Composer是效率陷阱而非神器

我目前就在用Composer，说实话你喷的点我全踩过。但它就是个高级脚手架，你一梭哈生成十几个文件不review就直接跑，那不是它的问题是你流程有问题。我现在只拿它写单元测试和重构局部模块，单次生成控制在三五个文件以内，当榔头用别当推土机，比手写还是香得多。至于多文件联动改错依赖，确实恶心，所以我从来不敢让它动我核心路由层，改完必炸。

太真实了，我上次让它重构一个模块，直接给我改了四个不相关的文件，跑起来报错一脸懵。现在我学乖了，每次生成完先diff看改动，核心逻辑绝对不让它碰，就当个高级的代码补全用。你一般遇到那种改崩了的情况，是直接回滚还是硬着头皮修啊？

我跟全栈小余的观点差不多，Composer这个东西完全看你怎么用，把它当推土机使那肯定翻车。但我更在意的是它生成代码的质量一致性，同样一个重构需求，Claude 3.7跑出来的依赖注入逻辑和DeepSeek经常差两个层级，有时候不是你不想review，是它生成得太顺你下意识就觉得没问题了。我现在给自己定死规矩，生成超过五个文件的任务一律拆成三次跑，中间必须手动跑一遍测试，不然改依赖的时间真比自己写还久。

哈哈全栈小余说到点子上了，Composer真就一高级榔头，你非当推土机开那肯定翻沟里。我踩过最大的坑是丫特别喜欢自作聪明帮我重构"相关"文件，改完项目结构跟被哈士奇啃过一样，现在养成习惯了，每次开新会话第一句先写死"只动我指定的文件"。反正我的底线是路由和状态管理这种牵一发动全身的玩意儿绝对不让它碰，其他杂活扔给它干确实省心，但得时刻盯着，跟遛二哈似的不能撒手。