这篇文章其实是这样来的——通勤路上用手机语音输入了一段思考，发给 Agent，Agent 整理成草稿，后来又配了图。全程没打开过一次编辑器。
这件事本身，就是想分享的。
过去两三年，AI 编码工具的节奏基本是这样的：2023 年初 Cursor 冒出来，大家开始认真对待 AI IDE 这件事；2024 年底 Windsurf 发布，同年 11 月 Claude Code 也出来了，2025 年各种工具密集迭代，连产品形态都在变——有的做进 IDE，有的做成 agent，有的又往 multi-agent 方向走。
每隔一段时间就有人在群里喊”这个工具真的太强了”。
但说实话，已经不太关心某个工具”最强”还是”次强”了。更在意的是：现在的这套配置，换了模型还能不能用？换了工具还能不能迁移过来？
这是这篇文章想聊的事情。
一、为什么是 Opencode——以及一个真实的迁移经历
用 Opencode 有一段时间了。选它不是因为它比 Cursor 或 Claude Code”更强”——这种比较本来就没什么意义，每个工具都在快速变化，今天的差距明天可能就不存在了。
选它，是因为它把可迁移性当成了第一优先级来设计。
具体来说：Opencode 完全兼容 Claude Code 的配置格式，CLAUDE.md 直接就能用，Skills 目录、MCP 配置、Slash commands，几乎没有什么东西是需要重新学的。如果之前在 Claude Code 上积累了一套完善的配置，迁移过来基本是零成本。
它支持多种使用形态——CLI、Web 端、桌面端——同一套配置，在本地跑、在云端跑、在沙箱里跑、甚至在 GitHub Actions 里跑，都是一回事。不需要为不同的环境再学一套新的用法。
最关键的是它的 provider 层完全可换。今天用 Claude，明天换 GPT，下周自己接一个内网代理，改一行配置的事情。
这里有个亲身经历：公司内网有一套内部 AI 编码工具，每个月给每位同学一定额度的请求次数。试过一段时间，功能上确实有些不如 Opencode，但更让人难受的是：已经为 Opencode 建了一套相当完善的子 Agent 协同体系——AGENTS.md 里的角色定义、各种业务 Skill、MCP 工具链——如果切到另一个工具，这些全要从头来。省下来的额度费用，远远抵不上重新搭一套配置的时间成本。
后来的解法是：直接把内部工具代理成 Opencode 的一个 provider，原来的配置一行不动，照常用。
想明白这件事之后就很简单了：工具随便换，但建设在开放格式上的配置积累不会清零。这才是值得花时间的地方。
二、yee88：从”必须坐在电脑前”到”随时随地”
2025 年 11 月，奥地利开发者 Peter Steinberger 做了个自用的 AI agent，原名 Clawdbot（后来被 Anthropic 要求改名，辗转成了 OpenClaw）。核心想法很简单：agent 跑在本地，用 Telegram、WhatsApp 这类 IM 来控制它、接收它的结果。2026 年初这个项目突然爆了，一周涨了 10 万 star，国内出现了”养龙虾”热潮。
OpenClaw 点破了一件事：IM 是比终端更自然的 agent 控制方式。agent 不是等你问才回答——它做完事情，会主动把结果、图片、文件一条条发回来，就像有个人在给你汇报工作进度。
yee88 受 OpenClaw 启发，是 fork 自同类项目、专门针对 Opencode 深度定制的版本。
在原项目基础上，加了定时任务、多 topic 管理（每个 Telegram topic 绑定一个项目，session 完全独立），还有一个叫 handoff 的命令——把电脑上正在进行的 Opencode 会话一键流转到手机继续，反之亦然。
这篇文章就是这套系统跑出来的。通勤路上用语音输入发了一段思考，Agent 整理好草稿、生成好配图，像数字人一样一条条发回来——不是”回家发现写好了”，是它在看手机的时候就已经在实时汇报进度了。
不只是写东西。开会时想到一个 bug，发条消息出去，Agent 改好等你回来 review。睡前想到某个功能，发出去，第二天早上结果已经在 Telegram 里了。Agent 不需要你陪着跑，你只需要在关键节点拍个板就行。
别小看这件事。异步加上碎片时间，攒起来推进的东西比想象中多得多。坐在电脑前盯着 agent 跑，本来就是一种浪费。
三、Raycast 插件：管 5 个项目和管 20 个项目的区别
有了 Opencode 做 agent runtime，有了 yee88 做远程桥接，真正高频遇到的摩擦点其实是另一件事：
手里同时有很多项目，上下文切换太频繁了。
这不是抱怨，这本来就是 AI 加持下的新常态。每个人能并行推进的项目数量比以前多了几倍——有的在 review，有的在等 Agent 跑，有的要关联起来一起给 Agent 处理。切换上下文、找目录路径、打开监控页面……这些操作每天统计下来至少 20-50 次。
解决方案是一个 Raycast 插件：扫描本地所有代码目录，自动识别项目类型，一键切换上下文。
选中一个项目，能直接跳到对应的终端目录、打开应用管理页面、看日志、触发预发部署、或者把项目路径直接扔给 Agent。前端项目和后端项目识别出来展示的 Action 不一样。用得越多的项目排越靠前，几天用下来就完全个性化了。
以前切换到一个项目大概要 30-45 秒——cd 目录、确认 branch、找相关链接。现在按快捷键、输两个字母、选择——3 秒以内。
这个效率差在管 5 个项目的时候感觉不明显，但当你同时在管 15-20 个项目的时候，它是一个每天都在生效的时间节省器。
四、关于”要不要追新工具”这件事
工具聊完了，说说背后的想法。
AI 工具更新这么快，要不要持续追新？这个问题想过挺多次。
现在的答案是：要追，但追的方式很重要。
“追”不是每隔三个月把整套工具链推倒重来，而是在稳定的底座上，持续接入新的能力。模型层变化最快——今天 Claude，明天 GPT-5，换一行配置的事，不需要任何其他东西改变。工作流层、习惯层变化最慢——“用 Agent 拆解并行任务”、”在终端里工作”、”异步处理碎片时间”——这些模式不依赖于任何具体产品。
真正需要认真投入的，是中间那几层：我的 AGENTS.md、我的 Skill 定义。这些投入是有价值的，但要投在开放格式上，而不是某个产品的私有生态里。Markdown 文件换到任何支持 system prompt 的 agent 都能用；MCP 是开放协议，不是 Opencode 的私有 API；Skills 就是文件系统上的指令集合。
选工具的时候，除了看功能，也得看你的投入能不能带走。一套建设在私有格式里的配置，等于把房子盖在别人的地上——工具一换，房子归零。
五、出差的一周：几个没想到的事
上面聊的都是工具和习惯。接下来说个最近的真实经历——三月份去海外出差，团队很小，产品、运营、研发加起来就几个人，待了一周。
出发之前以为会有大量时间在写代码。结果完全不是那么回事。
大部分时间花在了聊天上——聊业务问题、聊合作关系、聊一些产品形态上的可能性。晚上回酒店，三四个人围在一起，各自开着 Agent 忙到十一二点。但忙的不是在实现某个功能的细节，而是在讨论“我们到底应该做什么”。
这个过程有几个观察，挺出乎意料的。
Agent 管干活，人管想清楚
白天跟运营一起跑市场的时候，听到了一个很典型的痛点。
运营同学要帮卖家做大促提报，需要拿到平台系统期望的最低价。但系统没有直接导出这个价格的入口。于是他们想了个土办法：先从卖家后台把所有 SKU 导出来，再把这批 SKU 以一个偏高的价格导入到库存管理系统——系统会批量拒绝，而拒绝的 Excel 里面，会带上系统所期望的价格。运营再手动在 Excel 里把这些期望价格整理出来，和当前商家价格放到一起，搞成一份完整的对照表，拿去跟卖家谈。
核心就一件事：谈价格，看这个价格能不能用来做大促提报。
整个流程全靠手工，每个卖家都要跑一遍。
晚上回酒店，我们几个人就围着这个需求聊开了。这个需求本身很明确——已有的产品能力和数据接口就能搞定批量导出，不需要运营再去绕那个弯。方案 1、2、3 很快就出来了，Agent 当晚就开始跑最基础的那版。
但真正让我们加班到那么晚的，不是这个。
我们在讨论的是：为什么只导出成 Excel？Excel 导出来了，运营拿着去跟卖家谈，谈完了再手动回来改系统——这个环没有闭上。如果引入多维表，是不是能让整个从”看到价差”到”完成提报”的过程在一个地方跑通？讨论到一半，我们直接拉了协作平台那边的人，问权限打通有没有卡点、数据安全有没有问题、中间的技术瓶颈在哪、产品交互和流程流转该怎么设计。
从研发的角度看，这一晚上没有讨论过一行代码怎么写。讨论的全是：这个场景的产品形态应该长什么样？端到端的流程怎么闭环？短期做什么、长期做什么？
至于代码？”Agent 跑得怎么样了？””跑完了，review 一下。”就是这样。
第二天我们拿着近期、中期、长期三套方案去跟业务方聊，效率高得不像话。因为前一晚该想的都想完了，该跑的也跑完了。而且我们在这个过程中，已经有了比最初需求更远一步的产品形态——不只是”帮运营导个表”，而是从端到端的角度提供了一套更完整的方案。
以前出差大概是这样的：白天调研需求，晚上赶代码，第二天交一个半成品。现在变成了：白天调研需求，晚上讨论方向 + Agent 跑实现，第二天交的是方案加成品。人的时间从”怎么实现”彻底转移到了 “该不该做、做成什么样” 上面。
每个人都在跨界，而且跨得理直气壮
另一个让我感触比较深的事，是角色之间的边界在变模糊——而且是双向的。
一方面，产品同学在讨论交互的时候，直接用 Agent 生成了一个能跑的 HTML 页面，把她想要的效果完整表达了出来。不是线框图，不是 PRD 里的文字描述，是一个实际可运行的前端页面。这个东西拿到研发手里，相当于一份精确到细节的 spec，Agent 照着还原就行。这在以前是研发的活，现在产品自己就能出一部分。
但反过来也一样。研发不再只是坐在那等需求文档然后埋头写代码了——我们在那些晚上的讨论里，花了大量时间在聊业务本身的问题：当前已有哪些技术能力可以复用？这些能力分散在哪几个团队手里？我们应该以什么方式把这些能力组合成一个产品交互？甚至会讨论到产品形态本身——比如这个场景做成客户端会不会是更好的选择？还是做成 CLI 给 Agent 用，接入内部 AI 平台？这些都是技术侧给出的输入，反过来影响最终的产品设计。
以前的分工很清楚：产品想清楚要什么，研发负责怎么做。现在变成了大家坐在一起，产品可以直接输出一部分技术产物，研发也在用更宏观的视角参与业务决策。职能的边界不是消失了，而是变得更有弹性——每个人都在往对方的方向多走了一步。
说不上来这算好还是算乱，但至少在出差那一周，事情确实推得比以前快很多。
最后
回头看这篇文章，前半段在聊工具——Opencode、yee88、Raycast——本质上都是在解决同一个问题：怎么让自己的工作方式不被某个具体产品绑死。后半段在出差的那一周，其实在验证另一件事：当 Agent 真的接管了大部分执行工作之后，人的时间到底花在哪了。
答案比想象中清楚：花在了理解问题、讨论方向、跨出自己原来的职能边界去推进事情上。写代码这件事没有变少，只是不再需要人亲自坐在那一行行敲了。省下来的时间，被填进了更难、也更有意思的事情里。
工具会变，模型会变，甚至谁该干什么这件事也在变。但有两样东西越来越确定：一是你对自己工具链的积累——那些 AGENTS.md、Skill 定义、MCP 配置——只要投在开放格式上，就不会白费；二是你对业务和技术交叉地带的判断力——这个东西没有捷径，只能自己趟。
这两样东西，比任何一个具体的工具都耐用。
