Cursor 工程师直说：真正的 AI 软件工厂不是更聪明，而是更不敢乱来

很多人以为“软件工厂”就是让 AI 自动写代码。Eric Zakariasson 在这场分享里却反着来：真正决定工厂能不能跑下去的，不是模型多强，而是你给它加了多少“不许做错事”的约束。这是一套明显和当下狂热氛围相反的方法论。

反直觉开场：你不是缺 AI 工人，而是缺一个“不出事的系统”

Eric 一开始就把话挑明：在讨论自动化之前，先想清楚你要什么级别的“自治”。很多团队上来就想要“全自动”，结果很快发现，问题根本不在模型，而在系统。

他把“软件工厂”描述成一个目标导向的系统，而不是一个更聪明的代码生成器。你不是在雇一个写代码的 AI，而是在设计一条生产线——这条生产线要决定：AI 能做什么，不能做什么，什么时候必须停下来问人。

这点非常反直觉。过去一年，行业的主旋律是“让 agent 更自由”。而 Eric 的态度是：如果你不知道自己想要哪一档自治水平，那你根本不该谈软件工厂。

为什么要建“软件工厂”：不是省人，而是对抗规模失控

Eric 提了一个很多工程经理都会点头的问题：当代码库、需求和人都开始指数级增长时，靠个人英雄主义已经不行了。

他强调，建工厂的动机不应该是“少招几个工程师”，而是为了让系统在规模变大时仍然可控。否则你得到的不是效率，而是一堆没人敢动、却每天自动生成的新代码。

这里有一句非常值得记住的话：“你不是在自动化写代码，而是在自动化决策边界。” 软件工厂的价值，在于把哪些决策可以交给 AI、哪些必须由人拍板这件事，系统化、显式化。

真正的地基：代码结构、护栏和测试，比模型重要得多

进入具体做法时，Eric 讲得非常工程化。

第一层是代码结构。AI 工厂不是从 prompt 开始，而是从一个高度结构化、可被机器理解的代码库开始。没有清晰边界的代码，对 agent 来说就是一片沼泽。

第二层是 guardrails（护栏）。这些规则不是写给人看的，而是用来长期约束 agent 行为的：什么能改、什么不能碰、遇到不确定性要怎么处理。Eric 特别强调，这些护栏会“随时间外推”，也就是说，它们要在未来依然有效。

第三层是测试，而且是能验证真实用户行为的测试。他举了非常具体的例子：不仅要测功能对不对，还要测“按钮有没有 loading spinner”。因为一旦 agent 开始端到端改 UI，这些细节就是质量底线。

可验证输出：让 AI 产出的每一步都“可追责”

在演示环节，Eric 展示了一个运行在本地的系统：agent 启动服务、在 localhost 跑起来、产出可以被检查的结果。

这里的关键词是 verifiable outputs。不是“看起来差不多”，而是每一步都能被系统验证、被规则约束。

他还提到，用明确的 rules 去“引导” agent，而不是放任它自由发挥。原因很简单：你永远不该让一个未经验证的 agent 直接推到生产环境。 这一点他讲得非常保守，但也非常现实。

最容易被忽略的一点：管理者要把自己“自动化掉”

在 Q&A 里，Eric 把话题拉到了管理层。

当你开始构建软件工厂，你的工作会发生根本变化。你不再是 code reviewer，而是系统设计者。你的价值不在于多懂细节，而在于能否把自己的判断，变成系统的一部分。

他说得很直白：一个好的 manager，应该想办法“把自己自动化掉”。但前提是，你得先把规则、质量标准和风险底线想清楚。

最后他补了一句很有分量的话：在安全边界内，一定要给 agent 自由度。没有自由，系统不会进化；没有边界，系统一定出事。

总结

这场分享最大的启发在于：AI 软件工厂不是一场模型竞赛，而是一场系统设计能力的较量。真正拉开差距的，不是谁的 agent 更“聪明”，而是谁更早把护栏、测试和验证机制当成核心资产。如果你正在考虑引入 AI 自动化，不妨先问自己三个问题：我想要哪一级自治？我的代码结构是否机器友好？我有没有勇气不让 agent 直接碰生产环境？想清楚这三点，才配得上谈“工厂”。

关键词： AI 软件工厂， Cursor， Agent 自治， 工程护栏， 软件自动化

事实核查备注： 需要核查：演讲者 Eric Zakariasson 的职位与背景；视频的具体时长；演示中是否明确提到 localhost：3000；关于 guardrails 和 verifiable outputs 的原话表述。