很多技术文章是先在 Markdown 里写完，再复制到微信公众号后台。
问题通常不是 Markdown 写错了，而是公众号后台不是 Markdown 编辑器。
你从 Typora、Obsidian、VS Code、Notion、飞书里复制出来的内容，本质都是不同的富文本结构。公众号后台接收以后，最容易出问题的地方通常是：
- 标题层级；
- 引用块；
- 列表缩进；
- 代码块边界；
- 表格宽度；
- 图片位置；
- 移动端预览。
从技术上看，这一步不是简单的"Markdown 转 HTML"。
Markdown 编辑器会先把文本渲染成 HTML；浏览器复制时带走的又是富文本片段；公众号后台再对这段 HTML 做二次清洗、样式过滤和移动端适配。代码块依赖的 pre/code、表格依赖的 table/tr/td、引用块依赖的结构和 CSS，都可能在这个过程中被改写。最后看到的结果就会变成：代码块边界变弱、表格宽度失控、列表缩进不一致。
我现在比较推荐把"写作"和"发布前整理"拆开：
- 写作仍然用自己熟悉的 Markdown 工具。
- 发布前单独检查标题、引用、列表、代码块、表格。
- 整理成公众号后台更容易接收的发布前草稿结构。
- 再复制到公众号后台。
- 手机预览确认。
这个流程里，Markdown Nice 适合做 Markdown 样式化；135、秀米适合复杂素材和运营排版；如果你只是想把已有 Markdown / AI 初稿 / 纯文本稿先整理成更适合粘贴到公众号后台的发布前稿件，可以试试妥帖。
妥帖：
tuotie.kindmorn.com/what-is-tuo...
代码块场景：
tuotie.kindmorn.com/use-cases/w...
它的边界要注意：
- 不自动发布公众号；
- 不自动上传图片；
- 不替代公众号后台；
- 最终仍需要公众号后台手机预览。
所以它只是发布前整理器，不是完整公众号编辑器。
我发布技术文前会重点看这几个点：
- 代码块有没有被拆成普通段落。
- 表格在手机端是否太宽。
- 有序列表是否被复制成普通文本。
- 引用块是否还能和正文区分。
- 链接是否是公开可访问页面。
这几个点过了，再去公众号后台做最后预览，返工会少很多。