很多中大型企业正在讨论 AI4SE：要不要统一采购 Coding Agent，要不要建设企业级 Harness，要不要让研发团队全面采用 Spec-Driven Development，要不要把 Agentic Engineering 纳入研发流程。
但真正决定转型成败的，通常不是工具选得对不对，而是组织能不能熬过转型早期那段最容易失去信心的时期。
这段时期有一个很像 DevOps 转型的特征：新的方法已经开始带来局部改善，但整体交付效能反而可能暂时下降。 团队需要学习新的工作方式，需要补规格、补测试、补评审，需要为过去被隐含在个人经验里的知识建立显式资产。AI 让实现速度变快，却没有同步消除决策、验证、治理和协作的成本。
于是，组织可能在最接近形成新能力的时候停下来。
管理层看到周期变长了，认为转型没有价值；团队看到流程变复杂了，认为 AI 反而降低了效率；采购部门看到工具已经部署了，认为转型已经完成。最后，一次本来需要继续巩固的能力建设，被误判成“试点失败”，或者被过早包装成“全面成功”。
这就是 AI4SE 变革的 J 形曲线问题。
在讨论如何熬过这段低谷之前，还有一个更靠前的判断：组织是否把 AI4SE 放进了正确的问题域。如果认知定位错了，后面的路径再完整，也会用错应对策略——失败往往只是时间问题。
本文结合我们在中大型研发组织中的咨询经验，以及《From AI4SE Pilot to Conditional Scale: A Transformation-Path Experience in Mid-to-Large R&D Organizations》中的案例观察，讨论一条更稳健的路径：
先试点，验证方法是否能跑通；再巩固，把一次跑通变成团队可以重复和传授的能力；最后分波次规模化，让新团队在护栏下独立运行。
更重要的是，这三个阶段不能只按日历推进，而要由证据决定是否进入下一阶段；而证据能否被正确解读，又取决于组织是否先用对了问题域判断。
一、先理解 J 形曲线：为什么转型初期会变慢
DevOps 转型早期，很多组织会经历一个短期下降期。团队开始引入持续集成、自动化测试、基础设施即代码、看板和跨职能协作时，原先隐藏的问题会被暴露出来：
- 旧流程中的等待、返工和手工操作开始显形；
- 团队需要投入时间学习新的工具与协作方式；
- 原来依赖个人经验的质量控制，需要变成可重复的工程机制；
- 为了获得更短的反馈周期，组织必须先建设测试、流水线和环境能力；
- 局部团队的变化会暂时增加上下游的协调成本。
短期看，效率下降了；长期看，系统才有机会进入更高的效率区间。
AI4SE 会把这个问题进一步放大。Coding Agent 可以迅速生成代码、测试和文档，但它不会自动替组织解决以下问题：
- 需求到底要解决什么问题；
- 哪些约束不能被破坏；
- 生成结果是否符合真实业务意图；
- 谁拥有最终验收和风险接受责任；
- 这次经验如何沉淀，下一支团队如何复用。
可以把它理解为两个时钟同时存在：
代码生产时钟：越来越快
定义、决策、验证和治理时钟：不会自动同步变快如果管理层只盯着代码生成速度，就会产生一种错觉：代码更多了，交付却没有更快；工具更强了，评审和测试却更忙。事实上，瓶颈只是从“实现”移动到了“定义和验证”。
因此，AI4SE 早期出现效能下降，并不必然说明方向错误。它可能说明组织正在为新方法支付学习成本、质量成本和治理成本。真正要问的是：这些成本有没有被转化为可复用的组织资产，还是只是变成了更多的会议、文档和手工操作。
二、先判断问题属于哪个域：Cynefin 带来的认知定位
很多变革失败，并不是执行能力不够，而是一开始就把问题判断错了。组织面对一个复杂问题，却要求团队用简单问题的方式处理；或者面对已经稳定的问题，却继续无限探索。应对策略一旦与问题域错配，失败往往只是时间问题。
Cynefin Framework 提供了一种很有用的认知框架。它不负责告诉我们“AI4SE 应该选哪个工具”，而是帮助管理层判断：当前面对的到底是一个可以直接套用最佳实践的问题，还是一个必须通过试验逐步发现方法的问题。
可以先用下面这张简化的映射理解：
| Cynefin 问题域 | 问题特征 | 适合的应对方式 | AI4SE 中的典型含义 |
|---|---|---|---|
| Clear，清晰域 | 因果关系稳定，最佳实践已经明确 | Sense - Categorize - Respond | 已经稳定的标准工作流、低风险自动化和明确门禁 |
| Complicated，繁杂域 | 存在因果关系，但需要专家分析 | Sense - Analyze - Respond | 已经形成 Playbook，需要结合不同技术栈和组织约束做适配 |
| Complex，复杂域 | 因果关系事后才清晰，方法需要在实践中涌现 | Probe - Sense - Respond | AI4SE 早期试点：通过小范围真实场景探索流程、方法、人机分工和 Harness |
| Chaotic，混乱域 | 系统失去稳定性，首先要恢复秩序 | Act - Sense - Respond | 重大质量、安全或交付失控时，先止损和稳定环境，再谈转型实验 |
Cynefin 还有一个很重要的提醒：如果组织甚至还没有判断清楚自己处在哪个域，就处于“无序”状态。此时最重要的动作不是急着选方案，而是把问题拆开，分别判断其中哪些部分已经清晰、哪些部分需要专家分析、哪些部分仍然需要探索。
AI4SE 为什么通常要从复杂域开始
在中大型企业里，AI4SE 早期往往属于复杂域，而不是清晰域。原因包括：
- 不同组织的流程、系统、技术栈和质量约束差异很大；
- 工具能力、模型能力和 Harness 设计仍在快速演化；
- 人和 Agent 的责任边界不是购买工具后自然出现的；
- 需求定义、验证能力、权限治理和知识沉淀之间存在相互影响；
- 一个团队有效的方法，未必能直接迁移到另一支团队。
这意味着，试点阶段不应该假装自己已经拥有一套可以直接复制的“最佳实践”。试点更像一次有边界的探针：选择真实但可控的场景，运行一条端到端方法链，观察哪里有效、哪里失败、哪些条件必须成立，并把结果形成可检查的资产。
这也解释了为什么“统一买工具、统一上培训、统一要求使用”通常不是正确的起点。这些动作把一个复杂问题伪装成了清晰问题，默认答案已经存在，只需要让所有人执行。这种做法会压制真实反馈，把尚未解决的定义、验证和责任问题推迟到规模化之后集中爆发。
三个阶段，其实是问题域的逐步迁移
Cynefin 视角也能帮助我们重新理解 Explore、Consolidation 和 Scale：
Explore：在复杂域中 probe - sense - respond
通过真实试点发现局部可行的方法
Consolidation：把稳定发现带入繁杂域 sense - analyze - respond
通过 Playbook、Harness 和教练机制实现重复与适配
Scale：只对已经足够稳定的部分进行条件化复制
在明确护栏和反馈机制下分波次扩散这里有两个相反但同样危险的误区。
第一个误区，是把复杂问题当成清晰问题处理。管理层预先宣布“正确工具、正确流程和正确培训方案”，然后用推广率检查执行情况。结果是组织在还没有理解问题之前，就开始放大未经验证的假设。
第二个误区，是把所有问题永远留在复杂域。团队不断做实验、换工具、改 Prompt，却不愿意把已经稳定的做法固化为 Playbook、门禁、角色和 Starter Kit。这样会把“需要探索”变成“拒绝标准化”，最终无法形成可迁移能力。
因此，正确的变革不是一开始就全面标准化，也不是永远保持试验状态，而是让问题域随着证据发生迁移：先探索，再巩固，最后只规模化那些已经具备迁移条件的部分。
三、三种最常见的失败路径
这三种路径看起来像执行问题，本质上往往是 Cynefin 意义上的问题域错配：把复杂域问题当成清晰域问题处理，或者在还没有完成域迁移时就按清晰域方式推广。
1. 把转型等同于推广一个工具
最常见的做法是：选定一个工具，统一采购，统一安装，然后要求所有团队使用。
用 Cynefin 的话说，这是把早期 AI4SE 伪装成清晰域问题：因果关系已经稳定，最佳实践已经明确，组织只需要分类并执行。这种做法的隐含假设是：
只要大家使用同一个工具，组织就会自然形成新的研发能力。
但工具只解决了“能力可以被调用”的问题，并没有解决“能力应该如何嵌入工作”的问题。
企业真正需要重新设计的，至少包括：
- 需求如何进入 AI 可执行的规格；
- Agent 能访问什么上下文、工具和权限；
- 生成、应用和验证如何分离；
- 代码、测试、规格和决策如何形成追踪关系；
- 安全、合规和审计如何覆盖生成式产物；
- 团队如何把有效实践沉淀为规则、技能、模板和运行手册。
如果这些问题没有被回答，组织得到的通常不是 AI4SE，而是更快的局部试用。每个团队会形成自己的 Prompt、自己的上下文包、自己的检查习惯。短期看很有活力，长期看却会增加组织熵：相同的问题有多套做法，质量依赖少数熟练者，关键人员离开后经验无法转移。
所以，工具采购可以是转型的输入，但不能被当成转型本身。
2. 把转型等同于给全员上培训
第二种做法是快速组织培训：请培训师讲几天课程，让大家学会使用工具、掌握提示词、完成一些练习，然后宣布组织完成了 AI 能力建设。
这也是一种清晰域错配：它默认答案已知，剩余工作只是把答案传达给所有人。培训当然有价值，但培训完成只说明“人听过了”，不说明“组织会运行了”。
AI4SE 的能力不是一次性知识，而是嵌入真实交付过程的工作纪律。团队必须在真实需求中反复回答：
- 这类需求应该写成多精确的 Spec；
- 哪些任务适合交给 Agent，哪些任务必须由人主导；
- Agent 产生的结果由谁验证；
- 验证失败后如何回到规格和设计；
- 交付完成后，哪些经验需要回写到 Living Spec、规则和 Harness。
没有真实需求、真实代码库和真实质量约束的培训，很容易把 AI4SE 变成“工具演示周”。大家都觉得课程有收获，回到项目里却不知道第一条流程应该改什么。
因此，培训应当是转型中的一个能力补充动作，而不是转型的验收标准。更有效的方式是由外部教练在真实项目里引导团队，把最小必要的知识放在具体问题出现时学习，并把每次决策沉淀为可复用资产。
3. 把试点完成等同于规模化准备就绪
第三种做法最隐蔽，也最危险：
试点按期完成了，参与者反馈不错，说明已经可以向全组织推广。
这相当于跳过 Complex → Complicated 的域迁移：试点只说明局部 probe 有效，还不等于已经形成可分析、可适配、可迁移的稳定方法。但试点通常只回答一个问题：
在当前团队、当前教练、当前项目和当前上下文下，这条方法链能不能跑通？
规模化需要回答另一个更难的问题：
换一支团队、换一个项目、减少外部教练介入后，这条方法链还能不能被重复运行？
这两个问题不是一个问题。
试点成功与规模化准备就绪之间，隔着方法资产化、工具链硬化、角色责任明确、内部教练培养、赞助节奏建立和新团队验证等工作。跳过这些工作，组织只是把第一支团队的隐性经验，直接复制给第二支团队，然后期待第二支团队自行补齐所有缺口。
这通常意味着：第一支团队越来越像“转型专家组”，其他团队越来越依赖专家组。外部顾问退出后，能力也随之退出。
四、真正的核心问题：从“能跑一次”到“能被复现”
我们在论文中把 AI4SE 转型拆成两类不确定性。
第一类是产品不确定性：AI4SE 是否能在选定的业务、代码库和质量约束下改善工作方式？这需要通过真实试点来探索。
第二类是迁移不确定性：即使试点团队找到了有效方法，另一支团队能否不重新发明一遍，就能在自己的环境中运行它？这需要通过巩固和新团队验证来降低。
试点主要降低产品不确定性；巩固和规模化准入主要降低迁移不确定性。
这也解释了为什么“试点成功，但暂不允许规模化”是一个完全合理的结论。它不是自相矛盾，而是两个阶段回答了不同的问题。
从管理角度看，阶段决策应该至少区分三种资产状态：
| 状态 | 含义 | 可以支持什么判断 |
|---|---|---|
| 可引用（Citable） | 方法已经稳定到可以展示、讨论和追踪，缺口也被明确记录 | 可以结束探索，进入巩固 |
| 可运行（Runnable） | 方法的主要执行路径能够在目标工作流中稳定运行 | 可以开始评估是否适合交给新团队 |
| 可迁移（Transferable） | 新团队在明确护栏和有限辅导下能够独立完成一个周期 | 可以准入一个规模化波次 |
一个目录里有很多命令、技能、Agent 和 Hook，不代表这些资产已经可运行；一条路径在顾问陪同下跑通，也不代表它已经可迁移。
五、AI4SE 不是工具层升级，而是研发操作系统的重新组织
在实际转型中，我们通常从四个方向观察 AI4SE 能力：
| 方向 | 解决的问题 | 典型关注点 |
|---|---|---|
| Spec-Driven Development | 意图如何被说清楚 | Living Spec、Change Request、Delta Spec、验收场景 |
| Agentic Engineering | 人与 Agent 如何共同完成任务 | 任务编排、上下文使用、执行反馈、异常升级 |
| Harness Engineering | Agent 如何在边界内可靠工作 | 工具、权限、知识、反馈、可观测性和门禁 |
| Operating Model | 能力如何成为组织能力 | 角色、教练、资产、度量和推广机制 |
这四个方向不是四个彼此独立的工具包。
它们还需要放在两个横切关注点之下。
第一是 Effectiveness，也就是有效性。它不只是“速度更快”，还包括质量、信任、安全、合规和减少浪费之后的真实价值。第二是 Harmony，也就是人和 Agent 之间的协作契约：谁定义意图，谁维护规格，谁编排工具，谁验证结果，什么风险可以由 Agent 在监督下处理，什么风险必须由人直接参与。
换句话说，AI4SE 不是在传统研发分层上再堆一个“AI 层”。流程、方法和工具仍然各司其职，只是执行者变成了人和 Agent 的组合；Effectiveness 是底层目标，Harmony 横切整个交付链路。
SDD：把变更变成可验证的契约
在 AI 大量参与实现之后，研发工作项不能只停留在一句用户故事或一个模糊需求上。团队需要把意图、范围、约束、验收条件和风险写成足够精确的变更契约。
一个典型的链路是：
业务意图
-> Change Proposal
-> Delta Spec
-> Design and Task Plan
-> 生成与实现
-> 独立验证
-> Verified Increment
-> 合并回 Living SpecSDD 的价值不在于增加文档，而在于让规格成为人和 Agent 共同依赖的真相源。代码是规格的一个实现快照，而不是唯一的事实来源。
Agentic Engineering：让 Agent 进入真实工作流
Agentic Engineering 不是把一个聊天机器人接入 IDE，而是让 Agent 参与代码库探索、方案生成、任务分解、测试补齐、构建修复、评审辅助和知识回写等连续活动。
但“让 Agent 参与”不等于“让 Agent 独立负责”。人和 AI 的分工必须被显式设计：
- Intent Owner 负责目标、边界和风险接受；
- Spec Steward 负责把意图转化为可验证规格；
- AI Orchestrator 负责上下文、工具和执行路径；
- Verification Lead 负责独立验证和最终质量判断。
这些职责可以由同一个人兼任，但不能出现职责空缺。尤其要避免“应用变更的 Agent 同时证明变更正确”的自我认证。
Harness Engineering：把方法装进可控制的环境
Harness 不是一堆散落的 Prompt，也不是插件目录。它是围绕研发流程组织起来的外部控制层，包括：
- 上下文和知识如何提供；
- Agent 可以调用哪些工具；
- 权限和数据边界如何控制；
- 过程如何观察和反馈；
- 哪些质量门禁必须经过；
- 经验如何沉淀为规则、技能、模板和运行手册。
因此，Harness 的设计必须由方法和流程驱动，而不是先买一个平台，再试图把所有流程塞进去。
在这套结构中，SDD 的 Align、Verify、Merge 是单个变更的过程控制；Explore closeout 和 Scale admission 是组织阶段的治理决策。两层控制环不能混为一谈。
SDD 也不意味着要推翻 Scrum、Kanban 或其他既有团队协作方式。敏捷和精益仍然提供价值流、反馈和持续改进的原则，Scrum、Kanban 或 Scrumban 仍然可以承担团队协作和节奏管理；变化主要发生在工作项的定义上：从“有一张故事卡”进一步走向“有一个可追踪、可验证的变更契约”。
六、阶段一：试点不是展示，而是探索方法能否跑通
试点阶段的目的不是证明所有团队都应该使用同一套方案，而是在受控范围内探索一条真实可行的方法链。
试点阶段要探索什么
试点至少要同时观察四个方面：
- 流程：需求、设计、实现、验证、交付和知识回写如何衔接；
- 工具：Agent、MCP、CLI、CI、测试和权限如何组合；
- 方法论：SDD、Harness Engineering、Agentic Engineering 如何进入真实工作；
- 人机分工：什么由人决策，什么由 Agent 执行，什么必须由独立角色验证。
如果只试工具，试点结束后得到的是工具评价；如果只讲方法，试点结束后得到的是培训反馈。真正有价值的试点，需要把流程、工具、方法和人机协作放在同一个真实变更中验证。
用真实变更作为验证载体
试点不一定要把一个完整业务项目全部做完。更好的做法，是选择一个边界清楚、风险可控、能覆盖关键环节的真实 Change Request，作为验证载体。
验收重点不是“这个业务功能是否全部交付”，而是：
- 意图是否被正确捕获；
- Spec 是否足够精确；
- Agent 是否能在真实上下文中工作；
- 验证是否真正发生；
- 关键产物是否能够被追踪和引用；
- 团队是否发现了流程中“读起来正确、执行时却不成立”的部分。
试点的退出条件
试点结束时，管理层至少要检查：
- 是否有一份可以引用的初版 Playbook；
- 机会点、规格和最佳实践是否可以盘点；
- 可执行资产是否明确标记为 Ready 或 Stub；
- 效能和成熟度信号是否说明了数据边界；
- 下一阶段的巩固路径是否具体可讨论。
这里有一个容易被误解的地方：试点允许存在未完成的资产，但不允许隐藏这些缺口。
论文中的 Org-A 约用了六周完成 Explore，覆盖诊断、场景选择、四周工作坊、十二个机会主题和一个真实变更验证载体。管理层最终认可了 Explore closeout，因为方法链已经在真实约束下被端到端运行，初版方法和机会资产也能够被引用。但这并不意味着它已经具备规模化条件：主要执行链仍有大量 Stub，内部教练和跨团队迁移证据也还没有形成。
这是一个很重要的管理信号：试点的正面结论可以是“允许进入巩固”，而不是“立即全面推广”。
复杂流程环境下，方法必须适配
论文中的 Org-B 提供了另一个重要提醒。面对制造业组织里既有的 Integrated Product Development（IPD）和 SAFe-class 协作约束，AI4SE 不能简单要求组织“抛弃原有流程，换成一套全新的 AI 流程”。
Org-B 的记录更多是一份处于 late Explore 阶段的适配设计，而不是已经完成的组织级验证。它关注的是如何把原有需求入口、IPD 工作项和 SDD 变更契约连接起来，并在团队层面探索适配；论文没有把这份设计写成正式 Explore closeout、Consolidation 完成或 Scale admission。
这说明规模化需要同时保持两件事：方法的核心准入标准不能被稀释，但进入不同组织时，流程入口、角色安排和 Harness 资产必须允许本地适配。真正可迁移的不是一份不变的流程手册，而是一组可检查的原则、产物、责任和准入条件。
七、阶段二：巩固是把一次成功变成可教能力
巩固阶段是最容易被压缩、也最决定成败的阶段。
它要解决的不是“再做一遍演示”，而是把试点团队在真实迭代中遇到的问题，转化为方法和资产的改进。
巩固阶段需要做什么
第一，在真实需求中重复使用方法。只有当团队持续面对新的需求、缺陷、技术债和交付压力，才能知道 Playbook 是否真的可用。
第二，把“读起来正确但跑不起来”的条款改掉。很多流程在文档里逻辑完整，但缺少入口、上下文、工具接入、停止条件或异常处理，最终只能依赖教练现场解释。
第三，把执行链从 Stub 硬化为 Ready。可以从规则、技能、Agent、命令、Hook 等层次逐步推进，但每一步都要以主路径真的能运行作为判断依据，不能因为目录里存在文件，就把它当成生产能力。
第四，建立职责和教练机制。方法如果仍然只能由外部顾问解释，就还没有成为组织能力。
第五，坚持应用与验证分离。Agent 可以生成、修改、执行和修复，但最终验收必须保留独立的人类责任。
巩固阶段的退出条件
巩固的核心退出条件可以概括成一句话：
团队不只会使用方法，还能够把方法教给别人。
具体来说，应至少看到：
- Playbook 已经从 v1 迭代到更稳定的版本；
- 主执行链可以在真实工作流中运行；
- 角色责任和验证责任已经明确；
- 试点成员能够解释方法背后的原因；
- 新成员能够在有限辅导下完成一次完整周期；
- 关键资产的 Ready / Stub 状态仍然透明；
- 外部教练逐步从“带着做”转向“观察、反馈和纠偏”。
在论文记录的 Org-A Consolidation 观察窗口中，团队连续五周处理了 15 个需求、18 个变更并完成了 8 个变更；18 个变更都通过强制的 SDD 入口生成了对应规格。这些数字是流程信号，不是 ROI 证明，但它们说明团队已经开始在真实需求中重复使用方法。
与此同时，论文也保留了关键缺口：Verify 还没有形成足够完整的 Reject / Conditional 记录，Align 时间高于 Playbook 预期，一个 AI 编排角色仍在硬化。这些并不是“失败证据”，而是说明巩固尚未完成、规模化仍应保持条件化的证据。
八、阶段三：规模化不是全面铺开，而是条件化、分波次地扩散
规模化阶段不应该被理解为“一次性把所有团队迁移过去”。在复杂组织里，更稳妥的方式是逐波次扩散：
试点团队
-> 内部金种子
-> 第一批种子教练
-> 新团队验证
-> 下一波种子教练
-> 更大范围扩散规模化准入至少需要满足：
- 巩固阶段的“团队能教会”已经被观察到；
- 主执行链已经可以运行，而不是主要依赖 Stub；
- 新团队拥有可以直接使用的 Starter Kit；
- Intent、Spec、Orchestration、Verification 等责任有人承担；
- 赞助人能够提供稳定的节奏、资源和决策支持；
- 新团队可以在有限辅导下独立完成一个完整周期。
规模化准入还应该是可逆的。如果新团队无法独立运行，不应该把问题解释为“团队不够积极”，而要把失败的资产、角色安排或培训机制退回巩固阶段修正。
外部教练、金种子和种子选手
外部教练的价值，不是永远替组织做转型，而是帮助组织形成自己的教练梯队。可以采用三层结构：
- 外部教练：带领早期试点，帮助团队识别方法、工具和组织约束；
- 金种子：在试点和巩固过程中表现出较强学习能力、影响力和端到端理解的人；
- 种子教练：经过实际带队和教练训练，能够帮助其他团队完成方法迁移的人。
这里的“金种子”不应只是最会用工具的人。更重要的是，他能够理解为什么要这样做，能够识别方法的边界，能够在业务、工程质量和人机协作之间做取舍。
规模化阶段，真正需要增长的不是工具许可证数量，而是种子教练数量、方法资产质量和新团队独立运行的数量。
九、成熟度模型与度量：用证据牵引，而不是用口号施压
成熟度模型的作用，不是给团队排名，也不是要求所有团队在同一个时间点达到同一个等级。
更有价值的方式是建立团队画像，观察不同能力域的短板：
- 效能目标与价值假设；
- 人机协作流程；
- 规格化表达与验证纪律；
- Agent 运行环境、上下文和权限；
- 安全、质量与责任边界；
- 内部教练、知识资产和持续改进。
成熟度评估应当只评价已经稳定发生的实践，不把计划、演示和一次性成功当成团队能力。个人能做到，通常不代表团队能做到；团队能做到，也不代表另一支团队能迁移。
指标同样需要分层。可以关注：
| 维度 | 示例 |
|---|---|
| 流动与效率 | 需求到交付周期、PR 周转、构建修复时长、等待时间 |
| 质量与信任 | 返工率、缺陷、测试与验证证据、评审问题密度 |
| 组织能力 | 资产复用、种子教练数量、新团队独立运行情况 |
| 治理 | 权限拦截、合规问题、成本可见性、人工责任记录 |
需要特别避免把代码行数、Agent 调用次数、Prompt 数量、License 数量和培训出席率当成转型成功的代理指标。它们最多说明“活动发生过”，不能说明“能力已经形成”。
更好的管理问题是：
- 这条方法链是否在真实工作中被使用；
- 产物是否能够被引用和追踪；
- 主要执行路径是否真的可运行；
- 验证责任是否仍由人承担；
- 新团队是否能够在不依赖原团队的情况下完成一个周期；
- 发现问题后，组织是否能够修正 Playbook 和 Harness。
十、给管理层的一份阶段判断清单
可以结束试点、进入巩固时
- 方法链已经在真实场景中端到端运行过；
- 有可引用的初版 Playbook；
- 机会资产和规格资产可以盘点；
- Ready 与 Stub 状态已经公开；
- 已知缺口和下一阶段工作明确；
- 没有把局部效果包装成组织级 ROI。
还不能规模化时
- 主要执行链仍然依赖顾问现场操作；
- 工具目录看起来完整，但主路径仍是 Stub；
- 试点成员知道怎么做，却无法解释为什么这样做；
- 内部教练还没有形成；
- 应用者同时承担唯一验证者；
- 没有新团队独立运行的证据；
- 管理层只准备了推广预算，没有准备巩固节奏。
可以准入一个规模化波次时
- 试点团队能够重复使用并讲授方法；
- Playbook、Starter Kit 和 Harness 主路径已经稳定；
- 新团队的角色和验证责任明确；
- 新团队可以在有限辅导下完成完整周期；
- 赞助人承诺了资源、节奏和复盘机制；
- 失败时可以退回巩固阶段，而不是强行继续铺开。
结语：最好的转型不是看起来最快，而是能够持续传递
AI4SE 转型真正困难的地方，不是让一个熟练团队在一次演示中用上 Agent，而是让组织在人员变化、项目变化和流程约束存在的情况下，依然能够稳定地产生可信的软件交付。
这要求我们改变“转型完成”的定义：
- 不是工具已经部署，而是方法已经被验证；
- 不是培训已经结束，而是团队能够在真实需求中重复实践；
- 不是试点已经成功，而是新团队能够独立运行；
- 不是效率指标短期上升，而是质量、信任、流动和组织能力一起改善。
从这个角度看，试点、巩固、规模化不是项目计划里的三个时间段，而是三种不同的不确定性处理方式：
Explore：这条方法能不能在本地跑通？
Consolidation：这条方法能不能被团队重复和教会？
Scale：另一支团队能不能独立运行并保持质量？管理层最重要的职责，是在 J 形曲线的低谷阶段给方法足够的学习空间，同时持续做问题域判断：哪些部分仍需探索，哪些部分已经可以巩固，哪些部分才具备规模化条件。既不要因为早期下降就放弃，也不要因为局部成功就盲目全面铺开——更不要在问题域尚未判断清楚时，用清晰域的打法去处理复杂域的问题。
真正值得规模化的，从来不是某个工具，而是一套能够被验证、被传授、被迁移、被持续改进的研发工作方式。