BUYER GUIDE / 选型指南
一个完成95%的系统， 为什么可能不如连续运行30天的首期版本？
功能完成比例描述的是清单，不是业务结果。范围更小但能在真实环境持续运行、留下异常与使用证据的首期版本，通常更能支持下一步投资决策。
FIELD NOTES / 专业文章
先看判断依据，再把方法带回真实项目。
完成率容易制造错误安全感
项目汇报中的“完成95%”通常来自功能项计数，但每个功能的业务权重并不相同。登录页、列表页和多个报表都已完成，也不能弥补核心接口、结算规则或异常恢复尚不可用。
更危险的是，完成率很少说明功能是否在真实权限、真实数据和真实并发下工作。它适合描述开发进度，却不应单独承担上线和付款决策。
可运行首期版本提供不同类型的证据
首期版本应让一组真实角色完成一条完整业务任务，并覆盖最关键的异常。上线后可以观察进入量、完成量、失败原因、人工介入、处理时长和用户反馈，这些证据会直接改变后续优先级。
连续运行的价值不在于追求零问题，而在于让问题可见、可归类、可恢复。团队因此能够区分产品假设错误、业务规则遗漏、培训不足、数据质量问题和技术缺陷。
为什么用30天作例子， 而不是硬性标准
对每天发生的高频流程，数周可能足以覆盖多轮运行；对月结、学期或季节性业务，则需要更长窗口。本文使用30天只是为了强调“持续运行”与“静态完成比例”的差异，不构成统一验收或质保承诺。
观察期应提前写明业务频率、样本范围、不可接受风险、暂停条件和复盘时间。关键流程还需要灰度、回退和人工兜底，不能为了积累数据放任风险扩大。
从运行证据决定下一期
复盘时先问首期目标是否发生：任务是否完成得更快、更稳或更可追踪；再看哪些异常值得产品化解决，哪些只是偶发操作问题。只有真实出现且影响明确的需求，才优先进入下一期。
这种从小闭环到持续迭代的路径，也符合工信部“小快轻准”、由点及面和长期迭代的实施方向。范围不是越多越好，而是每次投入都能形成可观察结果。
PRIMARY SOURCES / 原始来源
引用公开原始资料， 并保留适用边界。
SCOPE / 项目范围
先看这类项目通常包含什么。
- 0195%不代表关键链路可用
剩余5%可能恰好是支付、接口、权限或异常处理。
- 02运行会暴露真实约束
真实用户、数据、网络和组织协作会揭示测试环境看不到的问题。
- 0330天是示例窗口
观察期应按业务频率和风险设置，不是所有项目的统一验收标准。
- 04用证据决定二期
根据使用、失败、人工兜底和业务结果决定扩展，而不是按原清单惯性投入。
DECISIONS / 关键判断
开始开发前，先把这些问题回答清楚。
定义一条必须跑通的任务
说明角色、前置数据、步骤、结果与关键异常。
设置观察与回退机制
确定指标、记录方式、人工兜底和暂停条件。
按证据排二期
优先处理高频阻断和真实业务损失，不按最初愿望清单机械推进。
BOUNDARY / 项目说明
运行时间不能替代质量与安全门槛。
FAQ / 常见问题
从验收到运行观察的两个问题
01
首期上线还有问题，是否代表验收失败？
要看问题等级和约定范围。阻断核心任务或影响结果的问题必须关闭；不影响上线的遗留项应记录责任和期限。
02
运行数据少还能判断吗？
低频业务应延长观察期或补充场景演练，不能用少量偶然样本得出稳定结论。
NEXT / 继续了解
从相关服务、案例或资料继续判断。
PROJECT CONTEXT / 项目沟通
问题已明确，直接讨论首期范围。
不用先整理完整需求文档，说明当前做法、使用角色、预算与首期目标即可。