从 0 到 1 构建 AI 需求分析引擎：Skills 技术架构与落地全复盘

从 0 到 1 构建 AI 需求分析引擎：Skills 技术架构与落地全复盘需求分析不是把一段自然语言丢给大模型，然后等待一份“看起来像 PRD”的回答。真正可落地的方案，必须把需求理解、知识约束、结构化编译、冲突校验、接口推导和工程治理串成一条可验证的生产链路。很多团队做 AI 需求分析时，第一反应是做一个聊天机器人，让产品经理输入一句话，模型输出一段功能描述。Demo 往往很好看，但一旦进入真实研发流程，问题立刻暴露出来：输出不稳定，同一个需求多问几次，结构和边界都不一样模型会幻觉出根本不存在的业务规则、字段和接口结果无法直接进入评审、设计、开发和测试环节需求量一大，请求成本、响应延迟和错误率迅速失控所以，企业真正需要的不是“AI 帮我写需求”，而是一个能把需求分析工程化、结构化、可回放、可治理的Skills 引擎。本文基于一套企业级 SaaS 平台的真实落地视角，系统拆解如何从 0 到 1 构建一个面向需求分析场景的 Skills 系统。重点不只放在 Prompt，而是回答下面几个工程问题：Skills 在需求分析场景中到底扮演什么角色为什么它比单纯的 Chat、RAG、工作流节点更适合作为能力底座如何把原始需求变成结构化需求卡片、接口变更和风险清单如何在高并发、多租户、复杂业务规则下做到稳定可扩展如何让这套系统进入真实研发流程，而不是停留在演示环境一、为什么需求分析会成为研发体系的瓶颈在很多中大型团队里，需求分析表面上是产品经理的工作，实际上它是整个研发交付链路的起点。一旦这个起点不稳定，后面的系统设计、接口开发、联调测试、上线验收都会被持续放大。以一个企业协同 SaaS 平台为例，团队负责即时通讯、项目协作、文档管理、审批流和权限中心等多个模块，季度活跃需求常年在数百个以上。团队最开始的问题并不是“开发不够快”，而是“大家以为自己理解的是同一个需求，但实际上不是”。典型表现有四类：产品经理用业务语言描述目标，研发团队却需要系统边界、状态机和异常分支一个看似简单的功能点，背后牵涉多个服务、多个角色和多条审批链路老同学靠经验能脑补出隐含规则，新同学只能靠会议和聊天记录猜评审会越来越长，但真正的逻辑冲突往往在开发中后期才暴露这类问题本质上不是沟通态度问题，而是系统缺少一层把“模糊需求”翻译成“工程对象”的编译层。换句话说，需求分析之所以难，不是因为人不会写文字，而是因为它同时包含五种不同形态的信息：业务目标：这个需求为什么存在，要解决谁的问题交互规则：谁在什么条件下能做什么事领域约束：组织、权限、计费、库存、审批等隐含规则系统影响：会改哪些服务、哪些接口、哪些数据结构非功能要求：性能、可用性、安全、审计、灰度、回滚如果没有一套中间结构，这五类信息就会在会议纪要、PRD、聊天记录和代码实现之间反复损耗。二、需求分析引擎不等于聊天机器人1. 普通 LLM 为什么做不好需求分析直接让通用大模型分析需求，通常会遇到三个致命问题。第一，模型擅长补全，但需求分析最怕“脑补”。用户说“给任务增加审批能力”，模型很可能自动扩写出审批人、抄送人、超时提醒、撤回规则等内容。这些内容未必错，但它们不一定真实存在于当前业务上下文中。对内容创作来说，这叫“丰富细节”；对需求分析来说，这叫“制造伪需求”。第二，模型没有企业内部领域锚点。大模型不天然知道你们公司的权限中心是 RBAC 还是 ABAC，不知道某个订单状态能不能逆转，不知道审批流里是否允许跨部门会签，也不知道历史兼容约束是什么。没有知识锚点，需求分析只能停留在“通用正确”，而不是“系统正确”。第三，输出不可控，无法进入工程流水线。需求分析最终要进入评审、任务拆解、接口定义、测试设计和发布检查，这意味着输出必须稳定、结构化、可校验、可追踪。自然语言回答再漂亮，只要不能稳定转成结构化对象，就无法成为生产资产。2. Skills 的本质：把能力做成可治理的“需求分析模块”在这个场景下，Skills 不是“写得更好的 Prompt”，而是一种可加载、可版本化、可审计的能力单元。它至少应该回答六个问题：这个技能解决什么需求分析问题触发条件是什么依赖哪些知识、规则、脚本和工具输入输出的结构是什么错误如何恢复，边界如何约束评测和回归用例如何组织因此，Skills 更像“面向 Agent 的能力包”，而不是“一段提示词模板”。在需求分析系统里，一个 Skill 可能是：requirement-intent-classifier：识别需求属于新增能力、规则变更还是流程改造permission-impact-analyzer：分析角色和资源权限影响面api-change-inference：从需求卡片推导 API 变更建议conflict-detector：检查与现有规则、流程、状态机是否冲突test-scenario-generator：把结构化需求转换为测试场景和验收用例这意味着，需求分析系统不应被设计成一个“大而全”的聊天入口，而应该被设计成一个由多个 Skills 组成的能力网络。三、从 Chat 到 Skills：需求分析系统的核心方法论1. 正确目标不是“生成 PRD”，而是“编译需求”很多团队希望 AI 一步生成完整 PRD，这其实把最难的事情留到了最后。更合理的做法是把需求分析看成一次“编译过程”：自然语言需求 - 意图识别 - 领域槽位提取 - 规则补全 - 依赖知识检索 - 结构化编译 - 冲突校验 - 影响面分析 - 接口与测试产物生成在这个模型里，大模型不是最终输出者，而是多个编译阶段中的一个推理组件。真正的主角是工程化流水线。2. Skills 在整条链路中的位置如果借用现代 Agent 架构的语言，可以把这套系统看成三层：Skills：负责知识、规则、能力和执行说明如何提供Harness：负责权限、状态、上下文、观测、重试、预算和故障恢复Loop：负责计划、执行、观察、反思和收敛本文重点讨论的是第一层，但生产落地时三层缺一不可。因为需求分析不是一次性回答，而是一个持续收敛过程。四、整体技术架构：一个生产级 AI 需求分析引擎应该长什么样先看整体架构。