这段时间我一直在调整自己的 AI 编程工作流。原因很简单以前用 AI 写代码小改动还好项目一大就开始失控经常出现“前面写得挺稳后面越改越乱”的情况。后来我把整个流程拆成了两个角色——PM 和执行者一个负责想清楚做什么一个负责动手写代码结果稳定性提升了一大截。这套方案不需要额外工具你正在用的聊天式编程工具就能跑适合被 AI 返工折磨的个人开发者也适合小团队拿来统一协作节奏。如果你也遇到过“AI 写了个新功能结果旧功能崩了”的情况下面这几点值得看完。1. 项目背景AI 编程为什么总是“一改就崩”1.1 单线程对话式编程的天花板很多人用 AI 编程的方式本质上是把 AI 当成一个“全会”的对话对象丢一段需求过去让它直接输出完整代码然后复制粘贴。这个方式处理简单任务没问题比如写个纯函数、修个正则、做个小页面。可一旦任务复杂起来问题就开始堆积。我观察到最典型的现象是“上下文漂移”。模型在长对话里会慢慢遗忘最初的约束可能在第五轮还记得“不要改登录逻辑”到第九轮就已经开始顺手动登录页了。另一个现象是“目标混淆”同一个上下文里一会儿在讨论需求一会儿在贴报错一会儿在改代码模型很难稳定保持一个身份经常出现答非所问甚至自己跟自己打架。不是模型变笨了而是工作流本身缺少角色边界。一个真实开发团队里项目经理不会边写代码边决定需求开发工程师也不会一边实现功能一边改产品方案。但直接对话式编程让 AI 同时承担了这些角色稳定全凭运气。1.2 团队模式对个人开发者的启发我在一次项目重构中踩了坑后突然想到一个类比与其让 AI 一个人“身兼数职”不如把团队里最常见的两个角色拆开——PM 负责拆解需求、定义验收标准执行者负责按方案实现、跑测试、修 bug。个人开发者也可以这样用拿出两个不同的“身份提示词”分别让 AI 扮演 PM 和执行者。拆开之后效果立竿见影。PM 角色专注于输出规划文档不会被代码细节带偏执行者角色只盯着实现不再需要做产品决策。两个角色之间通过文档交接而不是靠对话记忆传递信息。这样即使中间换了新会话、清了上下文依然能从文档里找回上下文。我把这套玩法叫做“双角色 AI 编程工作流”本质上没有引入任何新框架只是把团队里成熟的 PM开发分工移植到了提示词层面。下面重点讲怎么拆、怎么定义边界、怎么落地。2. 整体设计与角色拆解PM 和执行者各管什么2.1 PM 角色的核心职责把模糊变成可执行PM 在传统团队里做的是需求分析、任务拆解、进度管理。放在 AI 工作流里PM 角色的职责可以收敛成三件事拆解需求、定义任务清单、制定验收条件。拆解需求不是简单地把一句话变成两句话而是要把完整边界写清楚。比如“给博客加个评论功能”一个合格的 PM 角色应该输出用户故事作为访客我想要发表评论以便和其他读者交流。技术约束评论属于现有文章详情页的一部分必须复用当前数据库连接不能改变文章发布流程。任务清单任务 1创建comments数据表字段含 id、post_id、user_name、content、created_at。任务 2添加提交评论的接口POST /api/posts/{id}/comments包含基础校验。任务 3前端评论表单和列表渲染。验收清单提交评论后接口返回 201数据库能查到记录。页面刷新后评论列表能正常显示新评论。空内容提交返回 422 或 400不能写入脏数据。风险与禁止项禁止改动文章编辑模块。禁止影响已有迁移文件必要时新增迁移。这个输出本身就是一份小型 PRD。它的价值在于AI 执行者拿到这份文档后不需要猜直接照着做就行。人自己也方便监督哪条没做到一眼就能发现。2.2 执行者角色的核心职责只做事不决策执行者角色的定位是“资深开发工程师”但必须限制它的决策权。它只能根据 PM 文档实现具体任务不能新增需求也不能扩大修改范围。我给执行者定的规矩很简单只修改 PM 任务清单里明确涉及的文件。每完成一个任务运行一次相关测试。如果发现需求有歧义停下来列出“待确认问题”不要自己脑补方案。输出必须包含三个部分修改了哪些文件、为什么这么改、自测结果是什么。执行者最让人头疼的“自作主张”需要靠提示词来硬约束。我之前让 AI 实现一个评论接口结果它顺手把文章列表的排序也改成了“按评论数排序”直接把原功能带崩了。后来我在执行者提示词里加了硬性条款发现需要修改任务范围之外的文件时先停止并报告不允许直接动手。滥用范围问题才被压住。2.3 为什么拆开之后更稳定我复盘了一下稳定主要来自三个地方。第一上下文更聚焦。PM 的上下文全是业务、需求、验收执行者的上下文全是代码、文件、测试。两边的目标不再互相抢占空间模型也不需要在“产品经理”和“程序员”之间频繁切换身份逻辑一致性明显提升。第二验收清单能拦截低级错误。以前直接让 AI 写功能它经常自己说“完成了”我跑起来才发现完全跑不通。现在 PM 提前把验收条件写成“可执行的动作”比如“调用接口后能查库”“刷新后数据还在”执行者自测时必须逐条贴出结果很多低级问题在验收阶段就被挡掉了。第三每一次决策都有文档留痕。PM 的规划文档、执行者的实现状态会一直保留在工作目录里。哪怕隔天再继续也不用从头复述需求直接翻文档就能接上。这种“外部记忆”远比我依赖对话历史靠谱得多。3. 实操过程把“双角色工作流”真正跑起来3.1 准备两个独立的提示词模板提示词模板是这套工作流的灵魂。简单来说PM 提示词决定 AI 怎么“想”执行者提示词决定 AI 怎么“做”。我用的是下面这两份模板你可以按自己的项目习惯调整。PM 角色提示词示例你是这个项目的专职 PM负责需求拆解和验收定义。你不需要写代码也不讨论实现细节。 每次收到需求后必须按以下结构输出 - 需求背景 - 用户故事 - 任务清单每个任务标注依赖关系、影响范围、预计涉及文件 - 验收清单每条都要能验证禁止写“功能正常”这类模糊描述 - 风险与禁止项 如果需求描述不清晰先输出问题清单不要猜测。执行者角色提示词示例你是这个项目的核心开发只能按 PM 文档执行不能新增需求不能扩大改动范围。 工作步骤 1. 读取 PM 文档和必要代码文件。 2. 逐个任务实现每完成一个任务运行一次测试。 3. 发现需求冲突或文档遗漏时输出“待确认问题”等 PM 回复后再继续。 4. 最终输出格式modified files、修改原因、self-test 结果。 禁止修改任务清单之外的文件。如果必须修改先说明原因并等待确认。这两份模板的关键词不是“请”、“请帮忙”而是“必须”“只能”“禁止”。AI 编程工具对这类硬约束的响应明显好于模糊的请求式表达。3.2 定义完整的协作流程有了角色提示词下一步就是把流程串起来。我的日常操作路径是这样的我自己带着原始需求进入 PM 角色给 PM 发需求描述最好带上使用场景和边界条件。PM 产出规划文档收到结构化 PRD、任务清单、验收清单。我把 PM 文档交给执行者新起一个会话或使用执行者工具把文档原文粘进去让它按任务清单实现。执行者返回实现结果代码 diff、自测日志、待确认问题。我带着执行者的结果回到 PM 角色做验收新起 PM 会话贴上验收清单和执行者输出让 PM 逐条判定。如果验收不通过把问题描述清后回到步骤 3通过则手动合并代码。这里有个非常关键的习惯每次切换角色都要新开会话不要让两边的上下文混在一起。PM 的规划文档是执行者的“输入物”执行者的实现结果是 PM 的“验收物”两者通过文本文件或复制粘贴交接而不是靠同一个聊天窗口。3.3 实际项目示例给博客站加评论功能拿我最近做的博客评论功能举个例子。以前直接问 AI“帮我做个评论功能”它大概率会给一坨代码但数据库建表、接口校验、前端交互常常只实现了 60%。用双角色流程后PM 先给出了一份完整文档内容大概包括评论表结构、接口字段校验、前后端交互边界、禁止改动范围。执行者拿到任务清单后按任务 1、2、3 顺序实现。任务 1 建表输出 SQL 迁移脚本跑完migrate成功任务 2 写接口用 curl 模拟请求返回 201任务 3 前端组件实现手动测了提交和列表刷新没有报错。整个过程中它没有动过其他文件。最后我把执行者的自测结果贴给 PMPM 按验收清单逐条核对发现“空内容提交返回 422”这一条没有测试记录就打了回去。执行者补了校验逻辑并重新自测最终才通过。这一轮操作下来代码质量和稳定度都比原来单线程聊天高很多返工次数从七八次降到了三次以内。4. 工具选型与工作流编码怎么搭更顺4.1 常用 AI 编程工具怎么选双角色工作流不绑定特定工具但不同工具适合承担的角色不一样。我自己目前的搭配是PM 用更擅长长文本理解和结构化输出的工具执行者用更擅长命令行操作和文件批量修改的工具。下面是我实际用过的几个方向的选型感受工具特点我通常让它扮演的角色Codex CLI命令行工具擅长在仓库内批量改文件、执行测试适合按任务清单执行执行者Claude Code长上下文理解强结构化输出自然适合读 PRD、生成规划文件PMCursorIDE 集成度高适合边看 diff 边手动调代码审阅和修补Copilot Chat体量轻适合单文件小任务快速修改轻量执行者Cline / Aider开源、提示词可调可以自定义角色模板灵活性强可替换 PM 或执行者选型逻辑很简单谁更擅长“完整阅读 生成文档”谁去做 PM谁更擅长“改文件 跑命令”谁去做执行者。付费工具通常有使用额度限制实测下来一个中型项目的双角色轮询每周的 token 消耗会明显高于单会话建议优先选择带有上下文缓存的方案或本地模型成本会友好很多。4.2 用文件系统管理“工作流状态”双角色工作流最怕丢失上下文。我的解决办法是把关键状态写进项目目录这也是我觉得最值得推荐的一个习惯。在仓库里新建docs/workflow/目录固定维护四个文件docs/workflow/prd.md # PM 输出的需求文档 docs/workflow/tasks.md # 任务清单与状态标记 docs/workflow/acceptance.md # 验收清单与最终结果 docs/workflow/implementation_status.md # 执行者的实现进度和自测记录每次 PM 完成规划就把结果写入prd.md和tasks.md执行者开始工作前先读这两个文件和当前代码每完成一个任务更新implementation_status.md。这样即使 AI 清空了会话缓存我重新打开一个新会话只要让它“请先阅读docs/workflow/下的文档再继续”它就能快速恢复上下文。用文件而不是对话记录还有一个额外好处人可以随时查看工作流状态甚至可以 git diff 看文档的演进。这套设计本质上是用文件系统做工作流编码实现一个轻量级的“外部记忆”。4.3 跟 Git 和 CI 的配合双角色工作流跑起来后如果还在一个分支里乱改还是会翻车。我现在的习惯是执行者统一在feature/xxx分支工作每个任务完成就提交一次commit message 里带上任务编号比如task-3: add comment form handler。合并主干前先在本地或 CI 跑一遍 lint test把机械问题拦截掉。PM 验收通过后我再用git rebase整理提交历史最后合并进 main。这样做让我在验收不通过时可以直接git revert对应任务提交不需要重写整个功能。配合 CI 的自动化测试稳定度还能再上一层。如果你更习惯可视化工作流也可以把这套流程移植到 Dify、Coze 这类平台上本质上就是用两个节点分别承载 PM 和执行者提示词再加上人工审批步骤。不过我试下来纯文件加 Git 的方式最轻量也最容易 debug——毕竟工作流本身的日志也是一段段文本。5. 常见问题与排查技巧实录5.1 角色切换后“失忆”PM 和执行者互相甩锅最常碰到的问题是执行者在新会话里不认 PM 文档或者 PM 文档里缺少关键约束导致执行者自由发挥。我的排查顺序是先检查prd.md是否“自包含”。所谓自包含指的是执行者只看这一份文档不需要参考任何历史对话就能完成所有任务。如果文档里写了“按之前的讨论”那就是不合格的 PM 输出必须让 PM 把上下文全部补充进去。还有一种情况是执行者看到别的文件里有相似代码就自作主张模仿了一遍。解决办法是在执行者提示词里加死规矩“禁止参考任务范围外的代码逻辑。”5.2 执行者“自行发挥”改动范围失控AI 执行者很喜欢在完成主任务后顺手“优化”其他文件。比如实现了评论接口顺手改了文章列表的排序逻辑修了一个 CSS 样式顺手重构了整块布局。这种失控是稳定性的头号杀手。我现在的应对方式是双保险。第一PM 文档里的“风险与禁止项”明确列出不可触碰的模块第二执行者提示词里强制要求“如果必须修改范围外文件先停下来列出清单等待 PM 确认”。实测下来加了这条后范围蔓延现象大幅减少。如果仍然出现就回到这个任务的 git diff 里直接 revert只保留任务相关改动。5.3 验收条件形同虚设PM 如果写“功能正常”这类验收条件等于没写。执行者说“我测了没问题”但真正的业务场景可能完全没覆盖到。我的改进方法是把每条验收条件都写成“可执行动作”。比如用测试账号登录在文章详情页提交一条评论接口返回 201。刷新页面新评论出现在评论区。不输入内容直接提交返回 422页面不崩溃。这样验收就不靠主观感觉而是靠具体动作。执行者自测时也会一条一条贴结果哪怕它只是简单跑了接口我至少能从日志里看出有没有真实执行。5.4 Token 消耗翻倍双角色工作流天然会比单次对话烧 token因为每次切换都要重新发送提示词和文档。如果项目很大开销会让人肉疼。我控制成本的办法有三个方向合并任务不要让 PM 对每个小需求都单独输出文档而是凑成一批后统一规划。尽量把上下文压缩成结构化文档减少无关废话避免大段复制聊天记录。优先选择带上下文缓存或本地部署的工具长文档重复发送时费用会低很多。下面这组问题是我在实际使用中最常遇到的可以直接翻表排查症状可能原因解决方法执行者忘记 PM 约束文档没有自包含要求 PM 文档独立成文执行者不读历史对话执行者改了一堆无关文件提示词缺少范围限制加入“禁止修改任务清单外文件除非先报告”PM 说完成但功能跑不通验收条件模糊验收写成可执行的 checklist并附测试命令Token 消耗过高频繁发送长文档合并任务批次使用缓存或本地模型两个角色对话自相矛盾上下文混用每次切换都新开会话用文档交接6. 什么情况下不该拆轻量任务与后续扩展6.1 小任务直接做别走完整流程双角色工作流不是银弹过度拆解反而累赘。我的判断标准是改动量小于 20 行、只涉及单个文件、不影响其他模块时直接开一个会话让 AI 写自己审一眼就够。任务包含超过三个步骤、跨多个文件、涉及数据模型或公共接口时才值得走 PM→执行者→验收的完整流程。如果连需求自己都没想清楚更需要先让 PM 角色把问题列清楚而不是直接让执行者瞎写。最简单的原则是任务越复杂越需要“先想后做”任务越琐碎越不需要流程仪式。6.2 继续扩展加入更多角色双角色拆出稳定之后还可以继续扩展。比如增加一个“测试工程师”角色专门负责根据 PM 的验收清单写自动化测试用例或者增加一个“架构师”角色在 PM 之前负责划定系统边界。我自己目前停留在 PM 执行者 半个测试工程师的组合。每次要新增角色我都会先问自己这个角色能不能让某个环节的“返工率”明显下降如果一个角色只是让流程变得更完整但实际没有减少返工说明它不是必需品。6.3 后续自动化与平台化方向这套工作流目前还是“半自动”我还需要在角色之间手动复制文档。后续可以让它更自动化方向有两个。一个是写脚本把“读取 PM 文档→执行者实现→跑测试→写状态文件”封装成一条命令用 Makefile 或 just 工具让 AI 在固定脚本里直接执行任务人在旁边监督。另一个是接可编排工作流平台在 Dify、Coze 里把 PM 和执行者做成两个节点前一个节点输出规划后一个节点调模型实现中间增加人工确认步骤。这样整个流程可视化也方便分发给团队其他人使用。我个人在实际操作中的体会是AI 编程最稀缺的其实不是模型能力而是任务定义能力。之前我总想让它一步到位本质上是把需求的模糊性甩给了代码。现在用 PM 文档先逼自己把边界、验收、风险想清楚后面执行和验收都顺畅很多。如果你也被 AI 返工气到摔键盘先别急着换模型试试把工作流拆开一个人分成两个人用稳定度真的会不一样。