第 15 章 14 个技能全景图

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

课程讲解

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

示例类型：参考。 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。

                    ┌─────────────────┐
                    │   全自动构建     │   第一层：全自动层
                    │    (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（质量保障）

技能选择决策树：

示例类型：伪代码。 伪代码，不可直接执行。它只表达判断顺序，实施时必须补齐真实接口、权限与错误处理。

开始一个新项目？
├─ 是 → 需要完整从零到部署？
│   ├─ 是 → 全自动构建（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个工程技能中为需求澄清、实施、架构审查、故障咨询各选一个，并列前置输入、输出、失败升级条件。

本章必交产物：技能选择地图

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

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

查看参考反馈（先独立作答）

参考反馈

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

自评与下一步

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