AI2Work
Prompt Template

AI 信息核验 Prompt:把第三方总结拆成事实、推测和风险

这不是“再润色一次文案”的 Prompt,而是一套把候选材料重新拆回来源层、事实层和发布风险层的核验模板。它适合 AI 工具更新、教程、Prompt 页、功能说明页、技术 FAQ 和产品落地页,重点是先查官方来源,再决定哪些话能写满,哪些只能写成观察或待确认。

官方来源优先 事实与推测分层 适合内容发布前复核

这套 Prompt 怎么用

适合放在什么时候

  • 写文章前,先清洗第三方材料。
  • 页面快发出前,做一次风险复核。
  • 团队已有一版总结,你需要判断哪些能直接上线。
  • 自己产品页写到安全、传输、路由和限制条件时。

输出最好包含什么

  • 已确认事实。
  • 缺失的官方来源。
  • 只能保留为推测的部分。
  • 容易误导的夸张表达。
  • 可以安全发布的改写版本。

来源等级建议

A 级:正式官方来源

官方文档、官方博客、官方更新日志、官方 GitHub 仓库、官方公告、产品后台实际界面。涉及功能存在与否、限制和支持平台时优先用这一层。

B 级:半官方或强相关来源

官方员工公开说明、官方论坛答复、发行说明镜像、仓库 issue 里的维护者回复。可辅助判断,但不应替代 A 级结论。

C 级:第三方整理

媒体报道、博主总结、社交平台长帖、聚合站内容、AI 自己生成的总结。适合找线索,不适合作为最终背书。

D 级:无来源说法

“听说”“好像”“网上都这么说”“模型回答说”。只能作为待核验输入,不能直接进正式页面。

Prompt 1:快速事实核验

适合对一段简短总结、一个产品更新、一个社交平台帖子做第一轮筛查。

你现在是“信息核验编辑”,任务不是继续润色,而是把下面这段内容拆成:
1. 已确认事实
2. 未确认但可能成立的说法
3. 明显属于推测、夸张或不应直接发布的表达
4. 还缺少哪些官方来源
5. 一版更安全、可公开发布的改写

核验要求:
- 优先查找 A 级官方来源:官方文档、官方博客、官方仓库、官方公告、官方产品界面。
- 如果没有 A 级来源,不要把说法写成结论。
- 区分“功能存在”“当前可用”“默认启用”“适合所有人”“没有限制”这几类不同判断。
- 对每个结论标注:已确认 / 待确认 / 推测 / 不建议发布。

待核验内容:
{{candidate_text}}

输出格式:
- 已确认事实:
- 待确认说法:
- 推测或夸张表达:
- 缺失来源清单:
- 安全改写版本:

Prompt 2:正式文章或内容页核验

适合教程、评测、专题文章、Prompt 页、功能说明页在发布前做完整复核。

你现在是“正式发布前的事实核验编辑”。我会给你一篇候选文章或页面草稿,请你完成以下工作:

一、把全文拆成独立可核验的陈述句。
二、按陈述句逐条判断:
- 这是事实、推测、经验判断、宣传表达,还是未经证实的结论?
- 现有文字里是否隐含了“唯一、全部、一定、完全、默认支持、无需条件”等过满表述?
- 需要什么级别的来源才能支持它?

三、对每条陈述输出:
- 原句
- 分类:已确认事实 / 待确认 / 推测 / 风险表述
- 推荐来源级别:A / B / C / D
- 改写建议

四、输出一版“适合正式发布”的修订稿,要求:
- 保留可确认信息
- 下调无法确认的结论强度
- 补上前提条件、限制和适用边界
- 不要添加原文没有证据支持的新结论

待核验草稿:
{{draft_text}}

输出格式:
1. 逐条核验表
2. 高风险表述汇总
3. 缺失来源清单
4. 修订稿

Prompt 3:自家产品技术说明核验

适合工具落地页、FAQ、安全说明、传输说明和部署说明,避免营销话术跑到代码实现前面。

你现在是“产品技术说明核验员”。我会提供一个产品页面草稿、FAQ 或功能说明,请你站在“上线前技术复核”的角度处理。

目标:
- 只保留能被代码、配置、部署方式、实测结果或正式文档支持的说法
- 把“感觉像是这样”的描述降级成待确认或删除
- 特别检查安全、传输、加密、存储、日志、路由、限制条件和浏览器兼容性

请按下面格式输出:
1. 代码确认:哪些说法能被实现直接支持
2. 配置确认:哪些说法依赖当前部署或环境变量
3. 实测确认:哪些说法需要真实访问页面、抓包或多端测试才能确认
4. 待确认:当前不能写满的地方
5. 禁止写法:不应直接对外承诺的句子
6. 安全改写版 FAQ / 页面文案

待核验页面草稿:
{{product_copy}}

实现依据:
{{implementation_notes}}

变量说明

{{candidate_text}}

一段候选摘要、社交帖、二手总结或产品更新说明。适合快速核验模板。

{{draft_text}}

待发布的完整文章、教程、页面草稿。适合正式文章核验模板。

{{product_copy}}

你要上线的产品页文案、FAQ、安全说明或落地页内容。

{{implementation_notes}}

代码摘录、配置说明、部署现状、测试结论或已知限制。没有这部分时,要更保守。

实战案例

案例一:Codex Thread Handoff

这类内容最容易把“线程交接”和“整机环境迁移”混成一件事。核验时要特别区分线程上下文、Git 状态、目标 worktree、外部进程和远程环境依赖。

案例二:Codex Record & Replay

这类内容常见问题是把演示录制、技能沉淀、自动执行和浏览器控制能力混写。核验时要拆清楚“演示一次”“生成 Skill”“是否可复用”这些层次。

案例三:文件快传页

这类技术说明最容易出现“完全不经过服务器”“端到端加密”“无限大小”“任何网络都能传”等写法。正确做法是把信令、WebRTC、TURN、WebSocket fallback 和当前部署分开写。

常见错误

把没有来源的说法直接降格润色

没有来源的问题,不会因为语言变柔和就消失。先补来源,再决定是否保留。

把上游能力写成当前部署能力

开源项目支持,不等于你的网站当前就启用了这项能力。要区分代码存在、配置开启和线上实测三层。

把“没看到限制”写成“没有限制”

没有显式上限通常只意味着代码里没写死,不等于生产环境、浏览器和设备没有边界。

把推测写成产品承诺

尤其是价格、权限、跨网络能力、安全能力和兼容性,一旦写成承诺,后面返工成本最高。

FAQ

这个 Prompt 主要解决什么问题?

它帮助你把第三方总结、AI 生成内容或自家草稿重新拆回事实层和风险层,减少未经确认就上线的返工。

为什么要优先找官方来源?

因为功能、入口、限制和支持平台最容易在二次传播中被改写,官方来源通常最稳。

它适合哪些页面?

适合教程、Prompt 页、Blog、工具落地页、功能 FAQ、安全说明和产品发布文案。

如果只有第三方报道怎么办?

可以保留为线索,但不要直接写成结论。需要明确标为待确认或推测。

这套模板一定要联网查资料吗?

如果目标是正式发布,最好查。至少要把“当前已确认”和“暂未核验”明确分开。

适合核验中文内容吗?

适合,尤其适合核验中文二手解读是否把英文官方信息写过头了。

它和普通润色 Prompt 的区别是什么?

普通润色重表达,这套 Prompt 先判断能不能说,再决定怎么说。

可以拿来核验自己产品页吗?

可以,而且很适合。它能强迫页面把安全、传输、存储和限制条件说清楚。

相关内容

附件里提到的候选链接如果当前站点还没有独立成稿,不要硬接死链。优先把事实核验能力接到现有可访问内容页上。