在先前的 Codex 实践中，我们已经跑过 CLI、读过开源项目，也用 /status、/diff、/review、/plan 等 Slash Command 管理过一次完整的开发过程。
到了这一篇，我们来做一个时间更长的任务。
最近，小七一直在用 Codex 做一个叫 huhu-airConditioner 的小项目，中文名叫「隔屏吹风」。做这个项目的原因是有一天，小七在空调房里开着 28 度的空调吹风扇，被冻得瑟瑟发抖，于是萌生了个想法：能不能把风扇、空调、房间环境和人体体感全部算出来？
在这个页面上，你可以调节空调温度、风量和模式，也可以选择不同类型的风扇。页面会根据当前的输入信息，来计算风速、体感温度等结果。当然，小七还弄了个小黑屋------进入隐藏的工程模式，还能继续调整房间、湿度、衣着、距离等参数，查看空调与风扇组合的功耗，最重要的是，你可以知道怎么搭配会更省电！守住钱包很重要。
其实，这个隔屏吹风做到这里，基本上是成型了。接下来，小七带你进入另一种开发状态：基础功能已经有了，但产品还需要一轮一轮继续优化。
正好用来讲解本次 Codex 实践的/goal 和 /plan部分。
长任务里的 Goal 与 Plan
之前介绍 Slash Command 时，我们简单用过 /goal 和 /plan
如果只看名字， /goal 和 /plan两者好像都有一点"先告诉 Codex 准备做什么"的意思，但放到持续迭代的项目里，它们的职责其实很好区分。一开始，小七设想的流程是这样的：
Goal
整个阶段最终想做到什么
↓
Plan 01
这一轮解决什么
↓
执行 + 验证
↓
Plan 02
下一轮解决什么
↓
执行 + 验证
↓
Plan 03
继续推进
↓
最终回到 Goal 检查这样分工就很清楚了，Goal 管的是一段时间里的持续目标；Plan 管的是当前这一阶段准备怎么完成。
OpenAI 官方现在把 Follow a goal 定义成适合长时间工作的 Codex 用法：给 Codex 一个持续目标，让它在多轮工作中朝着可以验证的结果推进。
对于 huhu-airConditioner 来说，我们不会给 Codex 一个需求，然后让它一次性把整个产品重新做一遍。
这次准备围绕几个首屏体验问题继续优化：
- 提升首屏液晶数字的可读性；
- 让用户更容易理解不同风扇到底会带来什么风感；
- 优化工程模式入口，并增加更明显的体感反馈（观看视频的小伙伴可能发现了，有 20s 小七都在尝试进入隐藏模式，这就是这个优化点的由来）。
目前来说，这 3 个任务都在服务于同一个方向。所以，我们先设置 Goal。
项目状态的重新确认
其实，这个项目之前主要是在 Codex 客户端里开发的。这次为了方便观察执行过程和截图，我们回到 CLI，在同一个项目目录里继续。
先进入项目：
图 1：进入 Codex 模式
我们要继续开发旧项目时，小七不建议一上来就告诉 Codex"帮我优化一下"。这个需求本身比较模糊，而项目里又已经有不少现成逻辑，包括体感计算、风扇标定、酒店面板、工程模式和测试。如果 Codex 还没搞清楚这些内容，"优化一下"很容易顺手改到已经稳定的部分。
因此，在开始修修补补的优化工作之前，我让 Codex 整理了一份现有项目的 PRODUCT-FUNCTIONAL-SPEC.md。第一步，我们先让它恢复项目现场：
图 2：让 Codex 了解现有实现
这一步有点像重新接手一个做了一半的项目。代码告诉 Codex 现在是怎么实现的，产品文档则告诉它哪些设计是有意为之。
比如「隔屏吹风」里的那些夸张换算可以很好玩，但底层物理数字不能随便改；酒店面板和工程模式共享状态；体感和能耗计算也已经有对应测试。
这些都是后面 Goal 的边界。
给整个优化阶段设置 Goal
确认完现状：
图 3：Codex 了解完现状之后的返回图
我们就可以正式设置 /goal 了。这次我没有写：
/goal 继续优化隔屏吹风这样的目标信息太少。上面提到过，Codex 知道你要"优化"，却不知道优化到什么程度，也不知道哪些东西已经稳定，这样不利于它交付一个好结果。所以，最后给它的需求是这样的：
图 4：输入 /goal 后 Codex 的 Goal 状态
这个 Goal 里主要放了几类信息。第一类是当前基线 。项目已经有酒店面板、工程模式和计算系统，所以后面的任务是在现有产品上继续打磨。第二类是这一阶段真正想改善的东西 。这里没有写具体哪个按钮改成什么颜色，而是把目标放在可理解性、可读性和风感反馈上。第三类是不能随便碰的边界 。尤其是 physics 里的计算、风扇标定和已经固定下来的产品口径。第四类是完成方式。每轮都先规划，再修改，再验证。
接下来，我们就看看这个 Goal 会怎样带着 Codex 继续推进项目。
Goal 设置后，Codex 直接开始干活了
原本按照前面的设想，我准备先从最直观的问题开始，再用 /plan 处理酒店面板液晶数显的可读性。
当前酒店面板用了类似真实空调控制器的液晶屏设计。这个方向我挺喜欢，但实际使用时，"实际 / 体感"这一侧的数字有点暗。尤其是七段数码管还有未点亮的数字段，真正亮起的数字和背景之间层级不够明显。
图 5：项目现有面板
所以，我原本已经准备好了第一条 /plan：
/plan 根据当前 Goal，先处理酒店面板液晶数显的可读性问题。
当前问题：
设定温度比较清楚，但"实际 / 体感"数字和液晶背景的对比度偏低，用户需要仔细看才能分辨。
请先检查当前数显的组件、字体、颜色、未点亮数字段和相关样式。
要求：
1. 保留现在的液晶屏和七段数码管视觉；
2. 重点提高实际体感温度的可读性；
3. 不要把整个液晶屏简单改成高亮样式；
4. 不要修改任何体感计算；
5. 同时检查桌面端和现有响应式布局。
先给出问题原因、计划修改的文件、视觉调整方案和验证方式，不要修改代码。但这里出现了一个和我预想不太一样的情况。这条 /plan 我还没来得及输入，Codex 已经根据刚才设置的 Goal 开始工作了。 
图 6：Codex 开始修改代码
从执行过程里可以看到，它已经开始读取相关代码、修改文件，并继续运行 TypeScript 检查、Lint 和测试。在这一轮中，Codex 调整了液晶数显的字号，把原来的"实际 / 体感"改成了更直接的"当前体感"，同时还修改了与首屏交互有关的代码和测试。
现在，你可以直观地感受到 Codex/goal这个命令的主动性了：它不会等你 Plan 1、Plan 2 ......都拟定好，再一个个接着完成。一旦你设置了目标，它就会立马行动。
只要目标足够明确，Codex 会直接围绕这个 Goal 开始推进。 这也意味着，/goal 写得越具体，Codex 后续自主推进的边界就越清楚。
所以这次真正发生的流程更接近：
Goal
明确整个优化阶段
↓
Codex 自己分析项目
↓
开始修改
↓
运行检查和测试
↓
持续向 Goal 推进这也是为什么刚才的 Goal 不能写得太随意。如果我只写：
/goal 帮我继续优化隔屏吹风Codex 同样可能直接开始工作，但我们并没有告诉它哪些地方可以动、哪些计算不能碰，也没有给出完成标准。
前面 Goal 里写进去的项目基线、四个优化方向、禁止修改的内容和验证要求，这时候才真正开始发挥作用。
先看看 Goal 到底做了什么
既然 Codex 已经开始执行，我们就先让这一轮跑完。
在 Codex 执行的过程中可以看到，它并没有只盯着其中一个界面细节，而是在围绕整个 Goal 检查首屏相关实现。任务完成后，我们来运行下 /diff 看看：
图 7：Goal 执行后的 diff
我们来检查两件事。第一，看它实际改了哪些文件。第二，看这些修改有没有越过 Goal 里提前划定的边界，比如有没有顺手修改 physics 里的体感公式、风扇标定或者其他已经稳定的产品逻辑。
然后再回到浏览器里看实际效果。
图 8：Goal 修改后的首屏，效果并不明显，而且把面板拉高了；
用 Plan 收住这一轮修改
Goal 确实主动把任务往前推了，但是你也看到上面效果了：不合格，返工！
原先的问题没解决，还引入了一个新的问题------为了让用户更容易理解风扇，Codex 在面板底部新增了一段风感说明；模式键附近也补充了操作提示。信息确实更多了，但整个酒店面板也被向下撑高，原本一个桌面屏幕可以完整看到的内容，现在需要继续往下滚。
也就是说，这轮 Goal 虽然完成了一部分需求，但最终效果还有继续收敛的空间。这时候，我们再来用 /plan。
前面 Goal 已经让 Codex 做过一轮真实修改，所以现在的 Plan 不需要重新规划整个项目。我们只解决当前页面上已经暴露出来的问题。
直接输入：
图 9：Codex 返回的 Plan
这次 Plan 的作用就很明确了：先看清上一轮哪里改得不合适，再决定哪些内容保留、哪些需要收回来。
Plan 给出之后，Codex 还会再确认一次是否按照这份方案实施。这里我们先快速检查下修改范围和验证方式，确认没有继续扩大任务，就可以选择让它继续实施计划：
图 10：确认实施 Plan
确认后，Codex 会退出 Plan mode，按照刚才确定的方案开始修改代码。这一轮里，它主要做了几件事：提高"当前体感"数码管的对比度，压缩新增的风扇说明，把风感反馈重新收进现有区域，同时收紧面板的纵向空间。
图 11：Codex 执行 Plan
修改完成后，再看一次 /diff ：
图 12：Plan 执行后的 diff
最后回到浏览器检查实际效果。这里重点看三个地方：右侧"当前体感"是否更容易辨认；风扇信息有没有保留下来，同时减少重复说明；酒店面板能不能重新完整显示在桌面首屏里。
图 13：Plan 后的面板，UI 并没有改善
虽然这轮优化没能如期实现，但这次实际跑下来，Goal 和 Plan 的分工也清楚了很多。
Goal 更像整个阶段的持续目标。目标足够明确时，Codex 会直接围绕它往前推进。Plan 更适合放在具体节点上，当实际结果和预期还有偏差时，先让 Codex 停下来分析当前修改，再把下一轮范围、方案和验收条件收紧。
这次的流程最后变成了：
Goal
明确整个阶段要改善什么
↓
Codex 主动推进
↓
人工检查实际结果
↓
Plan
收窄下一轮修改范围
↓
确认方案
↓
执行 + 验证对于这种已经开发了一段时间、还要继续迭代的旧项目来说，这种组合会比较实用。Goal 负责让 Codex 知道项目接下来要往哪里走，Plan 则帮我们在关键节点重新控制修改范围。
文末吹个风
当然，项目没有停在这轮实践这里。
后面小七又继续处理了数显、风扇反馈、工程模式入口和页面细节，也修掉了这一轮修改过程中出现的一些回归问题。
你可以调调空调温度、换几个不同的风扇，再去找一下那个"酒店不希望你看到"的工程模式。
到这里，这次 Codex 长任务实践也就结束了。
从设置 Goal、让 Codex 主动推进，到人工检查实际结果，再用 Plan 收窄修改范围，这次实践至少说明了一件事：长任务交给 Agent 之后，我们可以把方向交给 Goal，把阶段性的控制交给 Plan，同时还得自己看最终结果有没有真的变好。
项目可以继续往下做，但每一轮要做什么，依然可以很清楚。