怎样建立稳定、可追踪的产品事实
范米花儿
三栖 Designer
👋 嗨，我是范米花儿。上一篇介绍了 Mihua Design 的整体生成系统。
这一篇从一次具体的需求修改开始，看看页面、流程、数据、代码和验证为什么需要一起变化，以及多次对话后为什么会产生漂移。
一、一句话的需求，为什么会影响整个产品？
AI 第一次生成产品时，需求、页面、流程和代码围绕同一个提示，很容易保持一致。真正的问题通常出现在第二次修改。
原来的需求
将线索转化为客户。
后来需求改成
线索转化成功后，创建或复用已有客户，并可选择是否创建商机。
对提出需求的人来说，只增加了半句话；对产品来说，重复客户检查、客户复用、创建商机选项、权限、完成跳转、列表刷新、失败处理和测试结果都需要一起变化。
只要一个环节仍按旧需求运行，页面可能看起来正确，最终数据却已经和需求不一致。这就是“产品事实漂移”：同一条需求在 PRD、页面、流程、代码和测试中逐渐变成几个相近却不同的版本。
二、真正失控的原因：不同地方记住了不同版本
需求改变以后，所有环节都要收到同一份新规则。只要有人仍拿着旧版本继续工作，局部看起来合理，整体结果就会互相矛盾。
- 页面增加了“创建商机”，却没有重复客户检查。
- 跨页流程仍默认每次创建新客户，复用规则没有真正发生。
- 客户已经更新，商机漏斗仍保留旧数据。
- 商机创建失败，客户创建已经成功，系统停在完成一半的状态。
- 测试只看成功提示，没有核对真实数据结果。
事实漂移通常不会让页面立刻崩溃。问题藏在页面之间、数据之间和下一次操作里。
三、让所有环节共享同一份产品规则
解决事实漂移，第一步是明确每一种信息由谁负责。
- PRD 负责业务背景、判断条件和失败处理。
- 页面约定负责用户要在这一页完成什么、哪个操作最重要。
- 流程约定负责页面之间怎样接力、完成后更新哪些数据。
- 代码和测试负责让规则真实发生，并留下验证结果。
在 Mihua Design 中，页面约定和流程约定统称为 Contract。可以把它理解成一份机器能够稳定读取的产品约定清单。
页面约定：这一页要完成什么
它记录主要任务、主要操作、业务对象和状态变化，在工程文件中对应 _product.yaml。
流程约定：操作之后发生什么
它记录先查重、创建或复用客户、可选创建商机，以及刷新列表和漏斗的完整接力，在工程文件中对应 _flows.yaml。
按钮颜色、间距、Tab 展开等局部细节继续由页面实现处理，不会全部塞进 Contract。
四、系统怎样自动检查有没有漏改？
Contract 写完以后，系统会把分散在页面与流程约定里的规则整理成一张统一关系表，称为 ProductContractIR。团队无需直接编辑它。
- 确认页面属于哪一条业务流程。
- 确认关键操作是否有对应的代码实现。
- 在需求变化后找到受影响的页面与流程。
- 确认实现完成后是否留下真实运行证据。
按钮名称和位置可以变化，只要业务含义不变，稳定 ID 就能让页面、流程、代码和测试继续指向同一个操作。Contract 保存关键产品决定，ProductContractIR 把这些决定连接起来。
五、需求再次变化时，团队会发生什么改变？
假设业务新增规则：普通线索可以自行选择是否创建商机，企业级线索在转化成功后必须创建商机。修改过程可以沿三步进行。
- 先在 Contract 中更新“什么情况下必须创建商机”，让新规则拥有唯一来源。
- 由 ProductContractIR 找到转化页面、流程步骤、关键操作、数据更新和相关验证。
- 代码完成修改后，再用浏览器确认客户、商机、列表和漏斗是否遵守新规则。
团队仍然需要做产品判断、开发和测试。变化的是协作方式：大家围绕同一版产品规则工作，系统负责连接规则并提醒哪些对象需要一起更新。
技术补充｜Mihua Design 在系统内部怎样实现
Contract 的真实文件
| 文件 | 职责 |
|---|---|
| _product.yaml | 产品与页面集合、页级任务、业务对象、状态、核心 Block 与高信号交互 |
| _flows.yaml | 跨页入口、稳定步骤、完成落点、业务副作用与 interaction ID |
| sample-pack.json | 编辑、替换与往返验证使用的一致领域样例值 |
| TSX / store | 承载可运行页面、命令、状态与数据投影 |
ProductContractIR 的编译链
PRD → Contract v3 → Contract Loader → Contract Compiler → ProductContractIR → 页面实现与静态检查 → Runtime Evidence → VerificationRun
稳定 ID 怎样连接实现
关键业务操作使用稳定 ID；流程通过 interaction_ids 引用，代码实现与运行证据也沿同一个 ID 对账。系统因此可以区分“文案变化”和“业务操作变化”。
验证怎样证明实现完整
- 静态证据检查契约对象是否连接到页面 Block、交互绑定和 store command。
- 运行时证据检查浏览器操作是否真的改变状态、跳转页面并同步相关数据。
最终形成一条可追踪、可核销的链路：需求 → Contract → ProductContractIR → 页面与代码 → 运行证据。