驾驭 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

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

可以把 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 注意力：

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

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

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

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

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

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

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

六、30 天刻意练习计划

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

第 1 周：意图表达

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

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

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

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

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

第 4 周：委派 + 元能力

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

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

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

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

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

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

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

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

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

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

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

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

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