# Prompt Forge > 手动调用 /prompt-forge <被测物> <量化验收线>。把一个 skill / prompt / 流程迭代打磨到明确的量化验收标准（如「85 分，可用于真实场景拆解」）。循环：clean-room-eval 评测 → 定位共性问题根因 → 改写被测物 → 换全新案例集复测，直到达标或迭代预算耗尽。强制红线：禁止对着评测案例硬编码或加诱导性限定、禁止下调验收线、被证伪的体系整体弃用不打补丁、每轮必须换新案例集、连续两轮无改善即停止并如实上报。产出偏好选择题与完形填空式模板而非主观题。不自动触发（内含多轮子 agent 评测，开销大）。 - Skill: `ruosong320/prompt-forge` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add ruosong320/prompt-forge` - Raw SKILL.md: https://api.skillmd.com/api/skills/ruosong320/prompt-forge/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: Ruosong320 (https://skillmd.com/u/ruosong320) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/ruosong320/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 步「命中率上升且无新增共性问题 → 保留」、`本轮结论不可信` 与「达标」的判定口径——以本表为准——但仅在该表某行的一线修复与正文规则确实冲突时生效。同一情形命中多行时，取一线修复最保守的那一行——停下、询问、不写入，一律优先于继续推进。但每一处例外都必须在报告里显式标出，不得静默降级。** | 触发条件 | 一线修复 | 仍失败兜底 | |---|---|---| | 子 agent 评测跑不起来（超时/不可用） | 缩小案例集重试一次 | 降级为主会话干跑，报告标注 `dry_run`；dry_run 占比 > 30% 时声明本轮结论不可信 | | 被测物找不到或不是 SKILL.md | 让用户给出确切路径 | 终止该被测物，报告标 `error`，不改任何文件 | | 用户拒不给量化验收线 | 拿「三件事」各给 2-3 个候选让用户勾选——候选由用户勾选产生，不得自行编一条线顶上 | 不进入循环，就此停止并说明原因 | | 案例集不够支撑下一轮（R4 要求每轮换新） | 让用户补样本 | 停止循环，报「样本耗尽」，不得复用旧案例 | | 改写后超过原文件 1.5 倍 | 精简冗余段落再复测 | 回退本轮改动，换下一个根因假设 | ## 报告 ```markdown ## 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` 记录被否决的改动方向与原因——哪条路走不通，比哪条路走通了更值得留档。