【More Than Coding】用 SOLO 10分钟搭建一套适配金融系统的 SDD 开发框架

SOLO挑战赛专区
1

  1. 摘要
    我是一名金融行业的后端开发，日常负责银行核心系统的开发工作。金融系统对开发流程规范性要求极高——需求冻结、架构评审、设计评审、代码审查、上线审批，每个环节都不能省。但团队一直缺乏一套标准化的流程框架，每次新项目都要从零整理文档模板、编码规范、评审检查表，浪费大量时间。我用 SOLO 研究了 OpenCode、Superpowers 等业界前沿的 AI 辅助开发流程规范，结合国内金融行业瀑布开发流程的监管合规要求（银保监会指引、等保三级、JR/T 标准），10分钟内生成了 25 个 Markdown 文件、约 17,000 行的完整 SDD 开发框架，包含 9 个 Skill 技能定义、6 个核心规范文档、5 个文档模板、以及一套完整的 Java 金融系统开发示例代码。

  2. 背景
    我的角色：金融行业后端开发工程师（Java 方向）

日常工作场景：

负责银行支付系统、账户系统等核心业务模块的开发
每个项目都需要经历完整的瀑布开发流程：需求分析 → 概要设计 → 详细设计 → 编码 → 测试 → 上线
每个阶段都要产出大量文档（SRS、HLD、LDD、测试计划、上线方案等），且必须满足等保三级、银保监会指引等监管要求
痛点：

没有统一的流程框架：每个项目组各自为政，文档格式、编码规范、评审标准不统一
合规要求散落各处：等保要求、JR/T 标准、安全编码规范分布在不同的文档中，难以系统化执行
新项目启动成本高：每次新项目都要花 1-2 天整理文档模板和规范
AI 辅助开发缺乏纪律：直接用 AI 写代码容易跳过设计阶段，产出不符合金融合规要求的代码
期望：用 SOLO 快速搭建一套"拿来即用"的开发流程框架，让团队从第一天起就按规范做事。

  1. 实践过程
    3.1 任务拆解思路
    我把整个任务拆成 3 个并行的研究子任务 + 4 个串行的编写子任务：

Plain Text

阶段一（并行研究）：
├── 研究 OpenCode 的规则体系、Skills 系统、多智能体协作架构
├── 研究 Superpowers 的 14 个技能、三条铁律、7 步工作流
└── 研究国内金融系统瀑布开发流程、银保监会指引、等保三级要求

阶段二（串行编写）：
├── 设计框架整体架构 → 编写框架总览 + AGENTS.md
├── 并行编写 9 个 Skill 文件 + 6 个核心规范文档 + Java 示例
├── 编写 5 个文档模板 + README
└── 验证所有文档完整性和一致性
3.2 使用了 SOLO 哪些能力
SOLO 能力 用途
WebSearch + WebFetch 搜索 OpenCode 官方文档、Superpowers GitHub 仓库、银保监会法规、JR/T 标准等
Explore 子代理 并行启动 3 个研究子代理，分别调研 OpenCode、Superpowers、金融合规
Task 子代理 并行启动 3 个编写子代理，分别编写 Skill 文件、规范文档、Java 示例
Write 工具 创建 25 个 Markdown 文件，总计约 17,000 行
LS + Read 工具 验证文件完整性、检查目录结构
3.3 关键 Prompt
Prompt 1（研究阶段）：

研究 OpenCode、Superpowers 等开发流程规范，以及国内金融系统瀑布开发流程的监管合规要求。重点关注：规则体系（Rules System）、技能体系（Skills System）、瀑布6大阶段的交付物和评审关卡、等保三级安全要求、国密算法使用规范。

Prompt 2（框架设计）：

基于 OpenCode 的 Plan/Build 双模式和 Rules 系统，结合 Superpowers 的三条铁律和技能化流程，设计一套适配金融系统瀑布开发的 SDD 框架。框架需要包含：9个 Skill 技能定义（对应6个开发阶段+3个贯穿全程的技能）、6个核心规范文档、5个文档模板、1个完整的 Java 金融系统开发示例。

Prompt 3（Java 示例）：

以"统一支付平台"的"交易订单创建"功能为例，按 SDD 框架的 6 个瀑布阶段编写完整的开发示例。需要包含：完整的 Java 代码（Controller/Service/Mapper/Entity/枚举/工具类/单元测试）、数据库 DDL、接口设计、时序图、测试用例、上线检查清单。代码必须遵循阿里巴巴Java开发手册，体现金额精度、幂等性、分布式锁、事务控制等金融行业特殊要求。

3.4 中间踩过的坑
研究范围过大：一开始想同时研究 OpenCode + Superpowers + Cursor Rules + Windsurf + Claude Code 等所有主流 AI 编程工具的规范，后来发现搜索预算有限，聚焦到 OpenCode 和 Superpowers 两个最具代表性的框架就够了。

金融合规资料分散：银保监会指引、等保标准、JR/T 系列标准分布在不同的政府网站和行业文档中，需要通过多次搜索才能拼凑出完整的合规要求清单。最终通过一个综合搜索 + Explore 子代理的深度调研解决了这个问题。

Skill 文件粒度把握：一开始计划了 15+ 个 Skill，后来发现太多会导致框架过于复杂。最终精简到 9 个核心 Skill，覆盖 6 个瀑布阶段 + 3 个贯穿全程的通用技能（代码审查、调试、文档更新）。

Java 示例代码量：完整的金融系统 Java 示例代码量非常大（10+ 个类、每个类 50-200 行），单个子代理的输出 token 有限。通过将示例拆分到独立的子代理中，并给出非常详细的类列表和代码要求来解决。

  1. 成果展示
    4.1 框架全景

Plain Text

SDD-Framework/ # 25个文件，约17,000行，712KB
├── README.md # 快速入门指南
├── SDD-Framework-Overview.md # 框架总览
├── AGENTS.md # AI Agent 全局行为规则
│
├── rules/ # 规则体系（10个Skill）
│ ├── SKILL-INDEX.md # 技能索引
│ └── skills/
│ ├── SKILL-requirement.md # 需求分析技能
│ ├── SKILL-high-level-design.md # 概要设计技能
│ ├── SKILL-detail-design.md # 详细设计技能
│ ├── SKILL-coding.md # 编码实现技能
│ ├── SKILL-testing.md # 测试验证技能
│ ├── SKILL-deployment.md # 上线部署技能
│ ├── SKILL-code-review.md # 代码审查技能
│ ├── SKILL-debugging.md # 系统化调试技能
│ └── SKILL-doc-update.md # 文档更新技能
│
├── docs/
│ ├── specs/ # 6个核心规范文档
│ │ ├── Project-Context.md # 项目规范
│ │ ├── Architecture-Spec.md # 业务架构规范
│ │ ├── Api-Standard-Spec.md # 接口标准规范
│ │ ├── Exception-Log-Spec.md # 异常与日志规范
│ │ ├── Common-Component-Spec.md # 公共组件规范（16个组件）
│ │ └── Data-Model-pec.md # 数据模型基础
│ │
│ ├── templates/ # 5个文档模板
│ │ ├── TPL-requirement.md # 需求规格说明书模板
│ │ ├── TPL-high-level-design.md # 概要设计说明书模板
│ │ ├── TPL-detail-design.md # 详细设计说明书模板
│ │ ├── TPL-test-plan.md # 测试计划模板
│ │ └── TPL-deployment.md # 上线部署方案模板
│ │
│ └── examples/
│ └── java-finance-example.md # Java金融系统开发完整示例
4.2 核心亮点
三条铁律（借鉴 Superpowers）：

:red_circle: 无测试不编码 — 在测试之前写的代码会被删除
:red_circle: 无根因不修复 — 没有根因分析的修复本质上是在碰运气
:red_circle: 无验证不完成 — 不是"我觉得修好了"，而是"刚刚验证过"
金融合规内建：

银保监会《商业银行信息科技风险管理指引》→ 瀑布6阶段 + 阶段评审关卡
等保三级（GB/T 22239-2019）→ 安全架构 + 安全测试
国密算法（SM2/SM3/SM4）→ 加密组件 + 数据安全规范
JR/T 0071 系列标准 → 等保实施指引
16个公共组件（含完整Java代码）： 统一响应、分页、异常处理、参数校验、Redis缓存、Kafka消息、分布式锁、幂等性、数据脱敏、国密加密、AOP日志、雪花ID、日期时间、金额计算、Excel导入导出、文件上传下载

4.3 关键文件预览
AGENTS.md 片段 — 安全红线：

Markdown

  • :white_check_mark: 所有外部输入视为不可信，必须校验
  • :white_check_mark: 敏感数据（密码/银行卡号/身份证号）必须加密存储
  • :white_check_mark: 加密算法优先使用国密（SM2/SM3/SM4）
  • :cross_mark: 禁止硬编码密钥/密码
  • :cross_mark: 禁止 SQL 拼接（必须使用 PreparedStatement）
  • :cross_mark: 禁止在日志中输出完整银行卡号/身份证号
    Java 示例片段 — 交易订单创建核心逻辑：

Java

@Service
public class TradeOrderServiceImpl implements TradeOrderService {

@Override
@Transactional(rollbackFor = Exception.class)
public TradeOrderCreateResponse createOrder(TradeOrderCreateRequest request) {
    // 1. 幂等性校验（基于业务请求号）
    TradeOrder existingOrder = tradeOrderMapper.selectByBizNo(request.getBizOrderNo());
    if (existingOrder != null) {
        return buildResponse(existingOrder);
    }

    // 2. 分布式锁（防止并发重复创建）
    String lockKey = "trade:order:create:" + request.getBizOrderNo();
    RLock lock = redissonClient.getLock(lockKey);
    try {
        if (!lock.tryLock(5, 30, TimeUnit.SECONDS)) {
            throw new TradeBizException("PAY_BIZ_005", "系统繁忙，请稍后重试");
        }

        // 3. 金额校验（使用 BigDecimal，禁止浮点数）
        AmountUtils.validateAmount(request.getAmount());

        // 4. 创建订单
        TradeOrder order = buildTradeOrder(request);
        tradeOrderMapper.insert(order);

        // 5. 发送异步消息（账户扣款、渠道路由、风控检查）
        kafkaTemplate.send("trade-order-created", JSON.toJSONString(order));

        return buildResponse(order);
    } finally {
        if (lock.isHeldByCurrentThread()) {
            lock.unlock();
        }
    }
}

}
5. 效果与总结
5.1 提效数据
维度 传统方式 使用 SOLO 提效
框架设计 + 文档编写 2-3 人天 约 10 分钟 ~100x
文档模板整理 半天 自动生成 ~30x
Java 示例代码 1 人天 自动生成 ~50x
合规要求梳理 2-3 小时 自动调研 ~20x
5.2 SOLO 在流程中做了什么
并行研究：同时启动 3 个 Explore 子代理，分别调研 OpenCode、Superpowers、金融合规，效率是串行调研的 3 倍
并行编写：同时启动 3 个 Task 子代理，分别编写 Skill 文件、规范文档、Java 示例，10 分钟内产出 25 个文件
质量保障：每个子代理都按照详细的 prompt 要求编写，确保内容的专业性和一致性
自动验证：通过 LS 工具检查目录结构，通过 wc 命令统计文件数量和行数，确保交付物完整
5.3 可复用的方法
"研究 → 设计 → 并行编写 → 验证"四步法：先用 Explore 子代理并行调研，再设计整体架构，然后用 Task 子代理并行编写，最后统一验证。这个模式适用于任何需要大量文档/代码产出的场景。

“给 AI 足够的上下文”：在 prompt 中明确指定文件路径、内容结构、示例要求，AI 的产出质量会大幅提升。模糊的 prompt 产出模糊的结果，精确的 prompt 产出精确的结果。

“借鉴而非重复造轮子”：OpenCode 的 Rules System 和 Superpowers 的 Iron Laws 是经过大量实践验证的设计模式，直接借鉴这些成熟理念，再结合金融行业的特殊要求进行定制，比从零设计要高效得多。

“Skill 化思维”：把每个开发步骤定义为一个独立的 Skill（触发条件 + 工作流步骤 + 交付物 + 评审检查表），这种思维不仅适用于 AI 辅助开发，也适用于团队流程标准化——每个 Skill 就是一个 SOP。

一句话总结：SOLO 不只是帮我写了 25 个文件，更重要的是帮我建立了一套"规则驱动 + 技能化流程 + 金融合规内建"的工程方法论，这套方法论可以复用到任何金融系统的开发项目中。