导读
AI-Coding时代，质量管理的核心从"是否管"转向"如何管"。通过建立Harness工程基础设施与全栈能力组织形态，结合三层约束框架（输入/生成/输出），可系统化提升AI生成代码的质量与可控性。RD与QA的协作目标对齐为"让AI代码安全上线"，协作模式从线性交接升级为闭环共建，QA左移至标准制定阶段，RD输出标准化Spec，共同实现测试效率提升与交付质量保障。三类项目实践表明，该方法能显著压缩开发周期、提升异常发现速度、增强系统可维护性，为组织级AI-Coding质量管控提供了可行路径。
01 背景
1.1 AI-Coding质量命题分析 - 代码生成效率、线上稳定性、交付周期 的关系
1.1.1 AI-RD 和 AI-QA 为什么重要
基于 信通院
www.fxbaogao.com/view?id=533... 报告 整理
1.2 传统软件工程 VS AI coding 软件工程对比
1.3 AI Coding 现状(电商) 和 痛点
80% 的代码是 AI 生成的，质量已经不是"要不要管"，是"怎么管才管得住"。
数据使用维度 2026.4 vs 2026.01
02 概述：建立统一认知框架
核心结论：Harness 工程是基础设施，全栈能力是组织形态------这两个支撑起 RD 和 QA 的新协作模式。
关于 Harness 的三篇重要的博客：
HashiCorp : mitchellh.com/writing/my-... 2026.2.5 Harness 名字起源，驾驭工程；
Openai : openai.com/zh-Hans-CN/... 2026.2.11 , Agent-first, 5个月100万行代码实践；
Anthropic : www.anthropic.com/engineering... 2026.3.24 AI连续执行10个小时，完成可交付任务，大模型的上下文焦虑、生产验收分离；
2.1 核心公式
Agent = Harness + LLM
质量 = 输入约束 × 生成约束 × 输出约束
拉通 = RD 定义边界 + QA 定义标准 + 共建资产
03 实践 - 三种不同类型项目
我们的实践按项目复杂度递进：品牌卡 （传统迭代）→ 榜单 （架构改造）→ 穿搭助手（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 技术栈。传统模式下这类需求最容易卡在 "前几天熟悉业务"，多语言跨度对角色分工是巨大挑战。
平台地址：
ecom.baidu-int.com/search/bran...
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 定位、修复建议和回归验证中形成闭环协作，推动智能测试从"测试执行提效"升级为"研发测试协同提效"。
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 , 然后产出设计文档 ，进行整体revie
测试：
TDD驱动 ， 包含 unit / itp / e2e 多种测试任务
审计验证：13 算子三阶段审计，发现 3 个代码问题（1 高/1 中/1 低）已修复；13 项逻辑差异闭环（2 修复 / 3 TODO / 5 无需处理 / 3 不纳入）；Top2000 策略召回率 75%（PV 覆盖 95.5%）；上榜理由召回率 99%。
3.2.3 效果对比
<br><br>改造前：策略 → 人工 Excel → 多轮审核 → 手动脚本提交入库 → 流式同步<br>改造后：策略提交 → 平台批量任务 → eflow 算子生产 → 自动聚合 → 自动入库 → 自动同步<br>
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产出）；
对话评估****** [philandzhen.bcc-szzj.baidu.com:8960/\*\*\*(http:/...](https://link.juejin.cn?target=http%3A%2F%2Fphilandzhen.bcc-szzj.baidu.com%3A8960%2F***%255D(http%3A%2F%2Fphilandzhen.bcc-szzj.baidu.com%3A8960%2F) "http://philandzhen.bcc-szzj.baidu.com:8960/***](http://philandzhen.bcc-szzj.baidu.com:8960/)")
prompt调试 + 数据集管理：
全链路Trace ：整体情况概览 + 各阶段工具调用/tokens使用/耗时*** philandzhen.bcc-szzj.baidu.com:8000/trace?sessi...***
线上效果监控trace : 结合 日志埋点/采集 + 普罗米修斯大屏展
console.cloud.baidu-int.com/mtgrafana/p...
3.3.2 QA 智能测试
核心理念：人定义标准，AI 执行验证------把"经验驱动的人工判断"变为"规则驱动的 AI 自动校验"。
3.2.2.1 AI智能测试实践
用例生成
痛点
· 手工用例生成：需求文档 / 功能描述 / 技术文档（输入）→ AI 解析需求意图 & 业务规则 → 自动识别测试维度（功能点、边界、异常） → 生成结构化用例（用例名、前置条件、测试步骤、预期结果）→ 输出标准化用例集
方案
· 基于整库理解的接口用例生成：获取变更→变更分析→生成可执行参数→生成接口测试用例（覆盖边界值、异常值、典型值）
· 边界值、异常分支依赖个人经验，经验不足则大概率遗漏
· 测试维度拆解不系统，等价类划分不完整
· 新人上手慢，同一需求不同人写出的用例质量差异显著
收益
· 生成效率：天级（人工编写） → 小时级（AI 自动生成+人工review）
· 场景覆盖：依赖个人经验 → 系统化维度覆盖，减少盲区
· 一致性：风格各异 → 标准化输出，可直接复用
· 可维护性：手工更新 → 增量精准更新
效果示例
基于需求文档+技术文档的手工用例生成：
基于整库理解的接口用例生成：
功能测试
人负责定义标准，AI 负责执行验证。将"经验驱动的人工判断"转变为"规则驱动的 AI 自动校验"，实现测试能力从点覆盖到面覆盖的质变。
痛点：部分功能点逻辑验证场景多，手工测试耗时久
方案：
收益：分钟级完成人工需数小时的验证覆盖
交付AIQA
痛点
· 信息分散，协同低效：需求、进展、文档散落多个系统，项目成员无法快速获取全貌，频繁跨平台切换耗费大量时间
· 进展同步全靠手动：日报依赖人工收集汇总，信息滞后、遗漏风险高**
· 需求与项目割裂：需求卡片与项目群缺乏关联，无法快速溯源需求进展状态
方案
· 建设交付AIQA，将项目关键信息整合到侧边栏进行统一展示，自动统计项目进度并发送项目进展日报
收益
效果示例
04 RD/QA 协作 SOP
三个不同类型的项目，几个核心认知：
质量定义变了：以前"代码能跑"就算合格，现在还得知道它为什么能跑、生成过程合不合规、出问题怎么定位
协作目标对齐了：RD 要快交付，QA 要找 bug，两边天然有张力；但 AI 时代目标对齐了------让 AI 生成的代码安全上线，两边是队友
流程必须闭环：线性的开发→测试→上线兜不住 AI 代码的隐蔽风险，得在生成前定标准、生成中实时管控、生成后复盘
05 后续计划
5.1 团队
-
小组：持续提升团队内成员 AI工具使用技巧， 激发同学的主观能动性，针对实际业务痛点，沉淀标准，落地工具；
-
部门：协同其他角色同学一起在具体场景落地相关Agent助手、工具能力，逐步积累经验和信心； 由点及面逐步进行落地完善；
5.2 业务
空间维度：点
能力维度：标准化
核心目标：验证可行性，输出标准
核心产出：规范、流程、清单
进展：
给大模型做好知识导航， 完善AGENTS.md ， 根据具体业务场景，沉淀SOP ，针对性创建skills；
指导思想：5.14 claude.com/blog/how-cl...
实践落地：部分skill 工具示例
空间维度：线
能力维度：工具化
核心目标：打通单链路，固化标准
核心产出：工具、数据、闭环
进展：
电商搜索小助手、上线check工具、搜索诊断工具 、报警诊断修复工具； 针对不同场景的工具逐步完善；
空间维度：面
能力维度：平台化
核心目标：全组织推广，能力复用
核心产出：平台、中台、知识库
进展：
平台化对应能力，存量业务/代码 进行配置化改造 ； 增量能力，针对具体场景，沉淀对应平台能力；逐步将各种工具能力接入，逐步落地为基础建设，向中台化演进；
电商搜索平台能力概览：
Agent-eval平台能力：
空间维度：网
能力维度：智能化
核心目标：组织级智能，自主进化
核心产出：智能体、自治系统
进展：探索中