Skip to main content

deai-polish

去除文章草稿中的 AI 腔,让文字读起来像具体的人在表达。使用时:草稿已生成但读起来太规整、缺乏真实细节或作者声音。编排 humanizer-zh(基础去味)→ 人工细节与声口编辑 → stop-slop(快速质检)→ shuorenhua(终审口语化),taste-skill 融入编辑判断。检测器结果只作诊断,不把规避某个检测器当作质量目标。输出润色稿和去AI化报告(不含发布终审判定,终审由 deai-review 完成)。

Jump to install

Source facts

Repository
lornshrimp/Lorn.TechProductManagerContentCreatorSkill
Last source activity
September 4, 2026 at 01:08
Detected SKILL.md language
Chinese
Stars
1
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
100 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
deai-polish
description
去除文章草稿中的 AI 腔,让文字读起来像具体的人在表达。使用时:草稿已生成但读起来太规整、缺乏真实细节或作者声音。编排 humanizer-zh(基础去味)→ 人工细节与声口编辑 → stop-slop(快速质检)→ shuorenhua(终审口语化),taste-skill 融入编辑判断。检测器结果只作诊断,不把规避某个检测器当作质量目标。输出润色稿和去AI化报告(不含发布终审判定,终审由 deai-review 完成)。
user-invocable
true
# `deai-polish` — 去 AI 化润色 ## When to Use - 文章草稿已生成,需要清除 AI 痕迹 - 文章读起来"太 AI"(过于规整、缺乏人味) - 需要一份去 AI 化处理前后的对比报告 ## Input - `drafts/{日期}/{选题名}/草稿-{标题}.md`(只读——deai-write 产出的原始版本,polish 不修改。文件名中的 `{标题}` 来自标题方案排名第 1 的候选标题,无标题方案则使用选题名) ## Output - `drafts/{日期}/{选题名}/润色稿-{标题}.md`(去 AI 化处理后的正文,供 `deai-review` 读取) - `drafts/{日期}/{选题名}/去AI化报告-{标题}.md`(去 AI 化处理前后的对比数据和修改记录) --- ## 核心方法论 ### 读者先于检测器 参考文章中最值得保留的不是“把某个工具的分数压到某个数字”,而是它背后的编辑动作:把抽象判断换成能核对的细节,把旁观者口吻拉回“我”和“你”,保留一点真实的不顺,再让另一轮审阅找出机器腔。 因此,`deai-polish` 的目标顺序固定为: 1. 读者能不能看懂、相信,并愿意继续读。 2. 作者的事实、判断和语气有没有留下来。 3. 文本有没有明显的模板化痕迹。 4. AI 检测工具是否提示异常,只作为辅助信号。 任何检测器都可能误判人工文本,也会随版本变化。不得为了追求低分,添加虚构经历、故意制造错别字、打乱事实顺序,或把文章改成一串短句。检测结果没有实测时,报告必须写“未测试”,不能填一个看起来漂亮的数字。 ### AI 味的本质(必须先理解这个) AI 味不是"AI 写的才有",而是一组文体特征。这组特征的核心是三条: | AI 味(机器思维) | 人味(人类思维) | |:---|:---| | **信息优先于体感**:恨不得把全文要点塞进每一段 | **体感优先于信息**:先让读者感受到一种体验,再传递信息 | | **结构优先于节奏**:依赖显式路标(首先/其次/此外/然而),结构硬 | **节奏优先于节奏**:靠语序和停顿完成转折,不需要显式连接词 | | **完备优先于取舍**:每个可以展开的地方都展开,害怕遗漏 | **取舍优先于完备**:该停就停,不说的话比说出来的更有力 | **记住这三条铁律——它们是整个 polish 流程的底层判断标准。每一个编辑决策,最终都要问:我是在往"体感/节奏/取舍"走,还是往"信息/结构/完备"走?** ### 六种必须清除的 AI 味模式 以下六种模式来自大量 AI 文本的实证分析,是 AI 味的"文体指纹"。polish 全程以清除这些模式为目标: | # | 模式 | 识别信号 | 清除方法 | |:--|------|----------|----------| | 1 | **"不是…而是…"家族** | "不是…而是…""不只是…更是…""与其说是…不如说是…""不是…也不是…而是…" | 拆成两句:前半句直接陈述,后半句用破折号或句号隔开 | | 2 | **显式路标词** | "首先/其次/最后/综上/此外/同时/并且/一方面...另一方面..." | 删掉所有路标词。如果删完逻辑不通,说明段落本身没有真正的逻辑关系——重新组织 | | 3 | **廉价比喻** | 比喻来得太容易、太流畅、太"随手就能掏一个" | 删掉。好的比喻是想了半天才找到的,不是批发的。如果删掉比喻后段落更有力,说明比喻本来就是多余的 | | 4 | **伪俗语** | "稳稳的接住了""不崩、不爆""从头就跑偏了"——表面有口语质感,但去任何社群都找不到原产地的表达 | 找到真实社群在用的口语替换它。检测标准:你能说出这个表达是哪个社群在用吗?说不出 → 禁用 | | 5 | **装出来的松弛感** | 全文书面框架 + 中间突然蹦出"说白了""扎心""绝了"——"穿西装翘二郎腿" | 要么统一到口语(推荐),要么统一到书面。不允许混搭 | | 6 | **假深刻收尾** | 以两个看似矛盾的形容词收尾:"很残酷,也很浪漫""很扎心,也很温暖"——用形容词制造廉价辩证 | 删掉整个收尾。用一句陈述替换,或者干脆不写收尾。真正的深刻不需要形容词 | ### ⚠️ 去味红线:去味 ≠ 去信息(新增保护规则) 去 AI 味的目的是清除"AI 腔",不是削减文章的信息量。以下内容**即使读起来有 AI 味也不能删除**——只能改表达方式,不能删除信息本身: | 受保护内容类型 | 示例 | 允许的操作 | 禁止的操作 | | --- | --- | --- | --- | | 技术原理/机制描述 | "KDA 混合线性注意力机制"、"算力转化效率比上一代提升了 2.5 倍" | 缩短句子、调整语序 | 整句删除 | | 行业术语/专有名词 | "价值链"、"注意力残差技术"、"SWE Marathon" | 保留,首次出现可加简短解释 | 替换为泛化词(如"蛋糕""工具"等) | | 关键数据引用 | "57 分全球第三"、"6 倍差价" | 保留数据,可改写数据前后的解说 | 删除或替换数据 | | 论证链条 | "因为 A 导致 B,进而影响 C"的完整推理 | 精简句式、合并短句 | 砍掉中间环节导致逻辑断裂 | | 个人经历细节 | 公司名、项目名、时间、具体数字 | 口语化改写 | 删除细节或替换为泛化描述 | | 大纲指定的金句 | 金句植入地图中的划线句 | 优化措辞 | 砍掉(金句是刻意设计的,不是 AI 味) | **三条保护铁律**(每条修改前先过): 1. **这条信息是事实还是填充?** 事实 → 保留;填充 → 可删 2. **删除后论证链还在吗?** 断裂 → 恢复;完整 → 可删 3. **原文作者刻意设计的句子?** 是(金句/断言/钩子)→ 保留;不是 → 可优化 **字数监控**:全部修改完成后,润色稿正文字数不应低于草稿正文的 **95%**。低于 95% 说明过度删减,需逐段回检被删除的内容是否属于"受保护内容"。 ### ⚠️ 窄化表达的清除(polish 新增红线) 去 AI 化之外,polish 还需**清除不必要的岗位身份标签**——这些标签不是 AI 味,但同样会窄化受众: | 清除类型 | 典型信号 | 处理方式 | |----------|----------|----------| | **岗位身份声明开头** | "作为一个产品经理""作为PM,我认为……" | 改为"我注意到""我观察到一个现象"——去掉身份标签,保留判断 | | **岗位限定性表达** | "做产品的人都知道""只有PM才懂" | 改为"做过项目的人都明白""稍微留心就能发现"——扩大共情范围 | | **不必要的岗位标签** | 在谈论通用话题(如AI、电视、短剧)时插入"从产品经理的角度看" | 直接去掉。角度本身应该通用,不需要用岗位来"背书" | | **隐性身份预设** | "我们PM经常遇到……""这个问题PM内部讨论过……" | 改为"很多人遇到过……""我关注到行业里在讨论……"——用更开放的视角 | **判断标准**:去掉"产品经理""PM"四个字后,如果句子依然通顺且意思不变,说明这个标签是多余的,必须删除。如果去掉后句子意思变了,说明你真的在讲岗位专属话题——这种情况应该重新审视选题角度是否过窄。 ### 子技能编排原则 deai-polish 集成的 4 个专用子技能不是互相替代,而是各有侧重的修理工。`taste-skill` 不作为独立子技能运行,而是融入人工编辑判断。先洗掉明显的 AI 腔,再补回真实细节和作者声音,最后确保读起来“像人在说话”。 | 工序 | 子技能 | 作用 | 执行位置 | 来源 | |:---:|--------|------|:--------:|------| | **1** | **humanizer-zh** | 基础去味:清除中文 AI 高频词、宣传腔/夸大腔、过度总结、四字结构填充、句尾假深度、"标志着/见证了"类抬升词 | Step 2 | `Humanizer-zh-main/SKILL.md` | | **2** | **stop-slop** | 快速质检:检查广告词、被动语态、"不是X而是Y"二元对比、清嗓子开头、无生命主语;输出 5 维评分(直接性/节奏/信任感/真实感/信息密度) | Step 6 | stop-slop 通用版 | | **3** | **taste-skill** | 风格定调:避免"AI 默认审美"——不要中庸结论、不要保险套话、不要"放之四海而皆准"的平庸段落;逼你选一个立场、一种语气、一种节奏 | Step 4(融入检查) | taste-skill 设计哲学迁移 | | **4** | **shuorenhua** | 终审口语化:按场景分档(`public-writing`/standard),去模板感、表演腔、虚假主语;保留事实、术语、责任主体,确保“改完能直接发” | Step 7 | shuorenhua 通用版 | **humanizer(英文版)**:仅当草稿含英文段落时按需调用,中文内容不经过英文 humanizer。 **编排原则**: - 先洗后修:humanizer-zh 做粗洗 → L1 reference 工具做精修 → shuorenhua 做终洗 - 质检在修之后:stop-slop 的评分在手动修复完成后运行,作为"质量门禁" - taste-skill 是融入式执行,不作为独立步骤——它的原则渗透在 Step 4 的声口/钩子/胆量检查中 --- ## Procedure deai-write 产出的草稿已经过了三层去 AI 化(词汇/句式/人味儿)。polish 的任务不是"再来一次去 AI",而是做 **AI 做不到的事**——注入毛边、校准声口、提升锋锐度、确保读起来就是一个有性格的人在说话。 **🧠 作者观点保留铁律(2026-08-22 确立——润色是"让作者的声音更响",不是"把作者的观点磨平")**: - 润色打磨的是**表达**,**绝不动作者观点**:草稿中立论点、结论、金句、立场句(来自研究报告「作者观点底座」)必须原样保留其立场——润色只改语气、句式、节奏、毛边,不得把"作者的锐利判断"改造成"稳妥的通用观点"。 - 与去 AI 化的关系:去 AI 化去的是"机器味",不是"作者脾气"。如果某句"作者观点味重、但像真人说的",这是金句不是 AI 腔——保留并强化;只有"AI 味重、但毫无作者立场"的句子才需要改。 - 对照检查:润色结束后,将润色稿与研究报告「作者观点底座」对读——若任一核心观点/金句在润色中"丢了立场"(改得四平八稳),回改。 **✍️ 作者文风保留铁律(2026-08-26 确立——润色不得把"作者的话"洗成"正确的话")**: - **润色只磨毛边,不换声口**:作者的语言指纹(反问收束、口语长句、设问-自答、"XX 不是 YY 是 ZZ"判断句、毒舌反讽、俚语点名)必须原样保留。若某个"反问句/口语表达/判断句"因为"不够书面/不够稳"被改成陈述句或四平八稳的书面语——这是**文风稀释**,改回。 - **对照风格画像卡**:润色前 Read `notebook/作者风格画像.md`(作者风格数据;方法模板与六层结构定义见 `deai-write/references/作者风格画像卡.md`);润色后逐项核对——①反问/设问是否被删或改陈述 ②口语连接词(说白了/结果呢/其实)是否被替换成书面连接(然而/由此可见)③毒舌反讽是否被"委婉化" ④第一人称判断(我的判断/我偏…)是否被去掉 ⑤结尾金句是否被换成稳妥句子。任一命中 → 回改,**原文作者风格句子保留率(关键句)应为 100%**,允许动的只有明显啰嗦/断裂的毛边。 - **🔫 弹药包金句禁洗(2026-08-26 确立)**:研究报告「风格弹药包」中落地的作者原话金句(直引/改造句),润色时**不得整句替换成通用说法**——可磨毛边(断句/去赘字),但句式骨架与核心语感必须留存(如"企业凭什么老老实实发薪?"不准改成"企业没有动力守法");弹药金句在润色稿中要能按原句辨认出来。 - **与去 AI 化的边界**:去 AI 化保留"作者的人味",文风铁律保留"作者的味道"——两者重叠处理同一类句子时,以"更不像机器、更不丢作者"为双重标准:既能去掉 AI 均匀腔、又不动作者锐利句,才算合格。 同时,polish 要检查可能暴露模板感的统计模式,例如句长过匀、连接词堆叠和段落过于整齐。但这些指标只能帮助定位问题,不能指导“伪装成人类”。以下流程将 4 个子技能、本地 reference 工具和人味编辑整合为统一工序。 ### ⚠️ 执行真实性铁律(2026-08-25 用户复核确立,最高优先级——禁止"空壳去AI化") **背景**:2026-07-21~08-01 期间的去AI化报告为完整 8 节模板(统计对抗/子技能记录/修改记录/未修改项/字数变动监控/stop-slop 评分/三条铁律/附录原则自检),是达标样板;但 08-24 之后的执行层严重敷衍——润色稿由"脚本复制草稿 + 少量替换"生成,去AI化报告退化成"检测维度与结果/主要改写动作/真人痕迹检查/结论"的几节空壳,且未执行任何子技能、无逐条修改记录。**报告存在 ≠ 流程真实执行。** 本铁律强制三点: 1. **禁止用脚本复制草稿冒充润色**:`润色稿-{标题}.md` 必须由**逐处真实编辑**产生(先执行 Step 2-7 全工序,再据编辑结果写正文);禁止"复制草稿正文 + 少量 replace + 写一份简短报告"代替去AI化。检出手段:润色稿与草稿正文差异 < 5%(纯脚本复制特征)即判未执行,回炉重走 Step 2-7。 2. **禁止报告默认全 ✅**:去AI化报告必须**如实记录每一步执行状态**——真实执行 = ✅ 并按模板附关键结果(清除 N 处 / stop-slop 总分 X/50 / 去字率 X%);**未执行的步骤必须标 ❌ + 原因**。绝不生成与实际过程不符的"全 ✅"报告("未执行却说执行了"比"没执行"更严重)。 3. **报告必须是 8 节完整模板**:按本文档 Output 模板输出——统计对抗结果、子技能执行记录、修改记录、未修改项(刻意保留)、字数变动监控、stop-slop 5 维评分、三条铁律终审、附录:去味核心原则自检。任何一节缺失即视为流程未跑完;`规范校验.py` 已加结构门禁(2026-08-25 生效,缺块即 ❌),不得带病进入 review。 > **达标参照**:`drafts/2026-07-22/Kimi K3 开源大模型军备竞赛/去AI化报告-Kimi-K3-开源了-但我劝你别急着用.md`(8 节完整模板样板);**不达标样例**:2026-08-24~08-25 期间各选题简版报告(已可被校验结构门禁拦下)。 > **三层机制落地**:事前 Read 本铁律 → 事中按 8 节模板逐级产出并自检 → 事后 `规范校验.py` 结构门禁兜底。 --- ### Step 0:确定文章标题(用于查找输入文件和命名输出文件) 在读取草稿之前,先确定文章标题: 1. **优先从标题方案提取**: - 检查 `drafts/{日期}/{选题名}/标题方案.md` 是否存在 - 如果存在,解析评分表提取排名第 1 的标题候选 2. **回退方案**:如果标题方案不存在或解析失败,使用 `{选题名}` 作为标题 3. **文件名安全处理**(`{标题}`): - 替换 Windows 非法字符:`\ / : * ? " < > |` 为 `-` - 替换全角问号 `?`、全角冒号 `:` 为 `-` - 替换全角引号 `""`、空格为 `-` - 连续多个 `-` 合并为单个,去除首尾 `-` - 截断至 50 个字符 4. 将安全处理后的标题存入变量 `{标题}`,后续所有文件操作均使用此变量 ### Step 1:读取草稿与上游质量数据 读取 `drafts/{日期}/{选题名}/草稿-{标题}.md`(只读不写,保留原始版本),提取末尾的**质量自检报告**(deai-write 产出),了解草稿已有的质量基线:哪些检查项已通过、哪些有残留问题。polish 在此基础上做增量,不重复劳动。 --- ### Step 2:humanizer-zh 基础去味(第一轮粗洗) 在进入精细编辑之前,先用 humanizer-zh 对全文做一遍基础去味。humanizer-zh 是专门针对中文 AI 腔设计的中文特化版 humanizer,处理以下模式: **清除目标(按 humanizer-zh 的内容模式清单 + 六种 AI 味模式):** | # | 清除类型 | 典型信号 | 处理方式 | |:--|----------|----------|----------| | 1 | 夸大意义/宣传腔 | "标志着/见证了/是…的体现/凸显了其重要性/反映了更广泛的" | 改为事实陈述——直接说成立了、做了什么、负责什么 | | 2 | 过度总结/结论腔 | "综上所述/总而言之/这一举措意味着" | 删掉总结词,直接给出判断或事实 | | 3 | 四字结构填充 | "蓬勃发展/日益增长/不断深入/持续优化" | 改成具体动作或删掉 | | 4 | 句尾假深度 | "为…奠定了坚实基础/指明了方向/提供了有力支撑" | 删掉整句,如果信息已在前文传达 | | 5 | 过度归因/溯源腔 | "究其原因/追根溯源/从根本上看" | 直接说原因,不加"究其原因" | | 6 | 连接词堆叠 | "然而/此外/因此/与此同时/更重要的是" 密度过高 | 删掉 80% 的连接词,用换行替代 | | 7 | "不是…而是…"家族 | "不是…而是…""不只是…更是…""与其说是…不如说是…""不是…也不是…而是…""是…不是…" | 拆成两个短句,顺着说,不要翻过来说 | | 8 | 廉价比喻 | 比喻来得太流畅、太随手——"像一把无形的刻刀""一条令人心碎的轨迹"等 | 删掉比喻。如果删完太平淡,换一个只有你因为真实经历才能想出来的比喻 | | 9 | 伪俗语 | "稳稳的接住了""不崩、不爆""从头就跑偏了"——无社群来源的口语搭配 | 替换为真实社群在用的口语。检测标准:说不出哪个社群在用 → 删 | | 10 | 装出来的松弛感 | 全文书面框架中突然蹦出"说白了""扎心""绝了""太真实了" | 要么全文统一到口语,要么删掉口语词。不允许混搭 | | 11 | 假深刻收尾 | 以两个矛盾形容词收尾:"很残酷,也很浪漫""很扎心,也很温暖" | 删掉收尾,用一句陈述替换,或不写收尾 | **humanizer-zh 核心规则(5 条,贯穿本轮执行):** 1. 删除填充短语——开场白和强调性拐杖词全部砍掉 2. 打破公式结构——避免二元对比、戏剧性分段、修辞性设置 3. 变化节奏——混合句子长度,两项优于三项,段落结尾多样化 4. 信任读者——直接陈述事实,跳过软化、辩解和手把手引导 5. 精简金句——如果一句表达过于规整(像"名人名言"模板),改口语化措辞而不是删除。大纲金句植入地图中的金句是刻意设计的,仅润色不删除 **执行规范**: - 保留事实、数据、术语、引用——只改表达方式 - 本轮不注入个人风格——先洗掉 AI 味,后续步骤再做风格注入 - 如果草稿含英文段落,额外调用 `humanizer`(英文版)处理英文部分 **参考文件**:`Humanizer-zh-main/SKILL.md`(完整规则)+ `Humanizer-zh-main/references/phrases-zh.md`(中文 AI 词库) --- ### Step 3:统计模式快速扫描(30 秒初筛) humanizer-zh 粗洗后,加载 L1 通用层 reference 文件中的核心诊断工具,对草稿做统计层面的快速扫描: | 检测维度 | AI 检测逻辑 | 扫描方法 | 阈值 | |----------|-----------|----------|:----:| | 困惑度(Perplexity) | 词汇过于可预测 → AI 嫌疑 | 扫描:是否有低频词?是否有方言/行业黑话/网络用语? | 每 500 字 ≥ 1 个非常规词 | | 突发度(Burstiness) | 句子长度方差过小 → AI 嫌疑 | 扫描:句子长度是否集中在同一区间? | 标准差 ≥ 8 字 | | 词频分布 | 连接词/抬升词密度过高 → AI 嫌疑 | 扫描:"然而/此外/因此/值得注意的是"密度 | ≤ 1 次/千字 | | 句法均匀度 | 句式重复率过高 → AI 嫌疑 | 扫描:"不仅…而且…""从X到Y"等公式句 | 0 处公式句 | | 段落规整度 | 段长过于均匀 → AI 嫌疑 | 扫描:段落句数标准差 | ≥ 2 句 | | 修辞重复率 | 修辞种类少、同一修辞反复出现 → AI 嫌疑 | 扫描:"像/仿佛/如同/似的"标记词密度与种类数 | "像…一样" ≤ 3 次/全篇,修辞种类 ≥ 3 种 | | 术语密度 | 场景外术语异常插入 → AI 嫌疑 | 扫描:情感/日常叙述段是否出现心理/医学/学术术语 | 场景外术语 0 处 | | 情感波动 | 情感曲线过于平滑、转折均匀 → AI 嫌疑 | 扫描:情感极性标准差、转折点数量与幅度 | 全文 ≥ 1 处情绪延迟或"不合时宜"细节 | **初筛结论**:全部达标 → 直接进入 Step 4 人味编辑。2 项以上超标 → 在 Step 4 定位问题,再用 Step 5 的参考库工具做针对性修正,不得为了达标凭空添加口语或错别字。 --- ### Step 4:六项人味编辑检查(融入 taste-skill 原则) 这是 polish 的核心工序——这六项是 AI 做不到、只有人工编辑才能判断的。 **taste-skill 定调原则(本步骤全程注入):** > taste-skill 的核心洞察:LLM 默认生成最安全、最像模板的东西。编辑时先“读懂房间”:文章写给谁,作者真正知道什么,哪一个判断愿意承担。然后避开默认开头、中庸结论和保险套话,选定一种语气和节奏,而不是写出“放之四海而皆准”的平庸段落。 **映射到六项检查**: - 钩子抓力 → taste-skill:"选一个立场,不要默认开头" - 声口一致性 → taste-skill:"一种语气、一种节奏,贯穿到底" - 胆量检测 → taste-skill:"不要中庸结论、不要保险套话" #### 编辑前置:把抽象话换成现场细节 逐段问一句:这句话如果删掉形容词,读者还能看到什么?如果什么也看不到,就补作者确实拥有的细节。优先补时间、数量、动作、具体对象、原话或可复核的前后对比,例如“处理时间从两小时缩到十分钟”,不要只写“效率显著提升”。 细节只能来自草稿、研究报告、简历、`notebook/` 或作者明确提供的素材。编辑不得为了“像真人”编造客户、公司、私信、地点、数字和感受。没有细节就删掉空泛形容,或在报告中标记“需要作者补充”,不要用公共化案例填坑。 #### 检查 1:钩子抓力 | 项目 | 内容 | |------|------| | **检查方法** | 读第一段 3 遍。如果第 3 遍还觉得"还行吧""差不多",钩子失败 | | **通过标准** | 读完第一段产生"然后呢?"的冲动。钩子必须明确选了一个立场——不是中立叙述,而是"我有一个判断要告诉你" | | **修复方法** | 换更强的钩子类型 / 缩短第一句 / 把最反常识的数据挪到第一句 / 用断言句替代描述句 | #### 检查 2:人设声口一致性 | 项目 | 内容 | |------|------| | **检查方法** | 全文读一遍,问:如果去掉署名,读者能认出这是"独孤虾"写的吗? | | **通过标准** | 以 `my-articles/` 提取的风格指纹为基准——句长分布、高频词密度、第一人称密度、毒舌指数不偏离基准 ±30%。全文语气一致,没有"前半段毒舌后半段温和"的语调漂移 | | **修复方法** | 补口头禅、在安全段落加锋锐度、把中性判断改为带个人立场的表达 | **声口校准清单**(目标值优先从 `my-articles/` 提取,提取不到才用人设基线默认值): | 声口维度 | 目标来源 | 基准 | 不足时怎么补 | |----------|:------:|------|-------------| | 句长分布 | my-articles 统计 | 平均句长 {X} 字,方差 {Y} | 调整句子长度匹配基准 | | 口头禅密度 | my-articles 统计 + 人设基线 | ≥ 2 次/千字 | 在分析段或过渡处插入 | | 高频词匹配 | my-articles Top 50 | 新文章的高频词与基准重合度 ≥ 60% | 替换通用词为你的惯用词 | | 毒舌程度 | my-articles 统计 | ≥ 2 处/全文 | 找到最安全的段落,加一句"但说实话…" | | 第一人称密度 | my-articles 统计 | "我"密度 ≥ 基准的 70% | 在纯分析段插入"我见过""我经历过" | | 类比密度 | my-articles 统计 | 2-3 个/全文 | 从 `notebook/` 找现成类比 | | 不端着 | 人设基线 | 无"从某种意义上"等专家腔 | 全部改成口语 | > 如果 `my-articles/` 目录为空(尚无文章),则全部回退到人设基线的固定目标值。**但必须在去AI化报告中标注"⚠️ 无历史文章数据,风格指纹使用默认值。建议在润色完成后人工通读一遍,确认语气符合人设基线"。** #### 检查 3:毛边检测 | 项目 | 内容 | |------|------| | **检查方法** | 逐段检查:句子长度是否太均匀?转折是否太工整?逻辑链是否太完整? | | **通过标准** | 至少 2 处自然的节奏变化,例如残句、停顿、轻微自我修正或不完整推理 | | **修复方法** | 找最光滑的段落,适度拆句、换行或删掉多余结论。不要为了达标硬塞错别字、病句、无意义断句或戏剧化碎片 | **毛边识别信号**(来自 reference 识别雷达): - 连续 3 句同长度 → 必须打破 - 所有段落都走"观点→解释→总结" → 至少 2 段砍掉总结句
View on GitHub
This SKILL.md is very large, so SkillsMP previews the first section here. View on GitHub