从一篇 Markdown 到七个平台：我们用 Vibe Coding 做了一次内容发布实验
写完一篇文章后，你通常需要多久才能把它发布到所有内容平台？
对于只发布到一个平台的创作者来说，复制正文、上传封面、检查排版可能只需要十几分钟。但如果目标平台包括博客园、掘金、CSDN、知乎、微信公众号、小红书和抖音，整个过程就会变得复杂起来。
同一篇文章，在不同平台上往往需要不同的标题、摘要、封面比例和内容格式。于是，我们决定用 Vibe Coding 开发一个多平台投稿发布系统，尝试把重复劳动交给程序处理。
一、一次看似简单的发布任务
假设我们已经完成了一篇技术文章，原始文件为：
vibe-coding-guide.md
文章中包含以下内容：
- 一级、二级和三级标题；
- 普通段落和引用；
- 有序列表与无序列表；
- JavaScript 代码块；
- 本地图片；
- 外部链接；
- 表格和分割线。
如果采用传统方式发布，我们需要依次打开七个平台，并重复完成以下操作：
复制标题 → 复制正文 → 调整格式 → 上传图片
→ 填写摘要 → 添加标签 → 设置封面 → 检查预览 → 发布
真正的问题不是某一步特别困难，而是每一步都要重复很多次。
自动化的意义，不是让人完全离开工作流程，而是把人的精力从重复操作转移到内容质量和最终决策上。
二、我们希望系统怎样工作？
我们为系统设计了一个相对清晰的操作流程。
- 用户创建或上传 Markdown 文章；
- 系统解析标题、正文、图片和代码块；
- 用户选择需要发布的平台；
- 系统根据平台规则生成不同版本；
- 用户预览转换结果；
- 系统创建发布任务；
- 用户确认后执行半自动发布；
- 系统保存发布地址和执行状态。
在理想情况下，用户只需要操作一次，系统就可以生成七份适配后的内容。
发布任务示例
{"articleTitle": "用 Vibe Coding 开发多平台投稿系统","platforms": ["cnblogs","juejin","csdn","zhihu","wechat","xiaohongshu","douyin"],"status": "waiting","publishMode": "semi-automatic"
}
这里没有追求完全无人值守的自动发布，而是采用更加稳妥的半自动方式。系统负责准备内容、打开页面和填写表单，用户负责最后检查并确认发布。
三、不同平台不能使用同一种内容格式
多平台发布最大的难点，不是“把文字发送出去”，而是“让内容在每个平台上都能正常阅读”。
| 平台 | 内容特点 | 系统处理方式 |
|---|---|---|
| 博客园 | 适合完整技术文章 | 保留长文结构和代码块 |
| 掘金 | 技术社区属性明显 | 优化标题、标签和代码展示 |
| CSDN | 支持技术长文 | 转换 Markdown 并处理图片 |
| 知乎 | 强调阅读体验 | 调整段落间距和引用格式 |
| 微信公众号 | 主要使用富文本 | 转换为带样式的 HTML |
| 小红书 | 偏向图片和短文案 | 将长文拆分为多张内容卡片 |
| 抖音 | 偏向短视频和图文 | 生成短标题、口播稿和图片文案 |
例如，一段适合技术博客的内容可能是：
async function publishArticle(article, platform) {const adapter = getPlatformAdapter(platform);const content = await adapter.transform(article);return adapter.createPublishTask(content);
}
对于掘金和 CSDN，这段代码可以继续以代码块形式出现；对于小红书，系统则可能将它转换成“核心实现思路”卡片，而不是直接展示完整代码。
这说明平台适配不是简单的格式转换，还包括内容重新组织。
四、Vibe Coding 如何帮助开发？
在开发过程中，我们没有一开始就详细设计所有页面和接口，而是先向 AI 描述一个可以运行的最小版本：
创建一个支持 Markdown 文档管理的平台。用户可以编辑文章、选择发布平台，并查看每个平台的转换预览。
AI 根据描述生成基础项目结构后，我们再逐步补充要求：
这种开发方式并不意味着需求可以一直模糊。相反，每次看到程序运行结果后，我们都需要更加准确地说明问题。
例如，“页面不好看”是一个模糊反馈，而下面的反馈更容易让 AI 执行：
文章编辑区域和预览区域采用左右布局；
左侧宽度为 55%，右侧宽度为 45%；
发布按钮固定在页面右下角；
任务失败时显示错误原因和重新执行按钮。
清晰的描述会直接影响生成结果的质量。
五、第一次测试中发现的问题
在第一次内部测试中，我们很快发现了一些问题。
首先，本地图片路径无法直接发布到其他平台。例如：
这张图片在本地编辑器中能够正常显示，但发布后，其他用户无法访问。因此，系统必须先上传图片，再将原始路径替换为在线地址。
其次，不同平台对表格、代码高亮和 HTML 标签的支持程度不同。一些平台能够正确显示复杂表格，另一些平台则可能出现内容错位。
最后，平台页面随时可能更新。依赖网页元素位置的浏览器自动化脚本，需要具备错误检测和重新配置能力。
因此，我们放弃了“写完脚本就永远不用维护”的想法。一次开发，永久稳定并不现实，更合理的目标是建立一套容易更新的平台适配机制。
六、一次发布，多份结果
发布任务完成后，系统需要给用户一个清晰的结果页面。
| 平台 | 状态 | 结果 |
|---|---|---|
| 博客园 | 成功 | 已生成文章链接 |
| 掘金 | 成功 | 已进入审核流程 |
| CSDN | 成功 | 已发布 |
| 知乎 | 失败 | 图片上传超时 |
| 微信公众号 | 待确认 | 等待用户点击发布 |
| 小红书 | 成功 | 已生成 8 张内容图片 |
| 抖音 | 待确认 | 已生成图文草稿 |
某个平台执行失败时，系统不应该终止整个任务，而应该保存已经成功的平台结果，并允许用户单独重新执行失败任务。
这也是系统设计中的一个重要原则：
平台之间相互独立，单个平台失败不能影响整个发布流程。
七、总结
通过这次项目实践，我们发现 Vibe Coding 最适合解决“目标明确、可以持续验证”的开发任务。AI 能够快速生成页面、接口和基础逻辑，但系统能否真正使用，仍然取决于开发者是否理解业务流程，并认真检查生成结果。
多平台投稿发布系统最终想解决的，不只是复制粘贴问题，而是内容从创作到分发的完整流程：
创作 → 管理 → 转换 → 预览 → 发布 → 追踪 → 优化
当文章、图片、封面、平台格式和发布记录都能在一个系统中管理时，创作者就可以把更多时间放在真正重要的事情上——持续产出有价值的内容。
相关资料：CommonMark Markdown 规范
第二轮测试说明： 本文用于测试多平台投稿发布系统对标题、列表、任务清单、表格、引用、删除线、代码块、链接和分割线等 Markdown 内容的处理能力。