搜索
  • 新来的leader上来就准备用Claude code升级现有项目
  • 发布于 1个月前
  • 81 热度
    12 评论
现有的项目背景，已经平稳运行了有接近 10 年了。所有的拓展、报表、API 等全部基于 PHP7 Laravel 5.2 进行的开发，最终目标是升级到最新的 Laravel 12
简单的使用 find . -type f -name "*.php" | wc -l 发现有接近 7500 个 php 文件。升级的原因是老板认为版本过老，有潜在的漏洞风险。

关于新的 leader ，目测有 20 年以上的开发经验，但他几乎不懂 php ，有.net react nodejs 的开发经验，Claude code Max 忠实用户，最近又新开了几个 Max 账号给其它三位 php 开发。目前执行到了第一步，先简单的从 5.2 升级到 5.3 试试水，让 Claude/Chat-GPT 生成了大概 12 个步骤，每个步骤都单独进行 git commit ，整体执行下来已经消耗了整月 20%的 token ，升完后遇到 bug 喂给 Claude 解决，一直反复进行。三位同事的反馈是 Claude 升级的时候会改现有的业务逻辑，需要大量的时间去 review 代码。各位有没有使用过 AI 来进行老项目升级的经历？
用户评论
  • DuXing
  • 我也升级了一个 PHP 项目，从 php5.6 升级到 8.3 ，Wordpress 从 4.x 升级到 6.8 ，wp 的向下兼容做得还不够错，遇到的错误和警告 ai 基本能处理。有些插件已经没人再升级维护了，我用 ai 修复了里面的写法。
  • 2025/10/25 19:43:00 [ 0 ] [ 0 ] 回复
  • Dock
  • 上面所有同学说的反对意见都很正确,贴合实际,但作为旁观者,我倒是想看看这么升级的进展, 反正我自己肯定不这么搞
  • 2025/10/25 19:28:00 [ 0 ] [ 0 ] 回复
  • 冰魄
  • 1. 我个人经验 laravel 在你们没定制底层的基础上兼容性其实是很好的。有很多老的方法现在不推荐使用（甚至文档上完全没有相关踪迹），但依然是可以使用的。（例如 model 里自定义属性以前是用同名方法现在是用 Attribute ；鉴权以前可能是在 controller 的前置 filter 或 middleware 里完全自己写逻辑现在推荐用 guard ）
    2. 个人经验，单纯的依赖 AI ，它会把很多老的方法改成最新的推荐的写法，这当然没错，但没必要，尤其是一次性改这么多是毫无疑问不推荐的。。。
    3. 建议是直接 composer 硬升版本，然后把 bug 丢给 AI 去解决
    4. 更好的做法是让 AI 先去写一堆 test cases ，然后再升级
  • 2025/10/25 11:06:00 [ 0 ] [ 0 ] 回复
  • 若如初见
  • 想要避免漏洞.那就写中间件转发请求呢..用 nodejs 都行..这样随时微服务隔离后续的开发.旧的代码包一层监控起来..
    现在的机器性能.没啥性能瓶颈.无限套娃请求都无所谓的.花那时间还不如加硬件配置..
    Ai 写很多旧业务都模拟不完..
    也有可能说说而已..不然怎么入职..最终会妥协最小改动
  • 2025/10/25 10:59:00 [ 0 ] [ 0 ] 回复
  • 摇滚枷锁
  • 大型项目想使用 AI 简单重构不太现实，投入大量时间是必然的。我的建议是直接用最新版重写，或者换语言，或者什么都别做，这取决于开发资源有多少。如果只是为了解决"漏洞"，升级后还有会别的漏洞，现有代码迁移到新环境可能有新的运行时隐患，如果只是一次性投入开发资源解决旧版本隐患，说实话没多大意义。
  • 2025/10/25 10:55:00 [ 0 ] [ 0 ] 回复
  • 随风流浪
  • 现在不太适合直接应用于整个完成的复杂的生态，在这种项目中 AI 会增加添加很多“创新”，我们项目之前玩过，后面放弃了，工作量太大，一个微信小游戏项目。
  • 2025/10/25 10:50:00 [ 0 ] [ 0 ] 回复
  • 枪蹦狗友
  • 只借助 Claude Code 到 Laravel 12 很困难吧，查了一下 Laravel 12 是 2025 年 3 月 7 日发布的，而 Claude Sonnet 4.5 的知识截止日期是 2025 年 1 月
    Claude Sonnet 4.5 has a knowledge cutoff date of Jan 2025. This means the models’ knowledge base is most extensive and reliable on information and events up to Jan 2025.

    我司目前还没在大项目上完全依赖 AI 做升级，倒是在几个代码量小的 Nest.js 和 Angular 项目中测试过 AI 跨一个大版本升级的能力，怎么说呢，还凑合，相较于人类工程师来说并没有节省很多时间。因为还是需要大量的时间去审阅所有的改动。
  • 2025/10/25 10:46:00 [ 0 ] [ 0 ] 回复
  • 果酱
  • 升级原因感觉就经不起推敲，很明显风险大于收益。Claude Code 或者 Codex 我觉得是具备做老项目升级的能力的，但是就跟普通开发去重构老业务一样，非常懂业务的老开发都可能被埋坑里爬不出来。如果你不给 Claude Code 和 Codex 提供足够详细的业务背景，完善的测试来兜底。那这么大规模的修改，不踩坑就奇怪了。

    另外，至少小规模按模块迭代，分批次上线吧，一口气改完是什么👻，开着飞机换引擎，一定要挑战最高难度吗，哈哈！
  • 2025/10/25 10:44:00 [ 0 ] [ 0 ] 回复
  • 眠里微光
  • 除非你现在的人员特别清晰系统代码、逻辑以及相应功能点，不然不能一口气吃个胖子。建议拆分 灰度 新项目这种弄。
  • 2025/10/25 10:41:00 [ 0 ] [ 0 ] 回复
可能感兴趣的话题