蔡崇信：千问开源470款模型，开源是AI普及钥匙？

B 站上 DeepSeek 闹鱼灾了，我发起《大肥鱼清除计划》！

Vibe Coding 实战：从零构建现代专业级 AI 搜索引擎

我的第一个出海产品！7 天 2 万

又一个国产版 Codex 神器，也来卷办公了！

day3-如何写出一个高质量的 Skill（组内分享）高质量的 Skill，关键不在“把一个 Prompt 调到多顺”，而在它能不能被验证、被回归、被维护，是一整套能力包。先讲清“什么算好”，再动手做“怎么做好”。评估体系得在 Skill 成形之前就立起来。接下来拿“故障诊断 Markdown 转 YAML”当案例，套路本身是通用的。一、Skill 到底是什么，先想明白一个 Skill 至少要有四块：接口，管的是输入什么、输出什么、边界划在哪；流程，管的是分几步走、每步交出什么产物；规则，管的是硬约束、经验规则和失败模式；降级策略，管的是拿不准的时候怎么办，而不是硬编一个看着合理的结果。高质量的 Skill 都有几个共同点：职责单一、接口清晰、规则能定位、输出可验证。反过来说，把几十条经验一股脑塞进一个主 Prompt，就是典型反例——改一条规则得把整个 Prompt 重调一遍，评估时也说不清到底是哪条规则退化了。二、核心方法：评估先行，Skill 后写别先写转换器再补测试，顺序得反过来：第一步，定义输出契约，什么算合法、什么算合格；第二步，建金标准集，凑一小批人工认可“可放行”的样本；第三步，先写评估 Skill，让它跑金标准集，跑出基线；第四步，再迭代生成 Skill，每次改动都跑同一套评估，既没有退化、目标维度又有提升，才算正向。这就是评估驱动的开发方式：评估相当于 Skill 的单元测试，金标准集则是回归的锚点。三、评估 Skill：三层门禁，一层过不了就不往下跑每层都要留下可追溯的证据。第 1 层是确定性硬门禁，交给解析器、Schema、校验器来做，不花模型成本：输出能不能解析；必填字段是否齐全，类型和枚举是否合法；引用目标是否存在，有没有悬空引用、不可达节点；关键路径至少有一条能走到预期出口。过不了这一层，直接打回。第 2 层是语义断言，用脚本加结构遍历去查“逻辑对不对”，依然是确定性的。通用检查项包括：覆盖率，源材料里的关键步骤、分支、条件，输出里是否都有对应；完整性，每个判断节点是否都有明确出口，有没有死胡同；可达性，每条路径能否到达预期终点，有没有无出口的循环；顺序与依赖，有先后依赖的操作顺序是否保留，有没有被拍平成无序列表。举个例子，故障诊断转换里要查“每个判断项是否都有是/否/异常出口”“每条路径是否能到根因”。第 3 层是 LLM-as-Judge，只处理解析器表达不了的维度：忠实度、完整性、可执行性。但 Judge 会漂移，不能单独放行，必须架在第 1、2 层之上。Judge 的 Prompt、rubric、模型版本都要版本化，换了模型就得用金标准集重新校准。通用的 Judge 维度有这么几项：忠实度，看输出是否忠实源材料意图、有没有自行发明内容；完整性，看关键步骤、条件、证据是否保留，隐式知识有没有被压成空话；收敛性，看输出是否仍指向原目标、有没有发散；可执行性，看下游不依赖源材料能否直接使用。四、金标准集：回归测试的锚点一开始不用标几百份。拿已认可的样本当种子，扩到 15～30 份，覆盖失败模式，而不是随机抽样：完整正例，典型流程；边界或异常分支，像异常路径、循环、前置失败回退；已知易错模式，实际踩过的坑；留出集，不参与调优，只用于最终验收，防过拟合。金标准不必完美，只要在当前标准下认可可放行就行。回归指标上，关键路径用 pass^k（k 次全过），稳定性用 pass@k。五、工程约束：批量产出要能重放幂等：同输入加同 Skill 版本加同规则，输出得一致，否则判断不了变好是因为 Skill 改了还是随机波动；隔离不阻断：单份失败进隔离队列，记下失败层和原因，别阻塞其余任务；版本绑定：规则、rubric、金标准集都进 Git，每份报告绑定“源版本 + 生成 Skill 版本 + 评估 Skill 版本 + Judge 模型版本”；抽样人工复核：盯 Judge 临界样本和易错模式，人工抽检的结果反过来校准 rubric。六、Skill 本身怎么写SKILL.md 控制篇幅，写清楚输入约定、输出契约、分步流程、硬规则、降级策略；经验规则放 references/ 或 rules/，按失败模式分类，别全塞进主 Prompt；拿不准时标 needs_review: true，不要硬编一个看起来合理的结果；迭代靠评估报告驱动，报告会告诉你哪层挂了、哪类失败模式，你改对应的规则文件，而不是漫无目的地调 Prompt。七、落地顺序，别反过来1. 固化输出契约：Schema 加结构约束；2. 建金标准集：从已认可的样本和最易出错的样本开始；3. 先写评估 Skill：跑出基线报告；4. 再迭代生成 Skill：每次修改对比逐项通过率，无退化且目标提升才算正向；5. 批量运行加隔离回放：失败进队列，结束后人工抽检；6. 评估 Skill 自身也要版本化：换 Judge 模型必须重新校准。八、给组员的三条硬要求1. 不许凭感觉说“变好了”：每次修改必须附评估报告对比，拿逐项通过率说话。2. 不许跳过确定性门禁直接看 Judge 分数：前两层挂了，Judge 分数没有意义。3. 不许把规则堆进主 Prompt：规则按失败模式分文件，评估报告要能定位到具体文件。收个尾：生成 Skill 决定“能不能做”，评估 Skill 决定“敢不敢用”。先把评估体系站稳，再让生成器迭代。这样交付出去的就不是一堆“看起来还行”的产出，而是一套可证明、可回归、可交接的 Skill 质量体系。