跳转至内容
  • 0 赞同
    1 帖子
    5 浏览
    A
    让 AI 改大型代码库,我最不推荐的说法是:“帮我把这个模块重构一下。” 这句话太大了。AI 会努力完成,但它不知道你真正能接受的风险边界在哪里。结果往往是:改动很多,diff 很漂亮,你却不敢合。 我更愿意把任务拆成这种形状: 第一步,只读代码,画出调用关系 第二步,只改命名,不动行为 第三步,补测试,确认当前行为 第四步,做最小结构调整 第五步,跑测试,整理剩余风险 这里的关键不是“AI 会不会写”,而是每一步都能被检查。大代码库最怕不可验证的聪明改动。 还有个经验:让 AI 每次改完都总结“它改了什么、为什么改、还没确认什么”。这个总结很有用,因为你 review 的时候能顺着它的意图看 diff,而不是在几十个文件里迷路。 大项目里,AI 最适合做耐心活:读文件、找引用、列影响面、补重复测试、批量替换。真正的架构判断还是要人来定。
  • 0 赞同
    1 帖子
    4 浏览
    A
    我越来越觉得,AI 编程真正的成本不是模型费,而是上下文管理。 很多时候 AI 写不好,不是因为模型不行,而是它拿到的信息太乱:旧 README、过期注释、没说清楚的目录职责、没人维护的测试命令。它只能在一堆不确定信息里猜。 我现在会给项目准备几类“喂给 AI 的材料”: 项目入口:这个项目是干嘛的,核心模块在哪里 运行方式:开发、测试、构建分别怎么跑 代码规矩:命名、错误处理、日志、接口返回格式 禁区:哪些文件不要动,哪些逻辑要兼容旧数据 验证方式:改完至少跑哪些测试或命令 这些东西不只是给 AI 看,也是在帮团队自己整理知识。很多老项目没人敢改,本质上也是因为这些上下文散了。 还有一点:不要每次都把问题丢给 AI 从零理解。能沉淀到 README、CLAUDE.md、CONTRIBUTING 的,就沉淀下来。下一次它会更快进入状态,人也会更省心。 如果你觉得 AI 经常“理解错项目”,先别急着换模型,先看看你给它的上下文是不是本来就不够清楚。
  • 0 赞同
    1 帖子
    4 浏览
    A
    AI 写单元测试确实快,但我踩过一个很典型的坑:它很容易写出“看起来覆盖了,其实什么也没防住”的测试。 最常见的情况是,它把实现逻辑又抄了一遍。代码怎么写,它测试就怎么断言。这样测试当然能过,但一旦实现本身有 bug,测试也跟着错。 我现在给 AI 写测试时,会把要求说得更具体: 不要复述实现,测用户能观察到的行为 至少覆盖一个正常输入、一个边界输入、一个错误输入 如果函数依赖外部服务,优先 mock 边界,不要 mock 掉真正要测的逻辑 测试名要像一句说明,而不是 test case 1 还有个办法很有效:先让 AI 列测试用例,不让它写代码。你先看用例是否靠谱,再让它补测试。这样能避免它直接冲进实现细节。 AI 写测试最适合的不是“替我保证质量”,而是“帮我把我已经想清楚的质量标准快速落地”。这两件事差别很大。 你们有遇到过那种全部绿灯、上线照样炸的 AI 测试吗?
  • 0 赞同
    1 帖子
    4 浏览
    A
    第一次用 Claude Code,不建议你上来就让它“写一个完整功能”。这样很容易失望,因为你会发现它动了很多文件,但你心里没底。 我更推荐这个顺序: 先让它解释项目结构 再让它解释一个报错 然后让它补一两个测试 最后才让它改代码 这几个步骤的风险是逐渐增加的。读代码几乎没风险,补测试可以验证,改代码才是真正需要你 review 的地方。 还有一个特别有用的小习惯:在项目根目录写一份 CLAUDE.md。不用长,写清楚技术栈、启动命令、测试命令、目录约定、不要碰哪些文件。这个文件对 Claude Code 的影响比很多人想象得大。 我现在比较常用的工作流是: “先不要改,先读这几个文件,告诉我你理解的调用链” “基于这个理解,给我一个最小改动计划” “按计划改第一步,改完跑测试” 这样用起来,它更像一个能执行任务的同事,而不是一个随机生成代码的聊天窗口。 如果你已经在用 Claude Code,可以分享一下你的 CLAUDE.md 怎么写的,我也想看看大家的实战模板。
  • 0 赞同
    1 帖子
    6 浏览
    A
    我最近看别人聊 Cursor 和 Claude Code,经常会被带到“谁更强”这个问题上。但真拿老项目重构来说,我觉得这个问题问反了。 老项目最麻烦的不是让 AI 写代码,而是你能不能放心让它动很多文件。这里 Cursor 和 Claude Code 的气质差别很明显: Cursor 更像坐在你旁边的编辑器搭子,适合边看 diff 边改。你想一处处确认、慢慢推进,它很舒服。 Claude Code 更像一个能在终端里跑任务的执行者,适合先让它读项目、列计划、改一批文件、再跑测试。 我的实际建议是:小范围重构、命名调整、局部逻辑梳理,用 Cursor;跨目录的批量改造、迁移、测试补齐,用 Claude Code。但前提只有一个:你得有测试。没有测试时,工具越强,越可能把风险放大。 重构前我一般会先让 AI 做三件事:读结构、列风险、给改动计划。计划没问题再让它动手。不要一上来就说“帮我重构整个项目”,那基本是在把方向盘交出去。 你们现在重构老项目时,更信任 Cursor 这种逐步确认,还是 Claude Code 这种长任务执行?