AI热榜 AI 写代码已经足够快，但从需求提出到生产上线，企业研发未必因此更快。
设计规范、工程资产、跨仓上下文、安全检查和协作断点，常常会把编码阶段节省的时间重新消耗掉。
如何让一个“会生成代码”的模型，成为真正能够交付、兜底和恢复的研发系统，正是 AI Coding 进入企业场景后必须解决的问题。
在 AICon 全球人工智能开发与应用大会上，小红书 AI Coding 总架构师郑鑫祺以 Vibe Coding 平台 Muse 和 AI Coding 实践为例，分享了小红书对这一问题的实践。
Muse 不只是一个代码生成工具，而是试图打通需求共创、设计、编码与交付，让产品经理、设计师和开发者在同一条上下文链路中与 AI 协作。
围绕“高可用”与“人机共创”，郑鑫祺重点拆解了 Muse 的 Agent Team 编排、Harness 控制机制、企业知识工程与 Agent OS 架构，并进一步讨论：面对持续增强的模型，系统如何兼顾精度与泛化，以及人的角色如何从具体实现转向更有价值的判断、监督与品味。
以下为郑鑫祺演讲内容，经整理。
AI 写得飞快，为什么交付并没有变快？
这次分享主要围绕两个关键词展开：高可用与人机共创。
高可用意味着，系统不仅能借助大模型解决局部问题，还必须具备稳定的交付、兜底和恢复能力。
毕竟，大模型本质上仍是概率模型。
如果系统只能完成演示，却无法进入真实生产环境，就不能称为高可用。
所谓人机共创，也不是简单地把工作交给 AI，而是人与 AI 共同讨论、持续判断，并将想法转化为最终产品。
2015 年毕业后，我曾在 Facebook 参与原型交互工具 Origami 的开发。
当时我关注的问题是，如何把头脑中的想象快速转化为可见、可操作的原型。
但原型完成后，新的问题随之出现：如何将它真正落到代码工程中？
从小型项目、创业公司业务，到大厂内部的复杂系统，不同规模的工程面临着不同约束。
此后的近十年里，我一直在思考：从产品原型到复杂系统，人应该如何与工程协同？
又该如何通过工程建模和架构设计，让不同开发者和团队保持高效、有序的长期迭代？
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接