用 Claude Code 为前端项目搭建 AI 知识库：从架构梳理到需求驱动开发
为什么需要项目 AI 知识库？
用 AI 辅助开发已经是很多前端工程师的日常，但大多数人的用法停留在「问一个问题、得到一个回答」的阶段。
真正的问题是：AI 不了解你的项目。
每次对话它都是第一次认识你的代码库。你问它「帮我做个表单」，它给你的是通用写法，而不是你项目里已有的封装方式。你问它「这个权限怎么控制」，它不知道你的权限系统是路由守卫还是指令还是组件。
我最近探索出来的解法是：给 AI 建一个项目知识库，用一组 Markdown 文档把项目的架构、开发套路、权限系统、接口层全部梳理清楚，存在项目里的 aiInfo/ 文件夹。以后每次对话，让 AI 先读这些文档，再给出符合项目实际情况的方案。
更进一步，我还加入了需求整理和缺陷修复两个角色文档，让 AI 能扮演需求分析师和资深开发，主动问我补充信息，最终输出可以直接使用的文档。
整套方案用 Claude Code 实现，因为它可以直接读取代码库，不需要手动粘贴代码。
整体方案结构
最终 aiInfo/ 文件夹包含 7 个文件：
aiInfo/
├── 01-项目架构.md # 技术栈、目录结构、入口、主要依赖
├── 02-开发套路.md # 表单、表格、弹窗、请求的实际写法
├── 03-权限系统.md # 路由权限、按钮权限、流程图
├── 04-接口层.md # request 封装、接口组织、调用链路
├── 05-需求接入指南.md # 新功能标准开发流程
├── 06-需求整理.md # AI 需求分析师角色说明书
└── 07-缺陷修复方案整理.md # AI 缺陷排查角色说明书前五个是项目知识文档，由 AI 读取代码后自动生成。后两个是角色指令文档，告诉 AI 接到需求或缺陷时应该怎么配合你工作。
第一步：梳理项目架构
目标
让 AI 读懂你的项目用了什么技术、目录怎么组织、从哪里启动。
提示词
请分析这个前端项目的整体架构，读取 package.json、目录结构和主要配置文件。
帮我整理以下内容并保存到 aiInfo/01-项目架构.md：
1. 技术栈（框架、UI组件库、状态管理、路由、构建工具等）
2. 目录结构说明（每个主要文件夹的职责）
3. 项目入口和启动方式
4. 主要第三方依赖及其用途生成结果示例
## 技术栈
- 框架：Vue 3 + TypeScript
- UI 组件库：Element Plus
- 状态管理：Pinia
- 路由：Vue Router 4
- 构建工具：Vite
- 请求库：Axios
## 目录结构
src/
├── api/ # 接口定义，按模块分文件
├── components/ # 公共组件
├── composables/ # 组合式函数
├── router/ # 路由配置与守卫
├── stores/ # Pinia store
├── utils/ # 工具函数
└── views/ # 页面组件第二步：梳理开发套路
目标
找出项目里真实的高频写法，表单用什么库、表格怎么分页、弹窗怎么控制，附上真实代码片段。
提示词
请分析这个项目的源码，找出有代表性的页面和组件文件。
帮我总结这个项目的「开发套路」并保存到 aiInfo/02-开发套路.md：
1. 表单：用什么库、怎么定义字段、怎么做校验、怎么提交
2. 表格：用哪个组件、分页怎么处理、数据怎么加载
3. 弹窗/对话框：用什么组件、怎么控制显示隐藏
4. 消息提示/Toast：用什么方式弹出成功失败提示
5. 接口请求：axios 怎么封装的、统一错误处理在哪里
6. 每种套路附上一个项目里真实的代码片段作为示例这一步生成的文档价值最高。以后让 AI 给你写代码，它会自动参考这份文档，生成风格一致的代码，而不是「通用示例」。
第三步：梳理权限系统
目标
把权限体系说清楚：数据从哪来、路由怎么拦截、按钮怎么控制、没权限怎么处理。附带 Mermaid 流程图。
提示词
请分析这个项目的权限控制逻辑，重点查看路由配置、权限指令、权限工具函数、store 中的用户信息等相关文件。
帮我梳理清楚权限体系并保存到 aiInfo/03-权限系统.md：
1. 权限数据从哪里来（接口？登录后存哪里？）
2. 路由级权限：怎么控制哪些页面能访问（路由守卫逻辑）
3. 按钮/元素级权限：用指令还是函数还是组件判断
4. 角色和权限的关系
5. 没有权限时的处理方式（跳转？隐藏？提示？）
6. 用流程图（Mermaid 格式）描述权限验证流程第四步：梳理接口层
目标
搞清楚请求是怎么封装的、token 怎么注入、错误怎么统一处理、接口文件怎么组织。
提示词
请分析这个项目的接口请求相关代码，包括 request 封装、api 目录下的文件。
帮我整理并保存到 aiInfo/04-接口层.md：
1. request 封装了什么（baseURL、token 注入、响应拦截、错误处理）
2. 接口文件的组织方式（按模块分文件？）
3. 接口函数的命名规范
4. loading 状态和错误提示是统一处理还是各自处理
5. 附上一个典型接口调用的完整链路示例第五步：生成需求接入指南
目标
基于前四份文档，生成「接到新需求时标准开发流程」，以后接需求有据可依。
提示词
请读取 aiInfo 文件夹下已有的所有文档，基于这些内容生成一份「需求接入指南」，保存到 aiInfo/05-需求接入指南.md：
内容包括：
1. 接到新需求时的标准开发流程（step by step）
2. 新增一个列表页需要做哪些事
3. 新增一个表单页需要做哪些事
4. 新增一个需要权限控制的功能需要做哪些事
5. 常见问题 FAQ（基于项目现有代码推断）
这份文档的目的是：以后我把需求告诉你，你能基于项目风格快速给我出方案。第六步：创建需求整理角色
目标
这是整套方案里最有价值的文档之一。它本质上是 AI 的「需求分析师角色说明书」——告诉 AI 收到粗糙需求时，要怎么主动追问、怎么输出标准需求文档。
以后你只需要说：
请根据
aiInfo/06-需求整理.md，帮我梳理需求：我想做一个用户管理页面
AI 就会自动进入需求分析师模式，分批追问你缺失的信息，最后输出一份可以直接用来开发的需求文档。
提示词
请在 aiInfo/06-需求整理.md 创建一份文件。
这份文件的作用是：以后我接到粗糙的需求，我会说「请根据 aiInfo/06-需求整理.md，帮我梳理需求：XXX」，
你就按照这份文件里的流程，扮演需求分析师的角色，主动问我补充缺失信息，最终输出一份标准需求文档。
请根据以下结构生成这份文件：
---
# 一、你的角色
描述 AI 在这个环节扮演的角色：资深需求分析师，熟悉本项目技术栈和开发习惯（可引用 aiInfo 其他文档），
目标是把粗糙需求变成可以直接开发的标准文档。
# 二、需求澄清流程
描述 AI 收到需求后应该做什么：
- 第一步：复述理解，确认方向没跑偏
- 第二步：按分类主动追问缺失信息（见第三节）
- 第三步：确认完毕后，生成标准需求文档（见第四节）
# 三、追问清单
列出 AI 必须主动确认的问题，按分类整理，包括但不限于：
【页面与入口】
- 这个功能在哪个菜单/页面下？是新页面还是在现有页面新增模块？
- 是否需要新增路由？
【数据与接口】
- 数据从哪里来？是否已有接口，还是需要后端新开？
- 涉及哪些字段？
【权限】
- 哪些角色可以访问这个功能？
- 是否有按钮级权限控制（比如只有管理员能看到删除按钮）？
【交互细节】
- 表单的必填项是哪些？校验规则是什么？
- 操作成功/失败后的提示和跳转行为？
- 列表是否需要分页、搜索、筛选？
- 是否有弹窗，弹窗里有什么内容？
【边界与异常】
- 数据为空时怎么展示？
- 操作不可逆的地方（如删除）是否需要二次确认？
- 是否有加载状态需要处理？
【设计稿】
- 是否有设计稿？如果没有，是否参考项目现有页面风格？
# 四、标准需求文档模板
AI 追问完毕后，按以下模板输出需求文档：
---
## 需求文档：[需求名称]
### 1. 需求背景
（一句话说明为什么要做）
### 2. 功能入口
（在哪个菜单 / 哪个页面）
### 3. 功能描述
（分点描述功能，用「用户可以…」的句式）
### 4. 页面与交互说明
（描述页面布局、关键交互、表单字段、校验规则等）
### 5. 权限说明
（哪些角色可访问，哪些操作有权限限制）
### 6. 接口需求
（需要哪些接口，入参出参的大概结构）
### 7. 异常与边界处理
（空数据、加载失败、操作确认等）
### 8. 验收标准
（列出几条，开发完成后对照检查）
---
# 五、注意事项
- 追问时一次不要超过 5 个问题，分批问，避免让用户一次填写太多
- 如果用户说「参考现有的 XX 页面」，要去读对应代码再继续
- 生成需求文档后，询问用户是否要同时输出「开发方案建议」第七步：创建缺陷修复角色
目标
和第六步类似，这份文档是 AI 的「资深开发 + 测试思维角色说明书」。收到测试提的缺陷描述后，AI 会先判断缺陷类型、主动追问复现条件和环境信息，最后输出一份包含原因分析、修复步骤、影响范围评估的指导文档。
以后你只需要说：
请根据
aiInfo/07-缺陷修复方案整理.md，帮我整理以下缺陷：点击提交按钮没有反应
提示词
请在 aiInfo/07-缺陷修复方案整理.md 创建一份文件。
这份文件的作用是：以后我收到测试提的缺陷，我会说「请根据 aiInfo/07-缺陷修复方案整理.md，帮我整理以下缺陷：XXX」，
你就按照这份文件里的流程，扮演资深开发的角色，主动问我补充缺失信息，结合项目实际代码，
最终输出一份可以直接参考执行的缺陷修复指导文档。
请根据以下结构生成这份文件：
---
# 一、你的角色
你是一名熟悉本项目的资深前端开发，同时具备测试思维。你的目标是：
- 听我描述缺陷后，先判断缺陷的性质和可能原因
- 主动追问我还没提供的关键信息
- 结合 aiInfo 中的项目文档，找到最符合项目风格的修复方式
- 最终输出一份清晰的修复指导文档，让我可以直接按步骤修复
# 二、缺陷分析流程
收到缺陷描述后按以下步骤执行：
- 第一步：复述缺陷，确认理解正确
- 第二步：初步判断缺陷类型（见第三节），并说明可能的原因方向
- 第三步：按分类追问缺失信息（见第四节）
- 第四步：确认信息完整后，输出修复指导文档（见第五节）
# 三、缺陷类型分类
收到缺陷后先判断属于哪种类型，不同类型关注点不同：
【展示类】页面显示错误、样式错乱、数据不显示、文案错误
【交互类】按钮无响应、表单提交异常、弹窗行为不对、跳转错误
【数据类】数据加载失败、数据不刷新、数据和预期不符
【权限类】不该看到的内容显示了、该有权限的功能被拦截了
【性能类】页面卡顿、加载慢、操作无响应
【兼容类】特定浏览器/分辨率/设备下出现问题
# 四、追问清单
按分类列出需要主动确认的问题，每次追问不超过 5 个，分批问：
【复现信息】
- 缺陷在哪个页面 / 哪个操作步骤下出现？
- 是否可以稳定复现，还是偶发？
- 什么角色 / 什么数据情况下会触发？
【环境信息】
- 测试环境还是生产环境？
- 是否所有人都能复现，还是只有特定账号？
- 浏览器和分辨率是否有限制？
【预期与实际】
- 测试期望的正确表现是什么？
- 实际表现是什么？
- 是否有截图或录屏？
【关联范围】
- 这个缺陷是新功能引入的，还是老功能突然出现的？
- 最近是否有相关代码改动？
- 修复这里是否可能影响其他地方？
【代码定位】
- 知道大概在哪个文件 / 哪个组件吗？
- 接口返回是否正常（是前端问题还是接口问题）？
# 五、缺陷修复指导文档模板
追问完毕后，按以下模板输出：
---
## 缺陷修复指导：[缺陷标题]
### 1. 缺陷描述
（用一段话完整描述：在哪里、做了什么、出现了什么问题）
### 2. 缺陷类型
（展示类 / 交互类 / 数据类 / 权限类 / 性能类 / 兼容类）
### 3. 复现步骤
1.
2.
3.
### 4. 预期表现 vs 实际表现
| | 描述 |
|---|---|
| 预期 | |
| 实际 | |
### 5. 原因分析
（根据项目代码和缺陷信息，推断最可能的原因，可列多个方向）
### 6. 修复方案
（分步骤说明怎么改，指出具体文件 / 函数 / 代码位置）
步骤一：
步骤二：
步骤三：
### 7. 影响范围评估
（这个改动可能影响哪些地方，需要回归测试哪些功能）
### 8. 验证方法
（修复后如何验证缺陷已解决，列出验证步骤）
---
# 六、注意事项
- 如果缺陷描述里没有提到接口是否正常，优先引导我先确认是前端问题还是接口问题，避免方向跑偏
- 如果缺陷涉及权限，主动去参考 aiInfo/03-权限系统.md
- 如果缺陷涉及表单 / 表格 / 弹窗，主动去参考 aiInfo/02-开发套路.md
- 修复方案要符合项目现有代码风格，不要引入项目里没有用过的新写法
- 影响范围评估不能省略，防止改了这里坏了那里日常使用方式
文档生成完毕后，日常开发只需要以下几句话：
接到新需求时：
请根据 aiInfo/06-需求整理.md，帮我梳理需求：[简单描述需求]收到测试缺陷时：
请根据 aiInfo/07-缺陷修复方案整理.md，帮我整理以下缺陷：[缺陷描述]想要实现某个功能时：
请读取 aiInfo/ 下的项目文档，然后帮我实现 [功能描述]，
要求代码风格和写法与项目保持一致项目代码有重大调整后，更新知识库：
请重新读取 [某个模块] 的代码，更新 aiInfo/02-开发套路.md 中对应的部分几点经验
按顺序执行很重要。 01 到 05 要顺序跑，因为 05 依赖前四份文档的内容。如果顺序乱了，生成的文档质量会下降。
文档要随代码更新。 如果项目引入了新的组件库或者重构了某个模块，要及时让 AI 重新读取对应代码，更新 aiInfo/ 里的文档，否则 AI 给的方案会慢慢偏离实际情况。
提示词可以加范围限制。 如果项目代码量很大，可以在提示词里补充「重点看 src/views 下的文件」或者「先从 src/api 开始」，避免 AI 读太多无关文件。
需求文档可以直接存项目里。 每次跑完 06-需求整理.md 的流程，生成的需求文档可以让 AI 保存到 docs/requirements/ 或类似目录，积累下来就是项目的需求历史。
总结
这套方案的核心思路是：把项目知识结构化，让 AI 从「陌生人」变成「熟悉你项目的同事」。
7 个文件，前 5 个是知识沉淀，后 2 个是角色定义。一次投入，长期受益。项目越复杂、团队越小，这套方案的价值越明显。
如果你也在用 Claude Code，可以直接把本文里的提示词复制过去跑，整个过程大概需要 20 到 30 分钟，之后的每一次需求开发和缺陷修复都会更顺畅。