AI不包治百病 别急裁程序员

上一期视频我聊了AI能不能撼动50万行那种“屎山”代码，结果留言区分歧特别大，反对的人也不少。既然大家都算有真本事，那咱就别玩空话，我把我自己的做法讲清楚，至于适不适合你，就看你结合自身经验来判断。这个系统的领域边界起初其实还算清楚，但后来因为一些因素变得更乱，再加上两次半途而废的重构，边界就越发模糊。不是说完全没能力把事做好，而是外部压力太多，尤其项目合同里，对技术严谨性的要求基本不太值钱。要不是有AI这“春药”，这个版本大概率只能拖到老死。真正让我动念头的，也多半是被AI圈里那些人夸大其词的说法带偏了，不过吃点苦头未必是坏事。Martin Fowler的绞杀者模式就是我重构时最核心的理论支撑，再结合AI能把项目成功率往上推。至于具体方法，完全可以灵活一点，不必死守教条。 在搞清楚大模型记忆短板，以及各种“记忆外挂”看起来很美但徒劳的故事之后，我决定：用claude code去做相对贵但更适合的规划设计，用cursor走更便宜的执行路线。把工作目录尽量放到一起，子目录做隔离，但提示词目录保持共享，这样两个agent之间就不需要频繁手工搬运提示词和产出。第一步，我先让cursor把所有存档的工单、bug做一轮梳理，尽量把“最主要的问题”先抓出来。接着用graphify从旧代码里抽取知识图谱，不过这里提取的主要是静态函数调用关系，并没有运行时链路，也缺少模式匹配路径；所以后面做功能对比和防腐层补强时，还得再补更多信息。第二步，再把重构思路用claude code讲细，特别是模块层面的领域边界，以及未来产品要往哪走。内容可以很零散，AI能帮我整理出一个顶层领域图。这一步我先不急着往下落地，把Gstack装好——它虽然不能直接用斜杠方式调用，但可以直接让claude code根据gstack的skill去校验领域图。第三步，让claude code把我们后续协作的方式写成“记忆”，同时把cursor的执行红线写好并放到对应目录里。这里必须提醒自己精炼点，因为每次调用都会塞进上下文，别把上下文空间吃满。第四步，确定新设计后，让claude code给建议，具体从哪个模块开始重构。一般策略是优先从边缘或外围边界较清晰的模块下手，再逐步“绞杀”向内推进。选定重构模块后，先由claude code写spec，并继续用gstack做review，尽量保证覆盖面。spec定下来之后，让claude code拆任务、生成任务卡；拆的时候要明确提醒它别拆得太细，避免丢关联性，也别拆得太粗，免得上下文直接撑爆。任务拆完还要让大模型再review一遍。到这里整体进展都很顺：cursor在我和claude code的监督下，产出质量确实很高，走TDD路线，测试用例和代码一起生成，单元测试自动跑，实际环境还能自动跑集成测试。真正卡住的是后续：新模块要如何接到旧代码上。 如果旧代码的领域边界足够清晰、接口也比较完备，最多就是写一层单向防腐层，把接口切过去就行；但“屎山”最麻烦的地方就在于：边界不清楚，而且领域交错非常严重。我这里让AI从ORM层反向推导，把所有与该模块数据模型相关的调用都找出来，包括出参入参、文件位置等信息，以便在写防腐层时尽可能覆盖。但最终的底线还是得落在运行时监控上：确保数据不再写进旧表，而是全部写入新表。依赖注入部分也要强制给AI提示词，否则它反推导时很容易漏。准备到位之后，就开始写防腐层。防腐层本质上是旧代码与新代码之间的“翻译器”，必须保证单向，这些规则在前面的红线里已经写清楚。接着要确认新模块的功能是否完整复刻旧代码，并且能匹配新的状态返回。 新模块开发里有个关键步骤是提取旧模块契约，这能最大程度保证功能完整性，但仍然会漏掉一些东西。我又补了一个process mining环节：让AI结合旧设计文档、旧代码与知识图谱，做流程比对。不过我自己总觉得这块仍有明显漏洞，也不知道别人有没有更好的替代方案。客户现场通常会有一些修复只针对特定场景，可能只是对固定条件做判断并触发某些行为——这种东西往往根本不在我们新设计模块的能力范围内，这就是看不见的“屎”。为了解决这个盲区，我让AI结合Git提交记录和工单关键词，把那些针对特定场景的补丁代码显式提取出来，再强行转化为测试用例，注入到新模块的验证流程里；但即便如此，风险依然存在。然后是切流测试。我从工单里整理出一些提交上来的元数据，让AI帮我写replay脚本，目的就是通过数据回放验证新模块能否正确接住旧流量。这个环节AI也能做得不错，但数据是否全面，仍然决定了新模块能不能在客户那边“躺下”。重构还在继续，而且必须继续：随着认知不断增长，新的思路和做法会不断出现，目标始终是把旧代码与新模块之间打通，让它们的“任督二脉”真正连起来。有人问能不能让openclaw或者hermes直接自动干这些事？理论上可以，尤其是hermes，它能直接调用claude code等编程工具。但我自己用过之后发现：它的规划能力还不够强，而且token消耗也很大，所以我现在还是先等等看。