A01 2026-06-07 开发流程验证门顺序

A01 正式版开发流程与开发顺序

定义 A01 每个阶段的执行顺序、工作流和验证门。

A01 正式版开发流程与开发顺序

状态：正式开发基线
日期：2026-06-07
用途：定义 A01 每个阶段的执行顺序、工作流和验证门。

1. 开发策略总则

正式开发遵守以下原则：

不直接从愿景跳到 Demo。
不把完整邪异系统压进一个阶段。
不让 HostRoom 阻塞单机 Demo。
不让 UI 直接修改 gameplay 真值。
不让 AI 生成带可读正文的 UI 图片。
不让存档、验证和 placeholder 清单最后补。

每个正式 change 的默认流程：

1. 明确 change 目标和边界。
2. 明确涉及模块和依赖。
3. 明确配置 / snapshot / save / validation。
4. 实现最小正式链路。
5. 跑对应验证。
6. 更新任务、模块文档和 placeholder 清单。
7. 必要时同步 OpenSpec。

2. 双轨开发模型

A01 后续开发必须按双轨推进：

轨道	职责	不做
系统功能轨	物品、行动、采集、背包、生存、邪祟、纸人、怪物、基地、死亡债业	不直接绑定最终美术质量
资源表现轨	UI Kit、HUD、图标、字体、场景 tile、怪物表现、AUD01 音频 cue	不决定 gameplay 真值

两条轨道通过以下接口交汇：

Snapshot
TextKey
AudioCueId
Prefab / Sprite resource key
Placeholder index
Validation evidence

3. 里程碑总览

A01-R0：文档、接口、美术圣经与验收标准重基线
Stage4F：普通生存底座正式化
M1：Stable Running Version
Stage5A-F：邪祟系统分阶段接入
Stage6-9：Demo 前关键系统切片
Stage10：Demo Content Integration & Polish
M2：Demo Ready
Stage11：Post-Demo HostRoom 验证
Stage12：完整版扩展

4. 正式开发顺序

4.1 A01-R0：Contract Freeze

目标：

冻结路线、依赖、验收、UI 美术规范、存档策略、Action / Place / Calendar 标签契约。

必须产出：

A01_Formal_Roadmap.md
A01_Module_Dependency_Map.md
A01_Stable_Running_Acceptance.md
A01_Demo_Acceptance.md
A01_UI_Art_Bible.md
A01_Config_Id_Range.md
A01_Save_Snapshot_Policy.md
A01_Action_Place_Calendar_Tag_Contract.md
A01_Placeholder_Index_Template.md

通过标准：

后续每个模块知道自己依赖谁、输出什么、如何保存、如何验证。

4.2 Stage4F：普通生存底座正式化

推荐顺序：

Stage4F.0 当前基础系统审计与口径修正
Stage4F.1 正式物品与背包后端
Stage4F.2 正式交互与行动命令系统
Stage4F.3 正式采集与资源节点
Stage4F.4 正式掉落、拾取与容器基础
Stage4F.5 植物生命周期 Lite
Stage4F.6 动物 / 野生生物 Lite + DamageableLite
Stage4F.7 正式生存数值与基础经济
Stage4F.8 正式 HUD 与玩家反馈
Stage4F.9 基础制造与基础建造 Lite

顺序原因：

物品 / 背包 / 行动 / 掉落是采集、动物、怪物、纸人、鬼市、基地派工的共同底座。
HUD 放在正式数据源之后验收，避免继续接占位数据。

4.3 M1：Stable Running Version

目标：

得到普通生存稳定运行版，而不是 Demo。

通过标准：

连续 30 分钟本地运行无阻断错误。
新建世界、采集、背包、制造、建造、保存、读取、死亡、重开可重复 3 次。
所有 placeholder 都进入清单。

4.4 Stage5A-F：邪祟系统分阶段接入

顺序：

Stage5A 世界时间与昼夜正式化
Stage5B 阴气、腐化与行动风险
Stage5C 禁忌框架 Lite
Stage5D 黄历 / 节气 / 日期标签 Lite
Stage5E 灵异事件触发 Lite
Stage5F 邪祟 HUD / 音频 / 文案反馈正式化

关键规则：

禁忌框架先做 O03-Core。
Stage5C 只做非日期型禁忌。
破日动土、鬼月夜渡、寒衣禁忌等依赖 CalendarTag 的规则后接 O03-CalendarRules。
Stage5A-E 可用工程占位反馈。
Stage5F 做 UI01-Occult + AUD01 正式反馈收口，不单独新增反馈模块编号。

4.5 Stage6-9：Demo 前关键系统切片

Stage6：基础战斗与怪物压力 Lite
Stage7：纸人 / 灵仆野外价值切片
Stage8：B00 小基地与魂灯 / 基础建筑切片
Stage9：D01-Lite 死亡记录与债业 Lite

目标：

Demo 不是系统堆叠展示，而是最小差异化体验闭环。

4.6 Stage10：Demo Content Integration & Polish

目标：

组合成 30-60 分钟可试玩闭环。

Demo 核心路径：

醒来
查看基础日课 / 风险提示
采集资源
背包与制造
建立小基地
经历夜晚风险
触发一个禁忌或灵异事件
遭遇少量怪物
获得一只纸人
用纸人协助采集或避险
死亡或回家修整

4.7 M2：Demo Ready

通过标准：

30-60 分钟可试玩闭环。
无阻断错误。
新手能理解采集、制造、建造、日课、禁忌、纸人的基础价值。
保存 / 读取可用。
Demo 内容可重玩。
美术与音频占位均有替换清单。
性能达到当前目标平台最低线。

4.8 Stage11：Post-Demo HostRoom 验证

目标：

Demo 稳定后，验证同一套业务流能否复用到 LocalHostRoom。

HostRoom 不阻塞单机 Demo。

4.9 Stage12：完整版内容扩展

范围：

二十四节气
完整禁忌库
完整怪物生态和 Boss
纸人多样化
基地任务板和防守
死亡债业循环
鬼市经济
NPC 阵营和祖灵
HostRoom 完整化
美术音频全面替换
性能和移动端适配

5. 每个阶段的固定开发流程

每个正式阶段必须包含：

1. OpenSpec change 或明确已有 active change。
2. 范围和非目标。
3. 模块依赖清单。
4. 数据结构 / 配置 / snapshot / save 策略。
5. UI 是否只读消费 snapshot。
6. placeholder 清单。
7. 自动验证或手动验证路径。
8. 阶段完成后的模块文档同步。

6. 阶段验收门禁

类型	验收要求
文档 / OpenSpec	`npm run spec:validate`
Runtime 代码	编译、Console 检查、相关 Harness
Unity asset	Unity import / Console / missing script / asset visibility
UI	snapshot 绑定、可打开关闭、文本 TMP、Safe Area、交互验证
生存系统	新建世界、采集、背包、制造、保存读取、死亡重开
邪祟系统	时间、阴气、禁忌、事件、HUD、AUD01 音频 cue、save/load
Demo	30-60 分钟流程、无阻断错误、placeholder 清单

7. 立即推荐开发入口

下一步最小正式入口：

wildlands-stage4f-core-survival-audit-and-rebaseline

原因：

在继续扩展邪祟、纸人、怪物、基地或 Demo 内容之前，必须先确认当前 Stage4 / Stage5 中哪些是正式系统，哪些仍是占位或验证壳。