AI 写代码越来越快,最危险的是你不知道它改坏了什么

你让 AI 给支付页加一个优惠券字段。

它三分钟写完，回答得也很自信：组件改了，接口接了，样式也顺手补好了。

等你打开 diff，也就是这次代码改动的对比记录，心里开始发毛。它不只加了优惠券输入框，还顺手动了订单总价计算；测试没跑，边界没写，两个本来不相关的文件也被改了。更麻烦的是，你不知道它为什么这么改，也不知道它到底验证过没有。

这不是 AI 不会写代码。很多 AI 编码工具的问题恰恰相反：它写得太快，快到像一个临时工，知道眼前要搬哪块砖，却不知道整栋楼怎么搭。

这时候更需要一张项目地图。从最初的需求对齐、计划拆解，到哪些核心文件绝对不能碰，再到测试究竟跑到哪一步、合并前有没有留下铁证，这一整条链路，过去全靠人工盯着，现在同样得有人来管。

所以我不太想把 Addy Osmani 做的 Agent Skills 只看成一个效率工具。它更像是在 AI 写代码之前多插了一道流程：先问清楚这次到底要改什么，哪些地方不能碰，改完以后又靠什么证明没出事。

先说清楚：它不是让 AI 更会写代码

先别急着看 star 数，也别急着看它支持多少工具。

Agent Skills 本质上是一套用 Markdown 写的工程流程说明书。它没有换模型，也不提供一个新的 IDE，做的事情更朴素：把规格、计划、构建、测试、评审、发布这些步骤，变成 AI Agent 可以按阶段读取的技能文件。

你可以把它理解成给 AI 补了一张项目地图：先确认目的地，再标路线、禁区和验收点。

普通聊天框里，你说“帮我实现优惠券”，AI 很可能直接开写。Agent Skills 更像是把它先拦下来：需求确认了吗？验收条件写了吗？计划拆了吗？测试准备怎么跑？改动结束以后，谁能看懂这次修改的证据？

它把这套流程拆成一批 Markdown 技能文件，常用入口就是 /spec、/plan、/build、/test、/review、/ship。其实不用死记这些命令，核心逻辑很简单：它先按住 AI 往前冲的惯性，不让它一收到需求就盲动，而是分阶段回到需求、计划、验证和合并前检查里。

工具支持和命令数量当然能说明它被很多人关注，但我觉得这些都不是重点。它真正处理的，是目前 AI 编码里最让人头疼的“伪完成”状态：代码看着能跑，测试、plan、review 这些关键步骤却可能早就被它偷偷省掉了。

AI 最容易省掉的，就是测试和 review

AI 写代码时很少说“我偷懒了”。

它更常见的表现是：这点改动不大，先不写测试；这个文件看起来没风险，不用再确认；这个问题我稍后再处理；代码能跑，应该就没事。

人类工程师看到这些话会警觉。AI 不会。它会很自然地把“看起来完成”当成完成。

Agent Skills 里最有意思的设计，是技能文件里的反跳过逻辑。它会把 Agent 常见的跳过理由提前列出来，再配上固定反驳。

比如它准备把测试放到“稍后再说”，技能文件会提醒它：测试不是事后装饰，而是当前步骤的退出条件。它要是拿“改动很小”当理由，也过不去。最麻烦的往往不是它完全不会写，而是它为了让当前页面跑通，顺手改了一个公共函数。优惠券页看起来正常了，订单详情页、退款金额、发票金额却跟着变了。等第二天有人反馈金额对不上，你再回头看 diff，才发现问题不是出在新增输入框，而是出在那个被 AI 顺手改掉的价格计算工具函数。至于“看起来没问题”这种话，在这里基本不算证据，至少要交出测试输出、构建结果或者运行记录。

所以这里不能靠 AI 自觉。只要没有检查点，它很容易把“看起来完成”当成完成。Agent Skills 有意思的地方也在这里：它不是多给几个命令，而是把原本写在 prompt 里的提醒，挪到了每一步结束前必须交代的位置。

优惠券这个小改动，问题不在输入框

回到开头那个优惠券例子。

如果你直接让 AI 写，最后大概率得到的是一堆代码。你要自己倒推：它为什么改这里，为什么没测那里，为什么碰了总价计算。

优惠券这种需求，最怕的不是输入框没画出来，而是金额链路没对上。页面上显示减了 20 元，后端仍按原价下单；用户截图里是 79 元，订单后台是 99 元；客服回头查日志，只看到 AI 改过价格展示，却没人说得清为什么没动结算逻辑。

所以第一步不是 /build，而是 /spec。你得先让它写清楚：有效券怎么展示，过期券怎么提示，重复使用怎么拦截，前端展示金额和后端结算金额不一致时以谁为准，失败时用户能不能继续下单。

那些糊弄事的 spec，往往只写一句“支持用户输入优惠券并展示折扣”，看着挺完整，其实根本没定义失败、过期、重复使用和金额不一致时怎么办。一份合格的规范，要在一开始就把这些细节抠死。

然后才是 /plan。它要把任务拆开：前端输入框、优惠券校验、价格计算、错误提示、测试用例，各自改哪些文件，哪些地方不能碰。计划如果写得含糊，后面就先别让它动代码。

对 AI 来说，最危险的不是不会写，而是边写边扩大范围。计划写得越含糊，它越容易把一个优惠券字段写成一次订单模块重构。

再往后才是 /build。Agent 按计划逐步改，遇到失败就停，不应该一口气把所有文件都扫一遍然后告诉你“完成了”。

最后是 /test 和 /review。测试不是一句“通过了”，而是要留下输出；review 可以简单理解成合并代码前的检查，也不能只写“看起来没问题”。这就像平时过审代码，敷衍的回复永远只有一句“Look good to me”，但它不会告诉你背后藏着什么盲区。真正有价值的 review，必须清楚复盘改动范围、测试结果，以及还没覆盖的风险。

这样走完一轮，留下来的就不只是一份代码改动。你还能倒回去查：需求当初怎么定，计划怎么拆，实际动了哪些文件，测试跑出了什么结果，review 又确认过哪些风险。

这才是它和普通“帮我写代码”最大的区别。

规则写在 prompt 里，不等于真的执行了

很多团队现在已经在 system prompt 或 .cursorrules 里写了规则。你可以把前两者理解成系统提示词和项目级规则文件。

比如“先写测试”“不要改无关文件”“提交前自查”。这些话都对，但问题是太容易被淹没。规则堆到几千字以后，Agent 真正执行时，还是会优先走向最快的答案。

Agent Skills 的做法更克制：规则按阶段加载，不把所有内容一次性塞给 AI。

写需求时看 /spec，拆任务时看 /plan，写代码时看 /build，验证时看 /test，合并前看 /review。每个阶段只处理当前该处理的事。

当然，它没法把 AI 变成靠谱同事。架构该怎么取舍、业务逻辑到底对不对，最后还是得人来判断。

但它能把一部分机械检查前置。测试有没有跑，验收条件有没有对上，有没有碰到不该改的模块，失败时停在哪一步，这些问题不用等 reviewer 从一堆 diff 里重新挖。

我不太建议只看 AI 最后交出来的代码。代码能跑，只能说明眼前这一刻没炸；到了 review 或线上排查时，大家真正需要的是另一套东西：它当时按什么需求改，计划里有没有限制范围，测试覆盖了哪些分支，有没有碰过不该碰的文件。AI 代码一旦进了团队协作，麻烦往往不是某一行能不能跑，而是三天后出问题时，没人说得清当时为什么这么改。

别先上主仓库，拿一个边角任务试

这类工具最怕一上来就进核心仓库。

如果你现在连人工 review 和测试都没有，Agent Skills 也救不了你。它不是帮一个没有流程的团队自动变规范，而是给已经想做规范的人多一层刹车。

更稳的做法，是先拿一个低风险项目试。不要上生产仓库，不要碰支付、权限、登录、合规这些关键链路。比如让它给一个已经存在的表单补两个校验提示，或者给一个工具函数补三条单元测试。任务越小越好，最好是你半小时内能人工复盘完，就算改坏了也能一眼看出影响范围。

第一轮不用看太多指标。最重要的是看 /spec 有没有把验收条件说清楚，/build 有没有老实按计划改，/test 和 /review 留下的记录能不能让你复盘。如果这三件事都做不到，后面接更多技能也意义不大。

这些都跑得顺，再考虑逐步加更多技能。反过来，如果第一轮就出现安装路径不清、失败日志看不懂、Agent 跳过测试、review 形同虚设，甚至改了不该改的文件还不提醒，那就先停。一个还没驯服的工具，不值得拿项目稳定性去冒险。

也别把它当合规审批。Agent Skills 的检查点是 Agent 自检，不是人类签字。安全边界、业务正确性、架构取舍，最后还是要人负责。

它更适合放在那些经常被 AI 一笔带过、但 review 时又一定会被追问的环节里，比如测试、边界条件、改动范围和发布前检查。

以后我会先翻它留下了什么

Agent Skills 很容易被当成又一个 prompt 工程仓库。

但我觉得它真正标志的，是 AI 编码工具的下一个瓶颈。

过去大家评估 AI 编码工具，主要看它能不能写、写得快不快、代码像不像高级工程师。现在变化已经很明显：问题要往后挪一步，写完以后，团队敢不敢合并；出了问题，能不能查清楚它到底改了什么、为什么这么改、有没有验证过。

AI 写代码的成本降下来以后，真正卡住团队的往往不是生成速度，而是 review、测试、回滚、权限和责任链。Agent Skills 的位置就在这里：它不负责让模型更聪明，而是让一次改动留下能复盘的证据。

它还没有解决所有问题。谁能触发 Agent，哪些文件不能动，日志怎么审计，出了问题怎么回滚，这些仍然要靠外部系统和团队流程接住。

所以以后我看 AI 编程工具，不会先看演示里代码生成得有多快。我会先翻它留下了什么：需求有没有写清，计划有没有拆开，测试有没有输出，review 有没有指出风险。翻不出来，就算它写得再快，我也不敢把它直接放进团队流程。