从手动到半自动：CSDN 技术博客发布效率提升实践
目录
- 背景：为什么需要自动化发文
- 方案选型与踩坑
- 半自动发布流程设计
- 关键实现细节
- 经验总结与下一步
一、背景：为什么需要自动化发文
对于做技术产品运营的同学来说，CSDN 是一个很重要的内容阵地。但每天手动登录、排版、填标签、点发布，重复性很高。一旦忙起来，发文节奏就容易断。
我们的目标是：每天能稳定发布 1-2 篇技术文章，同时尽量减少人工操作。最理想的状态是「全自动」，但受限于平台安全策略，实际落地时往往需要经历从「手动」到「半自动」的过渡。
二、方案选型与踩坑
2.1 最早尝试：CDP Proxy
一开始想复用已经打开的 Chrome 浏览器，通过 Chrome DevTools Protocol（CDP）远程控制页面。思路没问题，但很快遇到问题：
- 浏览器启动时必须加
--remote-allow-origins=*，否则 WebSocket 握手会被拒绝； - 不同页面框架（新版编辑器 vs 旧版编辑器）的 DOM 结构差异大，脚本很容易失效；
- CDP 连接不稳定，偶发断开。
结论：CDP Proxy 方案维护成本高，不太适合长期跑定时任务。
2.2 切换到 Playwright
后来改成 Playwright for Python 直接启动浏览器，优势很明显：
- 不需要依赖外部浏览器实例；
- 内置的
storage_state可以保存 Cookie、localStorage、sessionStorage； - 页面操作 API 更稳定，调试也方便。
2.3 新版编辑器的签名问题
CSDN 新版编辑器editor.csdn.net/md/的发布接口有 API Gateway 签名（X-Ca-Key），直接调用会返回 401。绕开的办法是切换到旧版编辑器mp.csdn.net/mp_blog/creation/editor，旧版使用 CKEditor，可以通过 JS API 直接设置标题和正文。
2.4 微信扫码是绕不开的门槛
即便登录态已经保存，CSDN 对发布操作仍有二次验证：需要绑定的微信扫码确认。这意味着当前账号无法做到完全无人值守，必须接受「半自动」——脚本完成前置流程，人工扫码确认。
三、半自动发布流程设计
整个流程拆成六个步骤：
- 内容准备：从 Markdown 文件读取文章，转换为 HTML；
- 打开编辑器：用保存的
storage_state进入旧版编辑器； - 移除干扰弹窗：CSDN 偶尔会弹出安全提示，用 JS 移除；
- 自动填充：标题、正文、摘要；
- 点击发布：触发 CSDN 的二次验证；
- 等待扫码：检测到微信扫码弹窗时，通过钉钉通知用户；用户扫码后，脚本多维度检测发布成功。
四、关键实现细节
4.1 成功检测不能只看 URL
早期实现只判断 URL 是否包含/article/details/，但旧版编辑器发布成功后不一定立即跳转。后来改成多维度检测：
- URL 跳转到文章详情页；
- URL 包含
article_id=参数； - 页面出现「发布成功/提交成功/审核中」等提示；
- 页面出现文章详情链接；
- URL 已离开编辑器且发生变化。
4.2 弹窗检测要精确
不能简单匹配「微信」两个字，否则会把页面上的「微信登录」「分享到微信」等正常元素误判。正确做法是限定为fixed/absolute定位的可见弹窗，并且包含扫码文案或二维码图片。
4.3 通知闭环
- 需要扫码时：钉钉提醒；
- 发布成功时：发送文章标题和链接；
- 失败或超时时：发送原因，浏览器保持打开供人工处理。
五、经验总结与下一步
自动化发文不是一蹴而就的，建议按这个顺序推进：
- 先跑通半自动流程，验证通知和成功检测；
- 再测试同一登录态下连续发布是否需要每次都扫码；
- 然后建立内容缓存池，预生成多篇文章；
- 最后设置定时调度，实现每日稳定输出。
如果平台安全策略不允许完全自动化，半自动已经是投入产出比很高的状态。把重复劳动交给脚本，把决策和确认留给人，这才是合理的分工。
 agent和组件)
