夜雨聆风
我现在用 Codex 写代码，已经养成了个雷打不动的习惯：只要遇上复杂的业务需求，绝不放任它直接去写第一行代码。
每次我敲下的第一句话通常都是这句：
先不要急着写代码。先帮我把这个需求的实施方案写出来。
说实话，这个习惯真算不上是为了显得自己开发流程有多专业，纯粹是之前被 AI 写代码给反复折腾、遭了无数次罪才逼出来的血泪经验。
如果你习惯把 Codex 当成一个有求必应的许愿池，一上来就甩过去一句类似“帮我做一个后台管理系统”、“帮我加一个会员功能”、“帮我重构这个页面”或者“帮我把这个老接口换成新接口”的话，它确实会立刻动手，而且敲键盘的速度比谁都快。
可糟糕的地方恰恰就在于它动得太快了。这时候需求往往还没完全想清楚，它已经呼啦啦写了一大堆代码；边界条件和隐藏问题还没确定，十几个文件就已经被它改得面目全非。
你本意可能只是想改动一个局部页面，它却自作聪明地顺手给你加了一大堆兼容逻辑、重定向、fallback 和 adapter，到头来整个项目新旧逻辑死死地混在一起，根本没办法收拾。
这种把工具当变魔术的用法，往往很难得到稳定的产出。
真正靠谱的姿势其实是前期把所有的需求、文档、规则以及验证环境全部铺设好，后面再让它去进行高强度的机械执行。
去翻看 OpenAI 官方的描述也会发现，他们更倾向于把 Codex 定义为一个 “可配置、可改进的队友”，而非那种一问一答的快餐式工具。官方最佳实践里反复强调的任务上下文、AGENTS.md、验证、MCP、skills 以及自动化流水线，本质上都在诉说同一件事：
别指望只靠一句空中楼阁般的 prompt 解决问题，得把工程化的工作流结结实实地搭起来。
在这个工作流里，我如今去判断一个需求能不能放心地交给 Codex，第一标准倒不在于这个需求规模有多庞大，关键在于它到底清不清晰。
Codex 面对复杂的逻辑任务从不露怯，它真正怕的是那些含糊其辞的指令。每当需求本身模糊不清的时候，AI 就会开始用自己的默认倾向去疯狂补全，也就是靠本能去“瞎猜”。它会猜你想要什么，猜你需要兼容什么，猜你需要保留什么，甚至猜你未来可能会扩展什么。
而这种不受控的“猜”，才是最终把整个项目代码写脏、写烂的罪魁祸首。
所以面对复杂需求，我们起步的动作绝对不能是去实现，得先进行头脑风暴。
为了不让它乱猜，我一般会用下面这段长 prompt 去和 Codex 沟通，把主动权抓在自己手里：
我们下面开始头脑风暴，主要流程是这样的，我想实现一个XXX 的任务。你先去充分调研我想做的事情，了解足够多的背景信息。然后把里面不确定的信息、模糊的要求向我提问。每个问题需要带上对应的答案，给我 3~4 个选项，每个选项需要解释，还需要给出你推荐的选项以及对应的理由。我会用 A、B、C、D 来选择。然后我们进行下一个问题，每次我确认完的结果你都需要直接写入需求文档里面。如果我的选择前后有矛盾，请直接指出来，不要顺着我的话来。在需求没有定稿前不要写代码。
这段话的精妙之处，并不在于单纯地让 AI 多问几个问题。它的核心价值在于形成一种强制机制，逼着我自己先把需求琢磨透。
说来惭愧，很多时候我们自己其实也说不清楚到底想要个什么东西，脑子里往往只有一个大概的朦胧感觉，比如想做个功能、改个页面、或者是把某个卡顿的流程优化一下。
这时候要是直接开机写代码，方向一定会往歪路上跑。更好的解法是让 Codex 反过来审问我。
拿我自己开发一个“AI 技术调研助手”的过程来说，要是当时直接丢一句“帮我做一个 AI 技术调研工具”，这句话完全无法落地。
Codex 可能会把它做成一个简单的搜索工具，也可能写成一个报告生成器，甚至整出一个庞大而臃肿的 SaaS 平台。可当我用了上面那套风暴指令后，它就会一轮一轮地向我发问。
比如第一轮它会问：
“问题 1：这个工具第一版主要服务谁？A. 独立开发者：关注技术选型、部署成本、维护成本。B. 企业技术负责人：关注稳定性、团队协作、迁移风险。C. 新手程序员：关注教程、入门路径、学习资料。D. 内容创作者：关注资料整理和文章生成。我的推荐：A。理由：你的内容方向是 AI 独立开发，独立开发者场景最贴近，也最容易验证。”
当我回复选 A 之后，它就会把这个决策写进文档，紧接着抛出下一个问题：
“问题 2：第一版输出应该是什么形态？A. 一份 Markdown 技术调研报告。B. 一个可视化评分表。C. 一个完整教程。D. 一个技术选型对比表。我的推荐：A + D。理由：Markdown 方便复制，对比表方便快速判断。”
这样一轮一轮地对齐和推拉，原本虚无缥缈的需求，就逐渐沉淀为了一个非常清晰、可落地的开发版本在这个基础之上再放手让 Codex 去敲代码，那种稳当和精准是完全不一样的。
当头脑风暴把思路理清之后，千万别觉得就万事大吉了，我们还面临一个很现实的痛点：聊天上下文。
我开始极度重视 “文档留痕” 这个动作，也是因为吃过亏。
每一次关于需求的讨论、方案的权衡、实现路径的选择以及最终的验收标准，我都不允许它们仅仅飘在和 Codex 的聊天记录里，必须一笔一笔地写进代码仓库的 docs/ 目录。
道理其实很简单，聊天上下文会随着对话的深入变得越来越长，AI 会对其进行压缩，中途切换线程或者清除历史时，那些好不容易对齐的重点随时会丢。但是存在仓库文件里的文档，它是永远不会缩水的。
在 OpenAI Cookbook 里面其实也能看到完全相同的工程思维。它在讲解如何让 Codex 顺畅处理长时间、跨度大的复杂任务时，就极力推荐使用 PLANS.md 这一类的计划文档来扮演“活文档（living documents）”的角色。这样用户在长线开发正式开启前能反复检查方案，Codex 在后面连续干活时也能有一个随时能抬眼对照的设计蓝本。
所以，在头脑风暴成型后，我会直接给 Codex 下达这样一份梳理文档的指令：
请把刚才确认过的需求整理成实施方案，写入：docs/features 文件夹下面的新的文档里面。文档可以包含：需求背景、目标、明确不做什么、页面流程、数据结构、API 设计、UI 草图、实施步骤、验收标准、风险点、后续版本再考虑的功能写完后先不要实现。
在长期的实践中，我慢慢摸索出了一套用着很顺手的项目目录结构，它长这个样子：
docs/ features/ ai-tech-research-tool.md billing-v1.md url-migration.md decisions/ 001-tech-stack.md 002-auth-strategy.md reviews/ fallback-code-review.md这里面最珍贵的地方，绝对不在于你的文件目录搭建得有多么赏心悦目，而是你让每一个重要需求在仓库里都拥有了一份可追溯的文本。
后面如果 Codex 代码写到一半，思维开始断线或者跑偏了，我就不用在聊天框里跟它费尽口舌地解释，而是可以直接下一道命令：
“重新阅读 docs/features/ai-tech-research-tool.md。对照文档检查当前实现有没有偏离需求。先输出偏离点，不要继续写代码。”
这招在实战中简直就是降维打击。因为 AI 写代码时极容易被眼前的局部代码勾走注意力，它看到老逻辑就想去兼容，看到旧数据结构就想顺手写个转换层。而这份一直躺在仓库里的需求文档，就是随时把它拽回正轨的缰绳。
如果说刚才聊到的 docs/ 文件夹是用来给每一个具体需求留底的备忘录，那么 AGENTS.md 则是整个代码仓库里至高无上的长期宪法。
越是用 Codex 做大项目，我就越觉得这个文件是绝对的核心。
OpenAI 的官方文档在提及工程配置时明确说明过，Codex 在正式启动工作前会雷打不动地去读取 AGENTS.md，而且它原生支持全局、项目级以及目录级的指令层级划分，越靠近当前操作目录的文件，其赋予的优先级就越高。
你可以把它看作是你们团队或者你个人的开发底线。它不去干涉某一个特定功能该怎么写，它只负责死死地告诉 Codex，在这个项目里有哪些高压线是永远绝对不能踩的。
这是是我的全局的AGENTS.md，可以给大家参考：
# 核心原则- 有UI/UX 相关改动时候，用 ascii ui 的方式展示示意- 始终用简体中文回复- 查询最新技术文档：使用 context7- 浏览器操作浏览测试：使用chrome dev tools mcp,首次连接需要等待用户同意授权,不然会超时- 代码要写清楚中文注释，所有函数和关键逻辑都必须有注释这是我的其中一个项目级的AGENTS.md，可以给大家参考：
# 核心原则- 查数据、跑SQL、看数据表，使用 `skills/pg-server`- 针对系统资源数据的新增、修改、删除，统一通过对应 skill 的安全命令链路执行；严禁直连数据库改写资源数据，确保关系完整与脏数据防护。- 当单个代码文件超过350行或承载多种职责时，需拆分，自动生成文件可豁免- 网页子项目响应式布局三档：`base` / `md` / `xl`，阈值为 `md=37.5rem(600px)`、`xl=56.25rem(900px)`- 本地所有的项目，都是热重载，别再额外启动。- 每次任务完成，需git commit，只关注本次变动，如果工作区出现了你没动过的变更,不需要找我再次确认，直接忽视。- `temp/` 是本地临时工作区和运营草稿区，严禁提交其中任何文件；发现 `temp/` 文件已被 Git 跟踪时，必须用 `git rm -r --cached temp/` 停止跟踪并保留本地文件。- 推崇最佳实践方案，禁止偷懒最小化临时方案。- 项目设计遵循奥卡姆剃刀原则：如无必要，勿增加实体。## 项目结构- `api`：Go后端，服务front端，port `18766`- `front`：React 前后台一体应用（前台 + 管理后台），默认 vite 端口 `5173`## AI Trace- 需要查看 AI 链路时，统一使用 `pnpm trace:ai -- --label <label> --path <runtime_path> --text <text> --type <Hanzi|Phrase|Snippet>`；复杂请求使用 `--payload-file <abs_json_path>`- 每次请求生成一个独立文件，输出目录是 `tasks/ai-traces/`- trace 文件只保留原始字符串：`request.payload_raw`、`steps[].ai_input_raw`、`steps[].ai_output_raw`、`final.response_raw`相信你在写日常提示词的时候也发现了，如果对 AI 吩咐一些大而化之的空话，比如“请写高质量的代码”、“请遵循行业的最佳实践”、“请尽量保持代码整洁”，这类指令基本没有任何实质性约束力。
规则必须要写到痛处，写到 Codex 经常掉链子、犯迷糊的细节上。比如明文禁止它乱加 fallback、不许偷偷保留旧代码、不能擅自改动无关文件。这样的宪法，在实际干活时才真正具有黄金般的价值。
即便有了长期的生存守则，依然需要配合一套高频的风险控制手段，因为 AI 改代码的速度实在太过于狂野了。
效率高当然是天大的好事，但如果你的项目没接好 Git，写得越快往往意味着灾难来得越迅猛。
以前咱们人肉手写代码，改错或者改崩了，脑子里大致还能记起来刚刚动过哪几个文件的哪几行。
可 Codex 一干，一瞬间就能跨模块重构掉好几个文件，再顺手塞进去一堆底层工具函数。要是中途没有留下清晰的、可以随时撤回的提交点，一旦后面运行报错，你想把代码完好地复原回来，难度不亚于大海捞针。
鉴于这个隐患，我后来直接把 Git 操作强行死锁在了 Codex 的流水线里。
这个看似不起眼的微小动作，在实战中一口气帮我解决掉了三个核心问题。
首先是有了完美的退路，Codex 后面要是哪一步不小心把逻辑彻底改瘫痪了，我随时一键回滚到上一个稳定的 commit 节点，不浪费一秒钟。
其次是让代码审查变得极度轻松，每一个小 commit 都清清楚楚对应一个子阶段，它为什么改、动了哪里一目了然。
最后是给后续的开发提供了绝佳的上下文，哪怕跨了几天，Codex 下次继续开工的时候，通过翻阅近期的 Git 提交历史，也能瞬间接上之前的思路。
我很赞同这样一句话：
Codex 写得越快，Git 的重要性就越是成倍放大。
因为只有当回滚和刹车的能力跟得上时，狂飙的速度才真正具有生产力意义。
在这个紧密相扣的链条里，既然提到了在 Commit 之前要运行“必要检查”，那就不得不认真聊聊 Harness 这个概念。
这个词在传统的软件测试领域，通常指的是“测试马缰（Test Harness）”，也就是为了支撑测试顺利执行而特意搭建起来的一整套基础设施，包括怎么初始化输入、怎么去 Mock 外部依赖、怎么写执行测试的驱动器以及怎么去自动化校验输出。
它的存在，就是为了让测试变得完全可重复、可隔离、可闭环验证。(Tricentis)
如果把这个概念平移到今天的 AI 编程场景里，我更愿意给它翻译成一个接接地气的中文说法：
“验证环境”。
或者叫
“可自动验证的开发环境”。
它绝对不仅仅代表某一个具体的测试框架或者神秘工具，它是一整套生态和武器库的合集，里面可能包含了：typecheck、lint、单元测试、集成测试、本地 dev server、浏览器调试接口、控制台日志输出、自动化页面截图、API 请求测试脚本，甚至是接入像 MCP（Model Context Protocol）这样的外部工具、Chrome DevTools 或者是 Playwright 自动化框架，以及预先准备好的数据库 seed 种子数据。
如果你把这些工具和环境毫无保留地开放给 Codex，它在写完代码后，就再也不会只待在原地盲目地“自我感觉良好”，而是能够真正迈出一步去执行和验证。
OpenAI Cookbook 在分享 Codex 迭代修复 Bug 的案例时，核心思路也是一模一样的：先自检当前状态，锁定范围做最小化修改，随后立马在环境里运行验证，再根据报错反馈继续修，直到绿灯亮起。
在做 Web 前端开发的时候，这个区别体现得尤为扎心。
一个人类程序员写完一个页面，好歹会顺手打开浏览器看一眼，点点按钮，瞅一眼控制台有没有红色的报错，看看接口到底有没有吐出正确的数据。
可如果你不把浏览器验证的能力开放给 Codex，它写代码就全靠脑补。
现在如果你手头配有 Chrome DevTools MCP、浏览器自动化工具或者其他智能 Agent 的浏览器生态，整个闭环过程跑起来会顺畅得让人awesome。
OpenAI Codex 的配置手册里也特别聊到过如何去架设 MCP server，并且在最佳实践中把 MCP 视为 AI 与外部真实操作系统和生产工具之间最核心的连接桥梁。
这就是我眼中真正的 Harness：
给 AI 提供一个能够亲眼观察运行结果、运行自动化自检、主动发现错误并持续自我修复的闭环生态。
如果没有这个环境的支撑，Codex 极容易写完一堆代码就拍拍屁股跟你汇报说“搞定了”。
至于到底能不能跑、页面有没有碎掉、交互是不是瞎了，它自己其实一无所知。
一旦有了这个环境，它在把代码交给你之前，自己就能在后台悄悄筛掉一大批低级趣味的低级 Bug。
当这一整套从文档到验证环境的防御工事全部修筑完毕，咱们才真正迎来了祭出大招的时刻：
开启 Goal（目标）模式。
不过在这里我想提醒的是，打一开始就盲目开启 Goal 模式其实是个不小的误区。在需求还是一片浆糊的时候开 Goal，就跟打发一个手里拿着错误地图的人去跑马拉松没什么两样，他确实跑得很卖力，但你根本无法预料他最后会跑到哪个未知的荒野去。
仔细阅读 OpenAI 官方对 Goal mode 的定义就能明白，Goal 模式本质上是为 AI 注入一个具备强持久性的终极目标，极其适合那些跨越多个繁琐步骤的长线任务。
目标文本既是它启航时的初始 prompt，同时也是它最后完工时的铁律标准，Codex 会在整个过程中反复用它来判断下一步该干什么，以及眼下的任务到底算不算彻底结束。
Cookbook 里也着重强调过，Goal 模式更契合那些“终点明确但路径不确定”的深度任务，比如全站的性能调优、排查那些时好时坏的 flaky test、底层依赖库的整体迁移、涉及多个文件的跨步重构或者是深度的研究性任务。
一个真正及格的 Goal，必须把预期产出、考核边界、约束条件、迭代策略以及遇到阻塞时的处理预案写得滴水不漏。
所以我的策略是， 在前期探讨需求的阶段，绝对不用 Goal。 那个时候我需要它陪着我一起把逻辑盘清楚，把结果一条条写进 docs，把底线更新进 AGENTS.md，把验证环境彻底打通。等这些基础设施全部到位、万事俱备了，我才会正式启动 Goal 模式。比如我会这样发号施令：
/goal 按照 docs/features/ai-tech-research-tool.md 实现 AI 技术调研工具第一版。
直到这个节点，Goal 模式的威力才算是真正释放出来了。因为它头上悬着明确的终点，脚下踩着详实的文档，四周有硬性的生存宪法约束，后面还有自动化的开发环境在帮忙做全方位的防线监控。
我对自己这套工作流的理解，可以用一句话来概括：
在探索需求的阶段，人类必须寸步不离地在场；而到了机械执行的阶段，人类可以放心地往后退一步。
在摸索功能到底该长啥样的时期，你必须留在回路里，一轮一轮地跟 Codex 碰撞和对齐。等到一切白纸黑字写得明明白白了，执行的大幕拉开，就可以放手让它自己去狂飙。
OpenAI 关于 Goal 的用例文档也特别指出过，目标的终极奥义是让 Codex 骨子里明白“完成”到底意味着什么，并且在漫长的执行链路中，能够用极其简练的状态报告来向你汇报每一个检查点、已经通过验证的模块、剩下还要干的活以及当前卡脖子的阻塞点。
不过话说回来，哪怕是在执行阶段，有一类代码即便能完美通过所有的自动化编译和测试，我也依然会保持最高级别的警惕。
这类代码我称之为“兼容性垃圾代码”。
这个坑在 AI 编程里埋得极其隐蔽。它既不会引发语法报错，表面上看起来甚至贴心到让人感动，显得逻辑非常严密专业，但实际上它正在像癌细胞一样让你的整个项目变得乌烟瘴气。
举个最常见的例子，你吩咐 Codex ：“把这个项目里的旧页面彻底迁移到新页面吧。”你的真实意图其实是想快刀斩乱麻，把旧代码全部删个干净，以后全站统一走新页面。
但是 Codex 拿到指令后，它往往会选择在保留旧页面的基础之上，在里面偷偷摸摸写一段 redirect 重定向到新页面。
单看运行结果，完美无瑕，路由跳转得非常稳。但回过头看代码仓库，旧页面跟新页面同时苟活在项目里。
再比如，你让它把一个老的底层接口换成全新设计的接口，目的是为了实现架构的统一。它可能扭头就会写出一段这样的逻辑：先尝试去请求新接口，如果新接口不幸失败了，那就自动 fallback 降级去调用老接口。
看起来安全感爆棚对不对？但长此以往，你的项目里就会永远并存着两套完全不同的业务逻辑。
类似的情况还有很多，比如遇到要改数据库或数据结构的时候，它为了不破坏现状，选择不去真正做数据迁移，而是写了一层又一层的适配转换函数，把老结构硬生生转成新结构。
短期内确实皆大欢喜不报错，但长远看全是技术债。
这就是 AI 编程时最具有共性的本能缺陷：它在骨子里默认倾向于保守，默认倾向于不破坏任何现状，默认倾向于去兼容地包容更多的情况。
如果是在极度脆弱、容错率极低的线上生产环境，这种保守或许算得上是个优点。
但是在我们个人开发、早期产品快速迭代或者内部大刀阔斧重构的阶段，这些自作聪明的兼容代码全都是纯正的垃圾。
它们会像慢性毒药一样把你的代码仓库弄得脏乱不堪，把原本应该暴露出来的真实架构问题死死地掩盖起来。
这就是为什么我一定要在 AGENTS.md 里，用极其严厉的措辞把这层窗户纸给捅破，立下死规矩：
## 关于兼容性代码开发阶段默认不要兼容旧实现。以下行为必须先征求确认：- 保留旧页面并重定向到新页面- 同时保留新旧两套 API- 查询失败后 fallback 到旧查询- 数据结构不迁移，只写转换层- 为了“不报错”隐藏真实失败- 未经确认添加 polyfill、adapter、compat layer如果你认为必须兼容，请先说明：1. 为什么必须兼容2. 不兼容会坏什么3. 兼容代码未来怎么删除4. 有没有更简单的方案这里我需要澄清的是，我并不是在盲目抹杀“兼容性”在软件工程里的客观价值。
当你的项目线上已经拥有了庞大的活跃用户、外面挂着无数错综复杂的外部链接、数据库里躺着好几年的历史数据时，灰度发布、优雅降级和兼容迁移当然重如泰山。
我真正反对的是，Codex 在你根本没有提出明确要求的情况下，擅自且盲目地在开发初期就把代码写得新旧并行、 fallback 满天飞、重定向一堆。
这种代码最让人反胃的地方在于它当下根本不报错。等过个把星期你再回过头来审查的时候，恐怕连你自己都分不清楚系统在特定场景下到底走的是哪条诡异的逻辑分支了。
除了在代码逻辑上和它死磕，在处理前端 UI 改动的时候，我还摸索出了一个虽然看着挺土、但是奇效明显的防翻车小技巧：逼它画 ASCII 字符图。
凡是涉及到页面结构或者用户交互的修改，我极其反感让 Codex 一上来就去写复杂的 HTML 或者 CSS 代码。我每次都会强迫它先用纯文本的 ASCII 字符把布局框架给我勾勒出来。
因为 UI 这种视觉层面的东西，如果前期双方在脑子里没对齐，后面在代码里反复修改样式的沉没成本会大得吓人。
尤其是 AI 做页面，它非常容易写出一种“虽然符合语法、看着也挺丰满，但完全不是你想要的”奇葩结构。
通常，我会甩过去这样一段指令：
先不要写代码。请根据这个需求，用 ASCII UI 画出页面结构。要求：
1. 展示桌面端布局。 2. 展示移动端布局。 3. 标出每个区域的功能。 4. 标出 loading、error、empty 三种状态。 5. 我确认后再开始实现。
接着，它就会在终端里给我吐出一张这样纯手工打造的结构卡片：
+--------------------------------------------------+| AI Tech Research Tool |+--------------------------------------------------+| Technology Name || [ Cloudflare D1 ] || || Project Context || [ Personal AI tool, low maintenance... ] || || Constraints || [ Free tier, no self-hosted DB... ] || || [ Generate Report ] |+--------------------------------------------------+| Summary || ... || || Best For Risks || - ... - ... || - ... - ... || || Alternatives || Supabase | Neon | Turso |+--------------------------------------------------+虽然这种字符画看起来土里土气，但在实战中它能发挥极大的威力。
它让我们在还没碰哪怕一行生产代码之前，就能把整个前端的骨架给完完全全对齐。你一抬眼就能看明白：输入框摆在哪、结果展示区留了多大、各种异常状态有没有兜底、核心按钮容不容易点到、到了移动端窄屏下空间会不会挤成一团。
彼此在视觉结构上达成共识后，再放它去写组件代码，开发效率和精准度能直接拉满。
说了这么多，我把这一整套目前在我手头跑得最顺、也是最完整的 Codex 闭环工作流毫无保留地梳理在下面，供大家直接参考复刻。
第一步是创建需求的留痕文档， 明确开辟属于这个功能的独立文件：docs/features/feature-name.md。
第二步是让 Codex 开启高强度的头脑风暴，明确限制它不许写代码。给它的 prompt 是：“先不要写代码。我们先头脑风暴这个需求。你来提问，给选项，给推荐理由，我来选择。每轮确认结果写入 docs/features/feature-name.md。”
第三步是要求 Codex 提炼并生成最终的实施方案， prompt 如下：“请基于我们确认的内容，生成实施方案。包含：1. 第一版目标 2. 明确不做什么 3. 页面流程 4. API 设计 5. 数据结构 6. 验收标准 7. 风险点 8. 实施步骤。写入 docs/features/feature-name.md。先不要实现。”
第四步是当上述所有基础建设全部落实后，正式向它发起 Goal 模式的冲锋，输入指令：“/goal 按照 docs/features/feature-name.md 实现第一版。必须满足文档中的验收标准。必须运行验证命令。必须浏览器验证主流程。验证通过后提交 git commit。”
第五步是当 Goal 模式顺利凯旋、目标达成后，立刻跟进一次冷酷的代码 Review，把可能遗留的脏代码连根拔起：“请 review 本轮改动，不要继续写新功能。重点检查：1. 是否严格符合 docs/features/xxx.md。2. 是否有未经要求的 fallback 逻辑。3. 是否同时保留了新旧两套实现。4. 是否有旧页面 redirect 到新页面的临时兼容。5. 是否引入了不必要的新依赖。6. 是否有隐藏错误的 try/catch。7. 是否有数据结构转换层掩盖真实迁移问题。8. 是否通过 typecheck、lint、test。9. 是否已经提交 git commit。请按：问题 / 影响 / 建议处理方式 输出。”
这套严丝合缝的流程彻底跑下来之后，Codex 展现出来的稳定性和工程质量会发生质的飞跃。这背后的真相，当然不是因为在这短短几分钟里 Codex 突然开窍进化了，而是因为你通过这套工作流，成功地把它从一个全靠猜测去写代码的迷茫机器，变成了一个手握精确图纸、身处完善监控环境下的高效率执行者。
一言以蔽之，我这段时间用 Codex 最深刻的体会就是，它本质上是一个极度重度依赖“明确性”的生产工具。
它非常擅长处理那些拥有宏大上下文、极度复杂的长线任务。只要你给足它明确的需求、清晰的仓库文档以及坚实的自动化验证环境，它干活时带给你的爽快感是无与伦比的。
但它绝对不适合、也没能力去替代你把一切需求都想得清清楚楚。在需求探索的关键阶段，人的思维必须牢牢把住关，你得陪着它去头脑风暴，去拍板方案，去狠心做功能的取舍，把每一步脚印都刻进仓库的文档里。
在这个阶段，只要你贪图省事当了甩手掌柜，它交卷时就一定会给你用代码画一个巨大的鬼符。
而一旦等这个阶段平稳度过，文档立起来了，AGENTS.md 铁律刻好了， Git 规则焊死了，验证环境跑通了，Goal 目标架设完毕了，这时候人类开发者就可以放心地往后退上一大步。
你再也不用盯着它写的每一行代码，你只需要优雅地站在终点，看最终的 diff 差异，查一查潜在的遗留风险，做做最后的验收。
所以，AI 编程的进阶之路，核心从来不是去钻研那些花里胡哨的 prompt 小花活，它的本质是极其纯粹的工程化落地。
用文档留痕，是为了让飘忽不定的需求变得随时可追溯；用 AGENTS.md ，是为了让通用的团队底线规则变得可跨文件复用；死磕 Git，是为了让疯狂狂飙的开发过程变得随时可吃后悔药、可回滚；而搭建 Harness 验证环境，是为了让冷冰冰的代码结果变得可闭环验证；最后开启 Goal，则是为了让漫长的复杂任务拥有一个持续不偏离的目标。
把这几块拼图彻底凑齐，Codex 才会真正脱胎换骨，成为一个能帮你分担重任的硬核开发搭子。否则，你所谓的 AI 编程，真的只是在对着一个许愿池凭运气碰巧碰运气罢了。
在文章的最后，我还是想把前文提及的那个关键核心——Harness，给出一个我认为在当下最精准的定义，方便大家在实践中随时查阅。
在传统的软件工程里，Harness 指的是那一整套为了测试能够顺利跑起来、为了模拟依赖和初始化输入、自动化校验结果而量身定做的代码和工具集。而当我们把目光投射到今天用 Codex 写代码的全新场景下时，我更愿意管它叫“验证环境”：它的核心功能，是让 Codex 在改完代码后，能够有一个真实的物理容器去运行、去观察、去捕获异常、去自我修复，而不是仅仅锁在自己的长上下文里盲目地猜测代码写得对不对。
所以，不要狭隘地把 Harness 误解为某一个孤立的测试框架。
它在今天更像是一套全方位立体式的环境闭环：测试命令加浏览器底层能力，配合控制台的实时日志，再加上 API 调试脚本、自动化截图、测试数据准备以及后台自动验证脚本。
把这套硬核的环境塞给 Codex，它才有可能真正完成蜕变，从一个“写完就盲目汇报”的半吊子，变成一个在后台默默经历“编写、验证、失败、修 Bug、再次验证”直到完美通关的成熟劳动力。
这，才是 AI 工程化提效最让人兴奋的终极奥秘。
参考文献
1. Best practices – Codex | OpenAI Developers 2. Using PLANS.md for multi-hour problem solving 3. Custom instructions with AGENTS.md – Codex | OpenAI Developers 4. Test harness: Definition, benefits & uses | Tricentis 5. Build iterative repair loops with Codex 6. Config basics – Codex | OpenAI Developers 7. Prompting – Codex | OpenAI Developers 8. Using Goals in Codex 9. Follow a goal | Codex use cases
