---
name: flexfox-ai-check
description: Use when checking or repairing AI-sounding, templated, overly polished, or untrustworthy prose in a FlexFox WeChat Official Account article.
---

# FlexFox 编辑与 22 项 AI 指纹审查

本模块是文章发布前的质量与人味硬门槛，不是单纯的词语替换。核心目标是剔除 AI 写作特有的“过度工整、光滑、说教与虚假感”，确保文章有血有肉、事实可信、人设立得住。

审查前必须确认 `过程/structure-check.json` 的状态为 `pass`；否则退回 `flexfox-writer`，不得生成“通过”的 `过程/review.md`。审查时读取：当前 Profile、`article.md`、`过程/brief.md`、`过程/evidence.md`。审查结果按出现顺序输出至 `过程/review.md`。

审稿者不是作者的自我表扬器。使用与 writer 独立的一次调用或干净上下文；审稿者**不得修改 `article.md`**。先运行：

```bash
python3 scripts/pipeline.py status --article-dir articles/YYYY-MM-DD-明确主题
```

结构未通过时停止。结构通过后，先找问题，再决定是否能通过；不得为了凑“全通过”而把可疑事实、假现场或模板句式解释成优点。

`structure-check.md` 中的「风格红旗」是快速检索提示，不是自动通过证明。逐项看上下文：命中明确禁句应退回修复；没有命中也必须完成 22 项人工审稿，不能把关键词扫描当作 AI 味检测器。

## 必写事实逐项核验

从 `过程/brief.md` 的「素材关系与关键证据」取出每个 `[必写] E##`。逐条核对它在正文的具体章节/段落、是否保留了证据原意、是否被错误弱化或夸大。必须把核对结果写进 `过程/review.md`：

```md
## 必写事实落稿核验
- [通过] E01：在「小标题」第 N 段，正文已说明……；与 `过程/evidence.md` 一致。
- [失败] E02：正文缺失；退回补写。
```

只要有任一必写事实没有对应正文位置，综合判定必须是 `needs-revision`。这一步专门防止“大纲写了、成稿漏了”。

## 一票否决项（阻断交付硬伤）

- **虚构事实**：凭空捏造亲身经历、测试结果、报错细节、人物对话、虚假数据或伪造官宣；
- **脱离证据**：正文中的具体数字、价格、限制与 `过程/evidence.md` 冲突；
- **证据外加戏**：来源未写明的日期、人数、收购、亲历、报错或人物对话被写成确定事实；
- **归属偷换**：将来源作者实测、页面观察或用户反馈改写成“我试了/我遇到”；
- **开场画饼未兑现**：标题承诺的痛点或收益在正文前 100 字内未开始兑现；
- **协作痕迹**：出现“正如你所要求的”、“我先写一版”、“你提供的材料”等与大模型的交互对话痕迹。

## 22 项 AI 塑料味指纹扫描（命中即打回）

| 编号 | AI 典型指纹 | 表现特征 | 修正方案 |
| :--- | :--- | :--- | :--- |
| **#1** | **求生欲式免责声明** | “当然，这并不是说……仍然需要……” | 删掉免责废话，直接说事实和限制 |
| **#2** | **虚假的「讲个故事」** | 凭空造景（“在清晨的办公室里，程序员小张正对着屏幕叹气……”） | 从真实的行业痛点和工具摩擦切入，不编造小说场景 |
| **#3** | **匀速对称排比** | 连续三个分句字数完全相同，语法结构像节拍器 | 打碎句式，长短交错，甚至单句成行 |
| **#4** | **模板化让步翻转** | “真正做XX时，最XX的往往不是A，而是B” | 禁用此句式，直接摆出账本和痛点 |
| **#5** | **每个段落必有收束金句** | 无论多小的事实，段末非要升华出一句对仗哲学 | 删掉空洞总结，保留真实的未完之意 |
| **#6** | **替读者说蠢话再纠正** | “大家都会问……其实没那么简单” | 不要预设读者蠢，直接陈述反直觉事实 |
| **#7** | **「不是 X 是 Y」高密度** | 全文出现 3 次以上“不是……而是……” | 强行删除“不是”，只讲正面是什么 |
| **#8** | **假拟人口头禅** | “没有什么玄学”、“说白了”、“说实话” | 删掉口头禅，直接讲客观逻辑 |
| **#9** | **没有任何犹疑与阻力** | 描述操作如同丝滑溜冰，完全没有碰壁与报错 | 仅在有真证据时补充摩擦细节，否则用客观拆解视角 |
| **#10** | **机械化大综述闭环** | 结尾用大排比把前面几个案例强行串成闭环 | 自然收束，给出主观倾向即可 |
| **#11** | **把结论包装成协议** | “这是一套底层范式/生产链路” | 用口语人话（如“这套打法”、“这套路子”） |
| **#12** | **情绪过载而事实亏空** | 狂喊“恐怖如斯”、“太炸了”、“杀死比赛” | 用具体倍数、金额和工时替代感叹词 |
| **#13** | **公关连接词堆叠** | “值得注意的是”、“总而言之”、“首先其次” | 全部剔除，直接转折或换行 |
| **#14** | **长段落窒息感** | 手机一屏全是密不透风的文字块 | 强制每段控制在 1~3 句，关键结论单独成段 |
| **#15** | **无意义的名词包装** | 动辄“飞轮”、“抓手”、“赋能”、“底座” | 换成“怎么做”、“工具”、“方法” |
| **#16** | **滥用破折号与分割线** | 正文出现 `——` 或大量 `---` 分割线 | 微信排版依赖留白和标题，不依赖破折号 |
| **#17** | **假全知视角** | “正如业内专家所预言……” | 降维为普通操盘手视角：“我当时看到也懵了” |
| **#18** | **结尾假大空展望** | 突然拔高到“AI 正在重塑人类未来的黎明” | 狠狠拉回地面：“下个月会员到底续不续” |
| **#19** | **前后态度骑墙中立** | 既说这个好，又说那个好，各打五十大板 | 个人号要有一贯的偏见，明确选边站 |
| **#20** | **虚假的提问互动** | “你准备好拥抱变革了吗？” | 换成具体场景：“你今天改稿被卡了多久？” |
| **#21** | **自相矛盾的格式混搭** | 纯口语文章里突然冒出学术论文式的加粗引用 | 保持全文语体一致 |
| **#22** | **空洞的行动号召** | “让我们拭目以待吧！” | 换成清晰实操：“链接放在这，自己去点” |

## 修订原则与报告格式

1. 不重复结构门禁已经检查过的字数、标题数和段落数；准确定位事实或文风问题，给出最小修改方案，不整篇推翻重写；
2. 修复后对整段及上下文重新复检；
3. 输出格式保存至 `过程/review.md`：

```md
# 编辑与 AI 检查

## 通过项
- 结构门禁：引用 `structure-check.json`，状态为 pass
- 事实硬核度：价格与参数已核对

## 必写事实落稿核验
- [通过/失败] E编号：正文位置与核验结论

## 待修订
### 1. [小节名/段落位置]
> 原文句子

- 命中指纹：#7「不是 X 是 Y」
- 修改方案：删除前置否定，直接叙述事实。

## 综合判定
- 状态：pass / needs-revision
- 查重与原创性：结构独立，无连续雷同句式
```

同时写入 `过程/review.json`。完整字段与例子见 [生产流水线合同](../../references/pipeline-contract.md)。

- `article_sha256` 必须是当前 `article.md` 的 SHA-256；
- 每个 `[必写] E##` 都要在 `fact_checks` 标记 `pass` 或 `fail`，并写正文位置与理由；
- 每个问题都要有 `severity`（`blocker` / `major` / `minor`）、位置、原文短引和最小修复动作；
- 有任何 blocker 或 major 时，`status` 必须为 `needs_revision`；
- `pass` 后运行 `python3 scripts/pipeline.py preflight --article-dir articles/YYYY-MM-DD-明确主题`。若正文在审稿后被改动，哈希失效，必须二审。