以 UMWELT 为例 · 撰写：ChatGPT · 2026-10-13
游戏开发要连续回答四类问题：准备做什么，怎样做出来，如何证明它符合要求，发布后怎样维护。 每个阶段都应留下可检查的成果，而不只是“完成了百分之多少”的进度描述。
本文以 UMWELT 中的《等足目赋格》及其形态、环境实验室为主要案例。它们将自然史资料转化为视觉与交互体验，同时区分科学资料、工作性判断和游戏参数。1 下文用“新增一段生境观察”贯穿流程；这些演示任务不是对项目实际开发顺序的追认，也不是已经执行的测试报告。
常见开发框架包括前期制作、正式制作、测试、发布与发布后维护。原型和垂直切片通常属于前期制作，这里为方便查阅单独列出。不同团队可以合并或调整阶段；这不是一套必须逐项照搬的行业强制标准。23
| 阶段 | 核心问题 | 主要交付物 |
|---|---|---|
| 1. 概念与立项 | 值得做什么，做到多大？ | 一页概念、范围与风险清单 |
| 2. 前期设计与计划 | 规则、资源和工作如何组织？ | 设计文档、技术约定、制作计划 |
| 3. 原型验证 | 核心体验与关键技术成立吗？ | 可验证的原型、试玩记录 |
| 4. 垂直切片 | 能否稳定制作出目标品质？ | 代表性片段、质量基准与成本估计 |
| 5. 正式制作 | 如何持续交付完整功能与内容？ | 可运行版本、资源、审查和测试记录 |
| 6. QA、验收与打磨 | 哪些要求已满足，哪些风险仍在？ | 测试证据、缺陷清单、验收结论 |
| 7. 发布 | 交到玩家手中的成品可靠吗？ | 发布包、说明、上线检查与回退方案 |
| 8. 维护与复盘 | 如何修复、扩展和结束维护？ | 补丁、兼容记录、复盘与归档 |
流程会反复迭代。 原型失败可以返回设计，试玩结果可以要求缩小范围。QA、无障碍、资料核查和授权检查应从前期开始；宣传与发行准备也不宜全部留到上线前。
目标：确定作品的核心体验，并给第一版划出边界。
先写清目标玩家、主要行为、体验目标、目标平台、预计体量和发布方式。再列出时间、预算、人员、工具、素材与研究工作的限制。免费作品同样有制作和维护成本。
立项不是把所有设想写进计划，而是区分“第一版必须有”“以后可以有”和“明确不做”。同时挑出最危险的假设：操作是否成立、关键效果能否运行、资料能否核实、内容量能否承担。
UMWELT 示例。 一段生境观察可以把目标限定为：玩家看见环境差异，采取一次行动，从反馈中形成新的观察。真实物种资料用于支撑内容，但界面中的表现参数不能自动被当作生物学测量或饲养标准。1 示例首版只做一个生境、一条可完成的观察路径；更多物种、复杂气候和联网功能先不进入范围。
交付与放行： 一页概念说明、首版范围、资源估计及风险排序。负责人能够说明项目成立的理由，也能够指出哪些结果会导致修改或停止当前方案。
| 术语 | 含义 |
|---|---|
| Concept／游戏概念 | 游戏是什么、面向谁、提供什么体验。 |
| Pitch／提案 | 用简短材料向合作者、发行方或团队解释项目。 |
| Target Audience／目标受众 | 主要服务的玩家，不等于“所有人”。 |
| USP／Unique Selling Proposition | 独特卖点，即作品值得被选择的理由。 |
| Design Pillars／设计支柱 | 少数用于取舍的体验原则，例如“观察优先于数值竞争”。 |
| Scope／范围 | 承诺制作的功能、内容、平台与品质边界。 |
| Greenlight／立项放行 | 根据当前证据，批准继续投入下一阶段。 |
目标：把想法变成可讨论、可分工、可验收的约定。
设计应写到能够回答具体问题的程度：玩家在哪里进入？能做哪些操作？什么条件改变状态？一轮体验如何结束？操作被中断、存档重载或条件不满足时怎么办？叙事作品还要画出节点、条件和分支关系，而不只保存对白正文。
技术设计则说明运行平台、模块边界、数据格式、存档与资源管线。美术和声音规范约定风格、尺寸、文件格式、动画与音量规则。文档应随已确认的设计更新，不是立项时写一次便失效的长篇承诺。4
对于资料驱动的作品，另设来源记录：每条资料支持哪个物种、环境或表现；哪些结论尚有争议；哪些数值只是设计参数。素材记录则保留作者、来源、许可证、修改情况与署名要求。资料可阅读，不代表图片、字体或音频已经获准再分发。
UMWELT 示例。 新增生境前，先确认它是现有规则的数据扩展，还是需要修改场景路由、状态、绘制与语言支持。项目扩展指南要求同时考虑稳定标识、保存与重载、旧存档、配套资料页和语言覆盖；登记一个名称不等于内容已经接入游戏。5
这里应分清职责，而不一定增设岗位。制作人（Producer）统筹范围、资源和交付；游戏设计师（Game Designer）负责规则与体验；叙事设计师（Narrative Designer）处理故事与交互的关系；程序、美术、音频和技术美术（Technical Artist）负责各自实现及衔接；QA 提供质量风险与验证信息。小团队可以一人兼任，但每项成果仍要有决策者和验收者。2
交付与放行： 简版设计文档、技术与数据约定、美术音频规范、任务拆分和里程碑。最关键的未决问题被明确列出，并进入下一阶段验证，而不是藏在模糊描述里。
| 术语 | 含义 |
|---|---|
| GDD／Game Design Document | 游戏设计文档，记录玩法、规则、内容与体验目标。 |
| TDD／Technical Design Document | 技术设计文档。注意 TDD 在另一语境也指 Test-Driven Development，即测试驱动开发。 |
| Art Bible／美术规范 | 统一视觉风格、制作规格与交付标准的参考。 |
| UI／User Interface；UX／User Experience | UI 是玩家看到和操作的界面；UX 关注整个理解、操作与反馈过程。 |
| Pipeline／制作管线 | 从原始资料、源文件到游戏内成品的一套处理和交付步骤。 |
| Data Contract／数据契约 | 模块约定的数据字段、含义、稳定标识及兼容规则。 |
| Milestone／里程碑 | 有明确成果和放行条件的检查点，不只是一个日期。 |
| Dependency／依赖 | 一项工作开始或完成前，需要另一项工作先满足条件。 |
目标：用尽量少的制作成本，消除最关键的不确定性。
原型应该对应一个问题。例如：“玩家能否理解这次触碰引发的反应？”“低性能设备能否承受这段动画？”“观察与选项之间的节奏是否成立？”先约定验证期限和判断标准，再制作临时素材、纸面流程或最小可运行版本。
UMWELT 示例。 先用临时背景和简化动物形象完成“观察—操作或选择—反馈—继续观察”的循环。请未参与制作的人试玩，记录他们在哪里停顿、误解或重复操作，不要在旁边不断解释。对安静、观察型作品，判断指标可以是理解、注意力与感受，而不必强行套用刺激性或竞争性游戏的“爽感”。
机制和技术可以分别做原型。视觉很好看的片段，不能替代对实际输入、状态变化或存档行为的验证；一次跑通也不能证明整部作品的内容量和长期体验成立。
交付与放行： 原型、验证问题、观察记录和结论。可以继续制作，也可以修改或舍弃方案。原型代码允许丢弃；是否保留取决于结构与风险，而不是已经投入了多少时间。
| 术语 | 含义 |
|---|---|
| Prototype／原型 | 用于试验某个设计或技术假设的模型，不要求全面或精美。 |
| PoC／Proof of Concept | 概念验证，通常强调某个方案能否成立；与 Prototype 的用法可能重叠。 |
| Mechanic／机制 | 具体规则与操作关系，例如一次选择如何改变状态。 |
| Core Loop／核心循环 | 玩家反复经历的行为与反馈结构。 |
| Playtest／试玩测试 | 通过实际游玩观察体验，重点不只是发现程序错误。 |
| Timebox／限时验证 | 预先限定投入时间，到点根据证据决定下一步。 |
| MVP／Minimum Viable Product | 用足够小的产品验证用户价值等假设，不等于任意半成品，也不是游戏必经的版本名称。 |
原型与垂直切片的关键区别，是前者优先验证想法，后者还要验证目标品质的生产方式。3
目标：做出一小段具有代表性的完整体验，验证品质与制作能力。
选择一段能暴露主要制作环节的内容，接入接近目标质量的交互、画面、声音、文字、反馈和必要的保存功能。记录每个环节的成本、返工原因和依赖关系。切片的意义不是做一张漂亮截图，而是确认这些部分能一起运行，而且制作方法能够复用。3
UMWELT 示例。 完成一个短观察片段：从正常入口进入，观察动物与环境，作出操作，得到反馈，留下可恢复的进度，再查看相关资料。为这段内容加入代表性的长文本、目标屏幕布局和目标声音效果，检查它们是否相互干扰。
切片不必覆盖每个罕见系统，但不能只挑最容易的一部分，却将尚未验证的困难视为已经解决。极小项目可以把原型与切片合并；仍要分别回答“体验成立吗”和“能按这个质量做完吗”。
交付与放行： 可玩的代表性片段、质量基准、制作步骤与成本估计。能够说明下一段内容如何生产，以及现有资源是否支撑整个范围。
| 术语 | 含义 |
|---|---|
| Vertical Slice／垂直切片 | 内容范围较小，但纵向贯通主要制作环节、接近目标品质的样本。 |
| Horizontal Slice／水平切片 | 横向覆盖较多系统或流程，但各部分可能较粗糙，便于检查整体结构。 |
| Demo／演示或试玩版 | 面向展示和体验的版本，是一种用途；不必等同于原型或垂直切片。 |
| Quality Bar／质量基准 | 后续内容应达到的可比较标准，不是“看起来差不多”。 |
| Production-ready／具备生产条件 | 方案、工具与流程已经足以支持后续持续制作。 |
目标：按照经过验证的方法，持续交付完整的功能和内容。
每轮先选择少量任务，明确需求、依赖和验收条件，再完成实现、资源接入、审查与测试。新想法先进入待办池，不应随手混入当前任务。变更范围时，同时调整成本、进度和验证计划。
UMWELT 示例。 “新增生境观察”并不只是一张背景：还包括入口、数据、可执行的状态变化、文字、渲染、配套实验室、语言、存档与测试。项目指南特别提醒：新增结局对象不等于新增可达分支，必须验证能够到达、不会误触发、重载后仍正确、归档后能够显示。5
美术源文件与运行资源也要分开管理。高精度源文件可以用于制作，游戏实际加载的则可能是经过导出、压缩或转换的资源。整理源文件不应无意覆盖已经验收的运行成品。
下面是一项演示任务的约定，不是对现有功能的测试结论：
任务：新增一段生境观察
范围：一个入口、一段观察、一组反馈；不调整其他生境
验收：
能从约定入口进入，并完成整段观察
一次操作只产生一次预期状态变化
中途保存并重载后，进度与反馈一致
目标语言和屏幕范围内没有缺字、溢出或不可操作区域
未修改生境与历史存档仍满足原有规则
证据：版本标识、运行记录、必要的截图与未验证事项
Acceptance Criteria（验收标准）针对这一项需求；Definition of Done，DoD（完成定义）是各任务共用的质量底线，例如完成审查、通过必要检查、同步文档、没有遗留阻断问题。Scrum 对 DoD 的定义强调成果应满足一致的质量要求。6
使用 AI 辅助实现时，也应交付同样的记录：改了什么、依据什么、实际运行了哪些检查、哪些仍未验证。代码生成完成，不自动等于验收通过。
版本控制让修改可比较、可追踪和可恢复。7 按完整任务提交变更，审查差异后再合并；不要把功能开发、无关重构和格式调整混成难以撤销的大包。
持续集成可以在提交或合并时自动构建和运行检查，但它只覆盖已配置的检查范围。8 任务看板则用于显示待做、进行中、待审查和已完成；限制同时开工的任务数，比维持一长列“做了一半”的任务更容易验收。
交付与放行： 每轮得到可运行、可追踪的版本和已验收成果。不是等所有内容完成后，才第一次把程序、美术和文字接到一起。
| 术语 | 含义 |
|---|---|
| Feature／功能；Content／内容 | 功能提供能力，内容利用能力形成具体体验；两者都可能涉及多种工种。 |
| Asset／资源 | 游戏使用的图像、模型、动画、音频、字体等。 |
| Backlog／待办池；Ticket／任务单 | 前者保存排序后的待做事项，后者记录一项工作或问题。 |
| Iteration／迭代；Sprint／冲刺 | 迭代是反复交付与调整；Sprint 是 Scrum 中固定时长、最长一个月的周期，不是所有任务周期的通称。6 |
| Commit／提交；Branch／分支 | 提交记录一次版本变化；分支承载一条独立的开发线。 |
| Merge／合并；PR／Pull Request | 合并将变更接入另一条开发线；PR 用于提出、讨论和审查待合并变更。 |
| Code Review／代码审查 | 检查实现、风险与可维护性；不等于已经运行游戏验证。 |
| Build／构建或构建版本 | 可以指生成可运行成品的过程，也可以指生成的那个版本。 |
| CI／Continuous Integration | 持续集成，频繁整合变更并自动检查。 |
| CD／持续交付或持续部署 | Delivery 保持随时可发布，正式发布可有人工关卡；Deployment 将通过关卡的变更自动部署。 |
| Refactoring／重构；Technical Debt／技术债务 | 重构整理内部结构并维持预期外部行为；技术债务是可能增加后续修改成本的实现或流程负担。 |
| Scope Creep／范围蔓延 | 未同步调整资源与计划，却不断加入原定范围以外的要求。 |
| 术语 | 含义 |
|---|---|
| FSM／Finite State Machine | 有限状态机，明确当前状态、允许的操作和转换条件。 |
| Event／事件；Trigger／触发条件；Flag／标记 | 事件描述发生了什么，条件决定何时触发，标记保存已发生或已满足的状态。 |
| Branching／分支 | 根据选择或状态走向不同内容；应检查可达性与互斥关系。 |
| Rendering／渲染 | 把场景数据转成画面；渲染表现不等同于后台模拟规则。 |
| i18n／Internationalization；l10n／Localization | 国际化为多语言和地区差异准备结构；本地化制作具体语言、格式和文化适配内容。 |
目标：用证据判断质量，而不是以“能运行”代替“符合要求”。
QA（Quality Assurance，质量保证）关注过程如何预防和减少质量问题；QC（Quality Control，质量控制）关注成果质量，测试是其中的重要手段。两者有联系，但不是同义词。测试既可以发现缺陷，也可以向设计和制作流程提供反馈。9（§1.2.2）
下表把常见检查方式放到 UMWELT 的场景中。它们不是互斥分类：测试层级、检查目的和执行方法可以交叉组合。
| 检查方式 | 在观察型游戏中的用法 |
|---|---|
| Unit／单元；Integration／集成；E2E／端到端测试 | 分别检查局部规则、模块协作，以及从入口到反馈和保存的真实操作链。 |
| Smoke Test／冒烟测试 | 快速检查能否启动、加载关键资源、进入并推进主要流程。 |
| Functional／功能与边界测试 | 检查正常操作，也检查连续点击、取消拖动、非法输入和异常中断。 |
| Confirmation／修复复测；Regression／回归测试 | 前者确认原缺陷已修复；后者检查修改有没有破坏其他行为。9（§2.2.3） |
| Compatibility／兼容性测试 | 检查约定的浏览器、系统、输入方式与屏幕范围。 |
| Performance／性能测试 | 检查加载、帧耗时、内存及长时间运行，不只看开发机器上的一次表现。 |
| Narrative QA／叙事检查 | 检查分支可达、条件冲突、人物与资料一致性、结局和重载后的连贯性。 |
| LQA／Localization QA | 检查译文语义、变量拼接、字体、换行和语言切换后的状态。 |
| Usability／易用性与 Playtest／试玩 | 观察玩家是否知道能做什么、能否理解反馈，以及体验是否达到设计目标。 |
| Accessibility／无障碍检查 | 检查可读文字、对比度、替代输入、音量控制及运动效果等；不能只凭颜色或声音传达关键内容。10 |
| 安全、隐私与资料核查 | 对导入数据检查失败处理；检查公开包中是否混入秘密或不应公开的数据；对科学陈述单独追溯来源。 |
项目测试文档把普通自动测试和浏览器回归分开。以下命令是仓库记录的入口：11
# Node 自动测试
node --test tests/*.test.mjs
# 统一的非浏览器结构检查
node isopoda/tools/check-all.mjs
第二个入口包含多项数据、语言和内容结构检查，不包含浏览器／视觉回归，也不包含发布字体工具检查。浏览器测试有独立脚本；涉及历史存档、交互、字体或最终成品的改动，需要选择相应验证。结构检查也不能证明资料的科学真实性。511
项目的公共页面回归还区分“检查基本运行”与“对照基线”：没有设置用于比较的基线地址，就不能声称已经证明新旧画面、文字和保存结果一致。11 同理，模拟移动设备的视口、触摸等参数不等于测试了一台真实手机。Playwright 的设备模拟提供这些可配置能力；真机验收仍应单独记录。12
可以采用：登记 → 分类与排序 → 定位 → 修复 → 复测与必要回归 → 关闭。验证失败则重新打开；重复、暂缓或无法复现的问题也要留下原因。
Severity（严重程度）描述影响大小；Priority（优先级）描述处理顺序。存档丢失通常比装饰偏移影响更大，但发布页上的文字错误也可能需要优先处理。P0、P1 等编号由项目自行定义，不能假定跨团队含义相同。9（§5.5）
一个可复用的缺陷报告模板如下：
编号与标题：DEMO-BUG-001／反馈期间重载后无法继续（演示性问题）
环境与版本：填写设备、系统、浏览器及构建／提交标识
前置条件：进入指定观察，已有可重载进度
复现步骤：作出选择 → 反馈出现 → 重载 → 尝试继续
预期结果：恢复到约定状态，可以继续观察
实际结果：记录观察到的现象，不把原因猜测当结论
证据：附存档样本、日志、截图或录屏，并注明复现次数
处置：严重程度、优先级、负责人、修复版本与验证结果
打磨不是无限增加特效，而是消除妨碍目标体验的粗糙处：反馈是否及时，文字是否易读，动画与声音是否抢占注意力，等待是否有意义。性能目标也应按设备和作品类型事先约定，再通过测量判断。
交付与放行： 记录测试对象、环境、执行方式、结果、证据及未覆盖范围。已知阻断问题已处理；其他问题有接受、暂缓或修复决定。没有发现缺陷，不等于证明不存在缺陷。9（§1.3）
| 术语 | 含义 |
|---|---|
| Test Case／测试用例 | 前置条件、操作步骤、输入与预期结果组成的一次检查。 |
| Fixture／测试样本；Baseline／基线 | 前者是可重复使用的输入或状态，后者是用于比较的参考版本或结果。 |
| Profiling／性能分析 | 测量时间、内存等开销，定位瓶颈，而不是凭感觉优化。 |
| Polish／打磨；Pacing／节奏 | 打磨提升完成质量；节奏处理操作、阅读、演出和等待的分配。 |
| Game Feel／操作感；Balancing／平衡调整 | 前者关注操作及视听反馈的综合感受，后者调整规则、难度或收益关系。 |
| Blocker／阻断问题；Softlock／软锁 | 前者阻止必要测试或发布，后者通常指程序仍运行，但玩家无法正常推进。 |
这两个名称没有跨公司的统一完成百分比，应以本项目约定为准。可以参考下列关卡，但不要把参考当成唯一行业定义：3
| 名称 | 可采用的项目定义 |
|---|---|
| Alpha／阿尔法阶段 | 主要功能能够整体运行和测试，仍允许临时资源或缺失内容。 |
| Feature Complete／功能齐备 | 约定范围内的功能已实现；不自动代表内容齐备或质量合格。 |
| Beta／贝塔阶段 | 约定功能和内容接近齐备，主要处理缺陷、兼容性与体验问题。 |
| Content Complete／内容齐备 | 计划中的内容已接入，仍可能需要修改、校对与打磨。 |
| Freeze／冻结 | 对新增功能、内容或代码设变更门槛，不表示绝对不准修复。 |
目标：让玩家拿到可识别、可运行、可支持的成品。
固定待发布的提交、依赖和工具版本，生成候选成品，再对成品执行检查。源码目录运行正常，不能保证打包后的相对路径、压缩资源、字体和离线行为仍然正确。
UMWELT 示例。 项目的 Pages 发布流程会生成站点输出、处理字体子集，并为本地资源写入提交标识；这些步骤本身也需要验证。测试文档还列有针对最终发布目录的检查入口。因而“源码检查通过”和“发布成品检查通过”应分别记录。1113
浏览器和桌面分发也有各自的风险。UMWELT 已有桌面预发布形式，不能以网页能打开替代对安装包、离线启动、文件路径和保存行为的验收。1
体验与数据。 从首次进入测试到退出、恢复和更新。网页声音应考虑浏览器的自动播放限制，提供清楚的开启或静音操作。14 使用浏览器 localStorage 时，应注意它受来源隔离和浏览器策略影响，不是跨域云存档；更换域名、协议或运行方式前，要检查进度迁移与备份。15
发布材料。 准备作品说明、截图或预告、系统要求、操作说明、版本记录、已知问题和反馈渠道。内容不得夸大当前功能。面向商店发行时，按目标平台办理商店页、构建审核、分级和其他适用手续；例如 Steam 分别检查商店展示与游戏构建。16 这些准备应提前进入计划，而不是发布日期当天才开始。
权限与公开边界。 核对素材、字体、代码和音频的授权与署名；检查个人资料、调试数据、密钥及未获准分发的文件。涉及账号、统计或其他数据收集时，另行确认适用的隐私要求。自动生成内容也应经过来源和使用范围审核，不能把生成工具当作授权证明。
恢复能力。 保留上个稳定成品与明确的回退步骤。代码回退并不自动恢复已经迁移或覆盖的玩家数据；有存档格式变更时，需要独立准备兼容、备份或恢复方案。
交付与放行： 发布包或站点产物、版本与提交对应关系、上线清单、发行说明、已知问题和回退方案。部署后再从公开入口核对真实下载或访问结果。
| 术语 | 含义 |
|---|---|
| RC／Release Candidate | 候选发布版本；发现问题后可以产生下一个 RC。 |
| Release Build／发布构建 | 按正式分发配置生成的成品，不等于质量天然合格。 |
| Artifact／构建产物 | 工作流程生成的文件集合，例如站点目录或桌面安装包。 |
| Tag／版本标签 | 给某个提交标注稳定名称，便于定位发布来源。 |
| Deployment／部署；Release／发布 | 部署是把成品放到运行环境；发布是向目标玩家提供某个版本。两者不必同时发生。 |
| Certification／平台认证 | 满足特定平台的技术或发行要求；不等于艺术品质认证。 |
| Rollback／回退 | 恢复到已知稳定的程序或配置，数据恢复需另外考虑。 |
| Early Access／抢先体验 | 一种向玩家提供开发中产品的发行安排，不是 Beta 的同义词，也不能只靠未来功能承诺支撑当前产品。17 |
目标：控制发布后的风险，并让后续工作仍然可持续。
把玩家反馈转为能判断和复现的问题，区分程序缺陷、设计分歧、内容建议和设备环境问题。按影响与优先级处理，不必把每条建议立即变成功能。
扩展内容重新经过范围确认、影响分析、实现和验证。UMWELT 示例： 添加物种、环境或结局时，同时核对来源、现有标识、配套实验室、语言与存档，保留历史存档样本作为验证输入。511 对资料修订，要区分知识更新与游戏规则变化，不能悄悄让旧进度产生不同含义。
定期复盘预估与实际工作量、返工原因、漏测位置和玩家反馈。更新当前文档，将历史方案明确归档。停止维护时，也应说明状态，并在许可与平台条件允许的范围内保留版本、操作说明和必要的资料出处。
交付与放行： 补丁经过相应复测与回归，更新说明准确，兼容策略清楚，仍未处理的问题可以追踪。维护的目标不是永久新增，而是对作品的支持边界负责。
| 术语 | 含义 |
|---|---|
| Patch／补丁；Hotfix／紧急修复 | 补丁修正或调整已有版本；紧急修复针对需要快速处理的问题，仍需必要验证。 |
| Changelog／变更记录；Release Notes／发行说明 | 前者记录变化历史；后者面向某次发布说明功能、修复、限制与注意事项。 |
| Migration／迁移 | 把旧数据转换到新规则或格式，需要定义失败处理和兼容范围。 |
| LiveOps／持续运营 | 持续安排活动、内容或服务运营；不是所有单机、网页作品都需要这种模式。 |
| Postmortem／项目复盘 | 根据实际过程分析成效、成本、失误与改进，而不是只写成功总结。 |
| EOL／End of Life | 产品或某个版本结束支持的状态，应说明时间与影响范围。 |
对小型项目，不必为每个术语建立一份文档。至少维持五类记录：概念与范围、设计与接口约定、任务与缺陷、验证证据、版本与来源记录。它们可以分文件，也可以集中管理；关键是能找到当前有效版本，不让重复文档彼此冲突。
每次改动都可以套用同一条工作链：
明确需求与不改动范围
→ 分析资料、模块、存档和平台影响
→ 写验收条件并选择验证方法
→ 实现与审查
→ 执行相应测试和实际试玩
→ 记录证据、限制与残余问题
→ 合并、发布，并检查公开成品
最后要区分三种状态：实现完成，不等于验收通过；验收通过，也不等于已经发布。 流程的作用，就是让每一种状态都有对应的成果和证据。
以下资料用于流程框架、术语及项目案例核对；本文的任务拆分和验收示例为综合整理，不代表任何机构对 UMWELT 的评审。在线资料访问日期：2026-10-13。项目文档固定到仓库提交 0bbe083943a4b307e38e3ea0de435d3d7864a345，后续实际维护应另查当前版本。
[1] fivsevn. UMWELT: README［项目说明］. 固定版本. 用于作品组成、科学资料与模拟参数边界、AI 辅助说明及桌面分发案例。
[2] Bramble, R. (2023-05-10). The Seven Stages of Game Development. GameMaker. 原文. 用于开发阶段及跨工种协作的概览。
[3] Kraj, N. Game Development Process: Keys for a Better Pipeline. GDKeys. 原文. 用于原型、垂直与水平切片及生产关卡的实践区分；其中阶段划分属于作者的方法，不作为统一行业标准。
[4] Hall, J. T. Game Development, “Designing Your Game”. 原文. 用于设计文档、范围与独立制作的实践参考。
[5] fivsevn. UMWELT：扩展工作流［开发文档］. 固定版本. 用于新增品种、生境、叙事、语言与存档影响的案例。
[6] Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. 官方文本. 参见 Sprints、Product Backlog、Definition of Done。使用任务板或迭代方法不自动等于完整采用 Scrum。
[7] Chacon, S., & Straub, B. Pro Git, §1.1 “About Version Control”. 在线版. 用于版本控制的基本概念。
[8] GitHub. Continuous Integration. GitHub Docs. 官方文档. 用于自动构建、测试及集成检查。
[9] International Software Testing Qualifications Board（ISTQB）及大纲作者. (2024-09-15). Certified Tester Foundation Level Syllabus, v4.0.1. 官方入口 · 大纲 PDF. 参见 §1.2.2、§1.3、§2.2、§5.5；相关概念与原文权利归 ISTQB 及相应作者。
[10] Microsoft. Xbox Accessibility Guidelines. Microsoft Learn. 官方指南. 用于无障碍设计与检查方向；这套指南不等同于法律合规或平台认证结论。
[11] fivsevn. UMWELT: Test Layout［测试文档］. 固定版本. 用于自动检查、浏览器回归、基线比较与最终发布成品验证的边界。
[12] Microsoft. Emulation. Playwright Documentation. 官方文档. 用于设备与浏览器参数模拟的能力说明。
[13] fivsevn. UMWELT: Static Deployment and Asset Identity［发布文档］. 固定版本. 用于站点输出、字体处理、资源标识及发布验证案例。
[14] MDN contributors. Autoplay Guide for Media and Web Audio APIs. MDN Web Docs. 文档. 用于网页声音播放的运行约束。
[15] MDN contributors. Window: localStorage Property. MDN Web Docs. 文档. 用于本地存储的来源隔离、持久化边界及运行限制。
[16] Valve. Review Process. Steamworks Documentation. 官方文档. 用于商店页与构建分别审核的发行案例。
[17] Valve. Early Access. Steamworks Documentation. 官方文档. 用于抢先体验与当前产品承诺的概念区分。