四个入口
加场景、加语言、接生产系统、补权限体系，这四类要求都会以顺便的名义出现。每项单独看都合理，叠加后原型变成半成品系统，验证结论反而更难产出，排期也会随之失控，审核时也很难向管理层解释。
规则一：一个假设
每轮原型只验证一个假设，并写进任务定义。新假设记入下一轮候选，不并入本轮。假设单一，评测维度才能收敛，团队也能判断结果到底说明了什么，业务方也能看到边界在哪里，不会反复追问，也不再追问。
规则二：迭代上限
预设提示词与流程的调优轮次上限，例如三轮。超过上限仍不达标，说明方向或数据有问题，应停下来复盘，而不是继续微调，把问题拖成沉没成本，也能避免团队陷入无休止的调参循环，士气被耗尽。
规则三：候选池与变更单
新增需求进候选池，确需纳入的走变更单重排里程碑。把加功能变成有成本的动作，扩张自然减少，团队也不必靠人情去拒绝业务方的临时想法，变更单也成了双方重新对齐预期的机会，而不是对抗。
停止判断
当新增需求不影响本轮验证假设时，一律不进；当它改变假设时，应结束本轮、另立一轮，而不是在原轮次上叠加。这条判断要提前和业务方对齐，否则每轮都会重新讨论范围，时间耗在会议而不是验证上。
适用与不适用
适合谁
- 原型阶段被不断加需求的团队，有加需求压力
- 业务方期望值高、需要管理预期的项目
- 多轮验证并行、需要控制资源的企业
不适合谁
- 范围本就极小、一轮即可完成验证的场合
- 客户方已明确接受原型转生产的情形
典型场景
某零售企业的商品文案原型在第二周被要求支持多语言与批量导入。项目组把两项记入候选池，只保留中文单条生成；第三周盲测通过后，多语言作为独立一轮立项，反而推进得更快，也没有拖累原定窗口，团队也保住了节奏。
可执行步骤
- 在任务定义中写明本轮唯一假设与不做的事情，并请业务方书面确认，留档
- 设定调优轮次上限与对应的停止规则，写进任务定义，双方各留一份，避免遗漏
- 新增需求一律先入候选池，标注提出人与影响面，当轮一律不展开讨论，只记不改
- 确需纳入时走变更单，并重排里程碑与资源，由双方签字确认后再执行，再报计划
- 结束时输出候选池与下一轮建议顺序，并附上建议的处理时点与责任人
常见坑
- 为了配合业务，边做边加，四周拖成十周，结论还没出来，预算也见了底，最后只能靠砍范围收场，工期也拖长。
- 无限调优提示词，把方法与数据问题当成参数问题，越调越偏，最后没人敢叫停，项目陷入停滞，团队也很挫败。
- 原型顺手接了生产库，安全与运维责任随之而来，收尾困难，评审时被反复追问，安全评审也很难通过。
- 没有候选池，访谈与评审中的好想法全部丢失，下一轮立项时又得从头梳理，团队也很挫败，热情也被消磨。
自检与验收清单
- 本轮假设是否只有一条并已书面，且有版本号，可查证
- 调优轮次上限是否提前约定，并写进任务定义，可对照
- 候选池是否有人维护并定期清理，每周清理一次
- 变更是否书面重排里程碑，并留存书面变更记录
- 结束时是否给出下一轮建议，并附建议处理时点
常见问题
业务方坚持要加功能怎么办？
把新增项换算成对交付时间的影响，让对方选择延期或下一轮。用排期而不是立场来沟通，通常能达成一致，也能留下书面记录，后续推进更顺畅，验收也更清楚，减少来回沟通。
原型做得好，能不能直接上线？
不建议。原型通常缺少权限、审计、异常处理与运维设计，直接上线会把这些缺口带进生产，后期整改成本更高，也难通过安全评审这一关，这一点最好在立项会上说明，也能减少争议。
范围冻结会不会影响迭代？
冻结的是本轮验证边界，不是产品路线。候选池照常记录，下一轮立项时优先级更清楚，反而比一边做一边改更容易排期，也更容易向管理层交代投入产出，评审时也更有底气。