跳到主要内容

用 ChatGPT 学编程与写代码（新手友好指南）

TL;DR：ChatGPT 特别适合 学习解释、调试推理、方案比较、写作（文档/测试/PR 描述）。想要稳定有效，你需要提供：最小复现、预期 vs 实际、约束 + 验证步骤。永远不要粘贴密钥。

你能从这份指南得到什么​

用 10-20 分钟建立一套可复用的方法：怎么提问更准、怎么用 ChatGPT 排错/重构，并且不盲目依赖输出。

快速上手清单：

  • 提供最小复现（错误 + 相关代码）
  • 明确“预期 vs 实际”
  • 写清楚约束（技术栈、不要加依赖、代码风格）
  • 要求给出验证步骤（测试/命令/边界情况）
  • 永远不要粘贴密钥或保密代码

ChatGPT 的“高命中率问法”长什么样？​

你可以把一次提问当成一个小规格说明（mini spec）。最低限度包含 5 件事：

  1. 目标：你想达成什么（一句话）
  2. 上下文：相关代码/文件路径/错误日志（最小复现）
  3. 约束：技术栈、禁止事项（不加依赖、不改 API 等）
  4. 输出格式：你希望它怎么回答（计划/代码/步骤）
  5. 验证方式：跑什么命令、如何复现、哪些边界要覆盖

模板（直接复制）：

目标：修复/实现 [X]。
上下文：
- 错误/日志： [粘贴]
- 相关代码： [粘贴]
- 复现步骤： [步骤]
约束：
- 技术栈： [语言/框架]
- 不要：新增依赖 / 改 public API / 访问网络
输出：
1) 先列出你确定的事实 vs 假设
2) 给 3 个最可能原因 + 如何验证
3) 给最小修复方案
4) 给验证命令/测试用例

用 ChatGPT 排错的最佳实践​

排错最怕“试 10 个东西都不知道为什么”。建议强制它按“假设 → 证据 → 结论”输出：

  • 让它先给 3 个假设（按可能性排序）
  • 每个假设配一个“验证动作”（加日志/打印/最小脚本）
  • 只做一个改动就复测
  • 修复后补一个回归用例（避免下次再踩）

你也可以让它帮你把问题缩小：

“请把复现步骤缩到 3 步以内，并给出最小代码片段。”

用 ChatGPT 做重构/优化时怎么不翻车？​

最有效的策略是：先要计划，再要最小 diff，再要验证。

请先给出分步重构计划（每一步都能独立验证）。
每一步只改动最小范围，并在最后给出验证命令与边界情况清单。

另外，把“可读性/性能”这种目标具体化：

  • 可读性：提取函数、减少嵌套、统一命名
  • 性能：减少重复计算、缓存、避免 N+1
  • 可维护性：模块拆分、分层清晰、错误处理一致

什么时候应该从 ChatGPT 切换到 Cursor/Claude Code？​

当你发现自己在做这些事时，切换通常更划算：

  • 反复复制粘贴多个文件片段
  • 需要跨文件一致性修改（改名、迁移、拆模块）
  • 需要它直接跑命令验证（lint/build/tests）

一个好用的组合是：

  • ChatGPT：想清楚、写清楚、把任务拆小
  • Cursor/Copilot：快速编辑与落地
  • Claude Code：终端验证、复杂排错、自动化脚本

常用场景模板库（建议收藏）​

1) 代码解释（带“反例”与边界）​

请解释这段代码在做什么。
要求：
- 用 3 句话总结（TL;DR）
- 列出关键步骤（列表）
- 给一个可能的 bug/边界情况
- 给一个改进建议（但不要改变行为）

代码：
[粘贴]

2) 调试（最小复现 + 假设列表）​

我遇到 bug。

最小复现：
[代码]

错误：
[日志]

预期：
[预期]
实际：
[实际]

请输出：
1) 3 个最可能原因（按可能性排序）
2) 每个原因的验证方法（具体操作）
3) 最小修复方案
4) 回归测试用例

3) 重构（小步、可回滚）​

请重构以下代码以提升可读性，但不改变行为。

约束：
- diff 尽量小
- 一次只做一种改动（例如：提取函数/改命名/减少嵌套）
- 每一步都给验证方式

代码：
[粘贴]

4) 写测试（避免灌水）​

为以下模块写测试。

信息：
- 语言/框架：[xxx]
- 测试框架：[Jest/Vitest/Pytest]

要求：
- 覆盖主流程
- 至少 3 个边界情况
- 尽量测行为而非实现细节

代码：
[粘贴]

5) 写文档（可运行示例）​

为这个功能写一段 README/文档。
包含：
- TL;DR
- 安装与用法（给一个可运行示例）
- 配置项
- 常见坑与排错

功能/接口：
[粘贴]

隐私与安全：哪些内容不要贴给 ChatGPT？​

无论你用哪个聊天 AI，建议默认把这些当作“不要发送”的内容：

  • API Key、Token、密码、私钥（任何形式）
  • 未公开的客户数据、日志中的敏感字段
  • 公司内部代码（尤其是核心业务逻辑）如果没有明确许可

替代方案：

  • 用“最小复现”替换真实业务代码（保留结构、去掉敏感）
  • 用假数据/脱敏数据（例如把邮箱改成 user@example.com）
  • 只贴接口签名、错误日志、关键代码片段

一个可落地的“从问题到答案”流程（建议照做）​

当你想让 ChatGPT 真正帮你解决工程问题，而不是给一堆泛泛建议，可以按这个流程走：

  1. 先定义 Done：什么算修好/做完？（能复现消失、测试通过、build 通过）
  2. 再给输入：最小复现 + 关键上下文（路径/代码/日志）
  3. 让它先提问：信息不足就先问（不要硬猜）
  4. 让它先给计划：按步骤、每步有验证
  5. 你执行验证：失败就回到第 3/4 步迭代

你甚至可以把它写成“强制格式”：

请严格按以下格式回答：

1) 你确定的事实：
- ...

2) 你的假设：
- ...

3) 计划（每步含验证）：
1. ...（验证：...）
2. ...（验证：...）

4) 如果失败：下一步如何排查

用 ChatGPT 做“代码审查”也很好用​

当你有 diff（或一段改动）时，让它帮你从“风险与测试缺口”角度审查：

你是资深工程师，请做代码审查。
输入：
- 目标：...
- Diff：...
输出：
- 按严重程度排序的问题
- 可能的回归点
- 缺失的测试用例
- 建议的验证命令

注意：审查结论也需要你用测试与运行结果来确认；它更像“第二视角”，不是最终裁判。

ChatGPT 在编程里最擅长什么？​

ChatGPT 不是 IDE，它默认看不到你的整个仓库（除非你用某些外部集成或把内容贴给它）。这既是限制，也是优势：它随时随地可用，而且非常适合“把问题说清楚”。

最强场景：

  • 学习与解释：为什么这样写可行？
  • 调试推理：把日志/堆栈变成“可验证假设”。
  • 设计取舍：给多个方案并解释 trade-off。
  • 写作：文档、README、PR 描述、变更说明。
  • 重构规划：拆步骤、列风险、建议测试。

相对弱的场景：

  • 大规模多文件改动（上下文不足时容易跑偏）。
  • “一口气写完整系统”但没有验收标准。
  • 没有验证闭环的项目（不跑测试/类型检查）。

应该单独用 ChatGPT，还是配合 IDE 工具？​

一个好用的分工：

  • ChatGPT：想清楚、解释清楚、计划清楚、审查清楚
  • IDE 工具（Cursor/Copilot）：快速编辑、导航、多文件改动、跑检查

如果只选一个：

  • 新手通常先从 ChatGPT 开始，因为它更像导师。
  • 老手通常会把 ChatGPT 与 IDE 助手组合，速度与稳定性更好。

怎么问问题，ChatGPT 才会给“可执行答案”？​

坏答案通常来自坏问题。

“最小但足够”的上下文清单​

  • 目标（你要做什么）
  • 预期行为
  • 实际行为
  • 复现步骤
  • 错误/日志（原样粘贴）
  • 环境（OS、语言版本、框架版本）
  • 约束（不加依赖、保持兼容）
  • 验证方式（要跑哪些命令）

可复制：高质量 Bug 报告提示词​

Bug：<一句话>
预期：<应该发生什么>
实际：<现在发生什么>
复现：
1) ...
2) ...
日志/堆栈：
<粘贴>
环境：Node 20, pnpm, Next.js
约束：最小 diff、不新增依赖
请输出：
1) 3 个最可能原因
2) 每个原因如何确认
3) 最小修复 + 测试计划

可复制：高质量功能需求提示词​

功能：<一句话>
用户：<谁>
验收标准：
- ...
- ...
非目标：
- ...
约束：
- 不新增依赖
- 保持 API 稳定
验证：
- pnpm lint
- pnpm typecheck
- pnpm test
输出：
- 先给计划
- 只实现第 1 步，然后停下来

用 ChatGPT 调试：最有效的套路​

第一步：把症状转成假设​

不要只问“为什么坏了”，而是：

  • “列出可能原因”
  • “每个原因怎么确认”
  • “最小修复是什么”

第二步：提供关键材料​

调试最有用的材料通常是：

  • 堆栈
  • 日志
  • 最小相关代码片段
  • 调用处
  • 预期数据结构

第三步：强制验证​

永远问一句：

  • “我该跑什么命令来确认修复有效？”
  • “成功时的预期输出是什么？”

用 ChatGPT 做重构：先把风险拆掉​

推荐两阶段重构​

  • 阶段 1：只做机械改动（改名/移动/类型），不改行为
  • 阶段 2：在一切通过后做行为层优化

提示词：

重构目标：<目标>
规则：
- 阶段 1 只做机械改动；做完停下来我审查
- diff 要小且可审查
- 保持 public API
每一步后都要跑：typecheck + tests

让它显式列风险与边界条件​

列出这个重构可能的风险与边界条件。
然后给出保护这些风险的测试建议。

用 ChatGPT 写测试：要“抓回归”，不要“看起来像测试”​

“不写作弊测试”规则​

好测试必须：

  • 修复前会失败
  • 修复后会通过
  • 断言行为而不是实现细节

提示词：

写测试必须满足：修复前失败。
覆盖边界条件。
避免断言内部实现细节。

要一个测试矩阵​

给我一个测试矩阵：
- 正常路径
- 空/非法输入
- 边界值
- 错误路径
然后写出测试。

用 ChatGPT 做 code review​

把它当 reviewer，需要你给出 diff 或关键片段：

请 review 这段代码：
- 正确性
- 边界条件
- 安全
- 性能
- 可维护性
先给问题（按严重程度排序），再给建议。

隐私与密钥：怎么保护自己？​

不要粘贴：

  • API key
  • 密码
  • token
  • 生产客户数据

安全替代：

  • 用 REDACTED 替换敏感信息
  • 用最小复现替代整段业务代码
  • 描述数据结构而不是贴全量 payload

一些稳定有效的提示词模式​

模式：先要计划​

写代码前先给计划。
列出假设与风险。

模式：不确定就提问，不要猜​

如果信息不够，请先问我问题，不要做假设。

模式：最小 diff​

只给最小 diff。
避免无关重构。

模式：必须给验证步骤​

给出具体验证命令，以及成功时应该看到什么。

提示词库（可复制）​

把模糊想法变成可验收需求​

我有一个想法：<想法>。
请输出：
1) 用户故事
2) 验收标准（要点）
3) 非目标
4) 风险与开放问题
先不要写代码。

为 PR 生成实施清单​

功能：<功能>
技术栈：<栈>
请给 PR 清单：
- 可能涉及的文件
- 可能的 API 变更
- 需要补的测试
- 需要更新的文档
- 验证命令

解释陌生代码​

逐行解释下面代码。
然后总结：
- 它做了什么
- 为什么存在
- 可能的边界条件
- 如何测试

把我的提示词改得更“高信噪比”​

这是我的提示词：<prompt>
请改写成更高信噪比版本：
- 包含必要上下文字段
- 防止范围过大
- 强制验证

进阶工作流（更像专业开发者在用）​

用 ChatGPT 设计 API 与数据模型​

为 <功能> 设计 API。
给 2 个选项：
- 请求/响应 JSON 结构
- TypeScript 类型
- 校验规则
- 错误码
比较 trade-off 并推荐一个。

用 ChatGPT 做性能优化（先测再改）​

性能问题：<症状>
上下文：<栈>
请：
1) 列出 5 个最可能瓶颈
2) 每个如何测量（命令/工具）
3) 先给低风险优化

写“跟代码一致”的文档​

基于下面的代码/配置（我会粘贴），写一段文档：
- quickstart
- 配置项
- 示例
- troubleshooting
不要虚构代码里没有的功能。

需要多文件改动但 ChatGPT 看不到仓库怎么办？​

用“分步补上下文”的方法：

  1. 先要计划与文件列表
  2. 逐个粘贴文件（或关键片段）
  3. 每一步做完就停下来
  4. 维护一个“事实区”（当前 API、约束、进度）
  5. 每一步后都验证

这比 Cursor/Windsurf 慢，但在任何环境都可靠。

如何在不贴一整份文件的情况下提供上下文？​

使用“渐进披露”：

  1. 先给签名、类型、调用处
  2. 再给错误与最小复现
  3. 最后才给内部实现细节
我会分阶段提供上下文。
阶段 1：签名 + 调用处。
你先告诉我下一步需要什么信息，再给修复方案。

什么时候该要求结构化输出（JSON/表格/清单）？​

当你追求稳定与可执行时：

  • 测试矩阵
  • 迁移清单
  • 风险清单
  • API 合约
请输出 JSON 清单：
- step
- command（如果有）
- expected outcome
- rollback plan

用 ChatGPT 做“内容深化”（写得更能被引用）​

如果你在写教程/对比/路线图，ChatGPT 最强的用法不是“写一篇文章”，而是把内容拆成可验证的小块，然后你再组合：

  1. 先要大纲（每节 3-5 个要点）
  2. 每节单独写（强制给示例/反例/边界条件）
  3. 加 FAQ（至少 6-10 个问题，覆盖读者真实困惑）
  4. 最后做一致性检查（术语、链接、结构、是否有空洞段落）

可复制提示词：

请把下面主题写成“可引用”的教程段落：
主题：<主题>
要求：
- 先输出大纲（H2/H3）
- 每个小节必须包含：步骤/示例/常见错误
- 最后生成 8-12 个 FAQ 问题 + 简短答案
- 不要写空话；如果缺信息就列出你需要我补的材料

双语内容：如何把中文写得像“原生”而不是直译​

做中文/英文双语时，最大的坑是“英文结构硬搬到中文”，导致阅读体验很差。你可以让 ChatGPT 做：

  • 术语表：英文术语 -> 中文常用叫法 -> 何时保留英文
  • 统一语气：教程型（你/我们） vs 文档型（推荐/必须）
  • 链接与例子本地化：把例子换成中文读者更常见的场景

示例提示词：

这是英文段落：<paste>
请翻译成中文，但不要直译：
- 用中文读者常用术语
- 句子更短，更像教程
- 保持技术准确
最后输出一个“术语对照表”。

文档站内容（教程/FAQ/对比）：一份可执行的检查清单​

如果你的目标是“内容能被读者复用、也更容易被 AI 引用”，可以用这份清单自查：

  • 标题层级明确：每个 H2 解决一个明确问题
  • 开头有 TL;DR：一句话说明结论/适用场景
  • 有步骤：至少 3-7 步，可照做
  • 有示例：包含可复制的命令/配置/代码片段
  • 有边界：列出不适用/风险点（不要只写好处）
  • 有 FAQ：覆盖 6-12 个真实问题（安装、成本、隐私、排错、对比）
  • 有相关链接：把读者导向路线图/课程/相关工具页（形成主题集群）

可复制提示词：

请按“教程质量检查清单”审查下面这篇文档（我会粘贴全文或大纲）：
- 结构（TL;DR/步骤/示例/FAQ）
- 缺失的信息（读者会卡住的点）
- 需要补充的例子与边界条件
输出：按优先级列 10 条可执行修改建议。

ChatGPT 的回答太长/太泛怎么办？​

给它“输出格式”和“字数上限”，并让它先问澄清问题：

请用 10 条要点回答（每条不超过 20 字）。
信息不足先问我 3 个问题，不要猜。

代码跑不通时，最该补的材料是什么？​

优先补这三样（比贴大段代码更有用）：

  1. 关键报错/堆栈（原样）
  2. 复现步骤（最小化）
  3. 相关文件路径（入口 + 调用处）

如何在不贴整份仓库的情况下做“多文件改动”？​

用“计划驱动”的渐进方式：

  1. 让它先列出可能涉及的文件清单
  2. 你按清单逐个粘贴关键片段
  3. 每一步只做一个小改动，并给验证命令

什么时候该强制它输出 JSON/表格？​

当你要“稳定可执行”而不是“写得好看”：

  • 测试矩阵（场景/输入/预期）
  • 迁移清单（步骤/命令/回滚）
  • 风险清单（风险/影响/缓解）

如何让它帮你写 PR 说明而不是“作文”？​

给它 PR 模板，并要求引用你的验证命令：

请写 PR 描述：
- What changed（3 条）
- Why（2 条）
- How tested（粘贴我跑过的命令）
- Risks/rollback（最多 3 条）

隐私与密钥：最稳的做法是什么？​

默认把它当外部服务：

  • 密钥/token 一律用 REDACTED
  • 客户数据用脱敏样例
  • 能用“数据结构 + 最小复现”就不要贴真实 payload

它会“自信胡说”怎么办？（证据优先）​

当你需要高准确性时，不要直接问“怎么做”，而是问“你基于什么判断”。让它先列事实、列未知、列验证步骤：

在给结论之前，请先输出：
1) 你确定的事实（基于我提供的材料）
2) 你不确定的点（需要我补充什么）
3) 你建议的验证步骤（命令/检查点）
然后再给最小解决方案。

让答案更“可执行”的一个小技巧：要求它给命令与预期结果​

当你在做工程任务（而不是聊天）时，直接把“验证”写进输出格式：

最后必须给出：
- 我应该运行的命令（如果有）
- 成功时应该看到什么
- 失败时最可能的 2 个原因

这个技巧在写文档/教程时也很好用：你让它把“读者应该怎么验证”写出来，内容会更落地。 也能有效减少“看起来很对但实际跑不通”的答案。

常见错误与修复​

错误：一次要完整答案​

修复：先要计划，只实现第 1 步。

错误：复制粘贴不理解​

修复：问“为什么”“会坏在哪里”“举例”。

错误：不贴日志/错误​

修复：堆栈和日志最值钱，原样贴。

错误：没有验证闭环​

修复：把 lint/typecheck/tests/build 固化成门槛。

Troubleshooting​

“看起来对但跑不通”​

  • 让它列假设
  • 要第二方案
  • 缩小到最小复现
  • 用测试/类型检查验证

“写得不安全”​

  • 要它做安全 review
  • 让它列 threat model（注入/鉴权/密钥）
  • 使用项目既有安全模式

“它忘了上下文”​

  • 重申目标与约束
  • 只给关键片段
  • 用‘事实区’保持一致

FAQ​

ChatGPT 能替代 Cursor/Copilot 吗？​

通常不能完全替代。ChatGPT 更强在推理与解释；IDE 工具更强在导航与快速应用改动。组合使用更稳。

新手用 ChatGPT 会不会依赖？​

会依赖的原因通常是“不练习”。正确用法是：先自己做，再让它 review；让它给练习题与反馈，而不是直接给最终答案。

一个好的练习节奏是什么？​

每周选一个固定练习：

  1. 从自己项目里找一个小 bug 调试
  2. 做一次最小 diff 重构
  3. 为一个 tricky 行为补测试
  4. 为一个功能写一页文档

重复几次，你会形成“问 → 改 → 验证”的肌肉记忆。

什么时候该从 ChatGPT 切换到 Cursor/Copilot？​

当瓶颈变成“跨文件改动太多、复制粘贴太频繁”时，就该上 IDE 原生工具。

代码提问时如何排版？​

  • 用 fenced code block
  • 只贴最小相关代码 + 调用处 + 错误
  • 要求先给计划再给代码

如果改动很大，让它每一步停下来给你审查，永远如此。

相关学习路径​

下一步​