夜雨聆风
AIcoding时代
AI Coding 摧毁的不是"完成"的定义而是验证的节奏
用AI写完了代码，Agent 自动跑了一遍测试------全绿。上线不到半小时，用户手点出了bug。
你遇到过这种情况吗？小范的团队上周就遇到了这样的情况。
出现这种情况，很多人的第一反应是："全绿就代表完成了吗？完成的定义都没有想好。"
仔细想想，如果自动测试真的覆盖了全流程、全模块、全单元、全集成、端到端，那么bug 为什么没在测试阶段暴露呢？
那么答案就只有一个：
验证体系有盲区。bug没被拦住，不是因为"完成"这个词定义不清，而是验证的覆盖范围根本不够。
那么，要怎么办呢？
"慢"曾经是一种隐性的质量保障
先说一个容易被忽略的事实：传统开发中，人工来coding，会自带一层隐性质量的保障。因为人写代码时，会思考——"这个判断会不会影响那个模块？""改了这块，下游接口会不会挂？"
这些思考本身就是一种实时、低成本的验证。你甚至不需要写测试，光是想逻辑，就会避免一些错误。
然而，AI 把"写代码"压缩到了几小时、几分钟、甚至几秒。因为AI写代码是从0到1的线性思维，而审查代码是从一还原到零的逆向破译。
但人写代码的时候，是顺着思路读来写的。
当人来看 AI 生成的代码的时候，因为意图消失，就必须要从结果反推来思考“AI为什么这么写”。
这从而导致了后期，对于AI 代码的维护成本远大于生成成本，因为它把“阅读理解”变成了“考古学”。
这也可能存在AI 没有断崖式的减少工作量，它把"理解"和"验证"变成了串行过程，而不是人类写代码的并行过程。
这个串行化才是"完成"变得模糊的根本原因——不是定义变了，是认知节奏被打乱了。
PMBOK 讲项目质量管理，强调"质量是规划和过程管理出来的，不是检查出来的"。以前写代码慢，规划和验证自然同步；现在生成是瞬时的，验证变成了事后补救。这才是问题的本质。
对软件工程中“完成”的重新洗牌
有人把"完成"拆成五层：代码完成、本地验证、集成验证、需求验收、工程完成。
代码完成=代码编译通过，不报错
本地验证=本地环境单元测试验证通过
集成验证= CI/CD 流水线验证通过
需求验收= UAT通过
工程完成=可发布就绪，同时可交接运维
这些在传统软件工程里都有成熟的工作清单——Definition of Done、测试金字塔、部署流水线、发布检查清单。
问题从来不在于"没有标准"。标准一直都在。
问题是：这些标准在 AI 的速度下被跳过了。
以前一个功能写三天，过程中自然走完了理解、自测、联调。现在三十分钟生成完毕，大脑还没跟上，代码就已经在仓库里了。门禁形同虚设——不是不存在，是还没来得及执行，代码已经往下走了。
那么，真正的难点是什么？
不是重新发明框架，而是让这些门禁在 AI 快速生成代码的前提下，仍然被强制执行，而不拖垮效率。
AI 代码的三个本质差异
既然不是框架的问题，那 AI 生成的代码本身有什么不同？
其实在我看来有三个点：
意图消失。人写代码的时候，每一行背后都有可追溯的意图和犹豫。
"这个判断是为了处理 A 客户的历史遗留"；"这个空值检查是因为上个月出过事故"。
而AI 生成的是无犹豫，无担忧的、统计意义上的最优解，意图全部消失了。
这意味着需求验收变得更难：不仅要验证代码对不对，还要尝试重建代码背后的意图，判断它的分支逻辑是否真的覆盖了业务场景。
当需求没有被通过prompt描述出来的时候，AI 的"完成"其实是一个没有全面的完成。
绿色幻觉。AI 生成的单元测试有一个特性：它们倾向于验证"代码做了什么"，而不是"代码应该做什么"。
因为 AI 同时生成实现和测试，测试往往是对实现逻辑的自我验证，而不是对业务契约的独立校验。
覆盖率很高，行为验证很弱——这就是"绿色幻觉"。那怎么办呢？测试必须从"验证实现"转向"验证契约"。
也就是，在进行AI coding的时候采用 “测试驱动生成”：先让 AI 读懂需求，生成验收标准和契约测试，人脑确认这个契约是对的；然后 AI 再生成代码去实现功能通过测试。
人审的是“业务契约”，AI 写的是“实现细节”。
这样既不降低速度，又守住了底线。先定义接口契约和行为边界，再让 AI 生成实现和测试。没有契约的测试，在 AI 生成代码时几乎等于没有测试。
还有一个就是级联穿透。
分层验证的隐含假设是：下层能过滤大部分错误。
但 AI 生成的错误是有连贯性的。因为 AI 的"理解"是概率性的，它对需求的一个误判，会系统地体现在所有层级上。从第二层漏掉的一个边界条件，在第三层变成集成错误；第三层的集成错误，在第四层表现为让人困惑的业务逻辑问题；到了第五层已经很难定位了。到第四层才发现的错误，可能在第二层就已经以另一种形式存在了。AI 的连贯性错误会穿透分层验证的假设。
"完成"是组织共识，不是工具问题
最后说一个更深的层面。
"完成"从来不是一个固定的分层模型，它是组织内的共识产物。
在传统开发中，团队通过长期协作建立了一套关于"什么叫做完"的默契。开发认为集成过了就算完成，测试认为没有bug 才算完成，产品认为客户满意才算完成，运维认为监控告警配好了才算完成。这套默契是隐含的、渐进形成的。
但AI 加入后，就打破了这套默契。
不同角色对"完成"的理解开始分化，而且分化的速度比达成新共识快得多。
因此需要重建完成共识机制，对不同角色进行重新约定强制设置门禁，且绑定到工作流中。
例如，PR 模板里必须包含“意图说明（Intention）”；CI 流水线里如果没有“契约测试文件”就直接构建失败；没有影响面分析就无法触发合并请求。
总结
在AI时代下，AI coding没有意图和犹豫，测试存在绿色幻觉，错误穿透全局，导致功能上线的反复和运维成本的增加，让软件工程对于“完成”的定义进行了重新思考。
对于AI-软件工程新范式下，是否需要把同步的思考与验证，变成了异步的生成与补救呢？
你有什么想法，欢迎评论区留言！
检查你团队的流水线上，有没有一个 AI 无法绕过的、由人类定义的‘契约检查点’。如果没有，那你现在拥有的不是一套 AI 研发体系，而是一台等待事故发生的生成器。
共勉～
END
小编不易点个赞呗!
