测试工程师常见痛点：

你是否遇到过这样的场景？接手存量历史项目时，翻遍 Wiki、群文件、共享盘，就是找不到一份完整的需求文档，当需要回归旧功能时只能对着页面点，或者需要基于现有业务梳理新需求测试点时，只能对着页面凭经验梳理场景。这种方式很容易遗漏底层隐藏业务逻辑，最终引发线上漏测问题。

之前我分享过蓝湖 / Figma /Axure/ 飞书文档一键转结构化需求文档的方案，那套在「有原型、有 PRD」的项目里行得通。但还有一种更棘手的场景：文档压根不存在。

那么，能不能让 AI 直接读项目源码，逆向输出一份可核对的需求文档，再交给后续的用例生成、评审环节？

针对这个痛点，我封装了 code-to-requirement-doc Skill。它支持 AI 扫描前后端代码，按业务视角整理功能、字段、流程和规则，输出带流程图、时序图、字段说明表的 Markdown 需求文档。测试同学拿到初版文档后先自行核对，存疑处再找产品 / 开发澄清，最终沉淀成团队可用的业务知识库。

Skill 原理介绍

核心逻辑：

项目源码（前端 / 后端 / App，同一工作区）    → 未指定模块：扫描项目 → 列出业务模块清单 → 人工选择    → 已指定模块：直接进入分析（如「用户登录」「订单管理」）    → Agent 提取功能点 / 字段 / 流程 / 业务规则    → 按业务视角撰写 Markdown 需求文档    → 附带 Mermaid 流程图、时序图、字段说明表    → 保存到指定目录

简单说，Skill 会先把代码里的技术实现翻译成业务语言：页面有哪些功能、字段什么意思、状态怎么流转、什么条件下报错——最终以测试和产品都能读懂的结构输出，而不是把 Controller / Service 文件名堆在一起。

Skill 适合解决这些问题：

• 存量项目无 PRD、无原型，需要回归或扩展测试；

• 新人接手老项目，需要快速建立业务全局认知；

• 团队想把隐性业务规则沉淀成文档，接入后续 AI 用例生成；

• 前后端分离项目，需要把页面交互和后端规则合并成一份完整说明。

操作步骤

项目代码拉取

1、使用git拉取你的项目，可以是前端，后端或者app项目

相关拉取指令：

git clone 项目地址 

项目权限的话就需要自己去找开发进行开通了，你可以跟它说只需要阅读权限，不进行代码的改动，而是用于AI辅助了解一下相关的业务逻辑或者产出需求文档等权限方面。如果实在没法提供权限给测试人员，那也可以把skill和执行流程提供给开发，让他们帮忙输出~

2、前后端放在同一工作区

前端、后端或 App 项目 clone 到同一根目录下，AI 才能跨模块扫描、关联分析；

推荐目录结构示例：

RAINA_APARTMENT/├── apartment-frontend/    # 前端项目├── apartment-backend/     # 后端项目└── docs/                  # 输出需求文档目录（可自建

以我常用的公寓管理项目为例，我会把前端和后端放在同一个工作区里，方便 Skill 把「页面字段」和「接口规则」对齐分析。

二、Skill获取 & 导入

下载 Skill 包，解压到 AI 工具的 Skill 目录下，例如：.claude/skills/

skill获取方式：

可以自己根据Raina提供的思路进行开发skill，如果需要现成的，也可以加入知识星球获取~里面还有很多AI赋能测试全流程的实战教程，学习过程中有疑惑也可以进行提问~

三、执行skill

Skill 支持两种执行方式：

下面我们演示下没有指定模块的执行过程

输入：直接在对话框引用我提供的skill

AI输出：

因为没有指定需要生成的模块，AI会先对代码进行扫描，扫描出本项目中所拥有的模块，之后再让你进行选择需要的模块，如下，是本次对话中扫描的模块列表

这里我们可以指定几个模块，或者说让其全部进行生成，但是全部生成的话，可能会比较消耗token，那本次，我就指定几个我需要的模块即可

比如我选择了以下几个业务相关的模块，然后点击继续

之后AI就会根据我的选择，产出了多份需求文档，这里默认是产出多个文件的，按照模块进行产出。

如果你需要整合成一个需求文档的话，也可以让AI修改 skill

生成效果演示

首先我们先看下全貌：

下面是具体模块的案例介绍：

1、模块概述

介绍一下这个模块的用途是什么

2、涉及的角色和权限

这块也是在测试的流程中，比较重要的流程

3、有哪些功能清单

4、相关业务流程

这里是用 mermaind 绘制流程图，便于我们进行理解

5、功能/页面详细的说明

6、业务规则与状态、&边界

7、开放问题

最后AI 还会扫描代码，对于不确定的事项进行输出，如下：

使用说明与边界

从源码逆向出来的需求文档，是初版草稿，不是可以直接派上用场的 PRD。

主要有这些边界：

1. 代码注释 / 命名不规范时，AI 推断的业务含义可能有偏差，必须人工核对；

2. 未在代码中体现的产品意图（如即将下线功能、灰度策略）无法被还原；

3. 大项目全量扫描耗时会较长，建议按模块分批生成；

4. 涉及敏感逻辑（计费、风控）时，输出文档注意脱敏后再共享。

因此，推荐的使用方式是：

AI 生成初版需求文档    → 测试同学核对 + 标注待确认项    → 产品 / 开发澄清修正    → 入库 / 接入用例生成 Skill    → 业务迭代后按需重新生成或增量更新

即便如此，这套方案在没有文档存量项目里作用还是很大的——先把 70 分的业务底稿跑出来，再花精力在 20 分的核对和 10 分的澄清上，远比从零摸黑强。

拿到文档后，你可以：

1. 对接用例生成、用例评审等后续 Skill；

2. 作为团队 Wiki / 知识库的基础素材持续维护；

3. 新人 onboarding 时，先读 AI 生成的模块文档，再上手测试。

小结

AI 提效测试，第一步是「让 AI 读懂业务」。蓝湖、Figma、飞书文档 Skill 解决了「有文档」的场景；而 今天分享的方案补上了「没文档、有代码」的情况。

它的核心价值不是替代产品写 PRD，而是帮测试同学快速建立业务全局图、减少存量项目漏测、把隐性规则显性化——让你不再对着页面猜逻辑，而是有一份可核对、可沉淀、可对接后续 AI 流程的需求底稿。

以上是今天分享的内容，文中 Skill 包、详细教程均已整理至【Raina的AI&测试实战圈】知识星球。跟着步骤操作就可以上手，里面还有很多AI提效测试的实战教程，学习过程中遇到问题也可以提问，感兴趣的小伙伴可以加入了解哦～