企业官网建设流程全解析

你有没有遇到过这种情况：一段文字读起来没毛病，但总感觉不痛不痒；或者文章发出去半天，才突然意识到里面有一处论据站不住脚。我过去大半年一直在折腾一个叫impeccable的个人项目，它不是什么了不起的软件，本质是一套用大模型做文本质检与打磨的工作流。核心思路就一句话：别指望 AI 一次写对，让它先写、再挑刺、修改、再挑刺，直到文本真正经得起推敲。

很多人用 AI 写作，拿到第一版就觉得“挺好，能用”，结果交出去被同事、读者、领导一指一个准。impeccable 解决的正是这个痛点——把“写”和“审”彻底拆开，让模型扮演一个足够苛刻的编辑，用明确的质检标准反复过滤文本。它适合这么几类人：每天要产出技术文档和方案的人，独立写博客的创作者，需要维护对外文案质量的运营同学，也包括只是想把工作邮件写得清楚体面的人。下面把这套工作流的设计思路、关键细节、完整实现和踩坑记录一次说清楚。

1. 整体设计与思路拆解

1.1 为什么核心思路是“挑刺”而不是“一次写好”

最早我用 AI 写东西，习惯是给一个大 prompt，让它“帮我写一篇关于某某的文章”。结果质量完全看运气：状态好的时候结构完整，状态差的时候满篇正确的废话。后来我发现问题出在方向上——大模型本质上是一个“看着合理就往下编”的系统，它生成的是概率上最像好文本的序列，而不是经过验证、经得起追问的文本。你让它一次写完，它就会把模糊的地方用自信的口气带过去，这就是幻觉的根源之一。

想明白这一点之后，我把流程改成“生成 + 审查”的双角色结构。你可以这么理解：把稿子递给普通朋友看，对方大概率说“挺好”，真正能帮你的反而是那个专门挑毛病的人。大模型也一样，让它当写手，它会自我感觉良好；让它当审查者，它反而能盘点出一堆问题。模仿安全领域里“红队蓝队”的思路，我让一个模型负责起草，另一个模型（或者同一个模型的独立会话）负责当那个专门找麻烦的人。这个设计的好处在于：批评比创作容易得多，让模型找问题，比让它一次写对，结果要稳定和可控得多。

1.2 用“触发式评分卡”而不是“感觉打分”

第一版 impeccable 我犯过一个典型错误：让模型给文本打 1 到 5 分。结果所有文章稳定在 4 分以上，理由是“整体不错，细节可以优化”。模型有很强的迎合倾向，你让它评价，它默认你是来求表扬的。而且打分没有可解释性，它说 4 分，我看不出哪里扣了一分，更没法反驳。

后来我彻底改成“触发式检查清单”——每条标准只有“通过 / 不通过”两个状态，不通过必须给出证据：哪一段哪一句，属于什么问题。这样就逼着模型严谨，也方便我人工复核。我日常用的维度有六个：事实性、逻辑性、完整性、风格一致性、简洁性、合规性。实际场景里不用每个都跑，写技术方案重点查事实性和逻辑性，写博客重点查风格一致性和简洁性，对外发公告则要加合规性检查。评分卡的意义不是给文本打标签，而是让“哪里不行”这件事被准确暴露出来。

2. 核心细节解析与实操要点

2.1 六个质检维度的定义与检查清单

直接把我现在用的检查定义放出来，你可以照着抄。

每个维度的 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_key=os.getenv("LLM_API_KEY"), base_url=os.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( model=os.getenv("REVIEW_MODEL"), temperature=0.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( model=os.getenv("REVISE_MODEL"), temperature=0.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_rounds=3): 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 跑第一轮，审查模型列出这么几条问题：

1. 原文引用“支持多种数据源接入”——问题描述：未明确具体支持哪些数据库类型，读者无法判断是否适配自己的环境。建议方向：补充具体清单或代表性数据源名称。
2. 原文引用“自动生成可视化报表”——问题描述：“自动生成”逻辑不完整，是否包含模板配置、字段映射规则？建议方向：说明自动化程度。
3. 原文引用“更好地理解业务情况”——问题描述：空泛宣传语，无实际信息量。建议方向：改为可感知的具体价值，如“减少手动汇总时间”。
4. 原文引用“操作效率有显著提升”——问题描述：缺乏可验证依据，“显著”是主观判断。建议方向：提供量化数据或删掉修饰词。
5. 原文引用“系统会自动生成”——问题描述：与上文“支持多种数据源接入”之间的衔接缺一步，用户行为到系统行为之间有什么触发条件。建议方向：补充操作步骤线索。

第一轮修改后，文本变成：

新报表模块支持接入 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 教会我一件事：大多数人缺的其实不是写的能力，而是审的耐心。以前我写完文章，巴不得立刻发出去，现在我会自然地问一句：“这一段如果被质疑，我拿什么回应？”这个问题本身就是最好的质检器。

最后再分享一个小技巧：我现在会让工作流先只输出问题清单，我确认完问题再进入修改，不让它一次把问题和建议都给我。原因很简单——一旦模型把修改建议也写出来，你就会不自觉地照着改，懒得自己判断；先看清单、自己想一遍怎么改，再让模型执行，稿件里保留的东西才是真正属于你自己的判断。这个细节改动很小，但对我帮助很大。