Evilom
631 lines
62 KiB
Markdown
631 lines
62 KiB
Markdown
# KshwdqwFuoSOKjxzYCjcn8THn6f
|
||
|
||
Source: https://fcnlycv6dd0w.feishu.cn/docx/KshwdqwFuoSOKjxzYCjcn8THn6f
|
||
|
||
|
||
# 环节一：李总课堂分享
|
||
## 主题：《AI 工作方式与学习能力建设》
|
||
AI 不只是提高效率的工具，而是正在改变人的**工作边界、组织分工方式、软件生产方式和学习方式**。适应 AI 的关键，不是掌握几个固定技巧，**而是形成一种新的工作认知和学习能力**。
|
||
## （一）AI 时代的基本判断
|
||
#### **对 AI 的最浅层理解****，是把它看作一种 “更好用的工具” **
|
||
可以写文案、整理表格、画图、写代码、节省时间。这种理解有一定道理，但不够完整。AI 的更深层影响在于，**它开始介入过去只有人类才能完成的认知劳动、判断劳动和组织劳动**。
|
||
**传统工具通常是人的能力延伸：**
|
||
例如，电脑提高信息处理效率，手机提高沟通和移动办公效率，搜索引擎提高获取信息的效率。
|
||
AI 则进一步介入**“理解、生成、分析、规划、执行、复盘”**等环节。它不仅帮助人完成动作，还能参与任务拆解、方案生成、逻辑推理和系统优化。
|
||
#### **AI 认知升级**
|
||
|
||
> [嵌入电子表格: IEZksvz4Wh7zHatxN3sc...]
|
||
|
||
**核心判断：**AI 的关键价值不只是把原来的事情做得更快，而是让个人和组织**可以处理过去无法处理、成本过高或难以规模化处理的问题****。**因此，AI 带来的变化不是单点工具升级，而是工作方式、组织方式和学习方式的整体升级。
|
||
|
||
> :black_medium_small_square:
|
||
#### 延伸判断：AI 带来的压力、机会与能力上限
|
||
- **AI 既是压力，也是机会**
|
||
那些能够重新设计流程、重新定义岗位、重新学习的人，则会获得新的成长空间。
|
||
AI 会接入一部分机械性、重复性、规则明确的工作环节，压缩传统人工堆叠型工作的价值，也会对个人技能边界和组织分工方式形成压力。但同时，AI 也会放大个人和小团队的能力，使其能够完成过去需要更多人力和时间才能完成的工作。
|
||
- **AI 改变的是能力上限，不只是工作效率**
|
||
未来的能力差距，不只是“谁懂得更多”，而是“谁更会调动知识、组织知识，并转化为实际产出”。
|
||
## （二）AI 对工作方式的重构
|
||
#### **机械性工作会率先被压缩**
|
||
AI 对工作的影响，首先会体现在机械性、重复性、规则明确的工作环节上。这类工作通常有明确输入、明确规则和明确输出，例如资料整理、表格汇总、基础文案、标准化客服、简单申报材料、初步数据清洗等。
|
||
**岗位中的低价值环节会被快速压缩**。人的价值会从“亲自完成每一个步骤”，逐步转向“定义任务、判断质量、处理例外、优化流程”。
|
||
|
||
> [嵌入电子表格: IEZksvz4Wh7zHatxN3sc...]
|
||
|
||
#### 不会使用 AI 的隐性成本会提高
|
||
当 AI 成为组织能力的一部分时，不会使用 AI 的个人会逐渐面临能力差距。
|
||
过去，一个人不会某个软件，可能只是效率较低。未来，一个人不会调动 AI，可能会影响其理解复杂任务、处理跨领域问题和完成高密度工作的能力。
|
||
AI 能力会像电脑能力、智能手机能力一样，逐步成为基础能力。**区别在于，AI 不只是操作界面，而是进入思考、判断、生成和创造环节。**
|
||
#### 岗位边界正在被重构
|
||
AI 对公司的冲击，不是简单“不要某个岗位”，而是原有的岗位分工方式不再稳定。
|
||
**AI 介入以前：**组织通常按照策划、美术、程序、测试、财务、人事、运营等专业岗位进行分工，每个岗位负责自己的部分，再通过流程向下游交付。
|
||
**AI 介入以后：**不是只替代某一个岗位，而是会进入多个岗位内部，接管其中一部分任务。这意味着岗位不会简单消失，但岗位内部的任务结构会发生变化，真正被压缩的往往是**旧分工、旧流程和旧工作习惯**。
|
||
|
||
> [嵌入电子表格: IEZksvz4Wh7zHatxN3sc...]
|
||
|
||
AI 时代仍然需要专业能力，但只守住单一岗位技能已经不够。未来更重要的角色，是能够把目标、工具、流程、数据、标准和反馈组织起来，并让 AI 和人共同形成生产系统的人。
|
||
## （三）AI 工作范式的演进
|
||
**AI 使用方式正在从“写提示词”转向“建立工作循环”，再进一步转向“优化生产系统”**。这意味着，AI 能力不只是会不会提问，而是**能否把 AI 纳入稳定、可复用、可持续改进的工作流程**。
|
||
|
||
> [嵌入电子表格: IEZksvz4Wh7zHatxN3sc...]
|
||
|
||
**新角色：**
|
||
在 AI 流程中，人的价值会从“亲自执行任务”，逐步转向“定义目标、设定约束、判断质量和优化系统”。AI 负责大量生成、执行、测试和反馈，人负责方向判断、价值判断、质量判断、边界控制和系统改进。
|
||
## （四）AI 原生能力与学习方式
|
||
- AI Coding 的意义不只是帮助程序员写代码，而是让更多业务需求可以被快速转化为小工具、小脚本、小页面和自动化流程。
|
||
- AI 原生能力是能够自然地把 AI 融入思考、学习、工作和问题解决过程。就像移动互联网时代，人们可以自然使用手机完成点餐、支付、导航、社交和办公一样，AI 原生人群会自然地让 AI 参与日常任务。
|
||
**AI 原生能力包括：**
|
||
|
||
> [嵌入电子表格: IEZksvz4Wh7zHatxN3sc...]
|
||
|
||
**核心判断：**未来的能力差距，不只是“谁懂得更多”，而是“谁更会调动 AI、组织知识、判断结果，并把 AI 产出转化为实际工作成果”。
|
||
## （五）AI 学习与使用经验分享
|
||
#### 分享一：用 AI 快速进入陌生领域
|
||
#### 分享二：用 AI 定制个人学习路径
|
||
#### 分享三：收集知识、整理知识、吸收知识、使用知识（四个效率）
|
||
#### 分享四：在使用 AI 中完成思维迭代
|
||
AI 的价值不只是完成单点任务，也会在持续使用中改变人的思考方式。使用者会从简单对话逐步转向工作流、循环和验证式使用，并在与 AI 共同探索中拓展问题视角和思维边界。
|
||
|
||
> :black_medium_small_square:
|
||
#### 总结：学习 AI 的关键是学会提问和持续反馈
|
||
- AI 学习的关键不只是获取答案，而是学会把复杂问题拆成自己能够理解和吸收的形式。可以要求 AI 用更简单的话解释概念、用案例或故事说明原理，也可以让 AI 反复举例、出题测试、检查自己是否真正理解。
|
||
- AI 的优势在于不厌其烦，可以不断根据人的反馈调整解释方式。因此，使用 AI 学习时，不必停留在“问一次、拿一个答案”，而要通过不断追问、复述、验证和应用，把外部知识逐步转化为自己的理解能力和工作能力。
|
||
#### 【推荐书单】：
|
||
|
||
|
||
|
||
# 环节二：课堂分享纪要
|
||
## **一. 《基于SDD思路的AI生成原型探索》**
|
||
**分享人：左颜昊（厦门）**
|
||
### （一）重点提炼
|
||
#### 背景问题：PRD、原型、说明三者容易不一致
|
||
- AI 能根据需求生成 PRD、原型预览和功能说明，但第一版通常还需要调试。
|
||
- 后续修改时，经常出现只改了 PRD、漏改原型，或只改了功能说明、漏改相关联模块的问题。
|
||
- 对下游开发、测试或 AI 来说，如果多个产物“相似但不同”，就会产生疑问：到底哪个才是要接收和执行的标准。
|
||
#### 三种 Spec 驱动模式
|
||
- **Spec First**：Spec / PRD 只用于生成初版产物，后续不再维护文档，而是直接基于产物修改。
|
||
- **Spec as Anchor**：Spec / PRD 作为锚点长期维护，每次先修改 Spec，再基于 Spec 修改原型或代码产物。
|
||
- **Spec as Source**：Spec / PRD 是唯一真相源，每次都基于 Spec 重新生成产物；该方式更激进，当前阶段成本较高，暂不适合现有流程。
|
||
#### 实验设计
|
||
- 实验对比了不同流程下 AI 在多轮迭代中的一致性表现。
|
||
- 主要测试三类修改：单模块字段增删改、跨模块联动修改、功能级新增 / 修改。
|
||
- 观察指标包括：产物之间是否一致、是否满足需求、需要人工干预几次。
|
||
#### 实验结论
|
||
- **严格先改 PRD、再改原型的流程**，整体一致性最好，但人工操作成本较高。
|
||
- **只保留产物、不维护 PRD**，在简单场景下效率更高，但复杂场景容易漏改跨模块内容。
|
||
- **PRD 和产物都放着，让 AI 自己判断怎么改**，效果反而最差，容易出现改 A 漏 B、后续也不举一反三的问题。
|
||
- 如果 AI 漏改后人工及时纠正，它后续会在上下文中修正；如果不纠正，错误会持续累积。
|
||
#### 对流程的调整
|
||
- 分享人倾向于将 PRD 和原型拆成两个明确流程，而不是依赖 Skill 自动保证一致性。
|
||
- 复杂场景下更适合由人工先确认 PRD 变更，再让 AI 基于新 PRD 修改原型或代码。
|
||
- 没有维护的参考文档风险较高，甚至不如不放；因为它会干扰 AI 判断。
|
||
### （二）讨论交流
|
||
#### **关于 Spec 三种模式的理解**
|
||
- **问题**：Spec First、Spec as Anchor、Spec as Source 的区别是什么？
|
||
- **回答**：Spec First 是文档生成初版后即丢弃，后续以产物为准。Spec as Anchor 是文档持续维护，后续产物围绕文档同步修改。Spec as Source 则是每次都基于文档重新生成产物，最强调文档权威，但现阶段成本较高。
|
||
#### **关于“都放着让 AI 自己看”的风险**
|
||
- **问题**：为什么同时放 PRD 和原型，让 AI 自己判断反而效果更差？
|
||
- **回答**：因为 AI 不一定能自动判断哪个产物是最新、哪个字段需要联动更新。多个相似但不一致的产物会干扰判断，导致它改了一个地方、漏掉另一个地方。
|
||
#### **关于项目规则和 Skill 的差异**
|
||
- **问题**：Codex 项目规则和 Skill 都能约束 AI 行为，它们有什么差异？
|
||
- **回答**：项目规则更像当前工程内的通用约束，可按全局、项目、目录等层级生效。Skill 更像面向具体任务的流程能力，可跨项目复用。二者目的相近，但一个偏工程规则，一个偏任务流程。
|
||
#### **关于工程思维**
|
||
- **问题**：这个实验对非程序岗位有什么意义？
|
||
- **回答**：讨论认为，AI 时代每个人都需要具备基本工程思维。不是要求策划、美术都写代码，而是要理解需求、文档、代码、测试、部署之间如何互动，理解数字产物是如何在不断增加、删除、修改中迭代演变的。
|
||
## **二. 《HTML小游戏开发工作流分享》**
|
||
**分享人：刘桥滨（广州）**
|
||
分享的核心，不是单独展示某一个 AI 工具，而是展示一套“AI 参与游戏开发”的连续工作流：先把想法变成方案，再把方案变成原型，最后把原型、资源、经验和项目记录沉淀为可复用资产。
|
||
**创意发散****→****方案文档****→****系统拆解****→****快速原型****→****美术包装****→****资源接入****→****项目沉淀****→****经验蒸馏****→****跨项目复用**
|
||
### （一）点子创意：从想法到方案准备
|
||
点子创意阶段的目标，是把初步想法、参考项目或已有玩法，快速整理成可以讨论、可以验证、可以继续开发的方案入口。
|
||
|
||
> :black_medium_small_square:
|
||
##### 创意发散
|
||
|
||
> :black_medium_small_square:
|
||
##### 系统拆解
|
||
|
||
> :black_medium_small_square:
|
||
##### 方案文档
|
||
#### 创意发散：让 AI 帮助扩展想法
|
||
当只有一个初步想法时，可以先和 AI 进行多轮对话。例如“我想做一个开宝箱游戏”，AI 可以围绕玩法结构、交互方式、界面表现和可能的扩展方向生成初步框架。人的作用是不断筛选、修正和补充，把不符合预期的部分删掉，把有价值的方向继续放大。
|
||
#### 系统拆解：把参考项目转化为可复用文档
|
||
如果已有参考项目，可以把视频、网址或录屏交给 AI，让它自动分析界面、流程和规则。AI 在不确定的位置会提出确认问题，例如某个选项是否固定、某个流程是否有条件限制。确认后，AI 再把结果整理成结构化文档。
|
||
#### 方案文档：从“人能看懂”到“AI 能执行”
|
||
方案文档不只是给人看的说明，也可以进一步转化为给 AI 使用的开发文档。文档中可以包含模块信息、交互信息、数据需求、界面结构和线框图，使后续原型开发更容易衔接。
|
||
|
||
> [嵌入电子表格: IEZksvz4Wh7zHatxN3sc...]
|
||
|
||
**核心：**点子创意阶段的重点，是把想法和参考案例快速整理成可以讨论、可以验证、可以继续开发的方案入口。
|
||
### （二）原型开发：从方案到可体验 Demo
|
||
原型开发阶段的目标，是把方案文档进一步转化为可运行、可试玩、可验证、可继续优化的小游戏 Demo。 这个阶段不是一次性做成完整产品，而是先让玩法跑起来，再通过试玩、资源接入和界面优化，不断贴近真实体验。
|
||
|
||
> :black_medium_small_square:
|
||
##### 快速原型
|
||
|
||
> :black_medium_small_square:
|
||
##### Skill 辅助
|
||
|
||
> :black_medium_small_square:
|
||
##### 资源接入
|
||
|
||
> :black_medium_small_square:
|
||
##### 动态与调整
|
||
在当前 AI 能力下，只要目标和方案说明足够清楚，就可以把方案文档交给 Codex 等工具， 快速生成初步游戏原型 / 浏览器可运行原型。
|
||
人的重点不再是从零搭建每个模块，而是明确目标、检查结果，并判断原型是否符合最初想法。 原型阶段首先验证的是：**核心玩法能否跑通、核心交互是否成立、整体体验是否有继续优化的价值**。
|
||
- **Game Design Skill：** 更偏“玩法怎么跑起来”
|
||
用于识别任务类型、选择实现路线、 锁定核心玩法、明确 UI 与资产边界，并完成测试交付。
|
||
- **UI UX Pro Max** ：更偏“界面怎么更像真实产品”
|
||
用于分析需求、生成设计系统、 补充界面规则、完成体验质检和优化交付。
|
||
这类 Skill 的价值，是降低非程序、非美术人员理解开发框架、界面规则和搭建原型的门槛，让更多人能把想法转化为可体验 Demo。
|
||
只有线框图的原型，很难判断真实体验，因此需要进一步接入图标、按钮、角色和界面素材。
|
||
- 可通过 GPT 图像生成、PS 批处理、cep-plugin 等方式处理静态资源。
|
||
- 由于 AI 在抠图、拆图等细节上还不完全稳定，实际操作中仍需要结合 PS 或自制辅助工具，主要用于降低重复处理成本。
|
||
- 处理后的资源再通过命名、尺寸和比例规范化，交给 AI 进行界面拼装。
|
||
在静态资源基础上，还可以进一步把图片转为视频或分帧素材，通过 Frame Ronin、sprite-video-lab 等工具输出动画序列， 让角色和 UI 更有反馈感和生命感。
|
||
对于 HTML 原型，也可以借助 HTML UI Editor 或类似可视化工具查看控件位置、尺寸和界面结构， 降低手动调整成本，并为后续转向 Unity 或其他正式引擎开发提供更规范的中间版本。
|
||
### （三）循环沉淀：从单个项目到生产系统
|
||
循环沉淀阶段的目标，是避免一个个项目变成零散片段，而是把项目、模块、经验和创意沉淀成可复用、可组合、可持续改进的资产。
|
||
|
||
> :black_medium_small_square:
|
||
##### 项目记忆
|
||
|
||
> :black_medium_small_square:
|
||
##### 经验蒸馏
|
||
|
||
> :black_medium_small_square:
|
||
##### 跨项目复用
|
||
- 通过 Obsidian 等本地知识库记录项目。每个项目启动时，先建立项目档案，记录项目名称、类型、目标、用途、玩法、系统和关键模块。
|
||
- 价值：项目不会只停留在本地目录或个人记忆中，而是形成可追溯、可管理、可继续补充的项目记录。后续玩法、数值、系统、界面等变化，也可以在开发过程中持续写入。
|
||
- 当项目数量增多后，玩法、系统、UI、资源和开发经验会变得多、杂、乱。因此需要持续分类、提炼和通用化。
|
||
- 重复出现的玩法可以归类为玩法模块，重复出现的系统可以整理为系统模块，UI、资源和问题处理经验也可以逐步沉淀为可复用资产。这样，项目经验就不会随着单个项目结束而流失。
|
||
- 当沉淀的模块足够多、足够清晰后，可以进一步用 AI 重新组合玩法模块、UI 模块、系统模块和资源模块，生成新的项目方向。
|
||
- 真正的目标不是只做出一个游戏，而是搭建一套可以持续产生创意、快速验证、沉淀经验并复用模块的生产系统。
|
||
**核心：**
|
||
循环沉淀阶段的重点，是把单个项目中的玩法、系统、资源和经验保存下来，并通过知识库、作品平台和模块化整理，转化为团队后续可复用、可组合、可持续进化的生产资产。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
> :black_medium_small_square:
|
||
### 李总点评：从做项目到搭建生产系统
|
||
AI 时代真正重要的能力，不是让 AI 替自己完成某个具体任务，而是能够围绕目标搭建一套可运行、可反馈、可沉淀、可持续优化的生产系统。
|
||
## **三. 《 AI 原型到 Unity 小游戏落地》**
|
||
**分享人：张视野（广州）**
|
||
### （一）重点提炼
|
||
#### **工作室愿景与项目方向**
|
||
- **工作室愿景：**每个人身兼策划、美术、程序岗位，做出受市场认可的游戏。目前明确做快节奏、快落地的小游戏方向。
|
||
- **工程化落地问题：**从原型到 Unity 小游戏缺工程化落地链路，需解决原型中 UI 资源、数据交互和规则进入现有小游戏框架的问题，使其成为可维护模块，符合项目规则。
|
||
#### **AI 工具的作用与现状**
|
||
- **AI 工具功能：**
|
||
- 程序利用 Codex 技能将策划的 HTML 原型自动化拼装成 UI 预制体，能搭出第一版结构，但工作流不成熟，产物粗糙，需人工二次调整。
|
||
- **AI 现实价值：**
|
||
- 辅助拆解需求，将视觉模型拆成 UI 区域、节点层级和复用结构；读懂项目规则，告知页面落地应触发的规则和路径；识别风险，列出工程任务，提醒自动化能力边界。
|
||
#### **未来改进方向**
|
||
- **提高还原质量：**优化布局识别、字体样式和分辨率适配，减少手工摆放。
|
||
- **建立资源流程：**让 AI 识别资源，输出缺失资源清单，建议命名规范，接入小图图集流程。
|
||
- **还原业务模块：**分析原型落地所需的 model 和方案，将页面方案推进到业务模块生成。
|
||
- **实现自动验证：**建立自动验证闭环，边生成或修改后自动触发编译检查、源路径检查、平台配置检查和构建检查，并反馈结果。
|
||
|
||
> :black_medium_small_square:
|
||
**总结：**
|
||
当前 AI 更现实的价值，不是让程序完全不用写代码，也不是把粗糙原型直接变成上线产品，而是**让想法更快变成原型，让原型更快接入工程，让工程问题更早暴露**。
|
||
## **四. 《 AI 全栈游戏开发工作流》**
|
||
**分享人：韦译（广州）**
|
||
### （一）重点提炼
|
||
#### AI 全栈的定义
|
||
- **全栈**：依靠 AI 能力，由单人承担策划、程序、美术等多岗位职责，完成从设计、代码实现到美术资源接入的单体功能落地。
|
||
- **AI 原生**：AI 深度嵌入工作流各环节，包括概念设计、需求讨论、代码实现、资源接入甚至引擎操作。没有 AI，该流程难以跑通。
|
||
#### 当前探索的几类工作流
|
||
- **策划到程序实现工作流**：以敏捷开发和快速迭代为核心，提高开发效率，同时通过流程约束保证一定质量。
|
||
- **AI 配表工作流**：尝试使用更适合 AI 读取和操作的表格格式，提高自动配表效率，但仍需人工检查，正确率暂低于传统 Excel。
|
||
- **AI 美术资源管线**：覆盖美术设计、规范制定、后处理入库、导入引擎等流程，本次分享暂未展开。
|
||
#### 核心思想：功能驱动，而非文档驱动
|
||
- 传统开发依赖详细策划案、程序开发、策划验收、测试排查，流程稳定但沟通链路长、返工成本高。
|
||
- AI 全栈流程更强调人与 AI 直接讨论需求，让代码和功能本身成为最终“真相”。
|
||
- 文档仍会存在，但主要用于上下文对齐、阶段记录和回溯，属于“即用即抛”，而非长期维护的核心资产。
|
||
#### 核心思想：小步快跑，快速迭代
|
||
- AI 上下文有限，不适合一次性处理过大的系统，因此需要将大功能拆成多个小功能。
|
||
- 每完成一个小功能后，立即验收、测试、反馈、修复，形成高频迭代循环。
|
||
- 这种方式利用了 AI 开发速度快、纠错快、重写成本低的特点，适合小型项目和原型项目。
|
||
#### 具体流程
|
||
- **前置准备**：先与 AI 对齐玩法方向、技术方案、美术风格，并寻找同类玩法的技术方案，避免从零造轮子。
|
||
- **上下文文档**：准备游戏设计文档、技术架构文档、美术方案文档、系统功能拆分文档，用于帮助 AI 理解项目。
|
||
- **架构约束**：通过 view layer、controller layer、model layer、service layer 等分层方式，强制 AI 按架构写代码，提高代码质量。
|
||
- **Superpower 工作流**：通过“想清楚 - 写清楚 - 子 Agent 执行 - 验证修复”的流程，让 AI 开发更有章法，减少需求误解、上下文遗忘和修复连带问题。
|
||
#### 实战效果
|
||
- 以一个二合玩法小游戏为案例，展示了 AI 全栈流程的落地效果。
|
||
- 前几天快速完成基础架构、棋盘、拖拽合成、测试美术接入和初步 UI。
|
||
- 约两周内实现主要功能、完整 UI、基础关卡与数值体验。
|
||
- 一个多月后，已接入较完整的局内、局外、商业化页面、剧情对话、物品详情、合成链等内容，整体完成度约 60%。
|
||
#### 当前局限
|
||
- 用户需求描述不清时，AI 容易理解偏差，需要通过 AI 反问来辅助需求对齐。
|
||
- AI 开发速度快，但代码质量不稳定，需要人为设定架构并定期重构。
|
||
- 小项目效果较好，大项目容易出现上下文不同步、模块理解不完整等问题。
|
||
- AI 全栈流程与传统团队分工存在冲突，如何嵌入现有团队流程仍需探索。
|
||
|
||
> :black_medium_small_square:
|
||
**总结：**
|
||
AI 全栈开发目前更适合小型项目、原型项目和探索性项目。它的优势是开发快、迭代快、沟通链路短；风险是代码质量不稳定、上下文有限、工程化和团队协同仍需继续沉淀。
|
||
### （二）讨论交流
|
||
#### **关于智能体拆分与工作流定制**
|
||
- **问题**：当前工作流是否需要拆分不同智能体，如架构师、程序、游戏设计、美术、UI 交互、测试验收等？
|
||
- **回答**：复杂任务不适合由一个智能体从头做到尾，可以拆成多个 Skill、多个 Agent 和多个子任务。不同智能体负责不同环节，并通过并行探索、审核筛选、逐步收敛来提高效率。通用智能体流程往往过重，当前更适合针对小游戏、H5 原型或具体项目定制专用流程。
|
||
#### **关于模型能力提升后的工作方式变化**
|
||
- **问题**：随着模型推理能力增强，是否还需要复杂的工具和流程？
|
||
- **回答**：更强模型会内化很多过去需要工具完成的能力，例如读表、看图、根据截图定位问题等。人的注意力会从“告诉 AI 怎么做”逐渐转向“告诉 AI 想要什么效果”。但人仍需要把控目标、体验、架构边界和结果质量。
|
||
#### **关于视频拆解与原型生成**
|
||
- **问题**：能否把 B 站、抖音上的小游戏视频直接转成源码，实现 1:1 复刻？
|
||
- **回答**：目前更现实的方式是从视频中提取玩法、界面、反馈等有效信息，形成不完整但有价值的拆解文档，再作为 AI 生成原型的上下文。单个视频信息不完整，难以支撑 1:1 复刻；但多个视频融合后，可用于生成方向接近的原型。
|
||
#### **关于老项目是否需要 AI 接管**
|
||
- **问题**：新项目可以设计成 AI 原生，老项目是否也应该让 AI 接管一次？
|
||
- **回答**：目前还缺少完整跑通的验证案例。老项目结构复杂、历史规则多、上下文难同步，直接接管风险较高。较稳妥的方式是在小型探索项目中先跑通流程，验证有效后再逐步推广到商业项目或老项目。
|
||
#### **关于 AI 自动玩游戏与自动化测试**
|
||
- **问题**：能否让 AI 直接玩游戏，总结经验，再反过来生成测试脚本或设计建议？
|
||
- **回答**：纯靠图像识别让 AI 玩游戏成本高、速度慢，效果不稳定。更可行的方向是让游戏向 AI 暴露结构化信息，例如 HTML 节点、客户端节点树、自动化测试 SDK 标签等。这样 AI 可读取界面元素并生成自动化测试脚本，后续通过多轮运行记录数据，用于分析玩家路径、卡点和经济循环。
|
||
#### **关于自动化测试的价值**
|
||
- **问题**：AI 自动化测试相比传统测试脚本的价值是什么？
|
||
- **回答**：传统自动化测试主要验证流程是否能跑通，而 AI 可以先自主探索玩法，再沉淀为测试脚本。玩法更新后，AI 还可以重新探索并更新脚本。若结合多窗口、多轮次运行和数据记录，自动化测试就不只是检查 bug，也能反哺玩法设计和数值分析。
|
||
## **五. 《 AI 对动效的应用》**
|
||
**分享人：陈怡弦（深圳）**
|
||
### （一）重点提炼
|
||
#### Spine 动画辅助制作
|
||
- 曾尝试使用即梦生成序列帧直接放入游戏，但受 Cocos 与 PNG 序列帧性能压力影响，该方案暂时搁置。
|
||
- 后续发现 Spine 动画相关 Skill，可通过 Codex 执行，输出 Spine 可用的 JSON 文件，程序侧可以直接接入。
|
||
- 当前效果更适合生成待机、跑步、受击、死亡等通用型动作；攻击动作、复杂表演和方向判断仍不稳定。
|
||
#### 实际尝试路径
|
||
- 早期尝试让 AI 根据拆分好的角色图片直接架骨骼、绑定并生成动作，但效果不理想。
|
||
- 后续改为人工完成骨骼、蒙皮和权重绑定，再让 Codex 基于约定好的骨骼命名与方向规则生成动作。
|
||
- 提示词方面，从简单描述逐步增加动作约束，例如地平面、旋转角度、运动方向等，第二版效果明显优于第一版。
|
||
- 对小怪等低复杂度角色，当前流程大约可提升 40% 左右效率，但高质量动作仍需要人工修正。
|
||
#### 当前价值与局限
|
||
- **价值**：适合不会动画或不熟悉 Spine 的同学快速生成动作框架，也适合小程序、小怪等对动作精度要求相对较低的场景。
|
||
- **局限**：骨骼搭建、蒙皮绑定、权重调整仍较依赖人工；复杂表演、创意型动作和非人形角色仍需更多案例积累。
|
||
- **后续方向**：建立动作学习库，将过往动作源文件、示范动作和不同角色形态喂给 AI，沉淀人形、鸟类、带翅膀小怪等不同类型的通用提示词。
|
||
#### 特效素材库工具
|
||
- 由于多年积累的特效文件越来越多，分享人用 Codex 搭建了一个内网特效素材库，用于展示、搜索和预览已有特效资源。
|
||
- 素材库可按关键词检索，如火、水、坐骑等，并关联对应网盘路径，方便美术、特效和策划查找可复用资源。
|
||
|
||
> :black_medium_small_square:
|
||
**总结：**
|
||
- AI 在动作制作上暂时更适合作为“起稿工具”和“效率辅助工具”，不能完全替代人工。
|
||
- AI 在工具搭建和素材管理上价值更直接，非程序岗位也可以借助 Codex 自建小工具，解决日常工作中的效率问题。
|
||
### （二）讨论交流
|
||
#### **关于 GIF / 视频参考对动作生成的帮助**
|
||
- **问题**：是否尝试过给 Codex 提供与角色体型接近的 GIF 或视频参考，让它直接参考生成动作？
|
||
- **回答**：尝试过提供 GIF 和视频参考，AI 能读懂一部分动作信息，但最终效果与纯提示词相比差距不算特别大，仍然需要人工修改。当前更现实的方式是让 AI 先生成动作框架，再由人工微调。
|
||
#### **关于通用提示词与动作库**
|
||
- **问题**：是否希望沉淀一套可复用的通用提示词？
|
||
- **回答**：是。目标是根据不同角色形态沉淀不同提示词，例如人形、鸟类、怪物、带翅膀小怪等。之后只需替换角色类型、攻击方式和性格特征，就能快速生成基础动作。
|
||
#### **关于用即梦动作反推 Spine 动作**
|
||
- **问题**：能否先用即梦生成高质量动作视频，再拆成序列帧，让 Codex 提取骨骼点和动作数据，最后应用回 Spine 角色？
|
||
- **回答**：这是一个可尝试方向。讨论认为，可通过“视频帧 - 骨骼示意图 - 动作数据”的方式给 AI 增加约束，而不是让 AI 直接看像素图生成动作。该方案对人形角色可能更有效。
|
||
#### **关于骨骼点识别工具**
|
||
- **问题**：是否可以借助现成的视觉骨骼点识别方案，将视频中的动作轨迹转成 JSON？
|
||
- **回答**：可以继续调研类似骨骼点识别、动作捕捉和开源图形学工具。分享中提到，动作本质上最终也是一套 JSON 数据，关键是建立“人类认为好的动作”和“正确 JSON 轨迹”之间的对应关系。
|
||
#### **关于是否必须局限在 Spine 流程内**
|
||
- **问题**：能否不依赖 Spine 文件，而是让 Codex 直接用程序实现类似 IK 的动作效果？
|
||
- **回答**：部分简单动作可能可行，例如拆出手、枪等部件后，用程序控制节点实现跟随鼠标的 IK 类效果。但 Spine 的优势在于可视化编辑、权重、变形和后期微调更方便，因此现阶段仍更适合作为主要承载工具。
|
||
#### **关于自建工具的启发**
|
||
- **问题**：特效素材库这类网站是否一定需要程序开发？
|
||
- **回答**：不需要，AI 时代各岗位都应尝试为自己的工作搭建小工具。只要能明确需求，例如资源预览、关键词搜索、路径跳转、性能优化等，就可以通过 Codex 快速生成可用工具，提升个人和团队效率。
|
||
#### **关于上下文与沟通方式**
|
||
- **问题**：为什么有时直接让 AI 做东西效果不好？
|
||
- **回答**：关键在于上下文是否足够。与其一开始就写很死的需求，不如先和 AI 充分讨论目标、想法和方向，让 AI 理解问题背景。过少的上下文会导致结果不满意，过多过细的约束又会限制 AI 发挥，需要在目标表达、上下文提供和细节约束之间找到平衡。
|
||
记录人：夏莲、莫润麟
|
||
# 环节一：李总课堂分享
|
||
## 主题：《AI 工作方式与学习能力建设》
|
||
AI 不只是提高效率的工具，而是正在改变人的**工作边界、组织分工方式、软件生产方式和学习方式**。适应 AI 的关键，不是掌握几个固定技巧，**而是形成一种新的工作认知和学习能力**。
|
||
## （一）AI 时代的基本判断
|
||
#### **对 AI 的最浅层理解****，是把它看作一种 “更好用的工具” **
|
||
可以写文案、整理表格、画图、写代码、节省时间。这种理解有一定道理，但不够完整。AI 的更深层影响在于，**它开始介入过去只有人类才能完成的认知劳动、判断劳动和组织劳动**。
|
||
**传统工具通常是人的能力延伸：**
|
||
例如，电脑提高信息处理效率，手机提高沟通和移动办公效率，搜索引擎提高获取信息的效率。
|
||
AI 则进一步介入**“理解、生成、分析、规划、执行、复盘”**等环节。它不仅帮助人完成动作，还能参与任务拆解、方案生成、逻辑推理和系统优化。
|
||
#### **AI 认知升级**
|
||
|
||
> [嵌入电子表格: IEZksvz4Wh7zHatxN3sc...]
|
||
|
||
**核心判断：**AI 的关键价值不只是把原来的事情做得更快，而是让个人和组织**可以处理过去无法处理、成本过高或难以规模化处理的问题****。**因此，AI 带来的变化不是单点工具升级，而是工作方式、组织方式和学习方式的整体升级。
|
||
|
||
> :black_medium_small_square:
|
||
#### 延伸判断：AI 带来的压力、机会与能力上限
|
||
- **AI 既是压力，也是机会**
|
||
那些能够重新设计流程、重新定义岗位、重新学习的人，则会获得新的成长空间。
|
||
AI 会接入一部分机械性、重复性、规则明确的工作环节，压缩传统人工堆叠型工作的价值，也会对个人技能边界和组织分工方式形成压力。但同时，AI 也会放大个人和小团队的能力，使其能够完成过去需要更多人力和时间才能完成的工作。
|
||
- **AI 改变的是能力上限，不只是工作效率**
|
||
未来的能力差距，不只是“谁懂得更多”，而是“谁更会调动知识、组织知识，并转化为实际产出”。
|
||
## （二）AI 对工作方式的重构
|
||
#### **机械性工作会率先被压缩**
|
||
AI 对工作的影响，首先会体现在机械性、重复性、规则明确的工作环节上。这类工作通常有明确输入、明确规则和明确输出，例如资料整理、表格汇总、基础文案、标准化客服、简单申报材料、初步数据清洗等。
|
||
**岗位中的低价值环节会被快速压缩**。人的价值会从“亲自完成每一个步骤”，逐步转向“定义任务、判断质量、处理例外、优化流程”。
|
||
|
||
> [嵌入电子表格: IEZksvz4Wh7zHatxN3sc...]
|
||
|
||
#### 不会使用 AI 的隐性成本会提高
|
||
当 AI 成为组织能力的一部分时，不会使用 AI 的个人会逐渐面临能力差距。
|
||
过去，一个人不会某个软件，可能只是效率较低。未来，一个人不会调动 AI，可能会影响其理解复杂任务、处理跨领域问题和完成高密度工作的能力。
|
||
AI 能力会像电脑能力、智能手机能力一样，逐步成为基础能力。**区别在于，AI 不只是操作界面，而是进入思考、判断、生成和创造环节。**
|
||
#### 岗位边界正在被重构
|
||
AI 对公司的冲击，不是简单“不要某个岗位”，而是原有的岗位分工方式不再稳定。
|
||
**AI 介入以前：**组织通常按照策划、美术、程序、测试、财务、人事、运营等专业岗位进行分工，每个岗位负责自己的部分，再通过流程向下游交付。
|
||
**AI 介入以后：**不是只替代某一个岗位，而是会进入多个岗位内部，接管其中一部分任务。这意味着岗位不会简单消失，但岗位内部的任务结构会发生变化，真正被压缩的往往是**旧分工、旧流程和旧工作习惯**。
|
||
|
||
> [嵌入电子表格: IEZksvz4Wh7zHatxN3sc...]
|
||
|
||
AI 时代仍然需要专业能力，但只守住单一岗位技能已经不够。未来更重要的角色，是能够把目标、工具、流程、数据、标准和反馈组织起来，并让 AI 和人共同形成生产系统的人。
|
||
## （三）AI 工作范式的演进
|
||
**AI 使用方式正在从“写提示词”转向“建立工作循环”，再进一步转向“优化生产系统”**。这意味着，AI 能力不只是会不会提问，而是**能否把 AI 纳入稳定、可复用、可持续改进的工作流程**。
|
||
|
||
> [嵌入电子表格: IEZksvz4Wh7zHatxN3sc...]
|
||
|
||
**新角色：**
|
||
在 AI 流程中，人的价值会从“亲自执行任务”，逐步转向“定义目标、设定约束、判断质量和优化系统”。AI 负责大量生成、执行、测试和反馈，人负责方向判断、价值判断、质量判断、边界控制和系统改进。
|
||
## （四）AI 原生能力与学习方式
|
||
- AI Coding 的意义不只是帮助程序员写代码，而是让更多业务需求可以被快速转化为小工具、小脚本、小页面和自动化流程。
|
||
- AI 原生能力是能够自然地把 AI 融入思考、学习、工作和问题解决过程。就像移动互联网时代，人们可以自然使用手机完成点餐、支付、导航、社交和办公一样，AI 原生人群会自然地让 AI 参与日常任务。
|
||
**AI 原生能力包括：**
|
||
|
||
> [嵌入电子表格: IEZksvz4Wh7zHatxN3sc...]
|
||
|
||
**核心判断：**未来的能力差距，不只是“谁懂得更多”，而是“谁更会调动 AI、组织知识、判断结果，并把 AI 产出转化为实际工作成果”。
|
||
## （五）AI 学习与使用经验分享
|
||
#### 分享一：用 AI 快速进入陌生领域
|
||
#### 分享二：用 AI 定制个人学习路径
|
||
#### 分享三：收集知识、整理知识、吸收知识、使用知识（四个效率）
|
||
#### 分享四：在使用 AI 中完成思维迭代
|
||
AI 的价值不只是完成单点任务，也会在持续使用中改变人的思考方式。使用者会从简单对话逐步转向工作流、循环和验证式使用，并在与 AI 共同探索中拓展问题视角和思维边界。
|
||
|
||
> :black_medium_small_square:
|
||
#### 总结：学习 AI 的关键是学会提问和持续反馈
|
||
- AI 学习的关键不只是获取答案，而是学会把复杂问题拆成自己能够理解和吸收的形式。可以要求 AI 用更简单的话解释概念、用案例或故事说明原理，也可以让 AI 反复举例、出题测试、检查自己是否真正理解。
|
||
- AI 的优势在于不厌其烦，可以不断根据人的反馈调整解释方式。因此，使用 AI 学习时，不必停留在“问一次、拿一个答案”，而要通过不断追问、复述、验证和应用，把外部知识逐步转化为自己的理解能力和工作能力。
|
||
#### 【推荐书单】：
|
||
|
||
|
||
|
||
# 环节二：课堂分享纪要
|
||
## **一. 《基于SDD思路的AI生成原型探索》**
|
||
**分享人：左颜昊（厦门）**
|
||
### （一）重点提炼
|
||
#### 背景问题：PRD、原型、说明三者容易不一致
|
||
- AI 能根据需求生成 PRD、原型预览和功能说明，但第一版通常还需要调试。
|
||
- 后续修改时，经常出现只改了 PRD、漏改原型，或只改了功能说明、漏改相关联模块的问题。
|
||
- 对下游开发、测试或 AI 来说，如果多个产物“相似但不同”，就会产生疑问：到底哪个才是要接收和执行的标准。
|
||
#### 三种 Spec 驱动模式
|
||
- **Spec First**：Spec / PRD 只用于生成初版产物，后续不再维护文档，而是直接基于产物修改。
|
||
- **Spec as Anchor**：Spec / PRD 作为锚点长期维护，每次先修改 Spec，再基于 Spec 修改原型或代码产物。
|
||
- **Spec as Source**：Spec / PRD 是唯一真相源，每次都基于 Spec 重新生成产物；该方式更激进，当前阶段成本较高，暂不适合现有流程。
|
||
#### 实验设计
|
||
- 实验对比了不同流程下 AI 在多轮迭代中的一致性表现。
|
||
- 主要测试三类修改：单模块字段增删改、跨模块联动修改、功能级新增 / 修改。
|
||
- 观察指标包括：产物之间是否一致、是否满足需求、需要人工干预几次。
|
||
#### 实验结论
|
||
- **严格先改 PRD、再改原型的流程**，整体一致性最好，但人工操作成本较高。
|
||
- **只保留产物、不维护 PRD**，在简单场景下效率更高，但复杂场景容易漏改跨模块内容。
|
||
- **PRD 和产物都放着，让 AI 自己判断怎么改**，效果反而最差，容易出现改 A 漏 B、后续也不举一反三的问题。
|
||
- 如果 AI 漏改后人工及时纠正，它后续会在上下文中修正；如果不纠正，错误会持续累积。
|
||
#### 对流程的调整
|
||
- 分享人倾向于将 PRD 和原型拆成两个明确流程，而不是依赖 Skill 自动保证一致性。
|
||
- 复杂场景下更适合由人工先确认 PRD 变更，再让 AI 基于新 PRD 修改原型或代码。
|
||
- 没有维护的参考文档风险较高，甚至不如不放；因为它会干扰 AI 判断。
|
||
### （二）讨论交流
|
||
#### **关于 Spec 三种模式的理解**
|
||
- **问题**：Spec First、Spec as Anchor、Spec as Source 的区别是什么？
|
||
- **回答**：Spec First 是文档生成初版后即丢弃，后续以产物为准。Spec as Anchor 是文档持续维护，后续产物围绕文档同步修改。Spec as Source 则是每次都基于文档重新生成产物，最强调文档权威，但现阶段成本较高。
|
||
#### **关于“都放着让 AI 自己看”的风险**
|
||
- **问题**：为什么同时放 PRD 和原型，让 AI 自己判断反而效果更差？
|
||
- **回答**：因为 AI 不一定能自动判断哪个产物是最新、哪个字段需要联动更新。多个相似但不一致的产物会干扰判断，导致它改了一个地方、漏掉另一个地方。
|
||
#### **关于项目规则和 Skill 的差异**
|
||
- **问题**：Codex 项目规则和 Skill 都能约束 AI 行为，它们有什么差异？
|
||
- **回答**：项目规则更像当前工程内的通用约束，可按全局、项目、目录等层级生效。Skill 更像面向具体任务的流程能力，可跨项目复用。二者目的相近，但一个偏工程规则，一个偏任务流程。
|
||
#### **关于工程思维**
|
||
- **问题**：这个实验对非程序岗位有什么意义？
|
||
- **回答**：讨论认为，AI 时代每个人都需要具备基本工程思维。不是要求策划、美术都写代码，而是要理解需求、文档、代码、测试、部署之间如何互动，理解数字产物是如何在不断增加、删除、修改中迭代演变的。
|
||
## **二. 《HTML小游戏开发工作流分享》**
|
||
**分享人：刘桥滨（广州）**
|
||
分享的核心，不是单独展示某一个 AI 工具，而是展示一套“AI 参与游戏开发”的连续工作流：先把想法变成方案，再把方案变成原型，最后把原型、资源、经验和项目记录沉淀为可复用资产。
|
||
**创意发散****→****方案文档****→****系统拆解****→****快速原型****→****美术包装****→****资源接入****→****项目沉淀****→****经验蒸馏****→****跨项目复用**
|
||
### （一）点子创意：从想法到方案准备
|
||
点子创意阶段的目标，是把初步想法、参考项目或已有玩法，快速整理成可以讨论、可以验证、可以继续开发的方案入口。
|
||
|
||
> :black_medium_small_square:
|
||
##### 创意发散
|
||
|
||
> :black_medium_small_square:
|
||
##### 系统拆解
|
||
|
||
> :black_medium_small_square:
|
||
##### 方案文档
|
||
#### 创意发散：让 AI 帮助扩展想法
|
||
当只有一个初步想法时，可以先和 AI 进行多轮对话。例如“我想做一个开宝箱游戏”，AI 可以围绕玩法结构、交互方式、界面表现和可能的扩展方向生成初步框架。人的作用是不断筛选、修正和补充，把不符合预期的部分删掉，把有价值的方向继续放大。
|
||
#### 系统拆解：把参考项目转化为可复用文档
|
||
如果已有参考项目，可以把视频、网址或录屏交给 AI，让它自动分析界面、流程和规则。AI 在不确定的位置会提出确认问题，例如某个选项是否固定、某个流程是否有条件限制。确认后，AI 再把结果整理成结构化文档。
|
||
#### 方案文档：从“人能看懂”到“AI 能执行”
|
||
方案文档不只是给人看的说明，也可以进一步转化为给 AI 使用的开发文档。文档中可以包含模块信息、交互信息、数据需求、界面结构和线框图，使后续原型开发更容易衔接。
|
||
|
||
> [嵌入电子表格: IEZksvz4Wh7zHatxN3sc...]
|
||
|
||
**核心：**点子创意阶段的重点，是把想法和参考案例快速整理成可以讨论、可以验证、可以继续开发的方案入口。
|
||
### （二）原型开发：从方案到可体验 Demo
|
||
原型开发阶段的目标，是把方案文档进一步转化为可运行、可试玩、可验证、可继续优化的小游戏 Demo。 这个阶段不是一次性做成完整产品，而是先让玩法跑起来，再通过试玩、资源接入和界面优化，不断贴近真实体验。
|
||
|
||
> :black_medium_small_square:
|
||
##### 快速原型
|
||
|
||
> :black_medium_small_square:
|
||
##### Skill 辅助
|
||
|
||
> :black_medium_small_square:
|
||
##### 资源接入
|
||
|
||
> :black_medium_small_square:
|
||
##### 动态与调整
|
||
在当前 AI 能力下，只要目标和方案说明足够清楚，就可以把方案文档交给 Codex 等工具， 快速生成初步游戏原型 / 浏览器可运行原型。
|
||
人的重点不再是从零搭建每个模块，而是明确目标、检查结果，并判断原型是否符合最初想法。 原型阶段首先验证的是：**核心玩法能否跑通、核心交互是否成立、整体体验是否有继续优化的价值**。
|
||
- **Game Design Skill：** 更偏“玩法怎么跑起来”
|
||
用于识别任务类型、选择实现路线、 锁定核心玩法、明确 UI 与资产边界，并完成测试交付。
|
||
- **UI UX Pro Max** ：更偏“界面怎么更像真实产品”
|
||
用于分析需求、生成设计系统、 补充界面规则、完成体验质检和优化交付。
|
||
这类 Skill 的价值，是降低非程序、非美术人员理解开发框架、界面规则和搭建原型的门槛，让更多人能把想法转化为可体验 Demo。
|
||
只有线框图的原型，很难判断真实体验，因此需要进一步接入图标、按钮、角色和界面素材。
|
||
- 可通过 GPT 图像生成、PS 批处理、cep-plugin 等方式处理静态资源。
|
||
- 由于 AI 在抠图、拆图等细节上还不完全稳定，实际操作中仍需要结合 PS 或自制辅助工具，主要用于降低重复处理成本。
|
||
- 处理后的资源再通过命名、尺寸和比例规范化，交给 AI 进行界面拼装。
|
||
在静态资源基础上，还可以进一步把图片转为视频或分帧素材，通过 Frame Ronin、sprite-video-lab 等工具输出动画序列， 让角色和 UI 更有反馈感和生命感。
|
||
对于 HTML 原型，也可以借助 HTML UI Editor 或类似可视化工具查看控件位置、尺寸和界面结构， 降低手动调整成本，并为后续转向 Unity 或其他正式引擎开发提供更规范的中间版本。
|
||
### （三）循环沉淀：从单个项目到生产系统
|
||
循环沉淀阶段的目标，是避免一个个项目变成零散片段，而是把项目、模块、经验和创意沉淀成可复用、可组合、可持续改进的资产。
|
||
|
||
> :black_medium_small_square:
|
||
##### 项目记忆
|
||
|
||
> :black_medium_small_square:
|
||
##### 经验蒸馏
|
||
|
||
> :black_medium_small_square:
|
||
##### 跨项目复用
|
||
- 通过 Obsidian 等本地知识库记录项目。每个项目启动时，先建立项目档案，记录项目名称、类型、目标、用途、玩法、系统和关键模块。
|
||
- 价值：项目不会只停留在本地目录或个人记忆中，而是形成可追溯、可管理、可继续补充的项目记录。后续玩法、数值、系统、界面等变化，也可以在开发过程中持续写入。
|
||
- 当项目数量增多后，玩法、系统、UI、资源和开发经验会变得多、杂、乱。因此需要持续分类、提炼和通用化。
|
||
- 重复出现的玩法可以归类为玩法模块，重复出现的系统可以整理为系统模块，UI、资源和问题处理经验也可以逐步沉淀为可复用资产。这样，项目经验就不会随着单个项目结束而流失。
|
||
- 当沉淀的模块足够多、足够清晰后，可以进一步用 AI 重新组合玩法模块、UI 模块、系统模块和资源模块，生成新的项目方向。
|
||
- 真正的目标不是只做出一个游戏，而是搭建一套可以持续产生创意、快速验证、沉淀经验并复用模块的生产系统。
|
||
**核心：**
|
||
循环沉淀阶段的重点，是把单个项目中的玩法、系统、资源和经验保存下来，并通过知识库、作品平台和模块化整理，转化为团队后续可复用、可组合、可持续进化的生产资产。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
> :black_medium_small_square:
|
||
### 李总点评：从做项目到搭建生产系统
|
||
AI 时代真正重要的能力，不是让 AI 替自己完成某个具体任务，而是能够围绕目标搭建一套可运行、可反馈、可沉淀、可持续优化的生产系统。
|
||
## **三. 《 AI 原型到 Unity 小游戏落地》**
|
||
**分享人：张视野（广州）**
|
||
### （一）重点提炼
|
||
#### **工作室愿景与项目方向**
|
||
- **工作室愿景：**每个人身兼策划、美术、程序岗位，做出受市场认可的游戏。目前明确做快节奏、快落地的小游戏方向。
|
||
- **工程化落地问题：**从原型到 Unity 小游戏缺工程化落地链路，需解决原型中 UI 资源、数据交互和规则进入现有小游戏框架的问题，使其成为可维护模块，符合项目规则。
|
||
#### **AI 工具的作用与现状**
|
||
- **AI 工具功能：**
|
||
- 程序利用 Codex 技能将策划的 HTML 原型自动化拼装成 UI 预制体，能搭出第一版结构，但工作流不成熟，产物粗糙，需人工二次调整。
|
||
- **AI 现实价值：**
|
||
- 辅助拆解需求，将视觉模型拆成 UI 区域、节点层级和复用结构；读懂项目规则，告知页面落地应触发的规则和路径；识别风险，列出工程任务，提醒自动化能力边界。
|
||
#### **未来改进方向**
|
||
- **提高还原质量：**优化布局识别、字体样式和分辨率适配，减少手工摆放。
|
||
- **建立资源流程：**让 AI 识别资源，输出缺失资源清单，建议命名规范，接入小图图集流程。
|
||
- **还原业务模块：**分析原型落地所需的 model 和方案，将页面方案推进到业务模块生成。
|
||
- **实现自动验证：**建立自动验证闭环，边生成或修改后自动触发编译检查、源路径检查、平台配置检查和构建检查，并反馈结果。
|
||
|
||
> :black_medium_small_square:
|
||
**总结：**
|
||
当前 AI 更现实的价值，不是让程序完全不用写代码，也不是把粗糙原型直接变成上线产品，而是**让想法更快变成原型，让原型更快接入工程，让工程问题更早暴露**。
|
||
## **四. 《 AI 全栈游戏开发工作流》**
|
||
**分享人：韦译（广州）**
|
||
### （一）重点提炼
|
||
#### AI 全栈的定义
|
||
- **全栈**：依靠 AI 能力，由单人承担策划、程序、美术等多岗位职责，完成从设计、代码实现到美术资源接入的单体功能落地。
|
||
- **AI 原生**：AI 深度嵌入工作流各环节，包括概念设计、需求讨论、代码实现、资源接入甚至引擎操作。没有 AI，该流程难以跑通。
|
||
#### 当前探索的几类工作流
|
||
- **策划到程序实现工作流**：以敏捷开发和快速迭代为核心，提高开发效率，同时通过流程约束保证一定质量。
|
||
- **AI 配表工作流**：尝试使用更适合 AI 读取和操作的表格格式，提高自动配表效率，但仍需人工检查，正确率暂低于传统 Excel。
|
||
- **AI 美术资源管线**：覆盖美术设计、规范制定、后处理入库、导入引擎等流程，本次分享暂未展开。
|
||
#### 核心思想：功能驱动，而非文档驱动
|
||
- 传统开发依赖详细策划案、程序开发、策划验收、测试排查，流程稳定但沟通链路长、返工成本高。
|
||
- AI 全栈流程更强调人与 AI 直接讨论需求，让代码和功能本身成为最终“真相”。
|
||
- 文档仍会存在，但主要用于上下文对齐、阶段记录和回溯，属于“即用即抛”，而非长期维护的核心资产。
|
||
#### 核心思想：小步快跑，快速迭代
|
||
- AI 上下文有限，不适合一次性处理过大的系统，因此需要将大功能拆成多个小功能。
|
||
- 每完成一个小功能后，立即验收、测试、反馈、修复，形成高频迭代循环。
|
||
- 这种方式利用了 AI 开发速度快、纠错快、重写成本低的特点，适合小型项目和原型项目。
|
||
#### 具体流程
|
||
- **前置准备**：先与 AI 对齐玩法方向、技术方案、美术风格，并寻找同类玩法的技术方案，避免从零造轮子。
|
||
- **上下文文档**：准备游戏设计文档、技术架构文档、美术方案文档、系统功能拆分文档，用于帮助 AI 理解项目。
|
||
- **架构约束**：通过 view layer、controller layer、model layer、service layer 等分层方式，强制 AI 按架构写代码，提高代码质量。
|
||
- **Superpower 工作流**：通过“想清楚 - 写清楚 - 子 Agent 执行 - 验证修复”的流程，让 AI 开发更有章法，减少需求误解、上下文遗忘和修复连带问题。
|
||
#### 实战效果
|
||
- 以一个二合玩法小游戏为案例，展示了 AI 全栈流程的落地效果。
|
||
- 前几天快速完成基础架构、棋盘、拖拽合成、测试美术接入和初步 UI。
|
||
- 约两周内实现主要功能、完整 UI、基础关卡与数值体验。
|
||
- 一个多月后，已接入较完整的局内、局外、商业化页面、剧情对话、物品详情、合成链等内容，整体完成度约 60%。
|
||
#### 当前局限
|
||
- 用户需求描述不清时，AI 容易理解偏差，需要通过 AI 反问来辅助需求对齐。
|
||
- AI 开发速度快，但代码质量不稳定，需要人为设定架构并定期重构。
|
||
- 小项目效果较好，大项目容易出现上下文不同步、模块理解不完整等问题。
|
||
- AI 全栈流程与传统团队分工存在冲突，如何嵌入现有团队流程仍需探索。
|
||
|
||
> :black_medium_small_square:
|
||
**总结：**
|
||
AI 全栈开发目前更适合小型项目、原型项目和探索性项目。它的优势是开发快、迭代快、沟通链路短；风险是代码质量不稳定、上下文有限、工程化和团队协同仍需继续沉淀。
|
||
### （二）讨论交流
|
||
#### **关于智能体拆分与工作流定制**
|
||
- **问题**：当前工作流是否需要拆分不同智能体，如架构师、程序、游戏设计、美术、UI 交互、测试验收等？
|
||
- **回答**：复杂任务不适合由一个智能体从头做到尾，可以拆成多个 Skill、多个 Agent 和多个子任务。不同智能体负责不同环节，并通过并行探索、审核筛选、逐步收敛来提高效率。通用智能体流程往往过重，当前更适合针对小游戏、H5 原型或具体项目定制专用流程。
|
||
#### **关于模型能力提升后的工作方式变化**
|
||
- **问题**：随着模型推理能力增强，是否还需要复杂的工具和流程？
|
||
- **回答**：更强模型会内化很多过去需要工具完成的能力，例如读表、看图、根据截图定位问题等。人的注意力会从“告诉 AI 怎么做”逐渐转向“告诉 AI 想要什么效果”。但人仍需要把控目标、体验、架构边界和结果质量。
|
||
#### **关于视频拆解与原型生成**
|
||
- **问题**：能否把 B 站、抖音上的小游戏视频直接转成源码，实现 1:1 复刻？
|
||
- **回答**：目前更现实的方式是从视频中提取玩法、界面、反馈等有效信息，形成不完整但有价值的拆解文档，再作为 AI 生成原型的上下文。单个视频信息不完整，难以支撑 1:1 复刻；但多个视频融合后，可用于生成方向接近的原型。
|
||
#### **关于老项目是否需要 AI 接管**
|
||
- **问题**：新项目可以设计成 AI 原生，老项目是否也应该让 AI 接管一次？
|
||
- **回答**：目前还缺少完整跑通的验证案例。老项目结构复杂、历史规则多、上下文难同步，直接接管风险较高。较稳妥的方式是在小型探索项目中先跑通流程，验证有效后再逐步推广到商业项目或老项目。
|
||
#### **关于 AI 自动玩游戏与自动化测试**
|
||
- **问题**：能否让 AI 直接玩游戏，总结经验，再反过来生成测试脚本或设计建议？
|
||
- **回答**：纯靠图像识别让 AI 玩游戏成本高、速度慢，效果不稳定。更可行的方向是让游戏向 AI 暴露结构化信息，例如 HTML 节点、客户端节点树、自动化测试 SDK 标签等。这样 AI 可读取界面元素并生成自动化测试脚本，后续通过多轮运行记录数据，用于分析玩家路径、卡点和经济循环。
|
||
#### **关于自动化测试的价值**
|
||
- **问题**：AI 自动化测试相比传统测试脚本的价值是什么？
|
||
- **回答**：传统自动化测试主要验证流程是否能跑通，而 AI 可以先自主探索玩法，再沉淀为测试脚本。玩法更新后，AI 还可以重新探索并更新脚本。若结合多窗口、多轮次运行和数据记录，自动化测试就不只是检查 bug，也能反哺玩法设计和数值分析。
|
||
## **五. 《 AI 对动效的应用》**
|
||
**分享人：陈怡弦（深圳）**
|
||
### （一）重点提炼
|
||
#### Spine 动画辅助制作
|
||
- 曾尝试使用即梦生成序列帧直接放入游戏，但受 Cocos 与 PNG 序列帧性能压力影响，该方案暂时搁置。
|
||
- 后续发现 Spine 动画相关 Skill，可通过 Codex 执行，输出 Spine 可用的 JSON 文件，程序侧可以直接接入。
|
||
- 当前效果更适合生成待机、跑步、受击、死亡等通用型动作；攻击动作、复杂表演和方向判断仍不稳定。
|
||
#### 实际尝试路径
|
||
- 早期尝试让 AI 根据拆分好的角色图片直接架骨骼、绑定并生成动作，但效果不理想。
|
||
- 后续改为人工完成骨骼、蒙皮和权重绑定，再让 Codex 基于约定好的骨骼命名与方向规则生成动作。
|
||
- 提示词方面，从简单描述逐步增加动作约束，例如地平面、旋转角度、运动方向等，第二版效果明显优于第一版。
|
||
- 对小怪等低复杂度角色，当前流程大约可提升 40% 左右效率，但高质量动作仍需要人工修正。
|
||
#### 当前价值与局限
|
||
- **价值**：适合不会动画或不熟悉 Spine 的同学快速生成动作框架，也适合小程序、小怪等对动作精度要求相对较低的场景。
|
||
- **局限**：骨骼搭建、蒙皮绑定、权重调整仍较依赖人工；复杂表演、创意型动作和非人形角色仍需更多案例积累。
|
||
- **后续方向**：建立动作学习库，将过往动作源文件、示范动作和不同角色形态喂给 AI，沉淀人形、鸟类、带翅膀小怪等不同类型的通用提示词。
|
||
#### 特效素材库工具
|
||
- 由于多年积累的特效文件越来越多，分享人用 Codex 搭建了一个内网特效素材库，用于展示、搜索和预览已有特效资源。
|
||
- 素材库可按关键词检索，如火、水、坐骑等，并关联对应网盘路径，方便美术、特效和策划查找可复用资源。
|
||
|
||
> :black_medium_small_square:
|
||
**总结：**
|
||
- AI 在动作制作上暂时更适合作为“起稿工具”和“效率辅助工具”，不能完全替代人工。
|
||
- AI 在工具搭建和素材管理上价值更直接，非程序岗位也可以借助 Codex 自建小工具，解决日常工作中的效率问题。
|
||
### （二）讨论交流
|
||
#### **关于 GIF / 视频参考对动作生成的帮助**
|
||
- **问题**：是否尝试过给 Codex 提供与角色体型接近的 GIF 或视频参考，让它直接参考生成动作？
|
||
- **回答**：尝试过提供 GIF 和视频参考，AI 能读懂一部分动作信息，但最终效果与纯提示词相比差距不算特别大，仍然需要人工修改。当前更现实的方式是让 AI 先生成动作框架，再由人工微调。
|
||
#### **关于通用提示词与动作库**
|
||
- **问题**：是否希望沉淀一套可复用的通用提示词？
|
||
- **回答**：是。目标是根据不同角色形态沉淀不同提示词，例如人形、鸟类、怪物、带翅膀小怪等。之后只需替换角色类型、攻击方式和性格特征，就能快速生成基础动作。
|
||
#### **关于用即梦动作反推 Spine 动作**
|
||
- **问题**：能否先用即梦生成高质量动作视频，再拆成序列帧，让 Codex 提取骨骼点和动作数据，最后应用回 Spine 角色？
|
||
- **回答**：这是一个可尝试方向。讨论认为，可通过“视频帧 - 骨骼示意图 - 动作数据”的方式给 AI 增加约束，而不是让 AI 直接看像素图生成动作。该方案对人形角色可能更有效。
|
||
#### **关于骨骼点识别工具**
|
||
- **问题**：是否可以借助现成的视觉骨骼点识别方案，将视频中的动作轨迹转成 JSON？
|
||
- **回答**：可以继续调研类似骨骼点识别、动作捕捉和开源图形学工具。分享中提到，动作本质上最终也是一套 JSON 数据，关键是建立“人类认为好的动作”和“正确 JSON 轨迹”之间的对应关系。
|
||
#### **关于是否必须局限在 Spine 流程内**
|
||
- **问题**：能否不依赖 Spine 文件，而是让 Codex 直接用程序实现类似 IK 的动作效果？
|
||
- **回答**：部分简单动作可能可行，例如拆出手、枪等部件后，用程序控制节点实现跟随鼠标的 IK 类效果。但 Spine 的优势在于可视化编辑、权重、变形和后期微调更方便，因此现阶段仍更适合作为主要承载工具。
|
||
#### **关于自建工具的启发**
|
||
- **问题**：特效素材库这类网站是否一定需要程序开发？
|
||
- **回答**：不需要，AI 时代各岗位都应尝试为自己的工作搭建小工具。只要能明确需求，例如资源预览、关键词搜索、路径跳转、性能优化等，就可以通过 Codex 快速生成可用工具，提升个人和团队效率。
|
||
#### **关于上下文与沟通方式**
|
||
- **问题**：为什么有时直接让 AI 做东西效果不好？
|
||
- **回答**：关键在于上下文是否足够。与其一开始就写很死的需求，不如先和 AI 充分讨论目标、想法和方向，让 AI 理解问题背景。过少的上下文会导致结果不满意，过多过细的约束又会限制 AI 发挥，需要在目标表达、上下文提供和细节约束之间找到平衡。
|
||
记录人：夏莲、莫润麟 |