AI Coding 实战：我现在怎么用这些工具

工具不是越多越好

现在 AI 编程工具很多，Cursor、Claude Code、Codex、Gemini、Qwen、Repomix，都有自己的位置。

我现在不会先问“哪个工具最强”。更常见的做法是先看任务。

如果只是读一段代码，聊天工具就够了。

如果要理解整个仓库，我会先用 Repomix 把代码打包，再让模型看结构。

如果要改一个真实功能，我更愿意用 Claude Code 或 Codex 这种能在代码库里直接跑的工具。

如果是做界面草图，HTML 比单纯描述更好。让 AI 先生成几个版本，再从里面挑一个改，比从零开始慢慢想更快。

我怎么拆任务

AI 做小任务很快，做大任务容易跑偏。

所以我一般会先把任务拆成几块：

• 先让它读代码，不急着改
• 再让它说清楚准备改哪些文件
• 然后只改一小块
• 改完以后跑测试，或者至少给出自查清单
• 最后自己看 diff

这个流程看起来慢，但比直接让它“大改一下”靠谱得多。

我现在最常用的一句话不是复杂 prompt，而是很普通的要求：

先不要改代码，先告诉我你理解的现状、问题在哪里、准备怎么改。

这句话能拦住很多乱改。

AI 生成之后还要看什么

AI 写出来的代码，最容易有三个问题。

第一个是看起来能跑，但边界没处理。比如空数据、权限、异常状态、重复请求。

第二个是局部没问题，但破坏了原来的结构。它可能为了完成当前任务，加一个很奇怪的分支，或者绕开已有抽象。

第三个是代码风格不稳定。同一个项目里，命名、错误处理、状态管理、目录结构最好保持一致。AI 很容易写出“另一个项目的风格”。

所以我看 AI 生成代码时，一般会重点看：

• 有没有改到不该改的文件
• 有没有引入新的状态和副作用
• 有没有绕开已有工具函数
• 有没有缺测试或缺边界判断
• 代码是否符合项目原来的写法

这些判断不能完全交给 AI。

哪些场景比较适合

我现在觉得 AI 最适合几类任务。

第一类是读代码。让它解释一个模块、画出数据流、找关键函数，效率很高。

第二类是补样板。比如表单、接口类型、测试用例、文档初稿，这些不太需要创造力，但很耗时间。

第三类是做方案对比。让它给出几种实现方式，再让它自己挑毛病，可以帮助我更快看到盲区。

第四类是做原型。尤其是前端页面，先做一个能看的版本，再慢慢改，比空想快很多。

不太适合的是完全没有边界的大任务。

如果你自己都说不清楚要什么，AI 也很难给出好结果。它会很努力地生成一大堆东西，但未必是你需要的。

所以我现在的用法很简单：让 AI 多做体力活和第一版，让人负责判断方向、拆任务和收尾。