得物以AI协同完成小摊多运行时全栈交付

得物小摊是从 0 到 1 孵化的创新业务，作者一人同时负责 H5、运营后台、Node 网关与 Go 服务的设计、实现、联调和交付。随着业务推进与协作范围扩大，一次需求常常要穿过多个工程与运行时，作者开始让 AI 并行参与这些模块开发：文中称代码产出速度明显提高、“一个人也像拥有了一支虚拟全栈团队”，并引用 Codex 基于近期任务记录给出的开发能力评价。工程半径扩大后新问题随之出现——如何保证同一条业务规则跨过不同运行时后不变形、改动不越界、验证/验收/发布仍可追溯，这直接引出从“写出更聪明的 Prompt”转向构建面向单人全栈交付的 Harness。文中也明确 AI 的边界：可检索、实现、补测试、整理报告并同时推动多个模块，但每一次状态跃迁都必须有合同和证据支撑。 Harness 包裹在模型之外，接管四件事：任务读取哪份事实、可修改多大范围、结果怎样被证明、什么条件下必须停止——模型负责生成与判断，Harness 负责边界与状态。Version Contract 把事实放在最接近它的位置（产品口径留产品文档、影响范围与技术方案留规格变更、版本与交付仓库进版本合同、验收结果进统一报告、真实缺陷进 Repair Case），任务开始只加载本轮所需，临时推断未经文档/代码/验证确认不得升级为长期事实。Execution Boundary 落到仓库与环境规则：一次需求用独立工作区与分支、跨仓改动逐仓声明、客户端不能绕过统一请求层直连业务服务、测试环境特殊入口不得扩展到预发或生产、涉及外部写入/发布/消息发送无明确授权即停止；并以 worktree 作第一层实现，规则为“一个需求 × 一个仓库 = 一个 worktree”，纯只读分析不建树，清理需满足生产发布成功、提交已推送、证据已持久化后才允许 git worktree remove 与 prune。Evidence Gate 把编译、单测、接口验证、真实设备验收、生产发布、稳定分支合入拆成六个状态，以“文档—需求—用例—证据”映射的统一验收报告决定能否推进（文档读取失败、规则无用例、跨模块无回执一律保持 pending），并明确 AI 可整理证据但不能替责任人签字。Repair Loop 要求同一 Repair Case 内含原始反馈、定位过程、失败基线、候选结果与回归结果，且基线检查必须失败、候选修复与回归检查必须通过，一条反馈只有改变了下一次任务的默认行为才算被吸收。 这套 Harness 第一次完整经受跨运行时考验的场景是一次多 SKU 履约改造：一笔订单从用户端出发，经管理端、Node 服务与 Go 服务进入下游系统，任一层把“订单”误解成“SKU”都会制造局部正确、整体错误（前端显示完整、后台只处理一部分；接口返回成功、下游却生成多条互不关联的履约记录）。团队先把唯一不能被拆散的业务不变量写进合同——订单是履约原子单位：多个 SKU 共享同一次履约决策，要么整单接受、要么整单失败，外部回执必须依靠持久化的稳定标识回到原订单，不能靠当前请求临时猜关联关系。Harness 在其中的作用是把这句产品口径变成跨运行时不变量：产品文档定义语义、接口合同约束输入输出、服务端校验资源与状态、测试主动构造部分失败的反例、验收报告记录跨服务结果，相关代码仓分别保留分支、提交与发布证据。