第10章 AI 能力编排

第09章讲了能力矩阵：你先盘点自己能调用哪些人、工具、知识和渠道。但矩阵只解决「有什么」，不解决「怎么让它们协同产出」。本章解决的问题是：把 AI 从一次性问答工具，变成可组合、可复用、可验证的能力系统。第11章会继续往前走，把这些编排沉淀成资产，让工作流本身开始复利。

10.1 结论先行：AI 不是员工，也不是搜索框，而是一组可编排能力

**AI 能力编排（AI Capability Orchestration）**的核心结论很简单：你的竞争力不是会问 AI，而是能把 AI 能力封装成流程。会问 AI 的人，得到一次答案；会编排 AI 的人，得到一条可重复交付的生产线。

这直接呼应第01章的公式一和公式三：

公式一 · 杠杆率 = 你编排的 AI 能力数量 × 每个能力被复用的次数
公式三 · 复利资产 = 一次生产 × N 次复用

AI 能力编排的目标：
一次 prompt → 可复用 skill → 可执行 workflow → 可售卖产品

如果你只是打开一个聊天框，输入「帮我写一个方案」，那 AI 只是你的临时外脑。它能让你快一点，但不会改变你的生产结构。真正的变化发生在你把一次成功经验拆成固定步骤、输入规范、输出格式、验证标准、失败处理，然后让它在下一个项目继续被调用。

一人公司不能靠临场发挥扩张。 你没有团队冗余，没有管理层，没有专门的 QA、产品、运营和交付经理。你能放大的只有两件事：一是 AI 能力，二是流程复用。AI 能力编排就是把这两件事接起来。

理解这一点后，本章其余都在回答一个问题：怎样把「我会用 AI」升级为「我能用 AI 编排一条可交付、可验证、可沉淀的流程」？

10.2 AI 能力编排是什么：定位、能力与边界

AI 能力编排不是把所有事扔给 AI，也不是收藏更多工具。它是一种工程方法：把目标拆成多个能力单元，为每个单元定义输入、输出、工具、验证和沉淀方式，再由你控制方向与验收。

与常见误解的差异

维度	搜索框式使用	员工式幻想	能力编排
对 AI 的定位	查资料、要答案	替你负责结果	可组合能力单元
人的角色	提问者	甩手掌柜	方向设定者、流程设计者、验收者
输出形态	一段文本、一个建议	不稳定的「半成品」	可验证的阶段产物
复用方式	每次重新问	依赖记忆和运气	prompt / skill / workflow / agent 沉淀
主要风险	答案过时或浅	方向失控、质量失控	编排成本和验证成本
适用场景	临时查询	低风险杂活	重复交付、研究、写作、开发、运营

搜索框式使用的问题是太碎。你问一次，它答一次；下一次你又从零开始。它没有结构，没有上下文沉淀，没有验收标准。

员工式幻想的问题更危险。很多人把 AI 想象成一个会主动负责的员工，于是把「定义问题、判断方向、验收质量」也交出去。结果是 AI 看似忙碌，产物却偏离目标。AI 可以补细节，但不能替你承担商业判断。

能力编排的优势在于边界清晰：你定义目标，AI 处理可拆分的认知劳动；你设计流程，AI 执行其中的局部步骤；你验收结果，AI 根据反馈迭代。它不是「人少做事」，而是「人只做不可让渡的事」。

能做什么

1. 信息压缩 — 把大量资料压缩成结构化摘要、对比表、决策依据。
2. 方案生成 — 基于约束生成多个可选方案，而不是只给一个灵感答案。
3. 代码与文档生产 — 在明确需求、结构和验收标准后，生成可运行代码或可发布文档。
4. 角色化审查 — 让不同 Agent 从产品、技术、风险、交付角度交叉检查。
5. 流程自动化 — 把重复任务封装成 skill、脚本、模板或 workflow。
6. 资产沉淀 — 把一次交付后的 prompt、检查表、失败案例转成下次可复用资产。

不能做什么（边界）

• 不能替你判断真实需求 — AI 可以帮你整理访谈、提炼痛点，但「这个需求值不值得做」必须由你基于场景和约束判断，见第02章到第08章。
• 不能替你承担交付责任 — 客户、用户和市场只认结果，不认「AI 这么说」。交付责任永远在人。
• 不能自动保证事实正确 — AI 生成的事实、引用、代码、预算、时间估算都要验证。
• 不能替你沉淀资产 — AI 可以生成文档，但「哪些东西值得沉淀、沉淀到哪里、以后怎么复用」是你的系统设计。
• 不能越过安全红线 — 凭据、生产数据、客户隐私、破坏性操作、发布动作必须人审，不能交给自动流程默认执行。

10.3 AI 能力编排的核心拆解：从目标到能力流水线

AI 编排不是「写一个更长的 prompt」。它是把任务从一个黑箱，拆成一组可观察、可替换、可验证的节点。

业务目标
  │
  ▼
范围定义 ──→ 能力拆分 ──→ 工具匹配 ──→ 执行编排 ──→ 人审验收 ──→ 资产沉淀
  │             │             │             │             │             │
做什么        谁来做        用什么        怎么串起来     对不对        下次怎么复用
  │             │             │             │             │             │
需求文档      能力单元表     Claude Code   workflow       checklist     skill/SOP/模板

这张图的关键不是中间的工具，而是两端：范围定义和资产沉淀。没有范围，AI 会高效跑偏；没有沉淀，AI 只是让你这次快一点，下次仍然从零开始。

10.3.1 第一步：把目标写成可验收范围

编排的起点不是 prompt，而是范围。你要先回答四个问题：

任务范围四问：
1. 最终交付物是什么？
2. 使用者是谁？
3. 成功标准是什么？
4. 哪些事情明确不做？

比如「帮某个小团队做一个内部知识库」不是可编排范围。它太大、太虚、不可验收。改成下面这样，才具备编排条件：

交付物：一个可本地运行的知识库问答 demo
使用者：10 人以内的小团队，用来查询内部制度和流程
成功标准：导入 20 份文档后，能回答 30 个高频问题，人工抽检正确率 ≥ 80%
不做范围：不接入真实生产账号；不处理敏感个人信息；不做复杂权限系统

范围写清楚后，AI 才能被约束。否则它会默认补全缺失条件，而这些补全往往不是你想要的。

10.3.2 第二步：把任务拆成能力单元

能力单元不是岗位，而是可被调用的动作。一个交付任务通常可以拆成下面六类：

能力单元	回答的问题	典型 AI 角色	输出物	验证方式
需求澄清	到底做什么	产品分析 Agent	范围说明、验收标准	人审 + 用户确认
资料整理	已知信息有哪些	Research Agent	摘要、证据表、风险清单	来源核查
方案设计	怎么做最合适	Architect Agent	架构图、模块拆分	约束对照
内容/代码生成	把方案变成产物	Writer / Coder Agent	文档、代码、配置	运行测试、人工审阅
质量审查	哪里可能错	Reviewer Agent	缺陷列表、修改建议	复核与回归验证
沉淀复用	下次怎么更快	Librarian Agent	skill、SOP、模板、案例	复用一次验证

注意：能力单元不是越多越好。 你拆分能力，是为了降低单点失控，不是为了制造复杂系统。一个 2 小时任务不需要 8 个 Agent；一个 2 周交付如果只有一个 prompt，才是失控。

10.3.3 第三步：给每个能力单元定义输入输出

AI 编排失败，常见原因不是模型不够强，而是输入输出没有约束。你要为每个能力单元写清楚三件事：

能力单元定义模板：

名称：____
目标：这个单元只解决什么问题？
输入：它需要哪些资料、约束、上下文？
输出：必须产出什么格式？表格、清单、代码、报告还是决策建议？
验收：怎样判断输出可用？
失败处理：输出不合格时，返工、换 Agent、还是人工接管？
沉淀方式：是否转成 prompt / skill / SOP / 案例？

这个模板看似啰嗦，但它决定了 AI 是生产力还是噪音。你不给输出格式，AI 就会给你一段漂亮但不可执行的文字；你不给验收标准，AI 就会把「说得通」伪装成「做得对」。

10.4 四级跃迁：从 prompt 到 skill 到 workflow 到产品

AI 能力编排有四个层级。每升一级，复用能力更强，但设计成本也更高。你不需要一开始就做产品，正确路径是从一次成功的 prompt 开始，逐级固化。

Level 1: Prompt   →  一次有效调用
Level 2: Skill    →  一个可复用能力
Level 3: Workflow →  一条可执行流程
Level 4: Product  →  一个可交付系统

10.4.1 Level 1：Prompt 是实验，不是资产

prompt 的价值在于快速试错。它适合探索问题、生成初稿、比较方案、找边界。它的问题是稳定性差：同一个 prompt，换一个上下文、换一个输入质量，输出可能大幅波动。

所以你要把 prompt 当成实验记录，而不是最终资产。一个 prompt 只有满足三个条件，才值得进入下一层：

• 重复出现：这个任务不是一次性的，未来还会遇到。
• 结果稳定：同类输入下，输出质量大体可控。
• 边界清楚：你知道它擅长什么、不擅长什么。

如果一个 prompt 只用一次，不要急着封装。过度封装会把你拖进维护泥潭。

10.4.2 Level 2：Skill 是封装后的能力单元

skill 的本质是把「怎么做某类任务」写成可调用说明。它不是神秘功能，而是带触发条件、步骤、约束和验证方式的能力说明书。

一个好的 skill 至少包含四部分：

Skill 最小结构：
1. When to Use：什么时候应该调用，什么时候不该调用。
2. Process：执行步骤，先做什么，后做什么。
3. Constraints：限制条件，尤其是安全、格式、范围边界。
4. Verification：完成后怎样验证结果。

当你发现自己第三次写同一种 prompt，就该考虑把它升级成 skill。比如：用户访谈整理、竞品分析、代码审查、交付验收、文档发布、数据清洗、知识库构建。它们都是重复出现、边界清晰、可写成流程的任务。

铁律：不要收藏 prompt，要沉淀 skill。prompt 解决一次问题，skill 复用一种能力。

10.4.3 Level 3：Workflow 是多能力协同

workflow 解决的是「多个能力如何按顺序协同」。它比 skill 更接近生产线：输入从一个节点流到下一个节点，每一步都有产物和检查点。

一个典型交付 workflow 长这样：

输入需求
  │
  ├─ Product Agent：澄清范围，写验收标准
  │
  ├─ Research Agent：收集资料，列证据和风险
  │
  ├─ Architect Agent：拆模块，定实现路线
  │
  ├─ Coder / Writer Agent：生成交付物
  │
  ├─ Reviewer Agent：按 checklist 审查
  │
  └─ Human：最终验收、定稿、归档

Workflow 的重点不是自动化率，而是可控性。每个节点都要留下中间产物，这样你才能发现错误发生在哪一环。如果所有步骤都塞进一个超长 prompt，最终结果错了，你不知道该改需求、改资料、改方案，还是改生成。

10.4.4 Level 4：Product 是被外部用户使用的封装

当一个 workflow 被反复使用、边界稳定、结果可预期，就有机会升级为产品。产品不是「把 prompt 包个网页」，而是把一条能力链路封装成用户可理解、可支付、可持续使用的系统。

从 workflow 到 product，至少要补四件事：

从 workflow 到 product	需要补齐的能力	为什么必要
输入界面	表单、上传、配置项	用户不能直接读你的内部流程
状态管理	进度、失败重试、历史记录	用户需要知道任务跑到哪了
质量控制	校验、审查、人工确认	产品必须稳定，不能靠运气
商业闭环	定价、交付、售后、复购	没有商业闭环就只是工具玩具

这就是第18章和第19章会继续展开的主题：工作流产品化和Agent 产品骨架。本章先把底层编排方法讲清楚，后面再讲怎么把它变成可卖的产品。

10.5 实战：把一个交付任务拆成 AI 编排流程

下面给一个脱敏场景：你要为一个小型团队交付「内部资料问答 demo」。不涉及真实平台、凭据、生产数据和客户信息，只保留可迁移的工程范式。

步骤一：定义交付范围

先用范围模板锁住任务边界：

项目名称：内部资料问答 demo

最终交付物：
- 一个可本地运行的 demo
- 一份使用说明
- 一份测试问答集
- 一份风险与后续迭代建议

输入资料：
- 脱敏后的制度文档 / FAQ / 流程说明
- 用户提供的高频问题列表

验收标准：
- 能成功导入指定资料
- 能回答约定问题集中的问题
- 回答必须标注依据来源
- 对资料中不存在的问题明确说不知道
- 不接入生产凭据，不处理敏感个人信息

不做范围：
- 不做复杂权限系统
- 不做生产级高可用部署
- 不承诺替代人工审核

这一步必须由人主导。AI 可以帮你润色范围，但不能替你决定范围。范围一旦模糊，后续所有自动化都会放大模糊。

步骤二：拆成能力单元

把交付拆成 7 个节点，每个节点有明确责任：

节点	AI 能力	输入	输出	人审点
1	需求澄清	初始描述、约束	范围文档、验收标准	必须人审
2	资料整理	脱敏文档	文档清单、结构摘要	抽查来源
3	问答集设计	高频问题、资料摘要	测试问题、期望答案	确认覆盖面
4	技术方案	约束、目标	模块设计、实现步骤	确认可实现
5	代码生成	技术方案	demo 代码、说明	本地运行
6	质量审查	代码、问答集	bug 列表、风险清单	决定是否修复
7	资产沉淀	全部产物	SOP、模板、案例摘要	归档复用

这里最容易犯的错是把第 1、6、7 节点省掉：不澄清范围就开写，不做审查就交付，不做沉淀就结束。省掉这三步，表面上快，实际会让第01章的公式二和公式三断裂：交付闭环不完整，复利资产为零。

步骤三：为每个节点写 prompt / skill 规格

不要只写一句「请帮我分析」。用规格化输入约束 AI：

节点名称：资料整理 Agent

任务目标：
把用户提供的脱敏资料整理成可供后续问答系统使用的结构化资料索引。

输入：
- docs/ 目录下的脱敏文档
- 项目范围说明
- 不处理敏感个人信息的约束

输出格式：
1. 文档清单表：文件名 / 主题 / 适用对象 / 关键条款 / 风险备注
2. 主题索引：按业务主题归类
3. 缺口清单：资料中缺失但验收问题可能涉及的内容

验证标准：
- 每条摘要能追溯到原文位置
- 不编造资料中不存在的信息
- 对不确定内容标注「需人工确认」

失败处理：
- 如果资料不足，停止生成方案，先输出缺口清单
- 如果发现敏感信息，停止处理并提示人工脱敏

这个规格可以直接沉淀成 skill。下一次做类似知识库、FAQ、制度问答、产品手册问答时，只改输入资料和验收标准，不需要重写方法。

步骤四：设置人机分工

AI 编排的正确分工是：人定方向、机器填细节、人审结果。

人负责：
- 选择要解决的问题
- 定义交付范围和不做范围
- 判断用户是否认可
- 审查风险与质量
- 决定哪些资产值得沉淀

AI 负责：
- 整理信息
- 生成初稿
- 比较方案
- 编写代码/文档
- 执行 checklist
- 根据反馈修改

这不是保守，而是责任边界。AI 的强项是高密度处理细节；人的强项是判断目标是否值得、结果是否可接受、风险是否可承受。把方向交给 AI，是把一人公司的方向盘拆掉。

步骤五：加入验证与回滚点

每个 workflow 都要有验证点。没有验证点的 AI 流程，只是自动化幻觉。

验证点设计：

V1 范围验证：
- 交付物是否一句话说清？
- 验收标准是否可测试？
- 不做范围是否写明？

V2 资料验证：
- 摘要是否可追溯来源？
- 是否出现编造事实？
- 是否有敏感信息未脱敏？

V3 实现验证：
- demo 是否能本地运行？
- 核心路径是否跑通？
- 失败输入是否有明确提示？

V4 交付验证：
- 问答集是否逐条测试？
- 风险是否写入说明？
- 交付物是否归档？

验证：这个实战流程是否合格，只看三个结果：第一，交付物能否按验收标准运行；第二，中间产物能否追溯；第三，流程能否被下一次复用。如果只有第一个成立，你只是完成了一次项目；三个都成立，才完成了 AI 能力编排。

失败边界（逐项排查）：

症状	根因	处理
AI 输出很多但无法交付	范围没锁定，输出格式不明确	回到步骤一，重写交付物和验收标准
结果看似完整但事实错误	没有来源追溯和抽查	增加资料验证节点，强制标注依据
代码能生成但跑不起来	技术方案缺少运行环境约束	在方案节点补环境、依赖、启动和测试要求
每次项目都重新设计流程	没有沉淀 skill / SOP	交付后强制做资产沉淀节点
Agent 之间输出接不上	输入输出格式不一致	为每个节点定义固定 schema 或表格格式

10.6 Claude Code / Skills / Workflow / Agent：角色分工与选型

在一人公司的 AI 编排里，Claude Code、Skills、Workflow、Agent不是同一种东西。混用概念会直接导致系统失控。

组件	本质	适合解决	不适合解决	你的控制点
Claude Code	执行与编排环境	读写文件、运行命令、调用工具、协调任务	替你决定商业方向	权限、文件、验证命令
Skill	可复用能力说明	重复任务的方法封装	一次性临时任务	触发条件、步骤、验证
Workflow	多步骤流程	端到端交付、发布、审查	单个小动作	节点顺序、输入输出、回滚点
Agent	角色化执行者	并行研究、审查、生成、复核	无边界自主决策	任务边界、上下文、汇总标准

10.6.1 Claude Code：不是聊天框，是工程操作台

Claude Code 的价值不只是回答问题，而是把 AI 接到真实工程环境里：读文件、改文件、运行验证、调用工具、协调子任务。它适合作为一人公司的「工程操作台」。

但工程操作台不是自动驾驶。你要用它做三件事：

• 把上下文放进项目：用 AGENTS.md、需求文档、checklist 约束产出。
• 把验证放进流程：写完不是结束，跑测试、查链接、验收输出才是结束。
• 把经验放回文件：成功流程沉淀成 skill、SOP、模板或项目规范。

10.6.2 Skills：把重复能力做成插拔模块

Skills 适合封装稳定方法。判断一个任务是否值得做成 skill，用下面的规则：

Skill 封装判断：
- [ ] 过去 30 天是否出现 ≥3 次？
- [ ] 每次步骤是否大体相同？
- [ ] 是否有明确输入和输出？
- [ ] 是否能写出失败边界？
- [ ] 是否能定义验证方式？

满足 4 项以上 → 封装成 skill
少于 4 项 → 继续用 prompt 试错

不要把所有 prompt 都升级成 skill。skill 太多但不用，会变成另一种工具收藏癖。你的目标不是「拥有很多技能」，而是「少数高频技能被反复调用」。

10.6.3 Workflow：把能力串成可交付闭环

Workflow 的判断标准只有一个：它能不能稳定完成一个端到端目标。 如果只是「整理一份资料」，那是 skill；如果是「从资料整理到 demo 交付再到验收归档」，那是 workflow。

Workflow 必须包含四类节点：

Workflow 四节点：
1. Scope：范围定义
2. Build：实现产物
3. Verify：验证质量
4. Archive：沉淀资产

这其实是在把第01章公式二「交付闭环」嵌入 AI 编排。没有 Verify 的 workflow，只是自动生成；没有 Archive 的 workflow，只是一次性劳动。

10.6.4 Agent：角色化，不是人格化

Agent 的本质不是「像人一样工作」，而是带角色、目标、边界和工具权限的执行单元。你不需要把 Agent 想象成员工，更不要给它模糊职位，比如「你是我的全能 CEO」。这种设定只会放大不确定性。

更好的 Agent 定义方式是：

Agent 定义模板：
角色：Research Agent
目标：只负责收集和整理资料，不做最终决策
输入：需求范围、资料来源、禁止事项
输出：证据表、观点分歧、风险清单
禁止：编造来源；接触敏感凭据；越权修改文件
验收：每条结论都有来源或明确标注不确定

Agent 要角色化，但不要人格化。角色化是为了分工；人格化会让你误以为它真的理解责任。

决策树

现在这个任务应该用什么？
│
├─ 只做一次、还在探索
│  → 用 prompt
│
├─ 高频重复、步骤稳定
│  → 封装成 skill
│
├─ 多步骤端到端交付
│  → 设计 workflow
│
├─ 可并行、需不同视角
│  → 拆给多个 Agent
│
└─ 已稳定复用且有人愿意付费
   → 产品化

10.7 失败边界：四种最常见的死法

AI 能力编排的失败，通常不是因为 AI 不够强，而是因为人把边界、验证和沉淀丢了。

死法一：工具崇拜，能力矩阵变工具清单

症状：你订阅很多 AI 工具，收藏很多插件，研究很多模型，但没有稳定交付能力。每次看到新工具都觉得「这次可以起飞」，两周后又换下一个。

根因：把工具数量误认为杠杆率。第01章说过，杠杆率是「能力数量 × 复用次数」，不是「工具数量」。没有复用次数，再多工具也是噪音。

对抗策略：建立工具准入规则：任何新工具必须绑定一个高频 workflow，并在 30 天内复用 5 次。否则不纳入你的能力矩阵。

死法二：完全放手，把方向盘交给 AI

症状：你让 AI 自己定需求、自己做方案、自己写交付、自己判断质量。产出很多，但方向漂移，最后你还要花大量时间返工。

根因：把 AI 当员工，甚至当负责人。AI 没有你的商业上下文、风险偏好、客户关系和长期目标。它会优化「看起来完成任务」，不一定优化「真的解决问题」。

对抗策略：明确三个人审点：范围必须人审，风险必须人审，最终交付必须人审。中间过程可以自动化，方向和验收不能外包。

死法三：无验证，生成即交付

症状：AI 生成文档很漂亮，代码也很完整，但一用就错。客户或用户第一次反馈就是 bug、事实错误、遗漏边界。

根因：把「生成」当成「完成」。AI 降低了生产成本，也降低了垃圾产出的成本。没有验证，产出越快，风险越大。

对抗策略：给每类任务配置最小验证：写作要事实核查，代码要运行测试，研究要来源表，方案要约束对照，交付要验收清单。

死法四：无沉淀，每次都是新项目

症状：你确实用 AI 做得更快了，但每次开新项目仍然要重新写 prompt、重新想流程、重新做 checklist。半年后，你只是变成一个更快的计件工。

根因：公式三没有启动。你把 AI 用在生产环节，却没有把生产经验转成复利资产。

对抗策略：每个项目结束后做 30 分钟资产转化：保留一个 prompt、一个 skill 草稿、一个 checklist、一个失败案例、一个可复用模板。下次项目先翻资产库，再开新对话。

红线边界：不可让渡的决策

• 需求取舍：做什么、不做什么，必须由你根据真实场景判断。
• 商业承诺：价格、交付范围、周期、风险免责声明，必须人审。
• 凭据与数据：密钥、账号、客户隐私、生产数据不能交给不受控流程。
• 破坏性操作：删除、覆盖、迁移、发布、付款、对外发送必须二次确认。
• 最终验收：AI 可以给建议，但不能替你说「可以交付」。

铁律：AI 可以替你跑流程，不能替你承担后果。凡是后果由你承担的决策，都必须留在人手里。

10.8 小结 / 核心心法

AI 能力编排的终点，不是更会聊天，而是拥有一组可复用、可验证、可沉淀的生产流程。

1. AI 不是员工，也不是搜索框。它是一组可编排能力，必须被拆成输入、输出、验证和边界。
2. 从 prompt 到 skill 到 workflow 到 product，是 AI 能力从一次性使用到复利资产的四级跃迁。
3. 人定方向、机器填细节、人审结果，是最稳的人机分工。方向和验收不可外包。
4. Claude Code 是工程操作台，Skills 是能力封装，Workflow 是交付流水线，Agent 是角色化执行单元。概念分清，系统才不会乱。
5. 每个 AI 流程都要回到第01章三公式：提高杠杆率，补齐交付闭环，沉淀复利资产。

执行清单（每次设计 AI 编排流程前自检）：

• [ ] 我是否先写清了交付物、使用者、成功标准和不做范围？
• [ ] 我是否把任务拆成了可观察的能力单元，而不是塞进一个超长 prompt？
• [ ] 每个能力单元是否有明确输入、输出、验收和失败处理？
• [ ] 哪些步骤适合 prompt，哪些应该升级为 skill，哪些需要 workflow 或 Agent？
• [ ] 是否设置了范围、资料、实现、交付四类验证点？
• [ ] 是否明确了必须人审的决策：方向、风险、凭据、发布、验收？
• [ ] 项目结束后，我是否至少沉淀了一个 skill / SOP / checklist / 案例模板？
• [ ] 这个流程下次能否少改动复用？如果不能，问题卡在输入、输出还是验证？

---

上一章：第09章 能力矩阵 下一章：第11章 工作流即资产