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