Addy Osmani（Chrome 工程负责人）做了一个叫 Agent Skills 的项目，刚突破 27K stars。他的核心观点：AI 编程 Agent 默认行为是走最短路径到「完成」，跳过了高级工程师职业生涯中学会的所有保护性步骤。
问题在哪
你让 Agent 写一个功能，它就写一个功能。它不会问你有没有 spec，不会先写测试再写实现，不会考虑改动是否跨越了信任边界，不会想 PR 对 reviewer 来说长什么样。它产出代码，宣布胜利，继续前进。
这是每个高级工程师花了很多年学会避免的失败模式。高级版本的任务包含「diff 里看不到」的工作：暴露假设、写 spec、把工作拆成可 review 的块、选择无聊但可靠的设计、留证据证明结果是正确的、控制变更大小让人类能 review。
Skill 不是文档，是工作流
Agent Skills 的核心区分：skill 不是参考文档（「关于测试的最佳实践」），而是一个工作流——agent 跟随的步骤序列，每个检查点产出证据，以明确的退出标准结束。
如果你把一篇 2000 字的测试最佳实践放进 agent 的上下文，它会读完、生成看起来合理的文本、然后跳过实际测试。如果你放进一个工作流（先写失败的测试、运行它、看它失败、写最少代码让它通过、看它通过、重构），agent 就有事可做，你就有东西可以验证。
五个核心设计原则
过程优先于散文。工作流是 agent 可执行的；散文不是。
反合理化表。每个 skill 都有一张表，列出 agent 可能用来跳过工作流的常见借口，配上预写的反驳。比如「这个任务太简单不需要 spec」→「验收标准仍然适用。五行也行，零行不行。」LLM 非常擅长合理化，反合理化表是提前写好的反驳，对付 agent 还没说出口的谎话。
验证不可妥协。每个 skill 都以具体证据结束：测试通过、构建输出干净、运行时行为符合预期。「看起来对」永远不够。
渐进式加载。不把 20 个 skill 一次性塞进上下文，而是根据当前阶段动态激活。一个小型元 skill 充当路由器。
范围纪律。元 skill 编码了一条铁律：只碰你被要求碰的东西。不要顺便重构相邻系统，不要删你不完全理解的代码。
来自 Google 的 DNA
这些 skill 里渗透了 Google 工程实践：Hyrum's Law（API 的每个可观察行为最终都会被人依赖）、测试金字塔（80/15/5）、Beyoncé Rule（「如果你喜欢它，就应该给它写测试」）、~100 行 PR 的大小控制、Chesterton's Fence（在你理解为什么之前不要拆掉围栏）。
这些都不是新想法。但它们默认不在 agent 里。Skill 就是确保 agent 在凌晨 3 点设计你的 API 时会应用 Hyrum's Law 的机制。
对出海独立开发者的实操价值
做 AI 编程工具或 Agent 产品的人应该直接抄这个项目的设计思路——反合理化表和验证不可妥协这两个原则，是区分「AI 写的代码」和「AI 写的可交付代码」的关键。
不用 Claude Code 也没关系。这些 skill 是纯 markdown，可以放到 .cursor/rules/，可以给 Gemini CLI、Codex、Aider 用。工具不重要，背后的工作流才重要。
来源：HackerNews