在先前的 Codex 实践中，我们已经跑过 CLI、读过开源项目，也用 `/status`、`/diff`、`/review`、`/plan` 等 Slash Command 管理过一次完整的开发过程。

到了这一篇，我们来做一个时间更长的任务。

最近，小七一直在用 Codex 做一个叫 `huhu-airConditioner` 的小项目，中文名叫「隔屏吹风」。做这个项目的原因是有一天，小七在空调房里开着 28 度的空调吹风扇，被冻得瑟瑟发抖，于是萌生了个想法：能不能把风扇、空调、房间环境和人体体感全部算出来？

现在，它已经可以正常运行了。

在这个页面上，你可以调节空调温度、风量和模式，也可以选择不同类型的风扇。页面会根据当前的输入信息，来计算风速、体感温度等结果。当然，小七还弄了个小黑屋——进入隐藏的工程模式，还能继续调整房间、湿度、衣着、距离等参数，查看空调与风扇组合的功耗，最重要的是，你可以知道怎么搭配会更省电！守住钱包很重要。

其实，这个隔屏吹风做到这里，基本上是成型了。接下来，小七带你进入另一种开发状态：**基础功能已经有了，但产品还需要一轮一轮继续优化。**

正好用来讲解本次 Codex 实践的`/goal` 和 `/plan`部分。

## 长任务里的 Goal 与 Plan

之前介绍 Slash Command 时，我们简单用过 `/goal` 和 `/plan`，没看过实践 vol.03 的小伙伴可以阅读这篇：https://mp.weixin.qq.com/s/dCd7miBce5T5hpQF6JwyVw

如果只看名字， `/goal` 和 `/plan`两者好像都有一点“先告诉 Codex 准备做什么”的意思，但放到持续迭代的项目里，它们的职责其实很好区分。一开始，小七设想的流程是这样的：

```Plain
Goal
整个阶段最终想做到什么
    ↓
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
```

![](https://developer.qcloudimg.com/http-save/yehe-12464096/2da5c844870b613df83ca076437a0873.png)

图 1：进入 Codex 模式

我们要继续开发旧项目时，小七不建议一上来就告诉 Codex“帮我优化一下”。这个需求本身比较模糊，而项目里又已经有不少现成逻辑，包括体感计算、风扇标定、酒店面板、工程模式和测试。如果 Codex 还没搞清楚这些内容，“优化一下”很容易顺手改到已经稳定的部分。

因此，在开始修修补补的优化工作之前，我让 Codex 整理了一份现有项目的 `PRODUCT-FUNCTIONAL-SPEC.md`。第一步，我们先让它恢复项目现场：

```Plain
请先阅读 PRODUCT-FUNCTIONAL-SPEC.md，并结合当前项目代码了解 huhu-airConditioner 的现有状态。

请告诉我：

1. 当前产品已经实现了哪些核心体验；
2. 酒店面板和工程模式分别承担什么作用；
3. 当前哪些产品行为和计算口径不能随意修改；
4. 如果接下来主要优化首屏体验，最需要注意哪些现有约束。

先只做分析，不要修改任何文件。
```

![](https://developer.qcloudimg.com/http-save/yehe-12464096/9ebbda04390fae8b6cf623d9b72cfd7c.png)

图 2：让 Codex 了解现有实现

这一步有点像重新接手一个做了一半的项目。代码告诉 Codex 现在是怎么实现的，产品文档则告诉它哪些设计是有意为之。

比如「隔屏吹风」里的那些夸张换算可以很好玩，但底层物理数字不能随便改；酒店面板和工程模式共享状态；体感和能耗计算也已经有对应测试。

这些都是后面 Goal 的边界。

## 给整个优化阶段设置 Goal

确认完现状：

![](https://developer.qcloudimg.com/http-save/yehe-12464096/084e07d4ddda9bff1962e7e99abd689d.png)

图 3：Codex 了解完现状之后的返回图

我们就可以正式设置 `/goal` 了。这次我没有写：

```Plain
/goal 继续优化隔屏吹风
```

这样的目标信息太少。上面提到过，Codex 知道你要“优化”，却不知道优化到什么程度，也不知道哪些东西已经稳定，这样不利于它交付一个好结果。所以，最后给它的需求是这样的：

```Plain
/goal 继续完善 huhu-airConditioner「隔屏吹风」项目。

当前产品已经完成酒店空调面板、风扇与体感计算、工程模式、等体感寻优和基础感官反馈。

本阶段目标是提升首屏的可理解性、可读性和风感反馈，让第一次打开页面的用户更容易看清关键数字、理解不同风扇带来的体感差异，并更自然地发现工程模式。

本阶段重点：
1. 提高液晶数显区域的可读性，尤其是实际体感温度；
2. 降低风扇类型选择区的理解成本，让用户知道不同风扇对应什么风感；
3. 增强首屏对当前体感和风力状态的反馈；
4. 改善进入工程模式的交互体验。

保持现有产品定位、酒店面板整体视觉语言和核心功能稳定。

不要静默修改 physics 计算公式、风扇标定值、默认参数、红绿灯计算口径和固定收尾文案；不要为了本轮优化重构无关模块。

每个阶段先分析影响范围和方案，再做必要修改。完成后运行现有测试，并说明修改文件、验证结果、剩余问题和下一步建议。
```

![](https://developer.qcloudimg.com/http-save/yehe-12464096/a6f0cf9ec165d9dbfca062933aad9405.png)

图 4：输入 /goal 后 Codex 的 Goal 状态

这个 Goal 里主要放了几类信息。第一类是**当前基线**。项目已经有酒店面板、工程模式和计算系统，所以后面的任务是在现有产品上继续打磨。第二类是**这一阶段真正想改善的东西**。这里没有写具体哪个按钮改成什么颜色，而是把目标放在可理解性、可读性和风感反馈上。第三类是**不能随便碰的边界**。尤其是 `physics` 里的计算、风扇标定和已经固定下来的产品口径。第四类是**完成方式**。每轮都先规划，再修改，再验证。

接下来，我们就看看这个 Goal 会怎样带着 Codex 继续推进项目。

## Goal 设置后，Codex 直接开始干活了

原本按照前面的设想，我准备先从最直观的问题开始，再用 `/plan` 处理酒店面板液晶数显的可读性。

当前酒店面板用了类似真实空调控制器的液晶屏设计。这个方向我挺喜欢，但实际使用时，“实际 / 体感”这一侧的数字有点暗。尤其是七段数码管还有未点亮的数字段，真正亮起的数字和背景之间层级不够明显。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/d48b48e7415f4a7678a461f18705bfda.png)

图 5：项目现有面板

所以，我原本已经准备好了第一条 `/plan`：

```Plain
/plan 根据当前 Goal，先处理酒店面板液晶数显的可读性问题。

当前问题：
设定温度比较清楚，但“实际 / 体感”数字和液晶背景的对比度偏低，用户需要仔细看才能分辨。

请先检查当前数显的组件、字体、颜色、未点亮数字段和相关样式。

要求：
1. 保留现在的液晶屏和七段数码管视觉；
2. 重点提高实际体感温度的可读性；
3. 不要把整个液晶屏简单改成高亮样式；
4. 不要修改任何体感计算；
5. 同时检查桌面端和现有响应式布局。

先给出问题原因、计划修改的文件、视觉调整方案和验证方式，不要修改代码。
```

但这里出现了一个和我预想不太一样的情况。**这条** **`/plan`** **我还没来得及输入，Codex 已经根据刚才设置的 Goal 开始工作了。**

![](https://developer.qcloudimg.com/http-save/yehe-12464096/a2f0d2f5de8deba4fa2f3fc84eff30d9.png)

图 6：Codex 开始修改代码

从执行过程里可以看到，它已经开始读取相关代码、修改文件，并继续运行 TypeScript 检查、Lint 和测试。在这一轮中，Codex 调整了液晶数显的字号，把原来的“实际 / 体感”改成了更直接的“当前体感”，同时还修改了与首屏交互有关的代码和测试。

现在，你可以直观地感受到 Codex`/goal`这个命令的主动性了：它不会等你 Plan 1、Plan 2 ……都拟定好，再一个个接着完成。一旦你设置了目标，它就会立马行动。

**只要目标足够明确，Codex 会直接围绕这个 Goal 开始推进。**这也意味着，`/goal` 写得越具体，Codex 后续自主推进的边界就越清楚。

所以这次真正发生的流程更接近：

```Plain
Goal
明确整个优化阶段
        ↓
Codex 自己分析项目
        ↓
开始修改
        ↓
运行检查和测试
        ↓
持续向 Goal 推进
```

这也是为什么刚才的 Goal 不能写得太随意。如果我只写：

```Plain
/goal 帮我继续优化隔屏吹风
```

Codex 同样可能直接开始工作，但我们并没有告诉它哪些地方可以动、哪些计算不能碰，也没有给出完成标准。

前面 Goal 里写进去的项目基线、四个优化方向、禁止修改的内容和验证要求，这时候才真正开始发挥作用。

## 先看看 Goal 到底做了什么

既然 Codex 已经开始执行，我们就先让这一轮跑完。

在 Codex 执行的过程中可以看到，它并没有只盯着其中一个界面细节，而是在围绕整个 Goal 检查首屏相关实现。任务完成后，我们来运行下 `/diff` 看看：

![](https://developer.qcloudimg.com/http-save/yehe-12464096/e1883dda2b007be029027a819ca184b5.png)

图 7：Goal 执行后的 diff

我们来检查两件事。第一，看它实际改了哪些文件。第二，看这些修改有没有越过 Goal 里提前划定的边界，比如有没有顺手修改 `physics` 里的体感公式、风扇标定或者其他已经稳定的产品逻辑。

然后再回到浏览器里看实际效果。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/9bc82722742a321fc734dbde0c2608d9.png)

图 8：Goal 修改后的首屏，效果并不明显，而且把面板拉高了；

## 用 Plan 收住这一轮修改

Goal 确实主动把任务往前推了，但是你也看到上面效果了：不合格，返工！

原先的问题没解决，还引入了一个新的问题——为了让用户更容易理解风扇，Codex 在面板底部新增了一段风感说明；模式键附近也补充了操作提示。信息确实更多了，但整个酒店面板也被向下撑高，原本一个桌面屏幕可以完整看到的内容，现在需要继续往下滚。

也就是说，这轮 Goal 虽然完成了一部分需求，但最终效果还有继续收敛的空间。这时候，我们再来用 `/plan`。

前面 Goal 已经让 Codex 做过一轮真实修改，所以现在的 Plan 不需要重新规划整个项目。我们只解决当前页面上已经暴露出来的问题。

直接输入：

```Plain
/plan 请根据当前 Goal 和刚刚完成的修改，对首屏做一轮收敛优化。

目前实际效果还有几个问题：

1. “当前体感”的七段数码管依然不够清晰。主要问题是亮起数字段与未点亮数字段之间的对比度不足，单纯放大字号没有明显解决可读性；
2. 新增的风扇说明和模式操作提示占用了较多纵向空间，导致酒店面板整体高度增加，桌面首屏无法完整展示；
3. 风扇说明与现有“当前风力”区域存在一定信息重复。

这一轮目标：

- 明显提高“当前体感”数显的对比度，同时保留七段液晶屏的视觉；
- 恢复桌面端首屏完整展示酒店面板的布局；
- 风扇反馈尽量收进现有“当前风力”区域，用更短的信息表达风感等级和当前风速；
- 压缩重复的模式操作提示，不新增大块说明区域；
- 保持现有计算、风扇标定、酒店面板视觉语言和其他稳定功能不变。

请先检查当前 diff，并告诉我：

1. 哪些修改导致了页面高度增加；
2. 数码管对比度准备如何调整；
3. 哪些新增信息准备保留、压缩或移除；
4. 预计修改哪些文件；
5. 如何验证 1440×900 桌面视口下酒店面板可以完整显示。

先只给计划，不修改代码。
```

![](https://developer.qcloudimg.com/http-save/yehe-12464096/38905998012e171047022f5eaf77827b.png)

图 9：Codex 返回的 Plan

这次 Plan 的作用就很明确了：先看清上一轮哪里改得不合适，再决定哪些内容保留、哪些需要收回来。

Plan 给出之后，Codex 还会再确认一次是否按照这份方案实施。这里我们先快速检查下修改范围和验证方式，确认没有继续扩大任务，就可以选择让它继续实施计划：

![](https://developer.qcloudimg.com/http-save/yehe-12464096/1bdfd5d14c2027fbad8127f6e09f99e3.png)

图 10：确认实施 Plan

确认后，Codex 会退出 Plan mode，按照刚才确定的方案开始修改代码。这一轮里，它主要做了几件事：提高“当前体感”数码管的对比度，压缩新增的风扇说明，把风感反馈重新收进现有区域，同时收紧面板的纵向空间。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/13cd3ac5acbae8bceb4e4a169f013c11.png)

图 11：Codex 执行 Plan

修改完成后，再看一次 `/diff` ：

![](https://developer.qcloudimg.com/http-save/yehe-12464096/791797afe2b9c131116fb93cc723b170.png)

图 12：Plan 执行后的 diff

最后回到浏览器检查实际效果。这里重点看三个地方：右侧“当前体感”是否更容易辨认；风扇信息有没有保留下来，同时减少重复说明；酒店面板能不能重新完整显示在桌面首屏里。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/e9aa7001cebf96b1b2e30815ee83db98.png)

图 13：Plan 后的面板，UI 并没有改善

虽然这轮优化没能如期实现，但这次实际跑下来，`Goal` 和 `Plan` 的分工也清楚了很多。

`Goal` 更像整个阶段的持续目标。目标足够明确时，Codex 会直接围绕它往前推进。`Plan` 更适合放在具体节点上，当实际结果和预期还有偏差时，先让 Codex 停下来分析当前修改，再把下一轮范围、方案和验收条件收紧。

这次的流程最后变成了：

```Plain
Goal
明确整个阶段要改善什么
    ↓
Codex 主动推进
    ↓
人工检查实际结果
    ↓
Plan
收窄下一轮修改范围
    ↓
确认方案
    ↓
执行 + 验证
```

对于这种已经开发了一段时间、还要继续迭代的旧项目来说，这种组合会比较实用。Goal 负责让 Codex 知道项目接下来要往哪里走，Plan 则帮我们在关键节点重新控制修改范围。

## 文末吹个风

当然，项目没有停在这轮实践这里。

后面小七又继续处理了数显、风扇反馈、工程模式入口和页面细节，也修掉了这一轮修改过程中出现的一些回归问题。

最终，`huhu-airConditioner` 变成了现在这个样子：https://019fda118a9574d2a955fb494ce55fe4.ap-northeast-2.c9b2d4.cloud/ （见证奇迹的时候）

你可以调调空调温度、换几个不同的风扇，再去找一下那个“酒店不希望你看到”的工程模式。

到这里，这次 Codex 长任务实践也就结束了。

从设置 Goal、让 Codex 主动推进，到人工检查实际结果，再用 Plan 收窄修改范围，这次实践至少说明了一件事：长任务交给 Agent 之后，我们可以把方向交给 Goal，把阶段性的控制交给 Plan，同时还得自己看最终结果有没有真的变好。

**项目可以继续往下做，但每一轮要做什么，依然可以很清楚。**

在先前的 Codex 实践中，我们已经跑过 CLI、读过开源项目，也用 /status、/diff、/review、/plan 等 Slash Command 管理过一次完整的开发过程。

Codex 实践系列 Vol.04：用 Goal 和 Plan 管住一个长任务

项目可以继续往下做，但每一轮要做什么，依然可以很清楚。

编程语言

开发工具

职业发展

Codex长任务实践展示Goal与Plan协同用法：为「隔屏吹风」项目设置明确目标后，Agent主动推进首屏优化，人工检查发现面板增高与数显对比度不足问题，再用Plan收敛修改范围。通过「目标驱动+阶段控制」模式，实现可验证的迭代开发，兼顾开发效率与产品稳定性。

代码解释

TypeScript

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Codex 实践系列 Vol.04：用 Goal 和 Plan 管住一个长任务-腾讯云开发者社区-腾讯云

Codex 实践系列 Vol.04：用 Goal 和 Plan 管住一个长任务

Codex 实践系列 Vol.04：用 Goal 和 Plan 管住一个长任务

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐