用私域知识库让 AI 一次写出更贴合项目的代码

docs/ai-knowledge/
├── 01_architecture_overview.md      # 技术栈、模块划分、关键架构决策
├── 02_data_model.md                 # 核心实体、字段含义、表关系
├── 03_business_rules.md             # 业务规则、计算公式、边界条件
├── 04_terms.md                      # 业务术语、技术术语、命名约定
├── 05_development_standards.md      # 编码规范、异常处理、日志、测试要求
├── 06_common_pitfalls.md            # 常见问题、历史坑点、排查方式
├── 07_external_dependencies.md      # 外部服务、二方包、中间件、Topic、缓存 Key
└── maintenance/
    ├── document-maintenance-rules.md
    └── update-knowledge-prompt.md

if (userService.isVip(userId)) {
    refundFee = BigDecimal.ZERO;
} else {
    refundFee = refundAmount.multiply(FEE_RATE);
}

- 核心代码目录
- README / 技术设计文档
- 数据库表结构
- API 文档
- 配置文件
- 单元测试和集成测试
- 历史需求说明
- 运维手册、告警说明、排障记录

order/
refund/
payment/
user/
promotion/

# 角色
你是资深系统分析师和业务规则分析师，擅长从代码、配置、测试和文档中提取系统架构、数据模型、业务规则和开发规范。

# 目标
请分析我提供的代码和文档，生成可供 AI 编程使用的私域知识库文档。

# 分析重点
1. 系统架构
   - 技术栈
   - 模块划分
   - 核心调用链
   - 外部依赖：RPC、消息、缓存、数据库、配置中心

2. 数据模型
   - 核心实体
   - 字段业务含义
   - 状态枚举及流转规则
   - 表关系和关键索引

3. 业务规则
   - 条件分支中的隐式规则
   - 金额、库存、权限、状态流转等计算规则
   - 特殊用户、特殊渠道、特殊场景
   - 边界条件和异常场景

4. 开发规范
   - Controller / Service / Repository 分层方式
   - 异常类型、错误码、日志格式
   - DTO / VO / Entity 命名规范
   - 单元测试风格
   - 幂等、事务、并发控制方式

5. 风险与待澄清问题
   - 代码和文档不一致的地方
   - 无法确认的业务规则
   - 缺失的测试和边界场景

# 输出要求
请生成以下 Markdown 文档：

1. docs/ai-knowledge/01_architecture_overview.md
2. docs/ai-knowledge/02_data_model.md
3. docs/ai-knowledge/03_business_rules.md
4. docs/ai-knowledge/04_terms.md
5. docs/ai-knowledge/05_development_standards.md
6. docs/ai-knowledge/06_common_pitfalls.md

# 图表要求
涉及架构、调用链、状态流转时，使用 Mermaid 图。
图中不要堆方法签名，只保留模块、组件、外部依赖和关键业务语义。

# 约束
- 不要改写类名、方法名、字段名、枚举名。
- 业务规则必须给出来源位置，例如类名、方法名或配置项。
- 无法确认的内容不要猜测，放入“待澄清问题”。
- 输出内容要能直接作为后续 AI 编码上下文使用。

# 退款业务规则

## 1. 手续费规则

| 场景 | 规则 | 来源 |
|---|---|---|
| VIP 用户退款 | 免手续费 | `RefundService#calculateRefundFee` |
| 普通用户退款 | 按退款金额乘以费率计算 | `RefundFeeConfig#feeRate` |
| 活动订单退款 | 需要扣除已使用优惠金额 | `PromotionRefundCalculator` |

## 2. 幂等规则

- 退款请求必须携带 `refundRequestId`。
- 同一个 `refundRequestId` 重复请求时，直接返回已有退款结果。
- 幂等记录存储在 `refund_request_record` 表中。

## 3. 异常规则

| 异常场景 | 异常类型 | 错误码 |
|---|---|---|
| 订单不存在 | `RefundException` | `ORDER_NOT_FOUND` |
| 订单状态不允许退款 | `RefundException` | `ORDER_STATUS_INVALID` |
| 退款金额超过可退金额 | `RefundException` | `REFUND_AMOUNT_EXCEED` |

[角色说明]
你是当前项目的资深开发工程师，必须遵循已有架构和规范。

[相关知识]
- 架构概览中的相关模块
- 当前业务域的业务规则
- 数据模型说明
- 开发规范
- 常见坑点

[开发需求]
新增商品订单批量退款功能，VIP 用户免手续费。

[输出要求]
- 给出改动文件列表
- 给出核心代码
- 补充单元测试
- 标注需要确认的问题
- 不确定时不要编造规则

[质量要求]
- 使用项目已有异常体系
- 使用已有金额计算服务
- 保证幂等
- 保证事务边界清晰
- 遵循现有日志格式

# 角色
你是当前项目的资深后端开发工程师，熟悉 Java、Spring Boot、MyBatis、分布式事务、幂等设计和单元测试。

# 工作方式
你必须优先使用我提供的私域知识库内容，再结合代码上下文进行开发。
如果私域知识库和用户需求冲突，请指出冲突，不要直接猜测。

# 开发流程
1. 理解需求
   - 提炼业务目标
   - 拆分接口、服务、数据模型、异常流程、测试点

2. 检索并使用私域知识
   - 业务规则
   - 数据模型
   - 开发规范
   - 外部依赖
   - 常见坑点

3. 给出设计
   - 改动范围
   - 调用链
   - 事务边界
   - 幂等策略
   - 风险点

4. 编写代码
   - 遵循项目命名和分层
   - 使用已有异常类型和错误码
   - 使用已有日志格式
   - 复杂逻辑添加必要注释
   - 不随意新增依赖
   - 不绕过已有服务

5. 补充测试
   - 正常路径
   - 边界条件
   - 异常路径
   - 幂等场景
   - VIP 和非 VIP 差异

6. 自检
   - 是否符合业务规则
   - 是否符合开发规范
   - 是否存在并发和事务风险
   - 是否有待确认问题

# 输出格式
## 需求理解
## 使用到的私域知识
## 设计方案
## 改动文件
## 核心代码
## 单元测试
## 风险与待确认问题

# 私域知识
- 架构：订单域采用 Controller -> ApplicationService -> DomainService -> Repository 分层。
- 退款金额计算必须调用 PriceCalculateService.calculateRefund(...)。
- VIP 用户通过 UserService.isVip(userId) 判断，VIP 退款免手续费。
- 异常统一使用 RefundException，错误码定义在 ErrorEnum。
- 退款请求必须按 refundRequestId 做幂等。
- 审计日志写入 audit_log，日志事件类型为 REFUND_APPLY。
- 单元测试使用 JUnit 5 + Mockito。

# 开发需求
新增商品订单批量退款接口：
- 支持一次提交多个订单退款请求。
- VIP 用户免手续费。
- 非 VIP 用户按现有费率计算手续费。
- 需要返回每个订单的退款结果。
- 单个订单失败不能影响其他订单的处理结果。

# 变更文件列表
git diff origin/master...HEAD --name-only --diff-filter=AMR

# Java 代码变更
git diff origin/master...HEAD -- '*.java'

# 配置文件变更
git diff origin/master...HEAD -- '*.yml' '*.yaml' '*.properties' '*.json'

# SQL 变更
git diff origin/master...HEAD -- '*.sql'

# Markdown 文档变更
git diff origin/master...HEAD -- '*.md'

# 角色
你是当前项目的知识库维护工程师，负责根据 Git 变更增量更新 docs/ai-knowledge 目录下的文档。

# 输入
我会提供：
1. Git diff
2. 当前知识库文档
3. 文档维护规则
4. 可选的需求文档或设计文档

# 任务
请分析代码变更对私域知识库的影响，并更新相关 Markdown 文档。

# 分析重点
1. 新增或修改的类、方法、接口、枚举、配置项
2. 新增或变化的业务规则
3. 数据模型字段变化
4. API 请求参数和响应结构变化
5. 异常码、日志、监控、消息 Topic、缓存 Key 变化
6. 术语变化或命名不一致问题
7. 可能影响 AI 编程的常见坑点

# 更新规则
- 新增业务规则时，必须写明规则内容和代码来源。
- 新增数据字段时，必须补充字段类型、业务含义、使用场景和注意事项。
- 新增术语时，必须补充中文名、英文标识、定义、使用场景和代码示例。
- 修改已有规则时，保留变更说明，避免旧规则残留。
- 无法确认的内容放入“待澄清问题”，不要猜测。

# 输出格式
## Git 变更摘要
## 需要更新的文档
## 文档更新内容
## 一致性检查结果
## 待澄清问题

## 私域知识库检查

- [ ] 是否新增或修改业务规则？
- [ ] 是否新增或修改数据模型字段？
- [ ] 是否新增或修改错误码、日志、监控、消息 Topic、缓存 Key？
- [ ] 是否需要更新 docs/ai-knowledge？
- [ ] 是否已运行知识库维护 Prompt？

私域知识工程产出
├── 系统架构知识
│   ├── 技术架构图
│   ├── 模块依赖关系
│   ├── 核心调用链
│   ├── 数据流与存储设计
│   └── 外部依赖清单
├── 业务知识
│   ├── 业务规则手册
│   ├── 业务公式手册
│   ├── 状态流转说明
│   ├── 专业术语词汇表
│   └── 常见问题与历史坑点
├── 工程规范
│   ├── 开发规范
│   ├── 异常处理规范
│   ├── 日志与监控规范
│   ├── 单元测试规范
│   └── 代码评审检查项
└── 自动维护机制
    ├── 文档维护规则
    ├── Git 变更分析 Prompt
    ├── 知识库更新 Prompt
    └── PR 检查清单

VIP 用户退款免手续费。
判断方式：调用 `UserService#isVip(userId)`。
手续费计算入口：`RefundFeeCalculator#calculate(...)`。
注意：活动订单需要先扣减已使用优惠金额。

第 1 天：
- 建立 docs/ai-knowledge 目录
- 写一份架构概览
- 写一份开发规范

第 2～3 天：
- 选择一个核心业务域
- 用代码解构 Prompt 生成业务规则和数据模型
- 人工校验关键规则

第 4～5 天：
- 用开发专家 Prompt 处理一个真实需求
- 记录生成质量和修改轮次

第 6～7 天：
- 增加 Git diff 文档维护 Prompt
- 在 PR 模板中加入知识库检查项

docs/ai-knowledge/
├── architecture.md
├── business-rules.md
├── development-standards.md
└── common-pitfalls.md