AI 写代码越来越快，但我更想让它慢一点
最近看到 Addy Osmani 开源了一个项目，叫 agent-skills。
一开始我以为它又是一个"让 AI 更会写代码"的工具。看了一圈后发现，不太一样。
它真正想解决的不是"AI 会不会写代码"，而是另一个更现实的问题：
AI 写代码太快了。
快到它经常还没想清楚，就已经开始改文件了。
快到你还没确认需求边界，它已经给你生成了一套实现。
快到它嘴上说"已完成"，但你一跑测试，发现事情没那么简单。
用 AI 编程久了以后，会慢慢发现一个很微妙的问题：
AI 最危险的地方，不是它不会写。
而是它太自信地开始写。
我们缺的不是代码，而是工程习惯
过去我们找 AI 写代码，经常是这样：
"帮我做一个登录功能。"
"帮我修一下这个 Bug。"
"帮我把这个页面优化一下。"
然后 AI 很积极。
它开始读文件，开始改代码，开始给你一堆看起来很完整的东西。
但真实开发里，靠谱的工程师通常不会这样。
一个有经验的人，大概率会先问几句：
登录是手机号还是邮箱？
要不要验证码？
失败几次要不要锁定？
有没有第三方登录？
旧用户数据怎么兼容？
接口错误怎么提示？
测试覆盖哪些场景？
这些问题听起来啰嗦，但这就是工程经验。
很多项目出问题，并不是因为某一行代码写错了，而是因为一开始就没想清楚。
agent-skills 有意思的地方就在这里。
它不是教 AI "写得更快"，而是教 AI "别急，先按工程流程来"。
agent-skills 是什么？
你可以把它理解成一套给 AI 编程助手用的工作习惯包。
里面有很多 skill，每个 skill 对应一种开发场景。
比如：
spec-driven-development：先写规格，不要直接开工。
planning-and-task-breakdown：把复杂需求拆成小任务。
test-driven-development：先想清楚怎么验证，再实现。
code-review-and-quality：像 code review 一样检查风险。
debugging-and-error-recovery：修 Bug 时先定位，不要乱改。
frontend-ui-engineering：做前端时关注交互、状态和响应式。
web-performance-optimization：检查性能，而不是凭感觉优化。
launch-and-deployment：上线前做发布检查。
这套东西的价值，不在于名字多酷，而在于它把很多"老工程师的肌肉记忆"写成了 AI 可以遵守的流程。
它怎么用？
如果你只是想快速安装，可以用这个命令：
bash
npx skills add addyosmani/agent-skills如果想先看看里面有哪些 skill：
bash
npx skills add addyosmani/agent-skills --list如果只想安装某一个，比如代码审查：
bash
npx skills add addyosmani/agent-skills --skill code-review-and-quality如果你用的是 Codex，可以这样装：
bash
codex plugin marketplace add addyosmani/agent-skills如果你用的是其它AI编程工具可以直接查看相关文档进行安装 agent-skills
装好之后，就可以在对话里直接调用具体 skill。
比如你不要直接说：
text
帮我做一个积分系统可以换成：
text
@spec-driven-development 帮我梳理一个积分系统的功能规格这时候 AI 的工作就不是马上写代码，而是先把需求拆清楚。
然后你可以继续说：
text
@planning-and-task-breakdown 根据这份规格拆开发任务再到实现阶段：
text
@test-driven-development 先为积分增加和扣减写测试，再实现逻辑写完以后：
text
@code-review-and-quality review 这次改动，重点看边界情况和数据一致性这套流程听起来慢一点，但真的更接近正常开发。
尤其是功能稍微复杂一点的时候，先慢下来，后面反而会快。
我觉得最值得用的几个场景
第一个场景，是做新功能。
以前我们很容易直接让 AI 写代码。现在更好的方式是先让它写 spec。
比如你要做一个优惠券功能，不要一上来就说"帮我写优惠券系统"。这个说法太大了，AI 只能猜。
你可以让它先用 spec-driven-development 梳理：
优惠券有哪些类型？
谁能发？
谁能领？
能不能叠加？
退款后要不要退券？
过期怎么处理？
库存并发怎么处理？
这些问题一出来，你会发现：真正的工作还没开始，但很多坑已经浮出水面了。
第二个场景，是修 Bug。
很多 AI 修 Bug 的方式很像"看见哪里红，就改哪里"。
但真实项目里，Bug 往往不是表面那一行的问题。
这时候用 debugging-and-error-recovery 会更好。它会引导 AI 先复现问题、缩小范围、看日志、找根因，再动手修。
第三个场景，是 code review。
我现在觉得让 AI 做 review，比让它直接写代码更容易出价值。
因为 review 不要求它凭空创造，而是让它站在已有代码上找问题。
比如你可以说：
text
@code-review-and-quality 检查这次改动有没有隐藏风险，尤其关注权限、异常处理和测试缺口这类任务非常适合 AI。
它可能不一定每次都说对，但经常能提醒你一些容易忽略的边界。
这东西适合谁？
如果你只是让 AI 写一次性脚本，可能没必要上这么完整的流程。
但如果你在做一个长期维护的项目，或者你已经开始把 AI 深度放进开发流程里，我觉得它很值得试。
特别是这几类人：
独立开发者。
你没有完整团队帮你 review、测试、把关，那就让 AI 多承担一点流程检查。
小团队。
团队规范还没完全建立起来，可以先借这套 skill 把基本工程动作跑起来。
重度 AI 编程用户。
如果你每天都在用 Codex、Cursor、Claude Code 之类工具，那你很快会发现：提示词不是越短越好，流程才是关键。
我真正喜欢它的一点
agent-skills 最打动我的，不是它提供了多少命令，也不是它支持多少工具。
而是它承认了一件事：
AI 编程的问题，不能只靠更强的模型解决。
模型当然重要。
但工作流同样重要。
一个很强的 AI，如果没有流程约束，也可能把项目改得一团糟。
一个没那么夸张的 AI，如果被放进好的流程里，反而能稳定地产生价值。
这和人其实很像。
新人程序员不是不会写代码，而是不知道什么时候该停下来想一想。
不知道需求哪里有歧义。
不知道一个小改动会影响哪里。
不知道测试应该证明什么。
不知道上线前要检查什么。
而这些，正是工程能力的一部分。
agent-skills 做的事情，就是把这些能力显性化。
最后
我们以前总说，AI 会让编程变得更快。
但我现在越来越觉得，真正重要的不是更快，而是更稳。
快，能让你一天写出很多代码。
稳，才能让这些代码下个月还敢改，半年后还能维护。
agent-skills 不是那种让人眼前一亮的酷炫工具。
它是一套朴素的工作方法：先想清楚，再动手；先验证，再收工；先审查风险，再上线。
这听起来平平无奇。
但软件工程里，很多真正管用的东西，本来就是这样。
它们只是让错误少发生一点，让项目走得远一点。
github地址 agent-skills