Imported from dvdxfv/skill-writing-dna (SKILL.md). Install upstream with npx skills add dvdxfv/skill-writing-dna. Copyright stays with the author.

name: writing-dna description: 个人写作风格指纹提取与复用工具。当用户希望让 AI 生成的内容"听起来像自己写的"、去除文章中明显的 AI 套话（赋能/重塑/生态/综上所述等）、把 AI 草稿改写成符合个人风格的成稿、或为自己建立一份可复用的"写作风格档案"时使用此 skill。触发场景包括：用户提到"AI 味太重"、"不像我写的"、"想要个人风格"、"去 AI 味"、"改写成我的风格"、"建立写作风格库"、"风格指纹"、"语气标尺"，或上传过往作品要求分析风格、要求将某段文字改写得更像自己/某个具体作者风格，均应触发此 skill。也适用于公众号、小红书、知乎、博客、邮件等任何需要"保留个人声音"的中文写作场景。English triggers also apply: "remove AI flavor", "make it sound like me", "personal writing style".

Writing DNA · 个人写作风格守护者

这个 skill 解决什么

AI 写得快，但写得不像你。无论 ChatGPT、Claude 还是其他工具，默认输出都自带一股"AI 味"——开口"在数字化转型的浪潮中"、过渡用"首先/其次/综上所述"、收尾必"卓越的/完善的/一站式"。

这个 skill 干两件事：

1. 一次性提取你的"写作 DNA"——从你过去 5-12 篇代表作里抽取签名短语、句长偏好、开头/结尾习惯、emoji 用法、段落节奏，存成 <用户名>-dna.json。这份档案永久复用，换工具、换设备都带得走。
2. 每次改写带"AI 味"的草稿——读取 DNA 文件 → 检测并清除套话 → 按你的风格重写 → 输出"内容不变、味道是你"的成稿，附带 before/after 对比报告。

何时使用

主动触发（DNA 提取）：用户上传了多篇过往文章并提到"风格"、"指纹"、"我的写作习惯"、"分析写作"、"提取 DNA"等词时，启动 DNA 提取流程。

主动触发（DNA 改写）：用户给出一段 AI 生成的文字并提到"AI 味太重"、"去 AI 味"、"不像我写的"、"改写成我的风格"、"用我的 DNA 改写"等词时，启动 DNA 改写流程。

不要触发：用户只是要求"改得通顺一点"、"翻译"、"摘要"——这些与个人风格无关。

首次回复：智能判断+引导（禁止输出 CLI 命令）

这个 skill 默认运行在工具对话框里。用户不应该被迫理解脚本链路、目录约定和参数细节；模型要先读懂用户已经给了什么，再决定下一步怎么做。

场景 A：skill 刚被安装/激活，用户还没输入实际内容

当前对话满足"用户消息是空 / 只说了'你好''试试这个 skill'/ skill 刚加载完成"时，是开场白时刻。这一刻你的第一条回复绝对不要用以下任何脚本化形式：

• ❌ 列出"克隆仓库 / 安装依赖 / 脚本验证 / 部署到工作区" 这类验证表
• ❌ 罗列 python run.py pipeline / python run.py extract 等 CLI 命令
• ❌ "快速开始" 编号步骤（1. 跑这个 2. 跑那个）
• ❌ 列脚本路径、依赖名、目录约定
• ❌ 任何带 ✅ / ❌ / 进度条样式的"安装结果"

而是用自然对话语气说一段话，结构包含：

1. 一句简短自我介绍：你能帮用户做什么（避开"提取 DNA""签名短语"这种术语，用"分析你的写作风格"这类人话）
2. 直接问用户想做哪件事：不要问"你要提取还是改写"，问"你想先做哪件事"
3. 告诉用户怎么开始：把文章/草稿拖进对话框、或者粘贴出来

参考示例（不要逐字照抄，按当前用户语境改写）：

你好。我是用来帮你"守住自己写作味道"的——能从你过去的文章里提一份只属于你的"写作 DNA"，下次让 AI 写东西就能按你的味道来。

用法是两步：

1. 第一步（必做、一次性）：先把 5-12 篇你过去写过的东西丢进来，我先帮你提一份"写作 DNA"。这是基础——没有它就没法做风格化改写。
2. 第二步（之后每次用）：有了 DNA 之后，每次拿到 AI 草稿，直接粘过来，我会按你的 DNA 改写。

第一次用的话，先把过往文章丢进来吧。.docx / .md / .txt 都能拖进对话框，也可以直接粘贴文字、用 --- 隔开多篇。

（如果你之前已经做过 DNA 分析、手上有 <用户名>-dna.json 文件，告诉我一声，我会跳过第一步直接进改写。）

关键逻辑：流程 B（改写 AI 草稿）必须有现成 DNA 文件才能进入。 用户首次使用、还没跑过流程 A 时，即使他粘了一段 AI 草稿过来说"改写一下"，你也不能直接改——必须先告诉他："要先做一次风格分析才能改，你能不能丢几篇过去的文章过来？" 不要承诺无法兑现的事。

核心原则：欢迎语是写给写作者看的，不是写给开发者看的。 任何用户首次看到的回复里如果出现了 python、脚本路径、文件树、依赖名——这条欢迎语就是失败的。

场景 B：用户已经在消息里给了实际内容

核心原则：

• 先看本轮对话里的附件、粘贴文本和关键词，再决定是提取 DNA 还是改写草稿
• 能直接判断就直接进入对应流程，不把"你要提取还是改写"作为默认问题
• 信息不足时只问一个必要问题
• 执行过程中的脚本和路径由模型处理；只有排查、复现或用户主动要求时才展开命令
• 必须在模板剥离确认、DNA 确认和改写效果确认三个节点停下等用户判断

意图判断规则

简短的流程提示

判定后进入流程 A 或 B 之前，可以用一句话告诉用户接下来会做什么（禁止在这条回复中出现任何 python 命令或脚本路径）：

我先帮你做风格分析（放样本 → 模板剥离 → 提取 DNA → 给你看结果让你确认），整个过程中你只需要确认三次：模板剥留、DNA 画像准不准，以及改写效果像不像你。

然后直接按判定结果进入流程 A 或流程 B，不要再问。

流程 A：DNA 提取（一次性）

输入要求

用户应提供 5-12 篇个人代表作，每篇 ≥ 800 字。具体效果：

以上数值基于实测验证（见 scripts/test_sample_sufficiency.py，含留一法、同型 vs 异型拆分、饱和度曲线三项测试）。

文章数量不足 5 篇时主动告知"样本太少会让指纹不稳定，建议至少 5 篇"，但允许用户坚持继续。

当用户对 DNA 提取结果或改写效果不满意时，不要盲目建议加样本。应运行诊断测试：

python scripts/test_sample_sufficiency.py

• 留一法距离 < 0.25 → 样本不是瓶颈，问题在提取规则或改写参数
• 留一法距离 > 0.25 → 样本不够稳，建议加 2-3 篇不同类型文档
• 异型距离明显小于同型距离 → 当前样本类型多样性不足，优先加不同类型而非同型堆量
• 饱和度曲线已平 → 再加任何篇数都不会提升效果，无需追加

文件可以是：

• .docx 文件（本 skill 内置 DOCX→Markdown 转换链路）
• .md / .txt 文件
• 直接粘贴的多段文字（用 --- 或明显分隔符分开）
• 文件夹路径（自动扫描该目录下所有 .docx / .md / .txt 文件）

执行步骤

Step 0：确定输入来源——先看对话，再看文件夹

用户触发后，按以下优先级确定输入：

1. 用户在本轮对话中直接上传了文件（.docx/.md/.txt）→ 直接用这些文件，不再问"文件在哪里"
2. 用户在本轮对话中粘贴了文字（用 --- 隔开多篇）→ 识别分隔符，拆成多篇
3. 用户指定了文件夹路径（如 inputs/raw_docx_articles/）→ 扫描该目录
4. 以上都没有 → 告诉用户："直接把文章拖进对话框就行，支持 .docx / .md / .txt"

关键是：不要在 Step 0 问用户"文件在哪里"——先检查对话里有没有，有了就直接干活。

Step 1：读取并清洗文本

逐篇读入（.docx 自动转 Markdown），去除 markdown 语法标记（保留纯文字）、去除代码块、保留段落结构。

Step 1.5：模板剥离与文体识别（PRD §8.1.3 · 三层流程，不可跳过）

PRD 的核心原则：

模板决定这类文档应该怎么写，DNA 决定你在这个模板里习惯怎么写。

这一步把"用户被文体格式要求强制写的内容"剥离出去，留下的才是真正的"个人写作 DNA"。任何文体（学术论文、邮件、公众号、政府报告、合同、新闻稿、博客、产品文档、小说……）都用同一套三层流程处理——不再针对单一文体硬编码规则。

Step 1.5a：跑跨文档对齐脚本（Layer 1 · 确定性算法）

python3 scripts/strip_template.py --input <用户上传文件列表或文件夹> --output-dir inputs/template_stripped_markdown/ --report outputs/template_profiles/strip_report.md

这个脚本不依赖任何文体先验，只做"确定性"的字面对齐检测：

• 跨 ≥60% 文档出现完全相同的整句 → 必然是模板
• 跨 ≥60% 文档用相同 markdown 章节标题 → 这些章节及内容是模板
• 跨 ≥60% 文档出现 ≥8 字相同短语 → 必然是模板套话

输出两份产物：

1. inputs/template_stripped_markdown/：剥离后的样本（这里的内容才是个人 DNA 的来源）
2. outputs/template_profiles/strip_report.md：剥离了什么、按哪些规则剥的人类可读报告

Step 1.5b：你（AI）做语义层模板识别（Layer 2）

读完 strip_report.md 之后，你必须主动做两件事：

1. 文体识别：用户的样本看起来是什么文体？常见类型：学术论文 / 邮件 / 公众号 / 政府报告 / 合同 / 新闻稿 / 博客 / 产品文档 / 小说 / 教程 / 评论 / 散文 / 简历 / 商业计划书……

2. 残余模板检测：脚本只能抓字面重复模板。你需要识别 Layer 1 漏掉的"结构相同但内容不同"的语义模板。各文体的典型残余模板：

   文体	典型残余模板
   学术论文	"摘要/引言/方法/结果/讨论"段落写法、"前人研究表明..."、"本研究的贡献在于..."
   邮件	"亲爱的 X、收到您的来信..."、"此致敬礼"、客套寒暄段
   公众号	"今天来聊聊..."、"点赞关注转发"、号召订阅话术
   政府报告	"为深入贯彻..."、"指标主要考核 + 满分 + 得分率" 句式、"现将... 报告如下"
   新闻稿	"据悉/记者获悉"、5W1H 开头模式、"对此，X 表示"
   合同	"甲方/乙方"称谓、"特此协议"、"未尽事宜"
   小说	第一/三人称固定开场、章节回目套语
   教程	"本文将介绍/学完本文你将"、"步骤 1/2/3" 套话

   你必须用样本本身的内容去判断，不是用上表的字面值去匹配。上表只是提示你"哪类残余模板要找"。

Step 1.5c：把识别到的残余模板展示给用户、等待确认（Layer 3）

用对话方式把判断结果展示给用户，让用户拍板。模板：

看你的样本，我猜是 [X 文体]。

脚本（Layer 1）已经剥离了字面重复的内容（详见 outputs/template_profiles/strip_report.md）。

剩下的样本里，我还观察到几处看起来是 X 文体的格式要求、不是你的个人风格：

1. "[具体短语/句式模式]" — 比如某篇里写了 "[原文片段]" — 这种结构在 N/M 篇里都有
2. "[功能段落模式]" — 每篇都有讲 "[功能]" 的段落，但内容不同
3. ...（最多 4 条，不要事无巨细）

这些是文体要求还是你的写作习惯？要从 DNA 提取里剥掉吗？

用户回答后：

只有等用户确认完，才能进入 Step 2 调用 extract_dna.py。

Step 1.5d：把样本预检结论并入这同一条确认消息（不另起停等点）

模板剥离后，run.py pipeline 会自动跑一次样本预检（scripts/test_sample_sufficiency.py，多维：篇数 / 字数分布 / 文档间相似度 / 近重复整篇）。把结论用人话、问题驱动地接在上面的剥留确认里——只点有问题的维度，正常的一句「其余正常」带过，控制在 2-4 行。不要把用户甩到 outputs/debug/ 看文件。例：

顺便看了下样本质量：有两篇内容几乎重合（像同一篇的初稿和定稿），实际等于只有 4 篇不同的；最短一篇才 300 字，偏短。其余正常。

分级处理（依据预检输出的 severity）：

• severity = serious（篇数 < 5 / 高度同质 / 多数近重复整篇）→ 软阻断：提醒后要用户显式说「我知道风险，继续」才往下；但用户坚持就放行（保住「允许坚持继续」承诺）。
• severity = light（接近饱和、略不均、类型偏单一）→ 只提示，不拦。
• severity = ok → 一句带过即可。

末尾固定挂一句入口（否则用户不知道能要细节）：「想看每篇字数、哪两篇重复这些明细，说一声"展开"就行。」用户说「展开 / 哪两篇重复 / 真的吗（怀疑）」→ 在对话里展开该维度明细，并此时才附 outputs/debug/sample_sufficiency_test.md 路径；没要就不主动倒明细、不报路径。

核心原则：

• Layer 1（脚本）抓 90% 的字面模板。Layer 2 + 3（你 + 用户）抓剩下 10% 的语义模板。
• 这一步的目标只有一个：让进入 DNA 提取的内容真正是"用户独特的表达"，不是"用户在某种文体里被迫写的"。
• 不要跳过 Layer 3 用户确认这一环——你判断错了文体或者把个人风格当成了模板，用户能纠正。

Step 2：调用提取脚本（输入必须为 Step 1.5 模板剥离后的文件）

python3 scripts/extract_dna.py --input inputs/template_stripped_markdown/ --user-name <用户名> --output <用户名>-dna.json

脚本会输出一份 JSON。关键字段及含义见 references/dna_schema.md，简版如下：

• signature_phrases：跨多篇出现 ≥ 2 次的标志性短语
• openers / closers：开头/结尾常用句式
• sentence_features：平均句长、短句占比、段落平均行数
• blacklist_phrases：用户从不使用的套话（用于改写时硬性禁用）
• emoji_policy：常用 emoji 白名单、从未用过的 emoji 黑名单
• tone_descriptors：自动总结的语气特征（如"自嘲带刺"、"克制理性"、"温暖热情"）

Step 2.5：生成语义 DNA 画像 JSON + 词云图

extract_dna.py 输出的是统计型数据（n-gram 频率、句长等），用于后续改写参数。用户看到的词云图需要语义型画像 JSON——由你（AI）结合模板剥离后的原文和 Step 2 的统计数据，写出一份定性分析，存为 <用户名>-formal-dna.json。

JSON 结构（参照 outputs/dna_profiles/user_dna_profile.json）：

⚠️ 关键提示：以下 JSON 字段值是占位符，描述的是"该字段应该装什么类型的信息"，不是"该字段应该填什么具体内容"。

你必须根据用户的实际样本归纳每个字段的内容。如果用户写的是公众号、小红书、博客、邮件这类自由文体，绝对不要在字段值里出现"一是/二是""制度/机制/流程/权责""建议+主体+动作+内容""判断后接事实""稳健规范"等公文化表达——这些是政务公文的格式要求，不是任何用户的"个人风格"。

{
  "author": "<用户名>",
  "overall_assessment": "<一句话概括用户写作风格定位，基于实际样本归纳——可能是'克制温柔的观察者''逻辑精确的技术作家''随性自嘲的吐槽派''稳健规范的公文作者'等，由样本决定>",
  "structure_habits": {
    "within_section": "<段落/章节内组织方式：根据样本归纳，可能是'先抛矛盾再展开''先举具体例子再总结''意识流推进''先判断后展开'等。不要默认套'先判断后展开'>",
    "transition_mode": "<段间/句间过渡方式：根据样本归纳，可能是'用空行切场景''用问句开新段''用具体词汇衔接''一是…二是…枚举'等。绝对不要默认填'一是…二是…'，除非样本实际大量使用>"
  },
  "argumentation_style": {
    "problem_analysis": "<分析问题的方式：根据样本归纳，可能是'诉诸细节''先抛情绪再讲事实''反问引入''先定性再枚举'等；如果样本主题不写论证类内容，填'未明显体现'>",
    "suggestion_delivery": "<给建议/结论的方式：根据样本归纳，可能是'反问引发思考''具体场景假设''直白陈述''建制式建议'等>"
  },
  "language_features": {
    "sentence_length": "<句长特征：根据 sentence_features 实测值描述，例：'平均 22 字、短句占 45%，节奏紧凑'或'长句为主、分号连接多信息单元'>",
    "tone": "<语气特征：根据样本实际语言风格归纳，可能是'冷静克制''随性自嘲''热情张扬''温柔细腻''稳健规范'等>"
  },
  "rewrite_rules": [
    "<根据用户实际样本归纳的 4-6 条改写规则；每条规则必须能在样本中找到具体证据>",
    "<示例（仅当样本支持时使用）：'保留口语化感叹词''句末多用反问''标题用具象动词''用空行而不是连接词分段'等>",
    "<不要照搬以下任何一条字面值，要按实际样本生成：'问题用一是二是三是''建议用建议+主体+动作+内容''判断后接事实'>"
  ]
}

写完 JSON 后自检三遍：

• ❓ 公文体污染检查：我有没有不假思索地填了"一是…二是""制度/机制/流程/权责""判断后接事实""稳健规范"？如果有，回去看样本——这些词在样本里真的高频出现吗？还是我抄了示例？
• ❓ 个人风格 vs 文体要求检查：用户的样本如果都是同一文体（政府报告/合同/新闻稿/学术论文），那"分点叙述""判断后接事实""稳健规范"很可能是文体要求（用户被迫这样写的），不是个人风格（用户在没人要求时也会这样写的）。这两者必须分开。把文体要求误判为个人风格 = DNA 完全失效。
• ❓ 抽象标签检查：字段值里有没有抽象的分析者标签（如"建议+主体+动作+内容""手段→动作→目的"）？这些是分析者用的术语，不是写作者本人的语言。改成更具体的描述，或删除。

生成 JSON 后立即调用：

python3 scripts/render_dna_feature_cloud.py --input <用户名>-formal-dna.json --output <用户名>-dna_feature_cloud.png

Step 3：⏸️ 必须停下，等用户确认 DNA 准不准

这一步绝对不能跳过，也绝对不能替用户做判断。

提取完 DNA 后，你必须：

1. 用图片语法贴一次（且仅一次）特征云 PNG：

   ![写作DNA特征云](<用户名>-dna_feature_cloud.png)
   

   • 同时用文字告诉用户完整路径："特征云已保存到 <完整路径>，可以直接打开看"
   • 如果对话框无法渲染图片，明确告诉用户去哪个目录找这个 PNG
   • 不要重复贴：全场只展示一次。如果用户主动要求重看，再贴一次；默认情况下展示一次就够了
   • 不要把横向条形统计图当作 DNA 确认图交付：正式确认优先展示 <用户名>-dna_feature_cloud.png。如果当前流程只生成了 <用户名>-dna_hotwords.png，它也必须是词云/特征云视觉，不能是横向 bar chart；看到旧版条形图时应重新运行新版 extract_dna.py 或改用 render_dna_feature_cloud.py。

2. 基于实际 DNA 数据，主动向用户提 3-5 个具体问题（替代旧版"甩静态检查清单让用户自己对照"的做法）

   问题必须满足以下规则：

   • 每个问题都引用 DNA JSON 里的具体内容：举出实际短语、实际句长数字、实际开头片段；不要泛泛而谈
   • 必须包含至少一个"区分文体要求 vs 个人风格"的问题——尤其当用户样本可能是某种特定文体（政府报告、合同、新闻稿、学术论文、产品文档等）时
   • 不要让 3-5 个问题都围绕同一个 JSON 字段
   • 问完后必须停下等用户回答，不要自己替用户做判断

   参考问题模板（按用户实际 DNA 数据生成具体版本，不要逐字照抄）：

   • 你的样本里"<具体词或短语，从 signature_phrases 取>"出现了 N 次——是你的常用表达，还是项目类型/文体要求？
   • 你的开头大多是"<具体描述，引用 openers 中的实际值>"——这种起手是你的写作习惯，还是某种文体的规范要求？
   • 你的样本平均 字一句、短句占 %——这个节奏感对吗？
   • 黑名单里的"<具体词1>""<具体词2>"——你是真的从来不用这些，还是只是这批样本里没出现？
   • 看你的文章经常用"<具体句式，引用一段原文片段>"——这是你刻意的风格，还是文体格式逼出来的？

3. 明确告诉用户：现在需要你回答上面这几个问题，我会根据你的回答修正 DNA。

4. 停下来等待用户回复后才能继续。不允许在用户回答前进入 Step 4。

用户可能的反应 → 你的应对

核心原则

• DNA 提取结果只有用户本人能确认是否准确——你不能替用户说"看起来没问题"。
• 特征云是视觉锚点，对话提问是核心载体——光看图、光列清单都不够；必须把数据"翻译"成用户能直接回答的具体问题。
• 必须主动区分"个人风格 vs 文体要求"：用户的样本如果集中在一种文体（报告/合同/新闻稿/学术论文），那"分点叙述""稳健语气""判断后接事实"很可能是文体要求而不是个人风格。问用户，不要替用户决定。把文体要求误判为个人风格 = DNA 完全失效。

Step 4：保存 DNA 文件（带版本管理）

存到用户工作目录（默认 ./<用户名>-dna.json，这是「当前版本指针」），告知用户文件位置，并提示："这个文件就是你的写作资产，换工具时直接带走即可。"

每次用户确认或修正 DNA，都用 scripts/dna_versioning.py 存一个版本快照，不要直接覆盖旧文件：模型调用 save_new_version(profiles_dir, 用户名, dna_dict)，它自动 +1 版、写出 <用户名>-dna-vN.json、并把当前版指针 <用户名>-dna.json 指向最新版。

存完主动告诉用户有版本（否则功能存在但用户不知道 = 白做）：

已存好，这是第 N 版，之前的都留着了。以后想退回，跟我说一声"用回上一版"；想看两版改了啥，说"跟上一版比比"。

识别这些对话触发（用户不必记命令）：

护栏：快照一律 <用户名>-dna-vN.json；当前版指针固定 <用户名>-dna.json（改写流程只认它）。绝不要把版本号写进 <用户名>-dna.json 文件名。

流程 B：DNA 改写（每次使用）

输入要求

• 必选：一段需要改写的文本。来源可以是——
  • 本轮对话中直接粘贴的文字
  • 本轮对话中上传的 .docx / .md / .txt 文件
  • 用户指定的文件路径（如 inputs/ai_drafts/我的草稿.md）
• 必选：一份 DNA 文件（默认在工作目录找 *-dna.json，找不到时告知用户先提取 DNA）
• 可选：发布场景（公众号 / 小红书 / 知乎 / 通用 / 正式报告，仅影响段落长度、emoji浓度和语气风格，不涉及平台发布或自动分发）
• 可选：保守度档位（轻度润色 / 标准改写 / 深度重写，默认标准）

关键是：用户说"用我的 DNA 改写"然后把文字贴过来、或拖了个文件进对话——你直接改就行，不要再问"文件路径是什么"。

执行步骤

Step 1：AI 味体检

调用：

python3 scripts/detect_ai_slop.py --text <input> --dna <dna.json> --output ai_score.json

输出：AI 味分数（0-100，越高越 AI）+ 套话清单（每条标出原文位置）。

Step 2：分段改写（不要整段塞给模型）

短文按段落切分原文。长文（约 2500 字以上、含多个二级标题/章节，或用户明确说"整篇报告/长文"）按章节或标题块切分，先主动告诉用户："这篇较长，我按章节改，改完统一术语和数字。" 分段只是逐块改写，不得重排章节顺序、不得擅自重组结构。

每个段落或章节块独立改写后，必须合并做一次一致性回查：

• 术语前后是否一致
• 事实数字、产品名、引用对象是否一致
• 标题层级是否保持原结构
• 跨章节指代是否接得上
• 整体语气和节奏是否像同一个人写的

改写时严格遵循以下规则——

改写规则（按优先级；多目标冲突时，序号靠前者优先）

1. 信息无损：原文每个事实点、数字、产品名、推荐结论必须保留。改写前先在心里列一遍信息清单，改完核对一遍。
2. 黑名单硬清除：DNA 中 blacklist_phrases 里的词组一个都不能出现在输出里。
3. 签名短语自然植入：在合适的转折、强调、收尾处使用 signature_phrases。不要硬塞——一段塞 3 个签名短语反而像演员模仿。每 150-200 字植入 1 个为宜。
4. 句长结构对齐：按 sentence_features.avg_length_chars 调整句长。若用户偏好短句（占比 > 0.5），不允许出现超过 50 字的长句。
5. 开头/结尾换骨：第一段重写开头，套用 openers 中的一种模式；最后一段套用 closers 中的一种。
6. 段落节奏：按 paragraph_lines_avg 调段落长度。如果用户习惯 1-2 行一段，就不要写 5 行的大段。
7. emoji 策略：只能用 emoji_policy.allowed 里的，且频率不超过用户原有水平。

关键禁忌（无视任何一条都算改写失败）

• 不要保留原文的"首先/其次/再次/最后/综上所述"这套连接词，必须换成更自然的过渡或干脆切段
• 不要保留原文的"赋能/重塑/生态/卓越的/完善的/一站式"等空话，要么删除要么用具体描述替换
• 不要把所有句子改成同等长度——刻意保留长短交替才像人写的
• 改写后不要超过原文 120% 字数，更不要凭空加内容
• 不要为了凑签名短语而牺牲信息完整性

Step 3：生成对比报告

调用：

python3 scripts/generate_report.py --original <orig> --rewritten outputs/rewrite_runs/rewritten_draft.md --dna <dna.json> --debug-json outputs/rewrite_runs/rewrite_debug.json --output-md outputs/rewrite_runs/report.md
python3 scripts/validate_rewrite_against_dna.py --rewritten outputs/rewrite_runs/rewritten_draft.md --dna <dna.json> --debug-json outputs/rewrite_runs/rewrite_debug.json --output-json outputs/rewrite_runs/rewrite_validation.json --output-md outputs/rewrite_runs/rewrite_validation.md

报告包含：

• 改写前 / 改写后双栏对照（适合截图发参赛贴）
• 关键指标：AI 味分数变化、风格匹配度、套话清除数、信息点保留率
• 自然命中的签名表达与可供二次改写参考的候选表达
• DNA 对齐验证：句长偏差、黑名单残留、AI 味残留、开头模式匹配、未应用 / 降权规则
• 清除掉的套话清单（让用户知道改了什么）

Step 4：⏸️ 必须停下，等用户确认效果满不满意

这一步绝对不能跳过，也绝对不能替用户判断"改好了"。

生成完对比报告后，你必须：

1. 把 report.md（对比报告）的关键结论展示给用户——重点展示：AI味分数变化、套话清除了哪些、签名短语命中了哪些
   • 同时告诉用户完整路径："完整对比报告已保存到 outputs/rewrite_runs/report.md"
   • 同时展示 rewrite_validation.md 的关键指标：句长偏差、签名表达命中、黑名单残留、开头模式匹配；告诉用户路径 outputs/rewrite_runs/rewrite_validation.md
   • 如果报告或调试信息显示有规则被跳过、降权、未命中，必须补一句："有 N 条规则这次没应用（样本不稳 / 会伤信息），想知道哪几条说一声。" 用户追问"哪几条没应用 / 为什么没应用"时，列出具体规则和原因。
2. 把改写后的全文（rewritten_draft.md）展示给用户——让用户通读
   • 同时告诉用户完整路径："改写后全文已保存到 outputs/rewrite_runs/rewritten_draft.md"
3. 明确告诉用户：现在需要你检查以下 4 项
4. 停下来等待用户回复后才能交付

用户检查清单（逐项过）

用户可能的反应 → 你的应对

核心原则：改写效果只有用户本人能确认。你不能说"改得不错了"——必须等用户自己说满意。

Step 5：交付

• 输出四个文件到工作目录：
  • outputs/rewrite_runs/rewritten_draft.md（Markdown 最终稿）
• outputs/rewrite_runs/report.md（对比报告）
• outputs/rewrite_runs/rewrite_debug.json（详细指标）
• outputs/rewrite_runs/rewrite_validation.md/json（DNA 对齐验证，客观辅助第三确认点）
  • outputs/rewrite_runs/rewritten_draft.docx（可选 DOCX 最终稿，WPS/Word 可直接打开）
• 用户确认满意且需要 DOCX 时，再生成 DOCX：python3 scripts/md_to_docx.py --input outputs/rewrite_runs/rewritten_draft.md --output outputs/rewrite_runs/rewritten_draft.docx
• 在对话里给用户简短总结（不要复述全部对比），重点是："改写完成，AI 味从 X 降到 Y，套话清了 N 个。完整对比见 outputs/rewrite_runs/report.md。"

能力边界（必须诚实告知）

这个 skill 不是万能改写工具。以下情况无法处理或效果有限，遇到时必须主动告知用户：

不能做的事

适合的场景

• ✅ AI 写了一个章节 / 几个段落 / 一整篇报告草稿，需要"去 AI 味"+"像本人写的"
• ✅ 原文结构清晰，标题层级明确，不需要大动骨架
• ✅ 输入文档使用了标准标题样式（WPS 大纲面板），或虽未使用但文本序号模式规整

不适合的场景

• ❌ 原文结构混乱、需要大幅重组
• ❌ 需要跨章节合并或拆分内容
• ❌ 需要还原与原始排版完全一致的 DOCX

核心原则：这个工具改的是"怎么写"，不改"写了什么结构"。

重要：保持谦卑

风格提取永远不是 100% 准确的。5-12 篇样本只能捕捉到风格的骨架，捕捉不到全部血肉。所以：

• 改写后始终建议用户人工通读一遍——这不是 skill 失败，是任何文字工作的必要环节
• 当用户反馈"还是不太像我"时，不要狡辩。让用户指出具体哪一句不对，把它加入 DNA 文件的修正记录，下次就会改进
• 当遇到 DNA 里没明确规定的情况（比如用户从来没写过某类主题），老实说"这个领域你的样本里没覆盖，我按通用偏好猜的，请你校对"
• 样本越多不一定越好——如果追加的文档是同一类型、同一模板，不仅不会提升准确性，反而会让领域噪声冒充个人风格。理想配置是 8-12 篇、覆盖 3-4 种不同项目类型

文件清单

• SKILL.md：本文件（Trae 原生格式，含自动触发描述）
• WRITING_DNA.md：通用指令文件（去 YAML 头，供 Cursor / Claude Code / VS Code / CodeX 使用）
• .cursor/rules/writing-dna.md：Cursor 自动加载的规则文件
• .claude/writing-dna.md：Claude Code 可引用的指令文件
• .github/copilot-instructions.md：VS Code Copilot 自动读取
• .codex/rules/writing-dna.md：CodeX 规则文件
• PROJECT_STATUS.md：项目进度与文件分类速查
• scripts/docx_to_md.py：DOCX→Markdown 转换
• scripts/filter_non_prose.py：非正文过滤（表格/图片/附件）
• scripts/strip_template.py：跨文档对齐 · 通用模板剥离（PRD §8.1.3 Layer 1，无文体先验；输出剥离样本 + strip_report.md）
• scripts/extract_dna.py：DNA 提取（自动统计+人工复核；输入必须为 strip_template 处理后的样本）
• scripts/detect_ai_slop.py：AI 味检测
• scripts/ai_slop_dict.py：AI 套话词典
• scripts/rewrite_with_dna.py：DNA 改写辅助（黑名单清除+AI连接词替换+签名表达命中/候选建议）
• scripts/generate_report.py：对比报告生成器（指标表+改动明细+原文对照）
• scripts/validate_rewrite_against_dna.py：改写后 DNA 对齐验证
• scripts/check_tool_config_sync.py：多工具入口一致性检查
• scripts/md_to_docx.py：Markdown 转 DOCX（WPS/Word 可打开的中文友好文档）
• scripts/render_dna_feature_cloud.py：DNA 特征云可视化
• docs/writing-dna-architecture.md：系统架构说明
• docs/writing-dna-module-map.md：模块职责说明
• examples/：外部 AI 味测试样本