下一章不一定是第十一章

作者刚写完第十章。

照顺序来看，下一章理所当然应该是第十一章。

但他脑中最清楚的不是第十一章。

而是第二十七章。

他已经看见那一章的场景。

Elena 终于进入封锁多年的地下档案库。

她会在那里见到一直拒绝和她合作的馆长。

城市的封锁已经解除。

她也终于知道多年前那封信的真正寄件人。

这几件事会在同一个场景里交会，让她有资格打开一份足以改变整个世界的纪录。

作者还不知道第十一章到第二十六章的所有细节。

却知道故事必须抵达这里。

于是他没有先建立第十一章。

他先建立第二十七章。

然后在这个未来场景里放下一个 REQ 锚点。

这个锚点要求：

地下档案库的位置已经被发现。

馆长的信任至少达到 3。

城市警戒状态已经变成解除封锁。

信件寄件人的身分已经确认。

那份一次性的档案库通行资格尚未被提前使用。

这些条件现在都还没有成立。

但作者已经知道，第二十七章需要它们。

所以那一章不是写作已经抵达的地方。

它是一个先被放在远方的未来。

从那一刻开始，第十一章到第二十六章便有了需要完成的事。

作者可以先看见结果，再回头寻找足以支撑它的原因

长篇写作不一定永远从前往后发生。

作者可能先想到结局。

先看见一场重逢。

先知道某件物品最后会回到谁手上。

先写下一段角色已经完成转变之后的对话。

也可能先确定某一章需要几条分散已久的剧情线同时交会。

这不是异常的写作方式。

很多时候，作者对故事最清楚的部分，本来就不会按照章节顺序出现。

问题在于，先看见未来很容易。

让未来得到足够的前因，却比较困难。

作者知道 Elena 会在第二十七章得到馆长协助。

但她在第十章仍然不受馆长信任。

作者知道城市封锁会在那一章以前解除。

但封锁目前才刚开始。

作者知道信件的秘密会成为进入档案库的关键。

但前文甚至还没有建立足够线索，让 Elena 怀疑寄件人的身分。

如果这些差距只留在作者脑中，第二十七章很容易提前使用尚未形成的结果。

角色忽然拥有信任。

封锁忽然消失。

身分之谜像是早已解开。

通行资格也在需要时自然出现。

作者确实先看见了未来。

但世界没有走到那里。

所以先写未来真正需要的，不只是保留一段灵感。

还要把那个未来正在等待的前因，一起留下来。

REQ 不是备忘录，而是未来向前文提出的条件

作者可以在笔记里写：

记得让 Elena 得到馆长信任。

记得解除城市封锁。

记得揭露信件寄件人。

记得准备进入档案库的方法。

这些都是有用的提醒。

但它们仍然只是作者写给自己的文字。

完成其中一项以后，作者必须自己把待办勾掉。

修改前文以后，也要自己重新判断那些安排是否仍然成立。

REQ 的作用不同。

它不是一句「记得处理」。

它位于第二十七章的实际时间点，并且明确声明：

当世界重播到这里时，这些条件必须成立。

因此，REQ 不是放在故事外面的规划笔记。

它是故事时间线里的一个因果检查站。

地下档案库的位置是否已经被发现，不由作者手动宣告完成。

馆长信任是否达到 3，也不由待办清单上的核取方块决定。

因果律引擎会沿着第十章之后真正发生的事件，重播相关 Flag 的状态。

走到第二十七章的 REQ 时，再检查那些条件是否已经成立。

如果尚未成立，未来仍然在等待自己的原因。

如果全部成立，第二十七章才真正得到世界的支持。

这份未来待办，不需要作者手动勾选

一般待办事项的完成状态由人决定。

作者写完一场对话，便把「提高馆长信任」勾掉。

写完解除封锁的场景，再把另一项工作标示为完成。

但「作者觉得自己处理过」和「世界状态真的已经改变」，不是同一件事。

作者可能写了一场让馆长开始动摇的对话。

却没有让信任达到第二十七章需要的程度。

可能写了市政府准备解除封锁。

但命令尚未真正生效。

可能揭露信件上的笔迹属于某个人。

却还没有让 Elena 确认寄件人的完整身分。

所以 REQ 不会因为相关内容曾经被提到，就自动完成。

作者需要在正文中放入真正改变相应 Flag 的事件锚点。

例如：

第十二章，Elena 从旧地图上确认地下档案库的位置，让「档案库位置已发现」成立。

第十六章，她归还馆长遗失多年的纪录，让馆长信任发生改变。

第二十章，她找到第二份证词，使「信件寄件人已确认」成立。

第二十四章，城市危机解除，警戒阶段才正式改为解除封锁。

这些事件被放进第二十七章以前，因果律引擎重新验证后，REQ 缺少的条件便会逐项减少。

待办不是被作者勾掉的。

是世界沿着实际历史证明它已经完成。

一个未来，可以同时等待不同种类的条件

第二十七章需要的条件，不一定全部都只是「有」或「没有」。

有些事情适合使用布林旗标。

地下档案库的位置是否已被发现。

信件寄件人的身分是否已经确认。

某份协议是否正式成立。

这些条件通常回答：某件事现在成立了吗？

有些事情具有多个阶段。

城市警戒可能经历：

正常、警戒、封锁、解除封锁。

调查也可能从未知、怀疑、确认，走向公开。

这类状态适合使用列举旗标。

REQ 不只确认旗标存在，还能要求它在第二十七章抵达特定阶段。

另一些条件则需要累积。

馆长信任至少达到 3。

调查进度高于某个门槛。

敌对程度低于特定数值。

三项授权中至少已经取得两项。

这些状态可以使用计数旗标，让 REQ 比较目前值是否大于、小于或达到指定门槛。

因此，第二十七章不是只有一张简单的完成清单。

它可以等待多种不同形状的世界状态。

某件事已经发生。

某件事走到特定阶段。

某个数值累积到足以支撑后续事件。

某项一次性条件也仍然保有作用。

当这些条件同时成立，未来场景才不只是作者希望它发生。

而是世界已经走到能让它发生的位置。

第二十七章不会把第十一章变成过去

先建立第二十七章，不代表故事时间已经越过中间十六章。

「第二十七章」首先是一个章节名称。

真正决定世界时间的，是它在专案结构中的排列位置。

作者刚建立它时，结构可能是：

第十章。

第二十七章。

接着，作者开始补写中间的路。

他建立第十一章，放在第二十七章以前。

再建立第十二章、第十三章与后续章节，逐步把它们插入正确位置。

最后，专案结构变成：

第十章。

第十一章。

第十二章。

一路到第二十六章。

然后才是第二十七章。

InkWeave 的因果律引擎不会因为章节标题里写着「二十七」，就凭空假设前面已经存在二十六章的历史。

它依照卷册、章节与正文锚点的实际顺序重播事件。

所以只有真正被放到第二十七章以前的 Flag 变化，才能满足第二十七章的 REQ。

如果作者把解除封锁的事件写在第二十八章，它不会倒流回去支援第二十七章。

如果作者后来把那个事件移到第二十四章，它才会成为 REQ 可以承认的前因。

第二十七章没有反过来创造第十一章到第二十六章的历史。

它只是先说明：

当故事真正走到我这里时，我需要前面的世界已经完成这些改变。

Project Seer 让未来持续出现在作者眼前

作者建立第二十七章的 REQ 以后，可以先回到第十一章继续写作。

但第二十七章不会因此从专案的因果视野中消失。

Project Seer 会扫描整个专案。

当因果律引擎重播到第二十七章，REQ 会按照那一刻的 Flag 状态检查所有条件。

如果地下档案库位置尚未发现，Project Seer 可以指出这项条件尚未成立。

如果馆长信任只有 1，但第二十七章要求至少达到 3，它可以同时显示目标值与目前值。

如果城市警戒仍然处于封锁，REQ 也不会因为作者打算在前文解除，就提前把意图视为结果。

如果一次性资格已在更早的事件被回收，Project Seer 也会指出它不能再被第二十七章使用。

这些未完成条件会持续留在专案检查里。

作者写完第十二章，满足其中一项。

写完第十六章，再满足一项。

如果第二十章的事件仍然不足，其他条件就继续存在。

因此，Project Seer 不只是找出已经写错的地方。

它也能让作者看见自己先放在未来的责任。

第二十七章还没有正式抵达。

但它已经开始向前文提出要求。

REQ 负责验证，Flag 事件负责让世界改变

REQ 不会替作者建立它需要的条件。

它也不会因为作者希望第二十七章成立，就自动改变任何 Flag。

REQ 只做一件事：

检查世界走到这个位置时，指定条件是否成立。

真正让条件发生变化的，仍然是前文中的事件锚点。

角色找到档案库。

馆长改变信任。

警戒进入新的阶段。

秘密身分被确认。

这些事件使 Flag 取得新的值。

等到因果律引擎重播至 REQ，它才有状态可以比较。

这个分工很重要。

如果 REQ 同时负责建立自己需要的条件，世界就会变成只要抵达第二十七章，一切前因便自动成立。

那不是因果。

那是作者把结果写进未来以后，要求世界倒过来承认它。

InkWeave 不会这样做。

未来可以提出条件。

前文必须真正产生条件。

REQ 则站在两者交会的位置，确认世界是否已经走完那段距离。

通过 REQ，不一定代表伏笔已经回收

第二十七章抵达时，所有条件都已成立。

这表示那一章可以使用它们。

但 REQ 通过，不一定代表所有 Flag 都已经完成使命。

例如「馆长信任至少达到 3」可能是一个持续状态。

第二十七章以后，这段信任仍然可能影响其他事件，不需要在场景结束时被回收。

「城市已解除封锁」也可能继续保持有效。

它不是使用一次就消失的条件。

但一次性通行资格不同。

Elena 使用它进入地下档案库后，这项资格可能就应该被回收。

信件寄件人的身分伏笔，也可能在真相公开后完成自己的叙事责任。

因此，完整的因果顺序可能是：

前文设定或改变 Flag。

第二十七章的 REQ 检查条件。

场景正式使用这些条件。

需要结算的一次性 Flag，再由后续锚点回收。

REQ 是检查。

回收是状态改变。

两者不能被压成同一个动作。

如果一项伏笔被设定，却到整条时间线结束仍然没有得到处理，InkWeave 也可以透过契诃夫之枪提醒，让作者回头确认它究竟是刻意保留，还是真的被遗忘。

世界不只需要知道伏笔是否足以支撑未来。

也需要知道它完成任务后，是否仍然背着一笔没有结算的责任。

修改前文，也可能让已经成立的未来重新失去支撑

作者终于完成第二十六章。

第二十七章的所有 REQ 条件都已经通过。

后来，他回到第十六章修改剧情。

原本是 Elena 归还失落纪录，让馆长信任提升。

新版本里，她选择隐瞒其中一页。

这个改动让场景更有张力。

却也让馆长的信任不再达到第二十七章要求的数值。

第二十七章的文字没有改变。

REQ 锚点也没有改变。

但它的前因已经变了。

因果律引擎重新重播后，原本通过的条件会再次失败。

Project Seer 便能重新把这笔未完成责任带回作者眼前。

作者可以修改第十六章。

可以在后面的章节建立另一场恢复信任的事件。

也可以重新思考第二十七章是否真的需要馆长信任。

系统不替作者选答案。

它只指出：

你改变了通往这个未来的道路，所以那个未来现在不再像以前一样成立。

这正是结构化未来待办和普通笔记最大的差异。

普通笔记只记得作者曾经想做什么。

REQ 记得的是目前这段世界历史，是否真的已经做到。

这不是 AI 替作者预测剧情

InkWeave 不会阅读第二十七章的文字，再由 AI 猜测这场戏需要哪些伏笔。

它也不会分析第十二章的语气，擅自判定馆长开始信任 Elena。

REQ 里需要检查哪些条件，由作者明确建立。

Flag 的种类、预设值与状态变化，也由作者定义。

InkWeave 自研的因果律引擎会按照专案中的实际章节顺序，依序重播 Flag 事件。

抵达 REQ 时，再将当下状态与作者设定的条件比较。

条件可以检查是否存在、等于、不等于、大于、大于等于、小于或小于等于指定值。

同一个 REQ 也可以同时检查多项条件。

这里没有语意猜测。

没有模型认为某段对话「看起来像」信任增加。

也没有 AI 觉得故事「大概已经」解除封锁。

在作者明确建立的模型范围内，相同的章节顺序、Flag 事件与 REQ 条件，会得到相同的验证结果。

这是事件顺序、状态转移与条件比较的数学保证。

没有被作者建模的情绪、隐喻与文学意义，因果律引擎不会假装理解。

作者仍然负责意义。

引擎负责确认作者明确交给世界的条件，是否真的沿着历史成立。

世界模拟不是预测未来，而是让未来等待自己的原因

先建立第二十七章，看起来像是作者跳到了未来。

但 InkWeave 不会把那个未来当成必然。

第二十七章可以被写下。

可以保留最重要的对话。

可以先确定角色会站在哪里，以及那场戏需要什么。

但只要 REQ 尚未通过，它就仍然是一个等待前因的未来。

这套方式不只适用于小说伏笔。

一场救援演练可以先定义最终撤离需要哪些安全条件。

一个制作计划可以先定义正式拍摄前必须完成哪些授权与准备。

一段历史模拟也可以先放下某个政治事件，再检查前面的支持、资源与冲突是否足以让它成立。

InkWeave 不会替这些未来生成过程。

它也不会预测人们一定会作出哪些选择。

它只是让创作者可以先声明：

如果世界要走到这里，它必须先成为什么样子？

然后让每一次真正被写入时间线的事件，逐步回答这个问题。

作者可以先看见远方的门。

可以先知道门后有什么。

也可以先写下抵达那里时最重要的一句话。

但世界仍然需要在前面的章节里，造出那把能够打开门的钥匙。

第二十七章不是对未来的保证。

它是一份由未来交给现在的因果契约。