程序员每天在用的 5 个 AI 工具（附实测场景与适用边界）

目录背景ChatGPT / Claude代码初筛与需求拆解GitHub Copilot上下文补全Cursor自然语言改代码Kimi / 豆包长文本处理即梦 / Midjourney视觉素材生成一点观察背景我主力语言是 Java平时也写 Python 脚本做一些 side project。下面这些工具是我过去一年多反复用过、最终留在日常工作流里的。不一定适合所有场景文中会标出我观察到的局限。1. ChatGPT / Claude代码初筛与需求拆解这是我使用频率最高的工具主要落在三个场景。代码 review。写完一段逻辑后我会把函数贴进去让它找潜在问题。它给出的建议不一定全对但能覆盖到我容易忽略的几类边界条件没处理空值、越界、并发异常处理缺失或捕获过宽个别情况下能指出 O(n²) 这类性能隐患它适合做第一轮筛查不能替代人工 review。我把它当成一个「不会嫌烦的初筛 reviewer」。指向越具体建议越可用。下面是一个可直接复用的 review 提示词你是一个资深 Java reviewer。请检查下面这段代码从三个角度给出问题清单 1. 空值与边界条件 2. 异常处理的范围是否合理 3. 是否存在明显的性能问题如 O(n²) 循环、不必要的对象创建 只列问题不重写代码。 ​ public OptionalUser findActiveUser(Long id) { ListUser all userMapper.selectAll(); for (User u : all) { if (u.getId().equals(id) u.isActive()) { return Optional.of(u); } } return Optional.empty(); }陌生语言/框架的示例生成。比如我主力是 Java偶尔要写 Python 数据处理脚本。直接描述需求让它出示例再在此基础上改比从零查文档快。需求文档拆解。遇到结构混乱的需求文档让它提炼核心需求并列实现步骤。它能很快给出一个可用的任务清单我再人工调整。局限复杂业务逻辑上它容易给出「看起来对但跑不通」的代码。涉及多个模块协作、有特定业务约束的部分我会自己写。2. GitHub Copilot上下文补全它是一个集成在编辑器里的上下文补全工具。你写一半它基于上下文补一半。我记录过一段时间它的补全准确率。模板代码CRUD、表单处理、DTO 转换、数据映射这类它的补全准确率大约在 80% 以上多数情况可以直接 tab 接受。真正复杂的逻辑它的建议经常不对。但这个场景下它的价值不在「替你写」而在「给你一个起点」。即便它补错了我改它的成本通常也比从零写低。我在意它的点和大多数人不太一样。我关心的不是它帮我省了多少打字时间而是它接管了日常代码里大约 70% 的模板活让我能把注意力集中在剩下 30% 真正需要设计的逻辑上。一个使用习惯上的建议别盲目 tab。它会错而且错得很自信。我每次都扫一眼再接受。VS Code 安装 Copilot 的关键配置.vscode/settings.json片段{ github.copilot.enable: { *: true }, editor.inlineSuggest.enabled: true, github.copilot.advanced: { length: 500, listCount: 3 } }3. Cursor自然语言改代码Cursor 把 AI 能力做进了编辑器的底层交互不是作为一个外挂插件。我最常用的两个功能CmdK / CtrlK 自然语言改代码。选中一段代码输入「重构成函数」「加异常处理」「换更高效的写法」它直接改。对中等规模的重构比自己手动改快不少。下面是一段让 Cursor 做异常处理加固的典型操作。选中代码后在 CmdK 输入给下面这段方法补全参数校验和异常处理id 为空时抛 IllegalArgumentException 数据库调用失败时捕获并记录日志不要向上抛原始 SQLException。 ​ public Order getOrder(Long id) { return orderMapper.selectById(id); }预期它会把方法改写为带校验和 try-catch 的版本同时保留原有返回逻辑。报错排查。它能看到完整的代码上下文。控制台报错时它能在上下文里定位问题并给出修改建议省去复制错误信息去搜索的步骤。局限它偶尔会理解错意图改出新的 bug。重构幅度越大出错概率越高。我的用法是小范围改动直接接受大范围改动让它生成 diff我逐段确认。我现在新开项目默认用 Cursor。是否切回去用纯 VS Code取决于项目本身是否允许引入这类工具。4. Kimi / 豆包长文本处理这类工具我用得最多的是「读长文本」这个场景。每周基本都会遇到需要处理大段文字的情况几十页的技术方案、陌生开源项目的源码、看不太懂的论文、竞品的产品文档。直接扔进去让它出摘要、提炼要点、回答具体问题。我试过把一份 60 多页的方案文档给 Kimi它能稳定说清楚每章的核心内容以及章节间的依赖关系。为什么选国产模型而不是 ChatGPT主要两个原因长文本处理上Kimi 和豆包在这一两年确实能打几十万字一次读进去信息丢失比较少。国内访问稳定免费额度够日常用。读长文档时可用的提问模板请阅读这份技术方案完成三件事 1. 用不超过 200 字概括整体目标 2. 列出各章节之间的依赖关系 3. 指出方案中未明确的边界条件或风险点局限摘要和提炼它能做好但涉及需要深度推理的内容比如论文里的证明细节、方案里隐含的设计权衡它的回答会比较浅。这类内容我还是自己读。5. 即梦 / Midjourney视觉素材生成这类文生图工具我主要用在 side project 的视觉素材上。独立开发者大概都有这个感受项目里的 Logo、icon、封面图、配图以前要么找设计师要么自己用工具凑。一个人做项目视觉这关成本很高。现在用 AI 出图一句话描述几分钟出几十张备选。我主要用在side project 的 Logo 和 icon博客文章的封面图demo 时的占位图和示意图局限也很明显它替代不了专业设计。出图质量在「够用」和「专业」之间更靠近「够用」那一端。如果项目对视觉有较高要求还是需要专业设计师介入。一点观察把这几个工具放在一起看可以归纳出一个比较稳定的规律它们各自只覆盖了工作流里的某一层但组合起来把程序员日常的重复劳动接管了相当一部分。Copilot 接管模板代码ChatGPT 做初筛 reviewCursor 处理中等规模重构Kimi 读长文档AI 出图解决视觉素材我自己的体感是产出比两三年前有明显提升。这个提升不完全来自某个工具更多来自工具之间的配合。如果还没开始用可以先从 ChatGPT 这类通用对话工具入手把它当成一个可以随时问的技术搭子。其他工具在场景明确之后自然会加进来。以上是我个人工作流里的记录不同人的场景和习惯会有差异仅供参考。如果对你有帮助欢迎点赞收藏 关注专栏。下一期会写 Cursor 的保姆级教程从安装到高效使用。