Andrew Ng 这周抛出一个观察：90% 的 Agent 项目卡在落地，不是模型不够好，是流程没护栏。这周我们注意到一个国产开源项目 spec-superflow 正在解决同一件事——只不过切口更窄，专注"AI 写代码"这个场景。

这是什么

spec-superflow 是 MageByte 开源的一套 AI 编程工作流插件，本质是把一次代码变更拆成 9 个阶段（探索、写规格、桥接契约、执行、调试、审查、归档、合并），由一台 8 状态的状态机串起来。它解决的是两件事：第一，AI 没想清楚就动手；第二，规划文档写得漂亮，执行阶段照样跑偏。

核心设计是"契约层"：把规划阶段的方案、规格、设计、任务四份文档压缩成一份 execution-contract.md，执行阶段只认这份契约，不认聊天记录。需求漂移就强制回退，没批准就不许动代码。整套流程设了三道人工门禁，其中最关键的一道是"契约批准"——不点头，AI 连启动执行的资格都没有。

行业怎么看

支持方认为，这才是 AI 编程工具从"玩具"走向"工程化"的标志。规划与执行断层是 Claude Code、Cursor 这类工具普遍的痛点，spec-superflow 用硬约束而非软提示来卡流程，思路领先一截。

但反对声音也明确。第一，9 个 Skill + 8 状态的状态机学习成本极高，小团队和个人开发者很可能"配流程的时间比写代码还长"。第二，状态机的硬拦截意味着容错性低——一次需求变更就可能触发回退到 exploring，整体效率未必比人工 review 高。第三，目前没有公开数据证明它在大型真实项目里的稳定性，文中演示的"加 RBAC"仍是典型简化场景，距离生产环境考验还有距离。第四，开源项目的可持续性存疑：MageByte 是个人还是公司主导？后续维护与社区治理是否透明，决定它能不能进入企业采购清单。

对普通人的影响

对企业 IT：如果你们已经在用 AI 写代码且踩过"改完才发现方向错"的坑，这种带状态机和人工门禁的工具值得评估，但建议先在非核心项目跑 1-2 个月再下结论。

对个人职场：开发者不必焦虑被取代，但需要补一项新能力——把需求写成可校验的规格（SHALL/MUST + Scenario），这正在变成 AI 协作时代的基本功。

对消费市场：短期内不会直接影响消费者，但会间接影响所有软件产品的迭代速度与质量稳定性——尤其是那些依赖 AI 快速出原型的小型 SaaS 工具。