从 Pete 的 AI Coding 工作流里，我学到的不是“多开几个 Agent”

过去一年，AI Coding 最容易被误解成一种更快的编码方式：给模型一段足够详细的提示词，等它写完，再把更多任务扔进去。Pete 的实践给我的启发恰好相反。真正改变产出的，不是让模型一次做得更多，而是把软件开发改造成一个能够持续观察、随时干预、快速验证的系统。

这篇文章不是复述 Pete 的工具选择，也不是把某个终端布局当作答案。工具会变化，模型也会变化；值得学习的是背后的工作纪律：任务要有边界，改动要有回声，自动化要能被人接管。

第一件事，是把任务写成一个可以被验证的假设，而不是一句模糊愿望。与其说“把 onboarding 做得更好”，不如明确：哪个用户动作要改变、哪些页面允许改、哪些数据不能碰、完成后用什么测试或截图判断。这不是为了给 Agent 加繁文缛节，而是为了降低它在错误方向上表现得很勤奋的概率。

我现在会在开始前先估计任务的“影响半径”：它会动几处状态、几类用户路径、几个文件边界？影响半径小的任务，适合直接交给一个 Agent 快速完成；影响半径大、依赖不清的任务，先让 Agent 只做代码阅读和方案对比。并行不是把不确定性放大，而是把互不干扰的小赌注同时推进。

这也解释了为什么“多个 Agent 同时工作”并不等于混乱。真正需要管理的不是 Agent 数量，而是写入冲突。一个 Agent 修构建、一个补测试、一个梳理文档，通常可以并行；两个 Agent 同时重构同一条数据流，就会把审查成本和回滚成本留给自己。并行前先按文件、模块和用户路径切分，胜过事后处理冲突。

第二件事，是把上下文当作产品接口，而不是聊天记录。成熟的项目不依赖某一轮会话还记得什么，而是把架构约束、关键决策、运行命令和验收方式放到 Agent 找得到的地方。文档不需要很长，但必须足够具体：这个目录负责什么、这条 API 的不变量是什么、改动后该跑什么。好的文档不是给人看的说明书，而是给下一次任务准备的压缩上下文。

这带来一个反直觉的结果：提示词可以更短。只要代码库本身有清楚的边界、命令和示例，任务描述只需要补充这次变化独有的信息。反过来，如果每次都靠一大段提示词解释项目结构，问题往往不在模型，而在项目缺少可被机器读取的秩序。

第三件事，是把验证放在生成之后，而不是相信生成时的自信。模型很擅长写出看上去合理的解释，却不能替代真实的构建、类型检查、测试和页面体验。对 UI 任务，一张截图往往比二十句“间距不对”更有效；对行为改动，一个能够复现问题的测试比“应该没问题”更可靠。Agent 可以写代码，但验收标准必须来自系统运行后的证据。

这里有个简单但很重要的闭环：提出任务 → 查看改动 → 运行最小验证 → 读失败信息 → 让 Agent 修正。不要把验证当成任务结束时才做的仪式。越早得到失败信号，Agent 的上下文越干净，修复也越便宜。对于耗时任务，我宁可让它先完成一个可运行的小切片，再基于真实结果继续迭代。

第四件事，是用原子提交把速度变成可控的速度。每个 Agent 只提交自己实际改动的文件，提交信息描述一个清晰意图。这样做不是为了 Git 历史好看，而是为了让你敢于尝试：出错时知道要回看什么，审查时知道改动服务于什么，多个任务并行时知道哪些结果可以保留。AI 提高了写入速度，更需要一个能够限制爆炸半径的版本控制习惯。

我尤其认同一个原则：人不必持续手写代码，但必须持续拥有停止权。当 Agent 的耗时、改动范围或方向明显偏离预期，最好的动作通常不是等它“也许会完成”，而是中断，问清状态，缩小问题，然后重新发出任务。把中断看作失败，会让人错过最便宜的纠偏机会；把中断看作控制系统的一部分，才能真正驾驭自动化。

这套工作流对产品也有直接影响。AI 让实现成本下降后，最稀缺的资源不再只是工程时间，而是判断什么值得实现。更快的 Agent 会更快地放大错误优先级，也会更快地验证正确假设。产品负责人要做的不是把需求写得更长，而是让每一次交付都回答一个值得回答的问题：用户行为是否改变？成本是否下降？体验是否更清楚？

因此，我不会把 Pete 的方式总结为“开更多窗口”或“只用某一个 CLI”。更准确的说法是：把 AI Coding 当作一套生产系统来设计。输入是任务与上下文，过程是受控的并行，输出必须经过运行时验证，版本控制负责保留选择权。模型会继续变强，但这套系统思维会持续决定谁能把能力转化为可靠的交付。

接下来我会继续试验一个更适合自己的版本：默认单 Agent 完成可逆的小任务；涉及多个模块时先做只读分析；所有用户可见改动必须有真实页面或测试证据；每周留出固定时间让 Agent 清理重复、过期依赖和脆弱测试。目标不是让 AI 替我工作，而是让我把更多时间放在定义问题、做产品判断和看见真实用户上。