20260511-日报-卓泽
输入“/”快速插入内容
20260511-日报-卓泽
20260511-日报-卓泽
用户4681用户46815月12日修改
一、工作内容概述
•
基于前期架构文档正式启动二合增量游戏的编码实现，按照完整架构思路搭建了包含完整核心系统边界的 MVP 原型
•
创建对应测试 Scene 进行运行验证，完成棋盘、合成、资源、任务、UI 与测试工具等基础链路的调试
•
复盘此前 API Key 异常用量问题，并且了解了背后的隐式思维链模型的技术基础
二、重点工作推进
2.1 完整架构 MVP 原型编码
此前已经完成二合增量游戏的整体系统拆分与核心流程设计，今天开始将这些结构落实到工程中, 从架构设计文档进入实际开发，目标不是先写一个孤立的小 Demo，而是在 MVP 阶段尽早按完整架构搭出可运行的基础骨架，方便后续逐步替换表现层、补充素材和扩展系统。
本次已按照架构创建并接入了核心游戏框架代码，覆盖棋盘、合成、资源、任务、UI、存档和运行时测试辅助等模块。当前测试 Scene 已能在完整架构下运行，支持基础棋盘显示、物品生成、拖拽、合成、资源变化和任务反馈等流程，为后续继续迭代玩法、表现和数据配置提供了可验证基础。
开发过程中也同步处理了多项会影响原型验证的问题：
•
修复 DontDestroyOnLoad 只能作用于根对象的问题，避免运行时管理对象持久化层级不正确。
•
修复运行时实例化对象继承 inactive 状态的问题，使棋盘格、生成物、任务需求和提示 UI 能正常显示。
•
修复合成成功时目标格子引用被提前清空的问题，保证合成流程稳定执行。
•
修复 Game 视图灰黑、运行时相机与 Canvas 配置冲突的问题，使测试 Scene 能在 Game 视图中正常显示。
•
修复拖拽时坐标系不一致导致物品瞬移偏移的问题，使拖拽交互能按鼠标位置稳定跟随。
•
将布局方向调整为手机竖屏，并重新整理棋盘、任务面板、体力条和生成按钮的位置关系。
至此, 核心系统逻辑已经基本跑通
2.2 测试工具与表现层准备
下一步打算重构 PrototypeSceneSetup.cs，并将棋盘、物品、任务面板、按钮和测试控制台等表现层对象逐步 Prefab 化。这样既能保留已经跑通的逻辑层，也能让后续美术素材填充、布局调整和交互动画接入更加稳定。
三、探索与复盘
3.1 API Key 异常用量原因复盘
今天复盘了此前 API Key 用量异常的问题。该问题主要出现在前期搭建 AI 工作流和横向测试不同模型输出质量的过程中。当时为了评估文档撰写、资料整理和 Skill 生成等流程，使用了 Gemini 与 GPT 系列模型进行对比，其中部分调用落到了价格较高且带有隐式长思维链特性的模型上。
复盘后判断，异常消耗并不是单纯由调用次数过多导致，而是由两个因素叠加造成：
第一，相关模型本身属于更偏研究和深度推理的模型，即使处理看似简单的资料收集或文档整理任务(这里是用来执行了拉取Git仓库并创建Skill的流程)，也可能在后台产生大量不可见推理 token。由于这部分消耗不直接体现在输入文本长度中，如果事前不了解模型特性，很容易低估实际成本。
第二，该模型在 OpenRouter 上的价格显著高于常规 Pro 模型，因此即便调用次数占比不高，也会在总消耗中占据很大比例。也就是说，本次异常用量的核心不是“所有调用都很贵”，而是少数高价模型在缺少成本边界时放大了整体消耗。
此外，这次使用的 Key 缺少明确的分组限额、用量提醒和预算告警。过去个人使用 API Key 时，通常会为不同工作流设置额度限制或平台侧风控，因此即使 Agent 出现请求异常、Session 未清理或循环调用，损失也会被限制在较小范围内。本次缺少这层保险后，异常消耗没有被第一时间拦截。
3.2 后续风控方案
这次复盘形成的主要结论是：AI 开发流程中，API Key 的成本控制需要被当作基础设施处理，而不能依赖事后人工检查。
后续改进方向包括：
•
到手 Key 后优先通过 One API 等工具进行二次分发，按用途拆分不同 Key 或渠道, 或者有条件, 轻量级地编写一个Key测试监测程序, 定期访问用量情况来监测异常(已添加备忘录)
•
新模型接入前先确认价格、上下文机制、特殊消耗特性等信息。
四、后续计划
•
重构测试用的 PrototypeSceneSetup.cs，将棋盘、合成材料、任务面板、测试控制台等表现层逐步 Prefab 化，为后续填充美术素材做准备。
•
尝试一下项目库嵌入，尝试创建项目文档库, 使Obsidian文档、项目代码和 AI Agent执行上下文能够统一起来, 减低文档迁移的成本
•
明天进一步研究 Codex /goal 指令，评估其是否适合作为后续自动开发流程的一部分。