最近关于 AI 写作有一个判断被反复提及Ethan Mollick 认为AI 写作的第一个黄金时代已经结束。这句话听起来有些反直觉毕竟大模型仍然能在一分钟内生成一篇几千字的文章。但如果认真读过他的观点会发现他讨论的不是“AI 能不能写”而是“仅仅靠 AI 自动生成文字就能产生红利的阶段已经过时了”。对开发者来说这句话值得被翻译成一套更具体的问题为什么早期那种“输入主题、点击生成、复制发布”的简单 AI 写作方案不再有效新的 AI 写作产品应该如何设计怎样把大模型从“自动打字机”改造成真正可控的内容生产系统本文将沿着这个思路展开先分析 AI 写作范式的变化再介绍 RAG、检索增强、幻觉检测、Agent 工作流等新阶段的关键概念最后给出一个可运行的 Python 示例搭建一套包含草稿生成、知识召回、事实校验在内的 AI 辅助写作系统。无论你是在做内容工具、写技术文档还是在企业内部落地 AI 编辑助手都可以在示例基础上扩展。1. AI 写作“黄金时代”结束模型能力没变弱使用方式变旧了1.1 第一波 AI 写作解决了什么问题如果把时间拨回大模型刚刚开放聊天接口的阶段我们会看到一类典型用法用户输入一个标题模型生成大纲再让模型按大纲逐段展开最后人工修改错别字和过渡句。对于工作总结、营销文案、周报、邮件等“结构化要求明确、事实密度不高”的写作任务这套流程确实能大幅缩短耗时。正因为如此很多团队在早期迅速把“AI 写初稿”接入了业务内容编辑从每天写两篇变成每天看十篇。这一阶段可以称为 AI 写作的“生成红利期”。模型的价值体现在文本组织能力上它懂开头要抓人、段落要有层次、结尾要总结也善于模仿不同文风。只要任务不要求准确数据和特殊知识生成结果往往高于普通员工的平均初稿水平。这个阶段给市场建立了一个默认预期让 AI 写文章只需要会聊天。1.2 为什么“能生成”不再是核心门槛随着使用人群扩大问题逐渐暴露。第一大模型生成的内容带有明显的“平均风格”句子通顺但缺少信息增量读者很快会产生审美疲劳。第二模型不懂它没有见过的企业内部数据、真实案例和业务指标只要涉及细节它就会用“合理猜测”填补于是出现编造引用、伪造数据、虚构案例等问题。第三平台对 AI 生成内容的消重机制和质量要求越来越严格无引用、无事实支撑的文本无法获得稳定分发。因此“第一黄金时代结束”的本质是用户对“写了一篇东西”这件事的预期变了。从前端看用户需要的不只是能读的文本而是可核验、可追溯、符合业务上下文的知识产品。从后端看模型只是生成器如果缺少知识检索、事实校验、结构化编排和人工审核系统就无法承担严肃写作任务。新的竞争优势不在于“生成更流畅”而在于“系统更可靠”。1.3 写作工作流的三种演进阶段阶段核心特征主要问题技术关键词一键生成时代把 AI 当输入输出工具无事实约束、同质化高Prompt Engineering检索增强时代先取资料再生成回答有出处知识库建设成本高、召回质量影响结果RAG、向量检索、重排序Agent 协作时代多角色分工AI 承担研究、初稿、审校任务流程编排复杂、需要可观测性和人工节点Agent、工作流、QC从工程视角看AI 写作正在从“单次调用大模型生成文本”转向“内容生产管线”。在这个管线里大模型只是其中一个组件前面连着知识采集后面连着事实校验与人工审核。这样理解 Ethan Mollick 的判断会更清楚让模型独自承担写作任务的“黄金时代”结束了而把模型嵌入一套生产系统的新阶段才刚刚开始。2. 新阶段需要补齐的四个技术拼图2.1 RAG让模型先查资料再回答RAG全称 Retrieval-Augmented Generation即检索增强生成。它的核心思路很简单当用户提出写作需求时不直接让大模型凭记忆生成而是先从外部知识库或搜索引擎中召回相关内容把召回结果拼在提示词里再由模型完成文本组织。这样生成的每个关键数据、案例和表述都可能对应到实际来源而不是模型脑补出来的内容。在 AI 写作系统中RAG 的价值尤其明显。写技术教程时模型需要版本号、接口名称和正确的代码片段写行业报告时模型需要最新的统计数据写企业内部公告时模型需要准确的组织名称和制度条款。这些信息往往不在模型训练数据里或者已经过期。通过 RAG内容系统可以把内部文档、产品手册、历史文章片段作为知识来源让模型在受控范围内写作。需要注意的是RAG 并不是简单地把知识库里的文本全塞进上下文。实际工程中要考虑召回准确性、上下文长度、引用格式、相关性重排等问题。一次失败的检索带来的危害比不检索更大因为错误的资料会诱导模型生成看起来严谨但实际错误的内容。2.2 幻觉检测从“写得像”到“说得对”大模型幻觉可以通俗地解释为“一本正经地胡说八道”。模型并没有真正理解事实它只是按概率预测下一个 token。当训练数据中没有对应知识或者生成时上下文不足模型就会用平滑的表达来填补缺口。对于 AI 写作来说幻觉是比“文笔差”更严重的问题一篇观点鲜明的文章如果引用了一个不存在的报告或者把人物身份写错轻则被读者质疑重则带来法律和公关风险。黄金时代结束后的一个关键变化是产品开始把幻觉检测作为必备模块。常见方案有两类一类是基于规则例如要求模型输出时带上引用编号再由系统检查每个编号指向的来源是否真实存在另一类是使用另一个大模型做“事实核查员”把原稿拆成单个论断再逐条与上下文比对。真正的生产系统通常会结合两类方案并把检测结果展示给编辑人员而不是自动修改。2.3 Agent将写作拆解成协作流程Agent 的概念可以简单理解为一个在大模型之上加入“目标、工具、记忆和动作”的程序。传统 AI 写作是单次问答用户给一个指令模型给一段结果Agent 化写作则是让模型扮演多个角色并让不同的角色协作完成一项复杂的写作任务。举个例子一个写作 Agent 可以拆成四个环节研究型 Agent 负责去检索资料提炼事实规划型 Agent 负责确定文章大纲和表达角度撰稿型 Agent 负责根据资料与大纲生成全文质检型 Agent 负责逐条检查事实一致性、风格漏洞和引用完整性问题。每个环节都可以调用不同的模型或工具也可以在某个节点插入人工确认。这样做虽然比单个 Prompt 复杂却大幅提升了结果的可控性。从开发角度看Agent 不应被过度神化。它本质上是一种工作流设计代码层面体现为“循环、状态、工具调用”的组合。成本、延迟和质量都要在工程中权衡不是“接入一个开源框架”就自动解决。2.4 可观测性与质量度量写作任务的最后一步往往不是发布而是评估。很多团队使用大模型写作却说不清楚“什么叫一篇好文章”。没有度量标准就难以调优也难以判断某个提示词或某个模型版本是更好了还是更差了。可观测性至少包括三类指标流程指标记录模型调用次数、耗时、token 成本质量指标记录文章的事实错误率、引用缺失率、人工修改比例业务指标记录文章阅读完成率、转发率、搜索收录情况。把这些数据沉淀下来才可能形成持续迭代的写作系统。3. 环境准备与工程结构3.1 代码运行环境本文的示例代码使用 Python 编写适合在 Python 3.10 及以上版本中运行。示例的大模型调用采用 OpenAI 兼容接口这样无论是访问官方接口还是使用兼容该协议的本地模型服务代码都不需要大改。API Key、模型名称和接口地址建议通过环境变量传入避免硬编码到脚本中。假设你本机已经安装 Python 和 pip可以先创建一个虚拟环境python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install --upgrade pip依赖包相对较少也可以直接写入 requirements.txtpython-dotenv1.0.1 requests2.32.3安装命令pip install -r requirements.txt版本号在不同时间可能更新这里只是给出一个已验证的组合。如果你的环境中已经安装了更新的版本并不一定需要完全对齐。3.2 模型接口变量在项目根目录创建.env文件LLM_BASE_URLhttps://api.example.com/v1 LLM_API_KEYyour_api_key_here LLM_MODELgpt-4o-mini LLM_TEMPERATURE0.3这里使用的是示意地址你需要根据实际的模型服务来源修改。为了安全不要把真实 Key 提交到代码仓库。3.3 项目结构规划为了让读者更容易理解文中不会一次性罗列全部生产级代码而是搭建一个可运行的最小示例ai_writer/ ├── .env ├── requirements.txt ├── llm_client.py # 封装大模型调用 ├── knowledge_store.py # 极简知识库检索 ├── writing_flow.py # 写作流程大纲、初稿、事实校验 ├── qc.py # 幻觉检测与质量报告 └── main.py # 主入口串联整体流程真实项目中可以按模块继续拆分比如把“知识库存储”改为向量数据库把“质检提示词”整理成额外配置文件。这里的项目结构只为了演示核心思路。4. 实战搭建一套“检索-写作-质检”内容系统4.1 封装大模型调用客户端先编写llm_client.py它负责读取环境变量并调用 OpenAI 兼容接口。这里为了减少依赖没有使用官方 SDK而是直接用requests发起 HTTP 请求。# 文件路径llm_client.py import os import json import requests from dotenv import load_dotenv load_dotenv() BASE_URL os.getenv(LLM_BASE_URL, https://api.example.com/v1) API_KEY os.getenv(LLM_API_KEY, ) MODEL os.getenv(LLM_MODEL, gpt-4o-mini) TEMPERATURE float(os.getenv(LLM_TEMPERATURE, 0.3)) def call_llm(messages, temperatureTEMPERATURE, max_tokens1024): 调用 OpenAI 兼容接口。messages 是一个 list格式如下 [{role: system, content: ...}, {role: user, content: ...}] if not API_KEY: raise RuntimeError(缺少 LLM_API_KEY请在 .env 文件中配置。) url f{BASE_URL}/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } payload { model: MODEL, messages: messages, temperature: temperature, max_tokens: max_tokens, } response requests.post(url, headersheaders, jsonpayload, timeout60) response.raise_for_status() data response.json() return data[choices][0][message][content].strip()这个模块的核心价值是隔离底层模型接口。后续写流程模块时不需要关心模型是本地部署还是远程服务只要替换环境变量即可。4.2 实现一个极简知识库检索模块知识库在示例中不需要很复杂。我们先将几段参考资料放入一个本地文本字典里然后通过关键词权重计算召回相关片段模拟 RAG 的第一步。生产系统中通常会改成向量检索加关键词检索的混合方式。# 文件路径knowledge_store.py import re class SimpleKnowledgeStore: 一个用于演示的极简知识库按关键词命中数量选择相关片段。 def __init__(self, docs: dict): # docs 的格式为{文档ID: 文档正文} self.docs docs def search(self, query: str, top_k: int 2): query_terms set(re.findall(r[\w\u4e00-\u9fff], query.lower())) scored [] for doc_id, content in self.docs.items(): content_lower content.lower() # 统计 query 中每个关键词在文档中出现的次数 score 0 for term in query_terms: score content_lower.count(term) if score 0: scored.append((score, doc_id, content)) scored.sort(keylambda x: x[0], reverseTrue) return [(doc_id, content) for _, doc_id, content in scored[:top_k]]这里没有引入向量模型目的是让代码可直接运行并让读者看清“检索后如何进 Prompt”。实际写作系统中知识库内容可以来自公司内部 Wiki、产品文档、历史文章、竞品资料等。如果文档数量很大则必须使用 Elasticsearch、OpenSearch 或向量数据库来保证检索效率和相关性。4.3 封装写作流程接下来是核心的writing_flow.py。它会实现三个动作根据主题召回知识、生成写作大纲、再生成初稿。写好的 Prompt 被集中放在代码中方便读者理解每个字段的作用。# 文件路径writing_flow.py from llm_client import call_llm from knowledge_store import SimpleKnowledgeStore class WritingFlow: def __init__(self, knowledge_store: SimpleKnowledgeStore): self.knowledge_store knowledge_store def _build_context_block(self, query: str) - str: hits self.knowledge_store.search(query, top_k2) if not hits: return 没有检索到参考资料请根据通用知识生成但不要编造具体数据。 blocks [] for doc_id, content in hits: blocks.append(f[资料 {doc_id}]\n{content}) return \n\n.join(blocks) def create_outline(self, topic: str) - str: context self._build_context_block(topic) system_prompt 你是一名资深的专业技术编辑。你的任务是写出结构清晰、有信息增量的文章大纲。 user_prompt f 写作主题{topic} 参考资料 {context} 要求 1. 大纲需要包含引言、核心章节、总结共 5 到 7 个一级模块 2. 每个模块下给出要点或小标题 3. 不要输出与主题无关的套话 4. 如果在参考资料中发现了可用的事实请在大纲后的“资料线索”中列出。 请现在输出大纲。 messages [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ] return call_llm(messages, max_tokens1500) def write_draft(self, topic: str, outline: str) - str: context self._build_context_block(topic) system_prompt 你是一名专业的 AI 写作助手。你输出的初稿必须严谨、清楚并尽量基于参考资料。 user_prompt f 写作主题{topic} 写作大纲 {outline} 参考资料 {context} 要求 1. 根据大纲展开生成一篇不少于 800 字的初稿 2. 涉及数据、日期、版本号、引述时必须标注 [来源:对应资料ID] 3. 不能为了凑字数编造资料里不存在的事实 4. 文笔接近技术博客风格避免过分营销化的表达 5. 如果某个信息不在参考资料中请在文末“待核实项”中单独列出。 请现在输出初稿。 messages [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ] return call_llm(messages, max_tokens3000)这个流程体现了“先检索再生成”的思路。参考资料会进入 Prompt模型生成时必须以这些资料为基准。不过我们仍然不能假设模型会 100% 遵守约束因此下一步还需要用质检模块来自动检查。4.4 实现幻觉检测与质量报告qc.py是防止“一本正经胡编”的关键模块。它使用另一个 LLM 调用把稿件中的事实性陈述逐条拆出来再依据原始资料进行判断。# 文件路径qc.py import re from llm_client import call_llm def split_statements(text: str): 简单按句号、问号、感叹号切分文本。生产环境可用更完善的句子分割算法。 raw_sentences re.split(r(?[。]), text) return [s.strip() for s in raw_sentences if len(s.strip()) 10] class QualityChecker: def __init__(self, knowledge_store): self.knowledge_store knowledge_store def check(self, draft: str, topic: str) - dict: statements split_statements(draft) context self._build_context(topic) issues [] for stmt in statements: # 如果语句中包含明显的数据、年份、专有名词等信息才进入模型校验 if not re.search(r\d|20\d\d|来源|是|根据, stmt): continue verdict self._check_single(stmt, context) if verdict and 不支持 in verdict: issues.append({statement: stmt, result: verdict}) return { statement_count: len(statements), issue_count: len(issues), issues: issues, draft: draft, } def _build_context(self, topic: str) - str: hits self.knowledge_store.search(topic, top_k3) blocks [] for doc_id, content in hits: blocks.append(f[资料 {doc_id}]\n{content}) return \n\n.join(blocks) if blocks else 无参考资料 def _check_single(self, statement: str, context: str) - str: system_prompt 你是一个严格的审校员只能根据参考资料判断陈述是否被支持。 user_prompt f 参考资料 {context} 待核查陈述 {statement} 请判断该陈述是否能被参考资料直接支持。如果资料中没有足够信息请回答“不支持资料不足”。如果陈述与资料冲突请回答“不支持与资料冲突”。如果资料可以支持请回答“支持”。不要输出其他解释。 messages [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ] result call_llm(messages, temperature0.1, max_tokens300) return result这个模块的准确性依赖提示词和模型审查能力但它展示了“用大模型监督大模型”的工程落地方式。在正式产品中还可以把高风险语句交给人工复核而不是全部依赖自动结论。4.5 主流程串联最后在main.py中把知识库、写作流程和质检流程连接起来。为了便于看到效果代码中直接写入了两段示例资料。# 文件路径main.py from knowledge_store import SimpleKnowledgeStore from writing_flow import WritingFlow from qc import QualityChecker if __name__ __main__: docs { doc_1: 向量数据库Vector Database是一种专门处理向量数据的存储系统。 在 RAG 应用中文档会被切分成片段再用嵌入模型转换成向量。 检索时系统通过相似度计算找到与问题最相关的片段。 , doc_2: AI 幻觉指模型生成的内容与事实不符或没有依据。 减少幻觉的方法包括检索增强生成、引用溯源、人工审核。 高质量的数据集和清晰的提示词也能降低幻觉发生概率。 , } store SimpleKnowledgeStore(docs) topic 如何降低大模型写作中的幻觉风险 writer WritingFlow(store) print( 1. 生成大纲 ) outline writer.create_outline(topic) print(outline) print(\n 2. 生成初稿 ) draft writer.write_draft(topic, outline) print(draft) print(\n 3. 事实一致性检查 ) checker QualityChecker(store) report checker.check(draft, topic) print(f共切分出 {report[statement_count]} 条陈述发现 {report[issue_count]} 条问题。) for issue in report[issues]: print(待核查陈述, issue[statement]) print(校验结果, issue[result]) print(---)运行命令python main.py预期输出会包含三段内容。第一段是模型生成的大纲第二段是根据大纲写出的初稿第三段是质检报告。由于模型生成有一定随机性具体文字每次都会不同但整体流程应该保持一致。如果某个语句超出资料内容质检模块就会提示“不支持资料不足”。这就是 AI 写作系统比“直接让模型写”更可靠的重要原因。4.6 进一步扩展为 Agent 流程上面的流程虽然已经比“一次 Prompt 生成全文”更完善但仍然是一个线性流程检索、大纲、初稿、质检。真实场景里文章主题往往需要多轮修改一篇好内容可能要经历“生成-评审-修改-再评审”的循环。我们可以把流程中的每个阶段看成一个 Agent 节点用外部代码来控制循环。比如写一个简单的修订函数# 伪代码展示 Agent 循环思想 for round_no in range(3): report checker.check(draft, topic) if report[issue_count] 0: break issues_text \n.join([i[result] i[statement] for i in report[issues]]) revise_prompt f根据审校意见修改初稿。\n意见{issues_text}\n\n初稿{draft} draft call_llm([ {role: system, content: 你是专业编辑负责根据审校意见修订文章。}, {role: user, content: revise_prompt}, ], max_tokens3000) print(draft)实际的 Agent 框架会在此基础上加入工具调用、状态机、人工审批和日志追踪但核心思想与上面的伪代码一致。先让模型生成再让另一个模型负责“挑错”最后通过循环优化能够显著降低内容风险。5. 常见问题与排查思路问题现象常见原因解决思路生成内容经常编造来源或数据模型仅靠参数记忆写作缺少知识库约束切换到 RAG 架构强制查询参考资料并要求输出引用 ID明明给了资料模型还是不按资料写上下文太长导致关键信息被稀释压缩检索结果只保留高相关片段在 Prompt 中强调“若无资料则标注”而非“自由发挥”事实一致性检查误报过多检查逻辑把表述性、评论性句子也当成事实只在语句中包含数字、年份、版本号或“根据……数据显示”等信号时才触发模型复核API 调用超时或限流模型服务端负载较高或请求 max_tokens 过长增加重试与退避机制在客户端做超时控制必要时切换模型路由生成成本过高每条写作请求都重复上传整段知识库设置缓存优化检索策略使用摘要代替原始长文本或使用更便宜的小模型做初筛内容同质化严重提示词模板过于固定模型输出平均化在流程中增加“素材库”先抽取独特案例和观点再让模型基于素材写作用户不愿意直接采用 AI 草稿缺少人工审核与编辑器无法确认问题位置增加批注模式把事实校验结果、疑似幻觉点、引用来源高亮呈现给用户语境越来越长模型却忽略开头要求大模型对长上下文尾部更敏感把关键指令放在系统提示词和用户提示词末尾或拆分成长文本多轮生成排查时不要一上来就调整 Prompt。建议先确认知识库召回结果是否正确因为“生成问题”往往是“检索问题”的后续表现。如果召回了无关内容再好的写作 Prompt 也无法写出正确初稿。另一个容易忽略的问题是质量检测模型本身也可能产生误判。用大模型作为审校员时审校模型的 temperature 要尽量降低并且每次只输出一个简短标签。必要时可以把“支持”“不支持”和“无法判断”分开讨论减少因为提示词造成的偏差。6. 最佳实践与工程建议6.1 提示词和数据资产化管理很多团队在 AI 写作初期把提示词写在聊天软件里时间一长就难以复现。更稳妥的做法是把提示词当作代码资产管理每个版本有名称、内容和变更记录。例如在项目中创建prompts/目录用 Markdown 或 YAML 文件保存提示词模板再由 Python 读取。这样修改提示词时可以走代码评审而不是直接在线上试错。数据资产同样关键。RAG 系统中的知识库不是简单丢一堆文本进去而要经过清洗、切分、去重、权限标注、更新周期管理。否则模型会不断引用过时或冲突的文档反而降低内容可信度。6.2 人工审核节点不能省无论系统引入多少自动校验严肃写作流程都应设置“人在回路”节点。机器负责完成效率高、成本低的批量检查例如错别字、格式、篇幅、明显矛盾人负责判断内容价值、观点倾向、组织逻辑和制度合规。对于涉及媒体发布、产品公告、法律文档或重要学术内容的写作人工审核的节点建议放在“生成初稿后”和“最终发布前”两步审核最稳妥。在代码中可以为待审核状态增加字段例如pending_review、approved、rejected让工作流停在人工确认之前。这不会明显降低效率却能让风险从“模型问题”变成“流程问题”。6.3 模型路由与降级写作流程可能会用到多个模型快速小模型负责切分句子和关键词抽取强模型负责长文写作严谨模型负责事实核查。因此系统最好设计一个简单的模型路由层。例如可以在.env中配置多个模型并根据任务类型设置优先级。当某个模型服务不可用时系统自动降级到备用模型而不是直接报错。在小成本团队中也可以先使用一款较便宜的模型做全流程验证等到评测指标达到阈值后再切换更大模型。这能降低实验阶段的费用。6.4 日志与评测先行每轮调用大模型都要记录输入规模、输出 token、耗时、成本和任务类型。对于写作系统尤其要记录“知识库命中了哪些文档”“生成稿被人工修改了哪些部分”。人工修改记录是很好的训练信号系统能够知道哪些段落质量不高、哪些资料导致模型理解偏差。评测方面可以引入“幻觉率”“人工修改率”“引用完整率”三个核心指标。不要只看模型生成速度有多快重点观察一篇稿子从生成到发布需要多少审校时间。AI 写作系统的最终目标不是完全替代人而是减少人的重复机械劳动。6.5 安全边界与最小权限写作系统如果接入了企业内部知识库就一定要处理权限问题。用户通过 AI 写文档时模型只能看到该用户权限范围内的资料。否则一次简单的“帮我把相关材料整理成周报”请求就可能把未见范围内的敏感信息带进结果。在工程上检索服务必须与权限系统打通每条文档都携带访问级别。即使模型提示词拼接了参考资料也只允许拼接用户有权访问的那部分。对涉及删除、修改或发布的写作后处理操作要提供撤销机制和操作日志这些能力面对真实生产环境时比“生成质量”更重要。7. 总结与下一步方向AI 写作的“第一黄金时代”结束不代表 AI 写作失去价值而是说明简单的文本生成已经无法满足更高层次的业务要求。未来值得投入的方向是把 RAG、幻觉检测、Agent 工作流和可观测性结合起来让大模型从“写手”变成“研究助理”和“编辑辅助工具”。本文从 Ethan Mollick 的观点出发结合大模型工程实践讲清了三个重点第一知识库是高质量写作的基础先检索后生成能明显降低编造概率第二用另一个模型做事实一致性检查是可行的落地方案但要配合足够的规则与人工审核第三AI 写作系统需要按工程方式组织提示词、模型、数据、日志和权限缺一不可。你可以把本文中的代码改成自己的知识库和文档主题运行几轮后记录问题。下一步如果想继续深入可以学习向量数据库和 embedding 模型把SimpleKnowledgeStore换成一个更完整的召回系统也可以尝试引入 Agent 框架让不同模型分别承担研究、初稿和审校任务。真正值得长期积累的不是让 AI 写得多快而是让 AI 写出的内容经得起追问、来源经得起核验、流程经得起复盘。
AI写作新范式：RAG、幻觉检测与Agent工作流驱动可靠内容生产
最近关于 AI 写作有一个判断被反复提及Ethan Mollick 认为AI 写作的第一个黄金时代已经结束。这句话听起来有些反直觉毕竟大模型仍然能在一分钟内生成一篇几千字的文章。但如果认真读过他的观点会发现他讨论的不是“AI 能不能写”而是“仅仅靠 AI 自动生成文字就能产生红利的阶段已经过时了”。对开发者来说这句话值得被翻译成一套更具体的问题为什么早期那种“输入主题、点击生成、复制发布”的简单 AI 写作方案不再有效新的 AI 写作产品应该如何设计怎样把大模型从“自动打字机”改造成真正可控的内容生产系统本文将沿着这个思路展开先分析 AI 写作范式的变化再介绍 RAG、检索增强、幻觉检测、Agent 工作流等新阶段的关键概念最后给出一个可运行的 Python 示例搭建一套包含草稿生成、知识召回、事实校验在内的 AI 辅助写作系统。无论你是在做内容工具、写技术文档还是在企业内部落地 AI 编辑助手都可以在示例基础上扩展。1. AI 写作“黄金时代”结束模型能力没变弱使用方式变旧了1.1 第一波 AI 写作解决了什么问题如果把时间拨回大模型刚刚开放聊天接口的阶段我们会看到一类典型用法用户输入一个标题模型生成大纲再让模型按大纲逐段展开最后人工修改错别字和过渡句。对于工作总结、营销文案、周报、邮件等“结构化要求明确、事实密度不高”的写作任务这套流程确实能大幅缩短耗时。正因为如此很多团队在早期迅速把“AI 写初稿”接入了业务内容编辑从每天写两篇变成每天看十篇。这一阶段可以称为 AI 写作的“生成红利期”。模型的价值体现在文本组织能力上它懂开头要抓人、段落要有层次、结尾要总结也善于模仿不同文风。只要任务不要求准确数据和特殊知识生成结果往往高于普通员工的平均初稿水平。这个阶段给市场建立了一个默认预期让 AI 写文章只需要会聊天。1.2 为什么“能生成”不再是核心门槛随着使用人群扩大问题逐渐暴露。第一大模型生成的内容带有明显的“平均风格”句子通顺但缺少信息增量读者很快会产生审美疲劳。第二模型不懂它没有见过的企业内部数据、真实案例和业务指标只要涉及细节它就会用“合理猜测”填补于是出现编造引用、伪造数据、虚构案例等问题。第三平台对 AI 生成内容的消重机制和质量要求越来越严格无引用、无事实支撑的文本无法获得稳定分发。因此“第一黄金时代结束”的本质是用户对“写了一篇东西”这件事的预期变了。从前端看用户需要的不只是能读的文本而是可核验、可追溯、符合业务上下文的知识产品。从后端看模型只是生成器如果缺少知识检索、事实校验、结构化编排和人工审核系统就无法承担严肃写作任务。新的竞争优势不在于“生成更流畅”而在于“系统更可靠”。1.3 写作工作流的三种演进阶段阶段核心特征主要问题技术关键词一键生成时代把 AI 当输入输出工具无事实约束、同质化高Prompt Engineering检索增强时代先取资料再生成回答有出处知识库建设成本高、召回质量影响结果RAG、向量检索、重排序Agent 协作时代多角色分工AI 承担研究、初稿、审校任务流程编排复杂、需要可观测性和人工节点Agent、工作流、QC从工程视角看AI 写作正在从“单次调用大模型生成文本”转向“内容生产管线”。在这个管线里大模型只是其中一个组件前面连着知识采集后面连着事实校验与人工审核。这样理解 Ethan Mollick 的判断会更清楚让模型独自承担写作任务的“黄金时代”结束了而把模型嵌入一套生产系统的新阶段才刚刚开始。2. 新阶段需要补齐的四个技术拼图2.1 RAG让模型先查资料再回答RAG全称 Retrieval-Augmented Generation即检索增强生成。它的核心思路很简单当用户提出写作需求时不直接让大模型凭记忆生成而是先从外部知识库或搜索引擎中召回相关内容把召回结果拼在提示词里再由模型完成文本组织。这样生成的每个关键数据、案例和表述都可能对应到实际来源而不是模型脑补出来的内容。在 AI 写作系统中RAG 的价值尤其明显。写技术教程时模型需要版本号、接口名称和正确的代码片段写行业报告时模型需要最新的统计数据写企业内部公告时模型需要准确的组织名称和制度条款。这些信息往往不在模型训练数据里或者已经过期。通过 RAG内容系统可以把内部文档、产品手册、历史文章片段作为知识来源让模型在受控范围内写作。需要注意的是RAG 并不是简单地把知识库里的文本全塞进上下文。实际工程中要考虑召回准确性、上下文长度、引用格式、相关性重排等问题。一次失败的检索带来的危害比不检索更大因为错误的资料会诱导模型生成看起来严谨但实际错误的内容。2.2 幻觉检测从“写得像”到“说得对”大模型幻觉可以通俗地解释为“一本正经地胡说八道”。模型并没有真正理解事实它只是按概率预测下一个 token。当训练数据中没有对应知识或者生成时上下文不足模型就会用平滑的表达来填补缺口。对于 AI 写作来说幻觉是比“文笔差”更严重的问题一篇观点鲜明的文章如果引用了一个不存在的报告或者把人物身份写错轻则被读者质疑重则带来法律和公关风险。黄金时代结束后的一个关键变化是产品开始把幻觉检测作为必备模块。常见方案有两类一类是基于规则例如要求模型输出时带上引用编号再由系统检查每个编号指向的来源是否真实存在另一类是使用另一个大模型做“事实核查员”把原稿拆成单个论断再逐条与上下文比对。真正的生产系统通常会结合两类方案并把检测结果展示给编辑人员而不是自动修改。2.3 Agent将写作拆解成协作流程Agent 的概念可以简单理解为一个在大模型之上加入“目标、工具、记忆和动作”的程序。传统 AI 写作是单次问答用户给一个指令模型给一段结果Agent 化写作则是让模型扮演多个角色并让不同的角色协作完成一项复杂的写作任务。举个例子一个写作 Agent 可以拆成四个环节研究型 Agent 负责去检索资料提炼事实规划型 Agent 负责确定文章大纲和表达角度撰稿型 Agent 负责根据资料与大纲生成全文质检型 Agent 负责逐条检查事实一致性、风格漏洞和引用完整性问题。每个环节都可以调用不同的模型或工具也可以在某个节点插入人工确认。这样做虽然比单个 Prompt 复杂却大幅提升了结果的可控性。从开发角度看Agent 不应被过度神化。它本质上是一种工作流设计代码层面体现为“循环、状态、工具调用”的组合。成本、延迟和质量都要在工程中权衡不是“接入一个开源框架”就自动解决。2.4 可观测性与质量度量写作任务的最后一步往往不是发布而是评估。很多团队使用大模型写作却说不清楚“什么叫一篇好文章”。没有度量标准就难以调优也难以判断某个提示词或某个模型版本是更好了还是更差了。可观测性至少包括三类指标流程指标记录模型调用次数、耗时、token 成本质量指标记录文章的事实错误率、引用缺失率、人工修改比例业务指标记录文章阅读完成率、转发率、搜索收录情况。把这些数据沉淀下来才可能形成持续迭代的写作系统。3. 环境准备与工程结构3.1 代码运行环境本文的示例代码使用 Python 编写适合在 Python 3.10 及以上版本中运行。示例的大模型调用采用 OpenAI 兼容接口这样无论是访问官方接口还是使用兼容该协议的本地模型服务代码都不需要大改。API Key、模型名称和接口地址建议通过环境变量传入避免硬编码到脚本中。假设你本机已经安装 Python 和 pip可以先创建一个虚拟环境python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install --upgrade pip依赖包相对较少也可以直接写入 requirements.txtpython-dotenv1.0.1 requests2.32.3安装命令pip install -r requirements.txt版本号在不同时间可能更新这里只是给出一个已验证的组合。如果你的环境中已经安装了更新的版本并不一定需要完全对齐。3.2 模型接口变量在项目根目录创建.env文件LLM_BASE_URLhttps://api.example.com/v1 LLM_API_KEYyour_api_key_here LLM_MODELgpt-4o-mini LLM_TEMPERATURE0.3这里使用的是示意地址你需要根据实际的模型服务来源修改。为了安全不要把真实 Key 提交到代码仓库。3.3 项目结构规划为了让读者更容易理解文中不会一次性罗列全部生产级代码而是搭建一个可运行的最小示例ai_writer/ ├── .env ├── requirements.txt ├── llm_client.py # 封装大模型调用 ├── knowledge_store.py # 极简知识库检索 ├── writing_flow.py # 写作流程大纲、初稿、事实校验 ├── qc.py # 幻觉检测与质量报告 └── main.py # 主入口串联整体流程真实项目中可以按模块继续拆分比如把“知识库存储”改为向量数据库把“质检提示词”整理成额外配置文件。这里的项目结构只为了演示核心思路。4. 实战搭建一套“检索-写作-质检”内容系统4.1 封装大模型调用客户端先编写llm_client.py它负责读取环境变量并调用 OpenAI 兼容接口。这里为了减少依赖没有使用官方 SDK而是直接用requests发起 HTTP 请求。# 文件路径llm_client.py import os import json import requests from dotenv import load_dotenv load_dotenv() BASE_URL os.getenv(LLM_BASE_URL, https://api.example.com/v1) API_KEY os.getenv(LLM_API_KEY, ) MODEL os.getenv(LLM_MODEL, gpt-4o-mini) TEMPERATURE float(os.getenv(LLM_TEMPERATURE, 0.3)) def call_llm(messages, temperatureTEMPERATURE, max_tokens1024): 调用 OpenAI 兼容接口。messages 是一个 list格式如下 [{role: system, content: ...}, {role: user, content: ...}] if not API_KEY: raise RuntimeError(缺少 LLM_API_KEY请在 .env 文件中配置。) url f{BASE_URL}/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } payload { model: MODEL, messages: messages, temperature: temperature, max_tokens: max_tokens, } response requests.post(url, headersheaders, jsonpayload, timeout60) response.raise_for_status() data response.json() return data[choices][0][message][content].strip()这个模块的核心价值是隔离底层模型接口。后续写流程模块时不需要关心模型是本地部署还是远程服务只要替换环境变量即可。4.2 实现一个极简知识库检索模块知识库在示例中不需要很复杂。我们先将几段参考资料放入一个本地文本字典里然后通过关键词权重计算召回相关片段模拟 RAG 的第一步。生产系统中通常会改成向量检索加关键词检索的混合方式。# 文件路径knowledge_store.py import re class SimpleKnowledgeStore: 一个用于演示的极简知识库按关键词命中数量选择相关片段。 def __init__(self, docs: dict): # docs 的格式为{文档ID: 文档正文} self.docs docs def search(self, query: str, top_k: int 2): query_terms set(re.findall(r[\w\u4e00-\u9fff], query.lower())) scored [] for doc_id, content in self.docs.items(): content_lower content.lower() # 统计 query 中每个关键词在文档中出现的次数 score 0 for term in query_terms: score content_lower.count(term) if score 0: scored.append((score, doc_id, content)) scored.sort(keylambda x: x[0], reverseTrue) return [(doc_id, content) for _, doc_id, content in scored[:top_k]]这里没有引入向量模型目的是让代码可直接运行并让读者看清“检索后如何进 Prompt”。实际写作系统中知识库内容可以来自公司内部 Wiki、产品文档、历史文章、竞品资料等。如果文档数量很大则必须使用 Elasticsearch、OpenSearch 或向量数据库来保证检索效率和相关性。4.3 封装写作流程接下来是核心的writing_flow.py。它会实现三个动作根据主题召回知识、生成写作大纲、再生成初稿。写好的 Prompt 被集中放在代码中方便读者理解每个字段的作用。# 文件路径writing_flow.py from llm_client import call_llm from knowledge_store import SimpleKnowledgeStore class WritingFlow: def __init__(self, knowledge_store: SimpleKnowledgeStore): self.knowledge_store knowledge_store def _build_context_block(self, query: str) - str: hits self.knowledge_store.search(query, top_k2) if not hits: return 没有检索到参考资料请根据通用知识生成但不要编造具体数据。 blocks [] for doc_id, content in hits: blocks.append(f[资料 {doc_id}]\n{content}) return \n\n.join(blocks) def create_outline(self, topic: str) - str: context self._build_context_block(topic) system_prompt 你是一名资深的专业技术编辑。你的任务是写出结构清晰、有信息增量的文章大纲。 user_prompt f 写作主题{topic} 参考资料 {context} 要求 1. 大纲需要包含引言、核心章节、总结共 5 到 7 个一级模块 2. 每个模块下给出要点或小标题 3. 不要输出与主题无关的套话 4. 如果在参考资料中发现了可用的事实请在大纲后的“资料线索”中列出。 请现在输出大纲。 messages [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ] return call_llm(messages, max_tokens1500) def write_draft(self, topic: str, outline: str) - str: context self._build_context_block(topic) system_prompt 你是一名专业的 AI 写作助手。你输出的初稿必须严谨、清楚并尽量基于参考资料。 user_prompt f 写作主题{topic} 写作大纲 {outline} 参考资料 {context} 要求 1. 根据大纲展开生成一篇不少于 800 字的初稿 2. 涉及数据、日期、版本号、引述时必须标注 [来源:对应资料ID] 3. 不能为了凑字数编造资料里不存在的事实 4. 文笔接近技术博客风格避免过分营销化的表达 5. 如果某个信息不在参考资料中请在文末“待核实项”中单独列出。 请现在输出初稿。 messages [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ] return call_llm(messages, max_tokens3000)这个流程体现了“先检索再生成”的思路。参考资料会进入 Prompt模型生成时必须以这些资料为基准。不过我们仍然不能假设模型会 100% 遵守约束因此下一步还需要用质检模块来自动检查。4.4 实现幻觉检测与质量报告qc.py是防止“一本正经胡编”的关键模块。它使用另一个 LLM 调用把稿件中的事实性陈述逐条拆出来再依据原始资料进行判断。# 文件路径qc.py import re from llm_client import call_llm def split_statements(text: str): 简单按句号、问号、感叹号切分文本。生产环境可用更完善的句子分割算法。 raw_sentences re.split(r(?[。]), text) return [s.strip() for s in raw_sentences if len(s.strip()) 10] class QualityChecker: def __init__(self, knowledge_store): self.knowledge_store knowledge_store def check(self, draft: str, topic: str) - dict: statements split_statements(draft) context self._build_context(topic) issues [] for stmt in statements: # 如果语句中包含明显的数据、年份、专有名词等信息才进入模型校验 if not re.search(r\d|20\d\d|来源|是|根据, stmt): continue verdict self._check_single(stmt, context) if verdict and 不支持 in verdict: issues.append({statement: stmt, result: verdict}) return { statement_count: len(statements), issue_count: len(issues), issues: issues, draft: draft, } def _build_context(self, topic: str) - str: hits self.knowledge_store.search(topic, top_k3) blocks [] for doc_id, content in hits: blocks.append(f[资料 {doc_id}]\n{content}) return \n\n.join(blocks) if blocks else 无参考资料 def _check_single(self, statement: str, context: str) - str: system_prompt 你是一个严格的审校员只能根据参考资料判断陈述是否被支持。 user_prompt f 参考资料 {context} 待核查陈述 {statement} 请判断该陈述是否能被参考资料直接支持。如果资料中没有足够信息请回答“不支持资料不足”。如果陈述与资料冲突请回答“不支持与资料冲突”。如果资料可以支持请回答“支持”。不要输出其他解释。 messages [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ] result call_llm(messages, temperature0.1, max_tokens300) return result这个模块的准确性依赖提示词和模型审查能力但它展示了“用大模型监督大模型”的工程落地方式。在正式产品中还可以把高风险语句交给人工复核而不是全部依赖自动结论。4.5 主流程串联最后在main.py中把知识库、写作流程和质检流程连接起来。为了便于看到效果代码中直接写入了两段示例资料。# 文件路径main.py from knowledge_store import SimpleKnowledgeStore from writing_flow import WritingFlow from qc import QualityChecker if __name__ __main__: docs { doc_1: 向量数据库Vector Database是一种专门处理向量数据的存储系统。 在 RAG 应用中文档会被切分成片段再用嵌入模型转换成向量。 检索时系统通过相似度计算找到与问题最相关的片段。 , doc_2: AI 幻觉指模型生成的内容与事实不符或没有依据。 减少幻觉的方法包括检索增强生成、引用溯源、人工审核。 高质量的数据集和清晰的提示词也能降低幻觉发生概率。 , } store SimpleKnowledgeStore(docs) topic 如何降低大模型写作中的幻觉风险 writer WritingFlow(store) print( 1. 生成大纲 ) outline writer.create_outline(topic) print(outline) print(\n 2. 生成初稿 ) draft writer.write_draft(topic, outline) print(draft) print(\n 3. 事实一致性检查 ) checker QualityChecker(store) report checker.check(draft, topic) print(f共切分出 {report[statement_count]} 条陈述发现 {report[issue_count]} 条问题。) for issue in report[issues]: print(待核查陈述, issue[statement]) print(校验结果, issue[result]) print(---)运行命令python main.py预期输出会包含三段内容。第一段是模型生成的大纲第二段是根据大纲写出的初稿第三段是质检报告。由于模型生成有一定随机性具体文字每次都会不同但整体流程应该保持一致。如果某个语句超出资料内容质检模块就会提示“不支持资料不足”。这就是 AI 写作系统比“直接让模型写”更可靠的重要原因。4.6 进一步扩展为 Agent 流程上面的流程虽然已经比“一次 Prompt 生成全文”更完善但仍然是一个线性流程检索、大纲、初稿、质检。真实场景里文章主题往往需要多轮修改一篇好内容可能要经历“生成-评审-修改-再评审”的循环。我们可以把流程中的每个阶段看成一个 Agent 节点用外部代码来控制循环。比如写一个简单的修订函数# 伪代码展示 Agent 循环思想 for round_no in range(3): report checker.check(draft, topic) if report[issue_count] 0: break issues_text \n.join([i[result] i[statement] for i in report[issues]]) revise_prompt f根据审校意见修改初稿。\n意见{issues_text}\n\n初稿{draft} draft call_llm([ {role: system, content: 你是专业编辑负责根据审校意见修订文章。}, {role: user, content: revise_prompt}, ], max_tokens3000) print(draft)实际的 Agent 框架会在此基础上加入工具调用、状态机、人工审批和日志追踪但核心思想与上面的伪代码一致。先让模型生成再让另一个模型负责“挑错”最后通过循环优化能够显著降低内容风险。5. 常见问题与排查思路问题现象常见原因解决思路生成内容经常编造来源或数据模型仅靠参数记忆写作缺少知识库约束切换到 RAG 架构强制查询参考资料并要求输出引用 ID明明给了资料模型还是不按资料写上下文太长导致关键信息被稀释压缩检索结果只保留高相关片段在 Prompt 中强调“若无资料则标注”而非“自由发挥”事实一致性检查误报过多检查逻辑把表述性、评论性句子也当成事实只在语句中包含数字、年份、版本号或“根据……数据显示”等信号时才触发模型复核API 调用超时或限流模型服务端负载较高或请求 max_tokens 过长增加重试与退避机制在客户端做超时控制必要时切换模型路由生成成本过高每条写作请求都重复上传整段知识库设置缓存优化检索策略使用摘要代替原始长文本或使用更便宜的小模型做初筛内容同质化严重提示词模板过于固定模型输出平均化在流程中增加“素材库”先抽取独特案例和观点再让模型基于素材写作用户不愿意直接采用 AI 草稿缺少人工审核与编辑器无法确认问题位置增加批注模式把事实校验结果、疑似幻觉点、引用来源高亮呈现给用户语境越来越长模型却忽略开头要求大模型对长上下文尾部更敏感把关键指令放在系统提示词和用户提示词末尾或拆分成长文本多轮生成排查时不要一上来就调整 Prompt。建议先确认知识库召回结果是否正确因为“生成问题”往往是“检索问题”的后续表现。如果召回了无关内容再好的写作 Prompt 也无法写出正确初稿。另一个容易忽略的问题是质量检测模型本身也可能产生误判。用大模型作为审校员时审校模型的 temperature 要尽量降低并且每次只输出一个简短标签。必要时可以把“支持”“不支持”和“无法判断”分开讨论减少因为提示词造成的偏差。6. 最佳实践与工程建议6.1 提示词和数据资产化管理很多团队在 AI 写作初期把提示词写在聊天软件里时间一长就难以复现。更稳妥的做法是把提示词当作代码资产管理每个版本有名称、内容和变更记录。例如在项目中创建prompts/目录用 Markdown 或 YAML 文件保存提示词模板再由 Python 读取。这样修改提示词时可以走代码评审而不是直接在线上试错。数据资产同样关键。RAG 系统中的知识库不是简单丢一堆文本进去而要经过清洗、切分、去重、权限标注、更新周期管理。否则模型会不断引用过时或冲突的文档反而降低内容可信度。6.2 人工审核节点不能省无论系统引入多少自动校验严肃写作流程都应设置“人在回路”节点。机器负责完成效率高、成本低的批量检查例如错别字、格式、篇幅、明显矛盾人负责判断内容价值、观点倾向、组织逻辑和制度合规。对于涉及媒体发布、产品公告、法律文档或重要学术内容的写作人工审核的节点建议放在“生成初稿后”和“最终发布前”两步审核最稳妥。在代码中可以为待审核状态增加字段例如pending_review、approved、rejected让工作流停在人工确认之前。这不会明显降低效率却能让风险从“模型问题”变成“流程问题”。6.3 模型路由与降级写作流程可能会用到多个模型快速小模型负责切分句子和关键词抽取强模型负责长文写作严谨模型负责事实核查。因此系统最好设计一个简单的模型路由层。例如可以在.env中配置多个模型并根据任务类型设置优先级。当某个模型服务不可用时系统自动降级到备用模型而不是直接报错。在小成本团队中也可以先使用一款较便宜的模型做全流程验证等到评测指标达到阈值后再切换更大模型。这能降低实验阶段的费用。6.4 日志与评测先行每轮调用大模型都要记录输入规模、输出 token、耗时、成本和任务类型。对于写作系统尤其要记录“知识库命中了哪些文档”“生成稿被人工修改了哪些部分”。人工修改记录是很好的训练信号系统能够知道哪些段落质量不高、哪些资料导致模型理解偏差。评测方面可以引入“幻觉率”“人工修改率”“引用完整率”三个核心指标。不要只看模型生成速度有多快重点观察一篇稿子从生成到发布需要多少审校时间。AI 写作系统的最终目标不是完全替代人而是减少人的重复机械劳动。6.5 安全边界与最小权限写作系统如果接入了企业内部知识库就一定要处理权限问题。用户通过 AI 写文档时模型只能看到该用户权限范围内的资料。否则一次简单的“帮我把相关材料整理成周报”请求就可能把未见范围内的敏感信息带进结果。在工程上检索服务必须与权限系统打通每条文档都携带访问级别。即使模型提示词拼接了参考资料也只允许拼接用户有权访问的那部分。对涉及删除、修改或发布的写作后处理操作要提供撤销机制和操作日志这些能力面对真实生产环境时比“生成质量”更重要。7. 总结与下一步方向AI 写作的“第一黄金时代”结束不代表 AI 写作失去价值而是说明简单的文本生成已经无法满足更高层次的业务要求。未来值得投入的方向是把 RAG、幻觉检测、Agent 工作流和可观测性结合起来让大模型从“写手”变成“研究助理”和“编辑辅助工具”。本文从 Ethan Mollick 的观点出发结合大模型工程实践讲清了三个重点第一知识库是高质量写作的基础先检索后生成能明显降低编造概率第二用另一个模型做事实一致性检查是可行的落地方案但要配合足够的规则与人工审核第三AI 写作系统需要按工程方式组织提示词、模型、数据、日志和权限缺一不可。你可以把本文中的代码改成自己的知识库和文档主题运行几轮后记录问题。下一步如果想继续深入可以学习向量数据库和 embedding 模型把SimpleKnowledgeStore换成一个更完整的召回系统也可以尝试引入 Agent 框架让不同模型分别承担研究、初稿和审校任务。真正值得长期积累的不是让 AI 写得多快而是让 AI 写出的内容经得起追问、来源经得起核验、流程经得起复盘。
