夜雨聆风天猫 AI 助手团队最近做了一次较大规模的复盘——他们在两周内同时推了两条线:一条是把调度框架从硬编码节点链重构成三层模型,另一条是把团队的 AI Coding 从"个人用 Agent 写代码"升级为"组织化的工程能力"。
两条线交叉推进,最终达成几个可量化结果。
从单一讲价流程,扩展到 5 个以上 ScheduleBizType 和 5 个以上 ProcessTemplate 共存,新业务接入压平到不足 1 天;状态写复杂度上,21 处散点的 query + CAS + retry 收敛到 2 个 Reducer 加 25 个 Event,单 process 终态写库次数从 4 次降到 2 次;可观测性方面,从一份 assistShared.log 拆成 monitor、bizStat、error 三通道独立采样;AI Coding 工程化方面,4 份范式、13 个 Skill、8 个 Hook 加月度观测报告形成闭环,单业务接入从 3.5 到 4.5 人天压到约 0.7 人天,提效约 5 倍。
第一条线:状态写入收敛的非线性收益
状态写入散点化是旧框架最痛的地方。service 模块里能数出 21 处对 scheduleBO 和 processBO 的写入,每处自带 query → mutate → CAS → retry。每接一个业务就要复刻一遍这套模板,且并发场景下不同组件之间的写入容易互相覆盖。
重构的核心思路是把"如何写"和"为什么写"分开。Reducer 统一处理前置校验、字段变更与并发重试,Event 描述业务意图,业务侧只表达"希望发生 X",避免并发组件互相覆盖。
为什么收益是非线性的?因为 Reducer 一次合并多源 mutation 后,多个子任务的并行写不再是串行排队。子任务越多,串行写库的开销削减越明显。原本 4 次串行写,在 8 个并发子任务的场景下等于节省 32 次 IO 开销。
更重要的是,Reducer 把"竞态条件"这件事从业务代码里彻底移除了。旧框架里每个业务方都要自己处理 CAS、retry、超时,稍不注意就埋个 bug;新框架下,业务方只关心 Event 顺序,Reducer 负责把所有并发安全的事情处理好。
一个踩坑:双兜底反而引入竞争
重构过程中有一个典型的踩坑。
团队最初保留了 DagTerminationChecker 和 Reducer 两套机制作为终态聚合的双兜底。结果两者在终态聚合时互相覆盖 mutation,导致任务卡在 CANCELLING 状态无法推进。
排查了 3 天才定位到根因——两个模块都想做"权威",结果都做不成"权威"。下线 Checker、全部走 Event 路径后,问题立刻消失。
这个教训让团队后来坚持一条原则:收敛要彻底,不要留双兜底。双兜底在并发系统里几乎一定会引入竞争,因为两个兜底逻辑的边界永远无法完全重合。
第二条线:把隐性知识显式化
AI Coding 工程化最大的挑战不是 Agent 本身,而是怎么把隐性知识变成显性资产。
团队的解法是先写范式文档,再编码为 Skill。具体来说,他们梳理了 4 份范式文档,覆盖典型业务场景、典型节点写法、典型状态流转、典型错误处理。每份范式背后都有 2 到 3 个真实业务案例支撑。
范式文档沉淀之后,编码为 13 个 Skill,可以直接被 Agent 调用。Skill 不是简单的 prompt 模板,而是把范式里的"什么时候该做什么"封装成结构化的决策树,让 Agent 在不同分支下走不同路径。
但光有 Skill 还不够。Skill 是"应该怎么做",Hook 是"实际怎么做"的真实数据采集。团队设置了 8 个 Hook,在 prompt 提交、工具调用、结果返回等关键节点采集数据,形成完整的可观测链路。
月度观测报告:闭环的最后一块
Skill 和 Hook 是基础设施,月度观测报告才是闭环的关键。
报告里会暴露几类核心指标:落地率——业务方使用 Skill 后,实际按范式执行的占比;绕过率——业务方主动跳过 Skill、按自己方式写的占比;GAP——按范式写但运行失败的占比。
这些数字背后藏着真实的体系漏洞。比如团队在第一份观测报告里发现,某类高频 Skill 的落地率不到 30%,深入排查才发现是范式文档里有个边界条件没写清楚。补充范式后,落地率两周内升到 75%。
月度报告的价值在于它把"AI Coding 在团队里到底有没有用"这件事从感觉变成了数据。可以基于数据决定范式要不要调整、Skill 要不要重写、Hook 要不要补充。
我的评价
这套实践的核心判断是:AI Coding 不是个人生产力工具,而是需要工程化的团队能力。
很多人以为 AI Coding 就是给每个人发一个 Cursor 账号,然后团队就会自动变快。这种假设忽略了三个事实:一是隐性知识不会自动显式化,二是经验不会自动跨人传递,三是失败模式不会自动被发现。
天猫团队的解法就是把这三件事显式化:范式文档负责显式化隐性知识,Skill 负责传递经验,Hook 加观测报告负责发现失败模式。这套闭环一旦建立,组织能力就不再依赖个别工程师的水平。
隐性知识显式化是穿越模型代际更迭的壁垒。当模型一代代更新,显式化的范式可以无痛迁移到新模型上;如果知识只存在个别工程师脑子里,模型换了人也要换。
另一面:不是所有团队都适合这套打法
这套实践也有明显的适用边界。
第一,业务规模得够大。如果团队总共就 3 个业务、5 个工程师,做范式文档和 Skill 的投入产出比可能不划算。
第二,业务形态得相对稳定。如果业务每个月都在大改,范式文档很快就会过时,观测报告里的 GAP 会持续高位。
第三,得有专门的工程资源投入。这套体系不是几个人业余时间能搭起来的,需要至少 1 到 2 个全职工程师持续维护。
判断标准是:你的团队有没有超过 10 个相似形态的业务?有没有重复出现的工程问题?有没有专职的工程效率团队?如果三个问题都答"是",这套打法值得投入。否则,可能更适合用现成的 Cursor、Claude Code 等工具,而不是自建体系。
最后一点:GAP 数据显示部分 agent 编辑未入 commit,团队真正受益的代码量应从 commit 角度度量,不能只看调用次数。这意味着 AI Coding 的真实价值评估,需要穿透到代码合并的最终结果,而不是停留在 Agent 的输出表面上。
