北京智能眼镜购新补贴15%：单件最高500元，七项举措促消费

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

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

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

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

day3 组内分享聊的题目，是高质量 Skill 该怎么写。分享者的看法是，高质量 Skill 不能等同于「一个调得很顺的巨型 Prompt」，它更接近一个能力包：能验证、能回归、能维护。路径是先界定「什么算好」，再处理「怎么做好」，评估体系得赶在 Skill 本身之前成形。例子用的是把故障诊断 Markdown 转成 YAML，这套方法本身通用。一、先把 Skill 是什么想明白。一个 Skill 起码有四个部分：接口，负责输入什么、输出什么、边界在哪；流程，负责拆成几步、每步产出什么；规则，负责硬约束、经验规则、失败模式；降级策略，负责不确定时怎么处理，而不是硬凑一个看着合理的结果。高质量 Skill 的共性在于职责单一、接口清楚、规则能定位、输出能验证。反过来的做法，是把几十条经验一股脑塞进一个主 Prompt，改一条规则就得把整个 Prompt 重调，评估时也搞不清是哪条规则退化了。二、核心方法：评估先行，Skill 后写。别急着写转换器再补测试，正确次序是：1. 把输出契约定下来，什么算合法、什么算合格；2. 建金标准集，一小批人工认可「可放行」的样本；3. 先把评估 Skill 写出来，让它在金标准集上跑出基线；4. 再迭代生成 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 质量体系。