企业官网建设流程全解析

1. 如何让 AI 理解业务需求？

核心逻辑：AI 不会自发“懂业务”，本质是语义匹配而非业务认知，必须通过「结构化输入 + 领域锚定 + 多轮校验」的工程化手段，把隐性需求显性化、模糊需求明确化，引导AI对齐业务语义。

落地方法：

1. 需求结构化预处理：把自然语言大段需求拆解为标准化字段：业务目标、角色权限、前置条件、输入输出约束、验收标准、异常处理规则，避免散文式模糊描述。
2. 领域知识锚定：通过RAG注入企业业务术语词典、业务规则库、历史需求范例、行业规范，对齐企业内部黑话、默认约定和领域规则，解决通用大模型不懂行业语境的问题。
3. 歧义前置自检：要求AI输出需求理解清单的同时，自动识别前后矛盾、概念模糊、约束缺失等显性歧义点，输出疑问清单，先澄清再推进。
4. Few-shot 范例对齐：注入1~2个同业务场景的优秀需求拆解范例，对齐输出格式、拆解粒度和业务视角。
5. 人工复核闭环：核心业务需求必须人工确认理解结果，再进入后续环节。

能力边界：AI仅能对齐显性化需求，无法识别行业隐性潜规则、跨部门默认约定，复杂业务场景必须人工兜底。

2. 如何保障 AI coding 的质量（AI 生成脚本 / 代码）

核心思路：全流程三层管控，不相信单次生成结果，从生成前约束、生成中控制、生成后校验建立完整质量门禁。

生成前：约束前置，规范注入

• 明确输入边界：输出目标、技术栈、编码规范、命名规则、异常处理要求、禁止项（如禁止硬编码凭证、禁止使用废弃API），不能只说“写个登录脚本”。
• 规范上下文注入：把团队编码规范、公共函数库、Skill封装规范、最佳实践作为上下文注入，避免风格混乱、重复造轮子。

生成中：多步生成，内置自检

• 分步生成：先输出结构设计，再编写核心逻辑，最后补充异常处理与注释，避免一步输出的逻辑漏洞。
• 自校验指令：要求生成后先自查语法、边界条件、逻辑一致性，输出自检结果。
• 高风险场景双模型互校：核心逻辑用两个不同模型分别生成，交叉比对差异。

生成后：多层校验，强制门禁

1. 静态校验：语法检查、Lint 扫描、安全漏洞扫描，自动拦截低级错误。
2. 单元验证：自动生成对应单元测试用例，执行验证功能正确性。
3. 分级人工复核：核心逻辑、高风险代码100%人工评审，非核心代码抽样复核。
4. 资产沉淀：通过的代码纳入代码库，优秀范例加入 Few-shot 库，持续优化生成质量。

3. AI 自动化测试的思路？

核心定义：AI 自动化测试 = AI 智能编排 + 原子化 Skill 执行 + 自动化流水线底座，是对传统脚本式自动化的升级：把“人工写脚本”变成“AI编排能力、自动生成用例、智能执行分析”。

四层核心思路

1. 需求层：AI 解析自然语言测试需求，拆解测试点，识别歧义，输出结构化测试范围与优先级。
2. 用例层：AI 自动设计测试场景、生成测试数据、输出标准化用例，人工复核校准，效率远高于纯人工设计。
3. 执行层：AI 匹配调用原子化 Skill，自动编排执行流程，驱动 Playwright、接口测试框架等底层工具执行；内置防环、熔断、重试等安全管控，避免执行失控。
4. 分析层：AI 自动读取执行日志、错误栈，匹配历史故障库，初步定位失败根因，生成测试报告；自动沉淀 bad case 进入用例库，形成质量闭环。

和传统自动化的核心区别：传统是脚本驱动，维护成本高、响应变更慢；AI 是能力编排驱动，复用率高、上手门槛低、适配变更快。

4. AI 应用的测试思路是什么？（大模型类产品，RAG 智能客服、AI 问答助手）

核心原则：分层解耦测试 + 概率化断言 + 基准集回归 + 正负向结合，和传统软件测试的核心差异是：输出为概率性，不能用固定字符串断言，质量是相对基线的量化评估，而非绝对的“对/错”。

五层测试体系

1. 底座能力基准测试
   验证模型本身的基础能力：推理、知识、指令遵循、基础安全，用 TruthfulQA 等通用基准集，先确认模型底座达标，避免把模型原生问题当成业务问题。
2. 组件层专项测试（RAG 核心）
   • 检索层：固定查询集，测召回率、精确率、排序质量，完全排除生成模型干扰。
   • 生成层：固定召回上下文，测忠实度、幻觉率、指令遵循、虚假引用，完全排除检索质量干扰。
3. 端到端业务测试
   模拟真实用户场景，测整体业务效果：业务正确率、问题解决率、多轮对话一致性、交互流畅度。
4. 安全合规专项测试
   提示词注入、敏感信息泄露、权限越权、行业合规校验，是企业级 AI 应用的一票否决红线。
5. 性能稳定性测试
   并发延迟、吞吐量、长对话稳定性、服务降级容错、海量知识库下的检索性能。

配套方法：用 Golden Set 黄金测试集做版本回归，用 LLM-as-Judge 做自动化评测，用语义相似度、核心要素命中替代固定字符串断言。

5. 什么是 Skill？在 AI 测试中 Skill 能解决哪些实际问题？

定义

Skill 是原子化、参数化、可复用、可编排的标准化能力封装，是 AI / Agent 可以直接调用的最小执行单元。它不是大模型原生能力，是工程层面把重复的操作、逻辑、工具调用封装成的标准“技能包”，遵循统一输入输出协议，可通过 MCP 等协议被大模型直接调用。
核心特征：单一职责、参数驱动、标准输出、内置容错、可编排、可复用。

AI 测试中解决的6类核心实际问题

1. 解决重复开发问题：登录、查询、断言、评测等通用操作只封装一次，全场景复用，避免每个脚本重复编写相同逻辑。
2. 降低维护成本：一处修改全量生效，不用同步修改散落在几百个脚本中的重复代码，维护成本降低60%以上。
3. 降低上手门槛：业务测试人员无需精通代码，通过组合 Skill 就能搭建业务测试用例，实现低代码自动化。
4. 解决AI执行失控：Skill 内置防环、重试、熔断、失败留证等安全管控，AI 只能调用标准能力，不能随意执行操作，从机制上避免“AI发疯”。
5. 提升编排效率：Agent 可直接识别需求，匹配组合 Skill 快速生成执行链路，不用从零编写脚本，用例搭建效率提升3~5倍。
6. 标准化集成：统一协议的 Skill 可无缝接入不同 Agent、流水线、测试平台，避免厂商绑定。

测试领域典型 Skill 示例

需求解析 Skill、检索指标计算 Skill、忠实度评测 Skill、Playwright 登录 Skill、接口调用 Skill、日志分析 Skill、测试报告生成 Skill。

6. RAG 做 AI 测试会存在哪些常见缺陷，怎么规避？

以下是 RAG 应用测试中行业普遍存在的测试误区、缺陷，以及对应规避方案：