这是【游戏开发那些事】第70篇原创

引子：春节后两个月，AI在狂奔，行业在浮躁

自春节返工以来，铺天盖地的 AI 新闻把大家心里都搅得有点浮躁。大模型相关话题也几乎是以“周”为单位在更新——和以前不一样的是，以前它们更多存在于新闻里，和日常工作关系不大；现在这股浪潮已经渗进公司的每个角落，吃饭的路上能听见各种相关讨论，内网里刷屏的多半也是大模型与智能体，分享会议也几乎绕不开这类话题。

从我真正开始规划这篇文章到现在，热点一茬接一茬，技术路线与发展方向也在快速迭代，不停往脑子里钻。 不知道大家是否和我一样，刷到的每个AI视频或帖子都忍不住点个收藏或者停留看一会，每天的信息密度太高，导致注意力已经被动透支了。

在这短短的两个月内，“小龙虾”热度经历了过山车式的变化，得物、Meta、甲骨文Epic等大公司都被曝出了大规模的裁员或者调整[1][2][3]，英伟达把企业未来的发展全部AllIn到了AI基建和Token算力当中，ClaudeCode/GPT/GLM/Kimi/DeepSeek等大模型都飞速迭代了多个版本。

在这波浪潮中，很多人会问一个特别朴素的问题：AI 真的已经把公司提效到这种程度了吗？

是，但也不完全是。AI很强，强大到已经开始颠覆了传统的工业管线，但局限也很明显，实际落地还没有那么理想。接下来我会尝试从最近两个月（2026.3-2026.4）在游戏行业内的观察来展开讲讲，

Epic 这次裁员在海外有一份公开的统计表格[4]，里面能看到不少熟悉的名字与职能方向（引擎、工具、技术美术等。这当然不全等于“AI 已经替代了这些人”，但它至少说明在当前环境下，“AI 提效”已经是一个不容置疑的共识。

英伟达 GTC 大会：能从中看到行业对未来几年的押注，比如 AI 基建的价值、Token 作为“算力时代硬通货” 被反复提起、以及应用形态是否会从“传统 App”进一步走向更偏自动化/代理化 的工作流等。[5][6] 过去半个月里，国内外外舆论场里关于 “给员工配 Token 预算/额度” 的讨论已经快速落地。[7] 软件侧更偏 CLI优先的开发与编排也逐步在各大公司里面落地成型。[9]

一、AI 确实已经很强——强到能改变“谁在写代码”：

1）“Vibe Coding”可能过于理想，但AI写代码已成趋势

现在行业里常说的 Vibe Coding（偏“描述意图—让工具生成—人来纠偏”的开发方式），在各类开发者调研里出现的比例确实越来越高。不同机构、不同样本得出的数字差很大，但 Anthropic 等大模型公司自己的工程团队，也确实已经把 AI 编程用得非常深了——内部往往至少有一条产品线是以智能体写代码为主在推动的。

对于大部分团队，更稳妥的说法是：在工具链清晰、反馈回路短的场景里，AI 辅助已经从小众变成了默认选项之一；对大量“普通强度”的编码与改码任务，模型的能力已经超过了很多人的预期，逐渐有成为主流的趋势。

2）OpenAI 的 Harness 工程：说明“组织级智能体工程”是可行的

更值得放进严肃讨论里的是 OpenAI 自己写的工程实践：在高度约束与强工程化配套下，Agent可以把软件交付推进到非常夸张的量级。

他们在《工程技术：在智能体优先的世界中利用 Codex》里描述了一个内部实验：在明确规则下构建产品，代码主要由 Codex 生成；文中也写了具体规模：从空仓库起步，数月内代码规模达到百万行量级，PR 数量与合并节奏远高于传统小团队的常见水平；同时强调人类工作重心转向上下文环境、工程目标、反馈回路（这种能力高度依赖仓库结构、工具链与流程设计，不应默认能无成本泛化到任何团队）。[8]

其中的关键不是“吹模型”，而且逐渐摸索出来大模型的最佳使用方式：团队的主要工作不再是手写每一行，而是设计好工程规范能让智能体稳定工作，本质上这也算是软件工程——AI时代的软件工程。

3）强的不只是模型，更是“约束 + 编排 + 周边系统”

把 OpenAI 与 Anthropic 两边的公开实践放在一起看，会更清晰：大家都在用“约束规范 + 多智能体分工 + 可验证反馈回路”去撬动复杂工程问题。这和早年深度学习里 生成对抗网络（GAN[12]） 的直觉有点像：单点模型再强，也往往需要 生成器/判别器 这种结构，以及数据、评测、训练环路的“周边系统”才能把效果推上去(调研结果参考[10]，这次的研究使用游戏来作为例子)。换句话说，就是需要多个不同职能的Agent互相对抗，讨论，协作，才能撑得起复杂的任务处理，大大提高AI的准确率。

Anthropic 他们的工程博客里有不少 Harness（智能体编排） 与 长程任务 相关的长文，其中一篇讨论“面向长周期应用开发的 Harness 设计”，明确提到从 GAN 获得启发的 多智能体结构、以及 上下文重置/交接工件 等机制。[10]

由此也能看出：上下文系统（context engineering）与任务编排 仍然有很大挖掘空间[11]；但与此同时，目前也 没有一个“绝对权威、放之四海皆准”的万能模型——更多时候是“模型 + 工具 + 流程 + 评测”的组合赛。

4）更新节奏与自我迭代：和以往“新技术发布”有本质区别

如果只看“体感”，过去一两年里 OpenAI、Anthropic（Claude）、Cursor，以及国内头部大模型产品（如字节系、阿里通义、GLM、MiniMax、Kimi、DeepSeek 等）几乎都在维持 月级别 的公开迭代：今天刚熟悉的按钮与参数，下个月可能就被新能力替换，你会明显感觉到：变化不是“偶尔出一个大版本”，而是长期高频迭代，最近随着大模型竞争日渐激烈，这种变化尤为明显，不仅几乎每周都有新的变化，还有ClaudeDesign，GPT IMG2.0这种颠覆传统工作流的产品出现。

参考：Cursor 更新日志[15] OpenAI 的模型发布说明[16] ChatGPT 的更新说明[17] Anthropic 的模型与能力文档 [18] 阿里千问模型 [19] 火山引擎大模型[20]

这和过去很多技术浪潮的本质差别在于：它不只是多了一套新库/新框架，而是 能力本身在持续升级，并且开始形成 “用智能体改进工程系统、工程系统再反哺智能体落地” 的闭环。也正因为如此，行业里已经出现一种越来越常见的现象：大模型团队自己的研发与交付，也会把智能体推到更核心的位置（例如 OpenAI 公开描述的 Harness / Codex 实践[8][9]；Anthropic 工程博客中对长程 Harness、评测与工具链的投入[10][11]）。我不会把它夸张成“全员无人化”，但方向很明确：人类更像制定规则与验收标准的一方，执行链条越来越可能被自动化拆分。

二、但大部分公司——包括游戏公司还都没有完全准备好：

虽然现在的大模型已经强悍如此，虽然Codex已经能靠AI快速堆出来百万级别的工程项目，但这些工具在各大公司落地时都会遭到不同程度的水土不服。任何一家大厂的业务都不是“单一代码问题”，而是多工种协作、流程耦合、历史包袱叠加。游戏行业更明显：项目技术栈差异、工具链差异、资源组织方式差异都非常大。“真正做到 300% 提效、砍掉一半人力”，往往需要的不是换一个模型，而是一轮组织适应：

• 哪些内容应该交给AI 

• Harness如何做 

• 是否要重新搭建团队的Agent，是否要有统一的技能库和知识库 

• 规范怎么落地、评审怎么做 

• 资产与代码的边界怎么划分，AI如何界定要处理的边界

• 哪些能自动化、哪些必须人来做最终仲裁

我最直观的感受是，目前大家都在尝试在做类似Harness的上下文工程，但是每个团队都处于一个摸索的过程，没有最佳实践。而且AI的发展着实迅速，一套当下看起来还不错的方案可能下个月就会被淘汰或取代。现实就是，智能体相关流程在推，但还没推上去，也没完全打通；很多团队也不清楚到底要做到哪些事、做到什么程度。

目前比较稳妥的推进思路就是：员工把自己的经验快速沉淀成可复用的 skill，公司把各个系统通过MCP的方式都接入到大模型中去，同时项目组能按类似前面提到的 Harness 思路，把历史债务与工程约束系统性持续的治理和调整，然后跟随AI的发展来不断调整方向。这些工作内容虽然可以由AI参与辅助提高效率，但是实际上还是在消耗团队额外的精力去处理。如果真的发生人力收缩，那团队目前的AI提效往往不足以覆盖缺失的人力，短期内一定会阵痛频繁。

当然，也有很多公司不甘于只做大模型的使用者，尝试推出自己的模型或者产品，比如小米3月底推出了自研大模型MimoV2.5，冲上了榜单前10，米哈游公开了自己的视频生成模型LPM1.0，主打智能NPC以及虚拟直播等应用方向。此外，基本上每家大厂都会在研自己的Agent产品，内部竞争也很激烈。[21]

三、游戏行业里谈 AI，先把概念对齐：不止 LLM：

现在舆论场的“AI 浪潮”，几乎默认等于 大模型 / LLM。但在游戏行业聊影响，我建议把概念拆成三类，不然很容易鸡同鸭讲。

1）LLM （你现在最常听到的）

特点：以Transformer神经网络为主的超大规模参数的AI模型。强在语言、推理、代码与知识综合；弱在长上下文、私有知识覆盖、以及强一致性的系统级改造（需要靠工具、流程与工程化补齐）。我们现在讨论的AI浪潮都是以大模型为前提的。

2）“游戏 AI”（行业里早就有的那条线）

早期语境里的游戏 AI，往往就是 寻路、行为树、状态机、NPC 决策 等。它们不依赖大模型，但同样是“让游戏世界看起来有智能”的核心技术栈。

到今天，这条线仍在进化：更复杂的行为、更拟人的对手——其中一部分会吸收机器学习的方法，但很多时候仍是规则 + 算法 + 数据的工程问题。

3）机器学习 AI（面向特定目标优化）

典型代表是 AlphaGo、深蓝 这类：为特定任务训练、在明确目标函数下超越人类的机器学习系统，可能使用传统的机器学习或者是神经网络，但是往往是适配某个领域的专用模型。游戏里也很常见：匹配、反作弊、推荐、留存预测、动画生成、图像超分、语音、口型……它们往往以“模型 + 数据闭环”存在，和“ LLM”不是同一条产品线。

一句话总结：LLM 更像是万能助手；游戏 AI 更像玩法系统的代码工程；机器学习 AI 更像数据驱动的专项引擎。 

4）相比两三年前，LLM 路线在游戏研发里多做了什么？

结合我自己的观察，LLM 在游戏研发里“明显变强”的增量，主要集中在AI真的变聪明了，几乎任何问题都可以尝试交给他处理或者优化：[14]

• 从“补全一行”到“实现功能”：对 C++/C#/Python/工具链脚本的日常改动，门槛下降很明显，对于业务逻辑已经可以Hold住一定复杂度的代码模块。

• 从“写代码”到“写流程”：生成测试样例、迁移脚本、CI 片段、日志分析思路、变更说明与评审 checklist甚至是分析需求以及功能原理——这些“围绕代码的工作”往往收益更大。

• 从“单点问答”到“多步骤任务”：在规范约束下，多 agent 分工（写、查、改、审）已经能跑通很多内部工作流——前提是你们真的把环境与规则准备到位。

但它仍然不擅长“无地图开荒”：不知道你们的资源规范、不知道你们的性能预算、不知道你们线上事故史，就会表现为“看起来很专业，一落地就踩坑”。

四、游戏领域里的一些尝试：提效的真实边界在哪里？

已经可以提升的地方

1）个人能做的变多了：AI拓展了个人的能力边界

过去，美术或设计岗位的人员通常不具备编写代码的能力，如今借助AI，他们能快速生成功能完整且界面美观的前端页面。在公司群中，我看到不少美术和策划岗位的同事利用AI制作了许多辅助工作的工具，并且已将这些工具上传至Git。

同理，程序员也可以不依赖美术搞定一些简单的设计，这大大的提高了个人工作的效率，一定程度减少了沟通成本。甚至也听说有些公司里面程序员和设计团队都在用AI搞自己的框架，企图取代对方。之前提起来很离谱，但最近claude design出来以后，还真有点这个趋势。

2）学习方式变了：先跑一轮，再用 Skill/文档把准确率拉起来

面对新的工作场景，你可以直接把一个工程丢给AI助手做通读、对比、风险点提示。也许第一轮输出往往不完美，甚至会“自信地错”；但一旦配上团队沉淀的 Skill（流程、模板、禁区）或指向明确的内部文档，命中率会显著提高。这和以前“先啃三天代码再下手”的节奏完全不一样：先广后深、先草稿后收敛，更贴合大模型的长处。

3）文档与知识沉淀：顺手生成，补齐“忙项目时欠下的说明”

以前大家忙着赶里程碑，很难保证文档的实时性与完备性；现在更常见的做法是：根据代码、提交记录、接口变更顺手补 README、变更说明、接口注释，把“写完再补文档”变成“边做边产出可检索文本”。虽然仍然需要人审，但从 0 到 1 的成本低了一个数量级。

对于个人来说，也可以从传统的云文档模式逐渐切换成本地的个人知识库管理，无论是写代码还是写文章都可以大大提效。

4）并行与多任务：想法很美好，瓶颈常在人与工程物理

你可以同时开多个需求：某个任务扔给助手跑起来后，你就能切去搞另一个；需求分析与拆解，也可以多路 agent 分头推进。反直觉的是：限制整体效率的往往并不是模型本身，而是人——注意力切换成本高，很难在 N 个并行任务之间高频来回而不串需求。另一方面，全流程仍难完全交给模型：幻觉、遗漏、边界条件默认成立等问题仍在，而且受限于模型本身的能力。游戏工程还会叠加 分支、环境一致性、编译与磁盘 的硬约束——“并行想法”经常会遇到“串行物理”。最近听过一些分享，公司层面多半会往 云端编排、增量验证、容器化 方向试，但这些短期内仍是硬成本，也谈不上成熟。

胡渊鸣在《如何有效地给 10 个 Claude Code 打工》里就提到了把「多实例并行」推到很工程化程度的实践：从单线程 vibe coding 一路写到 Git worktree 多开实例、Ralph 式任务队列、在隔离环境里减少反复权限确认，让人把带宽用在 CLAUDE.md / PROGRESS.md 这类长期上下文与任务拆解、验收 上，而不是跟每个 agent 来回点确认；他也写到「用程序管多个 agent」初期成功率很低，要靠 结构化日志闭环与错误沉淀 才慢慢拉高——和上面说的 瓶颈在人、在编排与工程物理 是同一类故事。[13]

5）策划侧：从创意到表格，从复盘到素材

策划同学能直接受益的场景也在变多，例如：

• 创意与脑暴：快速出多版方向，再人工收敛。

• 业内方案收集与对比：把公开分享、文章、竞品体验整理成对照表（注意版权与事实核对）。

• 线上运营向：结合当前版本与约束，生成活动排期/规划表的草案，再人工修订落地。

• 策划文档：从大纲到细纲，甚至对文档做 review（合理性、风险点、与程序/美术接口）。

• Excel：数值相关的粗算、表结构、批量公式与简单验证（仍以策划最终拍板为准）。

• 会议纪要与多语言：纪要初稿、对外沟通的多语言版本。

• 数据复盘与分析：把埋点/报表/日志摘要交给模型做整理、追问与可视化总结（仍以数据源与口径为准）。

• 内容生产：搭建原型时常见的“白模占位”，越来越多团队改为 直接生成可用占位素材，减少四处找资源的时间。

6）测试与质量：端到端很贵，但日志/指标侧很香

端到端跑通游戏测试仍然很难：启动客户端、复杂操作链路、画面识别与环境不稳定，都会让全链路自动化昂贵且脆弱。反过来，把问题收敛到 日志、指标、可重复脚本、明确断言，效率会好很多——例如崩溃栈定位、异常波动、配置扫描、性能分析等，很适合交给模型做第一轮分析与判断。

7）美术与场景：从“意向”到“进引擎”的链路在变短

「从想法到能进引擎」是有一串明确的环节：需求（仍主要由人定方向）→ 策划文档与方案发散（大模型多参与：起草结构、多版本对比、补全说明）→ 原画/风格板（文生图等：把「看得见长什么样」的试错做得又快又便宜）→ 3D（生成式或 2D→3D：先出白模/粗模，少从完全空白拓扑手搓起）→ 绑定与蒙皮（规则 + 模型辅助：压掉大量重复刷权重）→ 动作与特效（常配合参考视频、生成或半自动中间件）→ 导入引擎做可 walk 的原型。

其实每一步现在都在被AI渗透，比如文档与原画可以一开始就交给AI生成初版，多轮改稿而不必每次从零起笔，最后版本经过人工调整再做交付；3D/绑定则少买「第一版就完全手工」的账。

更具体一点，行业里已经出现几类很“工程化”的拼法：

• 动作：视频 → 数据 → 游戏

得益于视频的生成能力变强，传统的动捕流程甚至在某些场景下都可以被优化。比如，先用视频生成/实拍参考得到一段可视化动作，再用视频理解、姿态估计、动作提取一类能力，把时序信息转成骨架曲线或中间格式，最后做重定向（retarget）与清洗，导入引擎。直觉上也很朴素：参考视频越接近目标动作，后续提取越不容易“跑偏”；但中间涉及相机、体型差异、遮挡与物理合理性，仍然需要工具链与人工兜底。

• 绑定与蒙皮：自动化的收益很直观

自动绑定、蒙皮修复、权重建议 这类环节，最适合用规则 + 模型辅助：把重复劳动压下去，把人的时间留给异常骨骼、特殊体型与演出需求。

• 场景：从原画到摆放

一种典型路径是：用 AI 原画/气氛图 定调 → 再拆成模块化场景需求 → 生成或拼装 3D 资产 → 导入引擎 → 最后用 参考图布局/语义摆放（让人或智能体按截图、草图约束去摆物件与灯光）。它解决的不只是“建模”，而是更快完成可 walk 的原型关卡，便于策划与程序同步试玩法。

这条链路的最大现实约束不在“能不能生成”，而在 版权、风格一致性、性能预算、LOD、以及进引擎后的可维护性。所以更稳妥的落地方式通常是：AI 负责快速试错与占位，人类负责定标准与验收——和程序侧 Skill/文档拉准确率，是同一套逻辑。

不理想的地方

真正卡住团队的，往往不是“模型不够聪明”（当然也很重要），而是 知识如何进系统、如何更新、如何被正确调用：RAG、Skill、长上下文、MCP 工具链各有利弊，缺少像数据库 schema 那样行业统一的“项目知识库标准”。再叠加 UE 大型工程、蓝图与编辑器状态、测试环境成本，体感就会从“很强”变成“很烦”。

1）知识库与项目规范的构建：统一方案仍不成熟

想把项目知识交给模型用，常见几条路：检索增强（RAG）、可执行 Skill、以及 自定义agent的编排流程。现实里很少只选一种：

• RAG 适合“海量文档、频繁更新、需要引用出处”的场景，但会遇到切片质量、权限、过期文档、以及检索噪声。

• Skill 更像“可复用流程与模板”，对工程落地更硬，但需要人维护版本与边界，否则会变成“脚本地狱”。

• 两者不是替代关系，更像是 不同层的缓存：外层用 RAG 找材料，内层用 Skill 约束动作；但怎么切层、怎么做权限与审计，目前没有放之四海而皆准的模板。

往深了说，这和前文提到的 Harness（把模型放进可验收、可回滚的工程系统）是同一类问题：知识怎么切片、怎么挂进上下文、何时走检索何时走固定流程，本就和「工具怎么接、任务怎么拆、状态怎么交接」绑在同一张工程图上；大厂工程博客里讨论的 Harness，也是在约束这套东西。落到行业里，目前没有类似数据库 schema 那种可互操作的约定，多是各团队自建一套 RAG / Skill / 文档分层，各做各的、难以对齐，所以体感才会又碎又重。

如果没有这些经验积累，大模型能做的又非常有限，让他直接按照你的需求做一个功能，90%的概率是错的，而且解决问题的思和工程规范也大概率不符合项目的规范，如果一点点的告诉AI，结果就是你的时间成本根本没有省下来，反而可能更耗时。

所以很多Team都会选择构建自己的Agent，从流程上对大模型的提示词等进行规范和约束，同时配合RAG以及SKill来完善自己项目的上下文工程。也正是如此，这个东西对于不同的Team差异很大，很难有一套通用的模板。

2）UE 大项目 + 蓝图 + MCP：商业引擎的可视化功能给AI带来更高的学习成本

我最近在 UE 里用 Claude 尝试写蓝图时，遇到的现象很典型：流程比较冗余、上下文膨胀得很快，一个「创建蓝图」类任务可能执行非常久才完成。后来发现，问题在于蓝图和大模型的适配度比较差，项目积累的 Skill 和规范也几乎没有这方面的内容。

除了满屏节点连线，你还离不开「编辑器现在啥状态、引了啥资产、父类是谁、引擎哪一版」这些信息。一导出成文字，往往又长又碎，模型其实看着累，所以别指望它像grep代码那样改 .cpp 动一小块就能对上号——跟纯代码比，天生就不太对付。

现实里大家怎么绕？常见是加一层 MCP：引擎把「改蓝图、动资源」拆成一条条 Python 或命令行式的可调用动作（或者是C++代码），模型就调用 → 等结果 → 再调用。链能跑通，但我前面那种上下文浪费严重，速度慢、烧 Token 的情况还是非常常见的。目前感觉更像凑合用，谈不上理想形态；若能把这些嵌进 Agent 编排（并行、少人工反复点确认），会更有用。打通链条总比没有强。

3）游戏自动化测试：编辑器里「一用例一流程」，AI 端到端仍很吃力

落到编辑器里做自动化，很烦的一点是：几乎每个用例都是一套完全不同的操作路径——点哪儿、进哪个面板、要不要先烘资源、版本差一点点行为就变，很难抽成「一条脚本打天下」。要想让 AI 真的跑通，往往得背后先铺好一大堆固定自动化，再在关键步上做截图 / 画面对比一类识别；而大模型对这类「长链路 + 反复看图」的任务并不擅长，上下文里塞图像和中间状态，Token 也烧得很快。

反过来，画面里的细节（反射对不对、阴影干不干净）和玩家手感（输入延迟、动作黏不黏），都很难指望现在的 自动化测试体系（哪怕叠上 AI）把这些统统系统性地盖住——要么主观、要么和环境强绑定，自动化断言很难写稳。纯逻辑、纯数据流的问题，倒是更容易靠 日志、埋点、崩溃栈 揪出来，这也和前面「测试与质量」里说的收敛到可重复、可断言的一侧对得上。

真正还别扭的，是自动点按钮、在客户端里一步步执行玩法：驱动有了，稳定性不够，维护成本也不低。所以这一截短期内更像人力 + 传统自动化 + 日志分析的组合拳，而不是「交给大模型自己玩一遍就验收」。

五、游戏公司目前走到哪里？

最近几周（甚至一个月）的变化幅度非常大：就我观察，研发侧 几乎所有人 都已经在个人工作流里 主动或被动 接入了大模型——区别只在于深浅与是否体系化，而不是“用没用”。

公司层面更像“分部门各自推进”：

• 基建与中台（含工具团队）：

• • 代码 Agent 工具（类似ClaudeCode这种产品），尽量统一的 网关/API 去接外部大模型；

  • 内部服务与平台侧，几乎所有工具都会实现MCP功能，MCP 作为“模型—工具—系统”的通信方式已经很常见；

• • 用 云端部署的 Agent / 内部助手类方案（龙虾等），搭 定时任务、日志与崩溃辅助分析、重复运维、自动Review 等能力。

• 项目制作团队（程序/美术/策划/QA）：

• • 更多是在 摸索自己的工作流：有人专注 Skill 与规范，有人专注把文档与知识库补齐，有人在尝试打通引擎相关工具的 AI 使用场景。

  • 自定义适合项目的agent开发与编排，嵌进或者取代传统流水线的一两段

  • 打通游戏引擎的MCP，连接美术的DCC工具

  • 针对项目的辅助工具，比如文案编写AI辅助，策划配表自动化等

  • 自动化测试进一步AI化

如果把视野再拉开一点：各个部门都在推出自己的产品，比如市场与发行 也可以用同一套能力做 舆情与热度监控、竞品拆解、素材创作与投放文案等，很多内部非游戏团队也都把 AI 接进了工作流里，起码ClaudeCode、OpenCode、CCSwitch、ComfyUI这类产品几乎是人手必备了。

六、机会在哪？最后说说个人

门槛在降低，但“谁能用好”的差距在拉大。

个人能做的事情变多了：社交平台上出现过“AI 版 Facebook 一夜爆火”这类故事——demo 一晚上就能跑起来，这在以前很难想象。国内内容生态里，也有人用豆包等工具做小说解说续写、做动画“先行版”，速度比官方快、围观的人也不少。

我更想提醒一句：这个时代“做什么”比“怎么做更熟练”更值钱。很多人不是缺工具，而是被困在旧的工作细节里：反复抠琐碎、反复证明忙碌，却没时间抬头看需求与机会。

以前我对新技术常常“心有余而力不足”，但这一次不一样——AI确实能解决我的实际问题，能提高我的产出。每一个影响效率，需要重复操作的事情都可以尝试交给AI，一但跑通了流程后面用起来就会无比顺畅（当然这个过程是需要花费额外精力的）。

个人几点感受

去年年初我基本还属于“偶尔问问”的状态；下半年开始，我会更主动用这些工具写一些小功能、小工具、以及围绕需求让他帮我做拆解。如今，AI已经成为了我的编码主力工具，大部分需求我都会先把需求扔给AI，然后逐步通过对话完善目标，最后交给他来编码。

因此，我现在对未知技术的压力也小了很多：换作以前，遇到没接触过的模块，脑子里会先冒“我短时间能搞定吗？”；现在更像“先让工具跑一轮，我再决定怎么收口”。

不过，我也建议大家不需要盲目去跟进行业里面的每一个新概念，因为最后很多路线会收敛，很多会被抛弃，自己根据精力量力而行即可，不要被网上夸大的信息所影响；但同时必须拥抱和接触，不用的人注定会被善用的人拉开差距。

程序员的壁垒并不是“敲键盘的速度‘’，复杂系统的工程能力、判断力、对约束的理解在AI时代依然是关键。大模型一次性读不完你们项目的全部细节，上下文和工具链也有硬上限——领域壁垒越深，「会问」就显得尤其重要。

我更愿意把 AI 想成杠杆：你这边支点（规范、经验、判断、验收）越稳，放大越有意义；支点悬空，再强的模型也只是空转。

后面我会再写几篇，专门分享我的使用经验和日常用 AI 的场景，感兴趣的朋友可以关注一下，也可以先加群一起探讨更多可能。

参考：[1] Reuters. *Meta shares jump after report on plans for layoffs*（报道页面）. `https://www.reuters.com/business/meta-shares-jump-after-reuters-report-plans-layoffs-20-or-more-2026-03-16/`[2] 搜狐（转载/评论，宜交叉验证）. 得物前端团队组织调整相关讨论. `https://www.sohu.com/a/995275055_121124359`[3] PC Gamer. *Epic Games lays off more than 1,000 employees*（报道）. `https://www.pcgamer.com/gaming-industry/epic-games-lays-off-more-than-1-000-employees-were-spending-significantly-more-than-were-making-ceo-tim-sweeney-says/`[4] Google Sheets. Epic 裁员相关名单整理. `https://docs.google.com/spreadsheets/u/0/d/1CFwgPrwGvVvd2EZzqAVAuO7dCXvOff99CAJMA3IV4Fg/htmlview?pru=AAABnUoxY3s*oPqWhft6UM9I_V097t5LiQ&pli=1#gid=1785562436`[5] NVIDIA. GTC Keynote（官方入口）. `https://www.nvidia.com/gtc/keynote/`[6] NVIDIA Blog. *GTC 2026* 新闻汇总页. `https://blogs.nvidia.com/blog/gtc-2026-news`[7] Yahoo Finance. 英伟达 CEO 与 AI 需求、工程师 Token 激励等相关报道（宜与官方材料对照）. `https://finance.yahoo.com/news/nvidia-jensen-huang-thinks-1-173028109.html`[8] OpenAI. 《工程技术：在智能体优先的世界中利用 Codex》（中文）. `https://openai.com/zh-Hans-CN/index/harness-engineering/`[9] OpenAI. Codex 产品页. `https://openai.com/codex`[10] Anthropic Engineering. *Harness design long running apps. https://www.anthropic.com/engineering/harness-design-long-running-appsAnthropic Engineering. *Harness design for long-running application development*. `https://www.anthropic.com/engineering/harness-design-long-running-apps`[11] Anthropic Engineering. *Effective context engineering for AI agents*. `https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents`[12] Wikipedia. *Generative adversarial network*. `https://en.wikipedia.org/wiki/Generative_adversarial_network`[13] 胡渊鸣. 《如何有效地给 10 个 Claude Code 打工》（知乎专栏「图形之道」）. `https://zhuanlan.zhihu.com/p/2007147036185744607`[14] 知乎. 「AI 对游戏研发影响」相关问题下的回答线程. `https://www.zhihu.com/question/2013721223121635074/answer/2017934734890657492?share_code=13kST8l8mRiYk&utm_psn=2018640070077326696`[15] Cursor. Changelog（更新日志）. `https://cursor.com/changelog`[16] OpenAI Help Center. *Model release notes*. `https://help.openai.com/en/articles/9624314-model-release-notes`[17] OpenAI Help Center. *ChatGPT release notes*. `https://help.openai.com/en/articles/6825453-chatgpt-release-notes`[18] Anthropic. Claude *Models overview*（文档）. `https://platform.claude.com/docs/en/about-claude/models/overview`[19] 阿里云帮助中心. 通义大模型 / 模型服务（文档入口）. `https://help.aliyun.com/zh/model-studio/`[20] 火山引擎文档中心. 豆包大模型等（文档入口）. `https://www.volcengine.com/docs/82379`[21] 米哈游LPM视频模型 https://large-performance-model.github.io/### 其他链接- Anthropic Engineering. *Effective harnesses for long-running agents*. `https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents`- Neon. *State of AI 2025*（开发者工具采纳调查，第三方，注意样本口径）. `https://neon.com/blog/state-of-ai-survey-2025`- Anthropic 长文短链（重定向至[10]）. `https://t.co/HWvmXk1ykn`

我是Jerish，网易游戏工程师，8年从业经验。该公众号会定期输出技术干货和游戏科普的文章，关注我回复关键字可以获取游戏开发、操作系统、面试、C++、游戏设计等相关书籍和参考资料。