paper_type: HCI 与用户研究, 方法与系统 type_confidence: 高 reading_depth: 标准精读 title: "Fabula: Building a Narrative Storytelling Sidekick with the Writers' Community" authors: Piotr Mirowski, Ben Wedin, Reinald Kim Amplayo, Rich Galt, Duncan Williams, Rida Qadri, Jaume Sanchez-Elias, Erin Drake-Kajioka, Sian Gooding, Lucia Lopez-Rivilla, Joao G. M. Araujo, Lion Schulz, Satinder Baveja, Shakir Mohamed, Edward Grefenstette, Laura Rimell, Richard Evans year: 2026 source: arXiv:2606.14411v1, cs.HC preprint pdf: 33_fabula.pdf tags: [论文精读, HCI, 参与式设计, 职业写作者, 叙事规划, 写作工具, 创意支持] related: [[36_ai_fiction_in_the_wild]], [[34_graphstory]], [[14_agents_room]], [[27_calibrated_surprise]]
Fabula：最重要的产出不是故事生成器，而是对“AI 应该替作者做什么”的重新定位
一句话答案：Fabula 用 scene→beat 的分层计划和可编辑生成界面与职业写作者展开参与式设计；研究发现系统擅长结构化和场景拆分，却常在文体、文化适配和创造性摩擦上撞到天花板，促使团队把目标从“自动生成更好故事”转向诊断、教学和交互叙事工具。
当开发者说“质量提升”，写作者可能听见“约束增加”
问题入口。许多 AI 写作研究把用户反馈当作优化产品的输入，默认更连贯、更可预测、更高自动评分就是更好。Fabula 反过来问：如果专业写作者要的是意外、摩擦、局部失控和作者主权，那么工具的优化目标是否从一开始就错了？（作者主张，§1.1）
论文的核心问题不是单纯“Fabula 好不好用”，而是：把原型当作文化探针，能否暴露开发者的技术逻辑与写作者的创作逻辑在哪里冲突，并据此重新定义 AI 的角色？ 下文先说明原型把什么交给模型，再看 42 位专家参与的多阶段研究如何改变系统，最后判断这些材料能支持多强的设计结论。
先给结论
- 系统设计。Fabula 把故事组织为 story plan、scene plan、script 三个抽象层，scene 再拆成 beat；26 个 Drama Manager 变体调用 Gemini，在计划创建、内容生成和计划演化之间权衡质量与响应速度。（论文报告，§3.1，图 1–2）
- 研究方法。团队开展 18 场一小时设计访谈和 25 场三小时写作 session，论文称共涉及 42 位写作、戏剧、影视等专家；此外还有数百名内部测试者和超过 250 名有限公开测试者。（论文报告，§1.1、§3.4，图 4）
- 核心发现。写作者认可分层规划、场景拆解和角色分析，却反复把生成文本描述为 generic、corny 或“creative 101”，并担心固定叙事学、认知去技能化和批量生产逻辑；量化 CSI 在自称新手和电影从业者中较高，在戏剧从业者中最低。（论文报告，§4.3、§6–7，图 9）
- 设计转向。反馈推动团队加入脚本上传、结构批评和专门格式，并把后续重点转向写作导师、剧本诊断与实时交互叙事，而不是继续追求全自动成文。（论文报告，§7.3、§8.3、Conclusion）
Fabula 先把叙事理论做成可编辑对象
对象模型。Fabula 的高层 story plan 由 scene 组成，每个 scene 记录观众学到什么、感受什么、发生什么、社会情境以及时空；scene 下的 beat 再记录局部变化。用户既可在故事计划、场景计划和正文层进行高层指令，也可细改某个角色背景、某个 beat 或具体文本。（论文报告，§3.1.2–3.1.4）
生成机制。Drama Manager 是把 plan creation、content generation 和 plan evolution 委托给 LLM 的模块化接口。研究期间主要使用 Gemini 2.5 Flash，并实现 26 种变体；不同版本组合角色动机、主题问题、观众目标、悬念、升级、闭合、自评和候选搜索等叙事学组件。（论文报告，§3.1.2–3.1.6）
交互设计。Gardener 视图支持一次推进一个 beat 的即兴发现，Architect 视图同时暴露故事计划、场景计划和正文。系统后来支持上传已有剧本，把它解析为 scene 和 beat，再比较分支或续写；这项功能正是职业编剧希望修改既有材料，而不是从空白提示生成整篇故事后加入的。（论文报告，§3.2、§7.3）
这些设计使结构、正文和修改意图都可见，却也把特定叙事理论编码进界面。Fabula 因而既是工具，也是一个可被参与者具体反对的“边界对象”。（阅读者分析）
参与式研究不是一次可用性测试，而是连续碰撞
参与者与流程。18 位外部专家通过 snowball sampling 招募，参加由一至两名主持人的一小时访谈；录音转写后由两名作者用归纳式主题分析编码和讨论。25 位写作者参加三小时 session：前 90 分钟介绍并单独使用 Fabula，随后填写 creativity support survey，最后进行约 60 分钟 focus group。论文用 P1–P18 与 W1–W25 标识参与记录，图 4 明确标出 P7 与 W7 为同一人，因此两阶段共有 42 位独立专家。（论文报告，§3.4，图 4）
更广泛测试。内部与外部测试者使用简短问卷和自由文本反馈，主要用于发现 bug 和观察不同熟练度用户的反应；项目还向超过 250 名写作者有限开放。不同阶段的反馈会进入下一轮功能修改，因此研究测到的是持续变化的原型，而不是一个冻结版本的对照实验。（论文报告，§1.1、§3.3–3.4）
伦理与数据治理。研究经机构指定伦理委员会批准，参与者签署同意书并可无损退出；访谈和写作 session 按行业咨询小时费补偿。团队不收集人口统计，只记录自报写作经验与生成式 AI 经验，并声明测试者保留故事所有权，未经书面许可不公开输入与生成内容。（论文报告，附录 A.1–A.2）
自动优化首先撞上了“什么算好故事”
自动评价设计。团队从叙事理论教材和 Torrance 创意写作测试提炼 63 条 guideline，让 Gemini 2.0 Flash 逐条做五点评分；为降低选项位置偏差，模型先为 1–5 每个等级生成理由再给分。auto-rater 被用于 self-play 迭代，目标是在故事质量、指令遵从和响应速度之间扩展 Pareto frontier。（论文报告，§4.1–4.2，图 5）
效度证据。auto-rater 与既有人类成对偏好比较，原始版本的一致性为 0.72，改进版为 0.83；这里复用了 Agents' Room 的专家偏好数据，其人际 Fleiss' κ 为 0.46（p<.01，N=150，k=3）。（论文报告，§4.2，脚注 5–6）
写作者反馈。参与者认为 Fabula 擅长故事结构、scene breaking 和情感弧线，却对 dialogue 与具体文体评价分化；多名写作者称输出 generic、corny、creative 101，难以处理反讽、讽刺或有意违反语法的声音。有人甚至希望有“absurdity dial”，因为减少不一致的自动评分可能同时过滤创作所需的 glitch 和 productive friction。（论文报告，§4.3–4.4）
这组材料没有证明 63 条 rubric 无效，而是说明它们优化的是一种较规范、较易教的叙事质量。auto-rater 对既有专家偏好的 0.83 一致性，也不能推出它能识别新颖、文化特殊或刻意反常的作品。（阅读者分析）
分层计划帮助一部分人，也排斥另一部分实践
界面反馈。Architect 让部分参与者快速重排结构，Gardener 则被认为更像逐刻发现和游戏式共创；但写作者要求锁定元素、增删 scene、渐进构建计划，也有人仍希望保留聊天入口。结果支持可切换工作流，而不是一种界面取代所有写作方式。（论文报告，§5，图 7）
文化与媒介边界。scene→beat 层级来自偏西方、偏影视的叙事传统。参与者指出开放形式戏剧不一定预设观众“应该学到或感到什么”，系统也常把非西方文化当作覆盖在西方结构上的装饰，并频繁退回 screenplay 风格。团队随后增加 screenplay、theatre play 和 novel 格式，但底层通用模型与统一 Drama Manager 的偏差仍无法靠界面完全修复。（论文报告，§6、§8.2）
创造性支持。25 位写作 session 参与者的 CSI 按自报领域分组后，新手和电影从业者最高，戏剧从业者最低。定性材料同时显示：系统可帮助跨过糟糕初稿、做世界构建或提出角色问题，却可能把作者降为输出仲裁者，诱发认知去技能化，并服务“批量产出文本”而非写作实践。（论文报告，§7.2，图 8–9）
最有价值的结果，是系统角色被改写
从生成到诊断。写作者希望让 Fabula 分析已有作品、指出结构弱点并提供可选择建议。团队据此加入 script upload 和 critique chatbot，后续把系统定位收缩为新手写作导师、writers' room 中的结构反馈工具，以及导演探索“如果这样改会怎样”的交互叙事平台。（论文报告，§7.3、§8.3、Conclusion）
证据边界。这是参与式、迭代式、解释性研究，没有固定对照、随机分配或统一任务；数百测试者多为自愿注册，42 位专家通过网络和 snowball sampling 招募，不能估计所有职业写作者的总体偏好。研究者同时是系统开发者、访谈主持者和编码者，也会影响问题、迭代与主题解释。（阅读者分析）
这些限制不是论文失败，因为它的主要目标正是暴露冲突，而非估计平均处理效应；但它们要求我们把结论写成“哪些设计逻辑在这些参与者中发生了碰撞”，不能写成“职业作者普遍更喜欢诊断型 AI”。（阅读者分析）
原文定位（附录）
- 原型作为 inquiry、文化探针与四个设计问题：§1.1–1.2，PDF pp.2–3。
- Drama Manager、scene/beat 与三层编辑：§3.1–3.2，图 1–2，PDF pp.4–8。
- 参与式迭代、招募和协议：§3.3–3.4，图 3–4，PDF pp.8–11。
- 63 条 auto-rater 与写作者质量反馈：§4，图 5，PDF pp.12–15。
- Gardener/Architect、文化与媒介冲突：§5–6，PDF pp.15–20。
- CSI、去技能化、作者权和设计转向：§7，图 8–10，PDF pp.20–25。
- 综合讨论与新工具方向：§8、Conclusion，PDF pp.25–28。
- 伦理审批、补偿与数据治理：附录 A，PDF p.36。
读完后的判断
Fabula 没有证明 AI 能写出职业级故事，却有力回答了开头更重要的问题：原型确实可以把抽象的价值冲突变成可观察、可修改的设计对象。最强证据来自多阶段迭代中反复出现的对应关系——结构功能获认可，成文与文化适配受质疑，反馈最终推动产品从生成器转向诊断与教学伙伴。对这条设计学习可持中高信心，对特定界面或 auto-rater 的普遍效果只能持低到中等信心。
读完后应更新的认识是：专业创作工具的目标不应预设为“替作者生成更多”，而要先决定哪些认知劳动必须保留给作者。对当前项目，最可迁移的是让用户锁定元素、上传并解析已有文本、比较结构分支、请求诊断而不自动改写，并把文化假设、生成来源和作者否决权暴露在界面上。真正的下一步不是再加一个质量分，而是让不同创作传统能选择、修改或拒绝系统所编码的叙事逻辑。