AI 编程助手真实体验：哪些活它干得好，哪些越帮越忙

用 AI 写代码一年多，最大的收获不是"写得快了"，而是搞清楚了哪些活该丢给它、哪些活必须自己来。分错了工，它是在给你制造工作量。

一、它干得比人好的活

这些是我现在完全不自己写的：

样板代码和 CRUD。增删改查、接口封装、DTO 定义，几十行起步的重复劳动，它写得又快又规范。
正则表达式。这东西我以前每次都要搜，现在直接描述需求让它写，还会顺带给出测试用例。
数据格式转换。JSON、CSV、YAML 之间互转，字段映射、清洗脚本，一次到位。
单元测试。给它函数签名和期望行为，能一次性铺出十几个 case，包括我自己想不到的边界。
报错解读。长堆栈、没见过的库报错，它基本能直接指出第几行是什么问题。
跨语言移植。把一段 Python 改成 Go，把 jQuery 改成 React，机械但烦人，它很擅长。
写文档和注释。给它代码让它补 docstring 和 README，比自己写省事，质量也不差。
简单重构和批量重命名。改个命名规范、抽个小函数，全局替换还不会漏。
不熟悉的技术栈快速上手。“用 XX 框架搭一个最小可跑的例子”，比翻文档快。
shell、Dockerfile、CI 配置这类我记不住语法的东西。

二、越帮越忙的活

这些我吃过亏：

跨文件的大范围重构。它看不到全局，改了 A 忘了 B，编译都过不了。要么拆成小步，要么自己做。
性能调优。它会给你一堆"看起来有道理"的优化，跑分可能更慢。性能问题必须靠 profiling 数据说话。
并发和竞态。这类 bug 它经常看不出来，还会写出看似正确实则有 race 的代码。
需要领域知识的业务规则。你们公司的计费规则、审批流、历史包袱，它不知道，编出来的逻辑会一本正经地错。
环境依赖问题。版本冲突、路径问题、系统差异，它给的往往是通用答案，不一定对症。
前端像素级还原。让它对着设计稿调样式，来回十几次还不如自己量。
改动到一半的代码库。上下文是脏的，它会顺着错误的前提一直写下去。

三、怎么分配任务才划算

几条我自己一直在用的规则：

我定接口和边界，它写实现。函数签名、输入输出、错误约定我来定，实现交给它。反过来让它设计接口，后面一定返工。
我定验收标准，它写测试。我把期望行为写清楚，它写测试代码。
单次改动控制在 200 行以内。超过就拆。一次让它改十个文件，review 成本比自己写还高。
每完成一步就提交一次。小步提交，出问题能直接回退，也方便看 diff。
每天结束前自己读一遍 diff。读不懂的地方让它解释，读不懂就不该合进去。
别让它一次改太多文件。限定范围，比如"只改这个文件里的这三个函数"。

四、最贵的一个坑

最省事的用法也是最贵的：让它"直接改到能跑"。

短期看很爽，长期会积累一堆你自己也说不清为什么这么写的代码。等哪天它改不动了，接手的人（可能还是你）要从零理解。

我的做法是保留一个原则：凡是进了主干的代码，我都能讲清楚它在干什么。讲不清楚就打回去重来。

五、效率账

粗略感受：

样板类、脚本类任务，能省 70% 到 90% 的时间。
业务逻辑实现，省 30% 到 50%。
调试定位，省一半左右（前提是你会喂信息）。
设计和架构，省 0%，甚至可能倒退。

综合下来，日常开发大概能省三分之一到一半的时间。省下来的时间，值得花在想清楚要做什么上，那部分它帮不了你。

六、一句话总结

把它当成一个手速极快、读过所有文档、但完全不了解你项目的实习生。活派得好，它是十倍效率；活派得糙，它就是个制造返工的机器。