企业官网建设流程全解析

1. 为什么“提问”本身需要一张急救卡

写代码这件事，卡住的时候往往不是不会写，而是不知道该问什么、怎么问。我见过太多同行，包括我自己早期，遇到报错第一反应是复制整段堆栈丢进对话框，然后得到一段看似正确、跑起来继续报错的回答。来回几轮之后，时间没了，问题还在。后来我慢慢意识到，跟 Codex 这类代码助手打交道，本质上是一次“需求描述 + 上下文投喂 + 约束条件”的工程化沟通，而不是聊天。你给的信息越结构化，它返回的代码越接近可直接落地的状态。

所谓“提问急救卡”，就是把这套沟通方式固化成几个可复用的模板。标题里说的 7 个常用模板，覆盖的是日常开发中最高频的七类场景：报错定位、函数补全、代码重构、单元测试生成、性能优化、跨语言翻译、以及代码解释。而“组合写法”指的是当单一模板不够用时，把两三个模板拼接起来，形成一条信息密度更高的提问。这套东西我用了大半年，最大的感受是：提问质量决定了返工次数。一条好的提问，能让你少改三遍代码。

这篇文章适合谁看？如果你是刚接触代码助手的新手，这 7 个模板可以直接抄去用；如果你已经用了一段时间但总觉得“它答得不够准”，那问题多半出在提问结构上，组合写法那部分会对你有帮助。我不打算讲什么玄学提示词，只讲我实际验证过、能稳定复现效果的写法。下面从整体设计思路开始拆。

2. 提问模板的整体设计思路

2.1 一条好提问的三个必备要素

我总结下来，任何一条能让 Codex 给出高质量回答的提问，都包含三个要素：角色与目标、上下文、约束条件。缺一个，回答就会偏。

角色与目标解决的是“你要它干什么”。比如“帮我写一个函数”太模糊，“帮我写一个接收字符串数组、返回去重后按长度排序的数组的 Python 函数”就明确得多。上下文解决的是“它需要知道什么才能干对”，包括语言版本、框架、已有代码片段、报错信息。约束条件解决的是“边界在哪”，比如不能用某个库、必须兼容某个版本、时间复杂度要求。

很多人提问只给了第一项，然后抱怨回答不能用。其实不是模型不行，是信息没给够。你可以把 Codex 想象成一个刚入职的同事，他技术不错但完全不了解你的项目。你交代任务时如果只说“把这个功能做了”，他大概率做偏；如果你说清楚背景、目标、限制，他一次就能做对。提问模板的价值，就是帮你把这三要素固定成填空格式，避免每次临场组织语言时漏掉关键信息。

2.2 为什么是这 7 个模板而不是别的

日常开发中，我们向代码助手求助的场景其实高度集中。我统计过自己一个月的提问记录，排在前面的依次是：看不懂的报错、写一半卡住的函数、想优化但不敢动的老代码、没有测试覆盖的新模块、跑得太慢的查询、需要从别的语言搬过来的逻辑、以及接手别人代码时看不懂的段落。这七类几乎覆盖了 80% 以上的求助场景，所以我把它们各自固化成一个模板。

选择这七个而不是更细分的模板，还有一个考虑：模板太多反而记不住。急救卡的意义在于“卡住时能立刻想起来用哪个”，七个刚好是能记住的上限。每个模板我都尽量做到结构一致——都是“场景 + 输入 + 期望输出 + 约束”四段式，这样你记住一个就等于记住了七个的骨架，用的时候只需要换内容。

2.3 模板与组合写法的关系

单一模板解决单一问题，但真实开发中问题往往是复合的。比如你拿到一段报错，定位到是某个函数的问题，然后需要重构这个函数并补上测试——这就同时涉及报错定位、重构、测试生成三个模板。组合写法不是简单拼接，而是有主次的：通常以最终目标为主模板，把其他模板作为上下文或约束嵌入进去。

我常用的组合方式是“主模板 + 前置上下文模板”。比如以“重构”为主，前面嵌入“代码解释”让模型先理解这段代码在干什么，再让它重构。这样比直接丢一段代码说“重构一下”效果好很多，因为模型先建立了对代码意图的理解，重构时就不会改变原有语义。这个思路在后面组合写法章节会展开讲，这里先建立概念。

3. 七个常用模板逐个拆解

3.1 模板一：报错定位模板

这是使用频率最高的一个。核心结构是：环境信息 + 完整报错 + 相关代码 + 已尝试的操作。

很多人只给报错不给代码，模型只能猜。正确的写法是这样：

环境：Python 3.11，使用 requests 2.31，运行在 Linux 报错信息：（粘贴完整堆栈，不要截断） 相关代码：（粘贴报错涉及的函数，前后各留几行上下文） 我已经试过：（比如换过版本、加过超时，说明结果） 请帮我定位根因，并给出最小修改方案。

这里有个关键细节：报错信息一定要完整。我见过太多人只复制最后一行KeyError: 'xxx'，把前面的调用栈全删了。调用栈才是定位问题的关键，它告诉你错误从哪一层传上来的。另外“已尝试的操作”这一项很多人会省略，但它能避免模型给出你已经试过的无效建议，节省来回轮次。

注意：如果报错里包含敏感路径或内部标识，粘贴前先做替换，用占位符代替，这不影响模型理解问题。

3.2 模板二：函数补全模板

当你写了一半卡住，或者知道要什么但懒得从头写，用这个模板。结构是：函数签名 + 输入输出示例 + 边界条件 + 语言与风格要求。

请帮我实现下面这个函数： 函数签名：def merge_intervals(intervals: list[list[int]]) -> list[list[int]] 输入示例：[[1,3],[2,6],[8,10],[15,18]] 期望输出：[[1,6],[8,10],[15,18]] 边界条件：输入可能为空列表；区间可能完全包含；输入未排序 语言：Python 3.10+，不要用第三方库 风格：加类型注解，关键步骤写注释

给输入输出示例这一步特别重要。文字描述“合并重叠区间”有歧义，但给一组具体的输入输出，模型立刻就能对齐你的预期。边界条件则是防止它写出“happy path 能跑、边界就崩”的代码。我实测下来，带边界条件的提问，返回代码的健壮性明显更高。

3.3 模板三：代码重构模板

重构的难点在于“不改变行为”。所以这个模板的核心是：先声明行为不变，再给出重构目标。

下面这段代码功能正常，但我想重构它。 重构目标：降低圈复杂度 / 提取重复逻辑 / 改善命名 约束：不改变对外行为，不改变函数签名，不引入新依赖 代码：（粘贴完整函数） 请给出重构后的代码，并说明每处改动的原因。

“说明每处改动的原因”这一句是我后来加的，非常有用。它逼着模型解释自己的决策，你能借此判断改动是否合理，而不是盲目接受。有几次模型的重构其实改变了边界行为，正是通过它的解释我才发现的。

3.4 模板四：单元测试生成模板

写测试是很多人的痛点，交给模型很合适。结构是：被测代码 + 测试框架 + 覆盖要求 + 命名规范。

请为下面的函数生成单元测试： 被测代码：（粘贴函数） 测试框架：pytest 覆盖要求：正常路径、边界值、异常输入各至少一个用例 命名规范：test_ 开头，用例名描述被测行为 请使用参数化测试覆盖多组输入。

这里的关键是“覆盖要求”要具体。只说“生成测试”模型可能只给两个 happy path 用例。明确要求边界值和异常输入，它才会认真覆盖。另外指定参数化测试，能避免生成一堆重复结构的用例函数，可读性好很多。

3.5 模板五：性能优化模板

性能问题不能瞎优化，得先有数据。所以这个模板要求：现状数据 + 瓶颈位置 + 优化目标 + 不可动的约束。

下面这段代码在处理 10 万条数据时耗时约 8 秒，目标是降到 2 秒以内。 瓶颈：我初步定位在嵌套循环部分（已标注） 约束：不能改变输入输出格式，不能引入重型依赖 代码：（粘贴代码） 请分析瓶颈并给出优化方案，说明预期提升幅度。

“说明预期提升幅度”这句能帮你判断方案值不值得做。如果模型说某个改动只能提升 10%，那可能不值得引入复杂度。另外一定要给现状数据，没有基线就没法衡量优化效果，这是性能工作的基本纪律。

3.6 模板六：跨语言翻译模板

把逻辑从一种语言搬到另一种，坑很多，因为两种语言的惯用法不同。模板结构：源语言与目标语言 + 源代码 + 目标语言版本 + 特殊要求。

请把下面的 JavaScript 代码翻译成 Python： 源代码：（粘贴） 目标版本：Python 3.10+ 要求：使用 Python 惯用法，不要逐行直译；保持原有逻辑和边界行为 如果某些 JS 特性在 Python 中没有直接对应，请说明你的处理方式。

“不要逐行直译”这句很关键。逐行直译出来的代码往往带着源语言的思维，在目标语言里很别扭。要求用惯用法，模型会做更地道的转换。最后那句“说明处理方式”则是为了处理那些没有直接对应的特性，比如 JS 的undefined和 Python 的None语义差异。

3.7 模板七：代码解释模板

接手别人代码、或者看开源项目时用。结构：代码 + 解释粒度 + 关注点。

请解释下面这段代码： 代码：（粘贴） 解释粒度：逐段解释，每段说明它在做什么、为什么这么做 关注点：重点说明数据流向和异常处理逻辑 如果代码有潜在问题或坏味道，请一并指出。

“关注点”这一项让解释更有针对性。不加的话模型可能平均用力，讲了一堆你不需要的细节。加上之后，它会围绕你关心的部分深入。最后那句“指出潜在问题”经常能挖出一些原作者留下的坑，很有价值。

4. 组合写法：把模板拼起来用

4.1 主模板加前置上下文

最常见的组合。比如你要重构一段看不懂的代码，直接丢给重构模板，模型可能改错语义。正确做法是先让它解释，再让它重构：

第一步，请先解释下面这段代码的功能和数据流： （粘贴代码） 第二步，在理解上述功能的基础上，帮我重构它，目标是提取重复逻辑， 约束是不改变对外行为。

这种“先理解后操作”的组合，我实测下来重构准确率提升明显。因为模型在第二步时已经建立了对代码意图的认知，不会把“看起来冗余但实际必要”的逻辑删掉。

4.2 报错定位加函数补全

有时候报错是因为某个函数根本没实现完。这时候组合写法是：先定位，再补全。

下面这个报错出现在调用 process_data 时： （粘贴报错和调用代码） 请先定位根因。如果根因是 process_data 未实现或实现不完整， 请按以下签名补全它： 签名：def process_data(records: list[dict]) -> dict 输入示例：（给一组） 期望输出：（给一组）

这样一条提问同时解决了“为什么错”和“怎么修”，省了一轮交互。

4.3 测试生成加性能优化

给一段待优化的代码生成测试，先锁定行为，再优化，这样优化后能立刻验证行为没变。这是很工程化的组合：

第一步，为下面这段代码生成 pytest 测试，覆盖正常和边界情况： （粘贴代码） 第二步，在测试保护下优化它的性能，目标是从 8 秒降到 2 秒， 约束是不改变输入输出。

这个组合的价值在于：测试成了优化的安全网。我强烈建议做任何性能优化前都先有测试，否则你根本不知道优化有没有改变行为。

4.4 组合写法的注意事项

组合不是越长越好。我试过把四五个模板全塞进一条提问，结果模型顾此失彼，每个部分都做得不深。经验是：一条提问最多组合两个模板，超过两个就拆成多轮。另外组合时要有明确的主次，用“第一步/第二步”或“在……基础上”这样的连接词把逻辑串起来，别让模型猜你的意图。

提示：组合提问如果发现模型只完成了后半部分，说明前半部分被当成了背景信息。这时候把前半部分单独发一轮，拿到结果后再发后半部分，效果更稳。

5. 实操过程与核心环节实现

5.1 从一条真实报错开始走完整流程

假设你遇到一个典型报错：处理数据时抛出TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'。按急救卡流程，第一步用报错定位模板：

环境：Python 3.11 报错：TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' 相关代码： def total_score(records): result = 0 for r in records: result = result + r.get("score") return result 已尝试：确认 records 非空 请定位根因并给最小修改方案。

模型会指出r.get("score")在键不存在时返回None，与0相加报错。最小修改是r.get("score", 0)。这一步很快。

5.2 定位之后紧接着补全与加固

拿到根因后，问题其实还没完——如果业务上score缺失应该报错而不是当 0 处理呢？这时候用组合写法，把函数补全和测试生成接上：

基于上面的函数，请做两件事： 1. 修改为：score 缺失时抛出 ValueError 并带上记录索引 2. 为修改后的函数生成 pytest 测试，覆盖 score 存在、缺失、为 0 三种情况

这样一轮下来，你不仅修了 bug，还明确了边界行为，并且有了测试保护。这就是急救卡组合写法的实际价值——把一次救火变成一次加固。

5.3 参数与约束的写法示范

约束条件怎么写才有效？我总结了几种高频约束和它们的写法：

这张表是我踩坑总结出来的。约束越具体，模型越不会自由发挥。模糊的约束等于没约束。

5.4 一次完整的重构实操记录

我拿一段真实的老代码走过完整流程。原始函数有 60 多行，嵌套三层，命名混乱。第一步用代码解释模板让它先讲清楚这段代码在干什么，确认理解无误。第二步用重构模板，明确目标是“提取重复的校验逻辑、降低嵌套层级、改善命名”，约束是“不改变行为”。模型返回后，我用第三步测试生成模板补了测试，跑通确认行为一致。

整个过程三轮提问，比我自己硬啃快了大概一倍。关键心得是：别指望一轮提问解决所有问题。把大任务拆成“理解—改造—验证”三步，每步用对应模板，比一次性提一个大而全的要求靠谱得多。

6. 常见问题与排查技巧实录

6.1 模型答非所问怎么办

最常见的原因是上下文给少了，或者问题里混了多个不相关的诉求。排查顺序：先看是不是一条提问里塞了太多目标，是的话拆开；再看上下文是否足够，比如报错没给全、代码没给上下文。我遇到过一次，模型一直答偏，最后发现是我粘贴代码时漏了函数定义，它只能靠猜。补上之后一次就对了。

6.2 返回代码跑不通怎么排查

先别急着说模型不行。按这个顺序查：第一，检查它用的库版本和你环境是否一致；第二，检查它假设的输入格式和你实际的是否一致；第三，看它有没有用你没提到的依赖。多数“跑不通”其实是环境或假设不匹配。把报错再喂回去，用报错定位模板追问，通常一两轮就能收敛。

6.3 提问太长被截断的处理

组合写法容易让提问变长。如果发现回答只覆盖了后半部分，说明前半部分可能被当背景略过了。处理办法是拆轮次：先发前半部分拿结果，再把结果作为上下文发后半部分。另外粘贴大段代码时，只保留相关部分，无关的删掉，既省长度又减少干扰。

6.4 常见问题速查表

6.5 几条压箱底的避坑经验

第一，永远给一组具体的输入输出示例，这比任何文字描述都管用。第二，约束要写成“不能做什么”而不是“尽量怎样”，前者是硬边界，后者模型会打折执行。第三，重构和优化前先要测试，没有测试保护的改动都是赌博。第四，别在一条提问里既让它解释又让它改，先解释确认理解，再动手改，这个顺序不能省。第五，保留你的提问记录，好的提问是可以复用的资产，下次遇到同类问题直接改改就能用。

这套急救卡我自己用下来，最大的改变不是省了多少时间，而是提问前会先想清楚“我到底要什么”。这个思考过程本身，就解决了一部分问题。后面如果你用顺手了，可以按自己的场景再扩展模板，比如加一个“接口设计”模板或者“日志排查”模板，骨架还是那四段式，换内容就行。