# 第 15 章 14 个技能全景图

## 本章目标

- **O1** 能够为“规划技能”“执行技能”“验收技能”分配责任人与接口（产物：技能选择地图）
  - 证据: 技能选择地图为“规划技能”“执行技能”和“验收技能”分别指定责任人
- **O2** 能够构造技能选择地图，标明信息、授权和证据如何跨接口传递（产物：技能选择地图）
  - 证据: 技能选择地图标出至少两个接口及其输入、输出和授权边界
- **O3** 能够按任务风险选择规划、执行或验收技能组合（产物：技能选择地图）
  - 证据: 产物为一个任务记录候选技能、选择理由和不用某技能的边界

## 学习路径

- **初学者**: 本章迁移任务是：能够按任务风险选择规划、执行或验收技能组合。先按图中的“接口网络”关系完成技能选择地图的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够按任务风险选择规划、执行或验收技能组合。提交技能选择地图后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 技能选择地图
- **图解类型**: skill-map
- **关系语义**: 两侧角色通过中央接口协作，底部条带约束负责人、接口和证据，连接不表示授权自动转移。
- **核心概念**: 规划技能 · 执行技能 · 验收技能

![第 15 章技能选择地图教学图](/learning/diagrams/zh/chapter-15.svg)

用技能选择地图追踪跨角色接口，明确责任、授权和证据何时转移。

图将“规划技能”与“验收技能”置于两侧，“执行技能”位于中央接口。箭头表示信息或工作交接，底部条带要求逐项标注负责人、接口和证据；连接存在不等于授权已经转移。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

### 15.1 为什么需要 14 个技能而不是 1 个

你同时接手了三个功能需求：一个需要重构历史代码，一个要从零开始，还有一个是第三方系统的迁移。你打开 AI 编码工具，却不知道该从哪个开始。更糟的是，你发现之前做的一个功能，AI 最近生成的代码和它之前写的不一致了——它似乎"忘记了"当初的设计约定。

你可能会想：一个六步工作法不是已经够用了吗？为什么需要 14 个技能？

答案是：六步工作法解决的是"一个功能怎么做"的问题，但实际项目面对的是"多个功能怎么一起做"的问题。这是两个完全不同的问题。

一开始，你可能只需要一个 Coach（流程教练），它引导你走完"拆解 → 下发指令 → 编码 → 验收 → 分支判断 → 更新图纸"这个六步循环。一个功能、两个功能、三个功能，这个流程都够用。

但当你手上有五个功能需要同时推进时，问题出现了。你发现 Coach 在一个功能上的对话，可能干扰了另一个功能的上下文。你验收完功能 A 后切到功能 B，发现 AI 在写 B 的时候，悄悄改掉了功能 A 的某个核心接口——因为它在 A 的对话里记住了 A 的接口定义，但在 B 的对话里完全不知道 A 的存在。

这就像团队扩张：一个 3 人团队不需要复杂的管理结构——每个人都知道别人在做什么；但当团队扩张到 30 人时，你需要分工——有人负责架构，有人负责执行，有人负责验收，有人负责管理进度。14 个技能不是 14 个独立的方法，而是一个有机协作的体系。每解决一个特定类型的问题，当问题变复杂时，你调用更高级的技能来应对。

### 15.2 四层结构：全自动构建（Job）→ 项目编排（Orchestrator）→ 核心执行 → 基础支撑

14 个技能不是平铺在一个平面上的，它们有明确的层次关系。这个层次关系不是凭空设计出来的，而是随项目实践演化沉淀的——当项目规模从小到大，你会自然发现需要这些层级。

<!-- code-example:chapter-15-E1 mode:reference -->
> **示例类型：参考。** 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。
```text
                    ┌─────────────────┐
                    │   全自动构建     │   第一层：全自动层
                    │    (Job)        │   "从零到部署"整条链
                    └────────┬────────┘
                             │
                    ┌────────┴────────┐
                    │   项目编排       │   第二层：编排层
                    │ (Orchestrator)  │   管理多个功能的顺序
                    └────────┬────────┘
                             │
       ┌─────────────────────┼─────────────────────┐
  ┌────┴────┐          ┌─────┴─────┐          ┌─────┴────┐
  │ 需求分析 │          │ 自动工作流  │          │  监理验收  │   第三层：核心执行层
  │ (Req.)  │          │ (Workflow) │          │(Inspector)│   日常开发最常用
  └────┬────┘          └─────┬─────┘          └─────┬────┘
       │                     │                       │
  ┌────┴────┐          ┌─────┴─────┐                 │
  │ 架构设计 │◄─────── │  流程教练   │                 │   第四层：基础支撑层
  │ (Arch.) │          │  (Coach)   │                 │
  └────┬────┘          └───────────┘                 │
       │                                              │
  ┌────┴────┐          ┌──────┴──────┐                │
  │ 前端架构 │          │   质量保障    │               │
  │(Frontend)│         │    (QA)      │               │
  └─────────┘          └─────────────┘               │

辅助技能：
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│   顾问    │ │  代码克隆 │ │ 高保真原型│ │ 老系统还原│ │ 项目接续 │
│ (Advisor)│ │ (Cloner) │ │  (POC)   │ │ (Legacy) │ │  (Next)  │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
```

第一层：全自动构建（Job）。站在技能体系的最顶层。当你有"从零做一个完整项目"的需求时，连脚手架搭建、需求分析、架构设计这些前置工作都要自动化。Job 把"从零到部署"的整条链（脚手架搭建 → 需求分析 → 架构设计 → 前端设计 → 功能开发 → 集成验收 → 部署配置生成）封装成一个自动化流程。

第二层：项目编排（Orchestrator）。当你有 3 个、5 个、10 个功能需要实现时，问题不再是"怎么做一个功能"，而是"怎么安排这些功能的顺序"。Orchestrator 的职责不是写代码，而是管理"哪个功能先做、哪个功能后做、功能之间依赖什么"。它像项目经理一样，把多条并行的工作流串成一条有序的流水线。

第三层：核心执行层。这是日常开发中最常用的三个技能：需求分析（Requirements）——把模糊的需求变成结构化的功能列表和数据模型；自动工作流（Workflow）——自动完成一个功能的编码、验收、固化；监理验收（Inspector）——检查代码是否符合蓝图。

第四层：基础支撑层。架构设计（Architect）——在编码开始前产出蓝图；流程教练（Coach）——引导开发者走完六步工作法；前端架构（Frontend Architect）——前端专属的架构设计；质量保障（QA）——全面的测试策略和质量门禁。

辅助层：特殊场景技能。顾问（Advisor）——遇到技术决策时提供分析；代码克隆（Cloner）——复用现有代码模式；高保真原型（POC）——先出原型再开发；老系统还原（Legacy Recon）——从老系统重建；项目接续（Next）——接手半成品项目。

### 15.3 技能的触发条件与选择决策树

触发条件速查表：

| 触发条件 | 该用哪个技能 |
|---------|------------|
| "从零做一个 XXX" | Job（全自动构建） |
| "开始做这个项目"（蓝图已就绪） | Orchestrator（项目编排） |
| "完整实现这个功能" | Workflow（自动工作流） |
| "开始开发这个功能" | Coach（流程教练） |
| "帮我设计系统" | Architect（架构设计） |
| "帮我设计前端信息架构、页面状态与组件边界" | Frontend Architect（前端架构） |
| "验收代码" | Inspector（监理验收） |
| "帮我分析需求" | Requirements（需求分析） |
| "这个技术方案怎么选" | Advisor（顾问咨询） |
| "这个项目别人做的，我接过来" | Next（项目接续） |
| "老系统要迁移" | Legacy Recon（老系统还原） |
| "先做个原型看看效果" | POC（高保真原型） |
| "按这个现有代码的风格实现" | Cloner（代码克隆） |
| "全面测试一下" | QA（质量保障） |

技能选择决策树：

<!-- code-example:chapter-15-E2 mode:pseudocode -->
> **示例类型：伪代码。** 伪代码，不可直接执行。它只表达判断顺序，实施时必须补齐真实接口、权限与错误处理。
```text
开始一个新项目？
├─ 是 → 需要完整从零到部署？
│   ├─ 是 → 全自动构建（Job）
│   └─ 否 → 架构设计（Architect）→ 项目编排（Orchestrator）
│
├─ 实现一个新功能？
│   ├─ 需求明确，想全自动完成 → 自动工作流（Workflow）
│   ├─ 需要引导，边做边学 → 流程教练（Coach）
│   └─ 有多个功能要安排 → 项目编排（Orchestrator）
│
├─ 检查代码质量？
│   ├─ 常规验收 → 监理验收（Inspector）
│   └─ 全面测试 → 质量保障（QA）
│
├─ 遇到决策困难？
│   └─ 顾问咨询（Advisor）
│
├─ 特殊场景？
│   ├─ 要先看效果 → 高保真原型（POC）
│   ├─ 参考已有代码 → 代码克隆（Cloner）
│   ├─ 迁移老系统 → 老系统还原（Legacy Recon）
│   └─ 接手半成品 → 项目接续（Next）
│
└─ 需求模糊？
    └─ 需求分析（Requirements）
```

### 15.4 技能成熟度模型（L0–L4）与投资优先级

为什么需要成熟度模型？因为"知道"和"做到"之间有很大的差距。你可能已经制定了蓝图规范，但团队是否真的在遵守？如果没有量化的评估，你只能靠感觉——而感觉往往不准。

成熟度模型把"掌握程度"分为五个级别：

| 级别 | 描述 | 标志 |
|------|------|------|
| L0：未使用 | 团队不知道或不使用这个技能 | 没有相关流程和工具 |
| L1：尝试使用 | 团队开始尝试，但使用不频繁 | 有个别成员在使用 |
| L2：规范使用 | 团队有明确规范，大部分成员在遵循 | 规范文档、定期检查 |
| L3：优化使用 | 团队在使用的过程中不断优化流程 | 有复盘和改进机制 |
| L4：自动化 | 流程被工具自动化，不需要人工干预 | 自动化检查、自动报告 |

投资优先级（资源有限时的投入顺序）：

- 第一优先级（必须建立）：Architect——没有蓝图，AI 编码就没有方向；Inspector——没有验收，AI 编码的质量就不可控。在团队推广 AI 编码之前，先建立蓝图和验收的规范。
- 第二优先级（尽快建立）：Workflow——需求明确时大幅减少人工介入；Advisor——帮助团队解决技术决策困难，减少决策阻塞。
- 第三优先级（逐步建立）：Orchestrator——适合多功能项目；QA——验收体系成熟后建立；Requirements——项目复杂度高时引入。
- 第四优先级（按需建立）：Cloner、POC、Legacy Recon、Next、Job、Coach、Frontend Architect——特定场景下使用，按需引入。

这里要区分两张不同的地图，避免把“重要”误读成“核心执行”。

| 维度 | 它回答的问题 | Advisor 的位置 |
|------|--------------|---------------|
| 技能分类 / 技术分层 | 这个技能在交付链条中承担什么结构性角色？ | 辅助技能：在出现技术决策阻塞时提供选项、取舍和反证，不替代需求、实施或验收。 |
| 投资优先级 | 资源有限时，团队应先把哪项能力练到可用？ | 可列为第二优先级：决策阻塞会拖慢执行；这说明它值得早投入，不改变其辅助分类。 |

因此，全景图中的 Advisor 保持在辅助层；优先级表谈的是导入顺序，不是技能层级或日常执行的中心性。

核心逻辑：治理型技能是"地基"，执行型技能是"上层建筑"。地基没打好就建上层建筑，楼会塌。（管理者视角的详细分类见第 34 章。）

四套流程模型——六步工作法、"三步走"、八阶段全自动构建、客户项目三阶段——的统一映射见第 27 章。

---

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-15.md`，写上版本、决定、证据和缺项。

从14个工程技能中为需求澄清、实施、架构审查、故障咨询各选一个，并列前置输入、输出、失败升级条件。

<!-- chapter-artifact-requirement -->
### 本章必交产物：技能选择地图

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: 技能选择地图为“规划技能”“执行技能”和“验收技能”分别指定责任人
- O2: 技能选择地图标出至少两个接口及其输入、输出和授权边界
- O3: 产物为一个任务记录候选技能、选择理由和不用某技能的边界

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

Requirements需要场景与冲突，Workflow需要已确认蓝图，Inspector需要差异和验收标准，Advisor需要症状与复现。先检查技能实际可用性，不把14个工程技能与站点22个技能混为一个总数。成熟度表是本课程工具，不是行业认证。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

技能选择地图是课程内部教学方法，不是行业标准或外部实证结论；示例数字与情境仅用于练习，实际使用前必须验证。