WorkBuddy：一个面向内容创作的桌面自动化助手实践
最近在琢磨一个小工具，暂时给它起了个名字叫
WorkBuddy
这篇文章主要梳理一下WorkBuddy的设计思路、核心模块，以及几个让人印象深刻的踩坑点。整体偏向工程实践，不会铺开讲太多概念。
为什么要做 WorkBuddy
内容发布这件事，乍一看确实不复杂：写文章、打开平台、复制标题、粘贴正文、加标签、存草稿。
但真正上手做起来，问题比想象的要多：
- 各家平台的编辑器长得不一样，操作路径也不统一
- Markdown、代码块、封面、标签这些细节，很容易漏掉
- 浏览器的登录状态、页面弹窗、输入框位置，经常说变就变
- 如果完全依赖接口或者无头浏览器，稳定性和合规性都不太好控制
所以WorkBuddy的定位就很明确了——它就是一个桌面工作助手。帮我把内容准备好，打开真实浏览器，定位页面元素，填写草稿，但最终发布这一步，还是交给人工来做最终确认。
技术选型
WorkBuddy目前主要基于Python来实现，核心依赖包括：
pyautogui：截图、鼠标控制、基础桌面操作pynput：键盘输入和快捷键OpenCV：模板匹配和按钮定位PaddleOCR：识别页面文字和输入区域PyYAML：配置管理logging：调试日志和异常追踪
整体没有使用Selenium，也没有上Playwright。原因其实很简单：这个工具更关注真实桌面环境下的辅助操作，而不是浏览器自动化测试那套打法。
核心流程
目前WorkBuddy的一次草稿流程大致是这样：
读取 Markdown
-> 平台风格改写
-> 选择平台 Adapter
-> 启动真实 Chrome
-> 打开创作页
-> OCR 识别输入框
-> 鼠标定位并点击
-> 键盘输入标题和正文
-> 保存草稿
-> 人工检查后再决定是否发布
整个流程里最关键的环节，就是“人工确认”。工具只负责把重复劳动做掉，不替代人来做最终发布决策。
Adapter 设计
不同平台的编辑器差异很大，所以WorkBuddy使用了Adapter架构来应对。
举个例子，CSDN的适配器主要负责：
- 打开CSDN创作中心
- 检测是否登录
- 进入Markdown编辑器
- 定位标题输入框
- 填写标题
- 填写正文
- 添加标签
- 保存草稿
这样一来，后续要扩展知乎、掘金、InfoQ、腾讯云开发者社区这些平台时，不需要改动主流程，只需要新增对应平台的Adapter就行。
一个简化的调用示例
from publish_assistant.adapters.csdn_adapter import CsdnPublishAdapter, CsdnDraft
from publish_assistant.utils.config import load_settings
from publish_assistant.utils.logging import setup_logging
settings = load_settings("config/settings.yaml")
setup_logging(settings)
adapter = CsdnPublishAdapter.from_settings(settings)
draft = CsdnDraft(
title="WorkBuddy：一个面向内容创作的桌面自动化助手实践",
body_markdown="这里是 Markdown 正文",
tags=("Python", "桌面自动化", "AI工具"),
)
adapter.prepare_draft(draft, sa ve=True)
踩坑点
先聊聊OCR这个坑。OCR的识别结果真的很不稳定，页面缩放、字体渲染、窗口大小，随便一个因素都会影响识别质量。后来把调试流程固定下来：固定Chrome窗口大小、固定浏览器缩放为100%、每一步都截图、OCR结果全部写入debug日志。
第二个坑是输入中文和代码块。如果完全逐字输入，速度慢不说，代码缩进还容易出问题。现在的策略是：标题这种短内容用逐字输入，正文这种长Markdown用更稳定的分块方式写入。
第三个坑在于不同平台的“保存草稿”逻辑完全不同。有的平台会自动保存，有的需要点按钮，有的用快捷键也能触发保存。所以在Adapter里必须保留兜底逻辑，不能只依赖一种路径。
后续计划
WorkBuddy后面会继续推进三件事：
- 提升CSDN、掘金等平台编辑器定位的稳定性
- 增加更清晰的失败截图和错误报告
- 优化Markdown到平台编辑器的转换效果
目前它还不是一个“开箱即用”的商业产品，更像是一个把日常工作流工程化之后的实践版本。如果你也在研究桌面自动化、内容工作流或者AI辅助运营，欢迎一起交流。当然，这套工具本身也还在持续迭代中。
