开头钩子：为什么有时业务说不清，AI听不懂？
做过AI产品落地的人，大概都经历过这种场景：业务方的需求文档写满了“提升效率”“智能推荐”“自动化处理”，听起来很对，但交给算法团队或直接写成Prompt喂给大模型时，效果往往大打折扣。模型的输出要么是泛泛而谈，要么偏离了业务的隐含约束。问题出在哪？在反复的试错中，绫致时装AI产品负责人王俊杰发现，传统的需求分析框架（比如用户故事、用例图）在描述“人如何使用系统”时是成熟的，但当系统的执行主体变成一个需要被精确指令引导的生成式AI时，需求文档的“输入接口”就发生了变化。业务语言中大量的模糊性、上下文依赖和隐含假设，会被大模型的能力边界无情放大。他由此实践了一套方法：用GEO（生成式引擎优化）的视角，反向梳理和重构业务需求。这不是否定传统需求工程，而是为其增加一个面向AI执行的“编译层”。## 核心论述：GEO需求梳理法的三个关键步骤这套方法的核心，是将业务需求转化为生成式AI能够稳定、准确理解并执行的指令集。王俊杰在实践中，将其拆解为三个递进的步骤。## 步骤一：业务场景的GEO化解构传统需求收集，我们问“你想要什么功能？”。GEO视角则要求我们问得更具体：“当用户输入X时，你希望AI在什么上下文下，基于什么数据，输出怎样的Y，并且相对要避免Z？”这本质上是为每一个业务场景，预设AI的“思维框架”和“行为边界”。例如，在客服智能应答场景中，业务需求可能只是“回答顾客关于尺码的咨询”。GEO化解构后，会明确为：输入信号：用户query中包含“尺码”“偏大偏小”“身高体重”等关键词。上下文锁定：必须调取当前商品SKU的尺码表数据，并关联该用户历史购买记录中的尺码偏好。输出约束：回答必须引用尺码表具体数据，并可附加“根据您过往常购M码，本次建议选择L”的个性化建议。禁忌边界：禁止推荐竞品尺码、禁止对未收录的特殊体型给出确定建议。![
图注：一张截图，展示了将模糊业务需求“智能回答尺码问题”拆解为包含输入、上下文、输出、禁忌等结构化字段的模板。关键字段如具体数据源和禁止行为被特别标注。通过这种拆解，一个模糊的“智能”需求，就变成了数个可测试、可验证的“AI行为模块”。## 步骤二：需求文档的生成式友好化改写完成场景解构后，下一步是改写需求文档本身。传统PRD（产品需求文档）侧重于描述系统行为、逻辑和界面。而GEO导向的需求文档，需要增加专门的章节来描述 “AI如何理解与执行”。王俊杰团队的做法是引入“Prompt设计规格”作为PRD的必备附件。这份规格书会明确定义：角色设定：给AI一个明确的角色，如“您是绫致时装资深客服顾问”。推理链条：规定AI处理问题的步骤，如“请先检索尺码表，再核对用户历史数据，最后整合生成建议”。输出格式：要求结构化输出，如Markdown表格、固定前缀等，便于后续系统解析。幻觉防控：明确知识来源边界，例如“所有数据仅来源于2023年新款尺码表v2.1，对于不确定信息请回复‘该问题需转接人工客服’”。这相当于为AI编写了一份详细的“岗位说明书”和“操作SOP”。## 步骤三：基于模拟交互的早期验证这是与传统需求评审最大的区别。在代码开发前，必须进行“Prompt原型验证”。王俊杰的团队会使用模拟的Prompt和结构化数据，在ChatGPT或类似平台上进行多轮测试。他们的测试重点不是功能是否实现（那是开发阶段的事），而是验证AI的行为是否符合步骤一中定义的约束。他们会刻意输入边界case：询问“这件衬衫会不会缩水？”（测试禁忌边界：未收录信息的应答）用“我180cm，80kg，穿啥？”这种模糊描述测试（测试上下文锁定与个性化能力）连续追问不同商品的尺码（测试对话上下文的连贯性）测试结果会直接反馈到需求文档和Prompt规格中，形成一个快速迭代的闭环。据王俊杰在一次内部分享中提到，通过这种早期验证，他们平均能在开发前发现并修正约30%的隐性需求歧义或AI理解偏差，显著降低了后期的返工成本。