全量输出强制器

要解决的问题

大模型默认倾向简短输出，于是常见三类偷工：

• 代码块里出现 // ...、// TODO、// 实现略 这类占位符，把未完成的逻辑推给用户
• 正文里用「为简洁起见，其余从略」「如需更多细节可以告诉我」「剩下的当作练习」搪塞
• 请求完整文件却只给骨架，或只展示首尾两段、跳过中间部分，用一段描述代替重复逻辑的实现

接近 token 上限时，模型还容易压缩剩余章节、直接跳结论。结果是下游工程师拿到的是半成品，要么自己补全，要么逐段追问，返工成本往往比手写还高。

它如何工作

执行流程分三步，并配合硬性禁令与长输出处理：

1. Scope（定界） — 通读完整请求，数清交付物数量（文件、函数、章节、回答各几个），把这个数锁死。
2. Build（生成） — 逐个完整产出，没有半成品草稿，没有「可自行扩展」。
3. Cross-check（复核） — 输出前拿原请求逐项对照，缺什么补什么。

硬性禁令——以下三类输出被视为硬失败，绝不能出现：

• 代码块中的占位符：// ...、// rest of code、// implement here、裸 ... 代替省略代码
• 文本中的搪塞话术：「for brevity」「the rest follows the same pattern」「I'll leave that as an exercise」
• 结构性偷懒：请求全量实现却只给骨架、只展示首尾跳过中间、用描述代替重复逻辑的实现

长输出处理：接近 token 上限时，不得压缩剩余章节、不得跳结论，而是在干净断点（函数末尾、文件末尾、章节末尾）停下质量完整的部分，结尾附上：

On "continue", pick up exactly where you stopped.

用户回复 continue 后，从停下处原样继续，不回顾、不重复。

适用场景与注意点

• 最适合要求 exhaustive、unabridged 全量输出的任务：完整文件、全部组件、逐节正文。
• 对「给个思路就行」「列出要点即可」的请求是过度约束——用户要的是概要，不是全量，别硬塞完整实现。
• 它不生成原本不存在的功能，只做一件事：请求里有几项交付物，就完整交付几项，并以输出前校验兜底。
• 长输出记得用 continue 触发续写，否则模型可能把剩余部分「截断式合并」进结论。