output-formatting

name	output-formatting
description	当系统提示词需要为 AI 输出定义格式规范、长度约束、风格指南或反"AI味"策略时调用此 Skill。适用于聊天机器人、CLI 工具、移动端助手、设计生成器等需要自适应输出的场景。不适用于：纯内容生成（无格式要求）、内部推理链设计、安全策略制定。当需求仅涉及"用什么格式返回数据"而非"如何控制输出的风格与密度"时，这不是最佳 Skill。
tags	["输出格式","风格控制","反AI味","自适应长度","平台适配"]
related_skills	["conversation-flow","context-management"]

输出格式与风格控制

R — 原文 (Reading)

多个 AI 供应商系统提示词中共同浮现的输出控制模式：按复杂度自适应长度、按平台定制格式、用反"AI slop"启发式规则消除机械化表达。Claude Mobile 按屏幕尺寸分四档长度；Gemini CLI 限制三行以内；Meta AI 禁用"Here's a..."等套话；Le Chat 用表格替代列表；Claude Design 禁用圆角容器和 Inter/Roboto 字体。

I — 方法论骨架 (Interpretation)

1. 复杂度分级 — 按问题深度映射输出长度档位（一句话 / 短列表 / 两三段 / 完整文档）
2. 平台感知 — 检测目标载体（CLI / 移动端 / 桌面 / API），应用对应格式约束
3. 前置答案原则 — 结论先行，解释后置；"Always lead with the answer"
4. 反 AI slop 规则集 — 禁止套话开头、无意义表情符号、过度格式化、破折号滥用
5. 领域标记语言 — 为特定平台定制标记（Notion 压缩 URL {{1}}、GPT-4o image_group JSON）
6. 格式降级策略 — 默认散文体，仅在必要时使用列表/表格，绝不"为了好看而格式化"
7. 引用密度控制 — 代码引用使用 file_path:line_number 格式，摘要限制在 1-2 句

A1 — 案例分析 (Past Application)

案例: Claude Mobile 屏幕尺寸自适应输出

• 问题: 移动端屏幕空间有限，长回复导致用户需要大量滚动，体验差
• 设计模式的使用: Claude Mobile 系统提示词定义了四级长度策略：简单问题 → 1-2 句话；操作指南 → 短列表；实质性问题 → 2-3 段；复杂主题 → 不超过两屏。同时强制"答案先行"原则
• 结论: 该策略在有限屏幕空间内最大化信息密度，用户可快速获取核心答案，需要时再向下滚动查看细节

案例: Meta AI 反套话策略

• 问题: AI 回复普遍带有"Here's a..."、"Great question!"等机械化开场白，用户反感
• 设计模式的使用: Meta AI 系统提示词明确禁止此类套话，要求使用扁平列表、表格呈现结构化数据，禁止破折号，保持直接风格
• 结论: 消除 AI slop 后用户满意度显著提升，说明格式控制不仅是美学问题，更是体验核心

A2 — 触发场景 (Future Trigger) ★

用户在什么情境下需要?

1. 设计聊天机器人系统提示词时，需要控制回复长度和格式
2. 为 CLI 工具定义输出规范，要求简洁无废话
3. 为移动端 AI 助手适配屏幕尺寸约束
4. 设计品牌专属的 AI 输出风格指南（如设计工具中禁止特定字体和视觉元素）
5. 构建多平台 AI 产品，需要为不同载体定义差异化输出策略

语言信号

• "回复太长了/太啰嗦了"
• "输出格式需要适配手机屏幕"
• "不要那些 AI 常用的套话"
• "简洁一点，像终端工具那样输出"
• "品牌风格指南要求避免..."

与相邻 skill 的区分

• 与 conversation-flow 的区别: 本 Skill 聚焦输出的"形式"（长度/格式/风格），conversation-flow 聚焦交互的"流程"（路由/澄清/自主度）
• 与 context-management 的区别: context-management 管理输入侧的 token 预算，本 Skill 管理输出侧的格式密度

E — 可执行步骤 (Execution)

1. 定义复杂度分级表 — 完成标准: 建立至少三档长度映射（简单/中等/复杂），每档有明确的句子数或行数上限，并与目标平台视口尺寸挂钩

2. 编写反 AI slop 黑名单 — 完成标准: 列出至少 10 条禁止项（套话开场白、无意义表情符号、过度格式化、破折号滥用、Inter/Roboto 字体、圆角容器等），每条附带替代方案

3. 设计平台格式规范 — 完成标准: 为每个目标平台（CLI/移动端/桌面/API）定义默认格式模式（如 CLI 默认三行散文体、移动端默认答案先行+短列表），包含领域专用标记语法说明

4. 建立格式降级规则 — 完成标准: 明确"默认散文体 → 必要时列表 → 复杂时表格 → 极少时代码块"的升级路径，以及每级的使用触发条件

5. 添加输出自检钩子 — 完成标准: 在系统提示词末尾加入输出自检指令："生成后检查：是否套话开头？是否过度格式化？答案是否在前两句内出现？"

B — 边界 (Boundary) ★

不要在以下情况使用

• 用户明确要求某种特定格式（如 JSON Schema、XML）— 这属于数据契约而非风格控制
• 输出对象是机器而非人类（API 返回值、结构化数据）
• 场景是创意写作或文学创作，格式自由度是需求的一部分
• 仅需控制内容安全性（如敏感词过滤），不涉及格式和风格

常见失败模式

• 过度约束导致回复僵化：把"简洁"理解为"只回答是/否"，丢失关键上下文
• 反 AI slop 走向极端：禁止所有表情符号和格式标记，导致技术文档可读性下降
• 忽视平台差异：在桌面端适用的回复长度直接搬到移动端，不做适配
• 混淆输入压缩与输出控制：试图通过限制输出来解决 token 预算问题，应该用 context-management 而非本 Skill