# Ml Prompting Methodology

> 提示即编程：把 prompt 当代码做版本管理与回归测试。当用户问 few-shot 示例怎么选、思维链 CoT 何时有用、输出格式总不稳定、"prompt 改来改去时好时坏"时激活。纪律：回归测试集驱动迭代， 禁止无评估的玄学改写；few-shot 按多样性+代表性选择并固定顺序；CoT 只在多步推理任务启用， 简单分类纯属浪费；结构化输出靠 schema 约束而非口头祈求。不适用于：要不要升级到微调的档位 决策（ml-pretraining-paradigm）。触发词: prompt engineering, few-shot, chain-of-thought, 输出不稳定, prompt 回归测试

- Skill: `fieldlu/ml-prompting-methodology` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add fieldlu/ml-prompting-methodology`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fieldlu/ml-prompting-methodology/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: fieldlu (https://skillmd.com/u/fieldlu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fieldlu/ml-prompting-methodology

---


# 提示工程方法论 — 把 prompt 当代码做回归测试

## R — 原文 (Reading)

> （转述）Brown 等发现：大模型的少样本能力对提示构造高度敏感——示例的选择、顺序乃至格式都会显著改变表现；同一模型不同提示间的差距可与不同方法间的差距一样大，因此提示本身是需要谨慎设计的对象。
>
> — Tom Brown 等《Language Models are Few-Shot Learners》(NeurIPS 2020)

> （转述）Wei 等提出思维链提示：在少样本示例中附带中间推理步骤，可显著提升算术、常识与符号推理类任务的性能——其收益是推理规模带来的涌现性质，小模型上并不出现。
>
> — Jason Wei 等《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》(NeurIPS 2022)

---

## I — 方法论骨架 (Interpretation)

提示工程最大的误区是把它当"文字润色玄学"：凭感觉改措辞、碰运气换示例、好坏全看当天模型心情。本 skill 的立场是：**prompt 是代码**——有输入分布、有行为逻辑、有 bug，因此也应该像软件一样被测试和管理。

四个子系统：

- **示例选择系统**: few-shot 示例不是装饰而是"上下文中的程序"。按覆盖多样性 + 与查询的相似度选择，控制顺序偏差（同一组示例换个顺序结果会变），示例格式必须与期望输出严格一致。
- **推理链系统**: 思维链是给多步推理任务的专用工具——让模型把中间步骤显式写出以减少跳步错误；在简单分类/抽取任务上它只增加 token 成本与延迟而不增加正确率。先判断任务是否有"中间步骤"，再决定是否上 CoT。
- **结构化约束系统**: 输出格式的稳定性靠 schema（JSON Schema/类型声明/字段枚举）约束 + 失败重试解析，不靠在 prompt 里反复礼貌恳求。
- **版本管理与评估系统**: 每个 prompt 改动 = 一次代码提交；固定一个回归测试集（几十条覆盖典型与边界的样本），每次改动跑分对比，涨了才合入。没有评估的 prompt 迭代等于闭眼开车。

这条骨架直接回应 GPT-3 论文披露的核心事实——提示敏感性是真实存在的系统性现象，对抗它的唯一武器就是评估驱动的受控迭代。

---

## A1 — 文献中的经典应用 (Past Application)

*（本批主题超出西瓜书覆盖范围，A1 改引奠基文献的经典案例，均为学界公认的原始实验叙述）*

### 案例 1: GPT-3 论文对提示敏感性的系统实测
- **问题**: 少样本性能到底受哪些提示因素影响？影响多大？
- **方法论的使用**: 作者固定模型、逐一变换单一因素做消融：示例数量（0→1→…）、示例顺序、示例格式、是否自然语言任务描述。
- **结论**: 全部因素都有实质影响——示例数带来平滑增益但边际递减；顺序波动可使方差大到"相当于换一个方法"；元描述与格式一致性各有独立贡献。
- **结果**: 这组消融成为"提示是被设计的对象而非附属品"的直接证据，也定义了本 skill "单变量改动+固定评估集"纪律的出处。

### 案例 2: 思维链的适用边界实验
- **问题**: 让模型"一步一步想"是不是对所有任务都有效？
- **方法论的使用**: Wei 等在三类任务（算术应用题、常识问答、符号推理）上对照标准提示与思维链提示，并同时报告不同参数规模下的表现曲线。
- **结论**: 收益集中在需要组合式多步推理的任务，且随模型规模陡增——小模型上思维链反而产出更流畅的错误推理；简单任务上收益趋近于零。
- **结果**: 确立了"CoT 是推理任务的专用工具且有规模门槛"的边界认知，本 skill 的"先判断有无中间步骤再用 CoT"规则由此而来。

### 案例 3: 自动化提示搜索对人工调优的替代尝试
- **问题**: 人工措辞微调既低效又不可复现，能否让优化算法接手？
- **方法论的使用**: Zhou 等提出 APE（Automatic Prompt Engineer），把指令生成本身建模为优化问题：由模型生成候选指令集、按留出集评分筛选。
- **结论**: 自动搜索的指令在多项任务上达到或超过人工精心构造的指令（转述）；同时暴露出候选间得分差异常在噪声量级的现象。
- **结果**: 一方面证明提示可以工程化优化，另一方面反证"措辞差异带来的分数差必须过显著性检验"——两条都汇入本 skill 的评估纪律。

---

## A2 — 触发场景 (Future Trigger) ★

### 用户会在什么情境下需要这个 skill?

1. 用户在搭 LLM 应用（客服机器人/信息抽取/报告生成），输出格式时好时坏，解析频繁报错，不知道该上 schema 约束还是继续改措辞。
2. 用户写好了 prompt 但效果飘忽，改一句话这里好那里坏，陷入无限 A/B 循环，没有固定的评判基准。
3. 用户纠结 few-shot 示例怎么挑：放几个、放哪些、按什么顺序，以及要不要加"让我们一步一步思考"。
4. 用户听说思维链很神，想给自己的简单分类任务也加上，没人告诉他这是浪费。

### 语言信号 (用户的话里就应激活)

- "**prompt** 怎么写 / **提示词**优化 / prompt 效果不稳定 / 时好时坏"
- "**few-shot** 示例怎么选 / 放几个例子 / in-context examples"
- "**思维链**/**CoT**/**chain-of-thought** 有没有必要 / let's think step by step"
- "输出 **JSON** 老是解析失败 / 格式约束 / structured output"
- "prompt 改了一版变好了但不知道为什么 / **prompt 版本**管理 / 回归测试"

### 与相邻 skill 的区分

- 与 `ml-pretraining-paradigm` 的区别: 那是档位决策器（提示不够时要不要升微调）；本 skill 是档位 0 内部的施工规范。用户说"prompt 不行了怎么办"→ 先走那边确认不用升档，再到本 skill 施工；或本 skill 回归测试显示已到提示档天花板 → 移交那边升档。
- 与 `ml-evaluation-design` 的区别: 那是通用三层评估设计（切数据/定尺子/比较检验），本 skill 复用其原则但场景特化——评估对象从"模型+超参"变成"一段文本"，回归测试集规模小得多、迭代频率高得多。
- 与 `ml-llm-evaluation` 的区别: 那管"LLM 能力怎么科学度量"（benchmark 局限/污染/judge 偏差）；本 skill 管"单个应用的 prompt 怎么迭代变好"。前者提供尺子校准，后者做日常开发。

---

## E — 可执行步骤 (Execution)

当 skill 被激活后, agent 应按以下步骤执行:

1. **建立回归测试集（一切之前）**
   - 从真实输入分布采 30-100 条：覆盖典型样本 + 已知失败案例 + 边界情况（空输入/超长/对抗格式）；标注期望输出（可粗粒度：关键字段正确即可）。
   - 完成标准: 测试集落盘且冻结版本；含至少一条曾实际翻车的样本。
   - 判停条件: 用户拒绝构建测试集只想"帮我改改措辞" → 明确告知无评估的改动无法判定好坏，仍坚持则仅给出通用建议并声明不可验证。

2. **任务分解定工具**
   - 判断任务类型：有无多步推理成分（计算/多条件联查/逻辑推导）？输出结构化程度要求？
   - 完成标准: 任务画像一句卡："该任务是 X 型，CoT 开/关，输出需/不需 schema"。
   - 判停条件: 简单分类/抽取任务 → 关闭 CoT（省 token 与延迟），直接进步骤 3。

3. **组装初始 prompt**
   - 结构四件套：角色/任务描述（含元说明）→ few-shot 示例（格式与期望输出严格一致，覆盖主要类别，避免全部同类）→ 本次输入 → schema 约束（若步骤 2 判定需要）。
   - 完成标准: 初始版本 v1 入版本库（git 或带时间戳文件），并在回归集上记录基线分。

4. **受控迭代循环**
   - 每轮只改一个变量（指令措辞 OR 示例集合 OR 示例顺序 OR schema 字段），跑完整回归集记分；分数上升才合入新版本，下降或持平即回滚。
   - 完成标准: 版本历史表（vN/改动点/回归分/结论）；禁止一轮堆多个改动。

5. **稳健性抽检**
   - 对最优版本做扰动测试：调换 few-shot 顺序、替换同义措辞、混入边界输入，观察分数波动幅度。
   - 完成标准: 给出"该 prompt 对 X 扰动敏感"的稳健性结论；高敏感项写入交付文档的使用注意事项。
   - 判停条件: 扰动导致分数剧烈震荡（超过效应阈值）且无法通过设计稳定 → 提示档天花板信号，移交 `ml-pretraining-paradigm` 评估升档微调。

6. **上线监控**
   - 部署后持续采样线上失败案例回填回归集；模型/API 版本升级视为外部变更，须全量重跑回归。
   - 完成标准: 回归集进入维护状态（定期扩充）；有供应商变更触发重测的约定。

---

## B — 边界 (Boundary) ★

### 不要在以下情况使用此 skill

- 根本问题是"该不该放弃提示转微调/RAG"→ `ml-pretraining-paradigm` 的档位决策树；本 skill 只在确定留在提示档后开工。
- 要评估的是模型整体能力而非一个具体 prompt 的好坏 → `ml-llm-evaluation`。
- 传统 ML 的超参调优 → 那是 `ml-diagnosis`/`ml-evaluation-design` 的语境，"prompt 回归测试"那套不适用。

### 文献反复警告的失败模式

- **无评估的玄学迭代**: 凭感觉改措辞、用单条样例判断好坏——GPT-3 论文的消融已证明提示因素影响巨大且带噪声，没有固定测试集的"改进"大概率是噪声捕获。
- **示例随手贴**: few-shot 用例全部同类/格式与期望输出不一致/顺序从不固定，等于给模型一份错误的程序说明书。
- **简单任务滥用 CoT**: 分类和抽取上加"一步步思考"，token 翻倍延迟翻倍而正确率原地踏步；Wei 等的边界实验就是为此划线。
- **口头祈求格式**: 反复写"请务必输出 JSON 不要多余内容"却无 schema 校验与重试机制，把工程问题当态度问题。
- **一次改五处**: 措辞、示例、顺序、schema 同时动，涨了不知归功谁、跌了无法回滚——违反本 skill 单变量纪律。

### 作者盲点 / 时代局限（本批为外推补全）

- **必须声明**: 本 skill 主题超出西瓜书(2016)覆盖范围——BOOK_OVERVIEW 批判节指出提示范式在书中完全缺失；本 skill 是对该时代局限的外推补全，素材为 2020-2023 文献共识转述，**方法论仍在快速演化**（自动提示优化/长上下文/多模态提示不断改写最佳实践），执行时应核对当前格局。
- **提示脆弱性是未解难题而非已解决的问题**: 文献证实敏感性存在，但对"如何构造对扰动鲁棒的提示"缺乏成熟理论；本 skill 的回归测试只是止损手段，不消除脆弱性本身。
- **评估集自身的偏差盲区**: 回归测试集来自开发者想象的真实分布，可能与线上分布漂移；30-100 条的小样本使小幅改进难以与噪声区分——本 skill 要求效应须大于 seed 波动，但未解决根本的统计功效问题。
- 西瓜书的 NFL 思想在此依然成立："没有对所有任务都最优的提示模板"，网上流传的万能 prompt 清单脱离任务谈优劣，正是 NFL 陷阱的当代形态。

### 容易混淆的邻近方法论

- **RAG（检索增强生成）**: RAG 是知识注入架构，prompt 技巧无法弥补缺失的知识；用户抱怨"模型不知道我们内部流程"时应先考虑 RAG 而非改措辞。
- **系统指令 vs 用户输入**: 二者的注入攻击面与优先级机制完全不同，安全相关的约束应放在系统侧并假设用户输入不可信——这属于安全问题，超出本 skill 的效果优化范畴。
- **模型参数温度等解码配置**: 温度/top-p 影响输出随机性，属于推理配置而非提示文本；"调 temperature"不能替代提示迭代，但二者常被混为一谈。

---

## 相关 skills

- depends-on: ml-llm-evaluation（评估纪律的尺子校准来源）
- contrasts-with: ml-pretraining-paradigm（档位内施工 vs 档位间升降级）
- composes-with: ml-evaluation-design（回归测试的统计原则来源）, ml-methodology-router

---

## 审计信息

- **来源性质**: 扩充批B·深度学习与大模型时代——主题超出西瓜书(2016)覆盖范围，R 段为经典文献共识的转述表述（均已标注"（转述）"）
- **验证通过**: 待流水线三重验证复核
- **测试通过率**: 待阶段 4 测试 (详见 test-prompts.json)
- **skill_version**: 0.0.1
- **蒸馏时间**: 2026-08-24