AI 放大的是能力还是混乱？Cloud Code 团队的 9 类 Skill 地图与组织沉淀
AI 放大的是能力还是混乱？Cloud Code 团队的 9 类 Skill 地图与组织沉淀
很多团队在引入 AI 编程助手后，都会经历一个相似的阶段：起初兴奋于效率的提升，随后却陷入一种微妙的焦虑。
AI 会放大组织已有的能力，也会放大能力缺口。如果关键经验还没有被“技能化（Skill-ified）”，AI 产出的速度越快，组织的混乱程度也会越高。代码生成得越快，如果缺乏标准、缺乏验证、缺乏对内部系统的理解，技术债务的积累速度也会成倍增加。
近期，Cloud Code 核心团队工程师 Derek 复盘了内部几百个 Skill（技能），发现了一套极具参考价值的分类体系。这套体系不仅适用于 Cloud Code，对于任何希望将 AI 深度融入研发流程的团队来说，都是一张组织能力地图。
什么是 AI 时代的"Skill"？
在这里，Skill 不仅仅是一个 Prompt 或一段指令。在 Cloud Code 的定义中，Skill 是一组可复用的能力资源。
它里面可以放脚本、模板、参考资料、数据文件，也可以挂载钩子（Hooks）。AI 可以读取这些内容，调用、执行、组合这些内容。因此，Skill 是承载组织经验的最佳容器，也是长期积累技术资产的核心单元。
如果顺着研发流程往下看，这几十上百个 Skill 可以收束到4 个核心环节，共计9 类 Skill。
环节一：认知（Cognition）
核心问题：AI 到底知不知道自己面对的是一个什么系统？
通用大模型对公共技术知识了如指掌，但它不了解你的内部库、内部平台、内部设计系统。认知环节的 Skill，目的是填补“通用智能”与“组织私有知识”之间的鸿沟。
1. 内部库与接口文档
这类 Skill 负责补充组织内部的专属知识。
- 价值点：不要写 AI 本来就知道的东西（如 Python 基础语法），要写它推不出来的东西。
- 内容示例：内部计费库在边界条件下会出什么问题？前端设计体系最容易出现的误区是什么？那些公开文档没写、但团队反复踩坑的 Gotchas。
- 现状痛点：这些知识往往散落在老员工的脑子里、聊天记录里和零散文档里。缺这类 Skill，AI 就会在内部系统调用上不断“幻觉”。
2. 数据获取与分析
很多团队能让 Agent 写代码，但一到分析任务就开始“空转”，问题往往在于数据入口。
- 价值点：把数据源、凭证、仪表板、常用查询语句、分析脚本整理成 AI 能直接调用的东西。
- 内容示例：漏斗分析模板、分群对比脚本、监控面板接入方式。
- 现状痛点：否则 AI 会卡在数据入口上，根本不知道去哪里拿数据，也不知道该用什么方式查。
3. 故障排查手册
这类 Skill 接收一个症状（如 Slack 告警、错误签名、请求 ID），AI 不只是给建议，而是自己去查日志、查监控、串链路，输出结构化排查结果。
- 价值点：承接低频但认知负担极高的问题。
- 意义：把资深工程师的排障思路，变成组织可以复用的基础设施。一旦出事，不再只能依赖少数最熟系统的人。
环节二：生产（Production）
核心问题：AI 怎么稳定地产出标准化产物，而不是每次都从零起步？
4. 代码脚手架与模板
给 AI 一套稳定的“起手式”。
- 价值点：避免每次重新决定目录结构、命名习惯、文件分层。
- 内容示例：新建前端组件、新开接口、数据库迁移、微服务模板。
- 意义：有了这类 Skill，团队的结构和风格才有可能稳定下来，产出的东西才不会“漂”。
5. 业务流程与团队自动化
处理高频重复、规则清楚的流程工作。
- 内容示例：站会汇报（自动汇总任务、代码、聊天历史）、事故报告（自动创建、同步状态、通知相关人）。
- 意义：这类 Skill 会持续吃掉团队里那些低价值、重复性的劳动，从组织效率角度看，往往是最容易快速感知到收益的一类。
环节三：验证（Verification）
核心问题：AI 能不能证明自己写出来的东西真的能工作？
这是原文中最值得重视的环节。生成代码很容易，证明代码正确很难。
6. 代码质量与审查
负责检查代码、文档或方案本身的质量。
- 内容示例：安全风险、结构问题、命名习惯、性能隐患、团队规范审查清单。
- 高级技巧：Adversarial Review（对抗性审查）。不要只让 AI 用刚写完代码的视角审自己，要故意制造一个“新鲜视角”，让它专门来挑毛病，反复迭代。这背后是在对抗模型的自我一致性偏差。
7. 产品验证
这类 Skill 值得工程师花一周时间专门打磨，因为真正决定质量的是反馈闭环。
- 内容示例：配合无头浏览器、终端复用工具、断言脚本，描述怎么测试代码是否真的正确。
- 高级技巧：录制执行视频。让 AI 录制操作过程，你看到的就是完整执行路径：它到底测了什么？点了什么？停在了哪里？有没有真的走完关键路径？
- 意义：核心是让 AI 有能力证明自己做对了，而不只是交差。
环节四：交付（Delivery）
核心问题：AI 怎么把结果真正推进到系统里，并持续维护？
8. 持续集成与部署（CI/CD）
负责代码合并、流水线部署、灰度回滚这一整条交付链路。
- 内容示例：PR 监控、重试不稳定的流水线、处理合并冲突、灰度发布盯关键指标、异常自动回滚。
- 现状痛点：很多团队一到部署就必须完全切回人工，说明 Agent 的能力链条只走到了一半，真正的交付链路还没有接上。
9. 基础设施运维
处理基础设施和日常运维动作，尤其是高风险动作。
- 内容示例：查孤立资源、依赖升级、云资源费用异常调查、容器集群故障处理。
- 关键点：护栏（Guardrails）。删资源、改环境、切流量一旦失控代价很高。这类 Skill 更强调先把风险边界写清楚，再去谈自动化。
- 意义：如果这类 Skill 很弱，通常意味着基础设施操作依然高度依赖“谁熟谁来”，流程没有真正编码进系统。
总结：这是一张组织能力地图
当我们把这 9 类 Skill 摆在一起，它们不仅仅是一个工具列表，更像是一张组织能力地图。
你可以把自己团队现有的 Skill 摆上去，很快就能看出来：
- 哪些地方已经沉淀成了系统？
- 哪些关键环节还停留在人脑里？
- 哪些地方明明最需要 Skill，结果到现在还没被系统化？
如果要把这套方法论压成一句话，那就是：团队落地 AI 研发时，真正的短板往往不在于 AI 够不够聪明，而在于关键经验有没有被做成 AI 能真正调用、执行、验证和复用的 Skill。
AI 不会自动带来秩序，只有将隐性的组织经验显性化、技能化，我们才能在享受 AI 速度的同时，避免陷入混乱。这不仅是技术的升级，更是组织工程能力的升级。
原文标题：Lessons from Building Claude Code: How We Use Skills
原文链接：https://x.com/trq212/status/2033949937936085378