AI编程不稳定？将PM与执行者角色拆分是关键解法

说实话，我一开始并没有打算搞什么"角色扮演"。当时的处境很朴素：我在做一个内部项目，代码量一上来，AI编程助手就开始变得时灵时不灵。同一个功能第一版写得挺好的，让它改两个需求点之后，整个模块就像被人用锤子敲过一样，边界乱了、注释过时了、连函数命名风格都前后不一致。

我花了挺长时间去调提示词、改对话策略，收效都不算稳定。直到后来我把整个工作流拆成了两个角色：先让AI做PM，只负责把需求和方案掰扯清楚；再开一个环节让AI做执行者，只负责把规格书翻译成代码。这个改动做出来的效果比我想象中好太多，返工率肉眼可见地降下来了。

这篇就聊聊我是怎么拆的，提示词骨架长什么样，以及整套流程在实际项目中跑起来有哪些地方容易翻车。想让自己手里的AI编程工具产出更稳定的朋友，可以直接照抄里面的模板。

1. 让AI直接写代码时，真正不稳定的环节在哪

1.1 一次对话承载了三层职责，模型很难兼顾

以前我让AI写代码，习惯特别简单：打开对话框，丢一句"帮我写一个用户登录模块"，然后回车。AI反应很快，接口、Token校验、刷新机制、密码找回逻辑全都给你喷射出来。第一次看确实挺惊艳，可一旦想把它接进现有项目，麻烦就来了——我只需要一个账号密码登录，它给我喷了一整片跟权限管理相关的代码，删代码的时间比写代码还长。

后来我想清楚了一个道理：当你说"帮我写一个XX功能"的时候，AI其实同时在干三件事：

• 搞明白你到底要什么（需求澄清）
• 决定这东西应该怎么做（方案设计）
• 把方案变成实际代码（落地实现）

这三件事对注意力的需求是完全不同的。需求澄清要会追问边界，方案设计要在多个方案里做取舍，落地实现则得一路写到底。模型的能力再强，也只是在同一个上下文窗口里分配自己的注意力。一旦你一句"帮我把这个功能写完"下去，它的注意力就会被"写完"这件事拽走，越到后面越顾不上去核对边界。

这就像让一个厨师同时干市场调研、设计菜单和炒菜。调研需要他冷静提问，设计菜单需要他反复权衡，炒菜需要他手上别停。三个任务抢同一个大脑，最后端出来的菜一定是同一个味道——不稳定。

1.2 目标漂移和过度补全是我踩过最多的两个坑

拆角色之前，我遇到的AI编程问题主要集中在两种现象上。

第一个叫目标漂移。你要的是一个列表页，第一轮生成还挺正常。等你让它增加一个排序功能，它会顺着自己的语言惯性，把筛选、分页、导出按钮全给加上，到最后你已经分不清它做的是列表页还是报表系统。它并不是故意乱来，而是大模型在生成长文本时天然会顺着"已有趋势"往下推，没有一个人替它踩刹车。

第二个叫过度补全。你说返回一个用户ID，它偏要返回整个用户实体，还带上传头像字段、状态枚举、关联角色列表。单看每一条都合理，加在一起就是灾难。而且这种问题很难通过"让它改"来解决，因为它每次重写都会用新方式重新过度补全。

我后来把这些问题的成因归结为"职责混叠"。当一个角色同时负责界定范围和交付范围时，它一定会偏向交付速度，然后悄悄扭曲范围。人如此，AI也差不多。这不是提示词调得不够好，而是工作流结构本身缺了隔离。

1.3 角色拆分不是玄学，本质是上下文隔离

把PM和执行者拆开之后，我再看这个问题就清晰多了。所谓拆分，其实就是在AI动手之前，先强制它把"做对的事情"和"把事情做对"分成两个阶段来处理。

PM阶段只做规划，输出的是一份任务规格说明书。这份文档不包含任何具体实现代码，但会写清楚背景、目标、边界、模块拆解、交互约束和验收清单。执行者阶段只做翻译，拿到规格书之后按图索骥，把文档逐条变成代码。它不需要猜需求，也不需要做技术决策，只需要做到文档说什么就做什么。

稳定性的来源其实不玄——它是把原本模糊的、依赖业务判断的问题，转换成了清晰的、可机械执行的问题。判断的环节变少，规则执行的环节变多，出错率自然就下来了。我在第一个项目里用了这个思路之后，最直观的感受是：AI不再自作主张了，或者说，它就算想自作主张，也没有那个权限了。

2. 拆出PM之后，这个角色具体要产出什么

2.1 任务规格书的核心字段

很多人在让AI当PM的时候，容易犯一个错误：只是口头说"你是一个PM"，然后让AI自由发挥。这样做的结果往往是得到一堆正确但没有约束力的废话。我试了几轮之后，把PM的输出强制限定在下面几个字段里，效果立刻不一样：

这几个字段里，我要求最严格的是"边界与不做的内容"和"验收清单"。边界字段是专门用来对抗AI过度补全的；验收清单则是用来消灭"应该差不多了"这种模糊状态的。

2.2 验收清单为什么是整个流程的锚点

验收清单的价值，我在传统项目里也体会过，但在AI编程场景里它的权重会放大很多。因为模型判断"完成"的标准，和你心里的标准通常不一致。你要是口头说一句"帮我写一个注册接口"，它默认你什么都要；但如果你在PM规格书里写死"密码长度小于8位时返回422，并在响应体里带error_code字段"，执行者就不会去自由发挥了。

写验收清单有个技巧：所有条目必须是可执行的表述。不要写"需要处理未登录的情况"，而是写"未登录访问/profile接口时返回401，且响应体包含error_code=UNAUTHORIZED"。前者还是留了理解空间，后者则完全没有歧义。

我把这条规则执行到位之后，发现验收动作本身也变得省力了。以前测试靠感觉，不知道自己有没有漏测；现在对着清单一条一条打勾就行。这个文件还能直接作为项目文档的雏形，方便后来人接手。

2.3 一拆到底：PM也需要把任务拆成独立批次

PM在拆模块的时候，粒度也得有讲究。拆得太粗，执行者拿到一个"实现用户管理"，本质上还是在处理一个模糊的大任务，拆分的意义就丢了；拆得太细，比如把"建立一个空数组"都算一个模块，又会浪费大量对话轮次。

我的经验是：目标是让执行者每轮只做一件“能在十分钟内写完并能直接看到结果”的事。拿登录模块举例，PM阶段我会把它拆成接口定义、数据库结构、Token工具函数、登录处理逻辑、错误处理、单元测试这几个批次。每个批次不依赖前一批的中间结果才能开始，但整体顺序又是递进的。

每完成一个批次，我本地验证一次。这样出了问题能立刻锁定到具体批次，不用在整片代码里大海捞针。

3. PM会话的提示词设计：让它只规划，不动手

3.1 系统提示词骨架

如果你也想试这套工作流，可以先把下面这段PM提示词存成文件，每次新建会话时直接喂进去。我用了挺久，改过几版，目前在大多数情况下都够用：

你是本项目的产品经理（PM）。 你的职责： - 分析我提供的需求，产出任务规格说明书 - 将任务拆解为可独立交付的模块 - 提出技术选型建议与边界约束 - 编写可测试的验收清单 你的限制： - 不许编写任何功能代码，包括伪代码级别的实现片段 - 不许给出"大概思路""可以参考"这类模糊结论 - 需求存在歧义时，必须列出疑问并向用户确认，然后更新规格书 输出格式： - 使用固定Markdown结构： - 背景与目标 - 边界与不做的内容 - 模块拆解 - 模块间交互约束 - 技术选型约束 - 验收清单

这段提示词的核心就三个词：职责（干什么）、限制（不干什么）、格式（怎么输出）。AI对这种结构化的约束响应特别好，因为它清楚地知道自己在什么范围内活动。

3.2 关键约束：不许写代码，但必须追问

刚开始我其实舍不得加"不许编写任何功能代码"这条限制。总觉得让AI只动嘴不动手，有点浪费它的能力。但实际跑下来之后我发现：阻碍输出稳定性的最大元凶，恰恰就是模型忍不住夹带实现思路。

它只要在PM阶段写出了一个具体的函数名，哪怕只是举个例子，后面的输出就会顺着这个函数名往下延展，把整个方案拖进实现细节里。PM视角一旦被代码污染，它就开始像程序员而不是产品经理那样思考问题，而你想要的规划能力就全被稀释了。

另一条核心约束是追问。AI天然倾向于在信息不全时填补空缺，但空缺的方向可能跟你的真实意图完全相反。让AI先列出问题清单，你回答完以后，它再基于答案重新更新规格书，这个动作成本极低，但能避开后面执行阶段的大返工。流程上最快的一次，我问了三个问题，把需求从"做一个图表页"收敛成了"只做两个图、不下钻、不导出、不做日期筛选"，边界一下子就清楚了。

3.3 用固定输出模板减少解释成本

固定输出模板是我的第二个坚持。PM会话每轮输出都是同一个结构，最大的受益方其实是执行者——它读取规格书时，不需要在"散文式规格"里翻找某个字段，直接定位到对应区块就行了。

如果你用的AI编程助手支持文件引用，PM规格书保存成markdown文件之后，执行者甚至可以直接读取对应区块，减少大量重复粘贴。如果你用的工具不支持，也没关系，把规格书的关键区段贴进执行者会话开场即可，效果一样。

模板同时还起到了格式降噪的作用。AI不使用模板的时候，写出来的规格书经常一来就是几千字的长篇论述，有用的信息要自己提炼；用了模板之后，每个区块都变成了可以单独引用的段落，查找、更新、对账都方便很多。

4. 执行者会话的提示词设计：只翻译，不创作

4.1 系统提示词骨架

如果说PM提示词的目标是"别写代码"，那执行者提示词的目标就是"别的什么都别干，只写代码"。我用的执行者提示词骨架如下：

你是本项目的执行工程师。 你的职责： - 严格按照任务规格说明书实现指定模块 - 每完成一项，简要说明改动文件和验证方式 - 如果需要新增依赖或修改现有接口，备注原因 你的限制： - 不得新增规格书之外的功能 - 不得自行修改需求边界 - 遇到规格书未覆盖的情况，先列出疑问项，不要自行假设 执行节奏： - 一次只处理一个模块，确认完成后，再处理下一个 - 不要在一次回复里尝试完成多个模块

这段提示词最关键的句子是最后两句。大多数AI在拿到一份多重任务清单后，会倾向一次性全部做完，但那样的结果通常只有前两个模块质量在线，后面的就开始糊弄。把节奏锁死成一次一个，相当于给执行者加了强制专注。

4.2 按任务批次执行的正确节奏

执行者开始干活之后，我会在第一步先让它"读取规格书，并列出你的第一批任务清单"。这其实是在做对齐，确认它理解的范围跟PM写的一致，同时也给我一个检视窗口。

接下来才让它开始第一批。等它交上来，我先本地验证，通过之后回复"继续第二批"。这个过程看起来多花了几轮对话，但在修改成本上非常划算——问题在第一批就被逮住，远好过五批全写完再一起返工。

如果某个模块本身比较大，我会在PM阶段就要求继续拆细。比如登录接口的第一批任务只做参数校验，第二批做密码校验，第三批做Token签发，第四批做错误信息统一格式。每个批次都短到可以直接看到产出物。

4.3 遇到规格缺漏时，先反馈还是先猜测

执行阶段必然会遇到一种情况：PM规格书没覆盖的细节。比如，PM没定义用户名重复时后端应该返回什么状态码，执行者该怎么处理？

我见过的大多数人，包括我自己以前，都会让AI直接选一个合理的默认值。但问题是，AI选择的"合理"往往只是它在训练数据里看到的高频写法，不一定适配你的项目约定。你这一次让它猜了，下一次它就会更放心地继续猜，边界就在一次次默认中悄悄偏移。

我的规则是：遇到规格未覆盖的情况，必须停下来列疑问项，先问再写。可以明确告诉执行者："不确定的内容不要做，我不知道的参数需要先向PM确认。"这样做看似降低效率，实际上是在给稳定性上保险。问一次的成本只是一句回复，赌一次的代价却是整块逻辑重写。

5. 完整工作流的组织方式：两个会话三种产物

5.1 会话拆分和文件落地

在实际运作中，我的工作流由两个隔离的会话组成：PM会话和执行者会话。两个会话不混用，各自只做各自的事。

PM会话产生的规格书，我会在确认后复制到一个本地markdown文件里，比如task-spec.md。执行者会话开始时，第一句话就是让它读取这个文件路径，之后每轮任务只引用相关区块。

这个文件还有一个隐藏价值：它是整个项目里需求变动的唯一真源。需求改了多少次、每次改了什么，去看这个文件就能理清楚，不用在聊天记录里翻来翻去。对于需要回头复盘的项目来说，这比十个对话窗口加起来都管用。

5.2 一次完整交付的流程序列

我实际跑顺之后的完整流程是这样：

1. 在PM会话发布原始需求，语气可以很随意，甚至带点发散都没关系
2. PM会话输出规格书初稿，并在末尾列出疑问项
3. 你逐条回答疑问，PM更新规格书，直到输出稳定
4. 把最终规格书保存为task-spec.md
5. 新开执行者会话，让它读取该文件，拆出第一批任务清单
6. 执行者完成第一批，汇报改动文件和验证方式
7. 你本地验证，通过后下达"继续下一批"指令
8. 所有批次完成后，打开验收清单逐条回测
9. 如果需求变更，回到PM会话更新规格书，再去执行者会话下发增量任务

这套流程最关键的一步是第3步，也是我每次最花时间的一步。但正是这步把需求的不确定性压到最低，后面执行才会顺。

5.3 需求变更的处理方式：回PM会话，而不是直接改代码

需求变更是最容易把流程打回原形的地方。

以前的习惯是，AI写完了功能，你说"这不就加个字段吗，让它直接改"。执行者确实能很快改完，但你不知道它有没有因为这个字段，顺手改掉了别处的判断逻辑。几次小改之后，实现和最初的规格书差距越来越大，最后变成一团没人说得清的代码。

现在的做法是：任何影响接口、数据库结构、模块边界的变更，先回到PM会话，让PM在规格书里更新对应区块，并标注变更原因。执行者会话拿到更新后的规格书之后，再以增量任务的方式落地。

这么做的好处是变更不会让实现逻辑逐步烂掉。每次变更都回到源头理顺了再往下走，执行者的产出始终忠于最新一版的范围定义，而不是某一轮对话里的即兴发挥。

6. 实测效果：稳定在哪里，稳定不了什么

6.1 我用下来的三项改善

在一个内部管理后台项目里跑完这套流程后，我感受到的改善主要体现在三个方面。

第一，重写率明显降低。以前同一个模块经常整段推翻重来，因为AI生成的方案跟我的预期差距过大；现在执行者按规格落码，结构基本稳定，要改的只是局部细节。

第二，返工次数大幅下降。以前需求往往要反反复复在对话里重复解释，AI还是跑偏；现在需求只进入PM会话，执行者只看到规格书，往复解释的次数基本清零。

第三，需求回溯变得非常容易。任务规格书成了活的文档，任何时候都能查"当初这个字段为什么这么定义"“这个范围是哪个版本去掉的”，这种可追踪性在传统开发里要花很大力气才能建立。

6.2 仍然存在的边界问题

这套流程当然不是万能的。拆分之后，PM阶段的产出质量完全取决于模型本身的分析能力。如果模型在需求澄清阶段就不得力，后面执行者再听话也只是把错误方案快速落地。所以我的经验是，看到PM输出漏洞多的时候，千万别急着往下走，务必先把规格打磨到可执行状态。

另外，小任务强制拆分反而低效。比如写一个几十行的脚本、跑一次临时数据清洗，搞两个会话来回折腾的开销比收益大得多。我现在的判断标准是：项目超过三个模块，或者要基于现有代码库改结构，才值得上这套流程。

还有一个容易忽略的问题：当规格书落后于代码库现实时，执行者会照规格做，但撞上旧实现。要缓解这个，可以在PM提示词里要求它识别外部依赖，并在规格书的交互约束里注明"对现有代码的影响"。否则拆得再干净，也会在集成时被旧债绊住。

6.3 适合与不适合的不同场景

最后给个适用范围参考。

适合这套流程的场景：多模块的新项目、在既有代码库上做增量功能开发、需要留下文档痕迹的协作项目、以及你希望代码风格能被统一约束的项目。

不适合的场景：快速原型验证、一次性脚本、探索性技术Demo。这些场景逻辑简单，试错成本低，直接对话反而更快。我给自己的原则是，别为了方法论而方法论，工具永远服务于项目体量。

我调这套工作流用了差不多三轮。第一版只是嘴上让AI分个角色，效果平平；第二版把提示词限制写死了，才开始稳；第三版加了批次节奏，才真正跑顺。最核心的感悟只有一句：AI编程工作流稳不稳定，不取决于你让AI干了多少活，而取决于你有没有把决定权和执行权分开。

如果大家也想试，我建议先把PM和执行者两套提示词分别存好，每次新建会话直接用，别临时打一堆字去凑角色。而且记住一条铁律：永远别在PM会话里让AI"顺便给个示例代码"，它只要一下水写代码，PM视角当场就崩了。