从需求开始做
还没有系统，或者要重做。把需求资料投进去，就会从需求定义书开始依次搭起来。
- 01投入需求资料（会议纪要・报表・Excel）
- 02确定模块的切分
- 03从需求定义进入 7 道工程
从需求定义到运维，日式的全流程由 AI 来跑。
人只做三件事——提出课题、盖检查印、验收。设计书、测试成绩书、报告都由机器写，人来批准。相对交付物目录，缺失为 0 件。
- 7道工程从需求定义到运维。不省略。
- 100件标准的型所规定的交付物。缺失 0 件。
- 3件事人做的操作——提出・盖印・验收。
01
入口有两个，出口只有一个
无论有没有既有资产，进来之后走的都是同样的 7 道工程。不是省略工程，而是让机器执行工程——所以交付物的形态和以前一样。
从既有资产反推
系统还在跑，但没有规格书，写的人也不在了。读解源码，先把当初没有的设计书做出来。
- 01接入源码（Git / zip）
- 02由人确认并敲定 AI 的切分方案
- 03从需求定义进入 7 道工程（同一条路）
02
七道工程
工程不折叠。每道工程里，机器出什么、人盖什么，都是定好的。没盖印，下一道工程不会开始。
No.工程这道工程做什么机器出什么人盖什么
01需求定义把业务的诉求与现行约束对上，用文字确定要做什么。含糊不清就不往前走。机器出什么需求定义书、业务流程、术语表等人盖什么检查印
02基本设计定下画面、报表、数据库、外部对接的骨架。这里定下的形态，是之后一切的基准。机器出什么画面设计、报表设计、数据库设计、接口设计等人盖什么检查印
03详细设计按章节把处理写完整。以既有代码为依据，推测出来的地方明确标注「未确认」。机器出什么分章详细设计书、处理规格、依据行清单人盖什么逐章盖检查印
04实现照设计书写。单体测试代码同时产出，所以设计与实现不会走偏。机器出什么源码、单体测试代码、实现备忘人盖什么检查印
05测试单体、集成、总合、验收 4 段。故障单会逆向链接到造成原因的那道设计工程。机器出什么测试计划、测试规格、成绩书、故障管理票人盖什么逐段盖检查印
06迁移・发布做出迁移手顺与回退手顺，投放到生产。只有这里需要两个人批准。机器出什么迁移计划、发布手顺、回退手顺人盖什么双印（PM ＋ 运维）
07运维监控运行，处理故障与改修。每一件维护也作为课题提出，由对应单（针对一个课题的一次执行）走同样的 7 道工程。机器出什么运维手顺、月度报告、故障报告、变更管理票人盖什么检查印
只有测试分成 4 段——单体、集成、总合、验收。故障单各自逆向链接到造成原因的那道设计工程，于是哪一处设计的错误在哪一级测试暴露，事后可以追溯。
03
交付物目录
標準納品規程 v3交付什么由「型」决定。目录可以换成贵司的规程——章节结构和版式都是型的属性，所以能按贵司格式直接出。
No.工程明细件数
01需求定义需求定义书、业务流程、术语表、非功能需求等8件
02基本设计画面・报表・数据库・接口・批处理设计等14件
03详细设计分章详细设计书、处理规格、依据行清单等12件
04实现源码一式、单体测试代码、实现备忘等6件
05测试四段的计划・规格・成绩书、故障管理票等20件
06迁移・发布迁移计划、发布手顺、回退手顺等9件
07运维运维设计・手顺书、监控设计・故障流程、维护交接书、月度报告・故障报告・变更管理票等7件
＋横断WBS、进度报告、会议纪要、验收书等24件
合计100件
目录按贵司的规程来
章节结构和版式（页边距・字体・盖印栏）都是型的属性。把贵司格式的 Word / Excel 交给我们，就能按那个形态出。
缺失不会被藏起来
型所要求的文档没齐，验收画面上会以红色标出。这个结构做不到「就当它齐了」。
报告不用人写
进度报告与月度报告都由检查印的历史自动生成。任何地方都没有让人录入数字的栏位。
04
干活的地方
登录后的画面共有六个。每个画面都会先列出待人处理——等待人裁定与批准的事项。
课题
待人处理（等待裁定・批准的事项）排在最前的列表。在这里提出课题，在详情里开始处理，回答裁定与批准。
对应单
针对一个课题的一次执行。从受理判定到批准・收尾按 V 字工程推进，留下每道工程的成果物、审查记录与 PR。
值守智能体
查看在 VDI 线路上跑实机测试的 operator，以及从经验中提出改进的 evolution 的运行，并启动・停止它们。
项目
按项目设置仓库、文档与 VDI 线路。
系统
汇总 LLM 网关、执行上限、项目类型等对所有项目生效的设置。
个人中心
设置显示语言、外观与动效，管理自己的会话。切换到中文界面也能批准日文成果物。