从 2025 年 7 月到 2026 年 6 月，我后面这批博客，慢慢写成了两条线。
一条是二合游戏客户端工程。
另一条是 Unity 开发里，哪些活适合让 AI 先帮你干 60 分版本。
前者偏运行时、性能、架构、存档、防作弊。
后者偏工具链、排查、回归、编辑器工具、工程流程。
如果你是第一次点进来，直接从归档一篇篇翻，效率其实不高。
所以这篇就当一个系列导航。
不讲新概念，纯粹帮你省时间。
一、如果你主要关心二合游戏客户端工程，先看这一条线
这条线更适合这些人：
- 正在做二合、合成、订单类手游
- 想补客户端性能、棋盘结构、弱联网存档这类问题
- 对“为什么这种项目看着不重，做起来一堆坑”有切身感受
1. 从性能入门看
建议先从这 4 篇开始：
- 二合游戏看着很休闲，为什么 UI 一复杂就开始掉帧？
- 二合棋盘一热闹就卡？问题往往不在棋子，在你太想“有反馈”了
- 二合游戏最容易让人上头的，不是装修剧情，是生成器和掉落表那点小心机
- 二合游戏的订单系统，千万别只把它当任务列表，它其实在偷偷控制玩家节奏
这几篇基本能把二合项目最常见的客户端压力点和系统节奏感先搭起来。
2. 如果你已经踩到存档和安全问题了
接着看这 2 篇：
这两篇更偏架构边界和工程取舍，不是银弹方案，但适合先把脑子里的边界划出来。
3. 如果你已经进入“内容越堆越重”的阶段
建议顺着看这 5 篇：
- 二合游戏越做越重时，真正救命的往往不是加班，是那套顺手的配置工具链
- 二合游戏活动越多越赚钱，也越容易把客户端做崩，活动工程化该早点上桌了
- 二合游戏的新手引导，别只会加手指动画了，真正难的是状态机和容错
- 二合棋盘为什么越玩越乱？问题不只是策划设定，很多时候是对象生命周期没管住
- 二合游戏上了低端机就掉链子？别只盯优化点，先把降级策略设计成系统
这几篇连起来看，会比较像“项目中后期开始收债”时该先看哪些面。
4. 如果你已经开始盯线上稳定性和工程回路
可以继续看：
这篇更像是前面那些运行时问题的收口文。
它不再讲单个优化点，而是讲你怎么证明自己真的优化了，而不是自我感觉不错。
二、如果你主要关心 Unity + AI 工程工作流，走另一条线
这条线更适合这些人：
- 已经在用 Copilot、ChatGPT、Claude 之类的工具，但总觉得“能用，没用透”
- 想知道 Unity 开发里，到底哪些活适合先交给 AI
- 不想看空泛 AI 观点，只想看具体苦活怎么省时间
这条线我刻意没写成“AI 很厉害”的宣传稿。
核心就一句话：
别让 AI 替你拍板。
让它先把那些机械、重复、容易拖着不做的活推到 60 分。
1. 先从最容易落地的工具类开始
建议先看这 3 篇：
- 用 AI 帮 Unity 写编辑器工具挺香，但前提是你别只会说“帮我写个工具”
- 用 AI 帮 Unity 查配置表错误，比让它直接写玩法靠谱多了
- 编辑器批处理脚本总是又长又烦？这类活真的很适合先让 AI 打个底
这三篇比较像一组。
核心都是编辑器工具、规则检查、批处理脚本这类特别适合 AI 起草的活。
2. 如果你更关心排查和诊断
建议看这 3 篇：
- AI 能不能帮你查 Unity 卡顿？能，但你得先把现场证据喂明白
- Unity 日志一多就像看天书？AI 很适合帮你做第一轮异常归因
- 让 AI 先帮你列 Code Review 清单，比每次拍脑袋看提交靠谱多了
这组更偏“人已经在工程现场里了，怎么让 AI 帮你先收集、归类、整理判断面”。
3. 如果你更关心测试、回归和流程化
建议看这 4 篇：
- AI 能不能帮 Unity 写回归脚本？能，尤其适合那些重复到让人犯困的检查项
- 让 AI 先帮你列回归清单，比等版本提测后大家一起脑补靠谱多了
- 老 Unity 模块最怕没人敢动，AI 倒是很适合先帮你补那层测试和替身
- 埋点设计最怕事后补锅，AI 倒是很适合先帮你把埋点草图铺出来
这组更像项目中后期的日常工程维护线。
4. 如果你做的是资源、热更新、发布链路
建议顺着看这 4 篇：
- 热更新最怕资源依赖一团乱，AI 倒是挺适合先帮你查这笔账
- 资源规范最怕靠口头约定，AI 倒是很适合先帮你当那个不嫌烦的检查员
- CSV 导表这类脏活很适合先交给 AI，但别让它偷偷把配置协议写歪了
- 打包前总怕漏资源？AI 很适合先帮你做那层资源发布前检查
这几篇更像工具链和发布链的苦活合集。
三、如果你时间不多，我建议就按这条最短路径读
如果你是 Unity 客户端，时间又不多，我建议先看这 6 篇：
- 二合游戏看着很休闲，为什么 UI 一复杂就开始掉帧？
- 弱联网二合游戏的存档，到底该信服务器，还是该信本地？
- 二合游戏活动越多越赚钱，也越容易把客户端做崩，活动工程化该早点上桌了
- 用 AI 帮 Unity 写编辑器工具挺香，但前提是你别只会说“帮我写个工具”
- AI 能不能帮你查 Unity 卡顿？能，但你得先把现场证据喂明白
- AI 能不能帮 Unity 写回归脚本？能，尤其适合那些重复到让人犯困的检查项
这 6 篇差不多能把我这一轮最想说的东西看个大概：
- 二合项目哪里最容易出工程问题
- Unity 客户端后期为什么总在收债
- AI 到底该进哪些开发环节，才是真的省时间
四、这批文章的共同态度，其实就一句话
无论是二合客户端工程，还是 Unity + AI 工作流，我后面写这些文章时，其实都在强调同一件事：
别迷信一个“神奇功能”会替你把问题自动搞定。
二合游戏不是因为玩法轻，就没有技术债。
AI 也不是因为现在好用，就能替你做工程判断。
真正值钱的，往往还是这些东西：
- 结构先搭对
- 边界先划清
- 苦活尽量工具化
- 重复活尽量流程化
- 让系统越来越容易验证，而不是越来越靠感觉
如果这份导航能让你少翻半天归档，直接跳到自己真正关心的那几篇，那它就算有用了。
后面我应该还会继续沿着这两条线写。
毕竟项目里的坑，不会因为我写过博客就自动消失。
它们只会换个方式再来一遍。