流结束不等于完成：免费模型长代码生成的截断陷阱

当模型和服务器都免费时，长代码生成看起来毫无成本，但一个隐蔽的故障模式正在等待：传输层告诉你流已结束，你拿到的却是一个语法合法的半截函数。一位开发者在 48 小时的实地调试中，重建了围绕「可验证产物」的采集循环，并记录了每一步踩坑与修复。

为什么免费访问改变了 bug 的形态

当推理按 token 计费时，你自然会压缩输出长度、收紧重试预算。免费模型加免费服务器则反转了这个激励：长生成显得廉价，于是你要求整个模块，并把客户端跑在视线之外。原文作者明确指出：「可用性是给定的，但延迟、配额和持久性是我拒绝假设的。」

真正值得追问的不是「模型够不够好」，而是「一个被截断的答案从外部看起来是什么样」。读超时被丢弃、代理关闭空闲连接、笔记本休眠，都会产出同一个东西：一个前缀。而合法代码的前缀往往仍然是合法代码，这正是它能通过冒烟测试的原因。

幂等性与可重跑性是理解本文设计的前提。所谓可重跑，指同一任务用相同输入再次执行时，结果可被独立复核或重新生成，不依赖上一次运行的残留状态。作者之所以强调「任何无法重跑的任务不适合此流程」，是因为免费端点随时可能限流或断连，一旦失败且无法重跑，采集到的半截产物就成了唯一副本，账本中的哈希与路径也就失去了追责意义。在可重跑的前提下，每个运行独占目录、每次尝试写入账本，都是为了让失败成为一次可被审计的事件，而不是一次不可逆的损失。

三个文件与一条规则

作者的核心规则很朴素：永远不要向一个你无法描述的文件追加内容。采集器在同一目录下维护三个产物，各回答一个问题：

• answer.part：目前已收到的原始字节，每个 chunk 后执行 fsync。
• ledger.jsonl：仅追加的事件流，记录 chunk 偏移、前缀哈希、流错误与验证结论。
• prompt.txt：精确的请求文本，在第一个字节到达前写入。

为什么用前缀哈希而不是字节数？字节数告诉你「有多少」，哈希才告诉你「你准备续写的，是不是你真正采集到的那个东西」。如果续传写入了与哈希时不同的文件，你要到 diff 无法阅读时才会发现。

fsync 与写入持久性：fsync 是 POSIX 系统调用，强制将文件系统缓冲区中的数据刷写到物理存储，确保即使进程崩溃或机器断电，已写入的字节也不会丢失。普通 write 只保证数据进入内核页缓存，崩溃时可能丢失最后若干 chunk。本文主张每个 chunk 后 fsync，代价是显著降低吞吐量，但换来一个崩溃后状态诚实的 answer.part。对于免费机器上可能随时被回收的长代码生成，这个交换让「已收到多少字节」与磁盘上的实际内容保持一致，前缀哈希才有意义。

诚实标注的采集器

原文给出了一份 Python 采集脚本，作者刻意将其定位为「实验室产物」：未经你的端点验证，运行前请自行阅读并填写环境变量。脚本用 OpenAI 兼容接口以流式方式拉取补全，关键设计点集中在两处。

第一，[DONE] 帧只被记录为 transport_done，绝不记为 complete——这是两个不同的断言。第二，单个畸形帧跳过而非抛出异常，因为一行坏数据不该让整次生成作废。

拒绝「看似合理前缀」的验证器

提示词末尾要求模型在完成代码后，单独一行输出精确标记 # ---END---。这个哨兵是整个技巧的核心，它把「模型说完了」和「套接字关闭了」区分开来。

验证器的检查顺序至关重要：先查哨兵，再交给 compile() 解析。顺序颠倒的后果很直接——一个被截断但语法合法的前缀会顺利通过编译，带着绿色对勾被交付出去。作者在 48 小时日志的第 20 小时就遇到了变体：花括号平衡、却终止在字符串字面量内部的文件骗过了验证器。

compile() 的语法检查边界：Python 的 compile() 只验证源码是否符合语法规则，不验证语义完整性，也不关心函数体是否写完。因此一个在字符串字面量内部被截断的文件，只要引号与括号在截断点之前恰好平衡，就可能通过编译。哨兵标记 # ---END--- 是模型在生成完毕时主动输出的内容信号，与语法合法性正交。先查哨兵、再调 compile() 的顺序，本质上是先用内容完成信号排除截断，再用语法检查排除格式错误，两者不可互换。

续传而不把模型问死

失败时，作者把最后约 1200 个字符作为 assistant 轮次回传，附一条简短指令：从这里精确续写，不要开场白，不要总结。最多续传两次，之后运行以非零状态失败。事后用 jq 从账本中读出每次尝试的验证结论。

assistant 轮次与续写上下文：在 OpenAI 兼容的对话接口中，消息按 role 分为 system、user、assistant 等轮次。续传时把已收到的尾部作为 assistant 轮次回传，等于告诉模型「你之前已经说到了这里」，模型便会从该位置继续生成，而不是重头开始。若只重发完整提示词而不携带部分答案，模型会从头生成，导致尾部重复。作者把续传上限设为两次并以非零状态退出，是为了避免模型在反复续写中陷入循环或产生与原答案不一致的补全，同时让失败显式暴露给调用方。

48 小时故障日志

按发生顺序，原文记录了五次主要故障：

• 第 2 小时：轻信了 [DONE]。修复：提示词中加入哨兵，并最先检查。
• 第 9 小时：续传重复了尾部，因为重发了完整提示词而未附带部分答案。修复：续写消息始终把尾部作为 assistant 轮次携带。
• 第 20 小时：验证器放行了一个终止在字符串字面量内的文件。修复：哨兵优先，解析器其次，顺序不可颠倒。
• 第 31 小时：存在两个 answer.part，哈希了错误的那个。修复：账本在每个哈希旁记录绝对路径。
• 第 44 小时：长时间空闲杀死连接，重试循环静默跑了四次。修复：续传上限设为两次，触发即以非零退出。

作者表示会毫不犹豫重复的做法是：每次运行独占一个目录、每个 chunk 后 fsync、每次尝试都在账本中留下结论行。账本是第 31 小时只花十分钟修复而非重写的唯一原因。

适用边界与不该用的场景

原文用一张表划定了适用范围。适合的场景包括：人工审核后再使用的长代码生成（哨兵、解析器、两次续传上限）、批量文档字符串或测试脚手架（同样的账本，更小的输出）。不适合的场景同样明确：延迟敏感的请求路径（没有 SLA 可依赖）、受监管或机密数据（数据流审查在你自己，不在网络）、以及任何无法重跑的任务——可重跑性就是整个安全网。

作者还点名了三类不该使用此流程的人：输出未经人工阅读就进入部署的人、承担不起第二次运行的人、以及团队在任务失败时不会去看 ledger.jsonl 的人。如果账本对你只是噪音，这套工作流就只是围绕一个截断文件多打的几个字。

作者刻意不测量的东西

原文拒绝发布计时、吞吐量或成功率，理由是这些数字属于你的端点和你的提示词形态，而不属于作者。脚本会打印自己的偏移量与结论，你的第一次运行就会替换掉所有本可虚构的占位符。作者能诚实陈述的只有一点：在不止一次运行中，哨兵检查抓住了 compile() 单独放行的截断。

作者给出的下一步很小：如果你已经有免费模型访问和一个免费服务器槽位，把这个采集器指向一次你本就信任的长生成，然后观察 verify 行在 transport_done 之后于第几小时翻转为 false。

FAQ

[DONE] 是完成信号吗？ 它是传输信号。模型自身的输出结束标记才是唯一能代表内容完成的证据。

每个 chunk 都需要 fsync 吗？ 它牺牲吞吐量，换来崩溃后一个诚实的文件。对于免费机器上的长代码生成，作者接受这个交换。

只运行一次可以跳过账本吗？ 可以，但当结果看起来不对时，你将无从分辨它是被截断的答案还是一个本就简短的答案。

（披露：原文注明该文为 MonkeyCode 产品推广的一部分。）