| 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 干两件事：
- 一次性提取你的"写作 DNA"——从你过去 5-12 篇代表作里抽取签名短语、句长偏好、开头/结尾习惯、emoji 用法、段落节奏，存成
<用户名>-dna.json。这份档案永久复用，换工具、换设备都带得走。
- 每次改写带"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. 跑那个）
- ❌ 列脚本路径、依赖名、目录约定
- ❌ 任何带 ✅ / ❌ / 进度条样式的"安装结果"
而是用自然对话语气说一段话，结构包含：
- 一句简短自我介绍：你能帮用户做什么（避开"提取 DNA""签名短语"这种术语，用"分析你的写作风格"这类人话）
- 直接问用户想做哪件事：不要问"你要提取还是改写"，问"你想先做哪件事"
- 告诉用户怎么开始：把文章/草稿拖进对话框、或者粘贴出来
参考示例（不要逐字照抄，按当前用户语境改写）：
你好。我是用来帮你"守住自己写作味道"的——能从你过去的文章里提一份只属于你的"写作 DNA"，下次让 AI 写东西就能按你的味道来。
用法是两步：
- 第一步（必做、一次性）：先把 5-12 篇你过去写过的东西丢进来，我先帮你提一份"写作 DNA"。这是基础——没有它就没法做风格化改写。
- 第二步（之后每次用）：有了 DNA 之后，每次拿到 AI 草稿，直接粘过来，我会按你的 DNA 改写。
第一次用的话，先把过往文章丢进来吧。.docx / .md / .txt 都能拖进对话框，也可以直接粘贴文字、用 --- 隔开多篇。
（如果你之前已经做过 DNA 分析、手上有 <用户名>-dna.json 文件，告诉我一声，我会跳过第一步直接进改写。）
关键逻辑：流程 B（改写 AI 草稿）必须有现成 DNA 文件才能进入。 用户首次使用、还没跑过流程 A 时，即使他粘了一段 AI 草稿过来说"改写一下"，你也不能直接改——必须先告诉他："要先做一次风格分析才能改，你能不能丢几篇过去的文章过来？" 不要承诺无法兑现的事。
核心原则：欢迎语是写给写作者看的，不是写给开发者看的。 任何用户首次看到的回复里如果出现了 python、脚本路径、文件树、依赖名——这条欢迎语就是失败的。
场景 B：用户已经在消息里给了实际内容
核心原则：
- 先看本轮对话里的附件、粘贴文本和关键词，再决定是提取 DNA 还是改写草稿
- 能直接判断就直接进入对应流程，不把"你要提取还是改写"作为默认问题
- 信息不足时只问一个必要问题
- 执行过程中的脚本和路径由模型处理；只有排查、复现或用户主动要求时才展开命令
- 必须在模板剥离确认、DNA 确认和改写效果确认三个节点停下等用户判断
意图判断规则
| 用户消息特征 | 判定 | 直接进入 |
|---|
| 上传了文件 + 提到"风格/指纹/提取/分析/DNA/我的写作习惯" | 提取 DNA | 流程 A（跳过确认，直接说"我先提取 DNA，流程是..."） |
| 给了一段文字 + 提到"去 AI 味/改写/不像我/用我的风格/太 AI 了" | 改写草稿 | 流程 B（先确认 DNA 文件是否存在） |
| 用户只说了模糊的话（如"帮帮我""试试这个 skill"） | 无法判断 | 回到场景 A 的欢迎语，让用户告诉你想做哪件事 |
简短的流程提示
判定后进入流程 A 或 B 之前，可以用一句话告诉用户接下来会做什么（禁止在这条回复中出现任何 python 命令或脚本路径）：
我先帮你做风格分析（放样本 → 模板剥离 → 提取 DNA → 给你看结果让你确认），整个过程中你只需要确认三次：模板剥留、DNA 画像准不准，以及改写效果像不像你。
然后直接按判定结果进入流程 A 或流程 B，不要再问。
流程 A：DNA 提取（一次性）
输入要求
用户应提供 5-12 篇个人代表作，每篇 ≥ 800 字。具体效果：
| 篇数 | 效果 | 说明 |
|---|
| 1-4（< 1.7万字） | ❌ 不足 | 无法区分单篇特有与跨篇稳定特征 |
| 5（约2万字） | ⚠️ 下限 | 刚好让稳定特征浮现，不确定项偏多 |
| 8（约3.5万字） | ✅ 最佳 | 不确定项收敛，大部分特征确认 |
| 12（约5万字） | ✅ 上限 | 特征基本饱和，再增量边际收益极低 |
以上数值基于实测验证（见 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：确定输入来源——先看对话，再看文件夹
用户触发后，按以下优先级确定输入：
- 用户在本轮对话中直接上传了文件（
.docx/.md/.txt）→ 直接用这些文件，不再问"文件在哪里"
- 用户在本轮对话中粘贴了文字（用
--- 隔开多篇）→ 识别分隔符，拆成多篇
- 用户指定了文件夹路径（如
inputs/raw_docx_articles/）→ 扫描该目录
- 以上都没有 → 告诉用户："直接把文章拖进对话框就行，支持 .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 字相同短语 → 必然是模板套话
输出两份产物：
inputs/template_stripped_markdown/：剥离后的样本（这里的内容才是个人 DNA 的来源）outputs/template_profiles/strip_report.md：剥离了什么、按哪些规则剥的人类可读报告
Step 1.5b：你（AI）做语义层模板识别（Layer 2）
读完 strip_report.md 之后，你必须主动做两件事：
-
文体识别：用户的样本看起来是什么文体？常见类型：学术论文 / 邮件 / 公众号 / 政府报告 / 合同 / 新闻稿 / 博客 / 产品文档 / 小说 / 教程 / 评论 / 散文 / 简历 / 商业计划书……
-
残余模板检测：脚本只能抓字面重复模板。你需要识别 Layer 1 漏掉的"结构相同但内容不同"的语义模板。各文体的典型残余模板：
| 文体 | 典型残余模板 |
|---|
| 学术论文 | "摘要/引言/方法/结果/讨论"段落写法、"前人研究表明..."、"本研究的贡献在于..." |
| 邮件 | "亲爱的 X、收到您的来信..."、"此致敬礼"、客套寒暄段 |
| 公众号 | "今天来聊聊..."、"点赞关注转发"、号召订阅话术 |
| 政府报告 | "为深入贯彻..."、"指标主要考核 + 满分 + 得分率" 句式、"现将... 报告如下" |
| 新闻稿 | "据悉/记者获悉"、5W1H 开头模式、"对此，X 表示" |
| 合同 | "甲方/乙方"称谓、"特此协议"、"未尽事宜" |
| 小说 | 第一/三人称固定开场、章节回目套语 |
| 教程 | "本文将介绍/学完本文你将"、"步骤 1/2/3" 套话 |
你必须用样本本身的内容去判断，不是用上表的字面值去匹配。上表只是提示你"哪类残余模板要找"。
Step 1.5c：把识别到的残余模板展示给用户、等待确认（Layer 3）
用对话方式把判断结果展示给用户，让用户拍板。模板：
看你的样本，我猜是 [X 文体]。
脚本（Layer 1）已经剥离了字面重复的内容（详见 outputs/template_profiles/strip_report.md）。
剩下的样本里，我还观察到几处看起来是 X 文体的格式要求、不是你的个人风格：
- "[具体短语/句式模式]" — 比如某篇里写了 "[原文片段]" — 这种结构在 N/M 篇里都有
- "[功能段落模式]" — 每篇都有讲 "[功能]" 的段落，但内容不同
- ...（最多 4 条，不要事无巨细）
这些是文体要求还是你的写作习惯？要从 DNA 提取里剥掉吗？
用户回答后：
| 用户说 | 你做 |
|---|
| "是文体要求，剥" | 从 inputs/template_stripped_markdown/ 里手动删除这些段落（直接编辑文件） |
| "是我的风格，留" | 保留 |
| "[某条]剥，[某条]留" | 按用户指示分别处理 |
| "我看不出来，你来定" | 不要替用户决定。说"那我先按现状继续，提取出来你再校"，进入 Step 2 |
只有等用户确认完，才能进入 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 后，你必须：
-
用图片语法贴一次（且仅一次）特征云 PNG：
- 同时用文字告诉用户完整路径："特征云已保存到
<完整路径>，可以直接打开看"
- 如果对话框无法渲染图片，明确告诉用户去哪个目录找这个 PNG
- 不要重复贴：全场只展示一次。如果用户主动要求重看，再贴一次；默认情况下展示一次就够了
- 不要把横向条形统计图当作 DNA 确认图交付：正式确认优先展示
<用户名>-dna_feature_cloud.png。如果当前流程只生成了 <用户名>-dna_hotwords.png，它也必须是词云/特征云视觉，不能是横向 bar chart；看到旧版条形图时应重新运行新版 extract_dna.py 或改用 render_dna_feature_cloud.py。
-
基于实际 DNA 数据，主动向用户提 3-5 个具体问题（替代旧版"甩静态检查清单让用户自己对照"的做法）
问题必须满足以下规则：
- 每个问题都引用 DNA JSON 里的具体内容：举出实际短语、实际句长数字、实际开头片段；不要泛泛而谈
- 必须包含至少一个"区分文体要求 vs 个人风格"的问题——尤其当用户样本可能是某种特定文体（政府报告、合同、新闻稿、学术论文、产品文档等）时
- 不要让 3-5 个问题都围绕同一个 JSON 字段
- 问完后必须停下等用户回答，不要自己替用户做判断
参考问题模板（按用户实际 DNA 数据生成具体版本，不要逐字照抄）：
- 你的样本里"<具体词或短语，从 signature_phrases 取>"出现了 N 次——是你的常用表达，还是项目类型/文体要求？
- 你的开头大多是"<具体描述，引用 openers 中的实际值>"——这种起手是你的写作习惯，还是某种文体的规范要求？
- 你的样本平均 字一句、短句占 %——这个节奏感对吗？
- 黑名单里的"<具体词1>""<具体词2>"——你是真的从来不用这些，还是只是这批样本里没出现？
- 看你的文章经常用"<具体句式，引用一段原文片段>"——这是你刻意的风格，还是文体格式逼出来的？
-
明确告诉用户：现在需要你回答上面这几个问题，我会根据你的回答修正 DNA。
-
停下来等待用户回复后才能继续。不允许在用户回答前进入 Step 4。
用户可能的反应 → 你的应对
| 用户说 | 你做什么 |
|---|
| "都对，继续" | 进入 Step 4 保存 DNA |
| "X 不是我的风格，是文体格式要求的" | 把对应的 signature_phrase / rewrite_rule 标记为"文体要求"，从 DNA 主体中移除或降权（移到 _meta.format_artifacts 字段下作为参考），重新生成画像 |
| "签名短语有几个不对" | 让用户指出哪几个，从 signature_phrases 删除或替换，保存修正版 |
| "句长不太对" | 让用户说大概多少字一句，手动调整 sentence_features 后保存 |
| "整体都不太像" | 先别急着重提取，让用户跑样本充足性测试：
bash<br/>python scripts/test_sample_sufficiency.py<br/>
根据测试结果决定是补样本还是换模型 |
核心原则
- 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 版，之前的都留着了。以后想退回，跟我说一声"用回上一版"；想看两版改了啥，说"跟上一版比比"。
识别这些对话触发（用户不必记命令）：
| 用户说 | 你做 |
|---|
| 「用回上一版 / 换回原来的 / 退回第 N 版」 | rollback(profiles_dir, 用户名, n) 回滚指针，确认"已回到第 N 版" |
| 「跟上一版比比 / 这版改了啥」 | diff_versions(...) 给出两版差异 |
| 「有几个版本 / 看看历史」 | list_versions(...) 列出版本 |
护栏：快照一律 <用户名>-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 字以上、含多个二级标题/章节，或用户明确说"整篇报告/长文"）按章节或标题块切分，先主动告诉用户："这篇较长，我按章节改，改完统一术语和数字。" 分段只是逐块改写，不得重排章节顺序、不得擅自重组结构。
每个段落或章节块独立改写后，必须合并做一次一致性回查：
- 术语前后是否一致
- 事实数字、产品名、引用对象是否一致
- 标题层级是否保持原结构
- 跨章节指代是否接得上
- 整体语气和节奏是否像同一个人写的
改写时严格遵循以下规则——
改写规则（按优先级；多目标冲突时，序号靠前者优先）
- 信息无损：原文每个事实点、数字、产品名、推荐结论必须保留。改写前先在心里列一遍信息清单，改完核对一遍。
- 黑名单硬清除：DNA 中
blacklist_phrases 里的词组一个都不能出现在输出里。
- 签名短语自然植入：在合适的转折、强调、收尾处使用
signature_phrases。不要硬塞——一段塞 3 个签名短语反而像演员模仿。每 150-200 字植入 1 个为宜。
- 句长结构对齐：按
sentence_features.avg_length_chars 调整句长。若用户偏好短句（占比 > 0.5），不允许出现超过 50 字的长句。
- 开头/结尾换骨：第一段重写开头，套用
openers 中的一种模式；最后一段套用 closers 中的一种。
- 段落节奏：按
paragraph_lines_avg 调段落长度。如果用户习惯 1-2 行一段，就不要写 5 行的大段。
- 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：⏸️ 必须停下，等用户确认效果满不满意
这一步绝对不能跳过，也绝对不能替用户判断"改好了"。
生成完对比报告后，你必须：
- 把
report.md（对比报告）的关键结论展示给用户——重点展示：AI味分数变化、套话清除了哪些、签名短语命中了哪些
- 同时告诉用户完整路径："完整对比报告已保存到
outputs/rewrite_runs/report.md"
- 同时展示
rewrite_validation.md 的关键指标：句长偏差、签名表达命中、黑名单残留、开头模式匹配；告诉用户路径 outputs/rewrite_runs/rewrite_validation.md
- 如果报告或调试信息显示有规则被跳过、降权、未命中，必须补一句："有 N 条规则这次没应用（样本不稳 / 会伤信息），想知道哪几条说一声。" 用户追问"哪几条没应用 / 为什么没应用"时，列出具体规则和原因。
- 把改写后的全文（
rewritten_draft.md）展示给用户——让用户通读
- 同时告诉用户完整路径："改写后全文已保存到
outputs/rewrite_runs/rewritten_draft.md"
- 明确告诉用户：现在需要你检查以下 4 项
- 停下来等待用户回复后才能交付
用户检查清单（逐项过）
| # | 检查项 | 怎么看 | 不对劲怎么办 |
|---|
| 1 | AI 味消了吗？ | 读一遍还有没有"赋能/重塑/综上所述/首先其次"这类味道？ | 指出残留的句子 → 模型针对性重写 |
| 2 | 像我自己写的吗？ | 签名表达是自然命中还是硬凑？句长/段落节奏对吗？有没有像演员模仿的痕迹？ | 指出不像的地方 → 参考验证报告调整 DNA 或定点重写 |
| 3 | 信息丢了吗？ | 原文的事实、数字、结论都在吗？有没有被改写时遗漏或歪曲？ | 指出丢失的信息 → 补回 |
| 4 | 可以直接用吗？ | 整体读下来能不能直接发布/提交？还是还需要你自己再改一轮？ | "还需要微调" → 让用户指出具体段落 → 定点修改 |
用户可能的反应 → 你的应对
| 用户说 | 你做什么 |
|---|
| "满意，交付" | 进入 Step 5 输出最终文件 |
| "这几段还不像" | 让用户指出具体段落 → 针对性重写那几段 |
| "AI味没去干净" | 检查黑名单是否有遗漏 → 补充后重跑 |
| "整体都不对" | 先别急着反复改写，排查顺序：
① DNA 准不准？（回看特征云+签名短语）
② 样本够不够？（python scripts/test_sample_sufficiency.py）
③ 换个模型试试 |
核心原则：改写效果只有用户本人能确认。你不能说"改得不错了"——必须等用户自己说满意。
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 不是万能改写工具。以下情况无法处理或效果有限，遇到时必须主动告知用户：
不能做的事
| 限制 | 原因 |
|---|
| 不能跨标题改写全文结构 | 当前改写以段落/标题段为单元，不会移动或重组原文的章节顺序。如果你需要"把第三章提到第一章前面"，请人工调整后再改写 |
| 不能还原原始 DOCX 排版 | 输入 DOCX 转为 MD 时会丢失字体、字号、页边距等格式信息。最终交付的 DOCX 使用的是默认中文排版（黑体标题+仿宋正文），与原始排版不一定一致 |
| 不能保证 100% 的标题层级识别准确度 | 如果原文未使用 WPS/Word 的大纲样式（即标题是手动调字体做出来的），标题识别依赖文本特征推断，存在少量误判可能 |
| 不能处理图片、图表、附件 | 这些内容在文本清洗阶段已被移除，改写和交付时均不包含 |
适合的场景
- ✅ 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 味测试样本
