第2章 业务需求与技术映射：从用户故事到技术能力分解、关键假设识别
2.1 边界：用户故事与技术需求的界限
用户故事描述“谁需要什么、为什么”，技术需求描述“系统做什么、怎么做”。两者之间的边界决定了可行性分析的入口和出口。
| 维度 | 用户故事 | 技术需求 |
|---|---|---|
| 主语 | 角色（客服主管、终端用户） | 系统组件（推理服务、数据管道） |
| 谓语 | 业务动作（分类、分配、查询） | 技术能力（推理、路由、存储） |
| 度量 | 业务价值（减少80%人工分流） | 技术指标（延迟≤500ms、准确率≥85%） |
| 约束 | 业务规则（按优先级分配） | 非功能约束（吞吐量、可用性、合规） |
| 生命周期 | 迭代中持续刷新 | 架构基线冻结后变更驱动 |
界限转换的核心理念：用户故事是“锚点”，技术需求是“锚链”——锚点决定方向，锚链决定能否泊岸。
2.2 分层映射：从业务语言到技术能力
以典型场景“智能工单分类系统”为例：
- 用户故事：作为客服主管，我希望系统自动分类用户问题并分配至对应处理组，以便减少80%人工分流工作量。
- 业务需求：实时分类、路由至对应组、支持反馈闭环。
- 功能需求：NLP分类、队列路由、结果可干预。
- 技术能力：推理服务、特征管道、监控告警、安全控制。
分层映射的关键是将“业务动词”翻译为“技术能力原子”，并在每一层做可量化分解。
2.3 组件职责：技术能力单元的定义
每个技术能力组件需明确输入、处理、输出及依赖假设：
| 组件 | 职责 | 关键假设 |
|---|---|---|
| 推理服务引擎 | 加载模型，接收请求，返回分类/路由结果 | 单次推理延迟 ≤ 200ms；模型准确率 ≥ 85% |
| 数据特征管道 | 实时抽取文本特征，更新特征库，保障特征一致性 | 特征延迟 ≤ 100ms；特征覆盖率 ≥ 99% |
| 监控可观测性 | 采集延迟、吞吐、错误率，触发告警，提供诊断视图 | 监控数据丢失率 ≤ 0.1%；告警响应 ≤ 5min |
| 安全合规控制 | 鉴权、数据脱敏、审计日志、敏感内容过滤 | 脱敏覆盖率 100%；审计日志不可篡改 |
2.4 数据流 / 控制流 / 信任链路
三者共同定义了系统运行时行为与安全基线：
- 数据流：用户问题 → 特征管道 → 推理引擎 → 路由分发 → 处理组。关键约束：特征与推理在同一边界内完成，避免跨域传输原始文本。
- 控制流：配置中心下发模型版本号 → 推理引擎热加载 → 灰度验证 → 全量上线。失败时自动回滚至上一版本。
- 信任链路：API 网关签发 JWT → 推理引擎验证 Token → 特征管道校验用户权限 → 审计日志记录完整链路。任何节点鉴权失败立即拒绝请求。
信任链路设计原则：“永远不信任上游，始终验证下游”。即使在内网，每个技术组件之间的调用都必须携带身份凭证。
2.5 选型权衡
技术能力分解后，每个组件都面临选型决策。以推理服务引擎为例：
| 方案 | 延迟 | 吞吐 | 冷启动 | 运维成本 | 适用场景 |
|---|---|---|---|---|---|
| Triton Inference Server | 低（~5ms 附加） | 高（动态批处理） | 快（秒级） | 中 | GPU 集群，多模型混合部署 |
| ONNX Runtime | 低（~3ms 附加） | 中 | 快（毫秒级） | 低 | CPU/边缘端，单模型轻量推理 |
| TorchServe | 中（~10ms 附加） | 中 | 慢（分钟级） | 中 | PyTorch 生态，快速实验转生产 |
| 自定义 gRPC 服务 | 最低（~1ms） | 可弹性扩展 | 取决于实现 | 高 | 极致延迟要求，团队具备基础架构能力 |
选型决策模板示例：
# 推理服务选型 checklist (YAML)
inference_engine:
candidate: triton # onnx | torchserve | custom
rationale: "需要同时部署BERT和GPT模型，动态批处理可提升吞吐"
risk: "Triton依赖CUDA版本，与训练环境对齐需额外验证"
assumption: "GPU显存 ≥ 16GB，模型量化后精度损失 ≤ 0.5%"2.6 风险点
从用户故事到技术能力分解的四个典型风险：
- 假设沉默失效：关键假设（如准确率≥85%）未被显式记录，上线后实际值仅82%，导致业务拒绝采用。
- 映射鸿沟：用户故事中的“自动分类”被直接等价于“调用分类API”，忽略了上下文窗口、长尾分类等边界情况。
- 组件职责重叠：特征管道和推理引擎同时实现文本预处理，导致重复计算且版本不一致。
- 信任链路断裂：内网环境中省略了组件间鉴权，一旦某个节点被攻破，整个数据流暴露。
风险最大的不是技术难题，而是“未被识别的假设”。每个技术能力组件必须携带至少一条可测量的关键假设，并在架构评审中逐条通过。
2.7 落地步骤
将用户故事分解为可落地的技术能力，建议遵循6步流程：
- Step 1 故事解析：提取角色、功能、价值、非功能约束。
- Step 2 技术词汇翻译：将业务动词映射为技术原子（分类→推理+路由）。
- Step 3 能力分组：按推理、数据、监控、安全四个域划分组件边界。
- Step 4 接口契约定义：每个组件暴露gRPC/HTTP接口，明确输入输出Schema。
- Step 5 假设清单建立：每条技术能力附带可测试的关键假设与验收阈值。
- Step 6 风险回检：识别假设之间的依赖冲突，标记高优先级风险。
2.8 验收标准
本章交付物是否合格，以下验收清单缺一不可：
| # | 验收项 | 通过条件 |
|---|---|---|
| 1 | 用户故事→技术能力映射表 | 每个用户故事至少对应4个技术组件，且组件职责无重叠 |
| 2 | 关键假设清单 | 每条假设包含指标、阈值、测试方法，数量≥用户故事数×2 |
| 3 | 数据流/控制流/信任链路图 | 三张图覆盖所有组件交互，信任链路标明鉴权方式 |
| 4 | 选型决策记录 | 每个技术组件至少对比3个候选方案，并记录选定理由与风险 |
| 5 | 风险登记册 | 至少识别5条风险，每条有概率/影响评级与缓解措施 |
验收不是终点，而是基线。所有验收文档进入架构库，后续每次迭代变更时重新检视假设是否仍然成立。
2.9 关键假设识别：架构的“压力测试”
关键假设是连接业务预期与技术实现的脆弱桥梁。识别假设的核心方法：
- 正向推导：如果某技术组件完全失效，业务价值还能实现吗？
- 反向追问：要实现这个业务价值，技术组件必须满足什么条件？
- 极限压测：当流量达到峰值的3倍、数据延迟增加10倍、模型准确率下降5%时，系统行为是否仍可接受？
假设分类管理矩阵：
| 类别 | 示例 | 验证方式 | 失效影响 |
|---|---|---|---|
| 性能假设 | 推理P99 ≤ 500ms | 压测 + 持续监控 | 工单分配超时，人工介入 |
| 质量假设 | 分类准确率 ≥ 85% | 离线评估 + 线上A/B | 错误路由，客户投诉 |
| 容量假设 | 日均处理量 ≥ 10万 | 容量规划 + 弹性测试 | 队列积压，SLA违约 |
| 安全假设 | 脱敏覆盖率 = 100% | 安全审计 + 渗透测试 | 数据泄露，合规处罚 |
| 依赖假设 | 第三方NLP API可用性 ≥ 99.9% | 熔断测试 + 降级演练 | 核心功能不可用 |
每一条关键假设必须对应一个可观测的指标和一个明确的失效阈值，并在架构文档中单独成节。假设不是挂在墙上的装饰，而是上线后每一次告警的比对基准。