四、团队 AI 研发流程落地实践
4.1 AI 编程落地痛点问题与分析
4.1.1 痛点问题
站在用户层面讲，一线用户或多或少会经历4个阶段，初次相识、尝试体验、深入使用或弃用、回流使用，（谁好用就用谁的，谁便宜就用谁的）。
站在组织层面讲，团队落地推广 CodeBuddy 中遇到的问题可分为个人主观意愿,即态度问题（愿不愿用）和个人能力问题（会不会用及用的好不好）、产品能力问题（好不好用，爱不爱用），主观意愿影响因素很多，比如如个人态度、交互体验/模型能力是一个核心的影响因素，基于 2025 年6 月底，我们基于日常腾讯内部25 年 2900+ 用户反馈分析总结，梳理研发场景和Top问题，其中Top3 场景为：工程理解、代码生成、DeBug 定位和修复，主要问题是代码生成准确率、项目级代码生成能力弱、上下文理解不足。这块强依赖模型的能力，一方面我们持续造数据，增模型，与私有化客户共建，提升模型生成效果，另一方面和混元团队共建，持续推进模型基座能力提升，但这需要时间。
针对一线用户反馈的心声，我们都听到了，收到了，正在加急解决，并加班加点解决，推进排期，但 AI 变化很快，总会猝不及防，给人惊喜给人错觉，因此我们也会对标业界能力，并坚持一定的定力和考虑工具灵活性。
另外，对于优秀实践案例等工具使用上也有迫切需求，本质需求是大家想参照借鉴，希望提升自我/团队驾驭 AI CODING 工具的能力。 个人主观意愿问题有很多方式，比如借助礼品、激励活动实现自下而上的，适当采用自上而下的方式，本期内容我们聚焦于个人能力方面提升，进行分析问题和探索解决方案。
4.1.2 问题分析与应对方案
通过进行大量调研分析，了解到以下典型问题，并提出了一些解法。
问题分析 | 应对方案 |
|---|---|
与 AI 沟通不精确、不彻底，上下文不足，AI 工程理解差，出现幻觉，导致一直陷入与 CodeBuddy 的多轮对话中，低效和造成时间债务 | 1. 引入领先的模型，如 DeepSeek、Claude 、GPT 2. 调研了解具体问题，具体对话场景，制定措施 3. 寻找用的好的用户，内容沉淀和分享 4. 制定团队的 AI 研发流程 SOP |
一句话描述需求，缺失详细的需求文档说明，需求范围不断变更，导致延期 | 统一 AI 生成需求模版，形成用户故事需求规范化 |
难以一次性清晰地向 CodeBuddy 表达自己想要什么样的方案难以清晰的准确的向 CodeBuddy 表达技术设计方案和代码 | 1. 了解具体表达方式和内容 2. 提供反向 PUA CodeBuddy、提示词工程赋能、结合本地工程和私域 RAG 知识库熟悉工程，借助 CodeBuddy 提供方案，尽可能将表达沉淀微规模化或规范化 |
团队成员各自编码风格、接口不统一，企业规范的代码，不知道如何生成符合业务属性的代码，联调和部署环境耗时，导致跨团队协作低效。编码风格、接口不统一，跨团队协作低效 | 1.统一 编码规范，在团队内部达成共识，使其成为团队的规范，并以Rules 作为上下文形式关联 CodeBuddy 2.整理团队知识库，将知识库作为上下文，使用 Agent 时引用，先基于知识库生成代码，此时代码就具备了业务属性，再利用代码补全，CodeBuddy会自动识别上下文，补全符合业务属性的代码 |
缺乏开发变更记录或标准记录，团队成员不知道改了哪些地方， 追溯或理解耗时缺乏开发变更记录或标准记录，不敢动 | 借助 User Rules 制定规范，确保每次开发完后 CodeBuddy 都要按照规范生成开发变更记录，便于追溯。 |
新人不知如何下手， 缺失或依赖每个项目工程 Rules 或 知识库缺失或更新久远，需要额外花费时间指导和讲解 | 借助 CodeBuddy 盘清问题，基于工程理解输出文档， 以 Rules MD 形式沉淀各个阶段的知识库，并建立好 Coding 研发指南保存到仓库中，借助 Git 实现版本化管理与持续维护。 |
4.2 探索构建 AI 研发团队工作流
我们试想把日常开发的一个个需求的流程进行各阶段剖析，并采用 CodeBuddy 进行流程探索优化，辅助提效，借助 CodeBuddy AI的能力实现从单需求/单微服务应用到多需求/多微服务应用的并行交付。如下为 AI 开发流程和现状流程对比示意图：
采用 CodeBuddy 进行 AI CODING 应遵循一个清晰的、具有规划、执行、可迭代、及时反馈 、持续运营的闭环工作流，人与 AI 需要做些分工。
1.我们负责定义需求目标、背景、技术边界与要求，即，规划并管理好上下文：
2.我们将上下文与 CodeBuddy 引用，喂给 CodeBuddy，让 CodeBuddy 好好干活。同时，我们需要持续验证，检查 CodeBuddy 的产出是否满足我们设定的要求。即，驱动 AI 执行并验证：
3.步步为营，及时反馈与闭环：研发任务过程，单次完成任务后及时 Git Push 提交，遇到问题可随时对照，随时回滚上一步，然后通过补充或修改上下文来纠正 AI 的行为，然后再次驱动 AI。
4.3 面向文档的全流程 CodeBuddy AI 编程实践
4.3.1 核心理念：重新定义人与 CodeBuddy 的分工
观点：要想 CodeBuddy 好好干活，干好活，就必须拥有足够的上下文（Context）给到 CodeBuddy
- 人的职责：搞定上下文，组织、 补充描述、管理和维护所有与任务相关的背景知识和约束条件。
- AI 的职责：好好干活，干好活，基于我们提供的完整上下文和明确需求，可以高效、准确的执行任务。
结论：我们的工作中心，逐步演变为深度思考，写好 Prompt、管理好上下文，成为“AI上下文工程师”。
如果 AI 缺少上下文，那么我们就要主动给它补充上下文，或者让 AI 自动填充上下文，而在团队多人协作下， 每个人和 AI 的交互可能不一样，我们尽可能的将这些上下文，定义为一套规约(Rules)文档，帮助团队清晰理解，并提升团队能力，实现基于"文档驱动" 的编程， 理论很丰满，但落地难。
1. 结构化文档驱动开发
为了尽可能实现团队共用的一套上下文， 借助 CodeBuddy生成 MD 方式，实现“文档驱动”，为所有关键文档都创建了模板 ：
- dev-guide.md: 团队开发指南模版。
- project-arch.md 核心技术方案模板。
- devlog-rules.md: 开发日志模板。
- requirement-rules.md: 需求文档 PRD模板。
- ui-design-rules.md ： 需求文档转设计稿模版。
- ai-code-review-rules.md：代码评审模版。
- test-rules.md： 单元测试模版。
- security-rules.md：安全分析模版。
- release-rules.md : 发布上线模版。
- user-rules.md：编码规范模版。
当需要创建新文档时，就让 AI 会基于这些模板生成，人工审核确认，确保了格式的统一和信息的完备。这样做的好处也很多，沉淀团队知识库，及时共享，降低沟通成本。
2. CodeBuddy Rules & Custom Roles Assiant Modes
- CodeBuddy Rules ：通过上面模版和 CodeBuddy User Rules 和 Project Rules ，具体的任务使用时作为上下文引用，可以让 CodeBuddy 在执行任务时始终能记住这些背景信息，就像人一个"带了脑子"一样回答问题。
- Custom Roles Assiant Modes ：可以创建多种自定义角色助手模式，如 Product Manager（产品经理助手模式）、AI Go Developer（AI Go 语言开发助手模式）等。在不同模式下，通过 Rlues 约定风格，功能约束等，我们切换到不同模式，可以让 CodeBuddy 的行为和产出更符合当前任务的角色定位。
基于上述理念，我基于 5 月份底的时候做过一次从 0 到 1 的 AI 旅行 APP，没写一行代码的Vibe Coding 实践，先看下效果。
https://cloud.tencent.com/edu/learning/quick-play/4594-81418
当初，这是从 0 到 1 的初版 AI 旅行 APP，相对好实现，但我们的系统大多数是增量业务， 基于5月份总结，本次考虑增加一个用户管理权限系统，来实现用户注册、授权等功能。并尝试结合迭代的角度呈现 CodeBuddy 在研发全流程中各个阶段借助 Rules 模版和 AI 辅助的案例分享。
4.3.2 需求阶段：人与 CodeBuddy 协作，构建 PRD
在此阶段，我们常常遇到一句话需求，而一句话需求最痛点的问题是，没有经过详细的澄清需求范围，而导致在后续开发过程中存在需求变更，进而影响各个阶段。在此阶段，分三步进行落地, 沉淀标准化 产品需求文档（PRD），即：
步骤 1: 产品构思 (人与AI协作 梳理核心概念)
目标：将一个模糊的想法具体化。
方法：人与 CodeBuddy 进行 Chat 或 Agent 模式下对话，描述需求、澄清，共同梳理产品的核心概念，CodeBuddy 在这里扮演着一个出色的“梳理者”和“陪练教员”。
步骤 2: 需求文档 (人与 AI 协作编写PRD)
目标：将产品构思转化为结构化的产品需求文档（PRD）。
方法：AI 根据第一步的产品构思，自动编写初版的 Story PRD，然后人来评审和修改这份PRD，进行人机交互确认。
步骤 3: 标准化PRD（ AI 生成需求规范Story PRD）
目标：将需求文档转化为标准化、规划化的用户故事需求文档
方法：通过团队成员 AI 实践和持续打磨，形成一套团队共识的标准化PRD，在标准化 PRD 中要定义好项目需求概述、实现目标、目标用户、核心功能需求及涉及模块、优先级、处理人、期望上线时间，以及非功能需求、交付物等信息，采用人工描述，AI 一键生成需求文档，也便于后续的技术设计 和追溯。
以下为需求文档生成规则（requirement-rules.md） ，考虑篇幅原因，仅展示部分信息，如需完整版Rules 可私信微信公众号： 搜索「腾讯云代码助手」
---
type: always
---
# 需求文档生成规则
## 文档格式
根据用户输入，以及结合你对本地项目工程理解，技术规格，生成的需求文档应包含以下部分：
## 标准需求生成模板
br
用户提供信息时，请按照以下结构生成 需求文档：
br
```markdown
# 项目名称：[项目名]
br
## 1. 项目概述
### 1.1 项目背景
[根据用户输入填写]
br
### 1.2 项目目标
[根据用户输入填写]
br
### 1.3 目标用户
[根据用户输入填写]
br
## 2. 功能需求
### 2.1 核心功能
- [功能1]
- [功能2]
- [功能3]
br
### 2.2 功能详细描述
#### 2.2.1 [功能1]
[详细描述]
br
#### 2.2.2 [功能2]
[详细描述]
br
### 2.3 用户流程
[描述用户如何使用系统完成主要任务]
br
## 3. 非功能需求
### 3.1 性能要求
[响应时间、并发用户数等]
br
### 3.2 安全要求
[数据安全、身份验证等]
br
### 3.3 可用性要求
[易用性、可访问性等]
br
## 4. 技术规格
### 4.1 技术栈
[前端、后端、数据库等]
br
### 4.2 系统架构
[系统组件和交互]
br
### 4.3 第三方集成
[需要集成的外部系统或API]
br
## 5. 优先级及责任矩阵
- [优先级]
- [XXX模块Owner]
- [研发处理人]
- [测试处理人]
br
## 6. 交付与验收：
### 6.1 里程碑
[主要项目阶段]
br
### 6.2 时间线
[计划完成时间]
br
### 6.3 检验方式与验收标准
[项目成功的衡量标准]
br
## 7. 风险评估
- [风险项]
- [影响程度]
- [应对策略]以本地现有的旅行AI APP ，开发用户管理系统为例：
#Prompt 输入
基于 @requirement-rules.md 需求文档要求和当前工程理解，帮我完成生成用户管理系统的详细需求文档，包括用户的注册（注册支持手机号、邮件），删除，更改，查询及功能授权，并保存在我本地的 task/user-story.md 下面示例： AI 辅助生成用户故事（PRD）文档示意图
步骤 4：标准化 PRD 生成 Demo 设计稿
目的：基于标准化 PRD 生成设计稿，适用于 Demo 场景
方法：首先通过制定标准的需求转设计稿文档规则，在规则里面定义好，其次用户需指定要处理的需求文档文件路径，借助 AI 进行分析需求并生成UI设计，并以 HTML 文件形式保存到 output 目录。
在传统的交互方式下，产品依赖设计生成设计稿，设计稿依赖人力生成，耗时长。在 MVP Demo 场景，产品完全可以自己生成 UI 设计稿，快速做出原型。当然在生成场景下，还是需要专业设计输出设计稿。
以下是需求文档转为 UI 设计稿生成规则（ui-design-rules.md）供参考：
# 需求文档转UI设计稿生成规则
br
## 目的
本规则用于根据用户指定的需求文档，生成对应的UI设计并输出为单个HTML文件。
br
## 步骤
1. 读取用户指定的需求文档文件
2. 分析需求文档中的功能需求和用户流程
3. 根据需求生成适合的UI设计
4. 将设计转换为单个HTML文件并输出到output目录
br
## UI设计生成指南
br
### 基本原则
- 界面应简洁清晰，符合现代设计趋势
- 优先考虑用户体验和易用性
- 布局应响应式，适配不同设备
- 遵循需求文档中描述的用户流程
- 色彩方案应符合产品定位和目标用户群体
br
### 输出HTML要求
- 单文件HTML，包含所有必要的CSS和JS
- 不依赖外部资源（除非特别指定）
- 注释清晰，代码结构合理
- 实现需求文档中描述的核心功能
- 提供基本交互效果展示
br
### 设计元素
- 导航结构
- 布局框架
- 色彩方案
- 字体选择
- 按钮和表单样式
- 图标和视觉元素
br
## 模板结构
生成的HTML应包含以下基本结构：
br
```html
html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>[项目名称] UI设计title>
<style>
/* 此处包含所有CSS样式 */
style>
head>
<body>
<header>
header>
br
<main>
main>
br
<footer>
footer>
br
<script>
// 此处包含所有JavaScript代码
script>
body>
html>示例：
基于标准化 PRD 模版以及借助 AI 对本地工程的理解，生成符合当前项目的标准化产品需求文档，并快速帮助我们补充了详细的需求设计，实现了需求端开发左移，极大的减轻了产品与研发之间的需求沟通的成本，并保障了团队文档生成一致性，同时可追溯。
输入：
根据 @ui-design-rules.md 设计规则，将 @user-story.md 需求文档生成UI设计稿, 并保存为user-story-design.html参考 QQ 登录页面效果示意图：
步骤 5(可选)：设计稿一键转代码
目标： 基于现有 Figma 一键生成代码，或基于 AI 生成的 Demo 设计稿转化为前后端可维护源码，打通从设计到开发的“最后一公里，当然生成阶段设计稿，
方法：引用 Figma 图片或 HTML 图片，实现代码生成。
示例： 接基于Figma 现有设计稿给到 CodeBuddy 识别示意图：
4.3.3 方案设计阶段：CodeBuddy 辅助方案设计，自主执行编码
在此阶段，基于研发侧站在实现角度以及产品需求文档，以及结合项目工程情况，需要进行需求文档接收与确认、整体技术实现方案、详细系统设计，方案 Review 内审。
步骤 1：整体技术方案（人主导，借助AI，梳理整体技术设计方案）
目的：结合本地项目工程的复杂性，以及需求开发多人协作，需要梳理整体项目技术方案，面向开发者，清晰表达技术链路
方法：在业务需求分析与技术方案设计时，整个产品的技术Owner 需要从全链路视角产出整体设计方案，定义清楚上下游边界及交互链路，并通过一个整体架构文档将各方设计串联起来，需求模块的技术子 Owner 围绕技术需求，快速理解与清楚上下游边界及交互链路。这个阶段主要是面向开发者，因此可以抽象表达，清晰的表达技术链路即可。
团队 Rules 参考：
Prompt 输入：
基于你对本地工程的理解，进行项目介绍，帮我从全链路视角产出整体设计方案，定义清楚上下游边界及交互链路示意图：
项目架构结构：
进一步可以借助 AI 的多轮对话，完善模块的责任矩阵、具体服务模块作用和接口调用等信息，不仅维护一个整体技术设计方案，更是维护了一个项目架构和新人指导手册。
输入：
帮我补充各个模块的责任矩阵，相关信息如下，以 MD 方式进行输出到 project-arch.md 中
1. 首页服务(home-service)由@xiaoming负责，主要提供首页展示和热门推荐功能。
2. 定制路书服务(customize-service)由@xiaoai负责，主要提供AI路书生成和行程定制功能。
3. 地图导航服务(map-service)由@zhangsan负责，主要提供地图展示和路线规划功能。
4. 行程管理服务(trips-service)由@lisi负责，主要提供行程CRUD和收藏管理功能。
5. 景点详情服务(spot-detail-service)由@liuqiang负责，主要提供景点信息和评价展示功能。
6. 用户管理服务(user-service)由@sunliang负责，主要提供用户认证和个人资料管理功能。
7. 共享组件(shared-components)由@xiaoming负责，主要提供通用组件和工具函数支持。展示责任矩阵图：
步骤 2：需求技术方案设计（AI 辅助生成清晰的技术架构，实现细节）
目的：产出单需求/应用/单个微服务的需求技术方案设计，制定实现PRD所需的技术方案
方法：在大的技术方案设计之下，需求技术方案设计可先由人工撰写，再交由 CodeBuddy 并产出单个应用或单个微服务的详细的技术设计。 需求技术方案设计需要描述清楚应用内的技术实现方案，包括核心功能、功能详细描述、表单验证、调用链路、非功能需求（如性能、可用性、可扩展性）、技术栈实现细节, 如精确到具体的类、方法、数据结构等定义，由图或代码的形式清晰地表明每一层的业务流程。
团队 Rules 参考：
输入：
基于本地的项目架构@@project-arch.md 和@requirement-rules.md 需求标准化模版，帮我生成实现用户的注册、删除、改名、授权功能的需求文档 user-sory.md，同时基于该需求文档，辅助输出清晰的概要设计，需要包括核心功能、功能详细描述、表单验证、调用链路、非功能需求（如性能、可用性、可扩展性）、技术栈实现细节等。概要设计文档示意图：
功能详细设计流程图及函数、类等 API 设计：
步骤 3：AI 辅助方案评审，确定开发指南
目的：AI 辅助 ，制定实现 PRD 所需的开发指南，精确表达。
方法：结合需求文档和概要设计文档， 及结合 User Rules 编码规范可一同作为上下文，经过 CodeBuddy 和 人工 Review 通过后，可直接给到 CodeBuddy 进行代码生成代码。
团队 Rules 参考：
输入：
@user-management-design.md @user-rules.md @user-story.md
作为架构师专家，我将基于以下文档进行方案评审并给出优化建议：
br
1.评审依据：
- 技术架构文档
- 概要设计文档（包括系统架构、模块划分、接口设计等）
- 需求文档（功能需求、非功能需求、业务规则等）
- 用户规则文档
br
2.评审范围：
- 系统架构设计
- 技术选型适配性
- 数据模型设计
- API设计与实现
- 安全性设计
- 性能与可扩展性
- 测试策略
- 部署与运维
br
3.评审后将提供：
- 架构优化建议
- 技术方案改进意见
- 潜在风险预警
- 编码规范补充建议
br
待评审通过后，团队可进入编码实现阶段。整体架构评审示意图：
安全性设计评审示意图：
评审报告：
基于上下文 AI给出的评审建议，开始进行计划制定和代码生成：
步骤 4： 开发执行：核心循环，面向文档编程理念集中体现。
目的： 自主编码实现与提交入库
方法： 1.自主编码实现：CodeBuddy 根据PRD和技术指南进行编码。2.准备交付 (Commit)：AI完成编码后，会自动准备好Git的提交信息。3.人来确认并执行提交，这是关键的控制点，确保了代码质量和版本管理的清晰。
团队 Rules 参考：
Promot输入：
@/user-story.md @/user-management-design.md @/user-rules.md
基于需求文档，登录页面效果，和概要设计文档以及结合本地工程理解，进行执行用户需求管理系统开发，确保功能可用，确保按照原型效果开发。
重点关注一下：
- 创建前端组件，实现用户注册、登录和资料管理界面
- 实现客户端表单验证
- 添加用户操作的 UI 反馈
- 测试完整的用户流程代码生成实现示意图：
注册账户效果示意图：
步骤 5: AI 生成记录与迭代 devlog
目标：将开发过程资产化，并为下一次迭代提供参考。
方法： 通过定义 user-rules.md 规范，要求 AI 自动生成 devlog（开发日志），并轻松归档。这个日志保留了完整的开发记录，极大利于问题的排查和复盘。
团队 Rules 参考：
# 用户自定义规则 user-rules.md (User Rules)
br
## 基础规则
br
### 1. 语言要求
- **Always respond in 中文**
- 所有回复、文档、代码注释都使用简体中文
- 技术术语可保留英文，但需要中文解释
br
### 2. 变更记录管理 ⭐ 重要
- **每次修改后必须更新 devlog.md**
- **严禁删除历史记录** - 只能追加，不能覆盖
- **使用 `replace_in_file` 在文件顶部添加新记录**
- **采用时间倒序方式存储** (最新记录在顶部)
- **时间格式**: [YYYY-MM-DD HH:MM]
- **记录内容包括**: 修改文件、具体变更、影响范围
br
### 3. 系统环境
- **操作系统**: macOS
- **工作目录**: /Users/kongdeyuan/Desktop/awesome-repos/travel
- **默认 Shell**: Zsh
br
### 4. 文件操作规范
- **优先使用 `replace_in_file`** 进行文件修改
- **只有在创建新文件时才使用 `write_to_file`**
- **大文件修改时分批处理**，避免单次操作过大
- **修改前先用 `read_file` 确认当前内容**
br
### 5. 代码规范
- **组件命名**: PascalCase (如: TripCard)
- **文件命名**: kebab-case (如: trip-card.tsx)
- **变量函数**: camelCase (如: getUserData)
- **常量**: UPPER_SNAKE_CASE (如: API_BASE_URL)
- **TypeScript 优先**，所有新代码必须有类型定义
br
### 6. Git 提交规范
- **提交格式**: `type(scope): description`
- **类型**: feat, fix, docs, style, refactor, test, chore
- **示例**: `feat(auth): 添加用户登录功能`
br
## devlog 更新模板
br
每次修改后，必须在 devlog.md 顶部添加以下格式的记录：
br
```markdown
## [2024-MM-DD HH:MM] - 变更标题
br
### 修改内容
- **文件名**: 具体修改内容
- **文件名**: 具体修改内容
br
### 技术改进
- 改进点1
- 改进点2
br
### 文件变更
- `path/to/file`: 变更类型 (新增/修改/删除)
br
### 影响范围
- 影响的功能模块
- 影响的用户群体
br
---
```
br
## 操作检查清单
br
### 文件修改前
- [ ] 使用 `read_file` 查看当前内容
- [ ] 确定使用 `replace_in_file` 还是 `write_to_file`
- [ ] 准备 devlog 更新内容
br
### 文件修改后
- [ ] 验证修改是否正确
- [ ] 更新 devlog.md (使用 `replace_in_file`)
- [ ] 确认历史记录未被删除
- [ ] 检查时间格式是否正确
br
## 错误预防
br
### 常见错误及预防
1. **覆盖 devlog** → 永远使用 `replace_in_file`
2. **删除历史记录** → 只在文件顶部添加新内容
3. **时间格式错误** → 使用 [YYYY-MM-DD HH:MM] 格式
4. **工具使用错误** → 一个响应中只能使用一次文件操作工具
br
### 紧急情况处理
- 如果意外覆盖了文件，立即说明情况
- 提供恢复方案或重新创建内容
- 在下次操作中加强检查
br
## 质量标准
br
### 代码质量
- 所有代码必须有 TypeScript 类型
- 组件必须有 Props 接口定义
- 函数必须有返回类型声明
- 复杂逻辑必须有中文注释
br
### 文档质量
- 所有文档使用中文编写
- 技术术语提供中英文对照
- 示例代码包含详细注释
- 变更记录详细且准确
br
### 响应质量
- 回复简洁明了，避免冗余
- 技术解释通俗易懂
- 提供具体的操作步骤
- 包含必要的代码示例
br
---
br
*规则版本: v1.0*
*创建时间: 2025-08-08*
*适用范围: travel 项目开发*示例：
Prompt 输入：可在 Agent 任意输入，变更代码都可
基于你的优化建议，帮我执行一个计划，然后进行优化devlog 变更示意图：
4.3.4 评审阶段：利用 CodeBuddy 守护代码质量
评审阶段主要是保障代码质量，一方面存在 MR/Diff、单/多文件的代码评审，另一方面安全代码分析。
步骤 1: 通过 CodeBuddy 实现代码自评审
目标：借助 AI 实现代码智能评审，提升合流前的代码质量
方法： 通过定义 AI CodeReview Rules，并引用 Rules & 代码片段/单/多文件作为上下文进行自评审，下面以 MCP Store ，好的。
团队 Rules 参考：
# AI 代码审查规则，部分展示
br
这是一套团队定制的 AI 代码审查规则，融合了企业 TypeScript 编码规范，旨在确保代码质量、一致性和可维护性。
br
## 基本原则及规则等级说明
为明确规则的重要性和执行严格程度，并采用以下标记：
br
- 优先考虑代码的可读性和可维护性
- 遵循一致性原则，保持代码风格统一
- **规范等级**：【必须】= MUST/REQUIRED，【推荐】= SHOULD，【可选】= MAY
- **【必须】**：必须严格执行，违反将导致构建失败或代码审查不通过
- **【推荐】**：强烈建议遵循，特殊情况可以申请豁免
- **【可选】**：建议性规范，有助于提高代码质量和可维护性
br
## 1. TypeScript 基础规范
br
### 1.1 类型定义【必须】
br
- **明确类型**: 所有变量、函数参数和返回值必须有明确的类型定义
- **避免 any**: 除非绝对必要，否则不应使用 `any` 类型
- **接口定义 Props**: 组件 Props 必须使用命名接口定义，而非内联类型
- **类型集中管理**: 相关类型应集中在 `types` 目录下的适当文件中
- **类型断言语法**: 使用 `as Type` 语法，禁止使用 `` 语法
- **利用类型推断**: 基本类型变量应利用 TypeScript 的类型推断能力
- **接口优先**: 优先使用 interface 而非 type，除非需要使用联合类型等特性
br
```typescript
// ❌ 不推荐
const Component = (props: any) => { /* ... */ }
const foo = bar;
let num: number = 42;
interface User { getName(): string; }
br
// ✅ 推荐
interface ComponentProps {
title: string;
onAction: () => void;
}
br
const Component = ({ title, onAction }: ComponentProps) => { /* ... */ }
const foo = bar as string;
const num = 42; // 自动推断
interface User {
name: string;
getName: () => string;
}
```
br
通过遵循这些规则，我们可以确保代码库的质量、一致性和可维护性，同时提高开发效率和团队协作。示例：
需求生成 AICR 报告
Prompt 输入：
@global.d.ts @user.ts @jest.config.js @routes.ts
@ai-code-review-rules.md 按照 ai code review rules 进行代码评审，给出相关评审建议，提供 HTML 评审报告并给我一个实施计划引用变更文件，AI评审部分示意图
AI生成HTML评审报告示意图
AI生成代码质量提升计划示意图：
采用AI进行快速修复示意图：
步骤 2：通过 CodeBuddy 实现代码安全评审
Prompt 输入：
@/src/config/gateway.ts @/src/types/common.ts @/src/types/user.ts @/next.config.microservice.js @/src/app/customize/complete/page.tsx 按照@security-rules.md rules 安全评审规则，进行安全评审，给出相关安全评审建议，提供 HTML 安全评审报告并给我一个安全改进计划进行 AI 安全评审示意图：
AI 生成安全评审和修复示意图：
步骤 3（可选）: 通过 CodeBuddy + 腾讯代码分析 TCA 实现增量/整个分支代码扫码
目的：基于现有 TCA 代码扫码预料，以及整仓扫描和全量扫描，识别代码安全问题
方法：通过 TCA MCP Server 的方式，CodeBuddy 上配置和调用实现。
1.配置 TCA MCP Server，配置方法详见：
https://cloud.tencent.com/developer/mcp/server/11709?fromchannel=cb
2.Prompt 调用
Prompt 输入：
请采用 ts/react 扫描方案进行该分支进行全量扫描
br
PS: tca-rules.md 参考：
### 默认行为
在用户提问时， 问到和 TCA (不区分大小写）相关 时，比如：请采用 ts/react 扫描方案进行所有分支进行全量扫描，或者执行TCA、TCA MCP server 时候，，请给我确认，是否增量或全量扫码，由我确认后，直接调用 tca-mcp-server 进行代码扫描。
br
### 能力约束
当我问到 TCA 或 TCA MCP Server 的时候，你的能力受限于下面几点：
- 你只能 调用 TCA TCA MCP Server 的进行扫码，如果用户提出其他的需求，你应该回复：`很抱歉，我当前只能处理代码扫描的需求`。
- 一定要记住！你只能进行代码扫描，不能进行任何代码的生成！
- 以中文来与用户沟通，并保持礼貌。示例效果：
TCA 项目配置示意图 & Prompt 输入示意图：
人工确认是否进行代码扫描任务执行示意图：
获取扫描报告：
查看结果及相关分析示意图：
如需了解 TCA 更多信息，可访问 TCA 官网：https://tca.tencent.com/
4.3.5 联调阶段：涉及大量沟通， 由人主导
在这个阶段过程中，由于涉及多人协作和大量沟通对接，因此在联调阶段过程细节，主要还是采用人工主导，CodeBuddy 辅助提供沙箱运行环境方便在线模拟环境进行预览调试，
目的：在联调过程需要频繁依赖查看前端 UI 视角效果，可以采用 CodeBuddy 一键部署云端环境，是在线预览。
Prompt 输入：
部署当前项目到云端环境，或Deploy current project to remote
br
PS: 或点击小火箭按钮?一键部署示例：部署生成效果示意图
4.3.6 测试阶段：CodeBuddy 辅助生成测试文档及测试验收
此阶段，可以定义好团队测试规范，基于需求文档，借助 AI 可快速生成单元测试用例和生成单测报告。
步骤 1: 基于团队测试规则及功能需求文档，生成测试验收文档
目标：生成单个/多个功能测试验收文档。
方法：关联团队 Rules和需求文档，AI 辅助生成测试验收文档。
团队 Rules参考：
# 测试规则规范 testing-rules.md (Testing Rules)，考虑篇幅，仅展示部分，完整版本私信 CodeBudy 领码
br
## 概述
br
本文档定义了团队内部的研发自测规范，确保功能交付质量，适用于旅行路书项目的所有开发人员。
br
## 测试分层策略
br
### 1. 单元测试 (Unit Testing)
- **覆盖率要求**: 核心业务逻辑 ≥ 80%，工具函数 ≥ 90%
- **测试框架**: Jest + React Testing Library
- **命名规范**: `*.test.ts` 或 `*.spec.ts`
- **文件位置**: 与源文件同目录或 `__tests__` 目录
br
#### 必测场景
- 所有工具函数 (`src/utils/`)
- 业务逻辑函数 (`src/lib/`)
- 自定义 Hooks (`src/hooks/`)
- 状态管理 (`src/stores/`)
- API 服务层 (`src/services/`)基于需求功能文档，AI 辅助生成测试验收文档示意图，仅部分展示。
---
type: always
---
# 用户注册功能单元测试指南
br
本文档提供了如何运行和维护用户注册功能单元测试的详细说明。
br
## 测试架构
br
我们使用以下技术栈进行测试：
br
- **Jest**: 测试运行器和断言库
- **React Testing Library**: 用于测试React组件
- **Jest Mock**: 用于模拟API调用和依赖
br
测试文件组织结构如下：
br
```
src/
├── app/
│ ├── user/
│ │ ├── register/
│ │ │ ├── __tests__/
│ │ │ │ └── page.test.tsx # 注册页面测试
│ │ ├── verify-email/
│ │ │ ├── __tests__/
│ │ │ │ └── page.test.tsx # 邮箱验证页面测试
│ │ ├── login/
│ │ │ ├── __tests__/
│ │ │ │ └── page.test.tsx # 登录页面测试
│ ├── api/
│ │ ├── user/
│ │ │ ├── __tests__/
│ │ │ │ ├── register.test.ts # 注册API测试
│ │ │ │ ├── verify-email.test.ts # 邮箱验证API测试
│ │ │ │ └── resend-verification.test.ts # 重发验证邮件API测试
```
br
## 安装依赖
br
br
### 测试覆盖率不足
br
如果测试覆盖率不达标，请考虑：
br
1. 添加更多测试场景（边界条件、错误情况等）
2. 确保测试涵盖所有代码路径
3. 检查是否有未测试的组件或API路由
br
在将代码提交到仓库之前，请确保所有测试都能通过：
br
```bash
./scripts/run-tests.sh --all
```
br
这有助于保持代码质量并防止引入回归问题。基于测试规范和需求文档，AI 辅助生成测试报告
Prompt 输入：
按照测试规范 @/testing-rules.md 测试规范和注册用户需求@/user-story-test-guide.md 文档，进行测试并生成一份 HTML 测试报告，测试不通过的问题，标注优先级并按照相关模块进行责任矩阵分配AI 生成测试报告
AI 生成测试覆盖率及责任问题矩阵分配示意图
4.3.7 发布阶段：制定变更方案
发布阶段主要是围绕发布计划制定，生产发布是一件严肃且慎重变更的事情，通常具有团队发布规范，并经过一定评审，以下基于团队发布计划，通过 AI 辅助生成上线计划，并提供上线发布建议，保障发布质量。
步骤 1：基于现有变更规范梳理，基于 AI 生成或完善发布规范
目标：具备团队生成发布规范。
方法：基于现有发布规范，给到 AI 生成团队发布规范，人工确认规范模版。
团队 Rules参考： 由于篇幅原因仅展示
---
globs:
alwaysApply: false
---
# 变更发布计划方案
## 关键规则
- 需求上线计划必须严格要整的发布目标、变更方案、灰度和预灰度发布和正式发布五个主要部分
- 发布定义必须需求到责任人、发布执行人、需求分级和风险等级
- 需求分级必须明确区分：P0、P1、P2、P3
- 发布计划必须详细说明上下游发布节奏，包括模块依赖关系和发布顺序：
4.3.8 定位DEbug
Debug 贯穿研发全流程，每次迭代解决旧问题，产生新问题， 在日常定位 bug 比较耗时，此时可以采用 AI 辅助。
步骤 1: 通过描述问题，利用 AI 进行 Debug
目标：通过 AI 解决 Bug
方法： 将问题，报错通过日志、截图，关联上下文定位 DEBug，并将每一次的修复，都借助 AI 进行记录下来。
示意图： fix with CodeBuddy 示意图
也可以借助 CLS MCP Server 日志系统辅助定位系统
学员评价