什么
↓
Plan 01
这一轮解决什么
↓
执行 + 验证
↓
Plan 02
下一轮解决什么
↓
执行 + 验证
↓
Plan 03
继续推进
↓
最终回到 Goal 检查
这样分工就很清楚了，`Goal` 管的是一段时间里的持续目标；`Plan` 管的是当前这一阶段准备怎么完成。
OpenAI 官方现在把 Follow a goal 定义成适合长时间工作的 Codex 用法：给 Codex 一个持续目标，让它在多轮工作中朝着可以验证的结果推进。
对于 `huhu-airConditioner` 来说，我们不会给 Codex 一个需求，然后让它一次性把整个产品重新做一遍。
这次准备围绕几个首屏体验问题继续优化：
1. 提升首屏液晶数字的可读性；
2. 让用户更容易理解不同风扇到底会带来什么风感；
3. 优化工程模式入口，并增加更明显的体感反馈（观看视频的小伙伴可能发现了，有 20s 小七都在尝试进入隐藏模式，这就是这个优化点的由来）。
目前来说，这 3 个任务都在服务于同一个方向。所以，我们先设置 Goal。
## 项目状态的重新确认
其实，这个项目之前主要是在 Codex 客户端里开发的。这次为了方便观察执行过程和截图，我们回到 CLI，在同一个项目目录里继续。
先进入项目：
```Plain
cd huhu-airConditioner
codex
图 1：进入 Codex 模式
我们要继续开发旧项目时，小七不建议一上来就告诉 Codex“帮我优化一下”。这个需求本身比较模糊，而项目里又已经有不少现成逻辑，包括体感计算、风扇标定、酒店面板、工程模式和测试。如果 Codex 还没搞清楚这些内容，“优化一下”很容易顺手改到已经稳定的部分。
因此，在开始修修补补的优化工作之前，我让 Codex 整理了一份现有项目的 PRODUCT-FUNCTIONAL-SPEC.md。第一步，我们先让它恢复项目现场：
请先阅读 PRODUCT-FUNCTIONAL-SPEC.md，并结合当前项目代码了解 huhu-airConditioner 的现有状态。
请告诉我：
1. 当前产品已经实现了哪些核心体验；
2. 酒店面板和工程模式分别承担什么作用；
3. 当前哪些产品行为和计算口径不能随意修改；
4. 如果接下来主要优化首屏体验，最需要注意哪些现有约束。
先只做分析，不要修改任何文件。
图 2：让 Codex 了解现有实现
这一步有点像重新接手一个做了一半的项目。代码告诉 Codex 现在是怎么实现的，产品文档则告诉它哪些设计是有意为之。
比如「隔屏吹风」里的那些夸张换算可以很好玩，但底层物理数字不能随便改；酒店面板和工程模式共享状态；体感和能耗计算也已经有对应测试。
这些都是后面 Goal 的边界。
给整个优化阶段设置 Goal
确认完现状：
图 3：Codex 了解完现状之后的返回图
我们就可以正式设置 /goal 了。这次我没有写：
/goal 继续优化隔屏吹风
这样的目标信息太少。上面提到过，Codex 知道你要“优化”，却不知道优化到什么程度，也不知道哪些东西已经稳定，这样不利于它交付一个好结果。所以，最后给它的需求是这样的：
/goal 继续完善 huhu-airConditioner「隔屏吹风」项目。
当前产品已经完成酒店空调面板、风扇与体感计算、工程模式、等体感寻优和基础感官反馈。
本阶段目标是提升首屏的可理解性、可读性和风感反馈，让第一次打开页面的用户更容易看清关键数字、理解不同风扇带来的体感差异，并更自然地发现工程模式。
本阶段重点：
1. 提高液晶数显区域的可读性，尤其是实际体感温度；
2. 降低风扇类型选择区的理解成本，让用户知道不同风扇对应什么风感；
3. 增强首屏对当前体感和风力状态的反馈；
4. 改善进入工程模式的交互体验。
保持现有产品定位、酒店面板整体视觉语言和核心功能稳定。
不要静默修改 physics 计算公式、风扇标定值、默认参数、红绿灯计算口径和固定收尾文案；不要为了本轮优化重构无关模块。
每个阶段先分析影响范围和方案，再做必要修改。完成后运行现有测试，并说明修改文件、验证结果、剩余问题和下一步建议。
图 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 不需要重新规划整个项目。我们只解决当前页面上已经暴露出来的问题。
直接输入：
/plan 请根据当前 Goal 和刚刚完成的修改，对首屏做一轮收敛优化。
目前实际效果还有几个问题：
1. “当前体感”的七段数码管依然不够清晰。主要问题是亮起数字段与未点亮数字段之间的对比度不足，单纯放大字号没有明显解决可读性；
2. 新增的风扇说明和模式操作提示占用了较多纵向空间，导致酒店面板整体高度增加，桌面首屏无法完整展示；
3. 风扇说明与现有“当前风力”区域存在一定信息重复。
这一轮目标：
- 明显提高“当前体感”数显的对比度，同时保留七段液晶屏的视觉；
- 恢复桌面端首屏完整展示酒店面板的布局；
- 风扇反馈尽量收进现有“当前风力”区域，用更短的信息表达风感等级和当前风速；
- 压缩重复的模式操作提示，不新增大块说明区域；
- 保持现有计算、风扇标定、酒店面板视觉语言和其他稳定功能不变。
请先检查当前 diff，并告诉我：
1. 哪些修改导致了页面高度增加；
2. 数码管对比度准备如何调整；
3. 哪些新增信息准备保留、压缩或移除；
4. 预计修改哪些文件；
5. 如何验证 1440×900 桌面视口下酒店面板可以完整显示。
先只给计划，不修改代码。
图 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 则帮我们在关键节点重新控制修改范围。
文末吹个风
当然，项目没有停在这轮实践这里。
后面小七又继续处理了数显、风扇反馈、工程模式入口和页面细节，也修掉了这一轮修改过程中出现的一些回归问题。
最终，huhu-airConditioner 变成了现在这个样子。
你可以调调空调温度、换几个不同的风扇，再去找一下那个“酒店不希望你看到”的工程模式。
到这里，这次 Codex 长任务实践也就结束了。
从设置 Goal、让 Codex 主动推进，到人工检查实际结果，再用 Plan 收窄修改范围，这次实践至少说明了一件事：长任务交给 Agent 之后，我们可以把方向交给 Goal，把阶段性的控制交给 Plan，同时还得自己看最终结果有没有真的变好。
项目可以继续往下做，但每一轮要做什么，依然可以很清楚。
