ARTICLE · 1069783
我把整个系统喂给 AI 后,回归范围不用再拍脑袋了
我把整个系统喂给 AI 之后，回归范围不用再拍脑袋了
不是让 AI 写用例——是让 AI 先看懂你的仓库、接口和库表，再开口。
一、凌晨两点，你得答上来的三个问题
线上有个字段的值不对。负责人在群里问你三句话：这个值是从哪几个页面写进去的？哪些接口在读它、哪些接口在写它？这次改动，回归到底要覆盖哪些地方？
大部分人的第一反应是"我回去查一下"，然后花两天翻代码。不是不努力，是这份答案从来没写在任何文档里——它一半散在前端组件里，一半散在后端路由和数据库表里，还有一小部分只在某个人的脑子里。
01 ｜刚接手一个老系统，第一周全在问人："这个页面在哪？这个按钮叫什么名字？"
02 ｜改一个字段，没人敢说影响面。最后的做法往往是"那就全量回归一遍吧"。
03 ｜接口改了，不知道谁在调用，只能等线上炸了被人找上门。
04 ｜上线前那句"有没有漏测"，永远只能回答"凭我的经验应该没有"。
这四个问题的共同点是：答案都存在，但没有一处把它们放在一起。
二、缺的不是生成能力，是上下文
这两年所有人都在做一件事：让 AI 生成测试用例。但把需求文档丢给模型，它给你的往往是正确的废话——边界值、等价类、异常场景，放进任何一个系统都对，也就意味着对你的系统没用。
同样一个"修改用户手机号"，在一个有 3 张表、2 个服务调用的小系统里，和在 AITestX 这种 20 个业务模块 的系统里，要测的东西根本不是一回事。模型不知道你有多少模块、哪些接口读写这张表、这个字段在几个页面上被编辑——所以它只能给你通用答案。
所以我在平台里做的不是又一个"用例生成器"，而是一个知识库助手：先把仓库和数据库索引成一堆能被检索的对象，再让 AI 基于这些对象回答。
差别只有一句话：通用模型回答完你要自己去验证；它回答的每一句，都带着菜单路径、页面 URL、接口和表名——你可以拿来直接用，也可以一眼看出它错在哪。
三、它的底层是三层：对象 → 图谱 → 证据
这套东西不神秘，拆开就是三层。我按代码里真实的实现讲，路径都写在文末，你可以对着看。
第 1 层 · 把仓库拆成对象（19 类）
不是"把文档丢进向量库"。索引跑的是一条固定流水线：种子对象 → roadmap 文档 → 前端路由 → 后端 URL → 数据库 Schema → Django 模型 → 代码资产。
代码层用 ctags + semgrep 双工具链抽符号，工具没装就自动降级成正则方案；库表层走 schemacrawler + MySQL information_schema 双通道。19 种代码扩展名进得来，node_modules 这类目录有 22 项默认排除。
最关键的一条：读和写是分开建模的——正则把 from / join 判成"读"，把 insert / update / delete / merge 判成"写"。有了这个区分，"改一个字段会影响谁"才问得出来。
第 2 层 · 把对象连成图谱（12 类关系）
对象和对象之间用 12 类关系连起来：contains、calls、reads、writes、implements、references……于是"菜单 → 页签 → 页面 → 功能 → 操作项 → 接口 → 代码文件 → 库表 → 字段"这条链是查出来的，不是编出来的。
链出来之后，直接点开七张图看：页面功能图 / 页面-接口-库表字段图 / 接口关系图 / 数据库 ER 图 / 代码调用图 / 库表字段检索 / 幽灵代码排查。
第 3 层 · 把图谱变成能验收的回答
你问一句话进去，背后发生四件事：
① 中文按 2/3/4 元切词，再套 14 组业务同义词——你问"线上缺陷"，它能对上那张真实的表。
② 打分：整句命中 +12，名字全等 +10，名字子串 +6，正文命中 +2；再按类型加权，页面和页签权重最高，接口和表最低。
③ 取前 12 个对象，顺着关系做邻域扩展（最多 80 条边），把上下文补齐。
④ 组装成一份「知识库对象证据包」：命中对象、Roadmap 路径、双链关系、数据来源，外加一个 0.15–0.95 的置信度。
然后给模型套三条硬约束：只能基于证据包回答；涉及操作步骤必须给真实页面路径、按钮和字段；证据不足必须说清楚缺哪个对象——不许编。仓库还没索引过时，它直接返回置信度 0，告诉你"请先完成仓库配置并触发索引"。
工程上还有两个不起眼但必要的细节：索引是增量的（每个对象算哈希，没变的直接跳过，落"新增/更新/删除/未变"四个计数）；整个索引跑在 Celery 异步任务里，15 分钟硬超时、14 分钟软超时，不会把请求线程堵死。
四、落到测试身上，具体变了这六件事
1 ｜ 新人不再靠"问人"
问一句"创建缺陷在哪个页面"，它给出菜单路径、完整页面 URL、页签、表单标题、提交按钮、必填字段和默认值。带新人的时间成本，肉眼可见地掉下来。
2 ｜ 变更影响面不用翻两天代码
一个字段被哪些接口写、被哪些页面读，图谱直接列出来。评审会上你可以把清单甩出来，而不是说"我觉得应该都测"。
3 ｜ 回归范围从"全量"变成"可举证"
能列出受影响页面清单，也就意味着你能说清为什么不测另外三十个页面。这在以前是拍脑袋，现在是带证据的决策。
4 ｜ 漏测自查终于有了抓手
"幽灵代码排查"会标出：疑似没有页面调用的接口（高）、没有页签引用的组件（中）、只在库里有结构却没有任何代码读写证据的表和字段。这就是一份"从来没人碰过的地方"清单——而且是按严重程度排好序的。
5 ｜ 要口径、要数据、要图，一次给全
问统计口径，它按你的要求取真实数据，返回渲染好的柱状图或折线图（双轴、多系列都支持），不是给一份示例数据糊弄你。
6 ｜ 答错了能修，而不是重来
每次问答都留下一条记录（命中对象、证据、置信度）。答得不对，就挂一条「纠错/确认/补充」反馈，下次检索会带着你的修正走。你的经验第一次从"记在脑子里"变成"落在库里"。
补一句边界：幽灵代码那张清单，代码里明确写的是"疑似"，每条都附了处置建议（比如字段级误报率较高，建议结合 SQL/ORM 扫描和线上日志复核）。它帮你圈出怀疑对象，不做最终判决——这个判断权在你手上。
五、这些不是 Demo，是我自己的平台
AITestX · AI 测试平台本篇的知识库助手就在里面：apps/knowledge/ 一个应用 7000+ 行（models 312 / services 2207 / asset_insight 2426 / asset_scanner 1031），对外的 14 个接口全部带鉴权和项目级过滤。
AI 研发全链路平台AI 自动开发任务有 11 个状态节点、Docker 容器隔离执行、Celery 异步队列、Claude Code 接管 Git 的克隆/提交/推送。
AI Native OS把这一整套能力继续往系统级形态做。
这几样东西都是我用 AI Vibe Coding 一个人做出来的。上面每一个数字都能在代码里翻出来——这是我敢把它写成文章的唯一理由。
它在整个平台里的位置
AI 智能层：知识库助手（本篇）· AI 需求解析 → 用例生成 · AI 助手 · browser-use UI 自动化 · Claude Code 自动开发 · AI 自动部署
测试执行层：API / UI 自动化 · Celery 定时调度 · Allure 报告 · 用例与测试套件管理
平台支撑层：多 AI 模型适配 · Docker 容器隔离 · 私有化部署 · RBAC 权限
六、如果你想亲手做一遍
我开了一门 1 天 AI Vibe Coding 实战小班课，≤8 人，只做实战不纯讲理论。课上我会带大家做一个能跑的最小版知识库助手：把一个仓库索引成对象 → 建成带关系的图谱 → 问一句话能出带路径的证据包。做完你手上就有东西可以拿去演示，而不是一句"我会用 AI"。
课程安排 · 一天 · 6+ 模块 · 100% 动手
上午：定边界和目录结构 → 把 git 仓库接进来（本地路径 / 远程 / Token / SSH）→ 跑通第一条索引流水线下午：对象与关系建模（读写分开）→ 检索打分与证据包 → 接上 AI 助手做成能问答的工作台 → 打包一个最小部署
1 天 ｜ ≤8 人小班 ｜ 100% 实战
✅ 适合你来测试 / 开发 1-8 年，手上有一个真实的系统或仓库，想把“改一个字段要回归哪里”这类问题变成可查、可举证的东西；想做出一个能拿去演示的 AI 模块，而不是停留在“我熟悉 AI 工具”。
⚠️ 不适合你来只想听概念和趋势、不动手；或者期待学完立刻拿到某个具体 offer 或薪资——这门课交付的是能力和一个能跑的模块。
加微信备注「AI 实战课」，我拉你进本期小班
AI 不会替你理解业务，但它能把你对系统的理解，变成别人也能用的东西。
今天不用做任何大决定。挑一个你最熟的仓库，把索引跑起来——跑完那一刻，你会发现以前那些"凭经验"的判断，其实都可以有证据。
文中能力均来自 AITestX 真实代码：知识对象与关系定义见 apps/knowledge/models.py，索引流水线与检索打分见 apps/knowledge/services.py，代码与库表扫描见 apps/knowledge/asset_scanner.py，资产图谱与幽灵代码见 apps/knowledge/asset_insight.py，助手工作台见 frontend/src/views/manual-testcases/ManualQualityKnowledgeAssistant.vue公众号「AI测试开发实训」· AI Vibe Coding 实战系列