完整输出强制器

要解决的问题

把需求交给模型时，最常见的失败不是「答错了」，而是「答到一半就停了」。只要你要一份完整文件，它常回你一段骨架：开头几行，中间几个 // ...，结尾一句「其余部分同理」。你拿到的不是可运行代码，而是一份说明书，还得自己把逻辑补回去。

更麻烦的是这类输出会自我合理化——「为简洁起见」「如需要我可以继续」。一旦接受这个前提，就等于默认残缺的交付物是正常的。

核心能力

这个技能把「完整性」设为硬约束，而非风格建议。它针对的失败模式很具体：

• 代码块内的占位符：// ...、// rest of code、// implement here、// TODO、/* ... */、// similar to above、// continue pattern、// add more as needed，以及单独一个 ... 顶替被省略的代码，全部算硬错误。
• 散文里的推脱话术：Let me know if you want me to continue、for brevity、the rest follows the same pattern、similarly for the remaining、and so on、I'll leave that as an exercise，一律不允许出现。
• 结构性偷懒：你要完整实现，它只给骨架；只展示首尾两节，中间整段跳过；用一个例子加一句描述替代重复逻辑；用文字描述代码该做什么，而不真的写出代码。

执行流程

技能按三步运行：

1. Scope：读完整个请求，数清有多少个独立交付物——文件、函数、章节、答案，把这个数字锁死。
2. Build：完整生成每一个交付物，不留半成品，不写「你可以自己扩展」。
3. Cross-check：输出前重读原始请求，把交付物数量与 scope 阶段锁定的数字逐一比对，缺什么补什么，补齐后才作答。

收尾还有一道 Quick Check：确认输出中没有上述任何禁用模式，每个请求项都已存在且完成，代码块里是真正可运行的代码而非对代码的描述，没有内容是为省空间而被缩短。

长输出与边界

当回复逼近 token 上限，正确做法不是把剩下几节压缩硬塞，也不是直接跳到结论，而是在干净的断点处收住——函数末尾、文件末尾、章节末尾——保证写到那里的仍是完整质量。结尾固定附上：

收到 continue 后从停下的位置接着写，不重复，不回顾。

要注意的是，这套规则会显著拉长输出。它适合代码补全、批量组件生成、完整文件重建这类「部分即失败」的场景；对于只需要一句结论或简短要点的问题，强制完整反而会造成噪音。另外「干净断点后停止」依赖后续用 continue 触发续写，若客户端不支持这个约定，长输出可能被截断且无法自动恢复。