我发现很多人写“ChatGPT 编程技巧”,写出来的东西都不太像真实工作。
要么是“写个贪吃蛇”。要么是“用一句 prompt 生成一个博客系统”。这种内容看起来热闹,真到自己上班的时候,基本用不上。
这次我换了个思路。不是自己硬编场景,而是去翻开发者真实讨论。他们到底把 ChatGPT 用在什么地方,哪些地方真的省时间,哪些地方只是看起来厉害。
我先看了几组讨论量很高的 Reddit 线程,挑出了一批足够具体的案例。你会发现,真正高频的用法很少是“从零生成一整个项目”,更多是卡在某个具体环节时,把 ChatGPT 拉进来当一个很快的辅助位。
如果你平时也写代码,这 10 个场景基本都能对上号。
一、先别让它“直接开写”,先让它把方案讲清楚
一个很常见的误区,是把一句模糊需求丢过去,然后等它吐 300 行代码。
真实开发里,这么做通常会翻车。因为你自己都还没把边界讲清楚,它写出来的东西大概率只是“看起来像能跑”。
更稳的用法,是先让它把问题拆开。比如你要做一个后台审批流,不要一上来就说“帮我写”。你可以先把上下文、技术栈、数据流、权限边界喂进去,让它先回答三件事:应该怎么拆模块,最容易出问题的地方在哪,第一版最小可行实现是什么。
这一步做完,再让它落代码,质量会高很多。
我建议的问法像这样:
你先不要写代码。
先根据下面的业务背景,给我一个可落地的实现方案。
请按这几个部分回答:
1. 模块拆分
2. 数据结构
3. 接口设计
4. 最容易出 bug 的边界条件
5. 第一版最小实现顺序
很多 Reddit 开发者分享的高频用法,本质上也是这个逻辑。先让模型把脑暴整理成一份工程方案,再决定哪些部分值得让它继续写。
二、查“这个功能到底是哪个版本开始有的”
这个场景很实用,而且很像真实工作。
比如你想给老项目升级一个库。你知道新版本支持某个特性,但项目又不能直接升到最新版。这时候你真正想知道的不是“这个库好不好用”,而是“最少升到哪个版本,才能拿到这个能力”。
这类问题用传统搜索也能查,但要自己翻 changelog、issue、release note、commit,来回切几次页面。ChatGPT 的价值,是先帮你把查询路径压缩一下。
更有效的提问方式不是“这个库什么时候支持 xx”,而是把约束说完整:
我们项目现在用的是 X 库 3.8。
我想用的能力是 xx。
因为兼容性原因,我希望尽量少升级。
请先判断这个能力大概是哪个版本引入的,
再告诉我应该去看哪些 release note、PR 或文档确认。
如果你不确定,请明确标出来。
重点不是让它拍脑袋给结论,而是让它给你一个“缩小搜索范围”的起点。后面你再去核对官方 release note,会快很多。
三、从源码线索里追冷门实现细节
很多开发者开始把 ChatGPT 当“技术搜索的第一跳”,用在那些关键词根本搜不准的问题上。
最典型的情况,是你知道某个行为存在,但官方文档没写清楚,issue 也不好搜。你手上只有几段源码、一两个变量名,或者一个很怪的配置 key。
这种时候,ChatGPT 不一定能一次答对,但它很适合帮你做两件事。
第一件事,是根据你给它的源码片段,推断你真正应该追哪一层。第二件事,是把模糊线索翻成更适合搜索的关键词。
比如你可以直接把源码片段贴进去:
这是我在库源码里看到的一段逻辑。
我怀疑 xx 行为和这里有关。
请你先解释这段代码在做什么,
再给我 5 个最值得继续查的关键词或文件路径。
如果你的判断依赖推测,请把推测和确定信息分开。
这类用法特别适合新接手陌生代码库的时候。它不替代你读源码,但能减少“我到底该从哪里下手”的空转时间。
四、Linux 命令、环境变量、报错排查
这个场景已经很常见了。
很多人现在遇到终端报错,第一反应已经不是开搜索引擎,而是把报错、当前命令、系统环境一起贴给 ChatGPT,让它先做一轮定位。
它在这类问题上最有用的地方,不是“直接给正确答案”,而是能很快把排查顺序排出来。
比如同样是一个 Node 服务启动失败,好的提问方式不是只贴最后一行报错,而是把下面这些一起给出去:
- 你执行的完整命令
- 操作系统和 shell
- 相关环境变量
- 最近改过什么
- 当前目录结构里最相关的几个文件
然后让它按顺序给你排查:
请不要一次给很多猜测。
请按“最可能 -> 次可能”的顺序列出排查步骤。
每一步告诉我应该执行什么命令、预期会看到什么结果、
以及不同结果分别说明什么。
这样它更像一个会陪你走流程的助手,不是一个随机给答案的搜索框。
五、Excel、SQL、Python 这种跨工具脏活,最适合交给它
这是我自己很认同的一类场景。
真实工作里,很多麻烦不在“算法多难”,而在于你要在几个工具之间切来切去。Excel 公式坏了。SQL 要改。最后还得补一段 Python 清洗脚本。每个东西都不难,但来回切上下文很烦。
ChatGPT 在这里的优势非常直接。你可以把原始公式、表结构、目标输出一起给它,让它把这条链路串起来。
比如:
我有三步事要做:
1. 先修这个 Excel 公式
2. 再把它改写成 SQL 逻辑
3. 最后给我一段 Python 脚本批量处理 CSV
请你保证三部分逻辑一致。
如果你发现我前面的业务规则有歧义,先提问,不要直接写。
这种“跨工具搬运和对齐”的工作,往往比单纯写一段函数更省时间。因为真正浪费人的,是上下文切换,不是敲代码本身。
六、处理那些“偶发”的 bug,尤其是异步和并发问题
很多模型写 demo 很能打,一到异步、竞态、重试、取消、超时,质量就开始掉。
但就算它不能一步修好,这类问题也仍然值得拿去问。原因很简单,异步 bug 最难的地方通常不是改代码,而是先把问题表述清楚。
如果你能把“什么时候发生”“偶发还是必现”“共享状态在哪里变化”“预期行为是什么”这些信息描述出来,ChatGPT 往往能帮你把 bug 从一团雾,压缩成两三种更像样的怀疑路径。
我更建议你这样问:
这是一个偶发 bug。
请你不要直接给修复代码。
先根据这段代码判断:
1. 哪些地方可能有竞态条件
2. 哪些日志最值得补
3. 我应该怎样最小化复现
4. 如果用更稳的写法重构,方向是什么
这样做的好处是,你不会被一段“看起来很对”的修复代码带偏。先定位,再修,比直接让它生成 patch 安全得多。
七、重构遗留代码时,让它先给拆分计划
重构是另一个非常适合 ChatGPT 的场景。
尤其是那种几百行甚至上千行、混着业务逻辑、数据库访问、参数校验、响应拼装的老文件。你让人一眼看完都费劲,更别说马上动刀。
这时候最值钱的不是“帮我全改完”,而是先让它做结构诊断。
比如你可以把一个大文件贴进去,让它先回答:
- 这里现在承担了哪几类职责
- 哪些逻辑应该拆到 service
- 哪些逻辑应该保留在 controller 或 route
- 哪些部分拆了以后最容易破坏事务一致性
- 拆分顺序应该是什么
这一轮如果答得像样,你再让它逐段重构。这样你更容易 review,也更不容易把一坨旧屎改成另一坨新屎。
八、把行业规则翻成程序逻辑
有个案例我印象很深。有人拿它去排查诊所的保险编码和诊断码冲突。原本要一小时的事,压到了十几分钟。
这个例子说明一个问题。很多编程工作,真正难的不是语法,是业务规则很绕。
你写的其实不是代码,你写的是“规则之间的映射”。如果规则本身已经乱了,人脑先要把它翻译一遍,代码才写得出来。
这时候 ChatGPT 很适合做中间层。你先把规则讲成人话,让它帮你整理成判断树、伪代码或者测试用例。等这些东西顺了,再落正式实现。
这个场景在支付、风控、财务、医疗、物流这些系统里都很常见。代码只是最后一步,前面的规则整理反而更耗脑子。
九、批量处理那些低层级、重复、但不能全信的编码任务
还有一种很朴素,但每天都能省时间的用法,就是拿它处理低层级重复活。
比如:
- 根据已有接口补 TypeScript 类型
- 按已有测试风格补一批测试样板
- 给一组字段生成校验器
- 根据 SQL 表结构生成 CRUD 初稿
- 把一批接口返回值映射成前端需要的 shape
这种任务最适合它。因为重复度高,规则相对清楚,人工 review 成本也低。
但这里的前提只有一个,你必须把输入样例给够。
不要说“帮我补测试”。要说“按这个文件的风格,给下面三个函数各补一组 happy path 和一组异常 path,测试框架是 Vitest,mock 方式保持一致”。
说白了,ChatGPT 在这类场景里更像一个速度很快的初级同事。你要告诉它项目是怎么干活的,它才会跟上你的节奏。
十、最值钱的不是 prompt 花活,是你给它的上下文密度
看完上面这些场景,你会发现一个共同点。
真正决定结果的,通常不是你会不会写那种很花的提示词,而是你给了多少真实上下文。
上下文越密,结果越像工程问题。上下文越薄,结果越像内容农场。
我自己比较推荐一个通用模板,基本大多数开发任务都能套:
背景:我在做什么
技术栈:我现在用什么
目标:我这次想解决什么
约束:哪些东西不能动,或者代价很高
现状:我已经试过什么,卡在哪
输出要求:你先分析、先提问,还是直接给方案/代码
风险要求:不确定的地方请明确标注
很多人觉得 ChatGPT 写代码不稳定。我觉得这话只说对了一半。
它确实不稳定。但很多时候,不稳定不是因为它完全不行,而是因为你把一个工程问题,喂成了一个信息严重不足的填空题。
哪些编程场景最值得用 Plus
如果你只是偶尔问两句语法,免费版也能用。
但如果你已经开始拿 ChatGPT 真正干活,Plus 的价值会明显很多,尤其是下面几类场景:
- 一次要喂很多上下文。比如整段日志、较大的代码片段、多个文件关系
- 需要连续追问。比如先定位问题,再修,再重构,再补测试
- 需要更强的代码理解和多轮稳定性。这个在复杂排错和重构时差别很明显
编程场景里,最怕的不是它慢一点,最怕的是聊到一半开始丢上下文,或者前后回答不一致。你一旦把它放进真实工作流,这种稳定性差异会直接变成时间成本。
FAQ
ChatGPT 真的适合写生产代码吗?
适合当辅助,不适合无脑直出。生成样板、补测试、搭脚手架、给重构方案都很好用。涉及事务一致性、权限、资金、风控这类高风险逻辑,必须人工 review。
开发者最容易用错 ChatGPT 的地方是什么?
一是上下文给得太少。二是一上来就让它直接写。三是把它给的第一版当最终答案。真实工作里,先分析、再生成、最后 review,才是更稳的顺序。
哪些编程任务最适合拿它提效?
排查报错、整理方案、跨工具转换、生成重复代码、补测试、梳理业务规则、重构大文件,这几类最容易立刻省时间。
免费版够不够开发者用?
轻度用法够。重度用法不太够。你如果经常要喂长上下文、连续追问、反复修改代码,Plus 体验会稳定很多。
最后
如果你现在还把 ChatGPT 当“自动写代码机器”,那你大概率会经常失望。
但如果你把它当一个随叫随到、能快速帮你拆问题、补搜索、整理思路、生成初稿的编程助手,它是真的能省下很多碎时间。
开发里最值钱的,不是少敲几行字。
是你少走了几次弯路,少切了几次上下文,少盯着一个怪 bug 发呆半小时。
如果你已经准备把 ChatGPT 放进日常开发流程,Plus 会比免费版更顺手一些。上下文更稳,多轮对话更舒服,复杂任务也更容易做完整。
国内如果你不方便直接开通,可以用 PayForChat 充值 ChatGPT Plus。操作上就是选套餐、付款、按提示提交信息,后台审核后就能到账,比自己折腾海外支付链路省事很多。
参考来源
本文案例主要整理自 Reddit r/ChatGPT 社区里开发者关于真实工作流的讨论。