本文内容整理自RSGSH26大会主会场「AI雪鸟会·圆桌论坛」
熊节：华东师范大学国际传播研究院全球南方中心主任全球南方学术论坛秘书长、AI雪鸟会发起人 、POMASA开源智能体作者
Bill Li（李国彪）：大中华区敏捷导师第一人、优普丰AI敏捷创新咨询创始人、《AI原住民宣言》作者
申健（申导）：AI-FDE陪跑顾问、Scrum Alliance CST/CTC、优普丰敏捷AI咨询机构全球合伙人、AI 驾驭工程专家、教育智能体创始人、腾讯云TVP、AI 雪鸟会发起人
庄表伟：天工开物开源基金会执行副秘书长、开源社理事、华为内源平台架构师、开源治理专家
杨建良：金大一诚人工智能董事长、南大数科联合董事长、新浪江苏创始人、南大南京校友会副会长

开场

（熊节）本次「AI雪鸟会·圆桌论坛」，既是老朋友相聚交流，也为大家结识行业新朋友提供契机。「AI雪鸟会」是我们去年在RSG大会上正式发起成立的，得到了申健、Bill等众多伙伴的大力支持，虽然目前规模不大，但极具生命力，持续催生了诸多优质想法与深度行业讨论。

去年我便提出，国内软件行业早已陷入产能过剩状态，叠加AI技术的全面冲击，势必会深刻改变软件从业者的职业发展路径与行业生态。

我将当下行业核心矛盾总结为：大众群体自主设计智能数字系统的迫切需求，与数字系统建设不平衡、不充分之间的矛盾。

过去一年，我持续观察并深耕解决这一行业核心问题，能够清晰感知到这一矛盾愈发凸显。

以往大量普通群体、小众行业，从未被传统软件行业服务覆盖，没有专属的信息化、智能化工具。而AI技术的普及，让每一个普通人、每一个小众领域都能拥有专属数字工具、智能系统，成为了全新的可能性。即便当下软件行业整体氛围略显低迷，但我始终对行业未来充满期待。

过去一年，我持续推进AI普惠落地工作，在全球南方多个国家开展智能体应用培训，累计赋能约一千人，教授大众智能体使用、开发与个性化工具制作方法。我们落地了多个真实普惠案例：西非加纳一家八十人的小型电视台，工作人员均无编程基础，却依托AI智能体技术，自主搭建了专属新闻评论系统，填补了行业信息化空白；巴西的普通农户，也在我们的指导下搭建了家庭及小型农业智能知识库。

在过去四十年的传统软件产业发展中，这类基层小众群体、微小行业始终被行业忽视，没有商业软件公司会为其定制开发系统。但AI技术彻底改变了这一局面，真正实现了技术普惠，让数字化、智能化能力下沉到每一个有需求的个体与细分领域。因此在本轮行业变革周期中，我们很有必要交流过去一年各自的所见、所感、所行，共同探讨行业变化与未来方向。

话题1：交流过去一年各自的所见、所感、所行，共同探讨行业变化与未来方向

（李国彪）我顺着熊节提到的大众AI需求与行业核心矛盾，结合身边真实的个人、家庭与年轻人成长案例，分享我的观察与思考。

我有一位从事金融行业的中学同学，此前是四大会计师事务所华南区核心合伙人，现已退居二线。她的女儿今年考入香港大学社会学专业，其成长与择业经历，充分体现了AI时代年轻人的思维变化与时代变迁。过去一年，AI工具深度融入了她们的家庭生活，成为母女沟通的重要纽带。每当母女产生矛盾、分歧与纠结时，女孩都会借助豆包等AI工具分析问题、梳理矛盾，随后与母亲共同对照AI的分析内容，理性沟通、化解分歧，AI切实承担起了家庭沟通教练的角色。

女孩选择社会学专业，同样受到了AI时代社会变革趋势的影响。当下AI与智能体持续解放生产力、创造充足物质基础，未来社会将逐步走向高保障形态。她数理基础相对薄弱，但擅长人文艺术领域，希望通过社会学研究，探索适配未来高保障社会的发展模式，为社会变迁、民生发展贡献力量，让下一代能够自由选择、自在生活。

除此之外，我还了解到一个典型案例，另一个知识分子家庭的年轻人，主动放弃大学求学路径，选择成为法式点心师。我在温哥华生活期间，见过不少这类手工糕点匠人，其作品兼具艺术价值与亲民价格，拥有稳定的受众群体。值得思考的是，这名年轻人的职业选择几乎不需要用到AI工具。这两个年轻人的差异化选择，真实展现了AI时代个体发展的多元可能性。

（申健）去年RSG大会上，我们便探讨过AI教育的落地应用。此前我针对雅思考生开发了作文批改网站，早期并非智能体形态，而是通过定制提示词、对接DeepSeek模型，实现雅思真题作文一分钟快速批改，替代高价、低效的线下培训班人工批改服务。

原本我认为产品体验与效果良好，但实际落地后发现，学生用户的真实需求并不稳定，很多学生阶段性放弃作文练习，产品使用率不及预期。这让我深刻反思，很多时候我们技术从业者认为的优质创新，本质上只是技术自嗨，并非用户真实刚需。

今年，我借鉴熊节的开源插件思路，将该工具优化迭代，适配DeepSeek与混元模型并全面开源，开放给所有有需求的用户自主使用。即便前期落地遇挫，我依然坚信AI在教育领域拥有巨大落地价值。目前课件、PPT制作等常规教学工作，已普遍依托AI完成，效率大幅提升。

我在生活中观察到一个极具感触的场景，一名五六岁的普通孩童，母亲并非IT行业从业者，孩子却能熟练使用手机与AI对话，自主编写提示词训练专属AI智能体，定制专属对话风格。孩子坦言，日常缺少家人陪伴，AI成为了自己的倾诉对象。

这正是AI平权、赛博共产主义的真实体现，是划时代的生产力变革。在数字时代，所有人实现了信息与工具使用的平权，即便不掌握专业搜索、编程、技术能力，也能依托AI完成各类工作、满足精神需求，技术门槛被彻底打破。

昨天一天的大会演讲，很多人热议AI的能力边界，反复强调人类不能丧失对AI的控制权，但大多只是口号式表达，并未给出具体落地方法。我从音乐领域得到全新启发：当下AI可以制作出完美无瑕疵的音乐作品，零失误、标准化，但人类创作的魅力恰恰在于随机性、不确定性与不完美。就像知名吉他手现场演出会出现失误，却造就了独一无二的现场氛围与感染力。人类的创造性、随机思辨性、个性化特质，是AI无法复刻的核心价值，也是人性独有的魅力。

（庄表伟）结合AI普惠赋能的行业趋势，我分享过去一年深耕罕见病群体的真实实践。我接触到一位新疆00后罕见病患者艾力，他八岁出现病症，十八岁确诊为面肩肱型肌营养不良症，该病暂无有效治疗药物，患者肌肉会持续萎缩退化。

在身体尚可行动的阶段，艾力主动加入罕见病公益组织，希望帮助更多同类患者，但传统公益模式仅能实现简单的情绪安抚，无法解决实际问题。后来他了解到我们深耕开源与AI领域，主动寻求帮助。让我格外意外的是，并非我们主动赋能，而是艾力自主通过AI工具沟通调试，打包生成了完整的静态网页原型，具备浏览、登录、注册等完整功能，比口头描述、手绘原型更直观、更落地。

基于他的原型，我联合昆山杜克大学学生共同完善迭代，将其打造为完整的公益网站，作为开源项目捐赠给公益基金会，切实为罕见病群体提供服务。在落地过程中我发现，AI赋能仍存在巨大盲区：绝大多数罕见病患者并不知晓自身需求可以通过AI解决，也没有渠道对接技术资源，长期被困在固定的弱势圈层中，无力改变现状。能够主动发声、主动寻求赋能的患者只是极少数。

基于此，我未来计划搭建跨界交流平台，联动罕见病患者群体、AI技术从业者、医疗从业者、创意设计人员、3D打印与智能硬件开发者，打破行业与圈层壁垒，碰撞全新的落地思路。AI赋能不应停留在口号层面，要真正触达那些从未被技术惠及的弱势群体。

（杨建良）我并非传统敏捷圈从业者，深耕互联网媒体、数字营销、人工智能应用落地领域。今年年初，在申导的帮助下，我落地了多项AI应用，同时赴北美考察当地AI咨询公司的落地模式，回国后与人民大学联合成立人工智能企业。结合一年的考察与实践，我分享几点行业思考。

过去一年行业最大的变化，并非AI大幅提升开发效率，而是软件的核心定义被彻底改写。传统软件是供人类操作使用的功能工具，而新时代的核心载体是智能体，能够自主承接任务、完成闭环。这一变革，彻底颠覆了传统敏捷赖以生存的底层假设，需求、产品、开发、交付、用户的核心关系都需要重新定义。

传统软件时代，我们聚焦功能设计、用户体验、版本迭代；智能体时代，核心则是意图理解、工具调用、自主决策、行动落地与结果负责。这一变革对传统敏捷体系带来三大核心影响。

• 第一，人机角色重构，AI从辅助工具升级为协作同事，传统敏捷聚焦人与人的协同管理，未来核心将转变为人机协同管理，单人可依托AI智能体集群，完成以往整个业务单元的工作。
• 第二，产品与服务边界模糊，传统软件依赖人工操作界面完成流程，未来仅需向AI明确目标，即可自主完成订票、住宿安排、内容总结等各类任务，回归了敏捷贴近真实生活的本源价值。
• 第三，行业从缺模型、缺技术，转变为缺真实落地场景与落地方法。

从北美考察归来后，我聚焦中小企业AI数字化改造落地。实际对接企业过程中我发现，AI落地远比理论设想复杂。例如我们为企业搭建全网销售线索收集体系，实现线索精准分发，企业随即提出进阶需求，希望AI能够完成初步客户洽谈，仅将高意向客户流转至销售团队。虽然企业预算有限、需求迭代存在诸多限制，但我始终坚持深耕这类落地场景，能够切实提升营销精准度与业务效率，具备真实落地价值。

话题2：聚焦未来（1-2年）的核心规划和落地愿景

（熊节）聆听完各位的一线实践故事，我感触颇深。所有案例都指向一个核心趋势：技术越是高速发展，行业越会回归人与人的深度连接。过去二十年，软件行业存在明显的异化问题，为了适配规模化量产，我们刻意剥离了软件生产者与使用者的关联，开发者只看数据、不关注具体用户，彻底脱离真实用户场景与社会连接。

而AI时代的到来，正在扭转这一局面，让技术回归服务人、连接人的本质。接下来我们聚焦未来，聊聊未来一到两年，各位的核心规划与落地愿景，我们可以将这些目标记录下来，待明年圆桌论坛逐一复盘落地成果。

（李国彪）未来企业组织形态与教练定位规划 展望未来，创造经济价值的企业组织，将逐步分化为三类核心人群。

• 第一类是AI系统搭建与运维人员，负责优化AI体系、保障AI安全、提升AI生产与服务效率；
• 第二类是人机协同从业者，线上可与AI智能体配合完成贷款审批、风险校验等工作，线下可依托AI工具完成车辆检测、设备运维等实体场景工作，人类主要负责风险把控、最终决策；
• 第三类是普通大众，在各类线下物理场景中，享受AI技术带来的便利与服务。

未来我将以敏捷教练的身份，持续助力传统企业完成组织形态升级，推动企业适配人机协同的全新组织模式，完成AI时代的组织转型。

（申健）大中小企业AI落地与行业赋能规划 从落地现状来看，个人端AI应用已快速普及，但大中型企业AI转型落地难度极大，极易出现落地停滞、团队信心受挫的问题，而中小微企业的AI转型更加灵活、落地效果更显著。

今年年初，我面向北美退休群体、个体经营者、小微企业主开展了两期AI赋能培训，覆盖保险、短租、会计等多个行业。这类学员电脑基础薄弱，但学习意愿极强、落地行动力充足，成长速度远超预期。

其中多位学员实现了业务突破：短租从业者依托AI，将管理房源从60套提升至100余套，自主制作短视频、输出行业方法论；移民中介从业者熟练运用AI梳理客户线索、制作专业提案，业务效率大幅提升。这些落地成果让我对AI普惠落地更有信心。

未来一到两年，我一方面持续跟进大中型企业客户，深耕深度智能体落地场景，摆脱浅层AI试用的局限，实现规模化、体系化落地；另一方面聚焦传统敏捷人、IT从业者的职业转型，依托社区平台，为40至50岁行业资深从业者挖掘全新职业发展路径，助力老行业人拥抱AI新时代。

（庄表伟）Local AI本地智能生态建设规划 我未来的核心深耕方向是Local AI（本地AI）生态建设。回望计算机产业发展，早期全球仅有少数几台大型计算机，逐步迭代为人人可用的个人电脑，实现全民普及。当前AI行业高度集中，全球仅有少数几家企业掌控核心Token供给与模型能力，但我认为行业未来的终极形态，是人人可自主生产、自主使用本地Token。

Local AI是未来AI行业的核心趋势，我们需要全力推动行业变革，减少对云端通用大模型的依赖，实现企业、个人本地私有化模型部署与算力自给。未来我将联动硬件、软件、模型训练、智能体开发等各领域从业者，搭建Local AI专属社区，推动本地AI技术的普及、落地与生态共建。

（杨建良）AI营销与文旅行业落地规划。未来一到两年，我将聚焦AI在垂直行业的深度落地，核心深耕数字营销与文旅两大领域。在数字营销领域，重点落地销售线索挖掘、存量客户激活两大场景。大型国企普遍存在海量沉睡客户，传统短信、电话触达模式易引发用户反感、激活效果极差，我们将结合社交媒体逻辑，搭建全新AI客户激活体系，目前已与浙江企业启动项目开发，同时推进大型国企项目洽谈落地。

在文旅行业，大型工业企业AI落地竞争激烈，中小团队不具备竞争优势，而文旅行业AI智能化改造空间大、预算灵活、差异化需求强，是优质落地赛道。目前我们已落地多个标杆案例，包括南京西山文旅AI数字化呈现项目、政府千人骑行文体活动AI宣传项目。我们首次将AI技术融入文体宣传场景，低成本打造差异化宣传效果，获得了政府部门的高度认可。未来我将持续深耕文旅行业，打造更多AI垂直落地标杆案例。

总结收尾

（熊节）聆听完各位的实践分享与未来规划，我深受启发。行业变革期，从业者的交流、连接与经验互通至关重要，每一个一线真实案例、每一份行业思考，都能为整个社区带来正向激励。

未来十二个月，AI雪鸟会的核心工作，是深耕行业案例调研与成果沉淀。当前AI调研、行业复盘的成本大幅降低，我们将持续梳理传统软件人、敏捷人的转型现状、落地成果与成长故事，沉淀标杆案例、输出行业观点，为整个行业的转型发展提供参考与助力。

RSGSH26大会，由Scrum Alliance冠名赞助，由优普丰敏捷AI创新咨询承办，视觉记录由布解之媛视觉思维团队现场完成。

本文内容整理自RSGSH26大会主会场Bill老师分享《敏捷已死？AI时代如何活出真正的敏捷性？——AI对我们发出的一系列追问prompts》
Bill Li（李国彪）：大中华区敏捷导师第一人、优普丰AI敏捷创新咨询创始人

大家好，我从事敏捷领域工作已有二十余年，也是国内最早一批参与敏捷社区建设的从业者，2007年便参与筹办上海首届RSG敏捷大会，一路见证了敏捷在中国的落地、普及与迭代。

当下AI技术全面爆发，行业内开始出现一个核心讨论：传统敏捷方法是否已经过时？在AI新时代，我们该如何守住、重塑真正的敏捷性与反脆弱性。

这也是我今天想通过一系列深度思考与思想实验，和大家共同探讨的核心话题。

很多人会纠结传统敏捷是否会消亡，但我的核心观点十分明确：僵化、固化的传统敏捷方法需要迭代、蜕变，但敏捷性、反脆弱性这种核心能力永远不会消失。

这也是黑天鹅、反脆弱理论带给我们的核心启示，真正能够让个体与组织在不确定性中持续生存、发展的，从来不是固定的流程方法，而是持续适配变化、自我进化的敏捷能力。

随着AI、大模型、智能体技术普及，行业的角色体系正在发生颠覆性改变。此前申导分享的AI陪练模式，能够将资深老师傅的隐性经验蒸馏、沉淀、封装为AI智能体，实现24小时在线传承，让资深从业者可以从容退休、高效减负。

顺着这个思路延伸，未来的教练角色同样会被重构，AI智能体、大模型可以化身苏格拉底式的提问者，持续引导人思考、成长、迭代。

这也让我开启了一场全新的思想实验：不再是人向AI索取答案，而是让AI主动向人发起提问，倒逼我们重构对敏捷、对组织、对工作的底层认知。

今天的分享内容均为原创思考，没有套用通用模板，全程手动梳理打磨。在AI批量生成标准化内容的当下，这种原生的思考与输出，反而成为了稀缺价值。而这也恰恰是AI时代，人类不可替代的核心优势之一。

我们回归敏捷本源，重温敏捷宣言第四条核心准则：响应变化，高于遵循原计划。这是敏捷最核心的底层纲领，也是AI时代对我们提出的第一重追问：AI到来之后，传统敏捷体系面临的最核心变化是什么？

核心变化主要体现在两个维度。

• 第一，硅基智能体正式进入人类工作体系，与碳基人类共生协作，我们的工作伙伴、组织成员不再只有人类，如何接纳、适配、协同AI智能体，成为所有组织的全新课题。
• 第二，产品与服务形态彻底重构，过往SaaS、CRM、ERP等产品都是固定形态、流程化运转，而AI时代的产品具备智能体属性，动态演化、自主迭代，能够在不确定性中创造新知识、新业务价值。

这意味着，无论是个人工作模式，还是组织运转模式，都必须全面革新。

我们需要借助硅基智能体的能力，放大人类的灵活性、创造力与反脆弱性，重构人机协作的全新组织模式。

未来的组织形态可能极具颠覆性，甚至会出现AI主导工作、人类负责享受生活的全新格局，这不是空想，而是AI原生组织演化的必然趋势。

在这场变革中，我们唯一能牢牢掌控的核心，就是意图。一切工作、创新、变革，皆起于意图。AI可以完成执行、迭代、优化，但定义目标、明确意图、锚定价值的核心权利，始终掌握在人类手中。

这也是AI对我们的第二重追问：抛开后世衍生的各类流程、框架、方法论，敏捷最初、最原汁原味的核心意图到底是什么？

我深耕敏捷多年，始终坚持溯源本质、回归本源。2001年敏捷宣言发布，十七位行业先驱汇聚雪鸟镇，共同凝练出敏捷核心价值观。而“Agile”这一名称的由来，源自Scrum联合创始人Mike Beedle深耕十年的著作《Agile Competitors and Virtual Organization》。书中的核心思想，正是适配不确定性、拥抱变化、依托涌现效应与蜂群协作，实现组织的生存与进化，这也是多智能体协同的最早思想源头。

而Scrum的真正起源，可追溯至1986年《哈佛商业评论》的经典论文《新新产品开发游戏》，后续在1995年被正式完善落地。论文以英式橄榄球团队协作为原型，诠释了Scrum的核心逻辑：依靠团队群策群力、蜂群式推进，一步步创造业务价值。最初的敏捷体系，完全依托碳基人类的协同运转，而其底层初心从未改变。

敏捷最本源的意图，从来不是固定的流程与工具，而是帮助个体与组织在充满变化与不确定性的世界中，持续生存、持续创造客户价值、持续迭代获取新知。

真正的进化，是更低成本、更高效率、更快速地获取有价值的新知识，并将知识落地转化为行业与生活的竞争力。

基于此我们可以明确：敏捷的底层意图永不改变，但适配时代的敏捷方法必须持续迭代。硅基智能体的出现，倒逼我们重构全新的敏捷落地体系。

这就引出了AI的第三重追问：Agile（敏捷方法）与Agility（敏捷性）的核心区别是什么？这也是行业长期争论的核心问题。

简单来说，Agile是一套后天总结的价值观、原则、流程与落地方法，是可迭代、可替换的工具体系；而Agility是灵活性、适应性、反脆弱性的核心能力，是组织与个体长存的核心素养，永远不会过时。

AI时代的核心变革，就是彻底重构人机交互、组织协作的模式，所有流程优化、组织调整、方法创新，最终目的都是为了放大人类与组织的敏捷性。我们无需固守传统敏捷框架，而是要持续迭代适配AI生态的全新方法，持续强化核心能力。

随之而来的是第四重追问：在AI进入组织之前，敏捷体系中的Agent到底是谁？

在管理学与场景落地中，Agent的核心释义是代理人、执行者。日常生活中，中介是我们的事务代理人；企业管理中，从CEO到基层管理者，都是资本与组织的代理人，承担着资源管理、价值创造、资产增值的核心职责。

在AI普及之前，所有团队、组织中的Agent，全部都是碳基人类。而苹果公司的创新体系，让我对人类Agent的核心价值有了更深的认知。苹果内部并不推崇传统敏捷方法论，却践行着更极致的敏捷创新，其核心依托Creative Selection（创造性筛选）理念，搭配七大核心设计原则，强调人类的判断力、审美品味与价值选择。

在乔布斯的主导下，苹果团队每两周完成一轮迭代复盘，依靠人类的审美、判断、决策筛选优质成果、淘汰无效方案，持续打磨产品体验。

这套体系的核心，是极致放大人类的创造力、品味、共情力、决断力，而这些能力，恰恰是传统敏捷方法未曾重点强调、却是AI时代最稀缺的人类核心价值。其中包含灵感、协作、匠艺、勤勉、决断、品味与共情七大素养，是硅基智能无法替代的核心竞争力。

基于此，AI向我们提出第五重追问：在AI原生敏捷体系中，自组织该如何定义与落地？

传统组织分为四层管理模式，自上而下分别是管理层定义方向、团队承接任务，对应管理层主导团队、自管理团队、自设计团队、自治理团队四种形态。传统自组织，是碳基人类团队的自主管理、自主迭代、自主优化。

但AI时代，自组织的边界被彻底打破。智能体具备自主能动性与自我迭代能力，未来的组织方向、产品定义、流程优化、价值创造，都可能由硅基智能体自主完成，甚至出现AI主导的全自治团队、AI CEO。这也意味着，传统的人类自组织逻辑需要全面重构，人机协同下的全新自组织模式，正在逐步涌现。

由此延伸出第六重追问：AI时代，人类与智能体的位置、关系如何界定？企业组织会迎来怎样的进化？

结合落地实践，我将企业AI进化分为四个清晰等级。

• 第一级是个人提效，AI仅作为个人辅助工具，提升单点工作效率，不改变组织流程；
• 第二级是流程嵌入，AI智能体嵌入现有组织流程，赋能原有工作体系，无需重构组织架构；
• 第三级是智能体主导价值流，90%以上的常规工作、价值创造由硅基智能体完成，人类仅负责校验、救火、特殊场景处理，甚至出现人类为AI智能体协作赋能的全新工作模式；
• 第四级是AI原生组织，形成以AI CEO、AI智能体团队为核心的全新组织形态。

所有变革都指向未知的未知，这也是Cynefin框架、朗斯菲尔德矩阵的核心价值。行业未来没有标准答案，没有人可以精准预判AI与敏捷的融合终点。我始终保持“随机漫步”的心态，持续观察、吸收、探索、迭代，在未知中捕捉创新机遇，而这恰恰是创造力与新知涌现的核心来源。

未知的未知是创新的核心土壤，已知的未知是我们学习探索的目标，已知的已知是固化的经验，未知的已知是我们潜藏的隐性认知。AI的提问与碰撞，能够倒逼我们挖掘自身隐性认知、突破固有思维，持续涌现全新认知与创造力。

基于以上所有思考，我们回应第七重追问：能够极致放大敏捷性的AI原生敏捷框架，应该是什么形态？

我向苹果的创造性筛选理念致敬，提出Creative Agility（创造性敏捷）全新理念。

我们不再固守传统敏捷的工具与流程，而是构建一套全新的AI Agile OS操作系统，涵盖AI原生敏捷价值观、核心原则、落地体系，包含AI原生Scrum、AI原生工程体系，依托人机双循环学习模式，实现碳基人类与硅基智能体的双向学习、双向迭代、双向成长。

我们的核心重心，从僵化执行敏捷流程，转向持续强化、释放、放大人类的创造性与组织的敏捷性。

第八重追问聚焦角色重构：AI原生敏捷体系中，人的角色该如何重新定义？

随着AI承担大量执行、迭代、优化工作，人类的核心角色不再是执行者、操作者，而是意图定义者、价值判断者、审美决策者、风险把控者、AI训练者与生态共创者。

未来所有敏捷相关岗位，都将围绕人机协同、价值创造、创新赋能完成全面进化。

最后，回应第九重追问，总结本次分享的核心结论，分为个体与组织两个维度。

从个体层面，我们无需焦虑AI带来的变革，有两种核心选择。

• 第一，坦然拥抱未来变化，接受AI带来的生产力革新，静待行业分配体系完善，享受技术进步带来的红利；
• 第二，主动拥抱硅基智能，借力AI赋能自我成长，主动学习、持续迭代，掌控个人发展节奏，主动创造未来，将AI作为自我能力延伸的核心工具。

从组织层面，企业需要清晰认知自身AI落地阶段，循序渐进推进转型：从个人提效、流程嵌入，到智能体主导价值流，最终搭建AI原生组织。

无需急于求成，可结合自身业务特性，选择适配的迭代路径，稳步实现组织智能化、敏捷化升级。

未来的敏捷，不再是一套固定的工作方法，而是一种持续进化的生存能力。僵化的传统敏捷终将迭代，但真正的敏捷性、创造力、反脆弱性，将依托人机协同，在AI时代焕发全新生命力。

最后，诚挚邀请各位行业伙伴，加入我们的共创社群。我们将搭建两大社群，分别聚焦AI敏捷方法论共创与全新岗位角色体系进化，持续深耕AI原生敏捷领域，与大家一起探索、迭代、成长，共创行业全新未来。

本文内容整理自RSGSH26大会主会场申导分享《从老师傅的手，到AI陪练的脑子——AI-Native重塑制造业经验传承产品化》

申导：AI-FDE陪跑顾问、Scrum Alliance CST/CTC、优普丰敏捷AI咨询机构全球合伙人

视觉记录by布解之媛视觉思维团队

各位新朋友、老朋友、各位行业伙伴，大家早上好，非常荣幸今天能站在这里和大家交流。我与敏捷社区渊源颇深，2013年第一次登上RSG大会的讲台，2014年正式参与上海RSG大会的组织工作，见证了敏捷在中国从萌芽、普及，到如今与AI时代融合迭代的全过程。

当下很多人都在思考，AI全面普及的时代，敏捷是否还有价值、是否需要迭代升级？这也是我今天分享的核心初衷，希望通过制造业AI落地的实战思考，为大家带来新的启发，也为后续各位大咖的分享做好铺垫。

今天我将聚焦AI陪练与制造业经验传承这一核心话题展开分享。

AI技术走入大众视野已有三四年时间，从最初单纯的大模型对话，逐步发展到绘图、编码、复杂任务处理，应用场景也从个人工具升级为企业级落地。如今行业的核心痛点，早已不是个人如何使用AI，而是企业如何系统化、规模化地用好AI，实现组织能力升级。

本次分享所有案例均来自真实落地项目，涉密信息已做脱敏处理，重在分享可复用的思路与方法，适配各行业企业落地参考。

先问一个问题

我将以制造业为核心场景展开分享。制造业有一个普遍且关键的现象：产线大量核心经验、精准判断，完全掌握在资深老师傅手中。相同的原材料、相同的工艺标准、相同的生产设备，不同工人产出的产品良品率、质量稳定性差距极大，核心差距就在于老师傅日积月累的隐性经验。

这类经验传承长期依赖传统的师徒口传身教模式，一名学徒往往需要三年入门、五年深耕、十年才能独立胜任岗位。

这种模式存在极大的组织风险：老师傅一旦请假、离职或退休，对应的核心生产判断、故障处理经验、工艺调试手感就会随之流失。组织没有对应的经验备份，新人无法快速掌握核心能力，直接导致产线良品率下滑、故障频发、生产效率下降。

很多企业沉淀了大量的文档、SOP、培训手册、PPT案例，但绝大多数资料都处于“写完即存档”的状态，阅读率不足10%。新人即便查阅文档，也只能看懂表层操作步骤，无法理解操作背后的判断逻辑、取舍标准和隐性经验，最终依旧需要依赖老员工带教。

本质上，无法被对话、被复用的经验，最终只会烂在文档里，无法成为企业的组织资产。

先看大势：麦肯锡灯塔工厂洞察·AI在制造业的真实战绩

从行业大势来看，AI在制造业的落地已经从概念阶段走向实战阶段。

根据麦肯锡2025年全球灯塔工厂报告数据，当前60%的灯塔工厂已规模化应用AI技术，实现2-3倍的生产效率提升，头部案例可实现99%的产品缺陷率降低，同时达成30%的生产能耗优化。

这足以证明，AI赋能制造业不是未来趋势，而是当下正在发生的真实变革，其中经验数字化、经验智能化传承，是企业AI转型的核心突破口之一。

后看方法：从经验萃取到知识工程

今天讲的，不只是“经验萃取”，而是知识工程（Knowledge Engineering）。

传统经验萃取的三大原罪

传统的企业经验萃取模式，固定为“访谈-整理文档-员工培训”三步流程，但这套模式存在无法规避的三大原罪，导致90%的经验沉淀项目无法落地见效。

• 第一，经验沉淀仅停留在文字层面，产出的文档无人阅读、无法复用；
• 第二，沉淀对象错位，文档大多面向新人入门学习，而企业真正需要传承的资深经验，是用于中层骨干能力升级、核心岗位能力补位；
• 第三，沉淀内容片面，仅记录表层操作动作，缺失最核心的判断逻辑、取舍思维和场景化决策依据，导致经验断层、新人只会操作、不懂原理。

基于传统模式的弊端，我们摒弃了浅层的经验萃取，升级为知识工程（Knowledge Engineering）体系，重构企业经验传承全流程。

全新模式为“多维萃取——AI-Native结构化知识库——AI智能陪练Agent”，核心是跳出“知识给人阅读”的传统思维，转向“知识给AI检索、调用、迭代”的AI原生思维。

通过本体论建模、颗粒化拆解，把老师傅脑海中无法言说的隐性判断力、场景感知力、实操手感，封装为可对话、可复用、可迭代的组织资产，打造24小时在线的AI师傅，实现企业经验的持续复利。

AI带来的一次范式跃迁

AI的普及带来了企业知识管理的范式跃迁。

传统数字化转型中，企业耗费大量精力搭建系统、整理资料，但大多只完成了数据堆砌，没有实现知识的结构化、智能化。很多图表、流程、隐性关联逻辑，无法通过简单的文字记录留存，导致系统沦为空壳，无法支撑业务落地。

而AI原生时代，企业知识需要完成全方位重构，不仅包含文字资料，更要覆盖现场视频、操作手势、设备声纹、产品图像、工艺曲线等多模态全息信息，完整还原老师傅的隐性经验。

之所以需要全息采集，核心原因是大量顶级实操经验，属于老师傅的潜意识行为。很多老师傅能精准做好操作、判断故障、调试工艺，但无法用语言清晰描述自己的判断逻辑，单纯依靠访谈萃取，只能获取浅层信息，无法挖掘核心隐性经验。只有通过现场全息采集、语义化标注、多维拆解，才能让AI不止读懂文字，更能读懂真实的生产物理场景。

超级智能体的三个方向

未来企业发展的终极形态，是超级智体，由机器智人化、人人智体化、组织共智化三者耦合形成。

• 第一，机器智人化，将AI视为企业数字员工培养，从工具、助手升级为副手、专属员工，打造AI陪练、故障排查、合规校验、工艺创新四类专业智能体；
• 第二，人人智体化，重构人机协作模式，人类从重复执行工作中解放，专注价值判断、风险决策、方案取舍，管理AI、训练AI、优化人机团队；
• 第三，组织共智化，搭建企业智慧大脑，形成感知、响应、学习、沉淀、进化的完整闭环，实现组织整体智能化升级。

智能体需要的是AI-Native知识库

搭建AI原生知识库、培育AI智能体，核心依托专业的知识萃取方法。

结合权威专家经验理论与多年企业实战，我们落地了六种核心萃取方法，同时具象化为可落地的实操手段，解决老师傅“会做不会说、能做不会讲”的萃取难题。

核心包含深度访谈、录音二次提取、现场影子观察、决策点重建、关键事件复盘、知识结构建模六大维度，全方位挖掘显性与隐性经验。

在正式萃取落地前，我们会通过标准化工作坊完成前置诊断与场景筛选，避免企业盲目启动AI项目。通过结构化问卷调研、岗位焦点小组访谈、历史生产资料挖掘三种方式，梳理工艺、设备、质量、调试等核心岗位的痛点场景，经过两天共创评审，输出5至10个高价值AI提效场景清单、专属知识工程萃取方法，以及3至6个月的落地路线图，确保所有AI落地都精准匹配业务需求。

再看案例：2个真实制造业案例

我通过两个真实制造业案例，完整展示AI智能体的落地工作流与实战价值。

案例1：智检-某零部件生产的AI质检

第一个是零部件AI质检全流程升级案例。

传统质检模式效率低、误差大、依赖人工经验：

• 换型阶段，班长口头通知换线，质检工程师需要手动查找检验标准，耗时5至10分钟，且文档版本混乱、查找困难；
• 首件检验阶段，工程师逐项人工检验、手动记录数据，耗时15至20分钟，结果高度依赖个人经验；
• 异常处置阶段，人工填写报告、跨部门同步信息，耗时20至30分钟，流程繁琐、信息滞后。

接入AI智能体后，全流程实现智能化升级。

• 换型阶段，AI依托RAG检索与知识图谱能力，自动推送最新版检验标准至终端；
• 检验阶段，通过语音、图像识别自动采集数据，结合预测式AI给出合格概率参考，由人工最终确认，实现高效人机协作；
• 异常处置阶段，AI自动生成结构化不合格报告，关联历史相似案例，一键推送至维修、工艺部门，大幅缩短处置周期，同时明确人机边界，根因分析、风险决策始终由人类负责。

案例2：卡扣-机器人机械臂末端执行器的精密卡扣

第二个是机器人精密卡扣装配优化案例。

某机器人企业末端执行器的不锈钢卡扣，属于0.05mm级高精度装配工艺，新人极易出现装配不到位问题，导致工具脱落、产线停机、客户索赔。老师傅的核心隐性经验，依托三重感知判断：装配的弹性手感、清脆的卡扣声响、标准的扭矩装配曲线。

传统文档仅记录装配步骤，无法告知新人“如何判断是否装到位”，新人遇到异响、无声等异常情况无据可依。

而AI陪练智能体可以完整复刻老师傅的判断逻辑，针对新人常见问题，给出场景化排查方案：

• 首先甄别声响轻重，区分环境噪音、耳塞遮挡导致的声音偏差；
• 其次核对装配扭矩曲线，确认是否形成标准扭矩平台；
• 最后感知弹片弹性反力，三重维度综合判断装配状态，复刻老师傅的实操经验。

该项目通过敏捷迭代的知识闭环持续优化，依托访谈、现场观察萃取经验，完成知识颗粒化建模与入库，上线AI陪练后持续收集现场使用反馈，不断补充新场景、优化判断逻辑，实现知识的生长与迭代。

落地后成效显著：卡扣装配一次成功率从78%提升至94%，新人独立上岗周期从5周缩短至2周，彻底杜绝工具脱落安全事故。

AI Agent智能体 ≠ AI Chatbot聊天机器人

这里需要重点区分AI智能体与普通聊天机器人的核心差异。

普通Chatbot仅能完成一次性问答、问完即止，无持续价值；而企业落地的AI Agent，具备多步推理、工具调用、长期记忆、主动感知规划四大核心能力，能够对接MES、ERP等业务系统，调取设备传感器数据、历史案例、维修手册，完成复杂场景的关联推理、问题诊断与方案输出，是“会思考、能执行、能迭代”的业务助手，而非单纯的对话工具。

智能数据比率——一个判断”AI Native”的关键指标

判断一家企业是否具备AI-Native能力，有一个核心关键指标：智能数据比率，即AI Agent可调用、可读取、可解析的数据占企业总数据的比例。

制造业企业普遍存在数据分散问题，生产、进销存、营销、客服数据各自孤立，还有80%的核心经验留存于纸质资料、员工口头传承，无法被AI调用。数据数字化、结构化程度越低，AI能力的发挥受限越严重，这也是制造业AI转型必须补齐的核心短板。

AI进化企业的5个路标

传统企业的AI进化分为五个清晰路标，循序渐进实现从数字化到智能化、智慧化的升级：

• 第一阶段是知识沉淀化，将员工人脑隐性经验转化为可检索、可结构化的数字知识；
• 第二阶段是数据资产化，让生产、运营、客户数据成为企业可复用的核心资产；
• 第三阶段是AI融入核心业务，从边缘工具升级为业务核心支撑；
• 第四阶段是流程智能化，让核心业务流程自带判断能力，AI Agent深度嵌入流程；
• 第五阶段是组织全面进化，企业具备自主学习、持续迭代的智慧能力。

当下企业AI落地呈现三种早期形态：

• 超级个体，单人搭配多个AI智能体，实现单人匹敌团队的工作效能；
• AI原生企业，以小团队搭配大智能体系，动态组队、灵活迭代、快速创新；
• AI进化型传统企业，不推倒现有体系，通过AI持续赋能升级，实现存量业务提质增效、增量业务创新突破。

企业智慧大脑：双循环模型

企业智慧大脑的搭建依托双循环模型，双向驱动组织持续进化。

• 一是智能网络循环，通过数据采集、AI加工、信息转化、业务落地、反馈迭代，实现数据的高效流转与价值释放；
• 二是智慧生成循环，通过业务行动、结果复盘、效果评估、学习沉淀、知识更新，实现企业经验的持续积累与迭代升级。

AI时代，敏捷不仅没有过时，反而成为AI落地的核心底层逻辑。知识库搭建、智能体训练、人机协作体系优化，没有固定的终点与标准方案，无法一次性设计成型，必须依托敏捷迭代思维，持续试错、持续优化、持续生长。

传统敏捷聚焦团队迭代，而新时代敏捷升级为人机协作迭代，形成“意图规划-AI执行-人类校验-迭代优化”的全新闭环，人类仅在关键判断节点把控方向、把控风险、把控价值，无需全程介入琐碎流程。

最后讲落地+边界

最后明确企业AI经验传承落地的标准化路径、适用前提与核心边界，规避落地误区。

企业AI经验传承落地的标准化路径

标准化落地路径分为三步：

• 第一步，通过高质量访谈、现场影子观察、录音二次萃取，完整挖掘老师傅的隐性经验与判断逻辑；
• 第二步，完成知识颗粒化拆解与结构化建模，搭建可被Prompt调用、适配智能体迭代的AI-Native知识库；
• 第三步，落地场景化AI陪练、AI排查、AI合规、AI创新智能体，实现24小时在线赋能。

这套模式有明确的适用前提：

• 核心资深员工可被持续访谈、现场观察；
• 岗位经验具备差异化判断颗粒，而非单纯机械操作；
• 业务场景高频、人员流动大，经验传承需求迫切。

两条红线

同时存在两条绝对红线：

• 禁止跳过高质量经验萃取，直接投喂原始资料给AI，避免知识碎片化、失真化；
• 禁止AI陪练脱离真实业务场景泛化输出，确保所有AI决策贴合生产实际。

最重要的是坚守人机权责边界，核心原则为Human takes accountability。

AI可以完成数据分析、逻辑推演、流程执行、问题排查，但企业的使命价值、合规底线、风险判断、最终责任，永远由人类定义与承担。

我们不需要“全流程人机监控”，只需要“关键节点人机把关”，把人类注意力聚焦在价值决策、风险把控、战略取舍上。

AI会重构岗位形态、优化组织权责、重塑工作模式，但人类的核心价值永远无法被替代。

Human-in-Control控制权必须在人手中

未来最稀缺的人才，不是只会使用Prompt的AI使用者，而是能够萃取组织经验、训练AI能力、守住人机边界、主导价值决策的AI赋能者。

我们始终坚持以培养人为核心，让AI赋能组织、沉淀经验、传承能力，让创新持续发生，让智能助力企业长效发展。

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

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

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

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

一、先避坑：认清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时代真正的工作方式。