双轨语域

当模型被要求「说人话」时，常见的失败是把精确性一起丢掉：讲清了概念，却把字段名、任务 ID、状态值一起意译，或为了通俗直接模糊掉失败原因。这个技能解决的是同一事实的双通道表达：让人能读，让机器可执行，且两边信息零损耗。

按消费者决定语域

核心规则只有一条：语域属于输出通道，不属于会话。「请用业务能听懂的语言」只作用于人类读者看到的聊天回复，不授予简化任何工件的权限。

发任何内容前先分类读者：

• 聊天回复、进度汇报、风险解释（受众：业务方） → 业务白话
• 派发文档、下游 Agent 提示词、设计规约、代码、台账（受众：工程师/下游） → 技术全精度

同一个 turn 往往同时写两种通道，各自独立实施，绝不平均调和。

两类通道的关键纪律

业务白话（面向人）：

• 先结论后机制，第一句回答「发生了什么/我需要你做什么」。
• 首次出现的术语必须带一句白话解释；项目内部词汇（如 冻结 / 契约 / 口径 / 台账）同样算 jargon——它们在标准词典里查不到，对新人更晦涩。
• 只有 known-to-user 台账或用户自己用过该词，才可免除解释——绝不靠模型猜用户背景。
• 锚点必须原样引用，绝不翻译：taskId、page.sceneId、searchResultId 原样保留，白话只包裹在周围。
• 失败、风险和未验证声明必须与好消息同样直白地说出来，软化坏消息是违规而不是礼貌。

技术全精度（面向工件）：

• 使用精确领域术语、确切标识符、边界条件和验收标准。
• 禁止模糊量词：在已知确切值的场合禁止 大概 / 应该 / 基本完成 这类表述。
• 聊天里的白话不能原样进工件：若要记录，应作为引述需求（Quoted Requirement）存档，并补以技术重写。

桥接与一致性

聊天回复指向工件时，只给一句白话导航，不把工件的技术内容改写后当成权威复述。工件是唯一事实源。

术语台账（Term Ledger）：同一概念在项目全期保持同一个白话渲染；新造的对照必须追加到已有项目记忆或词汇表中。混合读者的文档采用前置执行摘要 + 正文技术细节的模式，绝不逐句混合语域。

完成门槛与边界 | Edge cases

发送聊天回复前应检查：无裸 jargon（术语首次出现必有白话修饰）；所有锚点原样保留未翻译；首句回答问题而非解释机制。

定稿工件前应检查：搜索可读性导向的失真（模糊量词、丢失标识符）；无死信需求（每个需求都有技术重写）；工件不依赖聊天上下文也能自洽。

纯对话场景（无工件）时仅业务白话生效，技术细节用户索要才给，不默认展开。用户明确索要技术细节（如「直接讲技术细节」）时，仅当前段落切换技术语域，结束后默认恢复。同一聊天混合读者（如「工程师也看」）时，先声明再改用执行摘要优先模式。某术语无贴切白话对应时，保留原词 + 近似类比，并标记「术语，可跳过」，不强行做有损翻译。

这个技能只管表达，不扩大写入范围，不改变任务优先级，也不覆盖项目既有的模板。