黄同学h 的 AI 开发工作流：需求对齐、端到端验证与代码 Review
来源：黄同学h 的 X 长文《入职大厂两个月，我的 AI 开发心得》，发布于 2026 年 10 月 9 日。本文将作者的个人工具配置与可复用的工作方法分开呈现。模型名称、Skill、浏览器工具和团队测试环境均以原文发布时的实践为准，不代表当前产品状态或通用排名。
AI 编码工具越来越能完成实现任务，但“代码写出来”不等于“需求做对了”。真正限制交付速度的，往往是需求上下文是否完整、结果有没有业务证据，以及人工 Review 能否跟上 Agent 的产出。
本文的核心做法可以概括为：先把目标和验收标准说清楚，再让 Agent 在真实测试环境里完成小步实现；用测试、日志和业务状态形成证据，最后由人检查关键业务逻辑与未验证风险。
先理解作者的工作背景
原作者在团队中主要负责 Agent 开发，同时维护既有后端业务。他记录的工作流来自入职后的实际项目，不是经过控制实验得出的模型对比。原文提到，较重的 Workflow Skill 能帮助组织 Spec 和 TDD，但也可能让模型机械执行已经不再必要的步骤，并增加上下文和 Token 消耗。
因此，这套方法不是“不要流程”，而是把流程压到任务真正需要的程度：简单任务直接实现；会改变方向的需求问题先澄清；复杂工作拆成可独立验收的小增量；能由自动化证明的部分交给测试环境，仍需业务判断的部分留给人。
工具配置是个人快照
原文在 2026 年 10 月记录的分工包括：用 Codex 承担主要编码、用 Astra 规划、用 Pi 配合轻量模型处理简单需求，并用 Claude 或其他 Agent 做对抗性方案审查和 Code Review。作者还列出 think、grill me、implement、ponytail、handoff、check 等 Skill。
这些名称是作者当时的个人工具组合，不是必须安装的清单。选择工具时应先看任务类型、仓库约束、团队允许的模型和数据边界，再确认工具的维护状态、权限和成本。
一、用短方法提示代替固定长流程
作者观察到，很多 Coding Agent 已经学过成熟的方法论。与其把每一步都写成固定 Prompt，不如说明希望采用的思考方式，再补上当前任务特有的约束。短提示不能替代事实、上下文和验收标准，但可以快速改变审查角度。
第一性原理：重新确认问题，而不是沿着预设方案加功能
适合你怀疑解决方向已经被过早选定的情况。例如接口变慢，不要直接让 Agent 设计 Redis 缓存，而是先找出瓶颈位置：
不要基于“加 Redis 缓存”这个既定方案继续设计。
从第一性原理分析接口为什么慢，并给出最小必要的解决方案。
检查 SQL、网络、序列化、锁竞争和重复计算等可能原因。
这会促使 Agent 先收集性能证据，再比较方案。是否采用缓存，最后应由实测结果和一致性需求决定。
对抗性审查：尝试推翻核心假设
普通的“帮我看看有没有问题”容易得到宽泛的肯定。可以要求它优先寻找会推翻方案的反例：
对这个方案做一次对抗性审查，优先寻找能推翻核心假设的反例。
检查失败模式、并发、重试、超时和依赖不可用时的行为。
如果方案是引入分布式锁来处理重复请求，审查可以继续追问：接口幂等能否解决？锁服务故障怎么办？锁过期但业务尚未结束怎么办？局部问题是否引入了新的分布式故障点？
消融实验：判断复杂方案中哪些部分真的有用
如果一次改动同时加入索引、缓存和批量查询，最终变快并不能证明三项都必要。让 Agent 按 Baseline 设计对照组合，例如只加索引、索引加缓存、完整方案，并固定数据和测量方式。
结果必须来自可重复的测试，而不是 Agent 根据代码猜测。若只加索引已达到目标，剩余机制就需要额外证据说明其成本值得保留。
奥卡姆剃刀：删掉没有必要的机制
当设计包含 Kafka、Redis、分布式锁、状态机和定时补偿时，可以要求 Agent 在满足需求的前提下删除多余机制。原文的例子是：若场景实际只有单库写入，一个事务和唯一索引可能已经足够。
这不是要求永远选择最短代码。复杂性仍可能由吞吐、隔离、可恢复性或跨服务一致性要求支撑；关键是每个新增机制都应对应明确需求和验证办法。
高内聚、低耦合：检查职责边界
对于同时处理库存、优惠券、短信、支付和报表的超大服务，可以问哪些职责属于该模块，哪些应通过稳定接口交给其他模块。不要只为拆文件而拆，也不要把模块化建议当作自动重构命令。
二、从需求材料到可执行 Spec
作者把 PRD、会议纪要、聊天记录、用户反馈、团队 Wiki 和现有代码一起交给 Agent。真实需求通常分散且可能互相矛盾，因此不能只让模型总结文档后就进入编码。
1. 先整理事实与冲突
让 Agent 区分当前资料中的明确要求、相互冲突的说法、尚未回答的问题，以及它自己推断的内容。对有时间顺序的材料，要说明哪一份更新，避免旧 PRD 覆盖会议中的新决策。
2. 只追问会改变实现和验收的问题
用连续问题澄清目标、范围、边界和取舍。剩下的问题如果不会显著改变实现方向或验收结果，就可以开始开发；实现细节不必全部在需求阶段预先设计。
遇到必须由产品或业务负责人决定的问题，应列为待确认项，而不是让 Agent 用默认假设填补。
3. 把结论写到共享工件
把对齐结果沉淀成 Spec、Issue 或 CONTEXT.md。至少记录：
- 要解决的问题和目标用户；
- 本次包含与不包含的范围；
- 会影响实现的关键决策和待确认问题；
- 可观察、可判定的验收标准；
- 测试环境、数据准备方式和权限边界。
这样，负责实现和审查的 Agent 可以读取同一份事实，而无需重新依赖完整聊天历史。
三、按复杂度决定实现方式
Spec 明确后，由主 Agent 根据任务复杂度决定直接实现还是拆分工作。
- 简单、局部的需求：由一个主 Agent 直接完成，并运行相关测试。
- 较复杂但可划分的需求：拆成边界清楚、可独立验收的 Issue。
- 可并行的子任务：只有接口和文件边界清晰、相互依赖较少时，才交给 subagent 在隔离 worktree 中并行处理。
- 集成与验证：由主 Agent 统一检查契约、处理冲突、跑完整验证，并整理交付证据。
并行本身不等于提速。若两个子任务都要修改同一核心接口，或者一个任务必须等待另一个的设计决定，过早拆分只会增加协调和合并成本。
作者建议把重复出现的稳定流程沉淀为 Skill：当某一操作已经重复多次、输入和输出相对明确，且按步骤执行确实减少遗漏时，再抽象成可复用 SOP。不要把一次性操作或已经过时的步骤永久固化。
四、给 Agent 一个真正可操作的端到端测试环境
单元测试和集成测试很适合检查局部逻辑，但实际问题常出在它们没有覆盖的业务链路。作者为团队构建的测试环境，让 Agent 能从真实入口开始操作，并查询数据库、日志和 Trace。
测试环境需要提供什么
- 环境自检与启动：说明当前版本、测试账号、服务状态和权限，支持一键启动或明确报告缺失依赖。
- 数据准备与清理：可重复创建测试数据，说明如何重置，避免污染共享环境。
- 真实业务操作入口：通过浏览器、API 或 CLI 完成用户会走的流程。
- 只读取证工具：用受限的数据库查询、日志和 Trace 确认系统实际状态。
- 失败定位与复测：保留失败步骤、输入、请求标识和观察结果，修复后重跑相同场景。
这些能力可以封装成 MCP、CLI、脚本或 Skill。工具的形式不重要，关键是 Agent 能安全地操作测试系统并取得足够证据。
业务契约定义正确结果
数据库状态和日志是证据，不是验收标准本身。系统完全可能返回一个格式正确、流程也完整，但业务上错误的结果。验收标准必须来自需求或业务契约，再用浏览器表现、API 响应、数据库状态和 Trace 解释是否满足它。
如果被测产品本身是 Agent，还要增加答案质量评估。仅验证接口返回 200 或任务状态完成，不能证明回答有用、准确或遵循了业务约束。
五、小步实现、交叉审查和人工 Review
作者采用小增量开发：编码 Agent 实现一个可验收的变更并先做自测；按任务风险引入另一个 Agent 做交叉或对抗性审查；问题反馈给主编码 Agent 修复并重新验证；再跑端到端测试，最后由人检查核心业务逻辑。
Review 时按风险分配注意力
- 先对照验收标准：确认测试覆盖了需求真正关心的行为，而不只看通过数量。
- 沿业务路径检查：重点看权限、状态变化、并发、重试、数据一致性、迁移和回滚。
- 审查新增机制：确认新增抽象、队列、缓存或锁解决了真实需求，并有相称的复杂度收益。
- 结合测试证据：看端到端结果、关键数据状态、日志和 Trace，不用代码通过测试的事实掩盖测试覆盖不足。
- 记录未验证项：明确哪些环境、数据规模、并发条件或异常路径没有覆盖。
稳定且风险低的 CRUD 可以采用抽样审查，但前提是有可靠的测试和明确的业务边界。涉及权限、资金、生产数据或不可逆状态时，应提高人工审查强度。
团队 MR 数量较多时，可以把 Git 变更信息和固定审查流程组合成 Review Bot。它应帮助发现可行动的问题，价值要看问题是否重要、是否减少遗漏和人工负担，而不是评论数量。
六、降低 Review 瓶颈
Agent 可以并行推进多个任务，但人的需求理解、业务判断和交付确认速度不会自动变快。如果只提高代码产出，结果可能是堆出更多等待审查的变更。
更有效的改进方向是让重复、可自动判定的问题在交付前暴露：类型检查、测试和业务断言先由 Agent 运行；环境与数据检查提供失败证据；跨 Agent 审查关注高风险假设；人的注意力集中在需求是否正确理解、核心业务逻辑是否成立，以及剩余风险是什么。
同时要定期回看 Harness。某些约束可能只是弥补旧模型的短板；模型和工具变化后，应检查这些约束是否仍带来收益。对没有实际帮助的长 Prompt、重复确认和固定步骤做减法，但不要因此移除安全边界或必要验收。
一次任务的可复用清单
开始前
- 汇总 PRD、讨论记录、代码和团队知识，并标出冲突与过期信息。
- 澄清会改变实现方向或验收结果的问题。
- 写出本次范围、关键决策、待确认项和验收标准。
- 确认测试环境、账号权限、数据准备和清理办法。
- 按依赖关系决定直接实现还是拆分，避免无效并行。
实现与验证
- 每个增量边界清楚，完成后可单独验收。
- Agent 先运行相关自动化测试，再从真实入口执行端到端流程。
- 用业务契约对照结果，并保留页面、API、数据状态或 Trace 证据。
- 失败时定位、修复并重跑相同场景。
- 交叉审查重点寻找能推翻方案假设的反例。
交付前
- 人工检查权限、状态变化、并发、重试、一致性、迁移和回滚等风险。
- 确认新增复杂度有明确收益依据。
- 写明测试范围、实际结果、未覆盖项和剩余风险。
- 将稳定重复的测试步骤沉淀为脚本、CLI、MCP 或 Skill。
- 将 Review 反馈用于下一次迭代，并删除已经没有收益的流程约束。
结语
这套工作流最可复用的部分，是把 Agent 从“生成代码”带到“在受控环境里操作系统、取得证据并对照业务标准”。需求对齐减少方向错误，增量实现控制变更范围，端到端测试揭示真实链路问题，人工 Review 则负责那些无法交给工具定义的业务判断。
测试和 Review 只能降低不确定性，不能证明所有生产场景都安全。线上流量、并发、数据分布和外部依赖仍会产生测试环境没有覆盖的情况。交付报告应说明这些边界，而不是把“测试通过”写成“绝无风险”。