Codex 这类 AI 编程助手接入工作流之后我身边几乎每天都有同事在同一个坑里摔跤明明 Codex 刚才还写得挺好换个人换个问法输出就变成了“看起来能用、一跑就炸”的废代码。一开始我以为是模型抽风后来对比了好几组提问才发现问题大部分出在提问本身——你给的信息颗粒度直接决定了 Codex 输出的质量上限。那段时间我自己也反复试错慢慢攒出了一套固定的提问模板后来整理成一张“急救卡”放在手边。说白了就是七种高频场景的标准问法再加上几种把模板串起来的组合方式。今天把这套东西完整写出来包含每一张卡的使用时机、背后的工作原理、以及我踩过的坑。适合正在用 Codex 写业务代码、又懒得每次想措辞的人也适合刚接触 AI 编程、不知道怎么开口的新手。1. 为什么提问方式决定了 Codex 的上限1.1 你说得越像需求文档Codex 越像资深开发Codex 本质上是一个基于海量代码和自然语言配对训练的生成模型它没有读心术也不会主动追问。你给出的是一个模糊的句子它就会用一个“模糊概率分布”去猜你想要的代码你给的是一个边界清晰、包含上下文、约束条件和输出格式的请求它就从一个“概率猜测器”变成能按要求执行任务的执行器。我做个不太精确但很好懂的类比Codex 像一个经验丰富但从来没见过你项目的外包开发你扔给它一句“帮我写个登录”它只能按行业最流行的模板写一套用户名密码登录但你告诉它“这是一个给内部运营用的后台系统前端用 Vue3登录接口要走现有的 /api/auth 网关Token 要存到 cookie 而不是 localStorage另外要兼容过期自动跳转”它写出来的东西才是能直接落地的。这背后的原理是模型在做下一个 token 的预测时你提供的上下文越具体候选的概率分布就越集中最终生成的代码就越贴合你的真实需求。很多人觉得 AI 编程“靠运气”其实只是还没学会给足信息。1.2 七个模板的选型逻辑覆盖日常开发的五种场景我整理这七张卡的时候不是凭空想的而是把日常开发里最常遇到的动作拆了一遍写新功能、改旧代码、查报错、做重构、理解陌生代码、以及多轮迭代。每个动作对应一种提问结构再把它们归纳成模板。这七个模板分别是场景锚定卡、任务明确卡、约束清单卡、代码注入卡、报错复盘卡、重构优化卡、追问迭代卡。用的时候可以单独出牌也可以两三张组合。比如你新接一个项目要改一个功能往往先用“场景锚定卡”交代项目背景再用“任务明确卡”说明要做什么最后用“约束清单卡”防止它放飞自我。这七张卡的选择逻辑有一个共同点每个模板都在回答模型最需要知道的一个核心问题。场景锚定回答“这是什么项目”任务明确回答“具体要我干什么”约束清单回答“哪些事绝对不能干”代码注入回答“现有代码长什么样”报错复盘回答“当前到底出了什么错”重构优化回答“你要的结果和不允许的代价是什么”追问迭代回答“我们刚才聊到哪了”。1.3 急救卡的正确用法不要背要拆很多人拿到模板以后第一反应是背下来下次提问把句子原封不动搬上去结果发现效果并没有想象中好。原因在于模板解决的是“结构问题”不是“内容问题”。你背下“请用 XXX 语言实现一个 XXX 功能”这句话没有任何意义真正有价值的是你往这个结构里填进去的细节。我自己的用法是拆成三层第一层是骨架也就是模板的句式第二层是变量也就是项目名、技术栈、文件路径、报错信息这些“本次专属信息”第三层是风格词比如“输出前先解释思路”“给出改动后的完整函数”这些控制 Codex 的输出形态。急救卡给的是第一层你要练的是往第二层和第三层填东西的手感。2. 七张卡每一张都带着使用场景2.1 场景锚定卡先告诉它“你在哪个世界”这张卡的使用时机是你要让 Codex 帮你处理一个它完全不了解的项目里的问题。很多开发者犯的错误是上来直接贴代码或者直接问“这个报错怎么办”但 Codex 对项目的技术栈、模块划分、接口规范一无所知自然只能给出最通用的答案。我的标准句式是我在维护一个 XXX 系统技术栈是前端框架 后端框架 数据库 部署方式目前主要负责 XXX 模块这个模块的代码入口在 src/modules/xxx/index.ts。现在我要处理的问题是XXX。注意几个细节技术栈要写全前端框架、后端框架、数据库、关键中间件一个都别省模块入口要写明最好带上相对路径项目背景要一带而过不要写三四段故事。Codex 的上下文窗口是有限的背景信息消费的是宝贵的 token 配额你要做的是用最少的词把最关键的信息说清楚。有一次我帮同事调一个问题他写了“我们有个管理系统登录有问题”Codex 给了一整套 session 和 JWT 的对比方案完全跑偏。我改成“内部运营后台Vue3 Spring Boot MySQL登录走网关 /api/auth目前登录成功后接口返回 401”Codex 立刻定位到了 Token 解析拦截器的写法上。差距就是这么明显。2.2 任务明确卡动词开头别用形容词这张卡是最基础的一步但我发现绝大多数人连这一步都做不扎实。比较一下这两种问法弱问法我想要一个搜索功能。强问法请用 Vue3 Composition API 实现一个搜索框组件输入关键词后调用 /api/search 接口结果列表防抖 300ms 再请求加载状态用 loading 变量控制。弱问法的问题在于“搜索功能”是一个抽象概念代码里没有“搜索功能”这个实体只有输入框、请求、渲染、状态管理这些具体零件。Codex 能做的只是把“常见搜索实现”的平均值吐出来至于它猜的是搜索框还是全文检索全看运气。任务明确卡的几个要点动词开头用“请实现”“请修复”“请解释”这类明确指令把任务拆成可验证的动作比如“写一个函数”“增加一个路由”“修改一个组件”涉及接口的把接口路径、请求方法、参数结构写出来哪怕是简写。我自己习惯在任务卡的最后加一句“如果我的需求存在理解歧义请先列出你的理解再开始写代码”。这句话能有效防止 Codex 闷头开写然后交出一堆返工货。2.3 约束清单卡把“别乱来”翻译成机器听得懂的话AI 编程最常见的一个问题就是“能跑但跑得很野”。你让它实现一个分页它给你引入一个全新的分页库你让它改个逻辑它顺手把变量命名风格都改了。这些“过度发挥”的来源就是提问里缺少约束。约束清单卡的核心是把你的红线一条一条列出来我通常用“必须 / 禁止 / 建议”三段必须保持现有函数签名不变兼容 Node 14不引入新的 npm 依赖。 禁止不要修改其它文件不要使用 any 类型不要用 async/await 重写已有 Promise 链。 建议优先复用 utils/request.ts 里的请求方法。为什么这三段有效因为模型在处理指令时对这些带有强烈逻辑含义的词必须、禁止、建议有更高的权重相当于给生成过程套上了硬性过滤器。只写“注意保持兼容”这种模糊表达模型很难把它转译成具体的代码约束。这里顺便提一个我踩过的坑约束不是越多越好。我曾经一次列了十几条约束结果 Codex 为了满足约束生成了一堆绕来绕去的代码可读性反而更差。约束要挑真正影响你的那几条一般五条以内就够了。2.4 代码注入卡贴代码要带“病历”很多人贴代码有一个坏习惯把两百行代码哗啦一下全扔进去然后说一句“这段代码有问题”。Codex 拿到的是没有上下文的代码块它既不知道这段代码属于哪个模块也不知道你期望它做什么。我的做法是贴代码时带上一份“病历”代码从哪来文件路径、功能是什么、哪里是你怀疑的病灶、你期望的输出是什么。比如文件 src/services/order.ts 中的 createOrder 函数完整代码见下用于创建订单但并发调用时偶发库存超卖。请分析这段代码的竞态条件并给出修复建议。重点关注 marked 的位置。这样贴代码等于帮 Codex 划定了重点区域。尤其是当代码超过一百行时一定要指出“重点关注大概在哪个函数、哪个区块”否则模型的注意力会被无关的逻辑分散给出的答案会泛泛而谈。代码块的格式也要讲究语言标记要写对python、javascript、typescript、bash 都要标清楚贴代码前尽量做最小化处理把无关的导入和工具函数删掉保留核心逻辑即可。我自己一般把目标代码精简到 30 到 80 行既保留上下文又不至于淹没重点。2.5 报错复盘卡报错信息 环境变量遇到报错问 Codex是所有人最早学会的用法但大多数人问得极度粗糙“报错了怎么办”报错信息只复述了前半句运行环境只字不提。结果是 Codex 只能靠猜一个错误可能对应十种不同原因。报错复盘卡的标准结构是操作步骤 运行环境 完整报错 怀疑对象。举个例子运行环境Node 18、TypeScript 5.3、MySQL 8.0。 复现步骤先启动本地服务然后调用 /api/user/update 接口时终端抛出了以下错误TypeError: Cannot read properties of undefined (reading map)对应的渲染代码在 src/components/UserList.vue 第 42 行。请帮我定位可能的原因并按概率排序给出排查方向。这一步为什么重要因为报错信息只是结果Codex 需要根据“环境 步骤”来推断因果链。同一个 “undefined 的 map”在 Vue 模板渲染里大概率是初始数据没赋值在 Node 后端里大概率是接口返回结构变了环境不同排查方向完全不同。还有一个小技巧报错信息一定要原样复制不要手打。我曾经手敲报错少了一个空格Codex 完全理解偏了。报错日志里的堆栈、时间戳、依赖版本这些看似无用的信息有时候反而是定位的关键。2.6 重构优化卡给目标给痛点给底线让 Codex 重构代码最忌讳的就是只说“这段代码太烂了帮我改好”。“烂”是一个主观评价模型不知道你眼里的“好好代码”长什么样。可能你在意的是性能它给你重写得花里胡哨你在意的是可读性它给你拆成十几个小函数。重构优化卡要明确三个东西目标、痛点、底线。这段代码功能正常但存在三个问题一是 processOrder 函数超过 200 行循环嵌套深二是变量命名混乱d1、temp、flag三是业务逻辑和数据处理耦合单测难写。我的重构目标是提高可读性和可测试性。底线是对外接口参数和返回结构保持不变不新增运行时依赖单次请求耗时不超过 300ms。请先给我重构方案确认后再改代码。这个例子里的“底线”尤其重要它决定了 Codex 在取舍的时候会怎么选择。没有底线模型会为了“优雅”把性能牺牲掉有了底线它就知道哪些地方的优化是禁区。我自己的经验是重构类任务最好要求 Codex“先方案后代码”也就是第一轮只输出重构思路和改动范围你确认之后再让它动代码。这能避免模型自作主张地大改特改也方便你在过程中发现它理解偏了的地方。2.7 追问迭代卡至少带上“上一次的结果”这是最容易被忽略的一张卡。很多人第一轮问完拿到代码第二句直接开一个新话题把之前的对话历史、方案选择全部扔掉。Codex 虽然会保留同一会话里的上下文但如果你发的是“这个还是不行”它不一定知道“这个”指的是什么。追问迭代卡的要点是每次继续对话都要用一两句话把当前状态同步给它。比如你上一步给的方案我已经按 A 方案参数校验放到入口处实现了功能能跑但现在并发量上来之后偶发超时。请不要重新设计方案基于现有代码继续排查重点看这一段贴代码。这种写法的价值在于它把“多轮对话”变成了状态同步让 Codex 能够继续沿着上一次的思路工作而不是每次都重新开始“猜”你的意图。我还发现一个规律每轮追问尽量聚焦一个问题。如果你一次说三个问题Codex 往往会选择性地处理其中一个或者平均用力导致每个都处理得不深入。宁可多追问几轮也不要在一句话里塞太多任务。3. 组合写法把单卡拼成提问配方3.1 黄金三段背景段 任务段 输出段单独的模板解决的是单一问题但大多数真实任务都至少涉及两个模板的需求。我自己在实战中最常用的是“黄金三段式”把场景锚定卡、任务明确卡、约束清单卡、以及输出格式放进同一个提问里分成三个段落发送。第一段是背景项目是什么、技术栈、相关文件在哪。第二段是任务你要它做什么用动词开头说清楚接口、数据、边界。第三段是输出你期望它交付什么形式的成果是完整代码、diff 片段、还是先给方案。实战例子背景我在维护一个商家后台的商品管理模块技术栈是 Vue3 Element Plus Pinia后端是 Java Spring Boot。 任务请帮我实现一个商品批量上下架的功能。前端需要一个弹窗勾选商品后点击“批量上架”按钮调用 /api/product/batch-status 接口请求体是 { ids: number[], status: 0 | 1 }。上架成功关闭弹窗失败按错误码提示。 输出给出弹窗组件和对应的 store action 代码接口调用放在 src/api/product.ts 里先列出改动文件清单再写代码。这样一段话发过去Codex 不太可能“发挥失常”。背景段解决了“在哪个世界”的问题任务段解决了“做什么”的问题输出段解决了“交付成什么样”的问题。3.2 多卡组合的实战案例一个功能从零到一组合使用最典型的一个场景是新功能开发我完整拆一个例子出来。第一轮用“场景锚定 任务明确 输出格式”组合维护一个基于 Next.js 14 的内部数据看板项目现有页面在 src/app/dashboard/。请新增一个“本周订单趋势”图表卡片数据来源是 /api/stats/weekly-orders返回结构是 { date: string, count: number }[]。使用 ECharts 渲染样式参考现有卡片组件 ui/Card.tsx。输出时先给出文件改动列表再给出每个文件的完整代码。第二轮基于第一轮的输出用“代码注入 追问迭代”继续按你给的方案我在 OrderChart.tsx 中接入了数据但初次渲染时图表宽度为 0导致折线图被截断。我猜测是容器还没有挂载就初始化了图表。当前代码是贴代码。请基于现状修复不要改数据结构。第三轮测试时发现新问题再用“报错复盘 约束清单”收尾接上一步修复后图表能显示了但页面切到其他 tab 再切回来时控制台报错 “ResizeObserver loop completed with undelivered notifications”。运行环境 Chrome 最新版。请修复 ResizeObserver 清理逻辑不要引入额外依赖也不要改动图表配置对象。三轮对话每轮都不长但每一轮都携带了足够的上下文和明确的边界。这种方式比打开一个新会话重新描述一遍项目要高效太多而且 Codex 的输出会越来越“懂你”。3.3 组合的小技巧占位符、分隔符与“参考答案”组合写法用久了还会碰到一些输出层面的问题我有几个小技巧可以分享。第一个是用分隔符把代码和指令明显区分开。比如在“代码注入卡”里贴代码前后都用三个反引号包裹并在代码块之前写清楚“下面是文件内容”这样 Codex 不会被大段代码干扰指令识别。有些模型对长上下文里的代码块解析不稳定清晰的包裹能让它更准确地定位“代码从哪里开始到哪里结束”。第二个技巧是在提问里加入“参考答案”。当你希望 Codex 按照某种特定风格写代码的时候找一段符合该风格的现有代码贴进去说“请参照这个文件的写法实现类似的 XXX 功能”。这比你写一百字描述风格要求都有效因为模型对代码风格的理解是直接的、模式匹配式的。第三个技巧是使用占位符预留变量。把常用的提问模板保存在笔记工具里用[项目名]、[技术栈]、[接口路径]这种占位符标记需要替换的地方。每次提问时套用模板替换变量既保证结构完整又不会漏掉关键信息。这其实就是“急救卡”的底层用法。4. 实测翻车现场与避坑清单4.1 翻车一只给一句话期待读心术我见过最典型的翻车是有人发了一句“帮我优化一下代码”然后扔了两百行代码。Codex 拿到一个没有目标、没有约束、没有背景的任务只能把它理解成“我做一次通用代码风格优化”于是改了一堆无关紧要的变量名核心问题一个没碰。这类翻车的共性就是提问者把模型当成了能自动理解“需求背后真实痛点”的同事但模型本质上是一个“指令跟随器”。给一条模糊指令它只能用一个模糊的平均策略来响应结果必然是“看似动了实际没动”。避免方式就是前面说的任何一次提问至少要回答三个问题之一——这个项目是什么、任务具体是什么、边界约束是什么。三个都答了最好答了其中一个也好过只扔一句话。4.2 翻车二报错信息只贴一半报错信息不完整是调试类翻车的头号原因。有一个下午我连续看到三个人问同一个类型的问题“这个 SQL 报错帮我看看”贴的却只是ERROR 1064后面那半行前面的完整语句、执行环境、数据量统统没有。Codex 每次都在补全缺失的信息而补全的方向纯靠猜测。有一次我同事贴报错只贴了最后一行 “Connection refused”没有贴完整的 Java 堆栈。Codex 判断是 Redis 连接被拒查了半天配置最后才发现是 RabbitMQ 挂了。只要把堆栈完整贴出来第一行就会告诉你具体是哪个组件的连接被拒。排查类提问的信息完整度优先级是完整堆栈 关键配置 操作步骤 代码片段。前两样缺一不可千万别只给结果。4.3 翻车三一次请求塞十个任务还有一种翻车是“贪多”。有人会在一次提问里写“帮我写用户注册、登录、忘记密码、第三方登录、短信验证码还有个人中心顺便把数据库表设计一下。”Codex 面对这种多任务请求通常的处理方式是挑一个它觉得最重要的详细写其他的草草带过。因为生成过程中注意力被任务列表分摊了。最终到手的代码里注册功能像模像样第三方登录只有一个 TODO 注释。这在视觉上非常有迷惑性因为它看起来是“写了”但你实际拿不到一个能跑的功能。我自己现在坚持一个原则一次提问只聚焦一个核心任务。如果确实需要它做多个模块也要分轮进行先完成一个再推进下一个而不是一盏茶里全部点名。4.4 翻车四把 Codex 当搜索引擎还有人把 Codex 当成搜索引擎来用问它“现在最流行的后端框架是什么”。这种问题不是 Codex 的强项它的知识有截止时间也不会去实时抓取最新的趋势数据给出的框架推荐可能会过时或者偏颇。Codex 真正擅长的是“基于你给的上下文生成代码、解释代码、修改代码”而不是当一个知识百科。想了解最新的框架生态建议去看官方文档和社区讨论想让 Codex 帮你用某个框架写代码才是在它的能力圈内。把用途分开之后你对 Codex 的期望值就能摆正也用不着一遇到“答不上来”就抱怨它不行。4.5 排查速查表我把自己踩过的坑整理成一个速查表顺手放在这里。翻车现象根因一分钟修复输出代码风格和项目不一致没有给“参考答案”或风格示例贴一段项目里的现有代码让它参照写法改 A 模块顺带改坏了 B 模块约束清单缺失加上“禁止修改 src/modules/b 目录下任何文件”报错定位没几天才找到真凶堆栈只贴了一半完整贴出报错信息和操作步骤别省一次请求回来只有一块能用任务堆太多拆成多轮一次一个核心任务兜兜转转几轮还没解决没有携带“上一次结果”用追问迭代卡把状态同步回去代码能跑但性能不符合预期缺少底线指标明确给出“单次耗时不超过 300ms”这类底线5. 我自己的使用习惯最后分享一点私货这套急救卡我用了挺长一段时间最后沉淀下来的使用习惯其实不是“背模板”而是两个很简单的原则第一每次提问之前拿出一分钟想一下“Codex 现在最缺哪条信息”缺项目背景就补场景缺任务定义就补动词缺边界就补约束第二把模板保存成笔记片段用占位符填充而不是每次从零打字。有个细节值得单独说一下同一类任务反复出现的时候我会提炼一个“专属模板”。比如我自己经常写数据报表页面就固定了一套“背景 接口结构 图表类型 空态处理 加载态要求”的组合写法每次新增报表页面只要替换接口和字段名就行。这种沉淀下来的模板比起通用的七张卡用起来顺手得多。Codex 这类工具的价值说到底还是取决于使用者的表达质量。急救卡给的是框架真正让框架生效的是你对项目的理解、对需求的拆解以及动手去试的耐心。写代码这件事AI 能做一部分剩下的还是得靠人。 
长河君 · 2026/10/15 7:40:58 · 阅读 1.2k Codex提问急救卡：7种模板让AI编程输出稳定高质量代码
Codex 这类 AI 编程助手接入工作流之后我身边几乎每天都有同事在同一个坑里摔跤明明 Codex 刚才还写得挺好换个人换个问法输出就变成了“看起来能用、一跑就炸”的废代码。一开始我以为是模型抽风后来对比了好几组提问才发现问题大部分出在提问本身——你给的信息颗粒度直接决定了 Codex 输出的质量上限。那段时间我自己也反复试错慢慢攒出了一套固定的提问模板后来整理成一张“急救卡”放在手边。说白了就是七种高频场景的标准问法再加上几种把模板串起来的组合方式。今天把这套东西完整写出来包含每一张卡的使用时机、背后的工作原理、以及我踩过的坑。适合正在用 Codex 写业务代码、又懒得每次想措辞的人也适合刚接触 AI 编程、不知道怎么开口的新手。1. 为什么提问方式决定了 Codex 的上限1.1 你说得越像需求文档Codex 越像资深开发Codex 本质上是一个基于海量代码和自然语言配对训练的生成模型它没有读心术也不会主动追问。你给出的是一个模糊的句子它就会用一个“模糊概率分布”去猜你想要的代码你给的是一个边界清晰、包含上下文、约束条件和输出格式的请求它就从一个“概率猜测器”变成能按要求执行任务的执行器。我做个不太精确但很好懂的类比Codex 像一个经验丰富但从来没见过你项目的外包开发你扔给它一句“帮我写个登录”它只能按行业最流行的模板写一套用户名密码登录但你告诉它“这是一个给内部运营用的后台系统前端用 Vue3登录接口要走现有的 /api/auth 网关Token 要存到 cookie 而不是 localStorage另外要兼容过期自动跳转”它写出来的东西才是能直接落地的。这背后的原理是模型在做下一个 token 的预测时你提供的上下文越具体候选的概率分布就越集中最终生成的代码就越贴合你的真实需求。很多人觉得 AI 编程“靠运气”其实只是还没学会给足信息。1.2 七个模板的选型逻辑覆盖日常开发的五种场景我整理这七张卡的时候不是凭空想的而是把日常开发里最常遇到的动作拆了一遍写新功能、改旧代码、查报错、做重构、理解陌生代码、以及多轮迭代。每个动作对应一种提问结构再把它们归纳成模板。这七个模板分别是场景锚定卡、任务明确卡、约束清单卡、代码注入卡、报错复盘卡、重构优化卡、追问迭代卡。用的时候可以单独出牌也可以两三张组合。比如你新接一个项目要改一个功能往往先用“场景锚定卡”交代项目背景再用“任务明确卡”说明要做什么最后用“约束清单卡”防止它放飞自我。这七张卡的选择逻辑有一个共同点每个模板都在回答模型最需要知道的一个核心问题。场景锚定回答“这是什么项目”任务明确回答“具体要我干什么”约束清单回答“哪些事绝对不能干”代码注入回答“现有代码长什么样”报错复盘回答“当前到底出了什么错”重构优化回答“你要的结果和不允许的代价是什么”追问迭代回答“我们刚才聊到哪了”。1.3 急救卡的正确用法不要背要拆很多人拿到模板以后第一反应是背下来下次提问把句子原封不动搬上去结果发现效果并没有想象中好。原因在于模板解决的是“结构问题”不是“内容问题”。你背下“请用 XXX 语言实现一个 XXX 功能”这句话没有任何意义真正有价值的是你往这个结构里填进去的细节。我自己的用法是拆成三层第一层是骨架也就是模板的句式第二层是变量也就是项目名、技术栈、文件路径、报错信息这些“本次专属信息”第三层是风格词比如“输出前先解释思路”“给出改动后的完整函数”这些控制 Codex 的输出形态。急救卡给的是第一层你要练的是往第二层和第三层填东西的手感。2. 七张卡每一张都带着使用场景2.1 场景锚定卡先告诉它“你在哪个世界”这张卡的使用时机是你要让 Codex 帮你处理一个它完全不了解的项目里的问题。很多开发者犯的错误是上来直接贴代码或者直接问“这个报错怎么办”但 Codex 对项目的技术栈、模块划分、接口规范一无所知自然只能给出最通用的答案。我的标准句式是我在维护一个 XXX 系统技术栈是前端框架 后端框架 数据库 部署方式目前主要负责 XXX 模块这个模块的代码入口在 src/modules/xxx/index.ts。现在我要处理的问题是XXX。注意几个细节技术栈要写全前端框架、后端框架、数据库、关键中间件一个都别省模块入口要写明最好带上相对路径项目背景要一带而过不要写三四段故事。Codex 的上下文窗口是有限的背景信息消费的是宝贵的 token 配额你要做的是用最少的词把最关键的信息说清楚。有一次我帮同事调一个问题他写了“我们有个管理系统登录有问题”Codex 给了一整套 session 和 JWT 的对比方案完全跑偏。我改成“内部运营后台Vue3 Spring Boot MySQL登录走网关 /api/auth目前登录成功后接口返回 401”Codex 立刻定位到了 Token 解析拦截器的写法上。差距就是这么明显。2.2 任务明确卡动词开头别用形容词这张卡是最基础的一步但我发现绝大多数人连这一步都做不扎实。比较一下这两种问法弱问法我想要一个搜索功能。强问法请用 Vue3 Composition API 实现一个搜索框组件输入关键词后调用 /api/search 接口结果列表防抖 300ms 再请求加载状态用 loading 变量控制。弱问法的问题在于“搜索功能”是一个抽象概念代码里没有“搜索功能”这个实体只有输入框、请求、渲染、状态管理这些具体零件。Codex 能做的只是把“常见搜索实现”的平均值吐出来至于它猜的是搜索框还是全文检索全看运气。任务明确卡的几个要点动词开头用“请实现”“请修复”“请解释”这类明确指令把任务拆成可验证的动作比如“写一个函数”“增加一个路由”“修改一个组件”涉及接口的把接口路径、请求方法、参数结构写出来哪怕是简写。我自己习惯在任务卡的最后加一句“如果我的需求存在理解歧义请先列出你的理解再开始写代码”。这句话能有效防止 Codex 闷头开写然后交出一堆返工货。2.3 约束清单卡把“别乱来”翻译成机器听得懂的话AI 编程最常见的一个问题就是“能跑但跑得很野”。你让它实现一个分页它给你引入一个全新的分页库你让它改个逻辑它顺手把变量命名风格都改了。这些“过度发挥”的来源就是提问里缺少约束。约束清单卡的核心是把你的红线一条一条列出来我通常用“必须 / 禁止 / 建议”三段必须保持现有函数签名不变兼容 Node 14不引入新的 npm 依赖。 禁止不要修改其它文件不要使用 any 类型不要用 async/await 重写已有 Promise 链。 建议优先复用 utils/request.ts 里的请求方法。为什么这三段有效因为模型在处理指令时对这些带有强烈逻辑含义的词必须、禁止、建议有更高的权重相当于给生成过程套上了硬性过滤器。只写“注意保持兼容”这种模糊表达模型很难把它转译成具体的代码约束。这里顺便提一个我踩过的坑约束不是越多越好。我曾经一次列了十几条约束结果 Codex 为了满足约束生成了一堆绕来绕去的代码可读性反而更差。约束要挑真正影响你的那几条一般五条以内就够了。2.4 代码注入卡贴代码要带“病历”很多人贴代码有一个坏习惯把两百行代码哗啦一下全扔进去然后说一句“这段代码有问题”。Codex 拿到的是没有上下文的代码块它既不知道这段代码属于哪个模块也不知道你期望它做什么。我的做法是贴代码时带上一份“病历”代码从哪来文件路径、功能是什么、哪里是你怀疑的病灶、你期望的输出是什么。比如文件 src/services/order.ts 中的 createOrder 函数完整代码见下用于创建订单但并发调用时偶发库存超卖。请分析这段代码的竞态条件并给出修复建议。重点关注 marked 的位置。这样贴代码等于帮 Codex 划定了重点区域。尤其是当代码超过一百行时一定要指出“重点关注大概在哪个函数、哪个区块”否则模型的注意力会被无关的逻辑分散给出的答案会泛泛而谈。代码块的格式也要讲究语言标记要写对python、javascript、typescript、bash 都要标清楚贴代码前尽量做最小化处理把无关的导入和工具函数删掉保留核心逻辑即可。我自己一般把目标代码精简到 30 到 80 行既保留上下文又不至于淹没重点。2.5 报错复盘卡报错信息 环境变量遇到报错问 Codex是所有人最早学会的用法但大多数人问得极度粗糙“报错了怎么办”报错信息只复述了前半句运行环境只字不提。结果是 Codex 只能靠猜一个错误可能对应十种不同原因。报错复盘卡的标准结构是操作步骤 运行环境 完整报错 怀疑对象。举个例子运行环境Node 18、TypeScript 5.3、MySQL 8.0。 复现步骤先启动本地服务然后调用 /api/user/update 接口时终端抛出了以下错误TypeError: Cannot read properties of undefined (reading map)对应的渲染代码在 src/components/UserList.vue 第 42 行。请帮我定位可能的原因并按概率排序给出排查方向。这一步为什么重要因为报错信息只是结果Codex 需要根据“环境 步骤”来推断因果链。同一个 “undefined 的 map”在 Vue 模板渲染里大概率是初始数据没赋值在 Node 后端里大概率是接口返回结构变了环境不同排查方向完全不同。还有一个小技巧报错信息一定要原样复制不要手打。我曾经手敲报错少了一个空格Codex 完全理解偏了。报错日志里的堆栈、时间戳、依赖版本这些看似无用的信息有时候反而是定位的关键。2.6 重构优化卡给目标给痛点给底线让 Codex 重构代码最忌讳的就是只说“这段代码太烂了帮我改好”。“烂”是一个主观评价模型不知道你眼里的“好好代码”长什么样。可能你在意的是性能它给你重写得花里胡哨你在意的是可读性它给你拆成十几个小函数。重构优化卡要明确三个东西目标、痛点、底线。这段代码功能正常但存在三个问题一是 processOrder 函数超过 200 行循环嵌套深二是变量命名混乱d1、temp、flag三是业务逻辑和数据处理耦合单测难写。我的重构目标是提高可读性和可测试性。底线是对外接口参数和返回结构保持不变不新增运行时依赖单次请求耗时不超过 300ms。请先给我重构方案确认后再改代码。这个例子里的“底线”尤其重要它决定了 Codex 在取舍的时候会怎么选择。没有底线模型会为了“优雅”把性能牺牲掉有了底线它就知道哪些地方的优化是禁区。我自己的经验是重构类任务最好要求 Codex“先方案后代码”也就是第一轮只输出重构思路和改动范围你确认之后再让它动代码。这能避免模型自作主张地大改特改也方便你在过程中发现它理解偏了的地方。2.7 追问迭代卡至少带上“上一次的结果”这是最容易被忽略的一张卡。很多人第一轮问完拿到代码第二句直接开一个新话题把之前的对话历史、方案选择全部扔掉。Codex 虽然会保留同一会话里的上下文但如果你发的是“这个还是不行”它不一定知道“这个”指的是什么。追问迭代卡的要点是每次继续对话都要用一两句话把当前状态同步给它。比如你上一步给的方案我已经按 A 方案参数校验放到入口处实现了功能能跑但现在并发量上来之后偶发超时。请不要重新设计方案基于现有代码继续排查重点看这一段贴代码。这种写法的价值在于它把“多轮对话”变成了状态同步让 Codex 能够继续沿着上一次的思路工作而不是每次都重新开始“猜”你的意图。我还发现一个规律每轮追问尽量聚焦一个问题。如果你一次说三个问题Codex 往往会选择性地处理其中一个或者平均用力导致每个都处理得不深入。宁可多追问几轮也不要在一句话里塞太多任务。3. 组合写法把单卡拼成提问配方3.1 黄金三段背景段 任务段 输出段单独的模板解决的是单一问题但大多数真实任务都至少涉及两个模板的需求。我自己在实战中最常用的是“黄金三段式”把场景锚定卡、任务明确卡、约束清单卡、以及输出格式放进同一个提问里分成三个段落发送。第一段是背景项目是什么、技术栈、相关文件在哪。第二段是任务你要它做什么用动词开头说清楚接口、数据、边界。第三段是输出你期望它交付什么形式的成果是完整代码、diff 片段、还是先给方案。实战例子背景我在维护一个商家后台的商品管理模块技术栈是 Vue3 Element Plus Pinia后端是 Java Spring Boot。 任务请帮我实现一个商品批量上下架的功能。前端需要一个弹窗勾选商品后点击“批量上架”按钮调用 /api/product/batch-status 接口请求体是 { ids: number[], status: 0 | 1 }。上架成功关闭弹窗失败按错误码提示。 输出给出弹窗组件和对应的 store action 代码接口调用放在 src/api/product.ts 里先列出改动文件清单再写代码。这样一段话发过去Codex 不太可能“发挥失常”。背景段解决了“在哪个世界”的问题任务段解决了“做什么”的问题输出段解决了“交付成什么样”的问题。3.2 多卡组合的实战案例一个功能从零到一组合使用最典型的一个场景是新功能开发我完整拆一个例子出来。第一轮用“场景锚定 任务明确 输出格式”组合维护一个基于 Next.js 14 的内部数据看板项目现有页面在 src/app/dashboard/。请新增一个“本周订单趋势”图表卡片数据来源是 /api/stats/weekly-orders返回结构是 { date: string, count: number }[]。使用 ECharts 渲染样式参考现有卡片组件 ui/Card.tsx。输出时先给出文件改动列表再给出每个文件的完整代码。第二轮基于第一轮的输出用“代码注入 追问迭代”继续按你给的方案我在 OrderChart.tsx 中接入了数据但初次渲染时图表宽度为 0导致折线图被截断。我猜测是容器还没有挂载就初始化了图表。当前代码是贴代码。请基于现状修复不要改数据结构。第三轮测试时发现新问题再用“报错复盘 约束清单”收尾接上一步修复后图表能显示了但页面切到其他 tab 再切回来时控制台报错 “ResizeObserver loop completed with undelivered notifications”。运行环境 Chrome 最新版。请修复 ResizeObserver 清理逻辑不要引入额外依赖也不要改动图表配置对象。三轮对话每轮都不长但每一轮都携带了足够的上下文和明确的边界。这种方式比打开一个新会话重新描述一遍项目要高效太多而且 Codex 的输出会越来越“懂你”。3.3 组合的小技巧占位符、分隔符与“参考答案”组合写法用久了还会碰到一些输出层面的问题我有几个小技巧可以分享。第一个是用分隔符把代码和指令明显区分开。比如在“代码注入卡”里贴代码前后都用三个反引号包裹并在代码块之前写清楚“下面是文件内容”这样 Codex 不会被大段代码干扰指令识别。有些模型对长上下文里的代码块解析不稳定清晰的包裹能让它更准确地定位“代码从哪里开始到哪里结束”。第二个技巧是在提问里加入“参考答案”。当你希望 Codex 按照某种特定风格写代码的时候找一段符合该风格的现有代码贴进去说“请参照这个文件的写法实现类似的 XXX 功能”。这比你写一百字描述风格要求都有效因为模型对代码风格的理解是直接的、模式匹配式的。第三个技巧是使用占位符预留变量。把常用的提问模板保存在笔记工具里用[项目名]、[技术栈]、[接口路径]这种占位符标记需要替换的地方。每次提问时套用模板替换变量既保证结构完整又不会漏掉关键信息。这其实就是“急救卡”的底层用法。4. 实测翻车现场与避坑清单4.1 翻车一只给一句话期待读心术我见过最典型的翻车是有人发了一句“帮我优化一下代码”然后扔了两百行代码。Codex 拿到一个没有目标、没有约束、没有背景的任务只能把它理解成“我做一次通用代码风格优化”于是改了一堆无关紧要的变量名核心问题一个没碰。这类翻车的共性就是提问者把模型当成了能自动理解“需求背后真实痛点”的同事但模型本质上是一个“指令跟随器”。给一条模糊指令它只能用一个模糊的平均策略来响应结果必然是“看似动了实际没动”。避免方式就是前面说的任何一次提问至少要回答三个问题之一——这个项目是什么、任务具体是什么、边界约束是什么。三个都答了最好答了其中一个也好过只扔一句话。4.2 翻车二报错信息只贴一半报错信息不完整是调试类翻车的头号原因。有一个下午我连续看到三个人问同一个类型的问题“这个 SQL 报错帮我看看”贴的却只是ERROR 1064后面那半行前面的完整语句、执行环境、数据量统统没有。Codex 每次都在补全缺失的信息而补全的方向纯靠猜测。有一次我同事贴报错只贴了最后一行 “Connection refused”没有贴完整的 Java 堆栈。Codex 判断是 Redis 连接被拒查了半天配置最后才发现是 RabbitMQ 挂了。只要把堆栈完整贴出来第一行就会告诉你具体是哪个组件的连接被拒。排查类提问的信息完整度优先级是完整堆栈 关键配置 操作步骤 代码片段。前两样缺一不可千万别只给结果。4.3 翻车三一次请求塞十个任务还有一种翻车是“贪多”。有人会在一次提问里写“帮我写用户注册、登录、忘记密码、第三方登录、短信验证码还有个人中心顺便把数据库表设计一下。”Codex 面对这种多任务请求通常的处理方式是挑一个它觉得最重要的详细写其他的草草带过。因为生成过程中注意力被任务列表分摊了。最终到手的代码里注册功能像模像样第三方登录只有一个 TODO 注释。这在视觉上非常有迷惑性因为它看起来是“写了”但你实际拿不到一个能跑的功能。我自己现在坚持一个原则一次提问只聚焦一个核心任务。如果确实需要它做多个模块也要分轮进行先完成一个再推进下一个而不是一盏茶里全部点名。4.4 翻车四把 Codex 当搜索引擎还有人把 Codex 当成搜索引擎来用问它“现在最流行的后端框架是什么”。这种问题不是 Codex 的强项它的知识有截止时间也不会去实时抓取最新的趋势数据给出的框架推荐可能会过时或者偏颇。Codex 真正擅长的是“基于你给的上下文生成代码、解释代码、修改代码”而不是当一个知识百科。想了解最新的框架生态建议去看官方文档和社区讨论想让 Codex 帮你用某个框架写代码才是在它的能力圈内。把用途分开之后你对 Codex 的期望值就能摆正也用不着一遇到“答不上来”就抱怨它不行。4.5 排查速查表我把自己踩过的坑整理成一个速查表顺手放在这里。翻车现象根因一分钟修复输出代码风格和项目不一致没有给“参考答案”或风格示例贴一段项目里的现有代码让它参照写法改 A 模块顺带改坏了 B 模块约束清单缺失加上“禁止修改 src/modules/b 目录下任何文件”报错定位没几天才找到真凶堆栈只贴了一半完整贴出报错信息和操作步骤别省一次请求回来只有一块能用任务堆太多拆成多轮一次一个核心任务兜兜转转几轮还没解决没有携带“上一次结果”用追问迭代卡把状态同步回去代码能跑但性能不符合预期缺少底线指标明确给出“单次耗时不超过 300ms”这类底线5. 我自己的使用习惯最后分享一点私货这套急救卡我用了挺长一段时间最后沉淀下来的使用习惯其实不是“背模板”而是两个很简单的原则第一每次提问之前拿出一分钟想一下“Codex 现在最缺哪条信息”缺项目背景就补场景缺任务定义就补动词缺边界就补约束第二把模板保存成笔记片段用占位符填充而不是每次从零打字。有个细节值得单独说一下同一类任务反复出现的时候我会提炼一个“专属模板”。比如我自己经常写数据报表页面就固定了一套“背景 接口结构 图表类型 空态处理 加载态要求”的组合写法每次新增报表页面只要替换接口和字段名就行。这种沉淀下来的模板比起通用的七张卡用起来顺手得多。Codex 这类工具的价值说到底还是取决于使用者的表达质量。急救卡给的是框架真正让框架生效的是你对项目的理解、对需求的拆解以及动手去试的耐心。写代码这件事AI 能做一部分剩下的还是得靠人。