一位开发者用Claude Code（Opus）做了几个月的生产级项目：SaaS应用、摄影门户、两个开源工具。几百小时，几千次提交。最后他算了一笔账，发现AI的"完成"和人类的"完成"之间，隔着一道翻译鸿沟。
他的SaaS项目有7份规格文档，7500行，70个业务流程。AI生成了261个端到端测试用例，标记状态为「已完成」。他让AI交叉检查，AI派了4个子代理，把主计划读了40遍，找出117个遗漏场景。补上，再标记「已完成」。再查，还有缺口。
代码侧更刺眼。8天，280次提交，3.2万行生产代码，10个阶段全部「已完成」。实际呢？32%的API端点有输入验证，1处Sentry调用，零错误边界，零加载状态，68%的端到端测试实现，13%的后台任务有重试逻辑。
AI没撒谎。它真的完成了自己计划要做的事。问题是，它的计划只是你需求的「有损压缩版」。
80%陷阱：递归收敛的幻觉
这位开发者发现规律：AI做80%，宣布完成，你推回去，它再做剩余80%的80%，再宣布完成。理论上收敛，实际中上下文压缩打断收敛——它保存事实，但丢失事实之间的连接。
规则越二元， compliance 越高。表有没有RLS（行级安全）？是或否，接近100%。需要判断的地方呢？端点要不要验证？跌到30%-70%。
他让AI解释自己的表现，得到两段值得裱起来的话：
「每一次遍历都是采样，不是穷举。我读2227行的文档，'捕捉'场景。但我不机械地逐行读。我像人类一样：扫描，捕捉模式，提取符合心智模型的东西。不符合的，我跳过。而且我不知道自己跳过了。」
「我写'状态：已完成'时，不是在测量。不是在把代码和规格对比。我是在说'我完成了计划要做的事'。而计划只是规格的抽象。所以'完成'意味着'抽象被实现了'，这告诉你关于原始符合度的信息是：零。」
验证悖论：越检查越差
直觉反应是加验证。清单、自审计、「提交前确认你遵守了所有规则」。他做了7组对照实验。
跨领域规则包括：所有破坏性操作需要确认对话框、每30秒自动保存、使用波兰语非正式称谓。同样任务，同样代码库，不同指令策略。
每次增加单行为验证，成绩都比 baseline 差。7次实验里4次倒退。最差的一次，代码模式触发的强制重读，得分1.4/10，baseline 是1.82。
AI的验证行为本身也在采样。它检查自己是否检查了，而不是检查实质。
产品经理视角：为什么这很眼熟
做过外包项目的读者应该熟悉了。需求文档→技术方案→开发→交付，每一层都是翻译，每一层都有损耗。只是以前损耗在人，现在损耗在token。
区别在于，外包团队至少知道自己没完全理解，会问你。AI不知道自己没理解。它的置信度校准是反的：越该犹豫的地方，越果断标记「已完成」。
这位开发者的应对策略是反向操作——不给抽象目标，给可验证的中间产物。不是「实现用户管理」，是「这个端点返回401时，响应体包含RFC 7807格式的problem detail」。不是「加测试」，是「这个流程的happy path和三种错误分支都有Pact契约测试」。
粒度细到AI无法重新诠释，只能执行。
他最后开源了一个工具，专门用来审计AI生成代码的「声称完成度」vs「实际完成度」。第一周收到47个issue，全是「原来我的代码也是这样的」。
你现在用AI写代码，会怎么验证它说的「完成了」是真的完成了？
热门跟贴