先做一个实验。打开任何一个 AI 编程工具，说：「帮我写一个请假审批的小工具，员工提交，老板批准。」几秒钟后你会得到一个界面美观、流程顺畅的应用——提交、列表、批准、拒绝，样样齐全。看起来很完美，对吧？
现在回答这几个问题，答完再回去看你的工具：
- 员工请假三天和请假三十天，走的是同一个审批吗？
- 老板三天没点批准，这件事谁负责——有没有提醒？
- 两个人同时批准同一条请假，会发生什么？
- 请假被批准之后又撤销，已经排好的班表怎么办？
- 老板能看到所有部门的请假，还是只能看到自己部门的？
你的小工具大概率一个都答不上来。不是 AI 笨——恰恰相反，它太忠实了：你只描述了「顺利的路径」，它就只实现了顺利的路径。而真实世界的复杂度，几乎全部住在「不顺利的路径」里。这部分就是必要复杂度：问题自带的、一个都不能少的复杂度。
必要复杂度的五种面孔
上面五个问题不是随口编的。几十年来，软件行业把「需求的必要复杂度」翻来覆去地踩坑，踩出的大坑基本就这五类。你可以把它们当成盘点任何一件事的清单：
一、边界与例外。数量、时长、金额走到极端时会怎样？三天假和三十天假是两种制度，一句「员工请假」把它们糊在了一起。所有「正常情况」的描述，都默认了一个未经检查的取值范围。
二、失败与时序。每一步都可能不发生、晚发生、发生两次。老板不点批准怎么办？网络断了提交一半怎么办？「超时」「重试」「并发」这些词听着技术，其实问的全是业务问题：事情不按剧本走的时候，责任归谁、状态算啥。
三、角色与权限。「谁能看到什么、谁能操作什么」从来不是实现细节，而是规则本身。请假工具里「老板」这个词，藏着至少三个角色：直属主管、部门总监、HR——他们的权限各不相同，你含糊地说「老板批准」，AI 就给你造一个能看到全公司数据的超级角色。
四、数据的一生。数据被创建之后去哪？请假记录三年后还在吗？员工离职了记录归谁？「对账差一分钱怎么追溯」这类问题属于此类。数据的生命周期问题平时隐形，出事时全是它在作祟。
五、验收标准。最重要的一个：你怎么知道结果是对的？「好用」「智能一点」不是标准，「请假超过三天的必须总监批准，否则主管即可」才是。没有验收标准，你和 AI 之间就没有合同，只有 vibes。
大白话：顺利的路径是公路，必要复杂度是地形。AI 能替你铺最快的路，但山在哪里、河有多宽，得你亲自指给它看——不指，它就开路开进河里。
「说清楚」不是写作技巧，是认知劳动
这份清单令人泄气的地方在于：它一个都外包不掉。你可以让 AI 写代码、配服务器、画界面，但「三十天假该不该区别对待」取决于你公司的管理制度，「数据留三年还是七年」取决于你的合规要求——这些问题的答案只存在于你的脑子里，和问题的上下文里。
过去这个劳动也存在，只是被中间商吸收了：程序员接到模糊需求时会追问、会假设、会替你补全，然后花几周把歧义磨平——你在评审会上看到的「做的不是我要的」，就是磨平的账单。AI 时代这笔账单没有消失，它只是提前了、显形了：从「开发中途扯皮」提前到了「你开口的那几分钟」。
所以 vibe coding 时代的核心技能，不是学会怎么写提示词——那些技巧三个月就过时——而是对自己要做的事情有结构化的认识：顺利路径是什么，五种复杂藏在哪里，验收线画在哪。这张清单就是「需求即代码」时代的语法书。
顺便说一句，这套清单不只对写软件有用。下一章你会发现，律师、分析师、设计师、产品经理的工作，正在全部变成同一件事：说清要什么，验收做出来的结果。这个趋势有个名字——vibe work。