GitHub 2.6万星的＂反AI捷径＂运动:为什么你的AI编程助手总像实习生?

上周三晚上，我在 Claude Code 里丢了一句”帮我加个用户登录功能”。

不到三分钟，代码写好了。路由有了，数据库模型建了，API 接口也通了。我扫了一眼 diff——逻辑没问题，跑得通。

但我心里隐隐不舒服。

没有写规格说明。没有测试。没有考虑认证边界。没有拆分变更大小。没有设计文档。没有思考这个改动会不会影响现有的 session 管理。

代码能跑，但这不叫”完成”。这叫”能交差”。

这和我带过的每一个实习生的工作模式如出一辙——接到需求，直奔代码，跑通就收工。至于规格、测试、评审、安全边界？那些是”后面再说”的事。

我不是唯一一个有这种感觉的人。

就在几天前，前 Google 工程师 Addy Osmani 发起的开源项目 Agent Skills 在 GitHub 上突破了 26,000 颗星。它的使命只有一个：让 AI 编程智能体不再像个实习生。

要理解为什么 AI 编程助手总让你觉得”差点意思”，得先看它的奖励机制是什么。

当你给 Claude Code、Cursor、Codex 或者任何一个 AI 编程工具下达指令时，它们的优化目标非常明确：完成任务。而”完成任务”在 AI 的理解里，通常等同于”写出能跑的代码”。

这导致了一系列连锁反应：

第一，AI 不走流程。 它不会主动问你”这个功能有没有规格说明？”也不会在动手之前写测试。它直接跳到实现阶段，因为那是离”完成”最近的路。

第二，AI 不做权衡。 资深工程师写代码时会考虑：这个改动多大？好不好评审？会不会引入技术债？有没有更稳健的方案？AI 不考虑这些——它的注意力全在”怎么最快实现这个功能”上。

第三，AI 不留证据。 它不会写设计文档，不会记录为什么选 A 方案而不是 B 方案，不会解释决策背后的思考过程。三个月后，当别人（甚至你自己）回看这段代码时，只能看到结果，看不到原因。

这不是 AI 的错。这是设计问题——我们给 AI 的目标太窄了。

Agent Skills 项目文档里有一句话，精准得让人背脊发凉：

“AI 编程智能体的默认行为是采取最短路径达到’完成’状态。”

换句话说，我们教会了 AI 怎么写代码，但没教会它怎么做工程。

资深工程师的秘密：代码 Diff 之外的世界

在软件工程领域，有一个共识：初级工程师和资深工程师的核心区别，从来不是写代码的速度。

区别在于”不可见的工作”。

一个资深工程师接到”加个用户登录”的需求后，脑子里跑的流程是这样的：

1. 1. 梳理假设——登录用 OAuth 还是邮箱密码？要不要支持多因素认证？
2. 2. 写规格说明——明确输入输出、边界条件、错误处理策略
3. 3. 拆分任务——把这个需求拆成 3-4 个可独立评审的小变更
4. 4. 先写测试——定义”什么算正确”，再开始实现
5. 5. 增量实现——写一点，测一点，提交一点，绝不搞大爆炸式变更
6. 6. 安全审查——认证逻辑有没有漏洞？token 怎么存？有没有 CSRF 防护？
7. 7. 写文档——为什么这么设计，有什么取舍，后续注意事项

上面这 7 步，没有一步直接体现在最终的代码 diff 里。但它们决定了这段代码是”能跑”还是”可靠”。

Agent Skills 的核心思想就是：把这些被 AI 视为”可选”的步骤，变成”强制执行”的工程纪律。

Agent Skills 是怎么做到的？

Agent Skills 的实现机制出人意料的简洁。

它不需要改 AI 模型，不需要写代码，不需要训练数据。它用的是一个朴素的思路：给 AI 看一份”怎么做正确的事”的清单，并且要求它按清单来。

具体来说，每个”技能”（Skill）都是一个带有元数据的 Markdown 文件。当 AI 遇到特定场景时，对应的技能文件会被注入到它的上下文中，告诉它：”现在是做 X 的时候，按以下步骤来。”

Agent Skills 目前包含 20 个核心技能，覆盖了软件开发的完整生命周期：

DEFINE（定义）    → idea-refine, spec-driven-development
PLAN（规划）      → planning-and-task-breakdown
BUILD（构建）     → incremental-implementation, test-driven-development,
                   context-engineering, source-driven-development,
                   frontend-ui-engineering, api-and-interface-design
VERIFY（验证）    → browser-testing-with-devtools, debugging-and-error-recovery
REVIEW（评审）    → code-review-and-quality, code-simplification,
                   security-and-hardening, performance-optimization
SHIP（发布）      → git-workflow-and-versioning, ci-cd-and-automation,
                   deprecation-and-migration, documentation-and-adrs,
                   shipping-and-launch

每个技能都遵循一个统一的”解剖结构”：

• • 流程步骤——不是模糊的建议，是具体的、可执行的步骤
• • 触发条件——什么时候该激活这个技能
• • 反合理化表——这是最精彩的设计（下面详说）
• • 红旗警告——什么信号说明出了问题
• • 验证标准——怎么才算”真的做完了”

最精彩的设计：”反合理化”机制

让我用一个真实场景来说明为什么这个设计如此重要。

假设你让 AI “加个新功能”。按照 TDD（测试驱动开发）的技能要求，它应该先写测试。

但 AI 有一个非常人类的特点——它会给自己找借口跳过步骤。

Agent Skills 在每个技能里都内置了一张”反合理化表”，预判了 AI 可能用来跳过步骤的借口，并提前写好反驳：

看到这里你可能会笑——这不就是在教 AI “别偷懒”吗？

但问题在于，AI 偷懒的方式和人类一模一样。它会在心里（或者说在上下文中）合理化每一个跳过的步骤。Agent Skills 的设计哲学是：不要指望 AI 主动做正确的事，要让它没有借口不做正确的事。

这个设计灵感来自 Google 的工程实践。Addy Osmani 在项目中融入了大量 Google 软件工程中的经典概念：

• • Hyrum’s Law（海勒姆定律）——在 API 设计技能中，提醒你：所有可观测的行为都是隐式契约
• • Chesterton’s Fence（切斯特顿的栅栏）——在代码简化技能中，警告你：在理解一段代码为什么存在之前，不要删它
• • Shift Left（左移原则）——在 CI/CD 技能中，强调测试和检查越早做成本越低
• • Beyonce Rule——在测试技能中：如果你不关心它，就别为它写测试（反过来说，你关心的就必须测）

这些不是抽象的原则，而是被嵌入到 AI 每个执行步骤中的具体检查点。

不只是 Claude Code：一个通用的工程纪律框架

虽然 Agent Skills 最初是为 Claude Code 设计的（通过 slash 命令 /spec、/plan、/build、/test、/review、/ship 触发），但它的底层格式——Markdown 文件——是通用的。

这意味着它可以在几乎所有主流 AI 编程工具中使用：

• • Cursor——把技能文件复制到 .cursor/rules/ 目录
• • Windsurf——写入 Windsurf 的规则配置
• • Gemini CLI——用 gemini skills install 一键安装
• • GitHub Copilot——作为 agent 定义和指令文件加载
• • Codex——作为系统提示词注入
• • 任何接受指令文件的 AI 代理——直接用 Markdown 就行

这让它不是一个”工具插件”，而是一个工程纪律的标准格式。

为什么现在会出现这样的项目？

Agent Skills 的爆发不是偶然的。它反映了一个更深层的趋势变化。

2025 年，AI 编程工具的主题是”能用”。 Claude Code 发布，Cursor 崛起，GitHub Copilot 进化，大家兴奋的是 AI 终于能写代码了。

2026 年，主题变成了”用好”。 人们开始发现，AI 写代码的能力已经不是瓶颈——真正的瓶颈是 AI 写代码的质量。

看看 GitHub Trending 最近的数据就知道：

• • Agent Skills（Addy Osmani）——26K+ 星，教 AI 怎么做工程
• • Everything Claude Code——AI 代理性能优化系统
• • DeepSeek-TUI——终端原生的 AI 编程智能体
• • Ruflo——45K 星，多智能体编排平台
• • Dexter——24K 星，自主金融研究代理

开发者社区的关注点已经从”AI 能写代码”转向了”AI 怎么能写出好的代码”。这是一个质的飞跃。

用一个类比来说明：

2025 年是”AI 终于会开车了”，大家都很兴奋。
2026 年是”AI 开车总是闯红灯”，大家开始教交通规则。

Agent Skills 就是那本”交通规则手册”。

对开发者的实际意义

你可能不用 Claude Code，也不打算装 Agent Skills。没关系。这个项目真正有价值的地方在于：它揭示了 AI 编程的通用问题，并给出了通用的解决方案思路。

即使你自己写提示词，也可以借鉴 Agent Skills 的设计哲学：

1. 给 AI 流程，不只是指令

不要只说”加个登录功能”。试试这样说：

请按以下步骤实现用户登录功能：
1. 先写一份简短的规格说明（不超过 200 字）
2. 列出你需要改动的文件和大致行数
3. 先写核心逻辑的测试用例
4. 再实现代码
5. 最后写一段安全审查说明

你会发现 AI 的输出质量完全不同。

2. 预设”反合理化”防线

在你的 prompt 里提前堵住 AI 的退路：

⚠️ 注意：不要跳过测试步骤，不要说"后面再补"，
不要假设"这个功能很简单"。每一步都要做完再继续。

3. 要求证据，不要求感觉

AI 最喜欢说”应该没问题”。让它证明：

完成每个步骤后，请提供验证证据：
- 测试是否通过？贴出测试结果
- 编译是否成功？贴出编译输出
- 是否有安全漏洞？列出你的检查项

结语：AI 不会自己变成工程师

Agent Skills 在 GitHub 上 26,000 颗星的意义，不在于这个项目本身有多完美。而在于它证明了一件事：

整个开发者社区都意识到了同一个问题——AI 编程工具需要工程纪律，而且这个需求巨大到足以让一个纯 Markdown 文件集合获得 26,000 颗星。

AI 不会自己变成工程师。它需要有人告诉它工程师是怎么工作的。Agent Skills 做了这件事——不是通过改变 AI 的能力，而是通过改变 AI 的行为。

也许有一天，AI 编程工具会内置这些工程纪律。但在那之前，像 Agent Skills 这样的项目，就是我们能给的最好的”实习培训手册”。

毕竟，每个资深工程师，都曾经是个实习生。

参考资料：

• • Agent Skills — Production-grade engineering skills for AI coding agents
• • Software Engineering at Google — Google 软件工程实践
• • Google Engineering Practices — Google 工程实践指南