简化顶层设计规则与架构衔接

精简顶层写作规则与模板，取消固定循环层级、资源消耗链和失败档位要求重组星露谷顶层样例，修正选择收益与损失描述并区分原型和完整版本范围同步架构玩法覆盖检查、顶层阶段提示和TDD简介，保留施工完备要求更新策划Agent技术文档和共享决策记录
2026-09-27 15:59:20 +00:00
parent 46024b5043
commit 89a901e329
10 changed files with 168 additions and 456 deletions
@@ -1 +1 @@
-当前阶段：顶层设计。明确玩家持续游玩的循环、资源流、节奏和系统范围。
+当前阶段：顶层设计。明确游玩过程、关键规则与反馈、版本范围和验证计划，为系统划分提供依据。
@@ -116,9 +116,9 @@ flowchart LR
 - 系统之间通过稳定 ID 关联（物品 ID、NPC ID、区域 ID、任务 ID、配方 ID）。
 - 任何系统都不复制另一系统的主数据；任务只引用物品 ID，不重新定义物品价格。

-## 核心循环覆盖检查
+## 玩法覆盖检查

-| 顶层循环环节 | 认领系统 |
+| 顶层玩法环节或关键规则 | 负责或协作系统 |
 |---|---|
 | 查看天气、日程与目标 | S01、S11、S12、UI |
 | 选择活动并移动 | S04、S02 |
@@ -1,182 +1,112 @@
 # 顶层设计：《星露谷物语》

-## 顶层定位与规模锚点
-顶层不是做长线农场生产线，也不是做以探索战斗为主的活动清单，而是让玩家每天都在想：
-> "今天做什么？——下雨天不用浇水，正好下矿井；回来的路上把罗宾的生日礼物送了。"
+## 玩法目标

-| 项 | 定义 |
-|---|---|
-| 循环单位 | 一个游戏日（约 10~20 分钟） |
-| 段落构成 | 日初规划 → 白天执行（农务/探索/社交）→ 日落结算 |
-| 操作复杂度 | 低——单人键鼠交互，无动作门槛 |
-| 经营复杂度 | 中——时间、体力、资金三约束下的日程规划；不做生产线布局优化 |
-| 长期主轴 | 第一：农场与生活方式成型；第二：社区修复与技能成长；角色数值只做辅助 |
+以一个游戏日组织慢节奏的农场生活。玩家根据天气、农场状态、居民日程和自己的目标安排活动，再将当天的成果投入后续生活。时间与体力提供温和的规划压力，农场、探索与社交共同支持不同的生活方式。

-## 设计目标
-让玩家在一个没有唯一正确答案的乡村生活循环中，同时获得三种回报：
- 轻松生活：可以按自己的兴趣安排一天，通过农场、装饰、收集和社交获得稳定的正反馈。
- 规划掌控：时间、体力、季节和资金构成可理解的取舍，提前准备会让未来更高效。
- 探索成长：探索区域、战斗和资源发现提供变化与风险，并将成果转化为农场与角色的长期改善。
+主要回报包括自由安排日常的放松感、通过规划改善生活的掌控感，以及探索新资源、区域和人际关系的发现感。农场提供稳定产出，探索带来原料和新内容，社交带来配方、剧情与情感回报；这些关系帮助玩家形成自己的计划。

-三者互相供给：农场提供稳定资源与恢复空间，探索提供稀有资源和发现，社交与社区目标提供方向和情感回报。
+农场与生活方式成型是长期主轴，社区修复与技能成长提供阶段目标。战斗是探索中的伴生风险，不扩展为高难度动作或装备构筑主轴；制作服务于日常投资，不扩展为生产线布局优化。

-## 核心推动力
-玩家每天拥有有限的时间与体力，但可以在一天结束后保留成果，并把收益投入到工具、设施、种子、装备和关系中。短期的"今天做什么"决策，持续转化为长期的"我的生活变得怎样"。
+## 游玩过程与节奏

-主要推动力按层次排列：
-1. **即时推动**：完成一次采集、收获、战斗或对话，立即得到物品、金钱、经验、信息或关系进展。
-2. **日程推动**：在日落或体力耗尽前完成今天最重要的目标。
-3. **季节推动**：抓住作物、鱼类、节日和任务的时间窗口，准备下一阶段。
-4. **长期推动**：改善农场、解锁区域和设施、完成社区目标、掌握技能，并建立属于自己的生活方式。
+一个常规游戏日目标约为 10～20 分钟，具体节奏需通过试玩调整。单人键鼠操作以日常行动为主，不以操作精度制造门槛。

-## 大循环
-**规划一天 → 执行活动 → 获得资源与关系进展 → 出售、加工或投资 → 解锁更高效率与新内容 → 进入下一天。**
-
-在更长周期中：**完成一个季节目标 → 调整生产与探索计划 → 迎接新季节 → 修复社区或解锁区域 → 扩大玩家可选择的生活方式。**
-
-```mermaid
-flowchart LR
-  A[规划一天] --> B[执行农务/探索/社交]
-  B --> C[获得资源·金钱·经验·关系]
-  C --> D[出售/加工/投资]
-  D --> E[解锁效率与新内容]
-  E --> F[进入下一天]
-  F --> A
-```
-
-## 小循环
-
-### 农务循环
-清理土地、播种或饲养 → 每日维护 → 等待成长 → 收获 → 出售或加工 → 将收益投入下一轮生产。
-
-### 探索循环
-选择目的地与携带物资 → 在有限体力和时间内采集、钓鱼或战斗 → 判断继续深入还是返程 → 带回资源 → 用于升级、制作或出售。
-
-### 社交循环
-寻找 NPC → 观察其日程与需求 → 对话、赠礼或完成委托 → 提升关系 → 解锁新对话、事件、配方或功能。
-
-### 成长循环
-重复使用某类能力 → 获得经验并提升技能 → 获得效率、工具或职业选择 → 以更低成本完成同类活动，并接触更高阶内容。
-
-## 资源流与输入输出
-
-```mermaid
-flowchart LR
-  F[农场生产] -->|作物·畜产品| S[出售与加工]
-  E[采集·钓鱼·采矿·战斗] -->|原料·鱼类·矿物·战利品| S
-  S -->|金钱| I[工具·设施·种子·装备]
-  I -->|效率提升| F
-  E -->|经验| K[技能成长]
-  K -->|效率·配方| F
-  G[社交] -->|关系进展| R[新对话·事件·配方]
-  R --> G
-```
-
- 主要输入：时间与体力；金钱、种子、原材料和消耗品；工具、装备和技能；NPC 关系、任务状态和社区进度；天气、季节、地图位置和活动开放状态。
- 主要输出：农产品、采集物、鱼类、矿物、战利品和加工品；金钱、技能经验、工具/设施升级；地图区域、配方、任务、事件和 NPC 关系解锁；农场外观、生产能力和社区状态变化。
- 反馈四层：
-  - 立即反馈：动画、音效、图标、数字、资源变更和状态变化。
-  - 短期反馈：背包、金钱、任务和技能面板更新。
-  - 中期反馈：设施完成、工具升级、关系事件和新区域开放。
-  - 长期反馈：农场自动化、社区恢复、生活方式成型和终局目标完成。
-
-## 最小体验单位
-一个约 10~20 分钟的"游戏日"：查看状态 → 选一个主目标与一两个顺路次目标 → 执行 → 在时间或体力约束下结束 → 结算并获得当日反馈，决定明天是否继续当前计划或转换方向。
-
-单个行动必须至少提供一种清晰反馈：资源增加、进度推进、能力提升、关系变化、地图信息或视觉状态变化。
-
-## 核心活动流程
-
-| 阶段 | 玩家行为 | 设计目的 |
+| 环节 | 玩家行为 | 对体验的作用 |
 |---|---|---|
-| 日初 | 查看天气、季节、农场状态、商店或任务提示 | 给当天决策提供完整状态 |
-| 目标选择 | 从生产、赚钱、探索、成长、社交和社区目标中确定优先级 | 制造当日取舍（张力兑现处） |
-| 准备与出发 | 整理背包，携带工具、消耗品和必要装备 | 投入成本前置，增强方向感 |
-| 执行活动 | 完成一组有空间关系或时间关系的行动 | 核心玩法发生地 |
-| 中途调整 | 根据体力、时间、掉落和突发事件，决定继续、转向或返程 | 张力的实时兑现 |
-| 结算与投资 | 出售或加工资源，购买材料，安排设施和下一轮生产 | 回流与长期化 |
-| 日终反馈 | 记录技能、关系、任务、生产和解锁变化，进入下一天 | 闭合并钩住明天 |
+| 日初与计划 | 查看天气、季节、农场状态、商店或任务信息，决定今天的优先级 | 让玩家根据当前条件选择目标 |
+| 准备与出发 | 整理背包，携带工具、消耗品和必要装备 | 为选定活动投入资源 |
+| 活动与调整 | 完成农务、采集、钓鱼、采矿、战斗或社交，根据时间、体力和发现调整计划 | 让选择产生可感知的结果 |
+| 结算与投资 | 出售或加工资源，购买材料，安排设施和下一轮生产 | 将当天成果转为后续机会 |
+| 日终 | 展示技能、关系、任务、生产与解锁变化，保存并进入下一天 | 保留进展，并为次日计划提供信息 |

-## 取舍表
+不同活动的过程与时间跨度有所区别：

-| 决策 | 立即收益 | 延迟收益 | 主要代价 |
-|---|---|---|---|
-| 出售原料还是加工（张力2） | 快速获得资金 | 更高价值或新用途 | 占用设备与等待时间 |
-| 留在农场还是外出探索（张力3） | 稳定推进生产 | 稀有资源与发现 | 错过维护或消耗补给 |
-| 深入探索还是及时返程（张力3） | 更多资源与经验 | 更高风险和返程压力 | 可能损失当日效率或物资 |
-| 购买工具升级还是扩大生产（张力2） | 提高行动效率 | 增加产量与收入 | 当前资金减少 |
-| 赚钱还是社交（张力4） | 直接经济进展 | 关系、剧情和配方回报 | 消耗可用于生产的时间 |
-| 追求效率还是装饰与兴趣（张力5） | 更快成长 | 个性化与放松体验 | 放弃部分短期收益 |
+- 农务：清理土地、播种或饲养，经过维护与成长后收获，再出售、加工或投入下一轮生产。
+- 探索：选择目的地和携带物资，在时间与体力限制下活动，权衡继续深入或返程，再把成果用于升级、制作或出售。
+- 社交：寻找居民，观察日程与需求，通过对话、赠礼或委托发展关系，解锁对话、事件、配方或功能。
+- 成长：使用能力积累经验，获得技能、效率、工具或职业选择，从而接触新的活动内容。

-（张力1"时间与体力有限"由目标选择阶段整体承载。）设计原则：这些选择应产生不同的合理生活方式，而不是把玩家逼向唯一最优路线。
+天气、营业时间和居民日程让日常计划发生变化。季初准备、季中经营和季末收获形成更长节奏；季节更替改变作物、资源、节日和目标。长期则从手工劳动推进到工具升级、自动化设施、新区域和更复杂的人际目标。

-## 节奏结构
- **日内节奏**：信息确认 → 连续行动 → 资源或发现反馈 → 体力/时间压力 → 日终结算。
- **周内节奏**：工作日进行生产与探索，商店营业、NPC 日程和周期事件制造计划变化。
- **季节节奏**：季初准备，季中稳定经营，季末收获与总结；季节变化带来资源、作物、天气和目标变化。
- **长期节奏**：从手工劳动起步，逐步获得工具升级、自动化设施、新区域和更复杂的关系目标。
+农场与小镇提供熟悉、安定的活动，探索与事件提供变化。节奏应容纳效率型和休闲型玩家，不把每天的任务完成率作为唯一价值。

-整体情绪应在"安定的重复"和"偶尔的发现"之间摆动：农场与城镇提供恢复，探索与事件提供变化。
+## 资源与进展

-## 失败与回收
-失败主要表现为"少拿与顺延"，不毁掉既有积累。
+- 时间与体力限制当天可以完成的行动；天气、季节、位置和活动开放状态影响行动机会。
+- 金钱、种子、原料与消耗品投入生产、制作或探索，转化为农产品、加工品、发现和后续投资能力。背包与设备容量影响携带、加工和安排。
+- 工具、装备、设施与技能改变行动效率和可选活动。经验积累用于成长，不要求玩家把经验作为货币消耗。
+- NPC 关系、任务状态和社区进度记录持续进展，带来对话、事件、配方与区域解锁。
+- 农场外观、生产能力和社区状态展示长期生活变化。

-| 情况 | 结果 |
-|---|---|
-| 当日计划未完成 | 成果顺延到明天，无惩罚；次日优先级重排 |
-| 深夜未归昏倒 | 当日行动终止，次日体力受限，轻度损失 |
-| 矿井中倒下 | 损失部分金钱或物品，保留大部分积累 |
-| 季节更替未收获 | 该季作物枯萎——日历压力的主要形式 |
-| 错过节日或窗口期 | 顺延至下个周期，制造轻度遗憾而非惩罚 |
+行动结果通过相应的动画、音效、资源或状态变化表现；背包与面板显示当前结果，设施完成、关系事件和区域开放表现更长周期的进展。重要变化应能被玩家理解，不依赖外部攻略才能形成下一步计划。

-## 系统范围
+## 选择与后果

-| 系统 | 顶层目的 | 边界（本层不做什么） |
+时间与体力有限，选择一项活动会挤占其他活动的空间。本例希望不同选择支持不同的生活方式，不把玩家逼向唯一效率路线。
+
+| 选择 | 方案 A 的收益与代价 | 方案 B 的收益与代价 |
 |---|---|---|
-| 农场经营 | 承载规划与回报的核心场 | 不做布局优化向的生产线 |
-| 时间与体力 | 全局硬约束、日程的标尺 | 不做饥饿等生存需求式衰减 |
-| 探索与采集（矿井/钓鱼/采集） | 提供风险与发现 | 不做程序生成的无限地牢 |
-| 轻度战斗 | 矿井探索的风险与节奏变化 | 不做装备驱动的成长主轴 |
-| 物品与制作 | 资源的转化与长期投资 | 不做复杂配方树管理 |
-| 技能成长 | 使用即成长的回报层 | 不做技能树构筑 |
-| NPC 关系与任务 | 社区叙事与情感回报 | 不做分支剧情引擎 |
-| 经济与商店 | 连接产出与投资 | 不做玩家间交易市场 |
-| 季节天气与节日 | 时间压力与变化来源 | 不做动态天气模拟 |
-| 日终结算 | 闭合一天并钩住下一天 | — |
+| 出售原料或加工 | 出售可立即获得资金，但放弃加工增值或其他用途 | 加工可能提高价值，但占用设备并需要等待 |
+| 留在农场或外出探索 | 农场收益较稳定，但会放弃部分探索机会 | 探索带来稀有资源和发现，但消耗补给并占用维护时间 |
+| 深入探索或及时返程 | 深入可能增加资源与经验，也提高倒下或来不及返程的风险 | 返程保住已得成果并可安排其他活动，但放弃继续发现的机会 |
+| 升级工具或扩大生产 | 升级提升行动效率，但占用可用于扩产的资金 | 扩产提高产出潜力，但增加维护负担并推迟工具改善 |
+| 赚钱或社交 | 赚钱加快当前投资，但减少发展关系的时间 | 社交带来关系与后续回报，但放弃部分眼前收入 |
+| 追求效率或装饰与兴趣 | 效率安排加快成长，但减少自由探索和个性化活动 | 兴趣活动带来放松和表达，但可能减缓短期经济成长 |

-## 范围与非目标
-最小完整版本包含：
- 一个可经营农场
- 一个小镇与若干功能区域
- 基础农务、采集、钓鱼、制作、轻度战斗和探索
- 有日程的 NPC、关系值、任务和社区目标
- 工具/技能成长、商店经济与基础加工链
- 季节、天气、节日和日终结算
+失败允许局部损失和机会错过，同时保留大部分长期进展。不同场景的后果需要分别判断，不能把温和压力理解为完全没有损失。

-不做清单：
- 不做无缝大型开放世界
- 不做复杂实时多人或玩家交易市场
- 不做以操作精度为核心的高难度战斗
- 不为每个系统都添加独立小游戏
- 不在本阶段确定具体数值、完整内容数量或实现方案
-
-## 验证标准
-
-| 验证点 | 成功标准 |
+| 情况 | 后果与恢复 |
 |---|---|
-| 一天循环成立 | 玩家能复述"今天做了什么、为什么、明天想做什么" |
-| 取舍真实存在 | 玩家在目标选择阶段出现可观察的犹豫或计划调整 |
-| 时间压力温和 | 玩家感到"今天做不完"而不是"今天被逼着做" |
-| 回流成立 | 玩家能把当日收益明确投入到下一轮计划 |
-| 长期钩子成立 | 玩家能说出自己"在为什么长期目标积累" |
+| 普通日常计划未完成 | 可继续的目标移到后续日期，重新安排优先级；限时目标按自身窗口处理 |
+| 深夜未归昏倒 | 当日行动终止，次日体力受限并有轻度损失，之后重新安排活动 |
+| 矿井中倒下 | 损失部分金钱或物品，保留大部分积累，补充准备后再探索 |
+| 季节更替未收获 | 不适应新季节的作物枯萎，需要改种；土地和已有设施仍可继续使用 |
+| 错过节日或窗口期 | 失去本次机会，等待后续周期或调整目标 |

-## 开放问题
- 休闲玩家与规划玩家的时间/体力压力如何共存？
- 战斗在整体游戏中的最低必要深度是什么，如何避免压过生活模拟？
- 社区目标应采用线性章节、可选收集，还是两者结合？
- 终局是明确的阶段性结算，还是允许玩家在结算后继续自由生活？
- 哪些信息必须通过 UI 直接展示，哪些信息可以保留为探索发现？
+损失幅度和恢复成本需结合试玩判断，不应把一次失误放大为长期无法恢复的挫败。

-## 顶层定稿
-顶层当前定稿为：以一个游戏日为循环单位，时间与体力构成温和硬约束，农场、探索、社交三线互相供给的慢节奏生活循环；矿井战斗保持伴生风险定位，失败只造成少拿与顺延。
-后续架构必须围绕"一天"拆系统（时间/农场/探索/社交/经济/成长/结算）；不得把战斗、制作或任何支线做成独立主轴，不得引入生存焦虑型惩罚。
+## 系统范围与版本边界
+
+以下是支撑完整版本的能力范围，架构层可按职责拆分或合并。
+
+| 能力方向 | 目的与主要联系 | 边界 |
+|---|---|---|
+| 农场经营 | 承载规划与回报，与物品、制作和经济连接 | 不做生产线布局优化 |
+| 时间与体力 | 限制行动并影响日程选择 | 不做饥饿等生存需求式衰减 |
+| 探索与采集 | 提供资源、风险与发现，成果回到制作和投资 | 不做无限程序生成地牢 |
+| 轻度战斗 | 为矿井探索提供风险与节奏变化 | 不做装备驱动的成长主轴 |
+| 物品与制作 | 支持携带、资源转化与长期投资 | 不做复杂配方树管理 |
+| 技能成长 | 回应重复实践，改变效率与可选内容 | 不做技能树构筑 |
+| NPC 关系与任务 | 承载社区叙事与情感回报 | 不做分支剧情引擎 |
+| 经济与商店 | 连接产出、交易与投资 | 不做玩家间交易市场 |
+| 季节天气与节日 | 改变行动条件与阶段目标 | 不做动态天气模拟 |
+| 日终结算 | 汇总各活动进展，衔接次日与保存 | 不重复定义各活动的奖励规则 |
+
+本例完整版本包含可经营农场、小镇与功能区域，基础农务、采集、钓鱼、制作、轻度战斗和探索，以及居民日程、关系、任务、社区目标、工具与技能成长、商店加工、季节天气和节日。具体内容数量与详细规格后续展开。
+
+范围排除无缝大型开放世界、复杂实时多人、玩家交易市场、高难度战斗，以及为每个系统附加独立小游戏。
+
+## 原型验证与开放问题
+
+以下是验证计划，尚不代表已经通过试玩。原型按问题分步覆盖，不要求一次实现完整版本。
+
+| 需要判断的问题 | 原型范围与游玩跨度 | 判断依据 |
+|---|---|---|
+| 日常计划能否形成有意义的选择 | 一个游戏日，包含农务、基础外出采集、时间体力与结算 | 观察目标选择与中途调整，结合玩家对选择理由的说明，判断限制是否真正影响行动 |
+| 当天成果能否支持后续计划 | 连续数个游戏日，包含作物成长与收获、出售、种子或工具投资、基础成长 | 观察收益是否进入下一轮活动，并询问玩家接下来想改善什么；仅能复述流程不足以证明愿意继续 |
+| 时间压力是否符合休闲体验 | 让偏休闲与偏规划的玩家尝试上述日常流程 | 结合未完成计划的频率、返程行为和体验反馈，判断是可接受的取舍还是被任务催促 |
+| 轻度战斗是否改善探索节奏 | 基础日常流程后加入一个矿井遭遇 | 观察理解、停顿和损失后的恢复，结合玩家反馈判断战斗是否压过探索与生活体验 |
+| 社区与成长能否形成长期目标 | 后续加入代表性的关系事件与社区目标，保留必要的多日推进 | 观察玩家是否愿意投入、如何解释目标价值；单日原型不据此宣称长期体验成立 |
+
+首个原型聚焦农务、基础地图与采集、时间体力、物品、经济、基础成长和日终结算。钓鱼深度、节日全量、完整社区内容和更多区域不作为首个原型的必需内容。
+
+后续仍需展开的问题包括：
+
+- 时间、体力和损失的具体幅度：核心方向已明确为温和规划压力，通过原型比较具体参数。
+- 战斗的最低必要深度：根据代表性遭遇的试玩结果确定，再补齐系统规格。
+- 社区目标采用章节、可选收集还是结合：在社区内容进入实现范围前明确，以便架构判断相应能力。
+- 终局结算与后续自由生活：不阻塞早期日常原型，在确定完整版本的终局内容前解决。
+- UI 直接展示与探索发现的边界：先保证原型的关键行动与结果可理解，再结合试玩展开详细信息设计。
+
+这些问题若改变当前范围或关键玩法，应回到受影响的正文调整，不能只留在问题清单中。
@@ -3,7 +3,7 @@
 ---
 name: game-gdd-architecture
 description: 写游戏策划案（GDD）系统架构时使用。在顶层设计定稿之后，
-  把顶层的系统范围表正式切成 Sxx 系统：编号、职责、依赖、数据流、优先级，
+  把顶层的能力范围正式切成 Sxx 系统：编号、职责、依赖、数据流、优先级，
  并向系统文档交付目录映射与 MVP 闭环。配套：templates/architecture.md、
  templates/analysis.md（全局一份）、exemplars/stardew-architecture.md、templates/stardew-analysis.md（全局一份）。
 ---
@@ -25,15 +25,15 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
 - **依赖无环**是硬要求；信息呈现层只读状态、只经行动入口写入。
 - 架构是全项目返工最多的一份（实测 11 版 vs 概念层 2 版）——所以每次改刀
  都要写变更记录，让"为什么这么切"可追溯。
- 你不越层：上不重定义玩法循环（那是顶层的），下不写单系统内部规则
+- 你不越层：上不重定义玩法过程（那是顶层的），下不写单系统内部规则
  （那是系统文档的），字段定义与数值配置归技术文档层（数值策划）。

 ## 二、动笔前
-1. 顶层设计已定稿可用——把它的**系统范围表**（粗清单）和**顶层定稿约束**
-   摊开当输入；切分是对粗清单的正式化（拆、并、裁都在这层做）。
+1. 顶层设计已定稿可用——以其中的玩法过程、能力范围、版本边界和验证计划为输入；
+   按职责拆分、合并系统，不要求与顶层清单逐项对应。需要改变已定范围时先讨论相关决定。
 2. 读取 exemplars/stardew-architecture.md 了解内容组织方式，
   然后往 templates/architecture.md 里填。
-3. 记住顶层的核心循环图——切完必须跑覆盖检查。
+3. 根据顶层已有的文字、表格或图检查玩法覆盖，不要求额外补画固定循环图。

 ## 三、架构设计的组织维度：写什么、为什么、怎么咬合

@@ -41,15 +41,15 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
 **这个架构为什么这样切（1~3）→ 系统是什么、怎么连接（4~6）→
 怎么落地、怎么验证（7~11）→ 还有什么没想清（12）。**

-第 1 节承顶层的定稿约束开篇，MVP 闭环在中间当守门员，开放问题收尾。
+第 1 节承顶层已确定的范围与约束开篇，MVP 闭环在中间当守门员，开放问题收尾。

 | # | 节 | 是什么 | 为什么写 | 和谁咬合 |
 |---|---|---|---|---|
-| 1 | 架构定位与目标 | 阶段边界（定哪些系统、不展开内部）+ 划分原则 + 一句话架构 + **变更记录** | 防止架构漂离顶层；改刀可追溯 | 承顶层定稿；必要时引用相关分析 |
+| 1 | 架构定位与目标 | 阶段边界（定哪些系统、不展开内部）+ 划分原则 + 一句话架构 + **变更记录** | 防止架构漂离顶层；改刀可追溯 | 承顶层已确定的范围与约束；必要时引用相关分析 |
 | 2 | 系统地图 | Sxx 编号清单（=系统文档范围真源）+ 支撑层 + P0 段五列表（目的/输入/输出/P0原因） | 编号让系统可引用；P0 原因逼答"删了塌什么" | **对下真源**：Sxx ↔ 04 系统文档一一对应 |
 | 3 | 系统职责 | 职责表（负责/不负责→移交谁）+ 逐系统说明段 | 边界写死，防两个系统管同一件事 | 系统文档的"边界与非目标"必须与此对齐 |
-| 4 | 依赖与数据流 | 依赖图（无环）+ 数据流图 + 主要状态 + 主数据归属规则 | 谁读谁、数据从哪到哪——接口的真源 | 顶层的资源流图在此展开成系统级 |
-| 5 | 核心循环覆盖检查 | 顶层每个循环环节 → 认领系统 | 顶层→架构的验收线，防切系统切碎循环 | 对上接口：逐环节对照顶层循环图 |
+| 4 | 依赖与数据流 | 依赖图（无环）+ 数据流图 + 主要状态 + 主数据归属规则 | 谁读谁、数据从哪到哪——接口的真源 | 顶层的资源与进展关系在此展开成系统级 |
+| 5 | 玩法覆盖检查 | 顶层玩法环节与关键规则 → 负责或协作系统 | 防止系统切分遗漏玩法能力 | 对照顶层已有的玩法描述，检查职责覆盖与分工 |
 | 6 | 目录映射 | 职责 → 物理文档目录的归并表 | 职责数≠文档数；归并规则显式化 | **对下接口**：系统文档照此开工 |
 | 7 | MVP 最小闭环 | 编号验证链 + 守门句（"闭环不成立不许加东西"） | 立项后第一条要跑通的链 | 对应顶层验证标准；失败回顶层而非加系统 |
 | 8 | 统一数值基准 | 单位清单 + 四类定性基准（时间/货币/成长/体力风险的风格约束） | 各系统单独配数值会互相失衡；先定全局尺度 | **数值换算与验算归技术文档层**，此处只到定性 |
@@ -61,11 +61,11 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
 咬合一图：

 ```
-顶层定稿 + 系统范围表（粗清单）
+顶层玩法过程、能力范围与版本边界
        ↓ 正式切分（拆/并/裁）
 1 定位与目标 ──► 2 系统地图（Sxx 真源）──► 3 职责表
        ↓                ↓                      ↓
-5 循环覆盖检查 ◄── 4 依赖与数据流（接口真源）
+5 玩法覆盖检查 ◄── 4 依赖与数据流（接口真源）
        ↓
 6 目录映射 ──► 7 MVP 最小闭环（守门员）
        ↓
@@ -74,16 +74,16 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
 12 开放问题 →（进分析文档 / 系统文档开题）
 ```

-三个接口：**对上**承顶层系统范围表并跑循环覆盖检查；**对内**地图↔职责↔依赖
+三个接口：**对上**承顶层能力范围并跑玩法覆盖检查；**对内**地图↔职责↔依赖
 三方一致、主数据归属唯一；**对下**目录映射 + MVP 闭环喂系统文档。

 ## 四、怎么写（模板参考结构，建议按此组织）
 （本节是带写法要领的教学版；实际填写的纯净模板在 templates/architecture.md）

 ### 1. 架构定位与目标
-本阶段确定"哪些系统支撑一轮玩法"，不展开单系统内部规则。
+本阶段确定哪些系统支撑已确定的玩法与版本范围，不展开单系统内部规则。
 划分原则：__。一句话架构：
-> （玩家通过哪些系统、以什么因果，把一轮玩法的输入变成下一轮的选择）
+> （玩家通过哪些系统完成主要行动，结果如何推动过程继续或结束）
 变更记录：日期 + 改了什么 + 为什么，必要时引用相关分析。
 → 没有变更记录的架构文档，第二轮迭代就会变成黑箱。

@@ -104,9 +104,9 @@ P0 段五列表：
 主数据归属规则：规则与数据表分工 / 稳定 ID 关联 / 任何系统不复制他系统主数据。
 → 依赖图出现环 = 回去重切。

-### 5. 核心循环覆盖检查
-| 顶层循环环节 | 认领系统 |
-→ 逐环节对照顶层循环图；有环节无人认领或多人认领都是切分错误。
+### 5. 玩法覆盖检查
+| 顶层玩法环节或关键规则 | 负责或协作系统 |
+→ 对照顶层已有的玩法描述，检查当前范围内的能力是否遗漏；多个系统共同支持一个环节时，明确分工，避免同一职责由多个系统重复维护。

 ### 6. 目录映射
 | 目录 | 本阶段定位 |
@@ -114,6 +114,7 @@ P0 段五列表：
 系统文档以此开工：地图上没有的系统不许有文档。

 ### 7. MVP 最小闭环
+依据顶层的版本范围与验证计划，确定最先实现的完整可玩流程；可以是线性推进或循环，不固定为单个体验片段。
 1. __ 2. __ …（编号验证链，一条玩家可走的完整因果）
 守门句：如果这条闭环不成立，不应继续增加 __。
 → 闭环失败回顶层改设计，不是加系统打补丁。
@@ -132,7 +133,7 @@ P1/P2 可用能力表（能力/说明）控制颗粒度。

 ### 11. 风险与校验
 | 风险 | 校验方式 |
-→ 从概念层跑偏风险和顶层失败档位反推；校验方式要可观察。
+→ 结合概念层跑偏风险、顶层关键规则与验证问题识别结构风险，说明相应校验方式。

 ### 12. 开放的结构问题
 → 结构级（接口归属/统一格式/合并拆分）才留这里；数值细节不留。
@@ -145,7 +146,7 @@ P1/P2 可用能力表（能力/说明）控制颗粒度。

 ## 六、自查参考
 - 每个 Sxx 都能一句话答"删了它什么塌"吗？
- 顶层的循环环节全覆盖、无重复认领吗？
+- 顶层当前范围的玩法环节和关键规则是否覆盖完整，协作分工是否清楚？
 - 依赖图无环？主数据无一物两管？
 - 系统文档拿到目录映射能直接开工吗？
 - 有没有字段定义或数值配置偷偷写进来？（该在技术文档层）
@@ -106,7 +106,7 @@ GDD 喂的（系统文档交接节就是订单）；程序侧的加载与验证

 ## A2 顶层设计分册（简介）

-本分册说明顶层循环、资源流、节奏、取舍、范围和验证标准。完整内容请阅读 `resources/skills/top_design.md`；顶层设计模板请阅读 `resources/templates/top-design.md`。
+本分册说明游玩过程、关键规则与反馈、资源与进展、选择后果、版本范围和验证计划。完整内容请阅读 `resources/skills/top_design.md`；顶层设计模板请阅读 `resources/templates/top-design.md`。

 ## A3 系统架构分册（简介）

@@ -1,180 +1,43 @@
-## A2 顶层设计分册（game-gdd-top-design）
-
---
-name: game-gdd-top-design
-description: 写游戏策划案（GDD）顶层设计时使用。在概念层定稿之后，
-  回答"玩家为什么一直玩"——把概念变成可玩的时间结构（循环/资源/取舍/节奏），
-  并向架构层交付系统范围。配套：templates/top-design.md、templates/analysis.md（全局一份）、
-  exemplars/stardew-top-design.md、templates/stardew-analysis.md（全局一份）。
---
-
 # 顶层设计写法（策划 · 顶层设计分册）

-> 本文件是顶层设计唯一承载写作流程的教学件。
-> 模板与例子文件保持纯净：不含任何步骤、检验提示与标记。
+产物：`project/01_top_design/design.md`。
+参考资源：`templates/top-design.md`、`exemplars/stardew-top-design.md`；全局分析文档的模板与样例：`templates/analysis.md`、`templates/stardew-analysis.md`。

-## 〇、结构适配原则
+## 判断立场

-根据游戏类型、项目规模、用户要求和概念层定稿选取本分册的适用内容，同类项可合并；复杂项目可以拆分补充，简单项目可以压缩为最小可用规格。
+将概念展开为可以理解的游玩过程，说明主要行动、关键规则、反馈与变化，明确当前范围及需要验证的设计问题，为系统划分提供依据。

-## 一、这一层的判断立场
-你是资深游戏策划，正在写全 GDD 最重要的一份文档——概念说"凭什么成立"，
-顶层说"好玩在哪"。核心循环无趣，后面写再多系统也救不回来。在这个层里你相信：
- 循环优先：先把大循环、小循环、最小体验单位三层跑通，再谈其他一切。
- 用玩家的手写，不用系统的嘴写：写"玩家在做什么、在想什么"，
-  不写"系统提供了什么功能"。
- 每个时间段的痛苦和甜都要有来处：取舍表接概念层的张力，节奏接情绪摆动。
- 资源守恒直觉：每种资源必问来源、储存、消耗——无来源是白给，
-  无消耗是废物，环环相扣成套利。
- 你不替概念层翻案（张力与定稿已定），也不替架构层拆系统（只划边界）。
+从玩家行为说明玩法，结合必要的系统功能解释结果。设计应服务于已确定的核心体验，不把自己的建议写成用户已经作出的决定。

-## 二、动笔前
-1. 概念层 design.md 已定稿可用——顶层定位与取舍表直接从它长出来。
-2. 读取 exemplars/stardew-top-design.md 了解内容组织方式，
-   往 templates/top-design.md 里填。
-3. 结合概念层已有的重要取舍展开玩法；需要追溯时引用相关内容或章节。
+## 动笔前

-## 三、顶层设计的组织维度：写什么、为什么、怎么咬合
+结合已获批的 `project/00_concept/design.md`、已有对话和项目资料开展设计，模板与样例按需参考。发现概念与新的约束冲突时，说明影响并讨论相关决定；不因套用样例自行改变方向。

-顶层文档回答四个问题：
-**玩家在玩什么（1~9）→ 玩家面对什么选择与后果（10~11）→
-交给架构什么（12~14）→ 没想清什么、定了什么（15~16）。**
+## 内容组织

-第 1 节承概念定稿开篇，第 16 节给架构硬约束收口，首尾呼应；
-中段三层循环互检，资源流从底下供血。
+根据项目实际玩法选择组织方式，同类内容可以合并，复杂部分可以拆分。不适用的内容省略，有意义但信息不足的内容保留已知信息与待补问题。

-| # | 节 | 是什么 | 为什么写 | 和谁咬合 |
-|---|---|---|---|---|
-| 1 | 顶层定位与规模锚点 | 承概念定稿 + 按需说明易混淆方向及排除理由 + "让玩家每天都在想"念头句 + 规模参数表（循环单位/段落/复杂度/长期主轴） | 循环单位定错全盘错；定位句防止顶层漂离概念 | 承概念层"概念定稿"；念头句是概念层玩家念头的时间维度版 |
-| 2 | 设计目标 | 几种回报、如何互相供给 | 回报并列=小游戏拼盘；互相供给才是循环 | 供给关系落到 4~5 的循环里 |
-| 3 | 核心推动力 | 按项目实际存在的即时、阶段或长期推动力组织 | 玩家"什么时候被什么推着走"的推动结构 | 与实际节奏结构对应 |
-| 4 | 大循环 | 跨较长时间的循环：文字箭头 + 核心循环图 | 长期留存的结构骨架 | 与 5、7 三层互检：大循环的每环应有小循环供血 |
-| 5 | 小循环 | 按项目实际存在的局内或短周期动词链组织 | 记录真正被玩到的循环 | 按实际循环层级互检 |
-| 6 | 资源流与输入输出 | 按项目实际存在的资源流、输入输出和反馈组织 | 说明循环中的实际供给与结果 | 与实际循环环节对应 |
-| 7 | 最小体验单位 | 多短一段玩法就能体现独有乐趣 + 反馈铁律 | 原型只做这一个单位——定原型规模 | 是 5 的最小切片；14 验证标准的试验对象 |
-| 8 | 核心活动流程 | 段落表：阶段/玩家行为/**设计目的** | "玩这个游戏的一天"的可复述剧本 | 设计目的列写不出的段=该删的段 |
-| 9 | 取舍表 | 决策/立即收益/延迟收益/主要代价 | 玩家决策的路口 | 与概念层已有的重要取舍衔接 |
-| 10 | 节奏结构 | 按项目实际存在的时间层级和情绪变化组织 | 说明玩法节奏如何变化 | 与实际推动力层级对应 |
-| 11 | 失败与回收 | 亏损定性 + 情况/结果表 | 失败的形态决定调性——"少拿"还是"毁掉" | 对齐概念层的情绪基调与边界 |
-| 12 | 系统范围 | 系统/顶层目的/**边界** 表 | 架构层接口：系统地图的种子 | **对下接口**：架构照此拆系统 |
-| 13 | 范围与非目标 | 最小完整版本清单 + 不做清单 | 立项交付物的边界 | 承概念层的边界与约束；给 14 提供验证范围 |
-| 14 | 验证标准 | 验证点/成功标准（行为判据） | "好玩"不可测，"玩家能复述循环"可测 | 判据对象=7 的最小体验单位 |
-| 15 | 开放问题 | 留给架构前必须想清的 | 显式债务清单 | 进分析文档或架构层开题 |
-| 16 | 顶层定稿 | 收口重锤 + 给架构的硬约束（必须__/不得__） | 检验全文档没写散；架构的紧箍咒 | 回环呼应 1；承概念层定稿的接力棒 |
+- **玩法目标**：说明主要行动和回报怎样实现概念中的体验，以及玩家为什么愿意推进。
+- **游玩过程与节奏**：说明玩家如何开始、行动、获得反馈，过程如何变化或结束。存在重复或长期推进结构时再展开循环及其联系，不预设循环层级、日历节奏或反馈层数。文字、表格和图按表达需要选用。
+- **资源与进展**：说明实际存在的资源、状态或进展怎样获得、变化、使用及受到限制。永久解锁、知识或经验等累积结果不必设计消耗环节。
+- **选择与后果**：说明重要选择的结果、收益和代价，以及它们怎样服务于目标体验。是否存在最优解取决于玩法，不要求所有选择等价。存在失败时，按场景说明损失、保留内容和恢复方式。
+- **系统范围与版本边界**：说明支撑玩法所需的能力、目的、边界及相互关系，明确当前版本包含和排除的内容。这里的系统范围供架构层拆分、合并，不要求每项对应一个独立系统。
+- **原型验证与开放问题**：说明需要判断什么，以及为此需要哪些内容、流程和游玩跨度。原型验证范围与当前完整版本范围分别写清；原型不固定为单个体验片段。根据问题采用试玩观察、完成情况、玩家反馈或指标，说明如何据此判断设计是否成立。尚未验证的预期不写成已验证结论。

-咬合一图：
+关键约束写在相关内容中，无需结尾重复定稿。影响当前玩法成立或范围确定的问题应先解决，其他问题按影响保留给后续设计。

-```
-概念层定稿（核心体验、重要取舍与约束）
-        ↓ 承接
-1 定位与规模锚点 ───玩法展开───► 9 取舍表（按实际取舍组织）
-        ↓ 展开
-2 设计目标 → 3 核心推动力 → 4 大循环 ⇄ 5 小循环 ⇄ 7 最小体验单位
-        ↓ 供血
-6 资源流与输入输出（防无来源/无消耗/套利）
-        ↓ 后果侧
-8 活动流程（段落表）→ 10 节奏结构 → 11 失败与回收
-        ↓ 交付
-12 系统范围（→架构系统地图的种子）＋ 13 范围 ＋ 14 验证标准
-        ↓ 收口
-15 开放问题 → 16 顶层定稿（给架构的硬约束）
-```
+## 展开深度

-三个接口：**对上**承概念定稿、展开实际存在的取舍；**对内**三层循环互检
-（大⇄小⇄最小单位）+ 资源三段全；**对下**系统范围表喂架构的系统地图、
-顶层定稿当架构的紧箍咒、验证标准当原型试玩判据。
+写清理解和判断玩法所需的关键规则与参数，详细系统规格和实现方案留待后续展开。必要的数值、操作方式和界面信息可以保留。

-## 四、怎么写（模板参考结构，建议按此组织）
-（本节是带写法要领的教学版；实际填写的纯净模板在 templates/top-design.md）
+## 分析参考

-### 1. 顶层定位与规模锚点
-承接概念定稿说明核心定位；存在容易混淆的方向时，说明排除方向及理由，表述按项目需要组织。
-顶层设计让玩家每天都在想：
-> "__（玩家每天惦记的那件事）"
-规模锚点表：循环单位 / 段落构成 / 操作复杂度 / 经营复杂度 / 长期主轴排序。
-→ 循环单位先行，定错全盘错。复杂度行可内联参照与"不做"。
+可关注玩法节奏、行动回报、重要取舍及范围选择的依据。按需参考 `templates/analysis.md` 和 `templates/stardew-analysis.md`。

-### 2. 设计目标
-玩家在 __ 循环中同时获得 __、__、__，三者互相供给：__。
-→ 检验：砍掉任何一种回报，另外两种是否受伤。
+## 交付检查

-### 3. 核心推动力
- 动机主次：__。
- 即时推动 __；日程推动 __；季节推动 __；长期推动 __。
-→ 只展开项目实际存在的时间层级；不存在的层级不设字段。
-
-### 4. 大循环
-**__ → __ → __ → __ → 回到 __。**（附核心循环图）
-→ 检验：断掉任何一环，后面是否塌；每一环应有对应小循环供血。
-
-### 5. 小循环（按项目实际数量）
-**__循环**：__ → __ → __ → __ → __。
-→ 必须具名（"农务循环"不是"资源循环"）；动词链完整到可以直接照做。
-
-### 6. 资源流与输入输出
-（资源流图：每种核心资源 来源 → 储存 → 消耗 三段全）
-主要输入 __；主要输出 __；按项目需要记录反馈层级。
-→ 三问：这资源哪来的？存在哪？花在哪去？答不出=资源设计未完成。
-
-### 7. 最小体验单位
-__（多短一段玩法体现独有乐趣——原型只做这一个单位）。
-保留的玩家行动应有与玩法相称的可理解反馈；反馈形式和数量按项目决定。
-
-### 8. 核心活动流程（段落表）
-| 阶段 | 玩家行为 | 设计目的 |
-→ 设计目的列必填；写不出目的的段落删掉。这份表要能让陌生人复述
-"玩这个游戏的一天"。
-
-### 9. 取舍表
-| 决策 | 立即收益 | 延迟收益 | 主要代价 |
-→ 需要追溯时引用概念层相关内容或章节；避免唯一最优解；不同选择应产生不同但都合理的玩法方式。
-
-### 10. 节奏结构
-日内 __ → 周内 __ → 季节/章节 __ → 长期 __。
-整体情绪在"__"与"__"之间摆动（恢复来源 __；变化来源 __）。
-
-### 11. 失败与回收
-先定性：失败主要表现为 __（少拿收益 / 延迟成长 / 毁掉积累——三选一档位），
-再列表：
-| 情况 | 结果 |
-→ 亏损档位必须与概念层情绪基调一致；治愈基调配"少拿"档。
-
-### 12. 系统范围（架构层接口）
-| 系统 | 顶层目的 | 边界（本层不做什么） |
-→ 只写目的与边界，不写系统内部规则；每行将来对应架构层一个 Sxx。
-
-### 13. 范围与非目标
-最小完整版本包含：__。不做清单：__。
-
-### 14. 验证标准
-| 验证点 | 成功标准 |
-→ 成功标准必须是行为判据（"玩家能复述__""玩家出现__行为"），
-  "感觉好玩"不算。
-
-### 15. 开放问题
-→ 逐条列出；值得跨轮保留的进分析文档，其余留待架构层开题。
-
-### 16. 顶层定稿（收口重锤）
-顶层当前定稿为：__（循环单位、核心结构、关键档位一句话说全）。
-后续架构必须围绕 __ 拆系统；不得 __。
-
-若某节对本项目没意义，直接省略。
-
-## 五、分析参考
-
-可关注一局玩法的节奏，以及风险、收益与长期成长如何相互支撑。
-按需参考 `templates/analysis.md` 和 `templates/stardew-analysis.md`。
-
-
-## 六、自查参考
- 三层循环互检了吗：大循环每环有小循环供血？最小单位切得出来？
- 玩法中的重要取舍是否与概念层的核心体验和约束一致？
- 每种资源三段全吗（来源/储存/消耗）？
- 验证标准是行为判据吗，还是写了"好玩"？
- 架构层拿到系统范围表能直接开工吗——有没有该划没划的系统？
- 失败档位和概念层基调一致吗？
-
-## 七、红线（只有三条）
-1. 不冒充用户决定：用户没说的方向标"待确认"，正文不写死。
-2. 不越层：向上不翻概念层的案，向下不写系统内部规则与具体数值。
-3. 不凑数：章节对项目有意义但信息不足时，记录已确定内容与待补问题；章节对项目无意义时，直接省略。
+- 能否理解玩家实际怎样玩，行动怎样产生反馈和后续变化。
+- 关键规则、资源或进展、选择与后果是否符合核心体验，是否存在矛盾或缺口。
+- 当前版本范围是否明确，是否足以让架构层判断所需能力及其关系。
+- 验证是否针对真实的设计问题，范围与方法是否足以支持判断。
+- 是否为了填模板编造循环、资源或取舍，或把未确定、未验证的内容写成定论。
@@ -5,7 +5,7 @@
 # 系统架构：《游戏名》

 ## 架构定位与目标
-本阶段确定"哪些系统支撑一轮玩法"，不展开单系统内部规则。
+本阶段确定哪些系统支撑已确定的玩法与版本范围，不展开单系统内部规则。
 划分原则：__。

 一句话架构：
@@ -66,9 +66,9 @@ flowchart LR
 - 系统之间通过稳定 ID 关联。
 - 任何系统不复制另一系统的主数据。

-## 核心循环覆盖检查
+## 玩法覆盖检查

-| 顶层循环环节 | 认领系统 |
+| 顶层玩法环节或关键规则 | 负责或协作系统 |
 |---|---|
 | __ | __ |

@@ -80,6 +80,8 @@ flowchart LR
 | 03_systems/S02__/ | __ |

 ## MVP 最小闭环
+依据顶层版本范围与验证计划，记录最先实现的完整可玩流程，可为线性推进或循环。
+
 1. __
 2. __
 3. __
@@ -1,122 +1,27 @@
-### C1 模板_顶层设计.md（→ templates/top-design.md）
-
-填写前按项目实际存在的循环、资源、时间层级和用户要求筛选本模板的章节；同类内容可合并，复杂项目可增加必要内容。表格、列表和循环示例按实际内容扩展。
-
 # 顶层设计：《游戏名》

-## 顶层定位与规模锚点
-核心定位：__。
-容易混淆的方向及排除理由（按需）：__。
+以下为参考结构，可按项目需要合并、拆分或省略。提示问题用于帮助组织内容，不要求逐项填写。

-顶层设计让玩家每天都在想：
-> "__"
+## 玩法目标

-| 项 | 定义 |
-|---|---|
-| 循环单位 | __ |
-| 段落构成 | __ |
-| 操作复杂度 | __ |
-| 经营复杂度 | __ |
-| 长期主轴 | 第一 __；第二 __；__ 只做辅助 |
+玩家的主要行动与回报怎样实现概念中的体验？

-## 设计目标
-玩家在 __ 循环中同时获得：__、__、__，三者互相供给：__。
+## 游玩过程与节奏

-## 核心推动力
- 动机主次：__。
- 即时推动：__。
- 日程推动：__。
- 季节推动：__。
- 长期推动：__。
+玩家如何开始、行动、获得反馈，过程如何变化或结束？有哪些关键规则？存在重复或长期推进结构时，它们如何连接？

-## 大循环
-**__ → __ → __ → __ → 回到 __。**
+## 资源与进展

-```mermaid
-flowchart LR
-  A[__] --> B[__]
-  B --> C[__]
-  C --> D[__]
-  D --> E[__]
-  E --> A
-```
+实际有哪些资源、状态或进展？它们怎样获得、变化、使用及受到限制？

-## 小循环
+## 选择与后果

-### __循环
-__ → __ → __ → __ → __。
+哪些选择影响体验，各自的结果、收益与代价是什么？存在失败时，会失去或保留什么，怎样恢复？

-### __循环
-__ → __ → __ → __。
-（以上为示例，可按实际循环删减或扩充。）
+## 系统范围与版本边界

-## 资源流与输入输出
+支撑玩法需要哪些能力，各自的目的、边界与关系是什么？当前版本包含什么，排除什么？

-```mermaid
-flowchart LR
-  A[__来源] --> B[__储存]
-  B --> C[__消耗]
-```
+## 原型验证与开放问题

- 主要输入：__。
- 主要输出：__。
- 反馈四层：立即 __；短期 __；中期 __；长期 __。
-
-## 最小体验单位
-__。
-保留的玩家行动应有与玩法相称的可理解反馈：__。
-
-## 核心活动流程
-
-| 阶段 | 玩家行为 | 设计目的 |
-|---|---|---|
-| __ | __ | __ |
-（按实际阶段逐行补充。）
-
-## 取舍表
-
-| 决策 | 立即收益 | 延迟收益 | 主要代价 |
-|---|---|---|---|
-| __ | __ | __ | __ |
-
-## 节奏结构
- 日内节奏：__。
- 周内节奏：__。
- 季节/章节节奏：__。
- 长期节奏：__。
-（以上为示例，可按实际节奏层级删减或扩充。）
-
-整体情绪在"__"与"__"之间摆动（恢复来源：__；变化来源：__）。
-
-## 失败与回收
-失败主要表现为：__。
-
-| 情况 | 结果 |
-|---|---|
-| __ | __ |
-
-## 系统范围
-
-| 系统 | 顶层目的 | 边界（本层不做什么） |
-|---|---|---|
-| __ | __ | __ |
-
-## 范围与非目标
-最小完整版本包含：__。
-
-不做清单：__。
-
-## 验证标准
-
-| 验证点 | 成功标准 |
-|---|---|
-| __ | __ |
-（按实际验证点逐行补充。）
-
-## 开放问题
- __
-（按实际问题逐条补充。）
-
-## 顶层定稿
-顶层当前定稿为：__。
-后续架构必须围绕 __ 拆系统；不得 __。
+需要判断哪些设计问题，为此需要怎样的原型内容和游玩跨度？通过哪些观察、反馈或指标作出判断？哪些问题影响当前设计，哪些可以后续展开？
@@ -1,5 +1,12 @@
 # 决策记录

+## 2026-09-27 顶层设计按实际玩法展开
+
+- 顶层说明游玩过程、关键规则与反馈、资源与进展、选择后果和版本范围；取消固定循环层级、回报数量、资源消耗链、日历节奏和失败档位，允许说明玩法所需的具体参数。
+- 原型范围依据验证问题确定，与完整版本范围分开；验证可结合观察、玩家反馈和指标，预期与已验证结论分清。
+- 架构按顶层已有内容检查玩法覆盖，可拆分、合并能力范围并由多个系统协作，不依赖固定循环图、独立定稿章节或逐项映射。TDD 自足性、产物路径和审批合同保持不变。
+- 当前规则见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
 ## 2026-09-27 概念设计按内容组织，取消固定填写程序

 - 概念层先利用已有对话与资料，按实际缺口补问；模板和样例按需参考，不强制参照、固定句式、字数、唯一卖点、六项锚点或调性编号。
@@ -310,7 +310,11 @@ TDD 的决策记录采用相同原则：施工规格、参数、默认值直接

 `resources/SKILL.md` 未登记到资源目录，不属于现役注入来源。

-顶层设计的分册、模板和示例保留核心定位及按需说明的易混淆方向与排除理由，不强制使用固定的“不是 X，而是 Y”句式。
+顶层设计将概念展开为游玩过程、关键规则与反馈、资源与进展、选择后果、版本范围及验证计划。规则、模板和样例按实际玩法组织，不强制三层循环、三种互相供给的回报、资源“来源—储存—消耗”链、日历节奏、反馈层数、唯一原型片段或失败三选一；最优解是否成立取决于玩法，必要的规则与参数可以在顶层明确。保留核心定位及按需说明的易混淆方向与排除理由，不强制固定句式或结尾重复定稿。
+
+原型范围由要验证的问题决定，与完整版本范围分别说明；验证可以结合试玩观察、完成情况、玩家反馈和指标，明确如何形成判断，不把未验证的预期写成结论。星露谷样例按选择双方的收益与代价比较，按场景说明损失与恢复，并区分单日、多日和后续内容的验证范围。
+
+架构层承接顶层已有的玩法描述、能力范围、版本边界和验证计划，不要求固定循环图、独立“顶层定稿”章节或清单逐项对应系统。玩法覆盖检查允许多个系统协作支撑同一环节，须明确分工，避免同一职责重复维护；仍保留系统编号、职责、数据归属与目录映射等架构职责。顶层短阶段提示和 TDD 中的顶层简介同步使用该口径，TDD 的施工完备要求不变。

 进入下一阶段必须由用户批准触发。Runtime 推进后向 Agent 追加明确的用户行为语义，例如“用户已批准上一阶段，现在进入顶层设计阶段”，避免 Agent 误认为 Runtime 自行推进。