AI编程用了几个月，我踩过的坑和真正好用的东西2

上篇写完之后，后台收到不少消息，大意都是"我也踩过这个坑"。

AI编程用了几个月，我踩过的坑和真正好用的东西

所以有了这篇续集。

这次较聚焦 Codex。不是那种"十大技巧"的合集，就是我自己用下来觉得真的有用的几件事——有的是配置层面的，有的是工作流层面的，还有一个跟打字都没关系。

一、先把 AGENTS.md 设好，不然记忆是假的

刚开始用 Codex 的时候，我以为它会记住我的偏好。

结果每次新开一个任务，它都像第一次见面一样——不知道我的项目用什么框架，不知道我不喜欢它自作主张改文件结构，不知道我的代码风格是什么。每次都要重新交代一遍，烦死了。

后来才搞清楚：Codex 本身没有跨会话的持久记忆。它的"记忆"靠的是你手动写的 AGENTS.md 文件。

AGENTS.md 是什么

简单说，就是一个给 AI 看的项目说明书。放在项目根目录，Codex 每次启动都会自动读取。你在里面写的东西，它每次都会遵守。

我自己的 AGENTS.md 大概长这样：

## 基础行为

- 默认使用中文回答，除非用户明确要求其他语言。
- 回答要简洁直接，避免不必要的铺垫和重复。
- 如果任务描述不清晰，先提问确认，再开始执行。
- 不要主动推测用户意图之外的需求，只做被要求的事。

## 安全边界

- 默认只读，不主动修改、删除任何文件，除非用户明确指示。
- 涉及不可逆操作（如删除、覆盖、调用外部 API 写入）前，必须先确认。
- 不在输出中打印任何密钥、Token 或敏感凭证。

## 工程规范

- 避免过度设计，只做任务明确要求或明显必要的改动，保持方案简洁。
- 不在未被要求的情况下添加功能、重构代码或进行额外优化。
- 不为未改动的代码添加注释、类型标注或文档字符串。
- 仅在逻辑不自明时添加注释。
- 不为不可能发生的场景添加错误处理或兜底逻辑。
- 不创建只使用一次的工具函数或抽象层。
- 确认无用的代码，直接删除，不留注释说明。

写完之后，Codex 的行为稳定了很多。它不再随手给我装一堆我不需要的包，也不会在我没说的情况下重构文件结构。

你如果是Codex app的话，就直接在设置 -> 个性化中填写对应的全局Agents.md，你也可以自行修改我上面的

还有一个功能很多人没开：记忆模式

Codex 有一个 --memory 选项，开启之后它会在对话过程中主动把重要信息写回 AGENTS.md。比如你说"以后这类组件都放在 /components/ui 下"，它会自动记录进去，下次就知道了。

不是所有版本都默认开启，可以在设置里找，或者启动时加参数。

这个功能开了之后，AGENTS.md 会慢慢变成一个真正活的文档，而不是你写一次就放在那里的静态说明。

二、/plan 和 /goal，先搞清楚它们解决的是什么问题

用 AI 写代码有一个让人抓狂的毛病：做到一半停下来问你"要继续吗？"

你说"重构 auth 模块跑通所有测试"，它改了三个函数，停下来报告："我已经改了这些，你想看一下吗？"你说看。看完它继续，再改一会儿，又停。一个本来二十分钟能搞定的事，被拽进来八次。

/plan 和 /goal 解决的就是这个，但方向不一样。

这两个都是cli的命令，如果你是codex app的话，在➕号处那里是有可以选择的。

1. 先说 /plan：动手前先想清楚

/plan 是让 Codex 在动手之前先列出执行方案。

输入 /plan 实现用户登录功能，它不会立刻开始写代码，而是先给你列出：要改哪些文件、分几步走、每步做什么。你看完觉得没问题，再让它执行。

听起来多了一步，实际上省了很多时间。AI 没有计划直接写，很容易改了 A 影响 B，回头改 B 又影响 C。有了计划，这些问题在动手前就能发现。

我现在的习惯是：任何超过两个文件的改动，都先 /plan 一下。

2. 再说 /goal：给目标，让它自己跑完

/goal 解决的是另一个问题——不是"方向对不对"，而是"能不能跑完不来烦我"。

用法是这样的：

1 2	/goal 重构 auth 模块跑通所有测试直到测试成功率100% /goal 先定义文章AI味指标1-10分，给我文章打分并改进，直到分数低于2分

然后它就开始自己跑——读文件、改文件、跑测试、自检完没完。这一轮没完，自动安排下一轮，再下一轮，直到自检通过才停。

这个过程可以跑几十分钟，不需要你一直盯着。

3. 目标怎么写很关键

"优化性能"这种目标它不知道什么时候算完。要写成有明确验收标准的：

❌ /goal 优化首页性能
✅ /goal 首页加载时间从 3s 降到 1.5s 以内，Lighthouse 性能分 ≥ 85

目标里没有验收标准，它要么跑偏，要么随便标个"完成"就停了。

为什么它不会随便说"完成了"

这是 /goal 设计里我觉得最有意思的地方。

Codex 的源码里有一段专门的 prompt，大意是：在判断目标完成之前，必须把目标拆成具体交付物，每一项找到真实证据（文件、测试结果、命令输出），逐项核对。 而且有一条规则专门写着：

把不确定性当作"尚未完成"。

就这一句话，把模型的默认值从"差不多了吧"改成了"没确认就是没完"。

还有一条：

不要仅仅因为预算即将耗尽，或因为你准备停止工作，就将目标标记为完成。

为什么要专门写这条？因为 OpenAI 实测发现，token 快用完的时候，模型有一个稳定的偷懒模式——反正要停了，标个完成算了。这条规则就是专门堵这个漏洞的。

4. Claude Code 也能用 /goal

Codex 的 /goal 目前还在内测，需要命令行手动开启。Claude Code 有个类似的 Outcomes 功能也在内测。

但有人已经把 Codex 的 /goal 逻辑复刻成了一个 Claude Code skill，直接装上就能用：

1 2	# 全局安装（所有项目都能用） git clone https://github.com/limin112/claude-goal-skill ~/.claude/skills/goal

装完重启 Claude Code，输入 /goal <你的目标> 就跑起来了。

三、语音输入，我低估它太久了

这个跟 Codex 本身没有直接关系，但我觉得必须说。

用 AI 编程，最大的瓶颈之一其实是打字。

不是写代码的打字——那个 AI 帮你写了。是你跟 AI 沟通的打字。描述需求、解释背景、说清楚你想要什么——这些都要打字，而且往往要打很多字才能说清楚。

我之前一直觉得语音输入是给懒人用的，或者是给不会打字的人用的。直到我真的用了一段时间，才发现自己想错了。

语音输入的真正价值不是快，是流畅

打字的时候，你的思维会被手速限制。想到一个复杂的需求，打字打到一半，思路断了，又要重新组织语言。

说话不一样。说话的速度跟思维速度更接近，你可以把脑子里的想法直接倒出来，不用等手跟上。

斯坦福有个研究数据：语音输入比键盘输入快 3 倍。在真实实测下，能达到每分钟 220 个字，是普通键盘输入的 4 倍左右。可想而知对于ai编程来说，是多大的效率提升。

我用过的两个工具

闪电说

我记得没错的话应该是国内最先出来的，之后其他厂才慢慢入局的，Windows 和 Mac 都有，本地优先处理，延迟很低，隐私也比较好。用法很简单，按住快捷键说话，松开就自动输入到光标位置。跟 Codex、Claude Code 这类终端工具配合很顺，因为它是系统级的输入，不挑软件。可以自定义AI服务帮你纠错。