team sharing
AI + Pipeline 开发闭环
从接单到发布
把流程交给机制，把判断留给人。这份分享用真实 issue、真实截图、真实 MR，讲清楚 AI 怎么进入团队的研发流程，而不是只停在聊天窗口里写代码。
接单
SPEC
E2E
Review
Gitflow
Release
背景 01
流程没变，节奏变了
现有流程是按人和人协作设计的，本身没有问题。AI 加入后，执行速度快了一个量级，原来靠人衔接的环节就跟不上了——我们要找的，是一套能和 AI 搭配得更高效的流程。
context需求变化快群里补一句“还要支持附件”，方案就变了——变更要有一个统一的落点。
planning计划调整频繁今天排好的功能，明天被线上问题插队——状态要随时可见，不能只靠人同步。
testing验证量级上升AI 产出变多，带附件发送、并发、异步这些边界场景也变多——验证要能沉淀成可复用的证据。
ownership责任靠约定谁确认方案、谁合并 MR、谁关单——协作提速之后，责任要落成可查的规则。
解决思路 02
新增 AI 登记，过程升级
TAPD、接单系统、群消息都继续用，同时新增 AI 机器人登记入口。真正要升级的是进入研发之后的过程：给它补上状态可见、责任有归属、证据可回放这三样。
入口新增 AI 登记TAPD、接单系统、群消息继续用；群里也可以让 AI 机器人登记。
→
研发统一承接转成 issue，AI 补齐背景、目标、验收标准，指派负责人。
→
证据一路回写Plan、E2E 截图、Review 结论、发布说明，全部写回同一个任务。
一个 issue 就是一张任务的完整档案：方案、验证、审查、发布说明都写在上面，想了解进展只用看这一个地方。
一句话接单，AI 补齐工程语言
两段真实记录：需求可以在群里 @ 机器人提，也可以在 AI 会话里顺手登记。一句话加一张截图，AI 就会补齐工程语言——背景、验收、优先级、目标线，自动建单、指派负责人。
群里接单：@机器人 一句话 + 标注截图 →
#436 自动登记，type::feat / priority::medium / target::release，指派负责人
AI 会话提单：一句话 →
#104 自动登记，type::feat / target::develop / workflow::planning 一次打齐
提出需求只需要 30 秒；进入研发的都是背景、验收、归属齐全的工程任务。
流程地图 03
AI 跑流程，人过门禁
接到任务之后，AI 沿五个阶段推进机械动作，人只在关键节点做决策。三条泳道分别是 AI 自动推进、人负责门禁、证据写回哪里。图上每个阶段都可以点开对应的真实记录。
关键门禁 04
SPEC：先把方案讲清楚，再开始实现
AI 拿到需求后不直接写代码，而是先把方案写成可讨论的 SPEC：做什么、不做什么、怎么验证。方案不确认，实现不开始——这是流程里第一道硬门禁。
meaning先定语义字段放结构化列还是 JSON？来源由入口决定还是函数内部推断？这些设计问题要在实现前就定下来。
boundary先定边界明确“非目标”：这次不拆模型、不改执行主流程。边界不说清楚，后面就得返工。
SPEC 不是文档负担，而是防止 AI 自由发挥的门禁：后续 implement 和 review 都以它为对照。
一个“加字段”需求的完整 Plan
还是 #104。看起来只是“表里加一个字段”，AI 的 Plan 里却包含背景、目标、非目标、逐文件改动范围、关键决策和验证清单。截图底部还保留了一段真实的讨论：source 应该在哪个阶段确定？——这类分歧就应该在写代码之前解决。
真实截图（框内可滚动）：
#104 的 Plan 全文，含逐文件改动范围和 E2E 验证清单
四个实现前就定下来的关键决策：字段放结构化列、来源由入口决定、历史数据统一 unknown、已有会话不覆盖来源。
验证 05
“显示出来”不等于“验证通过”
实现阶段的完成标准不是“代码改完”，而是真实用户动作可用、边界场景已验证、证据可回放。typecheck、单测、E2E 截图全部写回任务，任何人都能复查。
action用户动作实际操作一遍：点击“继续”要生成一条新的用户消息，而不是只看按钮渲染出来。
edge边界场景输入框里已有附件时点击建议，附件不能跟着发出去——这类边界要专门验证。
evidence验证证据测试命令、通过数量、失败原因、截图，全部写回 issue，可回放。
feedback测试反馈收到反馈就回到实现阶段补修复、重新验证，而不是口头确认。
implement 阶段的交付物
#104 实现完成时 AI 的真实汇报：主要改动逐条列出，typecheck 通过、8 个测试文件 36 个用例通过、迁移验证通过，24 个文件的 diff 待审。全过程在独立 worktree 中进行，主工作区保持干净。
真实截图（框内可滚动）：
#104 实现汇报——改动清单 + 验证结果 + 文件 diff，一屏说清
这套汇报格式是流程约束出来的：改了什么、怎么验证、还有什么风险，少一项都进不了下一个阶段。
测试把真正的边界暴露出来
#316 的按钮功能自测覆盖了 9 个场景，测试人员介入后提出了第 10 个。这不是对立，而是流程在起作用：缺陷写回 issue，补上 MR !491，修复后重新验证。
AI
给出 9 个可复制的验证场景：纯文本建议、外部链接、按钮组、更多菜单、代码块、50 条上限……
测试
输入框里已经有附件的时候，点建议会不会把附件一起发出去？
AI
确认是缺陷。写回 issue，补 MR !491：快捷入口只发送自身文本，不携带草稿和附件，修复后重新验证。
代码完成、测试完成、业务完成是三个不同的状态，流程把它们分开管理。
代码审查 06
Review 不是形式，而是守门
代码能跑起来只是第一步；能不能合并，要看稳定性、架构边界和测试缺口。Reviewer 不用翻聊天记录：改动范围、验证结果、风险说明都已经写在 MR 里。
01证据进 MR改了哪里、怎么验证、还有什么风险，写进 MR 描述，而不是留在会话里。
02Reviewer 判断看有没有绕过架构边界、有没有稳定性隐患，发现问题直接阻塞。
03AI 辅助修复每条审查意见拆成定位、改动、验证三步，逐条处理不遗漏。
04复查后放行review 阶段修改了业务代码，就回到实现阶段重跑验证，补测通过后再解除阻塞。
审查意见，逐条闭环
这是另一个真实 issue 的审查现场：Reviewer 发现队列可能并发 claim 多条，直接阻塞合并。开发用 AI 逐条分析意见、补串行保护、跑回归测试，复查通过后才解除阻塞。
审查
队列可能并发 claim 多条，有稳定性风险。这个 MR 暂时不能合。
开发
AI，帮我逐条分析审查意见：哪些必须改？分别怎么验证？
AI
这条是稳定性问题，必须改：补串行保护、移除不稳定依赖，再跑相关测试给出结果。
AI 不替代 Reviewer 的判断；它做的是让每条意见更快变成“定位 → 修复 → 验证”的闭环。
一个自带证据的 MR
#104 最终的 MR !81：关联 issue、改动摘要、验证结果、分支策略、风险与兼容性，全部结构化写在描述里。Reviewer 打开 MR 就能直接开始审，不用再单独去问背景。
真实截图（框内可滚动）：
MR !81——feat/bug 只写 Related to
#104，避免合并时自动关单
细节：功能和缺陷的 MR 禁止写 Closes #N，只写 Related to——合并不代表业务完成，关单权限在测试人员。
责任边界 07
每道门禁，都有明确的放行人
门禁不是拖慢流程，而是把“谁可以放行什么”写成规则。AI 可以加快流程，但不能替代责任——这五类越界必须停下，其它机械动作放心交给 AI 连贯执行。
方案确认研发 / 负责人SPEC 确认之前，AI 不进入实现。plan 是第一道停下来等人确认的门。
架构评估架构师涉及架构变更、大范围调整时必须有评估记录，没有记录 review 不放行。
MR 合并用户决定AI 不擅自合并 MR；什么时候合、要不要合，由人来定。
关单权限测试人员功能和缺陷 issue 只能在发布验收后由测试关单，研发中途不能关。
发布纪律发布负责人只在主干工作区发版，版本号单调递增，禁止在功能分支发包。
分支管理 08
合到哪里，决定怎么做
分支不只是命名约定，而是版本责任的容器。每个任务在 pickup 阶段先回答：这次改动属于哪条版本线？答案决定源分支、MR 目标和收尾校验。
线路示例
三条线路，不能混用
feature开发线
develop
↓
feature/f-316
↓
MR -> develop
release测试线
develop 已集成需求 1 / 2 / 3
↓
release/v1.4.0
↓
bugfix -> release
hotfix生产线
master
↓
hotfix/f-N
↓
master + develop
#316 走的正是开发线：pickup 判定 target::develop，从 develop 切出 feature/f-316，MR 合回 develop。
容易踩的坑 09
最常出错的三个地方
这些问题单独看都是小细节，但 AI 执行速度快，小细节会被放大成流程事故。以反例和正例的形式列出，方便团队一次对齐。
反例为了快，直接在主目录改代码多个任务互相污染，改动来源说不清楚。
正例每个 issue 独立 worktree任务相互隔离、可并行，主工作区始终干净。
反例功能 MR 里写 Closes #NMR 一合并就自动关单，测试环节被跳过。
正例功能 / 缺陷只写 Related to #N合并后进入 testing，发布验收后由测试关单。
反例hotfix 只修 masterdevelop 没带上这个修复，下个版本又会把缺陷带上线。
正例同一修复回合 master + developclose 前确认两条线都已覆盖，才算收尾完成。
产能变化 10
流程稳定之后，产能来自并行
最大的收益不是单个任务变快，而是一个人能同时推进多个任务：每个 issue 有独立 worktree 和状态标签，AI 在各自工作树中执行机械动作，人只在门禁节点介入。
2–4 天以前 · 一个人串行推进一个任务
→
3–5 个现在 · 一个人一天并行推进的任务数
任务池可见：提测、审查通过、复杂搁置都排在同一个列表里。
状态可见：高优先级、返工提测、转单和队列任务能同时推进。
最后一公里 11
代码合并，不等于交付完成
主流程解决“怎么做”，两端还要接上：任务怎么进入流程，版本怎么交付出去。发布之后，测试和业务要能看懂这一版改了什么、重点测什么。
最后一公里让版本可追溯、让测试有明确切入点，闭环才算完整。
落地路径 12
按复杂度选挡位，分阶段落地
不是所有任务都要走完整流程。轻任务轻流程，复杂任务留证据，跨版本守规则——流程的价值是把注意力分配到值得的地方，而不是把所有事情都变重。
常见问题 13
这套流程适合所有人吗？
先看团队当前的协作习惯和主要摩擦点，再选择合适的接入方式。
容易先试已经有 issue / MR 习惯，有可执行的测试命令，也有相对明确的发布责任人。
轻量接入分支、测试、命令还在磨合时，可以先做任务关联、Plan 确认和 Review 证据。
怎么开始先选一类中等复杂度任务试运行，跑通后再逐步加入 E2E、发布和关单门禁。
后续进化SPEC 模板化、E2E 证据化、Review 结构化、发布门禁化，按团队节奏推进。
这是一套可以按团队定制的闭环骨架，不是必须整套照搬的工具。
思考与后续演进 14
从 Pipeline 到 Loop，差的不是口号
Pipeline 解决了从接单到验证、审查、发布的主流程；Loop 进一步解决“下一步怎么判断、证据怎么复用、复杂任务怎么拆”的问题。从可执行流程走向可自我观察、自我路由、可被审计的工程闭环。
为什么转Pipeline 仍需要人频繁触发下一步；Loop 让 AI 先读取状态、判断下一步，只在关键门禁处请求人决策。
先补什么先做 next 判断器：统一输出当前阶段、阻塞点、门禁和下一步动作，减少人工判断成本。
证据怎么沉淀把 Plan、验证、Review、截图、耗时从散落文本变成结构化记录，后续才能复用、统计和回放。
再往后加入规模评估、子 issue 拆解、知识图谱关联和重复 issue 发现，让复杂任务先被拆清楚，再进入执行。
要讨论的问题不是“要不要自动化更多”，而是：哪些判断可以交给 Loop，哪些门禁必须继续留给人？
收束
明确的工作给 AI，判断留给人
AI 负责定位代码、实现、验证、整理证据这些有标准答案的工作；人负责优先级、方案、架构、合并、发布这些需要判断的决策。
重点不只是“更快”——
而是每一步的责任更清楚，每一步的证据更完整。
Issue 管事实
SPEC 管设计
Pipeline 管状态
Gitflow 管版本
Review / Testing 管质量
