这是「华为云码道实战」系列的第八篇。前七篇走了成长攻略、AI 智能体观点、安全审计、性能优化、容器化 CI/CD、数据分析、技术债盘点。这一篇回到一切代码的起点——需求。

场景太常见了：产品经理走过来，口头说了句"做个积分商城，用户能攒积分换东西"，然后说"你先出个方案"。你直接上手写代码？还是先问清楚？这次我把这句模糊需求丢给华为云码道的需求分析专家，让它做一次结构化拆解——结果挖出 25 个模糊点、27 个用户故事、27 项待确认。

一、那句"说清楚了"的需求

产品经理的原话是这样的：

"我们要做一个积分商城。用户在咱们平台消费能攒积分，积分能在商城里换商品或优惠券。要支持积分过期、限时兑换、库存管理。后台要能配商品、看兑换记录。大概这些，你先出个方案。

对了，优惠券兑换后要能直接在下次下单时用，实物商品要填收货地址。积分不够的时候给个提示就行。先做 H5，后面再上小程序。"

听起来是不是挺清楚的？有场景、有功能、有端、有优先级。很多开发拿到这段话，可能就开始建表写接口了。

但这段话里至少藏着 25 个没说清的地方——每一个都可能在开发到一半时变成"等等，这个到底怎么做？"

二、把需求交给需求分析专家

我没有自己逐条列问题，而是调用了华为云码道的需求分析专家（requirement-analysis）子智能体。给它这段原始需求，让它拆成结构化规格说明书。

它自己完成了全部工作：识别模糊点 → 拆用户故事 → 写验收标准 → 明确业务规则 → 草拟数据模型和接口 → 列待确认清单。最终产出一份 666 行、35KB 的需求规格说明书。下面每一个数字都是它真实拆出来的。

三、第一步：25 个模糊点，你想到几个？

需求分析专家从那段 100 来字的需求里，识别出 25 个模糊点/遗漏点，分成 6 组：

挑几个最关键的解读：

Q01｜积分获取比例未定义

"消费能攒积分"——1 元 = 1 积分？10 元 = 1 积分？比例不同直接决定商品定价体系和营销成本，是整个商城的"汇率基准"。

Q04｜积分入账时机未定义

下单即入账？支付完成入账？确认收货入账？时机不同直接影响退款纠纷与薅羊毛风险。如果下单就入账，用户可以疯狂下单攒积分再退款。

Q13｜并发防超卖机制未定义

100 个人同时兑换只剩 1 件库存的商品，谁成功？这是技术方案选型的前提——用行锁、乐观锁、还是分布式锁？需求不说，开发就得自己猜，猜错了上线翻车。

Q25｜风控与防刷机制

积分体系是薅羊毛重灾区。原始需求完全没提风控——但无风控上线即风险。

一个直觉：25 个模糊点里，大部分不是"产品经理忘了说"，而是"他默认你懂"。 但"默认你懂"的东西，恰恰是最容易出分歧的。

四、第二步：27 个用户故事，三个角色

需求分析专家把功能拆成了 27 个用户故事，每个都带了 Given-When-Then 验收标准：

举一个用户故事的验收标准例子：

US-U03｜用户兑换实物商品
Given: 用户登录且积分余额 ≥ 商品所需积分且商品有库存
When:  用户提交兑换请求（含收货地址）
Then:  系统原子扣减积分 + 扣减库存 + 创建兑换订单
       返回订单号，状态为"待发货"
       积分明细记录扣减批次与来源

Given: 商品库存为 0
When:  用户提交兑换请求
Then:  返回"库存不足"，不扣减积分

注意"原子扣减"这个词——它对应的是 Q13（并发防超卖）。需求分析专家不只是翻译需求，它把技术约束也写进了验收标准里，这样开发不会漏掉并发控制。

五、第三步：业务规则——把"默认你懂"变成"白纸黑字"

最有价值的部分是业务规则的明确化。原始需求里"支持积分过期"只有六个字，需求分析专家把它展开成了一套完整规则：

积分过期规则 - 粒度：按批次过期（每笔积分独立计有效期），非账户统一过期 - 周期：默认 24 个月【待确认】 - 消耗优先级：FIFO，优先消耗先过期的批次 - 提醒：过期前 7 天 + 1 天双提醒【待确认】

并发控制规则 - 积分扣减 + 库存扣减 + 订单创建：同一 DB 事务 - 并发请求仅一人成功，其余返回"库存不足" - 积分发放走 MQ + 幂等消费，保证最终一致 - 分布式锁兜底防超卖

这套规则不是凭空造的——每一条都对应前面识别的某个模糊点。25 个模糊点 → 25 条明确规则，这就是"需求澄清"的本质。

六、第四步：数据模型与接口草案

需求分析专家还草拟了技术方案层面的内容：

9 个核心实体： PointAccount（积分账户）、PointLedger（积分明细/批次）、Product（商品）、ExchangeOrder（兑换订单）、ExchangeOrderStatusLog（状态日志）、Address（收货地址）、StockLog（库存流水）、PointRule（积分规则）、Coupon（优惠券，复用现有系统）

27 个 API 端点：C 端 12 个 + B 端 10 个 + 内部 5 个，还给了完整兑换接口的四种响应契约：

POST /api/v1/exchange
├─ 200 成功：{ order_id, status: "pending", points_used }
├─ 402 积分不足：{ error: "POINTS_INSUFFICIENT", needed, balance, gap }
├─ 409 库存不足：{ error: "STOCK_EMPTY" }
└─ 429 限兑超限：{ error: "EXCHANGE_LIMIT_EXCEEDED", limit }

注意"积分不足"的响应里带了 needed、balance、gap——这对应 Q14（积分不足怎么提示）。原始需求说"给个提示就行"，但"就行"到底行什么？需求分析专家把它细化成了"告诉你差多少"，而不是一个干巴巴的"积分不足"。

七、27 项待确认：这才是交付的核心

整份文档最有价值的部分，是末尾的待确认清单——27 项（C01~C27），每一项都是从模糊点推导出来的、需要业务方拍板的问题：

"1 元 = 多少积分？" "积分过期周期是 12 个月还是 24 个月？" "每人限兑是按商品还是按活动？" "实物商品运费谁出？" "后台是否需要审批流？" ……

需求分析专家给了一个很关键的提醒：

"在业务方确认前，本文档不能作为开发基线。"

这句话是整篇博客最重要的一句。它把需求分析的边界划得很清楚——工具能帮你发现问题，但拍板的权力仍在业务方手里。

八、复盘：需求分析专家替我做了什么

回看整个过程，我作为"接需求的人"只做了一件事：把产品经理的原话给它。它自己完成了：

100 字口头需求
    │
    ├─ 识别模糊点     → 25 个，分 6 组，每个指出"哪里模糊"+"为什么必须澄清"
    ├─ 拆用户故事     → 27 个，3 角色，每个带 Given-When-Then
    ├─ 明确业务规则   → 积分获取/过期/兑换/并发，一套完整规则
    ├─ 草拟技术方案   → 9 实体 + 27 API + 响应契约
    └─ 列待确认清单   → 27 项，明确"不能作为开发基线"

这和"让 AI 帮我写份 PRD"有三个本质区别：

最让我意外的是它反向找漏洞的能力。普通 AI 倾向于"顺着你说"，你给个需求它就帮你扩展。但需求分析专家会主动问："积分入账时机你没说"、"并发防超卖你没说"、"风控你没说"——这些恰恰是开发到一半才会爆的问题。

九、哪些地方它还没法替代人

公平起见，也有它做不了的事：

1. 业务方意图确认：它列出 27 项待确认，但"1 元 = 1 积分还是 10 元 = 1 积分"这个决定，取决于公司的营销预算和商品定价策略——这是业务决策，不是分析能解的。
2. 优先级取舍：它标了 P0/P1/P2，但"限时兑换"是 P0 还是 P1，取决于这个商城的战略定位——是拉新工具还是留存工具？这需要产品判断。
3. 跨系统对齐：它说"优惠券复用现有系统"，但现有优惠券系统支不支持积分兑换的券？接口能不能对接？这需要跨团队沟通。

所以准确定位是：需求分析专家是"澄清层"的超级加速器——它把"模糊需求"变成"结构化问题清单"，但"回答这些问题"仍需要人来做。它的价值不是"替你决定"，而是"确保每个决定都被显式做出，而不是被默认掉"。

十、结语

这一篇解决的是一切代码的上游问题：在写第一行代码之前，先搞清楚到底要做什么。

很多项目延期、返工、线上事故，根子不在代码质量，而在需求没澄清——开发按自己的理解做了，上线才发现和产品想的不一样。而"需求澄清"这件事的成本，用华为云码道的需求分析专家，低到——一句话需求 + 一次调用。

系列八篇，从"写代码"一路走到"写代码之前"： 成长 → 观点 → 安全 → 性能 → 部署 → 数据 → 技术债 → 需求。 越往后越是"代码之外"的能力，但这些能力恰恰决定了代码的成败。下一份见。

本文所有拆解结果均由华为云码道需求分析专家（requirement-analysis）对原始口头需求真实执行。完整规格说明书见 /workspace/req-demo/requirement_spec.md（666 行，10 章，27 项待确认）。