AI 开发工作流：轻量约束、端到端测试与人工审查

AI 能同时写多个任务，开发者确认业务是否正确的速度却不会同步增长。代码生成越来越快之后，瓶颈可能转移到需求判断、测试证据和人工审查。

黄同学在《入职大厂两个月，我的 AI 开发心得》中，分享了自己做 Agent 开发和后端维护时的工作流。本文按需求、实现、验证和审查四条线整理原文，最后补充一份落地清单。

原文发布于 2026 年 10 月 9 日。工具与模型分工属于作者当时的个人实践；文中效率和质量的描述也来自作者自述，没有提供可独立复核的对照实验。

1. 模型进步之后，工作流也需要做减法

作者早期使用过围绕规格说明和测试驱动开发组织任务的重型 Skill。这类流程能给 Agent 提供约束，但也可能让它在信息已经充分时，继续执行没有必要的步骤，增加 token 和沟通成本。

随着模型能力增强，某些原来用来补短板的要求，可能逐渐变成噪声。作者因此主张定期检查工作流：简单任务直接处理，复杂任务再增加规划、拆分与交叉审查。

这里需要区分两类约束：

约束	应如何处理
业务范围、权限边界、验收条件	必须明确，不能因为模型更强就省略
为特定模型设计的固定思考步骤	定期评估，删除不再带来收益的部分

后面这一区分是对原文的工程归纳。流程精简的目标，是减少无效动作，同时保留判断交付是否成立的依据。

2. 工具按任务分工，Skill 沉淀重复操作

作者把编码、规划、简单任务、方案设计和对抗性审查交给不同工具。在原文所述版本中，Codex 与 GPT-5.6 Sol 主要承担实现，Astra 负责规划；pi 搭配 DeepSeek V4 Flash 处理简单任务，Claude 5 Fable 参与审查，网页端 GPT-6 Pro 用于个人项目方案设计。

这份分工值得理解为个人经验，不能直接当作模型能力排名。真正可迁移的是：根据任务需要选择实现、规划和审查能力，而不是让每个任务都走同样的工具组合。

作者常用的 Skill 可以按用途归为几组：

• 对齐问题。 用 think 做方案讨论，用 grill me 或 grill with docs 追问目标、限制和取舍。
• 推进实现。 需求明确后，再用 implement 执行计划或 Issue。
• 压缩复杂度。 用 ponytail 检查过度设计，减少人工理解负担。
• 交接上下文。 用 handoff 把关键背景整理成文件，方便换工具或新会话继续。
• 审查变更。 用 check 等审查能力辅助 MR 检查。
• 复用业务流程。 把测试、查询日志等重复操作整理成自己的 Skill。

原文还提出一个经验阈值：同一流程做过三次以上，就可以考虑提炼成 Skill。适合沉淀的是稳定、重复、可验证的操作；每次都需要重新判断的决策，仍应保留任务上下文。

3. 短提示词可以指定方法，但仍要给出具体问题

作者倾向于用成熟方法论指定思考方向，减少长篇固定步骤。原文重点讨论了五种方法：

方法	主要用途	可以怎样提出任务
第一性原理	检查问题是否被预设方案带偏	先定位接口延迟来源，再判断是否需要缓存
对抗性审查	寻找推翻核心假设的反例	检查分布式锁是否必要，以及失效时会发生什么
消融实验	分离多个改动的实际贡献	分别比较索引、缓存和批量查询带来的收益
奥卡姆剃刀	在满足需求时减少机制	检查事务和唯一约束能否代替多套协调设施
高内聚、低耦合	判断职责边界	分析服务应承担哪些责任，再决定如何拆分

这些方法对应不同的工作：重新定义问题、质疑假设、测量贡献、降低复杂度、整理边界。它们不能相互替代。

比如，要求“做消融实验”后，仍需明确基线、输入数据、测量指标和可接受的误差；要求“简化设计”后，也仍需保留必要的权限和一致性保障。这是本文对原文的补充：方法名称可以压缩指令，但不能替代验证条件。

4. 从需求对齐到小范围交付

作者的开发流程从收集上下文开始：PRD、会议记录、聊天补充、用户反馈、团队 Wiki 和当前代码共同构成需求依据。

这些材料可能过时或互相冲突，因此 Agent 需要帮助找出真正影响实现的问题，再由开发者回答，或向相关同事确认。作者给出的停止条件很实用：当剩余疑问已不足以改变主要实现方向和验收结果时，就进入开发，不必穷尽所有细节。

对齐结果沉淀到 Spec、ADR 或 CONTEXT.md 中，重点记录：

1. 要解决的问题和本次范围。
2. 会影响实现的约束与决策。
3. 判断交付成功的验收标准。

接下来按复杂度推进。简单任务直接实现；复杂任务拆成边界清楚、可单独验收的 Issue。只有能独立推进的部分，才适合交给 subagent，在不同 worktree 中并行开发，最后由主 Agent 集成。

实现 Agent 完成自测后，视复杂度引入其他 Agent 审查，问题统一回到主 Agent 修复并重新验证。人工审查之前，再检查端到端业务路径。

作者减少逐行阅读的前提，是 MR 足够小，而且测试随着开发逐步覆盖完整路径。改动范围小，才能让人理解这次变更；业务路径验证，则检查这些变更组合后是否成立。

5. 给 Agent 一套能自己使用的端到端环境

原文认为，大量测试代码未必能发现部署后的实际问题。一个重要原因是，Agent 没有环境去执行真实业务入口、检查最终状态、追踪失败原因。

作者把自己的日常自测过程整理成四类能力：

能力	Agent 需要获得的条件
准备环境	启动方式、版本信息、测试账号、权限、数据准备与重置
执行业务	通过浏览器、API 或 CLI 完成真实操作路径
检查结果	只读数据库查询、日志查询与 Trace 定位
复用流程	将稳定操作写成脚本，将入口与排障方式整理成 Skill

作者进一步把这些能力整合到统一测试 CLI 中，覆盖环境检查、数据准备、场景执行、结果查询和清理。这样 Agent 可以反复使用同一条验证路径，减少人工复制命令和补充上下文。

原文提到用 ego lite 做浏览器自动化，并搭配 pi 与 DeepSeek V4 Flash。这属于作者的工具选择；本文没有验证这些工具的性能，也不据此作速度排名。

最关键的原则，是把验收预期和系统输出分开。数据库、日志与 Trace 提供观察证据，业务需求决定什么结果才正确。如果 Agent 看见系统返回某个结果，就把它认作标准答案，测试会变成对现有实现的复述。

对于产品本身就是 Agent 的情况，还要补上答案质量评估。请求成功、状态落库、页面显示正常，都不能单独证明回答准确、完整或符合用户意图。

6. 人工审查集中在业务风险和新增复杂度

作者强调，即使实现和测试由 AI 完成，开发者仍需对交付负责。审查可以按下面的顺序进行：

先核对验收范围。 确认测试覆盖了需求真正关心的行为，而不只是统计通过数量；特别留意遗漏的条件和异常分支。

再沿业务路径检查风险。 把精力集中到权限判断、状态迁移、并发、重试、数据一致性，以及迁移和回滚。作者会减少对模式稳定的 CRUD 的阅读投入，但这是建立在其业务环境和已有验证上的个人选择。

单独检查新增机制。 对抽象层、缓存、锁、状态机和补偿流程追问必要性：解决了什么已知问题，是否有更简单的方案，新增了哪些维护成本。

重复审查交给自动化。 MR 较多时，可以构建 Review Bot，把 Git 变更和稳定审查流程结合起来。它的价值应体现为发现了多少有效问题、减少了多少人工负担，而非评论数量。

7. Harness 的价值：上下文、执行环境和判断依据

这篇文章对 Harness 的理解可以归纳为三部分：

上下文：知道问题、范围和约束
    ↓
执行环境：能够运行系统、操作业务、查询证据
    ↓
判断依据：用明确的验收条件检验结果

这三个部分缺一不可。只有上下文，Agent 可能写出无法验证的方案；只有工具，Agent 可能不知道应该证明什么；只有测试结果，开发者仍可能看不出代码和测试是否共同误解了需求。

作者也提醒，端到端测试只证明特定环境和选定场景中的行为。生产流量、并发与数据分布，仍可能引入新的问题。

8. 可以从一条自测路径开始

以下是基于原文整理的实践清单：

1. 选一个经常人工验证、结果明确的业务场景。
2. 写清前置条件、操作入口和预期结果。
3. 准备测试环境、测试账号与可清理的数据。
4. 让 Agent 执行操作，并核对页面、接口和持久化结果。
5. 失败时保存日志、Trace 或其他能够解释原因的证据。
6. 将反复有效的步骤整理成脚本、CLI 或 Skill。
7. 用小范围变更交付，人工重点检查业务判断和剩余风险。
8. 模型或工具升级后，重新评估流程中哪些步骤仍有收益。

原文最后还谈到学习：AI 替开发者修复了问题，也可能带走亲自排查的机会。因此，节省的时间值得留一部分用于复盘——理解为什么出错、证据怎样支持判断，以及下次能否更早发现。

这套工作流最值得借鉴的，是让 Agent 能够独立获取验证证据，同时把需求解释、关键取舍和交付判断留在开发者手中。

来源与相关笔记

• 黄同学：入职大厂两个月，我的 AI 开发心得（原帖及长文）
• X 长文入口
• [[AI Agent/Agent Skill 完全指南：它是什么、怎么来的、为什么管用|Agent Skill 完全指南]]
• [[工作笔记/Stacked PRs：把大改动拆成一条可合并的依赖链|Stacked PRs：把大改动拆成一条可合并的依赖链]]