企业官网建设流程全解析

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 排查速查表

我把自己踩过的坑整理成一个速查表，顺手放在这里。

5. 我自己的使用习惯，最后分享一点私货

这套急救卡我用了挺长一段时间，最后沉淀下来的使用习惯其实不是“背模板”，而是两个很简单的原则：第一，每次提问之前拿出一分钟想一下“Codex 现在最缺哪条信息”，缺项目背景就补场景，缺任务定义就补动词，缺边界就补约束；第二，把模板保存成笔记片段，用占位符填充，而不是每次从零打字。

有个细节值得单独说一下：同一类任务反复出现的时候，我会提炼一个“专属模板”。比如我自己经常写数据报表页面，就固定了一套“背景 + 接口结构 + 图表类型 + 空态处理 + 加载态要求”的组合写法，每次新增报表页面，只要替换接口和字段名就行。这种沉淀下来的模板，比起通用的七张卡，用起来顺手得多。

Codex 这类工具的价值，说到底还是取决于使用者的表达质量。急救卡给的是框架，真正让框架生效的，是你对项目的理解、对需求的拆解，以及动手去试的耐心。写代码这件事，AI 能做一部分，剩下的还是得靠人。