全员 AI 开发导致代码变成黑盒，失去 Prompt 操盘手后平台还能撑多久？
最讽刺的环节在于，这个平台在正式上线运行后，公司才紧急招了一名 PM。这位 PM 的工作不是规划产品方向，而是对着已经跑起来的系统，像写考古报告一样补写需求文档。作为 QA，我当时的任务就是对照这些“马后炮”文档来写测试用例。在这种流程下，开发周期被极度压缩，初期的交付效率高得惊人。
在运行的这段时间里，我确实感受到了 AI 驱动开发的恐怖速度。当时平台经常出现随机报错，比如典型的 502 Bad Gateway 或者是前端某些组件在 Chrome 120+ 版本下出现的渲染崩溃。但只要我提交 Bug 报告，那个超级个体部门的反馈速度快到离谱，几乎在几分钟内就能把修复后的版本推上来。这种“报错-喂 Prompt-修复-部署”的闭环在当时看来竟然能够跑通，让我产生了一种错觉：也许未来的软件开发真的不需要传统的工程团队了。
然而，这种脆弱的平衡在今天被彻底打破了。我提交了一个影响核心链路的 Bug，结果等了半天没有任何回应。进群询问后才发现，公司为了追求极致的成本优化，把整个“超级个体部门”给裁了。
现在的局面极其诡异：平台依然在服务器上运行，用户依然在访问，但支撑这个平台的每一行代码全是由 AI 生成的。最致命的是，那个懂得如何精准操控 AI、知道在哪个环节喂什么 Prompt 来修复 Bug 的“操盘手”全部离开了。目前只剩下那个新来的 PM 坐在屏幕前，对着他补写的需求文档发呆，因为背后已经没有任何一个工程师能接单了。
这让我意识到，这种完全依赖 AI 生成且缺乏工程化沉淀的项目，本质上是一个巨大的“黑盒”。当代码不再由人类通过逻辑推演而写就，而是由概率模型生成时，代码的可维护性就变得极其依赖于那个掌握 Prompt 的个体。一旦这个个体消失，剩下的代码就成了无人能解的密文。
我们之前习惯于抱怨 AI 生成的代码 Bug 多、鲁棒性差，但现在我发现，在一个极端的环境下，能有人快速修 Bug 竟然成了一种奢侈品。如果一个项目在诞生之初就放弃了代码 Review、放弃了架构设计，仅仅追求“跑起来”的快感，那么它在失去 AI 操盘手的那一刻，其实就已经进入了死亡倒计时。因为没有任何一个新接手的工程师能快速理清这堆没有逻辑支撑的 AI 代码，除非他们能通过某种魔法复刻出前任的 Prompt 习惯。
