自研 NPC 工作流构建器

要解决什么问题

当你用 CNB 的 NPC 流水线写代码时，协作链路实际是断裂的：NPC 沙箱没有仓库写权限，代码留在沙箱里出不来；流水线是黑盒，只能翻 Issue/PR 评论找方案和代码；多个 NPC 并行产出 PR 后，合并顺序和冲突解决全靠脑子记。这个技能把整条链路固化成一套可复制的标准操作：从 Issue 触发 NPC，到人工代推 PR、审查、解决冲突、合并。

它是怎么工作的

核心是一套 10～12 步的分阶段工作流，按场景分两种模式：

• 模式 A（单功能）：分析需求 → 创建 Issue 用 @npc/XXX(YYY) 触发 NPC → 60 秒无响应就追加带 @mention 的评论 → 从评论提取文件清单和架构说明 → 本地实现代码 → 代推 PR → 触发 NPC 审查 → 合并改进点、解决冲突。
• 模式 B（完整项目）：在 A 的基础上增加项目规划与 PRD、多 NPC Issue 看板（CodeWhale-pro 负责后端/AI、CodeBuddy 负责全栈、npc/icon 负责 UI）、批量创建分支和 PR、按依赖顺序合并（计费 → 功能 → 网关 → 前端）。

关键操作细节都有实战模板兜底：@O.o/CodeBuddy(glm-5.1) 这类完整 @mention 路径一个字符都不能少；评论分页每页只有 10 条，需要 while 循环翻到拿全；PR 必须用含 refs/heads/ 的 base/head 字段；合并必须带 commit_title 和 merge_style。

适用边界

• NPC 代码永远留在沙箱，需要自己 clone、提取、push，不存在自动提交
• NPC 不回复时，九成原因是 @mention 格式不完整，先查这个再查别的
• 多 PR 冲突要按文件类型选策略：共享基础设施文件取 main 版本，独立模块取分支版本
• npc/icon 响应不稳定，UI 任务要有人工兜底的预期

参考案例 GEO-NPC 走完了完整流程：20 个 Issue、2 个 NPC、15 个 PR 全部合并，产出 70+ 文件的可运行项目。