应对 1：Prompt Engineering
约束指令 + 局限性：模型不知道自己不知道什么
本页解决的问题
先给结论「应对 1：Prompt Engineering」要解决的关键问题是什么？
约束指令 + 局限性：模型不知道自己不知道什么
先检查模型究竟看到了什么。 把指令、参考材料、历史、工具和输出规则拆开。上下文变得可见后，通常更容易选对修复方式。
在修改 Prompt 或模型之前，先画出一个小流程的输入和输出。
不断增加文字，但真正的问题其实是相关性、顺序或缺少边界。
加载中…
对话对比
「选择业务场景」怎样变成可执行的指令
「约束指令 + 局限性：模型不知道自己不知道什么」强调的不是某句神奇咒语，而是信息是否足够让模型判断“为谁做、要完成什么、什么结果算合格”。
背景决定方向，限制决定边界
从「约束指令 + 局限性：模型不知道自己不知道什么」可以看出，一个有效请求至少要把任务、受众、输入材料、输出形式和限制条件分开。少了背景，模型只能猜；少了验收标准，即使文字流畅也无法判断是否完成任务。
继续加字不一定继续变好
把「约束指令 + 局限性：模型不知道自己不知道什么」变成一个小练习：只改背景、要求、限制中的一项，保留其他内容不动，观察哪一层真正改变了结果。
从「选择业务场景」走到「对话对比」
「选择业务场景」先把问题落在「场景 A · 智能客服 电商 / 金融客服机器人 用户问产品细节、退款政策，模型极易编造不存在的规则。 场景 B · 内容创作 AI 写作助手 / 公文生成 生成报告时模型可能捏造数据、引用不存在的法规文件。 场景 C · 知识问答 企业内部知识库问答 员工问内部流程，模型用通用知识填充，与公司实际规定不符。 PM 操作要点 加载中…」上；到了「对话对比」，讨论继续推进到「对比视图 Prompt 模板 为什么有效 三种策略 无约束 Prompt 加约束 System Prompt System Prompt 模板 · 可直接复用 无上下文 附上文档 强制说不知道 以「量子纠缠2025年商业应用」为例 发送给模型的内容： 模型回复： 没有 System Prompt 用户问题 → 编造的答案… 模型直接基于训练记忆推 Token，碰上知识盲区会流畅地编造 加入约束 System Prom…」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
写请求时也应逐层补齐：先说任务和受众，再给材料和输出要求，最后加上限制与验收方式；一次只改变一层，才能知道哪项信息起了作用。
- 「选择业务场景」：场景 A · 智能客服 电商 / 金融客服机器人 用户问产品细节、退款政策，模型极易编造不存在的规则。 场景 B · 内容创作 AI 写作助手 / 公文生成 生成报告时模型可能捏造数据、引用不存在的法规文件。 场景 C · 知识问答 企业内部知识库问答 员工问内部流程，模型用通用知识填充，与公司实际规定不符。 PM 操作要点 加载中…
- 「对话对比」：对比视图 Prompt 模板 为什么有效 三种策略 无约束 Prompt 加约束 System Prompt System Prompt 模板 · 可直接复用 无上下文 附上文档 强制说不知道 以「量子纠缠2025年商业应用」为例 发送给模型的内容： 模型回复： 没有 System Prompt 用户问题 → 编造的答案… 模型直接基于训练记忆推 Token，碰上知识盲区会流畅地编造 加入约束 System Prom…
最后的「最后把结论落到实践」把讨论落到「约束指令 + 局限性：模型不知道自己不知道什么」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
互动练习
把模糊需求拼成一条可执行的提示词
把目标、背景和限制说清楚，再把整理好的提示词带到你正在使用的 AI 工具里。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。