某AI Coding工具 + AI Agent：研发效能的范式转移
2024 年我开始基于 某AI Coding工具 构建研发 Agent 工具链。跟 2023 年的 AI Agent 不同——23 年是“让 AI 帮运营跑业务”，24 年是“让 AI 帮研发写代码”。
为什么是 某AI Coding工具 而不是 GitHub 某代码补全工具？
某代码补全工具 是补全式的——你写一半，它帮你补完。某AI Coding工具 是代理式的——你描述需求，它自主完成。
两者的本质区别：
| 某代码补全工具 | 某AI Coding工具 | |
|---|---|---|
| 交互模式 | 补全 | 对话+自主执行 |
| 上下文 | 当前文件 | 整个项目 |
| 能力边界 | 代码生成 | 编码+调试+部署+测试 |
| 适用场景 | 写代码时 | 整个开发流程 |
在 某业务线 业务中，某AI Coding工具 可以直接理解整个项目结构，然后：
- 理解需求文档
- 修改多个文件
- 写单元测试
- 运行测试并修复失败
- 提交 PR
整个过程，研发只需要描述需求和 code review。
实操：一次 某业务线 业务改造
需求：某业务线 线索分配逻辑从“轮询分配”改为“基于销售转化率的智能分配”。
传统模式：
- 2 天需求分析
- 3 天开发
- 1 天测试
- 0.5 天 code review
某AI Coding工具 模式：
- 把需求文档 + 现有代码喂给 某AI Coding工具
- Claude 生成改造方案，确认
- 自动修改 5 个文件，新增 1 个文件
- 自动生成 8 个测试用例，3 个失败
- Claude 分析失败原因并自动修复
- 全部通过，提交 PR
总耗时：1 天（主要是需求对齐和 code review），编码时间几乎为零。
关键经验
1. Prompt 决定天花板
给 某AI Coding工具 的 prompt 质量直接影响产出。好的 prompt：
好的 prompt：
"某业务线 线索分配目前是轮询的。改为按销售近 30 天转化率降序分配，
高转化的销售优先拿到线索。需要考虑冷启动（新销售无历史数据）。
具体改动点：
- src/lead/allocator.ts 的分配逻辑
- config/lead_allocation.yaml 新增权重配置
- 需要兼容旧版 API（v2 才能废弃）"
不好的 prompt：
"改一下线索分配的代码"2. 人类 review 不可省略
Claude 生成的代码需要在三个方面额外注意：
- 边界条件：测试覆盖不到的极端 case
- 性能影响：Claude 不考虑时间复杂度
- 安全漏洞：SQL 注入、权限校验等
3. 小步快跑
不要一次让 Claude 改太多。拆成独立的、可验证的步骤，每步 review 确认后再下一步。