CodeBuddy NPC 在需求到提测这段能接手多少 / 边界比功能清单更重要

判断 CodeBuddy NPC 在需求到提测这段能接手多少，按功能清单去数没有意义：功能列得再长，也不说明哪一段的产出能被另一个人验收。更实际的做法是按交接点看：每段工作的输入物能不能拿到、输出物能不能检查、失败时会不会被误当成成功。通常可以先交给智能体的是边界清楚、产出可核对的中间环节；需要人对需求意图和风险负责的节点，建议保留人工签字。

适用场景：团队已经把 CodeBuddy NPC 接进 IDE 或代码仓库，想把它放进「需求到提测」的固定流程。操作动作：把流程拆成五个交接点，给可委派的点定义可检查产出，再用一条真实需求试跑，记录停留时长和人工补充信息的次数。验证方式：产出文件字段是否齐全，另一个人能否只读文件完成复核。风险边界：需求理解、改动范围、提测前回归这三处没有人工确认时，功能跑通也不等于交付正确。

把需求到提测拆成五个交接点

把这段工作看成一条流水线，两端分别是需求单和提测单，中间切五段。每个交接点只写清三件事：谁交、交什么、怎么算交成功。下表是通用拆法，具体项目可以按自己的分支模型和测试流程调整，但「输入物 / 输出物 / 责任人 / 失败表现」这四列建议保留。

交接点	输入物	输出物	通常由谁完成	交接失败的典型表现
1 需求理解与任务拆解	需求单、验收标准、相关页面或接口现状	任务拆解清单、待确认问题列表	需求方与开发共同	拆解里出现需求单没写的行为，但没人追问
2 代码定位与改动范围	仓库权限、模块说明、相关报错或日志	改动文件清单、影响面初稿	开发	只改调用方没改被调用方，清单里看不出来
3 编码实现	改动范围、编码规范、分支约定	diff、提交记录	开发，可部分委派	顺手重构或整文件格式化，diff 无法逐行 review
4 自测与缺陷修复	用例、本地运行方式、测试数据	自测记录、失败复现步骤	开发	只走主流程，异常分支和执行环境没有记录
5 提测材料整理	diff、自测记录、影响面	提测说明、回归清单	开发	提测单只写「已改完」，测试无法判断范围

要注意，交接点失败通常不会报错，而是表现为下游停下来问问题。只要出现「测试来问这次改了哪些地方」「联调时发现另一处调用没跟着改」，就说明上游某个交接点的产出不合格，而不是下游理解能力差。

标出必须人工确认的节点

可委派的动作和必须签字的判断要分开。前者是执行，做错了能在 diff 里看出来；后者是取舍，做错了 diff 一样干净。

需求理解确认

判断依据：需求单是否存在歧义句、是否有隐含的兼容要求、验收标准能否被写成可执行用例。智能体在这类节点上倾向于把不确定的地方补成一个通顺的解释，而不是停下来提问，因为它的产出目标是「给出完整答案」。风险是假设被写进任务拆解，后面所有工作都建立在错误前提上，而且很难从代码里反向发现。

改动范围确认

判断依据：是否跨模块调用、是否涉及配置或数据结构变更、是否影响对外接口。智能体容易把「能跑起来」当成「范围正确」，倾向于给出最小可运行改动。风险是单点验证通过、联调阶段才暴露漏改，尤其是被多处复用的公共方法。

CodeBuddy NPC 在需求到提测这段能接手多少 / 边界比功能清单更重要

提测前回归

判断依据：回归清单是否覆盖被改动模块的直接调用方，是否存在难以自动执行的场景，例如权限、并发、脏数据、定时任务。交给智能体后常见的问题是自测记录看起来很完整，但缺异常路径，耗时的验证步骤被跳过且没有标注为「未执行」。

给每个可委派交接点定一个可检查产出

「它改好了」不是产出。可检查的意思是：字段齐全、字段为空要写明原因、另一个人只读文件就能复核。下面三份产出建议固定在仓库或提测单里。

改动文件清单：字段为文件路径、改动类型（新增 / 修改 / 删除）、对应需求项编号、是否引入新依赖、是否涉及配置或数据变更。
影响面说明：字段为受影响接口或页面、直接调用方、兼容性判断、回滚方式、需要通知的团队。
自测记录：字段为用例编号、前置条件、输入、期望结果、实际结果、执行环境、执行时间、结论、未覆盖项及原因。

如果让智能体生成清单，把字段直接写进指令，并要求缺项写「未确认」而不是省略，这样空缺本身成了信号：

按下列字段输出改动文件清单，缺项写「未确认」，不要省略任何字段：
文件路径 | 改动类型(新增/修改/删除) | 对应需求项 | 是否新增依赖 | 是否涉及配置或数据变更
只列实际发生改动的文件；只读过但没有修改的文件不要列入。
如某一项无法从仓库判断，写「未确认」并说明缺什么信息。

自测记录也可以直接用固定模板，避免每次自由发挥：

用例编号:
前置条件:
输入:
期望结果:
实际结果:
执行环境:
执行时间:
结论: 通过 / 不通过 / 未执行
未覆盖项与原因:

用一条真实需求走通全链路

试跑不要挑最简单的需求，那看不出边界；也不要挑跨多个团队的，变量太多。建议选一条中等复杂度、涉及两三个模块、有明确验收标准的真实需求，从头走到提测，全程只记录事实，不做评价。

记录表按交接点填，重点不是总耗时，而是「在哪一步开始需要人补上下文」：

交接点	开始与结束时间	停留时长	人工补充信息次数	补充的具体内容	是否卡住
1 需求理解
2 改动范围
3 编码实现
4 自测修复
5 提测材料

「人工补充信息」要写得具体到能被复用，例如「告知本地起服务要先跑哪个脚本」「说明这个字段历史上被三个业务共用，不能改语义」「指出分支命名规则」。常见的情况是卡点集中在第 2 步和第 4 步：前者缺的是仓库里没写下来的约定和历史包袱，后者缺的是本地环境与测试数据。这两类信息补一次就能沉淀成文档或提示词模板，值得补。

按卡点决定长期交给它哪些环节

试跑结束后，把每个卡点按三个条件过一遍，再决定这个交接点长期归谁。不要一次性调整多个交接点，否则下一轮分不清是哪项变化带来的改善。

卡点表现	判断条件	建议处理
每次都在同一交接点停下，现象一致	卡点可复现	不整体委派，降级为「它出草稿、人逐项确认」
同一交接点有时顺、有时卡，卡的时候都缺同一类信息	只由上下文不足引起	先把缺的信息写进仓库文档或固定提示词，再跑一轮
补上下文后不再卡，产出字段齐全	补上下文后消失	可长期委派，保留抽检
补上下文后仍会给出不自洽的结论	属于判断类工作	留给人，智能体只做信息收集

判断「可长期委派」时，还要加一条验收动作：让另一个人只读产出文件、不看对话记录，判断这次改动影响了哪些地方。如果他能得出和实际改动一致的结论，这个交接点才算真正交出去；如果需要回头问参与过程的人，说明产出仍然依赖过程记忆，边界还没有建立起来。