AI-Native 产品迭代从不确定判断到高效协作
先判断需求的不确定性，方向未定时先用可比较原型验证，再进入项目级约束下的实现与验收。
角色边界：产品经理｜团队提效、原型验证与视觉约束
01｜为什么直接 Vibe Coding 成本高
实现成本下降，不等于判断成本下降：方向未定时直接进入工程，可能更快放大错误投入。
我先识别当前缺口是产品判断、视觉方向还是工程执行，再选择协作路径。
方向未定
交互范式和信息层级还没有形成共同判断。
直接进仓库
Agent 在真实组件和状态中大范围试错。
反复修改
多轮沟通、Token 消耗和局部补丁持续累积。
回滚重来
严重时需要撤销实现，再重新选择产品方向。
效率不等于更快地产生代码，而是让不确定性在成本最低的阶段被暴露和拍板。
02｜先判断不确定性，再选择协作路径
UI 改动先依据 Design Contract 判断布局或信息层级是否变化，再决定是否先做原型。
原型是条件分支；无论是否使用，最终都回到真实仓库约束与同一套验收。
产品目标 · 真实组件 · 仓库上下文 · 视觉约束
两个环节都从同一份事实和约束出发；区别只在于当前更需要比较方向，还是进入受约束的真实实现。
ROUTE A · PROTOTYPE
低成本比较交互方向
复刻真实界面与设计语言，在不触碰项目逻辑的环境中生成可运行方案，让最终效果在工程化之前被体验和拍板。
减少错误方向进入项目代码后的 Token 消耗、多轮修改和回滚成本。
责任边界：个人主导的是这条路由里“要不要先做原型”的判断标准与原型分支；受约束执行、门禁与回滚属于研发主导的项目级体系。
03｜路线 A：HTML 原型降低决策成本
我个人主导 replicate-ui-prototype，读取真实组件、Design Spec 和项目 token，生成可比较、可交互的 HTML 原型并一键部署内网。
团队可在方向未定时直接体验方案差异，再决定是否进入工程实现。
把复杂消息流重组为用户可理解的执行过程。
在既有组件和 Design-spec 约束下比较交互范式。
验证多组件联动与上下文入口是否成立。
04｜路线 B：工程级 Harness 如何支撑多人交付
方向明确后，项目级 Harness 将规则、上下文、执行范围与验证条件组织成共享协作流程。
我参与研发主导的项目级 AI 协作体系，并与设计、研发共同沉淀可执行视觉约束；Design Contract 是其中一层，不替代产品判断与发布授权。
把个人经验变成团队共享的执行条件
项目级 Harness 不是其中某一个工具，而是这五层的总和：规则提供当前目录的上下文，合同定义结果关系，流程规定执行顺序，工具限制动作范围，门禁与人审决定能不能合入。
Harness 不是其中某一个工具，而是这五层的总和：规则约束能做什么，合同约束产出长什么样，流程约束按什么顺序做，工具约束在哪里执行，门禁决定能不能合入。约束自上而下逐层收紧，结果自下而上回报。
LAYERED RULES
规则不是一份要背下来的大文档
同一个仓库同时住着桌面端、共享能力包和云服务；没有人能记住全部规范。Harness 的解法是让规则跟着目录走：改到哪一层，就自动带上这一层以上的全部约束。
规则跟着目录走：改到哪一层，就自动带上这一层以上的全部约束。桌面客户端、共享能力包与云服务是同级兄弟，各自只补充自己那一层，不推翻上层——这是很多人和 Agent 能在同一个大仓库里并行工作的前提。
这是“很多人和 Agent 能在同一个大仓库里并行 vibe coding”的前提：定位到要改的目录，就已经拿到该目录的正确上下文和红线，不依赖谁更熟悉这块历史代码。
EXECUTION MECHANISM
工程级 Harness 执行机制示意
可交付不是因为每个人都更会写 Prompt，而是因为正确上下文先于代码加载、越界变化在 diff 中可见、确定性检查先于合入发生，产品判断与发布授权仍由人负责。
DESIGN TRUTH SOURCE
Semantic Token 与 Light / Dark
- 规则
- 颜色只引用 semantic token；主题通过 CSS 变量自动切换，不在组件里写硬编码色或 dark: 分支。
- 避免的问题
- 避免 Agent 在局部组件中创造新灰阶、品牌色和主题例外，导致全站视觉漂移。
- 对 AI Coding 的作用
- 把“看起来一致”转成可检索、可执行、可回归的工程约束。
HOW THE CONTRACT IS ENFORCED
视觉约束不是一份需要人记住的设计文档，而是每次 UI 改动都会被读到的固定输入。
是否遵守不取决于个人当天有没有想起来，而取决于任务类型是否命中这条流程。
UI 任务默认只允许出现样式与布局层的改动；handler、state 与协议变更一旦出现，就是需要单独说明的越界项。