你有没有遇到过这种情况一段文字读起来没毛病但总感觉不痛不痒或者文章发出去半天才突然意识到里面有一处论据站不住脚。我过去大半年一直在折腾一个叫impeccable的个人项目它不是什么了不起的软件本质是一套用大模型做文本质检与打磨的工作流。核心思路就一句话别指望 AI 一次写对让它先写、再挑刺、修改、再挑刺直到文本真正经得起推敲。很多人用 AI 写作拿到第一版就觉得“挺好能用”结果交出去被同事、读者、领导一指一个准。impeccable 解决的正是这个痛点——把“写”和“审”彻底拆开让模型扮演一个足够苛刻的编辑用明确的质检标准反复过滤文本。它适合这么几类人每天要产出技术文档和方案的人独立写博客的创作者需要维护对外文案质量的运营同学也包括只是想把工作邮件写得清楚体面的人。下面把这套工作流的设计思路、关键细节、完整实现和踩坑记录一次说清楚。1. 整体设计与思路拆解1.1 为什么核心思路是“挑刺”而不是“一次写好”最早我用 AI 写东西习惯是给一个大 prompt让它“帮我写一篇关于某某的文章”。结果质量完全看运气状态好的时候结构完整状态差的时候满篇正确的废话。后来我发现问题出在方向上——大模型本质上是一个“看着合理就往下编”的系统它生成的是概率上最像好文本的序列而不是经过验证、经得起追问的文本。你让它一次写完它就会把模糊的地方用自信的口气带过去这就是幻觉的根源之一。想明白这一点之后我把流程改成“生成 审查”的双角色结构。你可以这么理解把稿子递给普通朋友看对方大概率说“挺好”真正能帮你的反而是那个专门挑毛病的人。大模型也一样让它当写手它会自我感觉良好让它当审查者它反而能盘点出一堆问题。模仿安全领域里“红队蓝队”的思路我让一个模型负责起草另一个模型或者同一个模型的独立会话负责当那个专门找麻烦的人。这个设计的好处在于批评比创作容易得多让模型找问题比让它一次写对结果要稳定和可控得多。1.2 用“触发式评分卡”而不是“感觉打分”第一版 impeccable 我犯过一个典型错误让模型给文本打 1 到 5 分。结果所有文章稳定在 4 分以上理由是“整体不错细节可以优化”。模型有很强的迎合倾向你让它评价它默认你是来求表扬的。而且打分没有可解释性它说 4 分我看不出哪里扣了一分更没法反驳。后来我彻底改成“触发式检查清单”——每条标准只有“通过 / 不通过”两个状态不通过必须给出证据哪一段哪一句属于什么问题。这样就逼着模型严谨也方便我人工复核。我日常用的维度有六个事实性、逻辑性、完整性、风格一致性、简洁性、合规性。实际场景里不用每个都跑写技术方案重点查事实性和逻辑性写博客重点查风格一致性和简洁性对外发公告则要加合规性检查。评分卡的意义不是给文本打标签而是让“哪里不行”这件事被准确暴露出来。2. 核心细节解析与实操要点2.1 六个质检维度的定义与检查清单直接把我现在用的检查定义放出来你可以照着抄。维度检查重点典型“不通过”信号事实性每个可验证断言是否有依据数字、名称、结论是否准确“据估计”“业内人士认为”后没有出处关键数据前后矛盾逻辑性论据是否能支撑结论有没有因果跳跃前文说 A 导致 B后文直接用 B 论证 C范围被悄悄扩大完整性读者能否仅凭文本理解全貌省略了必要背景指代不明突然出现未解释的概念风格一致性语气、句式、用词是否符合作者基准混入书面腔突然出现排比句和自己平时文风脱节简洁性是否能用更少文字表达同样信息重复解释已说清的内容填充词过多合规性是否触及敏感边界或产生误导暗示效果、夸大承诺、缺乏依据的价值判断每个维度的 prompt 写法有讲究。比如事实性检查我最开始只写“检查事实错误”模型基本交白卷。改成下面这个版本之后输出的问题就靠谱多了你的任务是审查文本中的事实性风险。请把文本里每一个可以被验证的断言单独列出来标注它的风险等级高需要外部数据或权威来源支撑、中推测但未标明、低常识性描述。高和中风险必须给出原因。禁止自行补充真实世界知识只判断文本自身的信息是否扎实。关键就在于“把断言单独列出来”和“禁止自行补充知识”。前者逼着模型逐句过后者避免它拿自己的幻觉去“纠正”原文。2.2 让模型“认真挑刺”的三条实用技巧光有维度还不够模型天然不爱得罪人。我在调试过程中发现三个技巧特别管用。第一条在系统提示里写负面偏好。比如“本次审查的目标是找出必须修改才能发布的问题而不是提供表扬。如果问题清单少于五条说明你没有认真阅读请重新输出。”这样做不完全是数量要求而是让模型的心理预设从“找优点”切换到“找毛病”。注意“少于五条要重输出”这种话术会带来一点副作用——模型可能凑数。所以我会加上“每条问题必须引用原文并说明影响凑数的无效”。第二条限制输出格式只允许输出问题清单。模型一旦被允许同时给建议它就会忍不住动手改稿写出一堆“建议改为……”又长又发散。我把输出格式严格限定成序号 原文引用 问题描述 建议方向。建议只写方向不写具体句子把修改的工作留到下一步避免审查和修改混在一起。第三条给锚定范例。模型对“什么是好文本”的理解其实受 prompt 影响很大。我在审查 prompt 里塞了一小段“低质量文本”和对应的“高质量文本”作为对照模型判断时就有了参照系。尤其是风格一致性和简洁性这两个维度有没有例子效果差距非常明显。2.3 必须避开的三个坑坑一同一个会话里既写又评。模型对自己的输出有“维护倾向”让它写完立刻自己挑毛病它多半会嘴下留情。所以 impeccable 的每次审查都是把文本复制到一条全新的独立会话里进行的。如果条件允许审查用另一个模型更好能避免“同一个脑子”的思维惯性。坑二过度润色导致术语被替换。模型修改时特别喜欢把“初始化”改成“启动”把专业术语“过拟合”改成“拟合过度”看上去通顺了意思却不准。我踩过几回之后在修改阶段加了硬性要求除非原术语存在明显错误否则一律保留原文所有修改必须在原文基础上做局部调整不允许重写整段。这一步让“保守润色”成为默认模式。坑三合规检查不能完全交给模型。模型可以提示哪些表达可能有误导、哪些措辞容易产生承诺效果但最终边界得由人来定。我的做法是把合规检查作为辅助信号输出结果我会再过目一遍不直接采用。3. 实操过程与核心环节实现3.1 一条完整的流水线起草、质检、修改、复审这套工作流本身不依赖特定平台我用 Python 脚本串起来的。核心流程是把初始文本发给审查模型拿到问题清单把原文和清单一起发给修改模型得到修订稿再对修订稿跑一轮审查。最多循环三轮三轮后无论结果如何都出稿防止模型陷入“无限自我批评”的死循环。下面是一个可直接运行的简化版本我用环境变量管理 API Key你可以按自己用的模型服务替换调用部分import os import json from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), ) REVIEW_PROMPT 你是严格的文本审查编辑。目标找出必须修改才能发布的问题。 规则 1. 只输出问题清单格式为序号 | 原文引用 | 问题描述 | 建议方向 2. 必须引用原文未引用原文的条目无效 3. 如果问题清单少于5条说明没有认真阅读请重新输出 4. 不提供任何表扬 REVISE_PROMPT 你是保守的文本编辑。基于问题清单修改原文规则 1. 仅进行局部修改不重写段落 2. 保留所有专业术语除非原术语明显错误 3. 保留作者原有语气和句式习惯 4. 输出修改后的完整文本 def review(text): resp client.chat.completions.create( modelos.getenv(REVIEW_MODEL), temperature0.2, messages[ {role: system, content: REVIEW_PROMPT}, {role: user, content: text}, ], ) return resp.choices[0].message.content def revise(text, issues): resp client.chat.completions.create( modelos.getenv(REVISE_MODEL), temperature0.3, messages[ {role: system, content: REVISE_PROMPT}, {role: user, content: f原文\n{text}\n\n问题清单\n{issues}}, ], ) return resp.choices[0].message.content def impeccable(text, max_rounds3): current text for i in range(1, max_rounds 1): issues review(current) print(f--- 第{i}轮审查 ---) print(issues) if 无问题 in issues or 通过 in issues: break current revise(current, issues) print(f--- 第{i}轮修改稿 ---) print(current) return current if __name__ __main__: sample_text 这里放入你的文本 final impeccable(sample_text)这里有两个细节特别重要。一是审查和修改的 temperature 都设得很低0.2 和 0.3因为审查和修改都不需要创造性低温度能明显减少随机发挥。二是每一轮的审查结果和修订稿我都打印出来保留出了问题能回溯看看是审查给错了方向还是修改模型执行不到位。3.2 实战案例把一段“四平八稳”的文字改到无可挑剔我拿一段真实场景中很常见的文字演示一下。假设你在一家做数据工具的公司工作要给新功能写一段介绍我们的新报表模块支持多种数据源接入用户可以从数据库、表格文件、第三方接口导入数据。系统会自动生成可视化报表帮助团队更好地理解业务情况。新版界面经过重新设计操作效率有显著提升。这文字看着没毛病但经不起推敲。用 impeccable 跑第一轮审查模型列出这么几条问题原文引用“支持多种数据源接入”——问题描述未明确具体支持哪些数据库类型读者无法判断是否适配自己的环境。建议方向补充具体清单或代表性数据源名称。原文引用“自动生成可视化报表”——问题描述“自动生成”逻辑不完整是否包含模板配置、字段映射规则建议方向说明自动化程度。原文引用“更好地理解业务情况”——问题描述空泛宣传语无实际信息量。建议方向改为可感知的具体价值如“减少手动汇总时间”。原文引用“操作效率有显著提升”——问题描述缺乏可验证依据“显著”是主观判断。建议方向提供量化数据或删掉修饰词。原文引用“系统会自动生成”——问题描述与上文“支持多种数据源接入”之间的衔接缺一步用户行为到系统行为之间有什么触发条件。建议方向补充操作步骤线索。第一轮修改后文本变成新报表模块支持接入 MySQL、PostgreSQL、Excel/CSV 文件以及常见第三方 API 数据源。配置好数据源后系统可基于用户选择的字段自动生成图表覆盖折线图、柱状图和透视表三种形式。该模块可将团队每周的数据汇总耗时从平均 3 小时缩短至 30 分钟以内同时保留数据更新历史和权限设置方便追溯。第二轮复审只揪出一个问题“覆盖折线图、柱状图和透视表三种形式”这个断言如果是产品现状就通过但如果在演示版里还没上线就构成事实性风险。我确认之后补了“当前版本”四个字全文过关。这个案例直接说明这套工作流的价值它不会替你创造亮点但能把逻辑缺口、空泛表述和事实风险一个个挖出来。3.3 参数设置、成本控制与长文本处理旁边的读者可能会问这么来回审成本会不会爆炸我实际用下来一篇 1500 字左右的博客审查一次大约消耗 600 到 1000 token修改一次差不多 800 到 1500 token。跑满三轮总消耗大概在 5000 token 上下按现在的模型定价换算单篇成本在几分钱到几毛钱之间完全可控。真正要注意的是轮数我设的是 3实测大部分文本两轮就能过第三轮基本是“确认没有新问题”。不要设成 5 轮甚至更多模型会在第三轮之后开始对已经通过的文本做无意义改动反而引入错误。长文本是另一个坑。直接把一篇 8000 字的文章丢进去审查模型很容易“抓大放小”只盯着开头和结尾中间段落轻轻带过。我的做法是先做分块按章节切成 1500 字左右的单元每块单独审查。审查完再看全局让模型检查章节之间的逻辑衔接和术语一致性。这个“先局部后全局”的顺序不能反先全局的话模型会被整体结构带跑忽略细节问题。还有一个小细节给审查模型的 system prompt 里我从不写“你是一个 AI”或者“你是一个语言模型”直接写“你是严格的文本审查编辑”。角色设定越具体、越接近真实职业身份模型输出越靠谱。这是个便宜但非常有效的技巧。4. 常见问题与排查技巧实录4.1 模型总说“整体很好只是小建议”怎么办这应该是使用这套工作流时遇到最多的症状。审查结果写成“整体结构合理语言流畅以下是一些小建议”说明审查已经变成了变相表扬。我排查过一轮原因基本都在 prompt 语气上。“请评价这篇文章”这种说法模型默认你要的是反馈而不是批评。把任务改成“找出若不做修改就不能发布的问题并且每条问题必须引用原文中具体的句子”模型的态度会立刻变硬。再加上“问题少于五条说明没认真读”的压力你会发现它开始连标点规范都查了。当然凑出来的“问题”可能有些牵强但那是下一步人工复核的事宁可它先暴露也不能让它憋着。4.2 越改越不准事实错误和术语漂移怎么防模型在修改阶段最容易犯的错是为了让句子“更顺”而替换专业表达。“梯度下降”被改成“逐步降低错误率”“特征工程”被改成“数据处理技巧”。如果你在技术领域写东西这种改动是致命的。我的补救措施分两层第一层在修改 prompt 里把“保留所有专业术语除非原术语明显错误”加粗放在最前面第二层增加一次“事实复核”环节把原稿的术语表和关键数据单独喂给模型让它检查修改稿里有没有偏离原稿的表述。注意是“偏离原稿”不是“是否正确”目的是抓修改动作引入的偏差。这一层检查过的稿子术语基本能保住。4.3 改完不像自己写的建立“作者基准”还有一类问题是风格漂移。模型改出来的东西正确是正确但一读就是 AI 味排比句、宏大叙事、连接词用得过重。我的解决办法是从自己过去写得顺手的文章里抽两三段作为“作者基准”贴在修改 prompt 里明确让模型模仿基准的语气和句式习惯。基准不需要长300 字就够但必须是典型风格——短句多还是长句多、爱不爱用比喻、段落衔接密不密。另外我还会加一句硬约束“不要使用原文中不存在的修辞手法不要为追求气势改动句式结构。”有了基准加约束修改稿基本能保持我自己的口语化风格。4.4 审查结果忽好忽坏怎么让它稳定下来如果你发现两次审查对同一篇文本给出完全不同的结论先别怪模型笨这是采样随机性的正常表现。我处理的办法有三招第一招把 temperature 降到 0.2 以下审查是判断题不是创作题第二招同一个审查跑三次取“问题并集”而不是单次结果并集策略能最大化覆盖问题宁多勿漏第三招如果条件允许用两个不同模型做交叉审查一个偏逻辑一个偏语言查出来的问题往往互补。这三招都上完之后我遇到过最极端的情况也只剩“某个问题到底算不算问题”这种主观判断而那种判断本来就该人来做。5. 更进一步的扩展把 impeccable 变成日常习惯5.1 写博客、技术方案和工作邮件的组合用法impeccable 不只是一个“写完再查”的工具它可以根据场景调整检查维度组合我现在已经把它固化成了三种常用模式。写博客时用“事实性 风格一致性 简洁性”重点保证输出内容站得住脚同时读起来像我自己写的写技术方案时用“逻辑性 完整性 事实性”重点盯论据和结论之间的推导链发工作邮件时用“简洁性 合规性 语气检查”我加了一条自定义维度“是否礼貌但不过度谦卑”尤其适合需要反复沟通的跨部门邮件。三种模式其实只是几个检查 prompt 的不同组合成本几乎没有差别但对口味的贴合度提升非常大。5.2 想做得更重接入编辑器、批量质检与团队模板你现在用的编辑器如果支持外部命令可以直接把 impeccable 做成一个小插件。比如在 VS Code 里选中一段文字绑定快捷键调起脚本把选中内容送进工作流返回修改稿再粘贴回去整个过程不到半分钟。Obsidian 这类笔记软件也一样通过 URI 调用外部脚本就能实现。团队协作时可以把六维评分卡固化成一份团队内部的《文本质检规范》每个人用自己的 API Key 跑同一套标准这样不同人写出来的对外内容在质量口径上是统一的。这一步的价值比工具本身还大因为标准的统一比工具的统一难得多。5.3 一个必须保留的环节人工确认终稿用这套工作流的人都会遇到一个诱惑让模型输出最终稿自己直接复制粘贴发布。我强烈建议不要这么做。模型即使跑完了三轮质检它给出的终稿也是“在它自己的标准下合规的文本”而不是“在真实读者面前成立的文章”。我自己的习惯是模型输出的每一版修改稿都要人工读一遍重点感受中途被改掉的那些句子——如果哪句话读起来别扭但说不清哪里不对我会让它恢复成上一版的表达。这个动作其实是在用你的判断给模型补上它天生缺的那一环真实场景下的语感。写在最后一点真实感受这个项目用到今天我最大的感触不是文本质量变高了而是我重读自己初稿时的眼光变毒了很多。impeccable 教会我一件事大多数人缺的其实不是写的能力而是审的耐心。以前我写完文章巴不得立刻发出去现在我会自然地问一句“这一段如果被质疑我拿什么回应”这个问题本身就是最好的质检器。最后再分享一个小技巧我现在会让工作流先只输出问题清单我确认完问题再进入修改不让它一次把问题和建议都给我。原因很简单——一旦模型把修改建议也写出来你就会不自觉地照着改懒得自己判断先看清单、自己想一遍怎么改再让模型执行稿件里保留的东西才是真正属于你自己的判断。这个细节改动很小但对我帮助很大。