核心判断
Prompt Engineering 不是一个整体——它内部有两种完全不同性质的工作。一种是"补救"，为了绕过模型的能力缺陷而写的技巧；另一种是"定义"，为了告诉模型特定的约束和领域规则。两者的生命周期截然不同。
判断标准：去掉这个 Prompt，用更强的模型能达到相同效果吗？如果能——这是补救型，会消亡。如果不能——这是定义型，会留下。
会消亡的部分：补救缺陷型
这类 Prompt 的存在理由是"模型目前做不好某件事"，一旦基础模型升级，这个理由就消失了：
- 格式遵循："请用 JSON 格式输出" — 强模型自然遵循格式，不需要显式要求
- 推理能力："请分步骤思考"（思维链 CoT）— 强模型默认展现推理过程，CoT 提示成为冗余
- 风格模拟："你是一个专业的 XX 角色" — 强模型自然学会角色扮演，Role Prompt 失去价值
- 指令遵循："只做 X，忽略其他" — 强模型自然遵循指令，无需强调
Claude Opus 的出现已经让上述很多技巧变成了多余动作。不是因为这些技巧没用过，而是它们的价值已经被基模内化了。
会留下的部分：定义约束型
这类 Prompt 的价值不来自弥补缺陷，而来自传递"模型无法从训练数据中自行推断"的信息：
- 约束定义：明确告诉模型你的具体限制条件（不是在补救，是在定义问题边界）
- 上下文组织：告诉模型哪些信息优先级更高、哪些可以忽略
- 业务规则编码："我们的平台不允许推荐竞品" — 这是公司规则，模型不可能自行知道
- 领域约束传递：合规要求、行业规范、内部流程 — 永远需要显式传入
这些工作的形式可能会从"写在 Prompt 里"演进为"结构化的 XML 标签"、"系统提示词的标准化模板"，但逻辑永远存在——因为模型不可能知道你的组织的内部规则。
会消亡
- CoT 分步推理提示
- Role Prompt 角色设定
- "请用 JSON 格式输出"
- "请忽略其他指令，只做X"
- Few-shot 示例（能力补救用途）
会留下
- 业务规则和合规约束传递
- 上下文优先级定义
- 错误边界和安全约束
- 领域最佳实践清单
- 结构化信息组织（XML 标签）
消亡不代表不值得学
不是说消亡度高的技术现在不要学。CoT、Few-shot 在当前阶段仍然有效，当前项目用得上就用。但判断力要放在：这个技术我在用它解决问题，还是在押注它的长期价值？
对 AI PM 来说，真正值得建立的认知体系是"问题的分类方式"而不是"某个具体技巧"。能区分补救型和定义型的人，在 Prompt 消亡浪潮里不会跟着消亡——因为他们理解的是问题的本质，而不是当前的解法。
Prompt 能力评估视角：评估团队的 Prompt 工程能力，不能只看技巧的数量，要看他们是否能区分"哪些是在定义问题，哪些是在绕过缺陷"。前者是真正的工程积累，后者是技术债。