从“用AI写作很蠢”到工程化内容生产：完整校验流程指南

技术圈里关于“用AI写作”的争论常常被概括成一句带有强烈判断的话用AI写作是愚蠢的。这个判断并不是完全没有依据因为两种现象确实很容易被观察到第一大量生成内容看起来像文章实际上只有公共常识和空泛连接第二作者把生成结果直接发布后人名、API版本、数据来源层面的错误立刻暴露出来读者一眼就能看出问题。但把这两种现象归结为AI写作本身愚蠢等于把工具缺陷和使用方式缺陷混为一谈。以工程方式使用AI写作的开发者更清楚生成结果是否可靠取决于是否有清晰的输入规范、结构化的输出约束、事实校验步骤和人工编辑责任而不是取决于“模型能写得多像人”。接下来你会看到一个最小可复现的AI辅助内容流程它适合技术博客作者、开发者和文档工程师演示“用AI写作很蠢”这个判断在什么情况下成立以及如何通过配置、脚本和审查清单把它修正成一条可用的内容生产链路。整个流程不绑定特定厂商落地时可以使用本地部署的模型服务也可以使用通用API关键是始终保持对生成结果的可验证性。1. 当我们说“用AI写作很蠢”时指的实际是哪种坏习惯1.1 三个批评意见有现实依据但都指向不完整的工作流反对AI写作的人通常会列出三条具体理由。第一内容千篇一律。生成的文章经常使用“需要注意的是”“总的来说”“在现代社会中”这类过渡句段落结构相似观点不够尖锐。用于搜索引擎填充或低质量内容站时或许够用但在技术博客里这种段落几乎没有信息增量。第二事实不可靠。语言模型在生成涉及版本号、API名称、报错信息、价格、发布日期、历史背景等内容时会以很高的概率编造细节。它给出的文本在语法上完全正确在事实上却是幻觉。这种情况在技术文章中尤其危险因为读者会照着文章去操作。第三编辑责任缺失。很多使用AI写文章的人只是复制了一段提示词把第一次生成的结果直接发布没有第二步、第三步的审校和修改。出现错误后读者第一反应不是“这个作者没检查”而是“AI写的果然不靠谱”。这三条批评都成立但它们共同指向的不是AI写作工具而是不完整的工作流没有上下文准备没有事实校验没有编辑责任。1.2 语言模型是续写器不是事实数据库要理解为什么AI会一本正经地胡说八道需要先明确语言模型的底层机制。语言模型根据给定上下文逐个预测下一个词元最可能是什么。它学习的是文本中的统计规律而不是像数据库那样记录“某年某月某版本发布了什么功能”。当模型被问到“Spring Boot 3.2 的发布时间”时它不会去查表它会根据训练数据里出现过的相关词汇生成一个概率上最合理的答案。如果训练数据足够多答案可能是对的如果数据不足或存在干扰信息模型就会生成一个听起来很专业的错误答案。这就解释了为什么AI生成的长文看起来非常通顺。通顺来自语言概率模型而事实正确需要外部验证。一篇技术文章如果完全依赖模型自身输出那么文章越短、越接近常识可靠性越高文章越长、越涉及具体事实可靠性就越低。1.3 与其给工具定性不如给流程定性“用AI写作很蠢”这句话真正有价值的地方在于它是一个质量门槛。它提醒团队如果生成过程没有配套校验机制结果就不应该进入发布流程。把这句话改写成工程语言就是未经校验的AI生成文本默认被视为低质量内容。只有通过了结构检查、事实检查和人工编辑它才有资格称为文章。因此后续所有操作都围绕一个目标为AI写作建立可执行的流程规范让生成结果从“看起来像文章”变成“可以发布的文章”。2. 用工程方法管理AI写作先定输入输出边界2.1 好的写作提示本身就是一份技术需求文档很多人在写提示词时只写一句“帮我写一篇关于Docker的文章”。这不是提示词而是需求描述。模型没有任何判断依据它会按照训练数据里最常见的文章结构生成一篇泛泛而谈的内容。工程化的做法是把提示词当成一份技术需求文档来写。它至少需要包含以下字段每个字段都可以在后续出问题时单独调整。提示词字段作用示例角色约束语言风格和关注点你是负责微服务架构评审的技术负责人目标读者决定内容深度和术语密度有3年经验的后端工程师核心主题限定内容边界为什么服务拆分后接口调用变慢内容约束限定不准出现什么不要编造压测数据结构要求限定章节顺序和标题类型每个问题必须包含现象、排查、解决输出格式决定后续自动化处理方式Markdown使用表格写提示词时要像写需求文档一样可验证。每个字段的作用是缩小生成结果的概率空间。角色字段让模型选择匹配的语料分布目标读者字段控制专业术语的密度结构要求字段保证输出具备固定的信息骨架。2.2 用结构化输出约束模型而不是等它自由发挥普通泛化提示词会让模型输出大段连续文本。在技术内容生产流程中更好的做法是要求模型输出带结构的Markdown甚至输出JSON再由脚本转成正文。结构化输出有几个直接好处方便程序校验章节数量方便在生成后对每一节单独做事实检查方便把表格、列表、代码块分别提取出来做格式检查。一个用于技术排错文章生成的结构化要求示例输出格式要求 1. 使用Markdown。 2. 顶层标题从二级标题开始。 3. 每个问题写成一个小节小节标题必须包含“现象”“原因”“解决”三个词。 4. 每个小节结尾必须有一个“检查点”段落。 5. 如果真的不知道某个版本号写成“NEED_FACT_CHECK”。 6. 最后输出一个JSON块列出所有标记为NEED_FACT_CHECK的事实点。最后一条要求非常关键。它把模型无法确认的事实显式暴露出来而不是让模型假装知道。这样后续脚本可以自动扫描“NEED_FACT_CHECK”关键字生成一份待人工核验清单。2.3 分阶段生成不要一次请求生成全文一次性让模型生成八千字长文内容质量会随长度快速下降而且后半段可能偏离大纲。原因是模型在生成长文本时上下文窗口中的信息会被逐渐稀释前面写过的结论和后面写的内容可能出现矛盾。工程化的做法是分阶段生成第一阶段模型根据主题和读者信息输出文章大纲。第二阶段人工调整大纲删除不必要章节补充遗漏章节。第三阶段逐章调用模型每个请求只生成一个章节。第四阶段合并所有章节由脚本统一检查。分阶段生成牺牲了一点调用效率但换来的是每一段内容都更可控。合并章节时还可以让模型“只做编辑不做新增”把章节之间的衔接句统一改写。3. 最小可复现流程从提示到Markdown文件到检查脚本3.1 环境准备只需要Python和一个模型服务先看本地环境需要准备什么。这个最小流程不依赖大型框架只需要Python 3.9以上环境和能响应对话补全请求的模型服务。环境项说明备注Python3.9及以上用于运行请求脚本和检查脚本requests库用于调用HTTP接口安装命令pip install requests模型服务地址支持chat completion接口即可可以是本地服务也可以是远程服务prompt.md存放结构化提示词使用UTF-8编码示例中的模型服务地址可以指向本地启动的推理服务也可以指向云API。生产环境中模型服务地址、密钥等敏感信息不要写在代码里建议通过环境变量传入。3.2 Python脚本请求模型服务并保存Markdown下面的脚本负责读取提示词文件构造请求并把模型返回内容保存为Markdown文件。它刻意保持最小实现方便你复制后按项目要求修改。import os import json import requests import sys from pathlib import Path def generate_text(prompt: str, endpoint: str, api_key: str, model: str) - str: headers { Content-Type: application/json, Authorization: fBearer {api_key}, } payload { model: model, messages: [ { role: system, content: 你是一个严格按照提示词要求工作的技术写作助手。, }, {role: user, content: prompt}, ], temperature: 0.5, max_tokens: 4096, } response requests.post(endpoint, headersheaders, jsonpayload, timeout180) response.raise_for_status() data response.json() return data[choices][0][message][content] def main() - None: endpoint os.getenv(LLM_ENDPOINT, http://127.0.0.1:8000/v1/chat/completions) api_key os.getenv(LLM_API_KEY, local-api-key) model os.getenv(LLM_MODEL, local-model) prompt_path Path(prompt.md) output_path Path(article.md) prompt prompt_path.read_text(encodingutf-8) result generate_text(prompt, endpoint, api_key, model) output_path.write_text(result, encodingutf-8) print(f生成完成文件{output_path}) if __name__ __main__: main()这个脚本有几个设计点。第一endpoint、api_key、model从环境变量读取避免把密钥写进代码仓库。第二temperature设置为0.5既不等于0导致文本呆板也不高到每次结果跳跃过大。第三超时时间设为180秒避免长文章生成过程中请求提前中断。3.3 用检查脚本扫描泛化词和重复词生成完Markdown文件后先用脚本做一次基础文本体检。下面的脚本扫描常见的空泛词、句子长度分布和明显重复句子帮助编辑快速定位问题段落。import re import sys from pathlib import Path WEAK_PHRASES [ 需要注意的是, 总的来说, 综上所述, 在现代社会中, 随着科技的发展, 具有重要意义, 在当今时代, ] def split_sentences(text: str) - list[str]: chunks re.split(r[。!?], text) return [c.strip() for c in chunks if c.strip()] def analyze_article(path: Path) - None: text path.read_text(encodingutf-8) sentences split_sentences(text) if not sentences: print(未找到有效句子) return sentence_lengths [len(s) for s in sentences] avg_length sum(sentence_lengths) / len(sentence_lengths) max_length max(sentence_lengths) print(f段落字符数{len(text)}) print(f句子数量{len(sentences)}) print(f平均句长{avg_length:.1f} 字符) print(f最长句子{max_length} 字符) print(\n出现在文本中的空泛词) found_weak False for phrase in WEAK_PHRASES: if phrase in text: found_weak True print(f - {phrase}) if not found_weak: print( 未发现空泛词) print(\n重复句子片段超过20字符且出现2次以上) from collections import Counter counters Counter() for sent in sentences: if len(sent) 20: counters[sent] 1 repeated [(s, c) for s, c in counters.items() if c 2] if repeated: for s, c in repeated: print(f - 出现{c}次{s}) else: print( 未发现明显重复) if __name__ __main__: target Path(sys.argv[1]) if len(sys.argv) 1 else Path(article.md) analyze_article(target)这个脚本不负责判断文章是否优秀它只负责标出可疑区域。平均句长过高说明很可能出现绕口长句空泛词过多说明内容缺乏具体细节重复句子过多说明生成过程出现了复读。发现这些现象后编辑再去对应段落做二次生成或人工改写。3.4 运行结果和检查点执行流程后的正常检查顺序是运行生成脚本确认输出article.md存在。人工阅读大纲和章节标题确认没有偏离主题。运行检查脚本记录空泛词和重复句子数量。手动搜索“NEED_FACT_CHECK”把待核实事实抽出来单独处理。修改检查脚本标记的问题后再人工精读一遍。检查点不是“模型有没有输出内容”而是“输出内容是否通过了所有预定义规则”。4. 文章生成后质量验证为什么不只是读一遍4.1 验证层一事实性校验交给人工检查模型负责结构化AI生成内容的最大风险是幻觉。任何技术博客在发布前都必须对以下内容做人工核验版本号、安装命令、配置项名称、报错信息、性能数据、引用原文、数据来源、官方文档链接。不要指望模型输出“NEED_FACT_CHECK”就一定可靠。模型可能漏标也可能在提示词约束下仍然写出错误版本。建议在编辑阶段使用单独的核验清单把文章中的事实点逐条复制到搜索引擎中验证。这里推荐一个做法在文章生成时要求模型把所有外部事实用占位符标记例如{{FACT:Spring Boot 3.2发布时间}}。脚本扫描占位符后生成一张表格人工在表格中填写验证结果。这样事实核验就从“通读全文发现问题”变成“按列表逐项确认”。4.2 验证层二文本特征统计辅助编辑人的阅读习惯会被流畅的生成文本“欺骗”尤其是第一次阅读时很容易被连贯的逻辑掩盖细节问题。用脚本检查文本特征可以弥补这一点。需要关注的统计指标包括平均句长、段落长度、代码块比例、表格数量、空泛词出现频率。“代码块比例”和“表格数量”这两个指标对技术文章尤其重要。如果一篇技术文章占了大量篇幅却没有任何代码块说明内容可能停留在概念层面没有落到具体操作。如果排错文章没有表格也可能缺少问题对比。建议把检查指标写成可配置的阈值。例如平均句长超过40字符时告警空泛词超过5个时告警每千字代码块少于1个时告警。阈值可以根据文章平台和主题调整但不要只凭感觉。4.3 验证层三发布后追踪反馈很多内容质量问题不是发布前能全部发现的发布后的读者反馈同样是验证数据。技术文章发布后要主动收集三类反馈。第一类是更正请求。读者留言说“第二步的命令在我这里报错了”这通常意味着文章缺少环境差异说明。第二类是补充请求说明文章覆盖范围不够。第三类是时间戳问题文章中提到的版本和依赖已经过时需要在文章末尾增加“更新时间”字段。把这个验证层写进生产流程比每次都从头写文章更重要。一篇文章的价值不在于生成时花了多少时间而在于发布后能被多少人顺利复现。5. 用AI写技术文章时人该负责什么5.1 人和AI的分工必须有边界用“人机协作”四个字概括AI写作容易落到具体操作时却经常出问题。边界不清晰时人会逐渐变成只负责粘贴输出的工具AI的错误就全部流到读者面前。一种比较可靠的分工是按“风险等级”划分。工作环节AI负责程度人负责程度风险点确定选题和技术观点低高选题错误会浪费整篇文章生成文章大纲中中大纲需要人工筛选生成章节初稿高低内容可能偏离给定结构事实核验低高版本号、命令、配置项代码示例验证低高必须实际运行确认语言润色中高保留个人风格发布和更新低高发布前最终检查AI适合做“初稿扩展”和“语言转化”人适合做“判断”和“验证”。如果让AI负责判断技术观点或让人负责机械复制流程都会出问题。5.2 技术事实、版本号和错误码绝不能直接信任生成结果技术文章最容易被批评的地方就是事实错误。一个常见的错误是AI生成的代码示例看起来逻辑完整但其中用到的函数在某个版本已经被废弃或者服务名称与实际产品不一致。写作规范建议所有代码示例必须在本地或测试环境实际运行。所有命令中的参数必须在线上文档中核对。所有版本号必须标注“写文章时的版本”。所有报错信息必须来自真实日志不能来自模型生成。不确定的内容直接删掉不要用模糊表达掩盖。这条规范虽然增加了工作量但它正是“用AI写作很蠢”和“用AI写作可靠”的分界线。5.3 建立“绝对不交给AI”的排除清单有些内容即使增加提示词和校验脚本也不建议交给AI生成。第一类是涉及个人判断的技术选型结论。AI可以列出A方案和B方案的优缺点但“我们团队为什么选择B”这个问题必须由人来写因为这涉及业务背景、团队能力、历史包袱和长期维护成本。第二类是在实际环境中读取到的敏感信息。不要把服务器IP、数据库连接串、日志中出现的用户信息交给远程模型服务。如果需要AI辅助总结内部日志应该在本地私有化部署模型或者先对数据进行脱敏。第三类是需要在多个页面之间保持一致性的内容。模型每次生成都是独立上下文容易出现前后矛盾。如果文章是系列教程AI只负责单篇初稿整体系列的技术口径必须由人来维护。6. 从“看起来像文章”到“真的是文章”关键动作清单这一节给出一个发布前动作清单适用于个人博客和团队内容发布流程。它不是通用模板可以按项目情况裁剪但建议至少执行其中前六项。检查选题是否具有明确技术价值。如果文章只是把官方文档改写了不要发。检查文章是否有可复现的示例。没有代码、命令、配置或数据结构的文章读者无法验证。检查所有代码块是否能在干净环境运行。常用方法是准备一台空虚拟机按文章手动走一遍。检查所有版本号是否标注。推荐写成“本文写作时使用Spring Boot 3.2.1”的格式。检查所有外部链接是否有效。生成模型可能编造出指向不存在页面的链接。检查事实占位符是否全部清理。NEED_FACT_CHECK不能出现在最终正文中。检查文本统计指标。空泛词出现的频率是否过高平均句长是否过长。检查“结论”部分是否由人补充。AI写的结论通常只是前文总结缺少作者自己的判断。检查发布时间和更新日期是否明确。技术内容有强时效性不标注日期会对读者形成误导。检查文章是否带有原文出处声明。如果大量引用官方文档必须标明来源。清单的作用不是增加流程负担而是在发布时把风险控制在可接受范围内。每检查一项出错的概率就下降一截。7. 常见陷阱和排错路径7.1 现象生成内容全是空话没有具体信息可能原因提示词缺少“内容约束”模型不知道要写具体步骤。输入大纲本身缺少事实素材模型只能在概念之间打转。检查方式查看提示词中的“内容约束”字段是否存在。查看生成结果中代码块、表格、命令的数量。处理方式在提示词中补充“必须包含至少一个可运行命令”或“必须包含至少一个参数对比表”的硬性要求。把真实的项目背景和已掌握的信息作为上下文输入不给模型自由发挥空间。预防分阶段生成时每个章节都单独给素材避免模型从零开始“编造”。7.2 现象内容包括明显错误版本号或过期API可能原因模型训练数据滞后不知道最新版本。生成时没有遵守“不确定就标记为NEED_FACT_CHECK”的约束。检查方式搜索文章中的版本号逐个与官方发行说明对比。在预发布脚本中增加“NEED_FACT_CHECK”扫描。处理方式把不确定的版本号直接删除或替换成“请参照官方文档”。在提示词中增加更强约束“如果训练数据中不存在该信息必须写NEED_FACT_CHECK不得猜测”。预防把官方文档的最新版本信息作为上下文注入提示词。7.3 现象生成结果不遵守格式要求输出JSON失败可能原因模型在长输出时不稳定结构约束被遗忘。提示词中的格式要求和任务描述混在一起模型没有完整读取。检查方式查看是否输出了部分JSON解析失败时定位到截断位置。检查提示词是否有独立且靠后的“输出格式”段。处理方式把格式要求放在提示词末尾靠近期望输出位置。使用更稳定的方案先让模型输出纯JSON程序将JSON转成Markdown而不是让模型直接输出Markdown。预防在程序侧加入重试机制当JSON解析失败时自动让模型重新生成一次。7.4 现象耗时很长或请求超时可能原因单次请求文本长度过大模型推理时间成倍增长。远程服务负载较高响应变慢。检查方式查看请求的max_tokens设置。记录请求开始和结束时间统计单次生成耗时。处理方式减小单次生成长度一个章节一个请求。设置HTTP超时时间超时后重试。预防生产环境中为生成服务增加队列和重试机制避免因为超时导致整篇文章流程失败。以下表格概括这四类问题便于排错时快速定位。问题现象常见原因检查方式处理建议内容空泛提示词缺少内容约束和素材检查代码块、表格数量补充具体素材和硬性结构要求版本号错误模型输出幻觉或训练数据滞后与官方文档核对版本号删除不确定信息强制标记NEED_FACT_CHECK输出格式违规结构约束在长输出中失效解析JSON定位截断位置分离任务与格式增加重试机制请求超时单次生成文本过长记录请求耗时分章节生成降低单次长度8. 结束语让“写作愚蠢”的判断变成一种质量门槛回到最开始那句话“用AI写作很蠢”。如果这句话描述的是不做校验、不做人工编辑、不验证事实、直接发布生成结果的流程那么它确实是准确的。但如果这句话被当成“不应该使用AI写作”的结论它就过于简单了。在这个领域真正的工程问题是如何把AI生成过程纳入一个可控的质量流程。准备结构化提示词约定输出格式分阶段生成用脚本扫描空泛表达强制标记待验证事实最后让人完成代码验证、版本核对和观点判断。这套流程不复杂也不需要大型基础设施但它能把生成风险从“随缘”变成“可控”。以后当有人评价“用AI写作很蠢”时可以把它当成一个测试看看对方的流程里有没有验证环节。如果没有这句话是对的。如果有这句话需要改成“草率地用AI写作很蠢”。把判定标准从工具转移到流程才是AI写作真正进入工程实践的开始。