# AI4SE 工作坊不是培训班：组人、节奏与漏斗收敛
AI4SE 工作坊要的不是工具演示周，而是在真实项目上把机会点收敛成可复用 Playbook——关键在组对人、钉住周/日节奏、按 Pair→组→全场漏斗把决策持久化。
AI4SE 工作坊最常见的翻车，通常不是模型不够强，而是场子搭错了。
第一种：把「听说过 Copilot」当成「会用 AI」，结果一周都在教快捷键。第二种：没有真实项目，产品、开发、测试各自对着空气练工具，机会点永远停在 PPT。第三种：每个角色都交了「本岗满分答卷」，串起来却跑不通——局部最优庆祝完，端到端依然卡住。
工作坊买的不是培训课时。它买的是：在真实项目上，让端到端角色把 AI 机会点收敛成一份可执行的 Playbook。组人、节奏、过程纪律，缺一不可。本文按这三块给出可直接照着办的设计策略；组织视角的试点框架，可对照 中大型研发组织 AI4SE 试点转型。
一、如何组建工作坊人员
人选错了，后面节奏和收敛再漂亮也是空转。组人只抓三条。
1. 优先高频 AI 用户
工作坊要的是探索与决策，不是从零教提示词。优先找已经在日常里高频使用各类 AI 工具的人：写代码、写规格、做评审、做测试、做文档——哪个环节都行，关键是「用出肌肉记忆」。
把第一次打开 ChatGPT 的人塞进 AI4SE 工作坊，等于把刚学会骑自行车的人拉去环法：不是不能学，而是场合错了。入门培训可以另开；工作坊席位留给能立刻进入「人机共创」状态的人。
2. 用一个真实项目拉齐端到端角色
最好选定一个具体项目，按端到端交付把角色拉齐：产品 / BA、开发、测试、架构（按项目需要可加运维、安全）。机会点往往卡在角色交界处，而不是卡在某个 IDE 插件。
没有真实项目的工作坊，很容易变成「工具博览会」：人人都觉得收获很大，回去却不知道第一周改哪条流水线。项目是锚点；角色是受力结构。
3. 项目最好同时覆盖 Software 1.0 / 2.0 / 3.0
这里采用 Andrej Karpathy 的经典口径：
| 类型 | 含义 | 工作坊里为什么重要 |
|---|---|---|
| Software 1.0 | 人写规则与确定性代码 | AI 多用于加速实现、重构、测试；验收边界清晰 |
| Software 2.0 | 用数据训练出来的模型行为 | 机会点在数据、评测、漂移与人机边界；「写对代码」不等于「模型可用」 |
| Software 3.0 | 用自然语言 / Agent 编排驱动的软件 | 机会点在规格、工具权限、Harness 与可观测；失败模式完全不同 |
三类软件的 AI 切入点、风险与验收标准差得很远。同场，才能逼出「全栈最优」，而不是「开发岗最优」。组织可按自身语境映射模块，但入场时尽量保证三类都有代表路径——否则 Playbook 会偏科。
入场时建议拉一张简单矩阵： 人员 × 端到端角色 × 主要接触的软件类型。矩阵不漂亮没关系，空缺一目了然就有价值。
二、如何组织每周与每日工作坊
节奏不是「把人关在会议室里」，而是用固定节拍把探索压成可决策的进展。
1. 每周 Kickoff：本周只打几个核心机会点
周初对齐三件事：本周机会点清单、成功标准、本周要收敛到什么粒度。机会点一多，人人都在「很忙地探索」，周五却交不出能串进 Playbook 的东西。
Kickoff 的产出不是士气口号，而是本周收敛契约：哪些假设要验证、哪些方案要写入文档、哪些路径本周明确放弃。
2. 每日站会：用 ORID，而不是传统敏捷三问
传统站会擅长报进度；AI4SE 工作坊更需要逼出学习与决策。建议每日用 ORID 日志回顾：
| 步骤 | 含义 | 典型问题 |
|---|---|---|
| Objective | 客观发生了什么 | 用了什么工具？产出了什么实验 / 文档？ |
| Reflective | 感受与卡点 | 哪里顺、哪里卡？和 AI 协作时什么别扭？ |
| Interpretive | 这意味着什么 | 哪个假设成立 / 被推翻？机会点边界如何变化？ |
| Decisional | 今天决定什么 | 什么要写入方案文档？今天验证哪一步？ |
可以把 ORID 放在日末做完整回顾，日初用 5 分钟对齐当日 Decision。形式服务于决策；不要把 ORID 做成新的流水账模板。
3. 顾问先引入通识与业界热门实践
每天围绕当日机会点，顾问先做短、按需、可立刻用的引入：讨论所需的最小通识，以及业界正在怎么做。这是点火，不是开成半天培训。
学员需要的是「今天能用来做选择的上下文」，不是「顾问知识体系完整巡展」。讲到能动手为止，多出来的部分进附录或按需答疑。
4. 引导学员直接用 AI 脑暴工具探索方案
通识之后立刻上手：人 + AI 一起拆方案、比路径、记决策。顾问的职责是提问、澄清边界、推动写入文档——不是替学员点「生成」。
一条好用的日节奏：
| 时段 | 动作 |
|---|---|
| 短 | 通识 + 业界实践引入 |
| 主 | AI 脑暴探索机会点方案 |
| 中 | Pair 讨论、比选、回写文档 |
| 末 | ORID 收束，锁定当日决策 |
三、工作坊过程中的七条纪律
工作坊的质量不取决于「讲了多少」，而取决于：决策有没有被留下、收敛有没有发生、最优是不是全栈的。
1. 教练负责引导，而非培训
默认姿态是引导：提问、澄清、推动决策。培训按需发生——某人卡在关键工具能力上，再补最小必要的一刀。顾问一开口就停不下来，学员很容易变成「记笔记的观众」；观众是带不走 Playbook 的。
2. 分组，组内 Pair
分组保证并行探索；组内 Pair 充分吸纳结对编程思想：一人驾驭 AI 与实现路径，一人盯目标、约束与质量，角色可轮换。Solo 对着 Agent 狂聊很爽，但缺少第二双眼睛时，方案文档里最容易留下「当时觉得很对」的幻觉。
3. 漏斗式层次收敛：Pair → 组 → 全场
漏斗不是抽象的「从灵感到最佳实践」，而是按组织单元层层收窄：先让每组里的 Pair 充分发散，再收敛成每组的方案，最后把各组已收敛的内容再收敛为一份。每一层都有明确的输入、输出和「扔掉什么」。
| 层级 | 谁在场 | 动作 | 产出 |
|---|---|---|---|
| L1 · Pair 发散 | 组内各 Pair | 用 AI 脑暴大胆探索路径、假设与反例；允许分歧并存 | 各 Pair 的机会点探索稿（含决策记录） |
| L2 · 组内收敛 | 同一组的多个 Pair | 对照、辩论、合并；留下可验证路径，砍掉重复与空想 | 组级机会点方案 |
| L3 · 全场收敛 | 各组 + 顾问 + 关键角色 | 对组级方案做比选与权重分析，合并为一份 | 机会点定稿（再进入 Playbook 串联） |
三层缺一不可：
- 只有 Pair 发散、没有组内收敛 → 一堆平行宇宙，组里谁也说不清「我们到底主张什么」。
- 只有组内收敛、没有全场收敛 → 各组各自为政，周五得到的是 N 份「都很对」的文档，串不成一条路径。
- 过早全场收敛、跳过 Pair 发散 → 看起来高效，其实只是把最大声的那个人的方案合法化了。
顾问在漏斗里的职责，不是替大家写结论，而是守住层次：该发散时别急着投票，该收敛时别无限加戏。每一层结束时问一句：这一层留下了什么、扔掉了什么、依据写进文档了没有？
没有漏斗，工作坊是灵感市集；有漏斗，才有资格谈「最佳实践」。
4. 决策点必须持久化到机会点方案文档
人与 AI 脑暴中的关键决策、人与人切磋达成的共识，都要回写到机会点方案文档——而且要跟着漏斗层级走：Pair 稿、组级方案、全场定稿，各自留下本层决策，避免「收敛时把理由弄丢了」。聊天记录会消失；文档才是真相源。
这条纪律同时促进两件事：人与 Agent 的决策性互动，以及人与人之间的切磋——争论可以热烈，但争论的结论要落盘。否则周五你得到的是一堆截图和「我们讨论过」。
5. 权重分析 + 关键角色输出专属方案
全场收敛（L3）不是简单投票。顾问需要识别端到端角色中的代表性组员，对每个 Pair / 各组输出的文档做权重分析：谁的约束更硬、谁的验收更真、谁的路径更可落地。与此同时，仍要邀请工作坊中的端到端关键角色，围绕每个机会点输出一份专属的机会点方案。
Pair 与组级文档是漏斗原料；关键角色终稿是定稿前的责任锚点。两者都要，缺一不可——否则要么只有热闹的草稿，要么只有权威却未经碰撞的单方方案。
6. 所有机会点方案最终串成完整 Playbook
零散的机会点方案不是终点。工作坊的关键输出，是一份把机会点串起来的端到端 Playbook：谁在什么阶段做什么、用什么规格与工具、如何验证、如何回写资产。
对研发负责人而言，验收请看 Playbook，不要只看满意度问卷。问卷测的是体验；Playbook 测的是能不能带走。
7. 全局优化，而非局部优化——把人与 Agent 都当全栈通才
始终问：这是全栈最优，还是分角色最优？开发提速但测试更惨、规格更糊、发布更险，那不叫 AI4SE 成功，叫把瓶颈搬家。端到端最佳实践视角，可对照 AI4SE 端到端软件交付最佳实践。
更关键的一层：不要按「给开发的最佳实践 / 给测试的最佳实践 / 给 BA 的最佳实践」来设计机会点。 角色边界是组织分工的便利，不是 AI 时代优化的坐标系。工作坊要追求的是端到端链路的全局最优，而不是把旧岗位说明书翻译成一套套互不相通的 AI 技巧。
这意味着两种「通才」假设要同时成立：
| 对象 | 通才假设 | 实践含义 |
|---|---|---|
| 人 | 参与者按全栈通才来协作，而不是固守本岗话术 | 产品能碰验收与风险，开发能碰规格与可测性，测试能碰实现路径与发布约束——围绕机会点共担端到端结果 |
| Agent | 把 Agent 当全才协作者，而不是某个角色的专用外挂 | 同一 Agent 链路可以跨规格、实现、验证、文档与回流；不要先发明「BA-Agent / DEV-Agent / QA-Agent」再各自优化，最后发现接口对不上 |
入场时仍然需要端到端代表性角色在场（否则约束与验收会失真）；但优化设计时要淡化角色墙：机会点方案写的是「这条链路怎么更快、更稳、更可验证」，不是「这个岗位怎么更爽」。
一句话对照：
- 局部优化：为特定角色定制工具链与话术，岗位 KPI 好看，交接处照样堵。
- 全局优化：人当全才、Agent 当全才，对端到端一起改；角色负责提供视角与否决权，不负责把方案切成互不往来的领地。
局部最优可以庆祝；只有全栈最优才值得写进推广清单。
给研发负责人的三句话
- 工作坊买的不是培训课时，而是「端到端角色 + 真实项目」上的可验证路径。
- 验收看 Playbook，不看学员满意度问卷。
- 局部最优可以庆祝，全栈最优才值得推广——人当通才、Agent 当通才，优化端到端，而不是优化某个岗位。
一句话收束：选对人、钉住机会点、用 ORID 逼出决策、按 Pair → 组 → 全场漏斗收敛成 Playbook——让人与 Agent、人与人的共识，都落回同一份文档。