百度AI搜索升级：API调用4.9元/千次

离谱，DeepSeek 崩了 5 小时，大家却喊：梁圣恩情还不完？？

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

DeepSeek 全新模型发布，性价比最高的一集！

自己学习ai，直接买cursor 的套餐，还是买gpt 或者claude 的套餐?

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

分享进入第3天，题目是“如何写出一个高质量的 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 质量体系。