开发者角色转变：Conductor vs Orchestrator
两种工作模式
开发者流利地在两种模式间切换：
| 模式 | Conductor（指挥家） | Orchestrator（编排者） |
|---|---|---|
| 特征 | 实时、手把手指导 | 异步、多 Agent 委托 |
| 工作方式 | 在 IDE，看着代码出现，用 prompt 和纠正引导 AI | 定义目标、分配给 Agent、审查结果，不看代码逐行出现 |
| AI 角色 | 强大乐器，开发者主动指导每个移动 | 异步工作，可能后台并行，定期检查和路线纠正 |
| 适用场景 | 复杂逻辑、调试棘手问题、不熟悉代码库 | 明确定义任务：bug 修复、特征实现、迁移、测试生成 |
| 支持工具 | GitHub Copilot、Gemini Code Assist、Cursor、Windsurf | Google Jules、Copilot agent mode、Cursor background agents、Claude Code |
| 风险 | 可能成为瓶颈（吞吐改进受限） | 需要不同技能集 |
Orchestrator 需要的四种技能
| 技能 | 说明 |
|---|---|
| Specification（规范） | 足够精确定义任务，Agent 能无歧义执行 |
| Decomposition（分解） | 将大任务分解为适合 Agent 执行的单元 |
| Evaluation（评估） | 快速判断 Agent 输出是否满足质量标准 |
| System Design（系统设计） | 设计约束、测试、反馈循环保持 Agent 高效 |
The 80% Problem（80% 问题）
白皮书识别一个持久挑战：
“AI agents can rapidly generate approximately 80% of the code for a feature, but the remaining 20% - the edge cases, error handling, integration points, and subtle correctness requirements - demands deep contextual knowledge that current models often lack.”
翻译：AI Agent 能快速生成约 80% 的特征代码，但剩余 20%（边界情况、错误处理、集成点、微妙正确性要求）需要当前模型往往缺乏的深度上下文知识。
AI 错误的性质演变
| 过去 | 现在 |
|---|---|
| 简单语法错误 | 更隐蔽的概念失败 |
| 容易检测 | 更难检测 |
现在的错误类型： - 关于业务逻辑的错误假设 - 对模糊需求未寻求澄清 - 遗漏边界情况 - 创建微妙长期维护负担的架构决策
为什么更难检测？
“These errors are harder to detect precisely because the code ‘looks right’ and may even pass basic tests.”
翻译：这些错误更难检测正是因为代码”看起来正确”，甚至可能通过基本测试。
有效的开发者姿态
白皮书描述最有效开发者的做法：
“They use AI for what it’s good at (rapid implementation of well-specified tasks) while reserving their own attention for what AI struggles with (ambiguous requirements, architectural trade-offs, and correctness verification).”
翻译：用 AI 做擅长的事（明确定义任务的快速实现），保留注意力给 AI 困难的事（模糊需求、架构权衡、正确性验证）。
关键：不试图通过接受 AI 所有产出变得更快，而是将专业知识聚焦在最重要处变得更快。