Wechatsync CSDN 草稿同步源码分析：为什么当前只能保存草稿，不能自动公开发布
摘要：本文基于本地 Wechatsync 源码，分析 CSDN 文章同步链路从 CLI、MCP、Extension 到 CSDN adapter 的完整调用路径。结论是：当前源码实现对 CSDN 的能力边界是“保存到草稿箱”，不是“自动公开发布”。如果要做公开发布，需要额外确认 CSDN 公开发布接口、请求字段、签名和风控逻辑。
1. 问题背景
在做 CSDN 自动化发布链路时，一个很关键的问题是：Wechatsync 到底能不能直接把文章公开发布？
这个问题不能只看工具名称里的publish或sync。很多内容平台的自动化工具内部都会把“发布”抽象成一个publish()方法，但实际落到平台 API 时，可能只是创建或保存草稿。
本文的分析对象是本地源码：
/Users/jerry/tmpProject/Wechatsync重点看四个位置：
| 模块 | 源码文件 | 关注点 |
|---|---|---|
| CLI | packages/cli/src/index.ts | 命令参数是否提供公开发布开关 |
| MCP Server | packages/mcp-server/src/server.ts | MCP 工具语义是否是草稿 |
| Extension adapter 调度 | packages/extension/src/adapters/index.ts | 是否默认按草稿执行 |
| CSDN adapter | packages/core/src/adapters/platforms/csdn.ts | 实际调用哪个 CSDN API，请求体是什么 |
验证状态：来自源码分析，未执行真实 CSDN 网络请求。
2. 先看 CLI：只有 sync，没有公开发布参数
CLI 入口里，CSDN 同步最终走的是sync <file>命令。这个命令暴露的核心参数是：
-p, --platforms <platforms> -t, --title <title> --cover <url> --dry-run从源码可以看出，它没有提供类似下面这些公开发布开关：
--publish --public --final --releaseCLI 在非 dry-run 模式下，会通过 bridge 请求 Extension：
bridge.request('syncArticle',{platforms,article:{title,markdown:processedMarkdown,content:processedHtml,cover,},})这里传过去的是文章内容和目标平台，没有传“公开发布”状态。
这个信号很重要：如果 CLI 层没有发布状态参数，后面的 adapter 即使支持公开发布，也没有稳定入口让用户显式选择。
3. 再看 MCP：工具描述就是“保存为草稿”
MCP Server 里定义了sync_article工具。这个工具的描述是：
同步文章到指定平台（保存为草稿）它接收的字段包括：
platforms title content markdown cover同样没有公开发布相关参数。
调用时，它也只是把文章对象转发给 Extension bridge：
this.bridge.request('syncArticle',{platforms,article:{title,content,markdown,cover,},})所以从 MCP 侧看，当前工具语义已经明确偏向“草稿同步”，不是“公开发布”。
4. Extension 调度层：默认传draftOnly: true
Extension 的syncToPlatform()是平台 adapter 的统一调度入口。
关键逻辑是：
adapter.publish(platformArticle,{draftOnly:options?.draftOnly??true,onImageProgress:...})也就是说，在没有额外传入draftOnly的情况下，默认就是true。
而批量同步的syncToMultiplePlatforms()调用syncToPlatform()时，传入的 options 是undefined：
constresult=awaitsyncToPlatform(platformId,article,undefined,wrappedImageProgress)因此默认行为可以明确理解为：按草稿同步。
这里还要注意一个细节：即使调度层传了draftOnly: false，也不代表 CSDN 就会公开发布。最终是否公开发布，要看 CSDN adapter 有没有把这个参数转成 CSDN 平台认可的发布接口和发布字段。
5. CSDN adapter：实际调用的是saveArticle
CSDN adapter 的核心方法是publish(article, options)。
它做了几件事：
- 检查 CSDN 登录态。
- 处理 Markdown 图片。
- 准备 HTML 内容。
- 生成 CSDN API 签名。
- 调用 CSDN 保存文章接口。
关键接口路径是：
/blog-console-api/v3/mdeditor/saveArticle请求地址是：
https://bizapi.csdn.net/blog-console-api/v3/mdeditor/saveArticle请求体里最关键的字段是：
{title:article.title,markdowncontent:markdown,content:htmlContent,readType:'public',level:0,tags:'',status:2,// 草稿categories:'',type:'original',original_link:'',authorized_status:false,not_auto_saved:'1',source:'pc_mdeditor',cover_images:[],cover_type:1,is_new:1,vote_id:0,resource_id:'',pubStatus:'draft',creator_activity_id:'',}这里有两个判断点：
status: 2 pubStatus: 'draft'源码注释也把status: 2标成了“草稿”。
所以从 CSDN adapter 的真实请求体看，当前实现不是公开发布，而是保存草稿。
6. 返回链接也是编辑器草稿地址
保存成功后，adapter 取 CSDN 返回的文章 ID：
constpostId=res.data.id然后生成链接：
constdraftUrl=`https://editor.csdn.net/md?articleId=${postId}`这个 URL 是 CSDN Markdown 编辑器地址，不是公开文章访问地址。
公开文章通常应该是博客正文页，而不是编辑器页。因此返回链接也进一步说明：当前同步结果是草稿箱中的编辑态文章。
7.draftOnly只是结果标记，不会改变 CSDN 请求体
CSDN adapter 最后返回结果：
returnthis.createResult(true,{postId:postId,postUrl:draftUrl,draftOnly:options?.draftOnly??true,})这段代码容易误解。
draftOnly在这里只是返回结果里的标记。它没有参与请求体构造，也没有改变status或pubStatus。
也就是说，如果外层强行传入：
{draftOnly:false}当前 CSDN adapter 仍然会调用saveArticle，仍然会传：
status: 2 pubStatus: draft最多只是返回结果里的draftOnly标记可能变成 false，但平台侧行为不会因此变成公开发布。
这一点在工程上很关键：不能把返回标记当成平台发布状态。
8. 当前调用链路总结
完整链路可以画成这样：
wechatsync sync article.md -p csdn -> CLI 解析 Markdown/HTML -> bridge.request('syncArticle') -> MCP / Extension bridge 转发文章 -> syncToMultiplePlatforms() -> syncToPlatform() -> CSDNAdapter.publish() -> POST /blog-console-api/v3/mdeditor/saveArticle -> status: 2, pubStatus: draft -> 返回 editor.csdn.net/md?articleId=xxx从这条链路看，当前 Wechatsync 对 CSDN 的能力边界可以总结为：
| 能力 | 当前源码是否支持 | 依据 |
|---|---|---|
| 检查 CSDN 登录态 | 支持 | checkAuth()调用 CSDN base info 接口 |
| 上传/处理图片 | 支持 | adapter 有图片上传和替换逻辑 |
| 保存 Markdown 正文 | 支持 | 调用saveArticle |
| 保存为 CSDN 草稿 | 支持 | status: 2、pubStatus: draft |
| 返回草稿编辑器链接 | 支持 | editor.csdn.net/md?articleId=xxx |
| 自动公开发布 | 当前未看到支持 | CLI/MCP 无公开发布参数，adapter 请求体固定草稿字段 |
9. 如果要实现公开发布，需要补什么
不能简单把：
pubStatus: draft猜成：
pubStatus: publish也不能只把：
status: 2改成另一个数字。
原因是 CSDN 的公开发布可能涉及：
- 独立的发布接口；
- 分类、标签、封面、原创声明、AI 内容标识等必填字段；
- 平台审核状态；
- 验证码、实名、安全验证或风控；
- 签名路径变化；
- 成功响应到底表示公开可见，还是进入审核队列。
更稳的实现路径应该是：
10. 对项目封装的落地建议
基于当前源码，项目自己的 CSDN 发布封装应该保持三个原则。
10.1 默认只表述为“同步到草稿箱”
日志、终端输出和交付说明都应该写：
已同步到 CSDN 草稿箱不要写：
已发布到 CSDN因为这会误导使用者，以为文章已经公开可见。
10.2 payload 记录期望字段，日志不要误报自动设置
Wechatsync CLI 当前主要传标题和正文。分类、标签、封面、原创声明、AI 内容标识等字段，即使写进项目 payload，也只能作为草稿核对项。
比较稳的日志表达是：
自动传入：title, body 人工核对：category, tags, original, ai_label, cover10.3 公开发布必须作为实验版能力单独实现
公开发布不是草稿同步的自然延伸。它应该有独立开关、独立日志和独立失败诊断。
建议命令形态类似：
python3 10_csdn_publish/run_csdn_publish.py--filearticle.md--publish但这个参数只有在抓包验证完成后才能真正启用。
11. 总结
从当前源码看，Wechatsync 的 CSDN 链路已经能完成文章草稿同步，但还不能称为自动公开发布。
核心证据有三个：
- CLI 和 MCP 没有公开发布参数；
- Extension 调度默认按
draftOnly: true执行； - CSDN adapter 调用
saveArticle，并传入status: 2、pubStatus: 'draft'。
所以更稳的工程结论是：当前项目可以把 Wechatsync 用作 CSDN 草稿箱同步通道；如果要做公开发布，需要基于真实 CSDN 发布请求单独实现实验版。
如果你关注 Java 后端、Spring Boot 升级、MCP/Agent 落地和线上问题排查，可以关注我的 CSDN 专栏。