AI DEVELOPMENT PLATFORM
KUMIRAI ／ AI 驱动开发平台
从设计到单元测试：AI 负责生成，机器负责检查，人负责决定。
计划经人确认后才开始生成，交付的代码均已通过机械检证与一致性确认。
任务、成果物版本、Review 指摘与采用结论关联保存，换人后也能沿同一记录继续推进。
AI 导入后的四类交付缺口
课题并非「AI 能否编写代码」，而在于 AI 生成之后的团队交付 —— 对 2.2 万名开发者的遥测显示，审查耗时的中位数增加了 441.5%（Faros AI《Acceleration Whiplash》，2026 年）。缺口集中在下面四处。
术语、内容粒度和检查要求仍需按客户逐一确认，AI 的产出无法直接作为交付物；日语设计书中“適宜”“検討の上”一类的含糊表述，AI 会作确定性解读并反映到代码里，而且不会提示已作此解读。
资料可能缺失或相互冲突，业务规则和保留范围难以确认；形式正确、业务逻辑却错误的代码，正是从这里产生的。
PR 数量没有减少，每个 PR 要看的内容却在增加；业务判断与修正确认仍依赖少数资深人员，生成越快，等待确认的时间越长。
任务状态、采用版本和确认记录需要反复查找；了解来龙去脉的人一旦离开，判断的依据就无从追溯。
共同作业方式与工序
无论哪道工序，都按同一套方式推进 —— 确认输入、作成成果物、独立检查、人工确认、留存版本与证据；切换下图，可以看到这套方式在编码实现与单元测试中如何展开。
上方的横条是 KUMIRAI 的共同作业方式，下方是这套方式在各工序中的具体顺序。
人工确认点共两处：生成前的计划确认，生成后的最终确认与合入；预检不通过的计划不得进入人工审查。
代码按详细设计中的依赖顺序分批生成（配置 → 实体与契约 → 持久层 → DAO → Service → Controller）；机械检证未通过即自动回到代码生成，同一任务往返超过 3 次则升级处理（换模型、拆分任务，或挂起等人判断）。本工序不实施任何测试，品质由设计与生成内容的一致性担保。
上方的横条是 KUMIRAI 的共同作业方式，下方是这套方式在各工序中的具体顺序。
测试方针环节始终由人主导 —— 业务理解、客户沟通与品质承诺不交给 AI；其余五个环节按同一模式运转：AI 批量产出 → AI 自检过滤机械问题 → 人工闸门确认放行，未放行的不流入下一环节。
后端（JUnit 5）、前端单元测试、前端 E2E（Playwright）三条链都按这一模式运行；最后由 review-gate 统一把关，核对用例数与测试代码数，确认障害已修复、指摘已对应完毕。
生成再多，人工确认也不随之膨胀的开发方式
机器能判的问题挡在人工确认之前，公共工程能力沉到统一的工程基础，任务、版本与证据维持同一条关联链；人的时间只花在机器判不了的事情上。
人工确认点只有生成前与生成后两处，中间三段由 AI 与工具承担，并设有三道机器关卡：计划预检（跨文档检查与机器检查项）、编译与服务启动通过为止的机械检证 LOOP、按七个维度对照设计与代码的一致性确认初筛。任何一道未通过，都只对相应部分重新生成，不进入人工确认。
因此人只需判断两件事：计划是否符合预期，指摘是否采纳。AI 的产出量再大，验证负担也不会随之膨胀。
分层基类、认证授权（JWT、RBAC）、缓存与幂等、流控、数据访问、文件存储等通用工程能力，沉到 CORE 这一统一的工程基础，由业务工程按需装配；ApiResponse、错误码目录与 Trace ID 构成统一的技术契约。自动配置负责接入，SPI 保留替换空间。在此之上，BUILD 提供 Spring Boot 以及 Angular、React、Vue 的项目样板。
AI 参考样板的分层、依赖边界与测试结构扩展业务代码，公共能力留在 CORE，业务规则保留在领域工程；每个项目要写的只剩业务规则，基础能力的建设周期随之缩短，各项目的生成物也保持同一写法。
FLOW 为每一件任务写明输入依据、修改范围、责任人与完成条件；BUILD 按模板和规则作成设计、代码与测试，成果物及其版本保存在文档库或 Git 仓库；FLOW 再把 Review 的指摘、修正要求、复验结果与最终确认关联到同一任务上。
接手的人不必重新追查全部背景，就能看清任务停在哪里、下一步由谁处理；只有经项目验证、人工 Review 并允许复用的规则与方法，才会进入交付经验库，更新到模板与检查规则中。
适用场景与各自的最大价值点
同一方法在各层的收益来源不同；建议从削减最大的 Service 层与 DAO 层切入。
输入是否结构化、输出是否可机器验证、出错是否可逆、是否需要有人担责 —— 任一项为「否」，介入等级就降低一级；若稳定的输入必然产出稳定的输出，则无需 AI，以脚本处理成本更低、稳定性更高。
介入等级分为四级：由契约完整实现 CRUD 接口、由 DDL 生成 Repository／Mapper 层之类的作业由 AI 主导；复杂业务逻辑由 AI 产出七到八成的初稿，再由人补充业务判断并决裁；核心算法、涉及资金、权限与审计的关键路径以及与遗留系统的对接，由人主导、AI 辅助。生成前的计划确认与代码合入主干的批准属于 AI 禁区，无论精度如何均不委托。
生成前的计划确认与代码合入主干的批准由人实施：AI 产出一律按草稿处理，不提供省略这两处的设置。
编码实现工序不实施任何测试 —— 品质由设计与生成内容的一致性担保，单元测试的用例与测试代码在下一道工序中生成。
编码实现工序的导入阶段与判定基准以新规开发为前提；既有系统的维护与改修虽设有调查与影响分析的入口，但不适用本页的阶段与基准。
FLOW 当前为管理工作台 Demo，后台持久化、权限执行、自动采集以及与 CI/CD 结果的关联仍需验证。
工具运行在客户环境，不代表模型服务一定在客户内网；可以发送的代码、文档与提示词，以及模型服务的位置、数据留存与访问权限，在进入真实任务验证之前确定。
已经具备的能力与导入路径
下面逐项对照：已经具备的能力与它的意义，以及四个导入阶段各自的出口判据。
已经具备的能力 → 它的意义
| 已经具备的能力 | 它的意义 |
|---|---|
| 生成前后两处的人工确认点 | 人的时间集中在机器判不了的判断上 |
| 机械检证的自动 LOOP | 编译或启动就会失败的问题，不进入人工确认 |
| 七个维度的一致性确认初筛 | 与设计不符的实现，在测试之前就被发现 |
| 工程基础（CORE）与项目样板（BUILD） | 基础能力的建设周期缩短，生成物的写法保持一致 |
| 任务、版本与证据的关联（FLOW） | 换人后，仍能沿同一版本和确认记录继续推进 |
| 执行计划模板、规约、Golden Code 与教训库 | 经项目验证的方法，才成为下一个项目的规则 |
本中心整理的平台功能规格（提案资料，截至 2026 年 9 月）。FLOW 当前为管理工作台 Demo。
导入路径：四个阶段与出口判据
| 阶段 | 实施内容 | 出口判据 |
|---|---|---|
| L0 人工作业（导入前） | 整理编码规约、Golden Code、执行计划模板与上下文资产 | 上游资料达到 AI 可用的状态 |
| L1 AI 辅助（1〜2 个月） | AI 提示代码方案，由人判断、修正；整理审查基准 | 采用率达标、团队具备运用能力 （代码采用率 ≥35%、审查退回率 ≤65%、机械检证一次通过率 ≥50%） |
| L2 AI 主导（L1 后 3〜6 个月） | AI 主导从生成、机械检证到一致性确认初筛的全过程 | 退回率稳定、质量基线不劣化 （代码采用率 ≥55%、审查退回率 ≤50%、机械检证一次通过率 ≥80%） |
| L3 CI/CD（L2 后 1 年以上） | 设计变更 → 计划 → 生成 → 机械检证 → 一致性确认全自动 | 需同时调整合同与责任体制 |
提案资料中的设计值（截至 2026 年 9 月）。周期为业界口径的参考值，依试点实绩调整；采用率低于基准时重新整理规约与 Golden Code，退回率超过基准时中止范围扩大、优先整理资产。工时削减率是基于业界公开数据的推算，未经实测，因此不在此列出。
NEXT
咨询请联络相关负责人。
只要指定一个对象，我们就会展示对应的成果物及验证报告。
可以直接查看实际系统的输出，判断这套方式是否有效。
只需告知选定哪一个对象，即可开始。