Kevin Ma (@kevinma_dev_zh) “为什么“软件工厂”会失败？ Dex 这篇《Why Software Factories Fail》第二部分，核心观” — TopicDigg

为什么“软件工厂”会失败？ Dex 这篇《Why Software Factories Fail》第二部分，核心观点很简单： 别把需求扔给 AI，等它一次性写完几千行代码，再指望最后 review 一下就能上线。 至少在今天，这条路大概率会把开发效率从“写代码”转移到“清理 AI 产生的混乱”。 --- 很多人期待的是： “我描述一下需求，模型自己做完，代码自然能长期演化。” 但现实是，模型在局部任务上很强，在长期维护代码质量、理解隐性约束、处理架构取舍上，依然不够可靠。 所以问题不是要不要用 AI。 问题是：人应该在哪些环节保留判断力。 --- 作者的答案是：把 review 前移。 与其等 AI 写完一大坨代码后，再花几个小时改 PR；不如在写代码前，先花 30 分钟把关键问题想清楚。 这不一定让你 10 倍、100 倍更快。 但很可能让你稳定地快 2–3 倍，而且不会留下一个越来越难维护的代码库。 --- 一个更稳的流程，可以分成四步： 1. 产品设计：先说清楚用户到底有什么问题，什么结果算成功。能画界面就不要只写几段模糊文字。 2. 系统架构：明确服务、接口、数据模型和存储之间怎么协作。 3. 程序设计：继续往下细化到类型、函数签名、调用链和文件结构。这里最容易被忽略，但恰恰决定 AI 写出的代码会不会跑偏。 4. 垂直切片开发：每次只做一个能端到端验证的小闭环，而不是先写完数据库、再写服务层、再写 API、最后才打开前端看结果。 --- 所谓“垂直切片”，就是尽快把一个最小功能跑通： 先定义接口，返回 mock 数据； 然后让前端接起来，在浏览器里看效果； 再逐步接入服务、数据库、业务逻辑和异常处理。 每走一步都能验证，也都能及时纠偏。 这比一次生成 2,000 行代码，最后才发现方向错了，要便宜得多。 --- 作者还有一句很值得记住： 你不是 PR 太多，而是坏 PR 太多。 好的 PR 并不难 review。 因为关键决策早就在产品、架构和程序设计阶段对齐了。最后的代码只是把已达成共识的方案实现出来。 真正痛苦的是那种“一次性 AI 生成”的 PR：看起来量很大，但其中 20%、50%，甚至更多都需要返工。 --- 所以，AI 编程真正的杠杆不是“让模型替你思考”。 而是把人从重复劳动里解放出来，让人把注意力集中在更高价值的事情上： 需求是否正确； 架构是否合理； 程序结构是否清晰； 每一步是否真的在朝正确方向前进。 --- 一句话总结： 别追求让 AI 黑箱式地把软件做完。把 AI 放进一个有清晰约束、频繁验证、持续纠偏的开发流程里，才更可能真正变快。 —- 如果你想要阅读原文，推荐你使用 SentiaRead 来阅读这篇英文文章。 你可以直接复制链接导入到 SentiaRead 里面，或者使用浏览器插件。这个工具随时可以根据上下文语境来查询不认识的单词，或者把复杂的句子重写成简单、容易读懂的句子