写了10年代码的人,在AI编程时代反而最值钱

张开发
2026/4/4 21:05:08 15 分钟阅读
写了10年代码的人,在AI编程时代反而最值钱
最近 Hacker News 上有篇帖子火了365 票——讲的是怎么配置.claude/文件夹让 Claude Code 更懂你的项目。评论区一片热闹大家在分享自己的 CLAUDE.md 怎么写、规则怎么定、怎么让 AI 更听话。有人贴出了自己精心调教过的配置文件有人在讨论.cursorrules和CLAUDE.md到底哪个优先级更高。但我看完之后的第一反应不是赶紧学而是一阵恍惚这些人在手写配置文件教 AI 认识自己的项目。而我写了10年的 C 模块库AI 连它的存在都不知道。不是我没有积累恰恰相反——我有太多积累了。多到我自己都搞不清楚某个能力到底在哪个模块里。26个模块、10万行代码AI 一个都不认识我有一个 C 项目叫 hbcore维护了快10年。这不是什么玩具项目。它是一个完整的流媒体技术栈——音视频采集、硬件编解码、网络传输、RTSP/RTMP/WebRTC/GB28181 四种协议栈、HLS 分片、MP4 解析、录制回放、屏幕捕获、混流引擎……26个模块覆盖了从设备采集到服务端推流的全链路。上个月我用 repo-scan一个我写的 Claude Code / Codex CLI Skill能对整个代码仓库做逐文件深度审计做了一次全量分析。结果长这样模块源文件数体积技术栈审计判决base54337 KBC/C提纯合并protocol_webrtc44779 KBC/C重塑提取output_rtmp35526 KBC/C重塑提取rtsp_server85262 KBC/C提纯合并mp4_parser62160 KBC/C重塑提取capture_device13300 KBC/C重塑提取base_codec23153 KBC/C提纯合并protocol_gb2818123324 KBC/C重塑提取…共26个模块26个模块10万行代码。光是base一个模块就被其他23个模块依赖——它是整个技术栈的地基。下图是repo-scan 生成的HTML报告但你猜怎么着这个项目没有 CLAUDE.md。没有.cursorrules没有任何让 AI 工具理解项目结构的元数据文件。这意味着什么意味着当我用 Claude Code 或 Cursor 开一个新项目、需要一个 H.264 解析器的时候AI 会非常勤快地从零给我写一个。它不知道我的base模块里有一个经过生产验证的h264_frame_parser不知道record_play模块里还有一份甚至不知道rtsp_server里还有第三份独立实现。同一个能力在我自己的代码库里就有三份重复实现。AI 要来了大概率会写第四份。连我自己都在重复造轮子AI 只会更严重这不是夸张。repo-scan 的交叉审阅报告里有一张能力重叠地图看完以后我自己都吓了一跳能力域重复模块建议H.264 NAL 解析base / record_play / rtsp_server3份独立实现统一到 baseFAAC 音频编码base_codec / base_encoder / record_play3份统一到 base_codecx264 视频编码base_codec / base_encoder2份统一到 base_codecYUV 色彩转换base_codec / base_encoder2份统一到 base_codec位流读写base3套/ mp4_parser统一到 base/bit_stream.h缓冲区管理base2套命名空间 base:: vs hbase::合并为一套Base64 编解码rtsp_server2套实现统一为1套七个能力域全都有重复。其中 H.264 解析和 FAAC 编码各有三份独立实现位流读写甚至有四份。实际报告里的数字更夸张——base 基础库在整个代码库里被复制粘贴了30 份这就是10年代码的真相写的时候每次都觉得快速搞定最重要结果同一个东西在不同模块里被独立实现了好几遍。我自己都记不清哪些能力已经有了何况 AI坦白说这个问题在没有 AI 的年代还能忍——大不了多几份重复代码能跑就行。但到了 AI 编程时代问题被放大了你让 Claude Code 帮忙写一个新的流媒体服务它会老老实实从零实现 H.264 解析、FAAC 编码、YUV 转换——把你已经写好并验证过的东西再写一遍。不是因为 AI 笨是因为它根本不知道你有这些东西。新项目的目录是空的AI 的上下文窗口里看不到你其他项目里的积累。1.9万行 AI 代码进了 Node.js 核心——谁来保证质量这不只是我一个人的问题。整个行业都在面对AI 从零写带来的后果。最近两条新闻放在一起看特别有意思第一条1.9万行 Claude 写的代码直接进入了 Node.js 核心库社区炸锅。有人呼吁封杀 AI 代码有人说只要通过测试就行争论到现在没有定论。第二条有人统计了 Claude Code 的输出去向——90% 流向了 GitHub 上不到 2 颗星的仓库。两条新闻加在一起画面就很清楚了AI 在疯狂生产代码但这些代码大部分没人用、没人维护、质量存疑。开源维护者们已经开始集体掀桌。InfoQ 的报道说低质量的 AI 生成 PR 正在淹没开源项目维护者的审核负担暴增有些项目干脆在 Contributing 指南里加了一句禁止 AI 生成的 PR。与此同时Cursor 在用实时强化学习改进 Composer 的代码生成质量Claude Code 在优化上下文理解能力所有 AI 编码工具都在卷怎么让 AI 写出更好的代码。作为程序员我觉得除了期待AI写出更好的代码之外我们还需要认识到一点当前的AI并不认识你已经有的东西。它不是写得不好是根本不知道你有现成的、经过验证的方案。所以每次都从零来。成熟模块才是 AI 时代最值钱的资产AI 编程时代真正值钱的不是会用 AI 写代码——这个门槛正在快速归零。谁都会用 Claude Code 了谁都能让 Cursor 帮忙补代码了。真正值钱的是你那些经过了生产环境验证、踩过坑、修过 bug、在真实项目里跑了好几年的成熟模块。拿我的base模块来说被23个其他模块依赖。它的线程模型、缓冲池、H.264 解析器在生产环境里跑了多少年我自己都记不清了。早年做直播平台的时候反复锤炼过各种边界条件都覆盖了。再比如base_codec封装了 FFmpeg/x264/FDK-AAC 的编解码能力对外提供统一接口隐藏了底层三套库的实现差异和版本兼容问题。这套东西 AI 从零写出来当然可以——但它不知道我在 FFmpeg 从 4.x 升到 7.x 的过程中踩了哪些 API 变更的坑不知道某个旧版解码器在 Android 10 上有个诡异的崩溃要绕。这就是10年代码的真正价值不是代码本身有多精妙而是代码背后沉淀的工程决策。举个例子base_codec里有个参数crf_val25声明类型是bool——但实际当int传。历史遗留的类型 bug。AI 从零写编码封装当然不会犯这个蠢但它也不会知道在某些场景下我故意绕过了 CRF 配置、直接走恒定码率因为特定硬件解码器对 CRF 模式的兼容性有坑。成熟模块 经过验证的工程决策 已经踩过的坑 生产环境的适配经验。AI 能写出功能等价的代码但写不出这些。而这些东西恰恰是工程中最贵的部分。让 AI 认识你的模块从从零写到从八十分开始那怎么办回到开头那个 HN 热帖——大家在手写 CLAUDE.md告诉 AI我的项目是什么结构。方向是对的但对于有10年积累的人来说手写配置文件描述几百个源文件、几十个模块不现实。我仔细想了一下应该需要有一个工具能做这么几件事扫描已有代码库自动识别每个模块的能力、接口、依赖关系把它们注册到一个模块库里新建项目时用自然语言描述一下需求比如做一个支持 RTSP 的流媒体播放器系统从模块库里自动匹配已有模块补缺——模块库里没有的自动去 GitHub 上搜索合适的开源模块装配——用胶水代码把这些模块组装成初始项目生成工程配置——自动输出 CLAUDE.md、.cursorrules 等 AI 工程文件一键交接——把装配好的项目连同配置文件一起交给 AI Agent继续后续开发整个思路就是AI 不从零开始写而是从我已有的八十分开始只补最后20%的胶水和定制逻辑。经过一段时间的思考和设计在 AI 协助下我目前已经完成了初版。这个工具叫古法熔炉GufaForge——名字的意思是善待你的古法编程资产让它们在 AI 时代重新发光。界面如下。首先把我的古法编程模块导入指定模块目录选择 AI 配置支持 DeepSeek、Claude、Codex 等十几种后端点开始扫描。工具会递归扫描文件先做规则分析文件结构、头文件依赖、编译宏再调 AI 做增强分析功能语义、接口抽象、质量评估。扫描完成后这些模块连同能力描述一起进入模块库。然后在项目工坊里新建项目描述一下需求系统自动从模块库匹配、搜索 GitHub 补缺、胶水装配、生成工程文件五步走完输出的不是一堆 AI 从零写的代码而是一个以你的成熟模块为基座的工程项目——带着 CLAUDE.md带着模块依赖关系带着 AI 能理解的上下文。然后一键交给 Claude Code 或 Cursor让 AI 从八十分开始补剩下的部分。

更多文章