Concitech AI · 深度长文
2026/08/23 07:38
23 万 Star 的 AI 编程 Skills，真的让代码变好了吗？
AI 编程 Skill 越来越像一套完整研发流程：先访谈、写规范、拆任务、TDD、评审。但更多问题和文档是否真的能提高代码质量？两项 2026 年基准给出了截然不同、却可以同时成立的答案。
AI 编程圈最近出现了一套很受欢迎的工作方式。
不要马上让 Agent 写代码。先让它连续追问，把需求问透；再建立领域词汇，写 CONTEXT.md 和 ADR；然后生成 Spec、拆 Ticket、做 TDD，最后交给另一个 Agent Code Review。
这套方法的代表之一，是 Matt Pocock 的 skills 项目。截至 2026 年 8 月 23 日，它在 GitHub 上已经超过 23 万 Star。
项目介绍很有吸引力：这些不是 Vibe Coding 的提示词，而是从真实工程经验中提炼出来的 Skills。仓库里包含需求访谈、领域建模、架构设计、调试、TDD、代码审查、任务拆分和实现等完整流程。
它解决的问题也都真实存在。Agent 经常误解需求、生成一团难改的代码、没有测试就宣布完成。先对齐、再实施，听起来当然比“直接开写”可靠。
但一个问题逐渐浮出来：
这些 Skill 真的提高了最终代码质量，还是只是让整个过程看起来更像正规软件工程？
问了更多问题，写了更多文档，讨论持续了更久，人自然会获得一种“这次准备得很充分”的安全感。可最终动手写代码的仍然是同一个模型。
如果没有 with-skill 和 without-skill 的配对测试，这种安全感很难与实际提升区分开。
23 万 Star，不等于 23 万次验证
先看这个项目本身。
它的 README 建议每次修改都使用 grill-with-docs 进行深入访谈，并维护项目共享语言和 ADR。后续流程还可以依次进入：
grill-with-docs
to-spec
to-tickets
implement
tdd
code-review这已经不只是一个提示词，而是一套对研发过程的编排。
项目作者强调，这些 Skill 应当小巧、可组合、可以自己修改，不像 GSD、BMAD 或 Spec Kit 那样接管整个流程。这个设计方向是克制的。
但实际使用时，只要多个 Skill 串起来，问题数量、文档数量和状态转换仍然会迅速增加。用户原本只想改一个模块，Agent 却可能要求先回答一轮架构问题、补上下文文档、写 ADR、生成 Spec，再拆成多个 Ticket。
流程变得完整，不代表代码自动变好。
截至本文核对时，mattpocock/skills 公开仓库中没有找到针对这些 Skill 的行为 Eval，也没有公开同一任务“使用 Skill”和“不使用 Skill”的代码质量、通过率、Token、时间与成本对比。
这并不证明它无效。它只说明 23 万 Star 反映的是传播和使用热度，不是效果测量。
第一项基准说：Skill 很有用
2026 年发布的 SkillsBench，专门用配对实验评估 Agent Skills。
它当前包含 87 个任务、8 个领域和 18 种模型与 Harness 组合。每个任务都在两个条件下运行：
不加载 Skill
加载为任务专门整理的 Skill最终结果很漂亮：
| 条件 | 平均通过率 |
|---|---|
| 无 Skill | 33.9% |
| 有 Skill | 50.5% |
| 提升 | +16.6 个百分点 |
18 种模型与 Harness 组合全部获得提升，增幅从 4.1 到 25.7 个百分点不等。论文还发现，小模型加载合适的 Skill 后，可以追平没有 Skill 的更大模型。
这说明 Skill 并不只是安慰剂。它确实可以把模型原本缺少的程序性知识放进上下文，让 Agent 完成以前做不成的任务。
但论文还有一个容易被忽略的发现：最多只包含三个模块的聚焦型 Skill，效果优于更大、更全面的 Skill Bundle。
Skill 有用，不等于把整套软件工程方法一次性装进去更有用。
第二项基准说：大部分编程 Skill 没有提升
另一项更聚焦软件工程的预印本 SWE-Skills-Bench，结果冷得多。
研究团队从公开仓库收集了 49 个 SWE Skill，把它们放进真实 GitHub 项目的固定版本中，根据明确的需求文档生成约 565 个任务实例，并用可执行测试做确定性验收。
结果是：
| 指标 | 结果 |
|---|---|
| 没有提高通过率的 Skill | 39 / 49 |
| 平均通过率提升 | +1.2% |
| 明显有效的 Skill | 7 个 |
| 降低效果的 Skill | 3 个 |
| 最大 Token 增幅 | +451% |
7 个专业性较强、与任务匹配的 Skill 最多带来 30 个百分点提升。但有 3 个 Skill 让通过率最多下降 10 个百分点，原因之一是 Skill 中的版本化指导与项目实际环境冲突。
更刺眼的是，有些 Skill 在通过率不变的情况下，把 Token 消耗提高了 451%。
Agent 做了更多讨论，读了更多说明，执行了更多步骤，最后交付质量没有变化。
这正是“工程安慰剂”最容易出现的地方：过程增加了，结果没变。
两项研究为什么会得出相反结论
这两个结果并不冲突。
SkillsBench 使用的是为任务精心挑选和整理的 Skill，覆盖多个需要专业知识的领域。SWE-Skills-Bench 测的是公开流通的真实编程 Skill，把它们放入具体项目环境，检查能否满足工程需求。
前者回答的是：给 Agent 一份与任务高度匹配的程序性知识，能不能帮它？
答案是能。
后者回答的是：从网上安装一份编程 Skill，它是否通常能让真实项目做得更好？
答案是大部分时候不能保证。
差别在于四件事：
- Skill 是否包含模型原本不知道的知识。
- Skill 是否与当前任务和版本准确匹配。
- Skill 是否提供了可以执行的反馈回路。
- Skill 增加的上下文和流程成本是否小于收益。
一个教 Agent 调用冷门仿真工具、执行公司内部部署脚本或遵守特定数据库迁移规则的 Skill，通常有明确增量。模型无法凭空知道这些信息。
一个要求 Agent“先深入思考、充分沟通、遵循最佳实践、写出清晰文档”的通用 Skill，增量就很难判断。强模型本来就知道这些原则，额外说明可能只会把同一套常识重复一遍。
文档越多，控制感可能反而越少
写文档本身没有问题。问题是文档有没有清晰的寿命和权威边界。
AI Coding 很容易制造四份内容相似的材料：访谈记录、Spec、实施计划和 Ticket。需求变化后，代码改了其中一条路径，剩下三份继续描述旧世界。
人类很快就会放弃维护。Agent 下一次又把过期文档当成事实，产生新的偏差。
这类文档债务比普通代码注释更难发现，因为它看起来写得完整、逻辑通顺，甚至比当前实现更有说服力。
更稳妥的做法，是只保留三类文档：
| 文档 | 作用 | 生命周期 |
|---|---|---|
| 项目事实 | 架构边界、数据流、部署约束 | 长期维护 |
| 决策记录 | 为什么选择某方案 | 决策改变时更新 |
| 临时计划 | 当前任务如何实施 | 任务完成后归档或删除 |
聊天中的探索过程不需要全部沉淀。被淘汰的方案、重复确认和中间措辞，没有必要永久进入项目上下文。
真正需要保存的，是代码里看不出来、以后仍会影响判断的事实。
Skill 最有价值的三种形态
如果把 Skill 当成一种工程资产，而不是仪式，它至少应该属于下面三类之一。
1. 补充专有知识
例如公司内部 API、部署流程、数据口径、业务规则、版本限制和故障处理手册。
这些内容不在模型权重里，加载后存在清晰的信息增量。
2. 提供可执行工具
好的 Skill 不只告诉 Agent“认真测试”，还附带测试脚本、Fixtures、查询命令和结果解析器。
文字建议容易被忽略，可执行反馈会直接告诉 Agent 当前实现是否合格。
3. 阻止高代价错误
例如数据库迁移必须先备份、生产发布必须跑烟雾测试、安全扫描失败不得继续。
这类 Skill 的价值可以通过负面测试验证：没有 Skill 时 Agent 是否会犯错，有 Skill 时错误率是否下降。
除此之外的通用流程型 Skill，都应该先被视为待验证假设。
如何判断一个 Skill 是能力，还是安慰剂
最小的验证方法并不复杂。
先选 10 到 20 个与你日常工作相近的任务，固定模型、Harness、Thinking Level、代码版本和验收测试。然后做配对实验：一组加载 Skill，一组不加载，每个任务重复运行几次。
至少记录五项指标：
| 指标 | 要回答的问题 |
|---|---|
| 验收通过率 | 最终结果是否真的更好 |
| 回归缺陷 | 是否为了通过局部测试破坏其他功能 |
| Token 与成本 | 提升是否值得额外上下文 |
| 完成时间 | 流程是否让简单任务过度变慢 |
| 人工干预次数 | Agent 是否真的更自主、更可控 |
这里不能让另一个 LLM 只凭“代码看起来不错”打分。能写测试就运行测试，能检查仓库状态就检查状态，能测性能就直接测性能。
如果一个 Skill 让 Agent 多写三份文档、Token 翻倍、耗时增加，却没有提高验收通过率，它就是负优化。
如果删除 Skill 后结果不变，就应该删掉它。Skill 也需要通过删除测试。
人仍然需要掌握项目，但不必亲自决定每个细节
这条讨论最后会回到人的角色。
使用 AI Coding，并不意味着把架构理解外包给 Skill。至少在高风险模块上，人需要讲清楚数据如何进入系统、状态在哪里变化、失败如何恢复、部署边界在哪里。
有了这张心智地图，人与 Agent 的讨论会更短。哪些问题重要、哪些只是流程规定，也更容易判断。
但这不等于人必须提前设计每个函数。Agent 可以探索实现细节，也可以提出更好的架构。人的责任是掌握约束、验收标准和风险，而不是把每一步都写成文档再让模型照抄。
一份清晰的执行方案，加上可运行的测试，很多时候已经足够。再增加流程，应当拿出数据证明它值得。
Skill 的下一步，不是继续扩充，而是建立 Eval
现在的 Skills 生态很像早期 Prompt 工程：大量高 Star 模板、经验总结和成功案例，却很少提供失败率、基线与重复实验。
这种状态不会一直持续。已经有工具开始支持把同一个任务分别在 with-skill 和 without-skill 条件下运行，比较通过率、Token、成本和真实文件变化。
未来一个可信的 Skill 仓库，除了 SKILL.md，还应该带上：
evals/
fixtures/
deterministic graders
with-skill baseline
without-skill baseline
supported versions到那时，我们判断一个 Skill 的依据就不再是作者经验、Star 数量或文档写得多完整，而是它在什么任务、什么模型、什么 Harness 上，稳定改善了哪些指标。
Skill 当然可以有用。
但“看起来更像工程”，和“交付出了更好的工程”，中间还差一套 Eval。
