软件开发没有「银弹」，我们公司有

"软件开发没有银弹"这句话收录于《人月神话》，“银弹”定义是能在十年内将软件开发的生产率、可靠性或简洁性获得数量级（10倍）提升的单一技术或方法，1986年到现在已经不止十年，如今来看也许 AI 是最接近“银弹”的东西，但它还不是。AI 能解决技术的问题，但需求的本质是人的问题，换句话说 AI 并不知道它为什么要做，但你知道。

我们公司有个类似 AI 中控台的工具(CTO 歪脖扣腚出来的)，覆盖了从开发前产出 PRD 到开发完上线验收的整个工作流，还包括 UI 可以用它产出设计图。CTO 会要求产品、研发、测试 都用这个中控台工作流，在他眼里这就是我们公司的“银弹”。为了方便阐述，下文中的“银弹”都代指这个 AI 中控台工作流。

初心是好的，设想也很美好，期望银弹可以让对 AI Agent 有不同理解、不同技术水平的人高效稳定且统一的产出。但却小看了真实世界的复杂度，想用线性的工作流去代替非线性的真实开发环境。

银弹的使用体验

我们公司几乎人人“全栈”，甚至 PM 和 UI 在 CTO 的要求下也要用银弹去开发和迭代功能，当用银弹去跑 PRD 动辄十几个小时起步，好不容易产品和 UI 跑出了 PRD，然后 CTO 会用银弹去验收并打分，如果不满95分会要求去修改 PRD，然后再用银弹去跑 PRD 又是十几个小时，也许你会想问为什么修改 PRD 也要这么久，因为 CTO 太想让银弹一条龙解决模糊需求到实现并上线的问题，所以并没有一个能修改的机制，有问题只能整段重新跑。于是我让 AI 试着分析一下为什么跑 PRD 需要这么久，如图：

而且银弹产出的 PRD 很臃肿包含了技术方案、验收方案、各种说明、银弹自己的产物，这进一步增加任务执行的时间。这么一来二去 PM 和 UI 半个月都没有用银弹产出能够被银弹验收通过的 PRD，也就没有继续开发功能（这么看来是不是还得感谢银弹，系统到现在还没全面崩盘）。

那我们公司的研发会用银弹吗？据我所知几乎所有开发都不用，至少是让 AI 写代码的过程中不用，产出 PRD 那没办法，得走个过场，要让 CTO 认为银弹参与了公司开发需求的整个流程，也就是经常会出现一种情况：功能都已经开发完了，PRD 还没跑完呢。

上线需求前我们也会让银弹去全面扫描代码分析所有可能的问题，这一步我倒是觉得问题不大，只不过银弹糟糕的设计和上下文编排，导致扫描出来的结果并不完整，会有遗漏，不过大部分时候有参考价值，这还是得益于 OpenAI 优秀的基模能力，可以在长时间任务以及数百次 tools calling 之后保证最初的目标没有大的偏移。

银弹的架构设计

银弹的架构设计给我一种很拧巴的感觉，初版的银弹用 shell 脚本来组织上下文然后发给 coding agent 去执行任务，同时保留了终端的入口。shell 脚本还是适合一次性的命令执行，去写稍微复杂一点的逻辑会变得脆弱且不可维护，在终端使用体验 REPL(Read-Eval-Print Loop) 十分糟糕。大家还遇到了各种 bug：Windows 的兼容性问题、大部分人跑出来的结果和 CTO 不一致等。所以此后都是在 coding agent 的对话框中让 agent 去执行脚本获取上下文来跑任务，这就很没有必要，能用 skill 解决的问题，非要让 agent 先去执行脚本，获取的上下文内容还十分庞杂，干扰任务执行结果。

后来也许是 CTO 意识到了这些问题还发现了大家好像不怎么用且不会用银弹，他的做法不是将上下文转为 skill 而是改变银弹的架构，由一个项目拆分为了三个项目：银弹的入口、银弹运行的上下文、网关。前两个很好理解，至于网关项目是用来看我们的使用情况，想要在自己电脑上运行银弹要先申请 token，运行时会校验本地的 token。然而这三个项目只有银弹入口会允许我们看（只是看，不能修改），其他两个项目仅对 CTO 和另外一个运维开放，维护迭代的人也仅限于这两人，也就是说 CTO 本意不想让其他的开发去维护上下文，也就没法让那些老开发去沉淀他们脑中的对于项目的理解和知识。

这里有个小插曲：我在研究银弹的入口这个项目时，发现 build 操作会产生压缩包，然而他却没有在 .gitignore 文件中添加压缩包名或后缀，导致每次 build 之后 .git 文件夹会多一个压缩包的提交历史，几次 build 后整个项目变得很大，达到了3个G。

有一次我查看提交记录，发现他把项目给删了并重建，我以为是为了方便没有去 GC git的关于压缩包的提交而重建项目，结果还是没有 git ignore 压缩包，而是缩小了压缩包的体积，每次 build 还是会导致项目无意义的占用变大。

CTO 开了很多次 AI 培训会，实则是银弹的布道会，会上只讲银弹的理念、机制和运行流程。开了等于没开，自始至终没说银弹到底是个啥，感觉就像他 vibe coding 时对 agent 说的话对着我们复述了一遍，期望着我们也能预测并理解。当有些人在会上提出一些问题和建议时，他只是糊弄过去，并保留着最终解释权。

寻找银弹的适配器

我们公司新人来的第一周不给项目权限，不给看代码来熟悉系统，第二周开始接需求并要求使用银弹来完成，面试时只问 AI 相关的问题和如何与 AI 协作，无论你的技术背景是啥、之前时做什么的，到了公司统一变为全栈开发，甚至招来了一个 Java 和 JavaScript 都分不清的人。新人流动率很大，要么因为用不好银弹被劝退，要么就是自己离开，同时还在解雇一些老开发，这就导致越招研发反而研发人越少。他曾经对我说过，他不会开除一个测试人员，因为那个测试人员本地的银弹的使用效果能够和他对齐。

CTO 心目中理想的人就是个银弹的适配器，是个在公司需求生产流水线上的螺丝钉，但 AI 时代最不需要的就是螺丝钉。