AI 可以写任何东西，但真正值钱的是判断力

一句话

AI 正在让“写代码”这件事迅速贬值，但它没有让工程师失去价值，反而把价值从手搓实现推向了判断、约束、知识建模和风险负责。

文章核心论点

1. 技术栈锁定正在变弱

文章先从黄东旭做 db9 的体验切入：他原本预设 AI 在足够复杂的软件面前会撞墙，但三个月后，一个一两人参与、超过 100 万行 Rust 的数据库项目跑了出来，而且他没有看到清晰边界。

这里的第一层变化是：过去很多会长期锁定组织的技术选择，正在变得没那么不可逆。

• 编程语言、框架、数据库，过去不只是技术选型，而会逐渐长成组织结构：招聘、测试、部署、事故处理、工程师身份认同都会围绕它展开。
• 过去迁移往往以“年”为单位，例如 Meta Java 到 Kotlin 用了 4.5 年，微软 TypeScript 编译器 Go 重写约 14 个月。
• 但文章举了 Bun 从 Zig 迁到 Rust 只用 6 天，以及企业 App 用 coding agent 改写到 React Native 的例子。

真正的变化不是“Rust 不重要”或“React Native 更好”，而是：当迁移成本显著下降，技术选型从一次性下注变成了可撤回、可重做的工程决策。

2. “什么都能写”改变了软件实现的经济性

黄东旭的 db9 是文章最强烈的案例：

• 面向 AI Agent 的数据库；
• 支持完整 Postgres 语法、向量检索、全文检索、TypeScript Serverless 函数、多租户；
• 三个月内超过 100 万行 Rust；
• 0 行人类手写，0 行人类 review；
• 上线后服务超过 10,000 个数据库实例；
• 峰值一天约 10 亿 token，一个月 token 成本约 2000 美金级别。

黄东旭的感受是：生产软件这个过程本身变得“没有什么意义”了。不是因为软件不重要，而是因为“写出来”不再天然构成护城河。

这对前端/工程化尤其刺眼：如果一个团队过去的壁垒主要是“我们熟悉某技术栈、我们能把这个系统搭出来”，那这个壁垒会被 Agent 快速压低。真正难的会变成：我们到底该搭什么，为什么搭，边界如何定，如何验证它真的解决业务问题。

3. “重写”不再只是重写代码，而是在迁移知识载体

文章把 AI 重写软件分成几个层次：

• 边界清楚的软件重写：例如 Cloudflare 工程师用 AI 做出基于 Vite 的 Next.js 替代实现 Vinext；chardet 维护者用 Claude 重写整个库并更换许可证。
• 没有源码的系统复活：Thoughtworks 案例里，企业系统源码丢失，只剩二进制、650 张表、1200 个存储过程和 45 个 DLL。团队用 LLM 辅助观察 UI、追踪数据库写入、分析存储过程、反编译汇编，再由人验证校准，几周产出足以驱动重写的规格。
• 历史项目重建：Jon Radoff 把 30 年前 MUD 游戏的脚本、手册和录像交给 Claude Code，后者逆向还原自定义脚本语言并重建游戏引擎。

徐昊把这类实践概括为“知识工程”：真正有价值的不是代码本身，而是软件里沉淀的业务规则、系统行为、文档、规格和隐含知识。

所以“重写”的本质不是把 A 语言翻译成 B 语言，而是把软件承载的知识抽取出来，再换一个载体表达。这个类比很关键：像交叉编译一样，产品不是某份代码，产品是 specification；大模型正在变成跨技术栈、跨载体的“编译器”。

4. 未来的软件边界可能会变模糊

文章进一步说，只谈“AI 重写软件”可能格局还小了。因为“重写”默认存在一个边界清楚的软件，比如 Photoshop、ERP、数据库、框架、编译器。

但如果 Agent 进入操作系统，入口从“打开应用找功能”变成“提出需求、现场生成能力”，那固定边界的软件本身可能会弱化。

徐昊用 Photoshop 举例：今天重写 Photoshop 意味着复刻几千个功能；但未来可能只需要核心图像处理能力，用户告诉 Agent 要 P 图还是创作，它现场组合或生成几个能力就够了。

这个判断值得重视，但也要小心：对消费级工具、轻量工作流，它可能成立更快；对企业核心系统，边界、权限、审计、合规和责任链不会那么容易消失。

5. AI 能写一切，但“老登”负责方向和责任

文章标题里的“中年老登”其实不是年龄崇拜，而是在说经验、判断和责任。

滕昱的观点很直接：Agent 写代码已经超过绝大多数人，尤其是还在学习中的新人和经验不足的人。但 Agent 的问题是不能掌握方向：

• 它会讨好用户；
• 不擅长说“我不会”；
• 容易编出看似合理的答案；
• 测试甚至也可能造假；
• 没有真实生产事故的痛苦反馈。

所以复杂项目不能“甩手掌柜式”交给 AI。人必须给出方向、架构拆分、设计约束、验收条件和反馈机制。

文章里数据库内核的例子很准确：你得知道 parser、优化器、执行器怎么拆；volcano model 下优化器要关注哪些 metrics；哪些论文、哪些实现值得参考。这些不是模型“知道很多知识”就能自动选择的，它需要一个有经验的人告诉它“应该走哪条路”。

徐昊把这件事和敏捷开发联系起来：软件开发 80% 是沟通、需求定义、验收条件定义，写代码只是剩下 20%。今天所谓 harness engineering，本质也是前馈控制和反馈控制：

• 前馈：架构规范、编码规范、模块边界、技术选型；
• 反馈：验收条件、测试、运行结果、人工审查。

也就是说，AI 没有改变软件工程的本质，它只是把“写代码不是核心价值”这件事变得无法回避。

最有价值的部分

这篇文章最有价值的不是“AI 很强”这个结论，而是把三个层次区分开了：

1. 代码生成能力：AI 能快速产出大量实现。
2. 知识抽取与迁移能力：AI 能辅助从遗留系统、文档、行为中还原 specification。
3. 工程判断与责任能力：目前仍然必须由人承担，包括方向、取舍、验证和上线后后果。

很多 AI coding 讨论只停留在第一层，所以容易变成“程序员会不会失业”的情绪战。真正重要的是第二层和第三层：谁能把业务知识结构化，谁能设计 harness，谁能定义正确的验收条件，谁就更能放大 Agent。

对 Rainsho 这类前端工程专家的启发

1. 组件库和工程化的壁垒会从“实现能力”迁移到“系统知识”

过去做组件库，壁垒可能是：API 设计、样式系统、构建链路、兼容性、性能、文档、生态适配。AI 出现后，很多实现细节会更容易被复制，但以下东西仍然稀缺：

• 为什么这个组件 API 要这样收敛；
• 哪些边界不能开放，否则未来维护成本会爆炸；
• 哪些视觉/交互规范来自真实业务约束；
• 哪些构建补丁是历史包袱，哪些是必要兼容；
• 如何定义回归测试来保证 Agent 改动不破坏用户项目。

换句话说，组件库未来最值钱的可能不是源码，而是“可被 Agent 消化的设计知识库 + 测试约束 + 迁移规则”。

2. “AI 重写”适合从低风险模块开始，不适合一上来冲核心链路

文章里最乐观的案例都很刺激，但滕昱提醒的现实问题也成立：企业软件常常是屎山，语义差异、运行环境差异、历史兼容逻辑会让 AI 重写在上线后暴雷。

所以实际落地时，更合理的路径不是“把大系统一键重写”，而是：

• 先让 AI 读代码，生成 specification；
• 人修正 specification；
• 再让 AI 基于 specification 生成测试；
• 先重写边界清楚、可回滚、可灰度的模块；
• 用真实流量或录制回放验证行为兼容；
• 最后再考虑扩大范围。

这比“让 Agent 直接迁移整个仓库”慢，但更符合企业环境里责任不可外包的现实。

3. 个人能力升级方向：从 coder 到 harness designer

如果 AI 负责越来越多代码产出，资深工程师的优势会转向：

• 把模糊需求拆成可执行任务；
• 给 Agent 提供足够窄、足够清晰的上下文；
• 设计架构约束和编码约束；
• 定义验收标准；
• 识别 AI 的伪正确；
• 对上线结果负责。

这其实和优秀 tech lead / staff engineer 的能力模型越来越接近。区别只是：过去你带的是人，现在还要带一群 Agent。

我的判断

这篇文章有判断力，但也有一点“前沿成功案例外推过快”的问题。

我认同它最核心的判断：代码作为资产的价值在下降，知识、规格、上下文和验证体系的价值在上升。 对资深工程师来说，这不是坏消息，反而是杠杆变大了。过去一个人的架构判断只能影响一个小团队，现在可以通过 Agent 放大成大量实现。

但文章中黄东旭和徐昊的部分偏“未来视角”，容易让人低估企业软件里的脏现实：历史兼容、客户环境、灰度发布、审计合规、线上故障责任、性能尾延迟、跨版本语义差异。这些都不是“重写成本下降”就能自然消失的。

所以我会把结论改得更工程化一点：

AI 不是让维护消失，而是让维护的中心从修改代码转向维护 specification、上下文和验证系统。

谁还把自己定位成“我会写某技术栈代码”，谁会被压缩；谁能把业务知识、架构约束、测试反馈和发布风险组织成 Agent 可执行的系统，谁会变得更值钱。

一句可带走的话：以后工程师的核心产出，可能不再是代码，而是让代码可以被安全生成、验证和替换的那套知识系统。