Evilom
50 lines
7.3 KiB
Markdown
50 lines
7.3 KiB
Markdown
# ZKeNw6V9ViwCH3kyAM9cOYSpntf
|
|
|
|
Source: https://dianchukeji.feishu.cn/wiki/ZKeNw6V9ViwCH3kyAM9cOYSpntf
|
|
|
|
|
|
# 2026.5.12 日报
|
|
## 一、工作内容概述
|
|
- 在昨天跑通基础游戏循环的基础上，继续推进二合增量游戏从可玩到完整过渡，重点完善存档、测试控制台、Prefab 接入、金币生成逻辑和 UI/资产替换流程。
|
|
- 封装了一个可供 AI 稳定调用的图像抠图工具，支持输入图像并输出透明底素材，为后续 AI 生成美术资产后的自动化处理做准备。
|
|
- 配通 Amazon Bedrock Claude 4.6 在 OpenCode 中的调用方式，并初步配置试用 Codex /goal，继续补齐 AI 辅助开发工具链。
|
|
- 整理并写入 SO 配置与开局接入说明文档，用于后续规范项目配置、UI 皮肤、合成物素材和大等级链条的接入方式。
|
|
## 二、工具链与资产生产
|
|
### 2.1 AI 抠图工具封装
|
|
今天封装了一个输入图像、输出透明底图片的工具，基于 https://sync.koukoutu.com/v1/create API 实现。这个工具后续可以作为 AI 美术生产链路的一部分：当 AI 生成角色、建筑、道具或 UI 元素后，可以自动调用抠图工具得到透明底素材，经过测试处理效果非常令人满意, 十分方便后续进入 Unity 项目进行配置或二次处理。
|
|
这类工具本身不直接等同于游戏功能，但对 AI 全栈开发很关键。因为 AI 生成素材经常会带背景、边缘或不稳定格式，如果每次都人工处理，会打断开发节奏。把它封装成稳定工具后，后续可以并入节点流程，让“生成素材 -> 抠图 -> 导入项目 -> 配置测试”这条链路更接近自动化。
|
|
|
|
处理的UI对比
|
|
|
|
|
|
### 2.2 Bedrock Claude 4.6 接入 OpenCode
|
|
今天还配置并验证了 Amazon Bedrock Claude 4.6 在 OpenCode 中的调用方式。由于 AMS比较特殊的认证机制(需要单独配置)以及其地区限制, 需要修改配置文件，在参考了韦译的修改以及查阅了 OpenCode 文档之后，并进行了多轮配置调整，最终调试到了可以使用的状态.
|
|
|
|
## 三、重点工作推进
|
|
### 2.1 UI 与资产接入
|
|
今天开始把测试用美术素材实际接入到项目中。当前已经支持棋盘格和合成物通过 Prefab 配置图片，并修复了运行时代码覆盖 Prefab 图片的问题。此前即使在 Inspector 中替换了 Image，运行时仍可能被默认逻辑清空或染色；今天调整后，配置了图标时优先使用配置图，Prefab 自身有图时保留 Prefab 图，只有两边都没有图时才使用临时颜色兜底。
|
|
测试用美术素材使用GPTImage2生成之后直接令AI调用脚本进行处理, 实现了AI创建-生成-配置的闭环
|
|
|
|
在 UI 方面，新增了 UiSkinConfigSO，用于集中配置背景、金币框、金币图标、任务框、棋盘框、生成按钮、战斗按钮等 UI 资产。
|
|
还有些bug这块, 对棋盘居中问题进行了修复。此前棋盘位置计算中混用了逻辑单位和 UI 像素，导致表盘在不同分辨率下稳定偏移。今天统一为 UI 像素计算，使棋盘能围绕父节点中心展开。
|
|
### 2.2 玩法循环与测试能力完善
|
|
今天首先对昨天跑通的基础循环进行了局部重构和Bug修复。昨天的重点是让完整架构下的核心玩法能实际跑起来；今天的重点是让这个循环更适合持续测试、继续填充素材，并为后续从测试 Scene 过渡到正式表现层做准备。
|
|
本次对此前用于跑通了流程的运行时搭建部分做了拆分：将 PrototypeSceneSetup 中混在一起的运行时 View 创建逻辑拆出，单独整理为棋盘和 HUD 的构建逻辑。这样后续可以保留已经跑通的逻辑层，同时逐步把棋盘、合成物、按钮、任务面板和测试控制台替换成更正式的 Prefab。
|
|
|
|
同时修复了存档不稳定的问题。此前 Save 按钮虽然会触发保存，但棋盘物品在拖入格子后已经不在原本的父节点下，导致存档系统可能扫不到实际棋盘内容。今天将保存逻辑改为从棋盘格上的实际占用物品收集数据，并在测试控制台中补充了存档路径、是否存在存档和自动保存状态
|
|
后续测试不再只靠“看起来有没有生成”，而是可以验证一轮更完整的状态闭环，包括生成、合成、金币变化、保存、退出后恢复等流程。
|
|
### 2.3 配置体系文档整理
|
|
随着合成物等级、UI 皮肤、棋盘格、生成器和任务配置开始接入，今天也整理了一份项目配置与使用说明文档，写入项目文档目录。文档主要用于说明开局前需要准备哪些 ScriptableObject、每个配置的作用、推荐存放路径、挂载关系，以及常见的“配置了但运行时不生效”的原因。
|
|
## 四、探索与方法复盘
|
|
### 4.1 Codex /goal 初步试用
|
|
今天初步配置并试用了 Codex /goal 指令。该功能适合长时间、有明确验收条件的任务，例如代码迁移、大型重构、复杂实验、游戏原型持续迭代等。它的核心不是让 AI 随意长跑，而是先定义一个清楚目标、停止条件和验证方式，再让 Codex 在这个范围内持续推进。
|
|
初步判断是：/goal 比较适合后续用于“边界清晰、可验证”的开发任务，例如某个模块的 Prefab 化、配置系统重构、批量迁移或测试修复循环。对于开放式探索、模糊方案讨论或需求尚未定型的任务，则不适合直接使用, 容易导致模型反复撞墙。
|
|
这部分今天只完成初步试用和适用场景判断，后续会选择一个更具体的工程任务继续验证。
|
|
### 4.2 当前进度判断与阶段对齐
|
|
这两天的开发方式整体偏瀑布式：此前先按照 AIM4 可上线版本的要求设计完整架构，再逐步填充符合该架构的基础系统实现。也就是说，当前并不是只做一个临时小原型，而是在较早阶段就把存档、资源、任务、UI、配置、测试工具和后续扩展边界一起纳入考虑。
|
|
昨天主要完成的是完整架构下基础玩法循环的跑通；今天则继续补齐测试、存档、Prefab、UI 皮肤、金币生成和测试美术素材接入。当前结果已经从“能运行”继续向“能看、能玩、能配置”推进。
|
|
目前来看，整体进度符合预期。不过这块也暴露出一个沟通问题：架构先行的工作量，在视频演示中可能不如单纯做一个表层原型直观。此前的视频展示的简单合成循环，但背后实际推进的是后续可扩展的系统骨架。因此后续需要进一步和对齐一段时间内的阶段目标、验收口径和节奏预估，或者换用更可视化的敏捷开发标准以可运行可展示为各个里程碑目标。
|
|
## 五、后续计划
|
|
- 确定局外的大循环, 开始实际使用战斗系统或者订单系统
|
|
- 将当前的测试对象逐步转为确定的正式资源。
|
|
- 对齐后续阶段性目标和预期节奏 |