这段时间我在做一个项目。
功能已经基本跑通了。代码是 AI 写的，我也都测过，结果是对的。
但我慢慢开始有一种很奇怪的感觉。
这个系统，好像不是我做的。
我知道它能干什么，也参与了技术方案的选择。但如果让我去改一个地方，或者解释某一段逻辑为什么这么写，我其实说不太清。
表结构是和 AI 一起讨论出来的，实现也是一边对话一边生成的。评审的时候，我更多是在看"有没有明显问题"，而不是在判断"这个结构是不是对的"。
它是对的，但我并不理解它。
我后来意识到，这不是我一个人的问题，而是一种很典型的状态：
vibecoding 做出来的系统，功能属于你，但理解不一定属于你。
这件事让我开始重新想一个问题：
在 AI 编程时代，人工介入的边界，到底应该在哪里？
系统开始失去"被理解的人"
这两年 AI 编程工具越来越强。
以前，一个功能从想法到上线，要经历一整套过程：理解需求、设计结构、写实现、补测试、改 bug、做 review。
现在这条链路被极度压缩了。只要描述得足够清楚，AI 很快就能给出一版能跑的代码。
问题也正是在这里开始变得有点奇怪。
代码越来越多，系统越来越复杂，但真正理解它的人，反而越来越少了。
大家知道它能跑，也知道大致做什么。但再往深问一点：
- 这段逻辑为什么这么写？
- 这个复杂度来自业务，还是实现方式？
- 如果要改，应该从哪里下手？
就开始变得模糊。
我更愿意把这种状态叫做一种新的债：
认知债。
代码在，功能在，但理解不在。
边界不在"谁写代码"，而在"谁负责未来"
很多人讨论 AI 编程，习惯问一个问题：
哪些代码让 AI 写，哪些代码必须人写？
这个问题有意义，但不够本质。
我后来慢慢有一个更清晰的判断：
AI 编程的边界，不在"谁写代码"。 而在"谁对未来负责"。
代码是谁写的，并不能决定它以后是不是好维护。
真正影响长期质量的，是：
- 系统边界怎么划
- 约束落在哪里
- 复杂度被放在什么地方
- 未来改动有没有清晰落点
换句话说：
AI 可以拥有生成权，但不能天然拥有理解权和责任权。
粗暴一点，其实可以分三种代码
如果一定要拆，可以很粗暴地分三种。
第一种，是那种你看一眼就知道对不对的代码。
比如 CRUD、DTO、测试样板、简单封装。
这种地方，让 AI 多写一点，我觉得完全没问题。 它解决的是重复劳动，而不是认知问题。
第二种，是有点复杂，但还能说清边界的。
比如状态流转、缓存策略、跨模块调用、异常处理。
这里 AI 可以参与，但前提是：
边界必须是人先定的。
AI 更像实现工程师，而不是设计者。
第三种，是那种一旦做错，后面会持续还债的地方。
领域模型、架构边界、事务一致性、安全策略、对外契约、性能热点......
这些地方，其实不是在"写代码"，而是在"定义未来"。
这种地方，我不太相信纯 vibecoding。
不是因为 AI 一定写不好，而是因为这里的"对"，从来不只是功能对。
很多时候，你不是在 review AI
还有一个很有意思的现象。
很多团队会说，那就让 AI 先写一版，人再 review。
听起来合理，但实际很容易失效。
因为代码一旦先出现，就会天然形成一个锚点。
你会下意识顺着它改，而不是重新判断这个结构是不是合理。
所以很多时候：
你以为你在 review AI， 其实是 AI 在预先决定你的结构。
它不只是写实现，还在无形中决定：
- 类怎么划分
- 接口怎么组织
- 数据怎么流动
一旦第一版落地，这些决策就很难被真正推翻。
所以更合理的顺序应该是：
人先定结构，AI 再填实现。
代码，已经不再等于理解
以前有句话：
Talk is cheap, show me the code
它诞生的前提是：代码很贵。
一个人能写出代码，本身就意味着他已经完成了大量思考。
但今天这个前提变了。
代码已经不再稀缺。
AI 可以很快生成大量"看起来像好代码"的内容。
于是"给我看代码"，有时候只能说明一件事：
产物存在了，但理解不一定存在。
所以复杂系统里，理解不能只放在代码里。
它需要被外显。
可以是：
- 模块职责说明
- 状态机图
- 决策表
- 不变量清单
- 关键测试样例
- 日志与故障入口设计
重点不在形式，而在于：
系统的知识，不能只埋在源码里。
真正该追求的，不是人人看懂所有代码
很多人谈可维护性时，会有一个默认目标：
让任何人都能轻松读懂全部源码。
这不现实，也没有必要。
我更认同的目标是：
任何一个新接手的人，都能在有限时间内建立起对系统的基本理解------ 知道它的目标是什么、边界在哪里、关键约束有哪些、主流程如何运转； 并在这层理解之上，完成问题定位、局部修改与结果验证。
这里最重要的，是"理解"。
没有这一步，后面的修改和验证都只是碰运气。
AI 会变强，但这个问题不会消失
我不认为这些问题是因为"AI 不够强"。
未来 AI 很可能会：
- 更好地理解代码库
- 更稳定地做修改
- 甚至承担大量维护工作
但这并不意味着问题会消失。
相反，这些能力越强，对系统的要求反而越高：
- 边界要更清晰
- 约束要更显式
- 决策要更可解释
- 验证要更可靠
这些既是给人看的，也是给未来 AI 用的。
所以更可能的情况是：
AI 会解决执行问题，但不会消灭治理问题。
那初级程序员怎么办？
一个很现实的问题是：
很多人并不具备定义边界和设计系统的能力。
这很正常。
设计本来就不是确定性的，它是各种 trade-off 的平衡。
所以真正的目标，不是让每个人一开始就能设计好系统。
而是让设计变成一个可以被讨论、比较、复盘的过程。
一个更合理的成长路径是：
- 先学会在边界内实现
- 再练习模块级设计
- 最后再做系统级设计
AI 在这里，更像一个"设计陪练"。
它可以帮你展开方案空间，但不应该替你做最终决策。
回到我那个项目
说回一开始那个系统。
现在对我来说，最重要的事情已经不是继续让 AI 写更多代码。
而是把这个系统真正"接管"回来。
我准备做几件很具体的事情。
先用一页纸，把系统在干什么讲清楚：输入是什么，中间经过哪些关键步骤，输出是什么。
再把主流程梳理出来，明确每一步在哪里实现，哪些地方是核心。
然后重新推一遍表结构，不看代码，只问一件事：
这些表到底在表达什么业务概念？
最后，选一个点，手动改一次。哪怕很小，也要从头走一遍。
这些事情听起来不复杂，但它们做的，其实是一件更本质的事：
把一个"能跑的系统"，变成一个"我能解释、能修改、能接管的系统"。
最后
以前，软件开发最稀缺的能力，是把想法变成代码。
现在，可能变成了另一件事：
让系统长期保持在"可理解、可修改、可接管"的状态。
AI 可以帮你写出系统。
但如果没有理解，这个系统始终不会真正属于你。