Prompt 如何控制语言、语气和格式风格？

简化版

不要只写“专业一点”，而要把 locale、受众、术语表、语气维度和输出结构变成可验证契约。语言与地区要分开，例如 zh-CN 决定简体中文、日期货币和称谓；格式优先用 schema 或模板约束，品牌风格给正反例。内容事实与展示层最好解耦，生成后再用术语、格式和敏感表达检查器验证。

Prompt 应声明：目标 locale、读者水平、正式度、句长、称谓、禁用词、术语映射、日期/数字/货币规则和 Markdown/JSON 结构。冲突时规定事实准确与安全高于风格。动态变量使用枚举而非自由文本，防止用户把 style 字段变成注入入口。

多语言系统可先生成语言中立的结构化内容，再由本地化层渲染；直接生成更自然，但术语一致性难。评测分语言正确、术语命中、格式解析、品牌风格和事实保持，使用本地母语评审与程序规则结合，并测试代码、专名和引用不应被错误翻译。

事实/字段 -> locale规则 + 术语表 + style profile -> 文本渲染 -> 格式/术语/事实校验

“中文”只定义语言，不说明简繁体、日期、货币和地区用词；zh-CN 与 zh-TW 的术语、标点和格式可能不同。风格则描述正式度、亲切度、句长和品牌声音。把三者混成“用中文专业回答”，结果难以验收。

应把控制项拆成结构化 profile。事实内容不因风格变化而改变，地区格式也不应被品牌口吻覆盖。分层后才能独立测试和复用。

“友好”“简洁”“高级”因人而异。可改写为：使用“你”称呼；每段不超过 3 句；避免感叹号和网络流行语；先给结论再给依据；专业术语首次出现给短解释。规则越可观察，模型和评审越容易一致。

记忆钩子：风格控制要从“感觉词”变成“看得见、数得出、能判定”的输出行为。

Locale 会影响书写系统、日期、时间、数字分隔、货币、单位、地址和礼貌称谓。en-US 常用月/日/年和美元，en-GB 常用日/月/年；只写 en 会产生歧义。时区也应独立给出，locale 不能推断用户所在时区。

locale: zh-CN
timezone: Asia/Shanghai
currency: CNY
date_format: YYYY年M月D日
unit_system: metric

金额与日期最好由程序格式化，模型负责上下文措辞。这样可避免 1,234.56 与 1.234,56 混淆。

产品名、API、法律术语和行业译名应提供 glossary，包含源词、目标词、是否允许变体和大小写。代码、URL、引用原文、变量名标记为 verbatim，防止模型为了语言统一而改写。术语冲突时指定权威优先级。

例如 workspace -> 工作区，但产品品牌 GitHub Actions 保留英文；token 在模型语境可写“Token”，不要随意变成“令牌”。输出后做精确或词形感知检查，发现漏用则重试或由确定性替换器修复。

机器消费输出应优先 JSON Schema 或结构化输出，不要让“写得自然”破坏字段。人类阅读可用固定标题、表格和长度约束。先生成结构化事实，再渲染成不同 locale，能减少多语言版本间事实漂移。

如果同一份公告要生成中文、英语和日语，可先产出 {title, date, impact, action}，校验字段后分别渲染。直接三次自由生成可能让其中一个版本漏掉操作步骤。结构层是一致性的锚点。

少量正例比抽象形容词更有效，但要覆盖不同场景，而非三个近似营销句。再给一两个反例并说明错因，例如“过度热情、承诺未证实、责备用户”。示例中的事实和实体应脱敏，避免模型复制。

示例只负责演示风格，规则仍应明确。否则模型可能模仿示例主题而非语气。动态任务中按 locale 检索对应示例，不要让中文示例和法语输出混杂造成结构迁移错误。

程序可检查语言识别、长度、标题、schema、术语和禁用词；母语评审评价自然度、礼貌和品牌一致性；事实检查对比源字段。LLM Judge 可辅助，但需用本地人工标注校准，且隐藏版本信息。

测试加入数字、代码、专名、混合语言和用户要求覆盖品牌规则的案例。假设术语命中 99%、格式 100%，但事实一致率只有 92%，仍不能上线。风格是护层，不能用它抵消内容错误。

风格控制可记成“语、区、人、词、形、验”：明确语言和地区，定义读者与可观察语气，绑定术语表和不可翻译项，用结构契约固定格式，最后分别验证自然度与事实一致。把展示从事实层解耦，既能稳定本地化，也不会让漂亮措辞改坏内容。