AI编程实战9：用 Codex 把一段重复 UI 抽成组件

大家好呀，我是 Lazy熊。

前面我们已经练过一些很小的 AI 编程任务。

如果你还没有开始相关的ai编程工具，可以通过LetAiCode的API快速开始。

这次我们讲一个很适合新手实战的问题：

怎么用 Codex 把一段重复 UI 抽成组件，并且尽量不翻车。

一、先说结论：不要一上来就让 Codex 直接动手

很多新手会直接说：

这句话不是完全不能用。

但它太粗了。

因为 Codex 还不知道：

具体要处理的是哪个页面或文件
当前项目里有没有现成写法可以复用
哪些地方能改，哪些地方不能改
这个任务做到什么程度算完成
改完之后应该怎么验收

如果这些不说清楚，Codex 就会自己猜。

而 AI 一旦开始猜，新手就很容易遇到几种情况：

它改到了相似但不是目标的位置
它顺手改了无关样式或结构
它把一个小任务做成了大改动
它看起来完成了，但关键场景没通过
它说改完了，你却不知道怎么验收

所以这类任务最稳的顺序是：

先让 Codex 只读不改
让它定位相关文件和现有逻辑
让它给出最小方案
你确认后再让它修改
修改后先看改动范围
最后按清单验收

说白了就是一句话：

任务可以小，但流程要完整。

二、第一步：先描述目标或现象

你要先把任务说清楚。

比如这个任务的核心场景是：

页面里有几段长得很像的卡片、列表项、信息块或操作区域。

不要只写一句"帮我处理一下"。

更稳的写法是：

bash 复制代码

我想让你帮我把一段重复 UI 抽成组件。

请先不要修改代码。

请先帮我确认：
1. 这个任务涉及哪些页面或组件
2. 相关文件可能在哪里
3. 当前项目里有没有类似实现可以参考
4. 这个任务的最小改动方案是什么
5. 哪些地方不应该被改动

这一步的目标不是马上得到代码。

而是先确认 Codex 有没有理解任务。

新手最怕的不是 Codex 不会写。

而是它一开始就理解偏了。

一旦方向偏了，后面写得越多，返工越多。

所以先让它复述和定位，是非常值得的。

三、第二步：让 Codex 定位相关文件

接下来要让 Codex 找位置。

这个任务最需要先看的通常是：

重复片段、相同部分、不同部分、组件 props、替换位置。

你可以这样问：

bash 复制代码

请先定位和这个任务最相关的文件。

请说明：
1. 你找到了哪些候选文件
2. 最可能需要修改的是哪个文件
3. 为什么判断它和本任务相关
4. 当前已有逻辑是怎么工作的
5. 如果要实现这个任务，最小修改入口在哪里

先不要修改代码。

这一段非常适合收藏。

因为它适用于很多 AI 编程任务。

你不是让 Codex 直接开改，

而是让它先把项目里和任务相关的部分找出来。

这样你就能先判断：

它找的是不是对的地方。

如果它找错了，你可以马上纠正。

不要等它改完一堆文件之后才发现方向错了。

四、第三步：限制改动范围

等 Codex 找到相关文件后，不要马上让它自由发挥。

你要继续给边界。

这个任务建议这样限制：

bash 复制代码

请按最小改动完成这个任务。

限制：
1. 只抽确认过的重复 UI，不改变视觉效果，不改变业务逻辑，不做过度抽象
2. 如果你认为必须扩大改动范围，请先说明原因
3. 在我确认前，不要直接执行大改
4. 修改完成后，列出实际修改文件
5. 不要做和本任务无关的优化

这一步非常关键。

因为 Codex 很容易"好心做多"。

它可能觉得某段代码可以顺手优化，某个组件可以顺手重构，某个样式可以顺手调整。

但新手阶段最重要的不是让它做更多。

而是让它：

只做该做的。

尤其是实战任务，越要控制范围。

范围一大，你就很难验收。

五、第四步：修改完成后先看改动范围

Codex 改完之后，第一件事不是看它的总结。

而是先问它改了哪里：

bash 复制代码

请列出本次实际修改的文件。

请说明：
1. 每个文件为什么需要修改
2. 每个文件具体改了什么
3. 是否存在和本任务无关的改动
4. 是否修改了公共组件、接口、全局样式或配置
5. 如果有额外改动，是否可以回退

这一步能帮你判断风险。

如果只是一个小任务，理论上改动范围应该比较小。

如果它动了一堆无关文件，就要先停下来。

你可以继续追问：

bash 复制代码

这个任务本来只需要处理【重复 UI】。
请解释为什么需要修改这些额外文件。
如果不是必须，请给出回到最小改动的方案。

新手一定要养成这个习惯：

先看改动范围，再看功能效果。

因为改动范围不合理，后面就算效果看起来对，也可能埋下风险。

六、第五步：按场景验收

这个任务完成后，至少要验这些场景：

页面视觉是否一致、交互是否一致、重复代码是否减少、props 是否清晰。

你可以让 Codex 生成验收清单：

bash 复制代码

请给出这次【重复 UI】任务的验收步骤。

请包括：
1. 正常流程怎么验证
2. 边界情况怎么验证
3. 哪些旧功能可能受影响
4. 如果结果不符合预期，优先排查哪里
5. 本次修改最大的风险点是什么

不要只验最顺利的情况。

真实项目里，很多问题都出在边界场景。

所以你要让 Codex 帮你把验收拆开。

如果它只说"打开页面看效果"，这个验收就太粗了。

你要继续要求它说清楚：

打开哪个页面
做什么操作
预期看到什么
哪些情况算失败
如果失败先查哪里

这才是对新手真正有用的验收。

七、如果结果不对，先暂停，不要继续加需求

很多新手发现 Codex 改得不对，会继续追加一堆解释。

比如：

"不是这个意思。"

"你再看看。"

"顺便把这里也改了。"

这样很容易越聊越乱。

更稳的是先暂停。

你可以复制这张跑偏处理卡片：

bash 复制代码

先暂停，不要继续修改代码。

当前结果和我的预期不一致。

请先帮我复盘：
1. 我的原始目标是什么
2. 你刚才实际修改了哪些文件
3. 哪一步可能理解偏了
4. 哪些改动应该保留
5. 哪些改动应该回退
6. 下一步最小修复方案是什么

先给分析，不要直接继续改。

这张卡片很重要。

因为 AI 编程里，跑偏不可怕。

可怕的是跑偏后继续加需求。

你要先把上下文拉回来。

八、收藏版核心 Prompt

如果你想直接用，可以复制这一整段：

bash 复制代码

我想让你帮我把一段重复 UI 抽成组件。

请先不要修改代码。

请按下面流程处理：
1. 先理解我的目标
2. 定位相关页面、组件或配置文件
3. 说明当前已有逻辑是怎么工作的
4. 给出最小改动方案
5. 明确哪些文件需要修改
6. 等我确认后再开始修改

限制：
1. 只抽确认过的重复 UI，不改变视觉效果，不改变业务逻辑，不做过度抽象
2. 不做和本任务无关的优化
3. 不引入新依赖
4. 不修改无关文件
5. 如果必须扩大范围，请先说明原因

修改完成后，请补充：
1. 实际修改文件列表
2. 每个文件改了什么
3. 正常流程验收步骤
4. 边界情况验收步骤
5. 可能影响的旧功能
6. 如果验收失败，优先排查哪里

这段就是这篇最值得收藏的部分。

以后你换成类似任务，也可以继续套这个结构。