开源了一个 oss-skill：蒸馏开源软件作者或项目

蒸馏同事，蒸馏老板，蒸馏名人……当然，还可以蒸馏开源项目。

AI 写代码已是家常便饭。效率爆炸的背后，总有一种隐隐的焦虑：代码写得越来越快，但工程判断似乎成了某种被遗忘的慢功夫。

一个功能该加么？封装是不是做太早了？这个临时补丁不会在半年后反噬吧？这些问题，AI 默认是不会替你考虑的。除非你花更多精力进行各种形式的约束，比如提示词、Workflow、MCP、Skill、Memory 等等。

为了（在当前阶段）缓解这种「判断力缺失」，我决定把一些优秀开源项目的工程直觉，整理成一套可复用的 Skill，减轻大家重复约束的麻烦。（不过大概率模型再次进化后，也就不需要了）

这就是 oss-skill 的由来——Open Source Software Skill。

仓库地址：https://github.com/lianchi/oss-skill （可点击「阅读原文」查看）

来源

这个项目的灵感，来自 GitHub 上的「女娲 Skill」 alchaincyf/nuwa-skill。

截至目前，它已经有 1.2 万+ Star。无论「蒸馏」这个概念到底有多少噱头，但它确实把「蒸馏」做到了一个足够拟真的程度：从公开材料里提炼结构和心智模型，做出来的东西用起来真的有效果。

oss-skill 明确借鉴了它的思路和工程模板。这里要表示一下尊重和感谢。

但两者的关注点不一样。nuwa-skill 更偏向人的思维框架，即这个人怎么看问题。oss-skill 更偏向软件工程里具体的判断动作。

所以我想基于女娲 Skill，把「蒸馏」应用到更具体的开发场景里。

这个 Skill 是干什么的

简单说，oss-skill 是为开发者在 Vibe Coding 时提供的一套专业 Playbook。

它关注的是开源作者、开源仓库、维护团队在真实工程里的判断方式。其最终产物是一个符合你要求的 skill，你可以直接喂给 Claude 或各种代码 Agent。

就是为了适配开发场景：新功能怎么做，code review 先看哪里，API 设计怎么收口，bug 该怎么查，重构怎么推进，或者就是想理解某个 maintainer 为什么接受某个改动、为什么拒绝它。

Coding Agent 已经很强了，为什么还需要它

像 Claude Code、Codex 这样的 Agent，读代码、改代码、补测试、跑流程，已经像呼吸一样自然流畅。但它们默认的逻辑是「完成度优先」——只要能跑通、没报错，它就觉得任务搞定了。

要是小项目、个人玩票项目还好，但众所周知，对于生产级项目，最怕这种不知所以的黑盒。

一个成熟的软件工程，往往是靠「取舍」堆出来的。oss-skill 能帮助提供的，是一个有判断力、甚至有脾气的 Agent。它会模仿你推崇的软件大神，带着某种浪漫、克制和独特的审美，对 AI 生成的代码指手画脚。

很少，有人，真的，可以，一行代码都不写，就能完成一个软件的开发，和，长期维护。

几个例子

例 1

比如你在做一个框架或组件库，想加一个新的公共 API。没有特定约束时，一个通用 Coding Agent 很可能会先帮你把这项能力设计完整：API 怎么命名，参数怎么组织，默认行为是什么，类型怎么写，测试怎么写，文档怎么写。

于是你使用蒸馏出的 Evan-You Skill：（Evan You 是 Vue/Vite 作者）

> 帮我按 Evan You 的工程视角看一下，
  这个新能力是否应该进入框架公共 API？

> 这个能力先不要进公共 API。

  它解决的更像一个特定场景的抽象，
  不像已经稳定成立的通用模型。
  一旦进了核心，后面就要长期承担语义解释、
  组件组合方式和生态兼容成本。

  先考虑：有没有两个以上稳定场景都需要它，
  不加这个能力能不能先通过组合式 API、
  插件或用户态封装解决，它是在补框架的核心表达，
  还是只是在替一个边角 case 找官方入口。
  如果这三件事里有两件答不上来，就先别扩核心 API。

例 2

再比如，一个 patch 为了修 bug，加了几层兼容逻辑、几个额外状态和分支。没有特定约束时，通用 Coding Agent 往往会优先看它能不能覆盖用例、测试补没补齐。它关心的是这次是否能修好。

这时你问 Vitest Skill：（Vitest 是基于 Vite 的现代测试框架）

> 按 vitest 的标准 review 这个 patch，
  重点看边界、状态复杂度和长期维护成本。

> 这个补丁能工作，但方向不太对。

  它为了解决一个边界 case，
  引入了额外状态和分支，主路径反而变复杂了。
  短期像修复，长期更像把局部问题扩散进核心。

  更稳的改法通常是先把异常输入压缩到入口附近，
  尽量别把兼容逻辑带进主流程；如果只是少量 case，
  宁可局部重复，也别把状态空间做大。

注：以上两个例子虽然都是针对技术问题的自然语言回复，但在用户明确要求下，也能直接生成代码。

它是怎么做的

借鉴了 nuwa-skill 的思想，oss-skill 不是抓几个代码库和文档拼凑一下，就说这就是某某的风格，它更看重工程证据。

1. 先确定蒸馏对象

入口通常有两种。你可以直接指定：

> 蒸馏 Evan You

> 做个 vitest 仓库的 skill

也可以先给问题：

> 我想学 Evan You 怎么控制框架 API 膨胀

> 我想学 vitest 怎么处理 breaking change

oss-skill 会自行判断该看作者、仓库，还是维护团队。

2. 代码优先

开源作者和开源项目最有价值的材料，通常是代码、 commit message、PR 和 issue 讨论、release note、设计文档、migration guide。

一个开发者真正接受什么、拒绝什么、为兼容性愿意付出多少代价，最后都会落在代码仓库里。而代码又是当前 AI 推理模型最擅长的领域之一。

3. 按 6 个维度做调研

把调研拆成 6 个维度。

1. 架构：主要看结构、边界、状态和依赖；
2. 变更：看 commit、PR、release 里的变更模式；
3. 评审：看 maintainer 真正在维护和防止什么；
4. 文档：补充作者明确说过的原则；
5. 决策：看关键决策里为什么选 A 不选 B；
6. 演化：看风格怎么形成，后来有没有变化。

4. 提炼真正能落地的东西

最后会重点整理几类内容：

• 工程判断维度：遇到什么类型的编码/设计问题时使用，以及其局限；
• 决策启发式：从反复出现的维护决策中提炼快速规则；
• 代码特征/评审特征：写代码、审代码时有哪些稳定偏好；
• 开发任务映射：针对真实开发任务，提供写代码、review、debug、重构时的最佳实践。

5. 明确边界

这个 skill 中包含很多信息素材搜集整理工作，所以要务实讲证据，切忌过度概括。

证据如果来自于代码仓库，就不要轻易外推到整个人；如果团队痕迹更重，就优先做仓库 / 团队 Skill；只出现一次的结论，不能硬说成稳定风格；代码证据和公开表达冲突时，就把冲突保留下来；等等。

最后

做这些蒸馏类的 skill，经常会有个潜在的担心是，会不会冒犯原作者或维护者。

因为蒸馏某个开发者、某个代码库，本身就带着概括和转述的意味。做的糙了，别人很容易觉得自己被简化、被误读了。

所以有一个原则是，不替原作者发声，不打着原作者名义下判断，不做标签化定义，也不拿别人的开源劳动做轻飘飘的人设消费。

感谢一直以来为开源社区做贡献的那些长期写代码、做维护、回 issue、审 PR、扛兼容性压力的开发者们。

很多人看到的是一个仓库、一个功能、一次发布，背后往往是大量重复、琐碎、很难被看见和理解的工程劳动。

以及再次感谢花叔的 alchaincyf/nuwa-skill。