从灵感到上线
了解 Agent Skills 如何让 AI 编程助手像资深工程师一样工作
想象你正在让 AI 帮你写一个 App
你告诉 AI："帮我做一个待办事项 App"。几秒钟后，AI 给了你一串代码，页面跑起来了，你很开心。
但是——这段代码质量如何？有没有安全漏洞？能不能扛住真实用户的访问？能上生产环境吗？
大多数人的做法是：能跑就行，直接上线。结果呢？用户数据泄露、页面崩溃、功能异常……这些问题不是 AI 不够聪明，而是AI 太快了，快到跳过了所有质量关卡。
Agent Skills 就像给 AI 一本"资深工程师的操作手册"。AI 本身就像一台强力烤箱——它能烤出东西，但不知道该按什么菜谱、什么顺序来。Agent Skills 提供的就是那本菜谱：21 个结构化工作流，确保 AI 写出的每一段代码都经过定义、规划、构建、验证、审查和发布这六道关卡。
简单来说：没有 Agent Skills 的 AI 编程，就像没有安全带的跑车——快是快，但出事就是大事。
六阶段开发流水线
Agent Skills 把软件开发分成六个阶段，每个阶段都有对应的技能文件来指导 AI。就像工厂流水线一样，上一站的输出是下一站的输入，任何一站发现问题都会停下来解决。
把模糊的想法变成清晰的需求
把需求拆解成可执行的小任务
一步一步写代码
确保代码真的能跑
上线前的质量关卡
安全地推到生产环境
这六个阶段不是凭空发明的——它们来自资深工程师和顶级团队的实战经验。每个阶段对应一类 Agent Skills 文件，总共 21 个技能分布在这六个阶段里。后续模块我们会逐一认识它们。
你会怎么选？
你让 AI 帮你写了一个用户登录功能，代码看起来能跑。下一步你应该？
认识 21 个技能
每个技能都是一份操作手册，教你和 AI 怎么一步步把代码写好
每个技能都是一份操作手册
想象你在做一道菜。食谱不会只写"把鸡煮熟"——它会告诉你需要什么食材、每一步怎么做、哪些地方容易出错、怎么判断做好了没。
Agent Skills 里的每个技能就是这样一个"食谱卡片"。它不只是一句口号，而是一份完整的 spec，包含了目标、步骤、规则和边界。
下面是一个真实的技能模板，来自 spec-driven-development（规格驱动开发）这个技能。左边是技能文件里写的格式，右边是每一条的意思：
## Objective
[What we are building and why.]
[User stories or acceptance criteria.]
## Commands
[Build, test, lint, dev]
## Project Structure
[Directory layout with descriptions]
## Code Style
[Example snippet + key conventions]
## Testing Strategy
[Framework, test locations,]
[coverage requirements]
## Boundaries
- Always: [...]
- Ask first: [...]
- Never: [...]
当你用 PRD 写清楚"要做什么"，AI 就有了明确的导航地图。没有地图，AI 只能瞎猜。
六个阶段，21 个技能各就各位
这 21 个技能不是随便堆在一起的。它们按照软件开发的六个阶段排列，就像流水线一样，每个阶段有自己的职责。
想清楚要做什么，把模糊的想法变成清晰的方案。
把模糊想法变成清晰提案
写 PRD 再动手
把大目标拆成小任务，排好优先级。
把需求拆成小任务
动手写代码，一小步一小步来。
一小步一小步写代码
给 AI 正确的信息
先写测试再写代码
查官方文档，不瞎猜
用新视角质疑每个决定
界面设计和组件
接口设计
测试代码是不是真的能正常工作。
用浏览器工具测
系统化找 bug
从质量、安全、性能等维度全面检查代码。
五维度代码审查
简化代码
安全检查
性能优化
安全上线，确保版本可控、流程自动化。
代码版本管理
自动化流程
代码退役和迁移
写文档
上线检查清单
反借口对照表
当你让 AI 帮你写代码，它可能会说"先这样吧""后面再优化"。这些都是绕过质量检查的借口。下面是常见的借口和正确的应对方式：
听到 AI 说"先这样吧"的时候，立刻打开反借口对照表。红灯意味着必须停下来纠正，黄灯意味着可以继续但要有计划。
测一测
技能如何协作
像工厂流水线一样，每个技能的输出是下一个技能的输入
流水线上的技能们
想象一个汽车工厂。底盘组搭好车架，发动机组装上动力系统，喷漆组涂上颜色，质检组逐项检查。每一组的成品，就是下一组的原材料。如果底盘歪了，后面的工序全白费。
在 Agent Skills 里，软件开发也是一条这样的流水线。每个阶段都有一个或多个技能在干活，它们产出的成果物会传递给下一个阶段：
把"我想做一个登录功能"这种模糊想法，翻译成 AI 能看懂的详细规格：支持哪些登录方式、忘记密码怎么走、输错几次锁定……
把需求拆成一个个可以独立完成的小任务：设计数据库表、写注册接口、做前端表单……每个任务都有明确的验收标准。
按照任务清单，一个一个地写代码。每写完一个任务就跑测试，确保没破坏之前的功能。就像工人每装好一个零件就检查一遍。
全面跑测试套件，模拟用户操作，找到隐藏的 bug。这一步就是质检——发现问题不丢人，带着问题上生产线才要命。
检查安全漏洞（比如密码有没有加密）、代码质量（命名是否清晰、逻辑是否简洁）、性能问题。相当于出厂前的终检。
先部署到测试环境确认没问题，再推到生产环境，最后监控运行状态。就像新车先试驾，再交付给客户。
每个阶段的产出都是下一个阶段的"原材料"。如果定义阶段写错了需求，后面的规划、构建、验证都会跟着错——就像底盘歪了，整辆车都是歪的。这就是为什么 Agent Skills 强调每个阶段都有质量关卡，问题越早发现越便宜。
技能们在群聊
下面是一个模拟的群聊窗口，展示六个技能如何像团队成员一样接力完成一个"用户登录"功能。点击"下一条"逐条查看，或点"全部播放"一键看完。
每条消息都在前一条的基础上推进。需求文档 → 任务清单 → 代码实现 → 测试补充 → 安全审查 → 部署上线。没有人跳步，没有人各自为战——这就是协作流水线的力量。
一个需求走过六个关卡
下面这个动画展示了"我想做一个登录功能"这句话是如何走过六个阶段的。点击"下一步"逐步观看，你会看到一个光点从一个阶段飞到下一个阶段——那就是数据在传递。
每次光点飞过去，就代表一个阶段的成果物传递到了下一个阶段。Spec 飞给规划 → 任务清单飞给构建 → 代码飞给验证 → 问题报告飞给审查 → 审查通过飞给发布。这就是技能之间的"数据流"。
你会怎么选？
如果构建阶段（BUILD）跳过了测试直接写完所有代码，最可能发生什么？
没有测试保护，改一行代码就可能悄悄破坏其他功能——而且你还不知道。验证阶段找 bug 的成本是构建阶段的 10 倍以上。早发现早治疗，这个道理在软件开发里一样适用。
三位专家代理人
代码审查员、测试工程师、安全审计员——三个视角，一次全面体检
请三位专家来审你的代码
想象你要开一家餐厅。开业之前，你会请三位检查官来验收：
检查食品安全——食材有没有过期、厨房有没有细菌
品尝菜品质量——味道好不好、摆盘精不精致、菜单合不合理
排查安全隐患——灭火器够不够、逃生通道通不通、电线有没有裸露
三位检查官看的都是同一家餐厅，但每个人看到的东西不一样。卫生检查员觉得没问题的，消防检查员可能发现逃生门被锁了。
Agent Skills 也是这样。在 REVIEW 审查阶段，它提供了三位"专家代理人"，从三个不同的角度审查你的代码：
一个人审查代码，难免有盲区。代码审查员关注质量，测试工程师关注覆盖，安全审计员关注漏洞——三者缺一不可。就像一家餐厅不可能只通过卫生检查就开业，代码也不能只通过一个维度的检查就上线。
三位专家的身份卡片
下面是三位专家代理人的详细资料。每个人都有一套自己的审查哲学和铁律。
资深工程师的视角。从五个维度审查代码：正确性、可读性、架构、安全性、性能。就像一位经验丰富的编辑审稿——不只是挑错，更是帮你把文章写得更好。
审查范围控制在约 100 行代码以内，太大了就拆分。一次看太多代码 = 走马观花 = 看不出问题。
QA 专家的视角。关注测试金字塔：80% 单元测试、15% 集成测试、5% 端到端测试。就像质检员验货——不是抽一个看一眼，而是每种情况都测到。
测试行为，不测实现细节。用 DAMP（描述性，好理解）而非 DRY（不重复，省代码）。测试代码写得清楚比写得短更重要。
安全工程师的视角。对抗 OWASP Top 10（十大 Web 安全漏洞），三层边界防护。就像保安巡逻——不放过任何可疑角落。
所有外部输入都是恶意的，所有密钥都是神圣的，所有权限检查都是必须的。不信任任何人，包括你自己。
这个名字来自 Beyonce 的歌词"If you liked it then you should have put a ring on it"——换个说法就是：如果你在乎它（某个功能、某个场景），你就应该给它写测试。"如果它能断，就测它。"这是测试工程师的核心信条。
三位专家如何分工
下面这张架构图展示了三位专家是如何分工的。同一份代码提交上去，三位专家各自从不同角度审查。点击任意角色，了解它关注什么。
代码审查员可能觉得"代码写得挺干净的"，但安全审计员会一眼看到密码明文存储。测试工程师可能觉得"测试覆盖率 90% 够了"，但代码审查员会发现测试全在测实现细节而不是行为。三个视角互补，才能发现更多问题。
你会怎么选？
你的代码要上线了，代码审查员发现一个性能问题，测试工程师发现测试覆盖率只有 40%，安全审计员发现一个 SQL 注入漏洞。你应该先修哪个？
安全问题 > 功能正确性 > 测试覆盖 > 性能优化 > 代码美观。安全漏洞是"着火了"，性能问题是"灯不够亮"——你会先灭火还是先换灯泡？
你的第一个实战项目
跟踪"用户登录功能"从想法到上线的完整旅程
跟踪一个真实功能从想法到上线
你有一个想法：给 App 加一个用户登录功能。看起来很简单对吧？但在真实项目中，一个"简单"的登录功能背后要经过多少道关卡？让我们看看 Agent Skills 如何帮你从零到上线。
这就是起点——一个模糊的想法。
AI 问你澄清问题："支持哪些登录方式？忘记密码怎么处理？需要手机号登录吗？"
AI 帮你写一份完整的需求文档——目标是什么、用户故事是什么、边界在哪里。
AI 把需求拆成 5 个任务：数据库设计、注册接口、登录接口、忘记密码、前端表单。
AI 一个任务一个任务地写代码，每完成一个就验证一个，绝不一口气全写完。
每写一段代码前先写测试。"注册时邮箱格式不对应该报错"——测试先写，代码跟上。
发现 bug？不慌。系统化排查：复现问题 → 定位原因 → 修复 → 验证。不做"试试看"式的瞎改。
五维度审查代码：正确性、可读性、可维护性、性能、一致性。像资深同事帮你 review。
检查 SQL 注入、XSS、密码加密、会话管理——安全无小事。
部署上线：先上测试环境确认，再推生产环境，最后监控运行状态。完美收工。
从第 1 步到第 10 步，没有一步是"跳过"的。每个阶段都有专门的技能负责，每个成果物都经过验证后才传递给下一步。这就是 Agent Skills 的力量——不是让你更快地写代码，而是让你每一步都走稳。
Spec 长什么样？
还记得 Module 2 里介绍的 Spec 格式吗？下面是一个真实的"用户登录功能"Spec，左边是 AI 看到的格式，右边是每一条的中文解释。
## Objective
用户登录功能，支持邮箱+密码注册和登录。
## Commands
npm test # 运行所有测试
npm run dev # 启动开发服务器
npm run build # 构建生产版本
## Boundaries
- Always: 密码用 bcrypt 加密存储
- Always: 所有 API 输入必须验证
- Never: 不存储明文密码
- Never: 不在日志中打印密码
Boundaries 就是给 AI 划红线。"必须做"的事情 AI 每一步都会检查，"绝对不做"的事情 AI 碰都不会碰。没有 Boundaries，AI 可能为图方便把密码明文存在数据库里——这不是 AI 坏，是没人告诉它规矩。
你需要记住的最重要的三件事
1. 先想清楚再动手 — 写代码前先写需求文档和计划。就像盖房子先画图纸，不画图纸直接砌墙，盖到一半发现忘了留门。
2. 每一步都有验证 — 测试驱动、代码审查、安全检查。就像工厂流水线的质检站，每个零件出厂前都要检测。
3. 做减法不做加法 — 用最少的代码解决问题，发现复杂代码就简化。代码越少，bug 越少，维护越容易。
在 Claude Code 中安装 Agent Skills，用 /spec 开始你的第一个项目。
在 Cursor 中把 skills/ 文件夹复制到 .cursor/rules/ 目录下。
在 Gemini CLI 中使用内置的技能支持。
GitHub 仓库：github.com/addyosmani/agent-skills
最终测验
你是一个独立开发者，用 AI 助手开发一个电商网站。你刚写完购物车功能的代码，接下来要做什么？
购物车代码写完后，第一步应该？
AI 助手建议"先跳过错误处理，功能做完再加"。你应该？
你现在已经了解了 Agent Skills 的核心概念：六阶段流水线、21 个技能的分工、三位专家代理人的协作方式，以及如何跟踪一个真实功能从想法到上线。接下来，打开你的 AI 编程工具，用 Agent Skills 开始你的第一个项目吧。记住：先想清楚再动手，每一步都有验证，做减法不做加法。祝你写出高质量的代码！