我给 Codex 加上 Superpowers 和 OpenSpec 后，才开始真正理解 AI Coding 工作流

上一篇我写了 Codex 怎么参与 Good Plan 的开发过程。那篇文章里我真正想说的不是“Codex 帮我写了多少代码”而是另一个感受AI coding 真的进入项目以后最考验人的地方往往不是写代码本身而是问题定义、任务拆解和结果验证。写完以后我觉得还缺一篇更具体的文章。因为对很多会写代码的人来说真正卡住的可能不是“Codex 有没有用”而是怎么把它放进一个稳定的工程流程里。是不是直接说一句帮我做一个 XX 系统。它当然会动起来。但这也是很多新手第一次用 AI coding 工具时最容易踩的坑。不是因为 Codex 不够强而是因为它太容易开始了。你还没有讲清楚项目是什么边界在哪里哪些地方不能动什么结果算完成它就已经可以生成一堆看起来很完整的代码。所以这篇文章不写安装教程也不做工具广告。这篇我想写得更具体一点我在 Good Plan 里试用 Codex 时是怎样围绕 Superpowers 和 OpenSpec把一个模糊需求先问清楚、写成规格、再小步实现和验证的。我的建议很简单第一次用 Codex不要急着让它写代码。先让它理解项目、理解问题再让它小步推进最后一定让它拿证据交付。这里先交代两个工具。Superpowers 的地址是https://github.com/obra/superpowers它的 README 里把自己定义成一套给 coding agents 使用的软件开发方法论建立在一组可组合 skill 和初始指令之上。它的核心思路不是让 AI 更快开写而是让 AI 在写代码前先停下来问清楚需求、形成设计、拆计划、用 TDD 推进、完成前验证。OpenSpec 的地址是https://openspec.dev/它负责的是另一层把一次变更写成规格。也就是先把 proposal、design、tasks 和 spec deltas 整理出来让人和 AI 在写代码前先对齐“这次到底要改什么”。所以这篇文章真正想讲的不是单独介绍 Codex也不是单独介绍某个 skill而是我试用下来更顺的一套组合Codex 负责执行Superpowers 负责协作节奏OpenSpec 负责规格边界。第一个误区把 Codex 当成更快的代码生成器很多人第一次用 AI coding 工具最自然的反应是把它当成一个升级版代码生成器。以前我们搜代码片段后来用 ChatGPT 问一个函数现在有了 Codex就想直接让它在项目里改文件。这个变化当然很大。但问题也在这里。当 Codex 可以直接读项目、改代码、跑命令、修错误时它已经不只是“帮你写一段代码”了。它在参与你的工程过程。如果你给它的只是一个很大的、边界模糊的目标比如帮我加一个积分系统。它可能会真的开始做。它会找数据库模型找接口找前端页面补一些字段写一些逻辑也许还会顺手加一点 UI。从表面上看这很爽。你一句话它动了一堆文件。但如果你没有提前说清楚这些问题后面就会很麻烦•积分是谁的积分•什么行为会增加积分•积分能不能扣减•重复操作怎么算•管理员能不能手动调整•有没有历史记录•第一版是不是只做最小闭环这些问题如果人不说Codex 也会补答案。只是那些答案不一定是你真正想要的。这就是 AI coding 新手最容易踩的坑不是它不干活而是它太能干活了。需求还没想清楚代码已经铺开了。边界还没定义文件已经改了十几个。验收标准还没说页面已经看起来能用了。所以我现在更愿意把 Codex 当成工程搭档而不是代码打印机。搭档的意思是它可以帮你推进但你要先告诉它方向、边界和完成标准。第一步先让 Codex 理解项目上下文如果你第一次在一个项目里用 Codex我建议不要马上说需求。先让它理解项目。很多人会在提示词里写你是一个资深工程师。这句话不是完全没用但用处有限。真正重要的不是它扮演什么身份而是它知道自己现在站在哪个项目里。拿 Good Plan 来说它后来已经不是一个单页 Demo。它是一个 pnpm monorepo里面有后端、前端和共享类型•packages/serverNestJS Prisma 后端。•packages/webVue 3 Vite Tailwind 前端。•packages/shared前后端共享枚举和常量。项目里还有docs/prd、docs/test、openspec、tests/api、tests/checks、tests/e2e这些目录。如果你第一次让 Codex 进入这样的项目最好不要只说“帮我改功能”。Good Plan 的AGENTS.md里就写了很多具体约束•所有 AI 回复、文档、注释和提交信息默认使用简体中文。•后端是 NestJS所有 API 路由前缀是/api。•family模块路径是/api/family不是/api/families。•业务枚举统一从good-plan/shared导入不从prisma/client导入。•NestJS 的Post()默认返回 201不是 200。•孩子登录用/api/auth/login加{nickname, password}没有独立端点。•本地验证可以跑路由检查、角色检查和 API 场景测试。这些规则看起来很细。但它们会直接决定 Codex 写出来的代码是不是贴合项目。如果没有这些上下文它可能会按自己熟悉的习惯生成接口路径可能会从错误的包里导入枚举也可能会把 201 当成异常情况去修。这类问题不一定是 Codex “不会写代码”。很多时候只是它不知道项目里的约定。一个好的AGENTS.md不是写几句客气话而是告诉 Codex•这个项目是做什么的。•技术栈是什么。•目录怎么分工。•常用启动、测试、检查命令是什么。•哪些文件可以改哪些文件不要随便动。•具体业务和技术约定是什么。•完成后要怎么验证。你可以把它理解成项目给 AI 协作者看的入职文档。人接手一个老项目第一件事也不是直接写代码而是看 README、看目录、看现有风格、看测试怎么跑。Codex 也一样。我现在比较常用的第一句话是请先阅读 README、AGENTS 和相关目录不要马上改代码。读完后用 5 条以内总结这个项目的结构、规则和你认为需要注意的边界。这句话的重点不是“总结”。重点是“不要马上改代码”。先让它读一遍项目它后面的判断才更像是在这个项目里工作而不是从外面空降一套想当然的方案。第二步用 brainstorming把需求问清楚上下文有了以后也不要急着让 Codex 开工。尤其是当你的需求还只有一句话时。比如帮我做一个奖励系统。这句话对人来说已经能懂大概意思。但对工程来说它还不够。奖励系统是给谁用的谁创建奖励谁兑换奖励兑换后要不要审核积分不足时怎么处理奖励会不会下架是否需要库存第一版要不要做通知这些问题不问清楚Codex 也可以写。但写出来以后你很可能会发现它做了一个“奖励系统”却不是你家里、你项目里、你当前阶段真正需要的那个奖励系统。所以我在第三篇里提到过brainstorming。在 Good Plan 这种项目里我把它理解成一句话需求没想清楚时先让 Codex 提问和收窄范围不要直接写代码。这个词听起来像头脑风暴容易让人以为是在发散创意。但我自己的理解更简单brainstorming 是让 Codex 先陪你把需求问清楚。它不是为了聊得更热闹而是为了在动手之前回答几个问题•这个需求解决什么真实问题•谁会使用它•第一版必须做什么•哪些东西只是看起来不错可以先不做•什么结果算完成•哪些已有流程不能被破坏所以比起直接说帮我给项目加一个积分系统。我更推荐这样开始我们先不要写代码。请先和我一起梳理积分系统的使用场景、角色、边界和第一版范围。一次只问我一个问题直到需求足够清楚。这句话有几个关键点。第一先不要写代码。第二一次只问一个问题。第三目标不是发散而是收窄到第一版范围。这对新手很重要。因为 AI coding 最大的诱惑就是让你误以为“开始写”就是“开始推进”。但很多时候真正的推进发生在写代码之前。你把问题讲清楚了后面的实现才会稳。你没讲清楚后面的代码越多返工越多。第三步用 OpenSpec 把需求拆成规格和任务需求问清楚以后下一步也不是马上让 Codex 改代码。我会先让它进入 SDD也就是 Spec-Driven Development。这一步听起来有点像流程负担。尤其是个人项目里很容易觉得就我一个人写什么计划直接改不就行了。以前我也常这样。但 AI 参与以后我越来越觉得规格不是为了显得正式而是为了防止 Codex 跑偏。一个好的计划至少要说清楚三件事第一这次改什么。第二这次不改什么。第三怎么判断它完成了。比如你要做积分系统计划里应该写清楚•这一版只支持完成任务后增加积分。•暂时不做积分商城。•暂时不做管理员手动调整。•要补一条积分变更记录。•要有测试证明重复打卡不会重复加分。•前端只展示当前积分不做复杂统计。这样 Codex 后面写代码时就不会顺手把商城、排行榜、成就系统一起加进来。你也更容易审查它的结果。OpenSpec 的定位就是轻量级 spec-driven framework。它会围绕一次变更生成 proposal、design、tasks 和 spec deltas让人和 AI 在写代码前先对齐“这次到底要改什么”。在 Good Plan 里这部分就落在openspec/changes/archive下面。比如•2026-03-05-good-plan-mvp•2026-03-06-reward-shop-enhance•2026-03-06-habit-reminder-system•2026-04-04-mobile-app-mvp•2026-04-05-multi-mode-growth-system这些目录不是为了好看。它们是在记录每一轮变化的 proposal、设计取舍、任务拆解和规格变化。不一定每个个人项目都要写很重的规格文档。但至少要有一个轻量版本•背景是什么。•目标是什么。•范围是什么。•不做什么。•任务怎么拆。•验收标准是什么。我会这样说请按 OpenSpec / SDD 的方式先为这个需求整理一份轻量规格背景、目标、范围、不做什么、任务拆解和验收标准。先不要动代码。Good Plan 后来能一轮一轮推进也是因为每次都尽量先说清楚这一轮要解决什么。先做 MVP再补奖励商店再补习惯频率再补提醒系统再补移动端和质量门禁。它不是一次生成出来的。它是一轮一轮被推进出来的。这个节奏对 Codex 很重要。任务越清楚它越像工程搭档。任务越模糊它越像一个很勤快但方向不稳定的执行者。第四步小步实现每次只让它推进一件事有了计划以后才进入实现。这时新手还会遇到一个诱惑既然 Codex 能干那就让它多干一点。比如一次性说把后端接口、前端页面、测试、文档都一起做完。不是绝对不行。但对第一次使用 Codex 的人我不建议这样。因为改动范围一大你就很难判断每一步到底发生了什么。后端模型改了接口改了前端状态改了路由改了测试也改了。一旦报错你不知道问题出在数据结构、接口返回、页面调用还是测试本身写错了。这时候 Codex 也许能继续修。但你会越来越被动。我更推荐小步推进。比如这次只实现后端积分记录不改前端页面。完成后告诉我修改了哪些文件以及怎么验证。或者这次只接前端展示不改后端接口。如果发现后端接口不够用请先说明缺口不要直接扩展接口。再比如请不要顺手重构无关代码。如果发现无关问题单独记录不要混在这次修改里。这些提示看起来啰嗦。但它们会帮你保住节奏。AI coding 不是让你一次性把项目扔出去然后等它带回来一个成品。更稳的方式是每次只让它推进一块然后你检查、验证、确认再进入下一步。这和以前人写代码其实很像。好的工程师也不会在一个提交里同时改业务逻辑、UI 样式、数据库结构、构建脚本和无关重构。Codex 只是让这种纪律变得更重要。因为它动手太快了。你不给边界它真的会帮你把很多东西一起动了。第五步用 TDD 和验证收尾如果这篇文章只能留下一个提醒我希望是这一句Codex 写完代码不等于任务完成。这是我做 Good Plan 时很深的感受。AI 可以很快写出页面、接口、状态和测试。但系统是不是真的能用不能只看代码有没有生成。页面能打开不代表业务流程跑通。没有报错不代表没有问题。接口返回 200也不代表权限、角色、数据状态都正确。第三篇里我提过Good Plan 曾经修过一些很典型的问题。有些页面跳到了不存在的路由结果空白。有些家长创建完习惯后被带到了孩子视角页面调用了不该调用的接口。还有一些catch把错误吞掉页面看起来没崩但实际上用户什么也做不了。这些问题最麻烦的地方不是它们报错很吓人。恰恰相反它们有时候不吓人。它们只是让系统看起来“好像没坏”。所以后来我越来越重视验证。这里对应的是 Superpowers 里的两类 skilltest-driven-development和verification-before-completion。前者强调 RED-GREEN-REFACTOR先写失败测试确认失败再写最小实现让它通过。后者对应 Superpowers 里的“Evidence over claims”没有新鲜的验证证据就不要轻易说完成。TDD 对我最大的提醒不是“你必须写很多测试”而是顺序先说清楚什么行为算对。如果是修 Bug最好先写一个能暴露问题的测试确认它失败。然后再做最小修改让测试通过。最后再整理代码。你可以这样要求 Codex请先补一个失败测试证明当前问题存在。测试失败后再做最小修改让它通过。如果不是严格 TDD至少也要让它在完成前给出证据。比如请运行与这次修改相关的最小验证命令并把结果告诉我。如果不能运行请说明原因。或者不要只说“已完成”。请告诉我你做了什么、验证了什么、还有什么风险。在真实项目里这些证据可以包括•类型检查是否通过。•单元测试或接口测试是否通过。•路由检查是否通过。•浏览器里核心流程是否跑通。•这次修改有没有影响已有页面。•哪些地方还需要人工复核。Good Plan 后来有一条质量门禁命令把类型检查、路由检查和 E2E 串起来。命令本身不神奇。真正重要的是心态变化以前我可能会问“这个功能写完了吗”现在我会多问一句“有什么证据说明它写完了”用 Codex 的最后一步不是感谢它写完代码。而是要求它交出证据。给新手的一套最小流程如果你是第一次用 Codex 做项目我建议先别追求复杂玩法。就按下面这 5 步来第一步写清项目上下文。至少准备好 README 和AGENTS.md。告诉 Codex 项目是什么、技术栈是什么、目录怎么分工、常用命令是什么、哪些边界不能碰。第二步用 Superpowers 的 brainstorming 先讨论需求。不要一句话直接开写。让 Codex 先问你问题把用户、场景、边界、第一版范围和验收标准问清楚。第三步用 OpenSpec / SDD 写规格和任务。让它先列出这次改什么、不改什么、怎么拆任务、怎么验证。规格确认后再实现。第四步小步实现。每次只推进一件事。尽量控制文件范围避免一次性改后端、前端、移动端、测试和文档。第五步用 Superpowers 的 TDD 和 verification 收尾。让 Codex 跑相关命令说明验证结果。你自己也要读 diff、看页面、跑关键流程。最后确认的不只是代码而是业务结果。这套流程刚开始会显得慢。尤其当你看到 Codex 几秒钟就能改一堆文件时会觉得前面的讨论、计划和验证有点磨人。但我现在越来越觉得这个“慢”是值得的。因为它减少的是后面的返工。它让 Codex 的速度用在正确的方向上。Codex 没有降低专业要求很多人讨论 AI 编程时会自然走向一个问题程序员是不是不重要了我自己的感受刚好相反。Codex 的确能写很多代码。但它没有替你决定真实问题是什么。它没有替你决定第一版做多大。它没有替你决定哪些取舍符合当前项目。它也不会天然知道某个结果是不是真的能交付。这些判断仍然在人这里。只是程序员的专业能力开始往两端移动。往前你要更会定义问题。不是只说“做个功能”而是能讲清楚用户、场景、边界和成功标准。中间你要更会拆任务。不是一次性把所有东西扔给 AI而是把需求拆成能独立实现、独立验证的小步骤。往后你要更会验结果。不是看它有没有写代码而是看它有没有通过测试、跑通流程、留下证据还有没有隐藏风险。这可能才是会写代码的人第一次用 Codex 最该练的东西。不是怎么让它多写一点。而是怎么让它在正确的问题上小步写写完验验完再继续。如果说以前的程序员更多是在和代码本身较劲那么 AI coding 之后我们要更多地和问题、边界、证据较劲。Codex 可以成为一个很强的工程搭档。但前提是你不能把方向盘也交出去。第一次用它不要急着让它写代码。先让它理解你正在做什么。再让它理解你真正要解决什么。最后让它用可验证的结果证明这一步确实走对了。