推荐语

揭秘AI如何让跨境支付接入效率提升40%，“一键接入"系统背后的技术革命！

核心内容：
1. AI驱动的支付方式接入系统架构与工作流程
2. 克服大模型局限性的Prompt设计策略与实践
3. 多智能体协作模式在复杂业务场景中的创新应用

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

一、背景与挑战

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 分析历史项目。

输入信息：

# 角色

3.2.3. 工具能力封装：赋予 AI 操作真实系统的权限

设计亮点：

  • 工具命名清晰：明确工具功能和调用方式。

  • 限制工具使用：防止“幻觉”，只允许使用指定工具。

  • 要求完整工具名调用：防止拼接错误或越权访问。

MCP 工具列表示例：

## 🔧 MCP 工具列表（你可以调用）

安全约束：

  • 严禁使用未列出的工具（如 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

设计关键：

  • 引入“人机协同”机制：关键操作需用户确认。

  • 防止 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 能通过“模式匹配”自动生成代码。

示例模板：

// 必须继承

配合注释元数据（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附录

上下文分析专家

# 角色

项目代码分析专家

# 角色

代码变动分析专家

# 角色

Diamond分析专家

# 角色

技术方案生成专家

# 角色