AI 在日常开发中怎么用：补全、单测、长代码阅读的实战清单
很多人觉得自己用 AI 只停留在网页提问，其实差距不在工具，而在用法。这篇把实际工作里的 AI 场景分成补全、Demo、单测、长代码阅读、报错排查、杂活处理几类，说明哪些活交给 AI 稳、哪些容易踩坑，并给出可直接照做的步骤、工具形态取舍和一份注意事项清单。
把 AI 塞进日常工作，早就过了「要不要用」的阶段，现在卡住大家的是「怎么用才不浪费」。一个很典型的困惑是：看到别人晒 Cursor、Agent、自动化测试、批量写脚本，自己却只是打开网页问几句，于是怀疑自己用得「太小白」。
从大量实际反馈里能看出，差距往往不在工具本身，而在用法：把 AI 当搜索引擎、当代码补全、当能自己跑起来干活的执行者，是完全不同的三件事。下面把这些场景、分歧和能直接照搬的做法整理一遍。
场景盘点：AI 到底被用在哪些地方
| 场景 | 典型做法 | 合适的形态 |
|---|---|---|
| 代码补全与样板代码 | 打日志、补 import、写注释、类型定义、重复性改动 | IDE 插件 |
| 需求到 Demo | 先要一个能跑的最小实现，再逐行讲解 | 对话 + Agent |
| 单元测试 | 让它补边界用例，人工验收后再让它跑起来 debug | Agent |
| 读长代码 | 几百行存储过程、混淆代码、别人写的模块 | 长上下文模型 |
| 报错排查 | 环境配置、依赖冲突、构建失败 | 对话，但要喂全上下文 |
| 数据杂活 | Excel 清洗、批量脚本、格式转换 | 对话 + 本地执行 |
| 文档与文案 | 翻译、邮件、需求梳理、市场调研 | 通用对话 |
| 整块页面 / 后台系统 | 页面、CRUD、后台管理 | Agent |
可以看出，真正每天在用的高频项其实是「补全」和「读代码」这类低风险动作，而不是「让 AI 从头写一个系统」。
分歧最大的一点：AI 能不能写业务代码
这里存在两种极端。一派几乎全交给 AI，自己只做 Code Review，戏称自己已经变成「提示词编写工作者」；另一派只让它写单测、查潜在 bug，而且对结论保持怀疑——单测可能牛头不对马嘴，报出来的 bug 也许是凭空推测。
分歧的根源是两件事：代码的可验证性和上下文密度。
- 可验证性高、反馈快：单测能跑、页面能看、脚本能执行。这类活 AI 的产出可用率很高。
- 需要大量隐含上下文、错了代价高：性能敏感的核心组件、老系统里必须遵循的固定写法。这类活 AI 的产出可用率低，改它写的东西往往比自己写还慢。
所以一条比较稳的分界线是：**让 AI 做能被快速证伪的活，别让它做错了很久之后才发现的活。**业务代码并非不能碰，但要从「小模块、行为明确、有测试兜底」的地方开始。
可以直接照搬的几种做法
1. 先要 Demo，再逐行改造
- 用一句话描述逻辑，要求给出最小可运行示例，不要框架、不要过度抽象。
- 让它逐行解释，重点追问边界条件和异常分支。
- 自己改造成符合项目规范的代码，把用例留下来当回归测试。
好处是先看见结果再决定投入，避免在错误方向上「呲牙咧嘴一步步趟坑」。
2. 单测先行 + 自测闭环
流程是：先让它按业务写单测 → 你验收用例本身是否符合预期 → 让它跑测试并修到通过 → 最后只看 diff。
关键在第二步。用例本身没人看，「测试通过」就只是自我安慰。
3. 长代码优先「读」，别急着重写
面对几百行的存储过程、混淆过的旧代码，最省时间的用法是让模型先给出结构与意图摘要，再定位到需要修改的片段。有人统计过自己的用法，大头就在分析和读文档，写代码反而是小头，这个比例其实很健康。
4. 报错要给全上下文
一次性贴齐：完整报错、运行环境与版本、最近的改动、相关配置。反复问「为什么会报错」，不如把材料一次给够。要提醒的是，模型对版本相关的问题有可能编造，涉及具体版本行为时以官方文档为准。
5. 拆分重构
把五百行业务代码拆成若干不超过一百行的小块，是 AI 比较稳的用法：输出可以被 review，且不改变行为，出错也容易定位。
6. 把重复的杂活整批交出去
表格的条件清洗与合并拆列、文案批量翻译成 i18n 的 json、一次性处理脚本、变量命名、加日志，这些「繁琐但不复杂」的活交给 AI，收益最直接。做错就撤销，一般来回两三次就能对。
工具形态怎么选
| 形态 | 适合的时机 | 主要代价 |
|---|---|---|
| 网页对话 | 还在想清楚问题、查资料、写文档 | 需要自己粘贴上下文 |
| IDE 补全 | 手已经在键盘上，做连续的小改动 | 跨文件大改较弱 |
| Agent | 任务能自己跑起来验证，如单测、批量重构、初始化项目 | 耗 token，容易跑偏 |
一个常见误区是「把所有事都塞进 IDE 插件」。有人明确说过，集成到编辑器里的对话实测不如网页端顺手，于是把分析文档、写一次性脚本留在网页。反过来，纯网页对话去改代码也很低效——没有仓库上下文，模型只能靠猜。
至于免费版还是付费版，重度使用下真正的瓶颈通常不是功能，而是额度与上下文长度；长任务、大文件、多轮修改会很快把配额吃掉。
一份踩坑检查清单
- 幻觉优先验证：模型给的 API、参数名、库函数签名，粘贴前先查一遍。
- 核心链路不整段生成：性能敏感、并发、资金相关的代码，宁可用它查 bug 也不要用它写主体。
- 代码合规：把公司代码传到第三方平台或仓库前，先确认内部规定，别默认「私有仓库就没事」。
- 长文档会偷懒：翻译长文档时模型可能悄悄省略段落，需要抽查首尾和章节数。
- 控制单次改动规模：AI 写得越多，Review 成本越高，改动量要小到能被认真看完。
- 保留撤销余地：表格和文档类操作先备份或小步试，别一次性让它重排整个文件。
- 长任务要考虑中断：Agent 跑构建、跑自测经常要十几分钟以上，本机休眠、断电、网络抖动都会打断。如果这类任务很频繁，或者本地机器编译时明显吃紧，可以把执行环境放到一台长期在线的远程机器上——比如整机托管在机房的新加坡独享远程 Mac，本地只负责连上去看结果和 review，网络和供电都稳定，也能顺带缓解本地性能与发热压力。这属于可选做法，不是必需。
小结
如果现在的用法还停留在「网页里问几句」，不必焦虑，按收益排序往上加就行：
- 先开 IDE 补全，解决样板代码和重复改动。
- 再把报错排查交给对话，练习「一次给全上下文」。
- 然后让它写单测，你只负责验收用例。
- 之后尝试「先 Demo 后改造」，处理小模块。
- 最后才考虑 Agent 跑整块任务，并且始终保留人工 review 这一环。
工具会一直换，但判断标准不变：这件事错了以后，我多久能发现？ 发现得越快，越可以放心交给 AI。
