双11：当 AI 接管支付宝大促交付，模型之外还要建什么？
阿里技术 · 软件开发
原创 王晋阳 2026-11-05 18:12 浙江 关于如何通过 AI Harness 从工程化走向 AI 全链路交付，本文或许能提供一些经验和参考 这是2026年的第 76 篇文章 （ 本文阅读时间：约 20 分钟 ） 01 导读 支付宝大促主要指 618 和双 11，由支付宝、淘宝、天猫协同推进，支付宝大促以直播和互动两大会场承载，配合淘宝的预热期与现货销售期。直播会场接入淘宝直播，让用户边看边领、边领边买；互动会场通过抽奖、养成玩法和红包，让用户边逛边玩、领取优惠。 本文回顾支付宝大促技术团队近三年的演进，介绍如何通过 AI Harness（支撑 AI 研发交付的工程体系），从工程化走向 AI 全链路交付，提升研发效率与质量，并回答一个核心问题： 当 AI 接管大促交付，模型之外还需要建什么？ 02 大促研发演进：从工程化到 AI 全链路 (一) 大促特点 时间是刚性。 支付宝618、双11的排期和集团大促战略时间强绑定，必须按照既定时间执行，交付窗口以周计、全倒排——“延期”这个选项在大促字典里不存在。 质量是底线。 优惠、权益、资金全是高敏感业务，大促期间任何线上问题都处在用户与舆论的放大镜下，事故代价被数倍放大，质量标准只升不降。 需求脉冲式涌入。 平时细水长流的业务，大促前集中爆发——横跨直播、互动多个会场与几十个功能模块，短时间内交付密度陡增。 唯一不变的是变化。 每年的会场玩法、权益形态、对接方都在换，去年沉淀的经验今年只剩部分适用，再加上每年都有新人进场——体系本身必须能应对“变化”这个常态。 (二) 技术演进过程 2024年： 把需求交付的“又好又快”定义清楚、做到位 。 快的定义是随时可发布——以主干研发为基础，向主干合入小PR，随时保有可发布版本，发布能力从“一周一发”提升到“一天一发”，并行需求互不等待，接得住大促需求脉冲式涌入的交付密度。好的定义是科学拆分需求，Feature化小步快跑，单次变更控制在800行以内，保证CR质量，严控高风险代码，变更行覆盖和分支覆盖行业领先，达到90%才能合入，第一次大促就做到了线上0故障/0线上问题/0重大舆情，业务目标完美达成。但是也存在不足：当需求规模量级变大，人力投入线性上涨，交付下来不轻松。 2025年： 组件化沉淀 + AI 补全，效率的第一次杠杆 。 第一步是把通用能力从需求里抽出来：将签到、抽奖、发奖、弹窗这些大促标配能力沉淀为可复用模块，通过配置和拼装快速搭建会场，当年节省约106 人/日。第二步引入 CodeFuse 做 AI 代码补全和单测生成，AI 生成代码占比逐步达到30%。但补全的本质是“Coding加速器”：写这一下变快了，系分、自测、联调仍一条条是人工，模块怎么拼还是要人来决策。瓶颈没有消失，只是从“写代码”转移到了“串流程”。 2026上半年： Claude Code 引爆 Agent Coding ，重新理解 AI 的角色。 关键变化不是代码写得更快，而是 AI第一次能“接活”了——给它一个任务和一份上下文，它能自己读代码、自己改、自己跑测试验证。我们对 AI 的认知从“补全工具”升级为“可以委派的执行者”，这是 AI Coding 与传统辅助编码的分水岭。 2026年·618大促：Agent Coding 的第一次实战，也暴露了裸用 AI 的代价。 CY26-618 我们用 AI Coding 主导交付了 32 个需求，验证了可行性，但代价清晰可见：系分/编码/联调全程人工澄清 1332 次，AI 协作的人力成本全部压在人身上。复盘的结论很直接：裸用 Agent 不可行—— AI 产物质量不可控、对业务上下文一无所知，每一分不可控都要人来兜底。 2026年·双11大促： 用 Harness 回答这道题。 要让 AI 真正接管交付，光等更强的模型是等不来的，必须在模型外面补上一整套东西：它该看到什么、下一步该干什么、用什么工具动手、出错了怎么爬起来。而这整套东西的原料，正是前两年的工程积累——主干研发练出的CR纪律与质量门禁、组件化练出的复用抽象、评审与评测沉淀的准出标准，它们没有被 AI 淘汰，而是被翻译成 AI能执行的语言， 多年软件工程的深入理解与演进经验，在 AI 这里找到了结合点 。这个判断也得到业界印证——Anthropic 在《Building effective agents》中提出的 agent 工程化原则，以及 Claude Code、Cursor 等 Harness 的实践都表明： 同一个基座模型，套上不同的 Harness，表现天差地别；决定上限的是模型，但把上限稳定兑现的，越来越是模型之外的那一层 。这套模型之外的运行框架，业界称之为Harness——这正是我们双11要回答的问题。 03 定义大促Har