需求分析到详细设计有感
在 AI 辅助开发越来越普及的今天，Cursor 这类工具已经可以实现： 需求 → 详细设计 → 代码 的一键生成。
但实际工作中，我们经常遇到一个问题： 直接把原始需求丢给模型，生成的详设逻辑混乱、接口乱编、数据来源凭空捏造，最后代码根本无法使用，甚至越写越偏，出现“上下文中毒”，导致一错全错。
问题根本不在 AI，而在于我们忽略了软件开发最核心的一步：需求分析。
一、什么是真正的需求分析
需求分析，本质就是： 把模糊的想法，变成明确、完整、无歧义的“做什么”说明书。
它要回答三个核心问题：
- 基于当前什么业务痛点？
- 要做什么样的功能？
- 解决什么样的问题？
这份说明书，不能直接丢给模型生成详设。 因为原始需求几乎都是多层语义嵌套，人和人之间沟通都容易理解偏差，更不要指望模型能完全读懂。
二、一个真实业务需求：一句话藏多层含义
以一个典型订单场景为例：
在用户下单进行赠品活动查询时，需要新增用户订单关联了预订单的预定活动信息入参传入。
这句话看上去很正常，但直接丢给 Cursor，基本都会出现：逻辑理解错误、接口乱定义、数据来源瞎编等问题。
我总结了一套5 维度拆分法，拆完之后歧义基本消失：
- 场景：在什么环节生效
- 条件：什么时候执行
- 服务：哪些服务参与、谁调用谁
- 数据来源：从哪里取数（MySQL/ES/Redis/接口）
- 行为：具体要做什么操作
拆分结果
- 场景：用户在下单流程中执行赠品活动查询时生效
- 条件：仅当订单已关联预订单时需要传参
- 服务：由订单服务组装参数，调用赠品活动查询服务
- 数据来源：预定活动信息从 DB 的预订单表及关联活动表获取
- 行为：新增预定活动信息入参，并传入赠品活动查询接口
每条统一理解口径
-
场景 只在下单环节的赠品计算逻辑生效，不影响订单列表、活动中心等其他场景。
-
条件 订单有关联预订单则传参，无关联则不传，不是全局强制逻辑。
-
服务 明确职责：订单服务负责拼装参数，调用赠品服务，避免 AI 凭空编造服务。
-
数据来源 明确从 MySQL 取数，不是 ES、不是缓存、不是前端构造。不定义清楚，AI 很可能自己造一张不存在的表。
-
行为 在赠品查询接口新增入参，不传参数时走默认无活动逻辑，边界清晰。
精简版（可直接写入需求文档）
本需求适用于用户下单过程中的赠品活动查询场景；需在赠品活动查询接口新增入参，仅订单关联预订单时传入；参数为预订单对应的预定活动信息，数据取自数据库预订单相关表；最终将参数传入赠品活动查询接口完成逻辑调用。
三、不拆分直接喂 AI，必踩三大坑
1. 多层语义无法识别，逻辑全靠猜
一句话里包含场景、条件、参数、来源、行为，模型很难完整拆解，必然出现漏条件、错逻辑、扩范围的问题。
2. 服务关系不清晰，凭空编造接口
如果不让 Cursor 看到项目结构，不明确服务之间的调用关系，AI 会自创服务、自创接口，一旦开头错误，后续全线上下文中毒。
3. 数据来源不定义，自己造表造字段
不说明是 MySQL、ES 还是 Redis，不说明具体表名，AI 就会按想象生成一堆现实中不存在的表结构，代码完全无法对接真实业务。
四、AI 辅助开发的正确姿势：先拆分，再生成
想要让 Cursor 真正好用，必须做好三步转化：
1. 语义拆分
把复合需求，拆成单一语义、无歧义、可验收的细粒度需求。业务理解必须由人完成，工具无法替代。
2. 服务编排
明确哪些服务需要修改、谁调用谁、接口结构。把项目加入 Cursor 工作空间，让模型基于现有架构扩展，而不是凭空创造。
3. 数据溯源
明确数据来源：MySQL、ES、Redis 或第三方接口，并指定具体表名、字段名，必要时贴表结构，杜绝 AI 自由发挥。
五、总结
很多人有一个误区： 觉得 AI 强大到可以替代需求分析。
现实是： 真实业务需求往往层级复杂、依赖多、逻辑交叉，一句话可能隐藏多层语义，服务之间的调用关系高度业务化。
不做拆分、不做转化、不做定义，直接丢给模型生成详设和代码，绝大多数结果都是无效产出，返工成本比手写更高。
正确路径永远是： 原始需求 → 精细化拆分 → 清晰化描述 → AI 生成详设/代码
AI 是效率放大器，不是替代者。 需求分析做得越稳，AI 产出的内容越可用。 以上都是个人工作总结，比较粗糙，如有错误，可以指正下哈
标签
Cursor、AI编程、需求分析、后端开发、软件开发、效率提升
