de-ai-voice

v1.0.0

去除中文/英文/日文文本的“AI味”,以信息传递为核心先补齐事实/证据/取舍/边界,再按场景重写并清理模板化口癖与格式指纹;适用于文案、邮件、报告、PRD、社媒内容与学术写作的去AI味改写,以及识别并拦截假证据句式与虚构参考文献。

0· 38·0 current·0 all-time
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
The skill declares an editorial/rewriting purpose and ships only reference docs and a local Node-based scanner script (ai_smell_scan.cjs) to identify style fingerprints; nothing requested (no env vars, no credentials) is disproportionate to that purpose. One minor mismatch: SKILL.md shows running `node scripts/ai_smell_scan.cjs`, but the registry metadata does not list Node as a required binary.
Instruction Scope
Runtime instructions stay within scope: ask the user clarifying questions, run the local scanner optionally, perform rewrite passes and hallucination gating. The instructions do not direct reading unrelated system paths, accessing credentials, or contacting external endpoints. They do assume reading the user's text files (via the optional scanner) which is appropriate for the stated task.
Install Mechanism
No install spec (instruction-only) — low risk. The included scanner is a local Node script (no external downloads). Note: running the script requires Node on PATH; the skill does not declare this binary dependency in the metadata.
Credentials
The skill requests no environment variables, credentials, or config paths. The code reads input text (stdin or a provided file) and optionally appends to a logfile if the user supplies --logfile; there are no secrets or unrelated credential accesses.
Persistence & Privilege
always is false and the skill does not request persistent system presence or modify other skills. The only write capability is the scanner's optional logfile append (triggered by an explicit --logfile argument), which is reasonable and local.
Assessment
Functionally coherent: it is an on-device/editorial skill with a helpful heuristic scanner and explicit anti-hallucination guidance. Before using it: 1) Note the source is 'unknown' and there is no homepage—review the files yourself if provenance matters. 2) Ensure you have Node if you want to run the optional scanner; the skill metadata doesn't declare that dependency. 3) The scanner can write a logfile only if you pass --logfile; avoid supplying unexpected paths or run it in a sandbox if you prefer. 4) The skill enforces a Hallucination Gate and explicitly forbids fabricating citations, but you (or the agent) should still verify sensitive claims and never provide secrets to it. Overall it appears safe and proportional for the described rewriting task.

Like a lobster shell, security has layers — review code before you run it.

latestvk97e2j4qdf6a5rqwz43yqv59wh85at4d
38downloads
0stars
1versions
Updated 20h ago
v1.0.0
MIT-0

De Ai Voice

Overview

从内容本质出发:写作不是文字拼接,而是信息传递与决策支持。 “AI 味”很多时候不是词汇问题,而是信息密度不足、证据不可核验、取舍与边界缺失所带来的工业化痕迹。 因此本 Skill 的默认优先级是:信息与证据 > 结构推进 > 场景适配 > 去指纹(口癖/格式)。

Quick Start

  • 输入:用户提供原文 + 目标(用途/受众/平台/语气/篇幅/禁忌)。
  • 输出:改写稿 + 改动说明 + 需要作者补充的问题(若信息不足)。

可选:先跑一次扫描脚本快速定位“AI 味触发器”。

node scripts/ai_smell_scan.cjs --lang auto /path/to/text.txt

重要:ai_smell_scan.cjs 的定位是“AI 味 linter(风格与模板痕迹扫描)”,不是“AI 检测器”。它只能提示哪里更像模板/口癖/格式工具箱,不能证明文本是否由 AI 生成,也不能替代事实核验与引用验真。

Workflow

1) Intake: 先补齐写作约束

先问最少但关键的问题,避免在不知道目的时硬改“文风”:

  • 用途与场景:发给谁/发在哪/读者期望是什么(邮件、PRD、帖子、论文摘要、客服话术等)
  • 作者立场:要不要“站队/做判断/给建议”,还是必须保持中立
  • 信息来源:是否允许引用数据/案例/链接;能否提供真实材料(日期、地点、数字、截图、对话)
  • 风格边界:口语/正式、严肃/轻松、是否允许自嘲/吐槽、是否能用第一人称
  • 不能改的:专有名词、产品/接口名、法律表述、对外承诺

如果用户只说“帮我去 AI 味”,默认只追问两件事:场景/用途 + 受众。 其余信息不足(事实、证据、取舍、边界)由 Information Gate 在需要时再追问,不把“卡点”前置成入门门槛。

1.5) Scenario Selection: 媒介/场景快速选择表(改写前必须确认)

让用户先选一个最接近的场景;如果用户不选,默认 内部协作/文档。场景会决定允许的温度、结构和“去味阈值”(比如社媒允许更强情绪,但不允许空泛金句)。

  • 内部协作/文档(IM、PRD、周报、设计说明):少套话,多约束与决策;强调“下一步/owner/时间点”
  • 邮件/对外沟通:更克制的情绪,更明确的诉求与边界;结尾用“需要对方做什么/何时回复”
  • 社媒内容(公众号/小红书/短视频口播稿):允许更口语与节奏,但必须有具体细节与真实体验;避免模板金句与堆叠排比
  • 对外 PR/公告/新闻稿:措辞严谨,避免夸张;所有数据与“研究表明”必须可核验
  • 学术/研究/论文摘要:允许术语但必须可追溯;杜绝虚构引用;逻辑链条优先于“通顺好读”
  • 客服/支持/FAQ:减少情绪按摩;强调步骤、条件、错误处理、风险提示
  • 投诉处理/危机沟通:先承认问题与影响,再给补救方案与时点;避免空泛安慰与过度承诺
  • 商务合作/BD/报价:目标导向、信息密度高;给清楚范围/交付/里程碑/风险;避免“愿景大词”
  • 招聘 JD/岗位介绍:具体职责/边界/成功标准/协作关系;避免“激情叙事”与空洞价值观堆砌
  • 面试反馈/绩效反馈:事实-影响-建议-期待;避免人身评判与“正确废话”
  • 会议纪要/行动项:以决定与行动为主;明确 owner、截止时间、依赖与待确认事项
  • 方案/汇报/商业计划:先给结论与关键假设,再给证据与对比;必须有取舍与反例边界
  • 产品更新日志/Release Notes:短句直给;按用户影响组织;避免“全面升级/重磅焕新”式夸张
  • 教程/操作指南:以可复现为第一原则;写清前置条件、步骤、预期结果与排错;杜绝“显而易见”
  • 对外公关回应/声明:措辞审慎、可核验;避免推测与情绪化;保留法律/合规边界
  • 投资人材料/融资摘要:数据与口径优先;少形容词;明确增长驱动、风险、下一步里程碑

1.6) Source Model/Tool (Optional): 来源模型/平台快速选择(可跳过)

如果用户知道原文主要来自哪个模型/产品,先标注;不知道就跳过。目的不是“检测”,而是更快去掉平台模板指纹。

  • Claude(claude.ai/Claude Code):更容易残留 Markdown 结构(标题/列表/粗体);倾向“把内容组织得很规整”
  • Gemini:更容易出现“格式工具箱”式输出(小标题/分隔线/列表/结尾给下一步)
  • Kimi:更容易受“官方常用语/排版模板”影响(emoji/Unicode 美文排版、结构化小条目)
  • DeepSeek(深度思考模式):可能有开头语气词(如“嗯”)作为节奏缓冲
  • 豆包:在部分对话场景里可能有更强的情绪肯定与夸赞话术
  • 其他/未知:按通用规则处理即可

2) Diagnose: 判定“AI 味”是润色问题还是信息问题

将问题归类(可多选),并给出证据(用原文片段,而不是空泛判断):

  • 模板结构:三段论/教科书式“首先其次最后”、段段都在总结
  • 套话与连接词堆叠:值得注意的是/此外/总而言之 等密集出现
  • 过度工整与平滑:句式太齐、语气太稳、没有作者脾气与偏好
  • 空泛正确:名词很大、动词很虚、缺少可验证细节(人/事/数/时间/地点/机制)
  • 过度中立:每个观点都“两边都对”,不下判断也不做取舍
  • 过度礼貌/过度共情:用力过猛的“稳稳接住你/希望能帮助你”
  • 格式指纹:乱加粗、全篇列表化、段落像 PPT;高频“核心/关键/本质”但缺根据

references/signs-of-ai-writing.md 做快速对照(不要凭感觉打标签):

  • 过度总结 / 反复收尾(段尾反复“总之/Overall”)
  • 连接词与路标堆叠(段首“此外/Moreover/Firstly…”)
  • 三件套/三段论成瘾(硬凑 3 点且可互换)
  • 英文 -ing“伪分析”或中文“大词空转”(听起来像分析但没机制)
  • 过度修辞但信息不增(排比/比喻密集)
  • 格式工具箱痕迹(标题/分隔线/列表/粗体密度过高)

关键分流:

  • 若信息不足是主因:先输出“需要补充的信息清单”,等作者补齐后再进入改写。
  • 若信息足够但表达像 AI:进入改写流程。

2.5) Information Gate: 信息传递闸门(默认强制)

在动笔改写前,先把原文“信息结构”显式化,避免把低信息密度文本越润越像模板:

  • 信息库存(从原文抽取,不编造):
    • 事实:具体人/事/数/时间/地点/机制/限制条件
    • 结论:作者希望读者相信什么、做什么
    • 证据:数据/案例/来源/可复现步骤
    • 取舍:你选择了什么,放弃了什么,代价是什么
    • 边界:什么时候不成立/不适用/反例
  • 信息缺口(必须输出到“三件套”的第 3 部分):
    • 缺来源/缺口径/缺例子/缺约束/缺边界

如果信息库存过薄:优先追问补信息,而不是做同义替换或“去指纹”。

3) Rewrite Pass 1: 先修内容密度与推进

优先做“信息与结构”层面的改写,避免只换同义词:

  • 把“大词”落到可观察对象:谁做什么、怎么做、为什么这么做、代价是什么
  • 把“结论”绑定证据:数字/案例/对比/约束条件/反例
  • 删掉重复的铺垫与复述:同一观点不要用 3 种句式再说一遍
  • 让文章真的“往前走”:每段新增一个信息点或推进一个判断

3.5) Safety Checks: 假证据句式 + 过度安全中立(默认强制)

这两项是高频“AI 味”来源,且会引入内容风险;无论中文/英文/日文都要检查。

  • 假证据句式(必须处理):
    • 典型信号:研究表明/数据显示/大量实践证明/权威机构认为(但没有机构、时间、口径、链接或数据出处)
    • 处理策略:优先向作者要来源;拿不到就降级为“经验判断/观察”,并明确条件与不确定性;不要编造引用
  • 过度安全中立(必须处理):
    • 典型信号:整段都在“利弊都有/因情况而异”,但没有结论、取舍和边界
    • 处理策略:给出一个清晰选择(或默认建议)+ 适用边界(什么时候不适用/反例)+ 代价(你愿意换什么)

4) Rewrite Pass 2: 再修语气、节奏、作者指纹

  • 句长交错:短句收尾,长句承载解释;避免“每句 20 字/每句 15 词”的齐步走
  • 自然连接:减少“此外/Moreover/さらに”式硬连接,改为语义连接(因果、转折、递进)
  • 增加人类可识别的取舍:我倾向于…因为…但在…情况下会反过来
  • 允许适度不完美:合规前提下,保留一点口头语/顿挫/偏好词(但别装)

4.5) De-Fingerprint Pass: 自动规避高频 AI 味(默认强制)

这一步不是“润色”,而是清理高频可识别指纹。除非用户明确要求保留某种风格,否则默认执行。 优先按 references/signs-of-ai-writing.md 的“迹象→动作”映射处理,而不是仅凭词表替换。

  • 过度帮助式收尾:删除/改写 希望对你有帮助/如有需要我可以继续/如果你愿意我也可以…
    • 替代:用“下一步/行动项/需要你确认的点”收尾
  • 过度共情/客服腔:删除/降噪 我懂你/辛苦了/你太不容易了/我稳稳地接住你
    • 替代:用“事实复述 + 目标确认 + 解决路径”承接
  • 模板路标:降低 首先/其次/最后In conclusion/Overallまず/次に/最後に 的密度
    • 替代:用段落语义推进,不靠路标推进
  • 格式指纹:
    • 乱加粗:每个段落最多保留 0-2 处强调;全文尽量不超过 3-6 处(按篇幅调整)
    • 列表成瘾:列表只用于并列项;理由/背景/判断必须用段落写出来;单个列表尽量不超过 5 条
    • PPT 化:合并碎片段落,保证每段承担完整语义(主张/证据/条件之一)
  • “关键/核心/本质”滥用:没有“为什么关键 + 依据/代价”就删;有就补足再保留
  • 多余的“礼貌前缀”:如 当然/很高兴/我将从以下几点,在不需要的场景直接删

按来源平台做额外清理(若用户在 1.6 标注了来源):

  • Claude:把“标题+列表+粗体”改为段落叙述(除非场景真的需要清单);删除复制粘贴产生的 Markdown 符号
  • Gemini:减少“工具箱式格式”(过多小标题/分隔线/列表);避免固定“下一步我还能帮你…”式结尾,改为行动项/待确认点
  • Kimi:去掉 emoji/Unicode 装饰性排版(花字、符号项目符号、夸张标题行),把碎片化小条目合并为段落
  • DeepSeek:删除开头的“嗯/好的/让我想想”等缓冲词,直接进入任务动作
  • 豆包:删除“你真的很棒/你太不容易了/你说得太对了”式夸赞与情绪镜像,保留事实复述与可执行建议

可选:在这一步前后跑 node scripts/ai_smell_scan.cjs --lang auto,把它当“热力图”用:看哪些模板痕迹密集,然后逐项清理。结构化体裁(PRD/FAQ/汇报)会天然触发部分规则,需结合场景判断是否属于误报。

5) Verification: 不要为了“去味”而引入新风险

  • 不编造引用/研究/数据/出处;缺来源就明确“无法确认/需要补充链接或原始材料”
  • 不改动专有名词、接口名、合同/法律措辞(除非用户明确授权)
  • 不把“更像人”做成“更不准确”;信息优先级高于风格

Hallucination Gate(默认启用)

在交付前做一次“幻觉闸门”检查,重点拦截“语法正确但不真实/不可核验”的句子,尤其是虚构参考文献与假证据句式。执行规则:

  1. 发现强引用、强数字、强结论但无出处:先把它们转成“待补证据问题”,向作者索要链接/DOI/截图/原文片段/数据口径。
  2. 若作者无法提供证据:删除虚构引用,把结论降级为经验判断,并补“前提条件 + 边界 + 反例/失败模式”。
  3. 操作类内容必须可复现:每步补齐“输入→操作→预期输出→常见错误与排查”。

详细触发条件与处理策略见 references/principles.md,引用验真流程见 references/citation-verification.md

Language Packs (Read As Needed)

  • 中文:读 references/zh.md
  • English: read references/en.md
  • 日本語:references/ja.md
  • “AI 味”根因与校准范式:references/principles.md
  • Wikipedia/社区归纳的“AI 写作迹象”映射:references/signs-of-ai-writing.md
  • 参考文献验真(幽灵引用):references/citation-verification.md

Output Contract

默认按以下结构交付(除非用户指定只要其中一部分):

  1. 改写稿(目标语言)
  2. 改动说明(3-8 条,面向作者:删了什么、补了什么、为什么)
  3. 待补信息问题(若存在信息不足;问题要具体、可回答、可验证)

Model/Platform Fingerprints (Optional)

不同大模型与产品形态(system prompt / UI 默认)会带来不同“口癖/格式指纹”。需要做更针对性的去味时,读 references/model-tells.md

Comments

Loading comments...