如何利用 ChatGPT 编写代码：从需求到测试的完整指南

ChatGPT 可以成为高效的结对编程助手：它适合把自然语言需求转换成代码、解释陌生项目、定位报错并补充测试。但它不是自动通过验收的程序员，生成的代码仍可能遗漏边界条件、误用 API 或引入安全问题。

最可靠的工作方式是让 ChatGPT 参与一个可验证的开发闭环：明确目标 → 提供上下文 → 小步实现 → 本地运行 → 根据证据修复 → 测试和审查。

一、开始前准备：把问题说清楚

模型给出的结果高度依赖输入信息。不要只说“帮我写一个登录功能”，而应提供以下背景：

• 使用的语言、框架和版本，例如 Python 3.12、FastAPI 0.115；
• 输入和输出格式，以及成功、失败时的示例；
• 数据库、第三方服务和现有函数的接口约束；
• 性能、兼容性、可访问性或风格要求；
• 当前代码、完整报错和已经尝试过的方案。

如果项目较大，先让 ChatGPT 阅读目录和关键文件，再开始修改。一次只处理一个明确目标，避免把整个项目压缩到一个提示词中。

二、通用提示词模板

下面的模板适合代码生成、修改和审查。将方括号内容替换成你的实际信息：

你是一名熟悉 [语言/框架/版本] 的软件工程师。

目标：实现 [一句话描述目标]。
上下文：
- 项目用途：[项目简介]
- 相关文件：[文件路径和作用]
- 已有接口或约束：[不能改变的内容]

输入示例：
```json
[示例输入]

期望输出：

[示例输出]

要求：

1. 只修改 [允许修改的文件]；
2. 保持现有代码风格，并说明关键设计选择；
3. 处理空值、非法输入、超时和重复请求；
4. 同时提供测试用例和运行命令；
5. 如果信息不足，请先列出假设和需要确认的问题，不要编造 API。

请先给出实现计划，再输出完整代码或精确的 diff。

要求“先计划、后代码”可以减少模型忽略约束的情况；要求输出 diff 则更适合已有仓库，便于逐行审查和回滚。

## 三、四种最实用的编程场景

### 1. 生成一个小而完整的功能

先从最小可运行版本开始，再逐步增加功能。例如：

```text
用 TypeScript 编写一个 parsePagination 函数。
输入是 URLSearchParams，读取 page 和 pageSize。
page 最小为 1，pageSize 允许 1 到 100；缺失或非法值使用 page=1、pageSize=20。
返回 { page, pageSize, offset }，并使用 vitest 编写边界测试。

这样描述后，模型更容易同时考虑默认值、范围校验和测试，而不是只生成“能运行”的主路径代码。

2. 调试已有代码

调试时不要只粘贴错误信息。提供复现步骤、实际结果、期望结果、运行环境和最小代码片段，并要求模型先判断原因，再给修复方案：

运行环境：Node.js 22，React 19。
复现步骤：连续快速点击“保存”两次。
期望：只发送一次请求并显示最新结果。
实际：发送两次请求，较早的响应覆盖了较新的状态。

请：
1. 解释竞态条件发生在哪一行；
2. 给出保持现有组件 API 不变的修复；
3. 添加一个能稳定复现该问题的测试；
4. 说明取消请求和仅忽略旧响应两种方案的取舍。

拿到建议后，把实际修复后的新报错或测试输出继续发给 ChatGPT。错误信息是证据，胜过“看起来应该可以”的推测。

3. 解释和重构代码

面对陌生代码，可以先要求模型按“输入、状态变化、外部副作用、错误处理”四个方面解释，再提出重构。重构提示词应明确不能改变的行为：

请重构下面的 Python 函数，保持函数签名和返回值兼容。
优先降低嵌套层级和重复数据库查询，不引入新依赖。
先列出当前行为和潜在回归点，再给出 diff，最后提供回归测试。

不要一次重构几十个文件。每次改动保持足够小，运行测试后再进入下一步。

4. 生成测试和代码审查意见

测试提示词可以要求覆盖等价类、边界值和异常路径：

请为以下订单折扣函数设计测试矩阵。
至少覆盖：空订单、负数金额、满减临界值、优惠券过期、重复使用优惠券、浮点数舍入。
先列出测试矩阵，再使用 pytest 编写测试；不要修改生产代码。

审查时让模型扮演“挑剔的 reviewer”，并指定输出严重级别、文件位置、复现条件和修复建议。模型的审查结果应作为第二双眼睛，不能替代熟悉业务的人工审查。

四、推荐的协作流程

1. 建立上下文：发送目录树、相关文件和项目约定，隐去密钥、令牌和个人数据。
2. 拆分任务：把需求拆成数据结构、核心逻辑、接口、界面和测试等小任务。
3. 约定验收标准：先写输入输出示例和可执行测试，再让模型实现。
4. 小步生成：每轮只请求一个文件或一个函数，要求保留现有接口。
5. 本地验证：运行格式化、类型检查、单元测试和构建命令，把真实输出回传。
6. 人工审查：检查权限、数据校验、异常处理、日志、性能和依赖许可证。
7. 记录决策：让 ChatGPT 总结改动、已知限制和后续 TODO，写入提交说明或文档。

五、让输出更稳定的技巧

• 给出范例：展示一个符合项目风格的函数或测试，模型会更容易沿用命名和结构。
• 使用文件边界：明确“只改 src/parser.ts”，避免模型顺手修改配置。
• 要求不确定时停下：让模型列出假设，不要自行猜测版本、字段或业务规则。
• 分离思考和执行：先要方案和风险清单，确认后再要代码。
• 固定输出格式：例如“改动摘要 / diff / 测试 / 风险”，方便放进 PR 描述。
• 控制上下文长度：只提供相关文件；过时的对话应重新开一个会话并附最新代码。

六、安全与质量检查清单

提交由 ChatGPT 协助生成的代码前，至少检查：

• 是否把 API Key、密码、Cookie 或生产数据发送给了模型；
• SQL、Shell、HTML 和路径拼接是否存在注入或越权风险；
• 身份认证、授权、速率限制和错误信息是否完整；
• 外部输入是否经过类型、长度、范围和格式校验；
• 并发、超时、重试、幂等和资源释放是否有明确行为；
• 依赖是否真实存在、版本是否兼容、许可证是否允许使用；
• 测试是否覆盖失败路径，而不只是让 happy path 通过；
• 代码是否符合团队的 lint、类型检查、日志和可观测性要求。

尤其要警惕模型编造不存在的包、函数和文档链接。遇到不熟悉的 API，应查阅官方文档或在隔离环境中用最小示例验证。

七、何时不应直接使用生成代码

涉及支付、医疗、身份认证、权限系统、加密、生产数据库迁移或安全边界的代码，需要更严格的设计评审和测试。ChatGPT 可以帮助整理方案、解释规范和生成测试草稿，但最终实现应由有经验的工程师确认，必要时进行人工安全审计。

结语

高质量的 AI 编程并不是“输入一句话，复制一段代码”，而是把 ChatGPT 纳入正常的软件工程流程。清晰的上下文带来更贴合的实现，明确的验收标准带来更少的返工，真实的测试和审查才决定代码能否进入生产环境。

相关内容：

• Prompt Engineering 提示工程指南
• OpenAI API 快速入门
• 文本生成 API 指南