螺旋模型：先验证关键风险
螺旋模型用风险决定下一轮工作。每轮先明确目标、备选方案和约束，再识别并降低主要风险，随后开发和验证下一层成果，最后决定继续、调整或终止。它不是把需求、设计、编码机械重复几遍，也不要求每轮都增加功能。
例如订单导出需要处理百万级记录，但团队不知道直接查询主库是否会拖慢支付请求。最先做的应是带负载约束的技术试验。如果风险不能接受，继续完善按钮和业务代码也不能弥补方案缺陷。
一轮风险验证怎样组织
目标可以是“导出期间在线查询延迟保持在业务约定范围内”。备选方案包括主库限流读取、只读副本或专用数据快照。约束要写清数据一致性要求、可用资源和交付时间，否则性能更好的方案可能根本不满足业务。
技术试验应覆盖能推翻方案的条件。空库导出成功不能回答真实规模下的内存和查询压力；只测单个请求，不能回答并发任务是否挤占在线资源。报告需要记录输入规模、并发、环境、测量口径和失败现象。
| 本轮风险 | 验证动作 | 可用于决策的产物 |
|---|---|---|
| 全量加载导致内存耗尽 | 对比全量加载与分批读取 | 峰值内存、耗时、资源上限和日志 |
| 导出拖慢在线交易 | 在代表性混合负载下测在线延迟 | 在线延迟、数据库负载、任务吞吐 |
| 重试产生重复文件或错误状态 | 中断 Worker，再恢复任务 | 状态、文件标识、幂等和恢复证据 |
| 快照无法满足对账时效 | 比较快照时间与业务要求 | 可接受延迟和完整性结论 |
原型、试验和产品的区别
交互原型回答“用户是否需要、是否会用”，技术试验回答“方案是否可行、边界在哪里”，产品增量回答“某项能力是否已经可交付”。三者可以使用类似代码，但完成定义不同。
性能试验中的临时数据和单机配置不应直接带入生产。保留的是结论、测量方法和可复现实验；试验代码是否保留，应评估维护成本和安全。螺旋开发并不保证所有原型都会逐步变成最终产品。
风险决定下一轮
如果分批读取通过资源检查，但下载鉴权尚未验证，下一轮就优先处理下载越权；如果所有方案都超过资源预算，需要缩小范围、调整目标或停止投入。风险记录必须影响计划，否则它只是附加文档。
AI 可以比较方案、生成负载脚本和分析日志，但“可能更快”的解释不属于性能证据。Agent 执行试验前，应明确允许使用的环境、资源上限和停止条件；影响真实业务的负载操作必须按环境授权执行。
常见失败与验收
风险写成“技术难度高”无法指导实验。应改成可被证伪的假设，例如“分批读取在目标数据规模下不会超过约定内存上限”。只列概率和影响、没有验证动作，也不能减少不确定性。
每轮结束检查：最高优先级风险是否有新证据，证据能否复现，结论是否改变方案，剩余风险是否阻止交付。目标清楚、低风险的小改动无需套完整螺旋流程；设备适配、性能、迁移和复杂外部集成通常值得先验证风险。