说实话我一开始并没有打算搞什么角色扮演。当时的处境很朴素我在做一个内部项目代码量一上来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不要过度补全明确列出哪些事不属于本次范围模块拆解让任务可以分批交付每个模块都能独立测试模块间交互约束减少两个模块对接时的理解偏差用接口、函数签名或数据结构描述技术选型约束统一实现风格说清什么能用、什么不能用验收清单定义做完了的硬标准每一条都要可测试不能是模糊表达这几个字段里我要求最严格的是边界与不做的内容和验收清单。边界字段是专门用来对抗AI过度补全的验收清单则是用来消灭应该差不多了这种模糊状态的。2.2 验收清单为什么是整个流程的锚点验收清单的价值我在传统项目里也体会过但在AI编程场景里它的权重会放大很多。因为模型判断完成的标准和你心里的标准通常不一致。你要是口头说一句帮我写一个注册接口它默认你什么都要但如果你在PM规格书里写死密码长度小于8位时返回422并在响应体里带error_code字段执行者就不会去自由发挥了。写验收清单有个技巧所有条目必须是可执行的表述。不要写需要处理未登录的情况而是写未登录访问/profile接口时返回401且响应体包含error_codeUNAUTHORIZED。前者还是留了理解空间后者则完全没有歧义。我把这条规则执行到位之后发现验收动作本身也变得省力了。以前测试靠感觉不知道自己有没有漏测现在对着清单一条一条打勾就行。这个文件还能直接作为项目文档的雏形方便后来人接手。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 一次完整交付的流程序列我实际跑顺之后的完整流程是这样在PM会话发布原始需求语气可以很随意甚至带点发散都没关系PM会话输出规格书初稿并在末尾列出疑问项你逐条回答疑问PM更新规格书直到输出稳定把最终规格书保存为task-spec.md新开执行者会话让它读取该文件拆出第一批任务清单执行者完成第一批汇报改动文件和验证方式你本地验证通过后下达继续下一批指令所有批次完成后打开验收清单逐条回测如果需求变更回到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视角当场就崩了。
