从代价高的错误开始
样式 linter 可以在几秒内检查成千上万句子，因此很容易产生“把所有偏好都编码进去”的冲动。不要这样做。第一批规则应该解决最昂贵的问题：错误产品名、术语不一致、风险措辞、含糊警告和重复格式错误。
如果首次运行产生几百条低价值警告，团队会很快学会忽略工具。
把规则当作代码
把 Vale 配置和词表放进仓库，像代码一样 review。自定义规则的名称应表达意图，例如 ApprovedProductNames，而不是 RegexRule17。
为规则准备少量应通过和应失败的样例，可以避免后续修改造成回归。
区分错误与建议
只有团队明确同意必须修复的问题才应该阻断 build。需要编辑判断的模式应使用 warning。这样作者可以预测什么会真正阻止发布。
优先治理术语
术语通常是最快看到收益的地方。集中维护批准名称、大小写和替换规则，并显式记录产品例外，而不是全局关闭规则。
误报也值得分析：有时规则错误，有时是内容模型导致术语难以保持一致。
人的编辑仍然不可替代
Vale 无法判断解释是否回答了正确的问题，也无法判断示例是否建立了正确的心智模型。自动化应负责重复缺陷，把人工精力留给结构、证据和清晰度。
好的质量门几乎是无聊的：稳定地发现同一类重要问题，并且很少让作者意外。
实践示例
把《把 Vale 用作质量门，而不是标点警察》当作一次小型评估，而不是功能列表比较。选择三类真实内容：简单页面、包含代码或结构化数据的页面，以及带有导航、复用或本地化要求的复杂页面。用同一种工具或方法处理三者，并记录哪些工作变简单、哪些新的维护成本出现。
重点检查团队会重复进行的工作：
- 作者是否容易理解源文件；
- 审阅者是否能看出有意义的差异；
- 构建失败是否指出可以修复的问题；
- 内容能否在无需大量手工清理的情况下移动、翻译和复用。
好的工具会减少写作、审阅和发布中的不确定性。如果复杂性只是转移到脆弱配置、插件或某个专家的记忆中，也必须把它计入成本。
快速编辑检查
- 从代价高的错误开始. 样式 linter 可以在几秒内检查成千上万句子，因此很容易产生“把所有偏好都编码进去”的冲动。
- 把规则当作代码. 把 Vale 配置和词表放进仓库，像代码一样 review。
- 区分错误与建议. 只有团队明确同意必须修复的问题才应该阻断 build。
- 优先治理术语. 术语通常是最快看到收益的地方。集中维护批准名称、大小写和替换规则，并显式记录产品例外，而不是全局关闭规则。
