副标题：用一份标准稿、两套发布 Skill 和一个统一内容源，减少重复排版与多端内容漂移
很多团队同时维护微信公众号、官方网站和微信小程序。写文章本身只需要一次，真正费时间的往往是后面的重复工作：公众号重新排版，官网再录入一遍，小程序又复制一份；图片要重复上传，标题和摘要分别修改，文章更新后还要逐个平台核对。
复制次数越多，内容越容易不一致。一个段落在公众号里改过，官网没有同步；官网换了封面，小程序仍在使用旧图；表格在电脑上正常，到了手机端却被挤出屏幕。
群智泽强现在采用的方式不是让三个渠道共用一套页面，而是让三个渠道共用一份内容。文章只维护一份标准 Markdown，公众号、官网和小程序各自使用适合自己的渲染和发布方式。
先说结论：不是一个页面发到三个地方
公众号、官网和小程序的技术环境并不相同。
公众号文章主要依赖内联样式，最终进入微信草稿箱；官网由 Django 模板渲染，需要考虑搜索引擎、桌面浏览器和移动浏览器；小程序使用自己的组件体系，富文本能力和网页也不完全一样。
如果强行复用同一份 HTML，短期看似省事，后面很容易出现样式失效、图片地址不兼容和手机端溢出。
我们采用的结构是：
一份标准 Markdown
│
├── 公众号：Wenyan / 小虎排版 → 微信官方 draft/add → 草稿箱
│
└── 官网：内容管理 API → PostgreSQL
│
├── 官网：Django 安全渲染
└── 小程序：公开内容 API → rich-text
共享的是内容，不是页面样式。公众号、官网和小程序分别使用适合自己的渲染方式。
这里有两个关键点。
第一，文章正文、标题、摘要、作者、图片顺序和表格数据只有一个权威来源。
第二，三个渠道共享内容，但不强求共享视觉样式。公众号可以使用适合微信的内联排版，官网保留自己的品牌样式，小程序使用适合原生组件的简洁阅读界面。
第一步：建立一份标准稿
每篇文章先整理成一份结构清楚的 Markdown，至少包含以下内容：
- 标题；
- 副标题或摘要；
- 作者；
- 正文章节；
- 列表和表格；
- 正文图片与图片说明；
- 封面图片；
- 发布时间和内容类型。
标准稿是三个渠道的权威来源。渠道适配只改变外层样式，不改变事实、顺序和表格数据。
标准稿是后续所有渠道的依据。公众号排版时不另写一版，官网发布时也不重新摘录。必要的渠道适配只能改变外层样式，不能擅自删减段落、调整表格数据或打乱图片顺序。
封面同样需要统一管理。优先使用文章里的真实图片；如果文章没有合适图片，再围绕文章标题、主题和真实素材设计封面。不能为了完成发布流程临时放一张无关的抽象插画或通用“AI科技图”。
公众号和官网的封面比例不同，可以从同一组真实素材分别裁切：
| 渠道 | 建议比例 | 用途 |
|---|---|---|
| 微信公众号 | 约 900×383 | 草稿箱和公众号消息封面 |
| 官网 | 1200×630 | 首页、文章列表和详情页 |
| 小程序 | 沿用官网封面地址 | 列表缩略图和详情页头图 |
这样既保留了统一识别，又不需要让一张图片勉强适配所有容器。
第二步：用 WeChat Article Publishing Skill 生成公众号草稿
公众号发布使用 wechat-article-publishing Skill。它负责把标准 Markdown 转成适合公众号的 HTML，上传正文图片和封面，再调用微信官方接口创建草稿。
我们目前默认同时生成两个版本：
- Wenyan：作为简洁、稳定的基准版本；
- 小虎排版：使用相对克制的主题，提供另一种层级和阅读节奏。
两份草稿的正文、图片、作者、摘要和封面保持一致，只改变排版工具和主题。这样比较的是真实排版效果，而不是两篇内容不同的文章。
Wenyan 作为稳定基线，小虎排版作为视觉备选；两份草稿的实质内容保持一致。
发布过程使用微信官方 draft/add 接口。接口返回成功后，还要通过 draft/batchget 回读草稿，检查标题、作者、章节数量、图片数量和正文是否完整。
需要说明的是，写入草稿箱不等于正式发布。草稿接口、手机预览接口和直接发布接口是三套不同权限。当前可靠的工作方式是：
标准稿 → 自动生成两份草稿 → 官方接口回读验证 → 手机端比较 → 人工确认发布
保留最后一次人工确认，可以避免错误标题、异常图片或不合适的排版直接对外发送。
第三步：用 Django Content Management APIs Skill 发布官网
官网发布使用 django-content-management-apis Skill。文章通过本地受保护的内容管理接口写入生产数据库，而不是进入后台手工复制。
观点与动态的管理接口是：
POST /local-api/insights/
PATCH /local-api/insights/<id>/
写入的主要字段包括：
| 字段 | 内容 |
|---|---|
title |
文章标题 |
slug |
稳定的文章访问路径 |
kind |
文章、新闻、活动或回顾 |
summary |
列表页和搜索结果摘要 |
content |
标准 Markdown 正文 |
cover |
官网媒体目录中的封面路径 |
author |
作者或发布组织 |
published_at |
发布时间 |
featured |
是否进入首页推荐 |
status |
草稿、已发布或归档 |
seo_title |
搜索引擎标题 |
seo_description |
搜索引擎摘要 |
官网数据库保存的仍然是 Markdown。页面展示时，服务器把 Markdown 转成 HTML，再通过白名单清洗，移除脚本、事件属性和危险链接。标题、列表、表格、图片、图片说明和行内代码都可以保留。
四列表格在电脑上按表格显示，在手机上则允许表格区域内部横向滑动，不把整个页面撑宽。正文图片使用响应式宽度，避免只适配桌面端。
如果现有网站已经支持文章所需的结构，发布只调用内容 API，不修改网站代码，也不重建容器。只有新文章确实包含网站无法处理的新内容时，才进行最小范围的兼容改造。
官网真实发布效果。页面由 Django 渲染；同一条内容记录同时通过公开接口提供给小程序。
第四步：小程序不再单独维护文章
小程序不需要再复制一份文章数据。官网数据库是官网和小程序共同的内容源。
官网发布文章后，小程序通过公开只读接口获取内容：
GET /api/miniprogram/activities/
GET /api/miniprogram/activities/<slug>/
列表接口返回标题、摘要、类型、发布时间和缩略图；详情接口返回完整正文，以及服务器已经清洗过的 content_html。小程序使用 rich-text 组件显示正文。
因此，官网文章一旦发布，小程序内容也随之更新。以后修改标题、摘要、正文或封面，只需要更新官网中的同一条记录，小程序再次请求接口时就会获得最新内容。
这比在小程序项目里维护静态文章文件更稳妥，也减少了每次更新内容都重新提交小程序代码的需要。
正式上线的小程序仍有基础条件：请求地址必须使用已备案的 HTTPS 域名，并在微信公众平台配置为合法 request 域名。服务器 IP 适合开发验证，不适合作为正式发布地址。
三个渠道如何保持一致
跨渠道同步不能只看“接口返回成功”。我们会对同一篇文章检查以下项目：
| 检查项 | 公众号 | 官网 | 小程序 |
|---|---|---|---|
| 标题、作者、摘要 | 草稿回读 | 页面与 API | 列表与详情 API |
| 章节和段落顺序 | 草稿正文 | 详情页 | rich-text |
| 表格数据 | 手机预览 | 桌面及手机页面 | 真机或开发者工具 |
| 正文图片 | 微信素材地址 | 公共媒体地址 | 图片网络请求 |
| 封面 | 草稿封面 | 首页、列表、详情、相关阅读 | 列表缩略图和详情头图 |
| 安全检查 | 不暴露路径和凭据 | 清除危险 HTML | 使用服务器清洗结果 |
其中最容易被忽略的是封面。官网首页显示正确，不代表文章列表和相关阅读也正确；数据库里有封面路径，也不代表 Nginx 一定能够读取文件。每个实际展示入口都要检查。
这套流程使用了哪些 Skill
wechat-article-publishing
用于公众号 Markdown 排版、正文图片上传、封面上传、草稿创建和官方接口回读。当前默认生成 Wenyan 和小虎排版两个版本。
django-content-management-apis
用于官网文章的创建、更新和生产数据验证，也规定了官网封面目录、移动端验收和小程序内容 API 的使用方式。
humanizer
用于文章完成后的文字检查，去掉生硬的模板句、重复强调和过度宣传表达。它只调整语言，不改变事实、结构、表格和图片顺序。
这些 Skill 分工明确：一个负责公众号发布，一个负责官网与小程序的数据链路，一个负责发布前的语言整理。它们都围绕同一份标准稿工作。
为什么这样设计
这套流程没有追求“一个按钮把同一段 HTML 塞进三个平台”，而是解决三个更实际的问题。
一是减少重复维护。文章内容只保存和修改一次。
二是保留渠道差异。公众号、官网和小程序各自使用适合自己的展示方式，不为了代码复用牺牲阅读体验。
三是让发布结果可以验证。每一步都有回读或公开页面检查，而不是看到命令执行成功就结束。
最终形成的工作流是：
写一份标准稿
→ 检查内容、图片和封面
→ 公众号生成 Wenyan 与小虎两份草稿
→ 官网通过内容 API 发布
→ 小程序自动读取官网内容 API
→ 分别进行回读、页面和手机端验收
结语
一篇文章同时更新到公众号、官网和小程序，重点不是把三个发布按钮连在一起，而是先确定哪一份内容是权威来源，再为每个渠道建立稳定的适配器和验证方法。
当正文、图片、表格和封面都来自同一份标准稿，公众号负责排版和草稿发布，官网负责内容存储与公开展示，小程序负责读取同一内容 API，跨渠道维护就不再依赖反复复制。
这套流程仍然保留人工发布确认，但已经把最容易出错的重复录入、图片处理、格式转换和结果核对交给了 Skill。对日常内容运营来说，这比追求完全无人值守更可靠，也更容易长期维护。
