大云身世与剧情灵感草案
状态：灵感草案 v0.1 · 2026-10-14。包含后续剧情方向剧透。本文记录创作方向，不是定稿剧本、开发排期或已实现功能说明。
记录范围与唯一来源
剧情设计在 gza/docs/ 统一维护；dayun-kicker 的实现任务与剧本后续引用本文，不另存一份同内容设定，也不另建飞书知识库。当前只记录灵感，不修改游戏脚本、任务、存档或首章验收结论。
实际首章以第一章 · 粥还热为准，角色当前呈现见人物与载具，剧情接入边界见 ADV.JS 剧情接入。
用户提出的背景方向
以下来自 2026-10-14 的剧情讨论，作为本轮灵感的起点；背景尚不等于已写入游戏：
- 主角叫大云，曾是科技公司的一名程序员。
- 失业后开始送外卖。
- 开场不直接把过去告诉玩家。
- 随丧尸危机爆发，在剧情模式中逐层揭示他的故事。
“失业”不自动等于某一种裁员事件；失业经过、个人态度与具体履历暂不补定。玩家不知道他的过去，也不意味着大云失忆，或所有身边人物都不知情。
候选四层揭示
以下分层、桥段和对白意图均为候选，不锁定章节数、先后任务或最终因果。每一层先让玩家做一件当下有意义的事，再获得少量新信息。
| 层次 | 候选体验 | 玩家可能知道什么 | 保留的悬念 |
|---|---|---|---|
| 1. 骑手日常进入危机 | 从接单、认路、记住街坊叮嘱开始；订单备注或熟悉门口的变化带来异常 | 大云是正在努力做好配送的骑手，城市正在发生危险 | 不交代履历，也不让异常订单自动成为阴谋证据 |
| 2. 技术习惯露出线索 | 在救援或补给途中，他习惯先排查设备故障、辨认系统提示，或把复杂步骤拆开处理 | 他有超出眼前工作的旧经验 | 技术习惯不足以证明他了解危机原因；不出现万能破解 |
| 3. 旧身份被认出 | 在有现实任务理由的重逢中，由旧同事称呼、旧工牌等线索之一引出短对白 | 玩家逐步确认他曾在科技公司做程序员，失业后送外卖 | 公司名称、离职经过与同事立场仍可留白；不要求收集全部物件才看懂主线 |
| 4. 过去与现在共同支撑选择 | 后续救援或据点任务同时需要有限的技术排障、熟悉街巷、判断路线，以及与街坊协作 | 两段经历都构成今天的大云，他的选择比身份标签更重要 | 具体抉择、代价、章节落点和结局待讨论 |
可选的小桥段
- 同一个送餐地址，早先记住的门口细节在危机中帮助找到接应路线。优先利用现有阿婆两单的情感与空间记忆，不重复新建一套同质救援。
- 某次设备故障时，大云先问“什么时候开始不对劲的”，完成有限排查后仍需要修车师傅、值守人员或原设备负责人配合。技术经验有用，但不替代别人的专业。
- 旧同事第一次见到外卖箱时，先回应眼前的救援任务，再自然问起近况。避免用“沦落送外卖”式对白制造职业高低。
- 一件旧物可以补足关系和情绪，但不承担理解主线所必需的唯一证据。
这些只是可删改的场景种子，不代表新增 NPC、道具、交互系统或已授权实施的任务。
与现有首章衔接
目前文档未发现“大云曾是程序员、失业后送外卖”的明确相反设定，但以下衔接处不能直接替换或推定：
| 现有内容 | 本草案的处理 | 待确认点 |
|---|---|---|
| 客村登记、园区午餐、阿婆两单、滨江咖啡遭遇、密送试用药、祠堂补给与收尾 | 保留现有任务链与首章完成条件；第一层优先借用现有日常到危机的节奏 | 首章是否只埋一处轻线索，身份确认是否放到后续章节 |
| 陈叔的身份通过安排与街坊信任逐步显现 | 保留他的独立人物线，不把其隐而不宣的身份机制机械复制给大云 | 两条人物线如何错开信息量，避免同时揭谜 |
| 文档称“解药”，首章具体说明为数量有限的试用药 | 保留现有术语与表述，不改成已证明治愈一切的药物 | 后续是否需要统一术语与疗效边界，另行讨论 |
| 玩家在客村办理骑手登记 | 不推断这一定是大云人生中的第一天送餐 | 是首次入行、换站登记还是任务教学抽象，待确认 |
| 地图出现现实医院、园区与企业地标 | 场景参考不等于虚构危机的责任归属 | 若设计旧公司，应单独确认虚构名称与表达边界 |
本轮不扩展首发章节范围，不把原来已记录的测试结果用于证明新背景已实现。若后续发现剧本或其他设定冲突，保留双方内容并记为“待确认”，不静默覆盖。
叙事边界
- 主线要让不做支线的玩家理解：大云当前在帮谁、为什么行动、危险在哪里，以及关键身份信息如何影响当下选择。
- 支线、旧物与可选对白补充关系、生活细节和情绪，不补主线缺失的必要因果。
- 不默认旧公司制造病毒，也不把旧公司与危机存在关联当成既定事实。危机是否由病毒引起也未定。
- 程序员经历只带来有范围的经验，不让大云独自掌握医学、军事或城市全部系统，不塑造成凭职业标签拯救所有人的救世主。
- 骑手经历提供真实的路线经验、沟通、应变与人际信任，不是等待“恢复真正身份”的低谷占位。
- 广州街坊、医护、骑手和其他人物保留自己的能力与选择；大云在共同协作中发挥作用。
暂不确定
公司名称与业务、失业或裁员原因、危机起因、公司与危机是否有关、旧同事身份与立场、关键选择与结局均未定。暂不补年份、部门、技术专长、阴谋组织、亲属背景或人物死亡等正式设定。
迭代方式
- 新灵感先标“候选”，写清它服务的人物变化、玩家行动与揭示的信息；能复用现有场景时不先加新系统。
- 每轮只挑少量值得验证的桥段，核对首章、人物和实际剧本；疑点单列“待确认”。
- 经讨论选定的内容标“设计确认”，同时记录日期、采用理由和替代方案；未采用内容保留简短原因或移入备选，不混入现行设定。
- 进入实现后关联具体任务或 PR；只有核实脚本、交互、存档与相关测试后才标“已实现”，并更新对应玩家文档。本文不能代替验收记录。
下一轮优先讨论
- 首章只埋技术习惯，还是结尾允许确认“以前写过程序”？
- 骑手登记如何解释，才能兼容既有送餐经验与教学流程？
- 优先塑造哪种过去与现在的关系：重新认识自己的能力、修复旧关系，还是先把眼前的人照顾好？可以并存，但先选重心。
- 是否需要旧公司与危机有关？若暂不需要，就继续留白，不为制造悬念强行关联。
变更记录
- 2026-10-14 · v0.1：记录用户提出的背景方向、四层候选结构、与首章的衔接边界和待讨论问题；未修改游戏实现。