AI 写代码已是家常便饭，效率爆炸的背后有一种隐隐的焦虑：代码写得越来越快，但工程判断似乎成了被遗忘的慢功夫。一个功能该加吗？封装是不是做太早了？这个临时补丁会不会在半年后反噬？这些问题 AI 默认不会替你考虑。
为了缓解这种「判断力缺失」，橙线开源了 oss-skill（Open Source Software Skill），把优秀开源项目的工程直觉整理成一套可复用的 Skill，减轻重复约束的麻烦。
灵感来源
项目灵感来自 GitHub 上的「女娲 Skill」 alchaincyf/nuwa-skill（1.2万+ Star），它把「蒸馏」做到了足够拟真的程度——从公开材料里提炼结构和心智模型，做出来的东西真的有效果。
oss-skill 借鉴了 nuwa-skill 的思路和工程模板，但关注点不同：
- nuwa-skill：偏向人的思维框架，即这个人怎么看问题
- oss-skill：偏向软件工程里具体的判断动作
苏米注：两者互补——nuwa 关注「怎么看」，oss 关注「怎么做」。适合不同场景。
oss-skill 是什么
为开发者在 Vibe Coding 时提供的一套专业 Playbook。关注的是开源作者、开源仓库、维护团队在真实工程里的判断方式。最终产物是一个符合你要求的 skill，可以直接喂给 Claude 或各种代码 Agent。
适配开发场景：新功能怎么做、code review 先看哪里、API 设计怎么收口、bug 该怎么查、重构怎么推进、理解某个 maintainer 为什么接受或拒绝某个改动。
为什么 Coding Agent 还需要它
像 Claude Code、Codex 这样的 Agent，读代码、改代码、补测试、跑流程已经很流畅，但默认逻辑是「完成度优先」——只要能跑通、没报错，它就觉得任务搞定。
但对于生产级项目，最怕这种不知所以的黑盒。成熟软件工程靠「取舍」堆出来。oss-skill 能帮助提供一个有判断力、甚至有脾气的 Agent——它会模仿你推崇的软件大神，带着某种浪漫、克制和独特的审美，对 AI 生成的代码指手画脚。
踩坑记录：很少有人可以一行代码都不写就能完成软件开发和长期维护。AI 完成度高不代表工程判断到位。
使用示例
示例一：判断是否应该进入框架公共 API
做一个框架或组件库，想加一个新的公共 API。通用 Coding Agent 很可能帮你把能力设计完整：API 命名、参数组织、默认行为、类型、测试、文档。
使用蒸馏出的 Evan-You Skill（Vue/Vite 作者）：
帮我按 Evan You 的工程视角看一下，这个新能力是否应该进入框架公共 API？
回复：这个能力先不要进公共 API。它解决的更像特定场景的抽象，不像已经稳定成立的通用模型。一旦进了核心，后面就要长期承担语义解释、组件组合方式和生态兼容成本。
先考虑：有没有两个以上稳定场景都需要它？不加这个能力能不能先通过组合式 API、插件或用户态封装解决？它是在补框架的核心表达，还是替一个边角 case 找官方入口？如果这三件事里有两件答不上来，就先别扩核心 API。
示例二：Review patch 的长期维护成本
一个 patch 为了修 bug，加了几层兼容逻辑、几个额外状态和分支。通用 Coding Agent 会优先看能不能覆盖用例、测试补没补齐。
使用 Vitest Skill：
按 vitest 的标准 review 这个 patch，重点看边界、状态复杂度和长期维护成本。
回复：这个补丁能工作，但方向不太对。它为了解决一个边界 case，引入了额外状态和分支，主路径反而变复杂了。短期像修复，长期更像把局部问题扩散进核心。
更稳的改法通常是先把异常输入压缩到入口附近，尽量别把兼容逻辑带进主流程；如果只是少量 case，宁可局部重复，也别把状态空间做大。
技术要点：以上两个例子是自然语言回复，但在用户明确要求下也能直接生成代码。
oss-skill 是怎么做的
借鉴 nuwa-skill 思想，不是抓几个代码库和文档拼凑就说某某风格，更看重工程证据。
1. 确定蒸馏对象
入口有两种：
- 直接指定：「蒸馏 Evan You」「做个 vitest 仓库的 skill」
- 先给问题：「我想学 Evan You 怎么控制框架 API 膨胀」「我想学 vitest 怎么处理 breaking change」
oss-skill 会自行判断该看作者、仓库还是维护团队。
2. 代码优先
最有价值的材料：代码、commit message、PR 和 issue 讨论、release note、设计文档、migration guide。一个开发者真正接受什么、拒绝什么、为兼容性愿意付出多少代价，最后都会落在代码仓库里。
3. 按 6 个维度调研
| 维度 | 关注点 |
|---|---|
| 架构 | 结构、边界、状态和依赖 |
| 变更 | commit、PR、release 里的变更模式 |
| 评审 | maintainer 真正在维护和防止什么 |
| 文档 | 作者明确说过的原则 |
| 决策 | 关键决策里为什么选 A 不选 B |
| 演化 | 风格怎么形成，后来有没有变化 |
4. 提炼能落地的内容
- 工程判断维度：遇到什么类型的编码/设计问题时使用，及其局限
- 决策启发式：从反复出现的维护决策中提炼快速规则
- 代码特征/评审特征：写代码、审代码时的稳定偏好
- 开发任务映射：针对真实开发任务，提供写代码、review、debug、重构时的最佳实践
5. 明确边界
注意事项：
- 证据如果来自代码仓库，不要轻易外推到整个人
- 如果团队痕迹更重，优先做仓库/团队 Skill
- 只出现一次的结论，不能硬说成稳定风格
- 代码证据和公开表达冲突时，把冲突保留下来
使用原则
做蒸馏类 skill 有个潜在担心：会不会冒犯原作者或维护者？因为蒸馏某个开发者、某个代码库本身就带着概括和转述的意味。
原则：
- 不替原作者发声
- 不打着原作者名义下判断
- 不做标签化定义
- 不拿别人的开源劳动做轻飘飘的人设消费
感谢一直以来为开源社区做贡献的开发者们——很多人看到的是一个仓库、一个功能、一次发布，背后往往是大量重复、琐碎、很难被看见和理解的工程劳动。