知识驱动开发：用iFlow工作流构建本地知识库

原创于 2025-12-19 11:16:27 发布 · 622 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#前端 #iFlow CLI #ai #iflow #iflowcli #mcp #RAG

作者：单冲

概述

接触AI编程工具以来，一直思考怎样用知识库解决AI工具不了解业务的问题。传统的RAG知识库只有关键词匹配和被动文档检索功能。

而在实际的编程场景中，需要知识库具备深度语义理解与场景感知能力，为开发者提供更精准、高效且可验证的信息服务。与传统RAG知识库的差别可以用“智能大脑”与“数字图书馆”来类比：前者能主动联想、理解语境并推理，后者仅能被动存储与机械检索。这就是最近大火的Agentic RAG。

在对 AI Coding 工具进行一定的调研后，我尝试用 iFlow CLI 的工作流作为 Agent 驱动，构建本地知识库——iFlow CLI 更加轻量化，扩展性更好，封装、移植、升级会更方便。相比 Claude Code 安全性和成本更有优势。

参考现实世界开发人员的知识获取方式，将知识分成了3层：记忆、文档、代码。

代码：实现相对直观，这里不赘述；
文档：业务知识分为两类，通识知识与非通识知识。通识知识具有相对稳定性，便于广泛传播和复用；非通识知识则更新频繁、权威性难以确认，需要更严格的验证与持续维护机制。
记忆：应该是比文档知识密度更高的结构，知识获取的速度远高于文档和代码，利用 iFlow CLI 的 Memory 功能实现。

文档结构

通识知识：

名词术语库：核心概念和业务术语的标准定义
核心流程图：关键业务流程和技术流程
领域模型库：稳定的数据模型和业务模型
接口规范库：API文档和接口标准
解决方案历史：经过验证的技术方案和决策依据

非通识知识：

需求文档：个人负责的具体需求和分析
技术方案：个人设计的技术实现方案

知识循环机制：

在技术方案设计阶段，个人可选择性参考共享层的解决方案历史作为决策支撑；方案交付后，将有价值的经验沉淀回共享层，形成知识的持续更新循环。

这种架构既保证了核心知识的稳定性和一致性，又为个人创新提供了灵活空间，同时通过循环机制实现知识的持续积累和迭代优化。

项目背景

业务需求

评论系统集成用户信用奖励机制。

开发挑战

多年迭代积累了大量技术债务
技术文档缺失，过时不可信
首次接触该代码库，业务理解存在门槛

知识管理体系设计

知识库构建过程

创建工作空间，拉取评论域 3 个核心应用的代码库，构建完整的开发环境。使用 iFlow CLI 作为 AI 引擎，通过读取和分析代码自动提取技术知识，结合我对业务需求的理解，与 AI 协同设计技术方案。同时采用 Obsidian 作为可视化知识管理工具，构建结构化的文档系统形成知识图谱，实现知识的可视化组织和高效检索。

记忆/Rules

记忆是知识库中最核心的组成部分，图谱型知识库是最理想的记忆实现方案，但市面上缺少合适的技术，退而求其次，我选择使用 iFlow CLI 中的 Memory 功能。

iFlow CLI 的/memory机制构建了三级规则体系：User 级全局规则、Project 级项目规则、subAgent 级执行规则。这种分层设计实现了从宏观到微观的精细化管控，其中 subAgent 层提供执行粒度的精确控制，建立了三级管控：用户级(中文指令)、项目级(角色分工)、执行级(精确控制)。

没使用记忆vs使用记忆

记忆机制作为知识库的架构。实际应用中需要特别注意信息筛选，避免无限制地向记忆中填充内容，否则会超出大模型的上下文处理能力。

在我的使用策略中，每个需求对应一个独立的工作空间。Project 记忆区专门存储角色分工、文档索引和项目背景等核心信息；而 User 记忆区仅保留一条关键指令：所有回答请使用中文。

多 Agent 角色定义

该项目包含 3 个评论域应用，业务关联度极高。需要 AI 在宏观层面处理跨应用技术分工与架构整合，在微观层面专注单应用深度开发。subAgent 的上下文隔离特性为这种多层次协作提供了理想的技术支撑。

业务流程知识化

业务流程知识提取

作为首次接触该系统的开发者，我通过AI辅助快速理解代码结构和梳理技术细节。AI在功能接口定位和业务流程梳理方面节省了2-3天的人工梳理时间，相当于通过持续绘制架构图、流程图和数据流图来建立清晰的系统认知。这个过程不仅是知识构建，更是我个人对评论系统从陌生到熟悉的学习成长历程。

自定义IFlow工作流，封装知识库的构建过程：

提示词示例：用户评论提交接口文档整理一下，生成一个md文件

通过架构师角色的AI辅助，我能够站在评价域的宏观视角进行思考和学习，使其能够站在评价域的宏观视角进行思考。这种架构层面的分析不会局限于单一应用内部，从而"避免了单应用视角局限，产出全局一致性知识。

# 评论系统功能点综合交互流程图

```mermaid
graph TD
    %% 用户角色
    User((用户)) --> Client[客户端<br/>移动APP/Web]
    
    %% 评论中心 (amap-aos-appraise-center)
    subgraph 评论中心 [amap-aos-appraise-center]
        AC_API[API网关]
        AC_Controller[Controller层<br/>AppraiseController<br/>ContentEditorController]
        AC_Service[Service层<br/>AppraiseCreateAppService<br/>ContentEditorTemplateAppService]
        AC_Domain[领域层<br/>AppraiseRoot<br/>Factory工厂]
        AC_Integration[集成层<br/>CreditUtil<br/>消息发布]
        AC_DB[(数据库)]
        
        Client --> AC_API
        AC_API --> AC_Controller
        AC_Controller --> AC_Service
        AC_Service --> AC_Domain
        AC_Domain --> AC_Integration
        AC_Integration --> AC_DB
    end
    
    %% 审核后台 (poi-cmt-console)
    subgraph 审核后台 [poi-cmt-console]
        AU_Listener[消息监听]
        AU_Controller[Controller层<br/>TaskController]
        AU_Service[Service层<br/>ExamineOperateService<br/>TaskPackageDomainService]
        AU_Audit[审核处理<br/>TaskAuditRelateDomainService]
        AU_Reward[RewardService<br/>奖励服务]
        AU_DB[(数据库)]
        
        AC_Integration -- 消息推送 --> AU_Listener
        AU_Listener --> AU_Controller
        AU_Controller --> AU_Service
        AU_Service --> AU_Audit
        AU_Audit --> AU_Reward
        AU_Service --> AU_DB
        AU_Audit --> AU_DB
        AU_Reward --> AU_DB
    end
    
    %% 评论消费中心 (martian-sns-comment)
    subgraph 评论消费中心 [martian-sns-comment]
        CC_Listener[消息监听]
        CC_API[API接口<br/>UgcCommentIFaceImpl]
        CC_Service[Service层<br/>UgcCommentService<br/>UserCreditService]
        CC_DB[(数据库/缓存)]
        
        AC_Integration -- 消息推送 --> CC_Listener
        Client --> CC_API
        CC_API --> CC_Service
        CC_Service --> CC_DB
    end
    
    %% 外部系统
    subgraph 外部系统
        C1_API[C1接口<br/>用户信用服务]
        Taobao_API[淘宝奖励接口]
        MQ[消息队列]
        Cache[(Redis缓存)]
    end
    
    %% 功能点交互连接
    AC_Service -->|调用| C1_API
    AC_Integration -->|推送| MQ
    AU_Audit -->|调用| C1_API
    AU_Reward -->|回调| C1_API
    AU_Reward -->|调用| Taobao_API
    CC_Service -->|调用| C1_API
    AC_Service --> Cache
    CC_Service --> Cache
    AU_Service --> Cache
    
    %% 审核员角色
    Auditor((审核员)) --> AU_Controller
    
    %% 数据流向
    AC_DB <--> AU_DB
    AC_DB <--> CC_DB
    AU_DB <--> CC_DB
    
    style User fill:#FFE4C4,stroke:#333
    style Auditor fill:#FFE4C4,stroke:#333
    style Client fill:#87CEEB,stroke:#333
    style 评论中心 fill:#98FB98,stroke:#333
    style 审核后台 fill:#98FB98,stroke:#333
    style 评论消费中心 fill:#98FB98,stroke:#333
    style C1_API fill:#DDA0DD,stroke:#333
    style API fill:#DDA0DD,stroke:#333
    style MQ fill:#FFB6C1,stroke:#333
    style Cache fill:#DDA0DD,stroke:#333
    
    classDef user fill:#FFE4C4,stroke:#333
    classDef client fill:#87CEEB,stroke:#333
    classDef service fill:#98FB98,stroke:#333
    classDef external fill:#DDA0DD,stroke:#333
    classDef middleware fill:#FFB6C1,stroke:#333
    
    class User,Auditor user
    class Client client
    class 评论中心,审核后台,评论消费中心 service
    class C1_API,Taobao_API,Cache external
    class MQ middleware
```

## 功能点详细交互流程

### 功能点1: 编辑器模板下发 + 用户信用等级获取
```mermaid
sequenceDiagram
    participant U as 用户
    participant C as 客户端
    participant AC as 评论中心
    participant C1 as C1接口(用户信用)
    participant CC as 评论消费中心

    U->>C: 请求编辑器模板
    C->>AC: HTTP请求 /editor/template
    AC->>AC: ContentEditorController接收请求
    AC->>AC: ContentEditorTemplateAppService处理
    AC->>AC: CreditModuleCreator构建模块
    AC->>C1: 调用getCreditAuthInfo()
    C1-->>AC: 返回用户信用等级
    AC->>AC: 将用户信用信息加入编辑器数据
    AC-->>C: 返回编辑器模板(含用户信用)
    C-->>U: 展示编辑器(显示用户信用等级)
```

### 功能点2: 笔记创建提交 + 是否同意参数
```mermaid
sequenceDiagram
    participant U as 用户
    participant C as 客户端
    participant AC as 评论中心
    participant MQ as 消息队列
    participant AU as 审核后台

    U->>C: 提交笔记(含同意授权)
    C->>AC: HTTP请求 /note/create
    AC->>AC: AppraiseController接收
    AC->>AC: AppraiseMapNoteAppService.createAppraiseInner()
    AC->>AC: 参数校验(检查是否同意授权)
    AC->>AC: AppraiseRoot.create4Xdb()保存数据库
    AC->>AC: AppraiseRoot.sendAddMsgEvent()发送消息
    AC->>MQ: 推送审核消息
    MQ->>AU: 消息投递
    AU->>AU: TaskController接收消息
    AU-->>C: 返回创建成功
    C-->>U: 提示创建成功
```

### 功能点3: 笔记送审 + 用户等级信息
```mermaid
sequenceDiagram
    participant AC as 评论中心
    participant MQ as 消息队列
    participant AU as 审核后台
    participant C1 as C1接口(用户等级)

    AC->>MQ: 推送审核消息(含基础评论信息)
    MQ->>AU: 消息投递
    AU->>AU: TaskController处理消息
    AU->>AU: ExamineOperateService.preProcess()
    AU->>C1: 调用getUserLevel(userId)
    C1-->>AU: 返回用户等级信息
    AU->>AU: 将用户等级信息添加到审核任务
    AU->>AU: TaskPackageDomainService.createTask()
    AU->>AU: 生成完整的审核任务(含用户等级)
```

### 功能点4: 审核后台进审 + 用户等级和奖励信息
```mermaid
sequenceDiagram
    participant Auditor as 审核员
    participant AU as 审核后台
    participant AU_DB as 审核数据库

    Auditor->>AU: 登录审核系统
    Auditor->>AU: 拉取审核任务 /task/pull
    AU->>AU: TaskController.taskPull()
    AU->>AU_DB: 查询待审核任务
    AU_DB-->>AU: 返回任务列表(含用户等级、奖励信息)
    AU-->>Auditor: 返回审核任务(展示用户等级)
    Auditor->>AU: 执行审核 /task/operate
    AU->>AU: TaskAuditRelateDomainService.process()
    AU->>AU_DB: 更新审核状态和奖励信息
```

### 功能点5: 奖励发放回调 + 完成状态 + 通知
```mermaid
sequenceDiagram
    participant AU as 审核后台
    participant RS as RewardService
    participant C1 as C1接口(奖励回调)
    participant U as 用户

    AU->>RS: 触发奖励发放
    RS->>RS: handleRewardCallback()
    RS->>C1: HTTP回调 /reward/callback
    C1->>C1: 处理奖励发放逻辑
    C1-->>RS: 返回发放结果
    RS->>RS: 更新奖励状态=完成
    RS->>RS: 记录奖励日志
    RS->>U: 发送奖励通知(短信/推送)
```

### 功能点6: 质量分后奖励 + 淘宝接口 + 进行中状态
```mermaid
sequenceDiagram
    participant AU as 审核后台
    participant RS as RewardService
    participant TB as 淘宝奖励接口

    AU->>AU: 评论质量分评估完成
    AU->>RS: 触发质量奖励 processQualityReward()
    RS->>RS: prepareRewardData()
    RS->>TB: 调用淘宝奖励接口 /api/reward/send
    TB->>TB: 处理奖励发放
    TB-->>RS: 返回处理结果
    RS->>RS: 更新奖励状态=进行中
    RS->>RS: 记录发放流水
```

### 功能点7: POI详情页我的评论 + 用户奖励状态
```mermaid
sequenceDiagram
    participant U as 用户
    participant C as 客户端
    participant CC as 评论消费中心
    participant CC_DB as 数据库

    U->>C: 请求POI详情页我的评论
    C->>CC: HTTP请求 /comment/mylist
    CC->>CC: UgcCommentIFaceImpl.myCommentList()
    CC->>CC_DB: 查询评论数据
    CC_DB-->>CC: 返回评论基础信息
    CC->>CC: UgcCommentService.processCommentList()
    CC->>CC: 从缓存/数据库获取用户奖励状态
    CC-->>C: 返回完整评论数据(含奖励状态)
    C-->>U: 展示我的评论(显示奖励状态)
```

### 功能点8: 我的评论页个人信息 + 用户等级
```mermaid
sequenceDiagram
    participant U as 用户
    participant C as 客户端
    participant CC as 评论消费中心
    participant C1 as C1接口(用户等级)

    U->>C: 请求我的评论页个人信息
    C->>CC: HTTP请求 /user/info
    CC->>CC: UgcCommentIFaceImpl.getUserInfo()
    CC->>CC: UserCreditService.getUserCreditInfo()
    CC->>C1: 调用C1接口获取用户等级
    C1-->>CC: 返回用户等级信息
    CC->>CC: 组装用户个人信息
    CC-->>C: 返回个人信息(含用户等级)
    C-->>U: 展示个人信息(显示用户等级)
```

### 功能点9: 已评价列表 + 奖励信息
```mermaid
sequenceDiagram
    participant U as 用户
    participant C as 客户端
    participant CC as 评论消费中心
    participant CC_DB as 数据库

    U->>C: 请求已评价列表
    C->>CC: HTTP请求 /comment/commented_list
    CC->>CC: UgcCommentIFaceImpl.commentedList()
    CC->>CC_DB: 查询用户已评价列表
    CC_DB-->>CC: 返回评论列表数据
    CC->>CC: UgcCommentService.enrichCommentData()
    CC->>CC: 从数据库获取每条评论的奖励信息
    CC->>CC: 组装完整评论列表
    CC-->>C: 返回已评价列表(含奖励信息)
    C-->>U: 展示已评价列表(显示奖励信息)
```

## 数据模型增强交互

### UgcNewCommentMessage增强字段使用
```mermaid
graph LR
    A[AppraiseDTO] --> B[UgcNewCommentMessageConverter]
    B --> C[UgcNewCommentMessage<br/>增强字段]
    C --> D[直接存储<br/>避免JSON解析]
    D --> E[性能优化]
    
    subgraph 增强字段
        F[creditAuthorized<br/>用户信用授权状态]
        G[creditLevel<br/>用户信用等级]
        H[rewardInfos<br/>奖励信息列表]
    end
    
    C --> F
    C --> G
    C --> H
```

## 系统间数据流转

### 核心数据结构
```mermaid
graph TD
    subgraph 评论中心数据
        AC_Data[AppraiseDTO<br/>评论数据DTO]
        AC_Extra[ExtraInfo<br/>扩展信息JSON]
    end
    
    subgraph 消费中心数据
        CC_Data[UgcNewCommentMessage<br/>增强字段模型]
        CC_Fields[直接字段存储<br/>creditAuthorized<br/>creditLevel<br/>rewardInfos]
    end
    
    subgraph 数据库存储
        DB_Record[评论记录<br/>包含所有信息]
    end
    
    AC_Data -->|转换| CC_Data
    AC_Extra -->|解析| CC_Fields
    CC_Data -->|持久化| DB_Record
    CC_Fields -->|存储| DB_Record
```

## 错误处理与补偿机制

### 异常流程处理
```mermaid
graph TD
    A[正常流程] --> B[接口调用]
    B --> C{调用成功?}
    C -->|是| D[继续处理]
    C -->|否| E[记录错误日志]
    E --> F[触发补偿机制]
    F --> G[重试策略]
    G --> H[最大重试次数?}
    H -->|未达到| B
    H -->|达到| I[人工干预]
    
    subgraph 补偿机制
        J[消息队列重试]
        K[定时任务补偿]
        L[告警通知]
    end
    
    F --> J
    F --> K
    F --> L
```

## 监控指标

### 关键性能指标(KPIs)
```mermaid
graph TD
    subgraph 性能指标
        A[接口响应时间<br/><200ms]
        B[系统可用性<br/>>99.9%]
        C[并发处理能力<br/>>1000QPS]
    end
    
    subgraph 业务指标
        D[评论创建成功率<br/>>99.5%]
        E[审核处理时效<br/><24小时]
        F[奖励发放准确率<br/>>99.9%]
    end
    
    subgraph 用户体验指标
        G[编辑器加载时间<br/><1秒]
        H[评论展示延迟<br/><100ms]
        I[奖励通知及时性<br/><5分钟]
    end
```

这个综合流程图展示了评论系统中所有功能点的详细交互关系，包括数据流向、接口调用、异常处理等方面，为系统的理解和维护提供了全面的视图。

技术接口知识沉淀

以接口文档示例.md为模版，编写一下内容编辑器模板接口文档

可视化知识构建

为评论系统需求创建集成工作空间，统一管理相关代码仓库。基于集中式文档架构，配合Obsidian可视化平台，建立可操作的知识管理流程，通过信息聚合与图形化展示的有机结合，实现整体效能的显著提升。

知识应用实践

AI 协作开发全流程

需求分析阶段：我提出业务需求，AI快速定位关键接口并梳理完整业务流程。

方案设计阶段：双方深度讨论技术架构，确定最优实现路径后，AI承担核心代码开发。

质量保障阶段：通过代码审查确保质量，AI同步生成详细的接口文档。

测试优化阶段：我负责系统部署与全面测试，AI协助问题诊断与解决方案制定。

交付阶段：经多轮迭代优化，系统稳定运行，业务需求全面达成，输出完整项目文档。

需求分析阶段

初次接触评论业务，PRD串讲帮助我理解了基本需求。尽管开发经验让我能识别技术改动点，但期望AI仅凭PRD就能输出成熟技术方案并不切实际。

方案设计阶段

在AI架构师的协助下，逐步深入理解评论域业务逻辑，建立了更全面的认知。基于对需求的深刻理解，通过与架构师的多轮深入讨论，最终形成了一套完整的技术解决方案。在整个方案设计过程中，我新增了12个核心接口文档，完善了5个关键业务流程知识库中的相关内容，确保技术方案与业务需求的完美契合。

开发实施阶段

由 iFlow CLI 读取知识库生成各功能点的提示词，再进行开发。

## 核心需求
**编辑器模板下发功能**：在编辑器模版的高级配置中，根据用户信用开通状态，条件性显示"评价计入用户信用评分"开关。
## 技术实现要点
1. **下游接口调用**：需要调用用户信用接口获取用户开通状态
2. **条件渲染**：基于接口返回结果决定是否显示开关
3. **位置**：编辑器模板的高级配置区域
## 核心实现逻辑
用户请求编辑器模板 
    ↓
调用用户信用状态接口 
    ↓
判断用户是否开通用户信用
    ↓
如果开通：显示"评价计入用户信用评分"开关
如果未开通：不显示该开关

提示词工程的三要素框架：

角色(Role)：通过专业身份设定激活模型的特定能力参数
背景(Context)：提供充分的上下文信息引导模型推理方向
任务(Task)：明确具体的执行目标和输出要求

当模型理解偏差时，重点检查这三个维度的完整性和准确性，就像这样：

我在自测，发现了一个问题，访问编辑器接口的时候，不管我传什么uid。都能返回用户信用开关模块。请评论中心的开发人员帮我排查一下

开发人员agent，都检查一下自己的应用，看看获取用户信用授权信息的接口有没有类似的用法问题。

测试验证阶段

基于知识库生成测试清单

让架构师帮我生成测试清单，然后我来部署代码后手动测试。

# 用户信用集成项目 - 按业务流程测试清单

> **项目**: credit-integration  
> **创建时间**: 2025-08-28  
> **状态**: 待测试  
> **测试策略**: 按评论业务流程顺序测试，确保数据流转逻辑正确

## 📋 按业务流程顺序的测试清单

### 阶段一：评论创建前 - 用户信息获取

#### 1. 编辑器模板接口 【已完成】
**业务流程**: 用户打开编辑器 → 获取模板 → 显示用户信用信息  
**接口类型**: HSF服务  
**服务**: `xxxxxx.IContentEditorTemplateService:1.0.0`  
**方法**: `getTemplate`  
**测试状态**: ✅ 已完成  
**测试结果**: 用户信用模块配置正确，显示逻辑已修复，NPE问题已解决  
**测试数据**: uid=11111, poiId=111111  
**修复内容**:  
- 添加了creditRpcService的null检查  
- 增加了异常处理机制  
- 保持了代码整洁性，数据类型保持Integer  

#### 2. 接口 - 用户信用查询 【高优先级】
**业务流程**: 编辑器模板 → 调用C1接口 → 获取用户信用等级  
**接口类型**: HTTP POST  
**第三方服务**: 用户信用C1接口  
**URL**: `/ws/ple/inner/auth/info`  
**测试场景**:
- 用户信用分查询
- 信用等级判断逻辑（canAuth=1/0）
- 用户权限验证
- 异常情况处理（超时、错误响应）

**测试数据**:
```json
{
  "uid": "47574572",
  "channel": "amap7a", 
  "alipayId": "",
  "sign": ""
}
```

### 阶段二：评论创建与提交

#### 3. 评论提交接口 【高优先级】
**业务流程**: 用户填写评论 → 提交评论 → 包含用户信用授权状态  
**接口类型**: HSF服务  
**服务**: `xxxxx.IContentHsfService`  
**方法**: `createContent`  
**测试场景**:
- 评论创建基础功能
- 用户信用授权参数传递（creditAuthorized=true/false）
- 参数校验和错误处理
- 数据库存储验证

**测试数据**:
```json
{
  "uid": "47574572",
  "poiId": "B0FFFS3TDD",
  "content": "测试评论内容",
  "images": [],
  "creditAuthorized": true,
  "score": 5
}
```

#### 4. 消息推送验证 【中优先级】
**业务流程**: 评论提交成功 → 发送审核消息 → 消息格式正确  
**接口类型**: 消息队列  
**服务**: 消息监听  
**测试场景**:
- 消息格式验证（包含用户信用字段）
- 消息投递成功率
- 消息重试机制

### 阶段三：审核流程处理

#### 5. 审核任务创建接口 【高优先级】
**业务流程**: 收到评论消息 → 创建审核任务 → 包含用户信用信息  
**接口类型**: HTTP RESTful  
**服务**: `xxxx`  
**路径**: `/task/create`  
**方法**: `POST`  
**测试场景**:
- 审核任务创建
- 用户信用信息入库
- 任务状态管理

#### 6. 审核员获取任务接口 【中优先级】
**业务流程**: 审核员登录 → 拉取审核任务 → 显示用户信用等级  
**接口类型**: HTTP RESTful  
**服务**: `xxxx`  
**路径**: `/task/pull`  
**方法**: `GET`  
**测试场景**:
- 任务列表返回用户信用信息
- 审核界面显示正确

### 阶段四：奖励发放流程

#### 7. 奖励回调接口 【高优先级】
**业务流程**: 审核通过 → 触发奖励 → 回调C1接口  
**接口类型**: HTTP RESTful  
**控制器**: `RewardCallbackController`  
**路径**: `/api/reward/callback`  
**方法**: `POST`  
**测试场景**:
- 奖励发放回调
- 参数校验（commentNo、signId必填）
- 签名验证
- 重复请求处理
- 异常错误码返回

**测试数据**:
```json
{
  "commentNo": "111111",
  "signId": "test_sign_id_123", 
  "rewardType": "credit",
  "amount": "30%"
}
```

#### 8. 奖励状态更新接口 【中优先级】
**业务流程**: 奖励回调成功 → 更新奖励状态 → 记录发放日志  
**接口类型**: 内部服务调用  
**测试场景**:
- 奖励状态正确更新（进行中→完成）
- 发放日志记录完整
- 异常状态处理

### 阶段五：评论展示与查询

#### 9. POI详情页我的评论接口 【中优先级】
**业务流程**: 用户查看POI详情 → 查询我的评论 → 显示奖励状态  
**接口类型**: HTTP RESTful  
**服务**: `xxxxxt`  
**类**: `UgcCommentIFaceImpl`  
**路径**: `/ugc/comment/mylist`  
**测试场景**:
- 查询用户在POI下的评论
- 验证返回结果包含用户信用奖励信息
- 验证奖励信息字段完整性

#### 10. 我的评论页个人信息接口 【中优先级】
**业务流程**: 用户查看个人主页 → 获取个人信息 → 显示信用等级  
**接口类型**: HTTP RESTful  
**服务**: `martian-sns-comment`  
**类**: `UgcCommentIFaceImpl`  
**路径**: `/user/info`  
**测试场景**:
- 获取用户个人信息
- 验证用户信用等级信息显示
- 验证C1接口调用结果缓存

#### 11. 已评价列表接口 【低优先级】
**业务流程**: 用户查看历史评价 → 获取评价列表 → 显示奖励信息  
**接口类型**: HTTP RESTful  
**服务**: `xxxxx`  
**类**: `UgcCommentIFaceImpl`  
**路径**: `/comment/commented_list`  
**测试场景**:
- 获取用户已评价列表
- 验证用户信用和奖励信息字段
- 验证数据库存储的奖励状态

---

## 🎯 测试建议

### 测试优先级
1. **高优先级**: 接口用户信用查询 + 奖励回调接口（核心业务流程）
2. **中优先级**: POI详情页我的评论接口 + 个人信息接口（集成验证）
3. **低优先级**: 已评价列表接口（辅助功能）

### 测试环境
- **预发环境**: 
- **HSF控制台**: 
- **测试用户**:

### 关键测试数据
- **用户ID**: 
- **评论单号**: 
- **POI ID**: 
- **渠道**: 

---

## 📝 测试记录模板

```markdown
### 接口名称测试记录

**测试时间**: YYYY-MM-DD HH:mm:ss
**测试人员**: [姓名]
**测试环境**: pre

#### 测试用例1: [场景描述]
**请求参数**:
```json
{
  // 请求参数
}
```

**响应结果**:
```json
{
  // 响应结果
}
```

**测试结论**: ✅通过 / ❌失败
**备注**: [异常说明或补充信息]
```

---

## 🔗 相关文档
- [用户信用集成测试操作指南](./用户信用集成测试操作指南.md)
- [评论系统集成测试总览](./评论系统集成测试总览.md)
- [编辑器模板接口测试指南](./编辑器模板接口测试指南.md)
- [编辑器模板接口自测记录](./编辑器模板接口自测记录.md)

---

**说明**: 请按优先级顺序逐个完成接口测试，每完成一个接口测试后，请在对应接口前标记 ✅ 并更新测试状态。

总结

作为典型的上下文工程，绝大多数 AI 编程工具中的规则、文档、记忆模块、提示词工程乃至 MCP 等功能，本质上都在解决同一问题：如何为大模型提供高质量的上下文。