将资深工程师工作流融入AI编程

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：像人工代码审查一样检查潜在风险。
debugging-and-error-recovery：修复 Bug 时先定位根因，不要盲目改动。
frontend-ui-engineering：做前端时关注交互细节、状态管理和响应式布局。
web-performance-optimization：基于数据检查性能，而不是凭感觉优化。
launch-and-deployment：上线前执行完整的发布检查清单。

这套方案的价值，不在于名字多么炫酷，而在于它把许多“老工程师的肌肉记忆”转化成了 AI 可以严格遵循的流程。

它怎么用？

如果你只想快速安装，可以运行这条命令：

npx skills add addyosmani/agent-skills

如果想先预览一下有哪些 skill：

npx skills add addyosmani/agent-skills --list

如果只想安装某一个，比如代码审查：

npx skills add addyosmani/agent-skills --skill code-review-and-quality

如果你使用的是 Codex，可以这样安装：

codex plugin marketplace add addyosmani/agent-skills

如果你使用其他 AI 编程工具，可以直接查阅相关文档来安装 agent-skills

安装完成后，就能在对话中直接调用具体的 skill。

举个例子，不要直接说：

帮我做一个积分系统

可以换成：

@spec-driven-development 帮我梳理一个积分系统的功能规格

此时 AI 的任务不再是立刻写代码，而是先把需求分析清楚。

然后你可以继续说：

@planning-and-task-breakdown 根据这份规格拆开发任务

再到实现阶段：

@test-driven-development 先为积分增加和扣减写测试，再实现逻辑

写完以后：

@code-review-and-quality review 这次改动，重点看边界情况和数据一致性

这套流程听起来比直接写代码慢一些，但更贴近正规的软件开发节奏。

尤其是当功能稍微复杂的时候，先耐心慢下来，后面反而能更快交付高质量代码。

最值得用的几个场景

第一个场景，是开发新功能。

过去很容易直接让 AI 开始写代码。现在更好的做法是先让它生成规格文档。

比如你要做一个优惠券功能，不要一上来就说“帮我写优惠券系统”。这个要求太模糊，AI 只能靠猜测来写。

你可以让它先用 spec-driven-development 梳理这些问题：

优惠券有哪些类型？
谁能发放？
谁能领取？
能否叠加使用？
退款后需要退还优惠券吗？
过期如何处理？
库存并发怎么保证数据一致？

这些问题一列出来，你会发现真正的编码还没开始，但很多潜在的坑已经提前暴露了。

第二个场景，是修复 Bug。

很多 AI 修复 Bug 的方式很像“看到报错就改对应行”。
但在真实项目中，Bug 往往不是表面那一行代码的问题。

此时用 debugging-and-error-recovery 会更有效。它会引导 AI 先复现问题、缩小排查范围、查看日志、定位根因，最后再动手修改。

第三个场景，是代码审查。

让 AI 做代码审查，往往比让它直接写代码更容易产出价值。

因为审查不需要它凭空创造，而是让它基于已有代码寻找隐患。

比如你可以说：

@code-review-and-quality 检查这次改动有没有隐藏风险，尤其关注权限、异常处理和测试缺口

这类任务非常适合 AI。

它可能每次不一定完全正确，但经常能提醒你一些容易忽略的边界情况。

这东西适合谁？

如果你只是让 AI 写一次性脚本，可能不需要这么完整的流程。

但如果你在维护一个长期迭代的项目，或者已经开始把 AI 深度嵌入日常开发流程，那么这套方案值得一试。

特别适合以下几类人群：

独立开发者。
没有完整的团队帮你做代码审查、测试和把关，那就让 AI 多承担一些流程检查的工作。

小型开发团队。
团队规范尚未完全建立起来的阶段，可以先借助这套 skill 把基本的工程动作跑通。

重度 AI 编程用户。
如果你每天都在使用 Codex、Cursor、Claude Code 等工具，很快就会发现：提示词不是越短越好，流程才是关键。

真正喜欢它的一点

agent-skills 最打动人的，不是它提供了多少命令，也不是它兼容了多少工具平台。

而是它承认了一个重要事实：

AI 编程的问题，不能单纯靠更强的模型来解决。

模型性能当然重要。
但工作流程同样至关重要。

一个非常强大的 AI，如果缺少流程约束，也可能把项目改得一团糟。
一个不算特别出色的 AI，如果被嵌入规范的流程中，反而能持续稳定地输出价值。

这一点和人很像。

初级程序员并不是不会写代码，而是不知道什么时候该停下来思考。
不清楚需求哪里存在歧义。
不明白一个小改动会影响到哪些模块。
不知道测试应该证明什么。
不了解上线前需要检查哪些事项。

而这些，正是工程能力的重要组成部分。

agent-skills 所做的，就是把这类工程能力显性化、流程化。

最后

我们以前常说，AI 会让编程变得更快。

但现在越来越觉得，真正重要的不是速度，而是稳定性。

快，能让你一天写完大量代码。
稳，才能让你下个月还敢改动，半年后还能轻松维护。

agent-skills不是那种让人眼前一亮的神秘酷工具。

它是一套朴素务实的工作方法：先想明白，再动手；先验证，再收工；先审查风险，再上线。

这听起来平平无奇。

但软件工程中，许多真正经得起时间考验的方法，本来就是这样。

它们只是让错误少发生几次，让项目能走得更远一些。

github地址 agent-skills