superpower跟gstack还没摸透，又来个Google大佬的最佳实践，真学不动了

📝

在这个“不用 AI 写代码都不好意思跟同行打招呼”的时代，所有的开发者都体验过大语言模型带来的效率狂飙

原文链接：https://mp.weixin.qq.com/s/VIzr7Vc6ZOqL-TS7XdY35g

在这个“不用 AI 写代码都不好意思跟同行打招呼”的时代，所有的开发者都体验过大语言模型带来的效率狂飙。

在这个“不用 AI 写代码都不好意思跟同行打招呼”的时代，所有的开发者都体验过大语言模型带来的效率狂飙。无论是用 Cursor、Claude 还是 Copilot，看着几百行代码在屏幕上瞬间生成，那种多巴胺分泌的快感令人上头。

然而，狂欢之后往往是无尽的踩坑。

很多人逐渐发现，AI 写出的代码初看惊艳，实则经不起推敲。它往往是一个“看起来能跑”的黑盒：缺乏对边界情况的处理，无视测试覆盖率，架构耦合严重，甚至随意删改那些你虽然看不懂但就是能跑的“祖传代码”。可以说，如果完全放任自流，AI 就像一个手速极快但毫无责任心的实习生，正以光速为你堆砌一座座未来的“屎山”。

如何让 AI 不再只写“玩具代码”，而是产出能直接上线的“生产级代码”？

近日，谷歌 Chrome 团队的资深工程领导者 Addy Osmani 给出了一个极具颠覆性的答案。他在 GitHub 上开源了一个名为 agent-skills 的项目，短短几天内狂揽 4000 多颗 Star，在开发者社区引发了轰动。这不仅仅是一套提示词，而是将大厂资深工程师的灵魂，直接注入到了 AI 的大脑中。

今天，我们就来深度拆解这份火爆全网的 Agent 技能手册，看看它是如何驯服狂野的大模型，重塑 AI 时代的代码开发工作流的。

一、 核心痛点与现状：为什么聪明的 AI 总喜欢走捷径？

要理解 agent-skills 的价值，我们首先要明白一个底层逻辑：大语言模型在生成代码时，天生倾向于“最短路径（Shortest Path）”。

大模型的“偷懒”本性

大模型是被海量数据喂养出来的概率预测机器。当面对一个编程任务时，如果没有严格的约束，它会选择最容易生成、最符合直觉的答案。它不会主动去思考那些繁琐的防御性编程，不会为了一个简单的功能去搭建复杂的测试桩，更别提写详细的架构决策记录（ADR）了。

如果不加以干预，AI 的工作流通常是：看需求 -> 写代码 -> 结束。

原型代码与生产级代码的鸿沟

这种“短平快”的模式，用来写技术原型（Prototype）或者个人脚本没有任何问题。但在真实的商业世界里，原型代码和生产级代码（Production-grade Code）之间隔着一道巨大的鸿沟。

生产级代码要求什么？要求高可用、可维护、可测试、具备良好的安全性，且符合团队规范。资深工程师在写代码之前，脑子里思考的是接口契约、是异常回滚、是状态管理、是系统的长期演进。而这些“看不见的冰山底座”，恰恰是当前 AI 辅助编程最缺失的一环。

Addy Osmani 敏锐地察觉到了这个问题。他指出，我们不能仅仅依靠零散的 Prompt（提示词）来指导 AI，我们需要的是一套强制执行的“工程纪律”。这就是 agent-skills 诞生的背景：给 AI 配备一套标准的作业程序（SOP），让它像高级工程师一样思考和行动。

二、 核心机制拆解：重塑全生命周期开发工作流

agent-skills 的核心设计理念是：将软件开发的完整生命周期进行标准化拆解，并为每一个阶段赋予 AI 特定的行为准则。

它抛弃了传统的“一问一答”式生成，而是建立了一个包含六大阶段的严密流水线：定义（Define） -> 计划（Plan） -> 构建（Build） -> 验证（Verify） -> 审查（Review） -> 发布（Ship）。

为了激活这些流程，项目设计了 7 个核心的命令行指令（Slash Commands），每个指令都强制 AI 遵循相应的工程最佳实践。

1. 谋定而后动：/spec 与 /plan

传统模式下，开发者直接让 AI 写代码。而在 agent-skills 的世界里，写代码之前必须先规划。 使用 /spec 指令，AI 会被强制进入“规范驱动开发（Spec-driven Development）”模式。它不会立刻吐出代码，而是先帮你输出一份详细的产品需求文档（PRD），明确目标、接口结构、代码风格和测试边界。 紧接着，使用 /plan 指令，AI 会将庞大的需求拆解成极小的、可验证的原子任务，并排出依赖顺序。这种做法彻底杜绝了 AI 迷失在超长上下文中的风险。

2. 步步为营：/build 与 /test

进入开发阶段，/build 指令要求 AI 采用“增量实现（Incremental Implementation）”的策略。AI 被禁止一次性修改大量文件，而是必须每次只切下薄薄的一片垂直功能，写完一点，验证一点。 更关键的是 /test 指令。AI 会被强制要求“用测试来证明代码有效”。不管是红绿重构（Red-Green-Refactor）的 TDD 模式，还是严格的测试金字塔分布，都被死死地写进了 AI 的行为逻辑中。

3. 守住底线：/review 与 /ship

代码写完就完事了？并非如此。/review 指令会唤醒 AI 的审查人格，它会从五个不同的维度（代码健康度、安全性、性能等）对刚刚生成的代码进行自我批判，甚至能自动打上严重程度的标签。 最后的 /ship 指令，则教会了 AI 什么是持续集成和持续部署（CI/CD）的“左移”原则，强制它检查功能开关（Feature Flags）和回滚机制。

通过这套指令集，AI 被死死按在了流水线的各个关卡上，想偷懒都不行。

三、 深度融合谷歌工程文化：让 AI 拥有大厂思维

如果仅仅是拆分流程，agent-skills 还不足以被称为“神作”。它真正的杀手锏在于，Addy Osmani 将谷歌著名的《软件工程》（Software Engineering at Google）中的硬核理念，悄无声息地内化成了 AI 的 19 项具体技能。

这里我们剖析几个极为亮眼的工程原则设计。

海勒姆定律（Hyrum’s Law）与 API 设计

在涉及 API 和接口设计的技能中，系统向 AI 灌输了谷歌经典的“海勒姆定律”：当一个 API 有足够多的用户时，API 合同中承诺什么并不重要，系统所有可观察到的行为，都会被某些用户所依赖。 因此，AI 在修改哪怕最微小的接口时，都会被强制要求考虑向下兼容性，遵循“单一版本规则（One-Version Rule）”，并在边界处进行严格的数据验证。它不再是一个随心所欲篡改接口的愣头青。

碧昂丝法则（Beyonce Rule）与测试驱动

在测试环节，AI 会严格执行“碧昂丝法则”。这句起源于谷歌内部的玩笑话（源自碧昂丝的歌词 If you liked it, then you should have put a ring on it），在工程界的意思是：“如果你觉得某个行为重要，你就该给它加上测试”。 当你要求 AI 增加一个新功能时，它会自动检查这个功能是否有对应的测试覆盖。如果没有，它会暂停开发，优先为你补充测试用例。这种测试先行的习惯，是很多工作几年的程序员都难以坚持的。

切斯特顿栅栏（Chesterton’s Fence）与代码简化

我们在让 AI 重构代码时，最怕的就是它把原本起作用的补丁或防御性代码给删了。在 agent-skills 的 /code-simplify 技能中，AI 被赋予了“切斯特顿栅栏”思维模式：在你不明白一堵墙为什么被建起来之前，绝对不要去拆掉它。 这就意味着，AI 在精简代码之前，必须先通过逻辑推演和上下文回溯，搞清楚那些看似累赘的“丑陋代码”是不是为了解决某个特定的线上 Bug。这种对历史代码的敬畏之心，正是资深工程师的标志。

四、 反直觉的底层架构：专治 AI 的各种“糊弄学”

大模型是非常聪明的，聪明到它会像人类一样找借口。为了彻底堵住 AI 的退路，agent-skills 在底层设计上采用了三个极其生猛且反直觉的原则。

原则一：重流程，轻散文（Process, not prose）

大多数人在写提示词时，喜欢给 AI 讲大道理：“请你写出优雅、可读、高效的代码”。这种空洞的形容词对 AI 毫无约束力。 agent-skills 放弃了所有的“散文式”描述。它提供的 19 项技能，每一个都是极度结构化的工作流。没有大道理，只有冷冰冰的第一步干什么、第二步检查什么、第三步输出什么。AI 不需要理解什么是优雅，它只需要像走流程一样，一步步踩中所有的核验点。

原则二：反合理化机制（Anti-rationalization）

这是整个项目最令人拍案叫绝的设计。 人在偷懒时会找借口，AI 也会。比如当你让它写测试时，AI 可能会回复：“这个功能太简单了，不需要测试”，或者“我们可以等功能完全开发完毕后再统一写测试”。 为了对付这种“糊弄学”，每一个技能模块里都内置了一张“反借口表（Excuses and Rebuttals）”。一旦 AI 试图用某些常见借口跳过流程，系统会立即匹配反驳库，将借口驳回，并强制命令其继续执行标准流程。这种预判了 AI 预判的设计，堪称对大模型心理学的降维打击。

原则三：验证不可协商（Verification is non-negotiable）

AI 经常会给出“看起来没问题（Seems right）”的回复，然后自信满满地等待你的夸奖。 但在 agent-skills 的框架下，“看起来没问题”是不被接受的。每个技能环节的最后一步，都设定了硬性的“证据要求（Evidence requirements）”。AI 必须提供测试通过的日志输出、编译成功的命令行结果，或者是真实的运行时数据。没有证据，流程就卡死不往下走。这种死磕到底的态度，最大程度地挤出了 AI 代码中的水分。

五、 落地实践：如何在你的工具链中召唤“超级架构师”？

理论再好，不能落地也是空谈。agent-skills 的另一大优势是其极高的兼容性。无论你使用什么开发工具，都能轻松将其纳入麾下。

无缝接入各大主流工具

这些技能本质上是高度结构化的 Markdown 文件。 如果你使用的是 Claude Code，只需要通过插件市场直接输入一行安装指令即可激活。 如果你是 Cursor 的忠实用户，只需将 SKILL.md 文件复制到项目根目录的 .cursor/rules/ 文件夹下，Cursor 的智能体就会在后续对话中自动遵循这些规则。 对于 Windsurf 或 GitHub Copilot 用户，也可以通过系统规则配置和 .github/copilot-instructions.md 进行低成本的快速集成。

实战推演：化解线上危机

让我们假设一个真实的场景：线上系统的支付接口突然大面积报错。 在过去，你可能会慌乱地把报错信息扔给 AI，AI 会瞬间吐出几十种可能的原因和一段修改代码。你硬着头皮贴上去，结果引发了更大的崩溃。

现在，你拥有了 agent-skills。 你输入了一个指令调用调试技能。此时，AI 会自动变身，按照“重现、定位、精简、修复、防御”的五步法开始工作。 它不会急于改代码，而是先要求你提供网络链路追踪数据（Network traces）。接着，它发现是某个第三方依赖版本升级导致的入参类型不匹配。在给出修复代码后，AI 还会强制自己编写一个前置边界校验逻辑，防止未来再次发生类似情况。最后，它主动生成一份架构决策记录，将这次故障的解决思路沉淀下来。

在这个过程中，AI 不再是一个只会填空的打字机，而是变成了一个能主导危机排查的技术专家。这不仅是代码质量的跃升，更是开发者情绪价值和安全感的巨大提升。

六、 总结与展望：AI 时代开发者的自我进化

Addy Osmani 开源的 agent-skills，本质上撕开了当前 AI 编程的一层遮羞布：AI 可以极大地提高我们敲击键盘的速度，但它无法凭空产生对软件工程纪律的敬畏。

在过去的一年里，我们见证了“提示词工程（Prompt Engineering）”的兴起。但随着 Agent 时代的到来，简单的提示词已经走向穷途末路。未来的开发竞争力，不再是你多快能让 AI 生成一个增删改查的后台，而是你是否有能力管理和编排一个由多个 AI Agent 组成的“超级开发团队”。

agent-skills 是一次从“提示词工程”向“工作流工程（Workflow Engineering）”的伟大跨越。它证明了，只有将人类工程师几十年积累下来的方法论、踩过的坑、总结的铁律，以结构化的方式喂给 AI，大语言模型才能真正成为推动产业升级的生产力工具。

对于每一位开发者而言，这是一个极其强烈的信号：不要再让你的 AI 裸奔了。代码的生成成本正在趋近于零，但能够确保这些代码稳定运行在生产环境中的“工程纪律”，其价值正在被无限放大。

去 GitHub 上拉取这份技能手册，把它装进你的 IDE 里。从今天开始，停止生产“玩具代码”，让你的 AI 为你打工，享受成为技术总导演的乐趣吧。

开源地址：https://github.com/addyosmani/agent-skills

本文转载自微信公众号，如有侵权请联系删除。