海外SKILL实践：基于开发事件驱动的自动化协同提效！

分类说明

这条链路强调“本地代理负责跨系统编排，平台流水线负责专业交付”。建单、进度、文档、MR、Tag、PMS 流转、上线申请推进和通知由 Skill 直接执行；测试环境、CI/CD 打镜像与交付、PaaS 部署则由 GitLab 分支或 Tag 事件触发。两段链路用稳定事件衔接，部署完成后再以 PMS KEY 反向关联上线申请，实现从触发交付到业务收口的闭环。

一个可复用的案例

1. 开始：技术需求，研发执行“创建开发分支 intl-debug-agent”。工具先同步主干，再创建 feature/intl-debug-agent；post-checkout 自动创建 PMS 技术需求，并流转到“进行中”。

2. 开发：prepare-commit-msg 将工单 KEY 追加到提交MSG；第一次 push 只在 PMS 评论中留下开发分支链接。

3. 增量：后续 push 根据 SHA 区间生成结构化变更摘要，按目录列出 A/M/D 文件并识别接口路由；本地 LLM 在后台补充面向协作人的中文概述。

4. 提测与环境：执行“分支提测”，工具更新测试分级、流转 PMS、生成或更新功能迭代文档并通知测试；随后“合并测试”创建到 release 的 MR，合并事件触发测试环境自动部署。

5. Review 与合并：执行“合并主干”，工具自动补齐 PMS 上下文、选择 Assignee、展示 dry-run 并创建 MR；成功后飞书通知 Review 人员，已有同源同目标 MR 则直接复用。

6. Tag 与交付：主干合并后执行“创建TAG”，工具从 master/main 打 Tag ；GitLab Tag 事件触发 CI/CD 打镜像与交付，后续由 PaaS 完成部署。

7. PMS 上线：执行“分支上线”，工具逐步流转 PMS 至“已上线”，并按确认结果发送后端上线通知。

8. 上线申请收口：确认部署与线上回测后执行“上线完成”。工具从分支映射取得 PMS KEY，在上线申请中心查询当前用户相关的申请，循环推进状态至“线上回测完成 / 已完成 / 已上线”，再飞书通知申请发送人与“上线前检查”测试人员。

边界说明：“分支上线”负责 PMS 已上线与可选邮件；“上线完成”负责上线申请中心收口，二者是两个系统、两条状态链。“合并到测试分支触发测试部署”“master/main 打 Tag 触发 CI/CD、PaaS”仍依赖项目既有流水线。Skill 提供统一入口、可靠触发点与最终状态回写，不替代平台内部执行器。

3.1 选择“高确定性事件”，而不是监听一切

分支创建、commit、push、提测、MR、合并和 Tag 都具有清晰语义，适合触发管理与交付自动化；写代码、切换文件、临时调试则噪声高，不适合作为管理信号。事件选择越克制，自动化越可信。

3.2 分支是主键，工单、文档和通知是外部投影

本地映射将“仓库名 + 分支名”关联到 PMS KEY 和飞书文档 URL，同时记录 auto/manual 来源。MR 描述、Assignee 通知、Tag message 和上线通知都可复用这份上下文；选定代码段还可通过 git blame 反向追溯提交、开发人、开发分支和 PMS。分支由此成为贯穿代码、管理与交付的关联主线。

3.3 工作流按“目标状态”导航，而非写死按钮

不同项目的 transition 按钮名称可能变化。PMS 优先匹配 transition 的目标状态 to.name，无法唯一匹配时再用按钮名称 hint 兜底；提测和上线支持最多 20 步的逐级流转。上线申请中心同样按目标状态关键词判断是否完成，未完成时逐次调用下一步，而不是假设一次请求即可跨越所有节点。两个状态机采用统一的“读当前状态—执行合法动作—再次确认”模式。

3.4 自动化必须幂等、可降级、可关闭

幂等与去重

• 同标题工单查重

• processed-branches 防重复弹框

• push SHA 签名防重复评论

• 飞书通知使用幂等键

降级与开关

• 字段被 Jira 拒绝时最多三次剔除重试

• AI、同步评论、文档、通知均可独立关闭

• 外围失败记日志，不阻断 Git 主链路

• dry-run 先预览后执行

3.5 AI 只处理“理解与表达”，规则处理“确定性动作”

是否建单、绑定关系、状态流转、字段写入、去重签名都由规则驱动；AI 用于判断是否属于智能功能迭代、概括变更、生成文档。即使模型不可用，确定性流程仍然成立。这种边界能降低幻觉风险，也便于审计。

3.6 用事件契约连接系统，而不是把系统揉成一个脚本

Skill 负责生成可靠的分支、MR 和 Tag 事件，并把 PMS KEY、开发分支和操作人等上下文写入对应载体；GitLab、CI/CD、PaaS 按各自既有职责消费事件。这样的事件契约使链路可替换、可测试、可独立演进：更换部署平台时不需要重写开发管理逻辑，调整 PMS 工作流时也不会侵入镜像交付流程。

3.7 高影响写操作必须有确认门

自动化不等于取消责任边界。创建 MR 和 Tag 默认要求 dry-run 或二次确认；--no-prompt 不能单独构成授权，自动执行还必须显式传入 --yes。Review、合并和正式发布继续由责任人决策，代理只减少信息搬运与机械点击。

本质收益：不是“少点几次按钮”，而是让一次本地开发意图同时成为管理信号、协同信号和交付信号，使个人不漏项、负责人看得到、Reviewer 与测试接得住、发布平台能继续执行且上线申请有明确终态。

适合自动化

• PMS 字段、状态与文档同步

• MR/Tag 参数组装与通知

• 分支/Tag 触发平台流水线

• 结果可验证、失败可重试

人工审核决策

• 事项范围、目标分支与 Reviewer

• MR 合并与正式 Tag 确认

• 异常流程、回滚与权限变更

• 模型结论和上线结果的最终采信

开发管理SKILL经过多轮迭代试用，通过实践验证以本地原生开发行为作为可信事件，附加本地持久化存储开发生命周期的关键信息，可将开发事件集成转化为多系统管理操作，自动化协同操作多个系统形成完美闭环，将研发同学从多任务长周期跨系统的繁琐操作中解脱出来；

最终目标：开发者专心在本地开发(一个窗口交互)，本地开发任务全周期跟踪持久化记忆，Agent自动代理完成跨系统录入、流转、整理与通知；基础平台根据分支、MR 和 Tag 自动完成测试与发布，让产研协作从“人工记忆串联系统”升级为“事件驱动、平台接力、全程可追溯”。