AI网文写作实验笔记（一）：为什么你改了一百次提示词，效果还是没有提升？

0. 这个系列是什么，不是什么

开门见山说清楚：

这不是"一键写网文"的工具教程，也没有万能提示词。
这个系列记录的是：我怎么用做科学实验的思路，系统性地改进AI写网文的效果。

如果你只是想找个工具帮你快速出稿，这个系列不适合你。
如果你已经改了几十上百次提示词，但永远说不清"这次改完到底有没有变好"，永远在"好像变好了"和"好像又变差了"之间反复横跳，那这个系列就是写给你的。

---

它能帮你解决什么，不能帮你解决什么

我必须先把边界说清楚，避免你浪费时间：

✅ 它能帮你解决：

1. 所有可以被规则量化的基础问题：格式合规、禁用词、固定的人物设定有没有写错、每段是不是太长，等等
2. 更重要的是：把"这次改完提示词到底有没有变好"这个问题，从"主观感觉"变成"可量化的对比"。你不用再靠"我觉得好像变好了"做判断，你可以跑20次生成，统计成功率，用数字说话

❌ 它不能帮你解决：
文笔、节奏、人物一致性、情绪张力这些网文最核心的主观质量问题。不仅我解决不了，估计现在整个领域都没人能很好地解决。

它不能直接帮你写出更好的网文，但它能帮你排除掉90%的无效实验，让你每一次改进都是扎实的，不会在原地兜圈子。

---

1. 我是怎么把自己逼到要搭这套框架的

我之前写过一篇《LLM长篇网文生成：从API推理到QLoRA微调的完整实验与失败分析》，记录了我第一次完整尝试的全过程。

写完之后复盘的时候我发现，我犯了一个非常典型的错误：最基础的工程化和提示词实验都还没做系统，就直接跳到下一步去搞微调了。

失败简直是理所当然的。

然后我去用了用市面上的商业化写作工具，写的虽然说不上很惊艳，就是中规中矩的，但比我自己微调出来的效果还是好很多。

这说明方向错了。不是模型不够好，是我连最基础的实验方法都没有。我连"改一行提示词到底带来了多大变化"都测不准，就算给我再好的模型，我也用不好。

我相信你肯定也遇到过这三个问题：

第一个问题：主观判断永远靠不住。
你改了提示词里的三句话，跑了两次生成，读了一遍，觉得"嗯，好像效果变好了"。
过了两天再跑两次，又觉得"好像还不如之前那个版本"。
你永远说不清，到底是这次改的提示词真的更好，还是你当天的心情更好。

第二个问题：结果永远不可复现。
同一个提示词，同一个模型，同一个参数，上周跑出来的内容惊为天人，这周再跑就像个弱智。
你翻遍了git提交记录，确认代码一个字都没改，但就是跑不出上次的效果了。
你永远不知道到底是模型偷偷更新了，还是你上次只是运气好。

第三个问题：试了几十种写法，最后根本记不清哪个好。
你试了十几个提示词的写法，存了几十个版本，每个版本跑了几次。
一周之后回头看，你根本记不清哪个版本对应哪个效果，哪些改动是真的有用，哪些只是你的错觉。

所有这些问题的根源，都是同一个：你在做没有对照组的实验。
你所有的判断都是基于主观感觉，而人的感觉是最不可靠的。

所以这次我决定：不搞什么高大上的微调了，回头从最基础的地方开始，搭一套完全属于自己的实验框架，每一步都做彻底的对比实验，用数据说话，不拍脑袋，不做想当然的假设。

这个系列就是整个过程的完整记录。

---

2. 解决思路：四个核心实验原则

要解决上面三个问题，你不需要什么复杂的技术，你只需要一套最基础的实验规范。
在做任何实验之前，我先给自己定了四条硬规则，所有的工具和架构都围绕这四条展开。如果你也想做系统性的改进，这四条建议你直接抄走。

---

原则 1：所有实验必须 100% 可复现

什么叫 100% 可复现？
任何人拿着你的代码、你的提示词、你的参数，跑出来的结果，必须和你跑的一模一样。
任何一个结果，你都能精准还原当时用了什么提示词、什么参数、什么模型版本。
不需要你做任何额外解释，不需要补充任何信息。

这是区分"做实验"和"随便试试"的标准。如果你跑出来一个好结果，但再也复现不出来，那这个结果等于没有。

---

原则 2：对比实验只能有一个变量

任何时候你想测试"提示词A和提示词B哪个更好"，除了提示词本身之外，所有其他东西必须完全一致：

• 模型、温度、top_p 所有参数完全一样
• 输入的设定内容完全一样
• 甚至连请求发送的时间都尽量差不多

只要有第二个变量，你就永远不知道到底是哪个因素起的作用。
最常见的错误就是：改提示词的时候顺便把温度从0.7调到了0.8，最后效果变好了，根本说不清是提示词的作用还是温度的作用。等于白做。

---

原则 3：能自动评估的就不要用人看

只要是人看的，就会有偏差，就会有标准不一的问题。今天的你和明天的你，对同一段内容的判断都可能完全相反。

当然我知道，网文最核心的质量——文笔、节奏、人物一致性、情绪张力——没有任何办法用自动化规则评估。这是整个领域的难题，我也解决不了。

但有很多基础问题是完全可以自动评估的：

• 有没有出现禁用词
• 每段是不是太长了
• 人物的名字、称号有没有写错
• 有没有出现和设定里的事实描述矛盾的内容（比如设定里说角色用剑，正文写成用刀）

注意：这里说的只是事实层面的一致性，不是人物的性格、说话方式、行为逻辑这些创作层面的一致性。后者属于质量问题，我也解决不了。

这些基础问题虽然低端，但靠人检查非常累，而且很容易漏。能让机器做的，就不要让人做。把人的精力留给真正需要主观判断的地方。

---

原则 4：所有中间结果必须完整存下来

不要只打印一个成功率就完事了。每一次 API 返回的完整内容，必须全部存在磁盘上。

三个好处：

1. 可追溯：任何时候回头看，都能知道当时具体生成了什么
2. 可回溯：事后想到一个新的评估维度，可以直接拿旧的结果重新统计，不用再花几百块重新跑一次
3. 可对比：想知道两个提示词哪个更好，直接把两组的所有生成结果放在一起对比，不用靠记忆

---

3. 基于这四个原则的三层架构

我搭三层架构的时候，顺序不是先画图再写代码，而是反过来：先定了上面四条原则，然后一步步推导出每层该做什么。

下面的四步推导，就是当时从原则推导出架构的思考路径。写出来是为了让你理解为什么这么拆，而不是让你也重新推导一遍。

---

第一步：提示词必须和代码完全分离。
因为原则 2 要求对比实验只能有一个变量。如果提示词写在 Python 字符串里，改一个字就要改代码，很容易不小心改到别的逻辑，做对比实验的时候根本没法保证只有一个变量。
所以必须把所有提示词抽成单独的文件，和代码完全分开。改提示词，就只改提示词文件，不用碰任何代码。

第二步：具体生成逻辑，必须和流程控制完全分离。
因为原则 3 要求自动化评估，流程控制代码必须非常稳定，不能每次加个新的生成逻辑就要改流程。所以把"怎么写大纲"、“怎么写章纲”、"怎么写正文"这些具体的生成逻辑，全部单独抽出来，叫 Generator 层。
Pipeline 层只负责流程：先调哪个 Generator，拿到结果之后再调哪个，中间做什么校验，最后存到哪里。Pipeline 不碰任何具体的提示词，Generator 也不知道自己是在什么流程里被调用的。

第三步：所有底层调用，必须再包一层抽象。
因为原则 1 要求 100% 可复现。如果所有 Generator 都直接调 OpenAI SDK，以后换模型就要改十几处地方，很容易改出不一致。所以把 LLM 调用、模板渲染这些底层操作全部抽成 Core 层，提供统一的接口。换模型、改重试逻辑、加统计，只改 Core 层一处，所有上层全部自动生效。

第四步：实验脚本必须和主引擎完全分离。
因为原则 4 要求所有中间结果可追溯。做实验的脚本，绝对不能改主引擎的任何代码，不然你根本不知道实验结果的差异是因为改了脚本还是改了引擎。所以所有实验脚本全部单独放在 scripts/ 目录，只调用 Core 层的接口，和主引擎完全隔离。

---

基于这四步推导，最终就得到了三层架构，核心思想就是四个字：单一职责。

层	职责	可以碰什么	绝对不能碰什么
Core 层	基础抽象	LLM 调用、模板渲染	不能有任何业务逻辑
Generators 层	具体生成	只能调用 Core 层的 LLMProvider	不能直接读文件、不能直接存盘
Pipeline 层	流程控制	只能调用 Generators，不能直接调 LLM	不能在 Pipeline 里写任何提示词

---

outline 和 plan 的区别：outline=粗大纲（每章标题+一句话剧情），plan=章纲（完整的剧情点+场景拆分），后面整个系列统一用这个叫法。

---

最终目录结构

基于上面的三层架构，最终的目录结构非常清晰，我只列核心的部分：

ai-novel-engine/
├── novel.py                   # CLI入口，只做命令解析，不碰业务逻辑
├── engine/
│   ├── core/                  # 最底层抽象，只做两件事：LLM调用、提示词渲染
│   ├── generators/            # 所有具体的生成逻辑，只调用core层，不读文件不写盘
│   │   ├── outline_generator.py  # 生成粗大纲
│   │   ├── plan_generator.py     # 生成章纲+冲突检测
│   │   └── scene_generator.py    # 拆分场景+写正文
│   ├── pipeline/              # 流程控制，只调用generators，串起整个生成过程
│   └── prompts/               # 所有提示词，单独目录，和代码完全分离
└── scripts/                   # 实验脚本，和主引擎完全隔离，绝不修改主引擎代码

每个小说项目自己的目录结构：

我的小说项目/
├── project.yaml               # 项目配置（模型、参数、书名）
├── 设定/                      # 世界观、人物、全书大纲
├── 章节/                      # 生成好的章节内容
└── ab_test_results/           # 所有对比实验的结果自动存在这里

整个结构的设计思路非常简单：任何一个改动，你都只需要改一个地方。改提示词就改prompts目录，改生成逻辑就改generators，改流程就改pipeline，做实验就写scripts。绝对不会出现"改了一行代码影响了三个功能"的情况。

---

核心架构设计原则

---

1. 三层隔离，单一职责

前面已经讲过了，这里再强调一次这个设计的权衡：

好处：

• 改提示词只改 YAML 文件，不用碰代码，做对比实验非常方便
• 改流程只改 Pipeline，不会不小心改到生成逻辑
• 换模型只改 Core 层，上层代码一行都不用动
• 每一层都可以单独写单元测试，非常好测

代价：

• 代码量变大，多了一层抽象
• 加新功能要跨好几个文件，没有单文件脚本那么爽

为什么我愿意付出这个代价？因为我之前单文件写爽了，改了三次之后就彻底乱了，到最后根本没法做对比实验，根本不知道改了哪一行导致效果变化。
长痛不如短痛，前期多写点分层代码，后期省无数麻烦。

---

2. 所有提示词必须抽离 YAML，绝对不能硬编码在代码里

这是我踩的第一个大坑，所以放在最前面说。

第一版我把所有提示词全写在 Python 字符串里，改一个字就要翻几百行代码，做对比实验的时候要把整个函数复制一份改，最后出来两个几乎一样的函数，根本分不清哪个是哪个。

现在所有提示词都抽成单独的 YAML 文件，代码里只做变量注入。这么做的最大好处就是：做提示词对比实验的时候，根本不用改代码。 直接新建一个 YAML 文件，改个文件名参数就可以跑对比组，完美符合"一个变量"原则。

---

3. CLI 三命令体系

我给最终用户暴露的就是三个命令，覆盖所有使用场景：

# 最快，只看粗大纲，不写正文
novel outline 2

# 中等，快速写草稿，不校验不修正
novel draft 1

# 最慢，完整全流程，生成 + 校验 + 自动修正
novel write 3

---

4. 最小生成效果展示

说了这么多，最后还是要看实际输出长什么样。这里放一个最基础的例子，用 novel outline 3 命令生成的第三章粗大纲：

# 第3章 掌门殿对峙

陆清玄带着前任掌门的手谕，孤身一人闯进掌门殿，当众揭穿现任掌门谋害前任的真相。掌门震怒，下令拿下陆清玄，几位长老立场分裂，有人站掌门有人想保陆清玄。双方对峙一触即发，陆清玄拿出第二份证据。

大概就是这个水平：标题+一句话核心剧情，包含人物、冲突、转折点。

我不对这段内容的质量做任何评价，任何一个免费模型都能写出类似的东西。

但真正的差别不在这段内容本身，而在：我知道它为什么是这个水平，我知道改提示词的哪一部分能影响哪一块的输出，我可以做十组对照实验，准确地测量每一次改动带来的变化幅度，并且可以复现每一次的结果。

而如果你只是在大模型聊天框里改提示词，你就算改一百次，你也说不清到底是哪一句起了作用，下次再跑还能不能复现这个效果。

这就是差别。输出水平普通没关系，我们可以一步步改进。最怕的是你永远在瞎试，永远不知道为什么变好，也不知道为什么变差。

---

下一篇预告

Part 1 搭好了实验框架。但框架只是起点——在做任何实验之前，我遇到了一个必须先回答的问题：

AI 的输出到底有多随机？

同一个提示词，跑 50 次，最好和最差能差多少？如果我自己都没搞清楚随机波动有多大，那后面一切"改完提示词效果变好了"的结论，都可能只是运气。

所以 Part 2 会做两件事：

1. 先跑一个 50 次的稳定性实验——搞清楚 AI 本身的随机基线。没有这个，整系列的结果都可能站不住
2. 再跑第一个对照实验——写下一章时到底要给 AI 塞多少上文？零上下文、上一章全文、前三章全文、摘要+一章，四组各跑 20 次

结果出来之前，我自己也不知道哪个会赢。但更重要的是——我会先告诉你为什么稳定性实验是所有实验的前提，以及如果跳过这一步会得出多离谱的错误结论。

---

附录：本系列统一评估标准

本系列所有实验的评估严格遵守统一的公开标准，确保可复现、可验证。以下是核心指标定义，完整最新版手册永远可以在[项目仓库链接]找到，当前版本v1.0。

核心原则

1. 疑错从无：任何模棱两可的内容，一律不算错误
2. 只算硬错误：所有错误都是非黑即白的事实错误，不包括主观好坏判断
3. 全程透明：所有错误必须定位到具体句子，所有原始数据全部公开

事实错误类（自动化评估优先）

指标	定义
人物名称错误	人名、称号、称呼写错，张冠李戴
数值/设定矛盾	和已确定的数值、设定、规则冲突
事实反转	之前已经发生的事件被遗忘、被写反
空间位置矛盾	角色瞬间移动，没有合理过渡

人工评估类（必须2人独立盲测，相关系数≥0.7才算有效）

所有人工评分都有明确的锚点标准，不是拍脑袋打分：

• OOC程度（0-3分）：角色行为是否符合核心人设
• AI腔程度：统计固定网文套话的出现次数
• 继续阅读意愿（1-5分）：看完想不想看下一章
• 整体好看度（1-5分）：单纯评价写得好不好看

统计检验标准

• 所有结论必须同时报告p值和效应大小
• p<0.05才认为统计显著
• p≥0.05一律认为"没有足够证据证明两组有差异"

没有任何黑箱，没有任何拍脑袋的判断。所有标准公开，所有数据公开，所有人都可以复现。