mobile-adaptation

name	mobile-adaptation
description	当系统提示面向移动端（手机、平板）场景时调用。适用于 iOS/Android 应用内 AI 助手、移动端聊天界面、响应式输出的系统提示设计。不适用于桌面端优先的场景，不适用于移动端 UI 开发（非提示层），不适用于语音场景（语音场景使用 voice-optimization）。
tags	["移动端","屏幕适配","响应式输出","移动工具集成"]
related_skills	["voice-optimization","citation-system"]

移动端适配

R — 原文 (Reading)

Claude Mobile iOS 基于屏幕尺寸设定响应层级：手机一次显示 6-8 句话，简单问题 1-2 句、操作指南短列表、实质问题 2-3 段、复杂问题不超过 2 屏。集成移动原生工具（日历、提醒、位置、图表）。Claude for Word 禁止管道分隔的 Markdown 表格（任务窗格太窄）。Gemini 实现移动端专项输出压缩。核心模式：屏幕尺寸响应分级、移动原生工具集成、格式限制、答案优先策略。

I — 方法论骨架 (Interpretation)

1. 屏幕尺寸感知分级：根据目标设备屏幕容量将回答分为 4 个层级，每个层级有明确的长度上限（句数、段数或屏数）。
2. 答案优先策略：移动端用户注意力碎片化，回答结构必须"结论先行、细节后置"，禁止铺垫性开场白。
3. 格式限制清单：在窄屏场景中禁用特定格式——管道表格、深层嵌套列表、宽代码块、大段引用。
4. 移动原生工具集成：利用移动设备独有能力（日历、提醒事项、地理位置、本地时间、图表显示）增强交互。
5. 扫描友好结构：使用短列表、加粗关键词、分段标题等格式，使用户在 3-5 秒内定位核心信息。

A1 — 案例分析 (Past Application)

案例: Claude Mobile iOS 的四层响应分级

• 问题: 移动端屏幕一次只能显示 6-8 句话，过长的回答需要大量滚动，严重影响移动场景下的信息获取效率。
• 设计模式的使用: Claude Mobile iOS 将回答分为四个层级并设定严格长度约束——简单问题 1-2 句话直接回答，操作指南用最短列表，实质性问题 2-3 段，复杂问题不超过 2 个屏幕。所有层级均遵循"先给答案、无前言"原则。
• 结论: 基于物理屏幕约束的量化分级比模糊的"尽量简短"指令有效得多，为模型提供了可执行的长度标准。

案例: Claude for Word 的表格格式禁令

• 问题: Word 插件的任务窗格宽度极窄（约 300-400px），管道分隔的 Markdown 表格会溢出或折行混乱。
• 设计模式的使用: Claude for Word 明确禁止在聊天中使用管道分隔的 Markdown 表格（"No pipe-delimited markdown tables in chat"），改用结构化列表或自然语言描述替代。
• 结论: 格式限制需要具体到特定的 Markdown 语法元素，泛化的"注意格式"指令无法精准解决窄屏适配问题。

A2 — 触发场景 (Future Trigger) ★

用户在什么情境下需要?

1. 设计手机 App 内嵌 AI 助手的系统提示
2. 优化现有桌面端系统提示以适配移动端
3. 构建跨平台 AI 产品，需针对不同屏幕尺寸差异化输出
4. 开发集成移动原生功能（日历、位置）的 AI 助手

语言信号

• "移动端用户"
• "手机屏幕上显示"
• "小屏幕适配"
• "需要集成日历/提醒/定位"
• "App 内的 AI 助手"

与相邻 skill 的区分

• 与 voice-optimization 区别：语音优化关注听觉通道，移动适配关注视觉通道的物理约束；但两者共享简洁优先理念
• 与 citation-system 区别：引用在移动端需要特殊展示（如简化标记、折叠引用），但移动适配不涉及引用格式设计本身

E — 可执行步骤 (Execution)

1. 步骤 1：定义屏幕响应分级表 - 完成标准：基于目标设备屏幕容量，定义 4 级响应策略（简单/操作/中等/复杂），每级规定最大句数、段数或屏数，并附具体示例。
2. 步骤 2：编写格式限制清单 - 完成标准：列出在移动端禁止使用的格式类型（管道表格、深层嵌套列表、超过 60 字符的代码行等），并为每种禁止格式提供替代方案（表格→结构化列表、嵌套列表→扁平列举）。
3. 步骤 3：设计答案优先输出结构 - 完成标准：在系统提示中声明"结论先行"原则，规定回答结构为：直接答案 → 关键细节 → 可选扩展，并禁止铺垫性开场白。
4. 步骤 4：规划移动原生工具集成点 - 完成标准：列出可调用的移动原生能力（日历创建、提醒设置、位置查询、时间获取），为每个能力定义触发条件和调用格式。
5. 步骤 5：添加扫描友好格式规范 - 完成标准：规定移动端输出的格式增强规则——关键信息加粗、列表项不超过一行、段落间空行分隔、使用 emoji 前缀（如适用）提升视觉扫描效率。

B — 边界 (Boundary) ★

不要在以下情况使用

• 桌面端优先的系统提示设计，屏幕空间不是主要约束
• 移动端 UI/UX 设计（属于前端开发，非提示层）
• 纯语音交互场景（无屏幕显示，应使用 voice-optimization）
• 后端 API 设计（与输出展示层无关）

常见失败模式

• 量化标准缺失：仅说"尽量简短"而不给出具体句数或屏数限制，模型无法精确控制输出长度
• 一刀切压缩：将所有问题都压缩为一两句话，复杂问题信息丢失，应按复杂度分级处理
• 忽视原生能力：仅优化文本输出但未利用移动设备独有的日历、位置、提醒等能力，错失交互增强机会
• 格式限制过于笼统：说"注意移动端格式"而不具体指出禁止管道表格等特定语法，模型可能仍输出不适配格式