AI-Native 产品迭代从产品判断到可运行验证
用可运行、可比较的原型缩短产品判断到验证的距离，再用受约束的 AI 协作推进工程实现。
01｜为什么需要可运行验证
复杂 Agent 产品的许多问题只有在真实 streaming、工具状态和数据中才会暴露。仅靠文字沟通或静态 PRD，容易把关键判断留到工程后期。
我的目标是让产品判断尽早进入可运行、可比较的验证，同时保持设计、工程和算法边界清楚。
目标不是让 Agent 替代产品与工程决策，而是缩短产品判断到可运行验证的距离。
02｜哪些判断不能交给自动化
传统交付中，方向未定时缺少可比较的运行方案；方向确定后又容易在需求、实现和测试之间发生语义损耗。直接让 Agent 自由改代码，还会破坏既有组件和工程约束。
核心矛盾不是“人工还是 AI”，而是如何让 AI 加速产品判断与验证且不降低可审查性。
需求证据
为什么要做
PRD / 合同
什么算完成
可运行原型
交互是否成立
测试 / Review
边界是否守住
原始问题
“长任务执行过程太碎，用户不知道 Agent 还在做什么。”
可运行验证
构造 streaming、工具重复、确认和失败状态，验证聚合与打断规则。
工程验收
主回复开始、未解决控制点、历史回放与恢复状态成为明确验收条件。
03｜如何把模糊输入变成工程问题
优先用并排原型和真实组件约束验证产品范式；再将仓库规则、Skill、Agent 角色、Review、MR Gate 和回滚组织成可审查协作链；最后把结论写成工程可读输入。
高风险改动保留人工确认与代码审查；Vibe Coding 服务于交互验证、数据探查和边界复现，不替代产品与工程决策。
让 Agent 自由修改并直接推向生产，把自动化程度当作效率。
证据收集、隔离实现、测试、Review 和人工发布闸门组成可审查链路。
效率必须建立在约束、可回滚和责任可判断的基础上。
产品范式
方向未拍板时，Agent 只能提供证据和备选方案。
需求边界
范围、成功标准与风险由产品和工程共同确认。
发布与回滚
Agent 可准备检查，但不能替代最终发布决定。
TASK ROUTING
探索
- 输入状态
- 方向未拍板
- 验证方式
- 并排原型验证
- 关键护栏
- PM 选择范式后再进入实现
04｜可运行原型如何验证判断
组合 Claude Code、Codex、OpenCode、worktree 与多 Agent 协作：从仓库规则、真实运行状态和既有组件建立事实，再生成原型、实现最小路径、运行测试并回看差异。
个人主导 replicate-ui-prototype，使多组件联动、方向未定的方案能够快速产出高保真、可比较、可分享的 HTML 原型。
把复杂消息流重组为用户可理解的执行过程。
在既有组件和 Design-spec 约束下比较交互范式。
验证多组件联动与上下文入口是否成立。
STEP 01
隔离验证
用最小可运行路径验证产品判断。
- 输入
- 产品合同与现有设计/代码约束
- Agent 加速
- 按任务类型生成原型、fixture 或隔离实现
- 人工决策
- 交互范式是否成立，是否值得工程化
- 输出
- 可运行原型与验证记录
- 进入下一步
- 关键路径和边界状态通过验证
Agent 可以加速证据整理、原型和测试，但不会自行决定产品范式，也不会绕过人工 Review 直接推向生产。
05｜AI 协作如何受约束
把验证结论转成状态模型、数据字段、接口约束、Rubric 与验收用例，使研发和算法能够理解“为什么这样做”以及哪些边界不可破坏。
沉淀从模糊输入、方案比较、可运行原型到测试、Review 和回写的协作方式，但不把它包装为无需人工判断的一键上线系统。
不是工具清单，而是一条可验证的协作链
对应简历中的项目级 AI 协作体系：规则、Skill、Agent、MCP Tool 与 Harness 共同把产品判断带入实现、测试和 Review。
项目规则
CLAUDE.md / AGENTS.md 定义边界
Skill
把任务变成可执行工作流
Agent
按角色分解和推进任务
MCP Tool
执行文件、画布与服务动作
Harness
串联步骤、验证结果并处理失败
证据聚合
整理反馈、数据和业务信号
批量追问
一次提出高密度关键问题
假设挑战
发现未被说明的范围与替代方案
ARCHITECTURE L1
入口层
自然语言、用户反馈、数据、截图与已有文档把零散触点转成可追踪输入。
06｜结果
以可运行验证为核心，将规则约束和人工 Gate 纳入 AI-Native 交付流程，用于复杂 Agent 产品与原型验证。
一句话、截图与真实仓库约束
并排原型与关键取舍
Review、测试与人工发布