STYLE.md¶

为 impeccable.design 准备的编辑简报。在撰写或编辑任何面向用户的文案之前先读这个：首页、子页面、指令式评论、教程和 README 文档。

标准：对于每一段，指出那句让它专属于你的句子。 如果做不到，那这段文字默认就是 AI 写的，即使是一个人类敲出来的也不例外。

原则¶

1. 以读者的错误认知、你最有力的主张或例子开篇。 不要写“在本指南中”，不要写“让我们开始吧”。
2. 采取一个别人可能不认同的立场。 如果一段话被反着说也不改变含义，那它就没有立场。标明你的态度。
3. 点名道姓。用数字。 真实竞争对手、真实客户名、真实版本号、真实文件路径、真实基准数据。删掉“lightweight”；写“54 KB”。
4. 动词先行，名词随后。 祈使句没问题。用主动语态。删掉名词化（"the implementation of" → "implementing"）。
5. 刻意变化句子长度。 长、长、短。平滑均匀的节奏是 AI 最深的痕迹。
6. 散文承担内容；结构支撑它。 项目符号用于并列选项。段落用于论证。不要把一个句子能更紧凑表达的东西变成项目符号。
7. 用平实的词。只有当某件事确实依赖术语时才用术语。 混合层级能让术语更具冲击力。
8. 允许为了节奏出现不合语法的片段。 五个词。自信的信号。
9. 尊重读者的能力。 不要写“开发者应该考虑”；只需写“你可能不需要一个效果”。
10. 大声读出来。凡是绊住你的地方都改掉。
11. 具体先于全面。 覆盖是 AI 的执念。用覆盖换推进力。舍弃一些东西。
12. 结尾要交出下一步。 不要总结。以最强的句子收尾，给一个指令（“现在去做这件事”），或者干脆停下。

禁用列表¶

构建的 validateProse 步骤（位于 scripts/build.js）在遇到这些词时会让构建失败。这张列表就是被强制执行的编辑简报。当你禁用一种新模式时，在这里加一条规则；当一个词在这里赢得了真实含义时，移除一条规则。不要通过绕过正则的方式悄悄将其加回白名单。

被偷走的工程师措辞¶

那些在 2024 年底左右泄入训练数据后变成 AI 味的工程词汇。

内部行话外泄¶

在调研笔记里好用、但在用户文案里失效的词。

营销腔调¶

那些指向质量却没干实事的形容词和动词。

动词¶

铺垫废话¶

延迟切入正题的句子。删掉它们；几乎不会损失任何价值。

结尾套话¶

过渡词¶

标点¶

校验器无法捕捉的模式¶

上面这些是容易的胜利。更深层的问题需要对每一段做出人工判断。

• 否定式转折。 “不只是 X，而是 Y。”“与其说是 X，不如说是 Y。”这现在比任何词汇条目都更像 AI 痕迹。少用。大多数情况下应该换成直接正面的断言。
• 三件套一切。 每个列表都正好三项。每个形容词都三个一组（“快速、简单、强大”）。变化数量：用 2 或 4。用 1。
• 五段式作文结构。 每页都是 引言 → 3 个小节 → 结论。换换花样。用例子开头。跳过结论。让某些小节只有一句话。
• 段落长度整齐划一。 插入一句只有 4 个词的句子。插入一个单行段落。
• 人为均衡。 当一方明显正确时，却把赞成和反对写得一样长。写出建议；简短提一下真正的例外。
• 空洞的自信。 没有数字的“强大”。换成一个具体事实。
• 堆叠的含糊措辞。 “考虑一下……可能会有用。”每个含糊单独看没事；堆起来，听起来就像被训练过。
• 可互换的文案。 把“Impeccable”换成竞争对手的名字。如果没有任何内容变成假的，那这段文案就是通用的。

拿不准时¶

把段落大声读出来。如果读起来磕磕绊绊，就重写。如果某个句子没有描述本产品的具体内容，就删掉。