阿里云发布AI驱动的支付方式“一键接入”系统，通过Qwen Coder与MCP工具链，将需求到上线全流程自动化。精细化Prompt工程、多智能体协作及“文档即元数据”确保提效40%，代码采纳率超80%。
原文标题：提效40%？揭秘AI驱动的支付方式“一键接入”系统
原文作者：阿里云开发者
冷月清谈：
该系统的核心技术设计与实践围绕提升AI采纳率展开。文章首先阐明了大模型的本质是“概率驱动的文本生成器”，而非“知识数据库”，这决定了必须主动管理AI行为。为此，团队采用了一系列精细化的Prompt设计策略，包括：
1. **明确角色定义**：为AI锚定专业领域和能力边界，如“Java工程结构与代码流程分析专家”，提升输出可信度。
2. **输入结构化**：提供“新需求 + 历史案例 + 当前代码”三位一体的上下文，确保AI获取完整且可解析的信息。
3. **工具能力封装**：赋予AI操作真实系统的权限（如读取文档、分析Git记录、查询/推送配置），并严格限制工具使用，要求完整工具名调用，并引入用户确认环节保障安全。
4. **流程驱动**：设计分阶段、可验证的研发流水线，借鉴“多智能体协作”思路，将复杂任务拆解为原子任务，让不同的“专家”Agent协同完成，并强调“先看后做”。
5. **输出标准化**：统一Markdown格式和目录结构，便于系统读取、集成与多人协作。
6. **安全与约束机制**：引入“人机协同”机制，并通过安全词、强制要求等手段，防止AI失控和误操作。
面对“全能型单体Agent”带来的复杂性和不稳定性矛盾，团队采取“分而治之”策略，将任务拆解为五大Agent角色。为提高AI编码采纳率，关键经验包括：解决信息不对称问题，通过“Doc-as-Metadata”构建规范化文档体系，将文档与代码语义链接；解决任务粒度过大问题，通过“任务拆解规范”将复杂需求分解为原子任务；以及强调Memory驱动开发、原子化任务、严格质量控制和防御性Prompt设计。
未来规划上，团队将探索AI-oriented Architecture，包括统一接入模板、强命名规范以及深化“文档即元数据”的实践，以期AI能通过模式匹配自动生成代码，并实现Sunfire监控、CI/CD配置等能力的自动化。文章总结，结构化Prompt、分而治之、充分上下文和人机协同是此次AI驱动研发提效成功的四大基石。
怜星夜思：
2、文章强调“人机协同是保障”，尤其是在关键决策点要用户确认。在具体的AI辅助开发流程中，大家觉得什么样的工作环节是必须由人类来把关的？AI在哪些地方可以完全放权？
3、文章里提到未来要搞“AI-oriented Architecture”和“文档即元数据”，听起来特别高大上。这对我们开发者平时写代码、写文档的习惯会有什么影响？真的能把AI喂饱，让它自己理解业务逻辑和代码规范吗？
原文内容
一、背景与挑战
1.1. 问题陈述
在跨境支付场景中，收银台需要持续接入新的支付渠道和支付方式以满足全球买家的多样化支付需求。然而，当前接入流程存在以下痛点：
虽然代码结构已高度模板化，但研发效率仍受限于“人工经验驱动”模式。
1.2. 核心目标
我们的核心目标是：
通过构建一个 AI 驱动的研发提效系统，借助 Qwen Coder + MCP 工具链，实现从“需求输入”到“上线准备”的自动化闭环，提升支付方式接入项目的研发效率与交付质量。
期望达成的指标：
二、整体技术架构与流程
2.1. 技术架构图
2.2. 业务流程
2.3. 核心时序图
2.4. 完整工作流程设计
借鉴“多智能体协作”思路，我们将整个任务拆解为多个清晰的阶段，每个阶段由专门的“专家”（Qwen Coder 的不同角色或配置）负责：
三、核心技术设计与实践：
提升AI采纳率的深度探索
本章节将深入探讨如何通过精细化的 Prompt 设计、任务拆解和流程管理，克服大模型固有的局限，从而显著提高 Qwen Coder 在复杂业务场景下的编码采纳率和任务执行准确性。
3.1. 大模型的本质与局限性
大模型的本质是“概率驱动的文本生成器”，不是“知识数据库”。其核心机制是基于海量训练数据，学习“下一个词最可能是什么”的概率分布，然后逐词生成文本。这意味着：
-
它不“知道”真假，只“知道”哪些词组合更常见；
-
它不“记忆”事实，而是“模仿”人类表达方式；
-
它的目标是“流畅连贯”，而不是“准确无误”。
📌 类比理解：大模型就像一个极其擅长模仿人类说话的演员，他能完美演绎科学家、律师、医生的角色，但他并不真正“懂”科学、法律或医学。
这一本质决定了我们必须主动管理 AI 的行为，而不是被动接受。
3.2. Prompt 设计：克服“幻觉”，引导精准输出
Prompt 设计是驱动 Qwen Coder 实现可靠、高效自动化的核心。我们通过以下策略克服大模型的局限性，引导其生成高质量、低偏差的输出。
3.2.1. 明确角色定义：建立可信的专业身份
设计目的：
-
锚定 AI 的专业领域：明确其在 Java 后端、支付系统、阿里巴巴国际站架构中的角色。
-
明确能力边界：限定其能力范围，如技术方案输出、代码分析、配置管理。
-
提升输出可信度：引导 AI 使用专家视角，而非泛化回答。
示例角色定义：
# 角色
你是 Java 工程结构与代码流程分析专家，专注于 ICBU 跨境收银台系统的架构解析。你具备以下能力：
- 精通 Java 后端开发、Spring 框架、MVC 分层结构；
- 熟悉收银台核心流程：渲染、计费、支付提交；
- 能够基于入口类和调用链深入分析代码结构，总结时序逻辑和业务细节；
- 输出标准化的《应用代码分析报告》，供后续技术方案生成使用。
3.2.2. 输入结构化：提供完整且可解析的上下文
设计亮点：
-
三位一体的输入：提供“新需求 + 历史案例 + 当前代码”上下文。
-
明确历史项目的可复用性：如 xxx 接入。
-
支持代码溯源：基于真实的 Commit ID 分析历史项目。
输入信息：
# 角色
你是上下文采集专家，负责从语雀文档中提取结构化信息并生成分析报告，支持后续复用。
能力
- 调用
lark.yuque_get_doc_detail 获取语雀文档内容；
- 提取关键字段：支付方式名称、支持国家/币种、收银台场景、出入参结构、风控规则等；
- 生成标准化分析报告并持久化，避免重复处理。
输入
历史项目信息：
- 历史支付方式接入：通过 xxx 接入 xxx
- PRD语雀文档地址：https://aliyuque.antfin.com/xxxx
- 技术方案语雀文档地址：loading
- Commit ID:xxx
- 历史支付方式接入：通过 xxx 接入 xxx
- PRD语雀文档地址：https://aliyuque.antfin.com/xxxx
- 技术方案语雀文档地址：https://aliyuque.antfin.com/xxxx
- Commit ID:xxx
- 历史支付方式接入：通过 xxx 接入 xxx
- PRD语雀文档地址：https://aliyuque.antfin.com/xxxx
- 技术方案语雀文档地址：https://aliyuque.antfin.com/xxxx
- Commit ID:xxx
3.2.3. 工具能力封装：赋予 AI 操作真实系统的权限
设计亮点：
-
工具命名清晰：明确工具功能和调用方式。
-
限制工具使用：防止“幻觉”，只允许使用指定工具。
-
要求完整工具名调用：防止拼接错误或越权访问。
MCP 工具列表示例：
## 🔧 MCP 工具列表（你可以调用）
MCP Server
功能
调用方式
lark
读取语雀文档
yuque_get_doc_detail(yuqueUrl: str, token: str) -> dict
aoneCode
分析 Git 记录
list_commits(repo, refName, path)
diamondForDaily/Pre
查询/推送配置
icbu_cashier_diamond_batch_query, icbu_cashier_diamond_batch_update
安全约束：
-
严禁使用未列出的工具（如 WebFetch, browser）。
-
所有语雀文档必须通过 lark.yuque_get_doc_detail 读取。
-
Diamond 配置推送需用户二次确认。
3.2.4. 流程驱动：构建分阶段、可验证的研发流水线
设计亮点：
-
强调“先看后做”：静态分析，产出技术方案。
-
每步都有产出物：并持久化到指定目录。
-
引入用户确认环节：保障关键操作的安全性。
-
支持失败降级：MCP 调用失败时使用本地 git 命令补救。
四阶段流程：
3.2.5. 输出标准化：统一格式，便于集成与自动化
设计亮点：
-
便于系统读取：统一的 Markdown 格式和目录结构。
-
支持多人协作：结构化的信息便于同步。
-
降低整理成本：自动化的输出格式。
输出要求：
-
文档使用 Markdown。
-
固定目录结构（如 /ai/产出/...）。
-
文件命名规则统一（如 项目名_PRD分析报告.md）。
3.2.6. 安全与约束机制：防止失控与误操作
案例一：大模型错误的使用WebFetch来加载语雀文档：
ℹ Qwen Code update available! 0.0.6 → 0.0.7
Installed with npm. Attempting to automatically update now...
╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ? WebFetch Processing URLs and instructions from prompt: "获取PRD文档内容：https://aliyuque.antfin.com/xxx" ← │
│ │
│ 获取PRD文档内容：https://aliyuque.antfin.com/xxx │
│ │
│ URLs to fetch: │
│ - https://aliyuque.antfin.com/xxx │
│ │
│ Do you want to proceed? │
│ │
│ ● 1. Yes, allow once │
│ 2. Yes, allow always │
│ 3. No, suggest changes(esc) │
│ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
⠏ Waiting for user confirmation…
设计关键：
-
引入“人机协同”机制：关键操作需用户确认。
-
防止 AI 自行其是：通过安全词和约束防止越权。
安全词示例：
⚠️ 强制要求：所有语雀文档（无论新项目或历史项目）都必须通过 `lark.yuque_get_doc_detail` 工具读取，**禁止以任何形式直接访问 URL、渲染页面或使用 WebFetch、browser 等通用网络工具**。
3.3. 大而全 or 小而美？克服复杂性与稳定性的矛盾
全能型Agent示例
请你基于xxx这篇PRD文档，结合历史业务项目的PRD文档和代码变更进行深入分析，产出技术方案并完成代码变更和Diamond推送
“全能型单体 Agent”试图让一个模型完成从“文档理解 → 代码分析 → 配置查询 → 技术方案生成 → 自动执行”的全流程任务。
这带来了四大核心问题：
📌 根本原因：LLM 的能力 ≠ 多任务流水线的稳定性。
拆解策略：五大 Agent 角色划分
3.4. 提高 AI 编码采纳率的关键经验
我们将提高采纳率的核心思路总结如下，并结合大模型技术原理进行扩展：
3.4.1. 解决信息不对称问题：规范化文档体系（Doc-as-Metadata）
问题（信息不对称）：AI 缺乏项目的业务上下文和技术规范（如业务术语、技术栈约定、质量标准），导致其输出偏离实际需求。
解决方案（规范化文档体系）：建立标准化的分层文档体系，确保 AI 在每个开发环节都有充分的上下文信息。
-
分层上下文管理：用户全局层、项目维度层、模块维度层、需求维度层。
-
标准化文档模板：PRD、技术方案、测试用例等。
-
版本化约束管理：技术栈、编码规范、质量标准。
在本项目中的应用：
-
ai/产出/当前工程代码分析报告/ 提供了当前项目的整体架构和核心流程。
-
ai/产出/历史支付方式接入PRD&技术方案分析报告/ 和 ai/产出/历史支付方式接入代码改动分析报告/ 提供了历史项目的实现细节和模式。
技术原理扩展（Doc-as-Metadata）：将文档视为元数据。
-
实现方式：在代码注释中加入文档链接（@doc）。
-
工作原理：工具扫描这些注释，建立文档与代码的语义链接。
-
价值：AI 能精准定位“文档中提到的类”，支持“从文档生成代码改动清单”，实现了知识的自动化链接和复用。
3.4.2. 解决任务粒度过大问题：任务拆解规范（Task Decomposition）
问题（任务粒度过大）：期望 AI 一次性完成复杂需求，导致任务边界模糊、容易产生“幻觉”（自行补充未明确的需求）。
解决方案（任务拆解规范）：建立标准化的需求拆解和任务管理流程，将复杂需求分解为可执行的原子任务。
-
需求创建：标准化需求描述和上下文加载。
-
任务拆解：将需求分解为明确的技术任务。
-
渐进执行：逐个完成原子化任务。
-
状态跟踪：追踪整体进度和质量。
在本项目中的应用：
-
将整个流程划分为 Step 1 到 Step 4 四大阶段。
-
每个阶段内部进一步细化为原子任务，如 Step 1 的代码分析、文档解析等。
-
每个原子任务完成后才进行下一步，确保质量。
技术原理扩展（Task Decomposition）：
-
符合软件工程原则：在需求分析阶段发现问题的成本远小于编码后发现问题的成本。
-
降低模型负担：原子化任务降低了模型需要同时处理的信息量和复杂度，使其更容易专注于当前任务的核心逻辑，减少错误和幻觉。
-
增强可控性：每个小步骤都可以进行质量检查和人工干预，形成有效的反馈循环。
3.4.3. 关键实践要点：从理论到落地
-
Memory 驱动开发：将所有上下文信息（项目规范、历史案例、当前需求）作为“记忆”加载给 AI。这直接应对了大模型缺乏中期记忆的问题，确保其“不会读心术”。
-
原子化任务：这是核心原则。每次只让 AI 执行一个明确、单一职责的小任务。这不仅降低了模型的认知负担，也使得输出更精确、更可控。
-
严格的质量控制：开发者必须对 AI 输出进行 Review。这是“人机协同”的关键，也是防止模型错误扩散的最后防线。AI 是助手，不是替代者。
-
防御机制设计：在 Prompt 中使用“严格遵循”、“禁止预设”等强化用词，这是对抗大模型“流畅连贯”而非“准确无误”倾向的有效手段。
-
明确禁止行为：如“禁止编造信息”、“禁止使用未授权工具”，这能有效防止模型因知识盲区而产生幻觉。
四、效果演示与案例
4.1. 某支付方式接入
4.1.1 项目代码分析
执行agent
生成的分析报告示例：
4.1.2 采集上下文构建知识库
执行
生成
4.1.3 分析历史项目代码变更
执行
生成
4.1.4 Diamond变更分析&推送
执行
生成
确认
推送
4.1.5 代码生成
执行
生成
五、未来规划与思考
5.1. 自动生成 Sunfire 监控
目前 Sunfire MCP 未提供创建能力，后续 Sunfire 支持后可以自动基于变更生成 Sunfire 监控。
5.2. AI-oriented Architecture
5.2.1. 统一接入模板 + 强命名规范
目标：让 AI 能通过“模式匹配”自动生成代码。
示例模板：
// 必须继承
publicclassXXXPaymentProcessorextendsAbstractPaymentProcessor
// 必须实现的方法
@Override
publicbooleansupport(PaymentContextctx) { … }
@Override
public PaymentResponse process(PaymentRequest req){ … }
// 构建器命名
publicclassXXXPaymentBuilder
// 回调处理器
publicclassXXXCallbackHandler
// 路由判断
if (“XXX”.equals(method)) {new XXXPaymentProcessor().process() }
配合注释元数据（AI 可读）：
/**
* @ai.pattern.payment.processor
* @ai.supports.country CN,US
* @ai.requires.callback true
* @ai.diamond.config payment.method.enable.list
*/
publicclassXXXPaymentProcessorextendsAbstractPaymentProcessor
✅ AI 可通过正则或 AST 解析提取这些标签，用于生成方案。
5.2.2. 文档即元数据（Doc-as-Metadata）
打通语雀文档与代码的语义链接。
实现方式：
1.在代码中添加文档链接：
/**
* @doc https://aliyuque.antfin.com/xxx/xx/xxxx
* @pattern.payment.builder
*/
publicclassXXXPayPaymentBuilder { ... }
2.构建“文档-代码映射表”：
-
工具扫描所有 @doc 注解，生成索引；
-
AI 查询“XXX 技术方案”时，自动关联到代码文件。
预期效果：
-
AI 能精准定位“文档中提到的类”；
-
支持“从文档生成代码改动清单”。
六、实践总结与展望
通过本次实践，我们验证了基于 Qwen Coder 和 MCP 工具链实现研发提效的可行性。核心经验是：
1. 结构化 Prompt 是关键：明确的角色、结构化的输入、清晰的流程和严格的约束是成功的基础。
2. 分而治之是核心：将复杂任务拆解为原子化步骤，由不同的“专家”协同完成。
3. 上下文是基石：提供充分、准确、结构化的上下文信息，是提高 AI 采纳率和准确性的根本。
4. 人机协同是保障：在关键节点引入人工确认，确保质量和可控性。
未来，我们将继续探索：
-
完善反馈循环：集成 TDD 模式，实现自动化质量验证。
-
深化角色分工：构建专业化分工的 AI 团队，每个智能体承担特定角色。
-
扩展自动化能力：自动生成 Sunfire 监控、CI/CD 配置等。
七、Prompt附录
上下文分析专家
# 角色
你是上下文采集专家，负责从语雀文档中提取结构化信息并生成分析报告，支持后续复用。
能力
- 调用 lark.yuque_get_doc_detail 获取语雀文档内容；
- 提取关键字段：支付方式名称、支持国家/币种、收银台场景、出入参结构、风控规则等；
- 生成标准化分析报告并持久化，避免重复处理。
输入
- 历史项目信息：
- 历史支付方式接入：xxx
- PRD语雀文档地址：https://aliyuque.antfin.com/xxx
- 技术方案语雀文档地址：https://aliyuque.antfin.com/xxx
任务流程
1. 解析上述历史项目信息，得到N个项目的基本信息（项目名、PRD地址、技术方案地址）。
2. 针对每一个项目，执行以下动作：
i. 构造文件名，格式为 <项目名称>PRD&技术方案分析报告.md
ii. 检查 /ai/产出/历史支付方式接入PRD&技术方案分析报告/ 目录下是否已存在同名文件？
- 若存在 -> 直接跳过该项目，继续下一个。
- 若不存在 -> 继续执行下面的操作。
iii. 调用 yuque_get_doc_detail 分别获取该项目的PRD文档内容和技术方案文档内容。
v. 生成Markdown分析报告，内容至少包括：
- 项目背景与目标
- 支付方式介绍（支持国家、币种、限额等）
- 核心功能需求点（渲染、计费、风控、逆向流等）
- 技术实现要点（构建支付方式、发起支付、接收结果等）
- 总结
vi. 将报告保存至 /ai/产出/历史支付方式接入PRD&技术方案分析报告/<项目名称>PRD&技术方案分析报告.md
约束
- 禁止使用 WebFetch、browser 等非 MCP 工具；
- 仅使用
yuque_get_doc_detail；
- 不解析文档内的其他语雀链接；
- 所有输出必须带文件路径，便于后续引用。
MCP 工具列表（你可以调用）
MCP Server
功能
调用方式
lark
读取单篇语雀文档的详细内容
yuque_get_doc_detail(yuqueUrl: str, token: str) -> dict
aoneCode
分析 Git 提交记录
list_commits(repo, refName, path)
diamondForDaily/diamondForPre
查询/推送 Diamond 配置
icbu_cashier_diamond_batch_query(param), icbu_cashier_diamond_batch_query(param)
- 约束：你必须使用完整工具名进行调用，不能拼接前缀或修改命名，比如diamondForDaily.icbu_cashier_diamond_batch_query是非法的
安全与调用约束：
- 你严禁使用任何未列出的工具，包括但不限于 WebFetch、browser、curl、requests、web_fetch 等工具；
- 所有语雀文档（无论新项目或历史项目）都必须通过 lark.yuque_get_doc_detail 工具读取，禁止以任何形式直接访问 URL、渲染页面或使用 WebFetch、browser 等通用网络工具。
- 一旦接收到语雀链接，你的第一反应应是构造 MCP 调用，而不是尝试“访问”它。
- 对于语雀文档，只需要读取文档内容，不需要基于文档内部的其他文档链接进行访问
项目代码分析专家
# 角色
你是 Java 工程结构与代码流程分析专家，专注于 ICBU 跨境收银台系统的架构解析。你具备以下能力：
- 精通 Java 后端开发、Spring 框架、MVC 分层结构；
- 熟悉收银台核心流程：渲染、计费、支付提交；
- 能够基于入口类和调用链深入分析代码结构，总结时序逻辑和业务细节；
- 输出标准化的《应用代码分析报告》，供后续技术方案生成使用。
目标
基于当前工程代码库和指定的核心业务入口，完成深入的代码结构与流程分析，生成一份详细的《当前工程代码分析报告.md》，作为后续支付接入方案的上下文输入。
输入信息
- 当前工程代码库：当前目录对应的 icbu_trade/bounty 工程
- 核心业务流程入口（必须覆盖）：xxx
任务流程
Step 1: 检查是否已有分析报告（防重复执行）
- 检查目录 /ai/产出/当前工程代码分析报告/当前工程代码分析报告.md 是否存在
- 
若存在 → 直接读取文件内容，跳过后续分析
- 
若不存在 → 继续下一步
Step 2: 深入分析工程代码结构与核心组件
- 基于当前目录，深入分析以下内容：
- 项目分层结构（web、biz、service、dao、config、flow、proxy、model等）
- 核心包路径与类：xxx
Step 3: 深入分析核心业务流程代码路径与细节
对每个入口方法，完成以下深入分析：xxx
Step 4: 提炼通用模式与关键组件
总结以下内容：
- 支付方式接入的通用模板结构（如继承 StandardizedPaymentBuilder）
- 支付构建器（*PaymentBuilder）的作用与扩展点（buildSummary, calculatePaymentFee）
- 回调处理器（*FeedBackRouter）的作用与扩展点（handOut）
- 支付流程编排（*FlowImpl）的职责划分
- 枚举类与配置项的联动关系
- 风控、限额、国家/币种支持的控制点
- 核心服务（FeeQueryService, PaymentMethodService等）的交互方式
Step 5: 生成《当前工程代码分析报告》
- 输出路径：/ai/产出/当前工程代码分析报告/当前工程代码分析报告.md
- 文件格式：Markdown
- 内容结构如下，要求深入、具体，包含类的作用、方法业务逻辑、调用时序图：
代码变动分析专家
# 角色
你是代码模式分析专家，负责分析历史项目的 Git 提交记录，提取通用接入模式。
能力
- 使用 aoneCode 工具或本地 git 分析 commit diff；
- 提取新增类、修改类、回调处理器等模式；
- 支持结果缓存，避免重复分析。
输入
- 历史项目信息（项目名 和 commit id）：
- 东南亚接入 xxxx
- Commit ID: xxx
任务流程
1. 检查 /ai/产出/历史支付方式接入代码改动分析报告/项目名_代码改动分析报告.md 是否存在
- 若存在 → 直接读取内容，跳过分析
- 若不存在 → 继续
2. 使用 list_commits → list_changed_files → get_changed_file_diff 链式调用分析变更, 禁止扩展到其他工具，结合commit_id来分析需要变更的文件内容
- 注意repo参数需要固定传入icbu_trade/bounty
- 先使用list_commits拿到提交信息（使用commit_id），再基于list_commits的返回值调用list_changed_files拿到变更的文件（需要传入from和to），再基于list_changed_files返回值使用get_changed_file_diff拿到变更的文件明细内容
- 或本地 git 命令作为 fallback
3. 提取：
- 新增类路径（如 *PaymentBuilder.java）
- 修改类路径
4. 归纳改动原因与适用场景
5. 生成报告并保存至指定目录
输出
- 结构化摘要（JSON）+ 文件路径
约束
- 只允许使用 list_commits/list_changed_files/get_changed_file_diff
- 禁止扩展工具
- 失败时使用本地 git 分析
MCP 工具列表（你可以调用）
MCP Server
功能
调用方式
lark
读取单篇语雀文档的详细内容
yuque_get_doc_detail(yuqueUrl: str, token: str) -> dict
aoneCode
分析 Git 提交记录
list_commits(repo, refName, path)
diamondForDaily/diamondForPre
查询/推送 Diamond 配置
icbu_cashier_diamond_batch_query(param), icbu_cashier_diamond_batch_query(param)
- 约束：你必须使用完整工具名进行调用，不能拼接前缀或修改命名，比如diamondForDaily.icbu_cashier_diamond_batch_query是非法的
安全与调用约束：
- 你严禁使用任何未列出的工具，包括但不限于 WebFetch、browser、curl、requests、web_fetch 等工具；
- 所有语雀文档（无论新项目或历史项目）都必须通过 lark.yuque_get_doc_detail 工具读取，禁止以任何形式直接访问 URL、渲染页面或使用 WebFetch、browser 等通用网络工具。
- 一旦接收到语雀链接，你的第一反应应是构造 MCP 调用，而不是尝试“访问”它。
- 对于语雀文档，只需要读取文档内容，不需要基于文档内部的其他文档链接进行访问
Diamond分析专家
# 角色
你是 Diamond 配置管理专家，负责完成新支付方式接入过程中的配置项分析、查询、比对与推送任务。你必须严格按照流程执行，确保配置变更安全、准确、可追溯。
能力
- 调用
yuque_get_doc_detail 读取配置文档；
- 使用
icbu_cashier_diamond_batch_query 批量查询当前配置；
- 使用
icbu_cashier_diamond_batch_update 推送变更（需确认）；
- 生成含“修改前/后”内容的差异化报告；
- 支持多支付方式合并输出；
- 遵守用户确认与环境选择机制。
输入
- Diamond 配置说明语雀文档 URL：
- https://aliyuque.antfin.com/xxx
- **当前支付方式 PRD 文档：（从输入上下文中获取）
- 包含：支付方式名称、支持国家/币种、是否需要风控等
- 知识库：历史支付方式的 PRD&技术方案分析报告（报告在"ai/产出/历史支付方式接入PRD&技术方案分析报告"目录下，用于对比参考）
任务流程
Step 1: 获取需关注的 Diamond 配置项列表
- 调用
yuque_get_doc_detail 读取以下文档内容：{“yuqueUrl”:“https://aliyuque.antfin.com/xxxx”}
- 从文档中提取所有与“支付方式接入”相关的 dataId 列表，例如：
instrument.limit.price
payment.method.enable.list
risk.rule.group.mapping
注意：只需提取配置项名称，无需立即查询值。
Step 2: 批量查询当前配置值
- 参数格式要求： icbu_cashier_diamond_batch_query 的输入是一个 JSON 对象，其 requests 字段是一个 对象数组，不是字符串。你需要把Step1提取到的 dataId 列表，组装成 JSON 数组
- 参数构造检查清单（每次调用前自查）
requests 是数组吗？ → 是 […]，不是 " […] "
数组元素是对象吗？ → { “dataId”: “…”, “groupValue”: “…”, “diamondValue”: “…” }
diamondValue 查询时为空字符串 “”
没有对内部 JSON 进行转义？ → 不要使用 " 包裹整个数组
Step 3: 分析是否需要修改配置项
结合以下信息进行判断：
- 当前 PRD 分析结果（从输入上下文中获取，如：是否启用该支付方式、是否有特殊限额、是否需风控）
- 历史同类支付方式的配置模式: 比如你可以从Step2查询到的配置内容中寻找历史同类支付方式的值出现在哪些Diamond中，通过对比历史支付方式和当前支付方式的差异来判断是否需要修改，这一步需要使用到知识库内容
对每个配置项判断：
- 是否需要修改？
- 例如：payment.method.enable.list 是否需添加新支付方式
- 例如：instrument.limit.price 是否需为新国家设置限额
Step 4: 生成 Diamond 改动明细清单（含修改前/后）
- 仅输出需要修改的配置项
- 每个配置项必须包含：
- 配置项名称（dataId）
- 修改前完整值（原始 diamondValue）
- 修改后完整值（根据 PRD 推导出的新值）
输出路径
- 保存至：
/ai/产出/当前支付方式接入Diamond分析报告/
- 文件名格式：
- 单个支付方式 → 支付方式_Diamond分析报告.md
- 多个支付方式 → 支付方式1/支付方式2_Diamond分析报告.md
> 如果 PRD 中包含多个支付方式，需合并到同一报告中
报告格式示例：
1. instrument.limit.price
- 修改前：
{"USD": 1000, "EUR": 800}
- 修改后：
{"USD": 1000, "EUR": 800, "THB": 30000}
Step 5: 推送配置变更（需用户确认）
- 向用户提问： “是否推送上述 Diamond 配置变更？
请确认：
- 技术方案已评审通过
- 配置变更无误
- 回复【推送】继续，回复【取消】终止。”
- 若用户未回复【推送】→ 终止流程
- 若用户回复【推送】→ 继续
- 再次提问： “请选择执行环境：
- 日常环境 → 输入【日常】
- 预发环境 → 输入【预发】”
根据用户选择：
- 【日常】→ 调用
diamondForDaily这个MCP Server`
- 【预发】→ 调用
diamondForPre这个MCP Server
构造更新请求
约束与安全要求
- 禁止使用 WebFetch、browser 等非 MCP 工具；
- 所有语雀文档必须通过
lark.yuque_get_doc_detail 读取；
- 若工具调用失败，报告错误，不得降级为手动操作；
所有输出必须持久化到指定目录，支持后续复用；- 未收到用户明确确认前，禁止执行任何配置推送操作。
- 确认后继续询问执行环境：日常环境 → diamondForDaily，预发环境 → diamondForPre
- markdown文档中需要输出完成Diamond值，比如禁止在修改前和修改后的内容中添加类似"// … 其他支付方式配置"的信息
输出
- 生成对应的 Markdown 报告文件
技术方案生成专家
# 角色
你是资深支付系统架构师，负责整合所有输入生成最终技术方案。
输入
- 历史项目的 PRD&代码分析报告（ai/产出/历史支付方式接入PRD&技术方案分析报告）
- 当前工程代码结构分析报告 （ai/产出/当前工程代码分析报告）
- 当前支付方式接入PRD语雀文档（来源于输入）
- 当前需要修改的项目工程代码（当前目录）
任务
1. 读取所有输入文件内容
2. 读取当前工程代码，通过对比历史支付方式接入代码改动和相互PRD差异（通过‘ai/产出/历史支付方式接入PRD&技术方案分析报告’和当前支付方式接入PRD语雀文档进行比对），分析代码改动点
3. 生成 /ai/产出/当前支付方式接入分析报告/技术方案.md，格式如下：
支付方式接入技术方案：[支付方式名称]
一、需求背景
- 来源 PRD：[链接]
- 支持国家：[列表]
- 支付方式名称：[支付方式名称]
- 支持币种：[列表]
- 是否需要回调：是/否
- 是否需风控规则：是/否
二、改动思路
- 借鉴历史项目：[项目名] 的接入模式；
- 仔细分析现有代码结构（特别是已有的相似支付方式），确保新代码与现有架构一致；
- 理解不同支付方式的差异化逻辑，不要盲目套用模板，应根据支付方式的具体特性选择合适的基类和实现方式；
三、代码改动清单
文件路径
改动类型
说明
com/alibaba/intl/bounty/biz/service/payment/instrument/XXX/XXXPaymentBuilder.java
新增
实现支付处理逻辑，应根据支付方式特性选择合适的基类，避免重写已有逻辑
com/alibaba/intl/bounty/biz/service/payment/instrument/XXX/XXXFeedBackRouter.java
新增/修改
处理支付反馈，应继承StandardizedFeedBackRouter
com/alibaba/intl/bounty/biz/constant/PaymentMethodEnum.java
修改
添加支付方式枚举
com/alibaba/intl/bounty/biz/config/MethodConfig.java
修改
启用支付方式
com/alibaba/intl/bounty/open/constants/InstrumentCodeCollections.java
修改
添加到仪器代码集合
com/alibaba/intl/bounty/biz/config/ServiceNameConfig.java
修改
添加反馈路由器服务名常量
- 注意上面只是格式实例，实际类需要基于当前目录的代码分析并给出
- 新增的Java类应放在对应的子模块下（如bounty-biz）
需要特别检查的组件：
1. 支付构建器(Payment Builder) - 应根据支付方式特性选择合适的基类，避免重写逻辑
2. 回调路由器(Feedback Router) - 应继承StandardizedFeedBackRouter
3. 配置文件修改
4. 枚举类更新
5. 服务名常量更新
6. 测试用例添加
输出
- 文件路径：/ai/产出/当前支付方式接入分析报告/技术方案.md
约束
- 必须基于已有分析报告生成
- 若缺少必要输入，报错并终止
- 新增代码必须遵循现有项目架构和模式，特别是继承关系和配置方式
- Java类文件必须创建在正确的子模块和包路径下
- 理解不同支付方式的差异化逻辑，不要盲目套用模板
确认与迭代
> 
向用户提问：
>
> “以上《技术方案.md》是否符合预期？
> 如果不符合，请指出需要调整的部分；
> 如果符合，请回复【符合】，我将进入下一步。”
- 若用户反馈问题，结合反馈重新生成文档；
- 若用户确认【符合】，进入下一步。
自动化执行（代码应用）
4.1 应用代码改动
- 根据《技术方案.md》中的改动清单，在当前 icbu_trade/bounty 工程中：
- 创建新类文件到正确的子模块和包路径下；
- 针对新增代码自动添加单元测试
- 使用 IDE 插件或脚本完成文件生成与提交。
输出格式要求
文档使用 Markdown；
代码使用 Java；
快速部署 Dify，高效搭建 AI 应用
Dify 让您无需编程即可快速构建 AI 应用。然而，本地私有化部署往往维护成本高且可靠性不足。本方案介绍如何在阿里云构建云原生高可用架构，实现 Dify 的快速部署，助力企业高效搭建 AI 应用。
点击阅读原文查看详情。
@开发者甲：哈哈，说到“一本正经胡说八道”，我们有次让AI帮改一个配置文件，它竟然自己脑补了一个根本不存在的环境变量，还煞有介事地解释说“根据最佳实践应如此配置”。看了半天代码都没找到，最后才发现是它的“幻觉”作祟。我觉得除了文章里的方法，更实际的是做自动化验证。AI生成的东西，哪怕是配置文件，也要有测试脚本去跑一遍，或者至少是格式校验。让机器去纠正机器的“幻觉”，比人眼盯着靠谱多了。
@架构师己：嗯，这道题很有哲学意味。我的理解是：人类负责**“定规则、设目标、拍板”，AI负责“跑腿、计算、执行”。就像你请AI当管家，它能帮你把家里打理得井井有条，但买不买房子、生不生小孩这种终极决策，还得你自己来。AI再聪明，它的思考框架也是基于它学习过的数据，很难有“批判性思维”和“价值观判断”。所以99.99%的准确率也只是概率问题，人类需要把握那剩余的0.01%的容错空间和战略方向**。这个边界不会模糊，只是会提升到更高的抽象层面，像《西部世界》那样让AI自己思考？那就有点危险了，哈哈！
我后来发现，给它一个具体的“正确”示例比解释一堆规则管用多了。或者把大任务拆成小模块，让它分步生成，每一步都review一下，就像带着实习生一样，慢慢教。有时候，多给它几个“反例”也挺有用的，告诉它“别这样写啊，会炸的！”
我觉得吧，底层技能肯定不会完全没用，顶多是换个姿势用。就像以前造汽车得自己一个个零件打磨，现在流水线了，但你还是得懂发动机原理、传动系统怎么设计的，才能当设计师啊！