[research@ai4se] : ~ $ ▌
cd ../
[methodology] | | 11 min

# 把 AI4SE 当业务来做：双钻找问题，Spec 定真相，Skill 分摊职责

把 AI4SE 当成业务来做，交付物就不应停在 PPT。咨询项目可用 Spec Driven Development 的思路实施：先用 Design Thinking / Double Diamond 跑通痛点、机会点、方案的发散收敛，再把 IT4IT 相关 Specification 梳清，最后 Agentic / Skill 化——早期以原子 Skill 为主，Goal 驱动地收敛成 Agent，并辅以 Command、Hook、MCP。真正的难点在问题定义与方案收敛。

[pilot-transformation][sdd][design-thinking][ai4se-framework]

很多不懂咨询的同行——技术开发出身，或培训出身——很容易把市面上某种「权威答案」视若珍宝：一套开源工具、一门热门课程、某个标杆案例里的 Agent 栈。小团队照搬，有时还能凑合跑起来；换到中小型组织，这种拿来主义往往很快栽跟头。

原因不复杂：组织有自己的固有逻辑，有角色职能与协作惯性。别人的答案解决的是别人的问题。AI4SE 转型必须重新探索适应本组织的道路——不能带着答案直接上，更不能把「用了哪个 Agent / 哪套课」当成交付。客户真正买的是可验证的工作方式变更：哪条价值流更顺、哪段人机交接可验收、哪套资产下周还能复用。站内谈过的 工作坊三种翻车，根子多半也在这里：热闹结束，留下的仍是别人的工具记忆，而不是自己的经营路径。

主旨：经营一条 Spec 流水线

把 AI4SE 当业务来做，就要有价值链、规格和可交付资产，而不是一堆演示脚本。

The Open Group 的 IT4IT 把自己定位为 managing the business of IT——管理「IT 这件事」的参考架构与价值流。咨询侧同理：先把研发/交付业务里该说清的 Specification 梳出来，再谈自动化与 Agent；否则 Agent 只是在执行「它以为的目标」。

一句话公式：

双钻节奏 × IT4IT Spec × 资产化（Skill / Agent / …）= 可经营的 AI4SE 咨询

这正是把 Spec-Driven Development 从「写代码前先写 Spec」抬到咨询交付层：咨询项目本身也可以 Spec Driven——规格是工作方式与价值流的真相源，Agentic / Skill 化是后半程落地。

组织级试点框架见 中大型研发组织 AI4SE 试点转型；本文补的是咨询怎么把那条链经营起来。

三套框架各管一层

不必把 Double Diamond、IT4IT、SDD 揉成一个新名词。它们叠在不同层：

框架管什么在咨询里的产物
Double Diamond发散 / 收敛节奏痛点清单 → 问题定义；机会点 → 方案筛选
IT4IT「IT 业务」参考架构与价值流端到端能力与数据对象地图（Specification 骨架）
SDDSpec 作为真相源与门禁可评审、可验收、可交给 Agent 的 Spec

Design Council 的 Double Diamond 强调：先理解问题，再给答案——第一钻是问题域，第二钻才是方案域。站内 Design Thinking：双钻定节奏，模板定形状 已把节奏、模板、AI 脑暴三层叠架讲清；本文只借用其节奏纪律。

SDD 一侧，Thoughtworks / Fowler 圈层常把实践放在光谱上：spec-first → spec-anchored → spec-as-source。咨询项目多数停在 spec-first / spec-anchored 就够用——规格要能评审、能改、能当试点门禁；不必迷信「人永远不碰生成物」的 spec-as-source。

流水线一：痛点 → 机会点 → 方案

顺序不能跳。跳过问题定义直接选型，等于第二钻空转。

阶段在做什么典型产出
Discover访谈、现状价值流、摩擦点（IT4IT 各流上「哪里断了」）原始痛点与证据
Define第一难收敛：写成可辩论的问题陈述谁、何痛、何证据、何成功标准、明确不解决什么
Develop机会点并列：加速哪段人机交接、哪段可 Skill 化候选机会点墙 / 电梯演讲组
Deliver第二难收敛：选可试点的 solution slice1–2 个带边界的试点切片 + 初版 Spec

实践上，工作坊的 Pair → 组 → 全场漏斗 就是把这两次收敛做硬：决策必须持久化，不能停在便利贴。电梯演讲、用户旅程等模板提供 exit criteria——形状不清，多轮脑暴也对不齐「什么叫说清楚了」。

节奏口诀：发散时禁止选型；收敛时禁止加范围。

流水线二：梳清 IT4IT Spec（咨询版 SDD）

代码侧 SDD 的 Spec 是功能与设计真相；咨询侧 Spec 是工作方式与价值流真相。

一页可用的咨询 Spec，至少要能回答：

槽位问题
价值流段落落在哪段交付链？上下游交接是什么？
角色与职责人保留什么定义权与否决权？
输入 / 输出 / 门禁什么齐了才能往下走？
人机边界哪些可脚本 / Skill / Agent，哪些必须人判
验收证据怎样算试点成功——可复现、可度量

「变更走规格」同样适用：试点范围变了，先改 Spec，再改 Skill / Agent，避免演示驱动漂移。只有工具清单、没有 Spec，就会掉进 人定义、机执行 里写过的坑——机器在规模化执行从未被说清的流程。

流水线三：职责分摊与资产演进

Agentic / Skill 化，本质是把已经界定清楚的人类职责逐步分摊给 AI。载体通常是 Skill 或 Agent；在 coding agent 生态里，还会沉淀 Command、Hook，以及 MCP 这类连接资产。

阶段载体何时用
早期Skill（原子能力包）流程可描述、触发面窄、验证可写清
收敛Agent（Goal 驱动）多步闭环、需自主规划，但仍有人验收
配套Command / Hook确定性门禁与重复动作——模型不该「记得去做」的事
连接MCP外部系统访问（工具与数据），不是方法论本身

它们是组合关系，不是互斥选型：

  • Skill 回答「怎么做才符合我们的方法」——见 Skills 九型分类
  • MCP 回答「能不能够到那个系统」——见 MCP 标准接口
  • Hook 回答「这件事必须发生，模型不能跳过」
  • Agent 回答「在清晰 Goal 下，谁在隔离上下文里跑完闭环」

早期以 Skill 为主，是为了控制爆炸半径：原子能力可评审、可替换、失败面小。Goal 与验收清晰之后，再 Goal 驱动地收成 Agent——不是一上来就堆「全能协作者」，而是职责清晰后再放大自治。

挑战落点：两处收敛

全程都在发散与收敛，但项目翻车几乎都出在 Define 问题 与 Deliver 方案。

信号多半意味着
还在比模型 / 插件，没有「我们不解决什么」Define 未完成
机会点墙贴满，没有带 Spec 与资产边界的试点切片Deliver 未完成
Skill 无限增殖，没有 Goal 与验收资产化空转，未收敛到 Agent 或可运营能力
把 MCP 或某 Agent 产品当成 solution 本身跳过了 Spec，第二钻被工具绑架

把节奏钉住：第一钻收敛前，禁止深度选型；第二钻收敛时，只带走 1–2 个切片，其余进 backlog。漏斗与 ORID 之类的过程纪律，是为了让共识落回同一份 Spec，而不是落回会议室气氛。

反模式与最小动作

反模式

  • 把 PPT 当交付，试点结束无 Spec、无资产、无验收证据
  • 先买 Agent / 平台，再回头找痛点
  • Skill 只增不减，没有 Goal 驱动的收敛
  • 本该 Hook 的确定性门禁，写成「请记得跑 lint」的 Skill
  • 把 MCP 连接数或 Agent 数量当成成功指标

本周最小动作

  1. 选一条真实价值流上的摩擦点
  2. 写一页问题定义（含「不解决什么」）
  3. 补半页咨询 Spec（人机边界 + 验收证据）
  4. 做一个 Skill 级试点（能复现、能评审）
  5. 定下周是否 Goal 化成 Agent——用证据，不用感觉

一句话收束：把 AI4SE 当业务来做，就是经营 Spec 流水线——双钻找对问题，IT4IT Spec 定真相，再把人类职责分摊到 Skill、Agent 与配套资产上；难的从来不是发散，而是两次收敛。

参考与相关阅读