040 一页纸设计文档与从需求到设计走查

导读：

   把四个视角按业务、用户、风险、技术的顺序走一遍，技术选型的争议会自然消失大半。本文以门店补货场景完整演示这条设计路径。

1.从需求开始

   用一个贯穿案例走一遍设计流程。需求场景是门店补货：门店店长每周花四小时做补货计划，错补导致缺货与积压并存。

   先走业务视角：痛点是“算得慢”加“判不准”；成功指标定为“补货建议采纳率不低于70%，缺货率下降”。注意指标里没有“自动化率”——业务要的是结果，不是形态。这一点是设计走查中最容易出错的地方：把“智能体替人做了多少”当成目标，会让团队在错误的维度上优化。

2.用户与风险两个视角

   用户视角：店长在门店平板上使用，凌晨排班前后各看一次；输出必须是“建议+理由+一键采纳或调整”，理由栏不可省略。没有理由的建议，在门店端的信任度为零——店长不会因为系统说了就照做，他需要知道为什么。

   这个约束看起来是体验设计，实际上是采纳率的必要条件。用户视角的产出不是“界面好看”，而是“什么形态才可能被真正用起来”。

   风险视角：建议错误的最坏后果是单店库存积压，可逆且有界，因此风险等级为中等偏低；红线是“不得直接下单”，执行权永远在店长手上。兜底方案是建议失败时回退到原有的经验补货流程。

   风险视角的产出是两样东西：权限边界与人工介入点。前者决定智能体“能做什么”，后者决定人“何时必须出现”。这两样一旦缺位，前面所有关于体验与指标的讨论都建立在没有护栏的基础上。

3.技术视角最后登场

   技术视角安排在最后，此时它要回答的问题已经被前三方约束得很窄。数据依赖限定为销售时序、活动日历与物流时效这一最小可行集；编排采用混合模式，即数据组装（确定性）→生成建议（模型）→规则校验（确定性）；人工介入点则是一键确认，本质上就是事前审批。

   走查的价值在于顺序。四个视角各答各的，最后技术视角只剩“怎么实现已被业务、用户、风险三方约束过的方案”。技术选型争议在好的设计流程里会自然消失大半，因为约束已经把可行域夹得很窄。

   反过来说，凡是技术选型争论长期无解的团队，往往不是技术问题，而是前面的三个视角没有给出足够的约束。

4.收束成纪律

   把这次走查收成四条可复用的纪律：六项核心功能缺一不可，后四项应作为发布闸门而非二期工作；设计顺序固定为业务、用户、风险、技术，技术先行必然导致场景迁就技术；失败定义分两档，可容忍迭代的与出现即事故的分开处理；低代码定位为业务专家的最后一公里工具，核心流程验证成熟后固化回代码。

5.要点小结

   走查的核心价值在于顺序，业务定指标、用户定形态、风险定边界之后，技术视角的可行域已被夹窄，选型争议自然减少；指标应指向业务结果而非自动化形态；风险视角必须明确红线与回退路径，执行权始终保留在人手上。

下一篇：模型、提示、链与记忆的设计。