简化速览卡结构与参考样例

速览卡聚焦游戏概览、当前范围和已有设计入口。删除重复系统表、验证计划及样例中过时的素材数量。同步维护提示、技术方案与共享记忆。
2026-09-28 07:09:19 +00:00
parent a4013639cf
commit 5e3fb348f8
5 changed files with 28 additions and 92 deletions
@@ -1,44 +1,15 @@
-概念阶段定稿时，创建或更新 `project/速览卡.md`，简要介绍当前游戏。后续仅在核心体验、范围、平台等概览内容变化时更新，不复制完整决策清单。下面是速览卡的参考结构；根据游戏类型、项目规模和用户要求选择适用字段，同类内容可以合并，复杂项目可以增加必要字段。表格和列表中的示例行按实际对象逐行扩展：
+概念阶段定稿时，创建或更新 `project/速览卡.md`，让读者快速知道这是什么游戏、当前准备做什么、详细设计在哪里。后续仅在概览内容或设计入口变化时更新。
+
+按项目需要组织简短概览，不设固定字数，也不要求填满下面的结构。分类、支柱、循环、目标玩家等可以融入概述，不各自展开论证；不复制系统表、具体参数、素材数量、完整排除清单或验证计划。只有会改变游戏方向或当前范围的重要未决问题，才简要提示并指向详细位置。

 # 速览卡：《游戏名》

-## 1. 游戏名称
+一句话说明玩家做什么，以及主要体验。按需补充平台、美术方向、目标玩家等必要信息。

-## 2. 游戏分类
+## 当前范围

-## 3. 美术风格
- 视觉类型：
- 风格关键词：
- 色彩与氛围：
- MVP 美术边界：
+简述本次准备实现的主要内容和容易误解的边界；尚未确定时如实说明，不为填卡新增范围或未来计划。

-## 4. 一句话描述
+## 设计入口

-## 5. 游戏支柱
-| 支柱 | 玩家感受 | 实现机制 |
-|---|---|---|
-
-## 6. 核心循环
-
-## 7. 目标用户与情境
- 核心用户：
- 游戏偏好：
- 单次游玩时长：
- 参考游戏与参考点：
-
-## 8. 平台事实
-
-## 9. 最小 MVP 系统
-| 系统 | 最小功能 | 为什么必须有 | 验证方法 |
-|---|---|---|---|
-
-## 10. 给创作者的关键提示
- 先做：
- 暂时不做：
- 这样验证：
- 达标再扩展：
-
-### 待原型验证项
- 问题：
- 原型：
- 观察：
+只链接已存在且有用的详细文档，使用相对当前文件的路径；例如概念文档可链接 `00_concept/design.md`。尚无其他入口时可以省略，不预填未生成的文档。
@@ -1,58 +1,16 @@
-# 速览卡：《星露谷物语》金样项目
+# 速览卡：《星露谷物语》日常原型示例

-> 本卡概括当前游戏；仅在核心体验、范围、平台等概览内容变化时更新。具体规则和取舍依据见对应设计与分析文档。
+继承一座荒废农场，安排每天的时间与体力，通过种田、探索和乡村交往逐步改善生活。面向喜欢自主安排与慢节奏成长的玩家，采用温暖、朴素的俯视像素风；本例运行于 Web，支持桌面键鼠与移动触控。

-## 1. 游戏名称
-《星露谷物语》（金样项目沿用案例名）←概念设计标题
+## 当前范围

-## 2. 一句话描述
-继承一座荒废农场的乡村生活 RPG：安排每天的时间与体力，种田、探索、交朋友，把日子过成自己想要的样子。（←概念层「游戏概念」）
+本次只做农场、小镇与基础采集区域的日常原型：农务与采集获得成果，经买卖、成长和跨日推进形成下一轮计划，包含必要的界面与存读档。居民关系、矿井战斗等完整游戏内容不在本次施工范围。

-## 3. 游戏分类
-乡村生活模拟 RPG（经营+探索+社交；参照系牧场物语）←概念层「游戏概念」
+当前样例的基础采集、跨日结算、数值及表现规格仍有缺口，尚不能据此完成整个原型；详情见 TDD 总册。

-## 4. 美术风格（四件）←概念层「身份、基调与世界观」与美术圣经
- 视觉类型：手绘感像素风、俯视 45° 视角。
- 风格关键词：温暖、田园、四季分明、生活感。
- 色彩与氛围：暖土绿基底+季节信号色整体切换；治愈不压抑；无锐利科技感、无阴暗元素。
- MVP 美术边界：首期 3 区域 tileset、8 位 NPC（行走+立绘）、约 120 物品图标、玩家换装 5 层；不做 19 层全量换装与全区域。
+## 设计入口

-## 5. 游戏支柱（3 条）←概念层「游戏概念」「体验与玩法」
-| 支柱 | 玩家感受 | 实现机制 |
-|---|---|---|
-| 自己的节奏 | "今天想干嘛就干嘛，明天一切更顺手。" | 自由日程+时间体力预算；无失败结局 |
-| 今天的选择让明天更从容 | "升级工具、攒钱扩建是有意义的。" | 长期投资线：工具升级/技能/设施 |
-| 社区让独居变成归属 | "镇上的人在等我。" | NPC 关系/任务/社区修复目标 |
-
-## 6. 核心循环（5 步）←概念层「体验与玩法」
-安排一天的时间与体力 → 农/采/钓/矿/战/社交任选组合 → 获得资源·金钱·经验·关系 → 投资工具·设施·种子·物品 → 解锁更高效或更丰富的活动。
-
-## 7. 目标用户 ←概念层「目标玩家与情境」
-牧场物语系慢节奏成长玩家+动森式"无压力日常"需求；单人、可反复、每次一至数个游戏日；不要求预先掌握复杂数值。
-
-## 8. 平台事实（禁改）
-Web 浏览器运行 · 双视口（桌面/移动）· 键鼠/触屏双输入 · 本地启动后可在浏览器中试玩。
-
-## 9. MVP 系统（本例首期范围）
-| 系统 | 最小功能 | 为什么必须有 | 验证方法 |
-|---|---|---|---|
-| 时间与日程 | 时钟、天气、日终协调与跨日推进 | 组织日常活动 | 单日行动与多日状态持续一致 |
-| 体力与状态 | 行动成本、休息恢复 | 支持日常计划与取舍 | 结合行动调整和玩家反馈判断压力 |
-| 农场经营 | 耕种、浇水、生长与收获 | 核心产出与规划场 | 连续数日完成生长、收获与再投资 |
-| 探索与地图 | 农场、小镇与基础采集区域 | 支持外出和活动选择 | 移动、出入口与资源点状态正确 |
-| 采集与钓鱼 | 本期基础采集，钓鱼后续加入 | 提供农场外的资源来源 | 采集结果正确入账且不重复领取 |
-| 物品与制作 | 本期物品身份、背包与工具使用 | 连接活动成果与投资 | 拾取、消耗及存读档结果一致 |
-| 成长与技能 | 基础农务或采集成长 | 为后续活动提供目标 | 多日成果产生可理解的能力变化 |
-| 经济与商店 | 买种、出售与基础投资 | 连接产出与后续投入 | 收益可用于下一轮活动，具体节奏待验算与试玩 |
-
-## 10. 制作边界 ←概念层「边界与约束」
-不做：硬核生存（无饥饿/债务/死亡惩罚）；效率至上的工厂经营；以战斗为核心的动作游戏；剧情驱动的任务链主线；多人竞争；无边界开放世界（区域小网络全步行可达）。
-
-## 11. 创作者提示（本例原型验证安排）
- 先做：单日农务与基础采集，继续数日覆盖作物生长、收获、出售、投资和基础成长，包含必要的 UI 与存读档。
- 暂不做：装备刷取、随机构筑、复杂剧情、节日全量、联机。
- 这样验证：结合试玩观察和玩家对选择理由、后续目标的说明，判断是否形成有意义的计划；同时检查资源与跨日状态的一致性。
- 后续验证：加入一个矿井遭遇，再逐步覆盖关系与社区目标；依据实际问题调整范围，不把能自述计划作为唯一门槛。
-
-## 12. 待原型验证项
- 矿井中的轻度战斗能否提供节奏变化，同时保持探索流畅；通过原型试玩观察判定是否易懂、战斗是否拖慢探索。
+- [概念设计](stardew-concept.md)：游戏方向与核心体验。
+- [顶层设计](stardew-top-design.md)：游玩过程与版本范围。
+- [系统架构](stardew-architecture.md)：系统职责与协作。
+- [TDD 总册](stardew-tdd-master.md)：施工分册入口与重要缺口。
@@ -11,7 +11,7 @@

 阶段审批是五个策划阶段各自的最终检查，将已完成的本阶段产物交给用户检阅。需要用户选择的关键问题先通过问询解决，阶段审批不承担问询功能。提交前，解决所有影响本阶段完成的关键问题，或明确说明它们不阻塞本阶段交付，并更新相关产物。可以保留不阻塞当前阶段的后续事项和待原型验证项。

-共享文档按用途和内容变化维护，不逐轮更新或重复登记同一决定。分析文档按需保留重要取舍的依据与当前结论；待办变化时更新决策台账，完成后移出待办；对话摘要或交接记录仅在用户需要时维护；速览卡只在概览内容变化时更新。可以合并、修订条目，只保留理解当前决定所需的历史依据。未决事项说明原因或下一步，不要求固定状态、连续编号、候选数量或每项推翻条件。阶段提交前检查影响交付的信息是否一致。
+共享文档按用途和内容变化维护，不逐轮更新或重复登记同一决定。分析文档按需保留重要取舍的依据与当前结论；待办变化时更新决策台账，完成后移出待办；对话摘要或交接记录仅在用户需要时维护；速览卡只在概览内容或设计入口变化时更新。可以合并、修订条目，只保留理解当前决定所需的历史依据。未决事项说明原因或下一步，不要求固定状态、连续编号、候选数量或每项推翻条件。阶段提交前检查影响交付的信息是否一致。

 阶段获批后，产物中已经采用的方案作为后续工作的依据，并保留原有决策来源。用户主动质疑或出现新的约束冲突时，再重新讨论相关决定。

@@ -1,5 +1,10 @@
 # 决策记录

+## 2026-09-28 速览卡只承载概览、范围与设计入口
+
+- 速览卡帮助读者快速理解游戏及本次范围，分类、支柱、循环与目标玩家可融入概述；不复制系统拆分、具体参数、素材数量、完整排除清单或验证计划，不设固定字数或必填章节。
+- 仅在概览内容或入口变化时维护，只链接已有且有用的文档；影响方向或当前范围的重要未决问题简述并引用详细位置。注入说明与样例同步清理，概念阶段必需产物路径、资源登记及审批合同不变，已有用户项目不自动改写。详见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
 ## 2026-09-28 TDD 验证按需去重，范围外内容不自动规划

 - 验收判据与必要场景在对应分册完整写一次，其他位置引用并补充独有要求；总册汇总重要结论和缺口，不复制清单。必要数值验算保留，不重复行为状态推演，也不能代替运行验证。
@@ -286,7 +286,7 @@ concept → top_design → architecture → systems → tdd → consultant
 | 技术文档 | `project/04_tdd/01_技术实现.md`、`project/04_tdd/02_美术圣经.md`、`project/04_tdd/03_数据与配表.md`、`project/04_tdd/总册.md` |
 | 顾问态 | 不提交下一阶段审批 |

-`systems: []` 是已确定的行为，不是迁移时需要补齐的缺口。`project/analysis.md`、`project/决策台账.md`、`project/dialog.md` 保持原型中的共享过程文件口径，不升级为新的审批必需项。速览卡保留原型结构提示，但 Runtime 与 UI 不解析其章节或内容字段。
+`systems: []` 是已确定的行为，不是迁移时需要补齐的缺口。`project/analysis.md`、`project/决策台账.md`、`project/dialog.md` 保持原型中的共享过程文件口径，不升级为新的审批必需项。速览卡采用下述简短概览结构，Runtime 与 UI 不解析其章节或内容字段。

 提示词中的路径是策划 Agent 使用的相对路径约定：

@@ -302,10 +302,12 @@ concept → top_design → architecture → systems → tdd → consultant
 | `project/analysis.md` | 按需保留重要取舍的依据与当前结论；存在实际备选时再比较，未决问题说明原因或下一步。结论稳定或依据变化时更新，可合并修订条目，不记录每次讨论。 |
 | `project/决策台账.md` | 按需集中列出待处理事项和下一步，必要时引用分析或正式设计。事项变化时更新，完成后移出待办，不再重复保存全部已采用决定。 |
 | `project/dialog.md` | 仅在用户需要对话摘要或交接记录时维护，不逐轮转录聊天。 |
-| `project/速览卡.md` | 概念阶段形成游戏概览；后续仅在核心体验、范围、平台等摘要内容变化时更新，不复制完整决策清单。 |
+| `project/速览卡.md` | 概念阶段形成简短游戏概览、当前范围与已有设计入口；仅在概览内容或入口变化时更新，不复制系统表、参数、素材数量、完整排除清单或验证计划。 |

 正式设计承载当前采用的规则，共享文档按各自用途记录，不要求同一决定在多处重复登记。不强制连续编号、状态枚举、候选数、问题数量、推翻条件或完整历史流水；尚未确定的事项用自然语言说明，不冒充用户确认。阶段提交前检查影响交付的信息是否一致，不以补齐过程记录作为新门禁。已有项目文件不批量重写或删除。

+速览卡让读者快速了解游戏、当前准备做什么及详细设计的位置。分类、支柱、循环和目标玩家可合入概述，不再分别展开；不设固定字数，也不要求填满参考结构。只提示会改变方向或当前范围的重要未决问题，并引用详细位置；设计入口仅链接已存在且有用的文档，不为填卡新增范围或未来计划。注入说明与星露谷样例同步，样例清除旧 NPC、图标和换装数量，按当前日常原型概括；`project/速览卡.md` 仍为概念阶段必需产物。
+
 TDD 的决策记录采用相同原则：设计要求、当前采用值和实际工程约束直接写入对应分册，重要取舍按需保留分析，未决事项说明影响与下一步，不要求逐项登记到外部台账或附推翻条件。总册保留施工索引、跨分册约定与重要缺口，详细问题指向对应分册。问题解决后更新受影响的 GDD 与 TDD 正文并关闭待办，不能只登记处理去向。

 “施工方只看 TDD，应能完成当前范围的实现”仍是完成标准：设计要求、内容与数值、实际工程约束和验收条件写全，施工方无需回查 GDD 或猜测关键设计。保留来源版本与变更同步，外部分析与台账不能代替正文。代码组织、算法、内部接口、字段与数据结构、配置载体、资源命名与打包由施工方自主决定；未预定这些实现选择不构成策划缺口。已有工程契约、实际数据/资源格式和用户明确交付约束必须记录；有依据的实现建议可供参考，不成为唯一方案，也不增加逐项登记或用户确认。