Superpowers 订单审批开发：群晖测试环境实战

概述

一条订单审批需求，为什么需要一整条开发流程？

周一上午，业务部门提交了一条订单系统需求：满足指定金额、客户等级和折扣条件的订单，需要转入人工复核。本周内要完成测试，下个发布窗口上线。看起来只是加一条规则，研发负责人很快列出了会受影响的地方：Spring Boot API、PostgreSQL 订单数据、Redis 审批状态、角色权限、通知接口和前端提示。

这样的任务，AI 很快能给出第一版代码。团队更关心需求有没有漏项、测试环境能否复现、迁移出错怎样回退，以及由谁确认可以发布。下面跟着这次开发往下看，Superpowers 怎样推动任务，群晖 VMM 与 Container Manager 又怎样承接运行和验证环境。

上午：一句需求里还藏着哪些条件？

开发人员先用 Superpowers 的 brainstorming 把需求问完整：哪些订单进入复核，折扣按百分比还是金额计算，谁有复核权限，已有订单怎样处理，通知接口在测试中由什么服务代替。

讨论后，产品、开发和测试依据同一份验收样本确认了范围。业务需求从一句话变成了可以执行的判断条件。

这份记录里最容易被口头需求带过的，是条件之间的关系。金额、客户等级和折扣是三个并列条件，只有同时满足才把订单转入人工复核；其中任意一项没有达到规则，订单继续按既有流程处理。写清楚之后，测试人员才有办法为两条路径分别准备样本，而不是凭感觉判断某一单该走哪边。

角色权限是第二组容易被略过的条件。复核角色能看到待复核队列并做出审批动作，普通业务角色只能提交和查询订单，两种账号在测试中要分别登录验证一次。历史订单则只保留一条要求：执行数据库迁移之后仍然可以查询，并且既有流程可以继续走完。

产品负责人确认业务规则，技术负责人确认接口和数据边界，测试人员检查样本是否覆盖主要路径。后续的实施计划、测试用例和代码审查都以这份验收样本为准；讨论中出现的口头补充如果没有写进来，就不算这一轮的范围。

中午：开发人员如何知道先改什么？

范围确认后，Superpowers 通过 writing-plans 生成实施计划。计划列出规则服务、数据库迁移、API 契约、前端提示、权限校验、自动化测试和发布说明；每一项都写明相关文件、依赖、测试命令与完成条件。

开发人员按计划在群晖 VMM 的 Linux 测试虚拟机中创建独立 Git worktree 和功能分支。这个动作对应 Superpowers 的 using-git-worktrees：审批功能的代码、依赖安装和测试结果留在独立工作目录，不与其他正在进行的改动混在一起。

计划落到具体动作时，代码仓库会分成两块。主工作区（Main workspace）保持原样，供其他正在进行的改动继续使用；订单审批功能从它分出一条功能分支（Feature branch），并挂上一个独立的 Git worktree 目录。这个目录里有自己的源码副本（Source）、自己的依赖安装结果（Dependencies）和自己的测试产物（Tests），依赖版本冲突或构建失败都关在里面，不会波及主工作区。

整个独立工作区运行在群晖 VMM 的 Linux 测试虚拟机中。虚拟机接入测试 VLAN，使用测试 DNS、受控测试账号和 Btrfs 存储，它提供的是统一的 Linux 运行环境：每名参与者执行 Build 和 Test 时，依赖版本、网络路径和基础工具都可按同一份记录重建。VMM 可运行 Windows、Linux 与 Virtual DSM，项目可按实际工具链选择相应系统。

这样安排之后，构建结果在不同人机器上不一致时有了处理办法：把测试虚拟机重建一遍，或者把 worktree 换个目录重新拉起来，Build 与 Test 的结果就能重新对齐。计划表里每一项的完成条件也因此可以由别人复核，而不只是开发人员自己确认。

下午：先让新规则在测试中失败

测试环境先启动起来。群晖 DSM 7.2 及后续版本使用 Container Manager，DSM 7.1 及更早版本使用 Docker 名称。这个订单审批项目通过 Container Manager 启动 API、测试数据库、缓存和通知 Mock；项目配置与代码一同进入版本管理。

一条测试样本进入这套环境后的路径是固定的：请求带着金额、客户等级和折扣三个条件先到 approval-api，由它执行规则判断和状态流转；订单与审批记录写进 postgres-test 的脱敏数据；短期审批状态放在 redis-test；需要对外通知时调用 notification-mock，由它返回固定响应并留下调用记录。Container Manager 在这条链路上承担的是底座职责：把四个容器一起拉起来、一起停掉、一起按同一份项目配置重建。

开发人员运行“订单应进入人工复核”的测试。结果如预期失败，系统仍沿用原审批路径。失败结果把规则缺口标了出来，开发人员据此完成最小实现，这正是测试驱动开发（test-driven-development）在这项任务中的用法。

AI 在这个过程中可以起草测试代码、阅读失败日志、提示可能受影响的模块；开发人员根据规则调整服务逻辑和接口。随后，团队在同一套环境里依次复跑人工复核、原审批路径、角色权限和历史订单兼容四组样本。生产订单、生产数据库连接和生产凭据始终留在生产环境，测试项目只使用脱敏数据和受控凭据。

下午晚些时候：迁移脚本出错，怎样把环境拉回稳定状态？

历史订单兼容测试出现错误。数据库迁移脚本新增的字段定义影响了旧订单查询。开发人员按 Superpowers 的 systematic-debugging 流程保存失败日志和当前提交，固定复现条件，检查最近改动，再沿 API 调用、迁移脚本和数据库查询逐层排查。

导入脱敏订单数据、升级依赖或运行迁移脚本前，团队已经在 VMM 中创建了 order-approval-feature-before-migration 快照。快照记录了关联分支、创建人、用途和保留期限。测试人员停止相关服务，从迁移前的快照恢复虚拟机，再重新启动 Container Manager 项目、导入对应数据并复跑失败样本。

回退动作里最需要说清楚的是返回的位置。恢复指向 order-approval-feature-before-migration 这个迁移前快照，而不是出错之后的任何一次中间状态；旧订单查询报错的那条支线到此为止，不再往下延伸。从这个已验证的起点重新修改迁移脚本、重新执行迁移、重新跑历史订单兼容样本，得到的复测结果才能说明改动本身是有效的。

这次回退让排查重新回到一个已验证的状态。修复后的迁移脚本通过测试后，团队把问题原因、修复提交、复测结果和快照记录放进任务中。VMM 快照适合处理近期版本回退和测试实例克隆；虚拟机导出、备份副本和恢复演练则承接跨设备、站点故障和长期保留的恢复目标。

傍晚：审查人怎样判断这项功能可以合并？

代码审查时，审查人先打开当天确认过的实施计划，用 requesting-code-review 逐项勾对规则服务、迁移脚本、API、权限校验和测试记录，并查看每项对应的验证结果。

审查范围同时包括运行条件。除了代码提交，审查人还查看 Container Manager 项目配置、镜像版本、数据卷和环境变量，核对 VMM 快照记录与回滚说明。AI 可以整理候选审查意见，代码所有者仍负责判断业务规则、架构取舍和合并条件。

需要同时规划 AI 代码生成、审查规则和代码仓库备份的团队，可阅读 AI 代码审查与代码仓库备份方案。

发布前：怎样完成最后一次交付验证？

发布前，团队在干净的测试虚拟机或容器项目中重新启动依赖、运行构建与自动化测试，并验证快照恢复、角色权限、数据库迁移和回滚说明。这一步对应 Superpowers 的 verification-before-completion。功能达到完成条件后，再通过 finishing-a-development-branch 汇总材料、完成分支收尾，进入企业既有的合并和发布审批流程。

这些材料最终会归成同一个交付证据包：实施计划、代码提交、测试结果、环境配置、快照记录和回滚说明各是一份独立文档，谁写的、什么时候写的、对应哪次提交都能查到。环境配置那一份记录 Container Manager 的项目配置、镜像版本、数据卷和环境变量；快照记录那一份写明 VMM 快照的名称、关联分支、用途和保留期限。

证据包齐备之后才进入发布前的验证闸门：重新构建、跑一遍自动化测试、验证角色权限、执行数据库迁移、演练一次快照恢复。这几项都通过，这个功能分支的状态才是“可进入发布审批”，接下来由企业既有的合并和发布流程接手；AI 整理出来的候选审查意见到这一步已经完成它的作用，这也是这套 AI 开发治理安排里责任始终落在人身上的地方。

这次订单审批功能交付时，团队提交了验收样本、实施计划、功能分支、容器项目配置、虚拟机与快照记录、测试报告和发布说明。下一次遇到类似改动，这些材料可以直接作为环境准备、审查和发布的起点。

首次试点怎样开始？

首次试点可选择边界清楚的功能，例如增加一个查询字段、补一组报表校验，或调整一条内部审批规则。试点清单应列出仓库、参与角色、VMM 虚拟机或 Container Manager 项目、测试数据、构建命令、快照恢复点、代码审查人和发布责任人。每轮结束后记录需求遗漏、环境差异、测试缺口和返工原因，再据此调整项目模板和 AI 工作流。

涉及本地模型、内部知识库或研发资料存放时，还可延伸规划数据位置、访问身份、网络隔离和备份，相关架构可阅读 GPU NAS、本地 LLM 与 RAG 存储规划。

成都及西南企业怎样咨询 AI 开发流程与群晖测试环境？

企业可从一个试点功能开始，把需求澄清、计划、测试、调试、审查和收尾放进同一条流程，再为它准备可重建的 VMM 虚拟机与 Container Manager 测试项目。沟通前先整理出仓库清单、参与角色、现有测试环境形态和期望的发布节奏，评估会更具体。

成都美步科技有限公司（简称美步科技）是四川成都 Synology 群晖授权代理与方案集成商，可协助西南地区企业梳理群晖开发测试环境规划、VMM 虚拟机与快照策略、Container Manager 项目配置、研发资料存放、代码仓库备份与访问控制的实施范围。咨询热线 028-82009000。

申请 AI 开发流程与群晖测试环境评估

本文参考 Superpowers 开源项目文档与 Synology 官方知识库综合整理，具体功能以各自最新发布版本为准。详细引用清单详见文末“参考来源”区块。