你有一个生成工程 postmortem 的好 prompt。你复制下来换了输入，跑在一份营销简报上。输出读起来像一份关于营销简报的 postmortem：时间线、根因分析、“经验教训”。一份完美执行的错形状。
最快修法： 别再改旧 prompt 了。不看旧文本，先用一句话写下新任务目标，再从这句话重建角色、输出格式和示例。改旧的通常会留下你看不出的矛盾；从目标干净重建反而更省时，结果也更干净。下面的 Step 1-6 就是干这件事。
这事发生的原因是机械的，不神秘。Prompt 与原始假设紧耦合：受众、格式、隐性约束，尤其是 few-shot 示例。这些示例对模型的格式、语气、标签的锚定作用，比你的指令还强（所以一个不对的示例就能盖过一条清楚的指令）。任务一变，旧假设就成了隐形污染源。模型按它们走是因为它们还在 prompt 里；它产出的形态契合旧任务，不是新任务。
你属于哪一类？
动手前，先把症状对到原因上。多数复制 prompt 的失败只占其中一两条，不是全部五条。
| 输出里的症状 | 最可能的原因 | 藏在 prompt 哪里 |
|---|---|---|
| 用了新读者看不懂的领域行话 | 受众没更新 | 角色行 / “你是一名……” |
| 结构匹配旧交付物，不是新需求 | 格式继承自旧任务 | 指令 + 输出 schema |
| 引用只在旧示例里出现过的实体 | few-shot 示例来自旧域 | 示例块 |
| 引用现在并不存在的文件、PR 或数据 | 隐性约束来自旧上下文 | ”你有……访问权” 这类行 |
| 一份输出里旧、新受众/主题混杂 | 改了一半的 prompt（化石） | 散落的残留行 |
1. 受众变了，用词没变
旧 prompt 默认工程受众，新任务给营销。行话、语气、细节深度全错，但被原样继承。怎么看出来： 输出用了新受众不懂的领域词。
2. 格式继承自旧任务
旧任务要时间线，新任务要 one-pager。Prompt 还写着”产出时间线”因为你忘删。怎么看出来： 输出结构匹配旧任务，不是新需求。
3. 示例还是旧域
你保留了旧 prompt 的 few-shot 示例。模型仿其形态，产出形态对但任务错。这是最常见的单一原因，因为示例分量最重。怎么看出来： 输出引用了只在旧示例里出现过的实体。
4. 隐性约束来自旧上下文
旧 prompt 有”你有 PR 描述 X 的访问权”——当时是真的，现在是假的。模型现在编 X 长什么样（一个自信的幻觉）。怎么看出来： 输出引用了你新任务里不存在的资源。
5. 改了一半留下化石
你改了旧 prompt 适应新任务但漏了几行。半改 prompt 常常比新写更差，因为里面有你看不出的矛盾，而模型会悄悄选一边。怎么看出来： prompt 里同时有旧、新受众的引用。
动手前先确认
- 不看旧 prompt，先用一句话写下新任务目标。
- 从零定新受众、格式、约束。
- 找旧 prompt，标每行：保留 / 修改 / 删除。
- 保存复制 prompt 的差输出，方便和重建后的结果做 diff。
- 决定是改还是重写。通常重建更快。
最短修复路径
Step 1：从目标句开始
看旧 prompt 之前，把新目标写成一句具体的话：
新目标："为 SMB 卖家产出 Feature X 的 1 页营销简报，
结构：痛点 -> 方案 -> 证据 -> CTA。"和旧目标对比。如果两者共享的结构不到一半左右（受众和格式都变了），就重建而不是补。这句话就是你的 “output contract”（输出契约）——2026 年各团队最先写的那条最佳实践——后面的一切都从它推导出来。
Step 2：逐行审旧 prompt
每行打标。这比事后扫化石快：
- 第 1 行："你是一名资深工程师……" -> 删 （受众变了）
- 第 2 行："产出 postmortem 时间线……" -> 改 为"产出营销简报……"
- 第 3 行："用通俗语言……" -> 留
- 第 4 行：few-shot 示例 A -> 删 （旧域）
- 第 5 行：输出 schema -> 重建Step 3：示例全换
示例承载最重的假设，所以域一变，所有示例都必须换。半改的示例比没示例还差，因为它保着旧结构却装成新的。
差： 把"部署失败因为环境变量缺失"改成"campaign 失败因为跟踪缺失"。
一个半坏的混血，闻着还是 postmortem 味。
好： 换成你团队真实的营销简报示例。来自当前 few-shot 指南的两条实操规则（截至 2026 年 6 月）：多数任务保 2-5 个示例——这是甜点区；并且要均衡。如果大多数示例是同一种形状或同一个标签，模型遇到模糊输入时就会默认选它（majority-label bias，多数标签偏差），而且它会过度看重你列的最后一个示例（recency bias，近因偏差）。把最有代表性的示例放在最后。
Step 4：为新任务重建输出 schema
旧 schema：
{ "timeline": [], "root_cause": "", "action_items": [] }新 schema：
{ "pain": "", "solution": "", "proof": [], "cta": "" }这是不同文档，不是变体。把 schema 写明确，也能挡住模型默认伸手去够旧形状。
Step 5：先用窄样本测一次再放量
新 prompt 跑一个小输入。输出对就放量。不对，说明目标句或 schema 还错——去修这两个，别去抠周边措辞。
一次跑绿不算数。在你拿它干真活之前，用一把不同的输入各跑一遍。2026 年的经验法则：一个好输出什么都说明不了；十个不同输入上的好输出才说明 prompt 稳了。
Step 6：把新 prompt 存成独立模板
不要存成”旧 prompt v2”。存成有自己名字的新任务类型。混着存正是化石积累的源头。如果你用工具管理 prompt（PromptLayer、Langfuse、LangSmith、Braintrust 之类都行），给它一个全新的 prompt ID 从头版本化，而不是从旧的历史里分叉。
怎么确认已经修好
- 输出匹配新任务类型（营销简报，不是 postmortem）。
- 输出引用新域，不是旧域。
- 没有旧受众残留的行话。
- few-shot 示例（如果有）全部来自新域。
- 同事读输出，说不出旧 prompt 是关于什么的。
- 在好几个不同输入上都成立，不只是你最先测的那一个。
如果还是没修好
- 目标句本身可能不清晰——先把它打磨清楚，再去碰 prompt。
- 新域可能需要新的 few-shot 库；写 2-3 个真实示例用上。
- 多个新 prompt 单独都能用之后，再考虑合并。
- 高风险工作绝不复用——总是从目标开始。
常见问答
为什么改了一半的 prompt 比原版还差？ 因为里面有矛盾。旧角色行和新任务行都留在上下文里，模型会悄悄往一个方向消解冲突——往往是旧方向，因为示例还指着那边。干净重建没有相互竞争的信号。
该改旧 prompt 还是写新的？ 只要受众或格式变了，就写新的。只有当任务确实没变、你只是换一个槽位值（名字、日期、输入）时，改旧的才划算。再多一点，从目标句重建就更快也更安全。
我指令里明明写了”营销简报”，怎么还是产 postmortem？ 几乎总是 few-shot 示例的问题。示例对格式和语气的锚定比指令强，所以一个残留的 postmortem 示例会盖过”营销简报”这几个字。先删或换示例，通常这一步就修好了。
重建时该留几个示例？ 多数任务 2-5 个。再少模型就靠猜结构；再多则白付上下文成本、收益不大。让它们在你预期的几种结果上保持均衡，把最有代表性的放最后。
同一个 prompt 在一个模型上能用、另一个上不行，正常吗？ 正常。不同模型对格式和示例模式的反应不一样，所以为某个模型（GPT-5.5、Claude Sonnet 4.6、Gemini 3.1 Pro）调好的 prompt，换到另一个上可能要调示例或 schema。每换一个模型就重跑一遍 Step 5，别默认能平移过去。
预防建议
- Prompt 库按任务类型索引，不按”我用过的好 prompt”。
- 复用前先一句话写新目标，与旧对比。
- 参数化 prompt（带槽位的模板）只换槽位，其余稳定不动。
- 一次性 prompt 干脆不存——每次新写。
- 每季度审 prompt 库；原任务已不存在的删掉。
- 想改时先问：“从头重建会不会更快？“通常会。