面向 AI 原生研发团队的最佳实践
我们持续演进的 AI 原生研发团队工作手册——人负责定义规格与把关，AI 智能体则让每个功能沿同一条路径推进到底。
每个功能，同一条路
四个阶段，两次人工决策，零未经验证的合并。路径本身就是流程。
收敛契约
→ 一份等待您批准的契约
依契约构建
→ 附标准–测试对照表的 PR
像第一位用户那样验证
→ 议题上的证据包
凭证据发布
→ 压缩合并、经验证的部署、关闭的议题
人只出现两次
两次都是简短、准备充分的决策，而非开放式的审阅。吞吐量的上限是人的决策延迟，而非智能体速度——所以判断被集中到唯有人不可替代之处。角色对应视角，谁也不为不属于自己的视角盖章。
批准契约
验收证据
最佳实践
每一条都为提升研发效率与大模型 token 效率而存在。
用产品负责人自己的话写契约
一页以内，3–8 条可观察的验收标准，由脚本机械检查——不让工程术语偏离本意。
只谈行为，不谈技术细节
每条标准都能在产品中观察到；编号从契约到测试再到证据，全程可追溯。
测试驱动开发
任何实现之前，每条标准先有一条失败的行为测试来引导开发。
测试一红即锁
实现向测试低头；要解锁，需要书面理由加人工批准。
构建者绝不自验
验证者只拿到契约和地址——从不接触差异、源码或构建者的笔记。
证据胜过声明
每条标准一份本轮新鲜捕获的证据，由脚本校验——复用旧截图即伪造证据。
人只做产品判断
至多五项直白检查；智能体本可以执行的，是证据，不是验收。
规则交给钩子，不靠文字
写在文字里的规则终会被忽略——合并、改测试、署名都由钩子拦截。
健康检查绿了，不等于功能上线
部署验证要在用户将要看到的页面上探测功能本身。
每条教训只沉淀一次，落在成本最低的一层
反复出现的意外要变成一条规则、一项检查或一个钩子——赶在它第二次付出代价之前。
硬关卡，诚实分类
每条保证都被诚实分类——由脚本退出码强制的硬关卡、必然留痕的防篡改威慑，或明示的剩余信任。钩子拦不住的，就明说是信任，绝不默认。
独立证据未发布、人未验收之前，合并直接失败。
红色检查点之后，锁定的测试文件无法改动——哪怕绕道 shell 重定向也不行。
带 AI 共同作者署名的提交被拒绝；责任始终落在人身上。
检查未通过时，智能体无法中途收工——要么通过，要么如实记录受阻。
验证开始之前捕获的证据，一律拒收。
框内的一切都由退出码拦截，而非行为准则。
把您对任何 AI 写就的代码库的疑问，都拿来问我们
如果您评估过 AI 辅助工程，心里已经有一堆疑虑。很好——我们也一样。
智能体不就是自己给自己打分吗？
验证者是一个全新的智能体，只拿到契约和地址——从不接触差异、源码或构建者的笔记——像第一位真实用户那样使用产品。
凭什么保证实现不会去凑测试？
测试先失败，并在实现开始之前锁定；解锁需要书面理由加人工批准，并记录在 PR 中。
说“能用”——谁说的？
每条标准一份本轮捕获的证据。新鲜度由脚本校验；复用旧截图算作伪造证据。
出问题时，谁来负责？
一个具名的人。合并需要人工验收，带 AI 署名的提交被拒绝，每个决策都留下审计痕迹。
这么多流程，不会拖慢你们吗？
它砍掉了最慢的一步——人反复重审一切——把判断集中到两次简短、准备充分的决策上，其余全程由智能体以智能体的速度推进。
盯住两个延迟
两个数字就能告诉您生命周期是否健康——而不是一堆虚荣指标的仪表盘。
周期时间 = t·人 + t·智能体
人的延迟
契约等待批准、证据等待验收的时间——吞吐量的上限。
智能体延迟
一份批准的契约变成经验证的证据所需的时间。
t·智能体在变长？切片太大了——再拆。
让您的工程团队成为 AI 原生
我们扎进您的工程组织，在您的待办中找到最小的胜利，并在生产环境中把它跑通——就在您的技术栈上。然后把它扩展成团队的交付方式：同一批工程师，十倍的吞吐量，每一次合并依然对人负责。
交付物 · 您的第一个功能，走完整条生命周期并在生产环境上线