普通人 AI 实战手册

Appearance

14 · 四类日常工作流：探索、修 bug、重构、写测试 ​

真正用 Codex 做项目时，你每天做的事情大多逃不开四类：

  1. 探索：先看懂项目。
  2. 修 bug：找到问题并修掉。
  3. 重构：不改变功能，只整理结构。
  4. 写测试：让项目自己检查自己。

这一篇给你四套可复制流程。 不会编程也能照着问。

四类日常工作流

开始前先判断你属于哪一类 ​

不要一上来就说“帮我做一下”。 先把任务归类：

  1. 看不懂项目：探索。
  2. 功能坏了：修 bug。
  3. 能用但代码乱：重构。
  4. 想防止以后改坏：写测试。

一次只做一类。 混在一起，Codex 容易跑偏，你也不好验收。

先用一句话给任务分类 ​

开工前，先把你的任务写成下面其中一句：

text
我现在只是想看懂项目，不要修改文件。
text
我现在有一个明确 bug，需要先定位原因。
text
我现在想整理代码，但不能改变功能。
text
我现在想补一个最小测试，防止以后改坏。

如果你一句都套不上，说明任务还没想清楚。 先不要让 Codex 动手。

第一类：探索项目 ​

探索不是让 Codex 改代码。 探索是让它先读懂项目，再用普通话讲给你听。

适合场景：

  1. 你刚打开一个陌生项目。
  2. 你不知道从哪个文件开始。
  3. 你接手别人留下的代码。
  4. 你想知道某个功能在哪里。

可复制提示词：

text
请先探索当前项目，不要修改任何文件。
用小白能听懂的话告诉我：
1. 这个项目是做什么的
2. 主要目录分别负责什么
3. 启动或构建入口可能在哪里
4. 如果我要改【具体功能】，应该先看哪些文件

探索结束后，你要追问：

text
请给我一个下一步最小任务。
要求这个任务能在 30 分钟内验证结果。

第二类：修 bug ​

修 bug 不要一上来就让它改。 先让它复现和定位。

正确顺序：

  1. 描述现象。
  2. 给出你看到的错误信息。
  3. 让它先分析可能原因。
  4. 让它提出最小排查步骤。
  5. 确认后再修改。
  6. 修改后验证。

可复制提示词：

text
我遇到一个 bug。

现象：
【写你看到的问题】

错误信息：
【粘贴报错，没有就写“暂无”】

请先不要修改文件。
先告诉我：
1. 最可能的 3 个原因
2. 应该先看哪些文件
3. 最小排查步骤是什么

确认后再说：

text
请按最小方案修复。
限制：
1. 只修改和这个 bug 直接相关的文件
2. 不要重构无关代码
3. 修完后告诉我如何验证这个 bug 已经解决

第三类：重构 ​

重构的意思是：功能不变，只把代码整理得更清楚。

小白最容易犯的错是把重构说成“优化一下”。 这会让范围失控。

重构前必须说清楚：

  1. 不改变功能。
  2. 不改变页面效果。
  3. 不改变对外接口。
  4. 先做小范围。

可复制提示词：

text
请帮我做一次小范围重构。

目标：
让【文件或函数】更容易阅读。

限制：
1. 不改变现有功能
2. 不改变页面效果
3. 不新增依赖
4. 只修改这个文件

开始前，请先告诉我你准备怎么重构。
我确认后再动手。

重构后要问：

text
请说明这次重构前后功能是否一致。
如果有检查命令，请运行或告诉我如何运行。

第四类：写测试 ​

测试可以理解成：让项目自己检查自己。

小白不用一开始懂所有测试框架。 先知道测试解决什么问题： 以后改代码时，项目能自动提醒你哪里坏了。

可复制提示词：

text
请先查看当前项目是否已有测试。
不要新增文件。
告诉我：
1. 使用了什么测试工具
2. 测试文件通常放在哪里
3. 应该用什么命令运行测试

如果项目已有测试，再说：

text
请为【具体函数或功能】补一个最小测试。
要求：
1. 只覆盖一个明确行为
2. 不大改现有代码
3. 写完后运行对应测试
4. 说明这个测试验证了什么

如果项目没有测试，先不要让它一次搭完整体系。 你可以说：

text
当前项目好像没有测试。
请先告诉我最小引入测试的方案。
暂时不要安装依赖，也不要修改文件。

四类工作流怎么选 ​

你现在的状态应该用哪类
不知道项目怎么跑探索
页面或功能坏了修 bug
功能能用但代码乱重构
想防止以后改坏写测试

不要把四类混在一起。 一次只做一类。

小白最稳的总流程 ​

不管是哪类任务，都可以套这个节奏：

  1. 先读，不改。
  2. 先解释，再计划。
  3. 先缩小范围。
  4. 再执行修改。
  5. 看 diff。
  6. 做验证。
  7. 总结改动。

这套节奏看起来笨，但特别稳。

常见错误 ​

错误一：探索时就让它改

探索阶段只读。 先搞懂，再动手。

错误二：修 bug 时不贴错误信息

没有现象和报错，Codex 只能猜。

错误三：重构时改变功能

重构的底线就是功能不变。

错误四：测试写太大

一个测试先覆盖一个行为。 不要一上来测试整个系统。

检查清单 ​

开始前，确认你属于哪一类：

  • 我只是想看懂项目：探索。
  • 我看到明确问题：修 bug。
  • 我想整理代码但不改功能：重构。
  • 我想让项目自动检查：写测试。

执行后，确认：

  • 改动范围没有扩大。
  • Codex 解释了修改原因。
  • 有验证方法。
  • 结果能被你看懂。

小结 ​

Codex 不是只会“写代码”。 更重要的是帮你建立工作流。

先把探索、修 bug、重构、写测试这四类跑熟。 后面再学权限、安全、浏览器操作和高级功能，就不会乱。