Prompt Forge

Prompt Forge

把一份 skill / prompt 打磨到说得出数字的可用水平，而不是打磨到「感觉好多了」。

它是 clean-room-eval 的上层循环：eval 负责诚实地告诉你烂在哪，forge 负责改，然后再让 eval 用全新案例验一遍。这个分工是刻意的——评测方和修改方共用一套案例，必然过拟合。

何时用

用：一份 skill/prompt 已经能跑但质量不够；要把它推到一个能对外交付的水平；改了很多轮但说不清到底有没有变好。

不用：从零写第一版（先写出来再 forge）；只想知道好不好（clean-room-eval 就够）；改的是业务代码不是 prompt（ship-solution）。

开工前：把验收线钉死

没有量化验收线不许开始循环，否则会无限磨下去。

验收线必须包含：

• 数字：命中率 / 通过案例数 / 覆盖率，如「≥85% 案例通过」。
• 口径：什么算通过，第三方能复算。「质量好」不行；「拆出的值互斥、为区间而非点、覆盖行业标准分类的 ≥80%」可以。
• 场景：在什么条件下达标。「无上下文子 agent 单轮调用」和「主会话多轮引导」是两个完全不同的难度。

用户只给了「85 分」这种模糊说法时，先把它翻译成上面三件事并确认——这一步用 understand-first。用户拒不给量化验收线时，取「异常处理」表中以 用户拒不给量化验收线 开头的那一行处理。

迭代预算同时钉死：默认最多 5 轮。预算是防止无限循环的硬闸，不是目标。

🔴 CHECKPOINT · 🛑 STOP：进循环前逐条过下面四问，四问都要拿到用户的逐条确认；任何一项没确认，不进入循环。

• 数字写出来了吗？ ✗ → 回到上面「开工前：把验收线钉死」一节，按那里的翻译步骤补齐这一项。
• 口径第三方能复算吗？ ✗ → 同上。
• 场景写明了吗？ ✗ → 同上。
• 预算轮数钉死了吗？ ✗ → 同上（预算的定义在同一节）。

用户明确拒绝给量化验收线（不是说得含糊，是拒绝）时，才取「异常处理」表中以 用户拒不给量化验收线 开头的那一行处理。

循环

每轮四步，不得跳步。四步各自会以固定方式失败，遇到就取「异常处理」表中对应的那一行，不得静默跳过。

1. 评测

调 clean-room-eval，全新案例集。记录本轮命中率与共性问题清单。评测评不起来时，取「异常处理」表中以 子 agent 评测跑不起来 开头的那一行处理。被测物路径对不上时，取以 被测物找不到或不是 SKILL.md 开头的那一行处理。

2. 定位根因

对每条共性问题，回答：被测物的哪一段导致了它？

改动必须落到具体段落。定位不到具体位置就改，等于凭感觉重写，下一轮无法归因是哪个改动起了作用。

同时判断问题层级：

• 表述层：意思对，说得不清楚 → 改写措辞。
• 结构层：缺步骤、顺序错、约束漏了 → 增删章节。
• 体系层：整套思路方向错了 → 见下方「整体弃用」。

3. 改写

按红线改（见下节）。一轮只改共性问题，单点问题一律不管——单点问题吃掉迭代预算却不提升整体命中率。改写后体积超过原文件 1.5 倍时，取「异常处理」表中以 改写后超过原文件 1.5 倍 开头的那一行处理。

4. 复测

换全新案例集重跑，与上轮对照。凑不出符合 R4 的全新案例集时，取「异常处理」表中以 案例集不够支撑下一轮 开头的那一行处理：

• 命中率上升且无新增共性问题 → 保留，进入下一轮。
• 命中率上升但冒出新共性问题 → 改动有副作用，评估是否回退。
• 命中率持平或下降 → 回退本轮改动，换一个根因假设重试。

连续两轮无实质改善 → 停止。 如实上报当前分数、卡在哪、为什么这条路走不通、建议的下一个方向。磨不动就是磨不动，把它说出来比刷出一个假分数有价值。

🔴 CHECKPOINT · 🛑 STOP：停止后报卡点并交用户决定换体系还是收工，不自行开启下一轮。

红线

R1 · 禁止对着评测案例硬编码或加诱导性限定

这条最容易违反，因为它伪装成「把要求写清楚」。

案例集里恰好都是「2025 年日本女鞋」这类主题，产出不理想
✗ 在 SKILL.md 里写「拆解时必须给出地域、品类、时间三个维度」
   —— 换成「芯片设计」「养老社区」立刻崩，你只是把答案抄进了题面
✓ 写「识别主题中已被限定的语义槽位，未被限定的槽位才是可拆解方向」
   —— 描述的是判断方法，地域/品类/时间只是它在某类主题上的自然结果

判定方法：把这条新写的规则套到一个完全不同领域的案例上，如果明显不适用或产生荒谬要求，它就是硬编码。

注意区分——反例不是硬编码。 在 skill 里写「✗ 产出『iPhone15』（这是点不是区间）」是合法且有价值的，它教的是判别标准。硬编码指的是用限定条件把模型逼向特定答案形状。写反例说明「为什么错」→ 留；写死「必须包含 X 字段」→ 删。

R2 · 禁止下调验收线

分数上不去就改标准，是把失败重新定义成成功。达不到就如实报达不到。用户可以决定接受当前水平，但那是用户的决定，不是你的。

🔴 CHECKPOINT · 🛑 STOP：用户提出调低验收线时，先拒绝并说明作废前三轮记录；用户坚持才改，且在报告里写明「用户接受当前水平」而非达标。

R3 · 被证伪的体系整体弃用，不打补丁

用户判定某套思路「已经被证伪」时，不要在它上面继续改。证伪的是前提，前提错了，建立在它上面的所有细节调整都是浪费。整块删掉，换一套思路重写。

🔴 CHECKPOINT · 🛑 STOP：整块删掉是不可逆动作，须用户明示确认后才执行；不等同于「这次改动不好，回退」。

补丁堆叠还有个隐性代价：文档里同时留着新旧两套矛盾的说法，模型读了会混乱，比只有旧的更糟。

R4 · 每轮换新案例集

同一套案例连测两轮，第二轮的分数没有意义——改动就是照着它们做的。同领域分布、同难度分布、不同具体案例。

R5 · 输出模板偏好选择题与完形填空

同等效果下，让被调用的 agent 做判别而不是创作：

✗ 「描述这个维度的含义与边界」        —— 主观题，长、飘、难判对错
✓ 「从下列视角库中选出最贴切的一条：P01|… P02|…」  —— 选择题
✓ 「填空：该维度覆盖 <___>，不覆盖 <___>」          —— 完形填空

省 token、提准确率、产出可机器校验。改写时优先把主观题位点转成这两种形式。

R6 · 迭代预算是硬闸

预算耗尽即停，报当前状态。不许「再来一轮就好了」——那句话每轮都成立。

异常处理

循环假设环境理想，实操常遇下列情况。按表处理，不得静默跳过。

本节是上述流程的例外条款：与正文规则冲突时——例如 R6「迭代预算是硬闸」、R4「每轮换新案例集」、R1 的跨领域适用性判定、第 4 步「命中率上升且无新增共性问题 → 保留」、本轮结论不可信 与「达标」的判定口径——以本表为准——但仅在该表某行的一线修复与正文规则确实冲突时生效。同一情形命中多行时，取一线修复最保守的那一行——停下、询问、不写入，一律优先于继续推进。但每一处例外都必须在报告里显式标出，不得静默降级。

报告

## Forge 结果：<被测物>
验收线：<数字 + 口径 + 场景>    结果：达标 / 未达标（当前 X%）    用了 N/5 轮

### 分数轨迹
| 轮次 | 命中率 | 本轮改动（落到具体段落） | 结论 |
| 0 基线 | 40% | — | — |
| 1 | 62% | 第3节维度模板 → 改为语义槽位判别 | 保留 |
| 2 | 58% | 增加正交性约束 | 回退，引入了重复轴 |

### 已解决的共性问题
### 仍未解决 / 卡点
<为什么这条路走不通，建议的下一个方向>

### 红线自查
- R1 新增规则跨领域适用性：<抽查了哪个异领域案例>
- R2 验收线未变更：✓
- R4 每轮案例集独立：✓

未达标时报告以「未达标」开头，不要把部分改善写成成功。

与其他 skill 的关系

• 循环调用 clean-room-eval（评测）。
• 开工前用 understand-first 确认验收口径没理解错。
• 区别于 ship-solution：那个改业务代码、按既定方案执行；本 skill 改的是 prompt 本身，且方案在迭代中演化。
• 全程用 recoder 记录被否决的改动方向与原因——哪条路走不通，比哪条路走通了更值得留档。