写代码时，ChatGPT 最像一位「速度很快、偶尔一本正经胡说」的结对伙伴。你会在 https://chatgpt.com 里快速得到草稿，但能否合并进仓库，取决于你的提问质量与检查纪律。本文给可执行的提问方式、检查清单与落地步骤。
提问方式：给上下文，要约束
低质提问：写一个登录。 高质提问包含：
- 语言与运行时版本；
- 框架与已有目录结构；
- 输入输出契约；
- 错误怎么处理；
- 不要引入的依赖；
- 验收标准（测试或手动步骤）。
模板：
技术栈：……；现有函数签名：……；目标：……；约束：不新增依赖；输出：完整可粘贴代码 + 简短说明 + 三则边界测试用例。
一次只解决一个问题。又要重构又要加功能又要改风格，结果往往四处漏风。
多轮策略
- 先要方案对比（两三种实现与取舍）；
- 选定后再生成代码；
- 贴上报错原文继续修；
- 最后要求它列出仍需你本地确认的假设。
把报错、相关文件片段、复现步骤贴全，比骂「还是不行」有效十倍。注意脱敏：密钥、生产地址、客户数据先去掉。
检查：默认不信任，直到跑过
最低检查圈：
- 能跑吗？ 在本地或 CI 真正执行；
- 对吗？ 边界值、空输入、权限失败路径；
- 安全吗？ SQL 拼接、注入、路径穿越、密钥硬编码；
- 可维护吗？ 命名、重复逻辑、与项目风格是否一致；
- 有没有幻觉 API？ 查官方文档确认函数与参数存在。
对安全敏感代码（鉴权、支付、加密），必须人工深审，必要时第二人复核。不要因为「注释写得很像那么回事」就降低标准。
落地：从聊天窗口到仓库
- 新建分支，小步提交；
- 先补测试再扩功能；
- 生成代码若改动面过大，拆成多次 PR；
- 在提交说明里如实记录 AI 辅助范围（团队有规范则遵守）；
- 删除对话里临时打印的密钥。
IDE 插件与 ChatGPT 网页可以并用：网页适合讲清架构与粘贴长报错；插件适合改当前文件。无论哪条路径，审查责任都在提交者。
适合与不适合
适合：样板代码、正则草案、测试用例草稿、解释陌生代码、重构建议。 不适合：无审查直接上生产的权限系统、绕过授权的「破解」、把 GPL 代码改头换面却不清许可证。
提示词加分项
- 「指出你不确定的三处」；
- 「给出复杂度与潜在性能坑」；
- 「用最小 diff 思路，列出要改的文件路径」；
- 「不要伪造成功：若信息不足先问我」。
与代码审查清单对齐
把 AI 生成补丁贴进评审时，请在描述里写明：生成范围、你已跑过的测试、你仍担心的点。审查者应同样关注幻觉 API 与安全问题，而不是只看「能不能编译」。把「AI 辅助」当成需要更多测试的信号，而不是可以更少审查的借口。
长期来看，你积累的提示词与项目内文档质量，会决定 AI 输出上限。注释清楚、模块边界清晰的仓库，比任何万能提示词都更让模型好用。
让模型帮你写测试，而不是只写实现
很多人对 AI 写实现很兴奋，却忘了让它写测试。更好的顺序是：先要它根据需求列出测试用例表，你确认后再生成实现，最后再生成测试代码并由你跑通。测试用例表本身就是很好的需求澄清工具。
若项目已有测试风格，把示例测试贴给它，要求保持同一风格。这样落地时的修改量更小，审查也更快。记住：测试绿了不等于需求对了，还要对照验收标准看一眼。
遇到模型坚持使用过时库写法时，把你项目里的正确示例贴回去纠正，并要求它以后遵循示例。上下文里的活文档，往往比口头「用新版本」更有效。养成「示例驱动提示」的习惯，代码落地会稳很多。
把上述方法在下一周真实任务里各练一次，并记下成功与失败样例，你的个人手册就会比任何过时截图教程更值钱。
小结
用 ChatGPT 写代码的独立价值，是缩短从意图到草稿的时间。提问给足契约，检查以可运行为准，落地走分支与测试，你就能把它用成加速器，而不是缺陷发生器。入口仍是官方 chatgpt.com 或你受控的 API 集成。
Ai菜鸟网。发布者：AI菜鸟网，转载请注明出处：https://www.alyyhw.com/4225.html
