CodeBuddy AI Coding 企业场景落地实践与思考-腾讯云开发者社区-腾讯云
在 AI 浪潮席卷全球的今天，AI CODING 已经不是企业研发团队的可选项，而是必选项。
如果你是企业研发团队的负责人、 AI CODING 落地推动者或希望在工作中正在使用 AI CODING 工具的一线开发者，或多或少遇到一些落地困难，这篇文章结合日常团队的探索与实战，为你及你的团队提供一份可执行的 AI CODING 落地指南，欢迎和大家一起交流、探讨，也欢迎大家贡献更多相关 AI CODING 的优秀实践，相互学习，共同进步。
关注腾讯云开发者，一手技术干货提前解锁👇
AI CODING 工具在过去的几年高速发展里，根据 GitHub 2025年第一季度开发者调查报告，全球已有超过 1200 万开发者在使用 AI CODING 工具，相比 2024年增长140%，给 一线开发者带来巨大的效率提升，而 CodeBuddy 是腾讯自研提供的 AI CODING 工具，过去1年多以来帮助腾讯 5万+ 一线开发者提升编码效率，编码时长缩短 40%，AI 代码生成占比超 43%，同时也不断赋能腾讯外部一线开发者，帮助他们提升编码效率。
研发工具的提升一定引发研发流程的改进， 如何以最低的成本，最小的风险选好、并且引入后用好 AI CODING 工具，帮助团队实现最大化的研效，是很多研发团队当前需要或正在思考的问题。以 CodeBuddy 为例，自己是一线用户，也是落地推动者，背着产品在团队内落地的目标，常思考如何让 CodeBuddy 结合现有研发团队的研发流程，在研发团队中落地，达到提效的预期？如何持续满足一线用户的需求，高效解决他们的问题？这也是我们需要考虑和推进解决的，本篇简要讲述了 CodeBuddy 在个人/团队中落地的研发工程痛点、 解决方案和感受，期望提供一些参考思路。
02、诊断团队研发流程
Section titled “02、诊断团队研发流程”2.1 梳理团队研发流程现状
在没有引入 CodeBuddy 之前，我们需要站在研发管理的角度重新审视一下我们团队的研发流程，以及在研发各个阶段各个角色他们的痛点，分析哪些是可以借助 AI 帮助提效的。以下是基于一个需求级别的应用开发流程和协作现状，及各个阶段所做的事情。
（1）研发各阶段目标：
- 需求阶段： 进行需求的调研、需求的采集，以及需求/缺陷的创建、需求排期，制定迭代计划。
- 方案设计阶段： 根据需求颗粒度，制定产品方案、技术设计方案，设计交互稿方案，开展方案的可行性评估，确定方案设计，按照方案进行代码层面实现。
- 评审阶段： 针对代码实现层面进行代码 Review ，确保代码实现层面符合编码规范。
- 联调阶段： 进行前后端、基础设施层面 开发联调，确保前后端联通。
- 测试阶段： 进行功能测试，性能测试，接口测试等相关质量保障工作
- 发布阶段： 制定发布计划，进行功能上线，以及上线后的现网 Bug 定位和修复。
（2）协作现状： 基于各阶段目标，我们采用一张图来清晰的呈现我们在全流程的一个协作现状。
（3）涉及角色与分工：基于团队协作现状，我们针对各个角色，进行职责与痛点，需求挖掘， 如下：
- 研发 PM：
- 职责： 组织和协调人力安排，主要负责需求/缺陷等事项的跟进与推进排期上线。
- 痛点：
- 1.追人，追进度，信息不一致。
- 2.产品需求与代码实现不一致
- 核心需求： 整体项目进度风险诉求可控，发布计划如期落地。
- 产品经理：
- 职责： 需求调研、 需求澄清、需求/ 缺陷创建、产品迭代评审与产品方案设计、原型图
- 痛点：
- 1.产品方案/产品需求与代码实现层面存在不一致性
- 2.在追人、追进度，信息不一致上也存在一定痛点
- 3.此外，可能产品方案及细节考虑不全面。
- 4.从需求到设计稿周期长，反复沟通成本高，局部调整易破坏整体性
- 核心需求： 需求层面，目标确切，希望产品方案与技术实现落地一致且进度可控。
- UI**/UE 设计工程师：**
- 职责：负责产品交互设计稿等设计相关工作
- 痛点：从需求到设计稿耗时，反复沟通成本高，局部调整易破坏整体性
- 测试工程师：
- 职责： 负责产品功能测试方案及测试验收执行，与产品经理和研发工程师存在强协作。
- 痛点：
- 1.易漏测，手工测试验收慢
- 2.产品需求与代码实现不一致
- 3.解决进展无法快速获取，在追人、追进度，信息不一致上也存在一定痛点。
- 核心需求： 期望对产品方案和技术设计细节深入理解，测试方案设计面充分覆盖。
- 研发工程师：
- 职责： 负责技术方案设计、编码实现、Debug 定位与修复、产品和研发之间的需求目标的沟通协作，需求验收的变更调整。
- 痛点：
- 1.复杂业务存在耦合，需重构或重构不彻底，对功能开发造成债务影响。
- 2. 技术方案/产品需求/设计稿和代码实现存在不一致，产品等不接受。
- 3.开发过程受产品/测试等业务侧催办，分散精力，打乱开发节奏。
- 4.人工编码受限或编码重复编码工作多，缺乏创新。
- 核心需求：
- 1.系统架构解耦合，减轻历史债务。
- 2.迭代开发过程范围清晰且不变更。
- 3.快速且高效的编码，定位问题。
售前产品架构师/客户成功及售后工程师等其他角色：
- 职责： 负责产品售前和售后，技术咨询的服务工作。
- 痛点：
- 1.售卖产品或产品方案或功能需求与客户期望在交付功能层面存在不一致性。
- 2.在追人、追进度，信息不一致上也存在一定痛点。
2.2 解决思路
基于上述研发痛点，我们进行深度分析，并侧重围绕产品、研发、测试等核心角色的痛点，并兼顾其他角色的核心需求，尝试采用 AI进行应对解决。
| 选一款 AI CODING 工具，借助 AI Coding 工具进行辅助需求生成、方案设计，包括系统概要、技术设计、设计稿设计、测试设计等设计，人工进行确认 | ||
| ●人工技术实现难度●人工日编码极限瓶颈●人追人，精力分散 | 采用 CodeBuddy 工具，Agent 智能体，突破人工编码瓶颈尝试借助 AI 实现迭代总结和 企微机器人 MCP 随时的信息推送，确保迭代透明，供关注者及时获取，同时也建立定期会议机制，快速对齐 |
03、选择合适的 AI CODING 工具
Section titled “03、选择合适的 AI CODING 工具”3.1 AI CODING 工具的决策框架
目前 AI CODING 可选的工具数量很多，对于各种工具的出现，我们常抱着试一试的态度，进行体验使用，无论体验或选择何种 AI CODING 工具，在多轮验证中，都将为自己带来效率上的巨大提升，工欲善其事，必先利其器，器利则事半功倍， 选择一款好工具，将给你或你团队的开发效率带来质的提升。
在选择 AI CODING 工具，可根据个人/团队内部业务属性，基于核心关注点、权重及以下因素考量：
1. 技术匹配
- 工具支持的编程语言和框架，是否 团队内部用到的 IDE 类型
- 模型生成效果，代码质量和准确性如何
- 集成便利性，如 MCP 接入、多模型自助接入、内部系统集成
- 业务发展 与未来 AI CODING 产品路线图技术匹配度
2. 团队适应
- 用户学习成本
- 团队用户使用 AI 工具现状，工具的接受度/认可度，问题/根因
**3.**安全合规
4. 成本效益
5. 协作支持
- 业务团队需要的服务内容、服务形式（远程 or 现场）
基于上述维度，我们从安全合规、经济、技术匹配等因素，可以选择免费使用的 CodeBuddy 进行实践，接下来围绕 CodeBuddy 构建团队 AI 研发流程、落地过程的痛点解决方案与思考。
3.2 腾讯自研 AI CODING 工具 CodeBuddy 产品特色
我们发现国外很多一人公司或小而美的团队，形成超级个体，团队敏捷，因为不需要过多的复杂协作与沟通，个人或团队内实现闭环且非常高效；在 AI 时代，这种情况会更加明显。因此，我们认为未来：AI 会打破角色壁垒和工具孤岛，成为你的智能编程伙伴（Buddy ）
而角色/能力的边界，可以通过智能体进行协作和 AI 工具赋能，在 CodeBuddy 中将得到解决 ， 它提供 4 大智能体来驱动 AI 实现共同协作。
Plan Agent : 需求结构化，降低人的表达成本，支持将想法生成规范严格的需求文档和执行计划。
Design Agent ： 实设计生产化，支持将创意转成组件化、规范化、可交互的设计稿，深度集成 Figma 设计工具，一键生成高保真页面。
Coding Agent： 实现编码，工程化，通过 Agent 智能体能力，可以实现对项目级的理解，基于需求理解，自主实现多文件编码，从头构建完整的应用。
Deploy Agent : 交付简单化，内置腾讯云开发 CloudBase和 Supabase 后端服务，自动配置，一键部署到远端 CloudStudio 沙箱环境，即刻分享，未来也会深度集成公司内部/腾讯云 CVM/TKE、MySQL等基础设置，支持云端部署。
除了提供相应的智能体协作覆盖全流程，在服务专业开发者，企业开发者，CodeBuddy 也会在产品形态上，也助力个人/企业高效迈入智能研发时代，目前的支持 AI IDE 和 Plugin 插件形态，未来还会支持 CLI 、WbeAdmin、OpenAPI、SDK 形式提供能力支撑。
同时对于腾讯内部，会与内部研效工具做更多深度融合，提供差异化、定制化能力，基于腾讯内部大量用户和行业场景不断打磨产品，致力于为腾讯内部用户提供好用、易用、免费的产品体验，对腾讯外部用户提供具有腾讯特色的差异化 AI CODING 工具。
04、团队 AI 研发流程落地实践
Section titled “04、团队 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 、GPT2. 调研了解具体问题，具体对话场景，制定措施3. 寻找用的好的用户，内容沉淀和分享4. 制定团队的 AI 研发流程 SOP |
| 一句话描述需求，缺失详细的需求文档说明，需求范围不断变更，导致延期 | |
| 难以一次性清晰地向 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 实践，先看下效果。
当初，这是从 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---# 需求文档生成规则## 文档格式根据用户输入，以及结合你对本地项目工程理解，技术规格，生成的需求文档应包含以下部分：## 标准需求生成模板
用户提供信息时，请按照以下结构生成 需求文档：
```markdown# 项目名称：[项目名]
## 1. 项目概述### 1.1 项目背景[根据用户输入填写]
### 1.2 项目目标[根据用户输入填写]
### 1.3 目标用户[根据用户输入填写]
## 2. 功能需求### 2.1 核心功能- [功能1]- [功能2]- [功能3]
### 2.2 功能详细描述#### 2.2.1 [功能1][详细描述]
#### 2.2.2 [功能2][详细描述]
### 2.3 用户流程[描述用户如何使用系统完成主要任务]
## 3. 非功能需求### 3.1 性能要求[响应时间、并发用户数等]
### 3.2 安全要求[数据安全、身份验证等]
### 3.3 可用性要求[易用性、可访问性等]
## 4. 技术规格### 4.1 技术栈[前端、后端、数据库等]
### 4.2 系统架构[系统组件和交互]
### 4.3 第三方集成[需要集成的外部系统或API]
## 5. 优先级及责任矩阵- [优先级]- [XXX模块Owner]- [研发处理人]- [测试处理人]
## 6. 交付与验收：### 6.1 里程碑[主要项目阶段]
### 6.2 时间线[计划完成时间]
### 6.3 检验方式与验收标准[项目成功的衡量标准]
## 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设计稿生成规则
## 目的本规则用于根据用户指定的需求文档，生成对应的UI设计并输出为单个HTML文件。
## 步骤1. 读取用户指定的需求文档文件2. 分析需求文档中的功能需求和用户流程3. 根据需求生成适合的UI设计4. 将设计转换为单个HTML文件并输出到output目录
## UI设计生成指南
### 基本原则- 界面应简洁清晰，符合现代设计趋势- 优先考虑用户体验和易用性- 布局应响应式，适配不同设备- 遵循需求文档中描述的用户流程- 色彩方案应符合产品定位和目标用户群体
### 输出HTML要求- 单文件HTML，包含所有必要的CSS和JS- 不依赖外部资源（除非特别指定）- 注释清晰，代码结构合理- 实现需求文档中描述的核心功能- 提供基本交互效果展示
### 设计元素- 导航结构- 布局框架- 色彩方案- 字体选择- 按钮和表单样式- 图标和视觉元素
## 模板结构生成的HTML应包含以下基本结构：
```html<!DOCTYPE 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>
</style></head><body> <!-- 页面结构 --> <header> <!-- 导航栏 --> </header>
<main> <!-- 主要内容区域 --> </main>
<footer> <!-- 页脚 --> </footer>
<script>
</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 输入：基于你对本地工程的理解，进行项目介绍，帮我从全链路视角产出整体设计方案，定义清楚上下游边界及交互链路，并通过一个整体架构文档 @project-arch.md 将各方设计串联起来，需求模块的技术子 Owner 或新员工能够快速入门，投入需求开发工作示意图：
项目架构结构：
进一步可以借助 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作为架构师专家，我将基于以下文档进行方案评审并给出优化建议：
1.评审依据：- 技术架构文档- 概要设计文档（包括系统架构、模块划分、接口设计等）- 需求文档（功能需求、非功能需求、业务规则等）- 用户规则文档
2.评审范围：- 系统架构设计- 技术选型适配性- 数据模型设计- API设计与实现- 安全性设计- 性能与可扩展性- 测试策略- 部署与运维
3.评审后将提供：- 架构优化建议- 技术方案改进意见- 潜在风险预警- 编码规范补充建议
待评审通过后，团队可进入编码实现阶段。整体架构评审示意图：
安全性设计评审示意图：
评审报告：
基于上下文 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)
## 基础规则
### 1. 语言要求- **Always respond in 中文**- 所有回复、文档、代码注释都使用简体中文- 技术术语可保留英文，但需要中文解释
### 2. 变更记录管理 ⭐ 重要- **每次修改后必须更新 devlog.md**- **严禁删除历史记录** - 只能追加，不能覆盖- **使用 `replace_in_file` 在文件顶部添加新记录**- **采用时间倒序方式存储** (最新记录在顶部)- **时间格式**: [YYYY-MM-DD HH:MM]- **记录内容包括**: 修改文件、具体变更、影响范围
### 3. 系统环境- **操作系统**: macOS- **工作目录**: /Users/kongdeyuan/Desktop/awesome-repos/travel- **默认 Shell**: Zsh
### 4. 文件操作规范- **优先使用 `replace_in_file`** 进行文件修改- **只有在创建新文件时才使用 `write_to_file`**- **大文件修改时分批处理**，避免单次操作过大- **修改前先用 `read_file` 确认当前内容**
### 5. 代码规范- **组件命名**: PascalCase (如: TripCard)- **文件命名**: kebab-case (如: trip-card.tsx)- **变量函数**: camelCase (如: getUserData)- **常量**: UPPER_SNAKE_CASE (如: API_BASE_URL)- **TypeScript 优先**，所有新代码必须有类型定义
### 6. Git 提交规范- **提交格式**: `type(scope): description`- **类型**: feat, fix, docs, style, refactor, test, chore- **示例**: `feat(auth): 添加用户登录功能`
## devlog 更新模板
每次修改后，必须在 devlog.md 顶部添加以下格式的记录：
```markdown## [2024-MM-DD HH:MM] - 变更标题
### 修改内容- **文件名**: 具体修改内容- **文件名**: 具体修改内容
### 技术改进- 改进点1- 改进点2
### 文件变更- `path/to/file`: 变更类型 (新增/修改/删除)
### 影响范围- 影响的功能模块- 影响的用户群体
---```
## 操作检查清单
### 文件修改前- [ ] 使用 `read_file` 查看当前内容- [ ] 确定使用 `replace_in_file` 还是 `write_to_file`- [ ] 准备 devlog 更新内容
### 文件修改后- [ ] 验证修改是否正确- [ ] 更新 devlog.md (使用 `replace_in_file`)- [ ] 确认历史记录未被删除- [ ] 检查时间格式是否正确
## 错误预防
### 常见错误及预防1. **覆盖 devlog** → 永远使用 `replace_in_file`2. **删除历史记录** → 只在文件顶部添加新内容3. **时间格式错误** → 使用 [YYYY-MM-DD HH:MM] 格式4. **工具使用错误** → 一个响应中只能使用一次文件操作工具
### 紧急情况处理- 如果意外覆盖了文件，立即说明情况- 提供恢复方案或重新创建内容- 在下次操作中加强检查
## 质量标准
### 代码质量- 所有代码必须有 TypeScript 类型- 组件必须有 Props 接口定义- 函数必须有返回类型声明- 复杂逻辑必须有中文注释
### 文档质量- 所有文档使用中文编写- 技术术语提供中英文对照- 示例代码包含详细注释- 变更记录详细且准确
### 响应质量- 回复简洁明了，避免冗余- 技术解释通俗易懂- 提供具体的操作步骤- 包含必要的代码示例
---
*规则版本: 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 代码审查规则，部分展示
这是一套团队定制的 AI 代码审查规则，融合了企业 TypeScript 编码规范，旨在确保代码质量、一致性和可维护性。
## 基本原则及规则等级说明为明确规则的重要性和执行严格程度，并采用以下标记：
- 优先考虑代码的可读性和可维护性- 遵循一致性原则，保持代码风格统一- **规范等级**：【必须】= MUST/REQUIRED，【推荐】= SHOULD，【可选】= MAY - **【必须】**：必须严格执行，违反将导致构建失败或代码审查不通过 - **【推荐】**：强烈建议遵循，特殊情况可以申请豁免 - **【可选】**：建议性规范，有助于提高代码质量和可维护性
## 1. TypeScript 基础规范
### 1.1 类型定义【必须】
- **明确类型**: 所有变量、函数参数和返回值必须有明确的类型定义- **避免 any**: 除非绝对必要，否则不应使用 `any` 类型- **接口定义 Props**: 组件 Props 必须使用命名接口定义，而非内联类型- **类型集中管理**: 相关类型应集中在 `types` 目录下的适当文件中- **类型断言语法**: 使用 `as Type` 语法，禁止使用 `<Type>` 语法- **利用类型推断**: 基本类型变量应利用 TypeScript 的类型推断能力- **接口优先**: 优先使用 interface 而非 type，除非需要使用联合类型等特性
```typescript// ❌ 不推荐const Component = (props: any) => { /* ... */ }const foo = <string>bar;let num: number = 42;interface User { getName(): string; }
// ✅ 推荐interface ComponentProps { title: string; onAction: () => void;}
const Component = ({ title, onAction }: ComponentProps) => { /* ... */ }const foo = bar as string;const num = 42; // 自动推断interface User { name: string; getName: () => string;}```
通过遵循这些规则，我们可以确保代码库的质量、一致性和可维护性，同时提高开发效率和团队协作。示例：
需求生成 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 扫描方案进行该分支进行全量扫描
PS: tca-rules.md 参考：### 默认行为在用户提问时， 问到和 TCA (不区分大小写）相关 时，比如：请采用 ts/react 扫描方案进行所有分支进行全量扫描，或者执行TCA、TCA MCP server 时候，，请给我确认，是否增量或全量扫码，由我确认后，直接调用 tca-mcp-server 进行代码扫描。
### 能力约束当我问到 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
PS: 或点击小火箭按钮🚀一键部署示例：部署生成效果示意图
4.3.6 测试阶段：CodeBuddy 辅助生成测试文档及测试验收
此阶段，可以定义好团队测试规范，基于需求文档，借助 AI 可快速生成单元测试用例和生成单测报告。
步骤 1: 基于团队测试规则及功能需求文档，生成测试验收文档
目标：生成单个/多个功能测试验收文档。
方法：关联团队 Rules和需求文档，AI 辅助生成测试验收文档。
团队 Rules参考：
# 测试规则规范 testing-rules.md (Testing Rules)，考虑篇幅，仅展示部分，完整版本私信 CodeBudy 领码
## 概述
本文档定义了团队内部的研发自测规范，确保功能交付质量，适用于旅行路书项目的所有开发人员。
## 测试分层策略
### 1. 单元测试 (Unit Testing)- **覆盖率要求**: 核心业务逻辑 ≥ 80%，工具函数 ≥ 90%- **测试框架**: Jest + React Testing Library- **命名规范**: `*.test.ts` 或 `*.spec.ts`- **文件位置**: 与源文件同目录或 `__tests__` 目录
#### 必测场景- 所有工具函数 (`src/utils/`)- 业务逻辑函数 (`src/lib/`)- 自定义 Hooks (`src/hooks/`)- 状态管理 (`src/stores/`)- API 服务层 (`src/services/`)基于需求功能文档，AI 辅助生成测试验收文档示意图，仅部分展示。
---type: always---# 用户注册功能单元测试指南
本文档提供了如何运行和维护用户注册功能单元测试的详细说明。
## 测试架构
我们使用以下技术栈进行测试：
- **Jest**: 测试运行器和断言库- **React Testing Library**: 用于测试React组件- **Jest Mock**: 用于模拟API调用和依赖
测试文件组织结构如下：
```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测试```
## 安装依赖
### 测试覆盖率不足
如果测试覆盖率不达标，请考虑：
1. 添加更多测试场景（边界条件、错误情况等）2. 确保测试涵盖所有代码路径3. 检查是否有未测试的组件或API路由
在将代码提交到仓库之前，请确保所有测试都能通过：
```bash./scripts/run-tests.sh --all```
这有助于保持代码质量并防止引入回归问题。基于测试规范和需求文档，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 日志系统辅助定位系统
05、全面 CodeBuddy ，深入 CodeBuddy
Section titled “05、全面 CodeBuddy ，深入 CodeBuddy”5.1 价值收益
通过这套 AI 研发工作流，借助 CodeBuddy IDE 这款 AI CODING 工具，通过“面向文档驱动的 AI 编程”，可实现沟通结构化、开发过程标准化、系统化、资产化，最终实现从想法到产品的快速迭代。除此之外，还实现以下价值：
面向 Rules 文档编程， 深度激发人的思维和 CodeBuddy 潜力：通过面向文档编程，我们为 CodeBuddy 提供了丰富的 Rules 上下文， 让其发挥最大效能 。
请求-批准，指挥权归人 ： 人指挥 Codebuddy 干活，一个指令就让 CodeBuddy 负责需求理解、思考、规划、编码执行、多文件代码修改，以及终端执行 git add ”…”、git commit -m “xxx” 、git push origin ”…” ，包括 Deploy 应用部署操作，在线模拟生产场景，人工验收。在关键节点上，人来做最后的指挥权，是否“批准执行”，与CodeBuddy 形成“请求-批准”的协作模式。
角色转变： 让人从人工编码和繁杂重复的工作中释放潜能，并变成“监工”，实现角色左移/右移，我们不再是编码的执行者，而是流程的观察者和最高决策者。
每一步都可追溯： 基于User Rules 约束，每次AI CODING 都能保留了完整的开发过程和执行结果的 devlog.md ，极大利于 后续问题排查。
这套方法将AI CODING 从简单的“对话聊天”提升到了系统化的“项目级工程”维度，让我们能够真正驾驭 AI，去高效、可靠地完成复杂的独立开发任务。当前仅仅是一个落地探索，而腾讯内部存在不同团队的【需求级】或者【小需求级】实践，这边也可以踊跃征集，毕竟生产场景很复杂，面向不同场景也存在差异，比如 C 端/B 端/G 端，每个场景对交付质量、研发效率、服务SLA要求都各不相同，欢迎更多同学一起实践和探索 CodeBuddy。
5.2 心得感受
最后，我个人的心得感受是：
- 当前 AI 在不断抹平技术鸿沟，执行力才是核心关键。
- 早些拥抱CodeBuddy 这类 AI CODING 工具，可以让我们学的更快，解锁先进生产力。
- 实践中可小步快跑、持续迭代，最重要的是记得及时 git push your code !!!
- 4AI 编程在团队过程落地会存在很多挑战， 现在仅仅做文档标准化，任重而道远。
5.3 产品思考
- 多模态支持： 希望支持语音输入、文生图（均已排期），上面APP 我花了很多时间在网上找图，传COS，再批量修改。直接在对话框中生图，比如生成 混元3D 图，就非常便利了，而且可以满足游戏开发者需求。
- 安全层面： 基于TCA 代码分析结果可以直接传递到 CodeBuddy，CodeBuddy 一键进行修复
- 部署层面： 希望可以加速部署到腾讯云/DevCloud、TKE 等云原生环境之中。
Agent 智能体设计
- 【拆任务步骤】强化需求计划
- 【意图识别能力增强】精简+工程理解+记忆
- 优化意图识别算法，理解用户潜在需求轻量改动机制与确认回撤机制支持更多@Add Context类型探索和增加 AI 记忆模式，强化 AI 记忆能力，避免幻觉
- 【Rules】+ 【Prompt】+【上下文】+【知识库】开发权限和丰富
- 开放 Rules + Prompt 设计权，允许人工定义 AI 生成要求结合企业知识库，AI 生成符合业务需要的效果
5.4 未来展望
从编程的角度来看，如图，相信团队级别 AI 规约编程，未来以技术规范和系统设计会形成共识，会有更多的团队级别编程落地，同时，在团队中落地 AI CODING 过程一定会有摩擦，有分歧，有共识，特别是大型企业古老应用，或许不久将来，会诞生一个 “AI CODING 宣言” 作为理论支撑。
此外，未来研发工程师 + AI CODING 一定会比现在更加密切和共生，和业务关联跟密切，共同 奔赴AGI 。
06、诚邀共建
Section titled “06、诚邀共建”如果你在 CodeBuddy 使用或团队落地过程中遇到问题，可随时与我们联系反馈解决，也欢迎、期待和各位同仁共同探讨 AI CODING，分享你的实践 ，碰撞火花，共同成长!
-End-
原创作者｜deyuan
--- type: always --- # 需求文档生成规则 ## 文档格式 根据用户输入，以及结合你对本地项目工程理解，技术规格，生成的需求文档应包含以下部分： ## 标准需求生成模板 用户提供信息时，请按照以下结构生成 需求文档： ```markdown # 项目名称：[项目名] ## 1. 项目概述 ### 1.1 项目背景 [根据用户输入填写] ### 1.2 项目目标 [根据用户输入填写] ### 1.3 目标用户 [根据用户输入填写] ## 2. 功能需求 ### 2.1 核心功能 - [功能1] - [功能2] - [功能3] ### 2.2 功能详细描述 #### 2.2.1 [功能1] [详细描述] #### 2.2.2 [功能2] [详细描述] ### 2.3 用户流程 [描述用户如何使用系统完成主要任务] ## 3. 非功能需求 ### 3.1 性能要求 [响应时间、并发用户数等] ### 3.2 安全要求 [数据安全、身份验证等] ### 3.3 可用性要求 [易用性、可访问性等] ## 4. 技术规格 ### 4.1 技术栈 [前端、后端、数据库等] ### 4.2 系统架构 [系统组件和交互] ### 4.3 第三方集成 [需要集成的外部系统或API] ## 5. 优先级及责任矩阵 - [优先级] - [XXX模块Owner] - [研发处理人] - [测试处理人] ## 6. 交付与验收： ### 6.1 里程碑 [主要项目阶段] ### 6.2 时间线 [计划完成时间] ### 6.3 检验方式与验收标准 [项目成功的衡量标准] ## 7. 风险评估 - [风险项] - [影响程度] - [应对策略]
#Prompt 输入 基于 @requirement-rules.md 需求文档要求和当前工程理解，帮我完成生成用户管理系统的详细需求文档，包括用户的注册（注册支持手机号、邮件），删除，更改，查询及功能授权，并保存在我本地的 task/user-story.md 下面
# 需求文档转UI设计稿生成规则 ## 目的 本规则用于根据用户指定的需求文档，生成对应的UI设计并输出为单个HTML文件。 ## 步骤 1. 读取用户指定的需求文档文件 2. 分析需求文档中的功能需求和用户流程 3. 根据需求生成适合的UI设计 4. 将设计转换为单个HTML文件并输出到output目录 ## UI设计生成指南 ### 基本原则 - 界面应简洁清晰，符合现代设计趋势 - 优先考虑用户体验和易用性 - 布局应响应式，适配不同设备 - 遵循需求文档中描述的用户流程 - 色彩方案应符合产品定位和目标用户群体 ### 输出HTML要求 - 单文件HTML，包含所有必要的CSS和JS - 不依赖外部资源（除非特别指定） - 注释清晰，代码结构合理 - 实现需求文档中描述的核心功能 - 提供基本交互效果展示 ### 设计元素 - 导航结构 - 布局框架 - 色彩方案 - 字体选择 - 按钮和表单样式 - 图标和视觉元素 ## 模板结构 生成的HTML应包含以下基本结构： ```html <!DOCTYPE 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> <main> <!-- 主要内容区域 --> </main> <footer> <!-- 页脚 --> </footer> <script> // 此处包含所有JavaScript代码 </script> </body> </html>
输入： 根据 @ui-design-rules.md 设计规则，将 @user-story.md 需求文档生成UI设计稿, 并保存为user-story-design.html
Prompt 输入： 基于你对本地工程的理解，进行项目介绍，帮我从全链路视角产出整体设计方案，定义清楚上下游边界及交互链路，并通过一个整体架构文档 @project-arch.md 将各方设计串联起来，需求模块的技术子 Owner 或新员工能够快速入门，投入需求开发工作
输入： 帮我补充各个模块的责任矩阵，相关信息如下，以 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负责，主要提供通用组件和工具函数支持。
输入： 基于本地的项目架构@@project-arch.md 和@requirement-rules.md 需求标准化模版，帮我生成实现用户的注册、删除、改名、授权功能的需求文档 user-sory.md，同时基于该需求文档，辅助输出清晰的概要设计，需要包括核心功能、功能详细描述、表单验证、调用链路、非功能需求（如性能、可用性、可扩展性）、技术栈实现细节等。
输入： @user-management-design.md @user-rules.md @user-story.md 作为架构师专家，我将基于以下文档进行方案评审并给出优化建议： 1.评审依据： - 技术架构文档 - 概要设计文档（包括系统架构、模块划分、接口设计等） - 需求文档（功能需求、非功能需求、业务规则等） - 用户规则文档 2.评审范围： - 系统架构设计 - 技术选型适配性 - 数据模型设计 - API设计与实现 - 安全性设计 - 性能与可扩展性 - 测试策略 - 部署与运维 3.评审后将提供： - 架构优化建议 - 技术方案改进意见 - 潜在风险预警 - 编码规范补充建议 待评审通过后，团队可进入编码实现阶段。
Promot输入： @/user-story.md @/user-management-design.md @/user-rules.md 基于需求文档，登录页面效果，和概要设计文档以及结合本地工程理解，进行执行用户需求管理系统开发，确保功能可用，确保按照原型效果开发。 重点关注一下： - 创建前端组件，实现用户注册、登录和资料管理界面 - 实现客户端表单验证 - 添加用户操作的 UI 反馈 - 测试完整的用户流程
# 用户自定义规则 user-rules.md (User Rules) ## 基础规则 ### 1. 语言要求 - **Always respond in 中文** - 所有回复、文档、代码注释都使用简体中文 - 技术术语可保留英文，但需要中文解释 ### 2. 变更记录管理 ⭐ 重要 - **每次修改后必须更新 devlog.md** - **严禁删除历史记录** - 只能追加，不能覆盖 - **使用 replace_in_file在文件顶部添加新记录** - **采用时间倒序方式存储** (最新记录在顶部) - **时间格式**: [YYYY-MM-DD HH:MM] - **记录内容包括**: 修改文件、具体变更、影响范围 ### 3. 系统环境 - **操作系统**: macOS - **工作目录**: /Users/kongdeyuan/Desktop/awesome-repos/travel - **默认 Shell**: Zsh ### 4. 文件操作规范 - **优先使用replace_in_file** 进行文件修改 - **只有在创建新文件时才使用 write_to_file** - **大文件修改时分批处理**，避免单次操作过大 - **修改前先用 read_file确认当前内容** ### 5. 代码规范 - **组件命名**: PascalCase (如: TripCard) - **文件命名**: kebab-case (如: trip-card.tsx) - **变量函数**: camelCase (如: getUserData) - **常量**: UPPER_SNAKE_CASE (如: API_BASE_URL) - **TypeScript 优先**，所有新代码必须有类型定义 ### 6. Git 提交规范 - **提交格式**:type(scope): description- **类型**: feat, fix, docs, style, refactor, test, chore - **示例**:feat(auth): 添加用户登录功能## devlog 更新模板 每次修改后，必须在 devlog.md 顶部添加以下格式的记录： ```markdown ## [2024-MM-DD HH:MM] - 变更标题 ### 修改内容 - **文件名**: 具体修改内容 - **文件名**: 具体修改内容 ### 技术改进 - 改进点1 - 改进点2 ### 文件变更 -path/to/file: 变更类型 (新增/修改/删除) ### 影响范围 - 影响的功能模块 - 影响的用户群体 --- ``` ## 操作检查清单 ### 文件修改前 - [ ] 使用 read_file查看当前内容 - [ ] 确定使用replace_in_file还是write_to_file- [ ] 准备 devlog 更新内容 ### 文件修改后 - [ ] 验证修改是否正确 - [ ] 更新 devlog.md (使用replace_in_file) - [ ] 确认历史记录未被删除 - [ ] 检查时间格式是否正确 ## 错误预防 ### 常见错误及预防 1. **覆盖 devlog** → 永远使用 replace_in_file 2. **删除历史记录** → 只在文件顶部添加新内容 3. **时间格式错误** → 使用 [YYYY-MM-DD HH:MM] 格式 4. **工具使用错误** → 一个响应中只能使用一次文件操作工具 ### 紧急情况处理 - 如果意外覆盖了文件，立即说明情况 - 提供恢复方案或重新创建内容 - 在下次操作中加强检查 ## 质量标准 ### 代码质量 - 所有代码必须有 TypeScript 类型 - 组件必须有 Props 接口定义 - 函数必须有返回类型声明 - 复杂逻辑必须有中文注释 ### 文档质量 - 所有文档使用中文编写 - 技术术语提供中英文对照 - 示例代码包含详细注释 - 变更记录详细且准确 ### 响应质量 - 回复简洁明了，避免冗余 - 技术解释通俗易懂 - 提供具体的操作步骤 - 包含必要的代码示例 --- *规则版本: v1.0* *创建时间: 2025-08-08* *适用范围: travel 项目开发*
Prompt 输入：可在 Agent 任意输入，变更代码都可 基于你的优化建议，帮我执行一个计划，然后进行优化
# AI 代码审查规则，部分展示 这是一套团队定制的 AI 代码审查规则，融合了企业 TypeScript 编码规范，旨在确保代码质量、一致性和可维护性。 ## 基本原则及规则等级说明 为明确规则的重要性和执行严格程度，并采用以下标记： - 优先考虑代码的可读性和可维护性 - 遵循一致性原则，保持代码风格统一 - **规范等级**：【必须】= MUST/REQUIRED，【推荐】= SHOULD，【可选】= MAY - **【必须】**：必须严格执行，违反将导致构建失败或代码审查不通过 - **【推荐】**：强烈建议遵循，特殊情况可以申请豁免 - **【可选】**：建议性规范，有助于提高代码质量和可维护性 ## 1. TypeScript 基础规范 ### 1.1 类型定义【必须】 - **明确类型**: 所有变量、函数参数和返回值必须有明确的类型定义 - **避免 any**: 除非绝对必要，否则不应使用 any类型 - **接口定义 Props**: 组件 Props 必须使用命名接口定义，而非内联类型 - **类型集中管理**: 相关类型应集中在types目录下的适当文件中 - **类型断言语法**: 使用as Type语法，禁止使用 语法 - **利用类型推断**: 基本类型变量应利用 TypeScript 的类型推断能力 - **接口优先**: 优先使用 interface 而非 type，除非需要使用联合类型等特性 ```typescript // ❌ 不推荐 const Component = (props: any) => { /* ... */ } const foo = <string>bar; let num: number = 42; interface User { getName(): string; } // ✅ 推荐 interface ComponentProps { title: string; onAction: () => void; } const Component = ({ title, onAction }: ComponentProps) => { /* ... */ } const foo = bar as string; const num = 42; // 自动推断 interface User { name: string; getName: () => string; } ``` 通过遵循这些规则，我们可以确保代码库的质量、一致性和可维护性，同时提高开发效率和团队协作。
Prompt 输入： @global.d.ts @user.ts @jest.config.js @routes.ts @ai-code-review-rules.md 按照 ai code review rules 进行代码评审，给出相关评审建议，提供 HTML 评审报告并给我一个实施计划
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 安全评审报告并给我一个安全改进计划
Prompt 输入： 请采用 ts/react 扫描方案进行该分支进行全量扫描 PS: tca-rules.md 参考： ### 默认行为 在用户提问时， 问到和 TCA (不区分大小写）相关 时，比如：请采用 ts/react 扫描方案进行所有分支进行全量扫描，或者执行TCA、TCA MCP server 时候，，请给我确认，是否增量或全量扫码，由我确认后，直接调用 tca-mcp-server 进行代码扫描。 ### 能力约束 当我问到 TCA 或 TCA MCP Server 的时候，你的能力受限于下面几点： - 你只能 调用 TCA TCA MCP Server 的进行扫码，如果用户提出其他的需求，你应该回复：很抱歉，我当前只能处理代码扫描的需求。 - 一定要记住！你只能进行代码扫描，不能进行任何代码的生成！ - 以中文来与用户沟通，并保持礼貌。
Prompt 输入： 部署当前项目到云端环境，或Deploy current project to remote PS: 或点击小火箭按钮🚀一键部署
# 测试规则规范 testing-rules.md (Testing Rules)，考虑篇幅，仅展示部分，完整版本私信 CodeBudy 领码 ## 概述 本文档定义了团队内部的研发自测规范，确保功能交付质量，适用于旅行路书项目的所有开发人员。 ## 测试分层策略 ### 1. 单元测试 (Unit Testing) - **覆盖率要求**: 核心业务逻辑 ≥ 80%，工具函数 ≥ 90% - **测试框架**: Jest + React Testing Library - **命名规范**: .test.ts或.spec.ts- **文件位置**: 与源文件同目录或tests 目录 #### 必测场景 - 所有工具函数 (src/utils/) - 业务逻辑函数 (src/lib/) - 自定义 Hooks (src/hooks/) - 状态管理 (src/stores/) - API 服务层 (src/services/)
--- type: always --- # 用户注册功能单元测试指南 本文档提供了如何运行和维护用户注册功能单元测试的详细说明。 ## 测试架构 我们使用以下技术栈进行测试： - **Jest**: 测试运行器和断言库 - **React Testing Library**: 用于测试React组件 - **Jest Mock**: 用于模拟API调用和依赖 测试文件组织结构如下： ``` 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测试 ``` ## 安装依赖 ### 测试覆盖率不足 如果测试覆盖率不达标，请考虑： 1. 添加更多测试场景（边界条件、错误情况等） 2. 确保测试涵盖所有代码路径 3. 检查是否有未测试的组件或API路由 在将代码提交到仓库之前，请确保所有测试都能通过： ```bash ./scripts/run-tests.sh --all ``` 这有助于保持代码质量并防止引入回归问题。
Prompt 输入： 按照测试规范 @/testing-rules.md 测试规范和注册用户需求@/user-story-test-guide.md 文档，进行测试并生成一份 HTML 测试报告，测试不通过的问题，标注优先级并按照相关模块进行责任矩阵分配
--- globs: alwaysApply: false --- # 变更发布计划方案 ## 关键规则 - 需求上线计划必须严格要整的发布目标、变更方案、灰度和预灰度发布和正式发布五个主要部分 - 发布定义必须需求到责任人、发布执行人、需求分级和风险等级 - 需求分级必须明确区分：P0、P1、P2、P3 - 发布计划必须详细说明上下游发布节奏，包括模块依赖关系和发布顺序：
