docs(design): 交互系统执行案与项目文档整理

- 新增交互系统执行案 (P-002a)，含层级状态模型、行为规则、边界情况
- 新增概念草案 concept.md、头脑风暴记录
- 新增 Agent 配置 (策划/PM/程序) 及角色记忆
- 新增 P-002 质量门审查报告、任务汇报、工作日志
- 更新路线图、current.md 等项目计划文档

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/design/concept.md

@@ -0,0 +1,175 @@
+# 概念稿 — ChildHood（我的童年）
+
+> 本文档定义游戏的核心概念。进入原型阶段后冻结，不再修改。
+> 最后更新：2026-06-04
+
+---
+
+## 1. 一句话描述
+
+一个关于千禧年前后城郊小男孩的暑假——在老街小卖部门口弹弹珠、攒零花钱买四驱车配件、帮要搬走的死党准备送别礼物，在蝉鸣和街边喇叭声里度过一个再也回不去的夏天。
+
+---
+
+## 2. 玩家核心游玩内容与感受
+
+### 核心操作与活动
+
+- **自由探索**：在一条千禧年城郊小街上漫步，翻翻冰箱、看看小卖部、捡起地上的弹珠，每个角落都有故事
+- **小游戏互动**：弹珠、拍洋画、四驱车、FC 家用机、街机——那个年代的真实童年玩法
+- **收集系统**：弹珠、水浒卡、糖纸、随身听……帮玩家补全当年没集齐的、找回已丢失的
+
+### 情感基调
+
+**开心、无忧无虑。** 游戏还原的是快乐的童年——阳光灿烂的下午、和伙伴满街跑的日子、第一次集齐一整套卡片的兴奋。伤感不是游戏主动营造的，而是经历过那个时代的玩家自带的情感反应。游戏只负责把快乐还原得足够真，让伤感成为玩家的自然产物。
+
+### 视觉风格
+
+3D Lowpoly，温暖色调，怀旧氛围。
+
+### 整体感受
+
+"这不就是我小时候吗"——被某个物件、场景或声音击中的共鸣瞬间，和"终于集齐了"的圆满满足感。
+
+---
+
+## 3. 核心受众画像
+
+### 主要受众
+
+**千禧年前后（1985-1995）在中国城郊或小城镇长大的 80 后、90 后玩家。**
+
+- 现年约 31-41 岁，有独立游戏消费能力
+- 童年记忆中包含弹珠、四驱车、水浒卡、小霸王等真实经历
+- 对"那个年代的夏天"有强烈的情感共鸣
+
+### 为什么会喜欢
+
+- **时代共鸣**：街景、物件、声音精准还原千禧年风貌，一眼认出自己的童年
+- **补全遗憾**：收集系统帮玩家找回当年没集齐的、已丢失的童年物品，获得"圆满"
+- **放松治愈**：没有战斗、没有失败惩罚、没有"坏结局"，纯粹的童年快乐
+
+### 次要受众
+
+- 对千禧年中国市井文化感兴趣的海外玩家及年轻玩家
+- 喜欢生活模拟 / 探索 / 治愈类游戏的玩家
+
+---
+
+## 4. 游戏核心循环
+
+### 日常循环（以"天"为单位）
+
+```
+起床 → 自由探索与交互 → 推进目标（小游戏/收集/事件）→ 入睡 → 下一天
+         ↑                                    |
+         └────────────────────────────────────┘
+```
+
+每天四时段（上午 / 下午 / 傍晚 / 夜晚），时间基本自由掌控。某些活动有时段限制（小卖部下午才开、晚上在家看电视），但时间流逝是温柔的推动力，不催促。
+
+### 暑假大循环
+
+```
+日常循环 × ~50 天 + 关键生活事件节点 → 阶段目标推进 → 暑假结束（开学）
+```
+
+- 3-4 个关键生活事件把暑假切成阶段（如：放假的兴奋 → 有人要搬走 → 去奶奶家 → 开学倒计时）
+- 事件以情感为动机，链式串联小游戏、收集、探索
+- 暑假中期插入"去奶奶家住 1-2 周"的乡下章节，换节奏、补足乡村视角
+
+### 三大支柱如何支撑循环
+
+| 支柱 | 在循环中的角色 |
+|------|--------------|
+| **小游戏互动** | 核心玩法活动，赢取道具/收集品/零花钱，提供"好玩" |
+| **收集系统** | 持续目标感和情感锚点，驱使探索和交互 |
+| **剧情叙事** | 大时间线推进力，给暑假赋予方向感和意义 |
+
+---
+
+## 5. 游戏元素
+
+### 世界观
+
+**千禧年前后，中国城市边缘的城郊结合区。**
+
+一条小商业街 + 周边区域，紧凑精致，城乡结合的独特氛围。
+
+**城市主场景**：商业街为主线（小卖部、游戏厅、录像厅、文具店），两端延伸到巷子、空地、河边、学校操场、工地。可进入室内：主角家 + 4 家店铺。
+
+**乡下场景**（奶奶家）：暑假中期切换，紧凑型独立区域（院子、小溪、田间、村口小卖部），持续 1-2 周。
+
+### 主角
+
+约 10-12 岁男孩，小学四五年级，住商业街旁边巷子里的老房子。玩家的"眼睛"——不直接说话，通过行动和内心独白表达。形象追求"这就是我 / 我认识的孩子"的代入感。
+
+### 核心角色（6-7 人）
+
+| 角色 | 定位 |
+|------|------|
+| 死党 A（家境好的） | 家庭对比、物质羡慕，可能是搬走的那个人 |
+| 死党 B（家境差的） | 同理心，送别礼物事件的潜在主角 |
+| 女班长 | 性别动态、独特互动线 |
+| 转学生 | 外来者视角 |
+| 残障儿童（智商较低） | 真实存在的关系，不猎奇 |
+| 小卖部 / 游戏厅老板的儿子 | 资源节点、信息和物资中心 |
+| 小霸王 | 对手角色，不是纯坏人 |
+
+### 关键物品
+
+- **弹珠**：既是小游戏道具又是收集品（道具-收集品一体化）
+- **水浒卡 / 四驱车**：带收集属性的玩具，有套装概念
+- **糖纸 / 车票**：纯情感价值的收集品
+- **随身听 / 小霸王卡带**：承载时代记忆的特色物品
+
+### 时代元素（四层还原）
+
+| 层次 | 内容 | 作用 |
+|------|------|------|
+| 广告 / 招牌 | 娃哈哈、健力宝、小霸王 | 第一眼的时代标识 |
+| 交通工具 | 桑塔纳、面的、自行车大军 | 街景氛围 |
+| 街边饮食 | 冰棍推车、辣条、糖葫芦 | 与零花钱系统联动 |
+| 声音 / 音乐 | 随身听、磁带、街边喇叭、电视节目声 | 沉浸感核心层 |
+
+---
+
+## 6. 市场定位与三大卖点
+
+### 市场定位
+
+- **品类**：生活模拟 / 怀旧探索 / 叙事冒险
+- **平台**：PC（Steam）
+- **价位**：独立游戏价位
+
+### 三大卖点
+
+1. **千禧年时代精确还原**：不是泛泛的"复古"，而是精确到娃哈哈广告牌、桑塔纳街景、街边喇叭声的千禧年城郊生活还原。时代细节是底色，第一眼就认出来。
+
+2. **那个年代的真实玩法**：弹珠的四维策略系统（规则×场地×属性×手法）、四驱车的改装调试、FC 家用机里的完整小游戏——不是象征性的点缀，是真的能玩上十几小时的童年游戏还原。
+
+3. **补全你的童年遗憾**：收集系统不只是"集满"，而是帮你找回当年没集齐的水浒卡、已丢失的弹珠、再也找不到的那张贴纸。情感核心是"圆满"，集齐后世界会给回应（NPC 讨论、称号、支线剧情）。
+
+### 独特定位
+
+不是"中国版《放学后少年》"。时代细节是底色、小游戏是"玩"、收集系统是情感锚点，三者合一构成独一无二的体验。
+
+---
+
+## 7. 参考
+
+### 《放学后少年》（NDS）
+
+- **取**：放学后的自由探索感——地图上随处可去的开放感；小游戏的多样性；校园/街区的生活气息
+- **不照搬**：日式校园文化（我们是城郊小街）；过于碎片化的活动列表（我们需要更强的叙事线串联）
+
+### 《我的暑假》系列（PS）
+
+- **取**：日常的诗意——普通的一天也可以很动人；时间流逝感——从早到晚的光影变化；叙事节奏——日常中的小事件串联
+- **不照搬**：日本乡村文化（我们是中国城郊）；昆虫采集为核心玩法（我们的收集更广泛、更贴合城郊生活）
+
+### 我们的独特味道
+
+- **时代细节**是底色——街景、人物、物件，呈现千禧年风貌
+- **小游戏**是"玩"——童年最深刻的记忆就是玩
+- **收集系统**是情感锚点——帮玩家补全当年没集齐的、找回已丢失的

docs/design/prototype/brainstorm-2026-06-04-era-tech-inspirations.md

@@ -0,0 +1,230 @@
+# 头脑风暴：千禧年前后科技与生活元素灵感
+
+> 日期：2026-06-04
+> 性质：素材收集，作为未来版本的备用开发内容
+> 参与者：starmen1265、策划 Agent
+
+---
+
+## 讨论目标
+
+收集 2000 年前后城郊结合区的科技、通讯、电子产品等时代元素，作为游戏世界观填充和未来版本的内容储备。不急于决定如何游戏化，重点是捕捉记忆中的画面和细节。
+
+---
+
+## 一、通讯设备
+
+### 1.1 大哥大 → 功能机过渡期
+- 大哥大（砖头手机）正在没落
+- 黑白屏数字功能机开始兴起（如诺基亚类机型）
+- BP机（寻呼机）也在走下坡路
+
+### 1.2 电话座机
+- **按键式**和**转盘式**座机都用过（两种并存）
+- 子母机/无绳电话在当时较少见
+- 座机是家庭主要通讯工具
+
+> **游戏化灵感**：座机可作为可交互物品——接电话、打电话给NPC？BP机响了要找座机回拨的场景？
+
+---
+
+## 二、电视机
+
+### 2.1 品牌与档次
+- **高端**：日立（Hitachi）——进口品牌，代表"有钱人家"
+- **中端**：熊猫——国产经典品牌，很多家庭的选择
+- **即将流行**：TCL、长虹——液晶显示器即将取代 CRT
+
+### 2.2 搜台体验
+- **无信号**：纯雪花屏，发出"呲呲"的白噪声
+- **信号弱**：一半雪花+不太清晰的画面和声音，画面有滚动条纹干扰
+- **手动调天线**：信号不好时要站起来手动调整天线方向
+- **串台奇遇**：有时候能串台串到别人家打 FC 游戏！但画面一般不太清楚
+
+### 2.3 功能
+- 电视机有**自动搜台**和**手动搜台**两种模式
+- 爷爷奶奶家用的是**带天线**的彩电
+
+> **游戏化灵感**：搜台可以作为交互玩法——转动旋钮/按按钮跳台，经过不同频道看到不同画面（动画片、新闻、雪花）。串台发现别人在打 FC 游戏可以作为彩蛋事件。
+
+---
+
+## 三、电脑与上网
+
+### 3.1 拨号上网（ADSL猫）
+- 需要主动拨号连接
+- 拨号时发出**"嘀嘀嘀嘀"**的标志性声音
+- **与电话共用线路**：上网时电话占线，打不进来
+
+### 3.2 电脑硬件
+- **软盘**仍在使用
+- 已有**光驱和光盘**
+- **15寸 CRT 显示器**
+
+### 3.3 早期互联网
+- **西祠胡同**（BBS 论坛）
+- **新浪聊天室**
+- **QQ** 开始兴起
+- **MUD**（文字冒险游戏）流行
+
+> **游戏化灵感**：拨号上网的声音和等待过程可以做成体验式交互——听到"嘀嘀嘀"后等待连接，期间电话打不进来（可能错过重要电话事件？）。电脑可以浏览简化版的西祠胡同/聊天室。
+
+---
+
+## 四、盗版光盘文化
+
+### 4.1 珠江路买碟经历
+- **珠江路**（南京电子一条街）路边很多人偷偷卖盗版碟片
+- 走过路过就会问"要不要碟？"
+- 你要的话，他就带你**走街串巷**，进到一户人家
+- 拿出几个**敞口大箱子**，里面都是**纸壳包装的盗版光碟**
+
+### 4.2 价格与质量
+- **3-5 元一张**
+- 质量堪忧：**三张就有一张读不出来**，或者装不上游戏
+- 即使装上了，可能**玩到某个地方就报错**
+
+> **游戏化灵感**：这整段经历本身就是一个完整的游戏事件——路边被叫住→跟着走街串巷（可以做成路径探索）→翻箱子挑碟→花钱买碟→回家试碟（随机结果：正常/读不出/装上但中途报错）。天然带有随机性和探索乐趣。价格 3-5 元也符合游戏中零花钱系统的设计。
+
+---
+
+## 五、街机厅
+
+### 5.1 省币策略
+- 小孩经常**站在后面看别人玩**，因为这样省币（也叫**牌子**）
+- 围观本身也是一种社交——看高手打、学习连招
+
+### 5.2 跟老板儿子搞好关系
+- 街机厅老板有儿子，跟老板儿子关系好的话
+- 他会直接从机台底下**取出收币的篮子**，里面装了很多币
+- **免费玩**！小孩子之间的人情世故
+
+> **游戏化灵感**：可以做成社交关系系统——和老板儿子的好感度达到一定程度后解锁"免费街机"福利。围观别人打街机也可以作为观察/学习的小玩法。
+
+---
+
+## 六、磁带与收音机
+
+### 6.1 磁带
+- 磁带相对**比较贵**，一般拿来**收藏**，不瞎折腾
+- 不像现在可以随便单曲循环，听磁带是有仪式感的
+
+### 6.2 收音机（日常陪伴）
+- 日常生活中更多是**听收音机**
+- 有时候晚上会**开着收音机睡觉**，听睡着了
+- 第二天收音机**电池没电了**
+- 深夜经常有**谈话节目**，情感夜话类
+- 主持人声音比较**磁性、温柔**，很容易听睡着
+
+### 6.3 南京本地电台（千禧年时代标志）
+- **FM104.3** —— 有一档节目叫**《子夜聊斋》**，聊鬼故事的！
+- **FM105.8** —— 南京音乐台，每半个小时就会播报一次台标：
+  > *"南京 Music Radio，调频 105.8；南京 Music Radio，调频 105.8，南京音乐台！"*
+
+> **游戏化灵感**：收音机可以作为房间里的可交互物品——不同时段调到不同频率听到不同内容（白天音乐、晚上鬼故事/夜话）。FM104.3鬼故事可以做成深夜胆量挑战事件。电池消耗机制：忘记关收音机→电池耗尽→要去买新电池。南京本地电台的具体频率和台标词增强地域真实感。
+
+---
+
+## 七、小卖部与电子玩具
+
+### 7.1 电子宠物（拓麻歌子）
+- 电子宠物属于**比较稀缺**的玩具
+- **不好借到**，因为借给别人容易把电子小鸡**养死**
+- 小孩子之间有"借了就要负责养好"的隐性契约
+
+> **游戏化灵感**：电子宠物可以作为稀有收集品/社交道具——拥有它是一种"地位象征"，借给别人有风险。养死的后果可以做成有趣的叙事事件。
+
+---
+
+## 八、电子词典（文曲星）
+
+### 8.1 隐藏游戏
+- 文曲星里有隐藏游戏**《英雄传说》**
+- 有个经典的"骚操作"：可以**找根绳子把自己吊死**来重开游戏
+- 名义上在学习，实际上在偷偷玩游戏
+
+> **游戏化灵感**：文曲星可以作为道具——表面是学习工具，实际有隐藏小游戏。可以做成"在家长面前假装学习，实际在玩游戏"的紧张感玩法。
+
+---
+
+## 九、学校电脑课（已跳过）
+
+- 机房在当时属于**贵重资产**，进去都要**套鞋套**
+- 一般情况进不去，不适合拿来作为暑假元素
+- **结论：不纳入游戏暑假场景**
+
+---
+
+## 十、小学生搞钱方式（除日常零花钱外）
+
+> 2026-06-05 补充讨论
+
+### 10.1 捡废品卖钱
+- 可收集的废品种类：
+  - **易拉罐**
+  - **啤酒瓶**
+  - **旧报纸**
+  - **废铁丝**
+  - **牙膏皮**（挤完的铝制牙膏管，专门攒了卖）
+- 攒一攒拿到**废品站**换钱
+- 收入大概：攒一波能卖 **5-8 元**（对小孩子的购买力来说相当可观）
+
+> **游戏化灵感**：可以作为探索+收集+经济的复合玩法——在场景中散落可拾取的废品，攒够一定数量去废品站卖。牙膏皮这种冷门废品可以作为"隐藏收集品"。价格可以设计为每次随机波动（模拟废品行情），增加重玩性。5-8元的收入正好够买一张盗版碟或几次街机。
+
+### 10.2 帮爸妈有偿做家务
+- 家务活可以换零花钱
+- 千禧年家长的常见做法：洗碗、扫地、擦桌子等明码标价
+
+> **游戏化灵感**：可以作为每日/每周重复任务——接受家务委托→完成后获得零花钱。不同家务难度不同、报酬不同。可以设计为"主动找爸妈要活干"的交互。
+
+### 10.3 代写作业
+- 小学生之间的"地下经济"
+- 帮同学代写作业换零花钱
+
+> **游戏化灵感**：可以作为社交系统的一环——NPC同学找你代写作业，接受后消耗时间获得报酬，但有"被老师发现"的风险事件。也可以反过来，花钱请别人代写（省时间但有风险）。
+
+---
+
+## 已完成 & 待展开
+
+### ✅ 已完成
+- [x] 通讯设备（大哥大、功能机、BP机、座机）
+- [x] 电视机（品牌、搜台、串台）
+- [x] 电脑与上网（ADSL拨号、软盘/光驱、早期互联网）
+- [x] 盗版光盘文化（珠江路买碟）
+- [x] 街机厅（省币围观、老板儿子）
+- [x] 磁带与收音机（收藏、夜话电台、南京本地频率）
+- [x] 小卖部与电子玩具（电子宠物）
+- [x] 电子词典（文曲星隐藏游戏）
+- [x] 学校电脑课（已跳过，不适合暑假场景）
+- [x] 小学生搞钱方式（捡废品、有偿家务、代写作业）
+
+---
+
+## 十一、不需要玩具的户外游戏
+
+> 2026-06-05 补充记录
+
+千禧年前后小孩子聚在一起就能玩的游戏，零成本、纯社交：
+
+| 游戏 | 简述 |
+|------|------|
+| **丢沙包** | 两人投掷沙包，中间的人躲闪，被砸中就出局 |
+| **老鹰捉小鸡 / 警察抓小偷** | 一人当老鹰/警察抓，一人当母鸡/队长保护，后面拖一串"小鸡" |
+| **木头人** | "一二三木头人！"——口令停就要定住不动，动了就被抓 |
+| **斗鸡** | 抬起一条腿，单腿蹦着互相撞，谁先放下脚或倒下就输 |
+| **躲猫猫** | 经典捉迷藏，找地方藏起来 |
+| **翻花绳** | 用一根绳子在手指间翻出各种花样，两人交替翻 |
+| **石头剪刀布** | 万能决策工具，也是游戏本身（猜拳赌东西、决定先后手） |
+
+> **游戏化灵感**：这些都可以作为和NPC小孩互动的触发方式——走到操场上或巷子里遇到一群小孩在玩，加入进去。不同游戏对应不同的迷你玩法（反应力、策略、运气）。也是建立NPC友谊的手段——"一起玩过"提升好感度。
+
+### ✅ 已完成（续）
+- [x] 不需要玩具的户外游戏（丢沙包、老鹰捉小鸡、木头人、斗鸡、躲猫猫、翻花绳、石头剪刀布）
+
+### 🔮 待展开（未来灵感补充）
+- [ ] 小卖部的更多细节（零食、小玩具种类）
+- [ ] 四驱车、悠悠球、陀螺等具体玩具
+- [ ] 街机厅具体有哪些游戏（拳皇？三国战纪？）
+- [ ] 其他南京本地化的生活元素
+- [ ] 小学生花钱的方向（零食、玩具、游戏、文具等消费场景）

docs/design/prototype/interaction-system-execution.md

@@ -0,0 +1,438 @@
+# 交互系统执行案（v0.1 原型）
+
+> 最后更新：2026-06-05
+> 状态：待程序评审
+
+---
+
+## 迭代记录
+
+| 版本 | 日期 | 变更内容 | 作者 |
+|------|------|----------|------|
+| v0.1.0 | 2026-06-05 | 初版执行案，覆盖四类交互的完整行为规则 | 策划 Agent |
+| v0.1.1 | 2026-06-05 | 重构状态模型为层级状态（Free/Interacting/SubSystem/Cutscene），Detecting 降为 Free 检测标记，AnimLock 降为 Interacting 子阶段，新增 postAction 分叉机制 | 策划 Agent |
+
+---
+
+## 系统概述
+
+交互系统让玩家通过接近并按键的方式与环境中的物体、NPC 产生互动。v0.1 原型包含四种交互类型：观察、拾取、操作、对话（简化版）。
+
+### 核心设计决定（已确认）
+
+1. **交互中断行为：输入锁定** — 交互进行中，移动输入被忽略，玩家必须按 E 或 ESC 主动关闭交互后才能恢复自由移动。
+2. **多交互物重叠：自动最近 + 按键切换** — 默认显示最近的交互物提示，按 Tab 或鼠标滚轮切换到范围内下一个可交互物。
+3. **动画期间输入：全程锁定** — 任何交互动画播放期间忽略所有按键输入，动画必须自然播完才接受新输入。
+
+---
+
+## 状态定义
+
+系统采用层级状态模型，顶层状态 4 个，角色同一时刻只能处于其中一个顶层状态。
+
+### 顶层状态
+
+| 状态名 | 说明 |
+|--------|------|
+| Free | 自由状态，可正常移动。内部维护检测标记，当角色在交互物触发范围内时检测标记激活，显示提示 UI |
+| Interacting | 正在进行交互，所有移动输入被忽略。内部分为三个子阶段（见下文） |
+| SubSystem | 子系统状态（v0.1 预留），角色进入小游戏、对话系统等子系统的状态 |
+| Cutscene | 过场动画状态（v0.1 预留），播放不可跳过/可跳过的剧情演出 |
+
+### Interacting 子阶段
+
+Interacting 状态内部分为以下子阶段，按顺序流转：
+
+| 子阶段 | 说明 |
+|--------|------|
+| Enter | 交互进入阶段：角色自动转向、相机推镜等过渡动画 |
+| AnimLock / Active | 动画锁定或活跃阶段：AnimLock 表示动画播放中所有按键输入被忽略；Active 表示等待玩家输入（如文本显示完毕等待按 E/ESC 关闭） |
+| Exit | 交互退出阶段：相机回位、UI 淡出等收尾动画 |
+
+### Free 状态的检测标记
+
+Free 状态内部维护一个「检测标记」（isInDetectionRange），不作为独立状态，而是 Free 状态下的布尔标记：
+
+- 检测标记 = true：角色处于一个或多个交互物的触发范围内，显示提示 UI
+- 检测标记 = false：角色不在任何交互物触发范围内，无提示 UI
+
+---
+
+## 状态转换规则
+
+### 顶层状态转换
+
+```
+Free ──(E 键触发交互)──→ Interacting
+Interacting ──(交互结束)──→ Free     [postAction: return]
+Interacting ──(交互结束)──→ SubSystem [postAction: minigame / dialogue / sceneChange]
+SubSystem ──(子系统退出)──→ Free
+Cutscene ──(演出结束)──→ Free
+```
+
+v0.1 仅实现 Free ↔ Interacting 双向转换。SubSystem 和 Cutscene 在状态模型层面已定义，v0.1 不实现具体行为。
+
+### Free 状态内部的检测标记转换
+
+```
+检测标记 false → true：角色进入任意交互物的触发范围
+检测标记 true → false：角色离开所有交互物的触发范围
+```
+
+检测标记的切换不改变顶层状态（始终为 Free），仅控制提示 UI 的显示/隐藏。
+
+### Interacting 子阶段转换
+
+```
+Enter → AnimLock/Active：进入阶段完成后，根据交互类型进入动画锁定或活跃阶段
+AnimLock → Active：动画自然播完，进入等待玩家输入阶段（如适用）
+AnimLock → Exit：动画自然播完且无需玩家输入（如拾取类），直接进入退出阶段
+Active → Exit：玩家按下 E/ESC 触发关闭
+Exit → Free/SubSystem：退出阶段完成后，根据 postAction 回到 Free 或进入 SubSystem
+```
+
+### 交互结束后的 postAction 分叉
+
+交互结束后根据 postAction 参数决定去向：
+
+| postAction | 目标 | 说明 |
+|------------|------|------|
+| return | Free | 交互结束后直接回到自由状态 |
+| minigame | SubSystem | 交互结束后进入小游戏（v0.1 预留） |
+| dialogue | SubSystem | 交互结束后进入对话系统（v0.1 预留） |
+| sceneChange | SubSystem | 交互结束后触发场景切换（v0.1 预留） |
+
+v0.1 所有交互的 postAction 均为 return。
+
+---
+
+## 行为规则
+
+### 通用规则（所有交互类型共用）
+
+#### 触发条件
+
+- 角色与交互物的距离 ≤ 触发半径（建议值：1.5m，可调，范围 1.0-3.0m）
+- 角色当前处于 Free 状态
+- 交互物未被消耗（oneShot 且已触发过的交互物不再响应）
+
+#### 提示 UI 显示规则
+
+**进入范围时**：
+- 角色进入交互物触发范围 → 该交互物上方浮现提示 UI，淡入时长 0.2 秒（建议值，可调，范围 0.1-0.5 秒）
+- 提示格式：`[E] 动作词 物体名`（例：`[E] 查看旧冰箱`）
+- 提示位置：物体上方的屏幕空间投影
+
+**多个交互物在范围内时**：
+- 仅显示当前选中交互物的提示 UI，其余交互物不显示提示
+- 默认选中距离角色最近的交互物
+- 距离判定点：角色脚底中心到交互物注册点的水平距离
+- 玩家按 Tab 键或鼠标滚轮向下 → 切换到范围内下一个可交互物（按距离从近到远排序，循环切换）
+- 玩家按鼠标滚轮向上 → 切换到范围内上一个可交互物（反向循环）
+- 切换时提示 UI 立即更新为新选中物体的信息，无过渡动画
+
+**离开范围时**：
+- 角色离开某交互物的触发范围 → 若该交互物为当前选中物体，切换为范围内下一个最近的交互物；若范围内无其他交互物，提示 UI 淡出（0.2 秒，可调）
+- 若离开的非当前选中物体，提示 UI 不变
+
+#### 交互触发规则
+
+- 玩家在 Free 状态下（检测标记为 true 时）按 E 键 → 触发当前选中交互物的交互
+- 触发后系统进入 Interacting 状态
+- Interacting 状态下：
+  - 移动输入（WASD、方向键、摇杆）被忽略，角色不移动
+  - Tab 键、鼠标滚轮被忽略，不切换交互物
+  - E 键和 ESC 键的行为取决于具体交互类型（见下文）
+
+#### 交互结束规则
+
+- 交互结束后系统回到 Free 状态（v0.1 所有交互的 postAction 均为 return）
+- 若角色仍在某交互物的触发范围内，回到 Free 状态的同时检测标记激活，立即显示提示 UI
+- 若角色已不在任何交互物触发范围内（交互中角色不移动，仅因 oneShot 交互物被消耗导致范围内无交互物），回到 Free 状态且检测标记为 false
+
+---
+
+### 交互类型一：观察（Examine）
+
+**用途**：查看物品或场景，触发主角的内心独白。
+
+#### 触发条件
+- 通用触发条件满足
+- 交互物类型为 examine
+
+#### 触发后行为（按时间顺序）
+
+| 阶段 | 时间 | 行为 |
+|------|------|------|
+| 1. 转向 | 0 秒 | 角色自动转向交互物（面朝交互物方向），转向时长 0.2 秒（建议值，可调，范围 0.1-0.4 秒） |
+| 2. 推镜 | 0 秒（与转向同时开始） | 相机从当前第三人称位置平滑推向交互物前方约 0.8-1.0m（建议值，可调，范围 0.5-2.0m），高度略低于交互物中心（微仰视），推镜时长 0.5 秒（建议值，可调，范围 0.3-1.0 秒），ease-out 缓动 |
+| 3. 等待 | 推镜结束后 0.2 秒 | 无动作，间隔等待 |
+| 4. 文本显示 | 等待结束后 | 屏幕底部浮现内心独白文本框，半透明黑色背景（透明度 60%，可调，范围 40%-80%），白色文字，打字机效果逐字显示（每字间隔 0.05 秒，可调，范围 0.03-0.08 秒；一个汉字为一个单位） |
+| 5. 用户控制 | 文本全部显示完毕后 | 玩家可按 E 或 ESC 关闭文本框 |
+
+#### 关闭行为
+- 玩家按 E 或 ESC → 文本框淡出（0.2 秒，可调，范围 0.1-0.5 秒）→ 相机从推镜位置回到默认第三人称位置（0.3 秒，可调，范围 0.2-0.5 秒，ease-in 缓动）→ 进入 Exit 子阶段 → 回到 Free 状态
+
+#### 文本显示期间的按键行为
+- 文本仍在打字机效果中（未全部显示）时：E 键和 ESC 键被忽略（Interacting 的 AnimLock 子阶段）
+- 文本全部显示后：E 键和 ESC 键可触发关闭（Interacting 的 Active 子阶段）
+
+#### 可重复交互
+- oneShot 为 false 的观察类交互物可反复交互
+- 每次触发的叙事文本从该交互物的文本列表中随机选取（不重复上一次的内容；若文本列表只有一条则每次显示同一条）
+
+---
+
+### 交互类型二：拾取（Pick Up）
+
+**用途**：收集场景中散落的小物品。
+
+#### 触发条件
+- 通用触发条件满足
+- 交互物类型为 pickup
+- 该交互物未被拾取（oneShot 且已触发过则不再响应）
+
+#### 触发后行为（按时间顺序）
+
+| 阶段 | 时间点 | 行为 |
+|------|--------|------|
+| 1. 转向 | 0 秒 | 角色自动转向交互物方向，转向时长 0.2 秒（建议值，可调，范围 0.1-0.4 秒） |
+| 2. 动画 | 转向完成后 | 角色播放弯腰拾取动画（总时长约 1.0 秒，建议值，可调，范围 0.8-1.5 秒），进入 Interacting 的 AnimLock 子阶段 |
+| 3. 物品消失 | 动画播放至"手触碰物品"时间点（约为动画总时长的 60% 位置，可调，范围 50%-70%） | 交互物从场景中消失 |
+| 4. 提示弹出 | 物品消失后 0.1 秒 | 屏幕右上角弹出物品获得提示（物品图标 + 物品名称），提示显示 1.5 秒（可调，范围 1.0-3.0 秒）后自动淡出 |
+| 5. 计数更新 | 物品消失同时 | 该类型的收集计数 +1 |
+| 6. 自动结束 | 动画自然播完 | 系统回到 Free 状态 |
+
+#### 关闭行为
+- 拾取交互不支持手动关闭，必须等待动画自然播完
+- 动画期间所有按键输入被忽略（Interacting 的 AnimLock 子阶段）
+
+#### 相机行为
+- 拾取全程相机保持当前第三人称位置，不推镜、不移动
+
+#### 一次性消耗
+- 拾取类交互物均为 oneShot，拾取后永久消失
+- 消失后该交互物的触发范围不再生效，角色走过原位置不会触发提示
+
+---
+
+### 交互类型三：操作（Operate）
+
+**用途**：与场景设施或大型物体交互。
+
+v0.1 包含两种操作子类型，行为规则分别定义。
+
+#### 子类型 3A：门（开/关切换）
+
+##### 触发条件
+- 通用触发条件满足
+- 交互物类型为 operate，子类型为 door
+
+##### 触发后行为（按时间顺序）
+
+| 阶段 | 时间点 | 行为 |
+|------|--------|------|
+| 1. 转向 | 0 秒 | 角色自动转向门的方向，转向时长 0.2 秒（建议值，可调，范围 0.1-0.4 秒） |
+| 2. 动画 | 转向完成后 | 角色播放伸手推/拉门动画（总时长约 0.8 秒，可调，范围 0.5-1.2 秒），进入 Interacting 的 AnimLock 子阶段 |
+| 3. 状态切换 | 动画播放至"手触碰门"时间点（约为动画总时长的 40% 位置，可调） | 门的状态切换（关→开，或开→关），门的视觉表现立即更新 |
+| 4. 自动结束 | 动画自然播完 | 系统回到 Free 状态 |
+
+##### 相机行为
+- 门操作全程相机保持当前第三人称位置，不推镜
+
+##### 可重复交互
+- 门可反复操作，每次切换开关状态
+- 提示文字根据当前状态变化：门为关闭状态时显示 `[E] 打开门`，门为打开状态时显示 `[E] 关上门`
+
+#### 子类型 3B：废纸箱（翻找）
+
+##### 触发条件
+- 通用触发条件满足
+- 交互物类型为 operate，子类型为 search
+
+##### 触发后行为（按时间顺序）
+
+| 阶段 | 时间点 | 行为 |
+|------|--------|------|
+| 1. 转向 | 0 秒 | 角色自动转向纸箱方向，转向时长 0.2 秒（建议值，可调） |
+| 2. 推镜 | 0 秒（与转向同时） | 相机推向纸箱前方约 0.6m（建议值，可调，范围 0.4-1.0m），推镜时长 0.5 秒（可调，范围 0.3-1.0 秒），ease-out 缓动 |
+| 3. 动画 | 转向完成后 | 角色播放弯腰翻找动画（总时长约 1.5 秒，可调，范围 1.0-2.0 秒），进入 Interacting 的 AnimLock 子阶段 |
+| 4. 结果显示 | 动画自然播完后 | 屏幕底部弹出翻找结果文本（与观察类文本框样式相同），内容从该纸箱的结果列表中按顺序显示（首次翻找显示第一条，第二次显示第二条，依此类推；列表显示完毕后显示"什么都没有了"） |
+| 5. 用户控制 | 文本全部显示后 | 玩家按 E 或 ESC 关闭文本框 |
+
+##### 关闭行为
+- 文本显示完毕后按 E 或 ESC → 文本淡出（0.2 秒）→ 相机回到默认第三人称位置（0.3 秒）→ 回到 Free 状态
+
+##### 可重复交互
+- 纸箱可反复翻找，直到结果列表显示完毕
+- 结果列表显示完毕后，再次翻找始终显示"什么都没有了"
+- 如果翻找结果中包含拾取品，在该条结果显示的同时执行拾取逻辑（计数 +1、物品获得提示弹出）
+
+---
+
+### 交互类型四：对话（Talk）— v0.1 简化版
+
+**用途**：与场景中的 NPC 交谈。v0.1 为简化实现，NPC 视为"会说话的观察对象"。
+
+#### 触发条件
+- 通用触发条件满足
+- 交互物类型为 talk
+
+#### 触发后行为
+
+与观察类型（Examine）完全一致，唯一区别：叙事文本为场景描述而非内心独白。
+
+- 相机推向 NPC → 底部浮现场景描述文本 → 按 E/ESC 关闭 → 相机回位
+
+#### 可重复交互
+- NPC 可反复交谈
+- 每次触发的场景描述文本从该 NPC 的文本列表中随机选取（不重复上一次；列表只有一条则每次相同）
+
+---
+
+## 边界情况处理
+
+### 快速连续按键
+- 任何交互触发后，在 Interacting 的 AnimLock 子阶段所有按键输入被忽略
+- 交互结束回到 Free 状态后才能再次按 E 触发新交互
+- 不存在"连续按 E 触发多次交互"的可能
+
+### 交互物被消耗后范围残留
+- oneShot 交互物被消耗后，其触发范围立即失效
+- 若消耗后角色附近无其他交互物，系统回到 Free 状态，检测标记置为 false
+- 若消耗后角色附近仍有其他交互物，系统保持在 Free 状态，检测标记保持为 true，自动选中最近的可用交互物
+
+### 推镜期间角色位置
+- 推镜期间移动输入被忽略，角色不移动
+- 推镜完成后角色仍在原位置，相机回到默认第三人称位置时以角色当前位置为基准
+
+### 角色在交互进行中被强制位移（外部因素）
+- v0.1 无物理碰撞推力系统，不存在此情况
+- 若后续版本加入外部位移力（如爆炸、传送），需要额外定义中断规则，v0.1 不处理
+
+### 同一交互物反复进出范围
+- 角色反复进出某交互物的触发范围 → 提示 UI 每次进入时淡入、离开时淡出，无累积副作用
+- 不产生"多次进入导致提示叠加"的问题，因为提示 UI 始终只显示当前选中物体的一条
+
+### 切换交互物时按 E
+- 按 Tab 或滚轮切换选中物体的瞬间，如果玩家恰好同时按 E → 以切换完成后的新选中物体为准
+- 即：先完成切换，再判定 E 键按下时的选中物体
+
+### 交互物距离恰好等于触发半径
+- 距离 ≤ 触发半径 → 在范围内
+- 距离 > 触发半径 → 不在范围内
+- 恰好在边界上视为在范围内
+
+---
+
+## 跨系统交互
+
+### 与角色控制系统的关系
+- 交互进行中（Interacting 状态及其子阶段），角色控制系统接收"交互中"信号，忽略所有移动输入
+- 交互结束后，角色控制系统恢复正常输入响应
+- 角色面朝方向的自动转向由交互系统控制，不由角色控制系统控制
+
+### 与收集系统的关系
+- 拾取类交互触发后，交互系统通知收集系统"物品 ID +1"
+- 收集系统负责维护收集计数和物品获得提示 UI
+- 纸箱翻找结果中包含拾取品时，同样通知收集系统
+
+### 与 UI 系统的关系
+- 交互提示 UI 由交互系统控制显示/隐藏/切换
+- 叙事文本 UI 由交互系统控制显示/内容/关闭
+- 物品获得提示 UI 由收集系统控制（不在交互系统执行案范围内）
+
+---
+
+## v0.1 交互物清单（按实现阶段）
+
+### 第一轮：系统验证（5 个）
+
+覆盖全部 4 种交互类型，验证核心流程。
+
+| # | 物体名 | 交互类型 | 区域 | 验证目标 |
+|---|--------|----------|------|----------|
+| 1 | 旧冰箱 | 观察 | 家 | 室内大件观察，推镜 + 内心独白 |
+| 2 | 家的门 | 操作（门） | 家 | 门开关状态切换 |
+| 3 | 散落的弹珠 | 拾取 | 空地 | 拾取完整流程 |
+| 4 | 公用电话亭 | 观察 | 街道 | 室外独立物体观察 |
+| 5 | 小卖部老板 | 对话（简化） | 小卖部 | NPC 交互 |
+
+**探索路线**：家（冰箱 → 门）→ 街道（电话亭）→ 小卖部（老板）→ 空地（弹珠）
+
+### 第二轮：体验填充（5 个）
+
+验证多交互物并存、不同物体形态的差异。
+
+| # | 物体名 | 交互类型 | 区域 | 补什么体验 |
+|---|--------|----------|------|------------|
+| 6 | 老式电视 | 观察 | 家 | 同区域第二件观察物 |
+| 7 | 零食货架 | 观察 | 小卖部 | 矮物体推镜角度 |
+| 8 | 水浒卡碎片 | 拾取 | 空地 | 第二个拾取品 |
+| 9 | 墙上的涂鸦 | 观察 | 街道 | 墙面类物体 |
+| 10 | 废纸箱 | 操作（翻找） | 巷子 | 第二种操作类型 |
+
+---
+
+## 可调参数汇总
+
+| 参数 | 建议值 | 可调范围 | 说明 |
+|------|--------|----------|------|
+| 触发半径 | 1.5m | 1.0-3.0m | 每个交互物可独立设置 |
+| 提示 UI 淡入时长 | 0.2 秒 | 0.1-0.5 秒 | |
+| 提示 UI 淡出时长 | 0.2 秒 | 0.1-0.5 秒 | |
+| 角色转向时长 | 0.2 秒 | 0.1-0.4 秒 | |
+| 推镜距离（观察类） | 0.8-1.0m | 0.5-2.0m | 根据交互物体型调整 |
+| 推镜距离（翻找类） | 0.6m | 0.4-1.0m | |
+| 推镜时长 | 0.5 秒 | 0.3-1.0 秒 | |
+| 推镜后等待 | 0.2 秒 | 0.1-0.5 秒 | 推镜结束到文本开始显示的间隔 |
+| 相机回位时长 | 0.3 秒 | 0.2-0.5 秒 | |
+| 文本背景透明度 | 60% | 40%-80% | |
+| 打字机每字间隔 | 0.05 秒 | 0.03-0.08 秒 | 一个汉字为一个单位 |
+| 文本淡出时长 | 0.2 秒 | 0.1-0.5 秒 | |
+| 拾取动画总时长 | 1.0 秒 | 0.8-1.5 秒 | |
+| 物品消失时间点（动画进度） | 60% | 50%-70% | 动画播放到此比例时物品消失 |
+| 物品获得提示显示时长 | 1.5 秒 | 1.0-3.0 秒 | |
+| 门操作动画时长 | 0.8 秒 | 0.5-1.2 秒 | |
+| 门状态切换时间点（动画进度） | 40% | 30%-50% | |
+| 翻找动画时长 | 1.5 秒 | 1.0-2.0 秒 | |
+
+---
+
+## 叙事文本示例
+
+### 观察类
+
+**旧冰箱**：
+> 夏天的时候最期待打开冰箱的那一刻。
+> 冰棒、西瓜、偶尔还有一瓶健力宝。
+> 现在想起来，那个冰箱的嗡嗡声好像还在耳边。
+
+**公用电话亭**：
+> 街角的公用电话亭，玻璃上贴满了小广告。
+> 以前打个电话要排半天队，现在好像没人用了。
+
+**老式电视**：
+> 家里的大脑袋电视，拍两下就能出画面。
+> 有时候信号不好，得去转天线。
+
+**零食货架**：
+> 货架上摆满了五毛钱的零食。
+> 辣条、干脆面、还有那种一毛钱两颗的糖。
+
+**墙上的涂鸦**：
+> 不知道是谁画的，但画得还挺像奥特曼的。
+> 我以前也想在墙上画，被我妈追着打了半条街。
+
+### 对话类（简化）
+
+**小卖部老板**：
+> 老板正在柜台后面打瞌睡，电视里放着还珠格格。
+
+### 翻找结果类
+
+**废纸箱**（按顺序显示）：
+1. > 翻了半天，找到了一张皱巴巴的纸条：上面写着"小明是笨蛋"。
+2. > 纸箱底下一堆旧报纸，翻到一张去年的电视报。
+3. > 摸到一个硬硬的东西……是一颗弹珠！（触发拾取：弹珠 +1）
+4. > 什么都没有了。

docs/plans/archive/draft/pre-draft.md

@@ -0,0 +1,149 @@
+# 任务归档 — 草案前工作
+
+> 归档时间：2026-06-04
+> 说明：这些任务在正式阶段流程建立之前完成，现从 current.md 归档。
+
+## 基础设施
+
+### **INF-001** Git 分支策略与提交规范
+
+- **类型**：基础设施
+- **实际产出**：`.claude/refs/GIT-GUIDE.md`、`.claude/refs/GIT-GUIDE-LITE.md`
+- **完成日期**：2026-06-01 前后
+- **备注**：含 UE5 特别注意事项、远程仓库配置
+
+---
+
+### **INF-002** 项目目录结构与协作体系设计
+
+- **类型**：基础设施
+- **实际产出**：项目目录结构、四角色协作体系
+- **完成日期**：2026-06-01 前后
+
+---
+
+### **INF-003** 建立项目基础设施
+
+- **类型**：基础设施
+- **实际产出**：目录结构、规范文档、CLAUDE.md
+- **完成日期**：2026-06-01 前后
+
+---
+
+### **INF-004** 开发流程重构
+
+- **类型**：基础设施
+- **实际产出**：四阶段框架、阶段目录、文档同步规范
+- **完成日期**：2026-06-03
+
+---
+
+## 头脑风暴
+
+### **D-000** Brainstorm 讨论记录
+
+- **类型**：头脑风暴
+- **实际产出**：`docs/design/prototype/brainstorm-2026-06-01-vision-pillars-world.md`
+- **完成日期**：2026-06-01
+- **备注**：阶段 1-5 全部完成（愿景探索、支柱深挖、场景世界观、范围优先级、共识总结）
+
+---
+
+## 设计文档（原型阶段前置产出）
+
+> 以下设计文档在草案阶段 concept.md 未正式产出前即已编写，作为素材保留于 `docs/design/prototype/`。
+
+### **D-PRE-001** 游戏愿景文档
+
+- **实际产出**：`docs/design/prototype/game-vision.md`
+- **完成日期**：2026-06-01 前后
+
+---
+
+### **D-PRE-002** v0.1 范围定义
+
+- **实际产出**：`docs/design/prototype/v01-scope.md`
+- **完成日期**：2026-06-01 前后
+
+---
+
+### **D-PRE-003** 玩家控制设计
+
+- **实际产出**：`docs/design/prototype/player-controller.md`
+- **完成日期**：2026-06-01 前后
+
+---
+
+### **D-PRE-004** 交互系统设计
+
+- **实际产出**：`docs/design/prototype/interaction-system.md`
+- **完成日期**：2026-06-01 前后
+
+---
+
+### **D-PRE-005** v0.1 场景设计
+
+- **实际产出**：`docs/design/prototype/scene-v01-suburban.md`
+- **完成日期**：2026-06-01 前后
+
+---
+
+### **D-PRE-006** 修正项目时代设定
+
+- **实际产出**：更新 `CLAUDE.md` + `docs/art/style-guide.md`
+- **完成日期**：2026-06-01 前后
+
+---
+
+### **D-PRE-007** 收集系统设计
+
+- **实际产出**：`docs/design/prototype/collection-system.md`
+- **完成日期**：2026-06-02 前后
+
+---
+
+### **D-PRE-008** 场景与世界观详细设计
+
+- **实际产出**：`docs/design/prototype/scene-world.md`
+- **完成日期**：2026-06-02 前后
+
+---
+
+### **D-PRE-009** 小游戏系统设计
+
+- **实际产出**：`docs/design/prototype/minigame-system.md`
+- **完成日期**：2026-06-02 前后
+
+---
+
+### **D-PRE-010** 叙事框架设计
+
+- **实际产出**：`docs/design/prototype/narrative-framework.md`
+- **完成日期**：2026-06-02 前后
+
+---
+
+### **D-PRE-011** 主角角色设计
+
+- **实际产出**：`docs/design/prototype/protagonist-character.md`
+- **完成日期**：2026-06-02 前后
+
+---
+
+## 正式草案任务
+
+### **D-001** 玩法概念草案
+
+- **类型**：草案文档
+- **实际产出**：`docs/design/concept.md`（保留在位）
+- **完成日期**：2026-06-04
+- **备注**：7 字段齐全（一句话描述、核心游玩内容与感受、核心受众画像、游戏核心循环、游戏元素、市场定位与三大卖点、参考）。进入原型阶段后冻结，不再修改。
+
+---
+
+### **D-002** 技术可行性评估
+
+- **类型**：草案文档
+- **实际产出**：`docs/technical/feasibility-assessment.md`（保留在位）
+- **完成日期**：2026-06-04
+- **备注**：10 系统逐一评估，总体结论"有条件通过"。包含技术栈推荐、单人开发资源瓶颈分析、原型阶段 v0.1-v0.3 技术路线。

docs/plans/current.md

@@ -1,83 +1,118 @@
 # 当前进度
 
-> 最后更新：2026-06-03
+> 最后更新：2026-06-05
 > 代理完成工作后汇报结果，由开发者确认后才勾选 ✔
 
-## 当前里程碑：v0.1 场景漫游与环境交互
+## 当前阶段
 
-**开发阶段**: 原型阶段
-**阶段路线图**: `docs/plans/prototype-roadmap.md`
-**设计目录**: `docs/design/prototype/`
+- **开发阶段**：原型阶段
+- **当前版本**：v0.1
+- **版本验证目标**："世界有味道" — 角色控制 + 交互系统 + 6 区域白盒 + 收集计数
+- **关注问题**：这个世界好玩吗？美术风格对吗？技术方案跑得通吗？
 
-### 流水线状态
-- 当前阶段：④执行案（①②③基本就绪）
-- 阻塞点：执行案缺失，需先补齐执行案
+## 原型阶段退出标准
 
-### 进行中
+- [ ] 用户主观判断核心玩法已验证通过
+- [ ] `prototype/` 最终版复制到 `production/`
 
-> 按流水线阶段和优先级排列
+> 原型阶段使用版本开发流水线（③-⑦），执行质量门审查。
+> 原型阶段灵活性：⑤⑥允许交替推进，不必严格串行。
 
-- [ ] 整理全局设计文档，按规范放置 — ①全局设计
-- [ ] 产出 v0.1 版本设计文档（v01-design.md）— ③版本设计
-- [ ] 产出玩家控制器执行案（player-controller-execution.md）— ④执行案
-- [ ] 产出交互系统执行案（interaction-system-execution.md）— ④执行案
-- [ ] 产出收集系统 v0.1 执行案（collection-system-execution.md）— ④执行案
+## v0.1 流水线进度
 
-### 待开始
+| 步骤 | 状态 | 说明 |
+|------|------|------|
+| ① 设计案 | ✅ 已有素材 | `docs/design/prototype/` 下 10 份设计文档 |
+| ② 阶段路线图 | ✅ 已有 | `docs/plans/prototype-roadmap.md` |
+| ③ 执行案 | 🔴 质量门未通过 | 审查报告 `docs/plans/reviews/P-002-review.md`，需创建独立执行案并修正 |
+| ④ 程序设计 | ⬜ 未开始 | 依赖 ③ 完成并通过质量门 |
+| ⑤ 美术产出 | ⬜ 未开始 | 白盒场景 + 占位资产 |
+| ⑥ 程序实现 | ⬜ 未开始 | 原型阶段允许与 ⑤ 交替推进 |
+| ⑦ 版本复盘 | ⬜ 未开始 | -- |
 
-- [ ] 执行案质量门审查 — PM
-- [ ] 玩家控制器程序设计（player-controller-tech.md）— ⑤程序设计
-- [ ] 交互系统程序设计（interaction-system-tech.md）— ⑤程序设计
-- [ ] 收集系统程序设计（collection-system-tech.md）— ⑤程序设计
-- [ ] 程序设计质量门审查 — PM
-- [ ] v0.1 美术资产产出 — ⑥美术产出（v0.1 允许开发者自行处理占位资源）
-- [ ] 美术资产验收门审查 — PM
-- [ ] 清理引擎模板变体代码 — ⑦实现（无流水线依赖，可并行）
-- [ ] 角色控制器实现 — ⑦实现
-- [ ] 交互系统实现 — ⑦实现
-- [ ] v0.1 场景白盒搭建（6个区域）— ⑦实现
-- [ ] 收集计数系统实现 — ⑦实现
-- [ ] v0.1 验收测试
-- [ ] 文档同步（更新设计案/执行案匹配实现）
+## 进行中
 
-### 已完成
+> 按优先级排列，建议从上到下依次完成
 
-- [x] Git 分支策略与提交规范
-- [x] 项目目录结构与协作体系设计
-- [x] 建立项目基础设施（目录结构、规范文档）
-- [x] 游戏愿景文档（game-vision.md）
-- [x] v0.1 范围定义（v01-scope.md）
-- [x] 玩家控制设计（player-controller.md）
-- [x] 交互系统设计（interaction-system.md）
-- [x] v0.1 场景设计（scene-v01-suburban.md）
-- [x] 修正项目时代设定（CLAUDE.md + style-guide.md）
-- [x] 收集系统设计（collection-system.md）
-- [x] Brainstorm 讨论记录（brainstorm-2026-06-01）— 阶段 1-5 全部完成
-- [x] 场景与世界观详细设计（scene-world.md）
-- [x] 小游戏系统设计（minigame-system.md）
-- [x] 叙事框架设计（narrative-framework.md）
-- [x] 主角角色设计（protagonist-character.md）
-- [x] 开发流程重构：四阶段框架 + 阶段目录 + 文档同步
+- [x] **P-001** 原型阶段启动准备 ✔ 2026-06-05
+  - ✅ 全面重新评估并更新 `prototype-roadmap.md`（3→4 版本）
+  - ✅ 同步更新 `roadmap.md`
+  - ✅ 建立角色汇报机制（`docs/plans/reports/`）
+  - ✅ 归档草案阶段文档
 
----
+- [ ] **P-002** v0.1 ③执行案 — 质量门未通过，需修正后重新提交
+  - 审查报告：`docs/plans/reviews/P-002-review.md`
+  - 以下 3 个子任务按顺序完成，全部完成后重新提交质量门
 
-## 设计文档状态
+  - [ ] **P-002a** 交互系统执行案
+    - 产出：`docs/design/prototype/interaction-system-execution.md`
+    - 依赖素材：`docs/design/prototype/interaction-system.md`（原始设计案）
+    - 参考范围：`docs/design/prototype/v01-scope.md`
+    - **阻塞问题**（必须修正）：
+      1. 创建独立执行案文件（含迭代记录表头）
+      2. 移除技术越界内容：JSON 数据结构定义（原文件第170-193行）、程序实现注释（原文件第1行）、白盒占位模型需求（原文件第255-282行）
+      3. 补充边界情况：交互中断行为、多交互物重叠键位冲突、推镜目标不可达、快速连续按键防护
+    - **建议修正**：
+      - 交互取消行为链补完
+      - 废纸箱翻找结果的随机机制明确化
+      - 交互中角色可移动范围/速度限制明确化
 
-### 已完成（均位于 `docs/design/prototype/`）
+  - [ ] **P-002b** 收集系统执行案
+    - 产出：`docs/design/prototype/collection-system-execution.md`
+    - 依赖素材：`docs/design/prototype/collection-system.md`（原始设计案）
+    - 参考范围：`docs/design/prototype/v01-scope.md`、`docs/design/prototype/scene-world.md`（区域分布）
+    - **阻塞问题**（必须修正）：
+      1. 创建独立执行案文件（含迭代记录表头）
+      2. 扩展 v0.1 执行内容：10 个拾取品清单、计数 UI 位置/格式、区域分布规则、与交互系统的关联
+      3. 补充边界情况：一次性拾取确认、全部收集完表现、重启状态处理、拾取中断处理
 
-- [x] `game-vision.md` — 游戏愿景
-- [x] `v01-scope.md` — v0.1 范围定义
-- [x] `player-controller.md` — 玩家控制设计
-- [x] `interaction-system.md` — 交互系统设计
-- [x] `scene-v01-suburban.md` — v0.1 场景设计
-- [x] `collection-system.md` — 收集系统设计
-- [x] `minigame-system.md` — 小游戏系统设计
-- [x] `narrative-framework.md` — 叙事框架设计
-- [x] `scene-world.md` — 场景与世界观详细设计
-- [x] `protagonist-character.md` — 主角角色设计
+  - [ ] **P-002c** 角色控制执行案
+    - 产出：`docs/design/prototype/player-controller-execution.md`
+    - 依赖素材：`docs/design/prototype/player-controller.md`（原始设计案）
+    - 参考范围：`docs/design/prototype/v01-scope.md`、`docs/design/prototype/protagonist-character.md`
+    - **阻塞问题**（必须修正）：
+      1. 创建独立执行案文件（含迭代记录表头）
+    - **建议修正**：
+      - 明确 WASD 相对角色朝向还是相对摄像机方向
+      - 补充视角垂直角度限制
+      - 第1行注释移除"动画蓝图"技术术语
 
-### 待产出
+- [ ] **P-003** v0.1 ④程序设计
+  - 依赖：P-002 完成
+  - 基于执行案设计实现方案（类/组件架构、数据流、美术需求清单）
+  - 提交程序设计质量门
 
-- [ ] `docs/plans/roadmap.md` 更新 — 路线图补全 v0.5-v0.7
-- [ ] `economy-system.md` — 零花钱经济系统设计（v0.3 前产出即可）
-- [ ] `time-system.md` — 一天时间循环系统设计（v0.3 前产出即可）
+- [ ] **P-004** v0.1 ⑤美术 + ⑥程序实现
+  - 依赖：P-003 完成
+  - 白盒场景 + 占位资产 → 编写代码实现
+  - 原型阶段允许⑤⑥交替推进
+
+- [ ] **P-005** v0.1 ⑦版本复盘
+  - 依赖：P-004 完成
+  - 程序汇报偏差 → PM 协调 → 策划更新文档
+
+## 可用素材
+
+> `docs/design/prototype/` 下的设计文档 + 草案阶段产出：
+
+| 文档 | 内容 | 用途 |
+|------|------|------|
+| `game-vision.md` | 愿景、核心情感、三大支柱 | 设计案参考 |
+| `brainstorm-2026-06-01-*.md` | 5 阶段讨论记录 | 素材来源 |
+| `scene-world.md` | 场景与世界观详细设计 | 执行案：场景白盒 |
+| `protagonist-character.md` | 主角角色设计 | 执行案：角色控制 |
+| `narrative-framework.md` | 叙事框架 | 后续版本参考 |
+| `minigame-system.md` | 小游戏体系设计 | v0.2 参考 |
+| `collection-system.md` | 收集系统设计 | 执行案：收集系统 |
+| `interaction-system.md` | 交互系统设计 | 执行案：交互系统 |
+| `player-controller.md` | 玩家控制设计 | 执行案：角色控制 |
+| `v01-scope.md` | v0.1 范围定义 | 范围界定 |
+| `../concept.md` | 玩法概念草案（7 字段齐全） | 核心概念参考 |
+| `docs/technical/feasibility-assessment.md` | 技术可行性评估（10 系统） | 程序设计参考 |
+
+## 已归档
+
+- 草案阶段全部工作 → `docs/plans/archive/draft/`
+  - 基础设施、头脑风暴、10 份设计文档 → `pre-draft.md`
+  - D-001 玩法概念草案 → `docs/design/concept.md`（保留在位，归档记录）
+  - D-002 技术可行性评估 → `docs/technical/feasibility-assessment.md`（保留在位，归档记录）

docs/plans/prototype-roadmap.md

@@ -1,6 +1,7 @@
 # 原型阶段路线图
 
 > 定义原型阶段的版本迭代计划。每个版本验证一个核心假设。
+> 最后更新：2026-06-05
 
 ---
 
@@ -10,63 +11,291 @@
 
 ---
 
-## 版本规划
+## 版本列表
+
+| 版本 | 核心验证目标 | 预估工期 | 状态 |
+|------|-------------|---------|------|
+| v0.1 | 场景漫游与环境交互 — 探索感成立吗？ | 10-18 天 | 进行中 |
+| v0.2 | 弹珠小游戏 — 操作手感行不行？策略深度够吗？ | 18-28 天 | 待开始 |
+| v0.3 | 时间循环与NPC — 时间流动让世界活了吗？ | 15-25 天 | 待开始 |
+| v0.4 | 经济与叙事框架 — 目标感和方向感成立吗？ | 15-22 天 | 待开始 |
+
+---
+
+## 版本详细规划
 
 ### v0.1 — 场景漫游与环境交互
 
-**验证假设**：在场景中自由移动并与环境交互，这个基础体验成立吗？
+**验证假设**：在千禧年城郊场景中自由移动并与环境交互，玩家能感受到"探索的乐趣"和"时代的氛围"吗？
 
-**范围**：
-- 第三人称角色控制器（移动 + 摄像机）
-- 交互系统（观察 + 拾取）
-- v0.1 场景白盒（6 个区域）
-- 收集计数系统（基础版）
+**核心目标**：建立"世界有味道"的基础体验
+
+**范围概述**：
+- 第三人称角色控制器（WASD 移动 + 摄像机跟随 + Shift 跑步）
+- 交互系统核心框架（观察 + 拾取 + 操作 + NPC简化版，4 种交互类型）
+- 推镜相机系统（观察类交互的特写镜头）
+- 交互提示 UI + 叙事文本 UI（打字机效果）
+- v0.1 场景白盒（6 个区域：家、小卖部、街道、空地、巷子、水塘边，~80m x 60m）
+- 收集系统基础版（拾取 + 计数，无分类无图鉴）
+
+**涉及的系统**（引用设计案中的系统名）：
+- 角色控制器（`player-controller.md`）
+- 交互系统（`interaction-system.md`）
+- 收集系统 v0.1 简化版（`collection-system.md` v0.1 范围）
+- 场景白盒（`scene-world.md` v0.1 范围）
+
+**内容完成度**：
+| 内容类型 | 完成度 | 说明 |
+|----------|--------|------|
+| 角色控制 | 初版 | 走/跑/交互，无蹲下无跳跃 |
+| 交互系统 | 初版 | 4 种交互类型框架，25+ 交互点 |
+| 收集系统 | 占位 | 仅拾取+计数，无分类图鉴 |
+| 场景 | 白盒 | 简单几何体 + 颜色区分，固定下午光影 |
+| UI | 初版 | 交互提示 + 叙事文本 + 收集计数 |
+| 动画 | 占位 | 简单占位动画或无动画 |
+| 音效 | 无 | v0.1 不含音效 |
 
 **验收标准**：
-- 6 个区域均可探索
-- 25+ 交互点可正常触发
-- 10 个收集品可拾取
-- 整体帧率稳定 30+
+1. **基础运行**：游戏正常启动，角色出现在家门口，无崩溃，稳定 30 帧
+2. **移动体验**：WASD 响应流畅，摄像机跟随平滑不穿墙，跑步/步行速度差异明显
+3. **交互体验**：靠近可交互物体正确显示提示（1.5m 触发），按 E 触发交互，叙事文本打字机效果正常，离开范围提示消失
+4. **场景体验**：6 个区域均可到达和探索，每个区域至少 3 个可交互物体，10 个收集品可全部拾取
+5. **氛围体验**（主观）：走在街上能感受到"千禧年城郊"的时代感，交互文本能唤起共鸣，整体让人想继续探索
+6. **多交互物不冲突**：多个交互物在范围内时只显示最近的，切换流畅
+
+**与 feasibility-assessment.md 的对齐**：
+- 角色控制器：基于已有 ChildHoodCharacter 框架，1-2 天
+- 交互系统核心框架：3-4 天（Interface + Component + 检测 + UI）
+- 推镜相机：1-2 天
+- 场景白盒（6 区域）：2-3 天
+- 交互物数据填充（25+）：2-3 天
+- 收集系统基础（拾取+计数）：1-2 天
+- 调试打磨：2-3 天
+- 合计：10-18 天
 
 ---
 
-### v0.2 — 第一个完整小游戏
+### v0.2 — 弹珠小游戏
 
-**验证假设**：小游戏好不好玩？操作手感行不行？
+**验证假设**：弹珠四维策略系统（规则 x 场地 x 弹珠 x 手法）操作手感成立吗？策略深度足够让人玩十几把不腻吗？
 
-**范围**：
-- 弹珠小游戏完整实现
-- NPC 对话基础版
-- 基础音效（脚步、交互、环境）
-- 家和小卖部的室内空间
+**核心目标**：验证小游戏可玩性——游戏三大支柱之一"好玩"是否成立
 
-**验收标准**：（待 v0.1 完成后详细定义）
+**范围概述**：
+- 弹珠操作手感 Throwaway 原型（先验证操作方案再正式实现）
+- 弹珠物理系统（Chaos Physics，材质参数配置）
+- 四维策略数据框架（规则/场地/弹珠属性/手法 DataAsset）
+- 弹珠独立 GameMode + PlayerController
+- 弹珠与收集系统联动（赢弹珠/输弹珠）
+- NPC 基础框架（静态站位 + 作为弹珠对手的简单 AI 决策）
+- 蹲下系统（角色控制扩展）
+- 弹珠场地标识（空地大树下的区域标记）
+
+**涉及的系统**：
+- 弹珠小游戏（`minigame-system.md` 弹珠部分）
+- 角色控制器扩展（`player-controller.md` 蹲下部分）
+- 收集系统扩展（`collection-system.md` v0.2 弹珠关联部分）
+- NPC 基础（`narrative-framework.md` 角色列表，取死党 B 作为弹珠对手）
+
+**内容完成度**：
+| 内容类型 | 完成度 | 说明 |
+|----------|--------|------|
+| 弹珠小游戏 | 初版 | 1 种规则（画圈弹），1-2 种场地，验证核心操作 |
+| 弹珠策略 | 初版 | 四维数据框架，弹珠属性差异可感知 |
+| NPC | 占位 | 1-2 个 NPC 静态站位作为对手，无对话树 |
+| 蹲下系统 | 初版 | 蹲伏移动 + 蹲伏待机 |
+| 收集联动 | 初版 | 弹珠作为收集品 + 小游戏道具 |
+| 场景扩展 | 微调 | 空地增加弹珠场地标识，不新建区域 |
+| 动画 | 占位 | 弹珠操作动画占位，蹲下动画占位 |
+
+**验收标准**：
+1. **操作手感**：弹珠的"弹射"操作（角度+力度）直觉流畅，手柄/键鼠方案至少一种体验良好
+2. **物理表现**：弹珠在不同材质地面（水泥/泥土）的滚动、碰撞表现合理
+3. **策略深度**：不同弹珠属性（大小/材质）在游戏中能感知到差异，NPC 选择不同规则/场地时需要调整策略
+4. **收集联动**：赢比赛获得弹珠、输比赛失去弹珠（有保底），弹珠库存与收集系统同步
+5. **可重复性**（主观）：连续玩 5 把以上不觉得无聊，想尝试不同弹珠/手法组合
+6. **蹲下体验**：蹲下/站起过渡自然，蹲下移动速度降低，视角降低
+
+**关键风险**（来自 feasibility-assessment.md）：
+- 操作手感是核心难题。必须先做 Throwaway 原型（2-3 天）验证操作方案，验证不通过则需调整方案（可能增加 5-10 天）
+- 物理参数对微小物体（弹珠半径约 1cm UE 单位）数值敏感，需反复调参
+
+**与 feasibility-assessment.md 的对齐**：
+- 操作手感原型：2-3 天
+- 弹珠物理系统：3-5 天
+- 四维策略数据框架：3-4 天
+- 弹珠 GameMode + PC：3-5 天
+- NPC 基础框架（静态+简单AI）：3-5 天
+- 蹲下系统：1-2 天
+- 弹珠与收集联动：2-3 天
+- 调试打磨：3-5 天（含物理调参）
+- 合计：18-28 天
 
 ---
 
-### v0.3 — 一天时间循环
+### v0.3 — 时间循环与NPC
 
-**验证假设**：时间流动带来的日常节奏感成立吗？
+**验证假设**：四时段的时间流动 + NPC 按时段切换位置，能让玩家感受到"这个世界是活的"吗？日常节奏感成立吗？
 
-**范围**：
-- 一天四时段的时间系统
-- 时段与光照变化联动
-- 零花钱经济系统
-- 时段与 NPC 位置/行为联动
+**核心目标**：验证世界的活性——时间推动世界变化，NPC 有自己的生活
 
-**验收标准**：（待 v0.2 完成后详细定义）
+**范围概述**：
+- TimeManager 核心框架（四时段枚举 + 推进逻辑 + 事件广播）
+- 光影联动（Directional Light 旋转角度/强度 + Skybox + 四时段渐变过渡）
+- NPC 位置调度系统（NPCScheduleComponent，时段-位置映射表）
+- 3 个核心 NPC 的时段行为配置（死党 B、小卖部老板儿子、小霸王）
+- NPC 基础活性（Idle 动画 + 小范围巡逻，非纯静态站位）
+- 简单对话系统（JSON 对话数据 + 打字机文本显示，无分支无选择）
+- 时段与活动可用性联动（小卖部下午开、晚上在家看电视）
+- 基础音效（脚步声、环境音、时段过渡音效）
+- 学校操场区域扩展
+
+**涉及的系统**：
+- 时间循环系统（`scene-world.md` 时段光影 + concept.md 日常循环）
+- NPC 系统（`narrative-framework.md` 角色列表 + `scene-world.md` NPC 常驻地）
+- 场景氛围（`scene-world.md` 声音景观 + 光影变化）
+- 场景扩展（`scene-world.md` v0.3 学校操场）
+
+**内容完成度**：
+| 内容类型 | 完成度 | 说明 |
+|----------|--------|------|
+| 时间系统 | 初版 | 四时段推进 + 事件广播，非真实时间流逝 |
+| 光影变化 | 初版 | 四时段渐变过渡，Warm/Nostalgic 色调 |
+| NPC 调度 | 初版 | 3 个核心 NPC 的时段-位置表 |
+| NPC 活性 | 初版 | Idle 动画 + 小范围移动 |
+| 对话系统 | 初版 | 单线对话文本显示，无分支选择 |
+| 音效 | 初版 | 脚步声 + 环境音 + 时段过渡音 |
+| 场景扩展 | 微调 | 新增学校操场区域 |
+
+**验收标准**：
+1. **时间推进**：时段可通过事件或玩家行为推进，推进时所有注册系统收到通知
+2. **光影过渡**：四时段之间的光影切换平滑自然（无突兀跳变），下午金黄/傍晚橙红/夜晚深蓝各有辨识度
+3. **NPC 调度**：时段切换时 3 个 NPC 正确移动到新位置（可接受 Fade In/Out 过渡），每个 NPC 至少 2 个时段有不同的常驻地
+4. **时段活动**：小卖部有开门/关门状态，晚上在家有"看电视"的状态表现
+5. **音效氛围**：不同时段有可区分的音效环境（下午蝉鸣、傍晚蛙叫、夜晚虫鸣）
+6. **节奏感**（主观）：时间流逝感觉自然、不催促，玩家有"一天过去了"的感觉
+
+**与 feasibility-assessment.md 的对齐**：
+- TimeManager 核心：2-3 天
+- 光影联动：3-5 天
+- NPC 位置调度：2-3 天
+- 时段与活动联动：2-3 天
+- 简单对话框架：3-4 天
+- 基础音效：3-5 天
+- NPC 活性微调：1-2 天
+- 学校操场场景：1-2 天
+- 调试打磨：2-3 天
+- 合计：15-25 天
+
+---
+
+### v0.4 — 经济与叙事框架
+
+**验证假设**：零花钱系统 + 事件驱动的叙事框架，能让玩家产生"目标感"和"方向感"吗？多路径达成的设计成立吗？
+
+**核心目标**：验证游戏的持续驱动力——玩家有理由继续探索、收集、玩小游戏
+
+**范围概述**：
+- EconomyManager 核心框架（零花钱计数 + 获取/消费/换币逻辑）
+- 小卖部购买流程 UI（商品列表 + 价格 + 购买确认）
+- 事件管理系统框架（EventManager，基于事件条件触发）
+- 第一个情感事件链（"帮死党准备送别礼物"的简化版）
+- 链式任务框架（QuestManager，任务条件-目标-奖励数据结构）
+- 多路径达成逻辑（弹珠赢/收集换/零花钱买，OR 条件）
+- 2-3 个核心角色的对话扩展（死党 A/B + 小霸王，条件触发对话）
+- 收集系统扩展（四类分类 + 基础图鉴 UI）
+
+**涉及的系统**：
+- 经济系统（`collection-system.md` 获取方式设计 + `minigame-system.md` 经济循环）
+- 叙事系统（`narrative-framework.md` 事件设计模式 + 结局系统）
+- 收集系统扩展（`collection-system.md` v0.2 范围）
+- NPC 对话扩展（`narrative-framework.md` 角色列表）
+
+**内容完成度**：
+| 内容类型 | 完成度 | 说明 |
+|----------|--------|------|
+| 经济系统 | 初版 | 零花钱管理 + 小卖部购买 UI |
+| 事件系统 | 初版 | 事件触发 + 条件判断 + 广播 |
+| 任务系统 | 初版 | 链式任务 + 多路径完成条件 |
+| 叙事内容 | 占位 | 1 条简化版事件链（验证框架） |
+| NPC 对话 | 初版 | 2-3 个角色条件对话，无分支 |
+| 收集扩展 | 初版 | 四类分类 + 基础图鉴，无 3D 展示 |
+| 场景扩展 | 微调 | 小卖部室内可进入 |
+
+**验收标准**：
+1. **经济循环**：能通过小游戏（弹珠）赢零花钱，能在小卖部花零花钱买东西，收支有感知
+2. **事件触发**：满足条件时事件自然触发（不弹窗不强制），触发时机符合叙事逻辑
+3. **多路径达成**：同一个目标至少有 2 种不同路径可完成（如赢弹珠 vs 攒钱买），路径切换不影响进度
+4. **链式任务**：任务有明确的前后依赖关系，前一步完成自动推进下一步
+5. **收集图鉴**：拾取的物品按四类分类展示，有进度可视化
+6. **目标感**（主观）：玩家有"我想做这件事"的内在驱动力，不是因为系统奖励而是因为故事/情感
+
+**与 feasibility-assessment.md 的对齐**：
+- EconomyManager 核心：3-5 天
+- 购买 UI：3-4 天
+- 事件系统框架：3-4 天
+- 链式任务框架：3-4 天
+- 多路径逻辑：2-3 天
+- NPC 对话扩展：2-3 天
+- 收集系统扩展：3-4 天
+- 小卖部室内：1-2 天
+- 调试打磨：2-3 天
+- 合计：15-22 天
 
 ---
 
 ## 递进关系
 
 ```
-v0.1 场景漫游 → v0.2 小游戏 → v0.3 时间循环
-     │              │               │
-     └─ 验证"世界有味道"  └─ 验证"游戏好玩"  └─ 验证"世界是活的"
+v0.1 场景漫游+交互          v0.2 弹珠小游戏          v0.3 时间循环+NPC          v0.4 经济+叙事
+     │                          │                        │                         │
+     └─ "世界有味道"            └─ "游戏好玩"            └─ "世界是活的"            └─ "有理由继续"
+                                                                                    
+探索感基础 → 玩法深度 → 世界活性 → 持续动力
 ```
 
-v0.1 是基础（场景 + 交互），v0.2 在此基础上加玩法深度，v0.3 加时间维度让世界活起来。
+**递进逻辑**：
+
+1. **v0.1 是地基**：没有场景漫游和交互，后续一切都无从谈起。验证最基本的"在千禧年场景中走动并交互"是否成立。如果这个假设失败，项目方向需要根本性调整。
+
+2. **v0.2 验证核心玩法**：小游戏是三大支柱之一（concept.md 定义）。弹珠作为第一个小游戏验证"操作手感成立"和"策略深度足够"，这是整个小游戏体系的风险前置。如果弹珠不好玩，后续拍洋画、四驱车等也需要重新评估。
+
+3. **v0.3 验证世界活性**：在"好玩"的基础上加时间维度，让世界有节奏感。NPC 调度让空旷的场景有生气。此版本依赖 v0.2 产出的 NPC 基础框架。
+
+4. **v0.4 验证持续驱动力**：经济系统给玩家"钱"的概念（要做选择），叙事框架给玩家"方向"（为什么要做这些事）。多路径达成是 concept.md 的核心设计原则，必须验证。此版本依赖 v0.2 的弹珠（经济来源之一）和 v0.3 的 NPC/时间系统。
+
+**为什么是 4 个版本而不是原来的 3 个**：
+- 原 v0.2 同时包含弹珠小游戏（20-32天最大工作量）和 NPC 对话+室内+音效，范围过大
+- 原 v0.3 同时包含时间循环、经济系统、NPC 联动、音效，范围过大
+- 拆为 4 个版本后，每个版本聚焦一个核心假设，工作量更均衡（10-28 天/版本 vs 原来 10-32 天），风险更低
+
+---
+
+## 设计文档深度评估
+
+以下评估基于 `docs/design/prototype/` 下各设计文档的当前状态，指导每个版本需要的设计补充工作：
+
+| 设计文档 | 当前深度 | v0.1 可用度 | 后续版本需要的补充 |
+|----------|---------|------------|-------------------|
+| `player-controller.md` | 深入 | 直接可用 | v0.2 需补充蹲下系统执行案 |
+| `interaction-system.md` | 深入 | 直接可用 | 无 |
+| `v01-scope.md` | 精确 | 直接可用 | 无 |
+| `scene-world.md` | 极详尽 | v0.1 白盒参考 | v0.3 补充学校操场、v0.4 补充小卖部室内 |
+| `collection-system.md` | 完整 | v0.1 拾取部分可用 | v0.2 补充弹珠关联、v0.4 补充四类分类+图鉴 |
+| `minigame-system.md` | 完整 | 不涉及 | v0.2 需补充弹珠执行案（操作方案、物理参数范围、NPC AI 规则） |
+| `narrative-framework.md` | 框架清晰 | 不涉及 | v0.3 补充对话数据格式、v0.4 补充事件链执行案 |
+
+---
+
+## 阶段退出标准
+
+原型阶段通过以下条件后，可由用户决定进入批量生产阶段：
+
+1. **核心假设验证**：v0.1-v0.4 的四个核心假设（探索感、可玩性、世界活性、持续动力）全部通过用户主观判断
+2. **核心循环可玩**：至少存在一个可玩的核心循环（起床-探索-小游戏-收集-推进目标-入睡）的完整原型
+3. **文档已同步**：所有通过验证的系统的执行案已更新至与实际实现一致（迭代记录标记为"已同步"）
+4. **技术风险可控**：无未解决的阻塞性技术问题
+5. **用户确认**：用户明确表示"核心玩法已验证通过"
 
 ---
 
@@ -74,4 +303,5 @@ v0.1 是基础（场景 + 交互），v0.2 在此基础上加玩法深度，v0.3
 
 | 日期 | 调整内容 |
 |------|----------|
-| 2026-06-03 | 初始版本规划 |
+| 2026-06-05 | 全面重新评估：3 版本扩展为 4 版本，补全验收标准/系统清单/内容完成度/设计文档深度评估/阶段退出标准，与 feasibility-assessment.md 工期数据对齐 |
+| 2026-06-03 | 初始版本规划（3 版本：v0.1 场景漫游、v0.2 小游戏、v0.3 时间循环） |

docs/plans/reports/art-report.md

@@ -0,0 +1,37 @@
+# 美术汇报
+
+> 最后更新：—
+> 当前无活跃任务
+
+---
+
+## 基本信息
+
+- **日期**：—
+- **阶段**：原型阶段
+- **版本号**：—
+- **当前任务 ID**：—
+
+---
+
+## 本期完成内容
+
+—
+
+---
+
+## 遇到的问题 / 偏差
+
+—
+
+---
+
+## 下一步计划
+
+—
+
+---
+
+## 需要协调的事项
+
+—

docs/plans/reports/design-report.md

@@ -0,0 +1,37 @@
+# 策划汇报
+
+> 最后更新：—
+> 当前无活跃任务
+
+---
+
+## 基本信息
+
+- **日期**：—
+- **阶段**：原型阶段
+- **版本号**：—
+- **当前任务 ID**：—
+
+---
+
+## 本期完成内容
+
+—
+
+---
+
+## 遇到的问题 / 偏差
+
+—
+
+---
+
+## 下一步计划
+
+—
+
+---
+
+## 需要协调的事项
+
+—

docs/plans/reports/dev-report.md

@@ -0,0 +1,37 @@
+# 程序汇报
+
+> 最后更新：—
+> 当前无活跃任务
+
+---
+
+## 基本信息
+
+- **日期**：—
+- **阶段**：原型阶段
+- **版本号**：—
+- **当前任务 ID**：—
+
+---
+
+## 本期完成内容
+
+—
+
+---
+
+## 遇到的问题 / 偏差
+
+—
+
+---
+
+## 下一步计划
+
+—
+
+---
+
+## 需要协调的事项
+
+—

docs/plans/reviews/P-002-review.md

@@ -0,0 +1,112 @@
+# P-002 审查报告
+
+**审查日期**：2026-06-05
+**审查对象**：v0.1 执行案质量门 -- 交互系统、收集系统、角色控制
+**宏观阶段**：原型阶段
+**审查文件**：
+- `docs/design/prototype/interaction-system.md`
+- `docs/design/prototype/collection-system.md`
+- `docs/design/prototype/player-controller.md`
+- `docs/design/prototype/v01-scope.md`（范围参考）
+
+---
+
+## 结构性问题
+
+| 检查项 | 结果 | 说明 |
+|--------|------|------|
+| 独立执行案文件 | ❌ | 三个系统均无独立执行案文件（应为 `<系统名>-execution.md`） |
+| 迭代记录表头 | ❌ | 无任何文件包含迭代记录表头 |
+
+---
+
+## 交互系统（interaction-system.md）
+
+| 检查项 | 结果 | 说明 |
+|--------|------|------|
+| 完整性 | ✅ | 4 种交互类型覆盖全，交互物清单完整 |
+| 清晰性 | ⚠️ | 基本清晰，有少量模糊点（移动范围限制、废纸箱随机机制） |
+| 边界情况 | ❌ | 缺失：交互中断、多交互物键位冲突、推镜不可达、快速按键防护、遮挡处理 |
+| 技术越界 | ❌ | 包含 JSON 数据结构、程序实现注释、白盒占位模型需求 |
+| 范围一致性 | ✅ | v0.1 范围控制良好，"不包含"清单明确 |
+
+**判定**：不通过
+
+### 问题清单
+
+1. [阻塞] 缺失独立执行案文件和迭代记录
+2. [阻塞] 技术越界：JSON 数据结构定义（第170-193行）、程序实现注释（第1行）、白盒占位模型需求（第255-282行）
+3. [阻塞] 边界情况缺失：交互中断行为、多交互物重叠键位冲突、推镜目标不可达、快速连续按键防护
+4. [建议] 交互取消行为链不完整
+5. [建议] 废纸箱翻找结果的随机机制未明确
+6. [建议] 交互中角色可移动范围/速度限制模糊
+7. [轻微] 打字机效果"每字"定义不清
+8. [轻微] v0.1 可选交互物清单可能造成优先级困惑
+
+---
+
+## 收集系统（collection-system.md）
+
+| 检查项 | 结果 | 说明 |
+|--------|------|------|
+| 完整性 | ❌ | v0.1 部分仅 4 行，缺少行为规则、拾取品清单、计数 UI 定义 |
+| 清晰性 | ❌ | v0.1 描述过粗，程序无法直接实现 |
+| 边界情况 | ❌ | 完全缺失：重复拾取、全部收集完、重启状态、拾取中断 |
+| 技术越界 | ✅ | 未涉及技术实现细节 |
+| 范围一致性 | ✅ | 版本划分清晰，v0.1 范围合理 |
+
+**判定**：不通过
+
+### 问题清单
+
+9. [阻塞] 缺失独立执行案文件和迭代记录
+10. [阻塞] v0.1 执行内容匮乏：缺少 10 个拾取品清单、计数 UI 位置/格式、区域分布、与交互系统的关联
+11. [阻塞] 边界情况缺失：一次性拾取确认、全部收集完表现、重启状态处理、拾取中断处理
+
+---
+
+## 角色控制（player-controller.md）
+
+| 检查项 | 结果 | 说明 |
+|--------|------|------|
+| 完整性 | ⚠️ | 核心行为覆盖好，缺少 WASD 相对方向、视角限制等细节 |
+| 清晰性 | ✅ | 行为描述清晰，数值标注合理 |
+| 边界情况 | ⚠️ | 原型阶段基本可接受，缺少场景边界、输入冲突处理 |
+| 技术越界 | ⚠️ | 基本合规，第1行注释含"动画蓝图"技术术语 |
+| 范围一致性 | ✅ | P0/可简化/不做三级清晰 |
+
+**判定**：有条件通过 -- 需创建独立执行案，补充少量遗漏项
+
+### 问题清单
+
+12. [阻塞] 缺失独立执行案文件和迭代记录
+13. [建议] WASD 相对角色朝向还是相对摄像机方向未明确
+14. [建议] 视角垂直角度限制未说明
+15. [轻微] 第1行注释含技术术语"动画蓝图"
+
+---
+
+## 总判定
+
+**不通过。**
+
+### 阻塞级问题汇总（必须修正）
+
+| # | 问题 | 归属 |
+|---|------|------|
+| 1 | 缺失独立执行案文件和迭代记录（3个系统） | 全部 |
+| 2 | 交互系统技术越界（JSON/程序注释/白盒需求） | 交互系统 |
+| 3 | 收集系统 v0.1 执行内容匮乏（缺行为规则/拾取品清单/UI定义） | 收集系统 |
+| 4 | 收集系统边界情况完全缺失 | 收集系统 |
+| 5 | 交互系统边界情况缺失（中断/冲突/不可达） | 交互系统 |
+
+### 修正后方可进入的下一步
+
+④ 程序设计
+
+### 修正方向建议
+
+1. 创建三个独立执行案文件（含迭代记录表头）
+2. 交互系统执行案：移除技术越界内容，补充边界情况
+3. 收集系统执行案：扩展 v0.1 行为规则至可实现的详细程度，补充边界条件
+4. 角色控制执行案：提取 v0.1 范围部分，补充少量遗漏项

docs/plans/roadmap.md

@@ -9,11 +9,14 @@
 
 > 验证核心玩法可行性。详见 [prototype-roadmap.md](prototype-roadmap.md)
 
-| 版本 | 核心验证 | 状态 |
-|------|----------|------|
-| v0.1 | 场景漫游与环境交互 | 🔄 进行中 |
-| v0.2 | 第一个完整小游戏 | ⬜ 待开始 |
-| v0.3 | 一天时间循环 | ⬜ 待开始 |
+| 版本 | 核心验证 | 预估工期 | 状态 |
+|------|----------|---------|------|
+| v0.1 | 场景漫游与环境交互 | 10-18 天 | 进行中 |
+| v0.2 | 弹珠小游戏（操作手感+策略深度） | 18-28 天 | 待开始 |
+| v0.3 | 时间循环与NPC（世界活性+节奏感） | 15-25 天 | 待开始 |
+| v0.4 | 经济与叙事框架（目标感+持续动力） | 15-22 天 | 待开始 |
+
+**原型阶段总预估工期**：58-93 天（约 2-3 个月）
 
 ---
 
@@ -24,10 +27,9 @@
 
 | 版本 | 核心内容 | 状态 |
 |------|----------|------|
-| v0.4 | 叙事与收集 | ⬜ 待规划 |
-| v0.5 | 多小游戏 + 收集扩展 | ⬜ 待规划 |
-| v0.6 | 乡下章节 | ⬜ 待规划 |
-| v0.7 | 整合 + 多支线 + 结局 | ⬜ 待规划 |
+| v0.5 | 多小游戏（四驱车 + FC/街机）+ 收集扩展 | 待规划 |
+| v0.6 | 乡下章节（独立场景+乡村活动） | 待规划 |
+| v0.7 | 整合 + 多支线 + 结局系统 | 待规划 |
 
 ---
 
@@ -37,4 +39,4 @@
 
 | 版本 | 核心内容 | 状态 |
 |------|----------|------|
-| v1.0 | 全内容打磨 + 发布 | ⬜ 待规划 |
+| v1.0 | 全内容打磨 + 发布 | 待规划 |

docs/plans/work-log.md

@@ -0,0 +1,9 @@
+# 工作日志
+
+> 记录每日实际投入时间与工作内容
+
+| 日期 | 时长 | 内容 |
+|------|------|------|
+| 2026-06-03 | 2h | 初始化项目（仓库搭建、CLAUDE.md、工作流文档、Agent配置） |
+| 2026-06-04 | 2h | 尝试 AI 美术流程 |
+| 2026-06-05 | 2h | 建立草案阶段产出（概念案 + 技术可行性评估）、完成草案阶段收尾、进入原型阶段、设计与更新原型 roadmap（3→4版本） |

docs/technical/feasibility-assessment.md

@@ -0,0 +1,436 @@
+# 技术可行性评估 — ChildHood
+
+> 评估日期：2026-06-04
+> 评估基于：concept.md + 全部设计文档（13 份）
+> 引擎版本：UE 5.7.4
+> 评估人：程序 Agent
+
+---
+
+## 总体结论
+
+**技术可行性：通过。有条件通过。**
+
+ChildHood 的所有核心系统在 UE5.7.4 中均有成熟的实现路径，不存在引擎层面的硬性技术障碍。主要风险集中在**单人开发的内容量**和**小游戏的实现深度**上，而非技术可行性本身。
+
+**前提条件**：
+
+1. **严格控制小游戏范围**：弹珠和四驱车必须作为独立迭代周期，每个小游戏系统单独验证后再扩展。同时开发多个小游戏是单人开发的最大风险。
+2. **分阶段验证核心假设**：v0.1 验证探索感、v0.2 验证小游戏可玩性、v0.3 验证时间循环节奏。任一阶段验证失败需要调整后续范围。
+3. **善用 UE5 内置系统和 Marketplace 资产**：不重复造轮子，第三方资产和插件在必要时引入以节省工期。
+4. **叙事文本和美术资产是隐性工作量最大的部分**：25+ 交互对象的叙事文本、7 个 NPC 的对话树、全场景的 Lowpoly 资产——这些"非代码"工作可能比系统实现更耗时。
+
+---
+
+## 技术栈推荐
+
+### UE5 功能模块与架构
+
+| 层次 | 推荐方案 | 理由 |
+|------|---------|------|
+| **角色控制** | ACharacter + Enhanced Input System + SpringArm | 项目已有 ChildHoodCharacter 基类，Enhanced Input 是 UE5 标配，SpringArm + Camera 实现第三人称跟随 |
+| **交互系统** | C++ Interface (Interactable) + SphereOverlap 检测 + UMG Widget | 接口模式天然支持多类型交互物，SphereOverlap 简单高效，UMG 做提示和文本 UI |
+| **场景构建** | 子关卡（SubLevel）/ Data Layer 管理区域加载 | 完整版 ~150m x 120m 不大，可用单关卡，但子关卡便于管理和按需加载 |
+| **NPC 系统** | StateTree（项目已启用）+ 行为树辅助 | StateTree 是 UE5 推荐的 AI 框架，项目已启用插件；简单 NPC 也可以纯 Blueprint |
+| **UI 系统** | UMG (Unreal Motion Graphics) | UE5 标准 UI 框架，适合图鉴、对话、小游戏 UI |
+| **数据驱动** | DataAsset + DataTable | 配置收集品属性、交互物数据、NPC 数据；与 GameConfig/ 目录的 CSV/JSON 对应 |
+| **动画系统** | Animation Blueprint + Blendspace + State Machine | 标准 UE5 动画方案，Lowpoly 角色动画简单，Blend Space 处理 Walk/Run 混合 |
+| **光影 / 时间** | Directional Light + Skybox + PostProcess Volume | 四时段光影切换用 Directional Light 的 Rotation/Intensity + Skybox 材质变化 |
+| **物理** | Chaos Physics（引擎内置） | 弹珠碰撞、拍洋画的卡片翻转——引擎内置 Chaos 物理足够 |
+| **小游戏** | 独立 GameMode + 独立 PlayerController | 每个小游戏进入时切换 GameMode/PC，隔离逻辑，互不干扰 |
+| **音频** | UE5 Audio System + Audio Volume 分区 | 引擎内置音频系统支持空间音、背景音、分区音量，满足需求 |
+| **存档** | USaveGame + SaveGameToSlot | UE5 标准存档方案，收集进度、时间进度、剧情状态均可序列化 |
+
+### 不推荐使用的系统
+
+| 系统 | 原因 |
+|------|------|
+| GameplayAbilitySystem (GAS) | 本游戏无战斗、无技能、无 Buff/Debuff，GAS 引入的复杂度远超收益 |
+| Niagara（复杂粒子） | Lowpoly 风格不需要高端粒子效果，简单的 Cascade/材质动画即可 |
+| MassEntity / ECS | 场景 NPC 仅 7 个，不需要大规模实体管理 |
+| Lumen 全局光照 | Lowpoly 风格不需要，且对性能有较大影响；用烘焙光照或简单动态光即可 |
+| Nanite | Lowpoly 资产面数极低（道具 < 500，角色 < 3000），Nanite 的优势无法发挥 |
+
+### 推荐的项目架构
+
+```
+Source/ChildHood/
+├── Core/                    # 游戏核心框架
+│   ├── ChildHoodGameMode    # 主游戏模式
+│   ├── ChildHoodGameState   # 全局状态（时间、天气）
+│   └── ChildHoodSaveGame    # 存档系统
+├── Player/                  # 玩家相关
+│   ├── CHPlayerController   # 主控制器（交互、UI管理）
+│   ├── CHCharacter          # 主角（移动、动画）
+│   └── CHCameraManager      # 摄像机管理（推镜等）
+├── Interaction/             # 交互系统
+│   ├── InteractableInterface# 交互接口
+│   ├── InteractableComponent# 交互组件（可附着到任何Actor）
+│   └── InteractionDetector  # 检测最近的交互物
+├── Collection/              # 收集系统
+│   ├── CollectionManager    # 收集进度管理
+│   ├── CollectionDataAsset  # 收集品数据定义
+│   └── CollectionUI         # 图鉴UI
+├── NPC/                     # NPC系统
+│   ├── CHNPC                # NPC基类
+│   ├── NPCScheduleComponent# 时段位置调度
+│   └── DialogueComponent   # 对话管理
+├── Time/                    # 时间系统
+│   └── TimeManager          # 四时段管理、光影联动
+├── Narrative/               # 叙事系统
+│   ├── EventManager         # 事件触发管理
+│   └── QuestManager         # 链式任务管理
+├── Minigames/               # 小游戏系统
+│   ├── Common/              # 共享框架
+│   ├── Marble/              # 弹珠
+│   ├── CardFlip/            # 拍洋画
+│   ├── Mini4WD/             # 四驱车
+│   └── RetroGame/           # FC/街机/PC
+└── Economy/                 # 经济系统
+    └── EconomyManager       # 零花钱、交易
+```
+
+---
+
+## 系统逐一评估
+
+### 1. 角色控制器
+
+- **技术可行性**：UE5 原生完整支持。项目已有 `AChildHoodCharacter` 基类（继承 ACharacter，已配置 SpringArm + FollowCamera），已有 `AChildHoodPlayerController`（已配置 Enhanced Input 的 IMC/IA 框架）。WASD 移动、鼠标视角、Shift 跑步均为 Enhanced Input 的标准映射，零自定义引擎代码即可实现。
+- **实现复杂度**：低
+- **技术风险点**：
+  - 蹲下系统需要额外的胶囊体高度切换逻辑和 Crouch 状态的 Blendspace，但这是 UE5 Character Movement Component 的标准功能
+  - 摄像机碰撞穿墙需要 SpringArm 的 Collision Test 或自定义 Camera Blocking Volume，工作量为配置级别
+- **推荐方案**：C++ 基类（已有）+ Blueprint 配置 IMC/IA 资产。Crouch/跑步在 C++ 中用 `GetCharacterMovement()->bWantsToCrouch` / `MaxWalkSpeed` 切换，动画混合在 Blueprint 的 AnimBP 中处理。
+- **工期预估**：v0.1 核心 2-3 天（已有框架），完整版 5-7 天（含蹲下、惯性、碰撞优化）
+- **第三方需求**：无
+
+### 2. 交互系统
+
+- **技术可行性**：UE5 完全支持，无引擎限制。核心是 SphereOverlap 多播检测 + Interface 多态 + UMG Widget 显示。推镜相机用 Timelines 或 Simple Move To 实现相机平滑移动。
+- **实现复杂度**：中。4 种交互类型（观察/拾取/操作/对话）各有不同表现逻辑，但共享触发框架。
+- **技术风险点**：
+  - 多交互物共存时"只显示最近一个"的逻辑——需要排序和优先级判断，但不复杂
+  - 推镜相机的目标位置计算（物体前方 0.8-1m、微仰视）——需要考虑物体朝向和空间关系，某些场景中可能推镜位置不理想（如贴墙物体）
+  - 交互中角色转向 + 移动限制的同步——用 Gameplay Tag 或状态标记管理
+  - 打字机效果的 UI 文本——UMG TextBlock + Tick 或 Timer 逐字显示，标准实现
+- **推荐方案**：C++ 实现 InteractableInterface + InteractableComponent（核心逻辑），Blueprint 继承配置具体交互物数据。推镜逻辑用 C++ Timeline Controller。UI 用 UMG Blueprint。
+- **工期预估**：核心框架 3-4 天，填充 25+ 交互物数据 2-3 天，调试推镜 2-3 天，合计 7-10 天
+- **第三方需求**：无
+
+### 3. 场景白盒
+
+- **技术可行性**：UE5 BSP/Modeling Mode 原生支持白盒搭建。80m x 60m（v0.1）到 150m x 120m（完整版）均为单关卡可承载的规模，不需要 World Partition 或 Level Streaming。
+- **实现复杂度**：低（技术层面），中（设计/布局层面）
+- **技术风险点**：
+  - 场景布局和空间节奏需要反复调试——这不是技术问题而是体验设计问题，但会占用大量迭代时间
+  - 6 区域连通性和流线——需要确保玩家不会迷路也不会觉得局促，需多次 Playtest
+  - 室内空间（家、小卖部等）的 LOD 和碰撞——Lowpoly 模型简单，不是问题
+- **推荐方案**：UE5 Modeling Mode（已启用 ModelingToolsEditorMode 插件）直接在编辑器中白盒搭建。用 BSP 基本体 + 简单材质颜色区分区域。收集免费的 Lowpoly Starter Content 或 Marketplace 免费资产作为占位模型。
+- **工期预估**：v0.1 白盒 3-4 天，完整版场景（含室内）15-20 天
+- **第三方需求**：建议使用 Marketplace 免费 Lowpoly 资产包（如 Low Poly Megapack 等）作为白盒占位
+
+### 4. 收集系统
+
+- **技术可行性**：UE5 完全支持。基础拾取是交互系统的一个子类型（InteractableInterface 的 PickUp 实现），计数用 GameState 或 SaveGame 中的 Map/TArray 存储。扩展到四类收集品 + 图鉴 UI 后，需要 DataAsset 定义收集品数据和 UMG 构建图鉴界面。
+- **实现复杂度**：低（v0.1 基础拾取）→ 中（完整版四类 + 图鉴 + 世界反馈）
+- **技术风险点**：
+  - 图鉴 UI 中 3D 模型展示——需要 Render Target 或单独的 3D 场景渲染到 UI，UE5 支持有成熟方案（Widget 中的 Scene Capture 2D）
+  - 收集品与小游戏系统的联动——弹珠既是收集品又是道具，需要统一的 Inventory Manager 来管理数量和属性
+  - 收集进度驱动的世界反馈（NPC 对话变化、称号系统）——需要在 NPC 对话系统中加入条件判断，增加耦合度
+- **推荐方案**：C++ 实现 CollectionManager（Subsystem 或 GameState 中的组件），DataAsset 定义收集品元数据（名称、描述、稀有度、分类），SaveGame 序列化进度。图鉴 UI 用 UMG。
+- **工期预估**：v0.1 基础拾取 1-2 天（随交互系统一起），完整收集系统 10-15 天
+- **第三方需求**：无
+
+### 5. 小游戏系统
+
+这是**技术评估的核心重点**。小游戏系统包含多个独立子系统，复杂度和工作量差异极大。
+
+#### 5.1 弹珠（四维策略系统）
+
+- **技术可行性**：技术上可行，但需要自定义较多。物理碰撞用 Chaos Physics，策略系统用 DataAsset 配置，操作手感是最大挑战。
+- **实现复杂度**：高
+- **技术风险点**：
+  - **操作手感是核心难题**：弹珠的"弹射"操作需要映射到手柄/键鼠。设计文档提到"角度 + 力度"，可能的方案有：(a) 类高尔夫游戏的蓄力条 + 方向控制，(b) 类台球游戏的瞄准线 + 力度，(c) 触屏拖拽弹射的键鼠适配。操作方案的选择直接影响可玩性，需要原型验证
+  - **物理模拟的调参**：弹珠在不同材质地面（水泥/泥土/草地）的滚动、碰撞弹飞效果需要反复调参，Chaos 物理参数对微小物体（弹珠半径约 1cm UE 单位）的数值敏感度需要测试
+  - **四维策略的平衡性**：规则 x 场地 x 弹珠属性 x 手法的组合空间大，平衡性需要大量 Playtest，这超出了技术范畴但会影响开发周期
+  - **NPC AI 决策**：NPC 如何选择弹珠和手法，需要简单的效用系统或规则引擎
+- **推荐方案**：独立 C++ GameMode + PlayerController（弹珠专用），Chaos 物理处理碰撞，Blueprint 做操作 UI（瞄准、蓄力条）。先做操作手感的 Throwaway 原型（1-2 天），验证操作方案后再正式实现。
+- **工期预估**：原型验证 3-5 天，正式实现 15-25 天（含四维策略、NPC AI、与收集系统联动）
+- **第三方需求**：可能需要物理调试工具插件
+
+#### 5.2 拍洋画
+
+- **技术可行性**：与弹珠共享模板，物理模拟从滚动改为气流 + 卡片翻转。技术上更简单。
+- **实现复杂度**：中（复用弹珠框架降低复杂度）
+- **技术风险点**：
+  - 气流和震动的物理模拟——可能需要简化为动画驱动而非真实物理
+  - 卡片翻转的视觉表现——多张卡片叠加的翻转效果需要精心设计
+- **推荐方案**：继承弹珠共享模板（角度 + 力度操作），物理部分简化为预设动画 + 随机结果权重。
+- **工期预估**：8-12 天（在弹珠系统完成基础上）
+- **第三方需求**：无
+
+#### 5.3 四驱车（改装调试系统）
+
+- **技术可行性**：UE5 支持，但系统设计跨度大——UI 密集的改装界面 + 物理驱动的赛道比赛。改装 UI 本质是一个复杂的 Widget 交互系统。
+- **实现复杂度**：高
+- **技术风险点**：
+  - **改装 UI 的复杂度**：6 种部件各有多项属性，UI 需要直观展示改装效果（可能需要 3D 预览）。这是本系统中工作量最大的部分
+  - **赛道物理**：四驱车在赛道上的行驶物理——如果做真实的赛道行驶（弯道、跳跃、碰撞），物理调参量大；如果简化为预设路径 + 速度对比，则工作量可控
+  - **改装效果的可感知性**：玩家改了一个马达，需要在赛道上"感觉得到"差异——数值差异要转化为可感知的视觉/速度差异
+- **推荐方案**：C++ 实现 CarConfig DataAsset（部件属性）+ 改装 UI 用 UMG。赛道比赛用简化的物理：预设路径 + 速度/稳定性参数影响过弯和跳跃表现，而非完全物理模拟。
+- **工期预估**：15-25 天（含改装 UI、赛道系统、与收集系统联动）
+- **第三方需求**：无
+
+#### 5.4 FC 家用机 / 街机 / PC（游戏中的游戏）
+
+- **技术可行性**：技术上完全可行，本质是在 UE5 中实现小型 2D 游戏。FC/街机用 2D PaperZD 或 3D Lowpoly 做像素风格，RTS 用简化版 UI + 简单 AI。
+- **实现复杂度**：高（不是技术复杂，而是内容量大）
+- **技术风险点**：
+  - **内容量是真正的风险**：每种类型 3-5 关，FC 横版 + FC 清版 + 街机清版 + 街机格斗 + PC RTS = 5 个独立小游戏，每个有自己的关卡设计、敌人 AI、数值平衡。单人开发的工作量巨大
+  - **像素风 vs Lowpoly 的选择**：设计文档提到"用 3D Lowpoly 呈现 FC 的像素感"——这个视觉风格的实现需要特别设计，不是简单的 Lowpoly 化
+  - **格斗游戏的 AI**：即使简化版，格斗 AI（出招选择、距离判断）也需要一定工作量
+- **推荐方案**：每个小游戏独立 GameMode + 关卡。FC 横版/清版共享基础框架（角色移动、敌人 AI、关卡管理），街机格斗用简化版，RTS 用最简方案（几个单位 + 简单建造）。用 Paper2D 或简化 3D 实现像素风。
+- **工期预估**：每个小游戏 10-20 天，全部 5 个 50-100 天。建议分阶段：v0.5 先做 FC 横版验证，后续逐个追加
+- **第三方需求**：可以考虑 Marketplace 上的 2D Platformer 模板或 Beat-em-up 模板加速开发
+
+#### 5.5 肢体活动（简化处理）
+
+- **技术可行性**：极简。QTE 或节奏小游戏级别，UE5 完全原生支持。
+- **实现复杂度**：低
+- **工期预估**：每个活动 1-2 天，全部 5-8 天
+
+### 6. 时间循环系统
+
+- **技术可行性**：UE5 完全支持。核心是一个 GameState 中的 TimeManager 组件，管理当前时段（枚举），联动 Directional Light 的旋转角度和光照参数。
+- **实现复杂度**：中
+- **技术风险点**：
+  - **光影过渡的平滑性**：四时段之间的光影切换如果用离散跳变会很突兀，需要平滑过渡。方案：(a) 用浮点时间连续驱动 Directional Light Rotation，(b) 在时段边界用 Timeline 做渐变过渡。两者均可行
+  - **时段与 NPC 位置的联动**：时段切换时 NPC 需要移动到新位置。可以用简单的 Teleport + Fade In/Out，也可以做 NPC 走路移动（更真实但工作量大）
+  - **时段与活动可用性的联动**：小卖部下午才开、晚上在家看电视——需要在交互系统中加入时段条件判断
+- **推荐方案**：C++ TimeManager（Subsystem）管理时段状态，Blueprint 响应时段变化事件（OnTimePeriodChanged），联动光照和 NPC 位置。时段推进由事件或玩家行为触发，不需要真实时间流逝。
+- **工期预估**：核心框架 3-5 天，光影调试 3-5 天，与 NPC/活动联动 5-8 天，合计 10-18 天
+- **第三方需求**：无
+
+### 7. NPC 系统
+
+- **技术可行性**：UE5 完全支持。7 个核心 NPC 的 AI 用 StateTree（项目已启用）实现，简单 NPC 可以纯 Blueprint 逻辑。对话树用自定义数据结构 + UMG。
+- **实现复杂度**：中（AI 部分）→ 高（对话树部分）
+- **技术风险点**：
+  - **对话树的数据量**：7 个核心角色 x 多时段 x 多剧情阶段的对话内容，文本量大。对话数据需要结构化存储和管理
+  - **对话编辑工具**：如果对话复杂度高（分支、条件），需要对话编辑器。可以自建简单的 JSON 对话数据 + 解析器，或用 Marketplace 上的对话插件
+  - **NPC 位置调度**：每个 NPC 有时段位置联动表，需要在场景中配置多个位置点并管理切换逻辑。工作量不大但需要仔细配置
+  - **NPC 的"活性"感**：如果 NPC 只是站在固定位置切换，会显得很机械。加入 Idle 动画、小范围巡逻、看物品等微行为可以增加活性，但增加动画和 AI 工作量
+- **推荐方案**：C++ NPC 基类 + ScheduleComponent（时段位置表），StateTree 管理行为（Idle、巡逻、交互响应），对话用 JSON 数据文件 + 自建解析器。v0.1 NPC 为静态站位（不需要 AI），后续版本逐步增加活性。
+- **工期预估**：基础框架 5-8 天，7 个 NPC 数据配置 + AI 行为 10-15 天，对话系统 8-12 天，合计 20-35 天
+- **第三方需求**：建议考虑对话插件（如 Dialogue Builder 等），可节省对话编辑和渲染的工期
+
+### 8. 叙事系统
+
+- **技术可行性**：UE5 支持实现。核心是事件管理系统（EventManager）+ 任务管理系统（QuestManager），都是数据驱动设计。链式任务用图结构或线性链表存储。
+- **实现复杂度**：中
+- **技术风险点**：
+  - **叙事内容的创作**：不是技术问题，但日常事件、关键剧情、支线结局的文本创作是巨大的内容工作量
+  - **事件触发条件的复杂度**：多条件组合（收集进度 + NPC 关系 + 时段 + 剧情阶段）需要灵活的条件系统
+  - **多路径达成**：设计文档要求"多路径"（弹珠、收集、经济都能通向目标），这需要在任务系统中实现多种完成条件的 OR 逻辑
+  - **与多系统耦合**：叙事系统需要监听收集事件、小游戏结果、经济变化、时间推进——耦合度高，需要清晰的事件总线设计
+- **推荐方案**：C++ EventManager（基于 Gameplay Tag 的事件总线），QuestManager 用 DataAsset 定义任务链（条件、目标、奖励），对话触发用 NarrativeTrigger Component 附着到场景 Actor。事件总线解耦各系统。
+- **工期预估**：核心框架 8-12 天，内容配置和调试视剧情规模而定
+- **第三方需求**：无
+
+### 9. 经济系统
+
+- **技术可行性**：UE5 完全支持。核心是零花钱计数器 + 购买/消费/换币交易逻辑，本质上是一个简单的数值管理器。
+- **实现复杂度**：低
+- **技术风险点**：
+  - **经济平衡**：零花钱获取速率和消费速率需要平衡，但这是设计调参问题不是技术问题
+  - **购买流程的 UI**：小卖部购买、街机换币的 UI 交互需要精心设计，但技术上没有难点
+- **推荐方案**：C++ EconomyManager（Subsystem），DataAsset 定义商品价格和库存。购买 UI 用 UMG。
+- **工期预估**：核心框架 3-5 天，UI 交互 5-8 天，合计 8-13 天
+- **第三方需求**：无
+
+### 10. 场景氛围（光影 / 声音 / 天气）
+
+- **技术可行性**：UE5 完全支持，且引擎在此领域功能丰富。
+- **实现复杂度**：低（技术）→ 中（艺术调试）
+- **技术风险点**：
+  - **声音景观的细节度**：设计文档列出了非常详细的声音分层（主街/巷子/空地/河边各有不同音景），实现需要大量音频素材和 Audio Volume 的精细配置
+  - **天气效果**：v0.3 之后考虑，简单的雨效果用 Cascade 粒子 + 后处理材质 + 材质 Wetness 参数即可
+  - **Lowpoly 风格下的光影美感**：如何在 Lowpoly 简化几何体上做出温暖怀旧的光影效果，需要在材质和光照参数上反复调试
+- **推荐方案**：光影用 Directional Light + Skybox + PostProcess Volume（色调映射、色温），声音用 Audio Volume 分区 + Ambient Sound Actor，天气用 Cascade 粒子 + 材质变化。避开 Lumen，使用烘焙或简单动态光照以保持 Lowpoly 风格的简洁感。
+- **工期预估**：v0.1 基础光影 2-3 天（固定下午时段），完整四时段光影 5-8 天，声音景观 8-12 天，天气 3-5 天
+- **第三方需求**：大量音效素材。建议使用免费音效库（如 Freesound）或购买怀旧/城市场景音效包
+
+---
+
+## 单人开发资源瓶颈分析
+
+### 最具挑战的系统（按风险排序）
+
+| 排名 | 系统 | 挑战维度 | 瓶颈分析 |
+|------|------|---------|---------|
+| 1 | **小游戏系统（整体）** | 内容量 | 5+ 个独立小游戏 = 5+ 个小型游戏的开发量。单人同时维护多个独立玩法系统是最大的资源瓶颈 |
+| 2 | **叙事文本与对话** | 内容创作 | 7 个 NPC x 多时段 x 多阶段 = 数百条对话文本。这是非代码工作量，但可能比写代码更耗时 |
+| 3 | **美术资产** | 资产制作 | 完整版 150m x 120m 场景 + 室内 + 道具 + NPC，Lowpoly 虽然简化但仍有大量独特模型需要制作或采购 |
+| 4 | **四驱车改装系统** | UI 复杂度 | 改装 UI 是全游戏最复杂的 UI 系统，需要大量 Widget 交互逻辑 |
+| 5 | **收集系统（完整版）** | 系统联动 | 收集系统需要与小游戏、NPC、叙事、经济四个系统联动，耦合度高，调试和测试工作量大 |
+
+### 分阶段降低风险的策略
+
+1. **v0.1-v0.2：验证核心假设**
+   - 只做探索 + 弹珠。如果"在千禧年场景中漫步"和"弹珠小游戏"的体验不成立，及时调整方向
+   - 弹珠只实现 1 种规则模式（画圈弹），1 种场地，验证操作手感
+
+2. **v0.3-v0.4：扩展但不跳跃**
+   - 时间循环 + NPC 对话 + 简单叙事。这些系统相互依赖，一起做最合理
+   - NPC 先做 3 个核心角色（死党 A/B + 老板），其余后续追加
+
+3. **v0.5：内容扩展的高峰**
+   - 这是工作量最大的版本（四驱车 + FC/街机 + 收集扩展）
+   - 建议 FC/街机先各做 1 个小游戏验证框架，不急于做全量关卡
+
+4. **v0.6-v0.7：整合与收束**
+   - 乡下场景是独立模块，可以在 v0.5 期间并行设计
+   - 结局系统和多支线需要完整的回归测试
+
+### 可以显著节省工期的决策
+
+| 决策 | 节省工期 | 影响 |
+|------|---------|------|
+| FC/街机游戏每个只做 2-3 关而非 3-5 关 | 节省 15-20 天 | 耐玩度略降，但核心体验不变 |
+| 四驱车简化赛道物理（预设路径 vs 完全物理） | 节省 10-15 天 | 改装效果的直观感知度略降 |
+| NPC 对话用文本模板 + 关键词替换而非完全手写 | 节省 10-15 天 | 对话多样性略降，但可接受 |
+| 乡下场景缩小为 3 个区域而非 4 个 | 节省 5-8 天 | 活动内容略少 |
+| PC RTS 做为最简原型（甚至推迟到 DLC） | 节省 15-20 天 | 内容完整度略降 |
+
+---
+
+## 原型阶段技术路线（v0.1-v0.3）
+
+### v0.1：场景漫游 + 环境交互（验证探索感）
+
+**技术目标**：验证"在千禧年城郊场景中漫步并交互"的核心体验
+
+**开发顺序**：
+
+| 步骤 | 内容 | 工期 | 依赖 |
+|------|------|------|------|
+| 1 | 角色控制器 + 摄像机（基于已有框架调整） | 1-2 天 | 无 |
+| 2 | Enhanced Input 配置（WASD/Shift/E/ESC） | 1 天 | 步骤 1 |
+| 3 | 交互系统核心框架（Interface + Component + 检测） | 2-3 天 | 步骤 1 |
+| 4 | 交互提示 UI（UMG Widget） | 1-2 天 | 步骤 3 |
+| 5 | 叙事文本 UI（打字机效果） | 1-2 天 | 步骤 4 |
+| 6 | 推镜相机系统 | 1-2 天 | 步骤 1 |
+| 7 | 场景白盒（6 区域） | 2-3 天 | 无（可并行） |
+| 8 | 交互物数据填充（10 个第一轮 + 第二轮） | 2-3 天 | 步骤 3-6 |
+| 9 | 收集系统基础（拾取 + 计数） | 1-2 天 | 步骤 3 |
+| 10 | 调试打磨 | 2-3 天 | 全部 |
+
+**v0.1 总工期预估**：10-18 天
+
+**技术选型**：
+- 全部使用 UE5 内置功能，不引入第三方插件
+- C++ 做核心框架，Blueprint 做具体配置
+- 角色：基于已有 ChildHoodCharacter 修改
+
+### v0.2：弹珠小游戏 + NPC 基础（验证小游戏可玩性）
+
+**技术目标**：验证弹珠四维策略系统的操作手感和策略深度
+
+**开发顺序**：
+
+| 步骤 | 内容 | 工期 |
+|------|------|------|
+| 1 | 弹珠操作手感原型（Throwaway） | 2-3 天 |
+| 2 | 弹珠物理系统（Chaos 配置 + 材质参数） | 3-5 天 |
+| 3 | 四维策略数据框架（规则/场地/弹珠/手法 DataAsset） | 3-4 天 |
+| 4 | 弹珠 GameMode + PlayerController | 3-5 天 |
+| 5 | NPC 基础框架（静态站位 + 简单对话文本） | 3-5 天 |
+| 6 | 蹲下系统 | 1-2 天 |
+| 7 | 弹珠与收集系统联动 | 2-3 天 |
+| 8 | 调试打磨 | 3-5 天 |
+
+**v0.2 总工期预估**：20-32 天
+
+**关键风险**：步骤 1 的操作手感验证如果不通过，需要调整操作方案，可能增加 5-10 天。
+
+### v0.3：时间循环 + 经济基础（验证节奏感）
+
+**技术目标**：验证四时段时间循环带来的世界活性感
+
+**开发顺序**：
+
+| 步骤 | 内容 | 工期 |
+|------|------|------|
+| 1 | TimeManager（四时段枚举 + 推进逻辑） | 2-3 天 |
+| 2 | 光影联动（Directional Light + Skybox） | 3-5 天 |
+| 3 | EconomyManager（零花钱 + 购买） | 3-5 天 |
+| 4 | 时段与 NPC 位置联动 | 2-3 天 |
+| 5 | 时段与活动可用性联动 | 2-3 天 |
+| 6 | 基础音效（脚步、环境音） | 3-5 天 |
+| 7 | 调试打磨 | 3-5 天 |
+
+**v0.3 总工期预估**：18-29 天
+
+---
+
+## 风险汇总表
+
+| 系统 | 风险等级 | 核心风险 | 缓解措施 |
+|------|---------|---------|---------|
+| 角色控制器 | 🟢 低 | 几乎无风险 | 基于已有框架，UE5 原生支持 |
+| 交互系统 | 🟢 低 | 推镜相机位置计算 | 提前测试贴墙/角落场景 |
+| 场景白盒 | 🟢 低 | 布局体验需迭代 | 分阶段扩展，v0.1 先验证小场景 |
+| 收集系统（基础） | 🟢 低 | 无显著技术风险 | — |
+| 收集系统（完整） | 🟡 中 | 多系统联动耦合 | 事件总线解耦，逐系统接入 |
+| 时间循环系统 | 🟡 中 | 光影过渡平滑性 | 用 Timeline 渐变而非离散跳变 |
+| 经济系统 | 🟢 低 | 无显著技术风险 | — |
+| NPC 系统 | 🟡 中 | 对话内容量大 | 考虑对话插件，NPC 分阶段交付 |
+| 叙事系统 | 🟡 中 | 多系统耦合 | 事件总线设计，条件系统模块化 |
+| 场景氛围 | 🟡 中 | 声音素材需求量大 | 使用免费音效库，分阶段填充 |
+| **弹珠小游戏** | 🟡 中 | 操作手感验证 | 先做 Throwaway 原型再正式开发 |
+| **四驱车系统** | 🔴 高 | 改装 UI 复杂度 + 赛道物理 | 简化赛道物理，改装 UI 分阶段 |
+| **FC/街机/PC 小游戏** | 🔴 高 | 内容量巨大 | 每个独立迭代，先做 1 个验证 |
+| **整体内容量** | 🔴 高 | 单人开发的工作量天花板 | 严格控制范围，分阶段验证 |
+
+---
+
+## 结论与建议
+
+### 技术可行性判断
+
+**ChildHood 在技术上完全可行**。所有系统在 UE5.7.4 中都有成熟的实现路径，不存在引擎层面的不可行项。项目的真正挑战不在"能不能做"，而在"能不能在合理时间内做完"。
+
+### 关键建议
+
+1. **小游戏是最大风险，也是最大卖点**。弹珠的操作手感和策略深度必须在 v0.2 通过 Playtest 验证。如果弹珠不成立，整个小游戏支柱需要重新评估。
+
+2. **"游戏中的游戏"范围必须砍到最低**。建议 FC/街机每个类型各做 1 个最小可玩版本（2-3 关），验证"坐在电视前玩游戏"的感觉。更多关卡作为内容填充在后续版本追加。PC RTS 可以推迟到 v1.0 之后。
+
+3. **叙事文本应该尽早引入外部协助**。对话文本、物品描述、内心独白——这些不是程序工作，但单人开发意味着这些也需要自己写。建议在 v0.4 叙事阶段考虑找人帮忙写文本。
+
+4. **美术资产策略需要明确**。Lowpoly 资产是否全部自制、是否使用 Marketplace、是否外包——这个决定越早越好。建议优先使用 Marketplace 资产（购买或免费），自制只限于关键特色物件。
+
+5. **项目已有的 Variant_* 代码需要清理**。当前 Source 目录中有 Variant_Combat、Variant_Platforming、Variant_SideScrolling 三个游戏模式的遗留代码，这些与 ChildHood 的核心玩法无关，应该在 v0.1 开始前清理或归档，保持代码库整洁。
+
+6. **原型阶段不追求完美**。v0.1-v0.3 的核心目标是验证假设，不是打磨品质。推镜相机稍微不完美、动画暂时用占位、UI 朴素一些都可以接受——关键是让"在千禧年小街上漫步"的感觉立住。
+
+### 开发工期总预估（单人，含调试）
+
+| 版本 | 核心内容 | 预估工期 |
+|------|---------|---------|
+| v0.1 | 场景漫游 + 环境交互 | 10-18 天 |
+| v0.2 | 弹珠 + NPC 基础 + 蹲下 | 20-32 天 |
+| v0.3 | 时间循环 + 经济 + 音效 | 18-29 天 |
+| v0.4 | 叙事框架 + 核心角色 | 20-30 天 |
+| v0.5 | 四驱车 + FC/街机 + 收集扩展 | 40-60 天 |
+| v0.6 | 乡下场景 | 15-25 天 |
+| v0.7 | 整合 + 多支线 + 结局 | 20-30 天 |
+| v1.0 | 打磨发布 | 15-25 天 |
+| **总计** | | **158-249 天（约 5-8 个月）** |
+
+> 以上为全职投入的预估。如果兼职开发，需要按比例延长。关键路径在 v0.2（弹珠验证）和 v0.5（内容高峰）。
+
+### 最终结论
+
+**建议进入原型阶段（v0.1）**。技术可行性已验证通过，不存在阻塞项。v0.1 的 10-18 天投入是低风险的——即使最终发现"探索感"不成立，损失也可控。但基于设计文档的质量和参考游戏的成功先例，对 v0.1 验证通过的判断是乐观的。