夜雨聆风我参与过一个的企业项目，做的是销售团队的客户跟进提醒。
项目不大，12个人左右的研发组，目标也不复杂：客户太久没跟进，系统自动提醒销售，避免商机丢掉。听起来是不是挺简单的？
老周是后端负责人，动作嘎嘎快，他把产品初版的PRD文档扔给Claude Code，接口、定时任务、提醒模板、后台页面，一上午就把Demo做出来了。
他当时还挺兴奋，跟我说：
“以前这种功能怎么也得磨两三天，现在半天就能看Demo。”
我看了他的Demo，的确像那么回事，把PRD里主要的需求都实现了。
直到评审会开始。
销售负责人看完页面，问了一句：
“多久没跟进算逾期？”
会议室安静了一下。
产品说：“大概一周吧。”
销售负责人马上追问：
“客户昨天刚进入报价阶段，但销售没写跟进记录，这算没跟进吗？”
测试同事也开始翻用例：
“客户已经签合同了，还提醒吗？销售离职了，提醒发给谁？主管能看到下属所有客户，还是只能看自己区域？”
我当时就懵了。不是因为这些问题刁钻，而是因为代码已经写出来了，可真正该确认的业务规则，还停在一句话上：
系统自动提醒销售及时跟进客户，避免客户流失。
这句话写在需求文档里，好像没什么问题。
但你让AI写代码，它就必须猜。
“及时”到底是3天、7天，还是15天？
“跟进”是打电话算，发微信算，写拜访记录算，还是必须在CRM里留痕才算？
客户进入合同阶段，还算不算需要跟进？
销售离职了，提醒发给原销售、主管，还是区域负责人？
主管能不能看到跨区域客户？
提醒发错了，谁解释？
你发现没有，需求里每一个含糊词，落到系统里都会变成一个默认判断。
最麻烦的是，这些默认判断不是业务方确认过的，而是AI猜出来的。
AI写得越快，猜得越多。
猜得越多，后面返工越狠。
老周刚开始觉得问题不大，说“补几个条件就行”。
我一听这句话，心里就有点发紧。
企业项目里，“补几个条件”经常不是补几行代码。
这次就是。
补触发条件，定时任务要改。
补客户状态，状态判断要改。
补离职转交，人员关系要改。
补主管权限，权限模型要改。
补消息留痕，表结构和测试用例都要跟着动。
原来半天跑出来的Demo，看起来省了时间，实际把没澄清的需求快速固化进了系统。
后面老周连着改了三轮。
第一轮，销售主管说提醒太频繁，销售觉得系统像在催命。
第二轮，测试发现客户已经成交了，系统还在提醒销售继续跟进。
第三轮，上线前权限评审卡住了，因为区域主管能看到不属于自己区域的客户摘要。
你看，这里面没有一个问题是AI不会写代码。
问题是，AI把一个没讲清楚的业务规则，快速写成了一个没人敢签字的功能。
后来我把需求拉回来，先不让老周继续写。
我当时补了一张表，直接贴到评审文档里。
老周看完说了一句：
“这张表要是早一天有，我至少少改一半。”
这句话挺真实的。
AI不是不能用，恰恰是太能用了，所以前面的需求更不能糊弄。
后来我把原来的需求改成了这种写法：
当客户处于“意向沟通”或“方案报价”阶段，且最后一条有效跟进记录超过7个自然日时，系统在每天9:30向客户负责人发送提醒；如果客户负责人为空或已离职，提醒发送给直属主管；客户进入“合同签署”“成交”“关闭”状态后不再提醒；每条提醒都要记录发送时间、接收人、客户状态和已读状态。
这段话不漂亮，但能交付。
开发知道怎么写。
测试知道怎么验。
业务知道自己签的是什么。
上线后真出问题，也能查到是规则问题、数据问题，还是执行问题。
我现在参与这类AI项目，会很警惕一种情况：
页面出来很快，接口也能跑，可需求里的关键判断没人确认。
这时候千万别急着夸效率。
你要先问一句：
这个功能跑出来以后，业务敢不敢认？测试能不能验？负责人愿不愿意签字？
说白了，AI可以替你写代码，但不能替你背业务责任。
它能写定时任务，但不能替销售负责人定义什么叫客户流失。
它能生成权限判断，但不能替技术负责人承担越权风险。
它能补测试用例，但不能替产品确认验收标准。
后来我让老周改了AI的使用顺序。
别一上来就让AI写代码。
先让AI挑需求里的坑。
我给他的提示词很简单：
你是企业系统交付负责人。请阅读下面这段需求，找出会影响开发、测试、验收、权限、数据、异常处理和上线责任的模糊点。每个模糊点请输出：需要确认的问题、可能选项、建议默认方案、需要哪个角色确认、不确认会造成什么返工风险。需求如下：{粘贴需求原文}
这一步看起来像是在拖慢进度，其实是在省后面的命。
需求阶段发现问题，只是改几句话。
开发完发现问题，要改代码。
测试阶段发现问题，要改用例。
上线前发现问题，可能要改权限、改数据、改发布计划。
上线后发现问题，那就不是返工了，是事故复盘。
所以我现在越来越相信一句话：
AI不是交付捷径，它是放大器。
需求清楚，它放大效率。
需求模糊，它放大返工。
一个需求没澄清，AI写得越快，后面返工越狠。