适合放在什么时候
- 写文章前,先清洗第三方材料。
- 页面快发出前,做一次风险复核。
- 团队已有一版总结,你需要判断哪些能直接上线。
- 自己产品页写到安全、传输、路由和限制条件时。
这不是“再润色一次文案”的 Prompt,而是一套把候选材料重新拆回来源层、事实层和发布风险层的核验模板。它适合 AI 工具更新、教程、Prompt 页、功能说明页、技术 FAQ 和产品落地页,重点是先查官方来源,再决定哪些话能写满,哪些只能写成观察或待确认。
官方文档、官方博客、官方更新日志、官方 GitHub 仓库、官方公告、产品后台实际界面。涉及功能存在与否、限制和支持平台时优先用这一层。
官方员工公开说明、官方论坛答复、发行说明镜像、仓库 issue 里的维护者回复。可辅助判断,但不应替代 A 级结论。
媒体报道、博主总结、社交平台长帖、聚合站内容、AI 自己生成的总结。适合找线索,不适合作为最终背书。
“听说”“好像”“网上都这么说”“模型回答说”。只能作为待核验输入,不能直接进正式页面。
适合对一段简短总结、一个产品更新、一个社交平台帖子做第一轮筛查。
你现在是“信息核验编辑”,任务不是继续润色,而是把下面这段内容拆成:
1. 已确认事实
2. 未确认但可能成立的说法
3. 明显属于推测、夸张或不应直接发布的表达
4. 还缺少哪些官方来源
5. 一版更安全、可公开发布的改写
核验要求:
- 优先查找 A 级官方来源:官方文档、官方博客、官方仓库、官方公告、官方产品界面。
- 如果没有 A 级来源,不要把说法写成结论。
- 区分“功能存在”“当前可用”“默认启用”“适合所有人”“没有限制”这几类不同判断。
- 对每个结论标注:已确认 / 待确认 / 推测 / 不建议发布。
待核验内容:
{{candidate_text}}
输出格式:
- 已确认事实:
- 待确认说法:
- 推测或夸张表达:
- 缺失来源清单:
- 安全改写版本:适合教程、评测、专题文章、Prompt 页、功能说明页在发布前做完整复核。
你现在是“正式发布前的事实核验编辑”。我会给你一篇候选文章或页面草稿,请你完成以下工作:
一、把全文拆成独立可核验的陈述句。
二、按陈述句逐条判断:
- 这是事实、推测、经验判断、宣传表达,还是未经证实的结论?
- 现有文字里是否隐含了“唯一、全部、一定、完全、默认支持、无需条件”等过满表述?
- 需要什么级别的来源才能支持它?
三、对每条陈述输出:
- 原句
- 分类:已确认事实 / 待确认 / 推测 / 风险表述
- 推荐来源级别:A / B / C / D
- 改写建议
四、输出一版“适合正式发布”的修订稿,要求:
- 保留可确认信息
- 下调无法确认的结论强度
- 补上前提条件、限制和适用边界
- 不要添加原文没有证据支持的新结论
待核验草稿:
{{draft_text}}
输出格式:
1. 逐条核验表
2. 高风险表述汇总
3. 缺失来源清单
4. 修订稿适合工具落地页、FAQ、安全说明、传输说明和部署说明,避免营销话术跑到代码实现前面。
你现在是“产品技术说明核验员”。我会提供一个产品页面草稿、FAQ 或功能说明,请你站在“上线前技术复核”的角度处理。
目标:
- 只保留能被代码、配置、部署方式、实测结果或正式文档支持的说法
- 把“感觉像是这样”的描述降级成待确认或删除
- 特别检查安全、传输、加密、存储、日志、路由、限制条件和浏览器兼容性
请按下面格式输出:
1. 代码确认:哪些说法能被实现直接支持
2. 配置确认:哪些说法依赖当前部署或环境变量
3. 实测确认:哪些说法需要真实访问页面、抓包或多端测试才能确认
4. 待确认:当前不能写满的地方
5. 禁止写法:不应直接对外承诺的句子
6. 安全改写版 FAQ / 页面文案
待核验页面草稿:
{{product_copy}}
实现依据:
{{implementation_notes}}{{candidate_text}}一段候选摘要、社交帖、二手总结或产品更新说明。适合快速核验模板。
{{draft_text}}待发布的完整文章、教程、页面草稿。适合正式文章核验模板。
{{product_copy}}你要上线的产品页文案、FAQ、安全说明或落地页内容。
{{implementation_notes}}代码摘录、配置说明、部署现状、测试结论或已知限制。没有这部分时,要更保守。
这类内容最容易把“线程交接”和“整机环境迁移”混成一件事。核验时要特别区分线程上下文、Git 状态、目标 worktree、外部进程和远程环境依赖。
这类内容常见问题是把演示录制、技能沉淀、自动执行和浏览器控制能力混写。核验时要拆清楚“演示一次”“生成 Skill”“是否可复用”这些层次。
这类技术说明最容易出现“完全不经过服务器”“端到端加密”“无限大小”“任何网络都能传”等写法。正确做法是把信令、WebRTC、TURN、WebSocket fallback 和当前部署分开写。
没有来源的问题,不会因为语言变柔和就消失。先补来源,再决定是否保留。
开源项目支持,不等于你的网站当前就启用了这项能力。要区分代码存在、配置开启和线上实测三层。
没有显式上限通常只意味着代码里没写死,不等于生产环境、浏览器和设备没有边界。
尤其是价格、权限、跨网络能力、安全能力和兼容性,一旦写成承诺,后面返工成本最高。
它帮助你把第三方总结、AI 生成内容或自家草稿重新拆回事实层和风险层,减少未经确认就上线的返工。
因为功能、入口、限制和支持平台最容易在二次传播中被改写,官方来源通常最稳。
适合教程、Prompt 页、Blog、工具落地页、功能 FAQ、安全说明和产品发布文案。
可以保留为线索,但不要直接写成结论。需要明确标为待确认或推测。
如果目标是正式发布,最好查。至少要把“当前已确认”和“暂未核验”明确分开。
适合,尤其适合核验中文二手解读是否把英文官方信息写过头了。
普通润色重表达,这套 Prompt 先判断能不能说,再决定怎么说。
可以,而且很适合。它能强迫页面把安全、传输、存储和限制条件说清楚。