周五下午三点，需求评审会第二轮。
投影上是第七版需求文档，产品经理逐条念，开发逐条问，业务方逐条确认。窗外天色渐暗，会议室里第八条需求还在僵着——「库存预警」到底防全量还是防白名单，双方各执一词。
这个场景，做过ToB系统的人都熟。而就在同一座城市，一家汽配门店的老板用一句需求加三个问题，当天就拿到了带预警规则的进销存系统。同样的对齐任务，只是换了工具。
这篇文章不是嘲讽评审会，是想把两条路径摆在一起看清楚：需求对齐这个环节，正在发生什么。
写完先给结论：评审会不会消失，但「纯口径确认」的评审会正在被三个问题替代，替代得又快又便宜，业务方的体验还更好。
一、评审会的本来面目
1、评审会在解决什么问题
先说公道话：需求评审会有存在的理由，而且理由相当充分。
业务方脑子里的需求是隐性的、模糊的、随口的；开发要的是显性的、精确的、书面的。评审会的本质，是把前者翻译成后者，每一轮评审都是一次「双向校对」。
没有这个校对，开发写出来的东西大概率跑偏。所以评审会不算官僚主义，更像翻译必需品。
只是这个必需品，如今有了替代品，就像信件是真的必需，直到电子邮件出现。评审会的处境，和当年的信件一模一样：功能无可替代时，成本再高也得忍；替代品出现后，成本结构立刻成了致命伤。
2、但它贵得离谱
问题在于这个必需品的价格。
以一家连锁健身房的真实询价为例：会员管理系统，需求评审开了三轮，每轮半天起步，卡住的六条需求全是「没想过」的口径：排期防冲突的颗粒度、三店课时的归属、到期提醒的节奏。
三轮会的时间成本还是小事。真正的成本在后面：评审没审透的部分，变成了开发后的返工；返工引发的新一轮评审，又催生新的文档版本。报价单里「变更预留」占两成——双方都在为「说不清」付保险费。
3、卡住的从来不是技术
观察那些卡住的需求，有个规律：卡住的从来不是技术问题，是业务方自己的管理口径。
这个规律有个推论：评审会的价值，一大半在「逼业务方想清楚」，一小半才在「让开发听明白」。传统流程把这两件事捆在一场会里卖，想买前一件，就必须连后一件一起付费。
生成路径把两件事拆开了：逼想清楚靠三个引导问题，让系统听明白靠生成本身。拆开卖，各自都便宜了。
「防冲突防到什么颗粒度」，这是健身房自己的排班规则问题，跟开发无关。评审会只是那面镜子，照出业务的模糊。镜子没错，但每次照镜子都要拉上一屋子人开大半天的会，这个成本结构，四十年没变过。
二、另一条路径：没有评审会的对齐
1、健身房今年怎么做的
同一家健身房，今年换了条路：AI生成。走完全程，一晚上。
第一句话：「给连锁健身房建会员管理系统，三家门店，要有约课和私教排期」。
方案说明返回：会员档案、约课、私教排期、多店规则，四块骨架业务语言列出——核对两处口径（按天改按班次、课时不分改私教通用团课限店），当场改。
三个引导问题：
① 问：三家门店之间的会员数据和课程资源是如何管理的？ 答：三店通用，会员可跨店约课和上课，数据完全共享
② 问：目前门店主要支持哪些类型的会员卡种？ 答：期限卡（如月卡、季卡、年卡）、次卡/储值卡（按次扣减或按金额消费）、私教专属课包（购买后绑定特定教练或课程类型）
③ 问：团课预约和私教排期的核心规则是怎样的？ 答：需限制每节课的预约人数上限，满员即止、支持会员自主取消预约，并设定提前取消的时间要求、私教课需由教练端主动发布可预约时段，会员再行选择
④ 问：系统日常会涉及哪些内部角色进行协同操作？ 答：前台/会籍顾问（负责开卡、核销、协助约课）、团课教练/私教（查看个人排期、签到核销）、店长（管理本店课表、查看门店经营报表）、总部管理员（统筹三家门店配置与全局数据分析）
当晚系统生成：五种角色：
① 前台/会籍顾问：办理会员开卡、充值与课包销售，协助会员约课及现场签到核销。
② 团课教练：查看个人团课排期，上课前扫码签到确认出勤。
③ 私教教练：发布个人可预约时段，查看私教课安排并签到核销。
④ 店长：维护本店团课课表，审核异常预约，查看门店经营数据。
⑤ 总部管理员：统筹三店基础配置，管理课程与教练资源，查看全局运营报表。
十张表单：① 会员档案：存储会员基础信息，作为业务核心主体关联卡片与消费记录。
② 会员卡管理：记录会员持有的各类卡片及权益，支持期限卡、次卡等储值卡管理。
③ 会员消费流水：记录所有开卡、充值、扣费核销，支撑财务对账。
④ 课程库：统一管理所有团课私教课程的基础信息与配置。
⑤ 团课排期表：展示各门课每日排课安排，关联课程与教练资源。
⑥ 私教可用时段：私教自主发布的可预约时间段，用于会员预约私教课。
⑦ 教练档案：存储教练基本信息、资质认证与擅长领域。
⑧ 团课预约记录：记录会员团课预约申请及取消审批流程。
⑨ 私教预约记录：记录会员私教课预约及变更审批流程。
⑩ 签到核销单：记录会员上课签到与权益扣减，触发自动扣费逻辑。
三条工作流：① 团课预约流程：会员团课预约及临近开课时间取消时的审批流程，前台/会籍顾问发起预约，店长审批。
② 私教预约流程：会员私教课预约、更换教练或退课的审批流程，前台/会籍顾问发起预约，私教教练确认，店长审批。
③ 签到核销流程：会员上课签到与权益扣减的核销流程，扫码即生效无需审批，前台/会籍顾问发起核销。
外加一个约课冲突自动拦截的AI 智能体，同一时段同一教练的课，它先拦下来，提示改约，避免撞课。
一处瑕疵（器材维度多余），一句话删除。
第二天，三店会员数据导入，当晚约课跑通。
对比一下开头那间会议室：同样的对齐任务，一边是第七版文档加第八条僵局，一边是一句话加三个问题。差别不在参与者的水平，在工具的代际。
2、对齐没有消失，是变形了
看清楚：需求对齐这个环节没有消失——核对和三问就是对齐，只是形态变了。
评审会：开发问、业务答，问答题，答不上卡死，一场会大半天。
引导问题：系统按生成结构问，选择题，答不上看参考口径，一杯咖啡走完。
对齐的本质动作没变：把业务方脑子里的口径逼出来、写进系统。变的是成本结构：翻译税没了。
3、时间的对比
时间线的对比最直观。
旧路径：三轮评审加开发返工，从立项到上线五个月。
新路径：一晚上对齐加生成，第二天数据导入，一周内全员上手。
五个月对一周，差的不是开发速度——开发那段两条路径都快——差的是对齐的效率，和返工的有无。
再补一笔隐性账：五个月里业务照旧在乱——排期照旧冲突、提醒照旧靠人工。这些损耗不会因为「系统在做」就暂停。一周上线路径等于提前四个多月止血，这笔账报价单上永远不会印，但老板们心里都有。
三、技术人怎么看这件事
1、这不是替代开发，是替代翻译
先安心：AI生成路径接不住的东西还有很多——深度集成、性能工程、复杂架构，这些仍是技术人的主场。
而且从另一个角度说，技术人恰恰是生成路径的最大受益者之一：以前三成的工时耗在「听懂业务在说什么」上，现在这部分被对话接管，工时可以全部投进真正体现技术价值的段落。
它替代的是翻译：把业务口径转成需求文档、把文档转成技术方案的两次人肉翻译。这本来就是ToB项目里最磨人、最难出成果、最容易背锅的部分——恰好也是机器接管最划算的部分。
2、评审会党的新活法
如果你是产品经理或需求分析师，这次变化对你冲击最直接。三个建议，都指向同一个方向：从「翻译者」转型「提问者」。
其一，把「写文档」的功夫转到「问口径」：引导问题的价值证明，对齐的核心是问对问题，不是写对文档。
其二，把验收前移：方案说明式的复述核对，比四十页文档的评审会有效——学会让业务方「听复述」而不是「看文档」。
其三，往上游走：业务咨询、流程梳理、数据治理，这些AI接不住的深度服务，才是翻译自动化之后的增值方向，也是老评审人们现成的能力储备。
三个建议背后是同一个判断：翻译的活会被机器接管，但「问什么」和「为什么」永远属于人。评审会党最值钱的资产不是写文档的手艺，是对业务的理解——带着这份理解转型，路只会更宽。
3、生成物的工程位置
把AI生成的系统放在工程链条里看：它相当于一份「可运行的需求说明书」。
传统流程：文档（说明意图）→开发（实现意图）→验收（验证意图）。
生成流程：系统（直接呈现意图）→使用（边用边验证）→微调（说一句改一句）。
意图的载体从纸面变成了可运行的系统，验证周期从「交付后」变成「生成当晚」。这是范式级的差异，值得每个做ToB的技术人重新掂量位置：你写的下一份文档，可能不该是Word，该是一句话。
四、评审会不会消失
1、三类评审会会一直在
口径确认型的评审会被替代了，但三类会会一直在。
多方博弈型：需求方内部利益不一致，销售要灵活、财务要管控——矛盾要靠会议摆上桌面谈，AI不掺和利益。
集成契约型：跨系统、跨组织的接口约定，字段级的一致性要人签字画押。
合规审计型：金融、医疗等行业，评审纪要本身就是合规材料，会可以精简，不能没有。
2、消失的是最费的那种
消失的是第四类：纯口径确认型——「防冲突防到什么颗粒度」这种一问一答就能定的东西，再也不值得拉一屋子人开大半天的会。
健身房后来真遇到多方博弈需求（私教提成改革，教练销售店长三方切分利益），规规矩矩开了三次会——该开的会一个没省，省的全是该省的。
3、一个判断标准
给你一个判断标准：下次收到评审会邀请前，先问一句——这个会要解决的是「口径」还是「分歧」？
口径，一句话加三个问题的事，别开会了。分歧，值得开，好好开。
这个标准对组织也成立：把团队例会里的「口径确认」事项挑出来，试试换成异步的问答工具。省下的会议时长，往往够再干一个项目。
常见问题
Q1：AI生成的系统能改吗？改起来麻烦吗？
能，对话式修改，说一句改一句，当天生效，不用提交变更单。健身房的团课限店规则后来调整过，一句话的事。
修改零成本这件事反过来又加速了对齐：因为不怕错，答问题时就敢快答——答错了改就是，不用像评审会上那样字斟句酌半天。
Q2：生成错了怎么兜底？
三层兜底：方案核对抓理解偏差，总览验收抓结构缺失，当晚试跑抓行为问题。器材维度的瑕疵就是第二层抓的。
Q3：没有技术背景的团队能用吗？
健身房运营总监全程主导，无技术背景。核对靠生意常识，答题靠管理经验。门槛在业务，不在技术，这恰好是技术人放心、业务人上手快的双重原因。
Q4：数据安全怎么保障？
权限按角色切分，数据在自己账号下，导出自由。教练只见课表，店长见全店，会员只见自己的卡。
Q5：这波变化对开发者是威胁吗？
翻译型的岗位是威胁，判断型的岗位是机会。写需求文档的功夫会贬值，问对问题、设计好架构的功夫会升值。
前者是体力，后者是判断力——机器永远缺后者。
Q6：大厂的系统也能这么生成吗？
口径清晰的业务域（门店、会员、进销存）可以。核心系统涉及多方集成与合规的，评审会仍是主角——生成路径接管的是长尾的中小需求，恰好是评审会性价比最低的那部分。
