SDD 多仓协作流水线架构：提示词同步、Guard Rails 隔离与测试层级设计

归类：DevOps / AI 工程化 / SDD / 流水线设计
日期：2026-06-08
状态：✅ 已落地

一、背景与核心问题

在 AI 驱动的业务审批系统中，常见的工程化挑战是：

Prompt 资产如何在规范仓与原型仓之间保持同步？
涉及服务端（Java）的 AI 增量改造，如何既引入 AI 辅助又防止生产环境被污染？
哪些测试是自动化闭环的？哪些仍依赖人工验证？

本文基于一套实际落地的 SDD 流水线（以 cybervisor.yaml 为调度中心、三仓协作）的梳理结论，给出可复用的设计模式与改进方向。

二、三仓协作模型

┌─────────────────────────────────────────┐
│  规范仓 (finance-spec)                  │
│  ├── prompts/[费用类型]/                │
│  │     └── logic_audit_prompt_*.md     │
│  ├── scripts/run_v2_regression.py      │
│  └── cybervisor.yaml  ← 调度中心       │
└───────────────┬─────────────────────────┘
                │ Implement / Verify 管道
     ┌──────────▼──────────┐
     │  原型仓 (finance-proto)            │
     │  ├── generate_dify_workflow.py    │
     │  ├── test-dify/审批/*.yml         │
     │  └── AIVerifyDify.vue             │
     └──────────┬──────────┘
                │ AgenticUpgrade 管道（增量植入）
     ┌──────────▼──────────┐
     │  服务端仓 (Java)                  │
     │  ├── LocalAuditEngine.java        │
     │  └── WebServiceImpl.doAiAuditV2() │
     └─────────────────────┘

三、 Prompt 资产同步设计

3.1 双向同步脚本

脚本	方向	触发管道
`sync_prompts_from_proto.mjs`	原型仓 → 规范仓（提取干净版）	`Implement`
`sync_prompts_to_proto.mjs`	规范仓 → 原型仓（反向注入）	按需手动

3.2 一致性守卫

在 Verify 管道中，使用 git diff --exit-code prompts/ 强制校验两仓是否完全一致，防止漏同步导致线上 Prompt 与规范不一致。

yaml

# cybervisor.yaml Verify 管道片段
- name: check-prompt-consistency
  command: "node scripts/sync_prompts_from_proto.mjs && git diff --exit-code prompts/"

3.3 Dify 工作流重编译链路

Prompt 修改
  → generate_dify_workflow.py（字符串 replace 注入 YAML 模板）
  → 测试版/沙箱版_v2.yml（本地资产更新）
  → ⚠️ Dify 平台导入（当前为手动步骤，最大断链）

改进方向：接入 Dify Open API，将 YAML 上传/热更新封装为 CI step，消除手动瓶颈。

四、服务端增量修改：Guard Rails 隔离策略

当涉及 Java 服务端改造时，推荐采用 "提示词强引导 + 分支隔离 + 增量仅追加" 的受控 Vibe Coding 模式。

4.1 三道护栏

护栏	实现方式
分支隔离	强制 AI 所有操作在独立分支（如 `feat/agentic-upgrade-v2`）上进行，不能直接 push master
文件禁修清单	在 YAML 中声明 `forbidden_modifications`，AI 助手必须拒绝修改线上核心文件
增量仅追加	新增文件（`LocalAuditEngine.java`）或在类末尾追加新方法（`doAiAuditV2()`），绝不改动已有方法签名和方法体

yaml

isolation_policy:
  branch: "feat/agentic-upgrade-v2"
  forbidden_modifications:
    - "src/main/...WebServiceImpl.java#doAiAudit()"
    - "prompts/xxx/logic_audit_prompt.md"

4.2 为什么不能完全自动修改

Java Maven 工程依赖内部框架，若 AI 自由改写，易出现：

内部 SCF 框架依赖类型推导失败
Jetty 容器初始化路由注册异常
方法签名的 Bean 注入被破坏

因此，AI 辅助产出代码后，仍需人工 Review + mvn compile 编译验证。

五、测试层级设计与盲区分析

5.1 当前覆盖层级

L1  提示词一致性静态对比         git diff --exit-code          ✅ 自动化
L2  规则逻辑回归测试             run_v2_regression.py          ✅ 自动化（42用例 100%）
L3  人工可视化验证               在线工作台贴 JSON 运行         ⚠️ 依赖人工

5.2 当前盲区

盲区	风险
Java 编译 & JUnit 单测	AI 植入代码破坏编译链路，无法被提前发现
Controller 接口契约测试	Java 改动导致请求/响应字段偏移，无自动感知
Dify → Java 端到端链路	`localCalcResult` 字段结构悄悄漂移，两端约定失效
新费用类型自动感知	同步脚本硬编码路径映射，新增类型需手动扩展

5.3 推荐的补全路径

优先级 ① 接入 Dify Open API → 自动发布 YAML，消除最大手动瓶颈
优先级 ② 在流水线末尾追加 mvn compile → 捕获 Java 侧编译异常
优先级 ③ 将工作台调试 JSON 沉淀为 HTTP 测试脚本 → 接口契约自动验证
优先级 ④ 同步脚本动态扫描目录 → 支持新费用类型自动扩展

六、可复用的 cybervisor.yaml 管道模式

对于类似的多仓协作 SDD 项目，可参考以下四类管道模板：

管道名称	适用场景	核心 step
`panorama_analysis`	项目初始化后生成全景文档	发现子项目 → Mermaid 图 → 规范文档
`Implement`	原型验证通过后沉淀 Prompt 资产	`sync_prompts_from_proto.mjs`
`Verify`	验证原型与规范 Prompt 一致性	`git diff` + 回归测试脚本
`AgenticUpgrade`	服务端 AI 增量改造（含 Guard Rails）	分支创建 → 文件新增 → 方法追加 → 回归验证

七、关键设计原则

增量而非覆盖：所有 AI 辅助的服务端改动，优先选择新建文件和追加方法，禁止在未充分测试的情况下改写线上稳定代码。
测试先行的回归：Prompt 每一次变更后，必须在 commit 之前通过本地规则回归脚本的 100% 通过率验证，才能进入同步流程。
变更日志强制追记：每次 Prompt 或工作流资产变更，必须在对应费用类型的 CHANGELOG.md 中追加版本记录，保证高保真可追溯性。
守门员一致性检查：流水线的 Verify 管道作为"守门员"存在，用 git diff 强制拦截未同步的 Prompt 漂移，防止规范仓与原型仓的悄然分歧积累。

SDD 多仓协作流水线架构：提示词同步、Guard Rails 隔离与测试层级设计 ​

一、 背景与核心问题 ​

二、 三仓协作模型 ​

三、 Prompt 资产同步设计 ​

3.1 双向同步脚本 ​

3.2 一致性守卫 ​

3.3 Dify 工作流重编译链路 ​

四、 服务端增量修改：Guard Rails 隔离策略 ​

4.1 三道护栏 ​

4.2 为什么不能完全自动修改 ​

五、 测试层级设计与盲区分析 ​

5.1 当前覆盖层级 ​

5.2 当前盲区 ​

5.3 推荐的补全路径 ​

六、 可复用的 cybervisor.yaml 管道模式 ​

七、关键设计原则 ​