title: "Harness Engineering：快手电商用 AI 流水线重塑研发范式"

source_url: "https://mp.weixin.qq.com/s?__biz=Mzg2NzU4MDM0MQ==&mid=2247501293&idx=1&sn=0b3e4e954201012cff2ed48c71ea3369"

author: "快手技术"

excerpt: "公共早报 快手电商商家团队通过Harness Engineering框架，将AI贯穿需求全生命周期构建自动化研发流水线，实现从个人编码提效到组织效率跃升的实践与组织演进经验。"

---

序章：AI提效的"冰火两重天"

2026 年，"AI 提效"已经成为产研圈最急迫的词汇。它几乎被贴在所有季度汇报的第一页，却很少出现在真实的业务结果里。AI 工具正在疯狂赋能个体，但个体与组织提效却是冰火两重天。个人生产力可以轻松扩张 10 倍，但企业的规模化提效隐晦不明。因为其背后有个结构性问题：大多数团队对 AI 的使用，都停留在工具的使用上，而不是流程层面的重构。工具替换能产生局部加速，却无法带来组织效率的跃升。

个人效率不断提升，但是组织效率提升隐晦不明，我们该选择什么样的工具搭配什么样的流程和组织协同，才能真正使团队效率跃升？这篇文章主要和大家分享快手电商的商家团队如何通过"工具提效 + 组织结构升级"来整体提高组织效率。

从 2026 年初开始，快手电商商家和运营赋能中心就在工具提效和组织提效上做了深度探索，本文是团队对 AI 在快手域场景的梳理和总结。
一、我们的场景与问题

1.1 我们当前的系统庞大且复杂

团队负责快手电商的 B&M 端系统，其典型特点是链路长、业务域多且相互交织。当前系统共服务 6+ 类角色用户、20+ 个业务域、小几百个服务；每个业务域并非完全独立，而是相互交织形成一条条产品线，共同服务不同的用户角色。在这样的复杂系统里，一个需求的落地通常需要多个团队协作------指望靠"一句话"指令让 AI 完成需求显然不靠谱，我们必须在一套规范和约束下，指导 AI 更高效地完成需求。

1.2 数据说话：AI 写得快了，但交付没快多少

2026 年 1 月~4 月，团队核心的动作是推 AI 工具使用渗透，团队的人均周 token 消耗大几千万，人均代码量增加 170%，但是平均的需求交付时长只缩短极其有限。不管从我们自己团队的实战经验看，还是从业界经验看，单纯针对 coding 环节对整体需求的提效是极其有限的，想要需求交付效率高，必须使 AI 贯穿需求的全生命周期。如下是我们小组 2025 年需求耗时整体分布，以及业界需求耗时经验对照：

1.3 当前交付效率的三个结构性难题

a. "需求侧"理解分析成本高

电商 B&M 端业务需求复杂，需求的提出者是产品经理，在需求阶段需要进行需求预评审、需求评审、技术方案评审、TC 评审等各种评审。在传统需求环节：不仅容易出现需求少做、漏做等情况，也在需求侧的各种评审上消耗很长时间。

b. "交付侧"协同成本高

一个需求涉及：招商入驻、店铺管理、交易履约、资金管理、客服接待、结算清退等等环节。涉及到产品、前端、后端、测试等各个角色。当一个需求前端需要 3PD、后端需求 3PD、测试需要 2PD，那么其上线不是 5PD，很可能是 10PD。在传统需求交付环境下，人际沟通复杂度呈几何级数增长，需求的很大比例耗时是协同和相互等待。

c. "新同学"业务学习曲线陡

电商 B&M 端系统经过了 5 年+ 的迭代，积累了大量领域知识、且其做为一个业务系统，规则和业务形态会经常发生变化。很多情况下对于一个新同学，需要一定程度的了解和学习才能开始开发。在传统开发模式下：新成员缺乏系统上下文、需要高成本的知识传递。
二、我们的目标与设计原则

2.1 目标

为了解决上述三个问题，我们核心构建了一整套需求交付自动化流水线。通过这个流水线的实践，我们团队尝试回答一个问题：在业务复杂且有历史包袱的企业级系统交付中，我们该用什么样的智能交付流水线使需求交付 7x24 小时 自动运行起来

从几个维度来对比现状与目标：

核心效率指标：当前需求吞吐率和平均需求交付时间较长，目标是需求吞吐率提升 30%、平均需求交付时长下降 40%。

团队角色：当前为前端开发、后端开发、测试分工，目标转向业务全栈开发。

交付模式：

• 现状下，需求分析阶段单纯靠人工理解 PRD 和产品需求讨论；代码开发阶段 L3 占比仅 5%；测试联调阶段手动编写单元测试 + 人工进行错误日志分析；功能发布阶段手动触发部署流水线 + 线上回测。

• 目标状态下，需求阶段自动生成 PRD + 自动生成结构化需求 + 生成技术方案 + 自动生成 TC；开发阶段 L3 占比提升至 15%+，分解任务、测试驱动开发，单元测试 100% AI 生成，AI 分析业务错误日志，自动联调；测试阶段测试用例 AI 自动生成，经调试准确率可达 100%、测试用例 AI 自动执行率可达 80% 以上，需求测试交付效率平均提升 45%；发布阶段自动部署流水线 + AI 根据 PRD 进行产品验收。

工程工具：

• 现状是直接基于 team 进行项目管理，kdev 进行 CI/CD 过程，且缺乏需求生命周期环节的监控。

• 目标是完全基于智能交付流水线进行需求全生命周期的交付，并通过埋点监控需求全生命周期的交付效率，看整体需求的自动化程度。

下面两张图分别展示了传统研发模式和 AI 流水线模式的过程代入：

传统模式：

多角色参与，协作是其中最大的成本，相互等待是需求交付时间最大的消耗。

AI 流水线模式：

• 超级个体主导，敏捷响应实现需求交付自动化。

• 研发范式发生变革：领域负责人负责初始化该领域的初始化工作，保证本领域的流水线能自动化；需求实现人和产品经理现场讨论需求、和 AI 对话，然后输入"自动交付"。

2.2 核心原则

• 全生命周期：不只是针对单点工具做改进，更是沿着需求的全生命周期，从知识建设、需求生产、研发执行到测试上线，构建一套端到端的 AI 提效体系。

• 工程化工作流：不只是如何控制 AI 让它多写代码，更是把 AI 放进一套可控制、可审计、可复用的工程工作流中，然后让大多数需求只需要澄清清楚就能执行自动化研发流水线（Harness Engineering）。

• 云 + 端协同：不只是针对单角色工作的提效，更是要构造一个"云 + 端"的多角色协同开发系统。云是指挥官，负责结构化需求、分发任务、编排工作，协同多 agent；端是执行器，负责具体实现。我们称这个模式为"Agent Swarm"。

• 链路打通：不只是做交付侧提效，更是和电商产品深度合作，在需求侧通过"对话式 PRD 生成"和"结构化需求生成"实现需求侧的自动化。打通前端、后端、测试全链路，实现需求的自动化流转和可追溯。构建领域知识库，在 PRD 生成、技术方案生成和 TC 生成时更精准，使 AI 交付更智能。

2.3 对抗式设计：open-door 和 close-door

通过 open-door 和 close-door 的对抗式设计，真正使需求交付自动化起来。

• 流水线的各个节点就是一个一个房间，pandoraFlow-delivery 的职责是尽可能 open-door，使需求能够到达下一个房间，而 pandoraFlow-review 的职责是尽可能 close-door，只有让上一个阶段的产出物完全验收通过后才能进入当前节点。

• 通过以上两个 skill 把所有的 skills 串联起来了。但是我们需要对流水线的各个中间产物做存储和管理，也需要对流水线的状态做持续化管理，针对这部分我们的设计就非常简单，通过文件系统 + git 来解决。

• 在 AI code 链路，我们的判断是验证比生产更重要，但是不能只针对功能完整完成后做验证，而是针对每一步的中间产物做验证。贯穿需求的全生命周期中，我们在每个阶段都遵循"plan -> execute -> verify"，这样设计的核心目的就是对当前阶段的产出立马做验收，如果不通过则返回继续修改，通过这样的推拉式设计，力求需求交付自动化跑起来。

三、全链路拆解

3.1 需求侧：产运研协同方式升级

之前：产品经理需要人工梳理跨域交互逻辑和边界条件，PRD 完整性高度依赖个人经验，写完还要经历 MRD 评审、PRD 评审、视觉评审多轮拉齐，发现问题就整体再来一轮。历史需求文档、业务规则散落各处，产品写新需求时无法复用，研发拿到 PRD 产出技术方案时，也常因信息缺失反复回头找产品确认。

现在：我们构建了一个需求自动生产的工作台，该工作台在已有领域知识库的支撑下（包含历史 PRD、行业材料、业务规则、领域概念等）------产品经理可以通过和 agent 对话澄清需求，平台自动生成 PRD 和结构化需求（EARS/BDD）。并一键流转研发，整个需求侧从"多轮评审 + 人工对齐"变为"知识库驱动生成 + 原型确认 + 绑定 team 一键流转"。

3.2 Spec 阶段：需求交付模式升级

之前：从 PRD 到技术方案这一步完全靠人工。开发者需要自行翻查上下游服务的接口文档，逐一判断哪些服务会受影响------当前业务链路相互交织，光是理清影响范围就耗费大量时间。方案设计高度依赖个人经验，不同人产出的方案在深度和完整性上差异极大，写完还需要经历技术方案评审，评审中发现的遗漏和错误会触发返工，一轮下来消耗时间极长。更麻烦的是，历次需求积累的接口理解、架构决策散落在个人脑子和随手记的文档里，下一个类似需求来了依然从头再来。

现在：构建当前系统的领域知识（知识库由领域负责人一次性初始化，从存量代码中挖掘系统 API、数据结构和业务调用链，从历史 PRD 和技术方案文档中抽取业务规则、功能边界和历史架构决策，整合各业务域的功能入口与关键逻辑），基于领域知识，AI 可以自动完成上下游接口解析，结合代码调用图谱在相关服务中精准定位本次变动点，自动推导出接口依赖关系和影响范围，并一键生成 proposal.md + design.md + tasks.md 结构化需求三件套。整个 Spec 阶段变为"知识库驱动、自动生成、review 门控流转"。

3.3 Dev 阶段：开发阶段

之前：真正动手写代码之前，开发者还要面对一道门槛：B&M 端系统经历了 5 年以上的迭代演进，积累了大量技术债务，不同人的编码风格混杂其中，每个业务域都有自己的规则和历史包袱。开发者需要人工阅读存量代码、理解已有业务逻辑，才能判断本次需求在哪里改、改什么、改多少，哪些地方会产生连锁影响。对于复杂的业务场景------无论是涉及流程编排节点配置、还是跨域业务规则调整------梳理成本极高，高度依赖个人对系统的熟悉程度。即便是有经验的开发者，提测后也容易出现漏改、错改、重复配置等问题，反复触发返工。

现在：在当前的研发流水线中，tasks.md 中的编码任务已包含从 Spec 阶段自动推导出的变动点和影响范围：直接消费 spec 产出的 task.md 任务清单按序执行编码。领域知识库沉淀了存量系统的 API 定义、数据结构、业务调用链和历史架构决策，AI 在编码时始终在这套上下文约束下工作------自动识别本次改动涉及的业务规则边界、判断哪些逻辑需要新增或调整、哪些存在配置冲突或漏改风险。通过测试驱动方式进行开发，每个功能都有验证，新同学也能依托知识库快速进入状态，真正做到改得准、改得稳。

3.4 Test 阶段：测试阶段

之前：进入测试阶段后，测试同学需要人工编写测试用例、手动准备测试数据。一个需求涉及的业务路径众多，用例覆盖依赖测试同学对需求的理解深度，容易出现覆盖不全、边界场景遗漏的情况。测试数据的准备同样费时费力，不同业务域的数据之间存在依赖关系，构造一条完整的可测链路本身就是体力活。测试发现 bug 后，开发者需要重新介入排查修复，再等下一轮提测，多轮循环下来测试周期被拉得很长，整个阶段的协同等待消耗占比极高。

现在：整个测试阶段从"人工写用例 → 手动准备数据 → 等待修复 → 再轮回归"变为"通过 skill 生成 → 执行 → 问题自动闭环"的高效流转。基于结构化需求（BDD/EARS）和本次变动的影响范围自动生成测试用例，覆盖主流程、异常路径和边界场景。测试数据结合领域知识库自动构造，理解各业务域之间的数据依赖关系，自动准备完整可用的测试链路。基于变更功能点分析，可以进行多端精准回归、生成高覆盖边界用例、并通过 AI 进行全路径遍历探索和跳转链路验证，确保识别全、覆盖全、执行快。bug 自动记录定位，测试同学回传测试报告后，直接驱动修复流程，循环迭代直到无 bug 为止。

3.5 Oncall 阶段：日常线上运营

之前：日常 oncall 时线上告警或用户反馈问题后，oncall 同学需要在日志平台逐一捞日志、过滤关键字、根据 traceId 分析日志链，对照代码逐行分析，在复杂链路中定位问题根因往往需要大量时间。涉及多服务联动的问题更难排查，需要拉上多个域的同学一起看，协同等待消耗极高。

现在：在当前流水线中，oncall 排查由 skill 统一接入日志源，运行时日志和链路上下文自动注入大模型，直接在运行态完成多服务日志的关联分析和根因定位，不再需要在多个平台之间来回切换。定位到根因后，agent 结合代码调用图谱和领域知识库，自动圈定最小影响范围，形成有链条证据支撑的修复方案（问题日志 → 根因分析 → 影响范围 → 最小改动建议），而不是凭经验猜测改哪里。修复完成后自动在测试环境部署，并回捞日志验证问题是否消除，整个"告警 → 定位 → 最小范围修复 → 验证"的闭环在一个上下文里完成。
四、组织演进

只要使用了 AI 工具、搭建自动化的研发流水线，整个组织的研发效能就能提高起来？显然不是这样，组织效能是一个非常复杂的协同问题。

我们从《人月神话》开始讨论这个话题。书中有个经典命题：一个项目，假设原来需要 10 个人一年完成，能不能再加一倍的人，变成 20 个人半年时间交付？答案是做不到。命题所揭示的核心悖论在于，增加人力并不能线性缩短项目周期，原因在于人际沟通复杂度呈几何级数增长，且新成员缺乏系统上下文、需要高成本的知识传递。

书中另一个高频词是左移。以前大家一直说工程要左移------在问题出现之前就解决它。但为什么以前没那么好贯彻？从多年的工程经验来看，我们的看法是：左移的想法是对的，但投入太大、ROI 不够。左移本质上就是跨部门转移责任。也就是说，原来在右边承担责任的人，要把责任转移到左边，但左边的人接不接、认不认、有没有能力承担？这要付出巨大的软件工程能量，还有组织摩擦力。如果系统不具备很好的自动化能力，那么左移只是工作量的转移。

但是 AI 时代的到来，改写了这两道经典难题：

1. 在组织里加人会有低效的沟通问题，但加 AI Agent 就不一样了------Agent 可以无损地拿到上下文，能规模化地从已有代码里解析上下文，并不需要人与人之间低效的几何级数增长的沟通消耗。现在加 Agent 和原来加人是不一样的，原来的悖论在新时代的底层逻辑已经不同。

2. 关于左移：AI 时代里，原来那些上下文和知识资产，AI 可以从存量代码里抽取出来，再加上增量的 PRD、Spec 等上下文，业务复杂系统能够简化成一个大家可理解的上下文框架------无论对新成员还是不同岗位之间，都能在一个业务链路里更低成本、更高效地对齐。

所以在组织演进上，团队也尝试从职能分工型团队向超级个体型团队进行转型，这样的转型也对团队的分工和协作方式做了一些变化。

我们从如下五个维度来看组织演进带来的具体变化：

研发模式

之前：

• 运营、产品、研发、测试多角色参与，协作是其中最大的成本，相互等待是需求交付时间最大的消耗。

• 在需求交付过程中普遍要通过 MRD 评审、PRD 评审、技术方案评审、TC 评审、code review 等各个评审环节。

• 在代码实现环节，一个需求通常有前后端的开发，以及多个域的开发协同完成，其中需要完整周期的前后端联调和上下游联调。

现在：两种角色即可完成需求的全生命周期交付------产品经理和交付负责人（全栈）。

• 两个人开会讨论，并和 AI 对话形成结构化需求。

• 交付负责人会后和 AI 对话，生成技术方案、TC 和 plan，review 整体产出保证其正确。

• AI 自动化写代码、联调、测试（当前对中间产物需求人工验收、后续做到全自动化则可在凌晨让 AI 自动进行）。

• 产品经理验收。

领域负责人职责

之前：

• 存量系统业务复杂度极高，历史上积累了各种技术债务、不同人的编码风格；需要为生产稳定性负责，整个性能、可维护性都要关注。

• 领域负责人整理架构文档、通过技术方案评审和 code review 对领域的工程代码进行全面的约束和 review。

现在：在领域开启 AI coding 之前，领域负责人做该领域的初始化

• 从存量代码、PRD 里抽取上下文和知识资产；挖掘系统 API、数据结构和业务流程，再按照规约模板，引导 AI 生成结构化的 Spec 知识库。

• 配置当前的研发工作量、约束、校验条件。

需求左移

之前：

• 产品经理约会议，进行 MRD 评审，再进行 PRD 评审，然后再进行视觉评审。评审中有问题或者交付实现中提出新的功能点变动，整体再来一轮。

现在：交付负责人不再只是为了讨论需求细节，而是真正把精力关注到用户流程、产品价值和客户体验上。

• 通过 Zeta PM 工作台快速生成原型，原型作为直观载体并结合自动生成 PRD，做到"所见即所得"的需求确认，把原本上线后才发生的验收，前置到需求最左侧。

• 借助于领域知识的积累，在需求侧可以完整看到历史细节、改动影响，在这样的状态下，产品经理和交付负责人能从繁复的需求细节讨论中脱离出来，能真正把精力关注于客户价值和用户体验。

质量左移

之前：

• 测试左移之所以多年落地不足，本质不是方向不对，是成本太高、过程太重。

现在：AI 让覆盖度梳理变轻，让测试编写变快，也让质量左移从"正确但昂贵"变成真正可执行的工程实践。交付负责人通过 AI 工具自动化进行测试，通过把测试左移实现整体开发效率的提速。

• 测试工作的重心在测试用例的生成、测试数据准备和测试的执行。受益于 AI 用例生成、自动数据准备和 AI 自动执行，我们可以将测试阶段前置到研发阶段中，并打通 AI 问题定位和自动修复，循环迭代直到无 bug 为止，真正实现需求自动交付。

职责合并

之前：

• 当前技能深度是划分职能的主要依据------前端守前端，后端守后端，设计守设计，每个人在自身的技能领域里求极致。

现在：

• 产品经理、交互设计师、DA 三合一：负责从业务沟通到 Demo 确认，从业务意图到用户界面。

• 前端、后端、测试三合一：覆盖前端开发、数据结构、状态机、API、高可用和高可靠的问题，从业务模型到系统稳定性。

五、我们踩过的两个坑

1、坑一：不要花大成本去构建平台，而是去建立标准和流程

在我们团队一开始实践之初，我们花很长时间去讨论和实践开发一个平台让开发者去使用，但是这里有几个很大的问题：

• 去改变开发同学的习惯，大家难以接受

• 业界的方案、工具、skill 迭代非常快速，如果我们深度定制开发，既比不上业界迭代迅速，又没有业界的好用

造成这一问题的根本原因，一是开发者往往对重复造轮子有执念，且现在造轮子的成本越来越低；二是很多情况下一个横向的团队来推动，其必须有工具和平台作为组织的立身之本。

我们团队在这一块的解法是不建立平台但是建立标准，并通过极简的工具去监控，然后让工具和 skill 保留开放的能力。我们核心做两件事：

• 引入了研发流水线不同节点的正向推进和反向验收的流程，并强行通过两个 skill（delivery 和 review）把所有流程节点串联起来，然后中间使用的各个工具比如 openSpace、superPower 全家桶的选择都可以由领域负责人在初始化的时候自行选择和定义

• 强行把所有研发流程的数据收集上来，观察所有需求、技术方案、前端开发、后端开发、联调、测试、等待开发、等待提测......等各个阶段的耗时和自动化能力，然后通过管理的手段力求每个阶段做到非常高的自动化能力

2、坑二：Harness 好搭，但是领域实践困难

引入业界的 skill、直接用，或者在它基础上"魔改"，都不困难。但引入了工具、制定了流程，领域就能真正提效起来吗？结果往往不是。如果驱动工具和流程的还是人，那人与人之间的协作成本和摩擦永远不会消失。这一块我们团队的经验有两点：

• 建立领域自动化需求交付的观察体系，通过交付链路人工介入的次数判断领域的自动化能力，把这一指标列为考核模板

• 让真正懂业务的领域负责人进去看细节，review 知识库和 SOP，搭建和自定义自己的 workflow

六、给同行的避雷清单

• 不要花极大成本去构建平台，而是构建标准然后借助开源界的力量去解决平台工具的问题

• 领域知识的沉淀是极其重要的，研发提效三大核心要素"基模 + harness + 领域知识"。基模是属于全球 Top3 玩家的，harness 是属于开源界的，只有领域知识属于自己的。针对知识库，我们通过把所有的历史代码 + PRD + 技术方案构建出以流程、规则、实体为核心的领域知识层，用知识图谱的方式承载所有的领域知识。

• 能够使组织提效，在指标上我们最核心的是要求 AI 自动化率，即 AI 能接手人的工作、人需要介入几次。我们的判断是所有的复杂动作应该在 AI 在需求交付开始之前完成，让 AI 在写代码、做单测、做测试、发布上线的时候一定要达到极高的自动化比例。为了达成这一目标，一定的管理手段是必须的。

七、写在最后：工具提效与组织提效的双轮驱动

在工具提效上：更关注通过构建需求全生命周期的自动化交付能力使组织真正提效。

在组织结构上：关注全栈式超级个体的培养和实践，在横向组织维度减少职能部门使业务作战单元具备自闭环能力。

我们看到的指数级效率的提升，往往是因为第一步技术革命带来的效率的提升，进而倒逼组织结构发生调整，这样才能做到组织效率提升。反之，如果组织结构不调整，那么这会影响组织效率。所以站在组织提效的维度，必须从"工具提效 + 组织结构"两个维度一起看。

下面分两个维度梳理可复制的经验：

交付模式（工具提效）：

1. 需求提效：局部工具替换能产生局部加速，却无法带来系统性效能跃升。我们更需要关注整体需求研发交付全生命周期的自动化。如果不能做到真正自动化，就不能真正做到"指数级组织效率提效"。

2. 验证大于生产：摆脱生成代码的兴奋幻觉，站在领域负责人的角度去分解问题和验证阶段性产物。

3. 通过对抗式 AI Agent（一个往前跑，一个往后推）设计让自动化真正跑起来。

组织（组织结构）：

1. 纵向维度看：需求左移、测试左移，从流程分工式交付变为全栈式超级个体式交付。培养更好的领域负责人。领域负责人从"技术专家"→"领域专家"转变，从关注细节实现向关注用户流程、产品价值和客户体验转变。

2. 横向维度看：企业信息流转低效、协同内耗居高不下，本质症结在于组织架构设计、跨部门协作权责划分，同时受各部门在业务链条中的站位、当期业务发展阶段深度制约。AI 工具是个体的能力放大，那么两种实现存在可实施性：减少横向职能部门（算法、中台、效能、测试、前端），重组为资金、分销、运营平台等业务单元，推行阿米巴经营，这在 AI 时代将更容易实现。

八、团队介绍

快手电商商家和运营赋能中心技术团队，面向商家、达人与平台运营，覆盖全链路经营场景。团队定位为连接经营目标与系统能力的经营技术团队，聚焦商家经营与平台运营的智能化升级，由此降低经营成本、提升运营效率，驱动业务增长。

技术体系以智能经营闭环为业务主线，贯通经营场域的洞察、决策、执行与复盘归因；数字员工，即面向平台运营的 AI 运营智能体，是规模化运营载体。AI、数据智能与 B 端平台构成技术底座，并以 AI 原生研发方式支撑从业务判断到产品验证的迭代。

「参与互动，赢取好礼」

你工作中 AI 真正能独立完成的部分，能占到几成？如果 AI 把写代码、测试、发布的全流程都接管了，你最舍不得交出去的是哪一步？欢迎在评论区留言！我们将从留言中选取 3 位幸运同学，分别送出 1 个「马宝宝生肖挂件 牛仔小快」！

【活动推荐】