长期协作中的设计一致性
Orbit 持续开发期间，设计不断迭代，Agent 会话也会更换；我还会在 Unity 中手动调整场景。为让后续任务继承正确的规则，我记录设计理由、约定修改范围，并根据实机结果决定下一轮调整。
判断体验与方向
通过实际游玩决定规则和取舍；把会改变玩法的实现选择提到设计层讨论。
实现、拆解与检查
分析影响范围，完成代码与资产操作，并提供可复查的差异和验证证据。
当前有效的记录
入口文档、模块契约、任务卡与交接记录，说明当前决定及尚未完成的验证。
- 01体验反馈我提出问题与目标
- 02规则落地讨论状态与影响范围
- 03任务交接文档、边界与验收点
- 04实现与检查Agent 交付差异和证据
- 05实机判断我手测，再决定保留或修改
我现在判断一次协作是否可靠，会看下一个接手者能否说明：玩家为什么需要这项变化，当前规则是什么，本轮实际改了哪里，以及还有什么没有验证。
作者笔记节选 · Orbit 协作实践
Orbit：营地与休息规则的重构
早期营地包含独立场景与撤离流程。反复游玩后，我更希望玩家自由往返、观察生态和安排探索；封门、进出存档等步骤也打断了节奏。最终将休息点收拢到床，工作台与储物箱在附近配合使用。
我提出体验方向，Agent 协助追踪时钟、保存、复活点和道具归属之间的关系。任务开始前，先把这些会影响玩家进度的规则写清楚。
| 设计问题 | 落实为可交接的规则 |
|---|---|
| 下一轮何时出发？ | 休息可以选择清晨或黄昏。 |
| 退出后从哪里继续？ | 退出保存当前位置与进度。 |
| 何时更新复活床？ | 仅在成功休息后更新最近复活床。 |
| 能否靠反复休息接力搬运？ | 尚未交付的光核在休息后返回初始底座。 |
修改体验时，还需要处理旧数据：旧 CampSite 已不再代表需要封门的区域，但仍承担历史身份与兼容职责，不能只凭名称把它删除。
设计可以改变，已经产生的数据需要有明确的迁移办法。
作者笔记节选 · Orbit 协作实践
文档与任务交接
主线会话保留方向、优先级与审查结论，分支任务承接具体实现。交接卡列出需读文档、允许修改的范围、必须保留的行为，以及交付时的检查项。
共享 Unity 编辑器由一个任务操作；其他任务可在明确边界内分析和修改代码。对于我手调的碰撞体、场景和资产，先记录现场，再检查本轮差异。
如果只说“你做床、你做灯、你做地图”，三个 Agent 很可能各自完成了一套局部合理、互相不兼容的实现。任务之间需要约定谁产生状态、谁保存状态、谁只负责显示，以及失败时应该保留什么。
作者笔记节选 · Orbit 协作实践
科研系统中的协作实践
先约束动态生成的行为
面对无法预先枚举的历史人物与事件，反复调整提示词结构、角色描述与输出格式；结合同行反馈排查含义不清的指令。
让实现围绕研究问题收敛
在时间与条件有限时，明确系统要验证什么，对次要功能作取舍；技术阻碍出现时评估替代方案。
在 ChronoFork 中，我参与机制和交互设计，正式实验由我独立负责；在 MAVIS 中，我负责 VR 前端系统设计与开发，并与合作者共同开展用户实验。
实现代码几乎全部由 AI 生成，我们做的是设计的取舍：要不要加某个功能、提示词逻辑怎么组织等等。
作者笔记节选 · ChronoFork 项目经验总结
三个实践判断
关于设计主导权、验收范围与协作成本的项目笔记。
同样是“黄昏收缩”，为什么会通向不同的玩法？关于设计主导权 · 原文节选
假设我们希望藤蔓在黄昏收缩，让玩家通过。AI 可以让藤蔓响应昼夜切换，也可以让它响应环境光照。两种方案在黄昏时看起来完全一样，却通向不同的游戏：前者鼓励玩家规划时间，后者允许玩家通过遮光、照明操纵环境。选择哪种实现，已经是在决定玩法。一个满足需求的结果，可能同时隐藏了一个用户尚未意识到的设计选择。
作者笔记节选 · Agent 越来越强，我们该关注什么
通过编译之后，离“玩家体验正确”还有多远？关于验收范围 · 原文节选
编译通过，只能说明相应的编译检查通过；隔离场景中的组件测试，可以证明特定路径的行为；实际 URP 或 UI Toolkit 渲染能够提供视觉证据；完整 Play、存档续玩和分发包测试，还需要各自的验证。音量曲线的数值正确，也不能直接推出音乐听起来足够压抑。
作者笔记节选 · Orbit 协作实践
文档与检查，什么时候也会成为负担？关于协作成本 · 原文节选
存档和跨系统迁移值得认真检查，而一个范围明确的视觉微调，不一定需要扩展一整套测试设施。检查应当回答真实风险，文档应当服务下一次决策；如果只是不断增加材料，维护负担最终还是会回到我身上。
作者笔记节选 · Orbit 协作实践