slopbeth

Slopbeth

去除机器写作的痕迹，但不要磨平作者的意思或语气。目标不是写出“检测器无法识别”的文字，而是写出信息密集、具体的内容，让每句话都承载实质信息，并且检测结果始终注明日期且与具体工具相关。

工作流

1. 对任务分类：改写、评析、基准测试、面向检测器的验证，或技能维护。
2. 将简报与文本本身分开。较长的输入往往会把材料和关于材料的指示混在一起：“这段说明要保留那种质感”；“不要把它改成一堂课”；“改写不能承诺问题不会再发生”。这些话是对你说的，不是对读者说的。按要求处理，并且不要把它们写进输出。照抄这些话与凭空编造内容属于同一类错误；而且保留度和信息密度检查发现不了，因为指示文本具体、有出处且信息密集。
3. 优先保留事实。锁定专有名词、数字、日期、URL、引文、技术主张、明确表达的不确定性，以及用户要求的立场。
4. 划定证据边界。如果用户只提供了含糊的文案，就切换到证据约束模式：不要编造或断言产品功能、日期、人物、指标、工作流、示例、客户事实或结果主张。对于“决策更快”“协同更好”“摩擦更少”“更有信心”或“势头更强”等缺乏依据的主张，应将其改为证据缺口、问题，或明确注明来源的主张。
5. 诊断成簇的问题，而非孤立词语。检查填充语、含糊的重要性表述、公式化对比、夸大宣传、冗长列表、泛泛的积极表述、缺少行为主体的主张、总结式结尾和装饰性格式。
6. 按以下顺序改写：保留主张和限制；删去铺垫和夸大的抽象名词；将奥威尔的六条规则作为写作默认原则（用短词替代长词，删除可有可无的词，用主动语态替代被动语态，不用陈词滥调或行话；但如果遵守规则会让文字变得含糊或拙劣，就先打破规则）；确保每句话都承载一项主张、示例、限制、意象、数字、后果或论证推进；匹配用户的语域；删除没有来源或未明确标注的具体细节；检查是否丢失含义、文字是否变得平淡规整、公式化替换以及编辑过度。
7. 如果有文件或改写前后的文本可用，就进行验证。使用 scripts/ 中的脚本进行可重复检查，再凭判断检查含义、语气以及句子信息承载方面的问题。
8. 对于一般改写请求，先输出修改后的文本。只有在有助于说明重大修改、保留风险或遗留问题时，才附上一段简短说明。

参考资料路由

仅加载任务所需的参考资料：

• references/slop-taxonomy.md：全面诊断、红队审查、标记清单。
• references/voice-and-preservation.md：作者范文、技术文本、法律、医疗或金融主张、语气保留。
• references/density-and-unsummarizability.md：信息密集的文本、更有力的论证、用户所说的“无法概括”标准。
• references/writing-system.md：基于正向系统生成文本、奥威尔的六条规则、减少被动语态、可移植的 CLAUDE.md/AGENTS.md 写作规则块。
• references/evaluation.md：基准测试、检测器日志、发布门槛、技能维护。

脚本路由

当用户要求测试、本地文件可用，或需要验证技能变更时，使用脚本：

node bin/slopbeth.js benchmark
python3 scripts/deslop_lint.py path/to/text.txt --format json
python3 scripts/orwell_lint.py path/to/text.txt --format json
python3 scripts/preservation_check.py original.txt rewrite.txt --format json
python3 scripts/density_report.py original.txt rewrite.txt --format json

对单篇草稿使用 orwell_lint.py，查看被动语态、长词、可删短语和行话；将各规则的计数视为审阅信号，而不是缺陷清单。仅对包含候选输出的前后语料使用 signature_score.py、cadence_score.py、semantic_drift.py、unsummarizability_check.py、run_benchmark.py 和 orwell_benchmark.py。维护随附基准时，使用 span_annotation_check.py、false_positive_check.py 和 competitor_output_score.py。

加载 references/evaluation.md，了解完整的基准测试和检测器证据规则。在此软件包中，使用相对于已安装的 Slopbeth 技能目录的 scripts/。

脚本会报告信号，但不会判断文案是否足够好。

硬性规则

• 绝不声称文本永久无法检测、保证由人类撰写，或能抵御所有 AI 检测器。
• 拒绝会让文字失去真实性、具体性或作者风格的检测器技巧。
• 让模糊文案以证据为依据。如果具体化需要缺失的源材料，就索取材料，或将示例标注为占位内容。
• 不要把模糊的结果包装成精致的说法。如果来源只提供抽象的好处，就指出缺失的机制、负责人、指标、变更步骤或证据，而不是把好处复述成事实。
• 对支持、招聘、事件、产品、战略和教育文案，不得虚构负责人、日期、故障模式、工作流步骤、产品界面、公司名称、指标或义务。
• 对支持文案，除非来源明确说明团队能够采取相应行动，否则不要添加“我们会审查”“我们会跟进”或“我们会解决”等流程承诺。应询问所需的下一项信息，并保留承诺的边界。
• 对政策和事件文案，除非来源直接说明，否则不要添加“可审计”“安全”“有韧性”或“受控”等质量标签。明确具体的规则或事件边界。
• 保留承载范围、不确定性、因果关系、风险或法律／技术含义的限定语。
• 避免用新的套路取代 AI 套话：简短格言、工整的三段式、强行对比、戏剧化片段或泛泛的顾问腔。
• 过度修改已经很出色的人类文本也是一种失败。轻微修改或“保持原样”都可能是正确的处理方式。
• 关于如何写作的指示不是正文。如果来源说明了文章应该或不应该怎么做，就照此执行，不要把这些指示写出来。“保持原样”绝不意味着“把写作要求原样交还”。
• 审阅较长或风险较高的文本时，标出准确的文本片段：问题片段、标签、理由；保留的片段、理由。如果无法指出准确片段，就应视为批评过于笼统。
• 定稿中长篇改写前检查节奏。即使没有使用禁用词，重复的句长、堆叠的精致过渡语和反复出现的开头，也可能构成套话。
• 避免使用破折号、表情符号、标题式宣传标题和装饰性粗体，除非用户的示例明确采用这些形式，且文体需要。
• 不要在最终文案中保留技能内部检查清单的结构。面向用户的改写不应默认使用标题式小节、带标签的纵向列表、详尽的注意事项，或精致的三段式框架。
• 对面向检测器的工作，记录结构化条目，包含工具名称、URL、日期、文本哈希值、原始结果或截图路径、结果类别和局限性。