Hermes Agent 命令行操作界面
2026-07-15 3401541
2026-07-15 0
AI 生成的代码经常有一种危险的完整感：命名合理、结构清楚、注释也很自信。但真实项目里，正确性不是靠看出来的，而是要经过 lint、类型检查、测试、构建和关键路径验证。
所以 AI 编程真正需要形成的闭环，不是“需求 -> 代码 -> 结束”，而是：
复制代码改代码 -> 跑测试 -> 读失败 -> 定位原因 -> 再修改 -> 再验证
生成驱动的流程通常是：需求来了，AI 写一版代码，人看一眼，觉得差不多，就继续让它扩展。
这种方式适合做很小的原型，但在真实项目里会积累一堆未经验证的假设。代码可能编译不了，数据结构可能没对齐，旧行为也可能已经被悄悄改掉。
验证驱动的流程则把反馈提前接进来：每个小改动都有最小验证命令，失败以后先分析日志，再决定如何修复。AI 不再只负责提出实现，也要面对实现产生的真实结果。
自然语言反馈经常很模糊：
CI 反馈则更具体：
这类反馈更适合 AI 做定位。但日志具体不代表 AI 一定能直接修对。失败原因可能来自实现、测试、环境、依赖或数据准备，第一步仍然应该是分类判断。
我不建议把日志扔给 AI 后只说“帮我修好”。更稳的提示方式是：
复制代码先不要修改代码。请阅读下面的 CI 失败日志，并回答：1. 这是实现问题、测试问题，还是环境问题？
2. 最可能相关的文件有哪些？
3. 日志中最关键的失败信号是什么？
4. 失败的根因是什么？
5. 修改后应该运行哪些验证命令？等分析完成后，再给出修改方案。
这一步可以减少几种常见的盲修：为了通过测试而改弱断言，删除真实业务逻辑，绕过错误，或者一次性改动太多文件导致根因更难判断。
不是每个任务都要立刻跑全量测试。更实际的做法是为不同风险选择最小验证集：
| 改动类型 | 最小验证 |
|---|---|
| 样式和页面布局 | 前端构建、关键页面检查 |
| 类型和接口定义 | typecheck、相关单测 |
| 业务函数 | 单元测试、边界用例 |
| 接口行为 | 后端测试、接口 smoke test |
| 跨模块流程 | 集成测试、构建、关键路径检查 |
| 发布配置 | 构建、启动检查、配置和回滚检查 |
验证命令应该提前写进项目规则或仓库地图里。否则 AI 还要先猜“这个项目怎么测”，反馈闭环会在第一步就变慢。
代码没有满足已有约束，例如返回结构错误、边界条件漏掉、状态更新顺序不对。这时应该修改实现，并补上对应测试。
测试假设已经过期，或者断言写错了。不能因为测试失败就默认实现有问题，要对照需求和既有行为判断测试是否仍然有效。
依赖未安装、端口被占用、环境变量缺失、数据库没有启动等。环境问题应该修复执行条件，不能通过改业务代码来“修好”它。
让 AI 先做这一步分类，能明显降低它把不同问题混在一起处理的概率。
测试通过不等于产品一定正确。自动验证只能覆盖已经被定义的行为。如果测试本身漏了关键场景，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 变绿而制造新的不一致。
失败日志太长时，我不会把整个流水线历史都贴进去，而是整理一份最小反馈包：
复制代码## 任务增加“本周餐饮支出查询”。## 最近改动- backend/app/parser/parser_service.py
- backend/tests/test_parser_service.py## 执行命令pytest backend/tests/test_parser_service.py -q## 失败日志只保留失败测试、异常类型、关键断言和 traceback 中的相关路径。## 当前不确定点本周是否包含今天，当前项目还没有写成统一规则。
反馈包越小，AI 越容易围绕真正的问题分析；同时保留任务和不确定点，避免它只盯着最后一行错误。
出现下面情况时，我会暂停自动修改，转为人工判断：
停止不是流程失败，而是说明问题已经超出“小步验证”的范围。此时应该重新定义任务或补充上下文，而不是继续让 AI 试错。
AI 生成代码是在提出一个解法，CI 反馈是在告诉你这个解法能不能站住。
没有验证闭环的 AI 编程，只是更快地产生不确定性。真正成熟的工作方式，是让 AI 习惯面对测试结果、阅读失败信号，并且在每次修复后重新证明自己的改动仍然成立。