AI Coding

面向需求、代码、测试与应用运维的 AI DevOps 平台。

AI Coding 当前已经不只是代码生成工具，而是覆盖需求、开发、测试、部署、质量门禁、归档和应用运维的 AI DevOps / AI SDLC 平台。它把 MRD、应用管理、知识库、需求 PI、代码实现、测试验证、跨应用 AI Testing 和 AI Ops 应用运维串成一条可追踪的研发交付链路。

当前产品形态不是“上传项目文件让模型猜”。需求从 MRD 和平台知识库出发，系统先基于应用管理列表、全局知识库和应用级知识库判断影响应用，再进入需求归属确认、应用分支并发实现、跨应用测试和归档交付。

完整链路：

需求管理
  -> 应用管理 / 知识库管理
  -> 需求 PI / 影响面分析
  -> 多应用代码实现
  -> 单应用测试
  -> 跨应用 AI Testing
  -> 部署关联应用
  -> 质量门禁 / 回归计划
  -> 归档交付
  -> AI Ops 应用运维

AI DevOps 设计思路

这个系统的核心设计不是“让 AI 写一段代码”，而是把研发交付过程中的需求、应用、知识、代码、测试、部署、质量和运维统一到一条可追踪的事实链路里。

传统研发流程里，需求、技术方案、开发、测试、上线和运维通常分散在不同系统中。AI 只能看到局部上下文，很容易出现几个问题：

MRD 里没有明确写影响哪些应用。
开发知道改了哪些代码，但测试不知道该覆盖哪些跨应用链路。
测试有用例，但不知道需要准备哪些领域数据。
运维看到告警，但不知道和历史需求、代码改动、上下游依赖有什么关系。
产物散在聊天记录、文档、流水线日志和本地文件里，无法复盘。

AI DevOps 的设计目标是把这些分散事实统一起来：

MRD
  -> 应用管理
  -> 知识库 / GitNexus
  -> 需求归属确认
  -> 多应用分支实现
  -> 单应用测试
  -> 跨应用测试
  -> lifecycle artifacts
  -> 运维影响面分析

1. 知识库是怎么设计的

知识库分两层：

应用级知识库
  -> 描述单个应用负责什么、有哪些接口、依赖谁、有哪些数据库表、怎么测试和造数

全局知识库
  -> 汇总所有应用的业务域、能力地图、API 路由图、依赖图、影响面索引和业务术语

生成链路：

应用管理列表
  -> 仓库扫描
  -> GitNexus 代码图谱
  -> 应用级知识库
  -> 全局知识库合并
  -> 新鲜度记录

知识库解决的是“AI 判断必须有证据”的问题。比如 MRD 里出现“库存保护”，系统不会靠硬编码把它映射到 ecom-inventory，而是按下面的证据链判断：

MRD 关键词：库存保护、库存不足、可用库存
  -> global capability-map 命中库存能力
  -> app-domain-map 命中 inventory 域
  -> dependency-map 发现 ecom-marketing 依赖 ecom-inventory
  -> 应用级知识库确认 ecom-inventory 拥有库存可用性校验
  -> ecom-inventory 进入候选影响应用

2. 需求是怎么从 MRD 拆到多个应用改动的

需求 PI 的关键不是直接生成代码，而是先做需求归属确认。

MRD
  -> 提取业务关键词、验收场景、用户入口、领域名词
  -> 从应用管理拿候选应用
  -> 从 global 知识库召回相关应用
  -> 从应用级知识库验证应用能力
  -> 生成 requirement-ownership.json
  -> 生成 fanout-decision.json
  -> 创建应用分支 workflow

以当前 case 为例：

MRD: 定向营销活动创建时增加商品上架与库存保护校验

拆解结果：

MRD 能力点	命中证据	应用	分支动作
活动创建主流程	营销活动、campaign、createCampaign	`ecom-marketing`	后端实现 + 后端测试
商品上架校验	商品状态、SKU、SALEABLE	`ecom-product`	后端实现 + 后端测试
库存保护校验	库存、availableQuantity、stock guard	`ecom-inventory`	后端实现 + 后端测试
运营后台错误提示	console、运营后台、创建页面	`console`	前端实现 + 前端测试

最终不是生成一个大任务，而是生成多个独立应用分支：

console
  -> frontend-impl
  -> frontend-test

ecom-marketing
  -> java-impl
  -> backend-test

ecom-product
  -> java-impl
  -> backend-test

ecom-inventory
  -> java-impl
  -> backend-test

每个分支都有自己的子 agent、产物和失败回退，避免多应用上下文互相污染。

2.1 多应用代码实现怎么触发子 agent

需求归属确认完成后，系统会生成 fanout-decision.json。这个文件决定哪些应用进入本次实现分支：

fanout-decision.json
  -> includedProjects
  -> workflowInstance.branches
  -> branch nodes

Pipeline Engine 在进入应用实现阶段时，不是创建一个大 agent 处理所有应用，而是按分支创建子 agent：

for each branch project:
  create AgentEngine(projectName, nodeId)
  cwd = 当前应用项目目录
  tools = read / grep / edit / write / maven / bash
  prompt = 当前应用的 MRD + 技术方案 + OpenSpec 任务 + 知识库证据

也就是说：

ecom-marketing/java-impl 有自己的实现 agent。
ecom-product/java-impl 有自己的实现 agent。
ecom-inventory/java-impl 有自己的实现 agent。
console/frontend-impl 有自己的前端实现 agent。

子 agent 的触发条件来自分支节点状态：

branch node status != completed/skipped
  -> 可以触发对应子 agent

某个应用的 java-impl 完成后，该应用可以直接进入 backend-test，不需要等待其他应用的 java-impl 都完成。这就是“分支流水线并发”。

2.2 子 agent 之间怎么通信

子 agent 之间不直接通信，也不共享对话上下文。这样设计是为了避免一个应用的上下文污染另一个应用。

通信方式是通过结构化产物和 workflow 状态完成的：

子 agent A
  -> 写入 artifacts/<app>/...
  -> 更新 branch artifactIndex
  -> 更新 branch node status

子 agent B
  -> 只读取自己应用相关输入
  -> 需要跨应用信息时读取正式产物，而不是读取 A 的聊天记录

允许共享的是正式事实：

mrd-clarified.md
requirement-ownership.json
fanout-decision.json
<app>/tech-design.md
<app>/branch-summary.json
lifecycle artifacts
知识库 / GitNexus 证据

不允许共享的是：

sibling agent 的自由对话上下文
sibling agent 的未确认中间推理
sibling 分支的失败状态
sibling 分支的临时工具输出

分支汇合时，系统只汇总每个分支的 branch-summary.json 和 lifecycle artifacts：

branch summaries
  -> app join
  -> AI Testing input

所以子 agent 之间不是“聊天协作”，而是“通过产物和事实模型协作”。

3. 造数是怎么判断的

造数不是让模型随便编几条 JSON。AI Testing 会根据测试用例、应用影响面、知识库里的数据实体和依赖关系判断需要哪些领域数据。

判断依据：

MRD 的验收场景。
进入实现分支的应用。
知识库里的数据库表、领域实体和接口说明。
跨应用依赖链路。
测试用例的前置条件和断言。

当前 case 的造数判断：

活动创建需要：
  -> 一个可上架商品
  -> 一条可用库存
  -> 一个活动草稿或创建请求

负向场景需要：
  -> 一个未上架商品
  -> 一条低库存记录

所以 AI Testing 生成的数据计划会落到领域 data builder：

商品域 builder
  -> createSku(SALEABLE)
  -> createSku(OFF_SHELF)

库存域 builder
  -> setStock(AVAILABLE)
  -> setStock(lowStock)

营销域 builder
  -> createCampaign(DRAFT)

真实执行时，demo/ecom/ecom-integration-tests 会运行：

npm run seed
npm run test:live

其中 seed 负责真实造数，test:live 负责验证跨应用链路。

4. 影响面是怎么分析的

影响面分析是贯穿 AI Coding、AI Testing、AI Ops 的横切能力。

它综合四类事实：

需求事实：MRD、requirement-ownership、fanout-decision
应用事实：应用管理、应用业务域、应用能力
知识事实：应用级知识库、global 知识库、业务术语
代码事实：GitNexus 文件图谱、接口图谱、依赖图谱
运行事实：部署、测试、覆盖率、质量门禁、告警、归档

在 AI Coding 中，影响面用于判断哪些应用需要改代码：

MRD -> 知识库召回 -> 应用级验证 -> fanout-decision

在 AI Testing 中，影响面用于判断哪些链路需要测试：

已改应用
  -> 上游入口
  -> 下游依赖
  -> 共享数据实体
  -> 集成测试用例
  -> 回归范围

在 AI Ops 中，影响面用于判断告警会影响哪些上下游：

告警接口 / traceId / 错误关键词
  -> 应用知识库
  -> GitNexus 依赖图
  -> 上下游应用
  -> 修复建议

这个设计保证了同一套事实可以服务研发、测试和运维，而不是每个环节重新让模型猜一次。

5. 怎么知道要启动哪些服务

服务启动不是由模型随意决定，而是由 lifecycle deployment context 和影响面共同决定。

判断输入：

fanout-decision.json
  -> 本次需求直接影响哪些应用

branch-summary.json
  -> 每个应用实际改了什么

dependency-map / GitNexus
  -> 哪些上下游链路需要参与集成测试

AI Testing data plan / cases
  -> 测试执行依赖哪些领域服务

lifecycle deployment set
  -> 本次测试环境应该部署哪些 app ref

在当前 ecom case 中：

活动创建链路：
  console
    -> ecom-marketing
      -> ecom-product
      -> ecom-inventory

因此部署关联应用阶段会准备这些服务：

服务	启动原因
`console`	运营后台入口和前端交互
`ecom-marketing`	活动创建主服务
`ecom-product`	商品上架状态校验
`ecom-inventory`	库存保护校验

demo 环境下，服务启动落到：

./demo/ecom/scripts/start-all.sh

AI Testing 执行前会创建 deployment context：

deploymentSet
  -> environment
  -> app refs
  -> testing workflow

然后集成测试仓库执行：

cd demo/ecom/ecom-integration-tests
npm run seed
npm run test:live

如果后续接入真实环境，这里可以替换为：

K8s namespace 部署
CI/CD pipeline 部署
测试环境服务发现
稳定版本 + feature version 混部
按 dependency-map 只启动必要服务

产品截图

AI Coding / 需求 PI

AI Testing / 跨应用测试

AI Ops / 应用运维

应用管理

知识库管理

产品演示与技术方案

每个模块都可以作为一个独立产品来介绍：先看产品演示和核心特色，再看技术链路和实现边界。

核心能力

需求管理：维护 MRD，MRD Ready 后从需求管理页面启动 PI 流程。
应用管理：维护应用列表、仓库路径、应用类型、业务域、接口和依赖信息。
知识库管理：生成应用级知识库、全局应用能力图谱、依赖图谱、API 路由图和业务术语索引。
需求归属确认：根据 MRD + 全局知识库 + 应用级知识库确认影响应用，不依赖硬编码业务映射。
应用分支流水线：每个应用独立子 agent、独立状态、独立产物和独立失败回退。
AI Coding：面向开发交付，按应用生成实施方案与任务，完成 Java/前端实现、代码审查、后端测试、前端测试和分支摘要。
AI Testing：面向测试交付，生成集成测试用例、造数计划、集成测试代码，部署关联应用并执行真实跨应用测试。
AI Ops：面向应用运维，基于应用、源码、知识库、GitNexus 产物和本地告警内容做告警分析与修复建议。
生命周期产物：部署、测试、覆盖率、质量门禁、失败归因、回归计划和归档报告统一登记为 lifecycle artifacts。

已跑通的真实 Case

当前完整跑通的主用例是：

MRD: 定向营销活动创建时增加商品上架与库存保护校验

系统根据 MRD 和知识库命中的影响应用：

console
ecom-marketing
ecom-product
ecom-inventory

已验证能力：

从需求管理启动 PI 流程。
需求分析与归属确认不再要求上传代码项目。
应用分支按流水线并发推进，而不是阶段栅栏式推进。
子 agent 之间隔离上下文，一个分支失败不会污染 sibling 分支。
console 前端实现和测试独立执行。
后端应用完成 Java 实现和后端测试。
跨应用测试执行真实造数和真实集成测试。
最终归档完成。

真实跨应用测试仓库：

demo/ecom/ecom-integration-tests

真实执行命令：

npm run seed
npm run test:live

已验证 run：

g2jG99Lmk1

该 run 已完成全部 PI 节点，npm run seed 写入真实商品、库存、活动数据，npm run test:live 执行 node:test 集成测试并通过 2 个用例。

示例

需求输入示例

定向营销活动创建时，需要校验商品是否已上架，并校验库存是否可用。
如果商品未上架或库存不足，活动创建应失败并给出明确提示。

应用归属示例

应用	归属原因	处理方式
`ecom-marketing`	活动创建主流程	进入后端实现分支
`ecom-product`	商品上架状态校验	进入后端实现分支
`ecom-inventory`	库存保护校验	进入后端实现分支
`console`	活动创建页面提示和交互	进入前端实现分支

AI Testing 示例

造数：
  -> 创建 SALEABLE SKU
  -> 设置 AVAILABLE 库存
  -> 创建 DRAFT 定向活动

集成测试：
  -> 商品和库存数据准备完成后允许创建活动
  -> 未上架商品和低库存场景进入负向用例

AI Ops 示例

告警：营销活动创建失败率升高
线索：marketing createCampaign 接口返回库存保护错误
影响面：ecom-marketing -> ecom-product / ecom-inventory
建议：先校验商品状态接口，再校验库存查询链路，最后回归活动创建链路

工作流

需求 PI 主流程

MRD / Knowledge Init
  -> 需求分析与归属确认
  -> 实施方案与任务
  -> 应用分支流水线
  -> 分支汇合
  -> 集成测试用例
  -> 造数
  -> 生成集成测试代码
  -> 部署关联应用
  -> 执行集成测试
  -> 归档

应用分支流水线

后端应用：

implementation-plan
  -> java-impl
  -> backend-test

前端应用：

implementation-plan
  -> frontend-impl
  -> frontend-test

AI Testing 流程

load_requirement
  -> retrieve_context
  -> generate_strategy
  -> review_strategy
  -> generate_cases
  -> review_cases
  -> generate_data_plans
  -> review_data_plans
  -> deploy_related_apps
  -> generate_scripts
  -> review_scripts
  -> execute_scripts
  -> collect_report
  -> calculate_metrics
  -> quality_gate
  -> failure_triage
  -> regression_update
  -> persist_artifacts

快速开始

环境要求

Node.js 20+
npm
Java / JDK
Maven
可用的大模型 API 配置

安装

npm install
npm run build

启动

npm start

默认访问：

http://localhost:3000

开发模式：

npm run dev

模型配置

常用环境变量：

LLM_PROVIDER=openai-compat
LLM_MODEL=gpt-5.4
LLM_BASE_URL=https://your-model-endpoint/v1
LLM_API_KEY=your-api-key
JAVA_HOME=/path/to/jdk
MAVEN_HOME=/path/to/maven
PORT=3000

完整 PI 流程应使用真实大模型调用验证，不应使用 mock LLM。

Demo Ecom

Demo 多应用工程位于：

demo/ecom/

常用命令：

./demo/ecom/scripts/init-db.sh
./demo/ecom/scripts/build-all.sh
./demo/ecom/scripts/start-all.sh
./demo/ecom/scripts/stop-all.sh

集成测试仓库：

demo/ecom/ecom-integration-tests/

它包含：

测试 fixture
各领域数据 builder
seed 造数脚本
node:test 集成测试
live 服务健康检查

手动验证：

cd demo/ecom/ecom-integration-tests
npm run seed
npm run test:live

test:live 要求相关服务可用；服务不可用时会失败，不会静默 skip。

关键产物

运行态目录：

runtime-projects/runs/<runId>/artifacts/

常见 PI 产物：

project-manifest.json
mrd-clarified.md
mrd-clarify-questions.md
requirement-ownership.json
fanout-decision.json
<app>/tech-design.md
<app>/openspec/.../tasks.md
<app>/changed-files.json
<app>/code-preview-manifest.json
<app>/code-review.md
<app>/changed-test-files/*
<app>/test-report.md
<app>/frontend-implementation-report.md
<app>/frontend-test-report.md
<app>/branch-summary.json
cross-app/test-results.json
cross-app/delivery-metadata.json
archive-manifest.json

AI Testing 产物：

testing/<workflowInstanceId>/generate_strategy/testing-strategy-*.json
testing/<workflowInstanceId>/generate_cases/testing-test-cases-*.json
testing/<workflowInstanceId>/generate_data_plans/testing-data-plan-*.json
testing/<workflowInstanceId>/generate_scripts/testing-generated-script-*.json
testing/<workflowInstanceId>/execute_scripts/testing-execution-report-*.json
testing/<workflowInstanceId>/calculate_metrics/testing-coverage-report-*.json
testing/<workflowInstanceId>/quality_gate/testing-quality-gate-*.json
testing/<workflowInstanceId>/regression_update/testing-regression-plan-*.json

架构分层

src/
  agents/
    codegen/          # 需求 PI 与代码生成 Agent
    testing/          # AI Testing Agent
    ops/              # AI Ops Agent
    knowledge/        # 知识库 Agent
    core/             # 共享 Agent Runtime
  application/        # 应用管理产品服务
  knowledge/          # 知识库初始化与检索
  lifecycle/          # 部署、测试、归档、质量门禁等生命周期事实模型
  requirement-pi/     # 需求 PI 产品入口
  requirements/       # 需求管理服务
  testing/            # AI Testing 产品服务
  app-ops/            # 应用运维服务
  tools/
    builtin/          # read / grep / glob / edit / bash / Java / Maven 工具
    knowledge/        # 知识库检索工具
    testing/          # 造数、脚本、执行、指标、schema 工具
    ops/              # 运维分析工具
  workflows/
    definitions/      # Workflow 模板与节点契约
    engine/           # PI Pipeline Engine
    runtime/          # 分支执行、testing runtime、ops runtime
  server/             # Hono API、Controller、WebSocket
  session/            # Session 与 execution-state 读模型
web/                  # 单页前端
prompts/              # 节点 Prompt
demo/ecom/            # 本地多应用 Demo 工作区

分层原则：

Controller 只做 HTTP 入口，不承载业务逻辑。
产品服务层负责需求、应用、知识库、测试、运维等领域能力。
Workflow definition 描述流程模板，runtime/engine 负责执行。
Agent 负责推理和工具调用，正式结果必须落结构化 artifact。
Tool 负责读写文件、检索知识库、执行构建测试和运行真实命令。
lifecycle 记录部署、测试、覆盖率、质量门禁、失败归因、归档等事实。

测试

运行全部测试：

npm test

常用聚焦测试：

npm run build
node --test dist/__tests__/workflow-foundation.test.js
node --test dist/__tests__/testing-workflow-runtime.test.js dist/__tests__/testing-controller.test.js dist/__tests__/testing-tools.test.js

运行说明

运行态保存在 runtime-projects/。
本地模型配置和密钥不应提交到 Git。
每个应用分支拥有独立 agent id、artifact index、失败状态和重试状态。
顶层 fanout/join 只汇总分支状态，不共享子 agent 上下文。
跨应用测试不能只看节点状态，必须查看真实 execution report。

License

内部原型项目。公开发布前请补充正式 License。

Name		Name	Last commit message	Last commit date
Latest commit History 22 Commits
.codex/skills		.codex/skills
demo		demo
docs		docs
openspec		openspec
prompts		prompts
src		src
web		web
.gitignore		.gitignore
README.md		README.md
package-lock.json		package-lock.json
package.json		package.json
tsconfig.json		tsconfig.json
wechat.jpg		wechat.jpg

Folders and files

Latest commit

History

Repository files navigation

AI Coding

AI DevOps 设计思路

1. 知识库是怎么设计的

2. 需求是怎么从 MRD 拆到多个应用改动的

2.1 多应用代码实现怎么触发子 agent

2.2 子 agent 之间怎么通信

3. 造数是怎么判断的

4. 影响面是怎么分析的

5. 怎么知道要启动哪些服务

产品截图

AI Coding / 需求 PI

AI Testing / 跨应用测试

AI Ops / 应用运维

应用管理

知识库管理

产品演示与技术方案

核心能力

已跑通的真实 Case

示例

需求输入示例

应用归属示例

AI Testing 示例

AI Ops 示例

工作流

需求 PI 主流程

应用分支流水线

AI Testing 流程

快速开始

环境要求

安装

启动

模型配置

Demo Ecom

关键产物

架构分层

测试

运行说明

License

About

Topics

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

Packages