在 Codex 任务中，写代码本身是一项技术工作。只要问题里出现多 Agent、上下文压缩、代码审查和验收等内容，模型就很容易把回答写成技术分析报告。

这种回答通常有两个问题。第一个问题是用词生硬：模型喜欢用抽象名词和专业术语压缩意思。第二个问题是结构零散：每一段单独看都说得通，合在一起却没有一条持续推进的主线。

这两个问题经常同时出现。术语让句子变得难读，过多的小标题又把本来连贯的论述切成了几块。下面分别说明它们是怎样产生的，以及怎样通过提示词加以约束。

问题一：技术语境容易让表达变得生硬

现象：意思没有错，但说法不像自然中文

下面这句话来自一次真实的 Codex 任务：

这句话并非逻辑错误，但读起来很生硬。“衰减、替代、协调失败、假阳性”连续堆在一起，句子里几乎只剩抽象名词。读者必须先理解这些词，才能明白实际发生了什么。

以“假阳性”为例。它是统计学、医学检测和机器学习领域的专业术语，英文是 false positive。

例如：

• 一个人没有患病，检测结果却显示阳性，这是“假阳性”。
• 一段正常代码被安全工具判定为存在漏洞，通常称为“误报”。

Codex 把这个概念借到了任务验收中：

• 真实情况是任务没有完成。
• Agent 却判断任务已经完成。

这种类比在逻辑上能够成立，但它没有让原句变得更准确，反而增加了理解成本。在这里，直接写出发生了什么会更自然：

改写后的句子更长，却更容易理解。它明确说明了谁遗漏了要求、验收时检查了什么，以及最后造成了什么结果。

原因：模型容易把“专业”理解成“多用术语”

这句话之所以显得生硬，首先是因为问题本身带有很强的技术语境。提问中出现了多 Agent、上下文压缩、代码审查和任务验收等内容，模型便判断用户需要一份偏技术的原因分析。

确定这种风格以后，模型会模仿论文、评测报告和技术文章中的常见写法。这类资料经常使用“目标漂移、指标替代、上下文衰减”等抽象说法。模型因此没有直接描述发生了什么，而是先把具体过程概括成几个术语。

这种写法还能缩短句子。“假阳性”四个字，可以代替“任务实际上没有完成，但 Agent 错误地认为已经完成”。不过，模型只考虑了表达是否简短，没有充分考虑这个术语放在任务验收中是否自然。

用户又没有明确要求使用日常中文，模型便没有理由重新展开这些术语。于是，它最后写出了一句逻辑能够成立、形式上也很简洁，但不像正常工作交流的句子。

GPT-5.6 较为简洁的默认风格可能进一步放大这种倾向，这种倾向本身不是问题，但在技术语境中，模型可能通过增加抽象概括来压缩文字，从而牺牲中文的自然程度。OpenAI Model Spec、OpenAI 模型指南。不过，真正的问题不是回答太短，而是模型通过堆叠抽象名词来缩短回答。

因此，真正需要约束的不是回答的长短，而是模型用什么方式保持简洁。好的简洁应该删除重复内容，而不是把具体事实压缩成一串抽象名词。

问题二：小标题切得太碎，文章容易失去主线

现象：每一段都与主题有关，合在一起却像分别生成

一篇文章可以没有事实错误，也可以覆盖所有要点，但读者仍然会觉得它不连贯。常见表现是：文章先解释一个术语，接着列出几个原因，最后再补充模型的默认风格。每一部分都与主题有关，却没有说明前一部分为什么会引出后一部分。

这时，小标题只是把材料分了类，并没有推动论述。读者能够看懂每一段在说什么，却不容易看出整篇文章到底要证明什么。

原因：标题只负责分段，没有负责推进问题

文章的主线并不只是“所有内容都在谈同一个主题”，还要求各部分之间存在明确的承接关系。提出一个现象以后，读者自然会追问它为什么发生；解释原因以后，读者才会继续关心它造成了什么影响，以及应该怎样处理。后一部分只有接住前一部分留下的问题，论述才会向前推进。

如果大模型只是按照材料的类别设置标题，小标题就只能告诉读者“这一部分谈什么”，不能解释“为什么接下来要谈这个”。定义、背景、原因、例子和建议虽然都与主题有关，却承担着不同作用。把它们直接并列起来，读者就难以判断哪些内容是前提，哪些内容是在解释前文，哪些内容又是根据分析得出的结论。

段落之间缺少这种关系时，每次进入新的小标题，都像重新开始了一个话题。读者能够分别看懂各部分的内容，却需要自己推测它们为什么按照这个顺序出现。于是，文章虽然分段清楚，整体上仍然像几段单独写成的说明。因此，问题不在于小标题太多，而在于标题没有沿着同一个问题逐步展开。小标题应该标记论述真正进入了下一步，段落则要说明这一步怎样从前文产生。只有内容和关系同时写清楚，小标题才能帮助读者理解文章，而不是把文章切成互不相连的几块。

解决办法：在提示词中同时约束用词和结构

前面两个问题不能只靠一句“请使用自然中文”解决。提示词既要限制生硬的用词，也要要求模型先建立论述主线，再安排段落和小标题。

通用完整版

当任务需要较长的分析、说明或总结时，可以使用完整版：

请使用自然、连贯的现代书面中文回答。先建立一条明确的论述主线，再安排小标题。小标题必须处于同一逻辑层级，不要把原因、现象、评价和结论混列为并列标题。优先使用具体的主谓句和动词表达，避免为了显得专业而大量使用抽象名词、名词化结构或从英文直接迁移的技术术语。如果普通中文能够准确表达，就不要使用跨领域术语。使用术语时，请说明它在当前语境中是否属于通行用法，而不只是逻辑上能够类比。如果术语会增加读者的理解转换，请改用直接描述。每一段只承担一个明确功能，并通过“因为、因此、不过、具体来说”等连接方式说明段落关系。不要换一个标题重复相同的结论。完成初稿后，请检查：- 相邻段落之间是否存在清楚的逻辑关系；- 所有并列标题是否属于同一层级；- 是否重复表达了同一个结论；- 是否存在翻译腔或不必要的名词化表达；- 是否具体说明了“为什么”，而不只是给出笼统评价。

通用短版

如果希望每次提问时都附带表达要求，可以使用短版：

请用自然中文回答，不要模仿英文技术报告的名词化表达。先按“现象—原因—具体问题—修改建议”组织内容。小标题必须逻辑平行，段落之间要有明确的递进或因果关系。避免重复结论；不要只说“不自然”或“不合适”，必须指出具体是用词、句法、语域还是逻辑结构的问题。能直接说明事实时，不要使用跨领域术语。

完整版适合放在项目说明、长期任务要求或 Codex 的固定指令中。短版适合临时问题，可以直接附在具体要求之后。如果某项任务只需要约束日常表达，或者确实需要保留专业术语，还可以使用下面两组更有针对性的规则。

日常开发沟通：优先保证自然、直接

如果目标是让 Codex 像同事一样说明问题，可以使用下面这段提示词：

请使用符合现代中文阅读习惯的表达方式。具体要求：1. 优先使用简单、直接的主谓宾句子。2. 多使用具体动词，少使用抽象名词。3. 禁止翻译腔、术语堆叠和连续的名词短语。4. 不要为了显得专业而创造生硬概念。5. 能用日常中文说明的内容，不要使用“衰减、漂移、假阳性、对齐、收敛、范式、链路”等术语。6. 如果必须使用专业术语，要先用普通中文解释它的具体含义。7. 描述问题时，要明确写清楚：谁做了什么，哪一步出现了问题，最后造成了什么结果。8. 不要写“要求衰减、验收指标替代、完成判断假阳性”这类翻译式表达。9. 应改写为：“任务做久以后，前面的要求容易被遗漏；验收时又只检查测试和构建，导致没有真正做好的任务被误判为完成。”10. 输出前检查一遍：如果一句话不像中国人在正常工作交流中会说的话，就重新改写。

如果不需要这么细的规则，也可以使用短版：

请使用自然、直接、符合中文习惯的表达。多用具体动词和主谓宾句子，少用抽象名词、翻译腔和术语堆叠。不要创造看似专业但难以理解的概念。描述问题时，直接说明谁做了什么、哪里出了问题、造成了什么结果。

正式技术分析：保留术语，但先说清楚事实

有些任务确实需要专业术语，例如安全报告、模型评测或架构文档。此时不必完全禁用术语，但要限制它们的使用方式：

请使用准确、规范的专业术语进行分析，同时保持中文表达自然。术语使用规则：1. 只有当专业术语比普通表达更准确时，才使用术语。2. 禁止为了显得专业而堆砌术语。3. 专业术语第一次出现时，必须同时提供中文术语、英文原词和一句通俗解释。4. 说明该术语属于哪个领域，例如统计学、机器学习、软件工程或产品设计。5. 区分严格用法和类比用法。如果不是该领域的标准用法，必须明确说明。6. 不得自行创造看似专业但没有公认定义的词语。7. 每段最多引入一到两个新术语。8. 先用普通中文说清楚发生了什么，再用专业术语进行概括。9. 不要只给术语，要解释它在当前问题中对应的具体事实。10. 如果专业术语会降低可读性，优先使用普通中文，并把术语放在括号中补充。目标读者是有技术背景的普通开发者。表达应当专业、准确，但不能写成论文翻译腔。

结论

大模型会根据问题内容、提示词和训练中学到的写作方式选择语言。技术语境会同时影响它的用词和文章结构：它可能用抽象术语代替具体事实，也可能用一连串小标题代替真正的论述推进。

解决这个问题时，不能只要求“写得简洁”或“写得专业”。更有效的做法是明确告诉模型：先写清楚谁做了什么、哪里出了问题、造成了什么结果；只有在术语确实更准确时才使用术语；每一部分都要回答上文自然引出的问题。

一篇好的技术说明不需要故意回避专业内容，但它应该让读者先看懂发生了什么，再理解这些事实可以怎样概括。自然、准确和专业并不冲突，关键是让术语服务于说明，让标题服务于论述。