夜雨聆风
AI真的只能做辅助吗?代码生成的边界正在消失
前两天连续写了两篇文章，本质上都在指向同一个变化。
《吴恩达：代码能力的价值重估》在讲价值： 写代码的能力在贬值，判断该写什么的能力在升值。
《一个人能写完系统，但做不出系统：Vibe Coding 时代，瓶颈已经变了》在讲结构： 当代码不再是瓶颈，系统开发的问题，开始变成多视角的决策问题。
但如果继续往下推，会遇到一个更直接的问题——
既然代码可以被生成，那写代码这件事，还算不算“人的工作”？
换句话说：
AI，是在辅助，还是已经开始承担执行？
今天这篇，想把这个问题说清楚。
引言
有人说：AI能生成代码，还是得靠人来审核。
一句话生成一个系统，和200块做淘宝网站没区别。
不能指望AI生成专业的ERP。
AI只能辅助写函数或工具代码，最后还是得靠专业的人把控。
这些判断并不是错的，它们对应的是过去一段时间的真实情况。
但问题在于——
这些判断，正在逐渐失效。
AI的边界，并不是固定的，而是在快速外移。
一句话生成系统，真的等于廉价模板吗？
模板网站的逻辑很简单： 功能固定、结构封闭、修改成本高。
而“一句话生成系统”，本质上不是一个结果，而是一条流程：
需求描述 → 代码生成 → 运行验证 → 发现问题 → 再次生成。
这个过程可以反复进行。
关键不在第一次生成，而在能否持续迭代。
模板做的是交付，AI做的是生成过程。
两者看起来相似，但本质完全不同。
专业系统，AI真的做不到吗？
ERP之所以复杂，是因为规则多、流程长、边界多。
如果让AI一次性生成完整系统，确实很难成功。
但现实中的开发，本来也不是“一次完成”。
更常见的方式是：
先定义规则和流程， 再设计系统结构， 然后分模块逐步实现。
在这个过程中，AI可以承担“实现”这一层。
比如：
在已有架构约束下生成模块代码， 根据接口规范完成集成， 在测试反馈中不断调整实现细节。
这意味着，AI不需要理解全部业务，也可以参与复杂系统的构建。
前提是——
人先把边界定义清楚。
审核，真的只能靠人吗？
过去，代码审查高度依赖人工。
因为需要逐行检查逻辑、性能和潜在风险。
但现在，一部分工作已经可以被AI前置完成。
例如：
AI可以先扫描代码结构，发现明显的漏洞和不合理设计； 也可以基于规则检查命名、耦合度和潜在性能问题。
这并不等于AI替代审核。
更接近的情况是：
AI完成“预审”，人负责“判断”。
人不再逐行阅读代码，而是针对AI给出的结果做决策。
这一步变化的意义在于：
审核的成本，被显著压缩。
AI真的只是辅助吗？
“辅助”的前提是：人主导执行，AI提供帮助。
但在越来越多的实际流程中，这个关系正在变化。
以一个完整流程为例：
代码可以由AI生成， 初步审查可以由AI完成， 测试也可以自动运行。
人在其中的角色，没有消失，但发生了转移：
从“具体执行”，转向“结果判断”。
执行开始由AI承担，判断仍然由人负责。
这不是简单的效率提升，而是职责分布的变化。
复杂系统，是AI的边界吗？
一个常见观点是：AI只能处理简单工程。
但这个判断，往往忽略了一个前提——约束条件。
当系统的规则、边界和接口被清晰定义之后， AI可以在这些约束下完成结构生成和模块拼接。
相反，如果约束本身是模糊的， 生成过程只会不断放大这种混乱。
所以问题不在于系统是否复杂，而在于：
复杂性是否被结构化表达。
在约束清晰的前提下， AI可以参与构建结构复杂的系统。
专业把控，已经变了
“最终还是要靠专业的人。”
这句话没有问题。
但“靠”的方式，已经发生变化。
过去，专业意味着亲自参与实现、审查和测试。
现在，更重要的是：
定义规则， 评估结果， 控制方向。
专业能力，从执行能力，转向判断能力。
把控的位置，上移了。
Demo和生产，还存在边界吗？
很多人认为AI生成的系统只能用于demo。
因为demo可以不稳定，而生产系统必须可靠。
但从流程上看，两者的差异并不在“谁写代码”，而在“是否经过验证”。
如果一段代码经过：
结构审查、 测试验证、 多轮迭代修正，
它具备进入生产的条件。
这个过程，本质上和传统开发并没有区别。
区别只是：
执行这些步骤的主体，从人变成了AI。
结语
“AI能生成代码，但还是要靠人审核。”
这句话没有错。
但它描述的是过去的分工方式。
现在正在发生的变化是：
AI可以承担大部分执行工作， 也可以参与审查过程， 而人负责做最终判断。
如果把前两篇放在一起看，会更清晰：
代码的价值在下降， 系统的瓶颈在从实现转向决策， 执行本身，也在发生转移。
变化不是单点发生，而是整条链路在重构。
人的价值，不在执行，而在判断。
AI执行，人判断。
这，才是新的协作方式。