驻场卖人头，FDE卖结果。

从“会用AI”到“交付真实结果”，2天重塑你的职业角色。

2天12模块，你将带走

• 1种新角色定位：FDE不是售前，不是驻场，不适合咨询，不是PM
• 5层工具箱：平台底座/AI工程/数据集成/交付协作/业务组织
• 3种翻译能力：业务-技术、高管-工程、现场-团队
• 1种商业模型：按阶段交付、按结果验收（不是按人头计费）
• 1份转型清单：简历改写、面试准备、offer谈判
• 1个真实案例：句子互动×在线教育头部客户（1人月产能1000➡️3000）

课程大纲

day1：从是什么到怎么做

• FDE的崛起/一天/一周/一个项目
• 核心能力/翻译工作坊

day2：从怎么做到怎么赚钱

• 项目工作流/现场作战/商业化模式
• 职业转型/结业路演

适合人群

适合

• 工程师/AI工程师/数据工程师
• 售前/解决方案架构师/咨询顾问
• 创业者/自由职业者
• 心动但不知如何开始的人

不适合

• 只想学工具的人
• 只想学大模型API的人
• 不想出差，不想进客户现场的人

授课讲师：Bill li（李国彪）

大中华区敏捷导师第一人

国内敏捷Scrum引进推广先行者之一

优普丰AI敏捷创新咨询创始人、总裁

链接100位创变者，共同探索小而美极简商业模式

服务500+企业客户，10000+个人学员，完整经历移动通讯及互联网发展与创业大周期，深度研究AI落地应用和场景，发布《AI原住民宣言》

长年居住于加拿大，拥有国内外实践经验和双重视角，与Costco等甲方大厂、埃森哲、 OpenAI、加拿大联邦政府首席敏捷教练等多方碰撞与交流，并总结沉淀出行之有效的方法论，专程回国为RSG大会带来专属培训，全球首发。

时间：2026年11月14-15日 双周末 9:00-17:00
地点：上海，具体地点待定
人数：限40人/期
价格：盲鸟票 ¥2500
常规价 ¥5000
3人团购，9折

不是新工具，是新操作系统

从现场发现到生产采纳，一套让AI项目真正落地的端到端方法。

2天12模块，你将带走：

• 1套新共同语言：九大能力域+六项原则
• 1条可走的路径：七阶段作战路径+连续工程
• 1组实用工作模板：Gemba Notes/Value Stream Map/Concept Canvas /POC Canvas /Agent PRD /Eval Plian
• 一个真实案例：A fashion group（2800+门店）
• 一个同学圈子： AI决策者+架构师+业务负责人

课程大纲

day1 重新理解AI时代的“做项目”

• AI时代的行动鸿沟/6项基本原则
• 九大能力域全景/现在作业（小组）

day2 走完一遍端到端流程

• 从现场到价值流/复杂性的建模
• 从假设到agent/从demo到生产
• 结业路演

适合人群

适合

• AI项目负责人/业务总监
• scrum master/PMO/架构师
• 咨询顾问/产品经理
• AI创业公司创始团队
• AI项目落地困难的团队

不适合

• 只想要工具清单的人
• 只想学prompt技巧的人
• 想一夜间团队转型的人

授课讲师：Bill li（李国彪）

大中华区敏捷导师第一人

国内敏捷Scrum引进推广先行者之一

优普丰AI敏捷创新咨询创始人、总裁

链接100位创变者，共同探索小而美极简商业模式

服务500+企业客户，10000+个人学员，完整经历移动通讯及互联网发展与创业大周期，深度研究AI落地应用和场景，发布《AI原住民宣言》

长年居住于加拿大，拥有国内外实践经验和双重视角，与Costco等甲方大厂、埃森哲、 OpenAI、加拿大联邦政府首席敏捷教练等多方碰撞与交流，并总结沉淀出行之有效的方法论，专程回国为RSG大会带来专属培训，全球首发。

时间：2026年11月7-8日 双周末 9:00-17:00
地点：上海，具体地点待定
人数：限40人/期
价格：盲鸟票 ¥2500
常规价 ¥5000
3人团购，9折

购买RSG大会门票者，只需加99元，即可参加。

课程名称：Creative Agility: AI 原生敏捷工作坊–从 Sprint-driven Delivery 到 Intent-to-Evidence Delivery当执行主体从 Human Team 变为 Human-Agent System，团队需要的不是更快的 Sprint，而是一套重新设计的操作模式。

Intent 意图 → Execution 自主执行 → Evidence 证据 → Learning 学习

Human owns meaning & accountability · Agents own bounded execution

课程内容

3.5 小时，你将经历（自带电脑实操 · 动手练习 ≥ 50%）

• 开场 Opening：AI 时代，敏捷为什么必须重构
• 主题 + Agent 现场演示 Keynote & Demo：第一性原理 · 双速循环 · Artifact-driven Agent 如何工作
• Round 1 · 先失败 Traditional：用传统方式拆解模糊需求，让 Intent / 自主权 / 验证问题当场暴露
• Round 2–3 · 再重构 AI-Native：上机实操：用四大核心工作件，重新设计你的人机交付系统
• Evidence Gate Take-away：用证据做上线决策，映射你自己的 30-Day Pilot

全程上机实操· 请自带电脑

每组一个 Agent Workspace（5–6 人/组），现场跑通 Intent → Execution → Evidence 完整流程；也可使用自己的千问 / Kimi / DeepSeek / ChatGPT 全程参与。

四大核心工作件

01 Intent Artifacts 意图工作件 · 什么算成功、谁负责

02 Agent Work Package 智能体工作包 · 授权边界与升级条件

03 Verification Contract 验证契约 · 什么证据才算完成

04 Evidence Ledger 证据台账 · 偏差、成本与学习

带走的不只是概念

团队产出：

√ Intent Artifacts + 人机工作编排图

√ Agent 自主等级与 HITL 规则

√ Verification Contract

√ 一个 Evidence Gate 发布决策

个人带走：

My 30-Day AI Native Agile Pilot

一个真实工作· 30 天最小试点——第二天就能拿回团队讨论。

适合谁

研发负责人· 产品经理 · EA / 架构师 · Scrum Master · 敏捷教练 · 交付管理者

授课讲师：Bill li（李国彪）

大中华区敏捷导师第一人

国内敏捷Scrum引进推广先行者之一 

优普丰AI敏捷创新咨询创始人、总裁

链接100位创变者，共同探索小而美极简商业模式 

服务500+企业客户，10000+个人学员，完整经历移动通讯及互联网发展与创业大周期，深度研究AI落地应用和场景，发布《AI原住民宣言》

长年居住于加拿大，拥有国内外实践经验和双重视角，与Costco等甲方大厂、埃森哲、 OpenAI、加拿大联邦政府首席敏捷教练等多方碰撞与交流，并总结沉淀出行之有效的方法论，专程回国为RSG大会带来专属培训，全球首发。

授课讲师：王朝成

企业 AI 架构师 / FDE 实践者

创羽昀智能创始人兼CEO

浙江大学计算机硕士，前阿里高级技术专家、平安研发总监、饿了么高级架构师

10+ 年软件工程与复杂系统架构经验，8+ 年研发管理经验

曾负责大规模互联网系统及多个从 0 到 1 的技术与产品项目

近年专注企业 AI 与 FDE 实践，推动 AI 从技术验证走向真实业务交付

关注 AI Native Development、现场共创、快速原型、短周期验证与持续迭代

探索如何将 FDE 与敏捷方法结合，让技术团队更快理解业务、验证价值并完成交付闭环

培训时间和价格

9月13日  13:30-17:00 

课程时长：3.5小时 

课程形式：约45%理念讲解、45%小组练习、10%总结反思

这几乎是所有企业转型的通病：花钱、上系统、搞项目、做汇报，流程走得滴水不漏，看起来轰轰烈烈，落地之后却彻底沉寂。

很多企业陷入了一个致命误区：把“买工具、上系统”当成了数字化转型。

真正的数字化，从来不是一场技术采购，而是一场深刻的组织进化。工具可以花钱买到，但能适配数字时代的团队能力、业务模式、决策思维，只能靠企业自己打磨生长。

今天我跳出枯燥的理论框架，结合多年企业辅导的实战经验，拆解清楚：什么是真数字化、什么是伪转型、为什么绝大多数企业越转越累，以及普通企业可直接落地的转型路径。

一、先避坑：认清4种最常见的“伪数字化转型”

很多企业转型失败，根源不是执行力不够，而是从定义上就彻底跑偏了。如果你还在把以下这4件事当成数字化转型，做得再多也是无用功。

1. 把系统上线，等同于转型成功

上线ERP、CRM、各类办公系统，只是单纯的工具采购，和数字化转型毫无关系。就像买了一堆高端厨具，不代表能做好一桌好菜。工具摆在那里没人用、用不好、和业务脱节，最后只会沦为摆设，白白消耗企业成本。

2. 把渠道升级，等同于模式升级

搭建官网、开发小程序、上线APP，只是多了一个触达用户的渠道，只是表层的形式更新。没有重构服务逻辑、没有优化用户体验、没有迭代业务流程，再多的线上渠道，也只是空有外壳，无法带来真正的业务增长。

3. 把IT项目，当成企业转型

不少公司的数字化，全权交给IT部门负责，业务部门全程旁观、被动配合。但数字化的核心是业务变革，不是技术升级。技术只能实现功能，只有业务才能创造价值。IT自嗨式建设、业务落地脱节，是转型最常见的翻车原因。

4. 把一次性项目，当成长期进化

很多企业抱着“一劳永逸”的心态做转型：定一套完整方案、做完一次落地、验收一次项目，就觉得万事大吉。但数字时代的市场、用户、竞品永远在变，静态的完美规划，根本扛不住动态的市场变化。用工业时代的静态思维，做数字时代的动态转型，注定只会被时代淘汰。

二、读懂本质：真正的数字化，到底转的是什么？

拨开所有概念和噱头，数字化转型的核心本质只有一句话：用数字技术重构价值创造的方式，完成企业组织能力的迭代升级。

它的核心从来不是技术，而是思维、流程、组织的全方位变革。

技术只是手段，业务价值才是目的；

工具只是载体，模式升级才是核心；

项目只是起点，持续进化才是终点。

这里分享一个简单好用的自检标准，帮你快速区分真假转型：

如果你的关注点只有「系统有没有上线、项目有没有做完」，这是项目思维，伪转型；

如果你的关注点是「效率有没有提升、体验有没有优化、有没有新的增长机会」，这是价值思维，真转型。

数字化从来不是为了“看起来先进”，而是为了“跑得更快、活得更好、长得更强”。

三、深度拆解：绝大多数企业转型失败的3个核心根源

见过无数企业的转型案例，抛开表面的资金、团队问题，所有失败的底层逻辑，都逃不开三个核心错位。

1. 战略悬空：高层画蓝图，基层原地踏步

很多企业的数字化，只停留在高层的会议和PPT里。管理层喊着转型口号，却没有把宏大战略拆解为可落地、可执行、可验证的具体动作；中层看不懂方向、接不住任务；基层依旧沿用旧流程、旧思维工作。

没有落地路径的战略，终究只是空谈。转型不是一场宣讲，而是日复一日的价值交付，只有层层落地、逐步推进，才能真正见效。

2. 业务和技术两张皮：技术自嗨，业务无用

这是企业转型最普遍的内耗。IT团队专注技术迭代，追求功能完善、系统先进，却从不深入一线了解业务痛点；业务团队深陷日常工作，觉得数字化是额外负担，消极应付、不愿配合。

最终打造出来的数字化系统，看似功能齐全、十分专业，却解决不了任何实际业务问题，反而增加员工的操作成本，最后被全员闲置，彻底沦为摆设。

3. 规划僵化：用静态方案，应对动态市场

传统企业习惯做长线、全量、完美化的规划，试图一次性把所有问题解决。但当下的市场最大的特点就是不确定性：用户需求随时迭代、行业规则持续更新、竞品打法不断升级。

我曾辅导过一家制造企业，耗费大量时间和成本打造标准化智能工厂，落地完成后才发现，市场早已从大批量标准化生产，转向小批量定制化需求。一套完美的静态方案，彻底跟不上动态的市场变化，所有投入全部付诸东流。

在不确定的时代，完美的规划，远不如灵活的迭代靠谱。

四、转型核心：数字化的终极目标，是打造业务敏捷能力

很多企业本末倒置，一味深耕技术、搭建系统，却忽略了数字化的终极目标：通过数字化，让业务更敏捷、组织更灵活、增长更可持续。真正的转型，核心是三件事。

1. 重构客户价值：从“我有什么”到“用户要什么”

传统企业的经营逻辑是供给驱动：企业有什么产品、什么服务，就卖给用户什么。数字化转型，要求企业彻底切换为需求驱动。

依托数据洞察用户真实痛点，挖掘未被满足的潜在需求，通过数字化手段优化全流程客户体验，跳出同质化竞争，创造独属于自己的用户价值，这才是数字化的核心意义。

2. 再造业务流程：从“线上搬家”到“流程重构”

很多企业的流程数字化，只是把线下填表、审批、流转的工作，简单搬到线上，看似高效，实则冗余繁琐的问题依然存在。

真正的流程再造，是彻底打破旧有桎梏：砍掉无价值的审批环节、自动化重复机械的基础工作、打通各部门的流程壁垒，从“以部门为中心”转为“以价值流为中心”，让业务流转更顺畅、资源利用更高效、整体内耗更低。

3. 进化组织能力：从“经验决策”到“数据驱动”

技术可以采购、系统可以复制，但敏捷的组织能力，是企业独一无二的核心壁垒。

数字化转型，本质是组织思维的升级：告别老板拍脑袋、经验做决策的传统模式，用数据支撑判断；打破部门墙，建立跨部门协同机制；培养快速试错、持续优化的团队文化，让整个组织能够快速响应市场变化。

五、为什么做数字化，一定要结合敏捷思维？

很多人疑惑：数字化转型，为什么离不开敏捷？因为二者底层逻辑完全契合，是天然的共生关系。

1. 同样拒绝无效自嗨，坚持价值优先

数字化以客户价值为核心，敏捷以业务价值为导向。二者都摒弃“为了做而做”的形式主义，所有迭代、所有优化、所有投入，都只为落地真实价值，拒绝无用功能、无效投入。

2. 同样拥抱变化，拒绝僵化固守

市场永远在变，没有一成不变的转型方案。敏捷的短迭代、快试错模式，刚好适配数字化的不确定性，把宏大的转型目标拆解为小周期可落地、可验证的任务，有效规避一次性投入的巨大风险。

3. 同样强调协同，打破组织内耗

数字化转型需要全员联动，绝非单一部门的工作。敏捷的跨职能团队模式，能够打通业务、技术、运营的壁垒，让各岗位协同作战、目标统一，共同对转型结果负责，彻底解决“两张皮”问题。

4. 同样坚持持续进化，拒绝一劳永逸

数字化没有终点，只有连续不断的新起点。敏捷的持续复盘、迭代优化机制，能够让企业在转型过程中不断修正方向、补齐短板，让组织能力持续进化，适配市场长期变化。

六、落地指南：企业通用的四步数字化转型框架

数字化不用追求大而全，盲目全面铺开只会漏洞百出。这套轻量化落地框架，适配大中小各类企业，小步快跑、稳步见效。

第一步：价值发现，单点突破

摒弃全面转型的执念，优先梳理业务核心痛点，筛选出投入低、见效快、价值高的转型切入点。通过业务流程梳理、价值流分析，明确转型目标和价值标准，先做单点试点，不盲目铺大盘。

第二步：能力搭建，夯实基础

组建跨职能专项团队，整合业务、技术、运营核心人员，打破部门壁垒。导入敏捷工作方法和数字化工具，搭建基础的数据决策体系，培养团队数字化、敏捷化的工作思维，筑牢转型根基。

第三步：迭代落地，持续验证

以短周期迭代推进落地，每一轮迭代都聚焦具体业务问题，落地后及时验证价值、收集反馈。根据市场和业务变化灵活调整方案，不纠结完美方案，只求持续优化、逐步见效。

第四步：复制推广，全面进化

沉淀试点过程中的成功经验、落地方法和避坑逻辑，形成可复制的标准化模式。逐步推广到全业务线，同步搭建转型文化和治理体系，让数字化从项目工作，变成企业常态化的进化能力。

七、转型成功的5个核心关键，缺一不可

纵观各类企业的转型结果，能真正跑通数字化、拿到结果的企业，无一例外都做到了这五点。

1. 一把手深度认知，亲自推动

数字化是顶层变革，绝非中层或基层能够推动。企业负责人必须真正理解转型本质，亲自参与规划、协调资源、破除阻力，而非简单授权、甩手不管。高层的认知高度，直接决定转型的最终成效。

2. 从价值切入，用小成功建立信心

优先从业务痛点最突出、价值最直观的环节落地，用看得见的效率提升、体验优化、成本降低，让团队真切感受到转型的价值，打消抵触心理，积累转型信心。

3. 业务技术深度融合，协同共生

业务主导方向，技术负责落地，二者深度绑定、共同复盘、共同优化。彻底杜绝技术自嗨、业务旁观的问题，让每一次技术迭代，都精准服务于业务增长。

4. 建立数据驱动的决策文化

把数据贯穿业务全流程，用数据发现问题、验证效果、制定决策。逐步替代经验主义、拍脑袋决策的模式，让企业经营更科学、更精准、更可控。

5. 包容试错，坚持长期迭代

数字化没有完美路径，过程中必然会有试错和调整。企业要摒弃急于求成的心态，包容不完美，坚持持续复盘、持续优化，在迭代中不断完善转型体系。

八、即刻落地：普通人也能启动的3个转型动作

不用等待完备方案，企业想要启动数字化转型，从当下就能落地三个核心动作。

1. 召开全员共识会

拉通高层、中层、一线骨干，统一对数字化转型的认知，厘清误区、明确目标、对齐方向，解决“大家各有理解、各做各事”的内耗问题。

2. 锁定一个核心痛点

从效率低下、客户投诉多、成本浪费严重的核心业务环节中，锁定一个痛点作为首个转型切入点，聚焦发力、单点突破。

3. 组建专项落地小组

抽调业务、技术核心人员组成专项团队，明确目标、职责和落地周期，快速推进试点工作，尽快拿到首个转型成果。

结语

最后再重申一遍：数字化转型，从来不是买系统、做项目，而是一场企业组织的全面进化。

它淘汰的不是老旧工具，而是老旧的思维、僵化的流程、割裂的组织。在日新月异的数字时代，技术永远可以迭代，但能够快速适应变化、持续创造价值的敏捷组织能力，才是企业真正的核心竞争力。

转型没有捷径，但找对方向、用对方法，就能少走弯路、少花冤枉钱，让数字化真正成为企业增长的助推器，而非流于表面的面子工程。

如果你在企业数字化、敏捷转型的过程中，遇到认知困惑、落地卡点、团队协同难题，欢迎在评论区留言交流。

这个场景，我在从业多年里见过太多次，太多企业把“技术采购”当成了“数字化转型”，盲目跟风砸钱买系统、上工具，以为只要搞定了技术，就完成了转型。可到最后，钱花了不少，系统成了摆设，业务毫无起色，员工怨声载道，转型彻底沦为“面子工程”。

其实，绝大多数企业对数字化转型都存在根本性的误解，把手段当成了目的，把工具当成了核心。今天，我就从敏捷教练的视角，帮你拨开迷雾，揭开数字化转型的真正面目，避开那些让你白花钱、走弯路的坑。

一、本质澄清：先搞懂，数字化转型不是什么，是什么？

想要做好数字化转型，第一步必须破除那些根深蒂固的迷思，先分清“伪转型”和“真转型”的边界，否则从一开始就会跑偏。

数字化转型，绝对不是这些事

❌ 不是买一套ERP、CRM或各类SaaS系统。这只是单纯的技术采购，就像买了一台先进的机器，不懂得怎么用、用在什么地方，它永远只是一个摆设，带不来任何业务价值；

❌ 不是建一个App或网站。这只是渠道建设，顶多是多了一个触达客户的途径，和“转型”无关，很多企业建了App，下载量寥寥，反而浪费了大量人力物力；

❌ 不是让IT部门主导一个项目。这只是技术升级，把线下的工作搬到线上，没有改变业务逻辑，没有优化组织模式，本质上还是换汤不换药；

❌ 不是一次性就能完成的工程。这是典型的瀑布思维，以为制定一个完美的规划，按部就班执行，就能一劳永逸。可数字时代变化太快，等你按规划完成，市场早就变了。

数字化转型的本质，到底是什么？

核心一句话：利用数字技术，重塑企业的价值创造方式，实现组织能力的根本性进化。

它从来不是关于“技术”，而是关于“业务”。技术只是工具，最终目的是解决业务痛点、提升业务效率、创造业务价值；

它从来不是关于“工具”，而是关于“模式”。不是简单地用数字工具替代人工，而是重构业务模式、盈利模式，找到新的增长路径；

它从来不是关于“项目”，而是关于“能力”。不是做完一个项目就结束，而是打造企业应对变化、持续创新的核心能力。

这里有一个最简单的判断标准，帮你快速自检：

• 如果你开口就问“系统上线了吗”“项目完成了吗”，那你还是停留在“项目思维”，做的只是伪转型；
• 如果你开口问“业务效率提升了吗”“客户体验改善了吗”“新的收入模式出现了吗”，那你才真正理解了转型的本质，走在正确的路上。

二、为什么大多数转型都失败了？敏捷视角的深度剖析

见过太多企业，雄心勃勃地启动数字化转型，最后却不了了之，要么不了了之，要么半途而废，要么投入巨大却颗粒无收。结合我辅导过的众多企业案例，发现这些失败的背后，都藏着三个根本错位，也是最容易被忽视的坑。

错位一：战略与执行脱节，口号喊得响，落地没方向

最典型的表现就是：高层在会议上高喊“数字化转型”的口号，描绘了宏伟的蓝图，可中层管理者一头雾水，不知道该怎么落地，基层员工更是照旧按老路子工作，转型只是停留在PPT上、会议里，从来没有真正渗透到日常工作中。

根源问题在于，企业缺乏将战略转化为可执行行动的机制，把“转型”当成了一句口号，而不是需要一步步落地的具体动作。

从敏捷视角来看，真正的转型战略，从来不是靠一次宣讲、一份规划就能落地的，必须通过持续的价值交付，把宏大目标拆解成一个个可落地、可验证的小目标，一步步推进，才能让战略真正落地生根。

错位二：技术与业务割裂，IT自嗨，业务脱节

很多企业的转型，都是由IT部门主导，业务部门被动配合。IT部门埋头研究技术、搭建系统，却从来不去了解业务部门的真实需求，不知道一线员工每天面临的痛点是什么；业务部门则觉得“转型是IT的事”，消极应付，不主动参与。

最后的结果就是，IT部门辛辛苦苦搭建的系统，和业务需求严重脱节，员工用起来不方便，甚至还要额外增加工作量，最后只能弃之不用，形成“系统与业务两张皮”的尴尬局面。

敏捷视角下，转型从来不是技术部门单方面的事，必须是业务与技术深度融合的过程。技术要服务于业务，业务要引导技术，两者协同发力，才能避免“自嗨式转型”。

错位三：规划与执行断裂，用旧思维应对新变化

很多企业做转型，还是沿用工业时代的“预测式思维”，花大量时间制定完美的规划，试图把所有细节都考虑到，然后按部就班执行。可数字时代的核心特征就是“不确定性”，市场在变、用户需求在变、竞争对手在变，等你按规划完成系统上线，当初的需求可能早就过时了，用户也根本不买账。

我曾辅导过一家制造业企业，他们耗时许久、投入巨资打造了“智能工厂”，一心想实现大规模标准化生产，结果系统上线后才发现，市场需求已经转向了小批量定制，他们的系统根本无法适配，之前的所有投入，都打了水漂。这就是预测式规划的典型悲剧，用静止的思维，应对动态的市场。

敏捷视角下，转型必须是迭代演进、持续验证的过程，不是一次性的工程。与其追求完美规划，不如小步快跑，快速试错，根据市场反馈及时调整方向，才能跟上变化的节奏。

三、数字化转型的核心：从“技术系统”到“业务敏捷”

很多企业之所以转型失败，核心是搞错了重点，把精力都放在了技术架构、系统搭建上，却忽略了最核心的东西：组织能力的重塑。

真正的数字化转型，核心不是技术，而是组织能力的根本性进化。基于多年的实战经验，我认为数字化转型的三大核心，缺一不可，其中组织能力是最关键的一环。

核心一：客户价值的数字化重构，以客户为中心，而非以产品为中心

传统企业的思维是“我们有什么能力，就卖给客户什么产品”，而数字化转型，需要彻底扭转这种思维，变成“客户需要什么价值，我们就创造什么价值”。

通过数据洞察，找到用户未被满足的需求，发现客户旅程中的痛点；用数字化手段，创造全新的客户体验，让客户更便捷、更高效地获得价值。

这里有两个关键问题，值得每一位企业负责人深思：你的客户旅程中，有哪些环节可以通过数字化优化，提升客户体验？你能为客户创造哪些前所未有的价值，形成自己的核心竞争力？

核心二：业务流程的数字化再造，不是“搬家”，而是“重构”

很多企业的数字化，只是简单地把线下流程搬到线上，以为这样就是转型了。但实际上，这只是“换了个地方干活”，没有消除冗余环节，没有优化工作效率，反而可能因为操作繁琐，增加员工的工作量。

真正的业务流程数字化，是“重新设计数字时代的业务流程”——消除那些不创造价值的冗余环节，自动化那些重复、繁琐的工作，让员工从机械劳动中解放出来，专注于更有价值的事情；同时，打破“部门为中心”的思维，转向“价值流为中心”，让业务流程更顺畅、更高效。

关键问题：你的核心业务价值流是什么？数字化如何让这些价值流流动得更快、质量更高，减少内耗？

核心三：组织能力的数字化进化，打造敏捷的“组织肌肉”

这是最核心、最难复制的竞争优势。技术可以买，系统可以建，但敏捷的组织能力，只能靠企业自己慢慢生长。

所谓组织能力的数字化进化，就是建立基于数据的决策机制，告别“老板拍脑袋”“凭经验做事”；培养快速实验、持续学习的文化，让员工敢于试错、乐于创新；构建跨职能协作的组织结构，打破部门墙，让团队能够快速响应市场变化。

关键问题：你的团队能否快速响应市场变化，不被旧思维束缚？你的组织是否有能力持续学习、持续改进，跟上数字时代的节奏？

四、敏捷与数字化：天然的孪生兄弟，缺一不可

很多企业问我：“做数字化转型，为什么一定要用敏捷？”答案很简单：敏捷和数字化，有着完全相同的基因，是天生的孪生兄弟，只有深度融合，转型才能成功。

1. 价值驱动 vs 技术驱动。两者都聚焦“有用”，而非“有技术”

数字化转型的核心要求是“以客户为中心”，一切动作都要围绕客户价值展开；敏捷的核心原则是“价值优先”，拒绝做无用功。两者的结合点的是：每个迭代都必须交付可衡量的业务价值，不搞“自嗨式开发”，不做“无用的功能”。

2. 迭代演进 vs 一次性工程。两者都拥抱变化，拒绝僵化

数字化转型面对的是充满不确定性的市场，没有固定的路径可循；敏捷通过短周期迭代，快速试错、快速调整，恰好能应对这种不确定性。两者的结合点是：将宏大的转型目标，拆解成一个个可快速验证的小目标，小步快跑，逐步推进，避免一次性投入过大、风险过高。

3. 跨职能协作 vs 部门割裂。两者都强调“协同”，拒绝内耗

数字化转型需要业务、技术、运营等多个部门深度融合，缺一不可；敏捷通过组建跨职能团队，实现端到端交付，打破部门墙，避免推诿扯皮。两者的结合点是：组建包含业务、技术、运营等角色的转型突击队，让大家目标一致、协同作战，共同对转型结果负责。

4. 持续改进 vs 静态目标。两者都追求“进化”，拒绝停滞

数字化转型不是一次性的，而是一场持续的组织进化；敏捷通过迭代回顾会，持续反思、持续优化，不断提升团队能力。两者的结合点是：建立转型过程的定期检视和调整机制，及时发现问题、解决问题，让转型之路越走越顺。

我辅导过的很多企业，正是因为将敏捷与数字化深度融合，摆脱了“伪转型”的困境，真正实现了业务的提升和组织的进化。

五、数字化转型的四步实战框架，不用复杂，直接落地

结合多年辅导企业转型的成功经验，我总结出一套简单易落地的四步实战框架，不管是中小企业，还是中大型企业，都能直接套用，避开弯路、少花冤枉钱。

第一步：价值发现，找准切入点，不盲目铺开

转型不是“全面开花”，而是“单点突破”。先识别1-2个高价值的数字化切入点，不用追求“大而全”，重点找那些痛点最突出、最能快速产生业务价值的环节。

通过价值流分析，梳理核心业务流程，找到其中的瓶颈和痛点；明确转型的初步价值假设和成功标准，知道“我们要达到什么效果”，再制定清晰的转型路线图和第一个小目标。

第二步：能力建设，搭建团队，夯实基础

转型的核心是人，没有合适的团队，再好的规划也无法落地。组建第一个跨职能转型团队，成员要包含业务、技术、运营等多个角色，确保团队能覆盖转型的全流程。

导入敏捷实践和数字化工具，让团队掌握转型所需的方法和工具；建立数据驱动的决策机制，让团队养成“用数据说话”的习惯，夯实转型的基础能力。

第三步：迭代突破，小步快跑，持续验证

通过短周期迭代，交付数字化成果，不用追求“一步到位”，每个迭代都聚焦一个小目标，完成后及时验证价值假设——看看这个成果是否解决了痛点、是否创造了价值。

根据验证结果，及时调整方向，持续优化，把小的成功积累起来，慢慢建立团队的信心，也让转型成果逐步显现。

第四步：规模化推广，复制经验，全面进化

当第一个试点团队取得成功，形成可复制的经验后，再将这些经验推广到更多业务领域，扩大转型的覆盖面。

建立转型文化的传播机制，让更多员工理解转型、认同转型、参与转型；完善数字化治理体系，确保转型能够持续推进，最终打造出持续进化的组织能力。

六、企业数字化转型的五个关键成功要素，缺一不可

很多企业转型失败，不是因为方法不对，而是忽略了一些关键要素。结合实战经验，这五个要素，是转型成功的核心保障，缺一不可。

1. 一把手的认知升级，转型的核心推动力

数字化转型不是“IT部门的事”，而是“一把手工程”。一把手不能只授权给技术负责人就万事大吉，而是要亲自参与转型设计，理解数字化转型的本质，明确转型的方向和目标，不做“甩手掌柜”。只有一把手重视，才能打破部门墙，协调各类资源，推动转型落地。

2. 以价值为纲的切入点选择，用小成功积累大信心

转型不能急于求成，要从最能产生业务价值的环节开始，比如解决客户投诉最多的痛点、优化效率最低的流程。用早期的小成功，建立团队和企业的转型信心，让大家看到转型的价值，才能更好地推动后续的转型工作。

3. 业务与技术深度融合，拒绝“两张皮”

打破部门墙，组建跨职能团队，让业务人员和技术人员并肩作战，共同参与需求分析、方案设计、落地执行的全过程。业务人员提供需求和方向，技术人员提供实现方法，两者协同发力，才能避免系统与业务脱节，让转型真正服务于业务。

4. 数据驱动的决策文化，告别“拍脑袋”

建立数据采集、分析、应用的闭环，让数据贯穿转型的全过程。无论是需求判断、方案设计，还是效果验证，都要用数据说话，而非凭经验拍板。培养团队“用数据决策”的习惯，让转型更科学、更高效。

5. 持续学习与迭代改进，接受不完美，拥抱变化

数字化转型没有标准答案，也没有完美的路径，必然会遇到挫折和失败。要接受“小步快跑、快速试错”的转型节奏，不追求“一步到位”，从失败中快速学习，持续调整方向和方法，让转型在迭代中不断完善、不断进化。

七、立即行动：明天就可以开始的三个动作

很多企业负责人总说“转型太难，不知道从哪里开始”，其实转型不用等“完美方案”，从明天开始，这三个小动作，就能让你迈出转型的第一步，快速启动转型之路。

1. 组织一次转型共识会

召集核心团队，包括高层、中层和一线骨干，一起讨论“我们理解的数字化转型是什么”，澄清大家的认知差异，明确转型的核心目标，让所有人都达成共识，避免“各自为战”。

2. 选择一个痛点开始

不用追求“全面转型”，找出当前业务中最痛的一个环节，可能是客户投诉多、可能是流程效率低、可能是成本居高不下，思考“数字化能否优化这个环节”，把这个环节作为转型的第一个切入点。

3. 组建一个转型小组

从业务部门和技术部门各抽调1-2名核心骨干，成立临时转型突击队，明确小组的目标和职责，让他们专门负责第一个切入点的转型落地，快速拿到第一个小成果。

结语：数字化转型，是一场组织进化，而非技术采购

回到开篇的问题：什么才是真正的数字化转型？

它不是一个项目、一套系统、一次投入，而是一场组织能力的根本性进化；它不是让企业变得更“技术”，而是让企业变得更“敏捷”、更“高效”、更“懂客户”。

它要求企业从工业时代的“稳定可控”模式，进化为数字时代的“敏捷适应”模式——不再害怕变化，而是主动拥抱变化；不再依赖经验，而是依赖数据；不再各自为战，而是协同作战。

在陪伴企业转型的这些年里，我看到一个清晰的规律：那些把转型当作技术项目的企业，最终都失败了；那些把转型当作组织进化的企业，最终都成功了。

数字时代，最大的不变就是变化本身。真正的数字化转型，不是让你拥有多少先进的技术和系统，而是让你拥有应对变化、持续创新的组织能力。而敏捷，正是帮你打造这种能力的最佳路径。

如果你在数字化转型中，遇到了认知困惑、落地难题、团队协同等具体问题，欢迎在评论区留言，我们一起探讨解决方案～

上个月，一个朋友跟我吐槽：他们组 5 个 Claude Code agent 一起干活，后端 agent 把 API 字段改了，前端 agent 完全不知道，联调挂在生产环境。

我问他：”你们不是用 git 协作的吗？”

他说：”用了。但 git merge 退出码是 0，分支 tip 就是没进 main。下次部署就是旧代码。”

这其实是所有跨 2 个以上仓库跑 AI agent 的团队都会撞上的三面墙。今天介绍一个工具 HarnessXP，三面墙一起拆。

  项目作者是XP多年实践者，一开始是为了迁移和统一自己的已有的3个项目代码（小程序、后端服务、管理员网站）。后来越搞越大，最后相当于自己弄出来一套openspec commands。一开始确实是想直接用openspec的，后来发现他跨不了仓，然后就在chatGPT和ClaudeCode的帮忙下，自己搞出来一套跨仓的SDD框架。改业务代码过程中，就碰到各种bug，一边儿改代码儿，一边儿修这些命令，就弄出了这么个项目，剥离了业务代码，开源给社区供大家学习和参考。地址：https://github.com/mebusw/HarnessXP

5分钟上手

# 1. 拉框架git clone https://github.com/mebusw/HarnessXP.gitcd HarnessXP# 2. 初始化新项目（在干净父目录）mkdir my-project && cd my-project../HarnessXP/bin/init \  --name my-project \  --repo backend:../backend:service:node \  --repo web:../web:web:react \  --repo mobile:../mobile:app:flutter# 3. 把你的共享契约放进 orchestrator 的 shared/cd orchestrator# （把 openapi.yaml / types.ts / config.schema.json 丢进 .openspec/shared/）# 4. 同步契约到所有业务仓bash .openspec/swarm/sync-shared.sh all# 5. 启动 spec-driven workflowclaude> /spec USER_AUTH> /plan USER_AUTH> /swarm USER_AUTH> /merge USER_AUTH

蓝图

Harness Engineering ← 方法论

HarnessXP ← 开源框架

Specification Gravity ← 核心理论

AI-Native Harness Engineering for Polyrepo & Polyglot Development ← 愿景

跨仓开发的几个典型踩坑

坑一：合约漂移 —— 后端改了字段，前端到生产才挂

想象一下这个场景：

后端 agent 收到指令：”把 /api/users 的 email 字段改成 contact_email。” 它很快把后端代码改了，单元测试通过，提 PR，merge。

前端 agent 同时在另一个仓库登录页面。它不知道 email 改名了，照样发 email。联调在 staging 没跑过（前端的 spec 没同步），部署到生产，挂了。

合约漂移的本质：spec 和代码在不同的仓，改 spec 的 agent 和改代码的 agent 不沟通。

HarnessXP 的解法很直接 —— 把 spec 和共享合约集中到一个 orchestrator 仓。N 个业务仓持有代码，但所有”跨仓接口”必须在 orchestrator 仓里登记。M 个 agent 开工前先读 orchestrator，改完接口必须同步更新 orchestrator 仓。

💡 核心思路： 让”接口是什么”这件事只有一个真理来源。Agent 之间通过共享合约沟通，不通过 git commit 历史沟通。

坑二：状态无人负责 —— “特性 X 做到哪了？”

你问 PM，PM 说：”我以为前端在做。”

你问前端，前端说：”我看 PR 在后端那边挂着。”

你问后端，后端说：”我 merge 了呀。”

规格在仓 1，代码在仓 2，评审在仓 3，状态在某个人的脑子里。这是多仓 AI 协作最常见的死法 —— 状态没有归属，问谁都是”以为在别人那里”。

HarnessXP 用一个 4 态状态机解决：PROPOSED → IN_PROGRESS → REVIEWED → MERGED。每个跃迁由且仅由一个工具负责：

• PROPOSED：spec 在 orchestrator 仓登记完毕
• IN_PROGRESS：某个 agent 拿到这个 spec，开始改
• REVIEWED：CI + 跨仓合约校验通过
• MERGED：merge-all.sh 二次校验成功

任何时刻问”特性 X 的状态”，工具直接告诉你。不需要去问 PM、前端、后端。

💡 核心思路： 不要让人去维护状态，让工具去维护。状态机的价值不是机器本身，是”每个跃迁有且只有一个负责人”。

坑三：幽灵合并 —— git merge 退出码 0，但 tip 没进 main

这是最阴险的一个。

CI 全绿。PR 合并按钮显示 “merged”。git log main 也有这条 commit。看起来一切都好。

但下次部署，CI 跑的是旧代码。仔细看 git log main，发现这条 commit 在 main 上的位置比某个 feature 分支还老 —— 它根本不在 main 的 head 链上。

常见原因：rebase 出错、cherry-pick 错乱、force push 覆盖。git merge 的退出码 0 只能告诉你”本地操作没出错”，不能告诉你”这次合并真的进了 main 的 head”。

HarnessXP 的解法是 4 行 bash：

git fetch origin mainif git merge-base --is-ancestor "$BRANCH_TIP" origin/main; then  echo "OK: tip is in main"else  echo "FAIL: phantom merge detected"fi

git merge-base --is-ancestor 做的事就是：检查 $BRANCH_TIP 是不是在 origin/main 的祖先链上。如果不是 —— 合并看起来成功但 tip 没真进 main —— 就是幽灵合并。

每次 merge-all.sh 跑都对每个 PR 做这个二次校验。

💡 核心思路： 不要相信退出码，相信祖先链。CI 验证的是”代码能不能编译”，merge-base 验证的是”代码有没有真的进 main”。

架构：1 orchestrator + N 业务仓 + M agent

HarnessXP 整体架构极薄，由三部分组成：

• 1 个 orchestrator 仓：所有 spec、共享合约、状态机记录都在这里
• N 个业务仓：每个仓独立 git 仓库，代码在这里
• M 个 Claude Code agent：每个 agent 有严格的”允许修改的文件”边界，跨边界读写需要走 orchestrator

agent 之间通过共享合约沟通，不通过 git commit 历史沟通。这避免了”我看你昨天改了什么”这种脆弱的协调方式 —— 后者只在单仓有效，跨仓立刻失效。

结语

HarnessXP 是 MIT 协议，bash 3.2 兼容，macOS 开箱即用。仓库：https://github.com/mebusw/HarnessXP

如果你也在跨多仓跑 AI agent，欢迎试用、提 issue、扔 PR。

💬 讨论

你们今天是怎么处理幽灵合并的？是靠 CI 兜底，还是已经有专门的合并校验？评论区聊聊。

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

驾驭工程（Harness Engineering）先行者

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

这不是又一篇”AI 写代码提效 10 倍”的爽文。 这是一份真实工程实录：4 个遗留 git 仓、3 套异构技术栈、生产上跑着的服务。 我们花了一个月，搭了一套叫 Harness Engineering 的脚手架，让 AI 能在遗留系统上可控地演进，而不是 vibe coding 玩一玩。 写给正在评估”AI 编码能不能用在我们这种企业遗留系统上”的技术负责人、架构师、研发管理者。

一、先给你看个画面

如果你的企业里存在这样的场景，这篇文章就是为你写的：

你接手了一个项目。打开 git 一看：3 个仓——一个 Express.js 后端（带一堆历史遗留的 Liberating Structures 内容库），一个微信小程序（视频课程平台是叠在”线下课报名”老小程序上的），一个 AngularJS 管理员网站。

每个仓各自的 main 分支、release tag、CI pipeline、部署节奏都不一样。改 1 个 API 字段要 3 个仓联动，前端先上线、后端 API 还在部署——用户立即看到 500。

新需求：把这套跑了 3 年的老系统，演进成视频课程平台。

这时候你跟 AI 说：”帮我加个视频课程模块。”

AI 会回你一份”理想新系统”的设计稿——跟你手里这套老代码完全对不上。

这就是 vibe coding 的天花板。

它适合从 0 写 demo、做 side project、做学习练手。 它不适合企业里”老房子改扩建”这种真实工程。

那么，AI 编码在企业遗留系统上到底能不能用？

我们用一个月的时间，把这件事跑通了。答案不在模型本身，而在我们搭的脚手架——我们叫它 Harness Engineering。

二、Harness Engineering 是什么、不是什么

不是：

• 不是 prompt 工程（”你应该这样和 AI 说话”）
• 不是选模型（GPT 还是 Claude 还是 Gemini）
• 不是装个 IDE 插件（Cursor / Copilot / Claude Code）
• 不是从 0 开始搞 vibe coding demo

是：

让 AI 在你的工程里”按规矩办事”的一整套脚手架。

类比软件工程发展史——传统软件工程有这些环节：

需求分析 → 系统设计 → 编码规范 → 代码审查 → 自动化测试 → CI/CD → 灰度发布 → 监控告警 → 应急修复

我们没发明新东西，这套流程一个都没丢。只不过执行主体从”人”变成”人 + Agent”——人不再只写代码，人写让 AI 写出来的代码能可控地汇入主干的状态机、目录约定和脚本。

一句话总结我们的元经验：

当 AI Agent 接管了”写代码”这件事之后，工程师的工作不是写更多代码，而是构建”让 AI 写出来的代码能可控地汇入主干”的状态机、目录约定和脚本。 这套基建写不好，Agent 跑得越快，烂摊子越大。

我们 2026-06-09 一上午提交了 11 个 commit。没有一个是写业务的——全部都是在补齐 swarm 框架的状态机、文件命名、bash 兼容性、跨仓路径。

如果你看到这里还有共鸣，下面回答你最初关心的 3 个问题。

三、问题 1：怎么让 Agent 生成的代码”满足需求”？

3.1 需求分析：你得先搞清楚，再让 Agent 搞清楚

企业遗留系统的 AI 编码必须先冻结”哪些是基线、哪些要演进”。否则 AI 会把遗留代码当”待清理对象”——你的 LS 内容库、用户中心、线下课报名这些已存在业务，会被 AI 误判为”可以重构的新模块”。

我们的做法是冻结基线：开新会话的第一件事，跑 /release-skills（一个独立 skill，不在 7 个 slash command 之列）给当前 git 状态打一个 release candidate tag（带 release notes），把”哪些是已有事实、哪些是新增需求”钉在 tag 的 release notes 里，类似这样：

以 3 个仓的遗留代码和已实现的功能作为基础，继续开发视频课程平台功能。

• 公开遗留的 LS 内容库 API（保留不动）
• mp-app 视频平台是在”线下课报名”老小程序上叠的
• 已实现 API / feature 以 shared/openapi.yaml 为准
• 3 个仓各自的 CLAUDE.md 是遗留代码的总览

💡 Actionable Tip： Agent 不怕你啰嗦，怕你不说。你觉得显然的东西，对它一点都不显然。每次开新会话，第一件事就是把”哪些是基线、哪些是演进”写清楚。

3.2 系统设计：拆 spec 不是”想新系统”，是”扫老代码”

我们第一版用”理想新系统”思路拆出了 7 个 spec（认证、课程目录、订单、支付……），打完 RC tag 回到目录读 release notes，立刻发现两个偏差：

• 整个缺失”优惠券”（用户当面点出来）
• 整个集合过于”理想化”，完全没体现 LS 遗留域、用户中心、内容管理、线下课报名这些已存在业务

立刻回炉，最终落地 13 份 spec，按 4 类组织：

• 平台核心：AUTH / ORDER / PAYMENT
• 演进型（已存在但需明确）：LIVE_COURSES / VIDEO_COURSES / USER_PROFILE / USER_MANAGEMENT / MEDIA_UPLOADS
• 遗留 LS 内容域：STRUCTURES_CONTENT / STRINGS_GROUPS / CONTENT_ENGAGEMENT（保留但不再主动改）
• 新增（gap）：COUPON_PROMOTION / PROTOTYPE_TOOL

💡 Actionable Tip： 拆 spec 必须用真实代码与真实接口作证据，而不是凭需求文档”自上而下”命名。backend/index.js + backend/models/*.js 是事实之源，需求文档只是输入。

3.3 把”不要碰”写在契约里，不是写在文档里

遗留代码的”存在感”会不断干扰 AI 的判断——”我看到这段代码，是不是要重构它？”

我们的做法是：把 EntryWriteRequest / EntryContent / EntryGroupWriteRequest 这类 schema 显式打上”遗留的 liberating-structures 小程序接口，非当前视频平台核心需求”的 description 备注，并在 info.description 写明项目分层。

用 OpenAPI 的 tags: [Platform Core] / [Legacy LS Content] 给 AI 立边界，比写在 CLAUDE.md 里更难被忽略。

3.4 路由 ≠ 已实现

这条是血泪教训。

我们反推 openapi.yaml 时，backend/index.js 里挂了 30+ 个路由，但实际模型里只实现了 17 个。最终用户会把这个”假实现”当真——上线就崩。

💡 Actionable Tip： 扫 openapi 时必须同时扫 routes/*.js + models/*.js，区分”已实现”vs”只在路由里挂名”。请求 schema 加 additionalProperties: false，从宽松的 type: object 收紧到后端真实读取的字段。

3.5 永远做覆盖率审计

多仓遗留系统的 spec 集不是”写完即完”。我们做完 13 份 spec 后，对照原始需求 v5 文档做需求→spec 覆盖率矩阵，发现：

• COUPON_PROMOTION 是用户当面点出来才补的
• SCRM_ENGAGEMENT / REFERRAL_TRACKING / COURSE_SCHEDULE 三个 gap 还在

不审计，一定漏。

四、问题 2：怎么减少上线后的不稳定、减少紧急修复？

4.1 拆分细了才好审查

不管多大的功能，都要在 plan 阶段拆成”每次提交做一件事”的粒度。原因很简单：

拆分细了，审查的人（包括你自己）才能看得过来。 单仓内 rebase + 跨仓 release gate，三步到位。

可以先让 Agent 审查，但人要兜底。Agent 审查能抓住格式、命名、明显的逻辑错误，但业务逻辑对不对、边界条件有没有漏，这些还是得人来判断。

我们的 reviewer agent 有个硬约束：REQUEST_CHANGES 不是失败，是”拦截越界”。6/23 admin-courses 表格的 task 改到 course-detail / shared forms 已经是 forbidden 路径，reviewer 喊停是职责所在，不是流程摩擦。

4.2 自动化测试覆盖

这是减少线上事故最直接的杠杆。

单元测试：给 Agent 即时反馈的基础——它改了代码跑一下测试就知道有没有破坏已有功能。

集成测试：单个模块测试通过不代表组装在一起也没问题。用模拟数据把主要流程的集成测试覆盖起来。

CI 集成：单元 + 集成测试要跟 CI 集成，提交就自动跑，不要依赖人手动触发。

端到端测试：直接连测试环境或正式环境，通常没那么稳定，但可以代替大部分人工测试。现在有 AI 加持的 browser use 工具，写端到端测试比以前容易很多。

最后一点：自己多测试，不要过于信任 AI，尤其是关键路径和涉及钱的流程。

4.3 灰度发布 + Feature Flag

新功能不要着急全量上线。先给内部人用，测试没问题了再逐步扩大范围。加上 feature flag 开关，有问题随时关闭，不用等发版。

4.4 CI/CD：回滚速度决定事故影响范围

建立自动化部署、发布和回滚机制。修复了问题能以最快速度自动化验证和发布；出了严重问题第一时间回滚到稳定版本。

4.5 “Phantom merge” 必须正向校验

这是我们 2026-06-22 踩的一次大坑：OFFLINE_COURSE_SYNC-007 registry 里标 MERGED，但实际 branch tip没在 admin master 里。

原因：merge-all.sh 的 merge 命令看似成功（exit 0），但实际 push 失败 / merge commit 没真生成 / 后被 force-push 覆盖。

修复：

git merge --no-ff feat/$BRANCH -m "merge: $TID"
# 关键新增：merge 完成后立刻 verify
if ! git merge-base --is-ancestor HEAD origin/$DEFAULT_BRANCH; then
  git reset --hard HEAD~1   # rollback
  exit 1
fi

💡 Actionable Tip：“merge 成功”≠”代码真的进了 main”。 当脚本链条超过 5 步，必须在最后一步做正向校验（ancestor / build / test），不能相信中间步的 exit code。

可选 BUILD_CHECK=1（默认 0）：merge 后跑 ng build / npm test，失败同样 rollback。

五、问题 3：怎么让 AI 自行复现、debug、修复线上 bug 并提交 PR？

5.1 先说现实路径

说实话，让 AI 全自动修线上 bug 听起来很美好，但目前更现实的路径是：AI 辅助定位问题、生成修复方案、人来确认后再提交。

全自动闭环修复，对大多数团队来说还不成熟。建立好的开发、测试、发布流程比追求全自动化更重要。

但即便走”AI 辅助 + 人确认”这条路，前置基建也必须做：

5.2 记日志：没日志一切免谈

补充一点：日志要结构化，要有足够的上下文信息（请求 ID、用户 ID、关键参数、关键状态）。

这样 Agent 拿到日志才能还原现场。否则给它一堆无意义的 print 输出，它也分析不出什么。

5.3 能重现和验证

建立一套和生产环境尽量一致的测试环境，能重现问题、能验证修复。

没有重现环境，Agent 只能靠猜，修出来的东西你也不敢上线。

5.4 CI/CD：不要修一个 bug 搞出三个新问题

修 bug 本身可能很简单，但自动化测试跑通了再合并，这个纪律不能省。

5.5 /hotfix 命令：主控在 crisis 时的逃生通道

我们加了一个 /hotfix <TASK-ID> <app-repo> <commit-sha> 命令，追溯式生成 task spec + handoff + review + registry MERGED。

适用条件有 4 个 ✅（全打勾才能走）：

• bug 阻断 P0 交易
• 改动 ≤ 5 个文件
• 不跨仓
• 不动 .openspec/shared/ 跨仓契约 + 不动 .openspec/specs/ 业务规格

任一不满足就走正规流程。/hotfix 不是”事后补单据”，是”主控 Claude 在 crisis 时的逃生通道”——4 个 ✅ 是为了避免 /hotfix 命令被滥用为”随便写点东西”。

首个真实案例：PAYMENT-008（mp-app commit 0b8e51f，2026-06-22 retroactive 补登记）。

5.6 Session 中断必须可恢复

P0 bug 在凌晨来的时候，最容易出 session 429 中断。我们 6/19 凌晨 ADMIN_POLISH_V3 就中过一次。

做法：写 SESSION_INTERRUPT_<DATE>.md 到 handoff/<FEATURE>/，下次重启时第一件事读这个。内容 5 段：已交付 / 中断（partial）/ 未开始 / Registry 状态 / Resume 指令。partial 段的代码不能 stash / reset，直接让新 agent 读 diff。

💡 Actionable Tip： 与其追求 AI 自己修 bug，不如追求 AI 帮你少写 bug。前面说的需求分析、系统设计、测试覆盖、代码审查做好了，需要紧急修的 bug 自然就少了。

六、swarm-orchestrator 工程解剖

上面回答的是”为什么”和”怎么做”。下面给你看”长什么样”——把我们搭的脚手架原原本本摊开。

6.1 仓库布局：4 个仓的分工

~/work/001 优普丰课程平台多仓AI编码工程/
├── swarm-orchestrator/    ← 4 号仓（Source of Truth，不写业务代码）
├── mp-app/                ← 1 号仓（WeChat 小程序）
├── backend/               ← 2 号仓（Express 后端）
└── admin/                 ← 3 号仓（Angular 管理后台）

业务仓里没有.openspec/。Subagent 写交付物时不会污染业务仓的 main 分支——这是通过 worktree 内的 symlink 桥接实现的（详见后文）。

6.2 swarm-orchestrator 内部结构

swarm-orchestrator/
├── .openspec/
│   ├── specs/             # 13 份 feature spec
│   ├── plans/             # 每个 feature 的实施 plan
│   ├── tasks/<FEATURE>/   # 每个 task 的详细 spec
│   ├── handoff/<FEATURE>/ # Subagent 的交付物
│   ├── reviews/<FEATURE>/ # 跨仓一致性 review
│   ├── registry/          # agents.yaml + tasks.yaml
│   ├── shared/            # 跨仓契约（openapi / types / config）
│   ├── swarm/             # 5 个核心 bash 脚本
│   └── templates/         # spec / plan / task / handoff / review 模板
├── .claude/
│   ├── agents/            # 6 个 subagent prompt
│   └── commands/          # 7 个 slash command
├── CLAUDE.md              # 跨仓宪法（路径硬规则 + 失败模式速查）
└── README.md              # 仓库布局 + 操作步骤

6.3 6 个 subagent：每个角色都有清晰的边界

.claude/agents/ 下有 6 份 agent prompt，每一份都是这个角色专属的工作环境 + 边界 + 产出模板：

① architect.md — 跨仓契约 owner。

• 独占权：.openspec/shared/openapi.yaml、.openspec/shared/types.ts、.openspec/shared/config.schema.json、.openspec/plans/**、.openspec/tasks/**
• 产出：读 spec → 写 plan → 拆 task → 更新 registry/tasks.yaml（每个下游 task 标 app_repo）→ 写 .openspec/shared/openapi.yaml → 写 handoff
• 铁律：禁止改 ../mp-app/、../backend/、../admin/ 下任何文件；禁止 push main

② backend-agent.md — Express 后端实现者。

• 工作目录：../backend/wt-<task>/
• 第一件事：把跨仓契约从 orchestrator 拉到 types/（openapi.yaml + types.ts + config.schema.json）
• 改 models/utils/index.jstest/，push 到 feat/<task> 分支

③ miniprogram-agent.md — WeChat 小程序实现者。

• 工作目录：../mp-app/wt-<task>/
• 跨仓契约拉下来后，types.ts 会被改成 .d.ts + 注释结构（小程序对 TS 不友好）
• 改 pages/<feature>/，push 到 feat/<task> 分支

④ admin-agent.md — Angular 管理后台实现者。

• 工作目录：../admin/wt-<task>/
• 多一步：npx openapi-typescript 自动把 openapi.yaml 转成 TS 客户端（生成 src/app/shared/api-types.ts）
• 改 src/app/modules/、src/app/store/、push 到 feat/<task> 分支

⑤ docs-agent.md — API 文档生成者。

• 不写业务代码，只写 API 文档到 .openspec/docs/**
• 边界明确：shared / plans / tasks 都是 architect 独占，docs-agent 不碰

⑥ reviewer-agent.md — 跨仓一致性 reviewer。

• 只读 + 写 review，不写代码
• 跨仓一致性 checklist：API 字段一致 / Type 一致 / Auth 一致 / 错误码一致 / 跨仓写边界 / 编译测试真跑过
• 硬约束：1:1 review-per-task 约定——每个被 review 的工作 task 都必须有自己的 review file，缺一个 → 该 task 永远 stuck 在 REVIEWED 不入 main
• 文件名严格用 <TASK-ID>.md，不带 -review / -umbrella / -stub 等后缀

6.4 7 个 slash command：从 spec 到 merge 的完整闭环

.claude/commands/ 下有 7 份 slash command prompt，每一份都是一段状态机切片：

① spec.md — 写需求

读用户口述 → 加载 spec-template.md → 跟用户确认 4 件事（涉及哪几个端 / 是否需要 architect 先做跨仓契约 / 是否需要 e2e / Done Definition 是什么）→ 写入 .openspec/specs/<FEATURE>.md。

下一步：/plan <FEATURE>。禁止直接 /swarm——没 plan / tasks.yaml 时 swarm 没东西可调度。

② plan.md — 拆 plan + 拆 task

读 spec → 加载 plan-template.md / task-template.md → 起 architect subagent → 校验（plan 文件存在 / 每个 task 列 Allowed/Forbidden / tasks.yaml 有 app_repo 字段 / app_repo 合法 4 选 1）→ 同步 registry status。

关键差异（vs monorepo 版）：多一个字段 app_repo；跨仓契约统一在 .openspec/shared/，plan 必须列哪些 task 是 architect 独占的。

③ swarm.md — 调度

读 registry → 拓扑排序（按 depends_on）→ 跑 create-worktrees.sh（按 app_repo 分组，在各自业务仓里建 worktree）→ 跑 sync-shared.sh all（业务仓拉最新契约）→ 起 Subagent（注入 HANDOFF_DIR / REVIEW_DIR / SHARED_DIR 环境变量）→ 聚合结果。

如果 FEATURE plan 包含 umbrella reviewer task（FEATURE-<N+1>，owner = reviewer-agent），那么 /swarm 阶段已经一次性完成 review：reviewer 写 1:1 review files + 同步 tasks.yaml status → REVIEWED。不需要单独跑 /review。

④ review.md — 跨仓一致性 Review

只适用于以下场景：

• 老式 plan 风格（plan 里没有 umbrella reviewer task）
• hotfix 后重审（REQUEST_CHANGES → APPROVED 后需要刷新 review file）
• 手动 review 路径

⑤ merge.md — 跨仓 merge

按 tasks.yaml 拓扑顺序 + app_repo 分组，把 APPROVED 的任务分别 merge 到 3 个业务仓的 main。

关键纪律：

• 不带参数：处理所有 APPROVED 的 task
• 带 FEATURE：只处理该 Feature
• 前置校验：每个 task 必须 status: REVIEWED，否则跳过并打 ↷ X: status=IN_PROGRESS，not yet REVIEWED，跳过 merge
• 跨仓 release 协调：backend → 等部署 OK → mp / admin
• 脚本默认不暂停（RELEASE_GATE=0），要开 gate 跑 RELEASE_GATE=1 bash merge-all.sh

⑥ status.md — 一张表看全

读 tasks.yaml registry status → 列跨仓 worktree → 列 handoff 落地 → 列 review 状态 → 跑契约一致性检查。

输出示例：每个 task 按 ✓ / ⏳ / ✗ 三个状态色展示，按 app_repo 分组——主控一眼能看出哪些 task 卡在哪。

⑦ hotfix.md — P0 hotfix 追溯式补全

⚠️ 专为”来不及走正规流程”的 P0 hotfix 设计。 严禁把 normal-flow 任务伪装成 hotfix 走本命令——会绕过 reviewer-agent 的质量门。

适用条件 4 个 ✅（全打勾才能走）：bug 阻断 P0 交易 / 改动 ≤ 5 个文件 / 不跨仓 / 不动 .openspec/shared/ + .openspec/specs/。

追溯式生成：task spec + handoff + review（强制 APPROVED retroactive）+ 追加 registry MERGED。

6.5 跨仓 symlink 桥：handoff 不污染业务仓

这是企业遗留系统能放心让 AI 写代码的关键设计：

业务仓里没有.openspec/。Subagent 写交付物时如果用相对路径（.openspec/handoff/...），要么落到业务仓 main 分支（污染），要么报错。

解决：create-worktrees.sh 给每个业务仓的 worktree 自动建一个 .openspec symlink：

ln -s ../../swarm-orchestrator/.openspec  backend/wt-auth-002/.openspec
ln -s ../../swarm-orchestrator/.openspec  mp-app/wt-auth-003/.openspec
ln -s ../../swarm-orchestrator/.openspec  admin/wt-auth-004/.openspec

Subagent 在 wt- 里写 .openspec/handoff/AUTH/AUTH-002.md → 实际写到 orchestrator 仓。handoff / reviews 永远在 orchestrator 落地，不污染业务仓 main。

orchestrator 自己的 worktree（wt-auth-001-arch、wt-auth-005-doc）不走 symlink，因为 .openspec/ 本来就在仓里。

6.6 跨仓契约”单一真相源”

.openspec/shared/ 是唯一的接口事实之源：

• openapi.yaml — API 字段 + 路径 + 类型
• types.ts — TS 类型定义
• config.schema.json — 跨仓配置 schema

权限表：

• architect agent → 唯一能写的人
• 其他任何人 → 只读
• 业务仓需要时 → 走 bash $ORCHESTRATOR_ROOT/.openspec/swarm/sync-shared.sh 拉取

Subagent prompt 里明确写：

禁止在 mp-app/types/ 或 backend/types/ 直接写跨仓类型，只能跑 sync 脚本。

这是 3 仓版本能 work 的核心机制。没有这层”单一真相源 + sync 拉取”，3 仓独立就退化成”3 份维护负担”。

七、4 个 commands 的演进（这一个月发生了什么）

脚手架不是一天搭好的。下面是 7 个 slash command 一个月里的演进路径，每一步都有具体 commit 和真实教训。

7.1 第 1 周：spec / plan / swarm / review / merge / status 6 件套打地基

最初的 monorepo 模板只有 /spec /plan /swarm /review /merge 5 个。6/6 拆 4 仓时加了 2 个字段（app_repo + handoff 路径硬规则）。

最关键的设计是主控永远在 orchestrator。README.md「Where to run claude」表里写：

写需求 / 拆 plan / 启动 swarm：swarm-orchestrator/ → claude → /spec /plan /swarm /review /merge /status改业务代码（不通过 swarm）：mp-app/ 或 backend/ 或 admin/ → cd <业务仓> && claude改 agent prompt：直接编辑 swarm-orchestrator/.claude/agents/改 slash command：直接编辑 swarm-orchestrator/.claude/commands/

核心规则：主控永远在 orchestrator。不要在业务仓直接 claude 跑 /swarm 之类的主控命令。

7.2 第 2 周：status 字段 + handoff 命名严格化

最初 tasks.yaml 里没有 status 字段，”哪个 task 已合并”靠人脑或 grep handoff 文件。结果 /swarm 把已合并的 task 又起了一遍 worktree，/merge 在已删除的分支上 rebase 报错。

修法：先把状态机写死：

# status 枚举：
#   PROPOSED      —— 已建任务，未起 agent
#   IN_PROGRESS   —— launch-agents.sh 起 agent 时改写
#   REVIEWED      —— /review 写完且 APPROVED 后改写
#   MERGED        —— merge-all.sh 成功合并后改写

然后把”谁改哪个状态”分摊给 4 个 slash command 的 prompt：

• /plan 创建 task = PROPOSED
• /swarm 起 agent = PROPOSED → IN_PROGRESS（脚本里 python 原子改 yaml）
• /review 写完 = APPROVED → REVIEWED / REQUEST_CHANGES → IN_PROGRESS（review skill prompt 内嵌 python 多行脚本）
• /merge 合并成功 = REVIEWED → MERGED（merge-all.sh 改 yaml）

元经验：状态机不要交给主控 Claude 维护，要切片分给每个负责执行的 skill。主控不可能记住 4 个状态转换发生在何处，但每个 skill prompt 都能在自己那一格做”原子的状态推进”。

同时把 handoff 文件命名严格化：<TASK-ID>.md，不带 owner 后缀（-arch / -api / -mp / -admin / -doc / -review / -umbrella 一律不用）。owner 信息落文件正文 ## Owner 段。脚本里删了 owner-suffix fallback——约定不够，必须代码强制。

7.3 第 3 周：umbrella reviewer + /swarm 一体化 /review

老 reviewer 写 1 个 umbrella 算完 → merge 阶段 skip 了 3 个 task。修法：

新规则——1 个 umbrella reviewer 任务 = 写 1 个详细 umbrella + N 个 per-task stub。每个 stub 必须含 **APPROVED**（或 REQUEST_CHANGES）in ## Decision 段。缺一个 stub → 该 task 永远 stuck 在 REVIEWED 不入 main。

自检脚本（每个 reviewer 任务完成前必跑）：

for f in .openspec/tasks/FEATURE/*.md; do
  tid=$(basename "$f" .md)
  rf=".openspec/reviews/FEATURE/$tid.md"
  if ! awk '/^## Decision/{flag=1; next} /^## /{flag=0} flag && /\*\*APPROVED\*\*/{found=1; exit} END{exit !found}'"$rf"; then
    echo"✗ NO '**APPROVED**' in Decision section: $rf"
  fi
done

收益：从”3 步等用户”变”2 步等用户”，省一次 slash command 调用 + 一次 subagent 启动。/swarm 命令的”下一步”从 /review 改为 /merge。

7.4 第 4 周：/hotfix 命令 + P0-P2 hardening

P0 bug 阻断交易时，来不及走 /plan→/swarm→/review→/merge 全流程。业务仓已经直接 commit 了，事后需要补 audit trail。

解法：新 /hotfix <TASK-ID> <app-repo> <commit-sha> 命令，追溯式生成 task spec + handoff + review + registry MERGED。首个真实案例：PAYMENT-008（mp-app commit 0b8e51f，2026-06-22 retroactive 补登记）。

同步落地的 P0-P2 hardening 6 项：

• P0-1：phantom merge guard — merge-all.sh merge 后 verify git merge-base --is-ancestor HEAD origin/main，否则 rollback
• P0-2：可选 BUILD_CHECK=1 — merge 后跑 ng build / npm test，失败 rollback
• P1-3：worktree 路径校验 — create-worktrees.sh 拒绝 ../admin（应是 ../admin/wt-<task>）
• P1-4：枚举统一 — handoff Status 段 4 态，review Decision 段 3 verdict，模板与 schema 用同一组枚举
• P2-5：APPROVED 检测精确化 — 9 种历史格式兼容，避免”previous APPROVED inside REJECTED”误判
• P2-6：last_verification 字段 — merge 成功后写 {merged_at, method} 到 registry

核心教训：“看着 exit 0″是工程里最深的坑。任何链条长过 3 步的脚本，最后一步必须做正向校验（ancestor / build / test），不能相信中间步。

八、我们这一周的真实数据（6/18-6/24）

维度 → 数字 → 说明：

• Git commits → 53 → 6/18 上午到 6/23 下午
• 业务 feature 收尾 → 4 个 → ADMIN_POLISH_V3 / OFFLINE_COURSE_SYNC / ENROLLMENT_PIPELINE_HARDENING / ADMIN_UI_TABLE_FIX 等
• 框架代码 commit → 3 个 → P0-P2 hardening / /hotfix 模板 / umbrella reviewer 一体化
• 写新业务代码 → 0 → 全部在 swarming + hardening

关键判断：6/18-6/24 是「从建设期 → 运维期」的转折点。前两周几乎都在建流程（spec / plan / tasks / handoff / review / merge）；从这周开始，流程基本就位，进入”边跑边补”阶段。

九、6 条铁律（带走版）

1. 先冻结”基线”，再谈演进。 跑 /release-skills 给当前 git 状态打一个 release candidate tag（带 release notes），把”哪些是已有事实、哪些是新增需求”钉在 release notes 里，否则 AI 会把遗留代码当”待清理对象”。

2. 以真实代码反推契约，不要用需求文档正推。backend/index.js + backend/models/*.js 是事实之源，需求文档只是输入。架构师 agent 用 shared/openapi.yaml 重新反推——5 个阶段：扫路由 → 扫模型 → 写 schema → 区分已实现 / 挂名 → 按范围打 tag。

3. 共享契约文件要”独占维护”。shared/openapi.yaml 由 architect agent 独占维护，业务仓 agent 只读 + 同步拉取。这是为数不多必须”中心化”的设计——分散写一定会出三仓字段对不上的问题。

4. 状态机不要交给主控维护，要切片分给每个负责执行的 skill。tasks.yaml 里只允许 4 个状态枚举（PROPOSED / IN_PROGRESS / REVIEWED / MERGED），状态注释写在 yaml 顶部；每个 slash command 的 prompt 内嵌 Python 脚本做”原子的状态推进”。派生状态（ready / blocked）必须脚本入口现算，不要人手维护。

5. 任何”看着 exit 0″的脚本步骤都要加正向校验。 ancestor / build / test / 业务码 grep，缺一不可。脚本 fallback 短期友好、长期反模式——删 fallback 让 strict 路径生效。”Phantom merge guard”不是 nice-to-have，是脚本链条超过 5 步时的必填项。

6. CLAUDE.md 不是文档，是法律。 凡是踩过两次以上的坑、凡是 AI 容易猜错的目录约定、凡是涉及跨仓边界的硬规则——都要写进 CLAUDE.md，而且要写得像法条一样可执行（”做什么 → 在哪做 → 用什么命令”）。CLAUDE.md 是稳态规则；SESSION_INTERRUPT_*.md 是动态状态——两者分工明确，不要混。

十、这套脚手架不是模板，是要贴着企业实际搭的

最后说点不太中听的。

这套 harness 之所以能在我们这个项目跑起来，是因为它贴着我们的实际：

• 3 仓不同的技术栈（Express + 小程序 + AngularJS）→ 决定 SoT 必须独立仓
• 跨仓改动 < 5% → 决定走 3 仓独立而非 monorepo
• 团队职责边界要清晰 → 决定 architect 独占契约
• 业务仓 release 节奏独立 → 决定跨仓 release 必须有 gate

直接抄模板到你企业里，大概率跑不起来。每个企业的遗留系统长得不一样：

• 你的仓可能是 5 个、10 个，技术栈可能是 Java + Go + Python + Vue 的组合
• 你的 CI 可能是 GitLab 不是 GitHub Actions
• 你的跨仓 release 节奏可能比我们的更松散
• 你的 reviewer agent 可能不需要我这种 1:1 per-task stub 的硬约束

但 harness engineering 的核心思想是不变的：

• 把”AI 写代码”这件事工程化对待，套上状态机、目录约定、脚本校验
• 让传统软件工程的所有纪律（需求 → 设计 → 编码 → 审查 → 测试 → 发布 → 监控）一个都没丢，只是执行主体变了
• 把”状态外部化到脚本”，因为 Agent 没有持久记忆，每次会话起来都从零开始
• 把”规则”从 CLAUDE.md 升级到”代码强制”，否则就是空话

十一、如果你想搭一套自己的 Harness Engineering 脚手架

我们提供 企业级 AI 编码转型咨询顾问服务，覆盖：

• 现状评估：你企业的遗留系统 + 团队结构 + 现有 CI/CD 适配 AI 编码的程度
• 脚手架定制：基于你的多仓结构、技术栈、release 节奏，定制 harness engineering 脚手架（不是套模板）
• Pilot 落地：选 1-2 个 feature 做端到端验证，把流程跑通
• 团队赋能：把你团队的研发骨干培训成”AI 工程的脚手架搭建者”，而不是”AI 操作的执行者”

我们已经在 4 仓异构技术栈上把 13 份 spec、20+ 个 subagent、3 仓并发 merge 的完整流程跑通，这周又迭代了一轮 P0-P2 hardening。

如果你正在评估”AI 编码能不能用在我们这种企业遗留系统上”，欢迎把这篇文章转发给你的同事、架构师、技术总监——它就是我们能力的真实证明。

联系方式：jackyshen@uperform.cn 

项目实践：基于真实生产系统的 4 仓异构技术栈 AI 编码工程

💬 讨论

如果让你给自己企业的遗留系统搭一套 AI 编码脚手架，你会先做哪一步——先写 spec，还是先把跨仓契约的反推做对？

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

驾驭工程（Harness Engineering）先行者

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

起点：1 个 monorepo 仓的 OpenSpec × Claude Code 模板。 终点：4 个独立 git 仓 + swarm-orchestrator 编排 + 跨仓 symlink 桥。 触发原因：WeChat 小程序 / Express.js 后端 / Angular.js 管理员网站，三个工程上是 3 个独立的遗留 repo，monorepo 装不下，也不可能合并到一起。

TL;DR（30 秒版）

如果你只有 30 秒，看这一段就够了。

一、仓数变了。从 1 个装一切的 monorepo，拆成 4 个独立 git 仓：orchestrator + mp + backend + admin。

二、编排层搬出来了。OpenSpec 的 Source of Truth（.openspec/、.claude/、CLAUDE.md、registry）从业务仓里抽出来，变成了第 4 个仓，叫 swarm-orchestrator。这个仓不写任何业务代码，只做编排。

三、跨仓契约的落地方式换了。monorepo 时代直接在仓内的 openapi/types/config 里改。现在这些共享契约放在 orchestrator 的 .openspec/shared/ 下，业务仓通过 sync 脚本拉只读副本，architect 是唯一能写的人。

四、handoff 和 reviews 的物理路径变了。以前在 monorepo 仓内，现在永远在 orchestrator。业务仓里没有 .openspec/ 目录，靠 symlink 桥接。

五、merge 行为从 1 次变成 3 次。还要按 backend → mp → admin 顺序 release，因为 backend API 没部署之前，前端调不到新接口。

六、tasks.yaml 多了一个必填字段：app_repo，可选 4 个值：mp-app / backend / admin / swarm-orchestrator。4 个 shell 脚本都靠这个字段路由。

七、worktree 位置也变了。从 project/wt-/（都在 monorepo 仓内），变成各自业务仓的 wt-/。

结论：3 仓独立版适合”仓内任务清晰、跨仓改动少”的场景。跨仓改动超过 30% 仍然选 monorepo。

1. 起点：单仓 monorepo 工程目录长啥样

先看初始版本的目录结构。

根目录是 ~/work/openspec_claudecode_monorepo/。下面是 project/ 这个单一 git 仓：

project/.openspec/ 下分 specs/、plans/、tasks/、handoff/、reviews/、registry/、prompts/、templates/、swarm/ 这几个子目录。

project/.claude/commands/ 下有 4 个 slash command。

project/ 下面直接挂 backend/、frontend/、tests/、docs/ 这些业务目录，全在一个仓里。

还有一份 CLAUDE.md 当作项目宪法。

这个模板的工作流是：5 个 Subagent 跑在 project/wt-*/ 5 个 worktree 里（worktree 都在 monorepo 仓内），分别改 backend/、frontend/、tests/、docs/ 各自的目录。

架构干净，工作流也跑通。这个模板我用了一段时间，没问题。

直到我接了一个真实项目。

2. 痛点：真实项目是 3 仓，硬塞 monorepo 反而别扭

接的活是三个独立的技术栈：

• WeChat 小程序：用微信开发者工具打开，目录是 app.json + pages/ + utils/
• Express.js 后端：独立 Node 项目，src/routes/ + src/models/
• Angular.js 管理员网站：独立 Angular 项目，ng new 出来的，src/app/ + angular.json/

这 3 个本来就是 3 个独立 git 仓库：

• 各自的 main 分支、release tag、CI pipeline
• 各自的部署节奏：后端上线 ≠ 小程序发版 ≠ admin 发版
• 各自的开发团队：小程序组 / 后端组 / 前端组
• 各自的依赖管理：mp 用微信工具链，backend 用 npm，admin 用 ng

但为了用 OpenSpec 模板，我把它们塞进了 1 个 monorepo。具体做法是 frontend/ 放 mp+admin，backend/ 放 Express。

改起来才发现一堆问题：

🔴 部署粒度错位：monorepo 一次 release，3 端一起发版。本来后端先上线、前端第二天跟，硬塞成同一天。

🔴 团队职责边界糊：后端组 PR 改了 frontend/utils/api.ts 没人审。reviewer 看到的是”全仓 diff”，没人聚焦到自己的领域。

🟡 Git 体积爆炸：3 仓的 node_modules 互相污染，.gitignore 难写。

🟡 worktree 互相打架：5 个 Subagent 在同一个仓里 git worktree add 5 个分支，目录互相看不到，路径还容易搞混。

🟡 跨仓”改一处三处 pull”：改 types/user.ts 要 mp/backend/admin 三边手动同步。

🟡 装不下微信工具链：project.config.json 是 mp 专属，放 monorepo 仓怪怪的。

最致命的是”团队职责边界糊”。AI 给我们做的 Review 应该是按仓切分的，不是看一个混合 diff。monorepo 把这件事搞反了。

一句话总结这个阶段的教训：monorepo 是为了”原子化跨仓改动”设计的模板，真实项目压根不需要这么频繁地跨仓改。我们需要的不是更紧的耦合，而是更清晰的边界。

3. 转折：把编排层从 monorepo 抽出来

意识到”3 仓各自独立”才是真实需求后，问题变成一个 meta-level 的问题：OpenSpec 的 Source of Truth 放在哪？

我列了 3 个方案：

方案 A：塞 mp-app 仓。 简单，但后端组 / admin 组改 OpenSpec 都要 PR 进 mp-app，跨仓权限尴尬，乱。

方案 B：新建第 4 仓 swarm-orchestrator/。 编排 = 独立仓 = 单一真相源。代价是多一个仓，但跟获得的清晰度比，值。

方案 C：散落各仓。 每个仓带一份 .openspec/。看似解耦，实际上失去 single source of truth，编排乱套。

选 B。

最终的目录结构是这样的：

~/work/
├── swarm-orchestrator/            ← 第 4 仓，源真相
│   ├── .openspec/                 规约、计划、任务、契约
│   ├── .claude/                   agent prompt + slash command
│   └── CLAUDE.md                  跨仓宪法
│
├── mp-app/                        ← 1 号业务仓
├── backend/                       ← 2 号业务仓
└── admin/                         ← 3 号业务仓

关键认知：Source of Truth 必须是独立仓。如果它寄生在某个业务仓里，那个业务仓就自动成了”主仓”，其他仓的”从属感”会让团队边界再次糊掉。

这条认知后来被我升级成了 SoT 设计的一条新规则：

凡是”X 仓和 Y 仓都要参考的东西”，就不该放在 X 仓或 Y 仓里。

CI/CD 的 release-coordinator.yml 也得独立。跨仓 schema registry 独立。跨仓 e2e 测试仓库独立。

4. 4 个核心改动

从 monorepo 版本到 3 仓独立版，4 个地方必须改。4 个改完就能跑，其他都是 nice-to-have。

4.1 tasks.yaml 加 app_repo 字段

<span class="hljs-bullet" style="line-height: 26px;">- <span class="hljs-attr" style="color: #d19a66; line-height: 26px;">id: <span class="hljs-string" style="color: #98c379; line-height: 26px;">AUTH-002
  <span class="hljs-attr" style="color: #d19a66; line-height: 26px;">owner: <span class="hljs-string" style="color: #98c379; line-height: 26px;">backend-agent
  <span class="hljs-attr" style="color: #d19a66; line-height: 26px;">app_repo: <span class="hljs-string" style="color: #98c379; line-height: 26px;">backend                <span class="hljs-comment" style="color: #5c6370; font-style: italic; line-height: 26px;"># ← 新字段，4 选 1
  <span class="hljs-attr" style="color: #d19a66; line-height: 26px;">worktree: <span class="hljs-string" style="color: #98c379; line-height: 26px;">../backend/wt-auth-002
  <span class="hljs-attr" style="color: #d19a66; line-height: 26px;">branch: <span class="hljs-string" style="color: #98c379; line-height: 26px;">feat/auth-002-api
  <span class="hljs-attr" style="color: #d19a66; line-height: 26px;">task_file: <span class="hljs-string" style="color: #98c379; line-height: 26px;">.openspec/tasks/AUTH/AUTH-002-api.md
  <span class="hljs-attr" style="color: #d19a66; line-height: 26px;">depends_on: [<span class="hljs-string" style="color: #98c379; line-height: 26px;">AUTH-001]

作用：4 个 shell 脚本都靠这个字段决定 cd 到哪个仓。脚本不用猜。

4.2 4 个 shell 脚本都按 app_repo 路由

create-worktrees.sh：以前全在 monorepo 仓内 git worktree add。现在读 app_repo，先 cd 进对应仓，再 git worktree add ../<业务仓>/wt-。

launch-agents.sh：以前默认在 monorepo/wt-/ 启动。现在 cd $app_repo/wt-/ 启动，注入绝对路径环境变量（HANDOFF_DIR / SHARED_DIR）。

collect-handoff.sh：以前巡查 monorepo 内的 handoff。现在永远读 swarm-orchestrator/.openspec/handoff/，不去 worktree 里找。

merge-all.sh：以前是 1 个 PR 进 monorepo main 收尾。现在按 app_repo 分组，每个 repo 独立 rebase + merge。

最大的差异在 merge 阶段。以前是 1 次进 main，现在变成 3 个仓各 merge 一次，还要按 backend → mp → admin 顺序 release。原因是 backend api 部署 OK 后 mp/admin 才能发版，否则前端会调不到新接口。

4.3 Handoff 路径：永远在 orchestrator

这是最容易踩坑的地方。

业务仓里没有 .openspec/（业务仓只关心自己的业务代码，OpenSpec 的目录跟它无关）。但 Subagent 写 handoff 的时候，直觉上会写到自己 worktree 里的 .openspec/handoff/… 这个路径在业务仓里根本不存在，要么落进业务仓的 main 分支（污染），要么报错。

我比较了两种处理方式：

方式 A：任务文件里给绝对路径。 在任务文件末尾写明”写 handoff 到 /abs/path/.openspec/handoff/…”。可行但每个任务都要手动写一遍。

方式 B：worktree 内 symlink。 在 create-worktrees.sh 里加一步 ln -s ../../swarm-orchestrator/.openspec $WT/.openspec。一次性给所有业务仓的 wt- 建好 symlink，Subagent 用相对路径写就自动落到 orchestrator 仓。Prompt 模板几乎不用改。

选 B。

<span class="hljs-comment" style="color: #5c6370; font-style: italic; line-height: 26px;"># create-worktrees.sh 末尾
<span class="hljs-keyword" style="color: #c678dd; line-height: 26px;">if [ <span class="hljs-variable" style="color: #e06c75; line-height: 26px;">$APP_REPO" != <span class="hljs-string" style="color: #98c379; line-height: 26px;">"swarm-orchestrator" ]; <span class="hljs-keyword" style="color: #c678dd; line-height: 26px;">then
  ln -s <span class="hljs-variable" style="color: #e06c75; line-height: 26px;">$ORCH_ROOT/.openspec" <span class="hljs-variable" style="color: #e06c75; line-height: 26px;">$ABS_WT/.openspec"
  echo <span class="hljs-variable" style="color: #e06c75; line-height: 26px;">$ABS_WT/.openspec → <span class="hljs-variable" style="color: #e06c75; line-height: 26px;">$ORCH_ROOT/.openspec"
<span class="hljs-keyword" style="color: #c678dd; line-height: 26px;">fi

效果是这样的：

backend/wt-auth-002/.openspec   →  ../../swarm-orchestrator/.openspec
mp-app/wt-auth-003/.openspec    →  ../../swarm-orchestrator/.openspec
admin/wt-auth-004/.openspec     →  ../../swarm-orchestrator/.openspec

Subagent 在 wt- 里写 .openspec/handoff/AUTH/AUTH-002-api.md，实际写到 orchestrator 仓。handoff/reviews 永远在 orchestrator 落地，不污染业务仓 main。

小细节：orchestrator 自己的 wt-（architect 任务、docs 任务）不走 symlink，因为 .openspec/ 本来就在仓里。

4.4 Architect 角色扩成”跨仓契约 owner”

Architect 这个角色在 monorepo 版只管 openapi/ + types/ 几个目录。3 仓版下，它是唯一能写跨仓契约的角色。

新加的”跨仓契约统一源”：

• swarm-orchestrator/.openspec/shared/openapi.yaml → architect only
• swarm-orchestrator/.openspec/shared/types.ts → architect only
• swarm-orchestrator/.openspec/shared/config.schema.json → architect only

业务仓需要这些文件时只能走 sync-shared.sh：

<span class="hljs-comment" style="color: #5c6370; font-style: italic; line-height: 26px;"># 业务仓里
cd backend && bash ../swarm-orchestrator/.openspec/swarm/sync-shared.sh
<span class="hljs-comment" style="color: #5c6370; font-style: italic; line-height: 26px;"># 或
cd admin && npm run sync:shared     <span class="hljs-comment" style="color: #5c6370; font-style: italic; line-height: 26px;"># admin 还会自动跑 openapi-typescript

这是 3 仓版本能 work 的核心机制。没有这层”单一真相源 + sync 拉取”，3 仓独立就退化成”3 份维护负担”。

5. 4 个配套改动

4 个核心改完，已经能跑通。但要让 5 个 Subagent 真的不踩坑，还要 4 个配套：

5.1 Agent prompt 顶部加 WORKTREE_BASE 提示

<span class="hljs-comment" style="color: #5c6370; font-style: italic; line-height: 26px;"># .claude/agents/backend-agent.md 顶部
APP_REPO=backend
WORKTREE_BASE=<span class="hljs-variable" style="color: #e06c75; line-height: 26px;">$PWD                          <span class="hljs-comment" style="color: #5c6370; font-style: italic; line-height: 26px;"># ../backend/wt-<task>/
ORCHESTRATOR_ROOT=<span class="hljs-variable" style="color: #e06c75; line-height: 26px;">$WORKTREE_BASE/../..      <span class="hljs-comment" style="color: #5c6370; font-style: italic; line-height: 26px;"># swarm-orchestrator/
HANDOFF_DIR=<span class="hljs-variable" style="color: #e06c75; line-height: 26px;">$ORCHESTRATOR_ROOT/.openspec/handoff
REVIEW_DIR=<span class="hljs-variable" style="color: #e06c75; line-height: 26px;">$ORCHESTRATOR_ROOT/.openspec/reviews
SHARED_DIR=<span class="hljs-variable" style="color: #e06c75; line-height: 26px;">$ORCHESTRATOR_ROOT/.openspec/shared

launch-agents.sh 已经在 spawn Subagent 时 env 注入了这些变量，但 prompt 里写明让 agent 自己也知道，不会去 env | grep 查。

5.2 4 个仓的 .gitignore 各自维护

• orchestrator：极简，不忽略业务代码（业务代码压根不在这里）
• mp-app / backend / admin：各自的 types/ 全部 gitignored（同步副本不 commit）
• 业务仓统一 wt-*/ gitignore（worktree 不入仓）

5.3 CI/CD：每个业务仓独立 pipeline + 1 个 release coordinator

• 3 个业务仓各自跑 CI（mp 用微信工具链，backend 用 npm test，admin 用 ng test）
• orchestrator 加一个 release-coordinator.yml：watch 3 仓的 release tag，按 backend → mp → admin 顺序触发部署

这一步可选。如果业务仓 release 节奏本来就是人工协调的，可以先不做。脚本里 merge-all.sh 也带了”backend 段结束后停一下”的 gate，让主控人工 confirm deploy。

5.4 README “Where to run claude” 表变成 4 行

写需求 / 拆 plan  →  swarm-orchestrator/  →  claude → /spec /plan /swarm /review /merge
改业务代码 (直跑)  →  <业务仓>/  →  cd <业务仓> && claude

主控在 orchestrator，3 个业务仓是 Subagent 的工作区。不要在业务仓直接 claude 跑主控命令（虽然技术上能跑，但 /swarm 这类命令会找不到 registry）。

6. worktree 实际位置（最容易晕的地方）

跑完 /swarm AUTH 后，5 个 worktree 不在同一个地方。它们分别落在 4 个仓里：

~/work/openspec_claudecode_seperepo/
│
├── swarm-orchestrator/
│   ├── wt-auth-001-arch/         ← architect 任务（本仓内）
│   │    .openspec → ../../.openspec   (仓内 symlink)
│   │
│   └── wt-auth-005-doc/          ← docs-agent 任务（本仓内）
│
├── backend/
│   └── wt-auth-002/              ← backend-agent 任务（backend 仓内）
│        .openspec → ../../swarm-orchestrator/.openspec   ★ 跨仓 symlink
│        src/  tests/  types/
│
├── mp-app/
│   └── wt-auth-003/              ← mp-agent 任务（mp-app 仓内）
│        .openspec → ../../swarm-orchestrator/.openspec   ★ 跨仓 symlink
│        pages/  utils/  types/
│
└── admin/
    └── wt-auth-004/              ← admin-agent 任务（admin 仓内）
         .openspec → ../../swarm-orchestrator/.openspec   ★ 跨仓 symlink
         src/app/  types/

5 个 worktree 分别在 4 个仓里（orchestrator 自己有 2 个：architect + docs-agent；其他 3 仓各 1 个）。互不打架。

FAQ：为什么仓本体不放进 main/ 子目录和 wt- 平级？

不要。git init 创出来的 repo 默认根目录就是 main checkout，CI、IDE、部署脚本全假设这个。挪到 main/ 子目录是重发明一个本来就有的轮子。

7. 什么时候该 monorepo，什么时候该 3 仓独立

今天最大的收获是画清楚这个判定线。

改 1 处契约要 3 端联动：✅ 选 monorepo（1 个 PR 改完）；❌ 3 仓独立要做 orchestrator + 3 仓 sync + 3 次 PR。

3 端都是同一个团队，节奏一致：✅ monorepo 更顺手；⚠️ 3 仓独立嫌麻烦。

3 端不同团队，独立 release 节奏：❌ monorepo 一发全发；✅ 3 仓独立各自节奏。

团队职责边界要清晰：⚠️ monorepo 看 PR 评审；✅ 3 仓独立仓级 reviewer。

Agent Swarm 编排：monorepo 简单（1 仓）；3 仓独立复杂（4 仓）。

跨仓 refactor：✅ monorepo 1 个 PR；❌ 3 仓独立几乎做不了。

适合 Agent Swarm 的 task 切分：monorepo 任意；3 仓独立仓内任务清晰、跨仓改动少。

判定公式：

• 跨仓改动 > 30% → monorepo
• 跨仓改动 < 10% → 3 仓独立
• 10% ~ 30% → 看你团队结构

我们今天这个项目（mp + backend + admin，3 端完全是不同技术栈、不同团队、不同 release 节奏）属于”跨仓改动 < 5%”，3 仓独立赢麻了。

8. 一个新认知：Source of Truth 不能寄生

今天还有个隐性收获：Source of Truth（SoT）必须独立存在，不能寄生。

monorepo 时代，SoT 就是 monorepo 自己。但 3 仓独立的时候，”OpenSpec 放哪”这个问题是个 meta-level 的 SoT 问题：

• 寄生在 mp-app → 后端组 / admin 组改 OpenSpec 要 PR 进 mp-app，跨仓权限尴尬
• 寄生在 backend → 类似问题，反过来
• 寄生在任意一个业务仓 → 该仓自动变成”主仓”，其他仓的”从属感”再次让边界糊掉
• 独立成第 4 仓 → 编排 = 独立仓，所有业务仓都是平级

• CI/CD 的 release-coordinator.yml 也得独立
• 跨仓 schema registry 独立
• 跨仓 e2e 测试仓库独立

凡是”X 仓和 Y 仓都要参考的东西”，就不该放在 X 仓或 Y 仓里。这是我对 SoT 设计的一条新规则。

9. 验证：现在 seperepo 跑得通吗

我跑了一遍 sanity check。

5 个脚本全部通过 bash 3.2 语法检查（macOS 默认 bash）：

$ for f in .openspec/swarm/*.sh; do bash -n "$f" && echo "✓ $f"; done
✓ .openspec/swarm/collect-handoff.sh
✓ .openspec/swarm/create-worktrees.sh
✓ .openspec/swarm/launch-agents.sh
✓ .openspec/swarm/merge-all.sh
✓ .openspec/swarm/sync-shared.sh

5 个 task 全部带 app_repo，4 选 1 合法：

$ python3 parse tasks.yaml
  AUTH-001    app_repo=swarm-orchestrator      owner=architect
  AUTH-002    app_repo=backend                 owner=backend-agent
  AUTH-003    app_repo=mp-app                  owner=miniprogram-agent
  AUTH-004    app_repo=admin                   owner=admin-agent
  AUTH-005    app_repo=swarm-orchestrator      owner=docs-agent

未跑的部分（要等业务仓 git init 后才能真跑）：

• create-worktrees.sh 实际创建 5 个 worktree
• launch-agents.sh 实际启 5 个 Subagent
• merge-all.sh 实际 merge 3 个仓的 main

但脚本逻辑都验证过了，跑起来应该没坑。

10. 留给以后的自己

3 条带走：

1. monorepo 不是银弹。当”跨仓改动 < 10%”，3 仓独立 + 1 个 SoT 仓 = 更清晰。判定公式见 §7。SoT 必须独立成仓，不能寄生。否则业务仓边界再次糊掉。这是 SoT 设计的一条新规则。
2. worktree 跟着业务仓走，别堆在 SoT 仓里。handoff 路径永远在 SoT 仓，业务仓用 symlink 桥接。
3. app_repo 的设计，使得 Registry 会慢慢长成：Jira Issue + GitHub Project + Agent Runtime。

3 条防踩：

1. 改业务代码路径：”<业务仓>/wt-/ 里改”（不是 SoT 仓的 wt-）
2. 改契约路径：”SoT 仓的 .openspec/shared/，然后业务仓 npm run sync:shared”
3. merge 顺序：”backend → 等 deploy OK → mp → admin”

1 个下次要先问的问题：

接新项目时，先问”3 端是不是独立 release 节奏”。是 → 3 仓独立；否 → monorepo。别急着抄模板。今天的最大教训是：模板不是越多越好，是贴合实际场景的才好。

11. 下一阶段：从跨仓编排到 Agent Platform

这次从 monorepo 演进到 3 仓独立版，本质上解决的是：代码仓如何解耦。

但在搭建过程中，也逐渐看到了下一阶段可能出现的新问题。

今天的架构已经足够支撑：1 个项目 + 5 个 Subagent + 4 个 Git 仓。

但如果未来变成：多个项目 + 20~50 个 Agent + 更多跨仓协作，有些设计可能会继续演进。

11.1 Runtime State 可能从文件演进成状态系统

当前版本 .openspec/ 下的 handoff/、reviews/、registry/ 全部以文件形式存在。

这在 5 个 Agent 规模下非常简单且透明。

但未来如果出现 20+ Agent 同时更新 tasks.yaml + handoff/reviews/，可能会开始出现状态冲突。

因此未来有一种可能：把 handoff、reviews、status 统一视为 Runtime State，从文件演进到 Runtime State，再往后甚至演进为 SQLite / Redis 轻量状态服务，统一管理 Agent 生命周期。

这并不意味着文件方案不好。相反，文件 → Runtime State → Agent State Service 是一条非常自然的演进路径。当前阶段文件依然是最简单、最透明、最容易调试的方案。

11.2 Architect 可能拆分为 Contract Agent

当前版本中 Architect 同时负责：架构设计、OpenAPI、共享 Types、共享 Config。因此 .openspec/shared/ 实际上由 Architect 统一维护。

这种方式非常适合项目初期。但随着 Feature 数量增加到 10+、20+、30+，Architect 可能逐渐成为跨仓协作的瓶颈。

未来一种可能的演进方向：把 Architect 拆分成两个角色——Architect 负责系统设计，Contract Agent 负责共享契约。共享契约治理将成为独立能力。

11.3 SoT 仓可能继续演进为 AI PMO

当前 swarm-orchestrator 保存：Spec、Plan、Task、Review、Workflow。虽然它仍然是 Git 仓库，但从职责来看，它已经越来越接近项目管理系统，而不是传统代码仓库。

从这个角度看，swarm-orchestrator 其实已经承担了 Architecture Repository、Task Registry、Agent Registry、Workflow Engine 的角色。

未来它可能进一步演化成 AI PMO（Project Management Office），成为整个 Agent Swarm 的控制中心。

11.4 从项目级 Orchestrator 到组织级 Control Tower

当前架构：backend、mp-app、admin 三个业务仓被一个 swarm-orchestrator 管。对于单项目非常合适。

但如果未来同时管理 Project-A、Project-B、Project-C，就会出现新的问题：Prompt、Agent、Workflow、Skill 开始在多个项目之间重复。

因此未来可能出现更高一层：Workspace 下面挂多个 Project，每个 Project 有自己的 swarm-orchestrator，最顶层有一个 AI-Control-Tower。

AI-Control-Tower 统一管理 Agent Registry、Prompt Registry、Skill Registry、Workflow Registry。而项目级 orchestrator 只负责 Spec、Plan、Task。

这种结构与企业中的 Team → Program → Portfolio 层级非常相似。

11.5 Agent Engineering 的真正问题

这次演进还有一个重要体会。

最开始以为问题是：如何让 Claude 写代码。

后来发现问题变成：如何让多个 Claude 协同写代码。

再往后发现：如何让多个 Agent 在真实组织结构中协同工作。

这已经不再是代码生成问题，而是：组织结构、仓库结构、Agent 结构三者如何保持一致的问题。

从这个角度看，OpenSpec、Claude Code、Worktree、Subagent 都只是工具。真正的挑战始终是：如何建立一个能够持续演化的 Agent Operating System。

而这次从 monorepo 到 3 仓独立版，只是这条演进路线上的第一步。

附：项目地址速查

monorepo 模板：~/work/openspec_claudecode_monorepo/project/ 历史（保留作对比）

3 仓独立样例：~/work/openspec_claudecode_seperepo/ 当前主用

顶层 README：openspec_claudecode_seperepo/README.md 操作步骤 + worktree 位置

跨仓宪法：openspec_claudecode_seperepo/swarm-orchestrator/CLAUDE.md “where to run claude” 表

跨仓脚本：openspec_claudecode_seperepo/swarm-orchestrator/.openspec/swarm/*.sh 4 + 1 = 5 个

5 个 agent prompt：openspec_claudecode_seperepo/swarm-orchestrator/.claude/agents/*.md 顶部都带 WORKTREE_BASE 提示

6 个 slash command：openspec_claudecode_seperepo/swarm-orchestrator/.claude/commands/*.md /spec /plan /swarm /review /merge /status

日期：2026-06-06 状态：seperepo 骨架完成，脚本验证通过，等真实业务仓 git init 后跑通端到端

💬 讨论

你最近一次”架构推翻重来”是因为什么原因？是项目规模变了，团队变了，还是部署节奏变了？

如果接新项目，你会先问”3 端是不是独立 release 节奏”吗？

欢迎在评论区聊聊你的踩坑经历 👇

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

驾驭工程（Harness Engineering）先行者

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

前两天刷到一条帖子，看完我坐在椅子上愣了三分钟。

帖子很朴素，列了 7 条”程序员变成自己最讨厌的那种 team leader”的标准症状。我一条一条读，越读越不对劲——

不是因为陌生。

是因为每一条都像在照镜子。

我们这代程序员，从入行第一天起就被各种”领导力糟粕”耳濡目染过：

• “那个 leader 半年不写代码，凭什么指手画脚？”
• “PRD 写得稀烂还天天催进度，出了问题就甩锅”
• “PR 看都不看就 Approve，连 diff 都懒得滚一下”
• “新人被他骂哭三次了，他自己连 git rebase 都不会”

我们曾经在工位上、午饭时、复盘会后，立下过多少铮铮誓言：

“我以后要是当了 manager，绝不这样。”

然后呢？

2023 年，ChatGPT 来了。 2024 年，Cursor 来了。 2025 年，Claude Code 来了。 2026 年，连 PRD 都不用人写了。

我们没有等到当 manager 的那天——AI 直接替我们提前完成了转型。

那条帖子总结得精辟，我把它转写一遍，并附上一点”我亲眼见过 / 我自己干过”的注解。

如果你读着读着也像我一样”坐立不安”——恭喜你，这篇不是写给 manager 的，是写给你的。

二、7 张”AI 时代病”的精准 CT

① 半年不写一行代码，编程能力严重退化，还自诩”我也是搞技术的”

“搞技术的”——这四个字现在基本等于”搞过技术的”。

打开你最近一个月的 git log，git log –author=”你自己”，是不是有几次作者名出现次数 < 5？再看看 commit message，是不是清一色的”wip”、”fix”、”feat: 优化一下”？

上周我让一个三年经验的后端同事，徒手写一个 LRU Cache。 他憋了 15 分钟，最后说：

“我让 Claude 写一个吧，半分钟。”

我问他：”你还能闭着眼睛写出单例模式吗？” 他沉默了三秒，说：”我可以让 AI 给我写出 5 种实现，挑一个。”

这不叫”搞技术的”，这叫”搞 AI 技术的”。

更扎心的是——我问他 LRU 的 Get 时间复杂度，他想了想说”应该是 O(n) 吧”。 错了。是 O(1)。 然后他用 AI 验证了一下，确认”哦，对的，O(1) 哈希 + 双向链表”。

我们这一代，正在变成”AI 的肉喇叭”——AI 说什么，我们就转述什么。

② 开会的时候把一线开发干的活全说成是自己的，连自己的汇报材料都是让别人总结的

这个病最隐蔽，而且是 AI 时代独有的。

以前老板要 PUA 你好歹还得先认识你，现在：

• 周一 Scrum站立会，你负责的部分是 ChatGPT 帮你写的；
• 周三技术分享会，你的方案是 Claude 帮你 review 的；
• 月底部门 OKR review，你的 PPT 是让实习生帮你排的版；
• 季度战略会，你”展示”的那套架构是下属设计的，你连”为什么用 Postgres 不用 MySQL”都答不上来。

最有意思的是——你还自我感觉良好。

因为在 AI 帮你写的报告里，你是一个”技术深度扎实、推动力强、沟通高效”的工程师。 在 AI 帮你润色的述职里，你是一个”具有系统思维、能带兵打仗”的技术 leader。 你照着念，念得还挺像那么回事。

直到有一天，老板现场追问一个细节。

空气突然安静。

你脸上的表情，被全组 17 个人看得清清楚楚。

“AI 帮我们写 PPT 的时候，从来不会提醒我们：这个人其实没参与过这个项目。”

③ 瞎 JB 指挥，出了问题就甩锅说是下面没执行好

这一条，是 AI 给所有人的”权力幻觉”。

AI 让一个人看起来像一个 leader。 它不让他真正成为一个 leader。

所以你就出现这种症状：

• 需求没想清楚就催进度：”我让 AI 评估过，这个两周能做完。”
• 方案评审时只会说”AI 建议这么做”——AI 是你的 leader，你是 AI 的传话筒。
• 出了线上事故，凌晨 3 点的复盘邮件第一句是”经过排查，根因是 SRE 同学未按预案执行”。
• 老板问”这个架构你当时 review 过吗”，你立刻甩锅”我 prompt 写得可能不够细，回头我优化一下 prompt 模板”。

最经典的甩锅话术已经进化到 2.0 版本了：

1.0 版：”他执行不到位。” 2.0 版：”我 prompt 写得不够精确。”

1.0 甩的是下属，2.0 甩的是 AI。 本质上，都是甩的别人。

④ 不了解项目具体情况，只会提”单测加了没”、”性能还要优化”、”文档要沉淀一下”这类空洞的要求

这条我太熟了。AI 时代最伟大的一项发明，不是 Transformer，是”一键三连金句”：

“单测、性能、文档。

“任何 review 会上，你只要把这三件套甩出来，永远不会错：

• 加了单测 = 你重视质量
• 性能要优化 = 你关注用户体验
• 文档要沉淀 = 你在乎团队成长

至于具体加哪些单测、哪个接口要优化到多少 QPS、文档要沉淀到哪个 wiki 路径——

这是细节。细节是要命的。细节不是 leader 该关心的。

哦对了，这种话术还特别防 PUA。 因为下属如果反驳，他会显得”格局不够”。 如果照做，你可以随时补一句”我是从方向上把关的，你执行的时候要带脑子”。

AI 时代最讽刺的是：这三件套连 AI 自己都听得耳朵起茧。

你问它”我的代码有什么问题？” 它说：”建议加单元测试覆盖边界条件、性能可进一步优化、文档需补充示例。”

你问它”项目该怎么管理？” 它说：”建议完善单测体系、建立性能基线、沉淀团队知识库。”

我们用 AI 写出来的废话，又喂回 AI 让它自己消化。

⑤ PR 基本上看不懂，只会让别人先 review 了自己跟着点赞

这条最黑色幽默。

以前 PR review 是程序员的基本尊严——你至少要证明”我看过这段代码，我才点 Approve”。

现在？

PR review 已经是 AI 的事了。

同事 A 把 Cursor 生成的代码 commit 上来了； 同事 B 让 Claude review，给了 12 条建议； 同事 C 让 GPT 提了 8 条改进； 团队 leader 点 Approve，留言：”👍 看着没问题，辛苦！”

leader 那条留言的意义是什么？是告诉老板”我也参与了”，是 KPI 上的”团队 review 参与度 100%”，是周报里”持续推动 code review 文化”的素材。

更黑色幽默的是——

这段代码的 review，是 AI 写的； 你点 Approve 的依据，是”别人都 Approve 了所以我也 Approve 了”； 这段代码的作者，是 AI； 这段代码的 Reviewer，也是 AI。

这中间那个”leader”，是干嘛的？

是来给 AI 之间的对话，加一个 “+1” 表情的。

⑥ 遇到 bug 了只知道无脑转发让别人查一下，自己负责来来回回转发消息

这条是当代职场最大的表演艺术——bug 转发学。

9:00 客户发截图：这里报错了。 9:02 你把截图转给后端 A：@A 麻烦看一下。 9:05 后端 A 问你：是测试环境还是线上？ 9:06 你把客户原话复制给后端 A：他说”线上”。 9:08 后端 A 说：线上哪个账号？ 9:10 你把客户截图再转一次：他要账号吗？你给他一下。 9:15 客户回了一个 UUID。 9:16 你把 UUID 转给后端 A：客户说用这个账号复现的。 9:30 后端 A：找到原因了，是 X 服务在 Y 场景下的 Z 问题。 9:31 你把后端 A 的话转给客户：已经定位到问题了，开发同学正在修复。 9:45 修好了。 9:46 你把”修好了”转给老板：客户反馈的问题已修复。

全程 0 行代码。0 次 debug。0 个判断。唯一产出是 12 条转发消息。这是 AI 时代最完美的岗位描述：消息中间件 (Message Middleware)。

更绝的是——你还会用 AI 让自己的转发显得更专业：

让 ChatGPT 把后端 A 的话润色成”经过技术团队的快速响应和深度排查，已经定位到根因并完成修复”。

你把别人的话，喂给 AI 加工一遍，再发出去——你的核心能力就完整闭环了。

⑦ 还经常吐槽”今年的应届生水平越来越不行了”

这条是”AI 病”最严重的并发症。

你自己写不出的代码，AI 写出来你签字。 你自己 review 不出的 PR，AI review 完你点赞。 你自己调不出的 bug，AI 帮你定位你转发。

然后你转身跟 HR 说：

“今年秋招这批简历，看不出潜力啊。算法题让 AI 一做都满分，聊聊工程能力就露馅。”

你有没有想过——你招的”工程能力”，可能还不如这届应届生？

• 应届生至少能徒手写个快排。
• 你连单例模式都得 AI 写。
• 应届生至少 debug 时还会用 print。
• 你 debug 只会用”截图转发”。
• 应届生至少知道”git rebase”是什么。
• 你 rebase 出冲突了，直接 revert 然后让 AI 重新生成一份。

最讽刺的是，你一边用 AI 把自己的活干完，一边骂”应届生被 AI 惯坏了”——请问，你是被谁惯坏的？

这一条没有 AI 治得了。因为这不是技术问题，是病。

三、AI 没让我们变强，让我们变懒

写到这里，我得停下来。

因为这篇文章的讽刺如果只停留在”骂人”，那我也成了那种只会写”程序员堕落”爽文的烂账号。

我想真正戳一下自己——

为什么我们会集体滑向这种状态？

不是 AI 让我们变强，是 AI 让我们可以”看起来很强”地变懒。

• 写代码难，但你让 AI 写 → 容易。
• 理解架构难，但你让 AI 解释 → 听起来容易。
• 解决问题难，但你让 AI 诊断 → 像是容易。
• 团队协作难，但你让 AI 写话术 → 显得容易。

这 4 个”容易”，合起来就是 1 个——

“逃避真难的”容易”。

而那些”真难”的部分——

• 真正理解业务；
• 真正打过一场生产事故；
• 真正和一个难缠的客户聊一下午需求；
• 真正在 deadline 前熬 36 小时交付过；
• 真正为一个技术决策承担过后果——

AI 帮不了你。

AI 只能帮你”看起来像做过”。

但”看起来像”和”真的做过”，是两件事。前者让你 KPI 好看，后者让你半夜睡得着。

四、最后问一个得罪人的问题

你看完了。

笑完了。

转发了。

然后呢？

明天上班，你是准备继续让 AI 帮你写代码、自己继续转发 bug、自己继续 +1 别人的 PR——

还是打开 IDE，从一行真正的代码开始，重新做回一个”搞技术的”？

我选了后者。 你呢？

💬 今日互动话题： 

上面 7 条里，你中了几条？

A. 0 条（请受我一拜） 

B. 1-2 条（人之常情） 

C. 3-4 条（开始警觉了） 

D. 5-6 条（要不咱俩抱头痛哭一下） 

E. 7 条全中（兄弟，你就是那个 leader 本 lead）

评论区等你🐶

关于作者

申导（Jacky），一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

如果这篇文章对你有帮助,点个在看,让更多人看到AI时代真正的工作方式。

你上一次听到有人认真说”我们用的是敏捷”是什么时候？

开个站会，贴几张 Jira 卡，喊一声 Sprint，然后 deadline 一到全部乱套——这大概是大多数人对”敏捷”的真实记忆。

然而就在 2026 年纽约 ProductCon 的舞台上，Anthropic Claude Code & Cowork 的设计主管 Meaghan Choi 坐下来，用 40 分钟告诉你：

那个从 12 个人的内部工具，长到年营收 25 亿美金、拿下编程工具 51% 市场份额的产品，走的就是最正统的敏捷路子。

没有什么秘法，就是【构建 → 测量 → 学习】的循环。

第一章：故事从一个粗糙的原型开始

2024 年，AI 编程工具的主流范式是这样的：

把代码复制进聊天窗口，等回答，再复制回编辑器。少数人在用自动补全，仅此而已。

然后，一位 Anthropic 的工程师做了一个大胆实验：让 Claude 直接在你的电脑上执行操作，而不是给建议。

他用 CLI 做了个原型，给 Claude 开放了本地文件系统权限，录了一段演示视频，发到内部 Slack。

Meaghan 看到的那一刻，只有一个念头：

“Holy crap, this is it.”

但这个原型跑起来要将近一小时，体验粗糙，模型能力也没跟上。用她的话说——“至少提前了 6 个月。”

很多团队在这里会做什么？可能急着找时间表，可能开始写 PRD，可能先做竞品分析。

Anthropic 的团队做的事情是：在公司内部推广，让尽可能多的人用起来。

接下来 3 个月，他们跟着用户走，看别人怎么用，现场修 bug。

💡敏捷视角： 这就是最标准的 Sprint 0——不求对外发布，只求内部验证。”先让我们自己信，再让用户信。”

第二章：发布标准只有一条——真实采纳，不是功能完成

Claude Code 的发布流程非常清晰，分三步：

① 敏捷小队内部的人觉得够好、愿意用

② 推给公司其他团队

③ 追踪内部日活用户数，看到真实采纳增长，才考虑对外发布

注意——不是”功能做完了就发”，而是“有人真的在用了才发”。

这两者的差距，Meaghan 形容为建立 conviction（信念）：

“你对产品的信心，来自亲手用过、看到别人也在用。”

有多少团队的发布节点，是”需求评审通过了”？

有多少团队验收标准，是”测试用例全部通过”？

Claude Code 的验收标准是：自己用了、同事用了、停不下来了。

这套”先内后外”的机制，贯穿 Claude Code 至今。

第三章：头衔是你的专长标签，不是你的边界

Anthropic 怎么组队？

Meaghan 用了一个词：fluid（流动的）。

“头衔只是你带给团队的专业背景标签，它不划定你能做什么。”

她本人是设计主管，日常往生产环境推代码。她的工程师会做设计决策。她不参与每一个功能的设计。

一个敏捷小队，可以是：

• 5 个工程师
• 4 个工程师 + 1 个设计师
• 2 个设计师 + 3 个工程师
• 2 个 PM + 3 个工程师

只要人在 3-5 人之间，只要所有人一起冲刺，把东西做到在代码里跑起来。

她还强调了一点，听起来刺耳，但很重要：

“任何人都应该能往生产环境发布。”

她承认作为设计师，起初很难接受没经过自己手的功能上线。但她也承认：这种不适感，是进入快速迭代模式的必要代价。

要让这个模式跑起来，后面要有安全网：好的代码评审流程、CI 自动化测试、完善的测试覆盖。安全网在后面撑着，前面才能放开让所有人跑。

💡 敏捷视角： 这是跨职能团队的最佳状态——不是”前端等后端等设计等 PM”的串行，而是所有人围着同一个目标并行。

第四章：质量关卡，从纸面移进了运行中的代码

这可能是 Meaghan 整场分享里最”颠覆常识”的一点。

传统流程的质量决策发生在哪里？

讨论阶段。 看 PRD、看设计稿、在 Figma 里确认方向，然后才动手开发。

Anthropic 把这个决策点往后推了一步——推到了可运行代码的阶段：

“你得自己用，在真实工作流里体验产品，这时候做出的质量判断才最接近用户的真实感受。”

她用了一个词：“a flip on the head”（翻了个个儿）。

这对设计师尤其是职业本能上的挑战——放手让没打磨到 100% 的东西上线，是很难受的事。

但她也说：

“快速迭代和带着不完美上线不是 AI 时代的发明——AR、VR、空间计算一路走过来都是这样。这是新兴技术开发的天然节奏。”

先做出来，再迭代质量——而不是在动手前把所有迭代做完。

这句话，Scrum 从第一天起就在讲。只是现在 Anthropic 用一款年营收 25 亿的产品，把它演示了出来。

第五章：开发者先用，带动整个企业买单

Claude Code 的企业扩张走的是 PLG（产品驱动增长） 路线：

1. 开发者在个人项目中使用，觉得好用
2. 在公司内部推动采纳
3. 企业工具团队被驱动去做定制化连接器
4. 内部数据库、基础设施被接通
5. 每个人效率提升更大 → 循环继续

更有意思的是：当工具延伸到非工程职能——财务团队用 Claude Code，设计师用 Claude Code——使用者不仅完成了工作，还在过程中学到了新技能。

Meaghan 管这叫：

“Multiply your ability to learn those skills as well.”

这和敏捷对”跨职能能力成长”的期待完全一致：团队因共同工作而互相渗透，每个人的能力边界在悄悄扩大。

第六章：Token 用量不代表 ROI

这是 Meaghan 给整个行业的一个警告。

如果一个人的 token 用量是零，应该引起关注。

但不要让团队比拼谁用的 token 最多——消耗大量 token 却什么都没做到，太容易了。

她拿了一个精准的类比：

以前工程团队用代码行数衡量工程师贡献，后来发现这不是最好的方式。AI 时代的 token 用量，处在类似的阶段。

那应该看什么指标？

采纳率、留存率、收入。

无论你用不用 AI，这些指标都成立。

行业不应该因为工具变了，就发明一套全新的衡量体系。敏捷从一开始就说：关注可工作的软件，关注客户满意度。AI 工具改变的是效率，不是这些原则的有效性。

💡 给管理者的提醒： 你的 KPI 体系不需要推倒重来。先问问：用了这些工具之后，留存率提升了吗？交付速度提升了吗？用户满意度呢？

第七章：每个 IC 都成了”迷你管理者”

这是 Meaghan 最后抛出的一颗炸弹：

“Everyone’s kind of managing a fleet of Claudes that are also working.”团队里每个人，现在都在管理一群 Claude 实例同时工作。

分配任务、检查产出、协调节奏——这像是所有人都沿着管理链往上挪了一格。

一线执行者变成了”迷你管理者”。而 Anthropic 所有带团队的管理者，都同时在一线构建产品——Meaghan 自己做设计、推代码。

她的逻辑是：只有亲身经历工作流程的变化，才能判断应该在什么工具和培训上投入。

这其实是 Scrum 对 Scrum Master 角色的期待——不是一个会议主持人，而是一个深度理解团队工作方式的人。

写在最后

如果用一句话总结 Meaghan Choi 的整场分享：

构建 → 测量 → 学习。先让小队内部的人信，再让用户信，最后让市场信。

Claude Code 从 12 人的副项目到 51% 市场份额，用的不是更重的流程，而是更快的反馈环。

头衔不设边界、质量关卡后移、Token 用量不替代用户指标——这些不是 Anthropic 独有的方法论，它们有一个共同的名字：

敏捷开发。

不是墙上贴的敏捷，不是会议室里说的敏捷。

是真正跑起来的那种。

💬 你觉得，你们团队现在最难做到的，是哪一条？

是”任何人都可以发布”，还是”先做出来再迭代质量”？

欢迎留言，我来和你聊聊。

本文基于 Meaghan Choi 在 2026 ProductCon 纽约大会的访谈整理

原始来源：ProductCon NY 2026 · Product School 官方访谈

本文作者：申健 Jacky Shen

关于作者

申导（Jacky），一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

如果这篇文章对你有帮助,点个在看,让更多人看到AI时代真正的工作方式。