1. 为什么“会提问”成了程序员的新硬通货
我见过太多技术能力不差的人，在 Codex 这类 AI 编程助手面前栽跟头。同一个 bug，有人三句话拿到可运行的修复代码，有人来回拉扯十几轮还在原地打转。差距不在编码水平，而在提问方式。
Codex 本质上是一个代码生成与推理引擎，它没有读心术。你给它的输入越模糊，它返回的结果就越像“正确的废话”——语法没错、逻辑通顺、但跟你的项目毫无关系。反过来，当你把问题拆成它容易消化的结构，它给出的代码往往能直接粘进项目里跑起来。
这篇内容就是围绕“提问急救卡”这个思路展开的。所谓急救卡，就是当你卡住的时候，不用从零组织语言，直接套用一套经过验证的模板，把变量填进去就能用。我整理了 7 个高频场景的模板，外加几种组合写法，覆盖从报错排查、代码重构、性能优化到 API 设计、测试用例生成、正则编写、代码解释这些日常开发中最常遇到的场景。
适合谁看？如果你已经在用 Codex 写代码，但总觉得“它好像不太懂我”，或者你刚接触这类工具，想知道怎么问才能少走弯路，那这篇内容就是为你准备的。我不讲玄学，只讲可复现的提问结构和背后的逻辑。
2. 模板一：报错排查——把“报错信息”变成“可执行诊断”
2.1 为什么大多数人问报错的方式是错的
最常见的错误问法是：“我的代码报错了，怎么修？”然后贴一段几百行的代码。Codex 面对这种问题，只能靠猜。它不知道你用的什么语言版本、什么框架、什么运行环境，也不知道报错发生在哪一行、之前做了什么操作。结果就是它给你一段“看起来能跑”的代码，但你一运行，报错依旧。
正确的思路是：把报错排查当成一次“远程诊断”。你是在给一个看不见你屏幕的医生描述症状，信息越结构化，诊断越准确。
2.2 急救卡模板：报错排查
【环境】语言/框架/版本： 【操作】我执行了什么命令或调用了什么函数： 【预期】我期望的结果是： 【实际】实际报错信息（完整堆栈）： 【代码】相关代码片段（只贴报错涉及的部分）： 【已尝试】我已经试过哪些方法，结果如何：这个模板的核心在于“已尝试”这一栏。很多人会忽略它，但它能帮 Codex 排除掉那些你已经试过的无效方案，避免它重复给你同样的建议。我实测下来，加上这一栏之后，Codex 给出有效修复方案的概率明显提升。
2.3 一个真实场景的拆解
假设你在用 Python 的 pandas 读取一个 CSV 文件，报错UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb5 in position 0。如果你只贴这一行报错，Codex 可能会告诉你“用 encoding='utf-8'”，但这正是你已经在做的。
套用模板后，你的提问变成：
【环境】Python 3.10, pandas 1.5.3, Windows 11 【操作】pd.read_csv('data.csv') 【预期】正常读取并返回 DataFrame 【实际】UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb5 in position 0 【代码】df = pd.read_csv('data.csv') 【已尝试】已经试过 encoding='utf-8'，仍然报错；试过 encoding='utf-8-sig'，也报错这时候 Codex 就能推断出文件可能不是 UTF-8 编码，而是 GBK 或 GB2312，它会建议你尝试encoding='gbk'或者用chardet检测编码。这就是结构化提问带来的差异。
注意：贴代码片段时，只贴报错涉及的那几行，不要贴整个文件。Codex 的上下文窗口有限，无关代码会稀释有效信息。
3. 模板二：代码重构——让 Codex 按你的意图改，而不是自由发挥
3.1 重构类提问的核心矛盾
重构最怕什么？怕 Codex 把你的代码改得“面目全非”。你只是想让它把那个嵌套三层的 if-else 简化一下，结果它把你的函数签名改了、变量名换了、还引入了一个你根本没用的设计模式。
这个矛盾的根源在于：你没有告诉它“什么可以改，什么不能动”。重构类提问的关键，是划定边界。
3.2 急救卡模板：代码重构
【目标】我希望重构这段代码，目标是：（可读性/性能/减少重复/解耦） 【约束】以下内容不要改动：（函数签名/变量名/对外接口/特定逻辑） 【当前代码】 【期望风格】例如：使用早返回、使用列表推导式、拆分为多个小函数 【示例】如果方便，给一个你期望的重构后代码的片段“期望风格”这一栏很关键。不同团队有不同的代码风格偏好，有人喜欢早返回，有人喜欢单一出口；有人喜欢函数式，有人喜欢面向对象。你告诉 Codex 你的偏好，它就不会按它自己的“默认审美”来改。
3.3 约束栏的写法技巧
约束栏不是让你写“不要改太多”这种模糊的话，而是要具体。比如：
- 不要修改
process_data这个函数名，因为它在其他地方被调用 - 不要改变返回值的类型，必须是
list[dict] - 不要引入新的第三方库
- 保持现有的错误处理逻辑不变
这些约束越具体，Codex 的重构结果就越贴近你的预期。我个人的经验是，约束栏写三条以上，重构结果基本不需要二次修改。
3.4 一个重构实例的对比
假设你有这样一段代码：
def get_valid_users(users): result = [] for user in users: if user['age'] >= 18: if user['active'] == True: if user['email'] is not None: result.append(user) return result如果你只说“帮我重构这段代码”，Codex 可能会给你各种版本。但如果你套用模板：
【目标】提高可读性，减少嵌套 【约束】函数名不变，返回值类型不变，不引入新库 【期望风格】使用早返回或条件合并Codex 就会给出类似这样的结果：
def get_valid_users(users): return [ user for user in users if user['age'] >= 18 and user['active'] and user['email'] is not None ]干净、直接、符合你的约束。这就是模板的价值。
4. 模板三：性能优化——先定位瓶颈，再谈优化
4.1 性能提问的最大陷阱
“我的代码很慢，帮我优化。”这句话在 Codex 面前几乎等于没说。因为“慢”是一个相对概念，Codex 不知道你的数据规模、运行环境、性能基线，也不知道你所谓的“慢”是 100ms 还是 10s。
更糟糕的是，如果你直接贴一段代码让它优化，它可能会做一些微优化（比如把len()提到循环外），但这些往往不是真正的瓶颈。真正的瓶颈可能在算法复杂度、I/O 操作、数据库查询次数上。
4.2 急救卡模板：性能优化
【场景】这段代码的运行场景是：（数据处理/网络请求/数据库查询/计算密集型） 【数据规模】输入数据量大约为： 【当前耗时】目前耗时约为： 【目标耗时】期望优化到： 【瓶颈猜测】我怀疑瓶颈在：（某段循环/某个函数调用/某次 I/O） 【代码】 【已尝试】已经做过的优化：“瓶颈猜测”这一栏是灵魂。即使你猜错了，Codex 也能根据你的猜测去分析那段代码，而不是漫无目的地扫描整个片段。
4.3 性能优化的提问策略
我通常会把性能优化拆成两轮提问。第一轮先让 Codex 帮我定位瓶颈：
【场景】数据处理，输入是一个包含 10 万条记录的列表 【当前耗时】约 8 秒 【目标耗时】1 秒以内 【代码】以下是我的处理逻辑，请帮我分析最可能成为瓶颈的部分：等它指出瓶颈后，第二轮再针对那个具体部分问优化方案。这样比一次性问“怎么优化”要精准得多。
4.4 一个性能优化的实际案例
假设你有一个函数，功能是统计一个列表中每个元素出现的次数。你写的是：
def count_items(items): counts = {} for item in items: if item in counts: counts[item] += 1 else: counts[item] = 1 return counts如果你直接问“怎么优化”，Codex 可能会说“用collections.Counter”。但如果你套用模板，告诉它数据规模是 100 万条，当前耗时 2 秒，目标 0.5 秒，它就会进一步分析：Counter底层是 C 实现的，确实更快，但如果数据量再大，可能需要考虑用numpy的unique或者pandas的value_counts。这就是场景信息带来的差异。
5. 模板四：API 设计——让 Codex 帮你写出“像人设计的”接口
5.1 API 设计提问的特殊性
API 设计和前面几种场景不同，它不是“修”而是“造”。你需要 Codex 帮你从零设计一个接口，或者优化现有接口。这时候最大的挑战是：Codex 不知道你的业务上下文、调用方习惯、以及你对接口风格的偏好。
很多人问 API 设计的方式是：“帮我设计一个用户管理的 API。”这个提问太宽泛了，Codex 只能给你一个“教科书式”的 CRUD 接口，可能完全不符合你的实际需求。
5.2 急救卡模板：API 设计
【业务场景】这个 API 用于： 【调用方】谁会用这个 API：（前端/其他服务/脚本） 【核心操作】需要支持的操作有： 【输入输出】每个操作的输入参数和期望返回： 【风格偏好】RESTful / RPC / GraphQL；命名风格：驼峰/下划线 【约束】例如：不能有副作用、必须幂等、需要分页 【参考】如果有类似的现有接口，可以贴出来“调用方”这一栏经常被忽略，但它直接影响接口设计。给前端用的接口和给内部服务用的接口，设计思路完全不同。前端可能更需要聚合数据、减少请求次数；内部服务可能更看重单一职责和可组合性。
5.3 一个 API 设计实例
假设你要设计一个“任务管理”的 API，套用模板后：
【业务场景】一个内部工具的任务管理系统 【调用方】前端 React 应用 【核心操作】创建任务、查询任务列表、更新任务状态、删除任务 【输入输出】创建任务需要 title, description, assignee, due_date；查询支持按状态和负责人过滤 【风格偏好】RESTful，JSON 格式，字段用下划线 【约束】查询接口需要分页，每页最多 50 条；更新状态需要幂等Codex 就会给出类似这样的接口设计：
POST /api/tasks 创建任务 GET /api/tasks 查询任务列表（支持 ?status=&assignee=&page=&page_size=） PATCH /api/tasks/{id} 更新任务（幂等） DELETE /api/tasks/{id} 删除任务而且它会注意到你要求的下划线命名和分页约束，不会给你一个用驼峰命名、没有分页的接口。
5.4 API 设计提问的进阶技巧
如果你对某个接口的设计拿不准，可以让 Codex 给你两个版本对比。比如：
请给我两个版本的接口设计：一个偏 RESTful，一个偏 RPC 风格，并说明各自的优缺点。这种对比式提问能帮你快速看清不同设计取舍的利弊，比只看一个方案更有收获。
6. 模板五：测试用例生成——覆盖边界，而不是只测“正常路径”
6.1 测试用例提问的常见误区
“帮我给这个函数写测试。”Codex 通常会给你几个“正常路径”的测试，比如输入合法参数、返回预期结果。但真正有价值的测试，是边界测试和异常测试。
问题在于，Codex 不知道你的函数对边界输入应该有什么行为。比如一个除法函数，输入 0 作为除数时，是抛异常还是返回 None？你不告诉它，它就只能猜。
6.2 急救卡模板：测试用例生成
【被测函数】函数签名和功能简述： 【输入范围】参数的合法范围： 【边界条件】需要特别测试的边界值： 【异常预期】对于非法输入，期望的行为是：（抛异常/返回错误码/返回默认值） 【测试框架】pytest / unittest / jest / 其他 【覆盖要求】是否需要覆盖所有分支？是否需要 mock 外部依赖？“异常预期”这一栏是区分“能用”和“好用”的关键。你告诉 Codex 非法输入应该抛ValueError，它就会写with pytest.raises(ValueError):，而不是写一个模糊的assert result is None。
6.3 一个测试生成的实例
假设你有一个函数：
def divide(a, b): if b == 0: raise ValueError("除数不能为零") return a / b套用模板后：
【被测函数】divide(a, b)，返回 a 除以 b 的结果 【输入范围】a 和 b 都是浮点数 【边界条件】b 为 0、a 为 0、a 和 b 都是负数、a 和 b 都是小数 【异常预期】b 为 0 时抛出 ValueError 【测试框架】pytest 【覆盖要求】覆盖所有分支，不需要 mockCodex 就会给出完整的测试用例，包括正常除法、除零异常、零除以非零、负数除法、小数除法等。这些用例覆盖了函数的所有分支，比只测一个divide(10, 2) == 5要有价值得多。
6.4 测试用例提问的补充技巧
如果你想让测试更完善，可以追加一句：
请额外考虑浮点数精度问题，并给出相应的断言写法。这样 Codex 就会用pytest.approx来处理浮点数比较，而不是直接用==，避免因为精度问题导致测试误报。
7. 模板六：正则表达式——用自然语言描述，而不是自己拼符号
7.1 正则提问的痛点
正则表达式是典型的“写起来痛苦、读起来更痛苦”的东西。很多人写正则的方式是：先写一个大概，然后不断试错，直到能匹配为止。但这个过程在 Codex 面前可以大幅缩短。
关键是要用自然语言把匹配规则描述清楚，而不是自己先拼一个半成品正则让 Codex 改。你拼的半成品可能本身就方向错了，Codex 在你的错误基础上改，结果也不会对。
7.2 急救卡模板：正则表达式
【目标】我需要匹配/提取/替换的文本是： 【规则】匹配规则用自然语言描述： 【示例】给出 3-5 个应该匹配成功的例子： 【反例】给出 2-3 个不应该匹配的例子： 【语言】Python / JavaScript / Java / 其他 【特殊要求】是否需要忽略大小写？是否多行匹配？是否需要捕获组？“反例”这一栏极其重要。很多人只给正例，结果 Codex 写出的正则“过度匹配”，把不该匹配的也匹配上了。给出反例，Codex 就能收紧匹配规则。
7.3 一个正则实例的拆解
假设你想匹配中国大陆的手机号码。套用模板：
【目标】从文本中提取手机号码 【规则】11 位数字，以 1 开头，第二位是 3-9 之间的数字 【示例】13812345678、15900001111、18612345678 【反例】12345678901、1381234567、23812345678 【语言】Python 【特殊要求】不需要捕获组，只需要匹配Codex 会给出：
import re pattern = r'1[3-9]\d{9}'而且它会注意到你的反例，确保不会匹配到 10 位或 12 位的数字。如果你只给正例，它可能会给出1\d{10}，这个正则会把12345678901也匹配上，不符合你的要求。
7.4 正则提问的进阶用法
如果你需要提取多个字段，可以在模板中说明：
【目标】从日志行中提取时间戳、日志级别和消息内容 【示例】2024-01-15 10:23:45 ERROR Connection timeout 【特殊要求】需要三个捕获组，分别对应时间戳、级别、消息Codex 就会给出带命名捕获组的正则，方便你后续用groupdict()取值。
8. 模板七：代码解释——让 Codex 当你的“代码翻译器”
8.1 代码解释提问的场景
你接手了一个老项目，里面有一段看不懂的代码；或者你在网上找到一段实现某个功能的代码，但不确定它的逻辑；又或者你想确认自己写的代码是否真的按预期执行。这些场景都需要 Codex 帮你“翻译”代码。
但“解释这段代码”这个提问太宽泛了，Codex 可能会给你一个逐行翻译，也可能给你一个高层概括，完全取决于它的“心情”。你需要指定解释的粒度和重点。
8.2 急救卡模板：代码解释
【代码】 【解释粒度】逐行解释 / 按逻辑块解释 / 只解释核心逻辑 【重点】我特别想理解：（某段逻辑/某个变量的作用/某个函数的意图） 【背景】这段代码的用途是： 【输出格式】用列表 / 用段落 / 带注释的代码“重点”这一栏能帮你节省大量阅读时间。如果你只关心某个变量的计算逻辑，就告诉 Codex 重点解释那一部分，它会跳过那些显而易见的行。
8.3 一个代码解释的实例
假设你有这样一段代码：
def process(items): seen = set() result = [] for item in items: if item not in seen: seen.add(item) result.append(item) return result如果你只说“解释这段代码”，Codex 可能会逐行翻译。但如果你套用模板：
【解释粒度】按逻辑块解释 【重点】我想理解 seen 这个集合的作用，以及为什么需要它 【背景】这段代码用于处理一个可能有重复元素的列表Codex 就会重点解释：seen是一个辅助集合，用于记录已经出现过的元素，从而在遍历过程中去重。它还会说明这种写法的时间复杂度是 O(n)，比嵌套循环的 O(n²) 更高效。
8.4 代码解释提问的补充技巧
如果你想让解释更深入，可以追加：
请同时说明这段代码的时间复杂度和空间复杂度，以及是否有更优的写法。这样 Codex 不仅会解释代码，还会帮你评估代码质量，给出改进方向。
9. 组合写法：把多个模板串起来解决复杂问题
9.1 为什么需要组合写法
实际开发中，你遇到的问题往往不是单一维度的。比如你有一个函数，它既报错、又慢、还需要重构。这时候单独套用一个模板不够用，需要把多个模板组合起来。
组合写法的核心思路是：先定位问题，再分步解决。不要试图在一个提问里解决所有问题，而是把问题拆成多个轮次，每一轮聚焦一个模板。
9.2 组合写法示例：报错 + 性能 + 重构
假设你有一个数据处理函数，它报错了，而且即使修好之后也很慢，代码本身也写得比较乱。你可以这样组合：
第一轮，用报错排查模板定位错误：
【环境】Python 3.10, pandas 1.5.3 【操作】调用 process_data(df) 【实际】KeyError: 'user_id' 【代码】df['user_id'].apply(...) 【已尝试】确认过 df 的列名，确实有 'user_id'Codex 可能会告诉你，问题出在apply内部的某个操作上，而不是列名本身。
第二轮，用性能优化模板分析瓶颈：
【场景】数据处理，df 有 50 万行 【当前耗时】修复报错后约 12 秒 【目标耗时】3 秒以内 【瓶颈猜测】我怀疑是 apply 那一行 【代码】相关代码片段第三轮，用重构模板整理代码：
【目标】提高可读性，减少嵌套 【约束】函数名不变，返回值类型不变 【当前代码】修复并优化后的代码 【期望风格】使用向量化操作替代 apply这种组合写法看起来多花了几轮对话，但每一轮都聚焦一个明确的问题，Codex 给出的结果质量远高于一次性问“这段代码又报错又慢又乱，帮我改好”。
9.3 组合写法的注意事项
组合写法有一个前提：每一轮的输出要作为下一轮的输入。也就是说，你需要把上一轮 Codex 给出的修复代码，粘贴到下一轮的提问中。这样才能保证上下文连贯，不会出现“修好了报错但引入了新问题”的情况。
另外，组合写法不要超过三轮。如果三轮还没解决，说明问题可能不在代码层面，而在架构或需求层面，需要重新审视。
10. 提问急救卡的底层逻辑：让 Codex 少猜，让你少改
10.1 所有模板的共同结构
回头看这 7 个模板，它们有一个共同的结构：场景 + 约束 + 示例 + 期望。
- 场景：告诉 Codex 你在什么环境下、做什么事情
- 约束：告诉 Codex 什么可以动、什么不能动
- 示例：告诉 Codex 你期望的输入输出长什么样
- 期望：告诉 Codex 你希望它输出什么粒度、什么风格的结果
这个结构之所以有效，是因为它把 Codex 需要“猜”的东西降到了最低。Codex 不需要猜你的运行环境、不需要猜你的代码风格、不需要猜你的边界条件。它只需要在你给定的框架内生成结果。
10.2 从“问问题”到“下指令”的思维转变
很多人把 Codex 当成一个“问答机器人”，问它“这个怎么做”“那个怎么修”。但更有效的方式是把它当成一个“执行引擎”，你给它指令，它给你结果。
指令和问题的区别在于：指令有明确的输入、输出和约束。问题只有疑问。当你用指令的方式提问时，Codex 的回复会从“建议”变成“方案”，从“你可以试试”变成“这是代码”。
10.3 一个反直觉的结论
我实测下来发现，提问越长，Codex 的回复质量越高。这听起来反直觉，因为很多人觉得“问得简洁一点，它才好回答”。但实际上，Codex 的上下文窗口足够大，你给的信息越多，它越能理解你的真实意图。
当然，“长”不是指废话多，而是指结构化信息多。一个 200 字的模板化提问，比 50 字的模糊提问，效果要好得多。
10.4 最后的实操建议
如果你刚开始用这些模板，建议先从报错排查和代码重构这两个场景入手。这两个场景最高频，也最容易看到效果。等你熟悉了模板的节奏，再尝试组合写法。
另外，不要死记模板。模板是骨架，你需要根据实际情况调整。比如你的项目有特殊的代码规范，就在约束栏里写清楚；你的数据有特殊的边界条件，就在示例栏里补充。模板的价值在于帮你养成结构化提问的习惯，而不是让你变成填表机器。
我在实际使用中最大的体会是：Codex 的输出质量，90% 取决于你的输入质量。你把它当搜索引擎用，它就给你搜索结果的水平；你把它当结对编程的搭档用，它就给你搭档的水平。这 7 个模板，就是帮你把它变成搭档的工具。
