AI 代码盛行程序员的核心能力变成了什么？

最近一个月，我做了一件从未做过的事：构建微调大模型的数据集。我从未学过 Python，却使用 AI 完成了所有代码，验证了我的构想。

工作流是这样的：

• 我负责架构：技术调研，拆解流程，明确每个环节的输入输出。
• AI 负责实现：我给足上下文，AI 填充具体代码。
• 我负责审查：AI 的知识有滞后性，我需要查阅文档，纠正它，组装它。

为了让 AI 高效工作，我必须提供充足的上下文，包括运行环境、完整流程、现状和目标。AI 的上下文窗口有限，而我的流程很长。我的办法是，每个聊天窗口只专注一个环节。开启新窗口时，更新提示语，重点说明“当前状况”。整个流程跑完后，回顾所有提示词，以此总结复盘整个流程的经验。

AI 的知识有滞后性和不完整性。因此，在利用 AI 时，必须提供完整准确的信息，否则它写的代码很可能出错。这正是微调大模型的意义所在，但在日常使用中，我们微调模型的门槛很高。这也凸显了人类的一个关键价值——审查输出，提供信息。

总的来看，AI 的确把“把想法变成代码”的效率推到了一个新高度，它非常擅长帮人快速入门，辅助人类从 0 到 1 新建一个程序。完成了 1 我们不能停留在 1，而是走向下一步，就像初级工程师要变成高级工程师，如果有机会还要想办法成为架构师。

再来看 AI 生成的代码，其实是零散的，AI 关注的是局部最优解，即：如何最快地满足你当前的这个 Prompt，它生成的就像一张一张孤立的牌，打牌时，要赢得牌局，必须有序的组织这些牌。回到前端开发，软件不能光有组件，还需要组织组件，这就涉及软件架构。

在我的朋友圈里，有人创业，也有人找工作，还有人正在职场中使用 AI 提高工作效率。有这样一部分人，他们每天都在写代码，比不用 AI 时写得更快，更好，但其实他们不会写代码了。当面试时，被问到一些基础问题，他答不上来；被问到怎么规划系统时，他也答不上来。这一现象在当前的技术圈非常普遍，我将它称之为“技能空心化”。

编程本质上是将人类的意图翻译成机器的指令，不依赖 AI 时，程序员掌握的是“命令式”细节。由于必须自己写每一行代码，他们被迫理解数据结构如何流转、变量生命周期如何管理，这种微观的掌控感，是宏观架构设计的基础。

“技能空心化”的人，停留在“声明式”层面，他们只负责告诉 AI “我要一个登录框”，而不关心它是用 Form 表单还是 Ajax 实现，也不关心鉴权 Token 存在哪里，这种工作方式导致程序员的知识库是由无数个零散的代码片段组成的，而不是一张连贯的知识图谱。结果他们变成了“产品经理式的程序员”，只懂要求，不懂实现。面试问实现细节，他答不上来，问实现细节的组合与取舍更无从谈起。说他们懂需求，又无法和产品经理竞争，因此处于一个尴尬的境地，看似既懂需求又懂技术实现，其实即不懂需求也不懂技术实现。

技能空心化这一现象的本质是，把 AI 当成了“替代者”，而不是“加速器”。这类人让 AI 替他思考，替他写代码，他只负责按回车，他将自己变成一个机械劳动者，这就导致，他的编程能力被迅速蒸发了。

与“让 AI 替他思考”的另一个极端是完全不用 AI，给的理由是，想完全掌握某个知识。那类坚持“不用 AI”的人，其实是混淆了记忆与理解，在 AI 时代，我们需要重新定义“掌握知识”的标准。

我们要避免将“掌握知识”等同于“肌肉记忆”，这一行代码怎么敲？API 的参数顺序是什么？如果不查文档能不能默写出来？在获取信息难度大的时代，这种能力很贵；但在 AI 时代，这种能力的边际成本趋近于零。

我理解的“掌握知识”是逻辑与结构层面的。比如：这个功能由哪几步组成？数据流怎么变？模块间怎么解耦？如果一个人能精准地把大问题拆解成小流程，并定义好输入输出，即使他一行代码不写，他对这个系统的掌控力也远高于一个只懂默写语法但不懂拆解的人。

“掌握知识”的另一个标准是验收结果。我在利用 AI 写 python 时，整个工作流中必不可少的环节是，审查输出，提供信息。如果一个人完全不懂，他无法判断 AI 生成的代码是好是坏，是否有安全漏洞；而如果一个人“掌握”了知识，他能一眼看出 AI 的代码哪里逻辑冗余，哪里没有处理边界。尽管我没有学过 python，但我懂拆流程，清楚每一个环节要产出的结果。

总结一下，我这样使用 AI：先思考架构，定义流程，让 AI 填充细节，然后审查和组装。带来的结果是效率提升，核心竞争力聚焦于顶层设计。

更进一步的“掌握知识”是知其然，更要知其所以然，也就是说你要知道为什么这么决策，这是最高级的掌握。比如，为什么选 A 方案而不选 B 方案？当你在做这些权衡时，你就在掌握技术。

当下，真正的“掌握知识”，不再是“我能把它写出来”，而是“我知道它怎么被构建出来，以及为什么要这样构建”。

AI 可以帮你写出组件，但无法教你如何“组织组件”，AI 可以给你局部最优解，但无法给你“系统级思维”。

核心案例拆解

• 案例一：低代码引擎架构设计（从 0 到 1）
• 案例二：2D/3D 云设计平台架构升级（从 N 到 N+1）

核心洞见与方法论

• 架构五步法：一套从需求分析到技术选型的标准化流程，告别“拍脑袋”做架构。
• 非功能性驱动：识别那些真正决定架构生死的“隐形需求”（如可扩展性、兼容性）。
• 分层插件化：纵向隔离技术关注点（UI/数据），横向切分业务领域（插件自治），完美平衡复杂度。
• 通信与治理：掌握强类型事件总线、IOC 服务注入与命令系统，解决大型系统中的协作混乱。

你将获得的具体能力

1. 拒绝“技能空心化”：不再只会写业务组件，而是掌握系统级的设计与规划能力。
2. 掌握工业级规范：学习 Monorepo 代码组织、TypeScript 强契约设计。
3. 提升职场竞争力：拥有处理遗留系统重构、设计高可用架构的稀缺经验。

案例一：低代码引擎（从0到1）

本案例完整演示了如何运用架构设计五步法，从零开始构建一个面向后端开发者的中后台低代码引擎。

需求分析：从模糊到精确

架构设计的起点是对业务需求的深刻解读。专栏强调，架构师的核心任务之一是将产品经理提供的、模糊的用户故事，翻译为精确、可执行、无二义性的技术语言。通过5个高优先级需求的案例，展示了如何通过追问和拆解，将模糊概念细化为具体功能点。

基座与插件的职责划分

在分层插件化架构中，基座（Base）与插件（Plugin）的职责边界是关键决策点。基座的职责应等于它要服务的所有场景的“最大公约数”。对于低代码这一特定领域，其最大公约数是“可视化页面搭建”所必须具备的抽象能力。

• 基座职责：提供抽象能力和运行机制。包括定义协议（物料协议、页面协议）、提供抽象接口（界面、物料、设置器扩展等）和核心模块（文档、渲染、交互、数据源等）。
• 插件职责：提供具体实现和贡献内容。通过实现基座的抽象接口，将视图、物料和设置器等具体功能注入到系统中。

系统分层与数据流

基于职责划分，系统被设计为四个逻辑层次，依赖关系单向且清晰：

1. 插件层：实现具体功能，依赖抽象层。

2. 抽象层：基座暴露给插件的稳定API，依赖核心层。

3. 核心层：平台必须提供但用户不直接关心的核心能力与机制，依赖协议层。

4. 协议层：定义物料和页面的数据结构，是整个架构的基石，不依赖任何层。

通过“拖拽组件”和“修改属性”两个用户故事，专栏详细展示了数据和事件如何在这些层次间动态流转，体现了数据驱动视图和职责分离的设计精髓。

技术选型决策

技术选型需匹配架构目标和项目约束。

• 代码组织：采用 Monorepo 物理隔离不同层级的代码包，强制执行架构分层。
• 开发语言：TypeScript 是必选项，其类型定义本身就是最好的架构文档和契约。
• 视图框架：React 的声明式特性与“数据驱动视图”的逻辑高度契合。
• 状态管理：选用 MobX，因为它允许以面向对象的方式直观地操作深层嵌套的文档树，避免了不可变数据流带来的繁琐更新逻辑。低代码平台开发实践：基于React7天无理由运费险已售9¥57.9购买机械工业出版社

案例二：2D/3D云设计平台（从N到N+1）

本案例聚焦于架构升级，其核心挑战是在确保业务连续性的前提下，对一个高度耦合的现有系统进行解耦。

核心挑战：透明解耦

架构升级的目标是将平台的设计工具内核与家装业务域的代码彻底分离。此过程面临三个严苛的外部约束：

1. 对业务方透明：现有业务插件无需修改任何代码。这意味着对外暴露的API签名和NPM包名都不能改变。

2. 性能无衰减：升级后的加载速度与交互性能不得低于现有水平。

3. 数据兼容性：必须完全兼容所有历史设计方案的数据格式和语义。

四层能力模型

为了构建一个业务中立的新内核，专栏提出了一个四层能力模型来组织其内部功能：

• 数据与状态层：管理场景中的所有信息和状态，如数据生命周期、历史记录。
• 渲染引擎层：负责将数据绘制到屏幕，如场景渲染、相机系统。
• 交互抽象层：将用户输入翻译为操作指令，如实体选择、模式管理。
• 通用服务与扩展层：提供跨领域的基础能力和插件机制，如碰撞检测、单位系统。

工程实践：防腐层与运行时切换

• 防腐层：在业务插件与新内核之间引入的关键层级。它负责拦截旧的业务指令，将其翻译成新内核能理解的通用指令，同时承载那些从旧内核中剥离出来的、与特定领域相关的逻辑，从而保护了新内核的纯粹性。
• 运行时切换：为了实现快速、安全的线上回滚（“止血”），最终方案放弃了在前端代码内实现A/B切换的复杂逻辑，转而在基础设施层采用 Nginx 流量切换。通过部署两套静态资源，可在分钟级别将流量从新版切回旧版，将风险降至最低。

插件系统的深度设计

专栏对一个健壮的插件系统进行了深度解构，认为其必须包含四大支柱：

1. 准入门槛：使用 Class 作为唯一标识，解决了命名冲突并实现了强类型依赖。

2. 行为红线：通过上下文注入而非直接暴露内核实例，严格限制插件的访问边界。

3. 生命周期管理：核心是管理插件整体，包括依赖解析、状态机管理、上下文注入和错误处理，确保系统的一致性和健壮性。

分类的通信机制

◦ 强类型事件总线（1对多广播）：使用Symbol作为事件标识，避免命名冲突，实现静态可分析的事件流。

◦ 服务依赖注入（1对1请求）：插件面向接口（IXXXService）而非具体实现编程，实现能力提供者与消费者解耦。

◦ 命令系统：UI 组件只负责发射命令ID（如cmd.undo），由逻辑插件认领并执行，实现意图与实现的分离。

联邦式数据治理

为管理多插件并存的异构数据，专栏提出了“联邦式数据治理”原则：

• 插件：拥有数据的主权，负责定义数据结构和具体的I/O逻辑。
• 内核：拥有生命周期的治权，负责统筹加载、保存、撤销重做等事务。

这一原则通过一个名为 DocumentSource 的 TS 接口来实现。任何插件只要实现了该接口，其数据的生命周期就可以被内核统一、自动地管理，从而在保持业务隔离的同时实现了数据层面的协同。