|
研发测试AI工程化实战 把AI变成可测试、可复用、可管控的团队能力 课程背景： 很多研发团队已经开始使用AI：写代码、写用例、分析日志，打包发版等。但这些尝试大多停留在个人层面，没有沉淀成团队可复用的方法。会用AI，和把AI用进稳定的研发流程，是两回事。 落到具体岗位，问题很快变得现实：研发不敢把AI代码直接合进主干，测试拿不准AI用例覆盖够不够， 大数据担心口径算错，ERP开发担心业务规则跑偏。管理层真正关心的，也不是大家会不会用工具，而是这些零散尝试能不能变成稳定、可控、可推广的团队能力。 本课程围绕前端、后端、测试、BI、运维等岗位场景，带团队走完从能力边界、 智能体搭建、 智能体测试到多 智能体探索的路径。主线是半自动优先，结果可审，过程可控，把AI从个人尝鲜推进到团队级研发测试能力。 课程收益： 1. 建立研发测试团队的AI使用共识：清楚哪些任务适合交给AI，哪些必须人工兜底 2. 形成岗位级AI场景清单：不同研发岗位都能识别2–3个可落地场景 3. 掌握一个可复用的 智能体搭建流程：从需求分析、提示词、知识库、工具到测试调试与优化 4. 把测试团队从“AI使用者”升级为“AI质量守门人”：会设计测试样本、检查幻觉、验证权限、跑回归 5. 理解多 智能体的适用边界：知道什么时候一个 智能体加工具就够，什么时候才值得复杂化 课程时间：1-2天，6小时/天 课程对象：技术总监、前后端开发、测试、 大数据开发工程师，及相关技术负责人与项目骨干 课程方式：方法讲解+现场演示+统一样板分组实操（分岗位改造）+可复用成果交付 课程大纲 第一讲：边界认知搭建——厘清研发测试AI能力边界，建立标准化使用纪律与选型方法 一、掌握AI优劣势，落地研发流程风控底线 1. 优劣甄别：会生成、会归纳，弱在精确计算与事实保真 2. 风险预判：代码可能藏bug，口径可能算错，事实可能是编的 3. 流程底线管控：全程人工审核、结果可复测、异常可回滚 二、搭建自研选型框架，按需匹配低成本高适配模型 1. 框架自建 2. 多维研判选型（六维综合评估） ——模型能力、使用成本、上下文承载力、工具调用能力、私有化适配、数据安全边界 3. 场景适配匹配 ——实行分级选型策略 模型样本：GLM、豆包、通义、 DeepSeek、GPT、Claude、Gemini4. 模型池储备 三、拆解多岗位高频场景，制定AI标准化使用纪律 1. 五类岗位高频场景 第一类：前端页面/组件 第二类：后端接口/SQL 第三类：测试用例/数据 第五类：ERP规则/配置 2. AI编程助手使用纪律：生成→审查→测试→入库 工具样本：Cursor、Codex、ClaudeCode、Copilotcodingagent、通义灵码、Trae。 案例：从一段需求说明，到接口草稿、测试用例与前端原型——一个场景看清五岗落点。 讨论：哪些环节AI能写，哪些必须人来把关？ 第二讲：智能体工程化搭建——全流程实战搭建可测试、可迭代、可管控的岗位智能体 一条回路：感知→规划→记忆→行动。 ——搭之前先想清楚输入、知识、工具、输出 二、分级匹配落地工具 1. 低代码平台，快速验证：百炼、Coze、Dify、HiAgent 2. 研发执行环境，承接真实流程：Codex、ClaudeCode、Cursor、OpenHands、OpenCode 3. 自研编排样本，系统内嵌：LangGraph、LlamaIndex等 选择原则：先跑通、再下沉，先低门槛、再工程化 1. 需求分析：把想法拆成可执行任务 1）输入材料：需求文档、接口说明、业务规则、样例数据 2）输出结果：问答、草稿、检查清单、操作建议 3）责任边界：AI处理什么，人确认什么，失败如何兜底 2. 提示词设计：任务、边界、格式、示例、校验 2）输出格式：让结果可复制、可检查、可进入流程 3）校验规则：让模型遇到不确定内容先提示而不是编造 3. 知识库构建：清洗、切分、来源标注、召回检查 1）资料准备：去掉过期、重复和冲突内容 2）切分策略：按主题、流程、规则或问答场景组织 3）召回检查：验证答复是否来自正确资料 4. 工具调用：从“会说”到“会做”的风险控制 1）最小权限：只开放当前任务必须使用的能力 2）调用留痕：记录工具输入、输出和异常 3）人工确认：写入、提交、删除等关键动作必须兜底 1. 测试样本：正常、边界、错误输入 1）正常样本：验证基础任务能否稳定完成 2）边界样本：验证规则临界点和复杂组合 3）错误输入：验证拒答、澄清和风险提示 2. 专项检查：幻觉、召回、权限 1）幻觉检查：识别无来源、编事实、编规则 2）召回检查：验证知识库是否找到正确资料 3）权限检查：验证工具是否越权或误操作 3. 回归与量化：答对率、出错率、失败边界。 4. 可选工具：Ragas、promptfoo、Langfuse、LangSmith 1. 统一样板：测试用例生成助手/研发知识库问答助手 1）前端/后端组：围绕接口、页面、代码解释改造 2）测试组：围绕用例、数据、缺陷复现改造 3） 大数据/ERP组：围绕口径、规则、配置校验改造 2. 实战流程：搭建→测试→优化 案例：智能问数为什么不能裸用NL2SQL。 第三讲：多智能体进阶落地——按需轻量化搭建，规避过度设计（聚焦供应链） ——一个agent+工具能解决的，就别上多 智能体——过度设计最常见、也最贵 适用场景：长任务链、多角色、多系统、需仲裁 核心分工：检索、分析、生成、校验、执行 二、角色分工与冲突处理 1. 角色拆分 1）主控角色：拆任务、排顺序、汇总状态 2）执行角色：查资料、跑工具、生成草稿 3）校验角色：检查事实、规则、权限和风险 2. 冲突处理 1）仲裁角色 2）优先级规则 3）人工兜底 3. 研发Harness ——Codex、ClaudeCode、Cursor、 openclaw、OpenHands、OpenCode 总结：工具承接执行，治理仍靠团队 三、落地的现实约束 1. 权限与数据安全：数据流向、可见范围、操作边界 2. 成本与性能：调用次数、响应延迟、可观测性 3. 私有化部署：适用场景、代价与门槛 1. 供应链案例 1）订单角色：识别异常类型和影响范围 2）库存/物流角色：核查可用量、在途和延迟风险 3）处置角色：生成建议并交给人工确认 2. 关键判断：先做扎实单agent，再拆多 智能体1. 候选场景选择：结合本岗位系统或业务流程 2. 输出模板：场景、痛点、必要性、角色分工、数据工具、风险、兜底、MVP 3. 评审重点：是否真需要多 智能体，是否存在过度设计
| 
