遇到「读起来通顺、但同一概念有多个叫法」的中文技术稿，建议先处理术语，再处理句子。术语不一致属于事实层面的问题：同一份文档里出现「推理服务 / inference service / 推理后端」三种写法，读者检索、对照代码、跨文档引用都会出错；句子不够顺只是可读性问题，而且改写句子时很容易顺手动到术语，把刚统一好的叫法重新打散。可以先按这个顺序走：抽取候选术语 → 建立对照表 → 标出混用位置 → 用提示词只替换术语 → 复查代码块。适用场景是 Claude Opus 5.5 已经产出一版结构基本完整的中文技术稿；如果原稿本身缺章节、结构混乱，需要先补结构，术语统一放到结构稳定之后再做。
中文技术稿的检查顺序建议是：术语对照表优先，句子流畅度其次。术语不一致会直接影响检索、代码对照和跨文档引用，属于要先修的事实问题；句子改写容易连带改掉术语，所以放后。做法是先人工抽出名词短语、缩写、产品名和模块名，建一张对照表，再用表里的禁止写法定位混用句子，只做术语替换、不动句式。边界是：结构不完整的稿子先补结构，代码块和字段名不要交给模型自由改写。
从原稿中抽出专有名词和缩写
第一步的目标是先得到「需要统一命名的对象列表」，不要指望模型自动识别。模型在长文里往往把同一个概念拆成几个不同条目，或者漏掉只出现一次的缩写。抽取方式是把原稿按段落复制到一张草稿表里，逐段人工扫，重点抓四类对象：
- 名词短语：如「推理服务」「上下文窗口」「批次大小」。
- 英文缩写：如 API、SDK、TTL、JSON-RPC。
- 产品名与模块名：如模型名、组件名、子模块名。
- 代码里出现的标识符与字段名，先记下，后续不参与中文替换。
抽取时可以先用编辑器的查找功能把疑似概念过一遍，但最终归并要靠人判断：写法不同、指的是不是同一件事，只有读上下文才能确认。这一步做完，你会得到一份候选清单，里面允许有重复，重复在第 2 步合并。
建立中文名、英文名、缩写对照表
第二步是把候选清单收敛成唯一写法。建议每行只定义一个概念，字段固定下来，方便后面搜索和交给模型：
| 概念 ID | 中文首选 | 英文原名 | 禁止混用写法 | 首次出现位置 |
|---|---|---|---|---|
| TERM-01 | 推理服务 | inference service | 推理后端、推理 Service、inference server | 第 2 段 |
| TERM-02 | 上下文窗口 | context window | 上下文长度、上下文大小 | 第 5 段 |
| TERM-03 | 批次 | batch | 批量组、批处理单元 | 第 7 段 |
「禁止混用写法」这一列要写全，它是第 3 步搜索的依据，也是第 4 步提示词的输入。中文首选和英文原名各留一个，代码里保留英文的，正文里用中文的，这一点在表里就要写明，否则模型会在代码块里也替换。
在 Claude Opus 5.5 输出里标出混用位置
第三步只定位，不改写。做法是用对照表里的禁止混用写法逐个搜索，标出段落号和原句。用编辑器的全局查找即可；如果输出已经存成文件，可以用命令行一次性搜多个写法：
grep -n -E "推理后端|推理 Service|inference server" draft.md命中结果按下面的格式记下来，一条一行，后面交给模型或手动替换时都用这份清单：
TERM-01 | 第 4 段 | 原句：该推理后端默认复用连接池 | 替换为：该推理服务默认复用连接池
TERM-02 | 第 6 段 | 原句：上下文长度上限为 200k | 替换为：上下文窗口上限为 200k搜索完再回查一次对照表：如果某个概念一条都没命中，可能是原稿已经统一，也可能是禁止写法列漏了。替换完成后，同一组搜索的结果应该只剩下首选写法，这是一种可以自己验证的收尾方式。
用提示词要求模型只替换术语不改句式
第四步是把替换交给 Claude Opus 5.5，但要把权限收窄。提示词模板骨架如下，替换项是那张对照表和你的原稿：
你是中文技术稿的术语替换工具。只做术语替换，不改写句子。
替换对照表：
- TERM-01 | 统一写法：推理服务 | 禁止写法：推理后端、推理 Service、inference server
- TERM-02 | 统一写法：上下文窗口 | 禁止写法：上下文长度、上下文大小
- TERM-03 | 统一写法：批次 | 禁止写法：批量组、批处理单元
约束：
1. 只替换正文自然语言中的术语，保持句子结构和语序不变。
2. 不修改任何代码块、行内代码、API 字段名、命令行参数、配置键名。
3. 不修改对照表之外的内容。
4. 不新增、不删除段落。
输出：
- 替换后的完整正文
- 替换清单：段落号 | 原写法 | 替换为 | 原句片段
正文：
（粘贴原稿）拿到结果先看替换清单，再看正文是否与清单一致。如果清单为空但正文里仍有混用，说明对照表的禁止写法没写全，回到第 2 步补齐后重跑，不要直接让模型「顺便润色一下」，那会把句式一起改掉。
二次检查替换后的代码块和字段名
第五步是把替换结果和原稿做一次比对，重点只看可执行内容。检查清单：
- 代码块内的变量名、函数名、类名是否被换成中文或另一个英文写法。
- API 字段名、请求体键名、配置键名是否被改动，注意这些通常区分大小写。
- 命令行参数、环境变量名是否被替换或翻译。
- URL 路径、枚举值、状态码字面量是否保持原样。
- 行内代码与代码块外的术语改法是否一致，避免同一概念两套写法。
用 git diff 或编辑器比对原稿与替换稿，逐块确认。发现误替换就回退该处，而不是整段重跑；回退后再用第 3 步的搜索确认这条术语在正文里仍是首选写法。这样处理的顺序是：先术语、后句子，代码与字段名单独看守，风险边界集中在「不影响可执行内容」这一点上。