AI 编程提效是真的，但坑也是真的。我现在最警惕的是这几类： 第一，改得太顺。AI 很容易给你一种“它都懂了”的错觉。实际上它可能只是顺着命名猜，遇到隐藏约束就翻车。 第二，测试太假。它会写出能过的测试，但不一定写出有保护力的测试。 第三，依赖幻觉。一个包、一个 API、一个配置项，看起来像真的，实际不存在或者版本不对。 第四，局部正确、全局不通。单个函数没问题，接到现有项目里就破坏了缓存、权限、事务或兼容逻辑。 第五，人开始懒得 review。这个最危险。AI 让写代码变快，但不代表理解成本消失了。 我现在的底线是：凡是 AI 改过的核心逻辑，必须自己看 diff；凡是涉及数据、权限、支付、删除、迁移，必须跑验证；凡是它引用的库和 API，必须查官方文档。 把 AI 当加速器很好，把它当责任人就不行了。

我做过几次中文代码解释的小对比，感觉 DeepSeek、Qwen、Claude 的差异不是“谁一定赢”，而是风格不同。 Claude 通常解释得更稳，尤其是复杂调用链、边界条件、隐含假设，它更愿意把上下文讲完整。缺点是有时候篇幅偏长。 DeepSeek 在中文表达和代码理解之间的平衡不错，回答比较直接，适合快速看懂一段逻辑。对国内开发者来说，可获得性和成本也更友好。 Qwen 的优势是中文生态和国内部署选择多，做企业内部工具时比较容易纳入现有链路。解释业务代码时，如果上下文给得足，它也能做得不错。 我建议不要拿“解释一个函数”就决定主力模型。更好的测法是准备 10 个真实样本：老代码、异常栈、复杂 SQL、前后端联调、配置问题各放几个。让模型分别解释，再看谁更接近你团队的表达习惯。 模型选型最后不是排行榜问题，而是团队工作流问题。谁能让团队少误解、少返工，谁就更适合。

让 AI 改大型代码库，我最不推荐的说法是：“帮我把这个模块重构一下。” 这句话太大了。AI 会努力完成，但它不知道你真正能接受的风险边界在哪里。结果往往是：改动很多，diff 很漂亮，你却不敢合。 我更愿意把任务拆成这种形状： 第一步，只读代码，画出调用关系 第二步，只改命名，不动行为 第三步，补测试，确认当前行为 第四步，做最小结构调整 第五步，跑测试，整理剩余风险 这里的关键不是“AI 会不会写”，而是每一步都能被检查。大代码库最怕不可验证的聪明改动。 还有个经验：让 AI 每次改完都总结“它改了什么、为什么改、还没确认什么”。这个总结很有用，因为你 review 的时候能顺着它的意图看 diff，而不是在几十个文件里迷路。 大项目里，AI 最适合做耐心活：读文件、找引用、列影响面、补重复测试、批量替换。真正的架构判断还是要人来定。

我越来越觉得，AI 编程真正的成本不是模型费，而是上下文管理。 很多时候 AI 写不好，不是因为模型不行，而是它拿到的信息太乱：旧 README、过期注释、没说清楚的目录职责、没人维护的测试命令。它只能在一堆不确定信息里猜。 我现在会给项目准备几类“喂给 AI 的材料”： 项目入口：这个项目是干嘛的，核心模块在哪里 运行方式：开发、测试、构建分别怎么跑 代码规矩：命名、错误处理、日志、接口返回格式 禁区：哪些文件不要动，哪些逻辑要兼容旧数据 验证方式：改完至少跑哪些测试或命令 这些东西不只是给 AI 看，也是在帮团队自己整理知识。很多老项目没人敢改，本质上也是因为这些上下文散了。 还有一点：不要每次都把问题丢给 AI 从零理解。能沉淀到 README、CLAUDE.md、CONTRIBUTING 的，就沉淀下来。下一次它会更快进入状态，人也会更省心。 如果你觉得 AI 经常“理解错项目”，先别急着换模型，先看看你给它的上下文是不是本来就不够清楚。

GitHub Copilot 到 2026 还值不值得用？我的答案是：值，但它的位置变了。 它不再是那个“用了就觉得跨时代”的工具了。现在 Cursor、Claude Code、Codex 这类工具把上限拉得很高，Copilot 的优势反而变成了稳定、轻量、低打扰。 我会把它放在这些场景里： 写样板代码 补参数、补类型、补简单分支 根据上下文完成小函数 在已有代码风格里继续写几行 但如果任务是“读完整个仓库后重构”“跨文件迁移”“自动跑测试并修复”，Copilot 就不是最合适的主角了。 所以我不会说 Copilot 过时。它更像键盘增强，不像项目 Agent。对团队来说，这种工具反而容易推广：学习成本低，对现有流程影响小，也不会让新人一下子把大任务都交给 AI。 如果你只想日常提速，Copilot 仍然够用；如果你想把 AI 变成开发流程的一部分，那就需要 Cursor、Claude Code 这类更主动的工具一起上。

AI 写单元测试确实快，但我踩过一个很典型的坑：它很容易写出“看起来覆盖了，其实什么也没防住”的测试。 最常见的情况是，它把实现逻辑又抄了一遍。代码怎么写，它测试就怎么断言。这样测试当然能过，但一旦实现本身有 bug，测试也跟着错。 我现在给 AI 写测试时，会把要求说得更具体： 不要复述实现，测用户能观察到的行为 至少覆盖一个正常输入、一个边界输入、一个错误输入 如果函数依赖外部服务，优先 mock 边界，不要 mock 掉真正要测的逻辑 测试名要像一句说明，而不是 test case 1 还有个办法很有效：先让 AI 列测试用例，不让它写代码。你先看用例是否靠谱，再让它补测试。这样能避免它直接冲进实现细节。 AI 写测试最适合的不是“替我保证质量”，而是“帮我把我已经想清楚的质量标准快速落地”。这两件事差别很大。 你们有遇到过那种全部绿灯、上线照样炸的 AI 测试吗？

第一次用 Claude Code，不建议你上来就让它“写一个完整功能”。这样很容易失望，因为你会发现它动了很多文件，但你心里没底。 我更推荐这个顺序： 先让它解释项目结构 再让它解释一个报错 然后让它补一两个测试 最后才让它改代码 这几个步骤的风险是逐渐增加的。读代码几乎没风险，补测试可以验证，改代码才是真正需要你 review 的地方。 还有一个特别有用的小习惯：在项目根目录写一份 CLAUDE.md。不用长，写清楚技术栈、启动命令、测试命令、目录约定、不要碰哪些文件。这个文件对 Claude Code 的影响比很多人想象得大。 我现在比较常用的工作流是： “先不要改，先读这几个文件，告诉我你理解的调用链” “基于这个理解，给我一个最小改动计划” “按计划改第一步，改完跑测试” 这样用起来，它更像一个能执行任务的同事，而不是一个随机生成代码的聊天窗口。 如果你已经在用 Claude Code，可以分享一下你的 CLAUDE.md 怎么写的，我也想看看大家的实战模板。

我最近看别人聊 Cursor 和 Claude Code，经常会被带到“谁更强”这个问题上。但真拿老项目重构来说，我觉得这个问题问反了。 老项目最麻烦的不是让 AI 写代码，而是你能不能放心让它动很多文件。这里 Cursor 和 Claude Code 的气质差别很明显： Cursor 更像坐在你旁边的编辑器搭子，适合边看 diff 边改。你想一处处确认、慢慢推进，它很舒服。 Claude Code 更像一个能在终端里跑任务的执行者，适合先让它读项目、列计划、改一批文件、再跑测试。 我的实际建议是：小范围重构、命名调整、局部逻辑梳理，用 Cursor；跨目录的批量改造、迁移、测试补齐，用 Claude Code。但前提只有一个：你得有测试。没有测试时，工具越强，越可能把风险放大。 重构前我一般会先让 AI 做三件事：读结构、列风险、给改动计划。计划没问题再让它动手。不要一上来就说“帮我重构整个项目”，那基本是在把方向盘交出去。 你们现在重构老项目时，更信任 Cursor 这种逐步确认，还是 Claude Code 这种长任务执行？