7.9
深览指数
科技Bestblogs·得物技术··AI 生成
得物小摊 AI Native 演进实录：用 Harness 构建可控 AI 交付
本文以拼团页面数字语义分叉事故为引，提出 Delivery Harness 方法论，将单人全栈 AI 编码从「生成得快」升级为「交付得稳」。核心是四个组件：Version Contract 锁定事实源与版本基线，Execution Boundary 通过 worktree 实现需求级物理隔离，Evidence Gate 严格区隔六个交付状态并拒绝无证据推进，Repair Loop 将真实反馈沉淀为结构化 Case 回流系统。作者坦诚列出三项待补齐能力，并以多 SKU 订单跨运行时原子性保障验证系统。适合对 AI 工程化、系统设计、产研协作有实操经验的深度读者。原文 ↗
核心观点
- ▍AI Native 交付的本质是从「文档交接」升级为「可验证假设」，速度由模型放大，质量秩序必须由系统托底，Harness 四组件构成闭环：事实锁定、边界约束、证据门禁、反馈升级。
- ▍语义分叉是 AI 放大交付风险的核心机制：AI 一旦选错，会以极快速度将错误扩散到接口、页面、海报和测试用例，形成在错误前提上的自洽闭环。
- 01文章以拼团页面「最低成团数」vs「可售库存」的语义争议为例，揭示 AI 在两种解释中选错后，错误被高速扩散至接口、页面、海报和测试用例。
- 02Version Contract 通过 worktree 隔离与版本合同，锁定每个需求的事实源（如 PRD、接口文档）与仓库范围（代码、配置、测试用例）。
- 03Evidence Gate 将交付状态严格区分为六个：代码完成、研发验证通过、具备产品验收条件、产品真实环境验收通过、已生产发布、已合入稳定分支，每个状态对应可复查的证据集。
- 04Repair Loop 将线上反馈或验收 Bug 结构化沉淀为 Repair Case，输出到：进入测试用例库、固化到门禁规则、或追加到版本不变量定义中。
- 05多 SKU 订单履约改造案例：一笔订单穿过用户端、管理端、Node 服务和 Go 服务四个运行时，Harness 将「订单级原子性」转化为跨运行时不变量，通过产品文档、接口合同、服务端校验、反例测试、验收报告五层保障。
反方 / 局限
- — 作者坦诚列出三项待补齐能力：统一本地与 CI 的检查入口尚未打通、完整版本合同尚未接入流水线、稳定分支与版本合同的语义判断尚未统一——系统处于演进中，非完整方案。
4 分钟 · 4 卡片 · 8 资料
读原文 →