AI 生成的代码经常有一种危险的完整感：命名合理、结构清楚、注释也很自信。但真实项目里，正确性不是靠看出来的，而是要经过 lint、类型检查、测试、构建和关键路径验证。

所以 AI 编程真正需要形成的闭环，不是“需求 -> 代码 -> 结束”，而是：

 复制代码改代码 -> 跑测试 -> 读失败 -> 定位原因 -> 再修改 -> 再验证

生成驱动很快，验证驱动才稳定

生成驱动的流程通常是：需求来了，AI 写一版代码，人看一眼，觉得差不多，就继续让它扩展。

这种方式适合做很小的原型，但在真实项目里会积累一堆未经验证的假设。代码可能编译不了，数据结构可能没对齐，旧行为也可能已经被悄悄改掉。

验证驱动的流程则把反馈提前接进来：每个小改动都有最小验证命令，失败以后先分析日志，再决定如何修复。AI 不再只负责提出实现，也要面对实现产生的真实结果。

为什么 CI 日志比“再检查一下”更有用

自然语言反馈经常很模糊：

• 这里好像不对
• 再优化一下
• 注意不要影响其他功能

CI 反馈则更具体：

• 哪个测试失败
• 哪一行断言不符合预期
• 实际值和期望值是什么
• 哪个类型没有对齐
• 哪个构建步骤失败

这类反馈更适合 AI 做定位。但日志具体不代表 AI 一定能直接修对。失败原因可能来自实现、测试、环境、依赖或数据准备，第一步仍然应该是分类判断。

先分析失败，再允许修改

我不建议把日志扔给 AI 后只说“帮我修好”。更稳的提示方式是：

 复制代码先不要修改代码。请阅读下面的 CI 失败日志，并回答：1. 这是实现问题、测试问题，还是环境问题？
2. 最可能相关的文件有哪些？
3. 日志中最关键的失败信号是什么？
4. 失败的根因是什么？
5. 修改后应该运行哪些验证命令？等分析完成后，再给出修改方案。

这一步可以减少几种常见的盲修：为了通过测试而改弱断言，删除真实业务逻辑，绕过错误，或者一次性改动太多文件导致根因更难判断。

不同改动对应不同的最小验证

不是每个任务都要立刻跑全量测试。更实际的做法是为不同风险选择最小验证集：

改动类型	最小验证
样式和页面布局	前端构建、关键页面检查
类型和接口定义	typecheck、相关单测
业务函数	单元测试、边界用例
接口行为	后端测试、接口 smoke test
跨模块流程	集成测试、构建、关键路径检查
发布配置	构建、启动检查、配置和回滚检查

验证命令应该提前写进项目规则或仓库地图里。否则 AI 还要先猜“这个项目怎么测”，反馈闭环会在第一步就变慢。

读失败日志时，先区分三类问题

实现问题

代码没有满足已有约束，例如返回结构错误、边界条件漏掉、状态更新顺序不对。这时应该修改实现，并补上对应测试。

测试问题

测试假设已经过期，或者断言写错了。不能因为测试失败就默认实现有问题，要对照需求和既有行为判断测试是否仍然有效。

环境问题

依赖未安装、端口被占用、环境变量缺失、数据库没有启动等。环境问题应该修复执行条件，不能通过改业务代码来“修好”它。

让 AI 先做这一步分类，能明显降低它把不同问题混在一起处理的概率。

CI 反馈也有边界

测试通过不等于产品一定正确。自动验证只能覆盖已经被定义的行为。如果测试本身漏了关键场景，CI 也可能给出绿色结果。

因此，验证闭环应该包含：自动测试、diff review 和必要的人工验收。AI 可以帮助解释失败、整理影响范围和提出补测建议，但不能把一条绿色流水线当作全部结论。

一次真实的失败分析应该怎么做

比如我让 AI 给记账 App 增加“本周餐饮支出查询”，CI 报告了下面的失败：

 复制代码FAILED backend/tests/test_parser_service.py::test_parse_this_week_category_expense_query
E assert result.data.recent_days == 7
E        got 6

这时不能马上把 6 改成 7。首先要确认项目对“本周”的定义：当前代码把本周理解为从周一到今天，测试运行日是周日，所以包含今天在内可能只有 6 个已完成的日期区间；也可能是测试预期落后于产品定义。

我会让 AI 先输出这样的分析：

 复制代码失败类型：实现或测试定义不一致，暂不能直接修改。需要检查：1. period_label = 本周时，服务层如何计算开始日期
2. recent_days = 6 是否是当前项目的既有约定
3. 其他“本周”测试是否也依赖这个口径
4. API 返回文案是否暴露了日期范围建议验证：先查看 parser、stats service 和本周相关测试，再决定统一修改实现还是修改测试。

这比让 AI 直接修失败更安全。它把一个数字断言还原成了产品口径问题，避免为了让 CI 变绿而制造新的不一致。

把 CI 输出整理成 AI 能读的反馈包

失败日志太长时，我不会把整个流水线历史都贴进去，而是整理一份最小反馈包：

 复制代码## 任务增加“本周餐饮支出查询”。## 最近改动- backend/app/parser/parser_service.py
- backend/tests/test_parser_service.py## 执行命令pytest backend/tests/test_parser_service.py -q## 失败日志只保留失败测试、异常类型、关键断言和 traceback 中的相关路径。## 当前不确定点本周是否包含今天，当前项目还没有写成统一规则。

反馈包越小，AI 越容易围绕真正的问题分析；同时保留任务和不确定点，避免它只盯着最后一行错误。

什么时候应该停止让 AI 继续修

出现下面情况时，我会暂停自动修改，转为人工判断：

• 连续两次修复让失败位置发生大范围变化
• AI 开始修改测试，却解释不清需求变化
• 失败同时涉及环境、数据和业务逻辑
• 修复需要改数据库迁移或生产配置
• 测试通过，但核心行为没有人工验收

停止不是流程失败，而是说明问题已经超出“小步验证”的范围。此时应该重新定义任务或补充上下文，而不是继续让 AI 试错。

最后

AI 生成代码是在提出一个解法，CI 反馈是在告诉你这个解法能不能站住。

没有验证闭环的 AI 编程，只是更快地产生不确定性。真正成熟的工作方式，是让 AI 习惯面对测试结果、阅读失败信号，并且在每次修复后重新证明自己的改动仍然成立。