从实际 vibe coding 的效果来看，并非每个任务选择最强模型就是最佳选择，也不是无脑新开子 Agent 就能保持最佳上下文和执行效率。 最贵模型的推理思考能力很强，但处理普通任务，例如读写文件、代码搜索、格式化、简单查询时，效率经常很低。 背后的原因也很简单，强模型的 thinking 和 reasoning tokens 开销很大，而这些任务并不需要深度推理，过度思考只会增加延迟和 token 消耗。例如，用 Opus 做一次 Glob 搜索和用 Haiku 做，结果基本一样，但成本会差出两个数量级。 要把任务做好，关键不在于模型是不是最强，而是看任务能否正确匹配模型的能力密度。Claude Code 在创建 Sub-Agent 时，就围绕这方面做了大量设计： 1）当需要保留当前对话上下文继续工作时，例如并行探索不同方案、在后台执行独立子任务，它会 fork 一个 Agent，继承当前上下文，让任务在同一语境中延续； 2）当任务目标明确且不依赖父会话上下文，例如代码搜索、方案规划、结果验证，它会直接使用内置 Agent，包括 Explore、Plan、verification、general-purpose 等，调度的时候，会给 Agent 分配一个清晰的任务目标； 3）设计了 Agent Team 模式，支持让多个 Sub-Agent 协同工作，分工不同的子任务，互相之间通过消息传递和共享上下文来配合完成更复杂的工作。Agent Team 跟普通 subagent 的不同之处是，成员 Agent 之间允许通讯。 在 Sub-Agent 的模型选择上，Claude Code 是动态设定的，例如 Explore Agent 采用的就是 Haiku 模型，而 Plan 和 verification 默认会继承父模型。 Haiku 模型延迟最低、单 token 成本也最低，在文件搜索、代码定位、文档分析等等只读场景下，准确率已经足够了，整体性价比也是最优的。 有了模型选择的基础，再往下就是执行方式的优化。要同时兼顾成本和效率，核心思路是并行执行，将任务拆成多个上下文隔离的子任务，再分派多个 Sub-Agent 并发处理。也分享几个在 Claude Code 中的小技巧，用起来可以让成本、效率和效果达到一个更好的平衡： 1）通过环境变量 CLAUDE_CODE_SUBAGENT_MODEL 可以统一指定子 Agent 的默认模型，主会话用强模型做调度和决策，子 Agent 用轻量模型做执行，配置简单，几乎零成本接入。 2）通过 Fork 模式复用父会话的 Prompt Cache，让并行子任务共享上下文前缀的 KV 缓存，10 个并行 fork 的成本接近 1 + 9 × delta，在大规模并行场景中非常省钱。直接跟主对话说“从当前上下文 Fork 子进程处理”即可。 3）通过 .claude/agents/ 目录下的声明式 Markdown 文件定义专用 Agent，可以精细控制模型选择、工具权限、最大轮次、执行模式、隔离方式、记忆范围、MCP 服务、Hooks 等，适合那些会反复出现的固定角色，例如 code reviewer、security auditor 等等。项目长期使用的专用 Agent 可以考虑用这种方式来定义，后续维护和迭代也更方便。 好模型的 token 成本会越来越高，获取难度也是越来越大，短期内一定是供不应求的，因此模型的推理能力需要被转换为一种精细化分配的资源。中低难度的任务把国内模型用起来就好了，反而效率更高，还省钱。 在 vibe coding 的时候，学会让不同能力的模型组合完成任务，将会是一项必备技能。😄

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）。每一步要做什么，完全交给模型自己来判断，相当于把模型当成一个负责交付结果的工程师。

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

给娃的 vibe coding 做了一个游戏控制台，能够管理所有的游戏，也加了个“创意启动机”，帮助孩子管理创意。这里花了点小心思，加了范围约束，限制她的游戏都是开动脑筋、提升认知和激发阅读兴趣类的😅 游戏界面的聊天跟我微信里的 OpenClaw 打通了，有任何问题，娃可以随时留言，然后我开始指挥我的🦞远程后台处理，Perfect!

研究了几天 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 切换的效率，通过增量更新、差异加载与状态缓存等方式减少重复计算。不过，再往下优化，边际收益就不高了。