LoveCTO引子：真正的坑，不在写不出来，在写完之后
上一篇写了怎么给「写剧本」这件事单独造一个 AI —— 一个只有剧本、没有公众号排版的干净工作台。
那篇发出去之后，有朋友问我：这个编剧智能体，写得怎么样？
我说：写着挺顺，出问题的是写完之后。
这篇文章不讲剧本怎么写。讲一个更没人提、但更容易塌房的问题：当一个 AI Agent 真正产出规模化的成果之后，档案怎么管。
一、先看一眼当时的工作区
我的编剧智能体当时交出来的东西是这样的：
knowledge/scripts/
├── 2026-09-20-把账摊开-第1集.md
├── 2026-09-20-把账摊开-第2-3集.md
├── 2026-09-20-把账摊开-第4-8集.md
├── 2026-09-21-把账摊开-第9-20集.md
├── 2026-09-21-把账摊开-第21-32集.md
├── 2026-09-21-把账摊开-第33-45集.md
├── 2026-09-21-短剧调研笔记.md
├── 2026-09-21-渠道实访记录.md
├── ...
看着还行？问题全在后面。
剧本是按批次落盘的。第一批写了 3 集，就落一个「第1集」「第2-3集」；第二批补到 8 集，就再落一个「第4-8集」。文件划分跟着「我什么时候写的」走，不跟着「它到底是哪一集」走。
于是：
- 想知道第 17 集的结尾钩子是什么？得先猜它落在哪个批次文件里，再翻进去找。
- 想改 EP20 的一句台词？改完要检查跟 EP19、EP21 的钩子有没有对上，而这俩在另外两个文件里。
- 写新剧的时候，目录里没有任何东西告诉你「一部剧该怎么组织」 —— 只能照上一部剧的样子猜。
这是最简单的一类技术债：用「操作的时间顺序」当文件结构。人写日记可以这样，机器管资产不行。
二、第二个问题：一集一文件的幻觉
顺便说个副作用。
一开始我也有过「查档误判」的翻车 —— 问它「写了多少集」，它答「只有 3 集」，因为另外几集只在聊天里发过，没落盘。
那之后我给它定了一条硬规则：
任何一集定稿，必须立刻写进文件，不能只发聊天记录。
这条规则本身救回来了很多内容。但它只解决了「有没有落盘」，没解决「落盘之后的组织形式」。文件是有了，可它们依然按批次堆着。
三、动手：把「时间顺序」换成「资产结构」
我回头看了一眼整个工作区里其它成熟的部分 —— 比如我自己管内容的那套知识库 —— 结构是有规律的：
一个稳定实体，对应一个稳定的目录；一个稳定的最小单位，对应一个稳定的文件。
放到剧本上，最小单位是什么？一集。
于是我把编剧的知识库重排了一次，规则就一条：
一部剧 = 一个目录，一集 = 一个文件。
knowledge/scripts/
├── README.md # 剧本区总规则（怎么存、怎么开新剧）
├── _template/ # 新剧模板，复制即开新剧
│ ├── README.md
│ └── delivery/episodes/
├── story-seed-debt-repay.md # 素材库（不属任何一部剧）
└── va-banque/ # 一部剧 = 一个目录
├── README.md # 🔒 剧主页：全剧入口 + 45 集分集索引
├── sales-notes.md # 🔒 销售策略（内部，不外发）
├── structural-notes.md # 🔒 结构说明（内部，不外发）
└── delivery/ # 📦 交付区：能交给第三方的全在这
├── outline.md # 45 集大纲（母版兼交付件）
├── characters.md # 人物小传
├── lines-golden.md # 金句池（宣发用）
├── pitch-package.md # 样品包（对外一份通）
└── episodes/ # ⭐ 正文：一集一文件
├── ep01.md
├── ep02.md
├── ...
└── ep45.md
原来 6 个批次文件，拆成了 45 个文件。
| 想做的事 | 以前 | 现在 |
|---|---|---|
| 看第 17 集 | 猜它在哪个批次文件里 | delivery/episodes/ep17.md |
| 改一句台词 | 上下文散在别的文件 | 同目录，导航行直接跳 |
| 查资料齐不齐 | 翻目录靠记忆 | 进剧主页一眼看全 |
| 开一部新剧 | 照上一部猜 | cp -r _template/ 新剧名 |
关键不是「文件多了」，是「位置可预测」。 一个 Agent 再聪明，如果它得先猜再找，那它每次开口前都在赌。
📌 注意这里已经埋了一条线：可交出去的东西，全都塞进了
delivery/。这不是我最初的设计 —— 是后来被一个真实的翻车逼出来的，见第五节。
四、第三步：把规则写成文件，别留在「我记住了」
重排完了，我盯着另一个风险发了会儿呆。
这套规则此刻只存在于这一次对话里。明天它换个会话、换个上下文，这 45 个文件怎么来的、为什么这么分、新剧该怎么开 —— 全都会忘。
记忆会漂，文件不会。
所以我让它把规范落到两个地方：
1. scripts/README.md —— 剧本区的「作业规范」
- 一部剧一个目录
- 一集一个文件（epNN.md）
- 每集首尾带「上一集 / 下一集」导航
- 每部剧必须有剧主页（README）
- 新剧怎么开：复制 _template/
- 写完更新总索引（剧目总览表加一行）
2. _template/ —— 下次的起手模板
下次说一句「开一部 XX 题材的短剧」，它就该照着模板起：建目录 → 建 episodes/ → 写剧主页和大纲 → 一集一文件。不靠记性，照着文件走。
🔎 注意：这份初版规范还只解决了「怎么存」。「哪些能发出去」这一层，是下一节才补上的 —— 而且补它的代价差点很惨。
五、差点犯的错：把销售策略发给了买家
这部分是我最想写的，因为它差点造成真实损失，也直接催生了 delivery/ 这个目录。
剧写完了，下一步是对外投稿。它做了一份「样品包」文件，106 行，看着挺完整。
我让它改的时候，它读完全文后说了一句很关键的话：
它不是「过期」，是更严重的问题 —— 106 行里有一半是「销售策略建议」，不是「样品包」。
具体是什么内容呢：
- 分层卖法（初看档给前三集，深谈档给大纲，成片档才给全本）
- 防坑要点（分集大纲只给一句话，关键转折必须留白）
- 报价思路
- 「不卖断，剧本是自有资产」的底线
这些东西，是你卖剧本的底牌。
而它当时和「封面 / 简介 / 人物小传」写在同一个文件里 —— 这个文件的名字叫「样品包」，用途是「发给制片方看」。
你把这个文件发出去，等于先把自己的底价和盘托出： 对方一眼就看到「他打算分三档给、关键转折留白、不卖断」—— 谈判还没开始，你手上已经没牌了。
顺带说一句，这个坑还有第二层：剧早就定稿 45 集了，样品包里的状态还是「🟡 待确认走向、已完成 EP01-03」 —— 只有它停留在全剧大纲刚写完的时刻，之后剧写完了，它没跟着更新。要是这么发出去，对方会认为：这人只写了 3 集，连中点都没定。 报价直接砍一半。
第一步的修法：拆成两个文件
最直接的改法是按「给谁看」分家：
va-banque/
├── pitch-package.md 📦 对外交付版 —— 可直接发出
└── sales-notes.md 🔒 内部销售策略 —— 不外发
- 对外版只留能给对方看的：封面 / logline / 简介 / 人物 / 结构亮点 / 合规说明 / 物料清单 + 三档交付口径表。
- 内部版装不能外泄的：分层卖法 / 防坑要点 / 不卖断底线 / 报价思路 / 渠道。
修完我以为这事结了。但没有。
真正的修法：把「靠记性」换成「靠结构」
拆完文件之后我盯着目录看了一会儿，意识到一个更根本的问题：
这两个文件还是躺在同一个目录里。 pitch-package.md 和 sales-notes.md 挨着放，中间就隔几个文件。我发东西的时候，靠的还是「我记得哪个能发」——而前面那么多轮翻车，病根全都是「靠记性分类」。
于是我换了个思路：别靠人记，让目录本身说话。
规则就一条：
判据：这份文件能不能交给第三方？
能 → 进delivery/；不能 → 留在上层内部。
va-banque/
├── README.md 🔒 内部：剧主页（导航）
├── sales-notes.md 🔒 内部：销售策略
├── structural-notes.md 🔒 内部：结构说明
│
└── delivery/ 📦 交付区：能交给第三方的全在这
├── outline.md
├── characters.md
├── lines-golden.md
├── pitch-package.md
└── episodes/ep01~ep45.md
这一步的关键不在「搬家」，在「物理隔离」： 内部件根本不在 delivery/ 里 —— 你想发错，都没有机会。 以后管它叫「能发的」，打开 delivery/ 就是全部弹药，不用记。
三条定死的规矩
定这个目录的时候纠结了几件事，最后都拍板了，值得写下来：
1. 不复制、不生成、不搞双份。 我一开始想的是「跑个脚本把内部件剥掉导航头、生成一份对外版」。但那样就有两份文件了 —— 改了一处，另一处不同步，迟早在某个深夜打架。 最终定：一份文件只有一个家。 delivery/ 里放的是真身，不是副本。
2. delivery/ 是正常目录，照常读写。 这点我一开始想窄了，以为「交付区」该是只读的。后来才想明白：它就是普通目录 —— 我改金句、改小传、改正文，直接改里面的真身；你侧栏点开，照样看、照样编辑。没有什么「生成的、别动」的禁忌。
3. 集正文首尾的导航头，保留。 每集顶上那行「上一集 ｜ 下一集 ｜ 剧主页」，我一度想剥掉再发。后来决定留着 —— 库内翻阅方便，对方收到的是打包后的整合件，导航头在成品里无伤大雅。不为一个心理洁癖，去制造一份副本。
命名约定：外壳即标记
顺手定了一条省事的规矩：内部文件统一用 -notes.md 后缀（sales-notes.md / structural-notes.md）。看到这个后缀，就知道是「不外发」的东西 —— 不用记，看名字就知道。
六、最后一条规范：兼容两种干活节奏
规范成形之后，还剩一个边界情况：不是每次都能「四十多集写完再卖」。
如果写到 EP10 就碰上一个愿意看的买家呢？总不能等写完再谈。
于是规范里补了一节，明确两种模式都兼容：
| 模式 | 适用 | 样品包怎么写 |
|---|---|---|
| 写完再交 | 全剧定稿后集中投递 | 物料清单写「已定稿 N 集」 |
| 边写边投 | 写到 EP10 就想找买家 | 写「已完成 N 集，可续写」，只投已有集数，后续走向只写一句话 |
并钉了一句硬规矩：
样品包（对外）和销售策略（内部），必须从一开始就是两个文件。
不要等写完再拆 —— 因为在「等写完」的这段时间里，你很可能会先把它们发出去。
七、最后一块拼图：让「能不能发」变成一条命令
物理隔离解决了「别发错」，但还留了个尾巴：我怎么知道 delivery/ 里真的干净？
靠人肉 grep？靠我记住「当初清过了」？—— 那又回到「靠记性」了。
所以我让它写了个体检脚本，判据就那么几行：
=== 交付区体检 (delivery/) ===
扫描 49 个文件
=== 合计违规: 0 ===
✅ 交付区全部可发（49 个文件，0 处痕迹）
它扫三类痕迹：
- 指向内部件的链接（
sales-notes.md/structural-notes.md/ 素材库 / 模板） - 内部文件名出现在正文里
- 内部状态词（「暂名」「待验证」「TODO」「不外发」这类过程态）
这里踩过一个坑，值得单独说：导航头本身也是链接。 每集顶上那行 EP02，机械地扫会判它违规 —— 所以我加了白名单：集与集之间的互链 + 回剧主页的链接，放行，只抓真正指向内部的链接。不然「保留导航头」和「0 处痕迹」这两个决定就自相矛盾了。
现在验货就一句话：
cd knowledge/scripts && ./check-deliverables.sh
报 0 处痕迹，才能发。规范从「我记得」变成了「跑得出来」。
八、顺便修的一个小东西：链接
重排必然带来搬家，搬家必带来死链。
拆完目录之后它做了一轮全库校验，抓到的都是典型的搬家病：
- 集正文里指向大纲、剧主页的跨库链接层级变了（正文深了一层，
../README.md得改成../../README.md） - 若干条还指向已经迁走的旧路径
- 模板里的占位链接（
epxx.md这种格式占位符，不是真链接，得标注清楚免得又被误报）
全库死链归零。
这件事的意义不在「修了几个链接」，而在于：一个知识库如果允许死链存在，它就开始腐烂了；而 Agent 是不会自己发现腐烂的，除非你把「校验」也变成一个动作。
九、复盘：这套东西的通用部分
如果抛开剧本，这几步其实可以搬到任何「AI 帮你产出规模化资产」的场景：
1. 文件结构要跟「资产结构」对齐，不是跟「操作顺序」对齐。 「我什么时候写的」不是结构，「它到底是哪一集」才是。
2. 稳定实体 → 稳定目录，稳定最小单位 → 稳定文件。 一集一文件之所以成立，是因为「集」是这部剧的原子单位。
3. 规则必须落成文件。 写在 README 里的规则是资产，留在对话里的规则是空气。要连「怎么开新剧」都有模板可复制。
4. 别靠记性分类，靠结构分类。 内部件和交付件混在一个目录里，你就会永远在「这个能不能发」上纠结、出错。正确的分法只有一个维度：这东西能不能给对方看。 定完这条，剩下的交给目录本身。 （这条是我付出了好几次翻车才换来的。）
5. 把校验也变成一个动作。 「0 处痕迹才发」得是一行命令，不是一个我声称做过的检查。能被复现的标准，才是标准。
结尾
回头看，这套东西真正解决的问题不是「AI 写不出剧本」。
是 AI 能写出来了，但它的产出开始需要「被管理」。
代码有目录规范、生产物料有 BOM、内容有台账 —— 那我们让 AI 生成的东西，凭什么可以随便堆在几个按日期命名的文件里？
写剧本是创作，管剧本是工程。创作靠灵感，工程靠规范。
而规范这东西，从来都是等到东西真多起来了，你才知道该定在哪。
