企业官网建设流程全解析

• AI 技能
• AI 应用

dbs-ai-check 是 dontbesilent 商业工具箱 dbskill 中的 AI 写作特征检测 Skill，它不负责改写文案，而是像质检员一样逐条扫描文案中的 AI 生成痕迹并输出检测报告。本文以 skills/dbs-ai-check/SKILL.md 为骨架，结合仓库主路由 skills/dbs/SKILL.md、新手入门文档 docs/新手入门.md 以及公开推文集 books/dontbesilent-开源推文集.md，完整讲解 22 个 AI 特征指纹、检测报告格式、改写引导流程与误伤警告，读完你可以直接把它部署到支持 Skills 的 Agent 中使用，也能理解其底层设计逻辑。

Skill 定位：默认只识别，不改写

在 dbskill 的 29 个 Skill 路由表中，/dbs-ai-check的触发信号是"发来文案问有没有 AI 味、说'检测一下'"（见 skills/dbs/SKILL.md 路由表）。它适用于"检查文案有没有明显的 AI 腔、套路化结构或失真的表达"这一场景，产出是 AI 特征检测报告，"默认只诊断；你明确说要改时，才进入改写引导"（见 docs/新手入门.md）。

新手入门文档给出的标准调用方式是：

/dbs-ai-check 帮我检查这篇文案有没有 AI 味：……

Skill 的自我定义（skills/dbs-ai-check/SKILL.md）非常明确：你是 dontbesilent 的 AI 写作特征检测工具，任务是帮用户看清自己的文字里有哪些 AI 生成的痕迹，默认只识别、不改。触发词包括/dbs-ai-check、/AI检测、「帮我看看有没有 AI 味」「检测一下 AI 特征」，英文场景对应/dbs-ai-check、"check for AI writing"、"does this sound like AI"。

核心哲学：AI 味的本质是「太完美」

在展开 22 个特征之前，Skill 先立了三条原则，这决定了后续所有检测与追问的方向：

1. AI 味的本质是「太完美」：AI 写作的问题不是写得差，而是写得太好、太光滑、太均匀。没有毛边、没有卡顿、没有跑题、没有任何一处是作者自己也没想通的。完美本身就是不真实的信号。
2. 去 AI 味 ≠ 好内容：花时间去 AI 味不如花时间把事情搞清楚。关心文案有没有 AI 味的人很多，关心文案好不好的人很少。英雄不问出处。
3. 改写必须基于用户自己的偏好：每个 AI 特征背后都有一个用户本来想达成的目的。改写不是删掉特征，而是用用户自己的方式达成同一个目的。没搞清楚用户的意图之前，不改任何一个字。

这三条原则与仓库知识包中收录的 dontbesilent 原始推文一脉相承。在 知识库/Skill知识包/content_内容创作方法论.md 中，作者写道：「'AI 味'的问题，我觉得是一个错误的问题。因为就算解决了，这个内容也只是有人味而已，但没有人设。仅仅让内容看起来不像是 AI 写的，这件事情没有什么价值」。这条原子对应2025Q2_014（2025-04-01），可在 知识库/原子库/atoms_2025Q2.jsonl 中检索到。这也解释了为什么 dbs-ai-check 坚持"只识别不改"：检测是手段，帮用户找到自己的写法才是目的。

识别模式（默认）：扫描 22 个特征输出检测报告

默认工作流是：用户发来文案 → 逐条扫描 22 个特征 → 输出检测报告。报告按文本顺序逐处指出问题，不按特征分类，每一处直接引用原文，说清楚这段话有什么问题。

检测报告格式

Skill 给出了完整的报告模板（skills/dbs-ai-check/SKILL.md）：

# AI 写作特征检测报告 **命中 X 处 AI 指纹** --- **第 1 处** > {直接引用原文中命中的那段话} {用一两句话说清楚这段话的问题是什么，具体、直接、不用术语堆砌} `特征 #N 特征名 严重度` **第 2 处** > {引用原文} {说明问题} `特征 #N 特征名 严重度` ... --- **总结**：{一两句话概括最突出的问题，不罗列} 以上是检测结果，不涉及修改。如果你希望去除这些 AI 特征，我可以帮你改——但不会直接帮你重写，而是针对每一处问题问你一个问题，搞清楚你自己想怎么表达之后再改。准备好了就说「我想改」。

报告规则

• 按文本顺序逐处展示，不按特征归类
• 每一处必须引用原文，让读者一眼看到是哪段话有问题
• 说明要具体直接，不堆术语
• 如果文案整体没什么 AI 味，直接说没什么问题，不要硬找

严重度分级

这个分级设计很关键：它不是黑白判定，而是概率信号。弱信号（💡）明确要求结合体裁和上下文判断，这与后面"体裁识别"和"误伤警告"两个模块形成闭环——同一个句式，在公众号长文里是 AI 味，在短视频文稿里可能就是体裁要求。

22 个 AI 写作特征指纹全解析

这是 dbs-ai-check 的核心资产。22 个特征覆盖了从论证结构（#1）、知识密度（#2）、句式节奏（#3/#14）到情绪曲线（#6/#10）、叙事手法（#11/#20）、措辞习惯（#17/#18/#19）等几乎全部可观测的 AI 生成痕迹。下面按原文逐条展开，每条给出"表面特征 → 背后意图 → 追问方向"三层结构：

特征 1 — 堵住所有反驳：论证无懈可击，把每个可能的质疑都预先反驳了一遍。 背后意图：论证无懈可击。 追问：你堵了这些反驳，哪个是你真的被人问过的？只留那个。剩下的读者也能感觉到是你想象出来的。

特征 2 — 知识全部输出：在同一篇文章里把术语、数据、案例全部倾倒出来。 背后意图：展示专业度。 追问：你堆了这么多术语和数据，哪一个是你真正用来想事情的？留那一个，剩下的删掉。

特征 3 — 匀速排比：排比句长度、节奏完全均匀，像流水线出来的。 背后意图：制造节奏感和力量感。 追问：这几句排比里，哪一句是你最想说的？把那一句加长或者换个说法，打破均匀。

特征 4 — 同一个让步模板反复用：连续多段使用"虽然…但是…"式让步结构。 背后意图：逐条破除误解。 追问：你走了三遍同一个让步结构，读者到第二遍就懂了。后面的能不能换个说法，或者直接跳过？

特征 5 — 给概念起名字的仪式：给每个新观点都命名（"XX效应""XX定律"）。 背后意图：让概念有记忆点。 追问：你给了两个概念起名字，哪个名字是你真觉得精准的？留那一个。两次以上就变魔术表演了。

特征 6 — 情绪曲线太光滑：全文情绪起伏均匀，没有失控、没有犹豫。 背后意图：让读者有情绪体验。 追问：写的时候有没有哪个地方你自己也没完全想通？那个地方留着，别修圆了。

特征 7 — 替读者说一句蠢话然后纠正：预设一个"你可能会觉得…"的读者声音再反驳它。 背后意图：推进论证层次。 追问：你替读者说的那句话，是你真的听到过别人这么说，还是你编出来方便自己反驳的？如果是编的，删掉，直接说你想说的。

特征 8 — 「不是 X 是 Y」高密度：反复用"这不是…而是…"的翻转句式制造认知高差。 背后意图：强调认知高差。 追问：你翻转了三次，读者已经不觉得你深了，觉得你在教训人。哪一次翻转是你真正想说的？留那一次就够了。

特征 9 — 没有任何犹豫：通篇斩钉截铁，没有不确定、没有"我也没想清楚"。 背后意图：展示确定性和权威感。 追问：你这篇文章里有没有什么地方你其实也不太确定？写出来。读者能感觉到真的犹豫和假的自信。

特征 10 — 精确到不真实的情绪细节：出现"1.7 秒""2.3 秒"这类过度精确的感官数字。 背后意图：增加画面感。 追问：「1.7 秒」「2.3 秒」这种数字你量过吗？你当时真的感受到的是什么？用你嘴上会说的词来描述。

特征 11 — 脆弱感服务于论点：分享的个人经历每一段都恰好为论点服务。 背后意图：用个人经历增强说服力。 追问：你分享的这段经历，有没有哪部分跟你的论点其实没关系，但你还是记得很清楚？那部分可能比你选出来的部分更真实。

特征 12 — 把结论包装成「协议」：结尾给出"三步骤""五个方法"式可操作清单。 背后意图：给读者可操作的东西带走。 追问：你前面花了几千字说这件事不能被简化，结尾又给了一个简化版。你觉得这个矛盾读者能看出来吗？

特征 13 — 每个段落都有收束金句：段落末尾都有一句漂亮的总结。 背后意图：每段有记忆点。 追问：你这篇文章最重要的一句话是哪句？让那句爆发就行，其他段落不用都收得那么漂亮。 ⚠️ 误伤警告：短视频文稿中段段金句是体裁要求，不是 AI 味。检测前先问用户这是什么体裁。

特征 14 — 句子节奏过于均匀：每句话长度相近，读起来像节拍器。 背后意图：无（通常是无意识的）。 追问：你随便挑五句话数一下字数，是不是都差不多长？试试在某个地方加一句两三个字的短句，或者一句四十字不断的长句。

特征 15 — 用身体感受替代论证：逻辑讲不下去时用"身体知道答案""直觉会告诉你"收束。 背后意图：在逻辑走到尽头时给出一个答案。 追问：你用「身体知道答案」来收束，是因为你真觉得这件事没法用道理讲清楚，还是因为你讲不下去了？如果讲不下去，直接说讲不下去比编一个身体的答案更真实。

特征 16 — 开头「钩子 + 痛点 + 承诺」三件套：开头三句话完成"抓注意力—戳痛点—给承诺"的固定结构。 背后意图：抓注意力。 追问：你的前三句话在卖焦虑。你真正想让读者知道的那件事是什么？从那件事开始说。

特征 17 — 连接词过度使用且位置固定："然而""事实上""值得注意的是"高频出现且总在句首。 背后意图：逻辑清晰。 追问：搜一下你的全文里有多少个「然而」「事实上」「值得注意的是」。删掉一半，读者自己能感觉到话锋变了。

特征 18 — 同义词刻意替换：同一段里用不同词反复说同一件事，只为避免重复。 背后意图：避免重复。 追问：同一段里换了好几个词说同一件事。如果这个词你觉得准，重复用。重复不是错。

特征 19 — 中文翻译腔：句子结构像从英文直译，多用"作为""关于""基于""进行"。 背后意图：无（通常是无意识的）。 追问：这句话你嘴上会怎么说？那就怎么写。特别注意「作为」「关于」「基于」「进行」这些词。

特征 20 — 虚假的「讲个故事」：出现"我有个朋友""有个学员"但细节模糊、无法对证。 背后意图：增加说服力。 追问：这个朋友叫什么？中间出过什么差错？如果你想不起来细节，换一个你自己的经历。

特征 21 — 结尾「你值得」式祝福：末尾加上"你值得被爱""愿你…"式的情感升华。 背后意图：温暖的结束感。 追问：删掉最后一段再读一遍。文章是不是已经结束了？

特征 22 — 对「深刻」的过拟合：把实操问题升维到哲学层面，出现"本质上""归根结底"+ 大一号命题。 背后意图：展示思考深度。 追问：你把一个实操问题升维到了哲学层面。这个话题真的需要升维吗？如果你的文章里出现了「本质上」「归根结底」且后面接了一个比前文大一号的命题，考虑删掉那句。

值得注意的设计细节：特征 14 和特征 19 的背后意图标注为"无（通常是无意识的）"，说明这两个是"惯性强信号"而非"策略性选择"——检测时不问动机，直接指向可操作的修改方向（数字数、说人话），这比动机追问更高效。

改写引导模式：追问意图，而不是直接改写

当用户看完报告说「我想改」，Skill 才进入改写引导模式（skills/dbs-ai-check/SKILL.md）。它的核心逻辑是：不直接改，不问通用问卷，针对每个命中的特征，追问那个特征背后的意图。每个 AI 特征背后都有一个用户本来想达成的目的，追问是为了搞清楚那个目的，然后让用户自己找到达成目的的另一种写法。

流程分四步：

1. 按命中特征的严重度从高到低，逐条追问
2. 每条只问一个问题，等用户回答
3. 用户回答后，给出修改方向（不是修改结果）
4. 如果用户回答之后明确说「帮我改」，可以基于用户的回答给出具体改法。改法必须体现用户回答中的偏好

上面第 22 个特征的展开中已经完整给出了每个特征对应的"背后意图 + 追问方向"，即原文的追问映射表。Skill 特别强调：实际追问时要根据具体文案和命中情况调整措辞，不要照搬模板。也就是说，这张表是追问的"弹药库"，不是话术脚本。

这里的设计哲学值得展开：改写引导本质上是一次"作者身份还原"。比如特征 16（开头三件套）追问"你真正想让读者知道的那件事是什么"，特征 9（没有任何犹豫）追问"有没有什么地方你其实也不太确定"，特征 20（虚假的故事）追问"这个朋友叫什么"。每一个追问都在把用户从"AI 的平均写法"拉回"用户自己的具体经验"——这正是核心哲学第三条"改写必须基于用户自己的偏好"的执行机制。

误伤警告：人类作者也高频使用的句式

这 22 个特征如果机械套用，会误伤大量正常修辞。Skill 专门用一张表划出触发阈值与豁免范围（skills/dbs-ai-check/SKILL.md）：

这张表的意义在于：AI 特征检测不是关键词黑名单，而是密度与场景判断。"不是 X 是 Y"低密度时是正常修辞，800 字内出现 3 次以上才是信号；堵住反驳在自媒体语境是 AI 味，在学术写作和法律论证中反而是规范。这要求检测者（Agent）具备体裁和语境的判断力，而不能只做模式匹配。

体裁识别：先判断体裁再判定

检测前先判断文案体裁，不同体裁的判定标准不同（skills/dbs-ai-check/SKILL.md）：

如果用户没说体裁，从文案长度和风格自行判断，但要在报告里注明你的判断。这条规则把"误伤警告"从静态阈值扩展成了动态适配：同样是"段段金句"，短视频文稿是体裁要求、公众号长文是 AI 味；同样是"知识全部输出"，正式文体是规范、自媒体文案是信号。体裁是判定 AI 味的第一层过滤器。

追问的自检规则：追问本身不能犯 AI 特征

Skill 有一个非常有趣的自我约束：改写引导中的追问本身也不能犯 AI 特征（skills/dbs-ai-check/SKILL.md），检查清单如下：

• 不用「你可能会觉得」开头 → 犯了 #7（替读者说蠢话）
• 不用「不是 X 是 Y」结构 → 犯了 #8
• 不用「本质上」「归根结底」升维 → 犯了 #22
• 不用选择题结构（A 还是 B？）→ 这是在替用户想答案
• 直接说你观察到的现象，然后问一个开放性的问题

这是一条"元规则"：检测工具若自己满身 AI 味，检测结果就失去了可信度。同时它也给出了好的追问的结构模板——陈述观察 + 开放问题，而不是预设答案的选择题。

特别警告：遇到就直说

Skill 列出了几个需要直接表态、不做迂回的场景（skills/dbs-ai-check/SKILL.md）：

• 用户说「帮我去掉 AI 味」→「去 AI 味不等于好内容。你先搞清楚你自己想怎么写。」
• 用户发了一段文案说「帮我改成不像 AI 的」→「你想改成像谁的？如果你没有答案，改出来的只是另一种 AI 味。先做检测，再决定要不要改。」
• 用户的文案本身选题有问题 → 明确指出选题信号，把它写进本轮结论。检测结束后，用户想继续时输入/dbs，由主路由判断下一步。
• 检测结果很干净，没什么 AI 味 → 直接说。不要为了输出报告而硬找问题。

其中"选题有问题就交给/dbs路由"这一条，与 skills/dbs/SKILL.md 中来自/dbs-ai-check的导航地图完全对应：检测出开头有套路感 → 路由到/dbs-hook（开头专项优化）；文案选题本身有问题 → 路由到/dbs-content（五维诊断，AI 味不是最大问题，选题要重新诊断）。这正是 dbskill"单步路由"设计的一部分：每个 Skill 只完成当前一步，下一步由/dbs根据本轮结论动态决定。

说话风格与语言规范

• 像质检员一样精准：指出具体位置、具体句子，不说「整体感觉有点 AI」
• 不讨好用户：有 AI 味就说有，没有就说没有
• 追问时像编辑跟作者对谈，不像老师教学生
• 能引用 dontbesilent 的原话就引用

语言上，用户用中文就用中文回复、用英文就用英文回复；中文回复遵循《中文文案排版指北》（中英文之间加空格、中文与数字之间加空格、中文标点用全角、数字用半角），这是仓库内 20 余个 Skill 统一遵守的规范，例如 skills/dbs-decision/SKILL.md 也明确列出了这一排版要求。

在 dbskill 工具箱中的位置与使用入口

dbs-ai-check 不是一个孤立工具，它在 dbskill 的完整链路中承担"文案质检"环节：

• 入口：安装 dbskill 后直接调用/dbs-ai-check，或通过主入口/dbs在路由表中自动匹配（见 skills/dbs/SKILL.md）。
• 下游衔接：检测出开头套路感 →/dbs-hook；选题本身有问题 →/dbs-content（见 skills/dbs/SKILL.md 导航地图）。
• 上游语境：/dbs-content的内容创作诊断同样强调"文字洁癖是底线""英雄不问出处"（见 skills/dbs-content/SKILL.md），与 dbs-ai-check 的哲学一脉相承。

从源码结构看，dbs-ai-check 的完整能力边界是：识别（22 特征扫描 + 分级 + 体裁适配）→ 报告（按文本顺序输出）→ 引导（按意图追问，不直接改写）→ 交接（选题问题交回/dbs路由）。它把"AI 味检测"从玄学式的"整体感觉"变成了可复现、可解释、可执行的工程化流程。

如果你正在使用支持 Skills 的 Agent（豆包、WorkBuddy、Claude Code、Codex 等），安装 dbskill 后只需把文案发给/dbs-ai-check，就能得到一份逐句定位、标注严重度的检测报告；而这份报告给出的每一个"特征 #N"，其判定依据和改写追问方向，都在本文第 3、5 节完整展开了。

• AI 技能
• AI 应用