AI写代码飞快，交付为何没变快？小红书拆解Muse架构

AI写代码已经足够快，但从需求提出到生产上线，企业研发未必因此更快。设计规范、工程资产、跨仓上下文、安全检查和协作断点，常常会把编码阶段节省的时间重新消耗掉。如何让一个“会生成代码”的模型，成为真正能够交付、兜底和恢复的研发系统，正是AI Coding进入企业场景后必须解决的问题。

在AICon全球人工智能开发与应用大会上，小红书AI Coding总架构师郑鑫祺以Vibe Coding平台Muse和AI Coding实践为例，分享了小红书对这一问题的实践。Muse不只是一个代码生成工具，而是试图打通需求共创、设计、编码与交付，让产品经理、设计师和开发者在同一条上下文链路中与AI协作。

AI写得飞快，交付为什么没变快

这次分享围绕两个关键词展开：高可用与人机共创。高可用意味着系统不仅能借助大模型解决局部问题，还必须具备稳定的交付、兜底和恢复能力。大模型本质上仍是概率模型，如果系统只能完成演示，却无法进入真实生产环境，就不能称为高可用。人机共创也不是简单地把工作交给AI，而是人与AI共同讨论、持续判断，并将想法转化为最终产品。

2015年毕业后，郑鑫祺曾在Facebook参与原型交互工具Origami的开发，当时关注如何把头脑中的想象快速转化为可见、可操作的原型。但原型完成后，新的问题随之出现：如何将它真正落到代码工程中。从小型项目、创业公司业务，到大厂内部的复杂系统，不同规模的工程面临不同约束。此后近十年里，他一直在思考：从产品原型到复杂系统，人应该如何与工程协同，又该如何通过工程建模和架构设计，让不同开发者和团队保持高效、有序的长期迭代。

过去这些工程约束主要面向开发者和研发团队。2024年年中，团队开始意识到AI的快速发展将同时改变单点模块的实现方式和完整研发流程。此前积累的问题开始与AI Coding产生交汇：AI时代需要被重新定义的，不只是Coding，而是整个研发过程。目前郑鑫祺在小红书负责AI Coding大专项及相关产品矩阵，Muse是其中具有代表性的Vibe Coding产品。

一个值得关注的现象是，尽管AI大幅提高了代码生成速度，需求从提出到上线的周期却未必同步缩短。来自团队内部及小红书更大范围的反馈显示：AI写得很快，但研发人员并没有因此明显变得更轻松。代码生成只是研发链路的一部分，AI生成的代码可能不符合公司设计规范；界面看似正常，进入生产环境后却暴露出安全问题；代码虽然能够运行，却不满足现有代码仓库和工程体系的要求。节省下来的编码时间，最终又被消耗在检查、提测、修复、反复沟通，甚至推翻重做上。

与此同时，助理型Agent的出现也提高了用户预期。人们希望通过少量沟通就能让AI理解意图并执行不同任务，而不是每次都要按照固定格式编写复杂的Prompt。归根结底，当前企业级AI Coding主要面临三类问题：

• AI不了解企业资产，生成结果难以满足研发和设计规范。
• 用户记忆、业务知识与任务上下文分散在不同平台，AI无法形成完整理解。
• 从需求到交付的能力链路尚未贯通，即使系统具备大量原子化Skill和工具，这些能力也可能相互冲突，难以形成稳定协作。

因此，团队关心的不只是如何用AI把一个Idea快速实现出来，而是如何将它转化为具有商业价值、能够进入企业生产环境的程序。

Muse：让需求、设计与研发进入同一个共创空间

传统工作方式下，产品经理通常使用文字描述需求。但在AI时代，如果依然要先写一份纯文字PRD，再通过会议向团队逐一解释，整个团队的竞争速度会受到限制。更需要的是快速产出A、B、C、D多个方案，直接运行实验，观察哪个版本效果更好。需求产出的速度，在很大程度上取决于原型产出的速度。如果原型能够立即交给下游使用，整个协作链路才能真正提速。

设计工作也是如此。过去设计师可能需要花费大量时间“搓方案”和比稿，还要与开发者进行非常深入的沟通，而这些环节消耗的时间可能远多于实际编码。过去的比稿依赖体力，AI时代的比稿更依赖判断力。当AI可以一次提供十个版本时，人需要做的是判断哪个版本正确，然后快速推进MMVP、MVP和后续放量。

产品经理、设计师和开发者之间的协作方式也应该随之改变。过去可能需要拉会、约时间，再在线下慢慢解释；团队期待的体验则是：在IM群里提出一个Idea，团队直接进入共创面板，产出符合企业规范的高保真原型。研发接手以后，再由另一个Agent延续上下文，继续完成后续工程。

Muse正是在这样的目标下构建的。它生成的内容符合小红书现有App的设计风格和研发规范，用户在对话时可以保持开放和自由，同时也可以在编辑区域中沉浸式修改作品。Muse生成的不是一个只能展示的HTML页面，也不是仍然需要二次转译的中间产物，而是以达到上线标准为目标、能够适配真实工程仓库的代码。

在整个研发体系中，团队把需求形成以前的工作称为“上工程”，把进入真实代码仓库后的实现工作称为“下工程”。上工程需要收集不同角色的上下文，辅助团队做出决策。例如，需求分析Agent可能更多地与BI和数据系统交互，围绕业务目标形成需求判断。决策明确以后，团队还需要快速确认产品到底改哪里、怎样改，并对多个设计方案进行比较。Muse主要承载的就是这部分工作。

通过Muse场景，团队可以直接生成Demo和PRD。一方面，这些内容可以用于汇报；另一方面，它们也为开发者提供了更完整、更直观的需求上下文。再往下进入真实研发阶段，可能由PM Agent负责拉群和沟通，由Dev Agent进入代码仓库完成落地。Muse自身同样需要使用Dev Agent的能力，因为它必须即时完成预览，并生成高质量、符合规范的代码。

过去的AI往往只是被分别塞进研发流程中的某个格子。格子之间彼此断开，上下文也无法传递。团队希望把需求共创、设计共创和Coding串成一条主线，使上下文能够沿着整个链路持续流动。

高可用人机共创面临的三类挑战

Muse的核心技术能力可以分成两个方向。第一个方向是Dev Agent。无论前面如何讨论需求，系统最终必须生成符合研发规范的代码。这里涉及Spec质量、企业知识理解，以及复杂代码仓库带来的上下文问题。过去面向人设计的工程体系中，存在大量复杂甚至过度的微服务拆分。进入Agentic系统以后，团队更强调One Context、One Workspace：无论信息散落在多少微服务和代码仓库中，Agent都需要把与任务相关的Context汇集起来。尤其在服务端系统中，一个任务经常涉及多个仓库，如何让跨仓信息在一个Workspace中形成完整上下文，是必须解决的关键问题。

围绕“高可用”与“人机共创”，郑鑫祺重点拆解了Muse的Agent Team编排、Harness控制机制、企业知识工程与Agent OS架构，并进一步讨论：面对持续增强的模型，系统如何兼顾精度与泛化，以及人的角色如何从具体实现转向更有价值的判断、监督与品味。