#WorkBuddy# 实战心得：一次人机协作发文的全过程与踩坑记录

事情的起因

最近我在试用 WorkBuddy（腾讯出品的 AI 助手），想测试一下它执行完整任务的能力。正好需要在腾讯云开发者社区发一篇文章，就试着把这件事交给它，我在旁边观察并记录了全过程。这篇文章是一次真实的使用记录和踩坑复盘。

任务是怎么拆的

我给它的指令只有一句话："去腾讯云开发者社区，发表文章。"

它把任务拆成了几步：

1. 确认目标站点（cloud.tencent.com/developer）；
2. 启动浏览器打开登录页；
3. 扫码这一步需要我本人完成；
4. 按我选定的方向撰写正文；
5. 进编辑器填标题、正文、标签、来源，提交发布。

我实际参与的部分：扫码登录、在它给出的几个主题方向里挑了一个、中途两次催促进度。其余的网页操作、正文撰写、格式处理由它完成。所以这不是"全自动"，更准确的说法是：人管授权和决策，AI 管执行。

第一道坎：浏览器自动化

WorkBuddy 先尝试用它自带的浏览器内核，启动失败了。它自己换了几种方式（加 --no-sandbox 参数、清理残留进程、重启守护进程）都无效，最后改用我电脑上已安装的 Microsoft Edge，以远程调试模式启动：

msedge.exe --remote-debugging-port=9222 https://cloud.tencent.com/login

这样浏览器窗口对我可见，我能看到它在页面上的每一步操作，扫码登录也顺理成章。这里的心得：涉及登录授权的自动化任务，尽量让 AI 用你能看见的浏览器——验证码、扫码这些环节本来就需要人，窗口可见也方便随时监督。

第二道坎：两个深坑

坑一：往富文本编辑器里灌长文。 腾讯云的编辑器内核是 Monaco（VS Code 同款）。直接模拟键盘逐字输入，中文、特殊字符和代码块会触发自动缩进，整篇正文格式全乱。它的解法是跳过输入模拟，直接调用编辑器内部接口——Monaco 把文档内容暴露为 model 对象，一句 model.setValue(全文) 整体写入，格式问题全部绕开。

坑二：长文本怎么传进浏览器。 两千字中文加代码，经过命令行转义传入浏览器执行，编码和引号问题层出不穷。它最后把全文 base64 编码后写进一个 JS 文件，在浏览器里解码再写入。这个思路值得记一笔：当你控制的环境里有编程接口时，直接调接口永远好过模拟人操作。

坑三：自动化工具本身也会出毛病。 中途浏览器控制通道几次无响应，它从日志定位到守护进程卡死，杀进程重启后恢复。这段排查我没有插手。

发布环节

正文就位后，点"发布"弹出设置面板：来源选"原创"、标签选"运维"和"AIGC"，确认提交。之后文章进入审核，链接到手。从结果看流程走通了，但本文初版也被审核驳回过一次，原因在最后说。

几点心得

1. 人管授权，AI 管执行。 登录、支付、验证码天然需要人；网页操作、文本搬运、异常重试，AI 比人有耐心得多。这次最耗时的三件事——编辑器注入、编码转换、进程排查——没有一件是我愿意手动做的。
2. 下指令说目标，比说步骤效果好。 我从头到尾没告诉它"先点哪里再点哪里"，只给了目标和一两个约束。它自己选择技术路线，走不通时自己换方案。
3. 发布类动作保留人工确认。 AI 以你的名义发布内容，最终负责的还是你。
4. 用完即关。 远程调试模式等于把浏览器控制权暴露在本机端口上，任务结束应该随手关掉。

写在最后

说回这次被驳回的经历本身，它也是一个真实样本：初版成文时，机器叙事里带了些"全托管"式的渲染，在人工审核那里被判定为与事实不符。修改这一版时，我把表述逐句核对了一遍——哪些是我做的、哪些是它做的、哪些环节其实需要人，如实写。这也是我对 AI 工具的总体态度：它能显著降低执行的繁琐程度，但核对、判断和对内容负责的部分，仍然在使用者手里。