1. 从QClaw停运说起：一次被迫的迁移决策
QClaw停运的消息出来那天，我的工作群里炸了锅。不是因为这个工具本身有多不可替代，而是因为太多人的日常工作流已经深度绑定了它——自动化脚本、定时任务、数据抓取、消息推送，甚至一些团队把QClaw当成了内部工作台的调度中枢。停运公告给了一个不算长的过渡期，但真正动手迁移的时候，你会发现事情远没有"导出再导入"那么简单。
我自己是最早一批开始折腾迁移的人，前后花了大概两周时间，把三个不同场景下的QClaw工作流全部搬到了WorkBuddy上。过程中踩了不少坑，也总结出了一些官方文档里不会写的经验。这篇文章就是把这些东西完整地梳理出来，给同样面临迁移的同行一个可参考的路径。
先说结论：WorkBuddy作为替代方案，在核心能力上覆盖了QClaw的大部分场景，而且因为架构设计的不同，在某些方面反而更灵活。但迁移不是无脑复制粘贴，你需要理解两个工具在任务模型、触发机制、数据存储上的差异，才能把迁移这件事做干净。另外，迁移期间送的1000积分是个不错的启动资源，后面我会讲怎么把这1000积分花在刀刃上。
这篇文章适合三类人：一是正在用QClaw、面临被迫迁移的开发者或运维；二是刚接触WorkBuddy、想系统了解它能力边界的新用户；三是对自动化工作流工具有兴趣、想找一个长期可用方案的技术负责人。不管你是哪种，下面的内容都会从实际操作出发，把迁移这件事讲透。
2. 迁移前必须搞清楚的三个底层差异
2.1 任务模型：从"脚本中心"到"技能中心"的转变
QClaw的任务模型是典型的脚本中心制。你写一个脚本，配置一个触发条件，它就跑起来了。脚本本身是独立的，依赖关系靠脚本内部的逻辑来维护。这种模式的好处是简单直接，坏处是当脚本数量多了之后，管理成本急剧上升——哪个脚本依赖哪个环境变量、哪个脚本的输出是另一个脚本的输入，全靠人脑记。
WorkBuddy用的是技能中心制。每个"Skill"是一个封装好的能力单元，有明确的输入输出定义，可以独立运行，也可以被其他Skill编排调用。这个差异在迁移时非常关键：你不能把QClaw的脚本原封不动地搬过来，而是要先拆解脚本的功能，把它映射成一个或多个Skill。
举个例子，我之前在QClaw上有一个"每日数据汇总"脚本，它做了三件事：从数据库拉数据、做格式转换、发邮件。在QClaw里这是一个脚本，但在WorkBuddy里，我会把它拆成三个Skill：数据查询Skill、格式转换Skill、邮件发送Skill，然后用一个编排流程把它们串起来。这样做的好处是，格式转换Skill可以被其他流程复用，邮件发送Skill也可以独立配置收件人。
注意：拆解粒度不是越细越好。我的经验是，如果一个功能在三个以上的流程中会被用到，就值得单独封装成Skill；如果只是某个流程的专属步骤，放在编排里内联实现反而更高效。
2.2 触发机制：定时、事件与手动触发的取舍
QClaw的触发机制相对单一，主要是定时触发和手动触发。WorkBuddy在这基础上增加了事件触发和Webhook触发，这意味着你可以做到"当某个条件满足时自动执行"，而不需要轮询。
迁移的时候，你需要重新审视每个任务的触发方式。我遇到的一个典型问题是：QClaw上有个脚本是每5分钟跑一次，检查某个API是否有新数据。迁移到WorkBuddy后，我把它改成了Webhook触发——API那边有新数据时主动推送过来，WorkBuddy收到后立即执行。这样不仅减少了无效轮询，响应速度也从平均2.5分钟降到了秒级。
但也不是所有场景都适合改成事件触发。如果你的数据源不支持Webhook，或者事件频率极低（比如一天一次），那定时触发仍然是更稳妥的选择。关键是要根据实际场景来判断，不要为了用新功能而用新功能。
2.3 数据存储：从本地文件到云端状态的迁移
QClaw的数据存储默认是本地文件系统，脚本读写文件都在本地。WorkBuddy则提供了云端状态存储，Skill之间可以通过共享的状态空间来传递数据。这个差异在迁移时最容易出问题，因为本地文件路径在WorkBuddy的环境里可能根本不存在。
我的处理方式是分两步走：第一步，把所有依赖本地文件的读写操作改成通过WorkBuddy的状态存储API来操作；第二步，对于确实需要文件系统支持的场景（比如处理大文件），使用WorkBuddy提供的临时文件空间，但要注意这个空间是有生命周期限制的，不能当作持久化存储来用。
这里有个坑我踩过：QClaw上有个脚本会把中间结果写到一个临时文件，然后下一个脚本再读这个文件。迁移到WorkBuddy后，我一开始还是用文件路径来传递，结果发现两个Skill可能运行在不同的容器里，根本读不到对方的文件。后来改成用状态存储传递数据才解决。
3. 一键迁移工具的实际能力边界
3.1 官方迁移工具能做什么、不能做什么
WorkBuddy官方提供了一个迁移工具，号称可以"一键迁移"QClaw的配置。实际用下来，它的能力边界是这样的：
| 迁移项 | 支持程度 | 说明 |
|---|---|---|
| 基础脚本逻辑 | 部分支持 | 简单的顺序执行脚本可以自动转换，复杂逻辑需要手动调整 |
| 定时触发配置 | 完全支持 | cron表达式会自动转换 |
| 环境变量 | 完全支持 | 会迁移到WorkBuddy的环境变量管理 |
| 本地文件依赖 | 不支持 | 需要手动改为状态存储或临时文件 |
| 第三方API调用 | 部分支持 | 常见的HTTP请求可以转换，特殊认证方式需要手动配置 |
| 数据存储 | 不支持 | 需要手动迁移数据 |
这个表格是我实际测试后的总结。可以看到，迁移工具能帮你省掉大约60%的机械性工作，但剩下的40%才是真正花时间的部分。
3.2 迁移工具跑完之后必须手动检查的五个地方
迁移工具跑完不代表事情就结束了。以下五个地方是我每次迁移后都会逐一检查的：
第一，环境变量的值。迁移工具会把环境变量的键迁移过来，但值有时候会丢失或者被截断。特别是那些包含特殊字符的密钥，一定要手动核对。
第二，定时任务的时区。QClaw默认用的是系统时区，WorkBuddy默认用的是UTC。如果你不手动调整，原本早上8点跑的任务可能会变成下午4点跑。
第三，API调用的认证信息。迁移工具对认证信息的处理比较保守，很多情况下需要你重新配置。建议迁移后先手动跑一次，看看有没有认证失败的错误。
第四，日志输出。QClaw的日志格式和WorkBuddy不一样，如果你的监控系统依赖特定的日志格式，需要调整解析规则。
第五，错误处理逻辑。QClaw的脚本里如果有try-catch之类的错误处理，迁移工具可能会把它简化掉。需要手动检查每个Skill的错误处理分支是否完整。
3.3 1000积分怎么花才不浪费
迁移期间送的1000积分，我建议这样分配：
- 前300积分：用于迁移后的测试运行。每个Skill至少跑三次，确认稳定性。
- 中间400积分：用于调试和优化。迁移后的流程通常需要调整参数、优化性能，这部分积分就是用来试错的。
- 最后300积分：留作应急储备。迁移完成后的一周内，很可能会有一些之前没发现的问题冒出来，留点积分应对突发情况。
不要一上来就把1000积分全部花在批量运行上，那样一旦出问题，你连调试的余量都没有。
4. 不同场景下的迁移实操路径
4.1 场景一：定时数据抓取与报表生成
这是最常见的QClaw使用场景，也是迁移相对简单的场景。我在这个场景下的迁移步骤是这样的：
首先，在WorkBuddy里创建一个新的工作台，命名为"数据报表"。然后，把QClaw上的抓取脚本拆成两个Skill：一个负责数据获取，一个负责报表生成。数据获取Skill配置定时触发，报表生成Skill配置为被数据获取Skill调用。
关键点在于数据传递。QClaw上通常是把抓取结果写到本地文件，然后报表脚本读这个文件。在WorkBuddy里，我改成数据获取Skill把结果写到状态存储，报表生成Skill从状态存储读取。这样即使两个Skill运行在不同的容器里，也能正常传递数据。
实测下来，这个场景的迁移时间大约在2-3小时，主要包括拆解脚本、配置Skill、测试运行三个环节。迁移后的运行稳定性比QClaw更好，因为WorkBuddy的状态存储有自动重试机制，不会因为一次写入失败就导致整个流程中断。
4.2 场景二：多步骤审批与通知流程
这个场景比数据抓取复杂一些，因为涉及到人工介入和条件分支。QClaw上通常是用脚本来模拟审批流程，比如发一封邮件，然后轮询邮箱看有没有回复。这种方式在WorkBuddy上可以做得更优雅。
我的做法是：用WorkBuddy的表单Skill来收集审批意见，用条件分支Skill来判断审批结果，用通知Skill来发送提醒。整个流程不需要轮询，因为表单提交本身就是一个事件，可以直接触发后续步骤。
迁移这个场景时，最大的挑战是把QClaw上基于时间的轮询逻辑改成基于事件的触发逻辑。我一开始试图保留轮询机制，结果发现WorkBuddy的定时触发最小粒度是1分钟，对于需要快速响应的审批场景来说太慢了。后来改成事件触发后，审批响应时间从平均5分钟降到了10秒以内。
4.3 场景三：跨系统数据同步
这是三个场景里最复杂的。QClaw上做跨系统同步，通常是用脚本分别连接两个系统，然后做数据比对和同步。迁移到WorkBuddy后，我建议用Skill编排的方式来做，而不是写一个大而全的同步脚本。
具体来说，我会创建三个Skill：源系统读取Skill、数据转换Skill、目标系统写入Skill。然后用一个编排流程把它们串起来，并在中间加入错误处理和重试逻辑。这样做的好处是，如果目标系统暂时不可用，编排流程可以自动重试，而不需要整个流程从头开始。
这个场景的迁移时间大约在1-2天，主要花在调试数据转换逻辑和处理边界情况上。我遇到的一个典型问题是：QClaw上用的是全量同步，每次把所有数据都传一遍；WorkBuddy上我改成了增量同步，只传变化的部分。这需要额外维护一个同步状态记录，但长期来看节省了大量的传输时间和API调用次数。
5. 迁移后容易忽略的配置细节
5.1 系统缓存目录的调整
WorkBuddy默认的缓存目录在系统盘上，如果你处理的数据量比较大，很快就会发现系统盘空间不够用。迁移完成后，第一件事就是检查缓存目录的设置。
在WorkBuddy的设置里找到"缓存管理"，把缓存目录改到一个空间充足的磁盘上。我一般会专门划一个分区或者挂载一个数据盘来放缓存。改完之后需要重启WorkBuddy服务，否则配置不会生效。
提示：缓存目录的路径不要包含中文或空格，否则在某些操作系统上可能会出问题。我习惯用类似
/data/workbuddy/cache这样的路径。
5.2 账号切换后的记忆恢复
如果你在迁移过程中换了WorkBuddy的账号，会发现原来账号的记忆（比如历史运行记录、自定义配置）不会自动同步过来。这是因为WorkBuddy的记忆是绑定账号的。
解决办法是在切换账号之前，先导出当前账号的配置和记忆数据，然后在新账号里导入。具体操作是在"账号管理"里找到"导出配置"，选择导出全部数据。切换账号后，在同样的位置选择"导入配置"，把之前导出的文件上传即可。
需要注意的是，导出的数据里包含敏感信息（比如API密钥），要妥善保管，不要随意分享。
5.3 自定义指令的迁移
QClaw上如果你用了自定义指令（比如自定义的脚本模板），这些不会自动迁移到WorkBuddy。需要手动重新创建。
WorkBuddy的自定义指令功能比QClaw更灵活，支持变量替换和条件逻辑。我建议在迁移时顺便把之前QClaw上那些"凑合用"的指令重新设计一遍，利用WorkBuddy的新特性来提升效率。
比如，我之前在QClaw上有一个自定义指令是用来生成日报的，格式很死板。迁移到WorkBuddy后，我把它改成了一个带条件判断的指令：如果当天有异常数据，就在日报里高亮显示；如果没有，就用普通格式。这样日报的可读性提升了不少。
6. 从迁移到精通：WorkBuddy的进阶使用思路
6.1 哪些Skill最值得优先掌握
WorkBuddy的Skill市场里有几百个Skill，全部学一遍不现实。根据我的使用经验，以下五类Skill是优先级最高的：
第一类是HTTP请求Skill。这是最通用的Skill，几乎所有的外部系统交互都靠它。掌握它的认证配置、超时设置、重试策略，能解决80%的集成问题。
第二类是数据处理Skill。包括JSON解析、CSV处理、数据过滤等。这些Skill决定了你能否在WorkBuddy内部完成数据清洗和转换，而不需要依赖外部脚本。
第三类是通知Skill。邮件、短信、即时消息推送，这些是工作流闭环的关键。WorkBuddy支持的通知渠道比QClaw多，配置也更简单。
第四类是状态管理Skill。用于读写共享状态，是多Skill协作的基础。理解它的并发控制和事务机制很重要。
第五类是错误处理Skill。包括重试、降级、告警等。这些Skill决定了你的工作流在异常情况下的表现。
6.2 减少"AI味"的实用技巧
WorkBuddy内置了一些AI辅助功能，比如自动生成Skill描述、智能推荐参数等。这些功能用好了能提升效率，但用不好会让你的工作流显得很"AI味"——就是那种机械、生硬、缺乏针对性的感觉。
我的经验是：AI生成的描述和参数一定要手动调整。比如，AI可能会把一个Skill描述成"用于处理数据的Skill"，这太泛了。你应该改成"从订单API获取当日订单数据，过滤掉已取消的订单，输出JSON格式"。这样不仅更清晰，也方便后续维护。
另外，WorkBuddy的AI推荐参数是基于通用场景的，不一定适合你的具体情况。我通常会先让AI推荐一版，然后根据实际运行结果来调整。比如超时时间，AI可能推荐30秒，但你的API响应比较慢，就需要改成60秒。
6.3 科研场景下的特殊配置
如果你用WorkBuddy做科研相关的工作，有几个配置需要特别注意：
数据隐私方面，WorkBuddy默认会把运行日志上传到云端。如果你的数据涉及隐私，需要在设置里关闭日志上传，或者选择本地部署版本。
计算资源方面，科研场景通常需要处理大量数据，建议把WorkBuddy部署在配置较高的机器上，并且把缓存目录设在SSD上。
可复现性方面，WorkBuddy支持导出工作流的完整配置，包括所有Skill的参数和编排逻辑。建议每次实验前都导出一份配置存档，方便后续复现。
6.4 从入门到精通的资料选择
市面上关于WorkBuddy的教程很多，但质量参差不齐。我建议的学习路径是：
先看官方文档的"快速开始"部分，把基本概念搞清楚。然后找一个实际的小需求，比如"每天定时抓取某个网页的数据并保存"，从头到尾做一遍。遇到问题的时候，优先查官方文档的FAQ，其次查社区论坛。
不要一上来就看那些"从入门到精通"的大部头教程，那些内容太泛，看完之后你还是不知道具体怎么做。最好的学习方式就是动手做，做一个真实的、你自己的工作流。
7. 迁移过程中那些没人告诉你的坑
7.1 时区问题导致的定时任务错乱
这是我踩过的最大的坑。QClaw的定时任务用的是本地时区，WorkBuddy默认用UTC。迁移完成后，我发现原本每天早上8点跑的报表任务，变成了下午4点跑。一开始以为是cron表达式写错了，查了半天才发现是时区问题。
解决办法是在WorkBuddy的定时触发配置里，明确指定时区。不要依赖默认值，一定要手动设置成你所在的时区。如果你有跨时区的任务，建议统一用UTC来配置，然后在Skill内部做时区转换。
7.2 环境变量命名冲突
QClaw和WorkBuddy对环境变量的命名规则不一样。QClaw允许用点号（比如db.host），WorkBuddy只允许用下划线（比如DB_HOST）。迁移工具会自动转换，但转换后的名字可能和你现有的其他变量冲突。
我的做法是迁移完成后，把所有环境变量列出来，检查一遍有没有重名或者命名不规范的情况。特别是那些自动转换过来的变量，名字可能会变得很奇怪，建议手动改成易读的格式。
7.3 大文件处理的性能陷阱
QClaw处理大文件时，通常是直接读写本地文件。WorkBuddy的状态存储有大小限制，不适合存大文件。如果你迁移的流程涉及大文件处理，需要改用WorkBuddy的临时文件空间。
但临时文件空间也有坑：它的生命周期是有限的，默认是24小时。如果你的流程需要跨天处理同一个文件，就需要把文件存到外部对象存储里，比如S3或者兼容S3的服务。WorkBuddy提供了对象存储的Skill，配置好之后用起来和本地文件差不多。
7.4 并发执行时的状态竞争
WorkBuddy支持多个Skill并发执行，这提高了效率，但也引入了状态竞争的问题。如果你的多个Skill同时读写同一个状态键，可能会出现数据不一致的情况。
解决办法是使用WorkBuddy提供的锁机制。在读写共享状态之前，先获取锁，操作完成后释放锁。虽然这会稍微降低并发性能，但能保证数据的一致性。对于确实需要高并发的场景，可以考虑把状态分片，不同的Skill操作不同的分片。
8. 迁移完成后的验证清单与长期维护建议
8.1 迁移后的验证清单
迁移完成后，不要急着把QClaw停掉。先跑一周的并行验证，确认WorkBuddy上的流程和QClaw上的结果一致。以下是我常用的验证清单：
- 每个Skill单独运行一次，确认基本功能正常
- 每个编排流程完整运行一次，确认Skill之间的数据传递正确
- 检查所有定时任务的触发时间是否符合预期
- 检查所有通知是否正常发送
- 检查错误处理逻辑是否生效（可以手动制造一个错误来测试）
- 检查日志输出是否完整，是否包含足够的调试信息
- 检查资源使用情况，包括CPU、内存、磁盘空间
这一周里，如果发现任何不一致的地方，及时调整。一周后如果一切正常，就可以正式停掉QClaw了。
8.2 长期维护的几点建议
WorkBuddy的工作流和代码一样，需要持续维护。我的建议是：
定期审查Skill的使用情况。有些Skill可能只在特定场景下用到，时间长了就忘了。建议每季度审查一次，把不再使用的Skill归档或删除。
保持配置的版本管理。WorkBuddy支持导出配置，建议每次修改后都导出一份存档，用Git之类的工具管理起来。这样出问题的时候可以快速回滚。
关注WorkBuddy的更新日志。新版本可能会引入新的Skill或者改变某些行为。及时了解这些变化，可以帮你提前发现潜在的兼容性问题。
建立监控和告警。WorkBuddy提供了运行状态的API，可以接入你现有的监控系统。建议至少监控任务成功率、平均运行时长、错误率这几个指标。
8.3 从QClaw迁移到WorkBuddy的长期收益
虽然迁移过程花了不少时间，但长期来看是值得的。WorkBuddy的Skill生态比QClaw丰富得多，很多之前需要自己写代码实现的功能，现在直接用一个Skill就能搞定。而且WorkBuddy的更新频率更高，新功能上线更快。
另外，WorkBuddy的社区比QClaw活跃，遇到问题更容易找到解决方案。我在迁移过程中遇到的几个问题，都是在社区里找到的答案。这种生态优势是QClaw不具备的。
最后说一句关于那1000积分的：不要把它当成一次性资源，而是当成一个启动资金。用这1000积分把基础流程跑通，然后根据实际需求逐步扩展。WorkBuddy的积分体系设计得比较合理，日常使用消耗不大，真正需要大量积分的是那些高频、大规模的任务。所以迁移初期不用太担心积分不够用，先把流程跑起来再说。
