夜雨聆风这里说的 AI 编程工具，主要指的是 Codex 和 Claude Code 这类产品：它们不是单纯的代码补全插件，而是能读项目、改文件、运行命令、调用工具，并参与一段开发流程的 Agent 型编程工具。
如果只看单个功能，你大概会觉得这只是又一轮版本迭代。Codex 新增了 /goal 这类任务目标功能，让工具可以围绕一个明确目标持续推进；Claude Code 推出了 Routines，让一些重复任务可以按照时间、API 调用或 GitHub 事件自动触发。除此之外，Codex 还在加强权限配置和插件工作流，Claude Code 则在加强代码审查、执行钩子和多 Agent 协作。
这些变化看起来分散，但摊开对比以后，会看到一个更明显的趋势：
AI 编程工具正在从"帮你写代码"，变成"帮你持续推进一段开发任务"。
这也延续了我最近几篇文章里的判断。4 月 28 日那篇讲的是，模型竞争正在从回答能力转向任务交付能力；4 月 30 日那篇讲的是，当 Agent 开始执行真实任务，工程约束和 Harness 就会变得更重要。
今天这篇文章想继续看具体产品层面的变化：Codex 和 Claude Code 最近到底更新了什么，又为什么都在往工作流方向走。
Codex CLI 稳定版已经到 0.128.0。单独看某个功能，可能只是一次普通的迭代；但把这几个功能放在一起看，Codex 的定位正在发生变化。
先看 /goal 这个功能。这是 Codex 里用来记录和推进任务目标的功能。表面上看，它像是一个目标管理命令，但它背后实际的变化是：AI 编程正在从"这一轮对话里你让我做什么"，走向"这个项目里我持续要完成什么"。
一次 prompt 通常只对应当前这轮对话，而 Codex 的 /goal 是把一个任务目标固定下来，让工具围绕它持续跟踪进展、组织后续动作。这已经不只是对话式交互了。
举个例子，过去你可能会这样问：
> 帮我修一下登录页刷新后会丢失会话的问题。
这更像一次普通请求。Codex 做完一轮修改以后，任务是不是已经完成、测试有没有跑、相关边界有没有检查，仍然需要用户继续追问。
但如果把它写成一个 /goal，表达方式就会更像：
/goal 修复登录页刷新后丢失会话的问题。
要求：
1. 找到会话丢失的原因；
2. 修改前端和后端相关代码；
3. 补充或更新测试；
4. 运行相关测试；
5. 最后给出改动说明和验证结果。这时，重点不只是“让模型回答一次”，而是让工具围绕这个目标持续推进，直到它能说明自己做了哪些修改、跑了哪些验证、还有哪些风险没有处理。
再看权限 profiles、插件工作流、外部 agent 会话导入、MultiAgentV2。这里的权限 profiles，可以理解成不同任务场景下的权限配置；插件工作流，是让外部插件参与到 Codex 的执行过程里；外部 agent 会话导入，则是把其他 agent 做过的事情接入当前任务上下文。
这些概念本身并不陌生，但被放进 Codex 以后，说明它已经不满足于做一个"命令行里的 AI 助手"了。它要处理的问题开始变多：任务怎么持续存在？权限怎么分层？插件怎么参与流程？不同 agent 的结果怎么汇入？用户怎么在多个执行单元之间切换？
Claude Code 这边，变化同样密集。Routines 是定时或事件触发的自动任务；/ultrareview 是更深入的代码审查命令；session recap 是长会话的摘要和续接能力。
再往下看，hooks 是把团队规则接入执行过程的钩子机制；MCP 是让 Claude Code 连接外部工具和数据源的协议；worktree 则用于隔离不同并行任务的工作目录。这些功能看起来分散，但放在一起看，Claude Code 也不再只是一个本地开发会话了。
Routines 让任务可以被定时或事件触发。/ultrareview 强化审查深度。recap 让长会话不至于在中途断掉。hooks 和 MCP 把外部规则和工具接入执行过程。worktree 用来隔离并行任务。/usage 则让成本变得透明。
这些能力加在一起，并不是单纯为了让模型更会写代码，而是在给 Agent 接手任务之前，先把周围的脚手架搭好。
早期 AI 编程工具最容易展示的能力是写代码。你给需求，它生成函数；你贴报错，它帮你修。这些当然有价值，但都只是局部能力。
进入真实项目以后，一个任务往往是另一种形态：先理解项目结构，再判断改动边界，然后拆解步骤，修改多个文件，运行测试，根据失败结果调整，最后总结改动、提交或等待审查。整条链路跑下来，比的不只是模型能不能写出正确代码，而是工具能不能把这条链路稳住。
所以 Codex 和 Claude Code 都在围绕工作流继续完善产品。代码生成只是其中一环，更难的是任务持续推进时，工具能不能帮 Agent 记住目标、管理上下文、控制权限、调用工具、验证结果，并处理执行失败。
反过来想，如果这些能力跟不上，Agent 写代码越强，用户反而越不踏实。它能改更多文件、运行更多命令、调用更多工具，也就意味着它能影响更多状态。这时候用户真正在意的问题会变成：它知道该改哪里吗？会不会越过任务边界？改完以后验证了吗？失败以后会不会一路乱试？中间过程看得到吗？做错了以后能回退吗？
这些问题，靠模型本身解决不了。还需要产品设计、工程机制和 Harness 一起承担。
Codex 这轮更新里，我最关注的不是某个具体命令，而是它在让任务更容易被"托管"。
这里说的托管，不是把任务丢给 AI 就不管了。更准确地说，是用户不用把每一步都盯死，而是可以把一段任务交出去，让工具在明确边界里继续推进。
这和普通对话式 AI 不一样。对话里，你问一句它答一句；你不继续追问，任务就停在那里。但开发工作天然不是一轮问答就能收尾的。
比如修一个复杂 bug。Agent 需要先阅读 issue 里的问题描述，再查看日志，定位相关代码，修改实现，运行测试，最后根据测试结果继续调整。中间任何一步都可能出岔子。如果每一步都要用户手动推动，AI 不过是换了个人敲键盘而已。
/goal 功能的价值就在这里。它把任务从"对话里的临时请求"变成"工具持续跟踪的目标"。Codex 不只是等你下一句 prompt，而是围绕目标组织后续动作。
权限 profiles 同样关键。这里的 profile 可以理解成一套预设的权限方案。当 Agent 只负责生成建议时，权限不是大问题。但一旦它开始执行命令、修改文件、接入外部工具，权限就不能只靠一句"请谨慎操作"了。读代码、写文档、运行测试、安装依赖、访问外部服务、修改配置，这些动作的风险等级完全不同，不该被放在同一个权限层里。
权限 profiles 不是个小功能。它意味着 Codex 已经开始把 Agent 的操作边界当成一个产品问题来认真处理。
Claude Code 这边，我更关注的是它怎么把开发过程组织起来。
它一直有一个很强的特质：本地开发现场感。它知道项目结构，能读文件、改代码、运行命令，也能通过 hooks 接入规则，通过 MCP 接入外部工具。hooks 可以理解成工具执行前后的拦截点，MCP 则是把外部工具和数据源接进 Claude Code 的协议。你把它放进真实项目，它不是在旁边聊天，而是真的参与开发过程。
但这也带来一个新问题：它越能参与开发过程，就越不能只管"动手改"这一件事。
Routines 是一个明确的信号。它让任务不再只发生在"你打开终端的那一刻"。每天的代码审查、依赖检查、测试巡检、文档更新、PR review，都可以配置成定时或事件触发。Claude Code 正在接近一种"开发自动化代理"的形态。
具体怎么配置？Routines 不是写在项目里的某个普通配置文件，而是 Claude Code 的云端任务配置。你可以在网页端进入 claude.ai/code/routines，点击 New routine 创建；也可以在 Claude Code 命令行里用 /schedule 创建一个定时任务，比如 /schedule daily dependency check at 8am。如果你想让 routine 通过 API 调用或 GitHub 事件触发，通常需要到网页端继续编辑触发器。
桌面端也可以创建，但要注意选择 New remote task。如果选的是 New local task，那是本机定时任务，不是运行在 Anthropic 云端的 Routine。
比如你可以创建一个每天早上自动检查项目的 Routine。创建时，需要填三类东西：它要执行的 prompt，要关联的代码仓库，以及触发方式。prompt 可以写成这样：
每天早上 8 点运行：
检查这个仓库最近 24 小时的改动。
重点看三件事：
1. 是否有明显的安全风险；
2. 是否有测试缺口；
3. 是否有依赖版本或配置变更需要人工确认。
最后输出一份简短报告，并在需要时创建 issue 或评论到对应 PR。触发方式可以选定时，比如每天早上 8 点；也可以加 GitHub 触发器。比如每次有新 PR 创建时，让 Claude Code 按团队自己的 checklist 先做一轮审查，检查权限、数据库迁移、外部 API 调用和测试覆盖，再把结果留在 PR 评论区。
但自动跑只是第一步。自动跑的任务最怕两件事：方向跑偏，以及跑完以后没人知道质量怎样。
所以 /ultrareview 要提高代码审查质量，recap 要让长会话在中断后仍然能够继续，/usage 要让成本可见，hooks 要让团队把规则写进执行过程，worktree 要给并行任务划出隔离带。
这些功能合在一起，回答的是一个很实际的问题：如果 AI 真的开始替团队跑任务，怎么保证它不是"跑了就算"，而是过程能被看见，结果也能被审查？
两家的路线并不完全重合。
Codex 更像是在搭一个更大的工作台：命令行工具、桌面端、浏览器控制、computer use、任务侧栏、PR review、memories、remote connections、多终端。这里的 computer use，指的是让工具能够操作图形界面和浏览器；PR review 指的是参与代码合并前的审查；memories 则是让工具保留一些长期偏好或项目记忆。
这些能力放在一起，说明 Codex 的扩张方向，是围绕开发任务提供一个更完整的工作环境。
Claude Code 更像是从终端往外扩展：先把代码现场吃透，再通过 Agent Teams、Routines、hooks、MCP、worktree，把本地开发组织成更复杂的执行流。Agent Teams 解决的是多个 agent 如何分工协作；Routines 解决的是任务如何自动触发；worktree 解决的是并行任务之间的文件隔离。
一个从平台走向工作流，一个从开发现场走向自动化。
但走到最后，它们都会遇到同一道难题：Agent 越能执行任务，越需要明确的规则和边界。
这不是抽象概念，而是非常具体的工程问题：谁定义任务目标？谁决定工具能不能调用？谁限制高风险动作？谁验证执行结果？谁保存和清理记忆？谁处理失败和回退？谁审查最终交付？
如果这些问题没有答案，AI 编程工具就会一直卡在"很聪明但不太放心"的阶段。
所以我越来越觉得，AI Coding 的竞争不会只发生在模型层面。模型重要，但工具最终能不能进入真实项目，取决于它能不能把模型能力放进一套可控的工作流。
过去聊 AI 编程的最佳实践，基本都在讲 prompt，也就是我们给模型的任务指令：需求写清楚，约束写明确，让模型先解释再动手，改完让它总结。这些依然有用，但已经不够了。
如果今天重新谈 Codex 和 Claude Code 的最佳实践，我会更在意这几件事：
任务要有锚点。 不要只说"帮我优化一下这个模块"。写清楚目标、边界、验收标准、不该碰的地方。Codex 的 /goal、Claude Code 的 /plan 和 recap，都在强化这一点。/plan 是让 Claude Code 先生成执行计划，recap 则是让长会话在暂停之后还能恢复上下文。
权限要分层。 读文件、生成 patch、运行测试、安装依赖、修改配置、访问外部系统，风险完全不同。这里的 patch 指的是代码改动建议。别把所有动作都丢给一个全权限 Agent。能只读就只读，能建议就先建议，高风险动作必须确认。
验证要嵌进流程，不是事后补救。 写代码要跑测试，改配置要检查影响，生成文档要能追溯来源。Agent 越能自动执行，越不能让它自己宣布"我完成了"就算数。
长任务要有中断点。 同一类错误反复出现、同一批文件被连续修改、验证连续失败，这些都是该停下来交给人看的信号。别让 Agent 一路猜下去。
并行任务要隔离。 Claude Code 的 worktree、Codex 的多会话和多终端，都在处理这个问题。多个任务并行时，不能挤在同一个工作目录、同一个上下文里。
过程要可回溯。 AI 编程麻烦的地方不是它改错一次，而是你不知道它从哪一步开始改错。任务日志、review、recap、commit 粒度、变更说明，这些不是形式主义，而是后面能不能接管和回退的基础。
这些已经不是"怎么把 prompt 写好"的问题了，而是"怎么把 Agent 放进一套工程流程里"的问题。
这轮变化里还有一个容易被忽略的点：当 Codex 和 Claude Code 都开始支持更长任务、更复杂工作流、更多自动化以后，AI 编程就不只是"使用一个工具"，而更接近"运营一套流程"。
你得决定哪些任务适合交给 Agent，哪些必须由人处理；哪些可以自动跑，哪些必须审批；哪些结果可以直接合并，哪些只能作为建议；哪些记忆应该长期保留，哪些需要及时清理。
这会让 AI 编程变得更复杂。但所有进入生产环境的技术，最后都会走这条路。
一开始大家关注它能不能跑。然后关注它跑得快不快。再后来，就会关注它能不能稳定运行、能不能被管理、出了问题能不能查清楚。
AI 编程走到今天也到了这一步。当它只是补全工具时，我们只关心速度；变成 Agent 以后，我们开始关心边界；等它开始承接一段工作流，规则、权限和责任就都要跟上。
Codex 和 Claude Code 都不想只做一个写代码工具了。
它们正在变成两套不同形态的 AI 编程工作流。
Codex 在强化任务托管：目标、权限、插件、多会话、桌面端、浏览器和计算机控制，让用户可以把更大的任务交出去。
Claude Code 在强化开发流程：计划、执行、审查、复盘、定时任务、hooks、MCP、worktree，让 AI 更深地切入开发现场。
路线不同，但它们关注的问题越来越接近：AI 编程的重心，正在从"模型能不能写代码"转向"工具能不能稳定交付任务"。
接下来值得关注的，不只是 Codex 又多了哪个命令、Claude Code 又多了哪个功能，而是这些功能有没有被组织成一套可靠的工程工作流。
好用的 AI 编程工具，不会只是一个更聪明的聊天窗口。它会是一套能被托管、能被验证、也能被约束的执行系统。
这大概才是 Codex 和 Claude Code 这轮更新背后，更值得认真看的信号。
如果这篇对你有用，建议点个关注。
我会持续把 AI 编程领域的工具、方法和趋势拆成「最短上手闭环 + 坑点清单 + 复用配置」，让你少走弯路。
公众号 · 智享科技社
