最近这半年我把 Codex 从“偶尔问一段”用成了“主力干活的搭档”和不少同行交流后发现一个特别普遍的现象工具明明是同一个有人一条提示词下去Codex 三秒内给出能跑的代码有人来回掰扯十几轮拿到的东西还是没法落地。多数人把这个差距归结为运气或者干脆觉得 Codex 能力不行。但我在几十次失败重试之后得了一个很扎心的结论问题基本出在提问方式上。这篇就是想把我自己整理出来的“程序员 Codex 提问急救卡”完整放出来。核心是七张可以直接抄的模板外加一套把这些模板组合起来的写法。内容适合日常已经在用 Codex、但经常觉得它答非所问的开发同学也适合刚开始接触这类 AI 编码助手、想少走弯路的新手。我不会跟你讲那些悬在空中的大道理只讲我用踩坑经历换来的实操套路。看完你就能照着用。1. 先搞清楚 Codex 到底吃哪一套1.1 Codex 眼中的“读懂”和我们想的不一样在聊模板之前得先明白一件事Codex 不是你平时聊天那种“心有灵犀”的同事。它本质上是一个基于概率生成内容的模型你输入的提示词是它的上下文它在此基础上一步一步预测下一个最可能出现的 token最终组装成一段完整回答。你给的信息越明确它顺着概率走出来的路径就越接近你想要的答案信息一旦缺失它就按统计上“最可能的情况”去补全。这就是为什么同一个需求换两种说法结果能天差地别。打个不太严谨的比方你让刚入职的实习生去“把数据整理一下”他大概率会按自己理解的整理方式动手结果十有八九不是你要的但你说清楚“把 A 列的日期转成 YYYY-MM-DD 格式、去掉 B 列的空行、输出到新 CSV”他哪怕没经验也知道从哪儿下手。Codex 和实习生的这个共同点是所有提问技巧的地基。1.2 一次提问丢三落四等于让 Codex 猜谜再看一个具体的对比。这是我之前在项目群里看到有人实际犯过的错误很典型“帮我写个排序函数我的数据好像有问题。”Codex 拿到这个要求它凭什么知道它不知道你的数据长什么样、不知道要按什么规则排序、不知道在哪文件哪函数里改、也不知道改完之后怎么验证。所以它的回答一定是最通用的版本——大概率给你一段基础排序示例然后扔一句“请根据你的数据调整”。这不算它笨是信息真的不够。“在 src/utils/sort.js 中我有一个名为 sortRecords 的函数接收一个数组每个元素是 {id, name, score} 结构。当前返回结果顺序不稳定。请改成先按 score 降序、其次按 id 升序保持入参和返回值类型不变只改这一个文件。改完贴出完整函数并说明排序稳定性。”这里每个信息都对应了一层约束数据结构方便它正确写比较函数排序规则固定了结果文件范围防止误改其他逻辑接口不变保持兼容完成标准让它自己检查。这些就是七张卡片要覆盖的维度也是接下来所有模板的底层逻辑。写 prompt 这件事说白了就是在跟一个能力很强但缺乏常识的同事交代需求你需要替它补上所有它猜不到的背景。2. 七张提问急救卡按需取用这七张卡是我在大量试错之后整理出来的分别覆盖了日常开发里最高频的七种场景。每张卡的结构都一样适用场景、模板结构、实际案例。刚开始不用背直接对照着抄就行用多了自然就熟了。2.1 卡片一任务定义卡先把“干什么”说死适用场景从零开始写一个新功能、新脚本或者让 Codex 实现一段独立逻辑。这时最怕的是只给一个动词短语比如“写个排序脚本”然后就没有然后了。用【语言/技术栈】实现【核心功能】。 使用场景【场景描述】。 输入数据格式【结构】。 期望输出【结果】。 只需要涉及【文件/模块】其他部分不要动。实际案例用 Python 实现一个 CSV 差异对比脚本。 使用场景服务器导出的两份运营数据每天一次行数大概十万级。 输入数据格式都是逗号分隔第一行是列名主键是 order_id。 期望输出打印出新增记录数、删除记录数、字段变更记录数并把明细写入 diff_result.csv。 只需要涉及脚本本身不需要接入定时任务。为什么这个模板好用你细看每一句话都在缩小 Codex 的猜测范围语言确定了实现方向场景决定要考虑的约束输入输出格式定义了正确结果范围说明避免了它“顺手”改别的文件。很多第一次用这类工具的人问题就是省略了这些“看起来不用说的信息”。而在这个场景里信息密度直接决定输出质量。我个人的一个小建议如果你不确定需求里的“期望输出”到底是什么就先花两分钟把输入输出在纸上画一遍。这个动作逼你把模糊的想法变成明确的标准比任何技巧都有效。很多时候你连自己都没想清楚却怪模型不给力这就说不过去了。2.2 卡片二上下文补全卡把背景一次性喂进去适用场景项目已经有相当规模的代码Codex 需要基于现有代码做改动或分析。这时候如果你只丢一句“帮我优化下登录逻辑”它根本不知道登录逻辑在哪个文件、用了什么框架、有什么历史包袱。背景我正在做【项目类型】。 项目结构相关部分【目录或文件说明】。 当前代码位置【具体文件函数】。 已完成到什么程度【能跑/不能跑跑到哪一步】。 最终目标【描述最终想要的样子】。 之前尝试【方法】结果【效果】。实际案例背景我正在做一个小型内部工具用于批量处理前端导出的 Excel 报表。 项目结构相关部分后端只有一个 app.py前端是 Vue3 Vite。 当前代码位置app.py 里的 process_report() 函数。 已完成到什么程度接口能跑通但处理 5000 行数据时响应时间到了 8 秒。 最终目标把处理时间降到 2 秒以内。 之前尝试加了内存缓存效果不明显。这种问法的价值在“省轮次”。Codex 不像人那样会主动问“你还有其他背景信息吗”它会直接按现有信息作答。你第一轮提供的背景越充足后续返工的概率就越低。我见过太多人在对话进行到第三轮才想起来补一句“哦对我们其实用的是 Vue 不是 React”这时候整个方案已经跑偏代价就大了。上下文补全卡的本质就是替 Codex 省掉一段它本可以问你的话。2.3 卡片三约束条件卡提前说清哪些不能碰适用场景你已经明确知道雷区在哪比如不能用某个依赖、必须兼容某个旧版本、不能在服务端跑某些操作。这些信息如果不在 prompt 里说清楚Codex 大概率会选择最省事的路径而“最省事”常常就是那个雷区。必须满足 1. 【硬性约束如禁止额外依赖】 2. 【性能或资源约束】 3. 【兼容性约束】 禁止使用【排除的技术或方案】。实际案例用 Python 实现文件去重逻辑。必须满足 1. 不引入第三方依赖只用标准库。 2. 单个文件大小可能 2GB 以上内存占用要控制在 500MB 内。 3. 运行环境是 Python 3.8不能用 3.10 的语法特性。 禁止使用hashlib 以外的文件校验方式。为什么约束要写得这么细因为这是同类模板里最能决定上限的部分。Codex 的省事倾向很强你给它一个不带约束的需求它往往会选最偷懒的实现随手 import 一个方便的第三方库。如果你的环境装不了、或者你所在团队有依赖策略这个坑就来了。但有一点挺微妙约束不是越多越好。给太多约束会让 Codex 陷入“既要又要还要”的僵局最后产出一个处处妥协的四不像方案。我的经验是只写你真正强制要求的项把优先级最高的那条放到最前面。这样 Codex 知道什么是不可逾越的红线什么是可以弹性处理的次要项。2.4 卡片四验收标准卡替 Codex 定义“什么叫写完”适用场景一整段新代码生成以后你希望它拿过来就能用而不是“看起来对实际一跑就炸”。验收标准卡的核心作用是强制模型在生成阶段就完成一轮自我检查。完成标准 1. 行为输入【样例】时应当输出【结果】。 2. 边界空输入 / 异常输入时应当【怎样处理】。 3. 性能数据量【规模】时时间/内存应不超过【指标】。 请写完先按标准自查一遍不满足就不要提交。实际案例写一个 Python 函数 parse_line(line: str) - dict用于解析日志行。 完成标准 1. 输入 INFO 2024-01-15 10:00:03 user123 login success返回含 level、time、user、action、status 五个字段的 dict。 2. 输入空字符串或格式完全不对的字符串时返回 None不抛异常。 3. 批量解析 100 万行时单函数性能不低于每秒 10 万行。 请写完先按这三条自查不满足就不要提交。注意这里的关键词是“自查”。Codex 默认给的是一个它自我感觉良好的答案但它并不清楚你后面怎么调用。你给它一份明确的验收清单等于给了一把检查用的尺子它在生成时就会朝着这些标准使劲。实操里我经常把验收标准放在提示词末尾让它在生成完代码后直接用这套标准过一遍自己。有一点从不变验收标准一定要写进 prompt而不是等 Codex 回复之后再来一句“你这个不对”。先写标准它一次做对的概率能翻一倍。尤其是边界条件比如空输入、超长输入、非法输入你不写它默认不处理。2.5 卡片五错误定位卡带着“现场证据”来问问题适用场景代码报错、运行结果不符合预期、需要定位问题根源。这个场景最容易犯的错是只丢一句“报错了帮我看看”然后附一个残缺的错误片段。Codex 能获得的信息太少只能从错误信息的字面意思随便猜一个方向。执行命令【操作步骤】。 报错信息 【完整错误原文】 相关代码 【关键代码片段不需要全部贴】 我已经排查过 1. 【试过的方向】无效。 2. 【试过的方向】无效。 请按可能性从高到低列出原因并告诉我每一步如何验证。实际案例执行命令node src/index.js 报错信息 TypeError: Cannot read properties of undefined (reading length) at processData (src/index.js:42:23) 相关代码 const rows await getRowsFromDb(); for (let i 0; i rows.length; i) { ... } 我已经排查过 1. 确认了 getRowsFromDb 能正常返回不是接口本身的问题。 2. 试着在报错前打印 rows发现打印结果是 undefined。 请按可能性列出原因并告诉我每一步如何验证。这个模板把 Codex 从“佛系猜谜”拉回“侦探排查”。最关键的其实是“我已经排查过”那一块。Codex 很容易沿着错误信息的字面意思推测一个常见方向而不去想你已经在别的方向试过了。你明确告诉它排除项它的搜索空间一下就小了接下来给出的分析会直接切入剩余的可能性。这里提醒一句代码片段不要贴完整文件尤其是几百行的大文件。贴多了反而稀释注意力、增加 token 消耗。原则是“刚好能看懂就行”一般 10 到 30 行就够了。错误信息同样要贴完整错误而不是只贴最后一行的摘要。2.6 卡片六重构优化卡保持行为、改内部结构适用场景代码能跑但你想优化可读性、性能、可测试性。这类需求最容易翻车的地方就是你让 Codex “优化”代码它给你来一个彻头彻尾的重写表面上看代码漂亮了实际上某个隐藏行为被改了业务逻辑当场炸掉。现有代码在【文件函数】。 问题【具体问题列表比如嵌套过深、重复逻辑多、性能瓶颈】。 要求 - 保持对外接口和函数签名不变。 - 保持现有行为和边界情况不变。 - 提升【可读性 / 性能 / 可测试性】。 请分步给出改动清单并标注每个改动点可能影响的范围。实际案例现有代码在 src/services/user_service.js 里的 getUsers() 函数。 问题函数里嵌套了三层 if/else读起来很费劲部分逻辑和其他函数重复。 要求 - 保持 getUsers() 接收和返回的参数完全不变。 - 保持现有 URL 路径和 HTTP 状态码不变。 - 提升代码可读性把重复逻辑抽成单独函数。 请分步给改动清单并标注每个改动点可能影响的范围。“保持外部行为不变”这句提示是防止重构事故的保险丝。Codex 默认理解的重构是“变得更漂亮”而不是“保持行为不变的前提下变得更漂亮”。你不强调这一点它会自由发挥而自由发挥在重构场景里的容错率很低。还有一个小经验重构请求里让 Codex 先列改动清单再动手。这样你能在写代码前先审一遍方向。如果它列的清单里有明显越界的行为变更你可以当场喊停要是直接让它写你可能要在一大坨改动里翻了半天才能发现某个行为已经被悄悄改掉了。2.7 卡片七追问推演卡让多轮对话真正往前走适用场景对话已经进行了一轮以上Codex 给了方案或代码你实际执行后有了新反馈。这时候最忌讳的是直接在原 session 里插一个模糊问题比如“还是不行啊你再想想”。Codex 没有你的执行结果它只能基于上一轮的旧信息继续猜。上一轮你给出的方案我已经做到【哪一步】。 实际执行结果【新结果 / 新报错附上必要信息】。 和预期不一致的地方是【差异描述】。 请基于这个新信息修正原方案只改动需要调整的部分不要推翻之前的整体设计。实际案例上一轮你给出的方案我已经把 log_parser.py 跑起来了。 实际执行结果能处理常规行但处理带引号的字段时报错比如 INFO 2024-01-15 log user123 login success 会多截断一部分。 和预期不一致的地方是我以为正则已经覆盖了带引号的内容但实际没有。 请基于这个新信息修正 parse_line 里的正则只改 parse_line不要动整体结构。多轮对话变差很多时候不是 Codex 记忆不够而是你没主动帮它建立“当前状态”。每次追问时用两三句话把执行进度重新描述一遍相当于给它续上了上下文。这就是为什么这卡片叫“追问推演”——它既在追问也在用实际执行结果做新的推演而不是空对空地聊方案。记住一个原则每一轮对话都要当第一次见面来交代关键信息。3. 组合写法把单卡拼成一套组合拳3.1 组合的基础逻辑四件事一次说清七张卡片单独都能用但我实际体验下来单卡解决问题的场景其实很少组合才是常态。原因很简单任何一次完整的需求交付都包含四个基本维度——目标是什么、手里有什么条件、不能碰什么、怎样算做完。目标要什么由任务定义卡负责条件现有背景由上下文补全卡负责限制红线在哪由约束条件卡负责完成标准做完的判断依据由验收标准卡负责。剩下三张卡应对的是动态过程错误定位卡在出问题时用重构优化卡在代码能跑但想变好时用追问推演卡在每一轮对话需要推进时用。理解了这层关系你就明白组合写法为什么更接近真实工作流它不是在机械拼接模板而是把一个完整需求拆成四个维度每个维度用对应的卡片说话。Codex 拿到的是结构化的“任务简报”而不是一段随意的人类碎碎念。3.2 三条最常用的组合公式第一条公式新功能开发场景任务定义卡加上下文补全卡加约束条件卡加验收标准卡。这四张卡一次打完适合“写一个新模块”或“做一个一次性脚本”的需求。目标、条件、限制、完成标准一次全部到位Codex 直接进入工程实现模式而不是猜谜模式。这四个维度只要缺一个后续就可能多出一到两轮返工。第二条公式调试排障场景错误定位卡加上下文补全卡加约束条件卡加追问推演卡。错误定位卡负责摆出现场情况上下文补全卡把项目背景补齐约束条件卡防止它用激进方案乱改追问推演卡确保在一轮分析后还有收敛出口。这条公式在处理“运行能通但结果不对”这类棘手问题的时候特别好用因为它既给信息又给排查方向还限定了修改范围。第三条公式渐进式优化场景重构优化卡加验收标准卡加约束条件卡。对已有代码做优化最危险的动作就是偷换行为。重构优化卡固定改动范围验收标准卡预先定义新旧版本必须遵守的边界行为约束条件卡给出性能等硬性指标。三张卡一合优化过程基本可控不会出现“改完才发现某个隐藏行为没了”的惨剧。3.3 一次组合的完整演示不同说法结果完全不同用同一个场景走一遍项目中有一个函数处理日期格式你希望它改成输出“年月日”格式同时不影响其他调用方。先看不改写之前的直接提问帮我改一下日期格式输出成年月日。这种问法的问题太多了哪个文件、哪个函数输入是什么格式是“2024-01-15”还是“2024/1/15”输出是“2024年1月15日”还是“20240115”?改完会不会影响其它模块任何一个不确定Codex 就只能猜猜错了你就得再纠正一轮。用组合写法重写一次背景这是内部报表生成项目入口在 src/report.js日期格式化函数在 src/format.js 里名字叫 formatDate。 任务把 formatDate 的输出格式从 2024-01-15 改成 2024年1月15日。 约束保持函数签名和输入类型不变只改 format.js 这一个文件不能动 report.js 中的任何调用方式。 完成标准传入 2024-01-15 返回 2024年1月15日传入 2024/01/15 也返回同样中文格式传入非法字符串时保持原行为不变。 请先粘贴改动后的完整函数再说明改动点。这么写Codex 不需要问任何问题就能直接开始干活而且大概率第一轮就能给你正确结果。这就是组合写法最直接的收益把一次“猜谜式交流”变成一次“工程任务下发”。你多花了三十秒组织语言省下来的是后续至少两三轮的来回扯皮。4. 完整实操用组合写法开发一个批量文件重命名工具这节我完整走一遍真实流程把前面几张卡的作用串起来看。目标是写一个 Python 小工具把某个文件夹里的照片按拍摄日期重命名例如 IMG_1001.jpg 变成 20230712_IMG_1001.jpg。这个需求足够典型能覆盖新功能、边界处理、报错修复三种常见阶段。4.1 第一轮把目标、条件、限制、标准一次都交代了我的第一轮提示词背景我在整理一个摄影项目的图片文件夹里面的文件命名是相机导出格式比如 IMG_1001.jpg、IMG_1002.jpg现在想统一在文件名前加拍摄日期。 项目结构文件夹 /photos 下有约 5000 张 jpg 图片没有嵌套子目录。 任务写一个 Python 脚本 batch_rename.py扫描 /photos 下所有 .jpg 文件用 exif 里的拍摄日期生成新名字格式为 YYYYMMDD_原文件名。 约束只使用标准库不依赖第三方库。如果图片没有 exif 拍摄日期保留原文件名不动。如果新文件名已存在在名字后加 _1、_2 避免覆盖。脚本只负责重命名逻辑不做删除操作。 完成标准对一张有 exif 的图片运行后文件名变成 YYYYMMDD_IMG_1001.jpg。对没有 exif 的图片文件名保持原样。对名字冲突的情况后处理的文件自动加上后缀。 请直接输出完整脚本并在代码里注释每个关键步骤。这一轮我同时启用了任务定义卡、上下文补全卡、约束条件卡、验收标准卡。Codex 几乎不需要追问就能理解完整需求。它输出脚本时也会因为验收标准里写明了三种边界行为而主动把这三个分支都处理掉。实际测试下来第一轮给出的脚本通常情况下已经能跑顶多需要小修。4.2 第二轮验收找茬用追问推演卡收紧细节拿到 Codex 输出的脚本后我自己先跑了一遍测试发现一个细节问题脚本对“新文件名已存在”的处理是直接覆盖原文件而不是加后缀。这里用追问推演卡修正上一轮你给出的 batch_rename.py 我跑了测试发现一个小问题当新文件名已存在时脚本会直接覆盖原文件。 实际结果两张不同图片被重命名成同一个名字时后处理的那张把前面那张覆盖了。 和预期不一致我明确要求过不能覆盖而是加 _1、_2 后缀。 请修正重命名冲突处理的逻辑只改相关函数保持其他部分不变并告诉我修改后的行为是什么。这里的关键是我没有把整个脚本推倒重来而是明确缩小了修改范围只聚焦冲突处理逻辑。Codex 收到的信号是其他地方都对只有这个分支要改。这种局部位修改的准确率明显比“你再看看整个脚本”高得多。第二轮结束之后脚本的冲突处理逻辑就正确了。4.3 第三轮补一个现实环境才会出现的问题实际运行时我又遇到一个新情况有些图片的 exif 日期字段缺失但文件名里包含了标准日期形式比如 Photo_20220101_001.jpg。这种文件如果在第一轮没被处理就只能保持原名。我想增加一个兜底逻辑。继续追问新信息我发现有一部分图片没有 exif 日期但文件名里包含日期形式比如 Photo_20220101_001.jpg。 任务在 batch_rename.py 里加一个兜底逻辑解析不到 exif 日期时尝试从原文件名匹配 YYYYMMDD 八位数字能匹配到就用这个日期匹配不到再保留原文件名。 约束保持现有函数签名不变不要影响已有行为只新增兜底分支。 请给出改动后的完整函数并说明新增分支的判断顺序。这个第三轮使用的也是“追问推演卡”加“上下文补全卡”的组合我先告知新信息再明确任务增量最后限定范围。Codex 不需要重新理解整个脚本只需要在原有基础上按新约束补一段逻辑。三轮下来脚本功能完整且行为明确整个过程没有产生过“跑偏式返工”。这个经验也验证了我前面说的多轮对话的质量取决于每一轮你提供了多少结构化新信息。5. 常见问题与排查技巧实录5.1 六个最常见的提示词事故现场我把我和同事们在使用 Codex 时经常踩的坑做了整理做成一张速查表。这张表基本覆盖了我见过的绝大部分沟通挫败场景你对照自己踩过的坑会发现根因几乎都指向同一个方向。现象根因解决办法Codex 给出的内容太泛像教材示例缺少约束和验收标准加上约束条件卡、验收标准卡反复让你解释需求迟迟不写代码上下文不足它不知道从哪开始用上下文补全卡把背景一次补齐生成代码能跑但性能完全没法用缺少性能指标约束在约束条件卡里写明时间和内存上限改动范围失控改了不该改的文件缺少范围限制明确“只改某文件/只涉及某函数”调试报错时给你重复试错方案没告诉它已经排查过的方向在错误定位卡里列出排除项多轮对话越聊越乱前后矛盾没在每轮重建当前状态用追问推演卡显式总结“上一步结果”这张表里前四条都属于“首次提问缺信息”后两条属于“动态过程没跟踪”。如果你发现自己频繁踩其中某一条说明你该把对应卡片内化成习惯而不是临时想起才用。5.2 让对话质量持续变好的三个习惯除了关键时刻用急救卡我还想分享三个让日常对话更省心的习惯。这三个都来自实际体验不是那种虚空建议。第一提问里带上项目结构的路径。哪怕只是一句“在 src/services/user_service.js 的 getUsers 里”也能让 Codex 把改动范围精准绑定到目标文件。大部分“改动范围失控”的事故就是因为开头没有给这个锚点。你要知道Codex 对具体文件路径的敏感度比你想象的高很多只要路径真实清晰它基本不会去碰别的地方。第二一次只让 Codex 管一件事。想让 Codex 同时改 A 函数的性能、调 B 接口的参数、加 C 模块的日志大概率三件事都做不好。原因不是能力不够而是信息量太大每个目标的上下文都在互相干扰。把它拆成三次提问每次聚焦一个目标输出的质量和可控性都会高很多。第三对话跑偏超过两轮就果断开新对话把关键结论在新对话里重新描述一遍。Codex 的上下文窗口是有限的轮次越多越容易出现前后矛盾和“遗忘”。与其在新一轮里花大段文字解释“我们之前聊到哪了”不如直接开一个新对话把当前项目状态、目标、已完成的部分重新组织成一轮干净的 prompt。这个习惯看着简单实际上能让你的平均效率提升一大截。老实说我一开始也觉得写 prompt 很麻烦——需求我自己心里清楚为什么还要额外花两分钟把它写出来但用了一段时间 Codex 之后我完全改观了。与其说是 Codex 难交流不如说它逼我把需求想得更清楚。以前跟同事对接我也经常甩一句“你帮我改下那个排序”然后大家互相猜半天。现在我把问题写成 prompt 之前反而多了一个自我检查的环节如果我自己都写不清楚“完成标准”那说明需求本身还没想明白。七张卡片看起来好像很多真正用顺了你会发现大部分场景就是两三张卡来回组合。我现在的习惯是新功能来了任务卡加约束卡加验收卡一起上跑出问题了错误定位卡加追问卡代码想优化了重构卡加验收卡。熟练以后写一条高质量 prompt 的时间也就一两分钟但换来的却是少走好几轮弯路。如果你正在被 Codex 这“看似不听话”的回复折磨不妨先别急着怀疑工具试着用这七张卡片重新组织一次提问。方法就摆在这里剩下的就是多试、多总结、慢慢形成自己的提问节奏。等哪天你发现一条 prompt 下去能直接拿到可用的代码你也会理解我为什么说练习提问比钻研任何花哨的功能按钮都更值得。