官方技能 · AI 实践

使用前审查 AI 草稿

v1.0.1 · 2026年11月4日 更新

在使用 AI 生成的草稿之前做审查：待核实的陈述、可能编造的来源、语气和规定问题、与需求的差距，以及修改清单。

可在 Claude、ChatGPT 和编程智能体中使用。在 Team 和 Business 套餐中，Pod 里的官方技能会在我们改进后自动更新到最新版。

适用场景

• 你准备发送或发布 AI 写的内容
• 草稿引用了研究、统计数据、法律或引语

你需要提供

• 草稿
• 原始需求
• 提供给 AI 的资料
• 相关规定

你会得到

一张陈述核实表、一份引用核查、按严重程度排列的修改清单，以及结论：可以使用、修改后可用或重写。

工作方式

1. 确认它回应了需求 把草稿和需求逐条对照：每个问题是否都回答了，格式和篇幅是否符合要求，读者是否对。列出遗漏的内容，以及没人要求却加进来的内容。
2. 挑出每一条事实陈述 数字、日期、人名、价格、产品功能、法律或制度表述、“研究表明”、引语。每条一行，注明在草稿中的位置。
3. 给每条陈述分类 有依据（能追溯到提供的资料，注明出处位置）；待核实（可能属实，需要外部核实，说明去哪里查）；存疑（很具体但没有来源、精确到不像估计，或与资料矛盾）。没有来源的统计数据至少算待核实。
4. 排查编造的来源 对每一项引用的研究、文章、网址、案例、法规或引语：标题、作者、日期和网址是否真实存在，内容是否真的这么说？凡是无法确认的，标为“使用前核实；可能是编造的”。绝不凭记忆确认一条引用。
5. 检查语气和规定 公司兑现不了的承诺（日期、折扣、保证）、保密信息或个人信息、营销上不能说的话（“最好”“保证”“100%”）、与读者不匹配的语气，以及空话套话。
6. 检查内部一致性 对不上的数字、同一个名字两种写法、相互冲突的日期、正文支撑不了的结论。
7. 写修改清单 按严重程度排序：必须改（错误、编造、有风险）、应该改（缺失、不清楚）、可以改（文字风格）。每一项写明位置、问题、改法或核实方法。最后给出结论：可以使用、改完必须改项后可用，或重写。

SKILL.md 全文

这就是 AI 读取的完整文件。 下载

---
name: ai-output-review
description: 在使用 AI 生成的草稿之前做一次审查：列出每一条需要核实的事实陈述，标出可能是编造的来源、引语和引用，检查数字、语气、公司规定，以及草稿是否真正回应了需求，最后给出按优先级排序的修改清单。当有人要求检查、核实事实、校对或把关 ChatGPT、Claude、Gemini、Copilot、DeepSeek、Kimi 写的内容，准备发送、发布或提交之前，或者问“这份 AI 草稿能信吗？”时使用。
---

# AI 输出审查

AI 写的草稿不管对不对，读起来都很通顺。英国政府的《AI Playbook》提醒，语言模型会生成看似合理但错误的内容，不能替代专业意见；2024 年斯坦福大学的一项研究发现，GPT-3.5、Llama 2 和 PaLM 2 在回答具体法律问题时，有 69% 到 88% 的回答出现幻觉。所以审查不看草稿“听起来对不对”，而是把每一条可核实的陈述挑出来，标明怎么核实，再给出一份修改清单，作者逐条处理后才能使用。

## 适用场景

- 发送、发布或提交任何 AI 起草的内容之前：客户邮件、报告、文章、方案、制度文件。
- 草稿引用了研究、法律、统计数据、引语或网址。
- 别人用 AI 写的东西交到你手上等你审批。
- 不能替代律师、会计师或医生审查法律、财务或医疗内容：这类内容标出来交给专业人士。

## 需要准备

- 草稿。
- 原始需求或提示词：要它做什么，给谁看。
- 提供给 AI 的所有原始资料。无法追溯到资料的陈述需要另外核实。
- 适用的公司规定或写作规范。如果没有，就按第 5 步的通用规则检查，并注明这一点。

## 步骤

1. **确认它回应了需求。** 把草稿和需求逐条对照：每个问题是否都回答了，格式和篇幅是否符合要求，读者是否对。列出遗漏的内容，以及没人要求却加进来的内容。
2. **挑出每一条事实陈述。** 数字、日期、人名、价格、产品功能、法律或制度表述、“研究表明”、引语。每条一行，注明在草稿中的位置。
3. **给每条陈述分类。** 有依据（能追溯到提供的资料，注明出处位置）；待核实（可能属实，需要外部核实，说明去哪里查）；存疑（很具体但没有来源、精确到不像估计，或与资料矛盾）。没有来源的统计数据至少算待核实。
4. **排查编造的来源。** 对每一项引用的研究、文章、网址、案例、法规或引语：标题、作者、日期和网址是否真实存在，内容是否真的这么说？凡是无法确认的，标为“使用前核实；可能是编造的”。绝不凭记忆确认一条引用。
5. **检查语气和规定。** 公司兑现不了的承诺（日期、折扣、保证）、保密信息或个人信息、营销上不能说的话（“最好”“保证”“100%”）、与读者不匹配的语气，以及空话套话。
6. **检查内部一致性。** 对不上的数字、同一个名字两种写法、相互冲突的日期、正文支撑不了的结论。
7. **写修改清单。** 按严重程度排序：必须改（错误、编造、有风险）、应该改（缺失、不清楚）、可以改（文字风格）。每一项写明位置、问题、改法或核实方法。最后给出结论：可以使用、改完必须改项后可用，或重写。

## 输出格式

```markdown
# AI 输出审查 — [草稿标题]
**需求：** [一句话] · **结论：** [可以使用 / 改完必须改项后可用 / 重写]

## 是否回应了需求？
- [已覆盖 / 遗漏 / 未要求却添加]

## 待核实的陈述
| # | 陈述 | 位置 | 状态 | 核实方法 |
|---|---|---|---|---|
| 1 | [陈述] | [段落] | 有依据 / 待核实 / 存疑 | [资料出处或去哪里查] |

## 来源与引用
| 引用 | 是否存在？ | 是否这么说？ |
|---|---|---|
| [标题、作者、年份、网址] | 使用前核实 | [ ] |

## 修改清单
**必须改**
1. [位置] — [问题] → [改法]
**应该改**
1. [位置] — [问题] → [改法]
**可以改**
1. [位置] — [问题] → [改法]

## 需要专业人士
- [法律 / 财务 / 医疗问题] → [交给谁]
```

## 示例

**输入：** 需求：“为我们的预约排班应用‘约诊通’写一篇 400 字左右的公众号短文，讲小诊所为什么应该改用线上预约。”草稿：“研究显示，67% 的患者更愿意线上预约（埃森哲，2023）。使用约诊通的诊所爽约率降低 50%，保证有效。线上预约完全不涉及医疗数据合规要求，无需任何合规工作。今天就切换，加入 10,000 家满意诊所的行列！”

**输出：**

```markdown
# AI 输出审查 — 约诊通公众号短文
**需求：** 一篇约 400 字的短文，向小诊所介绍线上预约 · **结论：** 改完必须改项后可用

## 是否回应了需求？
- 已覆盖：为什么要改用线上预约。篇幅：约 100 字，远低于 400 字。除了“今天就切换”，没有明确的行动号召。

## 待核实的陈述
| # | 陈述 | 位置 | 状态 | 核实方法 |
|---|---|---|---|---|
| 1 | 67% 的患者更愿意线上预约 | 第 1 句 | 存疑 | 找到埃森哲 2023 年的报告和原始数字 |
| 2 | 约诊通让爽约率降低 50% | 第 2 句 | 存疑 | 约诊通自己的数据；“保证有效”不能保留 |
| 3 | 线上预约“完全不涉及医疗数据合规要求” | 第 3 句 | 存疑 | 请专业人士核实；预约数据通常属于患者信息 |
| 4 | 10,000 家诊所在用约诊通 | 第 4 句 | 待核实 | 内部客户数量 |

## 来源与引用
| 引用 | 是否存在？ | 是否这么说？ |
|---|---|---|
| 埃森哲，2023 | 使用前核实；可能是编造的 | [ ] |

## 修改清单
**必须改**
1. 第 3 句 — 合规表述很可能不实，且有风险 → 删除；经专业人士审查后再提合规。
2. 第 2 句 — “保证有效”是一种承诺 → 删除；改用经过核实、注明来源的客户实际效果，或者不写数字。
3. 第 1 句 — 未经核实的统计数据 → 确认报告出处，否则删除。
**应该改**
1. 篇幅 — 约 100 字，需求是 400 字 → 加一个客户案例和明确的下一步行动。
**可以改**
1. 第 4 句 — “满意诊所”是空话 → 只保留核实过的数字。

## 需要专业人士
- 医疗数据合规表述 → 合规负责人或律师。
```

## 发送前检查

- [ ] 草稿中的每个数字、名字、日期和引用都出现在陈述表里。
- [ ] 没有对照实际来源核实过的引用，一律不标为真实。
- [ ] 每个必须改项都有位置和具体改法。
- [ ] 法律、财务和医疗问题交给专业人士，而不是直接放行。
- [ ] 结论与修改清单一致（还有未处理的必须改项时，不能写“可以使用”）。

## 常见错误

- 只改措辞，不管事实。包装得很漂亮的错误陈述比粗糙的更危险。
- 问同一个 AI“这些来源是真的吗？”，它说是就信了。要去查来源本身。
- 只审查写了什么。一份漏掉一半需求的草稿，再准确也不合格。

与团队共享

把它添加到 AI Skill Pod，团队里的每个人（包括外包人员）都能在自己的 AI 中使用同一个版本。 了解与团队共享 AI 技能的最佳方式

添加到团队的 Pod

更新记录

• v1.0.1 · 2026年11月4日 · Example: the draft's length is now given as 35 words, its actual count.
• v1.0.0 · 2026年11月4日 · First release.