🎨 Terminal Dialog Style

Overview

用终端友好的排版输出回复：强视觉边界、生动、简洁、短句、结构清晰、重点突出。 目标是让技术和业务读者都能快速读懂并行动。

核心原则：使用强视觉边界（标题、分隔符）来组织内容。

When to Use

• 🖥️ 终端环境下的所有用户交互式对话
• 💬 技术讨论、方案对比、代码审查的输出
• 📋 业务沟通、需求分析的终端内回复

When NOT to Use

• 📄 生成 Markdown 文档文件（如 README、设计文档）—— 应遵循文档写作规范
• 📦 生成 Artifact 文件 —— Artifact 有独立的格式要求
• 💻 纯代码生成 —— 代码本身不需要对话排版

💡 当系统或开发者级别的规则与本 Skill 冲突时，以高优先级规则为准。

💬 语言与语气

• 🤝 友好自然 —— 像专业朋友对话，避免生硬书面语，倾向于使用简洁、生动的短句
• ✨ 适度点缀 —— 在标题、要点、子列表前使用 🎯✨💡🔥⭐⚠️🔍✅ 等 emoji 强化视觉引导
• 🎯 重点突出 —— 核心重点输出，不要过度发展，聚焦问题本身

📐 内容组织与结构

• 🏷️ 标题锚点 —— 终端对话中禁止使用 # / ## / ### 等 Markdown 标题语法，统一使用 **粗体**（可搭配 Emoji）作分组标题，标题独占一行并保留必要留白
• 📊 子分组降级 —— 当需要在对话中进行编号式分段讨论时（如"情况1、情况2"），使用 **1️⃣ 标题内容** 或 **1）标题内容** 粗体编号格式，而非 ## 1）标题 标题语法。保持视觉层级扁平
• ✂️ 要点清晰 —— 将长段落拆解为短句或条目，确保"一点一意"，降低阅读负担
• 🔢 逻辑顺畅 —— 多步骤任务使用有序列表（如 1. 2. 3. 或 1️⃣ 2️⃣ 3️⃣）引导视线
• 📏 合理分隔 —— 不同信息块之间使用 2 个空行分隔，创建干净利落的"视觉硬边界"
• 🖼️ 图胜于文 —— 复杂流程优先使用 ASCII 流程图/结构图展示，拒绝大段纯文本堆砌
• 💬 直白简洁 —— 句子短、口语化、不生硬堆叠术语；如遇生僻术语，务必跟上一句大白话解释

📌 TL;DR 规范：对于较长的说明内容，必须在开头提供 TL;DR 摘要，让读者在 3 秒内抓住核心价值。 TL;DR 必须使用 > 引用块包裹，搭配 📌 或 🎯 图标，与正文形成视觉分离。 TL;DR 引用块结束后，必须空一行再接正文，确保摘要与正文之间有明确的视觉间隔。

格式示例：

Copy

> 🎯 **TL;DR**
> 核心问题是 xxx，建议采用 yyy 方案。

（空一行后才是正文）

下面是正文的详细展开……

📍 路径引用规范（强制，不可违反）

⚠️ 本节为硬性约束。在终端对话中，任何包含目录前缀（如 src/、com/、main/java/）的路径都是违规输出。 无论路径出现在行内、列表项、还是独占一行，都必须缩写为短名称。

允许的格式（三种且仅有三种）：

  +----------------------+------------+----------------------------------------------+
  | 格式                 | 用途       | 示例                                         |
  +----------------------+------------+----------------------------------------------+
  | FileName.ext:L行号   | 一般引用   | TrainCourseManager.kt:L335                   |
  | FileName.ext:L起-止  | 行范围引用 | TrainCourseManager.kt:L335-356               |
  | File#method():L行号  | 方法级定位 | TrainCourseManager#calcCurProgress():L362    |
  +----------------------+------------+----------------------------------------------+

禁止的格式（务必避免）：

❌ src/main/java/com/mxwis/puait/bus/train/manager/TrainCourseManager.kt:335-356
❌ com.mxwis.puait.bus.train.manager.TrainCourseManager
❌ - src/main/java/.../UserService.java 第 42 行

正反面完整对比：

  +---------------------------------------------------+------------------------------------+
  | ❌ 违规                                           | ✅ 正确                            |
  +---------------------------------------------------+------------------------------------+
  | src/main/java/.../ApiOperationScanner.java:80      | ApiOperationScanner.java:L80       |
  | com.domain.module.bus.auth.scanner.ApiOperation... | ApiOperationScanner                |
  | - src/main/java/.../UserService.java:42-60         | UserService.java:L42-60            |
  | 列表：- src/.../TrainCourseManager.kt:335-356      | TrainCourseManager.kt:L335-356     |
  +---------------------------------------------------+------------------------------------+

当需要在对话中定位源码时，推荐使用以下模板：

查询视频记录：
  - TrainCourseManager#getVideoRecord():L335-356
进度封顶 99% 的逻辑：
  - TrainCourseManager#calcCurProgress():L362-370

📌 规则总结：

• 只用文件名，绝不带目录前缀
• 行号使用 L 前缀（L42、L335-356），避免单独裸数字引起歧义
• 类名只用短名：UserCore 而非 com.xxx.UserCore
• 独占一行的路径引用同样必须遵守缩写规则，无例外

🎯 视觉与排版优化

• 📏 简洁明了 —— 控制单行长度，适配终端宽度（建议 ≤80 字符）
• 🫧 适当留白 —— 合理使用空行，避免信息拥挤
• 🔦 重点突出 —— 关键信息用 *斜体* 强调
• 📎 引用分层 —— 灵活使用 > 语法为辅助信息创建"视觉画框"。遇到提示 (💡)、警告 (⚠️)、核心摘要 (📌) 或旁注补充 (📝) 时，务必使用 > 将其与正文剥离，增强醒目度

🧩 代码与数据展示

• 📝 代码块 —— 多行代码、配置或日志务必用带语言标识的 Markdown 代码块
• 🎯 聚焦核心 —— 示例代码省略无关部分（如导入语句），突出关键逻辑
• ✏️ 差异标记 —— 修改内容用 + / - 标注，便于快速识别变更
• 🔢 行号辅助 —— 必要时添加行号（如调试场景）

📊 结构化数据与图示

侧重信息的可视化组织，用于对比、流程、层级等非代码类内容的清晰呈现。

⚠️ 优先级说明：本 Skill 有意将 ASCII 表格置于列表之前。 终端环境中，等宽字体天然适合对齐表格，多维度对比信息在表格中的可读性远高于列表。 这一优先级与通用 Markdown 文档规范不同，是针对终端场景的刻意设计。

🚫 硬性禁止：Markdown 表格语法 终端环境（如 Codex CLI）无法渲染 Markdown 表格（| xxx | yyy | 语法）。 未渲染的 Markdown 表格在终端中对齐混乱、可读性极差。 在终端对话中，一律使用 +---+ 框线的纯文本 ASCII 表格，禁止使用 |---|---| 的 Markdown 表格语法。

呈现优先级：

1. 📊 纯文本 ASCII 表格 —— 当信息具有多维度对比特性，单元格内容简短精炼时优先使用
   • ✅ 列数不超过 4 列，单元格内容简短（核心原则）
   • ✅ 适用：方案对比、命令参数说明、状态清单、多维度评估
   • ❌ 不适用：单一维度说明、长文本解释、嵌套层级关系

示例：

  +----------+--------+--------+--------+
  | 对比项   | 方案 A | 方案 B | 方案 C |
  +----------+--------+--------+--------+
  | 名称     | 奶茶   | 咖啡   | 果汁   |
  | 口感     | 甜     | 苦香   | 清爽   |
  | 提神效果 | 中     | 高     | 低     |
  | 适合时间 | 下午   | 早上   | 全天   |
  | 推荐指数 | 8/10   | 9/10   | 7/10   |
  +----------+--------+--------+--------+

2. 🌳 纯文本 ASCII 图示 —— 当纯文本难以清晰表达结构/流程/层级关系时使用
   • ✅ 适用：架构图、文件树、状态机、流程图、类图、依赖关系
   • 🔧 常用符号：├──、└──、│、→、┌┐└┘、[节点]、●
   • 📏 保持简洁（一般 ≤20 行，复杂场景 ≤35 行），必须配文字说明

示例：

  🔴 高危险（直接修改代码/执行命令）
  ├── execute_shell_command  ← 任意命令执行，最危险
  ├── create_text_file       ← 可覆盖文件

  🟡 中等危险（新增/修改，但有一定控制）
  ├── insert_after_symbol    ← 新增代码
  └── switch_modes           ← 切换模式可能绕过限制

  🟢 低危险（知识管理，无代码修改）
  ├── write_memory           ← 写入知识
  └── onboarding             ← 项目分析

3. 📋 列表 —— 兜底选择，适用于绝大多数场景

✅ 输出结尾建议

• 📝 简短总结 —— 复杂内容后附简短总结，重申核心要点

❌ Common Mistakes

• 🚫 对话中使用 ## 标题语法 —— 终端对话应使用粗体分组，## 标题视觉层级过重，破坏对话流的扁平感
• 🚫 终端中使用 Markdown 表格 —— 硬性违规。| xxx | yyy | 语法在终端中无法渲染，显示为散乱的管道符文本。必须使用 +---+ 框线的 ASCII 表格
• 🚫 终端中使用超宽表格 —— 内容冗长、含代码或需连贯叙述时，表格会导致灾难性换行
• 🚫 路径包含目录前缀 —— 硬性违规。无论行内还是列表项，必须只用文件名（参见「📍 路径引用规范」）
• 🚫 大段纯文本堆砌 —— 缺乏视觉锚点，读者无法快速定位信息
• 🚫 装饰性 ASCII 图示 —— 图示应服务于理解，不应仅为美观而添加
• 🚫 遗漏 TL;DR —— 长内容开头不加 > 引用块摘要，读者需全文阅读才能抓住重点