微观管理 AI 无法扩展
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line unchanged and preserve all formatting, markdown, and technical terms as requested.
控制的悖论
你想要质量，所以审查每一行 AI 生成的代码。
听起来很负责。问题来了：
AI 在几秒钟内生成代码，而你要用几分钟审查它。
数学不成立。随着 AI 使用规模的扩大，审查成为瓶颈。你最终花在检查代码上的时间，比自己手写代码还要多。这就是微观管理的陷阱。
当控制变得适得其反
微观管理在 AI 开发中遵循一个可预测的模式：
- 你给出详细指令
- AI 快速生成代码
- 你仔细审查所有内容
- 你请求更改
- AI 重新生成
- 你再次审查
- 重复
每个循环都会消耗你的时间，抹去 AI 的速度优势。
此时，对于非平凡的代码，你不如自己动手写代码。
至少那样你会隐式地理解它，而不必承担解析他人实现决策的认知负担。
核心问题：不可扩展的责任
| 责任 | 描述 |
|---|---|
| Specification | 准确定义要构建的内容 |
| Verification | 确认已正确构建 |
两者都需要你的关注，都消耗你的时间，而且单个 AI 助手无法并行处理。这导致生产力出现硬上限：无论 AI 生成代码有多快，你的审查能力都会限制吞吐量。
解决方案：分离 Builder 与 Reviewer
与其使用一个由你监督的 AI，不如使用两个角色明确的 AI：
| 角色 | 职责 |
|---|---|
| Builder | 根据需求生成代码 |
| Reviewer | 检查代码中的问题并提出改进建议 |
关键洞察： Reviewer 的反馈直接送回 Builder。
flowchart LR
A[You (requirements)] --> B[Builder]
B --> C[Reviewer]
C --> B
B --> D[You (glance)]Builder 与 Reviewer 之间的循环在没有你参与的情况下运行。它们会反复迭代，直到 Reviewer 通过。你只需对结果一眼浏览即可。
人类何时介入？
仅针对缺乏客观正确答案的 权衡。
| 情境 | 处理者 |
|---|---|
| 明确的错误 | Reviewer → Builder |
| 缺少验证 | Reviewer → Builder |
| 命名改进 | Reviewer → Builder |
| 风格不一致 | Reviewer → Builder |
| 性能 vs 可读性 | 升级至人工 |
| 灵活性 vs 类型安全 | 升级至人工 |
| 约定 A vs 约定 B | 升级至人工 |
其他所有情况均由 AI 团队处理。
你实际要做的事
Your task shifts from review to glance.
| Before | After |
|---|---|
| Read every line | Skim for red flags |
| Understand implementation | Check for discomfort |
| Verify correctness | Trust the process |
如果没有任何不对劲的地方，你就完成了。快速浏览意味着要问：
- Does the structure match what I expected?
- Are there surprising abstractions?
- Is anything solving a problem I didn’t ask to solve?
你不需要验证逻辑或追踪控制流；审查者已经完成了详细工作。你的工作是整体层面的模式识别——这正是人类瞬间且直觉地完成的。
您的时间究竟花在哪里
| 低价值活动 | 高价值活动 |
|---|---|
| 逐行代码审查 | 端到端（E2E）测试 |
| 语法检查 | 集成验证 |
| 风格挑剔 | 行为确认 |
E2E 测试回答了关键问题：它能工作吗？
代码审查展示了如何构建某物；E2E 测试展示了是否它真的按预期工作。后者才是交付给用户的内容。
如果 E2E 测试套件通过且代码一眼看去没有红色警示，你就能在无需深度审查的认知负担下保持信心。
实施：升级规则
在你的提示中明确写出升级规则：
审查协议
When reviewing Builder's code:
1. Identify issues and suggest fixes
2. Send feedback directly to Builder for iteration
3. **Only escalate to Human when:**
- Multiple valid approaches exist with different trade‑offs
- The decision requires business/project context you don’t have
- Requirements are ambiguous or contradictory
Do not escalate:
- Clear bugs (just fix them)
- Style issues (apply project conventions)
- Missing error handling (add it)此协议确保只有在真正需要您判断时才会打断您。
信任转变
微观管理源于不信任：“我需要检查所有内容，因为 AI 可能会出错。”
Builder/Reviewer 模式并不能消除错误——它通过专门的验证步骤更早地捕获错误。你不是盲目信任 AI 的输出，而是信任包含验证的 过程。
| Trust Model | What You Trust |
|---|---|
| 微观管理 | 什么都不信任（自行验证所有内容） |
| Builder/Reviewer | 审核过程会捕获问题 |
第二种模型可扩展；第一种模型则不行。
这不是
这不是关于消除人类判断，而是关于将人类从不需要判断的循环中移除。
你仍然会：
- 定义需求
- 做出权衡决策
- 浏览最终产物以发现不适
- 对结果负责
你正在委派验证，而不是责任。这一区别很重要：你仍然对交付的代码负责，但你已经构建了一个系统，能够在不占用你注意力的情况下处理常规质量检查。
“超越提示工程”系列的一部分，探讨结构性和文化性方法如何在 AI 辅助开发中胜过提示优化。