从一次生成走向可追踪、可执行、可验证的完整产品生产线关于这个系列的表达方式过去介绍 Mihua Design 时我们更常展示结果并把复杂结构压缩成便于快速理解的概念。随着系统进入产品建模、生成执行和质量验证过度简化也会让真正决定结果的部分消失。接下来的系列会保留必要的专业细节再通过真实产品、代码和运行证据逐层解释。内容会比单纯看页面更有阅读成本也会更接近这套工具真实解决的问题。今天的 AI 已经可以一次生成多页面应用。真正值得继续解决的问题是如何让需求、页面、流程、代码和验收始终指向同一套产品事实并让每次生成都能被检查、修复和继续开发。过去一年AI 写前端的能力变化很快。给它一份 PRD、一个组件库和一些项目规则它可以搭出导航、列表、详情、表单、弹窗甚至一次生成一套结构完整的后台系统。把问题概括成“AI 只能生成单页”已经不符合今天的真实能力。新的问题出现在更深一层这套应用的二十张页面是否共享同一批业务对象一次操作能否稳定改变正确的状态跨页结果能否同步出现在列表、详情、指标和审计记录中生成过程能否复现交付之前有没有证据证明核心流程已经跑通页面数量已经很难衡量产品生成能力。更有价值的衡量方式是整套系统能否沿着同一份产品事实生成并通过同一套证据完成验收。AI 的能力基线已经变了界面能力多页面、复杂布局、组件组合、响应式和视觉还原已经越来越成熟。工程能力路由、状态、数据模型、测试与构建也可以在一次任务中共同生成。Agent 能力模型可以读项目、运行命令、修复错误并在较长任务里连续工作。因此Mihua Design 想解决的重点已经向前移动。我们关心一套产品如何从 PRD 进入稳定的产品模型模型如何被编译成每张页面真正需要的生成上下文代码生成后如何核对组件来源、业务副作用和跨页流程最后怎样留下可复查的运行证据。一个完整的产品生成系统需要同时管理“生成什么、依据什么生成、怎样生成、怎样证明已经完成”。单次生成很强系统仍然需要稳定的控制面同一个 PRD可以被不同模型生成出多套看起来合理的应用。每套结果都可能具备导航、页面和交互却在业务事实、状态口径和验收标准上产生不同解释。这种差异来自生成过程中的多个决策点决策点AI 需要回答的问题缺少控制时的结果产品事实有哪些角色、对象、状态、权限和异常页面各自解释需求字段和口径逐渐漂移。页面职责当前页面承担什么任务首屏应优先表达什么所有页面趋向相似的信息卡、表格和表单组合。流程关系一次操作会改变哪些对象并影响哪些页面按钮有反馈业务结果只停留在当前页面。组件能力哪些系统组件适合当前任务缺口如何治理组件库存在页面仍混入临时原生实现。完成证据怎样证明流程、视觉、多端和可访问性达标构建成功被当作完成运行质量缺少依据。这也是“产品生成系统”的价值它为这些决策建立稳定的控制面让模型的创造力在明确边界内发挥同时让结果具备可追踪性。一套完整生成体系包含七层连续结构在 Mihua Design 里我们把产品生成组织成一条从需求事实到交付证据的连续链路。层级系统产物解决的问题1. 需求事实PRD、角色、对象、状态、流程、异常和验收标准确认产品需要完成什么。2. 机器契约Contract _product.yaml 与 _flows.yaml把产品事实转成结构化、可校验的源文件。3. 契约编译ProductContractIR 与 trace graph统一页面、Block、流程、交互和验收项之间的引用。4. 页面上下文当前页面的任务、流程、数据、表达方式与组件清单让 AI 在生成一页时只读取相关事实。5. 工程执行示例数据、共享状态、工程骨架、页面代码与路由让页面进入同一套可运行工程。6. 组件治理组件能力筛选、来源追踪和缺口修复让组件库真正成为生成约束和质量资产。7. 质量证据流程、状态、视觉、多视口、可访问性和工程验证用运行结果证明产品可以交付。**这七层共享同一条追踪链。**PRD 中的一个业务目标可以继续追踪到页面职责、核心 Block、流程步骤、代码交互和最终证据。产品事实需要一个明确的权威来源完整体系的起点是明确每类事实由谁拥有。PRD 负责业务目标和验收意图产品契约负责角色、对象、页面、状态与流程页面上下文负责把相关事实编译给当前生成任务工程代码负责实现验证结果负责证明实现与契约一致。事实只定义一次页面名称、路由和职责来自产品契约流程步骤和业务副作用来自流程契约多端主任务来自 surface contract主表达方式来自 presentation contract下游持续引用生成上下文引用契约中的稳定 ID页面实现使用静态 Block 对账核心区域交互绑定回流程 step 与 effect验证报告回填同一条 trace graph这样做的直接收益是产品修改可以沿着引用关系向下传播。新增一个状态、调整一个流程步骤、改变移动端任务时系统知道哪些页面、交互和证据需要重新生成或复核。页面生成仍然重要只是被放进了完整链路产品生成系统不会削弱页面设计。相反它会给页面设计更明确的任务边界。生成“商机列表”时AI 得到的不只是页面名称。它还会得到页面服务的角色、用户要完成的主任务、首屏最重要的信息、主表达形式、关联的业务对象、相关流程步骤、桌面端和移动端的任务差异以及建议优先使用的组件能力。这些输入让页面拥有清晰的业务职责也让模型可以把更多注意力用于信息组织和交互表达。nodescripts/generation-context.mjs\--projectcustomer-operations\--pageopportunity-pipeline\--limit12\--jsonstatus:passpage:opportunity-pipelineprimary_task:推进当前商机到目标阶段并在失败时修复阶段缺口primary_block:pipeline-weighted-summarymobile:experience:alternate-taskprimary_job:识别停滞商机并推进单个商机related_flow:opportunity-stage-and-discount.s01warnings:[]业务流程是检验体系是否成立的最好证据以“线索转客户”为例。用户在线索池中选择一条已核验线索进入转化页完成重复检查再创建或复用客户、联系人和商机。一次完整转化会产生连续结果原线索状态改变客户列表新增或更新记录联系人建立关联可选商机进入商机列表和销售漏斗审计日志记录操作重复提交返回同一结果权限不足或数据冲突时进入明确的异常路径。流程卡线索核验与转客户**角色**销售代表 **入口**线索池中的已核验线索 **终点**客户详情步骤所在页面用户任务交接数据或结果1. 选择线索线索池选择一条已完成核验的线索把leadId交给转化页2. 重复检查线索转化检查企业、联系人和商机的重复关系形成“创建或复用”的处理方案3. 确认转化线索转化创建或复用客户、联系人并按需创建商机写入customerId、opportunityId和后续任务4. 核对结果客户详情确认新建立的联系人、商机和下一步任务流程到达可继续跟进的完成状态**完成条件**客户详情出现正确的联系人、商机和任务关系。**同步结果**原线索变为已转化客户、商机、漏斗与工作台投影更新审计日志记录本次操作重复提交返回同一结果。这里可以同时检查产品事实、页面职责、共享状态、权限、幂等、跨页副作用和运行证据。任何一层断开流程都会暴露问题。验证系统决定“完成”这个词的含义构建成功依然重要它只覆盖工程完整性的一部分。产品交付还需要验证契约追踪、功能正确性、信息结构、交互行为、布局几何、视觉一致性、内容与本地化、可访问性以及工程编辑模型。在 Mihua Design 的验证链路里flow-critical 交互需要真实浏览器证据state-changing 操作需要状态测试视觉证据覆盖 1440×900、1024×768 和 390×844 三个目标视口。连续主区间距、横向溢出、固定元素遮挡和响应式替换也会被实际测量。验证报告既给人阅读也能被机器继续消费。空报告、零扫描和缺失的关键证据会直接失败。生成、检查、修复、再验证由此形成闭环。Mihua Design product verify · customer-operations PASS manifest PASS page-intents PASS flows PASS contract-compile PASS interaction-bindings PASS interaction-coverage PASS project-structure PASS project-ia FAIL component-provenance PASS implementation PASS product-quality WARN editable-coverage Result: FAIL · 11/13 pass · 1 warning · 1 fail 系统阻止把尚未核销的 Dialog 能力当作已完成。这套体系的核心价值把生成变成可持续的工程能力一次惊艳的生成可以展示模型能力。一套稳定的生成体系还要支持需求变更、增量生成、质量回归、组件升级和后续工程迭代。当产品事实、生成上下文和验证证据被组织成连续结构团队可以更清楚地回答这张页面为什么这样设计这个交互对应哪一步业务流程这次需求变更会影响哪些页面和测试页面使用了哪些系统组件哪些实现仍需治理当前版本通过了哪些验证还有哪些门禁未完成这正是 Mihua Design 做得最深的部分组件库、规则、产品契约、生成执行和质量验证共同工作形成一套完整的产品生成基础设施。系列目录连续八篇拆开讲完整生成体系这是“Mihua Design 产品生成系统”系列第 1 篇。八篇文章依次覆盖产品事实、页面上下文、表达与多端、业务流程、组件治理、工程完整性和质量证据。篇次文章核心问题01AI 已经能生成多页面应用为什么还需要一套“产品生成系统”完整体系包含哪些连续层级02从 PRD 到 ProductContractIR怎样建立一份可追踪的产品事实怎样建立权威来源与追踪关系03生成一张页面前系统究竟应该给 AI 什么怎样编译页面级最小上下文04页面形态由什么决定从业务任务到主表达与多端契约页面结构和多端任务怎样被定义05从一次点击到跨页副作用怎样把业务流程写成可执行契约一次操作如何形成业务闭环06组件库怎样真正进入生成系统组件选择、来源和缺口如何治理07生成过程怎样保持工程完整怎样避免半成品进入正式工程08怎样证明 AI 生成的产品可以交付怎样用同源证据定义完成下一篇从 PRD 到 ProductContractIR怎样建立一份可追踪的产品事实最后AI 已经能够生成多页面应用这让我们的目标更清晰继续提高页面生成速度同时建立一套能管理复杂产品事实、跨页流程、工程状态和交付证据的系统。组件库提供可靠能力Rules 提供实现约束产品契约定义事实生成上下文组织任务工程管线保持完整验证系统证明结果。当这些层级共享同一条追踪链AI 生成的成果才真正成为一套可以持续演进的产品工程。这也是我们开发 Mihua Design 的原因。
从一次生成走向可追踪、可执行、可验证的完整产品生产线关于这个系列的表达方式过去介绍 Mihua Design 时我们更常展示结果并把复杂结构压缩成便于快速理解的概念。随着系统进入产品建模、生成执行和质量验证过度简化也会让真正决定结果的部分消失。接下来的系列会保留必要的专业细节再通过真实产品、代码和运行证据逐层解释。内容会比单纯看页面更有阅读成本也会更接近这套工具真实解决的问题。今天的 AI 已经可以一次生成多页面应用。真正值得继续解决的问题是如何让需求、页面、流程、代码和验收始终指向同一套产品事实并让每次生成都能被检查、修复和继续开发。过去一年AI 写前端的能力变化很快。给它一份 PRD、一个组件库和一些项目规则它可以搭出导航、列表、详情、表单、弹窗甚至一次生成一套结构完整的后台系统。把问题概括成“AI 只能生成单页”已经不符合今天的真实能力。新的问题出现在更深一层这套应用的二十张页面是否共享同一批业务对象一次操作能否稳定改变正确的状态跨页结果能否同步出现在列表、详情、指标和审计记录中生成过程能否复现交付之前有没有证据证明核心流程已经跑通页面数量已经很难衡量产品生成能力。更有价值的衡量方式是整套系统能否沿着同一份产品事实生成并通过同一套证据完成验收。AI 的能力基线已经变了界面能力多页面、复杂布局、组件组合、响应式和视觉还原已经越来越成熟。工程能力路由、状态、数据模型、测试与构建也可以在一次任务中共同生成。Agent 能力模型可以读项目、运行命令、修复错误并在较长任务里连续工作。因此Mihua Design 想解决的重点已经向前移动。我们关心一套产品如何从 PRD 进入稳定的产品模型模型如何被编译成每张页面真正需要的生成上下文代码生成后如何核对组件来源、业务副作用和跨页流程最后怎样留下可复查的运行证据。一个完整的产品生成系统需要同时管理“生成什么、依据什么生成、怎样生成、怎样证明已经完成”。单次生成很强系统仍然需要稳定的控制面同一个 PRD可以被不同模型生成出多套看起来合理的应用。每套结果都可能具备导航、页面和交互却在业务事实、状态口径和验收标准上产生不同解释。这种差异来自生成过程中的多个决策点决策点AI 需要回答的问题缺少控制时的结果产品事实有哪些角色、对象、状态、权限和异常页面各自解释需求字段和口径逐渐漂移。页面职责当前页面承担什么任务首屏应优先表达什么所有页面趋向相似的信息卡、表格和表单组合。流程关系一次操作会改变哪些对象并影响哪些页面按钮有反馈业务结果只停留在当前页面。组件能力哪些系统组件适合当前任务缺口如何治理组件库存在页面仍混入临时原生实现。完成证据怎样证明流程、视觉、多端和可访问性达标构建成功被当作完成运行质量缺少依据。这也是“产品生成系统”的价值它为这些决策建立稳定的控制面让模型的创造力在明确边界内发挥同时让结果具备可追踪性。一套完整生成体系包含七层连续结构在 Mihua Design 里我们把产品生成组织成一条从需求事实到交付证据的连续链路。层级系统产物解决的问题1. 需求事实PRD、角色、对象、状态、流程、异常和验收标准确认产品需要完成什么。2. 机器契约Contract _product.yaml 与 _flows.yaml把产品事实转成结构化、可校验的源文件。3. 契约编译ProductContractIR 与 trace graph统一页面、Block、流程、交互和验收项之间的引用。4. 页面上下文当前页面的任务、流程、数据、表达方式与组件清单让 AI 在生成一页时只读取相关事实。5. 工程执行示例数据、共享状态、工程骨架、页面代码与路由让页面进入同一套可运行工程。6. 组件治理组件能力筛选、来源追踪和缺口修复让组件库真正成为生成约束和质量资产。7. 质量证据流程、状态、视觉、多视口、可访问性和工程验证用运行结果证明产品可以交付。**这七层共享同一条追踪链。**PRD 中的一个业务目标可以继续追踪到页面职责、核心 Block、流程步骤、代码交互和最终证据。产品事实需要一个明确的权威来源完整体系的起点是明确每类事实由谁拥有。PRD 负责业务目标和验收意图产品契约负责角色、对象、页面、状态与流程页面上下文负责把相关事实编译给当前生成任务工程代码负责实现验证结果负责证明实现与契约一致。事实只定义一次页面名称、路由和职责来自产品契约流程步骤和业务副作用来自流程契约多端主任务来自 surface contract主表达方式来自 presentation contract下游持续引用生成上下文引用契约中的稳定 ID页面实现使用静态 Block 对账核心区域交互绑定回流程 step 与 effect验证报告回填同一条 trace graph这样做的直接收益是产品修改可以沿着引用关系向下传播。新增一个状态、调整一个流程步骤、改变移动端任务时系统知道哪些页面、交互和证据需要重新生成或复核。页面生成仍然重要只是被放进了完整链路产品生成系统不会削弱页面设计。相反它会给页面设计更明确的任务边界。生成“商机列表”时AI 得到的不只是页面名称。它还会得到页面服务的角色、用户要完成的主任务、首屏最重要的信息、主表达形式、关联的业务对象、相关流程步骤、桌面端和移动端的任务差异以及建议优先使用的组件能力。这些输入让页面拥有清晰的业务职责也让模型可以把更多注意力用于信息组织和交互表达。nodescripts/generation-context.mjs\--projectcustomer-operations\--pageopportunity-pipeline\--limit12\--jsonstatus:passpage:opportunity-pipelineprimary_task:推进当前商机到目标阶段并在失败时修复阶段缺口primary_block:pipeline-weighted-summarymobile:experience:alternate-taskprimary_job:识别停滞商机并推进单个商机related_flow:opportunity-stage-and-discount.s01warnings:[]业务流程是检验体系是否成立的最好证据以“线索转客户”为例。用户在线索池中选择一条已核验线索进入转化页完成重复检查再创建或复用客户、联系人和商机。一次完整转化会产生连续结果原线索状态改变客户列表新增或更新记录联系人建立关联可选商机进入商机列表和销售漏斗审计日志记录操作重复提交返回同一结果权限不足或数据冲突时进入明确的异常路径。流程卡线索核验与转客户**角色**销售代表 **入口**线索池中的已核验线索 **终点**客户详情步骤所在页面用户任务交接数据或结果1. 选择线索线索池选择一条已完成核验的线索把leadId交给转化页2. 重复检查线索转化检查企业、联系人和商机的重复关系形成“创建或复用”的处理方案3. 确认转化线索转化创建或复用客户、联系人并按需创建商机写入customerId、opportunityId和后续任务4. 核对结果客户详情确认新建立的联系人、商机和下一步任务流程到达可继续跟进的完成状态**完成条件**客户详情出现正确的联系人、商机和任务关系。**同步结果**原线索变为已转化客户、商机、漏斗与工作台投影更新审计日志记录本次操作重复提交返回同一结果。这里可以同时检查产品事实、页面职责、共享状态、权限、幂等、跨页副作用和运行证据。任何一层断开流程都会暴露问题。验证系统决定“完成”这个词的含义构建成功依然重要它只覆盖工程完整性的一部分。产品交付还需要验证契约追踪、功能正确性、信息结构、交互行为、布局几何、视觉一致性、内容与本地化、可访问性以及工程编辑模型。在 Mihua Design 的验证链路里flow-critical 交互需要真实浏览器证据state-changing 操作需要状态测试视觉证据覆盖 1440×900、1024×768 和 390×844 三个目标视口。连续主区间距、横向溢出、固定元素遮挡和响应式替换也会被实际测量。验证报告既给人阅读也能被机器继续消费。空报告、零扫描和缺失的关键证据会直接失败。生成、检查、修复、再验证由此形成闭环。Mihua Design product verify · customer-operations PASS manifest PASS page-intents PASS flows PASS contract-compile PASS interaction-bindings PASS interaction-coverage PASS project-structure PASS project-ia FAIL component-provenance PASS implementation PASS product-quality WARN editable-coverage Result: FAIL · 11/13 pass · 1 warning · 1 fail 系统阻止把尚未核销的 Dialog 能力当作已完成。这套体系的核心价值把生成变成可持续的工程能力一次惊艳的生成可以展示模型能力。一套稳定的生成体系还要支持需求变更、增量生成、质量回归、组件升级和后续工程迭代。当产品事实、生成上下文和验证证据被组织成连续结构团队可以更清楚地回答这张页面为什么这样设计这个交互对应哪一步业务流程这次需求变更会影响哪些页面和测试页面使用了哪些系统组件哪些实现仍需治理当前版本通过了哪些验证还有哪些门禁未完成这正是 Mihua Design 做得最深的部分组件库、规则、产品契约、生成执行和质量验证共同工作形成一套完整的产品生成基础设施。系列目录连续八篇拆开讲完整生成体系这是“Mihua Design 产品生成系统”系列第 1 篇。八篇文章依次覆盖产品事实、页面上下文、表达与多端、业务流程、组件治理、工程完整性和质量证据。篇次文章核心问题01AI 已经能生成多页面应用为什么还需要一套“产品生成系统”完整体系包含哪些连续层级02从 PRD 到 ProductContractIR怎样建立一份可追踪的产品事实怎样建立权威来源与追踪关系03生成一张页面前系统究竟应该给 AI 什么怎样编译页面级最小上下文04页面形态由什么决定从业务任务到主表达与多端契约页面结构和多端任务怎样被定义05从一次点击到跨页副作用怎样把业务流程写成可执行契约一次操作如何形成业务闭环06组件库怎样真正进入生成系统组件选择、来源和缺口如何治理07生成过程怎样保持工程完整怎样避免半成品进入正式工程08怎样证明 AI 生成的产品可以交付怎样用同源证据定义完成下一篇从 PRD 到 ProductContractIR怎样建立一份可追踪的产品事实最后AI 已经能够生成多页面应用这让我们的目标更清晰继续提高页面生成速度同时建立一套能管理复杂产品事实、跨页流程、工程状态和交付证据的系统。组件库提供可靠能力Rules 提供实现约束产品契约定义事实生成上下文组织任务工程管线保持完整验证系统证明结果。当这些层级共享同一条追踪链AI 生成的成果才真正成为一套可以持续演进的产品工程。这也是我们开发 Mihua Design 的原因。
