---
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