第 4 部分：执行工作
你已经有了规则文件、精心设计的上下文和验证机制。现在你实际开始工作了。决定效果好坏的两个问题：你处于哪种模式，以及哪种类型的智能体适合这个任务。
两种模式：指挥官与编排者
大多数开发者在一天中会在两种模式之间切换。它们要求不同的技能，为错误的任务选择了错误的模式是常见的挫败来源。
指挥官模式是实时的、亲力亲为的。你在编辑器里，看着代码出现，用提示词和纠正来引导，保持精细的控制。你随时了解每一个变化。
- 最适用于：复杂逻辑、棘手的调试、不熟悉的代码库——任何你需要理解每一步的场景。
- 风险：如果你指挥每一次击键，你就成了瓶颈，速度提升也就消失了。
编排模式是异步的、更高层次的。你定义一个目标，把它交给智能体，然后审查结果——而不是盯着每次击键。智能体可以在后台并行运行，处理代码库的不同部分。
- 最适用于：定义明确的工作——Bug 修复、迁移、测试生成、遵循既定模式的功能。
- 注意事项：它需要更多的前期纪律，而不是更少。你必须在委派之前写出精确的规格说明。回报在第二个任务上到来，而不是第一个。
编排模式奖励的是与语法熟练度不同的技能集：
- 规格说明能力——把任务定义得足够精确，让智能体无需猜测即可执行。
- 分解能力——把大工作拆解成智能体大小的单元。
- 评估能力——快速判断输出质量。
- 系统设计能力——构建约束和反馈循环，让智能体保持高效。
智能体在你日常工作中的三个位置
换个视角来看同一幅画，智能体出现在三个位置。大多数人都会用到所有三种。
- 在编辑器中——内联补全和就地对话，具备全代码库感知能力。这是你保持心流的地方。（Copilot、Cursor、Windsurf、JetBrains AI。）
- 在终端中——你启动智能体，用自然语言给它一个目标，让它跨文件工作，运行工具和测试并对结果做出响应。这是认真的实操工作发生的地方。（Claude Code、Codex CLI 等。）
- 在后台——智能体在沙盒中自主运行，有时持续数小时，最后交回一个待稍后审查的 Pull Request。（Jules、Copilot agent 模式、Cursor 后台智能体。）
一旦看清这个映射就很直观：编辑器智能体适合你在写代码的时候；终端智能体适合跨文件探索和运行-响应；后台智能体适合任何你可以用一段话描述然后放手的任务。正确的起点是任务本身，而不是哪个工具声称自主性最强。
在沙盒中运行
当智能体执行代码时——运行测试、尝试修复、读取文件——它应该在一个隔离的沙盒中进行，只拥有一套有限的工具和访问权限。这正是让"思考 → 行动 → 观察"的自主循环变得安全的原因：智能体可以尝试和失败，而不会触及任何它不该碰的东西。
80% 问题（事情出错的地方）
智能体能快速生成一个功能大约 80% 的代码。剩下的 20%——边界情况、错误处理、集成节点、微妙的正确性——需要模型通常缺乏的深层上下文。而这恰恰是生产故障的藏匿之处。
危险已经转移了。早期 AI 的错误是明显的语法错误。如今的错误是概念性的：对业务逻辑的错误假设、遗漏的边界情况、悄悄累积维护债务的架构选择。它们之所以难以被发现，正是因为代码看起来是正确的，甚至可能通过基本测试。
具体来说：
# The agent's 80%: looks correct, passes the happy-path test
def apply_discount(price, percent):
return price * (1 - percent / 100)
缺失的 20% 是智能体不知道该问的所有问题：percent 能超过 100 吗？price 是整数分值还是浮点数？适用什么货币舍入规则？100% 折扣应该被允许吗，还是说这意味着上游有 Bug？这些都在代码中看不见——它们是你掌握而模型不了解的业务规则。
做得好的开发者不会试图通过接受一切来加快速度。他们把智能体用于定义明确的那 80%，把自己的注意力花在需要判断力的那 20% 上。
搭建你自己的工作流
- 在任务开始前，有意识地选择指挥官还是编排——并注意你什么时候是在亲自操刀本该委派的工作。
- 将智能体位置与任务匹配：流中写代码用编辑器，跨文件用终端，可以放手的用后台。
- 确保代码执行发生在具有作用域访问权限的沙盒中。
- 对每个功能，写下那 20%——边界情况和业务规则——即使测试通过了，也要亲自审查这些代码行。