在 AI 编程工具快速普及的今天，写代码这件事在整个软件开发中的权重，正在发生不可逆的迁移。真正困难的部分，从来不是敲键盘。 AI 可以生成代码，但它不会主动告诉你一个接口必须幂等，不会判断一个功能是否值得存在，更不会在定义错误时举手说“等等，这个契约有问题”。这些问题的答案，构成了“定义”的全部内容。但“定义”不是一个笼统的概念，它至少包含三个完全不同的层次。
第一层是形式层定义：类型系统、接口契约、Schema 与验证规则。这些东西是机器可执行的，是 AI 能直接理解和遵守的边界。第二层是意图层定义：这个功能该不该做，解决什么问题，为什么这样设计。AI 可以帮你实现一个功能，但它不会判断这个功能是否值得存在。第三层是责任层定义：谁为最终结果兜底，出了 P0 事故谁来签字。AI 不坐牢、不背锅、不为商业损失负责。只要责任还在人身上，人就永远有不可替代的价值。
这三个层次需要完全不同的能力。一个能设计精妙类型系统的人，未必能判断一个功能该不该做；一个能划定系统边界的人，未必愿意为商业后果签字。但在 AI 时代，程序员的价值越来越取决于他在这三个层次上的综合能力，而不是打字的速度。
形式化约束是基础，但不是全部
形式化定义在 AI 协作中至关重要。当约束足够精确时，AI 就能在正确轨道上工作。 但形式化本身有明显的局限。
首先，很多业务逻辑的复杂性，恰恰在于它无法被完全形式化。 Schema 能约束数据结构，但约束不了“这个促销活动只对 VIP 用户在特定时间段生效”这类隐性规则。这类规则散落在产品文档、口头沟通、历史代码的注释里，形式化工具抓不到它们。
其次，形式化约束本身也会腐化。 你精心设计的接口契约，三个月后需求变了，契约本身成了新的技术债。谁来定义约束本身该怎么演进？这又回到了意图层和责任层。
最后，过度依赖形式化可能制造“安全幻觉”。 类型检查通过了、schema 验证通过了，程序员就放松了。但真正的 Bug 往往藏在类型系统表达不了的语义里——比如并发顺序、缓存一致性、跨服务的数据漂移。形式化约束能兜住一部分底，但兜不住全部。
所以核心观点不是“程序员应该转行去写 schema”，而是：形式化约束是 AI 时代的基础设施，但真正让约束有意义的，是约束背后的判断和责任。
执行层坍缩，定义层上升——但只适用于应用层
必须划定一个边界：这里讨论的是应用层/业务层的软件开发。如果你在写操作系统内核、编译器、高频交易引擎、密码学实现，那“写代码”的执行本身依然是极高难度的，AI 目前远不能替代。我绝不是说所有代码都变成了“定义”。
但在绝大多数业务软件开发中，执行层的成本确实在不可逆地坍缩。CRUD、UI 拼接、常规 API 调用——这些曾经占据程序员大量时间的工作，正在被 AI 高效接管。单纯比拼“写得快、写得多”的竞争力在迅速贬值，而“定义得准不准、边界清不清晰、责任明不明确”的价值在上升。
这不是预测，是正在发生的现实。一些团队已经开始改变招聘标准：不再考算法题，而是给候选人一个模糊的需求，让他定义接口、划分模块、说明边界和验收标准。这才是 AI 时代真正稀缺的能力。
程序员的下一站
面对这种迁移，务实的策略是：把精力从“写代码”转向“定义代码应该是什么”。 具体来说：
- 掌握形式化约束工具，比如类型系统、JSON Schema、验证库、接口定义语言；
- 培养契约设计能力，在系统边界处设计清晰的接口，让 AI 和其他模块都能在明确的契约下工作；
- 锻炼意图判断力，学会问“这个功能到底解决什么问题”而不是“这个功能怎么写”；
- 建立责任意识，无论 AI 写了多少行代码，最终为质量兜底的是你，不是它。
最后
AI 不会取代程序员，但会重新定义程序员的工作内容。执行层的价值在坍缩，定义层的价值在上升。谁能把意图和边界形式化得越清晰，谁就能让 AI 在正确的范围内高效工作。
但请记住：形式化约束只是工具，不是答案。真正的答案，在于你能否成为那个定义“对”的人，并在定义错的时候，有勇气承认并修正。
未来的业务代码，更多是被定义出来的，而不是被写出来的。而定义，从来不只是写 schema 那么简单。
