写在前面
最近读到 Nicholas C. Zakas 的一篇文章，讲他怎么用 AI 写代码。这位大神你可能听过，ESLint 的创始人。
说实话，我自己用 AI 也有段时间了，但总觉得不对劲。
有时候它能帮上忙，更多时候是瞎改一通，改着改着就跑偏了，最后还得我自己收拾烂摊子。
看完他的文章我才明白：问题出在我把 AI 当成了一个全能助手。
Nicholas 的做法很有意思。他把 AI 当成一个团队来用，不同的角色干不同的活。
这个思路让我眼前一亮。
为什么需要"角色"
我们先想想平时怎么开发功能。
通常是这样：搞清楚需求，设计方案，写代码，测试调试。
这是个多阶段的过程。每个阶段需要的能力不一样。
产品经理关心"用户要什么"，架构师关心"怎么设计"，程序员关心"代码怎么写"。
如果让 AI 一口气把这些事全干了，它很容易乱套。
就像让一个人既当产品又当开发还要当测试，肯定顾此失彼。
那怎么办？
Nicholas 的答案是：给 AI 分配不同的"人格"（persona）。
让它在不同阶段扮演不同角色。每个角色只负责自己擅长的那块，这样就不会跑偏。
产品经理
这个角色负责把用户需求转化成产品需求文档（PRD）。
注意，是产品需求，不是技术方案。
它写用户故事和验收标准，不去想"用什么技术实现"。
Nicholas 的提示词大概是这样：
你是产品经理。把用户需求转化成 PRD，包含用户故事和验收标准。
信息不够就问我。文档保存成 Markdown，放在 docs 目录，
文件名用 kebab-case，以 -prd.md 结尾。
他用 GPT-4.1 扮演这个角色。
为什么？因为 GPT-4.1 比较"老实"，不会自作主张想技术细节。
而且便宜（不是高级模型）。
架构师
有了 PRD，该设计技术方案了。
架构师需要深厚的技术功底。它扫描代码库，找集成点，给出实现指南。
但注意，它不写代码，只写设计文档。
提示词类似这样：
你是软件架构师。产品经理提供了 PRD。
你设计技术方案，确保满足所有验收标准。
扫描代码库找集成点，创建详细的实现指南。
不要包含源代码。不清楚就问我。
文档保存成 Markdown，文件名把 prd 换成 techspec。
Nicholas 最开始用 Gemini 2.5 Pro，后来换成 GPT-5.2。
他说 GPT-5 技术深度更好，输出的规格更具体。虽然贵点但值得。
如果编辑器里没有 GPT-5，就用 Gemini 2.5 Pro。
实施者
有了技术规格，该写代码了。
这个角色任务很简单：照着设计文档，一步步实现。
它不需要做设计决策，听话干活就行。
提示词：
你是软件工程师，负责实现附件中的功能。
不清楚先问我。必须完成文档中所有步骤。
完成后检查是否有遗漏，有就补上。
重复这个过程直到全部完成。
Nicholas 用 Claude Haiku 4.5。
这个模型又快又好用，在 VS Code 里只算 0.33 倍费用，性价比超高。
唯一缺点是它经常忘记读 AgentS.md 文件，不过你可以明确提醒它。
备选是 Gemini 3 Flash，也是 0.33 倍费用，速度也快。但上下文窗口容易满。
问题解决者
理想情况下，代码写完就能跑。
但现实往往是：功能不工作。
这时候需要问题解决者出场。它像侦探一样，找出问题，给出修复方案。
提示词很直接：
首页登录后没更新，应该显示头像和登出按钮。修复它。
Nicholas 用 Gemini 3 Pro。
他说 Gemini 解决问题特别厉害，总能快速找到症结，而且改动精准。
不会像 Claude Sonnet 4.5 或 GPT-5.2 那样大刀阔斧改一堆代码。
技术规格审查员
这是质量保证角色，不是每次都用。
复杂功能时很有必要。
它审查技术规格，找出潜在的性能问题、边界情况、竞态条件。
提示词：
你是软件架构师。审查这份技术规格，
特别关注可扩展性和性能问题。
找出没充分处理的边界情况和可能的竞态条件。
对照 PRD 检查是否满足验收标准。
Nicholas 用 Gemini 3 Pro。
他说 Gemini 在这方面表现出色，能准确描述设计会在什么情况下出问题。
而且它是他用过最不阿谀奉承的模型（不会一味附和你，会坚持自己观点）。
实现审查员
这是另一个质量保证角色。
用来审查代码实现是否符合技术规格。
提示词：
你是软件架构师。审查附件中的技术规格，
然后扫描代码库，验证规格是否被正确实现。
如果有问题，按严重程度降序列出，并给出修复建议。
不要实现修复，只描述它们。
同样用 Gemini 3 Pro。
Nicholas 说在一次复杂功能开发中，即使他自己审查过了，Gemini 还是找出不少问题。
我的思考
看完这套方法，我觉得最精妙的地方在于：它把复杂问题拆解成了多个简单问题。
每个角色只做好自己的事，不操心其他的。
这样 AI 就不容易"走神"了。
而且，不同模型确实有不同特点。GPT 系列稳，Gemini 技术深度强，Claude 执行力好。
知道什么时候用哪个模型，这本身就是门学问。
当然，这套方法也有成本。
你需要在不同阶段切换模型，写不同提示词，还要管理各种文档（PRD、技术规格等）。
但我觉得这个成本值得，特别是处理复杂功能时。
还有一点让我印象深刻：Nicholas 强调要让 AI 不要写代码（在架构阶段）。
这听起来反直觉，但仔细想想很有道理。
如果架构师角色一上来就写代码，它很容易陷入实现细节，反而忽略整体设计。
总结
Nicholas 的这套"角色扮演"方法，本质上是分而治之。
把软件开发流程拆成多个阶段，每个阶段用最合适的 AI 模型完成。
产品经理负责需求，架构师负责设计，实施者负责编码，问题解决者负责调试，审查员负责质量把关。
这样做的好处是：每个角色职责清晰，不容易跑偏，而且可以充分发挥不同模型优势。
如果你也在用 AI 辅助编程，不妨试试这个方法。
别再把 AI 当成全能助手了，把它当成团队来用。
你会发现效率提升不是一点半点
粤ICP备14082021号
免费POC，
零成本试错
