我把 WorkBuddy 从“执行工具”用成了一个 AI 工作台：这几天的真实使用心得

这几天我一直在尝试一件事情：不只是让 AI 帮我写代码、做图片或者完成某一个具体任务，而是看看它能不能真正参与到一个持续运转的业务里，逐渐变成一个可以长期协作的“AI 工作台”。

我目前同时在推进独立站 SEO、社媒运营、B2B 商业资料、ComfyUI 视频自动化、CRM、数据同步，以及新的 Shopify 项目。过去这些事情往往分散在不同的软件和对话里，需要我自己不断切换、记忆和协调。

所以我开始尝试用 WorkBuddy 做一个更上层的管理系统。

一开始，我还是把它当成了一个“更能干的执行助手”

最开始的思路其实比较传统。

我给 WorkBuddy 拆了几个任务组：

• WooCommerce 网站技术和 SEO
• Reddit、X、Klaviyo 等内容运营
• ComfyUI、LoRA 和视频自动化
• B2B 合作资料与素材整理

然后让它建立任务、写脚本、配置流程，再把需要真正操作服务器的部分交给 Codex。

这套方法一开始是有效的。

它可以很快把一个模糊的需求拆成脚本、配置文件、README、部署流程和任务卡，甚至能主动整理 Codex 的交接协议。

但很快我发现一个问题：

AI 很容易把“完成任务”当成最终目标。

而实际经营一个项目，很多时候最重要的不是“把任务做完”，而是先判断：

这件事现在到底还该不该做？

Merchant Center 的事情让我意识到这个问题

一个很典型的例子是 Google Merchant Center。

原来的任务里有一部分工作，是围绕 GMC 做成人产品合规、Schema 和 Meta 调整。

如果按照传统自动化思维，AI 很可能会非常认真地继续：

分析规则 → 修改网站 → 调整 Schema → 准备申诉。

但后来重新梳理业务以后，我发现：

我本来就不需要 Google Shopping。

真正对我重要的是 Google Search、Search Console、SEO、自然收录、Academy 内容和 Product Schema。

这时候继续花时间“救 Merchant Center”，实际上是在非常高质量地执行一件已经没有商业价值的事情。

于是整个策略被改成：

不申诉、不绕过、不新建 Merchant Center，只退出商品推广体系，同时完整保护 Google SEO。

这件事情对我影响很大。

我开始要求 WorkBuddy：

不要为了完成任务而完成任务，要为了正确的项目结果工作。

后来我们把整个协议升级成了：

Reason Before Action

流程也从简单的：

接任务 → 执行 → 汇报

变成：

OBSERVE → CHALLENGE → DECIDE → EXECUTE → VERIFY → REFLECT

也就是：

先观察，先质疑，再决定要不要执行。

我越来越看重 AI 的“停止能力”

以前评价 AI 好不好用，我可能会看：

“能不能执行？”

现在我反而越来越关注：

它什么时候知道不应该执行。

比如 ComfyUI 视频生成。

我们之前做 Wan2.2 分段生成时，已经遇到过多次 scene drift、crop drift。

如果一个自动化系统只知道“把 5 个 Chunk 全部跑完”，那么一旦 Chunk 4 已经明显跑偏，它仍然继续跑 Chunk 5、6、7，本质上只是在浪费 GPU。

所以后来我给它设了一条规则：

出现：

scene_or_crop_drift

就：

STOP

先检查，再决定是否继续。

我觉得这是 AI 自动化从“脚本”走向“智能系统”的一个非常重要的区别。

好的自动化不是永远往前跑，而是知道什么时候停下来。

第二个很重要的体会：文件夹不等于真正的工作台

后来我们进一步规划了整个 FDY Control Plane。

我希望左侧能长期存在几个独立工作台，例如：

• FDY 总控台
• 网站 SEO
• X 增长实验室
• Reddit / TikTok
• B2B 视觉
• ComfyUI
• CRM
• 数据中台
• Shopify 手串项目

WorkBuddy 很快给出了结果：

目录建好了，WORKSPACE.md 建好了，LESSONS_LEARNED.md 建好了，API 权限矩阵也建好了。

报告看起来非常完整。

但我看了一眼左侧：

任务仍然只有 1 个。

这其实是一个很有意思的问题。

AI 在自己的文件系统里“模拟”出了 9 个工作台，但我真正需要的是 WorkBuddy UI 里的 9 个原生任务。

也就是说：

技术上做了很多事情，但没有真正完成用户看到的目标。

这让我更加确认：

以后不能只接受：

DONE

而要问：

Evidence 是什么？

真正的验收标准应该是：

结果有没有出现在实际使用界面里。

而不是某个 Markdown 文件里写着“已经完成”。

我现在开始把 Codex 的成果也当作“待验证资料”

之前 Codex 帮我做过很多事情。

SEO、WordPress、API、ComfyUI、本地脚本都有。

但是随着项目越来越复杂，我现在不希望 WorkBuddy简单地“接着 Codex 干”。

新的原则是：

Codex 做过 ≠ 正确。

所有历史产物统一标成：

LEGACY_REFERENCE

然后由新的工作台重新判断：

• KEEP
• KEEP_WITH_MODIFICATION
• REBUILD
• DEPRECATE

这一点我觉得很重要。

AI 之间不能形成一种奇怪的“互相相信”。

真正应该相信的是：

证据。

API 接管也不能一步到位

下一阶段，我希望逐渐把 Canva、Search Console、WordPress、WooCommerce、Klaviyo、飞书、Shopify、ComfyUI 等 API 接给 WorkBuddy。

但我现在非常明确：

不会一开始就给完整权限。

我准备让它按照这样的顺序成长：

READ → UNDERSTAND → TEST → LIMITED WRITE → VERIFY → LEARN → CONTROLLED AUTONOMY

比如 Canva。

我不会一开始就让 AI 批量修改整个 B2B 手册。

第一步只是：

读取。

看看它能不能判断：

哪些页面太像电商详情页；

哪些图片 AI 感太强；

哪些页面不符合采购商阅读逻辑；

哪些地方信息不完整；

哪些过去的设计其实应该推翻。

然后给它一个副本，只允许改两三页。

我肉眼验收。

通过以后，再扩大权限。

我现在觉得这种“调教”比单纯写一大堆 Prompt 有用得多。

因为真正的 AI 工作流不是一次性提示词，而是：

规则 + 数据 + 反馈 + 纠错 + 权限逐渐升级。

我希望它最终不是“万能助手”，而是一组专业工作台

我现在反而不希望所有内容都塞在一个超级 AI 对话里。

网站 SEO 应该有自己的规则。

X 增长实验室应该记住哪些文案已经用过、哪些 Hook 已经疲劳、哪些 Tag 最近真的有流量。

B2B 工作台应该永远记得：

这是给采购商看的，不是做社媒擦边图。

ComfyUI 工作台应该记得：

什么时候自动停止，什么参数曾经失败。

CRM 工作台应该知道：

哪些动作只能生成 Draft，不能自动发给客户。

所以我现在更喜欢的结构不是：

一个什么都会的 AI。

而是：

一个总控层 + 多个被持续调教的专业工作台。

总控层负责思考、冲突检查、API 权限和风险。

下面每个工作台负责自己的专业领域。

我觉得这样才有机会真正变成长期生产系统。

目前最大的感受

用了这一段时间以后，我最大的感受不是：

“AI 可以替我做多少事情。”

而是：

AI 能不能逐渐理解我判断事情的方法。

单纯让 AI 写文案、写代码、做 PPT，其实已经不新鲜了。

更有价值的是：

当我给出一个可能已经过时的指令时，它能不能提醒我：

这个任务的前提变了，要不要先重新判断？

当一个视频已经生成失败时，它能不能自己停止？

当另一个 AI 曾经做过一个方案时，它能不能不盲目继承？

当它说“已经完成”时，它能不能拿出真实证据？

当获得 API 权限以后，它能不能克制自己，不越权？

我觉得如果这些能力能够逐渐稳定下来，WorkBuddy 对我的价值就不再只是一个“自动化工具”。

它会更接近：

一个能够参与经营、持续学习规则、接受反馈，并逐步获得更多权限的 AI 项目团队。

现在这个体系还远没有成熟。

甚至目前还会出现“文件工作台已经建立，但左侧原生任务其实没有建立”这样的基础问题。

但我反而觉得这些问题很有价值。

因为真正把 AI 放进业务里以后，会发现最大的挑战从来不是：

AI 会不会做。

而是：

AI 是否知道自己在做什么、为什么做、做到什么程度才算真的完成。

这也是我目前使用 WorkBuddy 最大的一点心得。