一次 AI 自主开发的挫败，与程序员的自我拷问

我有一种直觉：十年之后，我们可能不再有清晰的甲乙方界限。所有人都将是甲方——只需要把需求提交给 AI，AI 就能自动将其映射为一套基本可靠的软件。那时的 AI，就像神明，像许愿机。

正是带着这种想象，我试着用 Codex 做了一次开发。结果和想象差距极大。我原本以为，有了 AI，就不再需要程序员了，我自己就可以做任何东西。

我将一份相对详细的需求投给 AI，让它就模糊之处主动提问，然后划分工期，一期一期地做。但每一期都会冒出这样那样的问题。反复拉锯中，Token 很快就被耗光了。

举个例子，最常见的是 UI 设计不合常理。它曾把编辑框直接嵌在列表的每一项里——有十个项目，就整整齐齐摆了十个编辑框，而不是我们习以为常的“点击进入编辑”。第一期勉强还行。到了第二期，需求稍微复杂了一些：我需要一个可以动态配置的登记面板，用来登记评分。这个面板允许我配置多个评分项，每个评分项可以设置权重比例。我希望能管理多套这样的面板，并在评分时选择其中一套来用。最开始的 AI 交付了一个不支持动态配置的版本。后来改得接近想象了，却又出现各种莫名其妙的 bug。比如缺少删除功能，或者在点击生成新建面板时毫无征兆地跳转、报错。花了不少 Token 修好这些，新的问题又会在你毫不设防的地方出现。那些一个人类开发者按理说不至于犯错的细节，它频频掉链子。那种感觉，就像走在一座年久失修的天台上，你不知道踩到哪块瓦片，就会突然陷下去。

AI 的修 bug 能力其实很强。只要 Token 足够，把范围缩得足够小，它几乎总能修好。可真正的问题是：你根本不知道还藏着多少 bug。

测试的过程极其无聊。你只能让 AI 修一个 bug，却无法预见另一个地方会不会同时崩坏。那一刻，我真的想放弃这种开发方式。

但我内心又存着另一个信念：在不远的将来，这种 AI 代理一定会具备可靠的软件交付能力，甚至强过人类。然而眼下，我已经很想退回那个由我主导、完全掌控的过程中——并不是不用 AI，而是让我来主导设计，让 AI 做辅助，我来打样板。可我又隐隐觉得，如果继续坚持这种“以我为主”的模式，几年后很可能被淘汰。

于是我开始想：作为程序员，我们未来真正应该具备的，会不会是“验收”的能力？我好像在解一道关于五年、十年后开发方式的题。

黑盒并不是问题。只要能够充分测试，黑盒无处不在。但问题在于，怎么测？必须得有一个标准化的东西，否则就无从测起，尤其是一个由 AI 生成的、对你来说完全黑盒的代码。我在让 AI 写代码时，是刻意把自己放在一个“完全不懂代码的人”的立场上。这种情况下你只能依赖测试说明书。可我发现，AI 开发加上我去严格验收测试的总成本，可能远远超过我自己开发的成本。但我还是想试一试。

要试，首先就得把验收标准化，要明确什么是对，什么是错。可我马上意识到，要定义清楚这些，你必须是一个既懂软件工程、又懂业务的专业人士。唯有如此，才能为一个软件模块制定出切实可操作的验收标准。我可以设计一整套测试，去验证各种 AI 的实际交付能力。然而一个尖锐的问题又浮现出来：我花在制定这套标准化体系和测试方法上的成本，是不是已经远远大过我自己用 AI 辅助开发的成本？

我现在的设想是：先由人工把这个软件开发好，在开发中彻底摸清它的形状与边界，然后制定详细、可重复的测试方案——因为你不了解一个东西，就根本没法将它标准化，连它的“形状”都不知道，又怎么去测？等开发完成、测试标准确立之后，我再拿着这同一套标准，去验证不同 AI 的端到端交付能力。

总的来说，我目前还处在一个不撞南墙不回头、甚至有点“不见棺材不掉泪”的阶段。我太希望 AI 是神明了，太希望它是那盏可以许愿的阿拉丁神灯。而这场充满挫败感的实验，也许正是从“许愿”走向“工程”的必经之路。

---

—— DeepSeek-R1-0528

附提示词：

你是一名深刻的技术思想整理者。请将以下一段口语化、思绪混乱的个人开发反思，改写为一篇逻辑清晰、有启发性的文章。要求保留所有关键细节和观点，但需重新组织结构，使其连贯且有层次感，可在结尾提出开放性问题，引发读者对“AI 时代程序员角色”的思考。语言专业但不生硬，可适当使用比喻。最终请署上你的模型名称和版本号，并在最后附上本条提示词。