将 Markdown 格式的回复转换为适合 Telegram 的富文本，避免渲染错误。适用于用户偏好 Markdown 但目标平台为 Telegram 的场景。
电传马克当量适配器
功能概述
电传马克当量适配器是一项面向实际任务的技能，主要用于保持马克当量的结构和可读性, 但以格式的电传输出效果确实很好。它将相关步骤、工具调用和结果整理方式集中到统一流程中，帮助使用者更快完成目标并减少重复操作。
核心要点
- 使用时应结合输入条件选择合适的执行方式，核对必要参数、依赖环境与输出内容，并按原始要求处理异常情况。
- 该技能适合需要稳定复用相关能力的场景，可作为自动化工作流的一部分，也便于后续检查、调整和扩展。
- 从功能定位来看，该技能强调把分散的操作要求整理成清晰、可复用的处理流程，使用户能够围绕既定目标快速准备输入、选择执行方式并获得结构化结果。
使用与执行
实际使用前应先确认任务范围、数据来源、运行环境、必要权限和关键参数，再依据技能说明逐步执行；若输入条件不完整，应先补齐信息或采用保守配置，避免因错误假设导致结果偏离需求。
结果检查与注意事项
执行过程中需要关注工具调用是否成功、接口或依赖是否可用、输出格式是否符合预期，并对异常提示、缺失字段和边界情况进行处理；涉及批量任务时，还应保存进度，避免中断后重复操作。
Telegram Markdown 适配器
保留 Markdown 的结构与可读性，但输出 Telegram 实际能良好渲染的格式。
中文摘要 / 中文使用说明
该技能的目标并非保留原始 Markdown 语法，而是保留 Markdown 的结构感、层次感、可读性，再将最终输出适配为 Telegram 真正适合阅读和渲染的形式。
适用于以下场景：
- 用户偏好 Markdown 风格回复，但当前渠道为 Telegram
- 回复中包含标题、表格、任务列表、嵌套列表、代码块等 Markdown 元素
- 希望消息看起来清晰、整齐、有结构，但避免大量未渲染的原始 Markdown 符号
默认策略：
- 优先按 Markdown 结构组织内容
- 再根据 Telegram 场景自动选择更合适的最终表现形式
- 表格类内容优先在
伪表格 / 卡片式 / Emoji 分栏式之间自动判断 - 若不确定，默认采用可读性最稳定的卡片式
核心规则（Core Rule）
当目标平台为 Telegram 时，切勿仅因原始 Markdown 在纯文本中看起来美观就直接输出原始 Markdown。应在保留原始结构与强调语义的前提下，将其重写为 Telegram 安全的格式。
优先级顺序如下：
- Telegram 中的可读性
- 结构清晰度
- 视觉精致度
- 对原始 Markdown 语法的忠实度
工作流（Workflow）
0. 默认输出姿态
除非用户明确要求纯文本，否则先以类 Markdown 结构起草回复，再适配为 Telegram 安全的渲染形式。
默认写作风格：
- 发送最终 Telegram 文本时，使用加粗的章节标题替代原始 Markdown 标题（如
#） - 保留 Markdown 中的列表、空行与分节逻辑
- 保留命令、路径、环境变量、标识符等的行内代码格式
- 优先保障视觉结构的可读性，而非字面意义上的 Markdown 语法忠实度
1. 识别在 Telegram 中会失效或降级的 Markdown 特性
需警惕以下问题模式：
- ATX 标题，例如
# Heading - Markdown 表格
- 任务列表，例如
- [ ] - 嵌套层级过深的项目符号（超出 Telegram 舒适渲染范围）
- 过长或过于频繁的围栏式代码块
- 行内 HTML
- 脚注
- 过度堆叠的引用块（
>）
若原始内容含上述元素，应进行适配，而非字面保留。
2. 转换为 Telegram 安全的结构
默认采用以下转换方式：
# Heading→ 单独一行的**Heading**，可酌情添加 Emoji 以提升扫读效率## Section→**Section**- 水平分割线 →
─── - Markdown 表格 → 项目符号列表或紧凑的“字段/值”行式表达
- 任务列表 →
- [ ]改为- 待办：...或- ☐ ... - 已勾选项 →
- ✅ ... - 引用块 → 使用简短引导句，避免多层
>堆叠 - 长围栏式代码块 → 优先概括；仅在确有必要时保留原始代码
- 多列对比 → 拆分为重复的独立区块，而非表格
- 链接 → 当复制粘贴重要时，保持原始 URL 可见；若 Telegram 渲染效果不确定，则避免使用 Markdown 链接语法
若运行时支持 Telegram HTML 模式或富文本格式，应优先选用广泛支持、低风险的子集。切勿依赖脆弱的格式技巧。
3. 保持 Telegram 输出紧凑
Telegram 更适合阅读短段落。
默认风格：
- 段落简短
- 用项目符号替代密集叙述
- 每个项目符号仅表达一个观点
- 节与节之间留出空行
- 避免巨型单体消息
若回复较长，应自然拆分为 2–3 段。
4. 保意义，不保语法
请勿出现如下表述：
- “Telegram 不支持该 Markdown 语法”
- “以下是 Telegram 兼容的重写版本”
除非用户主动询问转换机制本身，否则直接输出适配后的结果即可。
5. 消息拆分与降级策略
当回复较长时，应自然拆分为多个 Telegram 消息，而非强行塞入单个巨型消息块。
推荐拆分顺序：
- 先发标题或核心答案
- 再发细节说明
- 可选：最后附上代码/附录
若某部分内容在 Telegram 中渲染效果不佳：
- 用重复的条目区块替代表格
- 用 2–3 个加粗节标题替代复杂层级结构
- 将低价值细节压缩为简短摘要
- 仅当语义保真至关重要时，才将原始内容放入紧凑代码块中
6. Telegram 专属回复惯例
面向 Telegram 的最终输出应遵循：
- 优先使用加粗节标题，而非原始 Markdown 标题标记
- 保持段落简短
- 用空行分隔不同节
- 当扫读效率关键时，优先使用项目符号而非段落叙述
- 完全避免 Markdown 表格
- 避免不必要的转义字符干扰
- 当存在多个链接时，每个链接应独占一行或作为独立项目符号，便于点击
7. HTML 模式使用指南
OpenClaw 的 Telegram message-tool 发送路径 支持 HTML 解析模式，并在解析失败时自动回退至纯文本。但普通助手回复渲染路径未必始终保留 HTML 解析模式。因此，HTML 应谨慎选用。
建议在以下情况优先使用 Telegram HTML：
- 回复将通过
message工具发送 - 需要明确加粗节标题
- 行内代码、路径、环境变量或命令的准确呈现至关重要
- 链接需干净渲染，避免 MarkdownV2 转义带来的麻烦
- 消息属于结构化通知、报告、告警或摘要
切勿假设原始 HTML 在普通直接助手回复中总能正确渲染。对于标准对话式回复，除非确认运行时路径支持 HTML 解析模式，否则仍应优先采用 Telegram 安全的结构化纯文本。
推荐使用的安全标签子集：
规则：
- 保持 HTML 简洁、扁平
- 当
<、>、&作为纯文本出现时，必须转义 - 不依赖生僻标签或深度嵌套
- 避免在同一渲染输出中混用 Markdown 语法与 HTML
- 若内容高度动态或标签安全性存疑，应回退至 Telegram 安全的结构化纯文本
- 对于常规助手聊天回复，结构化纯 Telegram 文本仍是安全默认选项
仅当发送路径兼容时，才将 HTML 作为 Telegram 的首选富文本模式，尤其适用于经由 message 工具的发送场景。
格式选择启发式规则（Format Selection Heuristics）
应依据内容形态而非个人习惯选择呈现风格。
风格 1：等宽伪表格
当同时满足以下多数条件时使用：
- 内容具有强对比性
- 行数较少
- 每个单元格内容简短
- 对齐精度比对话语气更重要
- 受众主要阅读配置/状态/参数类数据
适用场景：
- 配置快照
- 模型参数对比
- 简短状态矩阵
- 版本 / 状态 / 数值网格
应避免使用的情况：
- 某一列包含句子长度的解释性文字
- 行数过多导致区块过高、过重
- 中文字符宽度使对齐不可靠
风格 2：卡片式区块
当满足以下任一条件时使用：
- 一个或多个字段为中等或较长文本
- 可读性比视觉对齐更重要
- 输出用于解释、汇报或辅助决策
- 移动端可读性为首要目标
此为默认降级方案。
适用场景：
- 日常报告
- 问题列表
- 带解释的选项对比
- 用户需实际阅读（而不仅是快速扫描）的任何内容
风格 4：Emoji 分栏式
当全部或大部分满足以下条件时使用：
- 内容简短、易于扫读
- 需体现 Telegram 原生风格
- 状态/优先级/健康度提示至关重要
- 输出更接近仪表盘、快速摘要或进度面板
适用场景：
- 快速状态更新
- 轻量级摘要
- 群聊友好型报告
- 运维快照
默认选择顺序
- 若需严格对比且字段简短 → 风格 1
- 若含解释性文字或文本为中/长 → 风格 2
- 若内容简短、状态密集、强调扫读 → 风格 4
- 若不确定 → 风格 2
富文本模式选择
当回复面向 Telegram 且富文本有助于表达时，按以下优先级选择：
- HTML 模式：适用于经
message工具发送、需加粗标题、行内代码、链接及结构化报告的场景 - 结构化纯 Telegram 文本：当解析模式兼容性不确定时，用于普通助手回复
- 除非有特定理由，否则避免直接使用原始 MarkdownV2
实践中：
- 经
message工具发送的报告 / 告警 / 仪表盘 → 常用 HTML 或风格 4 - 普通聊天回复中的解释性区块 → 风格 2
- 技术性简短对比 → 风格 1，若经兼容路径启用 HTML 模式，则通常置于
中
推荐的格式化模式（Preferred Formatting Patterns）
模式 A：分节式解释
不采用原始 Markdown：
# Today ## What changed - Item A - Item B
应输出为：
**Today** **What changed** - Item A - Item B
模式 B：用区块替代表格
不采用：
| Item | Status | Note | |---|---|---| | A | Done | OK | | B | Blocked | Waiting |
应输出为：
**Item A** - Status: Done - Note: OK **Item B** - Status: Blocked - Note: Waiting
模式 C：报告风格的 Telegram 输出
适用于发送更新、摘要或运维报告时。
📊 标题 ─── **一、分类** - 事项 1 - 事项 2 ─── **二、分类** - 事项 3 - 事项 4 ─── 📌 下一步 - 动作 1 - 动作 2
何时保留代码格式
以下内容应保留行内代码格式：
- 命令
- 路径
- ID
- 简短配置键
仅在满足以下任一条件时保留围栏式代码块：
- 代码本身即交付物
- 换行具有语义重要性
- 用户明确要求原始代码
其余情况，应概括说明，并仅包含关键代码片段。
反模式（Anti-Patterns）
除非用户明确要求原始 Markdown，否则 Telegram 回复中应避免以下做法：
- Markdown 表格
- 巨型标题层级
- 深度嵌套列表
- 重复出现的围栏式代码块
- Telegram 无法有意义渲染的装饰性语法
- 当更简洁的 Telegram 渲染方式显而易见时，仍照搬原始 Markdown
快速决策规则（Quick Decision Rule）
若内容主体为：
- 状态 / 摘要 / 计划 / 对比 → 根据前述启发式规则，在风格 1 / 2 / 4 中选择
- 代码 / 配置 / 命令输出 → 保留最小必要代码格式
- 混合型 → 先以 Telegram 友好方式分节说明，再仅附必要代码片段
当出现类表格数据时，不应盲目默认。请按如下方式决策：
- 简短、固定、技术性强的行 → 风格 1
- 解释性内容占比高的行 → 风格 2
- 简短状态行，强调扫读效率 → 风格 4
- 不确定 → 风格 2
参考文档（Reference）
如需具体转换规则与示例（涵盖标题、表格、检查清单、代码及长回复），请查阅 references/telegram-format-rules.md。
相关专题
Java应用运行缓慢，如何调整JVM参数？本专题介绍OpenJDK JVM性能调优的基本流程，涵盖性能指标确认、运行数据采集、内存配置和垃圾回收分析，帮助你先定位瓶颈，再通过对照测试验证效果，避免直接套用参数而影响应用稳定性。
2026.10.16
0
10
怎样用OpenJDK搭建开发环境？本专题介绍版本选择、下载安装、环境变量配置和编译运行验证，帮助你理清JDK的作用及基本配置流程，并通过简单程序检查环境是否可用，为后续项目开发做好准备。
2026.10.16
0
10
Java项目开发完成后，怎样部署到目标环境并正常运行？本专题介绍OpenJDK应用部署流程，涵盖运行环境准备、版本兼容检查、应用打包、启动参数配置和日志查看，帮助你理清部署前后的操作顺序，减少环境差异造成的运行问题。
2026.10.16
0
10
本专题围绕Revel框架视图层开发，介绍模板语法、变量输出、布局复用、表单提交、参数绑定与验证规则，帮助开发者完成安全规范的页面交互。
2026.10.16
0
15
本专题聚焦Revel框架MVC核心机制，讲解路由定义、控制器Action、参数绑定、请求响应和反向路由，并结合常见场景梳理接口请求处理流程。
2026.10.16
0
15
本专题从Revel框架环境搭建讲起，系统介绍命令行工具安装、项目创建、目录结构、配置文件及热代码重载，帮助开发者快速完成首个Go Web应用。
2026.10.16
0
15
Linux新手命令专题汇集终端基础、文件目录操作、文本查看、软件安装和权限管理等入门文章，帮助按实际任务练习常用命令并建立命令行操作习惯。
2026.10.15
0
20
MySQL忘记密码专题汇集不同版本与系统下的root密码重置方法，覆盖MySQL 5.7、8.0、Mac、Linux及本地集成环境，并提示恢复权限与重新登录的检查步骤。
2026.10.15
0
18
Vue.js中ref和reactive的区别专题汇集两种响应式API的定义、访问方式、对象解构、侦听与性能取舍等文章，帮助结合实际状态类型选择合适写法。
2026.10.15
0
20
热门下载
相关下载
精品课程
共13课时 | 3.7万人学习
共30课时 | 4.4万人学习
共10课时 | 1.5万人学习
