规格驱动开发实战：用Codex从Spec到全栈应用的完整流程

这几年AI编程工具演进速度真的快。从最早GitHub Copilot的代码补全，到后来各种Chat模式、Agent模式，再到Codex CLI这种直接在终端里跑的AI智能体，我基本都第一时间上手试过。作为一个常年做全栈开发的开发者，我试的项目越多越觉得，真正拉开使用效果差距的，不是选哪个模型、用哪个工具，而是你喂给工具的输入到底是什么样的。很多人习惯丢一句话让AI“帮我写个登录页”，结果出来一个看起来能跑、但哪哪都不符合项目的登录页，然后开始漫长来回对话。我现在的做法完全不同：先写Spec，再让Codex动手。这套流程在圈里常被称作规格驱动开发，说穿了就是把需求文档化、场景化、验收化，让AI在动手前就拿到足够清晰、足够完整的上下文。

这篇文章就把这套实践完整拆开讲。内容包括：为什么规格驱动开发有效、一份能直接喂给Codex的Spec长什么样、Codex环境怎么准备、从Spec到代码的完整实操流程，以及我实际踩过的坑和排查经验。如果你正准备用AI做全栈项目，或者觉得AI生成的代码老是差一口气，这篇文章应该能给你一个可以直接上手的方案。

1. 先说清楚：为什么规格驱动开发值得认真对待

1.1 从“聊天式写代码”到“规格驱动”的转变

我先描述一个很多人都会遇到的场景。你打开AI编程助手，输入“帮我写一个用户注册接口”，AI噼里啪啦生成几十行代码，看起来逻辑完整，还能跑。但你仔细一看，邮箱没校验、密码没有复杂度要求、数据库表字段和项目现有规范对不上，更别提异常处理和权限控制了。于是你只能继续追加：“邮箱要校验一下”“密码至少8位”“改成项目里的统一返回格式”。四五轮下来，AI开始把之前正确的代码也改歪了，最后你索性自己动手。

问题出在哪里？不是AI能力不行，而是你给的信息太少了。“用户注册接口”这六个字，背后其实包含了一整套隐含需求：字段定义、校验规则、唯一性约束、密码存储方式、验证码机制、频率限制、错误码规范、日志记录等等。你不写清楚，AI就只能按它训练数据里最常见的模子去猜。

规格驱动开发解决的就是这个信息缺失问题。它的核心做法很简单：在让AI写任何实际代码之前，先产出一份结构化、可验证的Spec，把“要做什么”“做到什么程度算完成”“边界条件怎么处理”全部写明白，再让AI照着Spec去实现。这套思路本质上是把软件工程里“需求先行、设计先行”的原则，迁移到了人机协作场景里。

我自己的体会是，规格驱动开发和传统项目里的“写文档再开发”不完全一样。传统文档很多是写给人看的，写完之后放在Wiki里吃灰。但Codex这类AI智能体真的会把Spec当作执行的输入，你在Spec里定义的验收标准，可以直接变成它自测的依据。也就是说，Spec不再是“管理产物”，而是“技术输入”。

1.2 规格驱动到底解决了什么问题

结合我实际使用的经验，规格驱动开发至少有效解决了四个痛点。

第一个是上下文不足导致的车轱辘对话。AI模型的上下文窗口毕竟有限，你每追加一轮对话，早期信息就可能被压缩甚至遗忘。如果一开始就把目标和规则完整写进Spec，后续对话里AI可以反复参考，不需要你把同样的要求重复三遍。

第二个是需求二义性导致的返工。语言是有歧义的，“用户可以登录”这句话，AI可能理解为“只要用户名密码对就行”，也可能理解为“还要支持第三方OAuth”。Spec里有明确的用户故事和验收标准，就能把歧义降到最低。

第三个是验收标准缺失导致的“看起来对但实际不满足”。很多AI生成的代码表面功能齐全，但一旦你开始测试边界情况，比如重复提交、非法输入、大流量场景，就露出马脚。规约里如果写清楚了边界条件，Codex会在实现阶段主动考虑这些分支，而不是等你去提Bug。

第四个是大型任务无法一次性完成的问题。一个全栈功能少说涉及几十个文件、几百行代码，想让AI一口气生成完，很容易在中途跑偏。Spec本身天然适合拆解，把大任务拆成“登录注册功能”“任务列表功能”“评论功能”等子模块，每个模块按独立Spec去推进，整体进度可控得多。

这四个痛点解决之后，最大的收益不是代码写得快了，而是“返工”变少了。代码生成得再快，返工四次的时间成本也不低。

1.3 不是所有场景都适合写Spec

说完了优点，也得说说边界。规格驱动开发并不是银弹。我遇到过一些场景，写Spec反而是浪费时间的。

比较典型的是探索性任务。比如你想验证某个第三方库的API怎么用，或者想看看某种设计模式能不能解决当前问题，这种时候直接让AI生成个demo试试就行，没必要先写Spec。

还有一些一次性小任务也不用大动干戈。像是“把这个正则表达式改一下”“帮我把这段代码加个日志”，这些任务用一句话讲清楚就够了。事无巨细都写Spec，会让团队陷入文档崇拜，反而拖慢节奏。

我的经验是：只要任务涉及多个文件、多个功能环节、或者有明确的业务规则，就值得写Spec。如果是单文件、单点修改、探索性质，直接用对话模式处理更合适。规格驱动开发是工具箱里的重要工具，不是唯一工具。

2. Spec怎么写：一份能直接喂给Codex的规格说明书

2.1 一份Spec该有哪些组成部分

很多人一听到“规格说明书”就觉得头大，以为要像写论文一样。其实不需要。我给Codex用的Spec，就是一份结构清晰的Markdown文档，常见的中文或英文都可以，重点是把信息组织好。

我自己在大量项目里反复调整后，沉淀出了一份比较稳定的Spec模板，下面直接贴出来：

# 项目名称：待办事项全栈应用 ## 背景与目标 用一句话说明为什么做这个功能，最终要达成什么效果。 ## 技术栈 后端使用什么框架、前端使用什么框架、数据库选型、是否需要Docker等。 ## 功能需求 ### 功能一：用户登录 用户故事：作为已注册用户，我希望输入邮箱和密码就能登录，以便我看到自己的待办列表。 验收标准： - 邮箱或密码错误时，提示“邮箱或密码错误” - 连续失败5次时，账号锁定30分钟 - 登录成功后返回JWT Token 边界条件与例外： - 邮箱未验证时不允许登录 - 网络超时统一返回错误码10001 ### 功能二：任务管理 …… ## 非功能需求 - 接口响应时间在正常网络下小于500ms - 密码必须使用bcrypt加密存储 - 日志中不允许出现明文密码 ## 数据模型 users表、todos表、字段清单及关联关系。 ## API设计 POST /api/login、GET /api/todos等接口的入参出参。 ## 页面与交互 简要描述每个页面的布局与跳转关系。 ## 部署要求 构建命令、环境变量、部署目标。 ## 待确认问题 当前不确定、需要后续明确的事项。

这份模板看起来内容多，但每个部分并不需要长篇大论。如果项目很小，背景、技术栈、功能需求、数据模型、API设计这几项基本就够用了。关键在于始终记住：Spec是给AI看的执行依据，不是给领导看的汇报材料。

2.2 用“用户故事+验收标准”代替模糊需求

Spec里最核心的部分是功能需求，这部分的写法直接决定Codex的表现。我发现很多新手写的功能需求仍然是笼统的自然语言，比如“系统要支持任务分类”“用户可以按状态筛选待办”。这种描述看着清楚，AI实现出来的效果却很可能和你想的不一样。

一个比较好用的写作框架是“用户故事+验收标准+边界条件”。用户故事回答“谁会用什么方式完成什么目标”，验收标准回答“怎么做才算完成”，边界条件回答“什么特殊情况不能漏”。三者叠加，需求就变得可测试了。

举个例子。模糊写法是：“支持用户注册”。

规格化写法是：

用户故事：作为访客，我希望输入邮箱和密码完成注册，以便我拥有自己的待办空间。

验收标准：

• 邮箱格式必须合法，非法时在输入框下方提示“请输入正确的邮箱地址”
• 密码至少8位，且必须包含字母和数字
• 邮箱已被注册时提示“该邮箱已注册”
• 注册成功后自动登录，并跳转到待办列表页

边界条件：

• 同一邮箱连续注册失败5次后，需要等待10分钟才能再次尝试
• 注册接口需要处理重复点击提交，防止创建多条记录

这两段文字的差距，大家一眼就能看出来。模糊写法是在描述意图，规格化写法是在描述行为。Codex拿到后者，直接就能转化成具体的校验逻辑、数据库查询和错误提示文案。

2.3 边界条件与例外情况：AI最怕的隐藏需求

如果要我从Spec各章节里挑一个最重要的，我会选“边界条件与例外情况”。因为AI生成代码的最大问题不是主流程不会写，而是异常分支想不全。

说实话，我自己最初写Spec也经常漏掉边界条件。比如做一个删除待办的功能，我只会写“用户可以删除自己的待办”，忘了写“删除不存在的待办时应该返回什么”“删除别人的待办时怎么处理”“删除后的数据是物理删除还是逻辑删除”。结果AI生成出来的接口，就只处理了最理想的路径。

后来我养成了一个习惯：每个功能模块写完后，专门花几分钟做一次“捣乱测试”。就是假设自己是破坏分子，专门想各种异常输入和越权操作，把这些场景写进边界条件里。

常见的边界条件清单包括：空值、超长输入、非法格式、重复提交、不存在的数据、没有权限的访问、第三方服务超时、数据库连接失败、并发操作。你不需要每个功能都把这些列全，但要挑出和该功能相关的场景。

这个习惯也让我养成了新的协作方式：Codex实现完某个功能后，我会让它“根据Spec里的边界条件逐条自测”，把测试结果反馈出来。有了明确的边界条件，这个自测环节才能跑得起来。

2.4 完整示例：待办事项全栈应用的Spec

理论知识说太多不如给一份完整示例。下面是我用来演示规格驱动开发流程的Spec，属于一个经典的待办事项全栈应用。你可以直接复制这个模板改成自己的项目。

# 待办事项全栈应用 Spec ## 背景与目标 做一个多人可用的待办事项应用，用户可以注册登录，创建自己的待办事项，并对待办进行标记完成、编辑和删除。整个应用作为全栈开发演示项目，前后端分离。 ## 技术栈 - 后端：Python FastAPI + SQLite（开发环境），使用JWT做身份认证 - 前端：React + Vite，使用fetch请求后端接口 - 数据库：单表todos + 单表users ## 功能需求 ### 功能一：用户注册 用户故事：作为访客，我希望用邮箱和密码注册，以便拥有自己的待办空间。 验收标准： - 邮箱格式不合法时，返回错误信息“请输入正确的邮箱地址” - 密码少于8位或只包含字母/只包含数字时，返回“密码至少8位且需包含字母和数字” - 邮箱已注册时，返回“该邮箱已注册” - 注册成功后自动登录，返回JWT Token 边界条件： - 同一邮箱注册失败超过5次，锁定10分钟 - 防止重复点击导致重复注册 ### 功能二：用户登录 用户故事：作为已有账号的用户，我希望输入邮箱密码登录，以便查看我的待办。 验收标准： - 邮箱或密码错误时，返回“邮箱或密码错误” - 登录成功后返回JWT Token，过期时间为24小时 边界条件： - 连续失败5次后，账号锁定30分钟 - Token中不能包含密码等敏感字段 ### 功能三：待办管理 用户故事：作为已登录用户，我希望新增、查看、编辑、删除待办，以便管理我的日常工作。 验收标准： - 新增待办：标题必填，最大长度50；内容可选，最大长度200 - 查看待办：默认返回所有未删除待办，按创建时间倒序 - 编辑待办：可修改标题和内容，修改后更新updated_at - 删除待办：逻辑删除，标记deleted_at，不物理删除 - 标记完成：完成状态用completed布尔值表示，可切换 边界条件： - 只能操作属于当前用户的待办，越权时返回403 - 操作不存在的待办时返回404 - 标题为空白字符时视为空 ## 非功能需求 - 接口响应时间在正常网络条件下低于500ms - 密码使用bcrypt加密存储 - 日志中不得出现Token和密码 ## 数据模型 users表：id, email(unique), password_hash, created_at todos表：id, user_id(外键), title, content, completed, created_at, updated_at, deleted_at ## API设计 POST /api/register POST /api/login GET /api/todos POST /api/todos PUT /api/todos/{id} DELETE /api/todos/{id} ## 页面与交互 - 首页：未登录时显示登录/注册入口 - 登录页：邮箱+密码，进入后跳转控制台 - 注册页：邮箱+密码+确认密码，注册成功直接进入控制台 - 控制台：展示待办列表，顶部有新增输入框，每条待办可编辑、删除、标记完成 ## 部署要求 - 后端使用uvicorn启动，监听8000端口 - 前端构建后静态文件可由任意静态服务器托管

这份Spec写完后，项目需求的核心已经全部落在文字上了。接下来就是让Codex按照这份Spec干活。

3. Codex环境准备：安装、登录与模型选择

3.1 安装Codex CLI

Codex CLI是OpenAI推出的命令行AI编程工具，本质上是一个跑在终端里的智能体。它可以直接读取本地文件、执行命令、生成代码，非常适合规格驱动开发这种“按文档干活”的模式。

安装方式很简单，如果你本机有Node.js环境，直接全局安装即可：

npm install -g @openai/codex

安装完成后确认版本：

codex --version

这里需要说明一下环境要求：Node.js版本不能太老，建议18以上。我用过几个旧版本的Node，安装时虽然没有报错，但运行时会出现一些莫名其妙的兼容问题，升级Node之后就消失了。所以如果你准备长期使用Codex，先把Node环境理顺。

也有通过Homebrew安装的方式，我个人还是推荐npm，因为升级方便。Codex的更新频率不算低，隔段时间就会增加新功能或修复问题，用npm全局装的话，一条命令就能升到最新版。

3.2 登录方式和账号类型

安装完之后，需要登录账号。在终端里运行：

codex login

执行后会打印一个链接，跳转浏览器授权，授权成功后回到终端就能继续操作。

这里有一个容易让新人困惑的点：Codex支持用ChatGPT账号登录，也支持用OpenAI API Key登录，两种方式能用的模型范围不太一样。用ChatGPT账号登录时，登录形态比较像订阅用户，能够直接使用账号对应的模型配额；用API Key登录时，Codex则按API调用计费，能选择的模型更灵活一些。

我个人的习惯是：做个人项目时用ChatGPT账号登录，省心；在有明确的API预算或需要特定模型时，用API Key。两条路都能走通，取决于你手头有什么资源。

3.3 常用启动参数与模型选择

Codex的启动命令不算复杂，但有几个参数我几乎每次都会用到，这里整理成一个表：

举个例子，如果我已经把Spec写进了项目根目录的spec.md，想让它按Spec实现整个项目，可以这样启动：

codex -C "请阅读 spec.md，按其中的功能需求逐步实现项目，每个功能完成后先自测再继续" --skip-prompts

这里的-C是沙箱模式，Codex在执行任何命令前都会问我确认，我会看着它做。如果你对项目的运行环境非常熟悉，确认命令不会破坏文件系统，也可以考虑-f参数全自动执行。但我不建议一上来就用全自动模式，AI一旦执行了错误命令，后悔都来不及。

3.4 用配置文件固定项目习惯

如果你经常用Codex做项目，一定会遇到“每次都要重复指定模型和提醒规则”的麻烦。Codex支持通过配置文件把默认行为固定下来。

配置文件的位置和格式比较标准，常见的是在项目目录下放一个codex.toml，里面可以写模型选择、执行权限、额外的指令等。下面是我常用的最小配置示例：

# codex.toml model = "gpt-5.2-codex" [permissions] allow = [ "npm run build", "npm test", "git status", "git diff", ]

这个配置的作用是：指定模型的默认值，并自动允许一些安全命令，减少沙箱模式下频繁确认的打扰。不过要注意，不同版本Codex的配置字段可能略有差异，更新版本后最好看一眼官方文档确认。

如果你希望Codex在每次任务开始前自动了解项目约定，也可以设置项目的AGENTS.md或BUILD.md，相当于给它一份“项目说明书”，把目录结构、代码风格、常用命令写清楚。这个文件和Spec配合，基本能让AI的表现再上一个台阶。

4. 从Spec到代码：完整实操流程

4.1 让Codex读取Spec的第一条提示词

规格驱动开发和普通的“一句话需求”最关键的区别，就在第一条提示词上。我的经验是，不要直接说“帮我实现这个项目”，而是要把任务分层次说清楚。

我先给出我自己常用的提示词模板，你可以直接拿去用：

请阅读项目根目录下的 spec.md，这是本次任务的规格说明。 请按以下步骤推进： 1. 先复述你对 spec.md 的理解，特别是功能需求、验收标准和边界条件，确认没有遗漏。 2. 根据技术栈规划项目结构和实现顺序，输出一个简明的实施计划。 3. 按计划分阶段实现，每完成一个功能模块，就根据 Spec 中的验收标准进行自测，并报告测试结果。 4. 如果实现过程中发现 Spec 中有歧义或缺失的信息，先列出问题清单，不要自行假设重复提交、权限等边界行为。 5. 全部完成后，生成一份摘要，列出已实现功能、已知限制和后续建议。

这条提示词有几个细节是刻意设计的。第一，让AI先复述理解，相当于强制校验输入有效性，如果它理解偏了，你可以马上纠正，不用等它写完代码再后悔。第二，要求它分阶段实现，每到一个节点自测，这能显著降低长任务跑偏的概率。第三，明确要求遇到歧义先提问题，防止AI自作主张。

我用这套模板跑了十几个小项目，基本没有出现过“做完发现方向错了”的情况。偶尔会有理解偏差，也都在第一阶段复述时就被我发现了。

4.2 分阶段实现：计划、实现、自测

如果你第一次用Codex跑一个完整Spec，可能会忍不住让它一股脑把所有功能写完。我的建议是忍住，让整个过程慢一点。

一次典型的分阶段会话流程是这样的。

第一阶段是“计划”。Codex读取Spec后，会输出它理解的需求要点，以及预计的目录结构。比如对于待办应用，它可能会说：先建FastAPI后端，再建React前端，数据模型按Spec里的users和todos表来建。这时候我会检查它复述的要点，确认它没有漏掉“逻辑删除”和“越权返回403”这些关键细节。

第二阶段是“实现后端”。我会让Codex先做数据模型和API层，不做前端。因为后端是最容易被验证的，程序跑起来后可以直接用接口测试工具验证是否符合验收标准。Codex完成后，我会要求它启动服务，调用接口做一轮冒烟测试。

第三阶段是“实现前端”。后端稳定后，再让Codex按Spec里的“页面与交互”实现前端页面。前端联调时经常会出现字段名对不上的问题，所以我会告诉它必须先查看后端实际返回的JSON字段，再写前端代码。

第四阶段是“端到端自测”。Codex按Spec里的验收标准逐条测试，输出测试报告给我。如果某条不通过，它会定位到具体代码，修改后重新验证。

整个流程走下来，看起来比“一句话需求”多花了不少时间，但算上返工成本，实际上省得更多。因为每个阶段都有明确的自测点，错误在最早期被拦截，不会滚雪球堆到最后。

4.3 全栈场景拆解：从API到前端的落地顺序

用第2章那份待办事项Spec来演示一下，Codex最终生成的目录结构大概是这样的：

todo-app/ ├── spec.md ├── backend/ │ ├── main.py │ ├── database.py │ ├── models.py │ ├── schemas.py │ ├── auth.py │ └── requirements.txt ├── frontend/ │ ├── index.html │ ├── package.json │ ├── vite.config.js │ └── src/ │ ├── main.jsx │ ├── App.jsx │ ├── api.js │ └── components/ │ ├── LoginPage.jsx │ ├── RegisterPage.jsx │ └── TodoList.jsx └── README.md

实际运行时，Codex会先在后端生成FastAPI的入口文件、数据库连接、用户模型和待办模型，以及JWT认证逻辑。然后实现注册、登录、待办增删改查这几个接口。每个接口完成后，它会用curl或者Python脚本请求一下本地服务，确认返回结果符合Spec里的验收标准。这就是在自测。

后端完成之后，Codex才会转到前端。对前端来说，它最需要确认的是“接口返回的JSON长什么样子”，所以Codex往往会先去读后端的schema文件，再拿着真实的字段名写React组件。这一点我在使用中印象很深：如果我先让它写前端，它经常会按自己的想象编字段名，而如果让它先看后端代码，这个问题就很少出现。

数据库这一环在开发环境里通常用SQLite就能跑通逻辑。等整个流程验证通过，再考虑换成正式数据库。这也是规格驱动开发的一个优势，因为Spec里写明了对数据模型的约束，切换数据库时影响面可控。

4.4 验证与收尾：测试、文档、提交

全栈功能实现完，并不代表项目就交付了。我通常会做三件收尾的事。

第一件是人工走一遍关键路径。AI自测再详细，也替代不了人的真实使用感受。我会在浏览器里实际操作一遍注册、登录、新增待办、标记完成、编辑、删除，看看交互是否流畅，有没有哪个按钮点了没反应。

第二件是让Codex补充项目文档。基于Spec和实际实现，生成README，写清楚启动方式、接口列表和一些注意事项。这一步成本很低，但价值很大，尤其是项目过两周后再回来看，没有文档的自己也会感谢当时的自己。

第三件是把Spec和代码一起提交到版本库。这个习惯是我强烈建议的。Spec不是一次性文档，它是项目的一部分。后续需求变更时，先改Spec，再让Codex按新的Spec来调整代码，整个演进过程都有迹可循。

git init git add . git commit -m "feat: 按spec实现待办事项全栈应用"

到这里，一个从Spec到全栈应用的完整闭环就结束了。

5. 常见问题与排查技巧实录

5.1 “模型不支持”报错

Codex本身更新很快，模型支持情况变化也不小。经常有人反馈说，启动Codex时报出“the 'gpt-5.6-sol' model is not supported”之类的错误。

这类报错通常有两个来源。一个是你当前登录的账号类型不支持该模型。比如用ChatGPT账号登录时，某些模型可能只对指定订阅级别开放，用API Key登录时能选的模型范围就可能不一样。另一个是你的配置文件中显式指定了模型，但Codex当前版本或当前账号权限里有变化，导致模型不可用。

排查思路很简单：先看看是不是配置文件里手动指定了不支持的模型。如果在codex.toml或启动参数里写了模型名，先去掉，让Codex使用默认模型，再跑一次。如果确认账号或权限问题，就换一种登录方式，或者升级订阅方案。模型名这类信息变化很快，遇到报错时以当前官方文档为准，不要死磕旧教程里的参数。

5.2 上下文溢出：Codex ran out of room

用Codex跑长任务，尤其是全栈项目时，最常遇到的报错大概是“codex ran out of room in the model's context”。这个报错翻译过来就是上下文窗口塞满了。

为什么会塞满？因为Codex在执行任务时，会持续读取文件、记录中间推理过程和命令输出，这些内容都会占用上下文。任务越长、文件越多、对话轮次越密集，上下文被撑爆的概率就越高。

应对方法有三个层面。第一个层面是拆分任务，这也是规格驱动开发天然的优势。Spec已经把功能分成了注册、登录、待办管理等多个模块，那就一个模块一个模块地交给Codex，不要在一个会话里同时做后端、前端、数据库、联调、文档。第二个层面是在开始新阶段时重新开一个会话，每次只带目标和最少量的历史内容。第三个层面是不需要跟踪的中间文件，不要让Codex读取，减少不必要的上下文占用。

如果你用了--skip-prompts跑超长任务，也要注意控制任务的粒度。我第一次跑一个包含完整前后端的项目时，试图在一个会话里全部完成，结果执行到一半就遇到上下文溢出的报错，前功尽弃。后来改成每次只做一个模块，问题迎刃而解。

5.3 安装与启动异常

Codex安装和启动阶段也有一些常见问题，我整理成了一张速查表。

这里特别说一下“invalidversionspecerror”这类版本解析报错。它通常出现在安装依赖时，比如某个依赖项的版本号被写成了“=2.7”这种不标准的格式，或者本地缓存里记录了坏的版本信息。排查时先检查相关锁文件和依赖声明，实在不行就把依赖目录和锁文件清掉重新安装。

5.4 Codex生成的代码不符合Spec怎么办

最后一个常见问题非常现实：Spec也写了，流程也走了，但Codex生成的代码还是有不满足验收标准的情况，怎么办？

我的经验是不要立刻让它重写整个模块，而是先做精准反馈。AI在长任务里最容易犯的错误是“局部正确、整体偏离”，你让它重写整块，它反而可能把原本正确的部分也改坏。

正确做法是先把不符合的行为描述清楚，尽量给出可复现的触发条件。比如“按Spec，删除不存在的待办应返回404，但实际接口返回了500，请定位问题并修复”。这个提示词包含三个要素：期望行为、实际行为、复现条件。Codex拿到的信息越精确，修复越快。

如果多次反馈之后仍然不符合，你就需要检查Spec本身的信息密度了。很多时候不是Codex能力不够，而是Spec里某个边界条件仍然没有写清楚。比如“网络超时统一返回错误码10001”这种话，如果没说明超时阈值是多少毫秒、在什么环节判断，Codex实现出来的可能就是它自己脑补的版本。此时回到Spec，把缺失的部分补齐，再让Codex按补充后的验收标准调整，效果比盲目重试要好得多。

我在实际使用中发现，Codex对明确、可测试的验收标准的执行效率，要远远高于对模糊意图的理解。这让我越来越坚定一个做法：每次提交代码之前，先想清楚“这条功能的验收标准是什么”，把这个标准写下来，再交给Codex执行。当Spec足够好，Codex的表现才真的称得上可靠。

这套规格驱动开发的流程，我现在几乎每天都用。最开始我会觉得写Spec是在浪费时间，项目都那么赶了，哪有工夫先写文档。但跑完一个正式点的全栈项目之后，我就彻底改观了。现在我的节奏是，用大约四成时间把Spec写扎实，六成时间交给Codex跑实现和自测。表面上看给AI干活的时间变短了，但最终交付时间反而变短了。

最后再分享一个小技巧：Spec写完后，记得和代码一起纳入版本管理。需求变更时，第一时间更新Spec，再让Codex根据Spec的差异去改代码。这样一来，AI的每一次改动都有据可依，项目历史也不会变成一笔糊涂账。成长的路上，给AI多一点清晰输入，它回报你的产出质量会远超预期。