1. 当AI编程遇上十年老代码:一场认知鸿沟的危机
上周我在重构一个RTSP推流模块时,Claude Code给我生成了全新的H.264解析器——这已经是本周第三次了。看着屏幕上那300行似曾相识的代码,我突然意识到:我的十年技术积累正在被AI无视。这不是工具的问题,而是整个行业都在面临的工程认知断层。
1.1 模块化开发的"暗知识"困境
我的hbcore项目有26个模块,10万+行C++代码。base模块作为地基被23个模块依赖,protocol_webrtc处理WebRTC信令,rtsp_server实现RTSP服务端...每个模块都经过多年线上验证。但问题在于:
- 历史决策不可见:比如base_codec里bool型的crf_val实际当int用,这是当年应对某款硬件解码器的特殊处理
- 能力分布不透明:H.264解析器分散在base、record_play、rtsp_server三个模块
- 版本适配经验沉默:FFmpeg 4.x到7.x的API变更应对策略埋没在提交历史里
这些工程经验构成了项目的"暗知识",而AI只能看到明面的代码结构。就像让一个新人直接接手十年老项目,没有文档传承,必然重复踩坑。
1.2 AI代码的"绿野仙踪"现象
最近Node.js核心库引入1.9万行AI生成代码引发争议,暴露出两个事实:
- AI擅长从零生成功能代码
- 但缺乏对现有技术体系的认知
这种现象我称之为"绿野仙踪"——AI像被龙卷风带到陌生国度的桃乐丝,面对全新环境只能现场造轮子。我的repo-scan工具显示:
| 能力域 | 重复实现数 | 最稳定版本位置 |
|---|---|---|
| H.264解析 | 3 | base/h264_parser.h |
| FAAC编码 | 3 | base_codec/faac_wrapper.cpp |
| YUV转换 | 2 | base_codec/color_space.h |
当AI为我的新项目生成代码时,这些沉淀的经验完全未被利用。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
