1. 核心原则：方向 > 速度#

• 最重要的是开头和结尾
• 尤其是开头：一旦走偏，后面越改越难救
• 先把设计想清楚，再让 Agent 动手

2. 先做 Plan，不要一上来就写代码#

• 把新功能需求简单整理一下
• 把同一份需求发给 3 个不同的 Agent：Codex、Claude Code、Cursor
• 都打开 Plan mode，让它们先出设计方案
• 这里尽量用最好的模型（GPT-5.5、Claude Opus 4.7）

3. 比较多个 Plan，选最优方案#

• 看谁的方案最好
• 再吸收另外两个版本的可取之处
• 并不是 Opus 4.7 / GPT-5.5 永远最好——选好主方案后，再把其他方案发给它参考借鉴
• 如果都不满意，就继续调提示词，多轮讨论

4. 按复杂度决定怎么执行#

简单 Plan → 直接开始编码

复杂 Plan → 拆成几个 Phases：

• 每个 Phase 写清楚要求
• 每个 Phase 写清楚验收方法
• 保存成 Markdown 文档
• 把相关素材也引用进去

5. 执行时按 Phase 推进，必要时人工纠偏#

• 偷懒做法：用 /goal 把计划文件发给它，让它按 Phases 执行
• 不放心的话：每步完成后人工审核一下，及时纠偏
• 越早纠偏，成本越低

6. 编码模型怎么选？#

• 有条件当然用最好的模型
• 想省钱的话，便宜一级也可以——因为设计清楚了、验收标准明确了，就不容易跑偏

7. 最后 Review，不必太多 Agent#

• 代码 Review 不需要很多 Agent 一起上
• GPT-5.5 这类模型就足够了
• 重点检查两件事：
  1. 是否符合设计要求
  2. 代码质量有没有问题

类比：这像什么？#

这就像管理一个真实的技术团队：