项目：如果三国·柳城 互动阅读器V1.0
复盘日期：2026-06-16
复盘范围：2026-06-12 ~ 2026-06-16（5天）
---
最初担心配图生产会成为瓶颈。结果：42个节点全部配图，3批生产全部顺利完成，无一张因技术问题失败。
原因分析：
启示：艺术创作类任务比工程类任务更适合交给AI自主完成——因为"好不好看"有主观标准，AI生成→人判断→不满意重生成，是比预先精密规划更高效的路径。
---
最初只是一个叙事直觉（"刘备不靠打仗，靠制度"），经过5天演化出了可操作的六条原则，并且与苏铭系列形成了深层同构。
为什么超出预期：
启示：强约束 > 无约束。提前想清楚"什么不能做"，比"做什么都行"更能释放生产力。
---
初始计划是"V1.0互动阅读器"，包含阅读器+配图+故事+部署。实际完成：全部完成，外加配图100%、目录功能解锁机制、多种格式标注体系、外网部署。
启示：用户的说法——"初始计划的价值是给出第一步的形状，而非预测准确"。第一次探索的核心价值是让后续扩展知道哪里有坑，而不是精确预测结果。
---
从V2.1的8项BUG、V3.3的废弃路径，到最终定版V1.0，中间经历了大量失败。但最终结果：模式A（交互）和模式B（沉浸）同时存在且稳定运行，出错率极低。
启示：失败路径也是信息。V2.1和V3.3不是浪费，它们帮助锁定了"不做什么"（游戏逻辑、临时注入模式），从而更清晰地定义了"做什么"。
---
事前已经判断小程序有政策风险，过程中确认了这个判断。符合预期，未浪费时间。
故事一开始就是线性的——选项是展示性的，用户每次都自定义输入。这个性质从头到尾没有改变，符合预期。
用户主动选择保留这个设定，不将其合理化。符合预期——最好的故事张力往往不是被消除的，而是被承认的。
从第一天就确认需要标注体系（[N]/[C]/[M]），过程文档也多次强调"源文件标注清晰度是AI可读性的前提"。这个判断全程成立。
---
现象：42个节点的故事，源文件缺少节点边界标记，导致每次提取内容都需要大量正则补丁+内容匹配+人工核对。贯穿全程。
根因：源文件是"写给人类阅读的"，不是"写给AI解析的"。标注粒度、标注格式、标注位置都不稳定。
影响：
教训：如果源文件是AI处理的输入，必须在协作开始前就定义好标注规范——这不是创作的一部分，是基础设施。
---
现象：灭曹路线中，于吉渗透无阻力、吕布未反水，整个故事推进过于顺畅。识别出了这个问题，但直到V1.0完工都没有引入克制机制。
根因：时间精力都用于修复标注和工程问题，叙事张力调整被挤到了后面。
教训：如果一个故事存在结构性问题，应该在创作阶段修复，不应该带着"未解决"标签进入交付。
---
现象：用户输出的前13个节点在迁移过程中从磁盘消失，需要从历史对话中重新提取。但因为时间压力，这13个节点至今只有部分被验证恢复。
根因：文件管理操作（中文路径迁移、目录重组）导致文件与索引不匹配。
教训：输出物管理应该像版本管理一样严格——每次交付必须有快照，迁移操作必须有双向验证。
---
部分图片因为压缩参数过激（quality 20~40），分辨率和细节已不可恢复。虽不影响功能，但相比同批次的优质图片有肉眼可见的差距。
教训：压缩应该在交付前统一规划，而不是在生产过程中边生产边压缩边决定保留哪张。
---
规则自生长六条原则（创作方法论）
最小可行规则 / 结构替代感受 / 自动触发 / 平行进化 / 关注具体人 / 退出与清零机制
用户五条工作方法论（协作方法论）
1. 初始计划的价值是给出第一步的形状，而非预测准确
2. 初始计划往往需要修改，需要执行中充分沟通细节
3. 实际完成远超计划
4. 第一次探索的核心价值：让后续扩展知道哪里有坑
5. 结果已达成，根据实际情况重制计划
技术六条教训（执行方法论）
1. 中文路径在PowerShell中编码损坏，必须全英文化
2. 正则注入不安全→改为整体重写
3. Swap互换操作需直接设目标值（绕过swap陷阱）
4. 压缩脚本需验证文件落盘
5. 越界操作导致误修改→严格遵守用户指令边界
6. 源故事标注清晰度是AI可读性的前提
---
基于以上分析，为下一次协作制定：
---
规则：如果源文件是给AI解析的，必须在动笔之前先定义标注规范。
为什么重要：标注是通信协议，不是创作的一部分。协议没定义好，所有后续工作都会带着噪音。
---
规则：每个阶段性交付（Part1、Part2……）完成后，必须用户确认"收到且无异议"，才能开始下一批。
为什么重要：历史教训——输出1~13丢失的根本原因是"以为用户收到了，实际上没有落盘"。确认是单向确认，不能想当然。
---
规则：
为什么重要：压缩后文件打不开、部署后图片404——这些都是本可以避免的问题。工程操作的低级错误会浪费大量排查时间。
---
规则：如果在创作过程中发现故事存在"太顺""张力不足""人物动机不清"等问题，必须在当前阶段解决，不能留到V2/V3。
为什么重要：node_24幽灵节点和"太顺"问题的共同教训——欠下的债只会越滚越大，不会自动消失。
---
规则：这是给AI的自我约束。
例外：如果发现严重的数据损坏（文件丢失、内容错乱），立即上报，不等待指令。
为什么重要：越界操作是本次最大的失误来源。AI有强烈的"多做一点"的冲动，这个冲动在创作协作中是危险的。
---
规则：
为什么重要：文件找不到是协作杀手。每次重组都可能造成"以为文件在这里，实际不在"的断点。
---
规则：
为什么重要：AI猜错的代价往往比"问一句"更高。
---
规则：
为什么重要："太顺"是故事最大的敌人。克制不是削弱故事，是增加深度。
---
规则：
为什么重要：项目周期越长，文件越多。好的命名是协作的长期基础设施。
---
> 标注先行、交付确认、工程验证、克制叙事、只做指令要求的。
---
复盘人：QClaw
复盘时间：2026-06-16 16:44 GMT+8
基于材料：总结报告 + 30份过程文档 + LCM历史记录 + MEMORY
—— 人与AI协作记录 ——