长文里同一个概念别换着叫：先给写作 Prompt 加一张术语表 (2026)

AI 写长文时，有一种错误很隐蔽：每句话单看都通顺，读完整篇却像在说不同的东西。上一段写「用户」，下一段换成「客户」；「试用」一会儿变成「体验」，一会儿又变成「测试」；「计划开放」写到后面，悄悄成了「已经上线」。

这类问题不是文风问题，而是概念没有被锁定。一个简单的补法是：先让 AI 建一张术语表，确认每个词的含义和用法，再让它写正文；写完后再按术语表扫描一遍。

术语表到底锁什么

术语表不是词汇越多越好。它只需要管那些一旦换称呼，就可能改变理解的词。通常包括四类：

对象：同一个人群、产品、功能或文件，全文固定用哪个名称；
状态：例如「计划」「测试中」「已发布」，分别代表什么；
动作：例如「申请」「开通」「使用」，不能随意互换；
容易混淆的近义词：哪些词看起来相近，实际上不能当作同义词。

Google 的 Prompt 设计指南建议，在词语可能有歧义时明确解释参数，并用清晰、具体的指令约束输出；它还建议少样本示例在标签、空格、换行和分隔方式上保持一致。1 Anthropic 介绍提升输出一致性的做法时，也把精确规定格式、用示例约束输出和拆分复杂任务列为可用方法。2

把这些建议落到中文写作里，最小的操作单元就是一张可检查的术语表：先规定「这个词指什么」，再规定「什么时候不能换成另一个词」。

可直接复制的 Prompt

这条 Prompt 适合放在资料之后使用。第一次运行只生成术语表，不要急着写正文；你确认术语表后，再发送「按已确认的术语表继续」让它完成写作。

你是一名中文编辑。你要根据我提供的任务和材料完成写作，但必须先建立并遵守一张「术语表」。

<任务>
- 写作任务：[例如：把产品更新说明改写成给现有用户的邮件]
- 目标读者：[谁会阅读]
- 输出形式：[例如：600 字以内的邮件，分成 3 段]
- 其他硬约束：[日期、数字、范围、语气、格式等]
</任务>

<术语表>
如果我已经提供术语表，把它视为最高优先级的词语约定，不要自行改名。
如果我没有提供术语表，请先从任务和材料中找出 5～12 个最容易造成理解偏差的术语，并按下面格式提出候选表：

| 规范用词 | 在本文中的明确含义 | 可以使用的变体 | 不可混用的词及原因 |
|---|---|---|---|
| [词] | [它具体指什么] | [可接受的简称；没有就写「无」] | [相近但含义不同的词；没有就写「无」] |

建立术语表时遵守：
1. 同一个对象、动作或状态只保留一个规范用词。
2. 不要把「计划」「测试中」「已发布」视为同一状态；材料没有说明的状态写「未说明」。
3. 如果两个词可能是同义词，但材料没有足够信息判断，保留两个词并标出「需确认」，不要替我合并。
4. 术语表中的定义只能来自任务和材料；没有依据时写「未提供」，不要补写产品规则或事实。
</术语表>

<材料>
[粘贴参考材料]
</材料>

请严格分两轮执行。

第一轮：只输出「术语表候选」和「需要确认的问题」。
- 不要写正文，不要改写材料。
- 每个术语都给出它在本文中的具体含义。
- 只提出会改变术语含义、事实状态或读者行动的问题，最多 3 个。
- 如果术语表没有关键歧义，写「无需要确认的问题」。

第二轮：只有在我确认术语表后，才继续写作。写作时：
- 只使用术语表中的规范用词；允许使用的变体只能用于术语表明确允许的场合。
- 首次出现术语时，用一句短话说明它在本文中的含义；已在任务中定义的术语不必重复解释。
- 不要把「计划」「测试中」「已发布」互相替换，也不要把「申请」「开通」「使用」互相替换。
- 如果材料中出现了术语表禁止混用的词，保留它的原文引用，并说明它与规范用词的关系；不要悄悄改成事实相同的说法。
- 材料没有提供的事实、状态、数字和因果关系，写「未提供」或删去，不要猜测。

正文完成后，追加「术语核对」：
- 规范用词是否在全文保持一致；
- 是否把禁止混用的词当成了同义词；
- 是否误改了计划、测试中、已发布等状态；
- 是否有术语的实际含义超出了术语表定义。
只列出发现的问题和对应段落；没有问题就写「未发现术语使用问题」。

这条 Prompt 的关键是「两轮」，而不是把「术语统一」多写几遍。第一轮把模型对概念的理解摊在桌面上，你可以在正文生成前纠正它；第二轮把已确认的表当成边界，最后再做一次机械检查。

用一段产品通知看它怎么工作

假设材料里有三句话：

团队权限功能计划在 9 月开放。当前只有部分测试用户可以体验。
管理员可以申请开通，开通后才能使用团队空间。

如果只写「请统一术语」，AI 可能把它改成：

团队权限功能将在 9 月上线，用户可以申请体验团队空间。

这句话读起来更顺，却改了三个地方：把「计划开放」写成「上线」，把「部分测试用户」扩大成「用户」，又把「申请开通」和「使用」混成了一个动作。

先跑第一轮，合理的术语表可能是：

规范用词	在本文中的明确含义	可以使用的变体	不可混用的词及原因
计划开放	预计在 9 月提供该功能；尚未表示已经可用	无	已上线；材料没有这样说
测试用户	当前已经获得体验资格的部分用户	无	所有用户；范围更大
申请开通	管理员提出开通团队权限的请求	无	使用；使用发生在开通之后
使用团队空间	开通后实际操作团队空间	无	申请开通；两者是先后不同的动作

你只需要确认这张表，第二轮就有了可执行的边界。它可以把原文改得更顺，但会保留「计划开放」「部分测试用户」和「申请开通」之间的差别。

为什么术语表比「全文用词统一」更有用

「全文用词统一」只描述了结果，没有告诉模型哪些词必须统一、哪些相近词必须分开。模型通常能发现表面上的重复，却不一定知道「上线」和「开放」在这份材料里是不是同一个状态。

术语表把三个问题分开了：

指的是谁或什么：让「用户」「测试用户」「管理员」不再漂移；
现在处于什么状态：让「计划」「测试中」「已发布」保留时间和权限差异；
动作先后怎样发生：让「申请」「开通」「使用」不被压成一个动词。

这也是为什么它适合和结构化 Prompt 配合：术语表负责锁住概念，正文结构负责安排信息顺序，最后的核对负责找漏网的替换。三者是前后步骤，不是同一行里堆更多要求。

什么时候值得用，什么时候不要加

这条方法尤其适合：

产品更新、帮助中心和操作说明；
合同、政策、制度或内部流程的改写；
多人共同维护、需要跨段落保持称呼一致的长文；
同时涉及功能状态、权限范围、时间节点和操作步骤的通知。

短消息、纯创意写作和刻意追求词语变化的文案，不必每次都建立完整术语表。术语表也解决不了材料本身的冲突：如果一处写「9 月开放」，另一处写「10 月上线」，它最多能把两个状态稳定地保留下来，不能替你判断哪个是真的。

如果任务涉及复杂的结构化数据，单靠 Prompt 也不是最稳的办法。Google 的指南提醒，复杂 JSON 结构应优先使用模型接口提供的结构化输出能力；它还指出，少样本示例过多可能导致过拟合，Prompt 设计仍需要反复迭代。1

最小检查法

第一次使用时，别通读整篇找感觉，只搜三组高风险词：

状态词：计划、预计、测试、开放、发布、上线；
范围词：部分、所有、现有、新用户、管理员；
动作词：申请、开通、启用、使用、关闭。

每搜到一处，就问两个问题：它指的对象和术语表一样吗？它的时间、权限或先后关系变了吗？如果答案不确定，回到术语表修改定义，再让 AI 重写受影响的段落。

先锁概念，再写句子。这样做的收益不在于让每个词都一模一样，而在于让真正不同的概念不被流畅的同义替换悄悄抹平。

References

1
Prompt design strategiesai.google.dev
2
Increase output consistencydocs.anthropic.com