AI编程工具

等级 L2 · 每天 30 分钟 · 场景:选工具→一、三类工具的定位差异,写代码→二、什么活交给谁

一句话：工具三个月一变，所以这篇不做评测榜，只讲怎么判断哪类工具适合哪种活——以及一个比选工具重要得多的动作：把项目上下文固化成规则文件。

学习地图

你的问题	看哪一节
「该装哪个」	一、三类工具的定位差异
「什么该让 AI 写」	二、什么活交给谁
「每次都要重新解释项目背景」	三、项目规则文件
「它老是改错文件/看不到相关代码」	四、上下文管理
「怎么进团队流程」	五、把工具接进现有流程

一、三类工具的定位差异

按能接管多大范围的活分三类，这个分法比按厂商分有用：

类别	交互形态	擅长	不擅长
补全型（如 GitHub Copilot 的经典形态）	边打字边给建议	样板代码、重复模式、写到一半的函数	跨文件改动、需要理解全局的任务
对话型（IDE 内嵌的 AI 面板 / Cursor 这类 AI 优先编辑器）	选中代码问问题、让它改	解释代码、局部重构、单文件生成	长链路任务、需要跑命令验证的活
代理型（如 Claude Code）	交代任务，它自己读文件、改代码、跑命令、看结果	跨文件重构、按报错自主定位、批量修改、写完就跑测试验证	需求模糊时容易跑偏；要盯着 review

三类不冲突，实际是叠着用的：补全型处理击键级别的加速，对话型处理”这段什么意思”，代理型处理”把这个功能做完”。

怎么判断一个新工具值不值得试

不看宣传，看三件事：

它能不能看到足够的上下文——能不能自动找相关文件，还是全靠你手动贴
它能不能验证自己的产出——能跑测试/编译的，比只会生成文本的强一个量级
它认不认项目规则——支不支持规则文件，决定了你要不要每次重复交代规范

第 2 条是分水岭。能自己跑一遍看到报错的工具，产出质量完全不同——它会自己改到通过，而不是把一段编译不过的代码丢给你。

二、什么活交给谁

这张表来自实际使用，不是理论推演：

活	交给 AI 的程度	说明
DTO / VO / 配置类 / 枚举	✅ 基本全托	样板代码，错了也一眼能看出来
单元测试的边界用例	✅ 大部分	它想到的边界比人齐；业务语义的断言你补
写死的映射、格式转换、解析	✅ 基本全托	逻辑直白，易验证
读懂陌生代码 / 开源框架源码	✅ 很适合	让它解释调用链，比自己跟断点快
CRUD 接口第一版	🟡 生成后逐行审	结构能用，细节（事务、异常、参数校验）要改
重构 / 改造现有逻辑	🟡 先看计划再动手	让它先列改动范围，确认后再执行
排查线上问题	🟡 当助手不当结论	让它给假设，你去验证——见下
核心业务逻辑	🔴 自己写，让它 review	出错代价高，且往往依赖它不知道的业务背景
涉及钱 / 权限 / 删数据	🔴 自己写	当成实习生代码来审，一行不放过
架构决策	🔴 自己定	可以让它列对比维度，结论你来下

判断标准不是「AI 写得了吗」，是「写错了代价多大、验证起来多容易」。 容易验证 + 代价低 → 放心交；难验证 + 代价高 → 自己来。

排查问题时的正确用法

❌ 这个报错是什么原因？（然后照着它说的第一个原因去改）
✅ 这是完整堆栈和相关代码，给我 3 个最可能的原因，
   按可能性排序，每个说明怎么验证。

让它给假设，你去验证——这个模式能避开幻觉带来的最大风险：它给的第一个原因听起来很合理，但可能完全不是真因，你照着改会浪费半天。

三、项目规则文件

这是收益最高、最多人没做的一件事。

主流代理型工具都支持在项目根目录放一个规则文件（Claude Code 的 CLAUDE.md、其他工具的 rules 文件），每次对话自动带上。把「每次都要重复解释的东西」写进去一次：

# 项目说明
 
## 技术栈
Spring Boot 3.2 + MyBatis-Plus + MySQL 8 + Redis 7，JDK 21
 
## 目录约定
- controller 只做参数校验和转发，不写业务逻辑
- service 层方法必须标注事务边界
- 所有对外接口的出参统一包 Result<T>
 
## 本项目的坑
- 订单表已按月分表，写 SQL 必须带 create_time 条件
- 不要用 @Transactional 包住远程调用（历史事故）
 
## 命令
- 跑测试：./mvnw test -Dtest=XxxTest
- 本地起服务：./mvnw spring-boot:run -Plocal

写规则文件的三条经验

写「本项目特有的」，不写通用知识——不用告诉它什么是依赖注入，要告诉它你们的分层约定
写踩过的坑——「不要用 X，我们出过事故」这类信息它没法自己知道，价值最高
写命令——怎么跑测试、怎么起服务、怎么建库。能自己跑验证的工具，有了这些才能闭环

规则文件要像代码一样维护：进 git、随项目演进更新。过期的规则比没有规则更糟——它会照着错的约定写。

四、上下文管理

代理型工具用得好不好，八成取决于上下文给得对不对。

上下文不是越多越好

把整个仓库塞进去既贵又降质量——相关信息淹没在无关内容里，效果反而下降（原因见大模型基础概念）。

正确姿势是给准：

明确指出相关文件：「改 OrderService.createOrder，参考 PaymentService 的事务写法」
贴关键片段而不是整个文件
让它自己搜：好的代理型工具能按关键词找相关代码，比你手动贴更全

长会话要主动清

对话越长，成本越高、跑偏概率越大——早期的无关讨论会一直干扰后面。

换任务就开新会话。一个会话干一件事，干完就关。这个习惯的收益比任何提示词技巧都大。

小步验证，不要一次性来一大坨

❌ 帮我把用户模块重构一下
✅ 第一步：把 UserService 里的密码校验逻辑抽成独立的 PasswordValidator，
   保持行为不变，跑通现有测试。做完我看一眼再继续。

一次改一小步，每步能验证。大改动出问题时，你分不清是哪一步错的——这和写代码要小步提交是同一个道理。

五、把工具接进现有流程

个人用顺了之后，往团队推的几个落点：

落点	做法	注意
Code Review	提 PR 前先让 AI 过一遍，或接进 CI 做自动 review	它擅长找空指针、边界、并发问题；不擅长判断业务是否正确
写测试	给现有代码补测试用例	覆盖率能快速拉起来；断言的业务含义要人来定
写文档	生成接口文档、README、变更说明	事实要核对，尤其是配置项和参数
commit / PR 描述	让它按 diff 生成	省事且规范；关键改动的”为什么”要自己补
新人上手	让新人用 AI 读代码库	配合规则文件效果最好

推广时最容易翻车的两点

没定边界就全员放开——公司代码能不能传给外部服务，先问清楚。这是合规问题不是技术问题，详见 AI工程化与风险。
拿它当 KPI——「AI 生成代码占比」这类指标会逼出垃圾代码。要衡量就衡量结果（交付速度、缺陷率），不衡量过程。

常见追问

补全型和代理型只能选一个吗？ 不是，正常是都开着。补全型处理击键级加速（写到一半自动补完），代理型处理任务级委托（“把这个功能实现了”）。两者互不干扰。
AI 写的代码怎么 review 才高效？ 三个重点：边界条件（空值、越界、并发）、它有没有编 API（不存在的方法、配置项）、是不是过度设计（AI 倾向于加不必要的抽象和防御性代码）。业务逻辑正确性只能靠你自己——它不知道你们的业务规则。
它总是改我没让它改的地方？ 两个办法：把任务说小（「只改这个方法，别动其他文件」）；在规则文件里写清楚「不要主动重构无关代码」。新模型对这类约束遵循得不错，说了基本就听。
用了之后感觉自己变菜了？ 有真实风险。建议：核心逻辑坚持自己写，把 AI 用在样板代码和重复劳动上；读 AI 生成的代码时问自己”我能写出来吗”，答案是否的时候去补课。工具应该扩展能力边界，不是替代它。
怎么衡量到底提效了多少？ 别做精确统计，做主观记录：每周记一笔「这周哪几件事因为 AI 快了、哪几件反而慢了」。两个月后回看，模式会很清楚。慢了的那些，通常是需求模糊或验证成本高的任务——那些本来就不该交给 AI。

Interview Wiki

探索