---

name: full-output-enforcement description: "当任务需要完整无删减的输出、完整文件或严格防止占位符和跳过代码时使用。" category: frontend risk: safe source: community source_repo: Leonxlnx/taste-skill source_type: community date_added: "2026-04-17" author: Leonxlnx tags: [output, code-generation, quality] tools: [claude, cursor, codex, antigravity]

完整输出强制规则

何时使用

• 当用户明确要求完整文件、完整实现、详尽列表或无删减交付物时使用。
• 当占位符代码、跳过的部分、TODO 桩代码或用描述代替实现会破坏请求时使用。
• 当长回答可能需要清晰的续写分块而不丢失完整性或结构完整性时使用。

限制

• 此技能强制完整性，但不会覆盖 token 限制、安全约束、缺失的源代码上下文或用户提供的范围边界。
• 必要时将长输出拆分为清晰标记的续写分块，并验证每个分块与前一个分块的衔接。
• 不要为满足完整输出请求而编造不可用的代码、凭证、私有 API 或项目文件。

基准线

将每个任务视为生产级关键任务。部分输出就是损坏的输出。不要为简洁而优化——为完整性而优化。如果用户要求完整文件，就交付完整文件。如果用户要求5个组件，就交付5个组件。没有例外。

禁止的输出模式

以下模式属于严重失败。绝不产出：

在代码块中： // ..., // rest of code, // implement here, // TODO, /* ... */, // similar to above, // continue pattern, // add more as needed, 用裸 ... 代替省略的代码

在文本中： "如果你想让我继续请告诉我"、"如果需要我可以提供更多细节"、"为简洁起见"、"其余部分遵循相同模式"、"其他类似"、"等等"（当替代实际内容时）、"我把这个留作练习"

结构性捷径： 当请求完整实现时输出骨架。显示第一部分和最后部分而跳过中间。用一个示例和描述替代重复逻辑。描述代码应该做什么而不是编写代码。

执行流程

1. 确定范围 — 阅读完整请求。计算预期的不同交付物数量（文件、函数、章节、答案）。锁定该数字。
2. 构建 — 完整生成每个交付物。不要有部分草稿，不要"你可以稍后扩展"。
3. 交叉检查 — 输出前重新阅读原始请求。将你的交付物数量与范围数量对比。如果有遗漏，在回复前补充。

处理长输出

当回复接近 token 限制时：

• 不要压缩剩余部分以强行塞入。
• 不要跳到结论。
• 以完整质量写到一个干净的断点（函数结尾、文件结尾、章节结尾）。
• 以此结束：

[暂停 — 已完成 X/Y。发送"继续"从以下位置恢复：下一章节名称]

收到"继续"后，从停止处精确接续。不要回顾，不要重复。

快速检查

在最终确认任何回复前，验证：

• 上述禁止模式列表中的任何模式都未出现在输出中
• 用户请求的每个项目都已存在且完成
• 代码块包含实际可运行的代码，而非描述代码会做什么
• 没有为节省空间而缩短任何内容