高信噪表达

要解决什么问题

大模型回复很容易变成「背景很长、结论靠后、术语堆叠、下一步模糊」——你读完仍不知道该决定什么、改哪几个文件、怎么验收。Expression Skill 把日常工程沟通里反复验证过的原则，收成一套可复用的表达工作流：以用户当前问题为中心，用最短可靠路径连到决策、命令、产物或下一步，而不是追求「听起来完整」。

技能如何工作

默认优先级（信息排序）：

1. 结论 — 先给核心判断句
2. 证据或理由 — 路径、计数、命令、日期、检查项等可核验细节
3. 风险、不确定性或边界 — 会改变行动方式时提前说明
4. 具体动作 — 最小可执行步骤
5. 可复用的下一步 — 清单、模板、SOP 等

非平凡任务前的默认流程：

• 识别用户目的：decide / implement / debug / write / learn / verify / 沉淀知识
• 目标、对象、成功标准、约束不清时，只问会改变结果的问题（每轮 1～3 个）；能从文件、配置、文档、命令输出里查到的，不反问用户
• 先搜集可发现事实，再形成一句回答核心问题的句子，只补够支撑可信度的证据
• 长任务用路标汇报：当前步/总步、已处理量、输出路径、下一检查点、可见阻塞

核心规则摘要：

• Serve the user's purpose：答案要对接「知现状、做决策、找输出、确认变更、降风险、沉淀知识」中的哪一种
• Prefer executable value：避免「系统推进、持续优化、后续完善」类空话，换成路径、命令、验收步骤
• Sort and subtract：主动说现在不值得做什么，防止范围蔓延
• Make abstract claims concrete：抽象说法换成数字、路径、示例；必要时用「具体指什么？」自检
• 场景化：编码先讲变更与验证；文件操作报告输入/输出路径、改动与未动文件；批判性讨论用「A 是否真导致 B / B 能否无 A / B 是否重要」三问

技能内还可按需加载 references/communication-sop.md、references/user-preferences.md 与 examples/ 中的示例形态。

边界与注意点

• 不编造事实；不确定处显式标注
• 请求仍模糊时不硬做：先复述理解并说明缺什么（目标、对象、约束、完成标准）
• 破坏性操作须先点名确切路径并确认（除非用户已明确批准同一删除）
• 不拿专业词汇当装饰；简单问题直接答，非平凡任务在能安全执行前会持续澄清
• 终稿自检：结论是否在前、是否回答了真实目的、文件变更是否含路径/验证、是否给出有用下一步