项目回顾与常见问题排查

做完任务，回顾一下

上一节完成了 text-tools 的第一个里程碑。这一节回顾这次经历：哪里顺利？哪里卡壳？顺便把常见问题排查一遍。复盘，让下一次更快。

---

回顾这次任务

问自己三个问题：

1. 描述够清楚吗？ 它有没有因为我的描述含糊而跑偏？
2. 交互顺吗？ 我给的反馈有效吗？来回了几轮？
3. 验收到位吗？ 我有没有只信它、没自己验证？

诚实回答，下次就更好。

对照 text-tools：回顾我们「统计字数 + 大小写转换」那次——目标定得清吗？五段式用上了吗？最后是不是让 Codex 把真实输出打给你看了？把这些答完，就是一次有效复盘。

一个可复制的复盘提纲——直接套到 text-tools 上：

text-tools 第一次任务复盘
- 顺利：在沙箱建出工作区、五段式描述一次说清、tool.py 跑通了
- 卡壳：一开始忘记把成果同步到本地 / 中间跑偏过一次、来回改了两轮
- 原因：忘了沙箱要同步 / 反馈说得太模糊
- 下次改进：每次干完先同步、反馈带上「哪里错 + 要什么」

填一次，你就知道下次哪里能更快。

---

常见问题排查表

现象	可能原因	排查
任务没反应	模型配置/Key 问题	检查 model_id、api_key_env、Key 有没有额度
沙箱结果本地没有	忘了同步/导出	让它把成果同步到工作目录，确认本地有文件
产出跑偏	任务描述不清	回看描述，目标/输入/输出/约束补清楚
来回改很多轮	上下文没给足	一次给足相关代码、报错、约束
一直超时	网关/网络	确认没走境外代理，全程国内直连

给 text-tools 加功能时，这张表几乎覆盖了你九成的卡壳点。先对着表自查，多半能找到原因，不用瞎试。

---

排查的思路

遇到问题，别慌，按「先定位，再解决」：

1. 是「配置」问题？   → 查模型/Key/网关
2. 是「描述」问题？   → 查任务描述清不清楚
3. 是「交互」问题？   → 查反馈有没有给具体
4. 是「验收」问题？   → 查有没有自己验证

大部分问题，出在描述不清或忘了验收，而不是工具坏了。

一个可复制的排查话术——先让 Codex 自己报告状态，别急着让它乱改：

codex "text-tools 目前报错了，先把报错原文完整打印给我，再告诉我你判断是哪个环节（配置/描述/交互/验收）的问题，先别急着改"

先定位再解决，能避免「越改越乱」。

---

一个值得养成的习惯

每次完成任务后，花两分钟记一笔：

这次任务：
- 顺利的地方：
- 卡壳的地方 + 原因：
- 下次改进：

记下来，你的 Codex 使用水平就会稳定提升。

给 text-tools 做个简单的「项目日志」也行——每次加完功能，把「做了啥、踩了啥坑、下次注意啥」记进去。项目长大的同时，你的经验也在沉淀。

---

落地练习：给 text-tools 写一张「问题排查卡」

把这次的经验固化成一张你能反复用的排查卡：

1. 回想 text-tools 第一次任务里你踩过的至少一个问题（配置、描述、交互、验收都算）
2. 按「现象 → 原因 → 解法」把它写成一行，汇总成一张小表
3. 设想下一步加功能可能遇到的另一个问题，提前写进卡里

怎么判断做对了？——你手里有一张「下次遇到问题先看」的小卡，里面每条都是「现象 + 原因 + 解法」三件套，而不是泛泛的「注意排查」。

卡住了怎么办？ 想不起踩过坑？就照抄上面的排查表，把 text-tools 的常见项（同步成果、描述不清、忘了验收）写进去。不知道下一个坑？就先写「忘了同步成果」——它是出现率最高的一个。

---

常见坑：问题一出，就慌着反复重试，不定位

新手遇错最常见的反应：不管原因，反复重跑、反复重发指令，指望「多试几次就好了」——结果往往是越试越乱、浪费一堆 token。

正确的做法是先定位再解决：先弄清是哪一类问题（配置？描述？交互？验收？），再针对性处理。给 text-tools 排查时也一样——先让 Codex 把报错完整打给你，先判断环节，再动手改，而不是一上来就让它乱改一通。定位清楚，一次就能解决。

---

小结

1. 回顾三问：描述清吗？交互顺吗？验收到位吗？
2. 常见问题：没反应 / 结果没同步 / 跑偏 / 超时，逐项排查
3. 先定位再解决：配置 / 描述 / 交互 / 验收
4. 养成记录习惯，让水平稳定提升
5. 你已完成 text-tools 的第一个里程碑，并沉淀了一张排查卡

到这里，Codex 基础课结束，text-tools 的第一版已经在云端沙箱里跑起来了。下一门课进入进阶实战：多文件修改、代码审查、Git 工作流集成，继续把 text-tools 做大。