Whetstone

Whetstone

Overview

把"你做得好的一段会话"逆向蒸馏成一个岗位级 skill，让一个全新 agent 之后能按你的判断力做出质量相当的工作。核心是从"过程"而非"结果"提炼：会话里有判断力，skill 是这些判断力的载体，不是一份模板。

两条铁律（不可违反）

铁律 1 —— 不确定就提问

凡在"角色定位、触发条件、质量校尺、受众、输出格式、使用边界"这些关键项上有歧义，必须停下来用结构化选项问用户（推荐项放第一位），而不是替你猜。

• 用 ask_user_question，每个问题给 2–4 个选项，并把你的推荐项放第一位并标注 (Recommended)。
• 宁可多问一轮，也不要拿"一个我自己定的答案"当唯一解。基线测试证实：不问就猜，会产出"通用模板的诚实版"而非你的专属 skill。
• 提问工具不可用时不猜、不绕过：如果你身处无法调用交互式提问工具的环境（例如被委派的子代理），把结构化问题原样带回给父级/请求方，并停下来直到获答；不要在受限环境里替用户定答案，也不要换一种方式硬答。

铁律 2 —— 人工闸门（用"达标评估卡"，不用抽象感觉）

不得到用户明确认可（"达标"），绝不把产物当最终 skill 落地到技能库。 达标由用户对照具体证据拍板，不是由分数、重复次数或你的自评拍板。

判断"达标"必须直观，所以你要交付一张**「达标评估卡」，让用户能勾选、能对比**，而不是对着一份 skill 凭感觉打分。卡片含：

1. 标准对照表：会话里提炼的每条判断力要点 | 它在 skill 里怎么编码 | 子代理复现的证据 | ✓/✗。
2. 并排对比：用户自己的成品关键段 ↔ 子代理带 skill 做的新任务关键段（让用户一眼看出质量是否一致）。
3. 一票否决项：哪几条只要不满足就直接判"不达标"（如：把关联当因果、用汇总数字下结论）。
4. 你的判断动作：勾选逐项 + 给结论（达标 / 需微调 / 不达标回炉）。

只给用户看"这份 skill 你说达标吗"是不合格的交付。给不出可勾选的对照证据，就说明验证层还没做完。

When to Use

• 有一段会话/对话，其中的工作是你或某个角色做得很好的。
• 你希望一个全新 agent 之后能按同样的判断力做同岗位的事。
• 你明确要"skill 化 / 岗位化"。

When NOT to Use

• 只有一份成品文件、没有过程上下文。（若你必须做，就以成品 + 你补答的问答为源，并明确标注"缺少过程，判断力有限"。）
• 这件事是一次性的、不会再复用（不值得 skill 化）。
• 标准做法在别处已有充分文档，只是你暂时没找到。

流水线（Stage 0–5）

Stage 0 —— 判定 + 确认

• 判断这段会话值不值得 skill 化：里面是可复用的手法，还是只是一份终稿内容。
• 汇成《意图卡》：做什么岗位 / 哪些手法 / 给谁用 / 什么叫达标。其中"达标"交由用户定义。
• 有歧义就按铁律 1 提问。

Stage 1 —— 会话取证（逆向蒸馏，核心差异化）

• 按时间轴切分会话，标出决策点：用户或专家否决了什么、为什么、最后怎么改的。
• 抽取隐性资产：
  • 红线 / 反范式（反复强调不要做什么）
  • 被否决的方案与理由（这是最值钱的判断力）
  • 定稿时的取舍（为什么选这个、不选那个）
  • 输出结构 / 模板
  • 用语与颗粒度（措辞、直接程度、详略）
  • 质量校尺（什么算做得好）
• 产出《蒸馏物》：persona 薄层 + methodology 厚层的原始素材。

Stage 2 —— 岗位定位 + 人设（两层）

• persona 薄层：领域 / 年资 / 沟通风格（用领域基线表 + LLM 微调，保持可复现又有个人特色）。
• methodology 厚层：触发条件→手法路由、输出模板、质量校尺、反范式、使用边界。
• 把岗位边界固化成 frontmatter 的触发词（防止"一个岗位标题 = 一个 skill"的空泛化）。

Stage 3 —— 脚手架生成

• 结构护栏：必要小节齐全（When to Use / Instructions / Templates / Evaluation / Guardrails）、引用可达、多步流程有编排器。
• 静态审计：名称、描述合规；描述只写触发、不写流程（见 writing-skills 的 SDO）；无断链。
• 安全校验：防注入、防凭据外泄、防路径穿越。
• 版本与文件分离：SKILL.md + 可选 references/、templates/。不要把旧版直接覆写。

Stage 4 —— 验证闭环（护城河；终局 = 你的人工判断，须出具「达标评估卡」）

• 从会话抽取"参考答案 / 预期产出要素"或一份质量 rubric。
• 让一个全新子代理只带该 skill、不给答案，做一个同岗位的新任务（held-out 隔离，防止背题）。
• 用三重验证：① 边界/对抗 case（把"是否胜任"当测点，不是测安全校验器）；② LLM-judge 对照 rubric；③ 用户对照评估卡的人工判断。
• 必须交付「达标评估卡」（见铁律 2），把每条判断力要点、子代理证据、并排对比、一票否决项列出来，供用户逐个勾选。
• 判定（由用户基于卡片）：达标 → 进入下一阶段；需微调 → 改对应项；不达标 → 回 Stage 1 修正，循环。

Stage 5 —— 运维 / 演化（轻量）

• 用过几次后做健康扫描：缺失文件 / 断链 / 膨胀 / 内容重叠 / 工具蔓延。
• 教训回填：新的红线、被否决方案追加进反范式表。
• 可回滚：草稿版本化，不覆写，直到你批准升级。

快速参考

Common Mistakes

• 只给成品模板：退化成通用模板（基线测试教训）。必须从会话的决策点/否决点蒸馏。
• 有歧义却替用户拍板：违反铁律 1。
• 直接产出最终版并落库：违反铁律 2，没过人工闸门。
• 把分数 / 重复次数当质量：质量由用户人工判断，不是指标。
• 把"越位"当成"越界测试"：边界 case 是测技能是否胜任，不是让 agent 做无关的事。

Red Flags —— STOP and Start Over

• 我猜了这个角色的质量校尺。
• 用户没提供受众 / 结构，我就直接生成了。
• 我直接写出了最终 SKILL.md，而没先给草稿等用户确认。
• "这是标准行研模板，直接套就行。"
• 没让子代理重做验证，就下结论"达标"。

以上任意一条出现 = 停下，回 Stage 0/1，按铁律重做。

资源

• 使用说明（给用户的）：USAGE.md。
• 完整跑通示例：examples/行业研究员-单点营收验证.md（会话→意图卡→澄清提问→蒸馏出的岗位 skill）。

关联

• REQUIRED BACKGROUND: 遵循 writing-skills（Iron Law：没有失败的基线测试不写 skill；本 skill 的测试 = 子代理压力场景）。
• 动手前确认意图：brainstorming。
• 借鉴：agentforge 的两层架构、aceforge 的人工审批门、skill-factory 的版本与教训回填。