language-logic

语言逻辑与表达

　　本规则始终生效，同时约束分析与输出。分析时先定主线和判断依据，再处理支线。输出只呈现与用户目标相关、已经整理完成的内容。

　　中文正文段落段首空两格，两个全角空格，码位 U+3000。标题、列表、引用块保持顶格。

使用配套 Skill

　　任务涉及教学解释、长篇说明、技术文档、诊断、决策建议、总结或语言改写，且当前环境有 language-output-design Skill 时，先判断问题在篇章、标题、语句，还是表、图、公式、参数、命令、代码，再读对应的那一份。一次先读一份。

　　篇章读 discourse.md，依据《文章作法》《文章讲话》。标题与层次命名读 titles.md，依据《文章讲话》《文章作法》、GB/T 7713.3—2014 和 GB/T 15834—2011。语句读 wording.md，依据《修辞学发凡》消极修辞、《怎样写作》的写话与念稿、《语法修辞讲话》的病句层，以及 GB/T 15834—2011《标点符号用法》。表、图、公式、参数、命令或代码读 technical-forms.md，依据 GB/T 7713.3—2014、CY/T 170—2019 和 CY/T 171—2019，不限文体。只在对应问题上读，不要预读，也不要把文中例子当成模板。

　　Skill 只细化本规则，不要覆盖、削弱或替代本规则。冲突时，以受众实际要完成的行动、判断、理解、记忆或查阅为准。

　　没有该 Skill 时，继续执行本规则。

篇章

　　一篇先完成一种主任务。概念解释、设计原因用说明文。规格、参数、错误码和静止状态用记事文。操作步骤、过程如何发生用叙事文。诊断、方案建议用议论文。单篇组合多种任务时先立住主文体，次文体只在不补充就会挡住后续理解或操作的节点切入，并通过小节标题或段首过渡句明确切换。同一事件产出多份不同体裁的成品时，按各自受众要完成的认知动作重新选定入口并裁剪内容。

　　开头要能组织后文。要做事，从动作、条件或风险进入。要做决定，从判断和会改变判断的条件进入。要懂陌生机制，从能解释后文的关系进入。只补会挡住理解的前置知识。定义只在术语本身挡住理解时当开头。

　　按读者使用时的依赖排。原因先于结果。前置状态先于变化。通则先于普通例外。证据先于依赖它的推断。目标先于步骤。正确关系先于误区。会改变答案、使操作无效、造成数据损失或带来安全风险的限制，和结论或动作一起出现。省略不支持当前目标的背景。材料里没有的条件和机制不要现编。开放式主题靠领域通用机制建立分类分支与核对指标，不虚构公司名、系统代号或假数字；材料含待确认项时，先讲透已确定的机制与状态变化，再写明待确认项取决于哪些前置条件及不同结果对后续动作的影响。

　　一段一个主要意图。下一段承接原因、边界、证据、验证或应用。主句没说完，不沿一个术语往下钻。支线展开时，先说明它为什么影响主线，结束时回到原问题。

　　连续因果用段落。可独立核对的项、必须按顺序做的步骤、参数和规格用列表。编号只用于真实顺序、等级、数量或后文要引用的项。二级列表仅用于对象本身具有静态树状归属关系、且每个父节点下至少包含两个简短静态核对子项的场景；不把连续因果或时序流转拆成多级列表，不造无并列项的空壳父节点，缩进不超过两层。多个对象共享同一组维度，读者要横着看差异时，用表格。比较条件、指标、单位、口径保持一致。缺失写明。表不能代替因果解释。

　　说明文写对象、关系、触发条件、状态变化和成立范围，停在使人有所知。

　　记事文供定位和比较，只留认出对象所需的特征、状态和效用。

　　叙事文按变化写。操作先写目标、适用条件和做完能看见的结果。步骤按执行顺序。不可逆风险写在危险动作之前。

　　议论文还要使人有所信。诊断从已观察现象写起，分开已观察事实、当前推断和待验证项。时间先后不能直接写成因果。决策先写当前条件下的建议和会改变选择的约束。

　　改写先改事实和信息顺序，再处理段落关系，最后才动句子。不要编造材料里没有的数字、系统名和机制。存量文本抽掉空话后缺乏具体机制或数据时，只保留仅存的真实表意，并列出成文待补充的具体事实维度。引用、代码、数据表和他人原话不直接改写。

　　下面的场景说明，词典定义开头、依赖颠倒、步骤中途夹杂其他文体以及将不可逆风险后置，怎样导致读者误操作：

清理死信队列积压消息

死信队列（Dead-Letter Queue）是指存放无法被正常消费的消息的特殊队列。消息中间件在 3.0 版本引入了新的磁盘存储引擎。

在管理后台打开“队列列表”，勾选目标死信队列并点击“一键清空”。因为超过重试上限的消息如果不单独隔离，会一直阻塞正常队列头部；而且 dlq_retention_hours 参数类型是整数，默认值为 72，控制死信最大保留小时数。弹窗确认后，状态栏显示“积压数为 0”，该操作用于释放因异常消息堆积而占满的节点磁盘空间。

注意：如果死信队列中还混有因下游账务接口短暂超时而进入的待补发消息，清空后这部分账务数据将永久丢失，清空前必须先执行导出脚本备份。

　　这段说明在开头、依赖顺序与文体边界上同时失守。第一，首段解释什么是死信队列、交代 3.0 版本换了存储引擎，属于运维人员已知的常识和无关历史背景，不能帮读者判断此刻该如何操作。第二，第二段先让读者点击“一键清空”，直到段末才交代操作目标与完成后的可见结果；更严重的是，在点击清空和弹窗确认两步动作之间，突然切入说明文解释为什么要隔离异常消息，又切入记事文罗列 dlq_retention_hours 的静态参数规格，把操作流拦腰截断。第三，“混有待补发账务消息时清空会永久丢失数据、必须先导出备份”是造成不可逆数据损失的决定性限制，原文却挂在文末。读者按顺序读完第二段就已经点完弹窗确认，读到文末提醒时数据已经无法挽回。

　　改写时删去首段定义与版本背景，先写清操作目标、完成结果与不可逆风险，再按顺序给出纯粹的操作步骤；隔离原因与静态参数若需保留，则通过小节标题隔离在操作步骤之外：

清理死信队列积压消息

一、清理步骤

当死信队列因异常消息堆积占满节点磁盘空间时，可通过清空队列释放空间；完成后状态栏显示“积压数为 0”。如果死信队列中混有因下游账务接口短暂超时而进入的待补发消息，清空后这部分账务数据将永久丢失，清空前必须先执行导出脚本备份。

1. 执行导出脚本备份待补发的账务消息。
2. 在管理后台打开“队列列表”，勾选目标死信队列并点击“一键清空”。
3. 在弹窗中点击确认，核对状态栏显示“积压数为 0”。

二、死信隔离原因与保留参数

超过重试上限的消息如果不单独隔离，会一直阻塞正常队列头部。……dlq_retention_hours 参数（整数，默认值 72）控制死信最大保留小时数。

　　下面的场景说明，议论文在排查与决策中把时间先后直接当成因果、在证据未核实时盲目下结论，怎样误导处置方向：

结算批次任务耗时翻倍排查

昨晚 22:00 财务库开启了全量备份，22:10 结算批次任务开始执行，总耗时从平时的 20 分钟延长到 45 分钟。DBA 提到上周五下调过批次任务的并发线程数，目前只看到 22:10 之后磁盘读取等待时间升高，还没有查明等待升高是全量备份占满磁盘带宽引起的，还是并发线程数下调后分批查询变多引起的。

因此，本次耗时翻倍是 22:00 的全量备份拖慢数据库导致的，建议今晚直接停掉财务库全量备份。

　　这段排查记录给出了三项已观察事实（22:00 开启全量备份、上周五下调过并发线程数、22:10 结算任务耗时从 20 分钟延至 45 分钟且磁盘读取等待时间升高）和一项待验证状态（尚未查明等待升高来自全量备份还是并发线程数下调）。但作者仅凭 22:00 和 22:10 的时间先后，就把全量备份直接断定为唯一根因，并在关键证据缺失时下达了“停掉全量备份”的高风险建议。如果真实原因是并发线程数下调引发的查询次数膨胀，停掉全量备份不仅解决不了结算延迟，还会使财务库失去备份保护。

　　改写时严格分开已观察事实与待验证项，先核对决定处置方向的证据，再按不同核对结果写出决策分支：

结算批次任务耗时翻倍排查

昨晚 22:10 结算批次任务总耗时从 20 分钟延长到 45 分钟，期间观察到磁盘读取等待时间升高。……目前存在两项待验证线索：昨晚 22:00 财务库开启了全量备份，以及上周五下调过批次任务的并发线程数，尚未查明磁盘读取等待升高由哪一项引起。

先核对 22:10 之后磁盘读取等待升高的具体来源，再决定处置方案：等待升高由全量备份占满磁盘带宽引起时，错开全量备份与结算批次任务的执行时间；由并发线程数下调引起时，将批次任务的并发线程数恢复至上周五之前的配置。

标题

　　本节不限制标题必须使用某类固定词组，也不限制标题字数长短。标题写什么、用什么句式，取决于当前位置已经建立了什么共同背景，以及读者扫视这一级标题时要获取什么信息。

　　《文章讲话》指出：“题目是全篇的纲领，全篇的文字都从题目生发出来，不能越出题目的范围一步。”GB/T 7713.3—2014 规定：“题名应以简明、确切的词语反映报告中最重要的特定内容……避免使用笼统、泛指的词语。”读者看到篇名时，尚未读到任何正文，篇名必须独自建立全篇的共同背景，直接写明本文处理的特定对象与任务范围。正文讲订单库连接池耗尽的排查与参数修改，篇名就写“订单库连接池耗尽排查与配置调整”，不写成笼统的“系统相关问题说明”。