ppt-master 语言规则详解：面向 Agent 提示词的多语言纪律——单文件单语、内容可用外文而规则不可

docs/rules/language.md 是 ppt-master 仓库中约束"Agent 可读文件"语言一致性的核心规范。它回答了一个被许多多语言项目忽视的问题：当仓库同时存在英文工作流、中文翻译文档和面向大模型的提示词时，哪些字符串可以跨语言混用、哪些绝对不允许。读完本文，你将掌握该规则的四条核心条款（单文件单语、非英语只做内容不做规则、不硬编码输出语言、触发词保持语言中立）、原文档中"允许/禁止"边界表的完整判据，以及每条规则在当前仓库里的真实落点与验证方式。

一、规则的作用范围与存在动机

language.md 在开篇即声明其适用范围：包内每一个面向 Agent 的文件——skills/ppt-master/SKILL.md、references/*.md、workflows/**/*.md——以及仓库 docs/ 下的文档（见 language.md 作用域声明）。

这条规则并不是孤立的文档洁癖，而是直接服务于运行时行为：SKILL.md 的"Global Communication Rules"一节要求模型"Match the user's language and source language unless the user explicitly overrides it"，即默认跟随用户语言（见 SKILL.md L66-L70）。如果某个提示词文件里混入了外语书写的指令，模型会倾向于按该外语回复，从而静默地覆盖 SKILL.md 的"匹配用户语言"纪律。language.md 第 2 节的 Hard rule 正是为此而立：

模型必须遵循的指令，必须用该文件自身的语言书写。（原文：an instruction the model must follow is written in the file's own language.）

AGENTS.md 也把这条规则提升为仓库级强制约定："Markdown language consistency — follow docs/rules/language.md: one language per file, mirroring the siblings in that directory; a non-English string may appear in an English file only as quoted content … never as the wording of a rule; never hard-code which language the model replies in. Chat replies are unaffected."

二、规则 1：一个文件一种语言

原文规定（§1）：

• 每个 Markdown 文件只允许单一语言；
• 新文件必须镜像同目录兄弟文件的语言——即放入哪个目录，就跟随该目录既有文件的语言；
• 严禁在一个文件里混排"英文骨架 + 中文段落"（或反过来）。

一个容易产生误判的点是纯中文文件：docs/zh/、README_CN.md、SPONSORS_CN.md 等整体中文文件不是规则的例外，它们同样是"单语言文件"，只是单语言恰好是中文。当前仓库的对应关系印证了这一点——docs/ 下每篇英文文档在 docs/zh/ 都有完整的中文孪生版（如 docs/faq.md 与 docs/zh/faq.md），两套文件各自单语，而非在同一文件内双语混排。

对贡献者的实操含义：在 skills/ppt-master/workflows/ 下新增工作流文档时，应写英文并匹配该目录既有文件的风格（该目录全部为英文）；为中文用户写的面向仓库使用者的文档则放入 docs/zh/ 保持全中文。

三、规则 2：非英语语言可以是"内容"，但绝不能是"规则"

这是整份规则中最精细、也最常被误用的一节（§2）。其判据只有一条：在一个英文文件里，非英语字符串只有当它本身是主题（subject matter）时才被允许，永远不能作为给模型的指令措辞。

原文给出的"允许 / 禁止"对照表（完整继承）：

允许——字符串是内容	禁止——字符串是规则
用户实际会键入的触发短语（继续生成 projects/<name>）	用中文写出的决策规则（语速：edge 默认 +0%…）
示例 JSON / 注释块中的示例字段值	用中文表述的选择标准（财报 → 稳重男声）
幻灯片页面上要渲染的标签（情景数据）	英文句子里用一个中文词顶替它自己的术语
发音或排版示例（TTS 用的 百分之六十八）	中文的章节标题或表格表头
带英文语境的专有名词（印章、新中式）	用中文写的一整段说明性指令
本身就是中文的目录名或品牌名

这张表的每一行都能在仓库中找到真实存在的案例，下面逐一给出证据，可作为审查同类写法时的参照：

1. 用户触发短语：resume-execute.md 的 "When to Run" 表格中列出了 "继续生成 projects/<project_name>" 作为续接执行的触发模式。文件本身是英文，但 继续生成 是用户实际会键入的字符串，属于内容而非指令，因此合规。同一短语在 generate-pptx.md L437-L438 中作为交接命令出现，同样合规。
2. 页面渲染标签：executor-base.md L166 要求当 §IX 标注 Data class: scenario 时，在 KPI/图表旁放置可见的本地化标签 Scenario data / 情景数据。这里 情景数据 是最终 PPT 页面上要渲染的文字，是"被呈现的内容"。
3. 发音/排版示例：executor-notes.md L57 规定 TTS 读法不佳时应拼写出数字与符号，举例为"Chinese '百分之六十八' rather than '68%'"——这是发音示例，不是规则措辞；template-fill-pptx.md L229 有同样的示例。
4. 专有名词：visual-styles/_index.md 的样式索引把 新中式 作为 ink-wash 风格的适用场景词列出，ink-wash.md L9 用 印章 指代 seal-stamp 设计元素——这些词均处于英文语境的专有名词位置。

反之，上表右列的四类写法（中文决策规则、中文选择标准、中文标题/表头、中文说明段）在该仓库的英文提示词文件中均不应出现。判断一个中文串是否合规，只需问一句：删除这句话后，模型少知道的是一个"事实/样例"，还是少了一条"指令"？ 若是后者，必须改写为文件自身的语言。

四、规则 3：永远不要硬编码输出语言

§3 给出了一条具体的缺陷判定：任何把模型回复语言钉死的规则都是缺陷——例如 write a one-line Chinese description 这类写法即违规，正确写法是"in the user's chat language"（以用户聊天语言为准）。

该节同时划出了一个边界情形：用某种具体语言写成的用户可见消息模板是合规的——按 §2 的判据它属于"内容"，可以保留；但它必须附带一句显式说明："if different, translate to the user's chat language"（若用户语言不同则翻译）。这条要求与 SKILL.md 中"Localize user-facing option labels and explanations. Keep exact enum IDs or field names when needed for precision"（SKILL.md L68-L70）一脉相承：模板文字可本地化，但枚举 ID 与字段名这类精确标识保持原样。

五、规则 4：触发文本保持语言中立

§4 针对 SKILL.md 的 description 字段：

• 它必须是英文散文；
• 不得向其追加按语言分类的关键词清单，也不得在其中点名任何具体的 Agent 宿主（host）或执行框架（harness）；
• 当某类请求意图触发不可靠时，正确做法是扩展英文意图词汇——加入用户实际会输入的名词与动词，包括 PPT / PPTX 这类语言中立的记号——而不是再加一种语言的关键词。

理由原文说得很直接：语言清单没有天然终点，而 SKILL.md 是每次运行都会加载的文件，清单里每一个词条都在消耗每次运行的上下文预算。当前仓库的 SKILL.md frontmatter description 正是这一规则的标准实现：纯英文散文，意图动词覆盖了 create / generate / reconstruct / regenerate / beautify / redesign / template / fill / enhance 等，并显式包含语言中立的 token "PPT, PPTX, slide deck"，没有任何按语言切分的关键词列表，也没有点名宿主。

六、规则的维护与审查方式

这三条式规则与另外两条式规则（prompt-style.md 管 references/ 的写作风格、code-style.md 管 scripts/ 的 Python 风格）共同构成仓库的 docs/rules/ 体系，索引见 docs/rules/README.md：

规则	范围
prompt-style.md	skills/ppt-master/references/ 下文件的风格——语气、分节、表格优先、禁用模式
code-style.md	skills/ppt-master/scripts/ 下 Python 的风格——文件头、导入、CLI 入口、错误处理
language.md	面向 Agent 的 Markdown 与 docs/ 的语言规则

审查一份改动是否违反 language 规则，可以按这四步走：

1. 单语检查：改动后文件是否仍为单一语言？新增文件是否镜像了同目录兄弟文件的语言？（对照 docs/zh/ 与 docs/ 的双语孪生结构）
2. 内容/规则二分：文件中的每个非本语言字符串，逐条过 §2 允许表——它是不是触发短语、示例值、渲染标签、发音示例、专有名词或品牌名？若不是，判为违规。
3. 输出语言检查：是否存在钉死回复语言的措辞？用户可见消息模板是否带了"必要时翻译到用户聊天语言"的说明？
4. 触发词检查：SKILL.md 的 description 是否仍为英文散文、无按语言的关键词清单、无宿主点名？触发率不足时是否通过扩展英文意图词汇解决？

需要强调的是规则的效力层级：AGENTS.md 将遵守 docs/rules/ 列为 "Required Conventions"，且声明当通用编码技能与本仓库约定冲突时，以 skills/ppt-master/SKILL.md 及仓库内规则为准。因此在为这个仓库贡献 Agent 提示词或文档时，本文所述的四条语言纪律是硬性验收项，而非风格偏好。