你让模型写一个落地页、重构一个函数、起草一封发布邮件。结果它给了你 10 条要点：“写落地页的步骤”、“重构时要考虑什么”、“发布邮件要包含什么”。交付物没到——只到了关于”怎么产出交付物”的元讨论。这就是规划模式失效：模型把你的请求当成”求建议”，于是回方法不回工件。同一个模型，你问 "hero 文案怎么写" 它给你清单，你说 "写 hero 文案，两行内，不超过 14 字" 它直接交文案。
常见原因
按命中率排序。
1. “怎么”框架把模型推进建议模式
典型反面：
"我该怎么写这个函数？"
"这封邮件最好怎么写？"
"这段代码怎么重构更易读？"模型把它们当方法题，回方法。技术上没错——只是不给工件。
如何判断：prompt 的主要动词是 "怎么"、"什么"、"解释"、"approach"，而不是 "写"、"产出"、"输出"、"返回"。
2. 任务大，模型用规划自我保护
请求是 "给我搭一个 CRUD 应用" 或 "重构这个 800 行文件"，模型常常先给计划，因为完整工件超 token 限制、或一次性产出有风险。计划是它的”安全阀”。
如何判断：输出是编号的阶段列表，每个阶段只有名字、没有真实代码或内容。
3. 输出 schema 隐含”叙述”需求
"解释怎么做 X" 或 "描述做 Y 的步骤" 这种 prompt 本身就在要叙述，而叙述天然成列表。你要的不是工件，是”造工件的描述”。
如何判断：重读 prompt，动词是描述性的（解释、描述、走一遍），输出列表是设计的结果。
4. 前轮建立了规划框架
如果第 1 轮是 "我们先规划下迁移"，第 5 轮是 "现在做第一步"，模型多半留在规划模式，回的是子步骤而不是执行。
如何判断：往上翻。最近几轮都是阶段、里程碑、“怎么 approach”，不是具体工件。
5. 模型以为你在学，不是在出活
教程类训练数据严重列表化。当请求看起来像学习问题，模型默认进教学模式。"我想理解 X" 触发列表；"产出 X" 触发工件。
如何判断：输出读起来像教程的小节标题，带 "首先你应该考虑……" 这类句式。
6. 含糊的”给我 X”——X 既可能是文档也可能是项目
"给我一份营销计划" 是含糊的——X 是一份计划文档，还是一串营销步骤？模型常选列表，因为列表比写一份有立场的文档”更安全”。
如何判断：输出是 bullet；其实交付物可以是散文、表格或代码块。
动手前先确认
- 确认问题是本地、chat UI、还是 API 出现的；表现可能不同。
- 记下完整 prompt、模型、system prompt、以及前几轮历史。
- 把列表输出原样保存，与改写后对比。
- 判断任务是否真的大到需要先规划。
- 检查 prompt 是不是不小心写成”怎么”问句而非指令。
需要收集的信息
- 完整 prompt 文本和 system prompt（如有）。
- 模型名称版本、temperature、对话历史。
- 列表输出 vs 你真正想要的工件。
- 想要的交付物形状（代码？散文？表格？JSON？）。
- 之前是否在某一轮请求过规划。
最短修复路径
按收益排序。
Step 1：把”怎么”改成祈使动词
| 规划 prompt | 执行 prompt |
|---|---|
"我该怎么写这个函数？" | "写这个函数。签名：getUser(id: string): Promise<User>。给可运行 TypeScript。" |
"这封邮件最好怎么写？" | "写这封邮件。主题行 + 4 句正文。语气：温暖、直接。" |
"这段代码怎么重构更易读？" | "输出重构后的完整代码。行为不变。单函数不超过 20 行。" |
把动词从 怎么 换成 写/输出/产出，做了 80% 的工作。
Step 2：禁用规划词汇
附加：
输出规则：
- 直接产工件，不要给计划或步骤清单。
- 不要写 "首先你应该……" 或 "这件事可以这样 approach"。
- 工件本身不需要标题就别加标题。
- 没有前言；从工件第一行开始。Step 3：钉死工件类型和形状
明确告诉模型输出的”类型”：
输出类型：TypeScript 函数，单文件。
非显然逻辑才加注释。
不超过 40 行。或：
输出类型：3 段博客 intro。
长度：80-120 字。
首句必含具体数字或专有名词。类型化的返回值堵住模型用列表替代的可能。
Step 4：大任务把”规划”和”执行”拆成两轮
任务真的需要规划就显式拆：
轮 1："列出重构这个文件需要的 4 个子任务。先不写代码。"
轮 2："完整执行子任务 1。输出代码，不是代码的计划。"千万别在一个 prompt 里同时做——后半段必退化成列表。
Step 5：给”结果示例”不要给”计划示例”
用 few-shot 展示工件：
示例输出：
---
export async function getUser(id: string): Promise<User> {
const row = await db.query.users.findFirst({ where: eq(users.id, id) });
if (!row) throw new NotFoundError(`user ${id}`);
return row;
}
---
现在给 getOrder(id: string) 写同样形状的代码。模型会复制示例的形状——工件示例就出工件。
Step 6：对话卡在规划态就重置
如果 1-5 轮都在规划，第 6 轮才是执行，新开会话只粘相关上下文。长规划会话累积的框架，单次追问消不掉。
怎么确认已经修好
- 输出是成品工件（代码、散文、表格、JSON），不是步骤编号清单。
- 同事可以直接发布或入库，无需再生成。
- 输出前 2 行就是工件本体，不是前言。
- 没有
"首先你应该考虑……"、"这件事可以这样 approach……"这类句式。
如果还是没修好
- 换更强模型——小模型容易能力上限回退为清单。
- chat UI 切到 API，可以锁 JSON schema 或 output type。
- 执行任务把 temperature 降到 0.3；0.7-1.0 容易啰嗦元评论。
- 用 system prompt 把模型设定为”造东西的人，不是导师”。
预防建议
- 规划模板和执行模板分开维护，永远不混用。
- 执行 prompt 的禁用词：
approach、consider、you might、steps to、怎么做。 - 审最近 10 个 prompt：
怎么vs写/输出/产出各多少。目标 80% 是祈使句。 - few-shot 用工件示例，不用计划示例。
- 工具支持结构化输出时，schema 定为
{ artifact: string }而不是{ steps: string[] }。