你打开 14 个技能的列表，看到一堆陌生的名字——Architect、Inspector、Orchestrator、Workflow……你不知道该从哪里入手。别担心，作为管理者，你不需要掌握每个技能的细节，但需要知道它们解决什么问题、哪些需要你推动建立。

你收到一份 14 个技能的列表，每个技能都有一个听起来很专业的名字——Architect、Inspector、Orchestrator、Workflow。你的第一反应可能是："我需要全部学会吗？"

答案是：不需要。作为管理者，你的职责不是掌握每个技能的操作细节，而是知道哪些技能需要你推动建立、哪些技能团队可以自主使用、哪些技能在特定场景下引入就够了。

这就好比你管理一个餐厅。你不需要知道每道菜的具体做法，但你需要知道厨房的流程是否合理、出餐的质量是否稳定、食材的供应链是否可靠。14 个技能就是 AI 编码的"厨房流程"——你不需要会做每道菜，但你需要知道流程是否顺畅。

2.1 管理者视角的技能分类

从管理者的视角，14 个技能可以分为三类：

第一类：治理型技能（管理者需要推动建立）

这些技能是团队规范的一部分，需要管理者推动建立。

第二类：执行型技能（团队自主使用，管理者需要了解）

这些技能是团队日常开发中使用的，管理者不需要掌握细节，但需要了解它们的作用。

第三类：专项技能（特定场景使用，管理者需要了解适用场景）

这些技能在特定场景下使用，管理者需要知道团队是否有能力和工具应对这些场景。

三类技能之间有一个隐藏的逻辑关系：治理型技能决定"能不能做对"，执行型技能决定"能不能做快"，专项技能解决"能不能做特殊的事情"。作为管理者，你首先需要确保治理型技能到位——没有它们，AI 编码的质量就是不可控的。执行型技能可以在治理型技能到位后逐步推广，专项技能在遇到具体场景时引入即可。

2.2 技能与团队角色的对应

2.3 技能成熟度模型

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

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

评估示例：

团队技能成熟度评估：

Architect（架构设计）：L2 - 规范使用
  - 每个项目开始前都有蓝图产出 ✓
  - 蓝图定期更新 ✓
  - 蓝图质量没有统一标准 ✗

Inspector（监理验收）：L1 - 尝试使用
  - 部分成员在验收，但不是强制 ✓
  - 没有统一的验收标准 ✗
  - 验收结果没有记录 ✗

2.4 技能投资优先级

资源有限的情况下，建议按以下优先级投入。为什么是这个顺序？因为治理型技能是"地基"，执行型技能是"上层建筑"。地基没打好就建上层建筑，楼会塌。

第一优先级（必须建立）

第一优先级（必须建立）

Architect — 没有蓝图，AI 编码就没有方向。蓝图是质量的基础。

Inspector — 没有验收，AI 编码的质量就不可控。验收是质量的保障。

建议： 在团队推广 AI 编码之前，先建立蓝图和验收的规范。

第二优先级（尽快建立）

Workflow — 自动工作流是效率提升的关键。需求明确时，Workflow 可以大幅减少人工介入。

Advisor — 顾问技能帮助团队解决技术决策困难，减少决策阻塞。

建议： 团队掌握蓝图和验收后，推广 Workflow 和 Advisor。

第三优先级（逐步建立）

Orchestrator — 项目编排适合多功能项目，在团队熟悉 Workflow 后引入。

QA — 质量保障是验收的补充，在验收体系成熟后建立。

Requirements — 需求分析在项目复杂度高时引入。

建议： 团队成熟度提升后，逐步引入这些技能。

第四优先级（按需建立）

Cloner、POC、Legacy Recon、Next、Job、Coach、Frontend Architect

这些技能在特定场景下使用，按需引入，不需要全面推广。

本章小结

14 个技能从管理者视角分为三类——治理型、执行型、专项型——这个分类本身就是一个"管理者使用指南"：治理型技能需要你推动建立，执行型技能团队自主使用即可，专项技能按需引入。技能成熟度模型帮助你量化评估团队的掌握程度，投资优先级告诉你从哪里开始投入。记住：治理型技能是地基，地基没打好，上层建筑再漂亮也会塌。下一章，我们学习如何将这套方法论导入团队。