Meta收购Conductor：并行智能体团队将加入超级智能实验室

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

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

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

DeepSeek 重磅开源的超级 Agent，到底是个啥？

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 质量体系。