ChatGPT 写代码提示词：可复用的结构化写法与示例

引言

ChatGPT 写代码时，输出质量往往不取决于语气是否礼貌，而取决于约束是否具体：角色、技术栈版本、输入输出、边界条件、禁止项、期望格式。

本文给一套可复制的结构化模板，以及生成、调试、重构三类示例。不编造「用了提示词后效率提升百分之几」。所有生成代码仍需人工审查和测试。

五块积木

把提示词写成五块，缺一块就容易变成闲聊：

• 角色：你是资深的某种语言或某种框架工程师。角色用来收窄默认习惯，不是用来堆头衔。
• 上下文：项目类型、已有约束、相关报错或代码片段。贴代码前先脱敏。
• 任务：一次只做一个可验证的目标。
• 约束：版本锁定、风格规范、性能或安全的优先级，以及明确不要做什么。
• 输出：只要代码、先计划再改、给检查清单，或附测试用例。

另外两条经验法则：用小例子代替抽象形容词；复杂任务拆成「先诊断，再计划，再改代码」，而不是一句「把整个项目重写」。

「写得优雅一点」几乎无法验收。「超时 3 秒，失败时返回 false，不要把环境变量打进日志」可以验收。

三段模板

下面三段都可以直接改完再贴。方括号里的内容换成你的现场信息。

生成

你是资深 TypeScript 工程师。我在用 Next.js App Router（请按 App Router 惯例，不要用 Pages Router）。任务：写一个服务端可调用的函数，从环境变量读取 API_BASE，请求 /health 并返回是否健康。约束：超时 3 秒；不要把密钥打日志；不要引入新依赖。输出：完整函数，外加 3 条边界情况说明。

调试

下面的函数在偶数长度数组上把中位数算错了。请先指出原因，再给出修正版，并补一个偶数长度的测试用例。

【在这里粘贴脱敏后的代码】

重构

把下列 Promise 链式调用改成 async/await。错误处理的语义保持不变，不要改对外函数签名。

【在这里粘贴脱敏后的代码】

红线要写在模板旁边：不要粘贴真实密钥、内网域名和未脱敏的业务数据。AI 生成的代码必须人工审查安全和边界，并在独立分支上验证。通过了再进主干。

和 IDE Agent 配合

ChatGPT 适合讨论方案、解释报错、生成小段草稿。一旦改动牵涉多个文件和仓库上下文，终端智能体或 AI IDE 往往更省复制粘贴。

一个实用组合是：先在 ChatGPT 里把接口和边界谈清楚，再在项目环境里小步落地。聊天窗口负责把需求写成可测试的句子；仓库里的 Agent 负责对着真实文件改。这是工作流建议，不是对某一产品的测评排名。

如果聊天里已经产出了一段草稿，带回 IDE 时仍然不要点「全部接受」。对照你在提示词里写过的约束，逐段看它有没有越界。

总结

把提示词写成可测试的需求，比堆形容词更有效。固定你的五块积木，按生成、调试、重构切换输出要求，并坚持脱敏和人工审查。

若要做成系列，可以继续写「给 SQL 优化的提示词」或「给代码评审的提示词」。每篇带三到五个可复制的块就够了。

【我的真实体验】

以前我都是直接对 ChatGPT 喊「帮我写个 Python 爬虫」，结果它经常漏掉异常处理，跑一半就报错。后来试了「角色 + 明确约束」的写法，我加上一句：「你是一个资深爬虫工程师，请使用 requests 和 BeautifulSoup，必须加入 try-except 和随机延时」。这次出来的代码居然直接就能跑通，连基础的反爬策略都考虑进去了。

不过有一点要提醒：AI 生成的 SQL 或正则表达式，千万别闭着眼睛丢进生产环境。上次它就给我写了个会引发全表扫描的慢查询。人工 Review 绝对不能省。