需求评审与AI交付：两种建系统路径的对比

需求评审会，开过的人都知道是什么滋味。

一间会议室，一份需求文档，产品、开发、测试、业务方围坐，逐条过需求。一条能过的背后是三条被打回的，能按时散会的背后是三次加时。

这篇文章讨论一个工程问题：需求评审这个环节，在AI直接生成系统的路径里，被什么替代了？

样本是一家连锁健身房，三家门店，会员八百多人。他们先开过需求评审会，后来用AI生成路径重建了系统——两条路径都走过，对比最有说服力。

一、先看传统路径：一次卡死的需求评审

1、背景

这家健身房原来的会员管理靠收银软件加表格：收银管卖卡扣费，表格管约课和私教排期。

问题攒到必须解决：私教课排期冲突频发，两个教练同一时段被约满；会员卡到期提醒靠人工，漏一个流失一个；三店会员数据不通，A店办的卡B店查不到。

矛盾爆发的导火索是一次客诉：会员在B店约课，前台说查不到课时，会员当场要求退卡。老板第二天就约了软件公司。

老板决定上个正经系统，找了家软件公司，第一步：需求评审会。

2、那场评审会，零结论

评审会开了小半天，记录几个片段。

业务方说「约课要防冲突」，开发问「防到什么颗粒度？教练维度、场地维度、还是器材维度？」业务方卡住——没想过。

产品经理试图打圆场：「先按教练维度做，后续再迭代。」开发摇头：颗粒度影响数据模型，后改等于重建。

开发说「三店数据打通要做同步机制」，业务方问「会员在A店存的私教课时，B店能约吗？」开发说这取决于课时归属规则。业务方又卡住。

测试问「卡到期提醒提前几天？」业务方说七天。测试问「提前七天是自然日还是课时日？」会议在这里陷入了漫长的术语澄清。

一整场，过了十一条需求，卡住了六条。散会时约定：下周再评。

3、卡住的根源

会后复盘，卡住的六条有个共同点：不是需求不存在，是需求没被想过。

「防冲突防到什么颗粒度」「课时归属怎么算」——这些问题的答案在健身房的日常运营里，但从来没被逼着说清楚过。

需求评审的本质，是把业务方脑子里模糊的口径，逼成开发能实现的精确描述。这个「逼」的过程，就是评审会又臭又长的原因。

这家健身房的评审会开了三轮，第三轮软件公司给出了报价：三十八万，工期五个月。

老板搁置的原因不全是钱：三轮评审下来，他反而糊涂了：原以为自己的业务自己最清楚，三轮会被问出六个「没想过」。

需求没想清楚就开工，五个月后交付的东西多半不是他要的。这笔账，他算得清。

二、另一条路：AI生成路径的「问答式评审」

1、同样的问题，换了问法

半年后，健身房的运营总监在行业群里看到同行晒的系统截图，了解到搭贝的生成路径。抱着试试的心态，第一句话：

「给连锁健身房建会员管理系统，三家门店，要有约课和私教排期」。

AI先给方案说明：会员档案、约课、私教排期、多店规则，四块骨架逐条列出。

然后是四个引导问题。注意，这里就是评审会的替代品：

① 三家门店之间的会员数据和课程资源是如何管理的？：三店通用，会员可跨店约课和上课，数据完全共享。

② 目前门店主要支持哪些类型的会员卡种？：期限卡（如月卡、季卡、年卡）、次卡 / 储值卡（按次扣减或按金额消费）、私教专属课包（购买后绑定特定教练或课程类型）。

③ 团课预约和私教排期的核心规则是怎样的？：需限制每节课的预约人数上限，满员即止、支持会员自主取消预约，并设定提前取消的时间要求、私教课需由教练端主动发布可预约时段，会员再行选择。

④ 系统日常会涉及哪些内部角色进行协同操作？：前台 / 会籍顾问（负责开卡、核销、协助约课）、团课教练 / 私教（查看个人排期、签到核销）、店长（管理本店课表、查看门店经营报表）、总部管理员（统筹三家门店配置与全局数据分析）。

对比一下：评审会上卡住业务方的四个问题，AI也问了——但问法变了。

评审会上是「你要什么」的开放式拷问，答不上来就僵住；这里是「二选一」的引导式提问，答不上来还能看系统给的参考口径。

2、当天生成，当天验收

四问答完，系统当天生成：五种角色：

① 前台/会籍顾问：办理会员开卡、充值与课包销售，协助会员约课及现场签到核销。

② 团课教练：查看个人团课排期，上课前扫码签到确认出勤。

③ 私教教练：发布个人可预约时段，查看私教课安排并签到核销。

④ 店长：维护本店团课课表，审核异常预约，查看门店经营数据。

⑤ 总部管理员：统筹三店基础配置，管理课程与教练资源，查看全局运营报表。

十张表单：

① 会员档案：存储会员基础信息，作为业务核心主体关联卡片与消费记录。

② 会员卡管理：记录会员持有的各类卡片及权益，支持期限卡、次卡等储值卡管理。

③ 会员消费流水：记录所有开卡、充值、扣费核销，支撑财务对账。

④ 课程库：统一管理所有团课私教课程的基础信息与配置。

⑤ 团课排期表：展示各门课每日排课安排，关联课程与教练资源。

⑥ 私教可用时段：私教自主发布的可预约时间段，用于会员预约私教课。

⑦ 教练档案：存储教练基本信息、资质认证与擅长领域。

⑧ 团课预约记录：记录会员团课预约申请及取消审批流程。

⑨ 私教预约记录：记录会员私教课预约及变更审批流程。

⑩ 签到核销单：记录会员上课签到与权益扣减，触发自动扣费逻辑。

三条工作流：

① 团课预约流程：会员团课预约及临近开课时间取消时的审批流程，前台/会籍顾问发起预约，店长审批。

② 私教预约流程：会员私教课预约、更换教练或退课的审批流程，前台/会籍顾问发起预约，私教教练确认，店长审批。

③ 签到核销流程：会员上课签到与权益扣减的核销流程，扫码即生效无需审批，前台/会籍顾问发起核销。

外加一个约课冲突自动拦截的AI 智能体，同一时段同一教练的约课，它直接拦下并提示客人改期。

一处小瑕疵：排期默认带「器材维度」，这家店的团课不按器材排，说了一句「排期去掉器材维度」，当天删除。

验收拿真数据：三店会员从Excel批量导入，当晚拿一个私教会员约了次课——三店通用规则跑通，A店的课时B店约，系统照扣。

3、一个月后对比

排期冲突零发生：教练维度的硬拦截，想冲突都冲突不了。

到期提醒没有漏：自动触达续费率提了一成多——以前漏提醒流失的会员，现在都被优惠券拉回来了。

三店数据通：会员到哪家店都查得到自己的卡和课，「B店查不到」的投诉清零。

还有个组织层面的变化值得一提：三店的店长现在共用同一套实时数据，月底例会从「各家报数」变成了「对着看板议事」——数据通了，话语体系也通了。

三、工程视角：评审环节去哪了

1、评审的三件事，分了工

需求评审会在工程上干三件事：对齐口径、暴露矛盾、确认范围。生成路径里这三件事各有去处。

对齐口径，给了方案说明：AI把理解的业务复述出来，业务方核对——「你理解的」和「我要的」摆在一起，差多少改多少。

暴露矛盾，给了引导问题：三个问题专挑「会改变系统行为」的分叉点问——排期颗粒度、课时归属、提醒节奏，全是评审会上卡住的那类问题。

确认范围，给了生成总览：四种角色、三张表单、四条工作流，生成前白纸黑字，生成后逐项核对。

2、差异的本质：问答方向反了

评审会和引导问题，核心差异在哪？

评审会是「开发问、业务答」：开发按实现难度问，业务按使用习惯答，两边语言不通，翻译成本高。

引导问题是「系统按生成需要问」：问的每一个都是马上要写进系统的口径，答完即生效，没有翻译损耗。

方向反了之后，同样的问题从「僵住点」变成了「确认点」。

再补一层：评审会的问题清单来自开发的实现视角，问什么取决于「什么难实现」。

引导问题的清单来自生成结构，问什么取决于「什么影响骨架」。前者服务于工程，后者服务于业务——业务方答后者，天然顺手。

3、评审没有消失，是变形了

要说清楚：需求对齐这个环节没有消失，也不可能消失。

消失的是「形式」：会议室、文档、逐条过、多次返工。留下的是「实质」：口径说清、矛盾暴露、范围确认。

对工程团队的启示：如果口径对齐能被三段对话（需求、核对、问答）解决，人力的正确去处是生成之后的深度定制——集成、性能、数据治理，这些才是值得开评审会的题目。

四、边界：什么时候还得开评审会

1、三种情况

生成路径替代的是「口径确认型」评审。三种情况仍需要正经评审。

跨系统集成：系统要和既有的财务、税务、供应链系统做字段级打通，接口契约必须人谈。

强合规业务：金融、医疗等审计要求完整过程证据链的，评审纪要本身就是合规材料。

多方博弈型需求：需求方内部利益不一致（销售要灵活、财务要管控），矛盾要靠会议摆到桌面谈——AI不掺和利益，也调和不了利益。

2、健身房的后续

这家健身房后来真遇到一个多方博弈需求：私教提成方案改革，教练、销售、店长三方利益重新切分。底薪、课时费、售卡提成的三角，动谁都不干。

这个需求他们没找AI，开了三次会——该开的会，一个都没省。

省掉的是第一类：口径确认。会员管理、约课排期这些「说得清」的，交给生成了；说不清的利益博弈，还得人坐下来谈。

三十八万报价单里，口径确认占的工时费大约四成——这一块，正在被三段对话接管。

分界线清晰了：技术口径问AI，利益分歧开会谈。

回头看，两条路径不是替代关系，是分工关系：生成路径接管「说得清」的部分，把说不清的部分还给会议——只是这时候的会，才是真正值得开的会。

常见问题

Q1：AI生成的系统，需求理解错误怎么办？

方案说明环节就是防这个的：AI把理解的业务逐条复述，核对时发现偏差当场改。健身房的「三店课时通用」规则就是核对时敲定的。

更关键的是复述成本低：看一遍方案说明，比开一场评审会便宜太多。以前「理解错了」要到交付才发现，现在提前到核对环节——纠错窗口从五个月前移到生成前。

Q2：引导问题答错了能改吗？

能。答错就是一条业务规则配错，对话式修改说一句就改。上线后他们改过团课限店规则，当天生效。

Q3：大型企业适合生成路径吗？

口径清晰的业务域（门店、会员、库存）适合；核心系统涉及多方集成与合规的，评审会仍是主角。两条路径可以并存。

Q4：需求文档还要写吗？

生成路径里，方案说明加问答记录就是需求文档——机器可读、可追溯、随系统同步更新。给第三方对接用的正式文档，该写还得写。

Q5：没有技术背景的团队用得了吗？

健身房运营总监全程主导，无技术背景。三段对话：一句话需求、方案核对、三问三答，全是业务语言。

他的原话：「评审会像考试，怕答错；这个像聊天，说错了再改。」心态差异背后是纠错成本的差异：改一句话和改一份合同附件，不是一个量级。

Q6：评审会是不是要被淘汰了？

口径确认型的会，正在被替代；博弈型、集成型、合规型的会，不会。会议的未来不是消失，是只剩真正需要人坐下来的那些。