散文编辑 是做什么的？
假定事实正确。专注于文字和形式，而非事实。同目录下的 NOTES.md 包含工作示例。
检验标准
每一句话都告诉读者该做什么、该期待什么，或者做错了会发生什么；删掉那些一个都不符合的句子。简洁不等于简短：切勿为了凑字数而删减实质内容，应当砍掉的是包裹实质的冗余部分。
删除
- “清嗓”式开场。 将实质内容放在第一句。
- 重复陈述。 只说一次，并且摆在最合适的位置。
- 填充性过渡词（如“值得指出的是”、“如上所述”、“为了”）。
- 不改变行为的评述（如“平淡但重要”）。
- 含糊的量化（如“出人意料的比例”）。给出它起作用的真实原因，否则删掉断言。
- 回避承诺的含糊其辞。 以决策标准为依据，如实陈述真实的不确定性。
- 用于强调的引用块。 保留那些确实会改变读者行为的警告。
删除被标记为“AI 生成”的痕迹
模型会选择最宽泛读者群体的内容；而作者则只为一位读者和一个主题服务。首先审视结构，因为用词习惯会随模型变化。只有当一句话能给予当前读者他们尚未拥有的信息时才保留。
- 铺垫而非直述。 例如“不是 X 而是 Y”，但根本没人提过 X；用一句话重复观点的结尾；在观点之前添加冗长铺垫；听起来深刻却毫无实质的格言。直述事实。
- 按套路堆砌节奏。 无处不在的三连排比和破折号、重复的句式开头、堆叠的限定词。只有确实有三个并列项时才用三个。
- 过度吹捧。 把普通事实称为“关键”或“强健”，使用推销语言、无名的“权威”、用“-ing”形式暗示意义。直接说明它的作用，否则删掉。
- 按套路格式化。 每一条都加粗、每个想法都设标题，而其中的强调或结构毫无意义。
- 草稿遗留。 聊天框、知识限制声明、与第一句话重复的标题、谈论文档本身而非其主题的文字。
- 错位的读者。 向已经知道的读者重复解释，导致决策信息出现在最后。
保留作者原本的意思，不要添加任何东西来替代你删除的内容。真正的对比、真正的三条并列、或引用来源可以保留；而那些只是为了“显示”却没有增加任何价值的痕迹则要删除。
受保护：为什么绝非无意义
保留解释为什么（如为什么用这个顺序、这个工具、先做这个检查、这个步骤不能跳过）的句子，即使它不发出任何指令：这个理由能让读者处理文档未预见的情况，并判断流程何时不再适用。在理由不明显的地方给出理由，尤其对于安全与合规规则，因为意图才是让读者在无规则覆盖时能应用规则的关键。当一个句子同时包含修饰和理由时，重写句子以保留理由。检验标准是：没有这句话，读者是否会做得更差。
删除不必要的结构
只有在工作确实需要时才增加层级、表格、矩阵、嵌套标题或分支，而不是因为它们看起来严谨。试问：工作流是否真的在此处分叉（如果每位读者都走相同路径，那就是一个列表）？这一步是否必要，还是仅仅看起来周全？如果流程只有四步，就写四个步骤：首次阅读能执行的四个步骤流程，胜过容易被跳过的九个正确步骤。保留常见的陷阱、顺序陷阱以及“为什么”。
模型加载的指令
规则表、技能、角色文件和提示词每次加载时都会消耗 token，而读者是需要规则而非其背后故事的模型。根据加载时机来衡量其代价（D28）：
- 每次会话（规则表、技能和角色描述）：只有规则。描述用不超过 300 个字符说明技能涵盖什么及何时加载；
tools/check.py强制执行这些预算。 - 按需使用（技能或角色正文）：规则加一句理由。只有在规则看起来可选时才添加一个具体的失败案例，不包含日期、计数或项目名称。
- 按需调阅（
NOTES.md、EVIDENCE*.md）：包含事件、数字、日期和来源。正文则指向这些文件。
使用祈使语气。不要复述其他已加载文件中已有的规则；按名称引用它们。docs/REQUIREMENTS.tsv 中的固定需求会随其重写而移动，绝不会静默消失。
流程的结构
目的 → 何时使用 → 开始前准备 → 步骤 → 验证 → 如果不奏效 → 上报
- 切勿省略“验证”：这是最常被跳过也最有价值的部分。
- 每个步骤只做一个操作。精确命名 UI 元素。给出完整路径。
- 在不可逆的步骤之前标明警告，而不是之后。
- 面向有能力的陌生人写作：懂领域，但从未见过此环境。
- 标题应反映读者会搜索的内容。不要包含日期、版本号或“v2”。
语气
- 使用平实的语言和短句。
- 不要用“代价”来软化约束（如没收、终止、数据丢失、个人责任）：直接、明确地说明。
- 链接厂商文档而非复制其内容；仅记录你工作方式特有的部分：复制的文档到达时已经过时。