Barret李靖 (@Barret_China)

昨天跟团队分享，怎么把自己的工作真正搬到云端。 乍一看，只不过是给自己配置了一个可以对话的 Agent，但工作模式已经发生了颠覆性的变化。 比如我的AI 会读取我所有工作聊天记录后，将需要关注的事项定时推送给我，分析过程中会结合我自己的工作目标，给出针对性的建议。对于可直接被 AI 执行的任务，它也会自动处理掉。 比如晚上睡前我会将比较重的任务，指派给AI，讲清楚细节和验收标准，然后让它根据我设定的工作环境、操作流程和验收机制，进行研发。它开发好了之后会自己提一个PR 到仓库，然后走完 CI 流程，最后再给我一份质量报告、效果截图，等我验收。 比如系统收到一条面试通知，我的 AI 我会自动将候选人的基本信息拿出来，先跟业务和团队目标做一致性匹配，如果合适，它就会自动生成分析报告和推荐的面试题。等面试结束后，它又会将我跟候选人的聊天自动抓回来，做一次诊断，既有对我的建议，也有对候选人的分析。 之前的工作，更多是守在电脑前陪伴执行，必须盯着过程，脑子里还得时刻维护一张复杂地图，记住所有模块、技能、工具链、上下游关系，生怕哪个环节断掉。 把 AI 的执行过程搬到云端后，很多东西开始变了。它会将我的所有细枝末节工作自动串起来，而我需要做的就是想清楚要干啥，这有点像是，将“同步工作”变成了“异步工作”。现在基本上都是手机遥控，语音给 AI 发送指令。 人从执行细节里抽离出来之后，会突然多出大量时间。开始更多去思考：到底应该做什么；什么事情真正有价值；结果是否值得；方向有没有偏。 这个变化，可能比“用了 AI”本身还重要。越来越相信未来的工作模式，就应该是 cloud agentic 模式。

将所有的工作迁移到云端，然后通过一个对话框去接入，这听起来很极客。 最大的问题是，如果脑子里没办法装下所有的工作地图，并且不知道启用怎样的工具去触发工作地图里任务的流转，就会很容易因为频繁地通过聊天窗口跟云端对话而使自己迷失。 一旦还想着通过 GUI 的方式去呈现工作的入口，又会把自己拉回到原始的工作模式，捧着电脑，看着图形化界面，然后执行一些敲击和点击动作。 我也还在探索什么样才是最好的云端工作模式，过去一周，我几乎没有碰过键盘都是语音发送指令，包括编程工作（也包括这条）。脑子也经常因为频繁上下文切换变得略微混乱。 保持聚焦，可能是一个比较合适的解法。每天、每周我们都是有交付内容的，如果把精力聚焦在核心要交付的三件事情上，那一切也会变得简单。 在完成这三件事情的过程中去补充 skills 和一些基础服务能力，慢慢地，当天的工作解决了，AI 所需要的基础能力也补齐了。 到最后，人只需要想清楚具体要完成的目标上就行了，然后跟 AI 交代清楚。

已经把将近一半的工作迁到了云端。这一周的体感是，未来知识工作者的生产方式，绝大部分都会是云端 agentic，人类搭建 harness 环境，AI 来执行，生产质量完全取决于 harness 的质量。 曾经也想过用嘴编程，没想到这一天来的如此快😂

推荐卡兹克最近搞的这个 AI 资讯站点，内容质量还不错， 真正专业花心思做自媒体，一定都会精心维护自己的 feed 流，也能产出有价值的行业日报周报，相比之下，我就是个纯粹的技术研究者，哈哈。

研究了几天 Tailscale，用它组网实在是太方便了。它支持让任意两台设备，在复杂网络环境下，稳定、安全、低成本地互联，就像在同一个局域网一样使用，也支持将内网服务暴露到公网访问。 Cloudflare Tunnel 是把内网服务安全暴露到公网，在公网进行统一管理；Tailscale 的体验更像是，把所有设备拉进一个私有局域网，它会给所有的设备分配一个 100.x 的局域网 IP。设备跟设备之间互联，优先采用 P2P，通讯效率极高。 现在手机访问家里的 NAS，以及电脑 ssh 家里其他机器，都是局域网处理。这个产品简直就是在重新定义“内网”，😅

+ Agent 的协作模式，以群聊（Channels）为工作入口，核心产物是 todolist，AI 会自动推进 todolist，聊着聊着 AI 就把事情给干了。 平台不提供 Agent，用户来提供。用户在自己电脑上安装接入程序，它是一个 bridge 控制面，会把 Slock 里的消息、任务、系统通知等转换成可处理的输入，转给用户电脑上的 AI 来处理，然后将处理结果发回 Slock。 控制面在 Slock，执行面在本地 runtime。

关于 AI Coding 和 Harness 最近写的一些内容： 让 AI 学会并发干活儿 让 AI 能够复用过去的经验，把代码写的更好 如何让 AI 进入疯狂工作模式 让 AI 输出效果提升五倍 AI 解放双手，如何把工作托管给浏览器 AI 时代的软件开发速度 Claude Code 的编程哲学 Vibe coding 的宪法 Claude Code 的记忆设计 Harness，让 agent 跑长程任务 为什么你的 agent 跑不了长程任务？ 构建有效的工作上下文，让 AI 参与决策 AI 时代的软件形态 Harness 也是过渡产物 组合不同 LLM 完成任务，会成为必备技能之一。 文档编程，让 AI 一直跑下去。 让 AI 减少犯错 Codex 长程任务的运行机制 Claude Code/Codex 的记忆设计哲学 大多数人不知道如何给AI定目标

Spec-Driven Development 如果把任务的颗粒度拆得过细，且没有控制好任务边界和不做什么的声明，在调度多 agents干活时，特别容易出现过度设计问题。 over engineering 更让人头疼，下面是一个很高频的 case。 原始目标只是：给后台系统增加一个文件上传能力。 结果因为没有明确约束： * 一个 subagent 引入 repository pattern * 一个 subagent 开始设计 storage provider abstraction * 一个 subagent 顺手兼容 S3 / OSS / GCS * 另一个开始补异步队列和事件系统 * 最后甚至拆出了 upload-sdk 硬生生干出了一套半成品云存储框架🥹，可真实需求只是：单机部署，上传到本地磁盘。 从局部看，哪哪儿都没毛病，还写的挺好，全都是最佳实践，但离原始目标已经十万八千里了。 最头疼的是，你的同事给你提了这样的代码 PR，你合还是不合？

以前更换电脑，是吭哧吭哧用 dotfiles 管配置、写脚本，一点点把环境克隆出来。 现在的方式简单粗暴多了。打开新电脑的远程端口，让旧电脑直接 ssh 过去，然后丢给 AI，一路操作下去。吃个饭回来，七七八八了。😜

AI 能够很大程度替代知识工作者后，再去回看前些年流行的大厂 35 岁门槛，就更能理解原因了。 Coding 可以说是劳动密集型的知识生产活动，对熟练工的依赖性比较强，一般程序员到 30 岁基本都达到了熟练工程度，后续竞争力便开始下降。 社会对人的隐形评估函数是，经验 × 成本 ÷ 可替代性，经验不增长，成本提升，可替代性也提升，35 就很容易接近极点了。 而这一波 AI 的影响，大厂对两类人的需求量会增加，一类是工程和架构能力强的专家，能定义复杂问题，也能解决复杂问题，年龄反而没那么重要；另外一类是创新意识和动手能力强的年轻人，没有先入为主的观念，喜欢天马行空，想了啥就直接干。 最近的体感很强烈，未来挺长一段时间都要去适应不确定的环境，企业和个体都比较艰难。

十五年前学前端，把《JavaScript权威指南》精读了六遍，至今还能手写几乎全部底层API。 AI 时代的犀牛书，就是 Claude Code / Codex 的源码，时不时对着它提个问题，让 AI 写一份调研报告，熟悉 Agent 交互逻辑。同样需要长期浸染其中保持手感。

Codex 的 /goal 没有设置 turn 上限，也就是说，只要它认为目标没完成，除非把你的账号干到限流，不然不会停下来。 很多人根本不知道如何给 AI 设定目标，使用 /goal 和输入单条 prompt 几乎无区别。 例如，“把代码优化一下”，“提升系统性能”，“接口设计优雅一些”，这种目标是无法驱动 AI 持续工作的，既没有明确产物，也没有验收标准。 又比如，“网页改版，改的更好看”，“产品交互体验太差了，打磨一下”，这种目标最大的问题是“更好”本身没有可度量的指标，模型只能往各种可能性上反复尝试，要么提前结束，要么疯狂优化，无限烧 token。 好的目标 = 交付物 + 验收标准 + 约束条件 举个例子：“把登录接口优化一下” 可以改成：“重写登录接口逻辑，提交 PR，并确保在 100 并发下 P95 latency ≤ 120ms，所有现有测试通过，且不引入新的依赖” 在制定目标的时候，也无需吝啬 prompt： 从定义 /goal 的过程中，也能看出定义问题的水平。好的问题，可以调度更多的算力去解决更复杂的问题。

土耳其的货币长期贬值，因此软件售价也比较低，ChatGPT Plus 在美区大概是 136 元/月，到了土区就只要 75 元（499 拉里），相当于半价售卖。 刚试了下，把 ChatGPT 订阅换成了土区，还是比较轻松的。 1. 用 3 年前的老办法，申请了一个土耳其的账号。Apple 一直比较开放，注册账号的时候，选对应国家，那获得的就是对应国家的账号，也没有要求你必须用当地的手机号码验证。只不过第一次订阅支付的时候会报个错，可以考虑随便下载个软件，会触发「检查」，然后设置页补充填个土区地址就好了。 2. 去闲鱼或者 mtcgame 这个网站购买土区的礼品卡，充到 Apple 账号就可以开始订阅付费了。 比较搞笑的时候，土区的月费是 75 元，年费却要 1358 元（75 * 12 = 900），看不懂这个定价逻辑🐶

Codex 生成视频配音的做法也令人虎躯一震，它并没有按照文档指引（剪映+讯飞配音）来操作，而是采用工程手段，找到了一条比较通用的配音方案。 1）分帧截屏，将多图按序合成为一张图片（8x4，共 32 帧)，统一交给 AI 理解故事线，理解好了之后，AI 会生成每一关键帧的解说台词。 2）语音生成，它用到了开源的 text-to-speech 服务 rany2/edge-tts（10k star，这里应该是用到了我给它的全局设定，尽量“拿来主义”），将中英文台词分别合成为逐句音频，并严格对齐到时间轴。 3）视频合成，这个阶段基于 imageio/imageio-ffmpeg 提供的内置 ffmpeg，用 adelay + amix 完成配音与原声混音，再通过 subtitles 和 drawtext 一次性烧录双语字幕与缓动水印（视频里的水印被我处理掉了）。 这个模式感觉也适合将国语内容直接转换成英文内容，😄

女儿学校给布置了一道 AI 作业，用剪映和讯飞给一段无声视频配音，并给出了详细操作步骤文档。 经过半个月 vibe coding 的她，题都没看，直接把视频和 pdf 文档拖进了 codex😅，然后按下 fn 键开始微信语音输入，“帮我做这个作业”，👇

最近一直在研究 Codex 和 Claude Code 的记忆设计，发现两者的设计哲学和玩法有很大差异。 Codex 的设计目标是让一个 agent 运行的够久，所以它的执行策略偏向于把记忆当做工具，持续构建工作上下文（work memory），为当前的 goal 服务。OpenClaw 也是这个工作模式。 Claude Code 更像把记忆当成认知架构。它不只记录当前目标，还会在不同时间尺度上持续沉淀用户偏好、上下文变化、执行经验和行为反馈。它更偏向于让多个 agent 各自在独立上下文中高效工作，由外部逻辑（文件记录、coordinator 管理等）确保整体进度不丢失。它不信任任何单个 agent 能跑到底，所以把进度状态放在 agent 之外。 Codex 也意识到当前记忆设计的缺陷，尝试引入更持久的记忆机制（执行 codex features enable memories 可启用），支持跨对话记住你的项目上下文。每个交互轮次结束后，Codex 会自动从对话中提取有价值的信息（架构决策、代码约定、踩坑经验等），存到 ~/.codex/memories/。 Codex 更像是一个执行者，专注于完成任务，而不是管理记忆或上下文。它的设计哲学是“做就对了”，不太关心过程中的失误或偏差，只要最终结果符合预期就行。正因如此，很多人体感 Codex 在指令遵循方面做的更好。 Claude Code 更像是一个学习者，通过不断的试错和反思来提升自己的能力。它不仅关注完成任务，还关注如何完成任务。它会持续记录和分析执行过程中的每一步，积累经验和反馈，不断优化自己的行为策略。 二者各有优劣，你更看好哪种模式？

Codex 在 0.128.0 引入了 /goal，一个不达目的不罢休的 Agent 设计，轻轻松松跑七八个小时，烧 Token 也很猛。 它跟 Spec-Driven Development 不太一样，实现上比较直接，约等于把社区流行的 Ralph loop 内置到了 TUI 里：while :; do cat PROMPT.md | codex; done。 /goal 既不做任务规划，也不做流程编排，它只提供约束和目标。只要目标没达成，它就让模型持续干活。 那它是如何不忘记任务的呢？其实也很简单，它把目标写进了数据库🥲，默认放在 ~/.codex/state_5.sqlite，每次 loop 都会读一遍数据库。当前的设计里，一个 session 只支持一个 goal，无论是进程重启还是 ctrl+c 中断都会自动恢复目标任务。 在任务的恢复机制上倒是做了一些优化，为了避免跟用户抢控制权，/goal 会严格检查当前线程是否处于空闲状态，然后再自动注入一个 continuation prompt 推进下一个 turn，prompt 拼接的内容大概做了这么几件事情：1）把目标转成可验证交付物；2）构建 checklist；3）检查真实产物（文件、输出、测试）。 在 prompt 里还做了比较强硬的检测声明：不接受看起来完成，不要因为 token 预算焦虑就提前完成，不要相信之前的记忆，只要有不确定性就继续干。 这种设计最大的问题就是巨量的 token 消耗，/goal 没有采用对话追加模式，每轮都会发送完整的对话历史，这会导致 token 消耗随轮次 n² 增长，而烧钱的问题完全靠服务器端的 prompt cache 机制来缓解。cache 也不是完全免费，只是成本更低而已，Claude Code 的 cache-hit 价格是 1 折左右，估计 Codex 的价格会更低。 可以这么理解，/goal = 目标驱动（objective）+ 状态感知（budget/time）+ 验收机制（audit）。每一步要做什么，完全交给模型自己来判断，相当于把模型当成一个负责交付结果的工程师。

AI 会犯错误，而且喜欢犯同样的错误，如何确保在更换模型、切换上下文的时候，AI 不再犯？ 最有效的办法就是，把 AI 犯过的错误记录下来，然后将它变成规则文档或者程序脚本，每次提交前都强制检测一次，成为门禁。 我当前的设计是，AI 犯错后会自动更新两类产物：1）rules docs，每次 AI Code Review 的时候，会加载这部分内容；2）governance scripts，将可程序化的检测工作全部变成脚本，例如 git commit 规范、大函数检测、单测覆盖、代码引用规范等等。 项目跑的越久，AI 犯错的概率就越低。

代码编程之前，先进行一轮文档编程。由 Claude Code 完成所有 AI 任务的拆分和编排，再交给 GitHub Copilot 一气呵成，agent 疯狂跑了 8 个多小时，token 消耗才 0.3%，充分利用了 Copilot 按请求次数收费的机制。感觉永远用不完，😅 这套执行流程（图三）陆陆续续打磨了一个多月。整体设计为主从式 agent 结构，主 agent 负责决策与任务分发（Coordinator），多个从 agent（Explore / Review / Repair / Experience）负责执行、修复与经验沉淀。过程管理采用 TASKS.md（管任务）+ CURSOR.md（管进度），确保每个步骤执行到位，全程 AI 自主完成。 执行效果基本符合预期（图一）。每轮任务完成后会触发 2～3 轮 code review，将问题逐步收敛并修复。最终产出的代码质量较稳定，没有明显缺陷，还额外覆盖了一些性能优化场景。 目前最大的问题是，耗时太长了（图二）。整个过程花费了 8 个多小时。分析了整个执行过程的耗时分布，agent 真正写代码执行只占 48.7%，其余 51.3% 都花在 review、fix、recheck、accept、phase 任务上，后置的质量闭环占了大头。 这就是利用 subagent 做复杂 context engineering 的必然代价。每个 phase 结束后，agent 都需要重建上下文，重新加载代码、review 结果与规范，同时同步任务卡与状态文档，才能进入下一阶段，context 切换成本非常高。 要做到效率真正提升，目前有两条路径，一是压缩 agent 执行链路，将文档驱动的流程逐步固化为可复用的代码逻辑；二是优化 context 切换的效率，通过增量更新、差异加载与状态缓存等方式减少重复计算。不过，再往下优化，边际收益就不高了。