驾驭 Coding Agent：从快速生成到可靠交付的个人能力模型

Coding Agent 写出代码，已经可以很快；难的是让它持续交付正确、可靠、可维护的软件。

本文写给已经把 Coding Agent 用进真实项目，却开始被需求澄清、上下文失真、Review、返工或多 Agent 协调卡住的开发者。它不是工具选型指南、模型排行榜或「万能提示词」合集，而是一套较少依赖具体产品的个人能力模型。

你可以顺序阅读，也可以按问题跳转：想理解 Agent 为什么没有自动带来可靠交付，先读前两节；想诊断个人短板，读第三节；被 Review 拖慢，直接看第四节；想安排练习，读第五、六节；同类错误反复出现，从第七节反查闭环。

一、变便宜的是常规代码生产，不是工程判断

Peter Steinberger 是最早重度使用 Coding Agent 的工程师之一。他曾给自己的项目写下一份约 800 行的 AGENTS.md，其中有一大段手把手教模型使用 Tailwind 4——因为当时的 Sonnet 4.0 不认识这个太新的版本。几个月后 Sonnet 4.5 发布，这段说明被整段删掉：模型已经掌握了它，原来的教学从资产变成了噪声。

这个故事揭示的不是「技巧没有价值」，而是表层做法和底层原则有不同的保质期。

• 表层做法针对某个模型、工具、版本或当前缺陷，例如特定提示模板、会话编排和兼容补丁。它可能正是当下的最优解，但应该被视为可替换、需复查的实现层。
• 底层原则解决任何协作者都会面对的不确定性：意图是否清楚、信息是否相关、行动是否越界、结果能否验证、失败能否反馈。工具会换，原则通常更耐久。

因此，区分两者不必问「下一代模型还需不需要」，而应问：这项做法主要在补偿当前模型的局限，还是在降低意图、行动与验证的不确定性？ 前者要随模型更新而复查，后者值得内化成能力。

Simon Willison 从 2025 年到 2026 年写了大量 AI 辅助编程文章。工具换了一茬又一茬，他反复强调的仍是把规格写清楚、先跑测试、认真评审、维护好 Git 习惯。Jesse Vincent 的「架构师 + 实现者」双会话工作法也能跨工具迁移。具体形式会演化，背后的原则——先澄清意图，再执行，最后用反馈校准——相对稳定。

这也解释了一个容易被夸大的判断：正在下降的是把明确规格翻译成常规代码的生产稀缺性，不是全部编程能力。 领域知识、架构取舍、复杂调试、安全判断和结果责任没有因此消失；恰恰因为实现变快，它们更早暴露为交付瓶颈。

我把组织这些能力的总称叫作驾驭力（Agent Mastery）：把人的判断与 Agent 的执行组织成一个能够持续校准的可靠交付闭环。

贯穿案例｜订单 CSV 导出

假设你要给 SaaS 后台增加「按当前筛选条件导出订单 CSV」。Agent 很快就能写出按钮、接口和 CSV 序列化代码，但「完成」至少还包含四个问题：只有管理员可用吗？敏感字段脱敏了吗？导出的是筛选命中的全部订单还是当前页？十万条数据会不会拖垮在线请求？代码生成很便宜，不等于这些判断已经免费。

过去社区讨论 Harness，常把重心放在给 Agent 搭约束、验证和上下文管理体系。方向没有错，但 Harness 不会自动带来可靠交付，个人判断也不能替代系统约束。有效的关系是：人识别目标与风险，再把可重复的判断固化进 Context、Tools 和 Harness；系统返回证据，人据此继续校准。

二、你驾驭的不是模型，而是一个交付系统

很多失败被笼统归因于「模型不够聪明」，是因为我们把 Coding Agent 误看成了一个模型。实际参与交付的是一个系统：

可靠交付系统 = LLM + Context + Tools + Harness + Human Judgment

这不是可计算的数学公式，而是一张依赖关系图。五个部分各司其职，也无法简单互相替代：

要素	它决定什么	常见误解
LLM	理解、推理、规划与生成能力	把模型能力当成交付质量
Context	Agent 此刻能看到哪些事实、约束、状态与证据	信息越多越好
Tools	Agent 能读取、执行、观察和验证什么	只要能执行命令就够了
Harness	权限、环境、循环、检查点、反馈与记录如何被组织	把模型之外的一切都叫 Harness
Human Judgment	做什么、为何做、接受何种风险，以及何时可以放行	人必须手工介入每一步

可以把 Context 理解为信息平面，Tools 理解为行动与观察平面，Harness 是组织二者运行和反馈的机制，Human Judgment 则负责目标、取舍和责任。模型决定系统可能做到什么；Context、Tools 与 Harness 决定它能否稳定做到；人决定什么值得做、什么才算做对。

订单导出的例子里，LLM 可以提出实现方案；Context 要包含订单字段、筛选语义、权限规则、脱敏政策和数据规模；Tools 要能读代码、启动服务、构造多页数据并运行测试；Harness 要提供受控权限、测试命令、CI 门禁和验证记录；人则要决定哪些字段允许导出、大数据量走同步、流式还是异步，以及什么风险可以接受。任何一环缺失，都可能得到「代码写完了，功能却没交付」。

上下文工程：不是喂得越多，而是让正确的信息在正确时刻出现

上下文问题经常被简化成「再多给 Agent 几个文件」。但上下文窗口里有信息，不代表信息相关、真实、最新，也不代表 Agent 知道冲突时该信谁。更有效的上下文工程包含四个动作：

1. 选择： 只引入当前决策所需的代码、业务规则、示例和历史状态。对订单导出，权限中间件和订单查询比整个仓库的介绍更重要。
2. 组织： 区分稳定规则与临时任务状态，用索引和渐进展开替代一次性倾倒。AGENTS.md 适合放高频红线与入口，详细知识放到可按需读取的文档里。
3. 校验： 检查来源、时效、适用范围和冲突。让 Agent 复述关键假设，例如「当前筛选」是否包含全部分页结果，能在动工前暴露理解偏差。
4. 更新： 根据执行结果和业务变化修订上下文，删除过期规则。若导出功能因旧字段说明泄露手机号，修复的不只是代码，还包括字段政策的权威来源。

所以，上下文工程不是一次「喂足」，而是一个小循环：

选择 → 行动 → 获得反馈 → 校验 → 更新

这条小循环会嵌进更大的驾驭力闭环。人的判断发现系统缺口，Harness 把判断变成可重复反馈；系统越成熟，人越不需要在每次会话里重新口述同一件事。

三、驾驭力闭环：一块知识底座，六项能力

六项能力不是彼此独立的清单，而是一次交付中首尾相接的六类判断：

意图表达 → 委派决策 → 监督校验 → 失败诊断 → 资产沉淀 → 反哺下一轮意图

知识底座决定每一环的判断分辨率；元能力管理整条闭环中的注意力、节奏和责任边界。前一环的输出，是后一环的输入：意图不清，委派就无从判断；校验没有证据，诊断只能猜；诊断没有沉淀，同一个坑会在新会话里重来。

第 0 项：知识底座——表达的边界，就是认知的边界

它是什么： T 型知识结构里的竖杠——你在自己领域中的知识深度。Agent 显著降低了接触陌生知识的成本，却没有把「信息可得」自动变成稳定判断。提出更好的问题、做出更精简的表达、从多个方案中选出合适的一项，仍然依赖内化过的领域知识与工程经验。

订单导出看似只是生成 CSV，可靠判断却至少需要知道：权限必须在服务端执行，不能只隐藏按钮；「当前筛选」与「当前分页」不是一个语义；脱敏不等于任意删字段；大数据量导出还涉及一致性、内存、超时和审计。缺少这些概念，你甚至不知道该要求 Agent 证明什么。

具体做法：

• 积累「压缩过的判断力」。 第一性原理、奥卡姆剃刀、高内聚低耦合、幂等、正交——这些词有价值，是因为每个词背后都压缩了一类问题的判断框架。精简不是单纯删字，而是提高概念密度。
• 讲不懂就不放过。 接受自己无法复述的方案之前，让 Agent 解释到你能讲清它的假设、机制和边界。Agent 可以加速学习，理解仍要由你完成。
• 让方案互相质疑。 重要决策，让 Agent 给出立场不同的方案并互相反驳，你负责裁决。裁决暴露的知识缺口，比直接接受一个答案更有价值。
• 清理「默认接受」清单。 把「看不太懂但放行了」的改动记下来，定期挑一项补课。偶尔放行可以是风险选择，重复放行同一类问题则说明心理模型正在变薄。

刻意练习法： 接下来两周，每次想对 Agent 的产出说「行吧，就这样」时记一笔，标注是「判断过没问题」还是「看不懂，认了」。周末回看后者集中在哪些领域——那就是知识底座最值得补强的地方（若想系统地扩充知识广度，推荐阅读 慧悟万象阁：持续演化、结构严谨的知识体系，汇聚思维框架、效应、心智模型、定律、谬误、悖论、原则与策略，植根于哲学、淬炼于实践，适合用来提升判断力、澄清思路）。

能力一：意图表达力——把「想要什么」说成可执行、可验收的目标

它是什么： 在委派之前，把想法变成结构清楚的任务：解决什么问题、边界在哪里、什么算完成、什么明确不做、失败时应有什么行为。它表面上是表达，实质上是把模糊决策提前做完。

为什么难： 开发者习惯「边写边想」，因为过去实现很慢，思考可以摊在编码过程中。Agent 加快了实现，模糊处也会更快被默认假设填满。即使模型会提出问题，它也无法替你决定产品目标与风险取舍；流程没有要求澄清时，它往往会直接补齐空白。

具体做法：

• 开口前先答五问： 解决什么问题？怎么算完成？边界在哪里？哪些明确不做？失败时应该怎样？最后一个问题最容易被忽略，也最能区分演示与交付。
• 让 Agent 反过来问。 让它先检查项目现状，再一次只问一个问题，把模糊想法逐段逼成设计。分段确认能减少人在长篇结论前注意力滑走的概率。
• 为视觉问题提供视觉证据。 UI、报错和布局任务中，截图通常比长篇转述更接近事实；同时仍要补充无法从图中看出的交互与可访问性要求。
• 把稳定规格放进可评审的位置。 聊天记录适合探索，规格文件适合评审、复用和交接；临时想法则不必一律沉淀成长久文档。

对订单导出，一句「加个导出按钮」至少应展开为：只有管理员可以从界面和 API 发起；导出当前筛选命中的全部订单，而非当前页；敏感字段遵循既有脱敏政策；大数据量不得静默截断，并有明确的处理与失败反馈；本次不顺手重构整个订单查询模块。到这里定义的是目标与边界，还不必替 Agent 预先选定流式响应还是后台任务。

表达的分辨率仍受知识底座约束：你说不出脑中没有的概念。意图表达的产物不是漂亮文档，而是一组足以支持委派和验收的明确判断。

刻意练习法： 接下来的两周，每次给 Agent 下达任务前，先写一段 200 字以内的任务说明（目标 / 验收 / 不做 / 失败行为）。两周后对比：有说明和无说明的任务，返工次数差多少。

能力二：委派决策力——决定什么交给 Agent，以及怎样交

它是什么： 在「自己动手」「交给 Agent」和「先侦察再决定」之间做选择。它决定了注意力从哪里投入，也决定后续监督成本有多高。

为什么难： 委派过少，你会成为流程中的人工瓶颈；委派过多，则会把时间耗在盯梢、纠偏和收拾残局。边界还会随模型、工具、Harness、项目状态和任务风险而变化，不能凭一次经验永久划定。

具体做法：

• 用爆炸半径判断风险，而不是只数文件。 同时看影响范围、可逆性、耦合度、验证能力和失败代价。三行权限改动可能比三十个文案文件风险更高；大改动如果边界清楚、可隔离、可验证，也未必不能委派。
• 不确定时先派侦察兵。 让 Agent 先读调用链、列方案、指出未知项和预计改动范围，不直接写代码。侦察的价值不是生成一版注定丢弃的实现，而是用较低成本把雷区和决策点暴露出来。
• 优先并行低耦合任务。 调研、代码解读、低风险维护，以及已有详细规格且接口稳定的实现，通常监督成本较低。并行前仍需确认结果是否会争用同一业务规则或代码边界。
• 保留反向清单。 尚未确定的产品取舍、核心架构方向、缺少验证手段的高风险改动，不宜直接进入实现。Agent 可以辅助分析，决定权和风险责任不能无人承担。

订单导出适合先侦察：现有筛选条件在哪里构造？查询层如何处理分页？权限在哪一层统一执行？项目里是否已有脱敏函数、导出模式或后台任务？拿到这些信息后，再决定把权限、查询、导出和验证拆开，还是在一个边界清晰的任务中完成。

委派的关键前提不是任务看起来难不难，而是你能否定义边界、获得反馈并验收结果。

刻意练习法： 记一周「委派日志」：每个任务记录预估爆炸半径与事后真实返工时间。回看哪些任务类型稳定划算，哪些需要先侦察或自己拍板。每个人的边界都不同，因为它取决于项目和监督能力。

能力三：监督与校验力——用证据校准信任

它是什么： 在 Agent 声称完成之后，判断结果是否足以放行。核心不是在「全信」和「逐行读完」之间二选一，而是先核验证据，再按风险决定代码审查深度。

为什么难： Agent 的自述不是可靠证据。它可能没有实际跑过测试，也可能用错误的测试证明错误的实现；代码风格与项目一致，也不代表行为正确。另一方面，产出速度上升后，平均地审查每一行会把人变成限速环节。解决办法不是降低标准，而是重新分配注意力。

具体做法：

• 先做分级决策。 Review 开始时先看任务风险、diff 范围、执行过的验证及未验证项，再决定抽查还是深入审查。
• 按真实风险分配注意力。 权限与数据敏感度、影响用户或调用方的范围、可逆性、耦合度和自动验证覆盖，比「改动看起来小不小」更重要。
• 让 Agent 按固定格式汇报： 改了什么、为什么改；跑了什么、结果如何；实际验证了哪些路径；哪些没有验证。主动承认未知项，比笼统保证「全部通过」更有用。
• 对审查者也保持怀疑。 另一个 Agent 的审查结论同样需要证据。核实它标记的问题是否属实，也从它放行的高风险区域抽样，逐步了解它擅长什么、容易漏掉什么。
• 识别系统性模式。 一次局部小错可以就地修复；反复忽略失败路径、把编译通过当功能正确，则应进入失败诊断和资产沉淀。

订单导出的证据至少要回答：非管理员能否绕过 UI 直接调 API？管理员导出的行数是否与筛选命中数一致？跨页数据有没有遗漏或重复？敏感字段是否符合政策？大数据量是否会静默截断或耗尽资源？其中哪些尚未在真实环境验证？

刻意练习法： 连续一周，每次 Review 前先回答三个问题：「这次改动的风险是什么？验收标准是什么？我准备看哪些证据和哪些代码路径？」这三个问题会把模糊的「仔细看看」变成可执行的监督策略。

这一节给出能力原则；第四节会把它展开为完整的 Review 方法。

能力四：失败诊断力——先找断点，再决定怎么重试

它是什么： 当 Agent 交付不合格、循环打转或彻底跑偏时，判断可靠交付系统究竟断在哪一层。

为什么难： 不同根因常表现为同一句「结果不对」。不诊断就重试，只是在同一条件下再掷一次骰子；把一切归因为模型，又会把本可修复的规格、上下文和环境问题留到下一次。

诊断链应与前面的五要素系统对齐，从较容易检查的假设开始：

1. 意图与判断： 目标、验收和风险取舍是否清楚？Agent 理解的任务与你想的是同一个吗？
2. Context： 信息是否相关、充分、最新？是否漏了关键调用链，或同时存在互相冲突的规则？
3. Tools： Agent 能否执行真实路径并观察结果？环境起不来、权限不足、日志不可见，都会让它盲飞。
4. Harness 与验证： 反馈是否可信？测试是否覆盖目标？实现者是否也能随手改写裁判？
5. LLM 与任务形态： 前面都排查后，再考虑换模型、增加推理投入、拆小任务或改变协作方式。

Human Judgment 不是额外的第六层，而是贯穿整条链：每一步都需要人判断什么事实可信、什么风险可以接受。

订单只导出第一页，可能是规格把「筛选」与「分页」混在了一起，也可能是 Context 没揭示查询结构；CSV 泄露手机号，可能是脱敏政策缺失，也可能是验收没有覆盖字段；十万条订单超时，可能是工具环境没有规模数据，也可能是 Harness 从未检查资源上限。症状相似，修复位置完全不同。

刻意练习法： 下次 Agent 失败时，先忍住直接重试，花五分钟走一遍诊断链并记下根因。坚持一段时间，你会得到自己的失败分布图，也就知道改进应该优先投向哪一层。

能力五：资产沉淀力——让系统不用重复交学费

它是什么： 把重复出现的事实、约束、回归防护和流程固化到合适位置，让人的一次判断成为下一次任务的默认能力。它的复利效应最容易被观察：同一个坑不必在每个新会话里重新解释。

为什么难： 纠错后的自然反应是赶紧继续编码，而沉淀要求多走一步。另一个风险则是过度沉淀：把每次聊天结论都塞进仓库，最后得到一座过期信息的仓库。

每次纠正 Agent 后，可以追问：「可靠交付系统里缺了什么？」 再按四类落位：

• 缺信息 → 更新任务规格、AGENTS.md 索引或领域文档；
• 缺约束 → 对可机械判定的规则，优先变成类型、lint、权限门禁或架构测试；
• 缺回归防护 → 补成能复现问题的测试或契约；
• 缺流程 → 固化为 skill、脚本或 hook，减少重复的手工指挥。

订单导出踩过的坑可以分别沉淀为管理员权限测试、敏感字段白名单、跨分页回归用例、大数据量资源检查和导出审计记录。「筛选全集而非当前页」应进入规格或领域约定，而不是只在当次聊天里提醒。

资产沉淀也包含做减法。AGENTS.md 应优先保存高频红线和知识入口，详细内容按需展开；判断标准是相关性、可发现性和维护成本，不是固定行数。只有会复用、难以重新推导或能预防高代价错误的知识，才值得进入长期资产。模型、项目或业务变化后，过期规则要更新或删除。

刻意练习法： 给自己立一个简单规则：同一类错误被纠正第二次时，暂停编码，先判断它应进入信息、约束、回归防护还是流程。第一次可能是偶发，第二次已经值得检查系统是否有缺口。

资产沉淀完成后，闭环回到起点：下一次任务拥有更清楚的意图入口、更相关的 Context 和更可靠的 Harness。

能力六：元能力——管理注意力、节奏与责任

前五项能力构成交付闭环，元能力则贯穿每一环。在多 Agent 工作流里，人类的高质量注意力经常成为主要约束：并行执行增加产出，却不会让你同时拥有多份深度判断力。

具体做法：

• 默认由 blocked 通知驱动，同时保留关键节点抽查。 不必轮流巡视每个会话；让需要决策的 Agent 来找你，并在方案确认、权限变更、合并前等节点主动检查。
• 一次只深度评审一个变更。 调研和执行可以并行，深度判断很难等比例并行。频繁切换会让每个 diff 都停留在浅层。
• 给「快」设置刹车。 Agent 跑得越快，越要定期问：方向对吗？这是真需求吗？我是在交付行为，还是只在积累 diff？
• 允许 Agent 辅助慢思考，但不转移责任。 架构、产品取舍和风险判断可以让 Agent 提供方案与反驳，目标定义、风险接受和最终放行仍需有人负责。
• 保护学习带宽。 刻意保留理解调用链、亲自调试和复盘的时间，不是为了证明人写得更快，而是维护监督与诊断所需的心理模型。

订单导出中，查询调研、测试设计和实现可以并行；权限规则与脱敏政策应保持单一责任边界，最终风险评审串行完成。实现很快，不构成跳过筛选语义确认的理由。

刻意练习法： 连续三天记录深度评审时段和碎片切换次数，再用一周实践以 blocked 为主、关键节点抽查的方式。比较两种节奏下自己的判断质量和疲劳程度。

四、Review 的系统解法：证据优先，代码按风险审

深度使用 Agent 后，许多开发者会撞上同一堵墙：代码产出增长，Review 时间却无法同步增长。「检查它的时间比我自己写还多」，往往不是因为评审者读得不够快，而是旧的评审方式仍在把注意力平均分配给每一行代码。

需要改变的不是质量标准，而是评审顺序：

先用证据判断交付是否满足目标，再根据风险决定代码审查深度。

证据验证外部行为，代码审查内部结构、旁路和长期风险。证据不能替代高风险代码审查，逐行读代码也不能替代真实行为验证。目标不是「不审代码」，而是停止平均地审代码。

1. 先给证据分层，再检查证据质量

从「Agent 说做完了」到「结果足以放行」，可以分成四层：

• L0 自述： 「已完成，测试全部通过。」它只能告诉你作者的结论，不能单独作为完成依据。
• L1 过程记录： 实际执行的命令、测试输出、日志和断言统计。它证明某个过程发生过，但不自动证明过程与需求相关。
• L2 可复现行为： 他人能按明确的输入、步骤和环境重现预期行为，例如用非管理员账号调用导出接口并得到拒绝。
• L3 独立判定： 判定规则、执行环境或结果记录至少有关键部分不受本次实现变更控制，例如受保护的契约测试、只读金标准、外部评估或人工复核。

CI、类型检查和测试并不天然属于 L3。如果作者 Agent 能在同一次改动里同时修改实现、测试期望和 CI 配置，它仍可能改写裁判。新开一个审查会话也只是减少共享偏见，不自动构成独立判定。

层级只说明证据来源，还要从四个维度判断它是否可信：

维度	要问的问题
相关性	它直接证明验收目标，还是只证明了一个代理指标？
覆盖度	正常、边界、失败、安全与规模路径覆盖了哪些，又遗漏了哪些？
独立性	产出者能否同时修改测试、期望值、配置或裁判提示？
可复现性	输入、环境、命令和结果是否足以让别人重新得到结论？

不要把四个维度压成一个总分。一个高度可复现却验证错目标的测试，仍然是无关证据；一个覆盖很广却可被作者随意改写的裁判，也不足以独立放行高风险改动。

2. 把验收写成可执行断言

很多 Review 之苦，源于验收标准只停留在自然语言。规格写下「非管理员调用接口应返回拒绝」「筛选命中 231 条时 CSV 应有 231 行且订单 ID 唯一」「手机号只能出现脱敏格式」，行为验证就能从漫无目的地读代码，转成运行一组与目标对应的断言。

可执行验收不会让代码审查消失，也不是免费获得的：断言本身仍要检查相关性、覆盖度与独立性。它真正降低的是反复确认外部行为的成本，并把一次验收沉淀成未来可复用的回归防护。

3. 先审范围，再审实现

在委派前预估过爆炸半径，Review 时就可以用 diff 文件清单与计划对照。预期之外的文件、依赖和配置变化，是需要优先解释的异常信号，而不是必然错误——锁文件或生成文件可能是合理联动，顺手重构也可能是不必要越界。

范围审计先回答三个问题：

1. 实际改动是否仍服务于原始目标？
2. 有没有未经讨论的新行为、新依赖或权限扩张？
3. 测试、金标准和 CI 是否与实现一起变化，从而削弱了证据独立性？

范围对得上，才进入更细的质量判断；范围失控，则先收缩任务，而不是在扩大后的 diff 里继续找局部正确。

4. 按风险分配代码审查深度

「逐行读完」和「测试绿就全信」之间，存在按风险分配注意力的中间态：

• 低风险、可逆、验证充分： 做范围检查、复现关键证据，再抽样阅读实现；
• 中风险或耦合较高： 重点审边界条件、状态变化、错误处理、数据访问和兼容性；
• 高风险： 权限、敏感数据、资金、迁移、不可逆操作和大规模资源使用，需要深入审查关键代码、测试与运行证据。

历史表现可以调整额外抽查比例，却不能消除由任务风险决定的最低门槛。连续几次抽查无误，不代表下一次权限改动可以只看测试结果；一次低风险漏错，也不必把所有文案 diff 都升级成逐行审查。

信任不是谈出来的，而是持续校准出来的。抽查暴露的系统性偏差——例如总漏掉失败路径——应进入能力五的资产沉淀，而不是只在本次 diff 中修完了事。

5. 把评审前移到方案和证据设计

越早发现方向错误，返工通常越便宜。让 Agent 在实现前先给出计划：涉及哪些模块、接口如何变化、风险在哪里、准备用什么证据验收。你不需要把计划审成一篇完美设计文档，只需在代码大量生成之前拦住错误的边界和假设。

订单导出若在计划阶段就明确「筛选全集」「服务端权限」「字段白名单」「规模上限」，后续 Review 会有清楚的抓手；如果这些问题直到代码写完才第一次出现，测试和实现很可能已经围绕错误假设一起长成。

6. 用分离审查 Agent 补充视角，并校验审查者

有些代码仍需要第二双眼睛，而人的带宽有限，可以让另一个 Agent 审查。这里更准确的说法是分离审查：审查者不继承作者的结论和自我辩护，但必须获得相同的任务规格、验收标准、项目约束和必要代码上下文。完全没有上下文，只会让它在错误前提上独立犯错。

阅读它的结论与证据之后，再抽查两类内容：它标记的问题是否属实；它放行的高风险区域是否漏检。几轮下来，你会知道这个审查者擅长什么、在哪些问题上容易失明。它提供的是补充证据，不是自动生效的裁决。

7. 用同一任务把证据、风险和代码连起来

订单 CSV 导出可以这样分配 Review 注意力：

风险	先看什么证据	再审哪些代码
管理员权限	非管理员从 UI 与 API 发起均被拒绝	服务端授权位置、旁路入口、默认拒绝行为
敏感字段	样本输出与字段政策一致，日志不含明文	字段白名单、脱敏函数复用、错误日志
跨分页	多页数据行数、唯一性与筛选结果一致	查询条件复用、分页游标、排序稳定性
大数据量	规模测试、超时与失败行为可复现	内存上限、流式或异步路径、取消与清理

一套实用的 Review 顺序因此是：

确认范围 → 映射验收与证据 → 运行或复现证据 → 判断证据质量 → 按风险审查 diff → 把发现回流到 Context、Tools 或 Harness

这套方法的角色变化不是从「代码评审者」退成「测试结果查看者」，而是从平均拦截每个错误的质检员，转向设计质量反馈回路的人。体系越成熟，低风险区域越能依靠机械反馈；人的深度注意力则留给目标、风险和机器尚未证明的部分。

五、成长路径：从方向盘到编队

底座和六项能力不必同时练。不同阶段的主要矛盾不同，优先投入也不同：

阶段	人与 Agent 的关系	主要矛盾	优先练习	进入下一阶段前
方向盘期	你主写，Agent 处理局部任务	不敢交、不会交、交了不放心	意图表达 + 监督校验	已通过一批小任务校准边界，知道如何验收和诊断失败
副驾期	Agent 主实现，你负责方向、规格和验收	速度提高后，验证体系与心理模型开始吃紧	委派决策 + 失败诊断	关键路径有可靠反馈，重复纠正开始进入资产沉淀
编队期	多个 Agent 并行，你处理决策与集成	注意力、评审带宽和任务耦合成为瓶颈	元能力 + 资产沉淀	并行边界清楚，通知与门禁能暴露阻塞和集成风险

三个阶段不是勋章，而是当前位置。阶段高不代表交付强：副驾期没有建立验证体系就进入编队期，只会把一个不确定结果并行复制成多个。

订单导出在方向盘期可能由你实现、Agent 补测试；副驾期可以由 Agent 实现、你定义权限与验收；编队期可以并行做查询侦察、测试设计与安全审查，但权限和脱敏规则仍应有单一责任边界。升级的目的不是同时打开更多会话，而是让当前阶段的主要矛盾不再主导交付。

六、30 天刻意练习计划

读完能力模型只是「知道」。下面的计划把它变成一组实际练习；每周只聚焦一个重点，沿用你正在做的真实任务即可。

第 1 周：意图表达

• 每个交给 Agent 的任务，先写 200 字任务说明（目标 / 验收 / 不做 / 失败行为）再开口。
• 至少两次使用「一次一个问题」的追问方式，让 Agent 把模糊想法逼成完整规格。
• 周末复盘：比较有说明和无说明任务的返工情况。

第 2 周：监督校验 + Review 体系

• 每次 Review 前先答三问：风险是什么？验收标准是什么？要看哪些证据与代码路径？
• 把至少三个任务的验收改写成可执行断言；先运行断言验证行为，再按权限、数据、可逆性、耦合和资源规模等风险审查 diff。
• 每次都做范围审计：把 diff 文件清单与爆炸半径预估对照，解释预期之外的变化。
• 让 Agent 按固定格式汇报证据，并明确列出未验证项。
• 周末复盘：分级决策是否节省了时间？有没有被「全绿」误导？哪些问题只有代码审查发现？

第 3 周：失败诊断 + 资产沉淀

• 每次失败先走意图、Context、Tools、Harness/验证、LLM/任务形态的诊断链，再决定是否重试。
• 同一类错误第二次出现时，先判断应固化为信息、约束、回归防护还是流程，再继续编码。
• 周末复盘：画出自己的失败分布图——问题主要集中在哪一层？

第 4 周：委派 + 元能力

• 记委派日志：预估爆炸半径与真实返工时间。
• 如果你在运行多个 Agent：实践以 blocked 通知为主、关键节点抽查，记录深度评审时段与切换次数。
• 周末复盘：你的委派校准曲线是什么样？哪些任务类型稳定划算，哪些应该先侦察？

一个月后的产出不是又掌握了一组固定技巧，而是一张能力自评表、一张失败分布图、一张委派校准曲线、一份开始积累的资产清单、一份验收断言清单，以及一个更稳定的复盘习惯。表层做法会变化，这些对自身和系统的认识仍可继续复用。

七、六个闭环故障：从症状反查断点

同一个「Agent 不好用」的抱怨，背后可能是完全不同的闭环故障。遇到下面六种症状时，先找断点，再选修复动作：

症状	可能断裂的环节	先检查什么	首个修复动作
一失败就换模型或加 token	失败诊断被跳过	意图、Context、Tools、Harness 和验证是否完整	走一遍五层诊断链，再决定是否升级模型
AGENTS.md 越写越长	上下文的选择、组织和更新失效	哪些内容高频相关，哪些已过期，哪些可机械执行	保留索引与红线，把细节移到按需文档、测试、lint 或 hook
用代码行数、PR 数判断产出	目标和验收对象偏离	是否交付了可验证的用户行为	把评价对象从代码数量改回验收目标与可靠行为
同一个错误反复出现	诊断没有进入资产沉淀	缺的是信息、约束、回归防护还是流程	把第二次纠正固化到合适的系统位置
Agent 说「完成」就放行	监督校验断裂	证据的相关性、覆盖度、独立性和可复现性	复现关键行为，并按风险审查代码
产出增加，Review 流程不变	委派、Harness 与注意力没有校准	范围、风险分级、评审前移和自动门禁	先把高频验收变成反馈，再把人力留给高风险判断

订单导出少行、泄露字段和大数据量超时，看起来都可以被概括成「导出失败」，却可能分别指向意图、Context、验证覆盖或 Harness 的不同断点。用同一句提示重试，只会掩盖真正该修的位置。

这张表也可以每隔一段时间回看：你是在解决一次问题，还是已经让闭环下一次更不容易断？

八、结语：缰绳是双向反馈

「驾驭」这个词里有一幅画面：一匹强健的马，一副缰绳，一个骑手。

把缰绳只理解为限制，是对这个比喻的不完整理解。骑手通过缰绳传递方向、力度和边界，马通过动作、阻力与偏差把现实反馈回来；骑手再调整节奏。缰绳太松，失去的不只是控制，更是双向沟通。

规格、Context 和约束把意图向前传给 Agent；运行行为、测试结果和未验证项把证据向后传回来；人的判断据此校准下一轮任务，也更新 Tools 与 Harness。这才是驾驭力的完整循环，而不是写出一条完美提示词。

回到订单 CSV 导出：它最终是否可靠，不取决于 Agent 一次生成了多少代码，而取决于权限、脱敏、数据范围和规模风险能否被准确表达、被独立证据验证，并在失败后成为下一次任务的默认防护。第一次交付产生的不只是功能，也应该产生一个更不容易重犯同类错误的系统。

模型继续变强，会淘汰一部分表层做法，也会扩大我们可以委派的边界；与此同时，错误实现一项模糊意图的速度也会更快、影响范围也可能更大。因而，清晰目标、相关上下文、可信验证和工程判断不会因为生成能力提高而失去价值。

驾驭力不是比 Agent 更快地写代码，也不是把缰绳勒得更紧。它是持续校准人与系统的分工，让意图与反馈双向流动，最终把正确的想法变成可靠的软件。

Tags

• 人工智能