企业官网建设流程全解析

最近这半年，我把 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_原文件名。 约束：

1. 只使用标准库，不依赖第三方库。
2. 如果图片没有 exif 拍摄日期，保留原文件名不动。
3. 如果新文件名已存在，在名字后加 _1、_2 避免覆盖。
4. 脚本只负责重命名逻辑，不做删除操作。 完成标准：
5. 对一张有 exif 的图片，运行后文件名变成 YYYYMMDD_IMG_1001.jpg。
6. 对没有 exif 的图片，文件名保持原样。
7. 对名字冲突的情况，后处理的文件自动加上后缀。 请直接输出完整脚本，并在代码里注释每个关键步骤。

这一轮我同时启用了任务定义卡、上下文补全卡、约束条件卡、验收标准卡。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 时经常踩的坑做了整理，做成一张速查表。这张表基本覆盖了我见过的绝大部分沟通挫败场景，你对照自己踩过的坑，会发现根因几乎都指向同一个方向。

这张表里前四条都属于“首次提问缺信息”，后两条属于“动态过程没跟踪”。如果你发现自己频繁踩其中某一条，说明你该把对应卡片内化成习惯，而不是临时想起才用。

5.2 让对话质量持续变好的三个习惯

除了关键时刻用急救卡，我还想分享三个让日常对话更省心的习惯。这三个都来自实际体验，不是那种虚空建议。

第一，提问里带上项目结构的路径。哪怕只是一句“在 src/services/user_service.js 的 getUsers 里”，也能让 Codex 把改动范围精准绑定到目标文件。大部分“改动范围失控”的事故，就是因为开头没有给这个锚点。你要知道，Codex 对具体文件路径的敏感度比你想象的高很多，只要路径真实清晰，它基本不会去碰别的地方。

第二，一次只让 Codex 管一件事。想让 Codex 同时改 A 函数的性能、调 B 接口的参数、加 C 模块的日志，大概率三件事都做不好。原因不是能力不够，而是信息量太大，每个目标的上下文都在互相干扰。把它拆成三次提问，每次聚焦一个目标，输出的质量和可控性都会高很多。

第三，对话跑偏超过两轮就果断开新对话，把关键结论在新对话里重新描述一遍。Codex 的上下文窗口是有限的，轮次越多越容易出现前后矛盾和“遗忘”。与其在新一轮里花大段文字解释“我们之前聊到哪了”，不如直接开一个新对话，把当前项目状态、目标、已完成的部分重新组织成一轮干净的 prompt。这个习惯看着简单，实际上能让你的平均效率提升一大截。

老实说，我一开始也觉得写 prompt 很麻烦——需求我自己心里清楚，为什么还要额外花两分钟把它写出来？但用了一段时间 Codex 之后，我完全改观了。与其说是 Codex 难交流，不如说它逼我把需求想得更清楚。以前跟同事对接，我也经常甩一句“你帮我改下那个排序”，然后大家互相猜半天。现在我把问题写成 prompt 之前，反而多了一个自我检查的环节：如果我自己都写不清楚“完成标准”，那说明需求本身还没想明白。

七张卡片看起来好像很多，真正用顺了你会发现，大部分场景就是两三张卡来回组合。我现在的习惯是：新功能来了，任务卡加约束卡加验收卡一起上；跑出问题了，错误定位卡加追问卡；代码想优化了，重构卡加验收卡。熟练以后，写一条高质量 prompt 的时间也就一两分钟，但换来的却是少走好几轮弯路。

如果你正在被 Codex 这“看似不听话”的回复折磨，不妨先别急着怀疑工具，试着用这七张卡片重新组织一次提问。方法就摆在这里，剩下的就是多试、多总结、慢慢形成自己的提问节奏。等哪天你发现一条 prompt 下去能直接拿到可用的代码，你也会理解我为什么说：练习提问，比钻研任何花哨的功能按钮都更值得。