把长文本生产拆成一条可恢复、可评测的生产线：从选题、状态到五路验稿与 EvalOps

把长文本生产拆成一条可恢复、可评测的生产线：从选题、状态到五路验稿与 EvalOps

一、我最终理解的不是一条 Prompt，而是一套长文本生产系统

最开始我容易把长文本生产理解成：

给模型一份设定和写作规则，让它生成正文，再找几个 Agent 检查一遍。

把整条链路逐层拆开后，我才建立起一个更准确的认知：这不是一个 Prompt，也不是一个独立的通用 Agent，而是一套运行在 Codex、Claude Code 等公共 Agent Host 之上的领域 Workflow 与 EvalOps 系统。

公共 Agent Host 提供模型推理、工具调用和任务循环；领域工作区负责维护长文本生产所需的 SOP、Skills、状态、确定性检查器、评审合同和回归证据。

各部分的职责不能混在一起：

组成	主要职责	不应该承担的职责
Codex / Claude Code	提供通用 Agent Host、模型推理和工具调用	不天然理解每部作品的生产规则
Workflow / SOP / Skills	拆解生产步骤，为每个环节装载对应规则	不能保证 LLM 每次都绝对遵守
创作状态账本	保存计划、正史、当前状态、逐章变化和平台数据	不直接决定文件能不能写
Node.js Runtime	校验授权、状态、哈希、结构契约和评审证据	不判断长文本是否真正好看
写作与评审 Agent	生成正文，检查逻辑、读感和表达质量	不拥有确定性状态迁移权
EvalOps	保存输入、上下文、输出、Token、耗时和评审证据	不把一次高分自动解释成业务成功

这套系统解决的核心问题是：

如何让概率性的长文本生成进入一条可恢复、可检查、可追踪和可继续优化的生产线。

二、全链路：从选题证据到平台数据回填

完整生产链路可以概括为：

平台课程与市场证据 → 选题 → 作品脚手架 → 写入授权 → 大纲与正文 → 状态结账 → 机器预检 → 五路验稿 → 统一返修 → 投稿打包 → 平台数据回填
图中文字较多，可点击图片查看高清原图。

这条链路有几个重要分界：

1. 有选题，不等于已经创建作品；
2. 脚手架创建成功，不等于允许写正文；
3. 正文生成完成，不等于已经通过验稿；
4. 机器检查通过，不等于五路主观评审通过；
5. 评审没有发现问题，不等于真实读者一定喜欢；
6. 投稿成功，不等于已经获得有效平台数据；
7. 平台数据不好，可以调整未来计划，但不能反过来改写已经发生的正史。

每一步只确认当前阶段能够证明的事情，不能拿上游成功代替下游证据。

三、写作知识不是一次性塞进 Prompt，而是先沉淀再编译

系统收集了多个主流内容平台的课程、品类资料、活动信息和真实作品反馈。

这些内容不能直接全部拼进正文 Prompt。

一方面，来源可能过期、重复或者互相冲突；另一方面，平台流程规则、通用写作规律和阶段性市场风向并不是同一种知识。

当前沉淀链路会先区分：

• 原始来源；
• 公共写作规律；
• 品类增量规则；
• 平台执行规则；
• 市场和活动信号；
• 工程化流程约束。

多来源之间再按照三种关系处理：

• 共识：多个来源表达同一个稳定规律，归纳后进入公共部分；
• 互补：不同来源从不同角度补充同一件事，合并成更完整的执行规则；
• 分歧：相同条件下出现相反建议时，不强行归并成公共规则，而是保留适用范围，必要时通过真实作品和平台数据验证。

只有经过来源判定、裁决和创作算子化的知识，才会编译到 SOP、Skill、模板、写作前速查或验稿矩阵中。

因此，平台课程的价值不是让 Prompt 变得更长，而是让对应知识在真正需要它的环节出现。

四、三层 Guardrails 是互补关系，不是覆盖关系

正文生成时，系统按照三个粒度装载约束：

1. 公共底座；
2. 品类增量；
3. 作品专属约束。

公共底座保存跨平台、跨题材仍然成立的写作规律，例如场景必须真实发生、人物行为需要动机、重要信息需要通过情节呈现。

品类增量补充当前类型的节奏、冲突和读者预期。不同内容类型面对的开篇承诺、信息密度和情绪节奏并不相同。

作品专属层保存当前作品的设定、人物边界、标题承诺、能力代价、关系红线和特殊表达要求。

这三层不是 L3 > L2 > L1 的覆盖关系。

越具体的层级可以增加约束，但不应该重新定义公共规律或与品类核心相冲突。出现冲突时必须先完成单一真源裁决，不能让模型在正文生成时临场选择自己愿意遵守的版本。

五、创作状态：从未来、过去、现在、变化和反馈描述作品

长文本不能每次都依赖模型重新阅读全部历史正文。

系统通过五类创作状态维护连续性：

状态资产	保存什么	不允许怎样使用
计划账	未来准备发生的情节、阶段目标和伏笔安排	不能冒充已经发生的事实
正史账	正文中已经发生并确认的事实	不能为了后续方便静默删除
current_state	下一段开始前人物、物品、位置、关系和能力状态	不能只写模糊的内容摘要
逐章快照	当前内容让哪些状态从什么值变成什么值	不能代替完整当前状态
数据账	发布后的曝光、阅读、追读、完读和平台反馈	不能反向改写正史

例如主角在某一节点拿到一把钥匙：

• 正史账记录"主角已经获得钥匙"；
• current_state 记录钥匙当前由谁持有、位于哪里、能否使用；
• 当前快照记录钥匙从哪个状态转移到哪个状态；
• 后续即使钥匙交给同伴，也只能更新当前状态和快照，不能删除"主角曾经获得钥匙"这一历史事实。

跨会话恢复时，也不需要重新塞入全部正文。更合理的最小上下文是：

• 作品红线；
• 当前适用的品类和作品规则；
• 正史账；
• current_state；
• 已确认的后续计划；
• 最近一到两段正文。

这些状态保证事实和人物位置不漂移，但不能单独保证语气、节奏和叙事质感完全连续。最近正文仍然是必要上下文。

六、授权状态：回答当前作品到底能不能写

创作状态回答"接下来应该怎样写"，系统授权状态回答"此刻能不能写"。

当前作品主要存在以下状态：

状态	含义	默认动作
scaffolded-locked	脚手架已经创建，但尚未获得真实写入授权	禁止起草正文
writable / authorized-write	已获得授权，可以进入写作链路	继续检查写前准备
protected / content-frozen	正文已定稿、投稿、发布或进入保护阶段	拒绝继续修改
blocked / upstream-blocked	上游事实、评审、状态或人工决策尚未解决	停止流程并处理阻塞
legacy-readonly / legacy-frozen	历史作品只读保留	不进入当前生产流程

脚手架成功和正文可写是两道不同的门。

新作品会先登记为 scaffolded-locked。只有真实授权回执被 Runtime 消费后，才可以切换为 authorized-write。即使已经可写，作品仍然需要通过设定、状态、品类规则和当前内容目标等写前准备检查。

当 Loop 无法继续收敛时，Runtime 还可以把作品从 writable 单向降为 blocked，冻结当前正文摘要，等待人工决策或者上游重构。

七、SHA-256、Runtime 和文件锁分别解决什么问题

这三个概念很容易混在一起。

7.1 SHA-256 是内容证据

系统会根据正文文件的路径和字节内容生成 SHA-256 摘要。

摘要可以快速回答：

当前参与比较的正文，是否仍然和之前冻结的正文完全一致？

文件增加、删除、重命名或者任何一个字节发生变化，摘要都可能改变。

但 SHA-256 不知道：

• 谁修改了正文；
• 修改是否合法；
• 修改后质量是否提高；
• 内容逻辑是否正确。

它只证明受比较内容发生了变化。

7.2 Runtime 负责判断变化意味着什么

Node.js Runtime 会重新计算摘要，并结合当前状态作出确定性决定：

• 受保护正文发生变化时，拒绝继续生产；
• 当前正文与获得 PASS 的正文不一致时，旧 PASS 失效；
• manifest 与作品状态文件互相冲突时，失败关闭；
• 当前作品不是 authorized-write 时，拒绝写入；
• 评审上下文变化时，不能复用以前的评审批次；
• 缺少结构化评审证据时，不能标记为定稿或可投稿。

所以更准确的关系是：

SHA-256 提供证据，Runtime 解释证据并执行门禁。

7.3 文件锁只解决并发迁移

文件锁负责避免两个会话或进程同时迁移同一部作品。

它不能判断正文质量，也不能证明正文没有被其他路径修改。它只保证当前受控状态迁移期间，另一个遵守相同协议的进程不能同时进入。

7.4 临时文件与原子替换

一批文件需要共同迁移时，系统采用类似事务的思路：

1. 获取作品文件锁；
2. 在目标文件附近创建临时文件；
3. 写入新字节并执行 fsync；
4. 保存原始字节作为普通异常回滚依据；
5. 通过同文件系统的原子重命名逐个替换；
6. 任一步出现受控异常时，按照已提交顺序逆序恢复；
7. 全部成功后再更新状态和摘要；
8. 最后清理临时文件并释放锁。

这套机制主要覆盖受控迁移和普通异常，不应该被描述成数据库级的崩溃恢复协议。进程强杀、断电或底层文件系统异常仍需要额外的持久化事务日志和恢复协议。

八、正文候选必须先结账，再进入验稿

模型产出正文以后，得到的只是候选稿。

进入正式五路验稿前，需要先同步：

• 当前正文；
• 正史账；
• current_state；
• 逐章快照；
• 合并全文；
• 连载进度和内容范围。

结账检查的目的，是确保评审看到的正文和状态描述属于同一个版本。

如果正文已经写了角色把钥匙交给同伴，但 current_state 仍然记录钥匙在主角身上，那么此时直接验稿没有意义。即使评审通过，证据也建立在互相冲突的输入上。

因此，候选正文必须先完成状态结账，才能冻结 inputHash 和 contextHash，进入下一阶段。

九、机器步骤先处理确定性问题

五路 LLM 评审前，机器链先运行三类自动检查：

• 格式和必需文件预检；
• 观察性评分；
• 逻辑与状态结构检查。

机器检查适合处理：

• 文件是否存在；
• 字段是否完整；
• 正文是否达到结构要求；
• 状态文件是否可解析；
• 必要账本是否同步；
• 评审批次输入是否合法；
• 明确可编码的重复、遗漏和状态冲突。

任一确定性硬项失败时，流程立即返回修复，不启动五路 LLM。

这样做既减少无效 Token 消耗，也避免让模型替脚本判断本来就能确定的问题。

机器链通过只代表输入具备进入主观评审的资格，不能直接解释成作品已经可以投稿。

十、五路评审为什么必须只读

正文通过机器检查后，五类评审 Agent 基于同一份冻结正文和评审上下文并行工作：

角色	主要检查范围
逻辑一致性	时间线、因果、人物认知、物品归属、能力边界和连续性
平台内容适配	当前平台和品类下正文内容是否错位
读者第一印象	开篇是否想继续、结尾是否想继续阅读、哪些内容让人想快进
写作技法	场景、节奏、对白、叙事和文字表达
常识合理性	生活常识、物理动线、制度流程、数值和现实可行性

每个角色只负责发现自己边界内的问题，不直接修改正文，也不独立签发返工命令。

如果评审一边检查一边修改：

• inputHash 会不断变化；
• 后续角色面对的不是同一版正文；
• 五路意见无法比较；
• 旧上下文和新正文可能互相错配；
• 评审者同时变成参赛者；
• 最终 PASS 无法绑定到唯一输入。

因此，五路先提交 candidate 或 uncertain 问题。主流程再负责验真、去重、正文问题与投稿包装问题分流，以及跨角色冲突裁决。

只有被主流程接受的正文阻塞问题，才进入统一返修。

十一、统一返修与四态 Loop

一轮评审发现的全部正文阻塞问题会合并成一次返修，不能采用：

修一条 → 重跑五路 → 再修一条 → 再重跑五路

这种方式会让 Token 和时间快速膨胀，而且不同修改之间容易互相影响。

修改后正文会产生新的 inputHash。由于以前的 PASS 只绑定旧正文，新版本必须重新接受评审。

当前 Loop 设置了明确的收敛边界：

• 默认目标是 P0、P1 正文问题清零；
• P2 默认不阻塞交付，除非用户明确开启额外润色；
• Production Full 最多执行 3 次；
• P0、正文 blocker 和 unresolved 三项不能增加；
• 至少一项下降，并且已修根因没有复发，才算本轮有改进；
• 连续 2 次没有改进时停止；
• 无法继续裁决时进入 NEEDS_DECISION；
• NEEDS_DECISION 会把作品降为 blocked，等待人工处理。

停止不是流程失败，而是避免用无限 Loop 假装模型必然能够收敛。

十二、为什么正文和评审上下文都需要哈希

评审证据不只绑定正文，还绑定完整评审上下文。

• inputHash：当前正文输入的摘要；
• contextHash：公共规则、品类规则、作品护栏、正史、当前状态、评审合同和外部插槽配置等上下文的摘要。

即使正文没有变化，只要评审规则或者作品状态变了，旧结论也不能自动复用。

例如：

• 正文仍是 H1；
• 以前的上下文是 C1；
• 后来补充了一条新的作品红线，得到 C2；
• 旧 PASS 实际证明的是 H1 + C1；
• 当前交付需要证明的是 H1 + C2。

两者不是同一个评审输入，必须换批次重跑。

因此，PASS 不是挂在内容名称上，而是绑定到具体的正文版本和上下文版本。

十三、EvalOps 保存的不只是最终分数

如果系统只保存最终正文和"通过"结论，出现问题时只能重新拆测。

当前 Trace 会记录：

• 批次 ID；
• inputHash 与 contextHash；
• 节点和角色名称；
• 模型及参数；
• 原始输入和输出；
• 输入、输出和缓存 Token；
• 开始时间、结束时间和持续时间；
• 工具调用；
• 节点结论与失败原因；
• 机器原始记录；
• 五份角色原始记录；
• 最终生产 sidecar 和可重放校验结果。

这些信息支持回答：

• 哪个节点最耗 Token；
• 哪个角色运行最慢；
• 哪个 Agent 没有按照预期返回结构；
• 哪一轮修改使问题回归；
• 某个 PASS 到底绑定哪版正文；
• 当前结果能否被确定性重放。

Trace 的价值不是证明流程运行过，而是让后续优化能够定位到具体变量。

十四、优化时为什么只能改变一个变量

如果同时更换模型、Prompt、正文和上下文，即使结果变好，也无法证明是哪项修改产生了效果。

因此，不同优化目标需要冻结不同条件：

• 比较模型：保持 inputHash、contextHash、参数和样本集一致；
• 优化上下文：只改变上下文方案，保持正文、模型和其他条件一致；
• 优化评审规则：保持正文、模型和非目标规则一致；
• 优化 Loop：保持回归集和单轮评审合同一致，再比较轮数、Token、耗时和质量结果。

成本下降也不能单独证明优化成功。

如果 Token 下降，但真实坏例检出率同时下降，这只是降配，不是可靠优化。质量门和成本指标必须放在同一次冻结实验中比较。

十五、29 个真实坏例如何形成回归证据

当前正式回归集包含 29 个过去生产流程中真实出现过的问题。

这些问题一部分被原有规则发现，一部分由人工补充发现。它们不是为了适配当前评审标准而临时生成的理想样本。

如果根据某个缺陷描述生成坏例，再使用同类规则识别这个缺陷，很容易形成自证循环：样本本身已经按照答案设计，检出结果会过于乐观。

29 个真实坏例分别交给五类评审角色，形成：

29 × 5 = 145 份原始记录

五路联合捕获了其中 27 个，另外 2 个漏检原样保留。

这个结果只能证明当前方案对这组真实历史缺陷的覆盖情况，不能泛化成对所有长文本问题的统一检出率。

保留两条漏检比删除失败样本更重要，因为它们正是下一轮规则和角色边界调整的依据。

十六、外部写作 Skill 是可选执行插槽

正文起草阶段还预留了外部写作 Skill 插槽。

是否启用由用户要求和作品配置决定。外部 Skill 必须满足：

• 位于代码白名单；
• 许可证符合登记要求；
• 绑定固定版本或 Git commit；
• 来源与本地适配件摘要一致；
• 运行时不追随远端最新版本；
• 只能输出正文候选、诊断或者拒绝结果；
• 不能修改正史、状态、平台决策和评审结论；
• 不能签发 PASS；
• 失败时只关闭外部插槽，宿主 Workflow 继续运行。

外部 Skill 不是第四层 Guardrail，也不是第六个评审角色。它只是正文起草环节的可选增量能力，最终合稿权仍属于宿主三层约束和主流程。

当前生产流程没有实际启用这一插槽，因此能够确认的是接入契约和隔离边界，而不是生产效果。

十七、平台数据怎样回到创作计划

正文投稿或发布以后，平台数据进入数据账。

只有投稿状态、少量曝光和稳定样本量不是同一种证据，需要区分不同的数据成熟阶段。

平台数据可以推动：

• 调整后续节奏；
• 提前冲突或高潮；
• 修改计划账；
• 检查内容类型和平台是否错配；
• 决定继续、调整或者止损；
• 为下一部作品的选题提供参考。

但数据不能直接推动：

• 删除已经发生的内容；
• 修改人物已经公开做出的选择；
• 让同一物品无解释出现在另一个地点；
• 为了流量把旧正史改成另一条时间线。

正确的闭环是：

平台反馈 → 数据账 → 归因 → 修改未来计划 → 新正文 → 新评审 → 新平台数据

而不是：

平台数据不好 → 回头改写历史事实

十八、当前系统的能力边界

这套系统已经实现了 Workflow、状态账本、授权门禁、哈希绑定、五路评审、Trace 和回归资产，但仍然有几条必须明确的边界。

18.1 公共 Agent Host 仍可能绕过项目 Runtime

如果 Codex 或 Claude Code 拥有工作区文件的原始写权限，它理论上可以绕过 Node.js 脚本直接修改正文。

当前方案可以保护遵循既定 Workflow 的主路径，并通过哈希和状态检查发现覆盖范围内的漂移，但不是操作系统级权限隔离。

如果要做到所有写入绝对经过 Runtime，需要把正文存储移到 Agent Host 无直接写权限的位置，由独立 Runtime 或 MCP 服务持有唯一写入凭证。

18.2 哈希不能识别内容逻辑

SHA-256 只能发现字节变化。

状态冲突由确定性 Runtime 识别，因果、人物动机、读者体验和文字质感仍然由评审 Agent 概率性判断，因此可能漏检。

18.3 五个 Agent 身份不等于密码学证明

结构化记录可以保存 agentId、角色、双哈希和原始输出，但工作区内自报的 agentId 不能单独证明五份结果一定来自五个不可伪造的独立宿主任务。

如果需要更强的来源证明，仍需要 Agent Host 提供绑定角色、调用身份、输入哈希和原始输出的外部回执。

18.4 内部通过不等于市场成功

五路评审和自动检查主要控制逻辑、表达和平台内容适配下限。

它们不能保证平台一定分发，也不能保证真实读者一定继续阅读。平台结果和真实读者行为必须作为独立业务证据回流。

十九、如果要还原这套系统，真正需要保存什么

只保存正文 Prompt，无法还原这条生产线。

至少需要保存以下资产：

1. Workflow 契约：每个阶段的入口、输出、失败条件和恢复路径；
2. 知识来源契约：来源索引、时间、指纹、共识与分歧裁决；
3. Context 契约：公共、品类和作品三层 Guardrails；
4. 创作状态契约 ：计划账、正史账、current_state、逐章快照和数据账；
5. 授权状态契约：脚手架锁定、可写、保护、阻塞和历史只读状态；
6. 文件迁移协议 ：文件锁、临时文件、fsync、原子替换和回滚边界；
7. 评审合同：机器预检、五路职责、问题 Schema 和主线程裁决规则；
8. Loop 契约：严重程度、改进定义、轮次上限和停止状态；
9. 证据绑定 ：inputHash、contextHash、批次 ID、原始输出和生产 sidecar；
10. 回归资产：真实坏例、盲审协议、检出记录和保留漏检；
11. 平台闭环：投稿物料、发布状态、数据账和计划调整记录。

这也是整次梳理后最重要的认知：

长文本生产不是模型记得多少设定，而是系统能否解释每次事实变化、每次写入授权、每次评审结论和每次优化依据。

结语

回看整条链路，我会把它概括成三句话：

• 创作账本决定当前作品已经发生什么、现在是什么状态、未来准备发生什么；
• Node.js Runtime 决定当前是否允许继续，以及旧证据能不能用于当前正文；
• 写作与评审 Agent 在这些边界内处理文字生成、逻辑判断和读者体验。

真正的工程质量，不只看模型能不能生成一部完整作品，也不只看内部评分高不高，而是看：

• 跨阶段事实能否恢复；
• 未授权写入能否被阻断或发现；
• 正文与评审证据能否一一绑定；
• 多角色意见能否保持同版输入；
• Loop 无法收敛时能否停止；
• 真实坏例能否进入回归；
• 平台数据能否回到下一轮计划；
• 已实现能力和未验证边界能否被准确区分。

当这些环节都能留下状态和证据，长文本生产才不再是一场不可解释的长对话，而是一套可以恢复、可以复盘、也可以继续演进的生产系统。