docs: distinguish commercial validation stages

Separate paid problem validation, software contribution, repeat sales, and resilience to upstream changes so service revenue does not imply software demand.

Validation: git diff --check -- docs/product-iteration-plan.md passed; documentation-only change.

docs/product-iteration-plan.md

@@ -10,6 +10,17 @@
 
 收费试点与可靠性改善可以并行。人工包办的成功不算软件成功；后续代码修改须另行确认，本计划不代表授权实施。
 
+**商业验证的判断顺序（2026-09-09 讨论补充）。** 以下是基于现有研究的实验设计，没有新增访谈、付款或产品效果数据。技术开发的授权与完成状态以实际任务和版本记录为准。
+
+| 需要验证的判断 | 最小可检查证据 | 证据不足时的选择 |
+| --- | --- | --- |
+| 问题值得付费解决 | 最近一次真实任务的人工成本、明确预算人，以及固定范围试点的实际付款 | 调整客户或问题，不凭公开 issue 数量扩大开发 |
+| Meldwork 软件有独立贡献 | 同质量对照下，相对客户惯用的原生 Agent 加文件/Git，减少恢复、交接或复核的人工分钟；单列创始人补位 | 保留有收益的工具能力，服务收入继续按服务评价 |
+| 软件可以重复销售 | 客户在下一次真实任务中自行使用，并为明确的软件权益再次付款；计入支持工时后贡献为正 | 改进上手和支持成本，或维持服务模式 |
+| 优势能承受上游变化 | 更换或升级 Agent 后，重复比较仍有净收益；客户认可的验收方法能改善后续任务 | 缩小收费范围或调整定位，不把兼容数量和记录量当作壁垒 |
+
+前三项决定近期是否值得扩大投入；第四项需要持续观察，不能由一次演示证明。访谈数量、案例数量和复购门槛用于控制投入，不能替代上述证据。
+
 ## 2. 前两周 选择客户问题
 
 A 组：5 位需复核 AI 产出的技术负责人或研发服务者。B 组：5 位反复交付技术选型/产品方案的专业服务者。人数是招募目标，不是显著性要求。