ChatGPT审稿实战：如何用AI提升技术文档质量与效率-编程实验室

背景痛点：人工审稿的“三座大山”

写技术文档最怕什么？不是没内容，而是写完没人敢拍板“可以发”。传统人肉审稿往往卡在三件事上：

术语不一致。同一篇文章里“微服务”一会儿叫“micro-service”，一会儿叫“MS”，一会儿又成了“服务拆分”。人工肉眼扫，十页以内还能忍，百页以上直接崩溃。
逻辑漏洞。步骤 3 引用的配置在步骤 2 里被删了；图 5 的箭头指向 404 页面。这些“断链”靠人找，得把文档和代码仓库两边来回切，耗时翻倍。
格式错误。代码块没高亮、表格列宽失控、标题层级跳级。正则写一条能抓一条，但规则一多就变成“正则地狱”，维护成本比 bug 还高。

这三座大山把发布时间卡得死死的。我们组曾统计过，平均一篇 8000 字的技术博客从 PR 到合并要 4.5 人时，其中 70% 花在“挑小毛病”上。于是把脑筋动到了 ChatGPT 身上：既然它能写，能不能审？

技术方案：正则 vs AI 的“降维打击”

先放一张最简架构图，后面代码就按这个链路串。

传统正则方案像“安检仪”，关键词命中就报警；AI 方案更像“同行评审”，先读再理解，再给意见。优劣直接摆表：

| 维度 | 正则匹配 | ChatGPT 审稿 | |----| |---| | 召回率 | 低（只能抓已知模式） | 高（理解上下文） | | 误报率 | 高（“Ctrl+C”被当成错别字） | 低（可要求只输出确认问题） | | 维护成本 | 随规则线性增长 | 调一次 Prompt 通用多篇文章 | | 扩展性 | 差（新增风格得加规则） | 强（换温度就能切换严格/宽松） |

一句话：正则适合“守底线”，AI 适合“拔上限”。两者不是替代，是互补。

代码实现：30 行 Python 跑完审稿闭环

下面给出可直接跑的脚本，依赖只有 openai 库（v1.x 版本）。重点看三个细节：重试、Prompt 工程、结果解析。

import re import time from typing import List, Dict import openai from openai import OpenAI client = OpenAI(api_key="sk-xxx") # 放环境变量更安全 ROLE_PROMPT = """ 你是一位有 10 年经验的技术写作专家。请对下方技术文档进行审稿，仅返回结构化 JSON，禁止额外解释。 检查点：1.术语一致性 2.逻辑断链 3.代码格式 4.标题层级。 JSON 格式: [{"line":<int>,"type":"<term|logic|format|heading>","desc":"<问题描述>","suggestion":"<修改建议>"}] """ def call_gpt(text: str, model: str = "gpt-3.5-turbo", temperature: float = 0.2) -> str: """带指数退避的重试封装，限流友好""" for attempt in range(1, 6): try: response = client.chat.completions.create( model=model, messages=[ {"role": "system", "content": ROLE_PROMPT}, {"role": "user", "content": text} ], temperature=temperature, max_tokens=1500 ) return response.choices[0].message.content except openai.RateLimitError: wait = 2 ** attempt + 1 print(f"Rate limit hit, retry after {wait}s") time.sleep(wait) except Exception as e: print(f"Unexpected error: {e}") time.sleep(1) raise RuntimeError("Max retry exceeded") def parse_gpt_json(raw: str) -> List[Dict]: """正则抠 JSON 数组，容错率更高""" match = re.search(r"(\[.*\])", raw, re.DOTALL) if not match: return [] try: import json return json.loads(match.group(1)) except json.JSONDecodeError: return [] def review(text: str) -> List[Dict]: raw = call_gpt(text) return parse_gpt_json(raw) if __name__ == "__main__": with open("sample.md", encoding="utf-8") as f: issues = review(f.read()) for i in issues: print(f"L{i['line']} [{i['type']}] {i['desc']} -> {i['suggestion']}")

运行效果示例：

L37 [term] "k8s"与"Kubernetes"混用 -> 建议统一为"Kubernetes" L81 [logic] 图 4 链接 404 -> 确认图片路径或是否遗漏提交

Prompt 里把“只返回 JSON”写死，能砍掉 90% 的废话；temperature=0.2 让输出稳定，几乎不会放飞。正则parse_gpt_json是为了防止模型偶尔在代码块外多打一行解释，容错解析保证下游 CI 不会炸。

生产级考量：速率、限流与敏感信息

速率与限流
官方默认 3 RPM/60K TPM，对单篇 8K token 的文档够用，但批量跑 200 篇就会 429。折中方案：把文章拆段为 2K token 的滑动窗口，每窗口留 500 token overlap，既避免截断上下文，又把并发量降到 1/4。再配合上面代码的指数退避，基本不会被限流拍死。
敏感信息过滤
代码里常带内网 IP、密钥名，虽然 GPT-3.5 不存储数据，但合规团队仍要求“先脱敏再上传”。用 Presid 框架的固定词典即可：ip → 、password → 、ak → 。审稿完再反向替换，保证报告行号对齐。
成本核算
按 0.002$/1K token 算，一篇 8K 输入 + 1K 输出 ≈ 0.018$，合 0.13 元。对比 4.5 人时 × 200 元/人时，成本只剩千分之一，ROI 肉眼可见。

避坑指南：别把 AI 当“甩锅神器”

三原则
- 先规则后模型：用正则守住底线（比如代码块必须带语言标记），再让 AI 拔高。
- 人审最后一关：把 GPT 意见当“初筛”，合并前仍需人工点 head。
- 变更可回溯：审稿结果写回 PR comment，@原作者，保留完整上下文，方便回滚。
量化指标
我们用两指标衡量效果：
- 误报率 FP = AI 报出的问题中人工忽略的比例，目标 <15%。
- 漏报率 FN = 人工事后补充的问题 / 总问题，目标 <10%。
  跑一个月后发现，temperature 0.2 时 FP 12%、FN 8%，在可接受区间；temperature 升到 0.7，FP 飙到 30%，基本没法看。数字说话，比拍脑袋调参靠谱得多。