Leroy
d3e9bd45bd
- SKILL.md 双工作流（创建/迭代）+ 两道门（验料/通用化）+ 三档位 - 7 篇方法论 references + 3 个纯标准库脚本（scaffold/validate/trigger_eval） - 自身触发用例 16 条 + 先例研究/创建/迭代证据报告 - 方法论吸收自 qiaomu-meta-skill 与 luban-skill，取舍见 reports/prior-art.md
3.0 KiB
3.0 KiB
意图工坊——接单与验料
目标不是做问卷，而是避免把一个模糊想法过早包装成错误的结构。用户已经给了足够信息时，直接做，并在动手前写出自己的假设。
什么时候需要问
- 用户只给了粗想法，还没说明输入和输出。
- skill 可能被别人复用（档位至少 shared）。
- 触发边界和相邻请求容易混（比如"优化提示词"vs"优化 skill"）。
- 用户给了参考项目、竞品或长对话，需要先圈定借鉴范围。
必须捕获的七要素
- 重复任务：它要长期接住哪一类反复出现的工作。
- 输入：用户实际会丢给它什么材料（文件、链接、一句话、目录……）。
- 交付物：做好后交回什么——文件、报告、改动、结论。
- 排除项：哪些相近请求不该触发它（负触发，写进 description）。
- 首要标准：速度、一致性、可审计、跨项目，哪个优先。
- 参考：有没有要对标的公开项目；只借结构和方法，不复制表达。
- 已有资产：现成的脚本、模板、旧 skill、笔记、样例在哪，能直接收编什么。
七要素里最容易被跳过的是排除项——而它恰恰是触发不误伤的关键。
中文开场方式
适合模糊请求：
我们先不急着定结构。你先像聊天一样说说：这个 skill 以后最想帮你稳定接住哪类重复工作？你通常会丢给它什么材料？它最后交回什么结果才算好用？
适合目标明确的请求：
我按可复用 skill 来做。默认假设：它要接住的重复任务是 X，输入是 Y，交付 Z，不做 A/B。假设不对的话我动手前先改。
停止追问的标准
当你能写出一句可防守的能力描述时，就停止追问：
这个 skill 接收 <真实输入>，用于 <重复任务>，输出 <可交付结果>，不处理 <相邻但不该触发的请求>。
不要为了把结构做完整而继续问不影响设计的问题。
验料三问（来自工坊第一道门）
| 问题 | 通过信号 | 不通过的处置 |
|---|---|---|
| 重复性 | 这类任务已出现 ≥3 次，或可预见高频出现 | 保留为对话步骤，等重复出现后再收编 |
| 稳定性 | 流程能写成固定步骤，判断点可枚举 | 拆出稳定子流程单独做，其余留对话 |
| 增益 | 能说清比现场对话强在哪（一致性/触发/携带资产/沉淀） | 没有增益就不做，直说 |
三个都过 → 好料。部分过 → 料可用，先调整定位（缩小职责到能过三问的子集）。重复性或增益不过 → 朽木，停手，给替代方向。
从对话历史里提取
用户说"把我们刚才做的这个变成 skill"时，先从对话里提取：实际用的工具、步骤顺序、用户做过的纠正、输入输出格式。这些比用户事后口头描述的"理想流程"更真实——按实际发生的行为建模，再让用户确认删减。