一件有点反常的事是：一个 7B/8B 级别的小模型，花大约 50 美元训练账单，就能写出一点 1990 年代微软技术手册的味道。

这不是微软官方项目，也不是商业发布。它是一名技术写作者做的个人实验：把 Bitsavers/Internet Archive 上的微软旧文档整理成语料，用 QLoRA 给 Llama 3.1 8B 和 Qwen 2.5 7B 训练适配器。

我更在意的不是“AI 能不能写文档”这个大问题，而是一个更窄的问题：低成本微调，能不能把小型本地 LLM 训练成可信的技术文档风格模仿者？

这次答案比较清楚：能摹形，但不能负责。

实验怎么做：旧手册语料，加 QLoRA 适配器

语料来自 Bitsavers/Internet Archive 收录的微软旧文档集合，覆盖 1977 年到 2005 年的过期手册，总规模约 3700 万词。

作者下载 OCR 文本后，用 Python 清理索引、前言等噪声。又通过 OpenRouter 调用 gemma-4-26b，对段落做保留或丢弃分类。这一步成本约 8 美元。

最终，语料被整理成 192456 条 JSONL 训练样本。

训练方式是 QLoRA。也就是说，作者没有从零训练一个新模型，而是在冻结底座模型权重的前提下，训练较小的 LoRA 适配器。训练跑在 Runpod GPU 上，总训练支出约 50 美元。

这个数字要小心看。50 美元只是这次个人实验里的训练账单，不包括数据清洗、人力时间、失败运行和反复调参成本。它不能直接换算成企业生产成本。

项目事实对读者的含义
语料Bitsavers/Internet Archive 微软旧文档，约 3700 万词风格密度够高，实验才有意义
样本192456 条 JSONL 训练样本不是随手喂几篇文档就能复现
方法QLoRA 训练适配器成本低，但受底座模型能力限制
模型Llama 3.1 8B、Qwen 2.5 7B 及多个微调版本面向本地运行和个人/小团队试验
成本Runpod 训练约 50 美元只能代表训练支出，不能代表稳定生产成本

作者也明确说明：非商业、非附属，不分发模型和适配器。这个边界很重要。

它更像一份技术写作者的实验笔记，不是一个可以采购的“微软文档生成器”。

结果如何：Qwen 更像旧手册，但也会认真胡编

测试任务有三个：给 C 函数 malloc() 写文档，给虚构 Win32 API ConnectWifi() 写文档，用 1990 年代微软手册风格解释 REST API。

未微调模型表现并不好。它们更容易输出今天常见的 Markdown、教程式说明，或者干脆不能稳定完成任务。非指令版 Llama base 表现尤其差。

微调后，差异拉开了。

Qwen 系列整体更能保留旧式技术文档的章节结构、正式语气和术语节奏。Qwen-192k 在 REST API 测试中表现最好，能把一个更偏现代的概念，写成类似 Windows 2000 Resource Kit 的章节开头。

Llama 微调版本也能学到一些格式和腔调，但更容易滑回现代说明文。它像是在“套模板”，Qwen 更像是在“续写旧手册”。

测试项观察结果说明的问题
malloc()微调模型更容易生成旧手册式结构风格、栏目、语气可以被学进去
ConnectWifi()有的模型会编出常量、平台要求、交叉引用风格越像，幻觉越有迷惑性
REST APIQwen-192k 表现最好强风格迁移可以包装现代概念
base model非指令模型表现很差微调不能弥补所有交互能力缺口

最值得警惕的是 ConnectWifi()。这是一个虚构 API。

有的模型会识别设定，提醒它不存在。有的模型会顺着 90 年代微软文档腔，认真编出参数、常量、平台要求和 See Also。

这就是技术文档里最危险的地方：不是写得不像，而是写得太像。

作者还观察到，rank 和 epoch 会影响拟真程度和幻觉倾向。rank 较低的适配器有时更忠实地模仿腔调；rank 16 加较少 epoch 的组合，反而更容易把相近概念拉进来，出现 SOAP 等错配内容。

这也说明，它不是“调大参数就更好”的简单问题。风格、事实和服从设定之间，会互相拉扯。

对文档团队和开发者意味着什么：能进草稿流，别进终审位

对技术写作者和文档团队，这类微调最现实的用法不是替人写终稿，而是内化风格指南。

如果团队有大量干净的历史文档、API 说明、产品手册，可以考虑把小模型微调成草稿助手。它可以帮忙生成接近公司口径的初稿，也可以做一点风格一致性检查。

但采购和流程上要保守。文档团队不该因为“50 美元训练”就把它当成可上线系统。更合理的动作是：先选一个低风险文档类型试点，把模型产出放在人工审校之前，而不是之后。

对关注本地 LLM 和微调实践的开发者，这次实验给的信号也很具体：如果目标是“写得像”，微调比 RAG 更直接；如果目标是“说得准”，RAG 或检索校验仍然更关键。

两条路线不要混用概念。

RAG 是把事实从资料库里找出来，适合回答“这个接口真实参数是什么”。QLoRA 风格微调是把语气、结构、表达习惯压进模型，适合回答“这段文档要写成什么腔调”。

需求更适合的路线风险
查内部事实、参数、版本RAG / 检索增强检索质量差会答错
学公司文档口吻QLoRA 风格微调会把旧错误和坏习惯一起学进去
写第一版草稿微调模型 + 人工审校草稿看起来可信，但事实未必可靠
生成可发布终稿不宜只靠微调模型缺少判断、责任和边界控制

我不太买账的是，把这类实验直接包装成“本地小模型替代技术写作者”。证据还到不了那一步。

技术写作的难点不只是排出 Synopsis、Parameters、Return Value、See Also。真正难的是知道什么该写，什么不能写，什么看似合理但会误导用户。

接下来更该盯三个变量。

一是语料是否足够干净。OCR 噪声、过时 API、旧手册里的错误，都会被模型学进去。

二是模型能否稳定服从事实边界。尤其是在虚构 API、时代错置概念、过期平台要求上，不能只看文风像不像。

三是团队有没有审校流程。没有人工控制，风格微调越成功，错误越难被一眼看出。

回到开头那个 50 美元的数字，它的价值不是证明“廉价 AI 写作者”已经来了。

它证明的是另一件更实际的事：小模型已经可以低成本学会组织语气和文档形状。至于文档能不能发布，仍然要靠人来取舍和负责。