Community写作与编辑github.com

abhishekkumar541/pre-ai-writing

确保为他人撰写的任何文本(如邮件、帖子、简历、报告等)在结构上符合2022年11月前的写作标准,避免明显的AI输出痕迹。

pre-ai-writing 是什么?

该技能旨在消除文档中常见的AI生成痕迹,例如“一句话回答”的标签、阅读指南、每项事实的状态标签、每节都包含的反驳观点、过度使用表格以及每段都嵌入URL等问题。它要求先明确目标、假设,使用朴素的标题,将核心观点放在每节首句,并主要采用散文形式,最后附上编号的资料来源。该技能支持多种平台,如Claude Code、Cursor、Codex等,通过一个包含10个步骤的工作流程来确保文本质量:从框架设定、素材收集、结构设计、草稿编写、Lint检查、人性化处理、用户声明核实、读者视角审阅,到高 stakes 场景下的额外质量保证和最终交付。它拥有自己的脚本(如lint_doc.py)和参考文件(rules.md、structures.md等),并通过覆盖规则(如禁止使用长破折号、静默修订等)来确保一致性。该技能特别设计为最终处理步骤,在文案撰写、邮件或简历技能之后运行,而不是替代它们。

兼容平台✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/abhishekkumar541/pre-ai-writing/tree/HEAD

Installed? Explore more 写作与编辑 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

Pre-AI写作

文档之所以读起来像LLM输出,是因为一些结构性问题,而词级别的处理无法修复:

  • 嵌入式标签(如“一句话答案”字样)
  • 阅读指南
  • 每项事实都带状态标签
  • 每节都包含一个反驳观点
  • 用表格呈现所有内容
  • 每段都嵌入URL

请像2022年11月之前的人们那样写作:先说目标,再说假设,使用朴素的标题,将核心观点放在每节的第一句,主要采用散文形式,并在末尾列出编号的资料来源。然后由humanizer技能(https://github.com/blader/humanizer)处理句子。

references/rules.md 包含每条规则及其前后对比示例。references/structures.md 为每种文档类型提供了一个模板。以下路径相对于本技能文件夹。

工作流程

  1. 框架设定。 在一行对话中说明四件事:

    • 读者
    • 他们阅读的场合(收件箱、面试小组、信息流)
    • 类型:家庭作业、备忘录、邮件、求职信、帖子、简历、演示文稿、登陆页或文档
    • 层级

    高 stakes 意味着求职申请或家庭作业、客户交付件、任何面向高管的材料,或用户明确说明为高 stakes 的材料。当这一行写好时完成。

  2. 起草前收集。 收集:

    • 简报的原文,包括任何字数或页数限制。
    • 覆盖表,将简报中要求的每项内容映射到文档中相应的章节。该表保留在对话或笔记中,不出现在文档正文里。
    • 第一手证据,每条证据注明来源。
    • 用户自己的语言,来自笔记和之前的消息。
    • 对于客户文案,收集15到20条客户的原话。

    将任何计划中但无来源的说法标记为“待确认”。当每个计划的说法都有来源或“待确认”时完成。

  3. 结构设计。 从 references/structures.md 中选择模板,并根据重要性为每个章节分配字数预算。简报中的任何限制优先于默认长度。当存在带有预算的提纲时完成。

  4. 起草 到 <名称>_draft.md,遵循 references/rules.md 和 references/evidence.md。状态标签、访问日期和编号表格放入 <名称>_notes.md。

  5. Lint检查。 运行:

    python3 scripts/lint_doc.py --type <类型> <文件>
    

    对于演示文稿,传入幻灯片文件夹;<aside> 被视为演讲者备注。修复所有 FAIL。对于每个 WARN,要么修复,要么在对话中说明保留原因。当退出代码为0时完成。

  6. 人性化处理。 使用技能工具调用 humanizer 技能,即使是一封三行邮件也不例外。手动“我自己检查过了”不算数;在测试中,新启用的对话会跳过此步骤。对纯文本部分使用嵌入式模式运行。表格、引用的文本、代码和资料来源列表保持不变。将结果保存为新文件并再次进行lint检查。当新文件通过lint检查时完成。

  7. 关于用户的声明。 列出所有描述了用户的行为、习惯、结果、使用情况或感受的句子。将每个句子追溯到用户的简历、笔记或记忆,或本次对话中用户说过的话。对于没有来源的句子,请询问用户或将其删除。当对话中的一张表格(声明 | 来源 | 保留、删除或已询问)覆盖了所有此类句子时完成。

  8. 以指定读者的身份通读。 对每个问题回答“是”或“否”,并修复任何错误答案:

    • 每个章节的第一句话是否传达了核心观点?
    • 如果去掉某个段落,读者是否会错过它?
    • 是否有任何句子在描述文档本身?
    • 章节的长度是否与重要性成正比?
    • 哪些内容只能来自第一手工作?(请指出它;如果没有,则草稿是泛泛而谈。)
    • 每个数字是否都能在笔记中找到对应的出处?
    • 文档末尾是否包含下一步行动或请求?
    • 格式是否适应其最终用途?(邮件和LinkedIn使用纯文本,不使用markdown。)
  9. 仅限高 stakes 层级。 只要第1步指定了高 stakes(包括短文本),就必须执行此步骤。遵循 references/high-stakes.md:

    • 由一个新的智能体进行读者视角审核
    • 对于家庭作业和方案,使用基线加上 scripts/sameness_check.py 以及通过 scripts/blind_pack.py 进行盲审

    当满足其通过规则,或已报告失败时完成。

  10. 交付 以目标格式呈现:

    • 邮件和帖子使用纯文本
    • 文档使用Markdown或doc格式
    • 演示文稿使用幻灯片

    覆盖表、声明表和状态表保留在对话中或 <名称>_notes.md 中。仅在用户要求或交付物是PDF时创建PDF:

    python3 scripts/build_pdf.py in.md out.pdf --title "..." --footer-left "..."
    

    然后检查页面图片,包括资料来源页。运行时不要加 -I 参数,因为它会导入 markdown。

覆盖其他技能的规则

  • 破折号。 任何地方不允许使用U+2014或U+2013,包括引用和笔记。这是作者的个人规则;如果你的风格允许使用破折号,请删除 scripts/lint_doc.py 中的 dash 检查。
  • 修订版是新版本。 永远不要静默地修改原始的交付物。
  • 流程不要出现在页面上。 方法、流程和AI使用情况只在资料来源幻灯片或备注中占一行,绝不能作为一个章节或幻灯片。
  • 本技能是最终处理步骤。 文案撰写、邮件和简历技能负责起草内容;本技能在这些技能之后运行,而不是代替它们。

文件

  • scripts/lint_doc.py:结构和措辞检查器。运行 --help 查看标志;--fix-typography OUT 会写入一份修正后的副本。
  • scripts/sameness_check.py、scripts/blind_pack.py:高 stakes 工具包。
  • scripts/build_pdf.py:将Markdown转换为PDF,并附带检查。
  • scripts/prompt_trigger.py:可选的UserPromptSubmit钩子,用于提醒Claude使用本技能(参见README)。
  • references/:
    • structures.md
    • rules.md
    • evidence.md
    • voice.md
    • high-stakes.md
  • templates/blind_review_prompt.md
  • tests/test_lint_doc.py:在更改任何规则后运行它。

相关技能