规模会改变一致性的来源
小团队可以依靠共同习惯和直接编辑。贡献者达到几十或几百人后，记忆就不再是控制系统。规则必须进入发布环境。
结构化写作并不一定意味着采用某种 XML。它意味着明确有哪些内容类型、每种类型需要什么，以及它们如何复用。
定义一个小而稳定的内容模型
从经常出现的形状开始：概念、流程、API reference、troubleshooting、release note。给每种类型规定必要元数据，并在有意义时使用可预测结构。
不要为每个例外创建新类型。
集中管理术语
把批准的产品名、UI label 和技术术语放在一个地方，明确替换和例外，并尽可能连接到 linter。
术语其实是用户界面的一部分。同一概念在不同页面被不同命名，是导航缺陷，不只是风格问题。
谨慎复用
Warning、prerequisite 和共享解释只有在语义与生命周期真的一致时才应复用。每个共享 fragment 都需要 owner，也需要能看见它被使用在哪里。
让 style guide 保持可用
主 guide 只保留高频、高影响决策，边缘情况放入可搜索 reference。可以由 schema、template 或 linter 强制的规则，优先自动化。
目标不是让所有文字一样，而是让文档在贡献者增长后仍然可预测、可维护。
实践示例
把《在数百名贡献者规模下仍然有效的结构化写作规则》应用到一个真实页面，而不是只讨论规则。选择包含标题、表格、注释、示例、重复术语以及至少一个用户操作的内容。先以作者身份审阅，再以不了解内部术语的读者身份审阅。
记录可观察的问题：
- 哪种结构承载了纯文本中不存在的意义；
- 哪个术语的写法或含义不一致；
- 哪条指令依赖未说明的上下文；
- 哪项规则在审阅中难以稳定执行。
标准真正有用的标志，是两个编辑面对同一内容能得到近似判断。如果规则听起来正确却无法在代表性页面上演示，就需要 уточ确规则、补充示例或缩小适用范围。
快速编辑检查
- 规模会改变一致性的来源. 小团队可以依靠共同习惯和直接编辑。贡献者达到几十或几百人后，记忆就不再是控制系统。
- 定义一个小而稳定的内容模型. 从经常出现的形状开始：概念、流程、API reference、troubleshooting、release note。
- 集中管理术语. 把批准的产品名、UI label 和技术术语放在一个地方，明确替换和例外，并尽可能连接到 linter。
- 谨慎复用. Warning、prerequisite 和共享解释只有在语义与生命周期真的一致时才应复用。
