第一章：方法论全景
2026.07.26你同时接手了三个功能需求。一个需要重构历史代码，一个要从零开始，还有一个是第三方系统的迁移。你打开 AI 编码工具，却不知道该从哪个开始。更糟的是，你发现之前做的一个功能，AI 最近生成的代码和它之前写的不一致了——它似乎"忘记了"当初的设计约定。你不知道该找哪个技能来解决这些问题。
1.1 从"会用"到"用好"
这是"技能体系"存在的意义。它不是教你 14 个孤立的技巧，而是帮你回答一个更根本的问题：当项目变得复杂，你该在什么时候、用什么方法、以什么顺序推进工作？
第一册教你的是"六步工作法"——一个普适的核心流程，适用于任何 AI 编码任务。但现实中的项目不是单线程的。你可能需要同时管理多个功能、在不同阶段使用不同的方法、在出问题时知道该找谁（哪个技能）来解决。
这就是 14 个技能存在的意义：它们不是 14 个独立的方法，而是一个有机协作的体系。
1.2 为什么需要 14 个技能而不是 1 个
你可能在想：一个六步工作法不是已经够用了吗？为什么需要 14 个技能？
答案是：六步工作法解决的是"一个功能怎么做"的问题，但实际项目面对的是"多个功能怎么一起做"的问题。这是两个完全不同的问题。
一开始，你可能只需要一个 Coach（流程教练）。它引导你走完"拆解→下发指令→编码→验收→分支判断→更新图纸"这个六步循环。一个功能、两个功能、三个功能，这个流程都够用。
但当你手上有五个功能需要同时推进时，问题出现了。你发现 Coach 在一个功能上的对话，可能干扰了另一个功能的上下文。你验收完功能 A 后切到功能 B，发现 AI 在写 B 的时候，悄悄改掉了功能 A 的某个核心接口——因为它在 A 的对话里记住了 A 的接口定义，但在 B 的对话里完全不知道 A 的存在。
这就像团队扩张。一个 3 人团队不需要复杂的管理结构——每个人都知道别人在做什么。但当团队扩张到 30 人时，你需要分工：有人负责架构，有人负责执行，有人负责验收，有人负责管理进度。这不是增加了"层级"，而是应对复杂度做出的自然调整。
14 个技能也是同样的道理。它们不是 14 个独立的方法，而是一个有机协作的体系。每个技能解决一个特定类型的问题，当问题变复杂时，你调用更高级的技能来应对。
1.3 技能全景图
整个技能体系围绕三个维度组织：
┌─────────────────┐
│ 全自动构建 │
│ (Job) │
└────────┬────────┘
│
┌──────────────┴──────────────┐
│ 项目编排 │
│ (Orchestrator) │
└──────────────┬──────────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
┌────┴────┐ ┌─────┴─────┐ ┌─────┴────┐
│ 需求分析 │ │ 自动工作流 │ │ 监理验收 │
│(Req.) │ │(Workflow) │ │(Inspector)│
└────┬────┘ └─────┬─────┘ └─────┬────┘
│ │ │
┌────┴────┐ ┌─────┴─────┐ │
│ 架构设计 │ │ 流程教练 │ │
│(Arch.) │◄──────│(Coach) │ │
└────┬────┘ └───────────┘ │
│ │
┌────┴────┐ ┌──────┴──────┐
│ 前端架构 │ │ 质量保障 │
│(Frontend)│ │ (QA) │
└─────────┘ └─────────────┘
辅助技能：
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 顾问 │ │ 代码克隆 │ │ 高保真原型│ │ 老系统还原│ │ 项目接续 │
│(Advisor) │ │ (Cloner) │ │ (POC) │ │(Legacy) │ │ (Next) │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
四层结构从何而来
14 个技能不是平铺在一个平面上的。它们有明确的层次关系。这个层次关系不是人为设计出来的，而是从实际项目中"长出来"的——当项目规模从小到大，你会自然发现需要这些层级。
一开始，你可能只需要一个 Coach（流程教练）。它引导你走完六步循环。一个功能、两个功能，这个流程都够用。
但当你手上有五个功能需要同时推进时，问题出现了。你发现 Coach 在一个功能上的对话，可能干扰了另一个功能的上下文。这时候你需要一个 Orchestrator（项目编排）。它的职责不是写代码，而是管理"哪个功能先做、哪个功能后做、功能之间依赖什么"。它像项目经理一样，把多条并行的工作流串成一条有序的流水线。
但 Orchestrator 也不是终点。当你有"从零做一个完整项目"的需求时，连脚手架搭建、需求分析、架构设计这些前置工作都要自动化。这时候就需要 Job（全自动构建）站在最高层，把整个流程串起来。
这就是四层结构的由来。它不是拍脑袋想出来的，而是应对"项目复杂度"这个变量，自然生长出来的组织结构。每一层解决上一层解决不了的问题。
来看一个反面案例：一个 10 功能项目，没有分层管理。开发者把所有功能放在一个对话中让 AI 做。AI 做了 3 个功能后，对话已经很长了。AI 开始"忘记"前 3 个功能的约定——命名风格变了、数据模型不一致了、API 接口定义冲突了。开发者在第 7 个功能时不得不停下来，花了一周时间修复前 6 个功能的冲突。
如果有分层管理：Job 负责整体流程，Orchestrator 负责功能顺序，Workflow 负责单个功能，Inspector 负责验收——这些冲突在早期就会被发现和修复，而不是累积到最后集中爆发。
第三层：核心执行层 这是日常开发中最常用的三个技能：
- 需求分析（Requirements） — 把模糊的需求变成结构化的功能列表和数据模型
- 自动工作流（Workflow） — 自动完成一个功能的编码、验收、固化
- 监理验收（Inspector） — 检查代码是否符合蓝图
第四层：基础支撑层
- 架构设计（Architect） — 在编码开始前产出蓝图
- 流程教练（Coach） — 引导开发者走完六步工作法
- 前端架构（Frontend Architect） — 前端专属的架构设计
- 质量保障（QA） — 全面的测试策略和质量门禁
辅助层：特殊场景技能
- 顾问（Advisor） — 遇到技术决策时提供分析
- 代码克隆（Cloner） — 复用现有代码模式
- 高保真原型（POC） — 先出原型再开发
- 老系统还原（Legacy Recon） — 从老系统重建
- 项目接续（Next） — 接手半成品项目
1.4 技能之间的协作关系
典型的协作流程
项目开始
│
▼
Job（全自动构建）
├── 第一阶段：脚手架搭建
├── 第二阶段：需求分析（Requirements）→ 产出 REQUIREMENTS.md
├── 第三阶段：架构设计（Architect）→ 产出 CONTEXT.md
├── 第四阶段：前端设计（Frontend Architect）→ 产出 FRONTEND-DESIGN.md
├── 第五阶段：开发阶段
│ └── Orchestrator（项目编排）
│ ├── 功能 1 → Workflow（自动工作流）
│ │ ├── Coach（流程教练）引导
│ │ ├── Inspector（监理验收）检查
│ │ └── Advisor（顾问）辅助决策
│ ├── 功能 2 → Workflow
│ └── ...
├── 第六阶段：集成验收
└── 第七阶段：部署配置生成
技能的触发条件（什么时候该用哪个）
| 触发条件 | 该用哪个技能 |
|---|---|
| "从零做一个 XXX" | Job（全自动构建） |
| "开始做这个项目"（蓝图已就绪） | Orchestrator（项目编排） |
| "完整实现这个功能" | Workflow（自动工作流） |
| "开始开发这个功能" | Coach（流程教练） |
| "帮我设计系统" | Architect（架构设计） |
| "验收代码" | Inspector（监理验收） |
| "帮我分析需求" | Requirements（需求分析） |
| "这个技术方案怎么选" | Advisor（顾问咨询） |
| "这个项目别人做的，我接过来" | Next（项目接续） |
| "老系统要迁移" | Legacy Recon（老系统还原） |
| "先做个原型看看效果" | POC（高保真原型） |
| "按这个现有代码的风格实现" | Cloner（代码克隆） |
| "全面测试一下" | QA（质量保障） |
1.5 三大纪律的深层含义
三条纪律看似简单，但每一条背后都有一个完整的推演链。理解这些推演链，比记住三条纪律本身更重要。
纪律一：没有蓝图不开工
这条纪律的底层逻辑是：AI 没有长期记忆。
每次对话，AI 看到的是一张白纸。它不知道你之前做过什么、不知道项目的技术栈是什么、不知道你喜欢的命名风格是什么。如果你不给它上下文，它就只能"猜"——猜技术栈、猜命名风格、猜数据结构。
而"猜"在工程中是最昂贵的。因为不同的人（包括 AI 在不同对话中）的猜测结果不同。你今天让 AI 做用户管理，它猜了一个命名风格（camelCase）。明天你让 AI 做订单管理，它猜了另一个命名风格（snake_case）。两个模块的数据模型冲突了——因为 AI 在两个对话中独立地"猜"了两次。
蓝图的本质不是文档，是"约束器"。它把 AI 的可能性空间从"无限"压缩到"你的项目范围内"。当蓝图说"使用 Prisma ORM、camelCase 命名、统一 AppException 异常处理"时，AI 无论开多少次对话，都会遵守这些约定，因为它每次看到蓝图时，这些"规则"都是固定的。
所以蓝图必须是完整的、准确的、可读的。 不完整意味着 AI 仍然需要"猜"——它会去猜那些蓝图没有覆盖的部分。不准确意味着 AI 会基于错误的信息做决策。不可读意味着 AI 无法快速理解，浪费了上下文窗口。
纪律二：没有验收不固化
这条纪律的底层逻辑是：AI 存在"自洽陷阱"。
AI 生成的代码从语法上看几乎总是正确的——因为它是一个概率模型，它生成的每一个 Token 都是"在当前上下文中概率最高的那个"。这意味着它的代码看起来"对"，但可能在逻辑和架构层面有严重问题。
一个典型的场景：你让 AI 实现用户注册，它写了代码，你跑测试——注册成功，登录成功。你提交了代码。但一个月后你发现，密码是明文存储的——因为功能测试只检查了"注册成功"这个结果，没有检查"密码是否加密"这个实现细节。
"自洽陷阱"的意思是：AI 会让自己看起来"正确"，即使底层逻辑是错的。它不会主动告诉你"我用了明文存储密码"，因为它认为"跑通了"就是"完成了"。
所以验收不能只看"能不能跑通"，还要看"是不是按蓝图设计的"。 这就是为什么需要三条防线：功能防线检查"能不能跑通"，架构防线检查"是不是按蓝图设计的"，安全防线检查"有没有隐藏的漏洞"。
纪律三：逢混乱必重建
这条纪律的底层逻辑是：修复成本可能高于重建成本。
传统开发中，代码写错了，你修。但在 AI 编码中，"修"的成本可能高于"重写"。原因很简单：AI 写代码的成本接近于零，但人类审查代码的成本非常高。
如果 AI 在错误的思路上走了 30 分钟，产生了 200 行代码，你让 AI 修复这些代码——AI 可能需要 3 轮对话，每轮 5 分钟，共 15 分钟，而且修复后的代码质量通常低于重写。如果你选择重建——回滚到上一个干净的 commit，重新下发更精确的指令——AI 只需要 1 轮对话，5 分钟，而且生成的代码质量更高，因为上下文是干净的。
三个重建信号是判断"是否需要重建"的快捷方式：
- 篡改地基：AI 修改了不该改的核心代码（数据库连接、认证逻辑、全局配置）——这是最危险的信号，说明 AI 失去了对架构的理解，必须重建
- 过度设计：AI 引入了不必要的复杂性（不需要的抽象层、设计模式、第三方库）——说明 AI 在"以防万一"而不是"刚刚好"，重建是更干净的解决方案
- 体积失控：单个文件无节制膨胀——说明 AI 在"追加代码"而不是"重构代码"，重建比修复更高效
1.6 技能体系的演进
14 个技能不是一次性设计出来的，而是在实际项目中逐步演进的结果。
第一阶段：只有 Coach 最初只有一个流程教练，引导用户走六步工作法。但很快发现，纯手动引导效率太低。
第二阶段：Workflow + Inspector 增加了自动工作流（自动完成编码到验收的全流程）和监理验收（专门负责代码检查）。Coach 负责引导，Workflow 负责执行，Inspector 负责把关。
第三阶段：Architect + Orchestrator + Job 随着项目复杂度增加，需要更前置的架构设计（Architect），更宏观的多功能管理（Orchestrator），以及从零到部署的全自动（Job）。
第四阶段：辅助技能
代码克隆（Cloner）、老系统还原（Legacy Recon）、项目接续（Next）等特殊场景技能逐步加入，形成完整的 14 技能体系。
本章小结
14 个技能不是工具集合，而是应对项目复杂度的分层决策框架。核心流程是"先设计→再执行→再验收"，管理层次是"Job 管整项目、Orchestrator 管多功能、Workflow 管单功能"。三条纪律——没有蓝图不开工、没有验收不固化、逢混乱必重建——每一条背后都有一个从 AI 的底层特性出发的推演链。这个体系不是一次性设计出来的，而是在实际项目中逐步演进形成的。下一章，我们深入需求分析——如何把模糊的需求变成精确的蓝图。