货拉拉千人 AI Coding 落地：用自建 Harness 收口，跑通组织级 AI Native

一、背景：个人提效 ≠ 组织提效

货拉拉是国内一家大型物流平台，业务场景覆盖用户端、司机端、调度系统、仓储系统、财务结算等几十条产品线，货拉拉技术中心有1000+ 工程师，跨10+ 技术栈。

AI Coding 喊了一年多，统计口径都在说"效率提升30%"、"代码采纳率40%"。货拉拉千人规模的研发组织放开用，个人确实快了：自己装插件写单测、补注释，IDE 里 Tab 补全少敲几行。但镜头拉到整个组织，画风就变，一线暴露的问题归成五条：

• AI工具各用各的，用法各自为政；
• 重复整理相同的项目资料；
• 代码风格不统一，Review 负担重；
• 说不清 AI 到底提效多少，返工三次，表面采纳率高，组织效率其实是降的；
• 成本与风险没人管得住，甚至有人把内部代码贴给外部大模型。

个人提效有了，组织提效没影。根子在衡量维度不同。组织提效要回答整条研发链路：需求、编码、测试、Review、发布、线上故障处理，有没有变快、质量守没守住、协作成本涨没涨。

货拉拉的判断直白：AI Coding 在个人层面是"效率工具"，在组织层面必须变成"协作约束工具"。重点是怎么把工具嵌进研发流程。先立三个必须回答的问题当解法框架，想不清楚后面每一步都会走偏：如何统一管理、代码质量如何守住、效果如何度量。这也正是接下来要展开的内容。

二、AI工具选型与场景适配

2.1 三类 AI 编码工具的核心定位与选型逻辑

市面上的 AI 编码工具按"从轻到重"分三类：代码补全类、对话式生成类、智能体类。

货拉拉选型只看工具能否和现有研发流程无缝衔接。他们的研发流程里，代码托管在自建 GitLab，Review 有固定检查单，CI 有统一规范，希望 AI 代码从第一天起就进流程、不游离在外。三条硬标准：能否私有化部署、能否接入内部代码库理解项目上下文、能否支持权限管控与审计留痕。

最后选了以私有化部署的模型底座为基础，自研了一部分 IDE 插件能力，同时兼容了市面上的主流补全工具。这套底座后来被包装成统一的 harness（即 AiBox），在管控面上把千人用法收口。

2.2 场景适配：哪些环节真正值得"AI 化"

不是所有编码任务都适合 AI，硬套反而拉低效率。货拉拉按"效率收益 × 风险等级"梳理场景适配清单：高收益低风险优先上，低收益高风险坚决不上。

• 高收益低风险（优先上）：单元测试生成（性价比最高）、重复 CRUD（按表结构生成 Model / Mapper / Service 骨架）、代码注释与文档生成、SQL 优化改写（适合慢查询优化初稿）。
• 低收益高风险（坚决不上）：核心交易链路（支付、订单状态机，AI 只能参考不能生成）；高并发调度算法（路径规划、车辆调度，约束复杂 AI 难应对）；底层基础设施（网络框架、存储中间件，性能稳定性要求极高）。

三、AiBox：把千人 AI Coding 收口到自建 harness

在AI工具铺开后最先看到的是分化。同一套工具，20% 的人和 80% 的人，产出差距大到不像在用同一个东西。

组织提效的第一道坎，是把这 80% 的下限抬起来。

3.1 工作台在管什么

AiBox 是货拉拉的自建的统一工作台，本质是面向 AI Coding 的 harness / control plane（管控面）。它集中管理四类配置并下发到大家的每个 IDE：

• Rules：团队编码约束
• Skills：可复用的多步工作流
• Commands：高频动作的快捷指令
• MCP：外部服务与数据源的接入

这些配置由平台统一维护，工具准入、用量统计、合规检查和审计也由平台统一管理，而不是靠每个人自觉。商业 coding agent 解决的是个体写代码，AiBox 解决的是组织如何让 1000 人用同一套纪律写代码，这正是"公司自建 harness"在研发场景的具体落点。

除了提供工作台，还配套安排了培训，帮助大家熟悉工具和使用方法；另一个是把日常研发拆成五类高频实战场景并提供真实执行案例。

培训内容包含：

• 校准预期：先建立 AI 编码常识，搞清楚 AI 在哪些任务上靠谱、什么时候会一本正经地编（hallucination），别一上来当搜索引擎用。
• 讲清 IDE 能力边界：上面三类工具（代码补全类 / 对话式生成类 / 智能体类）各自的代价与适用边界是什么。
• 统一开发环境配置：Rules、项目初始化、MCP 接入一次配好，不让每个人自己摸。
• 整理新人培训流程：把前面的培训和配置步骤固化成入职流程，按步骤学。

五类高频实战场景按BugFix、从 0 到 1 新项目、线上运维排障、重构优化、需求开发分类。每个场景配一个能照着跑的真实例子，每个体例子都包含以下内容：

• 阅读理解代码（以订单模块为例，让 AI 梳理核心逻辑、依赖关系、数据流向，输出分析报告）
• 新增字段与查询接口（一次完成改接口字段、加数据库列、新增查询接口三件事，只改必要代码）
• 代码变更评审（当前分支变更交给 AI 做系统化 Code Review，输出结构化 CR 报告）
• 单元测试生成（为指定方法分支逻辑一次生成覆盖主干的测试类，不启动容器和真实数据库）

3.2 网关把能力收口到接入层

团队规模变大后，"每人一个 AI 账号"不可持续：成本、能力、数据安全都不可控。货拉拉把 AI 能力统一收口到自建网关（AiBox 的一部分），所有 IDE 插件、内部工具、CI 流程都经网关调用模型。这正是 AiBox 作为 harness 的控制面落地，也是"公司自建 harness"在接入层的具体形态。

收口带来四个直接好处：

• 统一鉴权与用量：每个开发者的 token 消耗、调用模型、使用项目全可追踪，按团队设配额，避免把 AI 当聊天工具刷流量。
• 统一数据安全：发往模型的代码和文本先过脱敏与过滤模块，识别 AccessKey、数据库连接串、手机号、身份证号等敏感信息，发送前脱敏、含敏感信息直接拒绝。
• 统一审计留痕：所有 AI 交互落到日志，代码泄露或事故能定位到具体的人和具体内容。
• 统一模型路由：补全模型与推理模型分开配置，网关按任务类型和上下文长度自动路由，既保效果又控成本。

这一步让 AI Coding 从"工具"升级为"组织基建"，后续度量、质量追踪、新模型接入都在这层之上扩展，不用反复打补丁。

四、多智能体协作开发：从"AI 帮你写"到"AI 团队帮你写"

多智能体协作是 AiBox 收口后放大提效的抓手：多个不同职责的 Agent 引入流程，靠约定接口协作。当 Agent 能独立推进各环节，组织要补的是协作规则而非单点能力。

实际流程：需求理解Agent 把需求拆成子任务、识别模块与接口；技术方案Agent 生成设计含改动文件与关键算法；编码Agent 读方案结合仓库生成实现；测试Agent 同步生成单测；Review预审Agent 对照编码规范和质量红线做一轮预审，输出问题与修改建议。

Agent 之间会互相挑错：测试Agent 真的运行测试给失败原因，Review Agent 给意见退回编码 Agent 修改，形成"AI 开发团队闭环"。

货拉拉也给多智能体泼冷水：远没到全自动跑核心业务代码的程度，定位是"提速器 + 预审员"而非"替代者"。需求判断、架构取舍、产品逻辑兜底仍由人负责，Agent 只压缩"需求描述到初版代码"这段最耗时重复的工作，让人专注真正需要判断力的部分。

4.1 多智能体开发规范：比写代码更重要的"游戏规则"

不立规范，多智能体跑起来就是一锅粥。货拉拉踩坑后总结出四条，作为内部"智能体开发标准"，接入协作的项目第一件事就是过这套规范。

• 第一，任务边界锁死：一个 Agent 不能既改前端又写后端，知识库、工具权限、操作范围启动前定死，否则互相干扰、改到对方文件、重复实现。
• 第二，接口格式严格定义：如需求理解 Agent 输出的"任务卡片"必须含任务名称、涉及模块、依赖文件、验收标准四字段，编码 Agent 只认这格式，不对直接拒执行。
• 第三，失败回退机制：Agent 跑测试失败或代码冲突不能硬编，回到预设检查点由人介入。货拉拉每次自动操作前生成备份分支，异常一键回滚，不留坏一半的代码库。
• 第四，行为可审计：改了什么文件、为何改、调了哪些模型、耗多少 token，全有日志。无日志，Agent 擅自改公共模块导致别处测试失败根本没法排查。

AI Agent 本身不危险，没有规范约束的 Agent 才危险。

五、提升 AI 代码质量的关键

工具铺开、网关收口、多智能体提效，解决的是"人人都能用、流量可控、跑得更快"。但 AI 代码能不能用、稳不稳，取决于质量。

货拉拉把质量拆成三道关，正好对应一次 AI 编码的事前、事中、事后：先喂够上下文（事前，少凭空编），再按规范（spec）把变更结构化（事中，锁住不确定性），最后用硬规则与双闸门兜底（事后，兜住漏网）。三关串起来，AI 代码质量才立得住。

5.1 上下文先行：先"喂"上下文再让 AI 动手

货拉拉观察到：抱怨"AI 代码质量差"时，问题往往是没给够上下文。直接让 AI"写个订单超时自动关闭"，它不知道订单状态枚举、不知道分布式锁用 Redis 还是 ZooKeeper、也不知道异常规范，生成的东西能跑但不是团队想要的。

所以，货拉拉把"上下文先行"做成标准写法，分三步：

• 第一步，先让 AI 读关键文件：把订单实体、状态机、缓存工具类加进对话上下文，先理解现有风格与架构约定。
• 第二步，用"伪代码 + 约束"描述需求：不只说"写个超时关闭"，而是给一段伪代码（遍历待关闭订单、检查状态、调用关单服务、失败记日志并重试三次），再列约束（统一日志框架、事务边界放 Service 层、禁止循环内远程调用）。
• 第三步，先看大纲再实现：让 AI 先出大纲或关键函数签名，人确认后再展开，多一步但省返工。

直接生成 Review 通过率约50%，"上下文先行"后到80%以上。这是组织效率差距，不是模型能力差距。

但千人规模推开后不能只靠人均自觉。货拉拉把"上下文先行"从一次任务的写法升级成平台机制，这正是 5.2 要展开的 Spec 驱动：让规范与领域知识由系统召回、自动打包，人只做策展。

5.2 让 AI 按规范写：Spec 驱动把不确定性锁住

AiBox解决了能用，没解决稳定可用。走 Spec 路线有两条理由：普通研发写不好方案，那就把方案结构化、模板化，让 AI 按规范生成；另一条是规模化之后最稀缺的东西变了：代码行数反而不缺，缺的是结构化的领域知识。

货拉拉参考 OpenSpec 的 spec / delta 结构和 Superpowers 的 Skill 化方法论。前者能把每次改动追溯到增量，适合我们这种有大量存量代码的老系统；后者把方法论固化成能让人照着跑的载体，适合在上千人里推开。

货拉拉把通用形态接到自己的研发系统上。他们自己做四件事：需求系统接入、spec 自动召回（规范上下文准备）、用完打分回写、全链路 trace。

规范驱动开发（SDD）五个核心步骤里，第一步（澄清需求）最关键，传统流程里该读哪些上下文全靠研发自己脑补，也最容易翻车。他们把上下文准备拆成四个动作：

1. 需求接入：从 PMIS（内部需求平台）自动拉取需求并关联 PRD；
2. Spec 召回：AI 从 tech / domain / dev / cr_spec 四个库里召回候选 spec；
3. 上下文打包：spec、代码片段、历史设计打包成上下文清单；
4. 人工策展：工程师删掉无关项、补上缺失项，输出 proposal.md。

第四步 AI按Spec 编码执行时采用原子 delta 执行法：一次变更常牵动多个文件。AI 一口气写完，失败就全废，还不知道从哪步走偏。做法是拆成 N 个原子 delta，跑前跑后各校验一次，出问题只回退那一步。

spec 不是写完就摆在那儿。每次被召回使用后，审查环节会记录这条 spec 命中了没有、有没有误导，据此给它打分；命中率低、误导率高的进 backlog 修订，长期不命中的下架。

规范驱动开发（SDD）五个步骤，每一步的产物既要方便人评审，也要保留下一步 AI 需要的信息：

5.3 守住质量红线

质量红线是度量的前置防线，靠组织机制不靠个人自觉，货拉拉用"代码宪法、审查机制、双闸门"三道关锁质量（"上下文先行"已在 5.1 展开）。

5.3.1 代码宪法：规范写成能自动拦截的硬规则

把命名风格、注释、代码结构（例：禁循环体内远程调用远程接口）、安全红线（例如：禁硬编码密钥、禁日志打敏感信息）写成能靠静态检查工具 ESLint、Checkstyle、SonarQube 及自定义规则在 CI 自动拦截的硬规则，在提交前自动拦截，不过关直接打回。机器先筛、人只处理剩余小部分。

5.3.2 审查机制更新：从"读代码"到"重点验证"

有了规范前置后，语法已规范。人工Review逐行读性价比低，重心转向验证行为：需求真满足没、边界异常够不够、有无过度设计。配合统一 Review 检查单与内部 AI Review 插件（基于 diff 标注"疑似空指针""循环内调外部服务"等高风险模式），人只核对标记，效率约翻倍。

5.3.3 双闸门评审：AI 自检后再交人工

AI 生成代码先自检、附带变更说明，再交人工裁决。两道闸门叠加，把"写得快但不可信"的风险压到最低。

六、度量体系是组织提效的真相机

度量要回答三件事：AI 到底写了多少、质量有没有恶化、第一次写得顺不顺。货拉拉把这套度量拆成三层，每层只回答一个问题，互不打架。

第一层是 AI 代码占比，它是所有度量的分母。通过 IDE 插件上报，能知道每个 PR 里有多少代码是 AI 生成的。

AI 代码占比 ＝ AI 生成且最终合入主干的代码行 ÷ 主干新增代码总行

「最终合入主干」这六个字是关键。IDE 里看到的 AI 生成行数，跟最后留下来的完全不是一回事，中途删掉的、重写的、合并时被覆盖的，都不算。为了让这个分子经得起对账，我们做了三层采集：

1. IDES 遥测层　给每行 AI 生成的代码打 hash 签名；
2. 提交比对层　在 git commit 时检查每行是否还匹配签名；
3. 合入统计层　只认最终进主干的行。

第二层 是缺陷率，看质量有没有恶化。接入内部缺陷管理系统和 CI 流水线，追踪每一段代码从提交到上线的全生命周期。一个 PR 里的 AI 生成代码如果在测试或线上出了问题，会被标记回对应的 PR 和代码块。这样能对比 AI 生成代码的缺陷率和手写代码的缺陷率，用趋势线判断质量是否在往下走。

第三层是 首次正确率与返工率，看 AI 代码顺不顺手。一个 PR 第一次提交就被通过的比例（即 FPY，一次通过率），以及一个 PR 被要求修改的次数（返工率），这两个数字直接反映 AI 代码的"顺手程度"。

FPY ＝（commit 终版行数 − diff(v1, commit) 改动行数）÷ commit 终版行数

按 task 算，再按代码行数加权

同一条需求里的不同任务，FPY 差别可能很大。总值看着还行，里面往往藏着一两个特别差的。那些低分任务，就是下一轮要补 spec 和上下文的地方。

全链路 trace，每一次生成都打点、每一次采纳都可追溯。一个订单批量导出的需求，全流程 1.5 小时、20 个 span。proposal 生成 3 次采纳 1 次，tech 生成 2 次采纳 1 次，tasks 一次拆出 7 个任务，review 跑了两轮才过。

生成了几次、采纳了几次，这两个数之间的差，才是 AI 还有多大改进空间的信号。

七、踩坑实录：常见问题速查表

AI Coding 落地一年多，货拉拉在工具与组织层面踩过不少坑，挑有代表性的整理成表，供后来者参考。

八、走向 AI Native：组织、人才与流程的重排，让经验自己回流

harness 落下来之后，生产关系要跟着变，否则工具红利会被旧流程吃掉。货拉拉把变革拆成组织、人才、流程、知识体系四个层面的重构：前三个层面收口生产关系，第四层让经验在交付中自动回流，构成 AI Native 闭环。

前三层：组织、人才、流程重构

• 组织：从职能切分转向业务域对齐。团队边界从前端 / 后端 / 客户端按职能切，转向按业务域对齐，让一个域内的需求能在同一个团队内闭环，而不是跨三个职能团队来回交接。
• 人才：从实现者转向目标设定者与结果审计者。域内人员从单栈个体转向多栈加 AI 协作者；招聘标尺从编码熟练度转向上下文构建能力，看的是把任务讲清楚、把边界和验收定明白的本事。
• 流程：全链路为 AI 重写。文档从各写各的转向全部按 spec 结构化，原来靠团队默契才懂的内容和边界条件、验收标准也要补进文档，方便 AI 读取；工作流从凭经验做转向 spec 全流程跑，澄清、方案、拆任务、实现、审查按统一结构串起来；评审从纯人类评审转向 Agent 一审加人复审。

第四层：知识体系重构（经验回流闭环）

把个人玩法变成组织资产，靠的是知识体系重组与自动回流。货拉拉从提示词资产库入手，再靠闭环让经验持续生长：

• 提示词资产库工业化：按业务域和技术场景集中管理，带使用说明、适用范围、已知局限和典型输出，每两周迭代一次，让新人直接站在验证过的起点上。
• 经验回流闭环：两块
  • 资产沉淀：过程每一步自动入档，踩过的坑变成新的 Rule 和新的 CR 检查项，下一轮自动生效，不靠某个人记笔记。
  • 线上反哺：线上一旦报警，回溯当初的过程档案，把根因反推出一条规则，下次同类需求自动套用。

两条合起来，下一轮需求进来时就自带历史资产。提示词资产库每两周迭代、踩过的坑自动变 Rule，把组织经验从「人工维护的知识库」升级成「随每次交付自动生长的反馈系统」。

一句话总结

把 AI Coding 攒成组织提效的，是自建 harness 对个体玩法与流程的收口：统一规范立下限、多智能体提上限、度量看清真相、闭环让经验自动回流。个人或工具都给不了这一层，组织级 AI Native 才真正成立。

JOTO 企业落地观察

• 对企业部署意味着，千人规模AI Coding落地的核心瓶颈不在模型能力，而在能否构建统一的Harness管控面。货拉拉自建AiBox收口工具接入、模型调用与审计，表明企业级AI工程化必须将AI能力视为基础设施而非插件——这意味着部署决策需前置评估私有化模型底座、内部代码库接入、权限与审计等管控能力，而非仅关注IDE插件功能。
• 这类系统的取舍在于：组织必须放弃‘人人自由选工具’的松散模式，转而接受‘统一Harness+场景化放行’的约束性架构。货拉拉明确划定高收益低风险场景（如单元测试生成）优先上，而核心交易链路坚决不上，说明企业AI落地不是追求覆盖率，而是通过精准场景切口建立可度量、可审计、可收敛的质量闭环。
• 对RAG知识工程而言，货拉拉将‘上下文先行’从个人习惯升级为平台机制，并依托Spec召回与自动打包，揭示了企业级RAG的关键不在向量检索精度，而在结构化知识资产的治理能力。其tech/domain/dev/cr_spec四库召回实践表明，高质量RAG依赖于将领域规范、历史设计、代码片段等非文本资产进行标准化建模与版本化管理。
• 对AI安全治理而言，货拉拉通过网关层统一脱敏过滤、敏感信息识别与调用审计，证明企业AI安全不能依赖开发者自觉。其将AccessKey、数据库连接串等硬编码风险纳入实时拦截，意味着AI安全治理必须嵌入研发流程的接入层，以自动化策略替代人工检查，且所有策略需具备可配置、可追踪、可回滚的工程化属性。