dc-docs/output/feishu-docs/KshwdqwFuoSOKjxzYCjcn8THn6f.md

# KshwdqwFuoSOKjxzYCjcn8THn6f


Source: https://feishu.cn/docx/KshwdqwFuoSOKjxzYCjcn8THn6f


# 环节一：李总课堂分享

## 主题：《AI 工作方式与学习能力建设》

AI 不只是提高效率的工具，而是正在改变人的工作边界、组织分工方式、软件生产方式和学习方式。适应 AI 的关键，不是掌握几个固定技巧，而是形成一种新的工作认知和学习能力。

## （一）AI 时代的基本判断

#### 对 AI 的最浅层理解，是把它看作一种 “更好用的工具”

可以写文案、整理表格、画图、写代码、节省时间。这种理解有一定道理，但不够完整。AI 的更深层影响在于，它开始介入过去只有人类才能完成的认知劳动、判断劳动和组织劳动。

传统工具通常是人的能力延伸：

例如，电脑提高信息处理效率，手机提高沟通和移动办公效率，搜索引擎提高获取信息的效率。

AI 则进一步介入“理解、生成、分析、规划、执行、复盘”等环节。它不仅帮助人完成动作，还能参与任务拆解、方案生成、逻辑推理和系统优化。

#### AI 认知升级

核心判断：AI 的关键价值不只是把原来的事情做得更快，而是让个人和组织可以处理过去无法处理、成本过高或难以规模化处理的问题。因此，AI 带来的变化不是单点工具升级，而是工作方式、组织方式和学习方式的整体升级。

#### 延伸判断：AI 带来的压力、机会与能力上限

AI 既是压力，也是机会

那些能够重新设计流程、重新定义岗位、重新学习的人，则会获得新的成长空间。

AI 会接入一部分机械性、重复性、规则明确的工作环节，压缩传统人工堆叠型工作的价值，也会对个人技能边界和组织分工方式形成压力。但同时，AI 也会放大个人和小团队的能力，使其能够完成过去需要更多人力和时间才能完成的工作。

AI 改变的是能力上限，不只是工作效率

未来的能力差距，不只是“谁懂得更多”，而是“谁更会调动知识、组织知识，并转化为实际产出”。

## （二）AI 对工作方式的重构

#### 机械性工作会率先被压缩

AI 对工作的影响，首先会体现在机械性、重复性、规则明确的工作环节上。这类工作通常有明确输入、明确规则和明确输出，例如资料整理、表格汇总、基础文案、标准化客服、简单申报材料、初步数据清洗等。

岗位中的低价值环节会被快速压缩。人的价值会从“亲自完成每一个步骤”，逐步转向“定义任务、判断质量、处理例外、优化流程”。

#### 不会使用 AI 的隐性成本会提高

当 AI 成为组织能力的一部分时，不会使用 AI 的个人会逐渐面临能力差距。

过去，一个人不会某个软件，可能只是效率较低。未来，一个人不会调动 AI，可能会影响其理解复杂任务、处理跨领域问题和完成高密度工作的能力。

AI 能力会像电脑能力、智能手机能力一样，逐步成为基础能力。区别在于，AI 不只是操作界面，而是进入思考、判断、生成和创造环节。

#### 岗位边界正在被重构

AI 对公司的冲击，不是简单“不要某个岗位”，而是原有的岗位分工方式不再稳定。

AI 介入以前：组织通常按照策划、美术、程序、测试、财务、人事、运营等专业岗位进行分工，每个岗位负责自己的部分，再通过流程向下游交付。

AI 介入以后：不是只替代某一个岗位，而是会进入多个岗位内部，接管其中一部分任务。这意味着岗位不会简单消失，但岗位内部的任务结构会发生变化，真正被压缩的往往是旧分工、旧流程和旧工作习惯。

AI 时代仍然需要专业能力，但只守住单一岗位技能已经不够。未来更重要的角色，是能够把目标、工具、流程、数据、标准和反馈组织起来，并让 AI 和人共同形成生产系统的人。

## （三）AI 工作范式的演进

AI 使用方式正在从“写提示词”转向“建立工作循环”，再进一步转向“优化生产系统”。这意味着，AI 能力不只是会不会提问，而是能否把 AI 纳入稳定、可复用、可持续改进的工作流程。

新角色：
在 AI 流程中，人的价值会从“亲自执行任务”，逐步转向“定义目标、设定约束、判断质量和优化系统”。AI 负责大量生成、执行、测试和反馈，人负责方向判断、价值判断、质量判断、边界控制和系统改进。

## （四）AI 原生能力与学习方式

AI Coding 的意义不只是帮助程序员写代码，而是让更多业务需求可以被快速转化为小工具、小脚本、小页面和自动化流程。

AI 原生能力是能够自然地把 AI 融入思考、学习、工作和问题解决过程。就像移动互联网时代，人们可以自然使用手机完成点餐、支付、导航、社交和办公一样，AI 原生人群会自然地让 AI 参与日常任务。

AI 原生能力包括：

核心判断：未来的能力差距，不只是“谁懂得更多”，而是“谁更会调动 AI、组织知识、判断结果，并把 AI 产出转化为实际工作成果”。

## （五）AI 学习与使用经验分享

#### 分享一：用 AI 快速进入陌生领域

先让 AI 整理专有名词，快速了解行业基础概念。

再让 AI 拆解学习路径，明确核心知识和阶段重点。

最后用 AI 提炼资料内容，快速把握书籍、文章或播客的主要观点。

#### 分享二：用 AI 定制个人学习路径

先让 AI 了解自己：把个人经验、知识基础、学习习惯和思维方式整理给 AI，形成更个性化的学习基础。

再让 AI 拆解学习内容：学习新领域时，让 AI 根据自己的现有水平，推荐最先需要掌握的基础知识，并逐步拆解学习路径。

最后用 AI 出题检测：通过让 AI 出题或设置测试，检查自己是否真正理解，从而巩固学习效果。

#### 分享三：收集知识、整理知识、吸收知识、使用知识（四个效率）

收集知识：AI 可以快速收集学习资料，降低检索资料的成本。

整理知识：AI 可以把分散、庞杂的资料重新组织成结构化内容，让学习对象从“信息堆”变成可理解的体系。

吸收知识：AI 可以根据个人基础和偏好，把复杂内容改写成更容易理解的形式。

应用知识：结合具体业务场景，帮助把新知识转化为方案、工具、流程或实际产物，让学习结果进入真实工作。

#### 分享四：在使用 AI 中完成思维迭代

AI 的价值不只是完成单点任务，也会在持续使用中改变人的思考方式。使用者会从简单对话逐步转向工作流、循环和验证式使用，并在与 AI 共同探索中拓展问题视角和思维边界。

#### 总结：学习 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 参与游戏开发”的连续工作流：先把想法变成方案，再把方案变成原型，最后把原型、资源、经验和项目记录沉淀为可复用资产。

创意发散→方案文档→系统拆解→快速原型→美术包装→资源接入→项目沉淀→经验蒸馏→跨项目复用

### （一）点子创意：从想法到方案准备

点子创意阶段的目标，是把初步想法、参考项目或已有玩法，快速整理成可以讨论、可以验证、可以继续开发的方案入口。

##### 创意发散

##### 系统拆解

##### 方案文档

#### 创意发散：让 AI 帮助扩展想法

当只有一个初步想法时，可以先和 AI 进行多轮对话。例如“我想做一个开宝箱游戏”，AI 可以围绕玩法结构、交互方式、界面表现和可能的扩展方向生成初步框架。人的作用是不断筛选、修正和补充，把不符合预期的部分删掉，把有价值的方向继续放大。

#### 系统拆解：把参考项目转化为可复用文档

如果已有参考项目，可以把视频、网址或录屏交给 AI，让它自动分析界面、流程和规则。AI 在不确定的位置会提出确认问题，例如某个选项是否固定、某个流程是否有条件限制。确认后，AI 再把结果整理成结构化文档。

#### 方案文档：从“人能看懂”到“AI 能执行”

方案文档不只是给人看的说明，也可以进一步转化为给 AI 使用的开发文档。文档中可以包含模块信息、交互信息、数据需求、界面结构和线框图，使后续原型开发更容易衔接。

核心：点子创意阶段的重点，是把想法和参考案例快速整理成可以讨论、可以验证、可以继续开发的方案入口。

### （二）原型开发：从方案到可体验 Demo

原型开发阶段的目标，是把方案文档进一步转化为可运行、可试玩、可验证、可继续优化的小游戏 Demo。 这个阶段不是一次性做成完整产品，而是先让玩法跑起来，再通过试玩、资源接入和界面优化，不断贴近真实体验。

##### 快速原型

##### Skill 辅助

##### 资源接入

##### 动态与调整

快速原型：目标清楚后即可启动

在当前 AI 能力下，只要目标和方案说明足够清楚，就可以把方案文档交给 Codex 等工具， 快速生成初步游戏原型 / 浏览器可运行原型。

人的重点不再是从零搭建每个模块，而是明确目标、检查结果，并判断原型是否符合最初想法。 原型阶段首先验证的是：核心玩法能否跑通、核心交互是否成立、整体体验是否有继续优化的价值。

Skill 辅助：把经验封装为可调用流程

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 或其他正式引擎开发提供更规范的中间版本。

### （三）循环沉淀：从单个项目到生产系统

循环沉淀阶段的目标，是避免一个个项目变成零散片段，而是把项目、模块、经验和创意沉淀成可复用、可组合、可持续改进的资产。

##### 项目记忆

##### 经验蒸馏

##### 跨项目复用

项目记忆：给每个项目建立“身份证”

通过 Obsidian 等本地知识库记录项目。每个项目启动时，先建立项目档案，记录项目名称、类型、目标、用途、玩法、系统和关键模块。

价值：项目不会只停留在本地目录或个人记忆中，而是形成可追溯、可管理、可继续补充的项目记录。后续玩法、数值、系统、界面等变化，也可以在开发过程中持续写入。

经验蒸馏：从“项目垃圾堆”到“模块资产库”

当项目数量增多后，玩法、系统、UI、资源和开发经验会变得多、杂、乱。因此需要持续分类、提炼和通用化。

重复出现的玩法可以归类为玩法模块，重复出现的系统可以整理为系统模块，UI、资源和问题处理经验也可以逐步沉淀为可复用资产。这样，项目经验就不会随着单个项目结束而流失。

跨项目复用：用沉淀资产重新组合新项目

当沉淀的模块足够多、足够清晰后，可以进一步用 AI 重新组合玩法模块、UI 模块、系统模块和资源模块，生成新的项目方向。

真正的目标不是只做出一个游戏，而是搭建一套可以持续产生创意、快速验证、沉淀经验并复用模块的生产系统。

核心：
循环沉淀阶段的重点，是把单个项目中的玩法、系统、资源和经验保存下来，并通过知识库、作品平台和模块化整理，转化为团队后续可复用、可组合、可持续进化的生产资产。

### 李总点评：从做项目到搭建生产系统

AI 的价值不只是做出单个项目，而是搭建生产系统
分享展示 AI 如何帮助团队快速实现创意、验证方向，并逐步搭建一套持续生产、持续迭代的工作系统。

人的角色要从“系统执行者”转向“系统构建者”
未来的重点不是单纯完成某个任务，而是思考如何让任务被系统持续完成。对策划来说，过去是写一份策划案，未来要思考如何持续生产策划案，并把自己的经验、判断和方法沉淀到系统中。

AI 不好用，往往是因为只把它当成单点工具
如果只是直接让 AI 解决一个问题，效果很容易不稳定。更有效的方式，是围绕问题搭建工作系统，包括输入材料、执行流程、确认机制、质量标准和反馈方式。

非程序人员也可以搭建 AI 工作流
AI 工作流并不完全依赖程序员。程序员的优势不只是会写代码，而是具备工程思维。非程序人员如果能学习拆解、验证、复用和迭代的方法，也可以借助 AI 搭建自己的工作系统。

提前使用 AI，是为了获得长期优势
AI 工具还在快速变化，但越早开始使用，越容易形成自己的理解、方法和优势。未来竞争力不只是来自执行熟练度，而是来自能否学习、建构、突破边界，并形成适合自己的生产系统。

AI 时代真正重要的能力，不是让 AI 替自己完成某个具体任务，而是能够围绕目标搭建一套可运行、可反馈、可沉淀、可持续优化的生产系统。

## 三. 《 AI 原型到 Unity 小游戏落地》

分享人：张视野（广州）

### （一）重点提炼

#### 工作室愿景与项目方向

工作室愿景：每个人身兼策划、美术、程序岗位，做出受市场认可的游戏。目前明确做快节奏、快落地的小游戏方向。

工程化落地问题：从原型到 Unity 小游戏缺工程化落地链路，需解决原型中 UI 资源、数据交互和规则进入现有小游戏框架的问题，使其成为可维护模块，符合项目规则。

#### AI 工具的作用与现状

AI 工具功能：

程序利用 Codex 技能将策划的 HTML 原型自动化拼装成 UI 预制体，能搭出第一版结构，但工作流不成熟，产物粗糙，需人工二次调整。

AI 现实价值：

辅助拆解需求，将视觉模型拆成 UI 区域、节点层级和复用结构；读懂项目规则，告知页面落地应触发的规则和路径；识别风险，列出工程任务，提醒自动化能力边界。

#### 未来改进方向

提高还原质量：优化布局识别、字体样式和分辨率适配，减少手工摆放。

建立资源流程：让 AI 识别资源，输出缺失资源清单，建议命名规范，接入小图图集流程。

还原业务模块：分析原型落地所需的 model 和方案，将页面方案推进到业务模块生成。

实现自动验证：建立自动验证闭环，边生成或修改后自动触发编译检查、源路径检查、平台配置检查和构建检查，并反馈结果。

总结：

当前 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 全栈流程与传统团队分工存在冲突，如何嵌入现有团队流程仍需探索。

总结：

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 搭建了一个内网特效素材库，用于展示、搜索和预览已有特效资源。

素材库可按关键词检索，如火、水、坐骑等，并关联对应网盘路径，方便美术、特效和策划查找可复用资源。

总结：

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 发挥，需要在目标表达、上下文提供和细节约束之间找到平衡。

记录人：夏莲、莫润麟