电商搜索H1提升AI-Coding质量实践 RD & QA

导读

introduction

AI-Coding时代，质量管理的核心从“是否管”转向“如何管”。通过建立Harness工程基础设施与全栈能力组织形态，结合三层约束框架（输入/生成/输出），可系统化提升AI生成代码的质量与可控性。RD与QA的协作目标对齐为“让AI代码安全上线”，协作模式从线性交接升级为闭环共建，QA左移至标准制定阶段，RD输出标准化Spec，共同实现测试效率提升与交付质量保障。三类项目实践表明，该方法能显著压缩开发周期、提升异常发现速度、增强系统可维护性，为组织级AI-Coding质量管控提供了可行路径。

全文 4343 字，预计阅读时间 6 分钟

GEEK TALK

背景

1.1 AI-Coding质量命题分析 - 代码生成效率、线上稳定性、交付周期的关系

1.1.1 AI-RD 和 AI-QA 为什么重要

基于信通院 [【中国信通院】AI4SE行业现状调查报告（2026年）]

https://www.fxbaogao.com/view?id=5333095 报告整理

1.2 传统软件工程 VS AI coding 软件工程对比

1.3 AI Coding 现状(电商) 和痛点

80% 的代码是 AI 生成的，质量已经不是"要不要管"，是"怎么管才管得住"。

数据使用维度 2026.4 vs 2026.01

GEEK TALK

概述：建立统一认知框架

核心结论：Harness 工程是基础设施，全栈能力是组织形态——这两个支撑起 RD 和 QA 的新协作模式。

关于 Harness 的三篇重要的博客：

HashiCorp : https://mitchellh.com/writing/my-ai-adoption-journey 2026.2.5 Harness 名字起源，驾驭工程；

Openai : https://openai.com/zh-Hans-CN/index/harness-engineering/ 2026.2.11 , Agent-first, 5个月100万行代码实践；

Anthropic : https://www.anthropic.com/engineering/harness-design-long-running-apps 2026.3.24 AI连续执行10个小时，完成可交付任务，大模型的上下文焦虑、生产验收分离；

2.1 核心公式

Agent = Harness + LLM

质量 = 输入约束 × 生成约束 × 输出约束

拉通 = RD 定义边界 + QA 定义标准 + 共建资产

GEEK TALK

实践 - 三种不同类型项目

我们的实践按项目复杂度递进：品牌卡（传统迭代）→榜单（架构改造）→穿搭助手（Agent 系统）。

共同点是 Harness 工程 + 全栈能力，差异在 RD/QA 协作侧重点

3.0.1 三类需求概览：

3.0.2 不同类型项目 AI流程改造方式：

3.1 品牌卡迭代 — 传统产研项目

High light:

老人接新业务：4 代码库 / 3 技术栈（Go/Python/Vue）/ 1 人全栈→ 技术评审时已完成研发50%+，整体周期减少20%+

3.1.1 项目背景

品牌卡内循环商家入驻需求，是典型的 "老人接新业务"场景，技术架构涉及在线、离线、运营平台 4 代码库 + 3 技术栈。传统模式下这类需求最容易卡在"前几天熟悉业务"，多语言跨度对角色分工是巨大挑战。

△ 产品需求

△ 研发实现 - 配置平台

平台地址：

https://ecom.baidu-int.com/search/brand/brandShopMapping

3.1.2 核心解法：Harness 三件套 + 全栈 + 平台化

通过对应手段，该项目在整体技术调研、开发、联调阶段时间周期由10人/天降低至了 4人/天。

3.1.3 RD&QA 智能测试协同

通过 RD 与 QA 在需求理解、Spec 前置评审、AI 辅助 Case 生成、Bug 定位与边界验证等环节形成协同闭环，实现了测试效率和交付质量的同步提升。本次测试中，原计划排期 3 天的测试任务，服务端测试仅用 1.5 天便完成，测试周期压缩约 30%。

****RD 前置输出标准化 Spec 文档：****RD 基于业务需求和技术实现方案，提供规范化的技术 Spec，明确功能逻辑、数据流转、接口约束、异常处理及边界场景，为 QA 测试设计提供清晰输入。
****QA 基于 Spec 快速生成测试 Case：****QA 结合 RD 提供的 Spec 文档、搜索电商后端用例生成SKILL 以及 AI 能力，分钟级生成高覆盖度测试 Case，提前识别核心验收标准和潜在风险点。
****RD 与 QA 共同提升 Bug 定位与修复效率：****在测试过程中发现 Bug 后，QA BugFix 数字员工可自动响应，基于 AI 快速完成问题归因分析和代码修改建议。QA 能够带着更明确的问题定位和修复思路与 RD 沟通，减少反复确认成本。
****QA 自主完成边界场景验证，减轻 RD 支持成本：****过去边界场景验证高度依赖 RD 解释和协助，现在 QA 可基于 Spec、AI 生成能力和代码理解能力，自主完成边界 Case 设计与验证，边界 Case 测试效率提升约 60%。
****形成 RD 与 QA 双向协作闭环：****RD 通过规范化 Spec 提升需求与技术表达质量，QA 通过 AI 更高效地理解业务逻辑、定位关键代码并反馈高质量测试结果。双方在需求评审、Case 生成、Bug 定位、修复建议和回归验证中形成闭环协作，推动智能测试从“测试执行提效”升级为“研发测试协同提效”。

△ Bug Fixed

△ 基于 Spec 用例生成

3.1.4 关键洞察

业务熟悉从天级压到小时级，意味着团队对插入需求和陌生方向的承接能力变强了。

变化本质：以前先写方案等产品确认再开发；现在边调研边开发，拿着实际跑起来的 Demo 去对齐，需求澄清来回次数明显减少。

3.2 榜单自动化 — 架构改造项目

High light : 1 RD × 6 周→ 完整数据生产 & 评估流程打通；涉及8 代码库 / 3 技术栈；13 算子；含在线/离线/评估/算子多技术栈系统。

3.2.1 项目痛点

原流程：策略+人工线下评估 → 平台入库上线。数据流跨 4 层存储（content-platform → rank-strategy → ecbase → SNDB），全链路靠人串。

实际效果：平台能力示例

ecbase内容生产平台

eflow算子平台

3.2.2 解决方案：算子化架构 + Harness 约束 + 开发/测试模式变更

3.2.2.1 算子化架构 + Harness 约束

算子化架构（13 算子）：

Harness 工程约束****：****

技术选型：Python 3.14 + eflow-operator + Pydantic Settings + OpenAI SDK + instructor + ruff/mypy/pytest 三重检查 + doubao-seed（主）/ deepseek-r1（降级）

开发：

使用工作区模式，提供更多的更准确的上下文给到大模型，先统一沉淀各模块系统wiki , 然后产出设计文档，进行整体review

△ 架构文档统一沉淀梳理

△ 整体方案Review

测试：

TDD驱动，包含 unit / itp / e2e 多种测试任务

审计验证：13 算子三阶段审计，发现3 个代码问题（1 高/1 中/1 低）已修复；13 项逻辑差异闭环（2 修复 / 3 TODO / 5 无需处理 / 3 不纳入）；Top2000 策略召回率75%（PV 覆盖 95.5%）；上榜理由召回率99%。

3.2.3 效果对比

改造前：策略 → 人工 Excel → 多轮审核 → 手动脚本提交入库 → 流式同步
改造后：策略提交 → 平台批量任务 → eflow 算子生产 → 自动聚合 → 自动入库 → 自动同步

3.2.4 RD & QA 协同

QA 必须左移到数据契约定义阶段：

测试重点变了：从"测功能" →"测数据正确性和链路可靠性"
介入时机变了：从接口写完后测试 →算子接口定义时就参与
关键产出：数据契约定义、链路可回滚性测试、算子审计标准
协作模式：与 RD 共同制定算子 I/O 规范，确保数据一致性

3.3 穿搭助手 — Agent 项目 ⭐

Agent 项目最能体现 RD/QA 协作的本质变化，且涉及完整工程闭环。

3.3.1 研发阶段→ 4 项平台能力

核心理念：好的 Agent 是不断迭代、评估出来的；可观测、可追踪至关重要。传统的中台 Agent 平台业务适配差，自己造轮子在模型+harness 工程成熟的今天，成本已经很低。

调研期间：调研期间同时完成项目demo 编写（前后端、可交互的原型），技术详设时直接使用主对话Agent的实际工程效果进行评审（RD产出）；

△ 产品需求

△ 技术详设-RD产出的交互图	△ 技术详设-RD产出的交互图

对话评估http://philandzhen.bcc-szzj.baidu.com:8960/

△ 对话评估-测试用例	△ 评估结果列表	△评估详情 - 实际产品效果+性能分析

prompt调试 + 数据集管理****：****

△ 数据集管理

全链路Trace ：整体情况概览 + 各阶段工具调用/tokens使用/耗时

http://philandzhen.bcc-szzj.baidu.com:8000/trace?session=da7ec441-367d-495f-9f8b-77ce5ac9605c

线上效果监控trace : 结合日志埋点/采集 + 普罗米修斯大屏展

https://console.cloud.baidu-int.com/mtgrafana/p/d/S4PdKN2Dk/chuan-da-zhu-shou?orgId=467&var-ds=Prometheus%E7%9B%91%E6%8E%A7&var-tool_name=All&from=1776700800000&to=1776787199000&var-cluster=All&var-namespace=All

3.3.2 QA 智能测试

核心理念：人定义标准，AI 执行验证——把"经验驱动的人工判断"变为"规则驱动的 AI 自动校验"。

3.2.2.1 AI智能测试实践

用例生成
痛点

· 手工用例生成：需求文档 / 功能描述 / 技术文档（输入）→ AI 解析需求意图 & 业务规则 → 自动识别测试维度（功能点、边界、异常） → 生成结构化用例（用例名、前置条件、测试步骤、预期结果）→ 输出标准化用例集
方案

· 基于整库理解的接口用例生成：获取变更→变更分析→生成可执行参数→生成接口测试用例（覆盖边界值、异常值、典型值）

· 边界值、异常分支依赖个人经验，经验不足则大概率遗漏

· 测试维度拆解不系统，等价类划分不完整

· 新人上手慢，同一需求不同人写出的用例质量差异显著

收益

· 生成效率：天级（人工编写） → 小时级（AI 自动生成+人工review）

· 场景覆盖：依赖个人经验 → 系统化维度覆盖，减少盲区

· 一致性：风格各异 → 标准化输出，可直接复用

· 可维护性：手工更新 → 增量精准更新
效果示例

基于需求文档+技术文档的手工用例生成：

基于整库理解的接口用例生成：

功能测试
人负责定义标准，AI 负责执行验证。将"经验驱动的人工判断"转变为"规则驱动的 AI 自动校验"，实现测试能力从点覆盖到面覆盖的质变。
****痛点：****部分功能点逻辑验证场景多，手工测试耗时久
方案：
****收益：****分钟级完成人工需数小时的验证覆盖

交付AIQA
痛点

· 信息分散，协同低效：需求、进展、文档散落多个系统，项目成员无法快速获取全貌，频繁跨平台切换耗费大量时间

· 进展同步全靠手动：日报依赖人工收集汇总，信息滞后、遗漏风险高

· 需求与项目割裂：需求卡片与项目群缺乏关联，无法快速溯源需求进展状态
方案

· 建设交付AIQA，将项目关键信息整合到侧边栏进行统一展示，自动统计项目进度并发送项目进展日报