AI 与游戏研发周期：五个阶段，四处扎穿

立项原型 · 内容生产 · QA 自动化 · 上线运营 · 数据迭代

名词速查

首次阅读可跳过本表，直接看「场景问题」，遇到生词再回查。

本篇是业务纵向轴，不拥有自己的一组名词——所有专业名词的完整解释（后台类比 + 系统职责 + 失效边界）都在各自归属页。下面只给"它在本篇里承担什么角色"和去处，避免同一个词在站内解释两遍。

场景问题

一个上线两年的手游项目，团队同时在四个地方用 AI：策划用它写活动文案、美术用它出概念图、QA 用它生成测试用例、运维接了个 AI 巡检。半年后复盘，四个的结局完全不同——

• 文案：真正节省了时间，但需要一个人全职审校，净收益约 30%。
• 概念图：产量暴涨，但可用率不到 5%，成了"灵感刷新器"而非生产工具。
• 测试用例：生成了 800 条，跑起来 700 条报错，最后发现问题不在生成，在没人能说清"通过"的标准是什么。
• AI 巡检：唯一被完整保留并扩大的一个——因为它的判据（告警是否需要人介入）本来就有人工基线可对齐。

同一个技术，四种命运。差异不在模型能力，在每个阶段"正确"是否可判定。这篇按研发周期五阶段横向展开，每阶段先说清它引入的新问题，再在后台侧四处扎到实现层。

实现方案

五阶段全景

下面按这张表展开：②⑤ 只给形态与边界，③④ 扎到实现层。

① 立项与原型：唯一值得说的是那条红线

AI 在这个阶段的价值最直白——一周搭三个玩法原型试手感，以前要一个月。形态没什么可深挖的（就是加速编码与数值模拟）。

值得说的只有一条红线：原型代码默认不进主干。理由不是"AI 写的代码质量差"，而是原型的优化目标就不是可维护性——它为了快，会把配置写死、把边界省掉、把错误处理跳过。这些在原型阶段是正确取舍，进了主干就是债。

判据：如果玩法验证通过要转正式开发，重写而不是重构。这条在 AI 加速原型后变得更重要，因为原型的产出量上去了，"顺手留下"的诱惑也更大。

② 内容生产：形态与失效边界

这个阶段的 AI 形态最多，但对后台岗不是追问面，所以只给形态 + 一句边界。共同的规律是：产量提升不等于产能提升，因为审校环节没变快。

如果 AI 不只是辅助写文案、而是直接生产可交付内容（互动影游、长视频），下面这些"失效边界"就成了必须解决的正题——手段见 互动影游与长视频创作 Agent：世界观一致性靠结构化 Story Bible 当黑板、视觉一致性靠参考图+固定种子（不靠 prompt 复述）、时间线靠显式事件表+连续性断言。

策划侧

• 文案 / 剧情 / 台词：批量出草稿。失效边界：AI 写不出「与既有世界观和角色历史一致」的内容——它不知道三年前某个 NPC 说过什么，写出来的东西需要熟悉设定的人逐句核，而这个人正是最稀缺的。
• 本地化翻译：多语种首轮翻译。失效边界：游戏文本高度依赖上下文（同一个 "Fire" 是技能名、按钮还是剧情动词），且各地区有合规与文化禁忌，机翻在这两点上必须人工过审。
• 配置表校验：用 AI 检查数值配置的异常（掉落概率总和不为 1、等级曲线断档）。失效边界：这类校验其实规则写得出来——能写成规则的就不该用模型，规则更快更确定更便宜。AI 只在"这个数值看起来不合常理"这类模糊判断上有增量。

美术侧

• 概念图 / 参考图：发散阶段刷灵感。失效边界：开篇那个 5% 可用率就是典型——AI 出图与项目既定美术风格的对齐成本极高，它更适合"我还不知道要什么"的阶段，不适合"我要这个角色的第 3 套皮肤"。
• 贴图 / 材质：批量生成变体。失效边界：贴图要满足技术规格（分辨率、UV、通道约定、内存预算），生成结果需要走一遍资产管线校验，这一步通常没被算进"节省的时间"里。
• 动画辅助：动作补间、动捕数据清理。失效边界：手感是逐帧调的，AI 能出"看起来对"的动作，但游戏动作的攻击框判定帧、取消窗口这些gameplay 语义它给不了。
• 资产命名与合规检查：批量检查命名规范、版权风险、敏感元素。失效边界：合规判定的后果严重且地区差异大，AI 只能做初筛并标注置信度，终审必须是人。

程序侧

• 代码生成与存量代码理解：这块与游戏无关，是通用软件工程问题，完整展开见 AI 研发工程化（四层栈、存量代码三索引、企业级落地红线）。失效边界：游戏项目特有的困难是引擎代码 + 大量配置 + 美术资产混杂，纯代码知识图谱覆盖不到"改这个配置会影响哪个关卡"这类跨类型依赖。

③ QA 与自动化测试：难点不在「能不能点」，在「怎么知道错了」

打个比方：这正是你写接口自动化测试时的老问题——发请求容易，写断言难。谁都能拿脚本把接口调通，难的是"返回什么才算对"：字段齐了但数值错了算不算过？所以真正的成本在断言，不在驱动。类比失效边界：接口测试的断言可以精确比对（期望 JSON 一字不差）；游戏里大量正确性是状态与数值的一致性——扣了多少血、掉了什么装备、任务进度对不对，且很多结果带随机性。所以断言得建在可查询的状态快照上（服务端数值、日志事件），而不是画面截图，也不能指望"跑通了就是对了"。

这是后台侧第一个扎穿点。开篇那 800 条测试用例失败的根因就在这——大家默认难点是"让机器会玩游戏"，实际难点是"让机器知道什么算错"。

两条路线的分工

服务端 fuzz 相对成熟，因为判据清晰：进程崩了、返回了不该返回的错误码、数据库出现了不该有的状态。真正难的是客户端。

为什么游戏客户端自动化比 Web 难得多

三个结构性原因：

1. 状态空间爆炸 + 长序列依赖。Web 测一个下单流程，5 步以内到目标状态。游戏要测"公会战结算异常"，得先建公会、招够人、报名、打完三轮——几百步操作才到测试起点，且中间任一步失败整条链就断了。这让"随机探索"的效率低到不可用。
2. 渲染与物理的非确定性。同一份输入，两次运行的画面像素不同（粒子、光照、随机动画），物理模拟受帧率影响会分叉。所以图像比对做断言基本不可行——它会产生大量假阳性，最后没人看告警。
3. 没有 DOM。Web 有稳定的选择器，游戏画面是一张纹理。要么接引擎侧的调试接口拿 UI 树（需要客户端配合埋点），要么做图像识别（不稳定）。这决定了自动化测试必须在项目早期就要求客户端提供可测性接口，事后补代价极高。

可判定的断言从哪来

这是这一节的核心答案。不要试图断言"看起来对不对"，用这五类客观信号：

五类的共同特点：都不依赖"预期画面"，所以不受渲染非确定性影响。

录制回放与确定性种子的作用是让失败可复现——固定随机种子 + 录制输入序列，崩溃才能被开发定位。没有这一步，探索测试只能产出"某次跑崩了"这种无法行动的报告。这与 Agent 离线回放要固定的东西是同一类问题（见 评测与线上运营）。

Agent 在其中的角色边界

Agent 负责探索与用例生成，不负责判定。

# Agent 只产出"怎么走到那个状态"，断言由确定性规则给
async def explore_episode(agent, client, invariants: list[Invariant]) -> Report:
    seed = new_seed()
    client.reset(seed=seed, record=True)      # 确定性种子 + 录制，保证可复现
    trace = []

    for step in range(MAX_STEPS):
        obs = client.observe()                # UI 树 + 游戏状态（引擎调试接口，非截图）
        action = await agent.next_action(obs, goal="到达公会战结算界面")
        client.act(action)
        trace.append((action, obs.digest))

        # 断言全部来自客观信号，与 Agent 的判断无关
        for inv in invariants:
            if not inv.holds(client.state()):
                return Report(FAIL, reason=inv.name, seed=seed,
                              replay=client.dump_record(), step=step)
        if client.crashed() or client.stalled(threshold_ms=3000):
            return Report(FAIL, reason="crash_or_stall", seed=seed,
                          replay=client.dump_record(), step=step)

    return Report(PASS if goal_reached(client) else NOT_REACHED, seed=seed)

关键在 invariants 与 agent 的分离：如果让 Agent 自己判断"这样对不对"，它会把自己造成的 bug 判为正常——它对"正确"的理解和它对"该怎么操作"的理解来自同一个模型，一起错。这与 运行时 里"不能让模型自己判断危险动作"是同一条原则。

规模锚点：Agent 探索在目标状态 50 步以内的场景收益明确；超过几百步的深层状态，更划算的做法是用存档/GM 指令直接跳到测试起点，让 Agent 只探索最后那几十步。指望它从新号一路打到公会战，是在拿模型调用费换本可以一行 GM 命令解决的事。

与压测的分界：这里讲的是功能正确性自动化；万级并发下的性能与稳定性是压测的范畴，方法论完全不同（详见 极限压测 与 性能分析与优化）。两者容易混：压测发现的是"5000 人同时进会崩"，功能测试发现的是"这个流程走到第三步数值算错了"。用压测工具做功能断言，或用功能测试跑并发，都会两头不着。

④ 上线运营：后台侧的主战场

打个比方：这三处的取舍就是你给不同链路定 SLA 与告警策略时做的事——核心交易链路容不下 200ms 抖动、离线报表能等几分钟；而误报和漏报的代价也不对称：多打一次电话叫值班，比漏掉一次资损便宜得多。同一套能力放在不同链路上，可用与不可用完全取决于这两条。类比失效边界：常规链路的延迟与误判率是可测且稳定的，压测一遍就有数；模型的这两项随输入分布漂移——同一个反外挂模型，换个版本、来了新一批玩家行为，误判率就变了，而它不会告警。所以这里除了定预算，还必须持续监控口径本身有没有偏。

三个扎穿点，共同约束是延迟预算与误判代价不对称。

深挖点一 · AI 巡检 Agent

场景与其他 Agent 应用有个本质差异：它是持续观察，不是一问一答。日志、指标、告警持续流入，没有明确的"用户提问"，也没有明确的"任务结束"。这带来两个设计后果。

后果一：上下文永远在增长，压缩不是优化而是必需。 三层窗口的时间参数：

参数不是拍的，是跟着业务判断周期走的：10 分钟对应告警聚集、1 小时对应升级决策、1 天对应周期对比。换个场景（比如经济系统监控）这三个数就得重标。

后果二：必须能从崩溃中接上。 压缩产出固定结构：

{time, service, symptom, root_cause_hypothesis, action}

每步把 current_focus（一句话："正在确认 db-proxy 的连接池是否耗尽"）写进独立 memory。崩溃恢复时用 current_focus + Layer-2 摘要重建上下文，两轮内接上——不必 replay 全部原始日志，因为 Layer-2 已经是判断所需的充分信息。这套记忆机制的实现细节（写入触发、压缩水位、pin 如何不被滑走、三种失效的检测）在 Agent 运行时深水区 展开，本篇不重复。

护栏边界：涉及重启 / 回滚 / 扩缩容的动作，Agent 只能提交审批，不能自行执行。理由是这类动作在故障期的破坏半径最大——一个误判的"重启"会把一次局部抖动变成全服不可用。巡检 Agent 的正确定位是把人的注意力引到该看的地方，不是替人操作。日常运维本身的流程与判据见 服务器日常运维。

打个比方：AI 巡检像医院的分诊台——它不治病，它读一眼你的症状和体温，判断该去哪个科、要不要插队。分诊准了，医生的时间就用在对的病人身上。类比在哪失效：分诊台面对的是一个个独立就诊的病人，判断错了下一个病人不受影响；而巡检 Agent 面对的是同一个系统的连续状态，它上一轮的错误结论会留在上下文里污染后续判断（"我已经排除了数据库问题"），越往后越偏。所以巡检必须周期性 checkpoint + 重开窗口，分诊台不需要"忘掉上一个病人"。

深挖点二 · 反外挂：在线拦规则，离线定罪模型

反外挂是延迟预算与误判代价两个约束同时最紧的场景。分工是硬性的：

为什么 LLM 不进在线拦截路径，三个理由缺一不可：

1. 延迟：一次模型调用几十到几百毫秒，而外挂判定在战斗结算这类关键路径上——加这一段等于让所有玩家为极少数外挂等待。
2. 成本：按每秒判定次数算，全量走模型的成本是荒谬的。
3. 不确定性：同样输入可能给出不同结论，而封禁类动作必须可复现、可举证。玩家申诉时你无法解释"模型当时觉得你像外挂"。

模型的正确位置在离线：它擅长的是「从长期行为序列里发现规则写不出的模式」（比如操作间隔的分布过于规律、多账号的资源流向构成团伙图）。特征工程侧负责把原始日志变成可计算特征，模型侧负责在特征空间上找模式——两者边界就在这。

误判代价不对称如何决定阈值：误封一个正常玩家的代价（流失 + 舆情 + 客服成本）远高于漏封一个外挂（少量经济影响，且可以后续再封）。所以：

• 自动封禁的阈值设得很保守（高精确率，宁可漏），只对证据链极强的自动执行。
• 中间置信度区间进人工复核队列，而不是自动封——这个队列的容量决定了阈值能放多宽。
• 可逆动作（限速、匹配隔离）阈值可以激进，因为误判的补救成本低。

这与 Agent 评测 里护栏阈值的判据是同一个逻辑：看误判的补救成本。反外挂的业务侧全貌见 反外挂。

深挖点三 · 客服 Agent：查得准 > 答得像

客服场景的核心不是生成能力，是能不能拿到准确的玩家状态。一次请求的组合：

为什么「查得准」比「答得像」重要：一个措辞完美但说错了订单状态的回答，比一个生硬但准确的回答糟糕得多——它会让玩家基于错误信息做决定（比如再充一次），把一次咨询升级成一次投诉。所以客服 Agent 的评测重点应该是工具调用的正确率（是否查了该查的、是否读对了返回），而不是回答的流畅度。这正是 Agent 评测 里「过程断言」比「终态断言」更适用的典型场景。

副作用动作必须走人工闸门：补偿、退款、解封都是 L2 不可逆动作（分级见 运行时）。Agent 的产出是一张填好的申请单（附上它查到的证据），人点确认。这既是风控要求，也让 Agent 的错误可以在生效前被拦住。

知识过期的治理——这是客服 RAG 最常见的事故：版本更新后，旧版本的 FAQ 仍在向量库里，且与新问题语义高度相似，于是被召回并当成当前事实。三条治理手段：

• 切片带版本元数据，检索时按当前版本过滤（不是靠相似度碰运气）。
• 过期切片主动下架，而不是靠新切片"盖过"旧切片——相似度不保证新的排前面。
• 召回结果带时间戳呈现给模型，并在 prompt 里明确"若引用内容早于当前版本，需说明可能已变更"。

检索链路本身的实现（chunking、混合检索、rerank、"迷失在中间"）见 RAG 与 RAG 存储与版本化，本篇不重复。

舆情监控（形态 + 边界）

论坛/社区/应用商店评论的情感分类与话题聚类。失效边界：游戏社区的黑话、反讽、梗图密度极高（"这游戏真好玩"可能是骂），通用情感模型在游戏语料上准确率明显下降，需要用自己社区的标注数据校准。且舆情指标只能作为信号不能作为结论——声音最大的群体不等于多数玩家。

⑤ 数据驱动迭代：形态与那个真实的坑

形态：自然语言查询数据（"上周留存跌了多少"）、异常指标自动检测与归因、流失预测与召回名单。

真实的坑：AI 给的归因与 AB 实验结论冲突时怎么办。AI 做的是观察性数据上的相关分析——它会说"流失玩家里 70% 在第 3 关卡住了，所以第 3 关难度是流失原因"；而 AB 实验做的是干预——把第 3 关调简单，留存可能一点没变（真正卡住他们的是别的东西，第 3 关只是共同表现）。

裁决规则：有 AB 结论时以 AB 为准，AI 归因的定位是提出假设、缩小实验范围，不是给结论。这个分工搞混的代价是：团队按 AI 的归因改了一版，数据没动，然后开始怀疑数据平台。

为什么这么做

为什么后台侧只扎穿这四处

判据是「这一处能不能追问到实现层」。巡检的窗口参数、反外挂的在线离线分工、客服的工具调用组合、QA 的断言来源——这四处都能一路追到代码与阈值。而"美术生成"追下去会到扩散模型原理，那既超出后台岗的追问面，也稀释了这篇的主线（何况写深了会与 llm-fundamentals 重复）。

为什么 QA 阶段的答案是「断言」而不是「操作」

开篇那 800 条用例的故事就是答案。业界的注意力长期在"让机器会玩"上（视觉识别、强化学习玩游戏），但工程上真正卡住落地的是：你能自动跑一万次，但如果不能自动判定这一万次里哪次错了，你只是烧了一万次的机器时间。

所以投入顺序应该反过来：先把数值不变量、协议断言、崩溃检测这套判据建起来（这部分不需要 AI），再考虑用 Agent 提高探索覆盖率。反过来做的项目都卡在了同一个地方。

为什么巡检能成功而其他三个不理想

回到开篇的四种命运——巡检成功的结构性原因是它的判据本来就有人工基线：值班同学看到这个告警会不会介入，是可以标注的、可以对齐的、可以算准确率的。而"这段文案好不好""这张概念图能不能用"没有这样的基线，于是无法评测、无法改进、只能凭感觉。

推论：判断一个 AI 应用能不能在游戏研发里活下来，先问「它的正确与否有没有可标注的人工基线」。有，就能进入评测-改进的循环；没有，它最多是个辅助工具，且随时会被弃用。

为什么别的选择不行

「上一个统一的 AI 中台，全周期都用它」

五个阶段的约束根本不同：QA 要的是可复现（固定种子、录制回放），巡检要的是持续观察 + 崩溃恢复，反外挂在线侧要的是毫秒级 + 确定性（所以根本不该用 LLM），内容生产要的是批量 + 人审接口。硬统成一个平台的结果是：为了兼容在线反外挂的延迟要求，整个平台的抽象被拉到最低公分母，其他四个场景反而都不好用。

可以统一的是底座（模型网关、prompt 版本管理、可观测、成本核算），不是应用形态。这与 AI 研发工程化 里控制面/数据面/可观测面的划分是一致的。

「反外挂用 LLM 做在线判定，效果肯定比规则好」

效果可能更好，但三条硬约束都过不去：延迟（关键路径上加几百毫秒）、成本（每秒判定次数 × 单价）、不确定性（封禁需要可复现的证据链，玩家申诉时"模型觉得你像"不是理由）。而且规则并不弱——服务器权威校验（伤害是否超过理论上限、位移是否超过速度上限）这类规则的召回率在硬外挂上极高，且零假阳性。

「客服 Agent 直接接数据库，别搞工具那一层」

工具层不是多余的间接层，它承载三件事：权限最小化（只暴露必要的查询，不给 Agent 任意 SQL）、凭据隔离（模型只见连接句柄，见 运行时）、审计（每次查了谁的数据有记录，这在有隐私合规要求时是硬性的）。直连的方案在第一次提示注入事故里就会付清全部代价。

「QA 用图像比对做断言，最直观」

游戏画面的非确定性（粒子、光照、随机动画、帧率相关的物理）会产生大量假阳性。假阳性的真正代价不是"多看几个告警"，而是告警会被整体忽略——一个 30% 假阳性率的自动化测试，两周后就没人看它的报告了。宁可断言覆盖面小但零假阳性（崩溃、数值不变量），也不要覆盖面大但吵。

三类 AI 应用的落地难度对照

这张表解释了开篇的四种命运，也是选型时的第一道筛子：从判定类开始上，生成类最后上。

沉淀结论

面试常见问题清单

全周期与选型

• Q：AI 在游戏研发各阶段解决什么问题？ A：立项期加速试错（红线是原型不进主干）、内容生产期提产量（新瓶颈是人审）、QA 期提探索覆盖（真难点是断言）、上线运营期是后台侧主战场（巡检/客服/反外挂）、数据迭代期提假设（不是给结论）。
• Q：怎么判断一个 AI 应用能不能落地？ A：先问「它的正确与否有没有可标注的人工基线」。有基线才能进评测-改进循环（判定类、查询类），没有的（生成类）最多是辅助工具。落地顺序：判定类 → 查询类 → 生成类。
• Q：为什么不该做一个全周期统一的 AI 中台？ A：五阶段约束冲突——QA 要可复现、巡检要持续观察+崩溃恢复、在线反外挂要毫秒级确定性、内容生产要批量+人审接口。统一会被拉到最低公分母。可统一的是底座（模型网关/prompt 版本/可观测/成本），不是应用形态。

QA 与自动化测试

• Q：游戏客户端自动化比 Web 难在哪？ A：① 状态空间爆炸 + 长序列依赖（几百步才到测试起点）② 渲染与物理非确定性（图像比对不可行）③ 没有 DOM（要么接引擎调试接口，要么图像识别）。第三点决定可测性接口必须早期就要求，事后补代价极高。
• Q：自动化测试的断言从哪来？ A：五类客观信号——进程级（崩溃/卡死/内存超预算）、协议级（非法错误码/状态机破坏）、数值不变量（金币不为负/结算守恒）、帧同步一致性（多端同帧校验和）、日志级（ERROR/断言/Sanitizer）。共同点是都不依赖预期画面。
• Q：Agent 在自动化测试里的角色边界？ A：只负责探索与用例生成，不负责判定。让它自己判断对错，它会把自己造成的 bug 判为正常——因为"怎么操作"和"什么算对"来自同一个模型，一起错。

上线运营

• Q：AI 巡检的窗口参数怎么定？ A：跟业务判断周期走——10 分钟对齐告警风暴聚集窗口、1 小时对齐值班交接与升级决策、1 天对齐周期性对比。换场景必须重标，不是通用常数。
• Q：为什么 LLM 不能做在线反外挂判定？ A：延迟（关键路径加几百毫秒，全体玩家为极少数外挂等待）、成本（每秒判定次数 × 单价）、不确定性（封禁需可复现证据链，申诉时"模型觉得像"不是理由）。分工是在线拦规则、离线定罪模型。
• Q：反外挂阈值怎么定？ A：误封代价（流失+舆情+客服）远高于漏封（少量经济影响且可补封）。所以自动封禁阈值保守（高精确宁可漏）、中间置信度进人工复核队列（队列容量决定阈值能放多宽）、可逆动作（限速/匹配隔离）阈值可激进。
• Q：客服 Agent 最重要的是什么？ A：查得准 > 答得像。措辞完美但说错订单状态会让玩家基于错误信息行动，把咨询升级成投诉。所以评测重点是工具调用正确率（过程断言），不是流畅度；副作用动作（补偿/退款/解封）必走人工闸门。
• Q：客服 RAG 的知识过期怎么治？ A：切片带版本元数据并按当前版本过滤、过期切片主动下架（不靠新切片"盖过"旧的，相似度不保证新的排前）、召回结果带时间戳并要求模型声明可能已变更。

数据迭代

• Q：AI 归因与 AB 实验结论冲突时听谁的？ A：以 AB 为准。AI 做的是观察性数据的相关分析（"70% 流失玩家卡在第 3 关"），AB 做的是干预（调简单了留存可能不动——第 3 关只是共同表现不是原因）。AI 的定位是提假设、缩小实验范围。

记忆口诀

• 五阶段：立项试错 → 生产提量 → QA 提覆盖 → 运营主战场 → 数据提假设
• 每阶段新问题：技术债 / 审得起吗 / 断言从哪来 / 延迟与误判 / 归因 vs AB
• 落地第一道筛子：有没有可标注的人工基线——判定类 → 查询类 → 生成类
• 内容生产一道题：（原耗时 − AI 耗时）− 审校耗时 > 0 吗
• QA 三难：状态空间爆炸 / 渲染非确定 / 没有 DOM
• 断言五来源：进程 / 协议 / 数值不变量 / 帧同步校验和 / 日志——都不看画面
• Agent 角色：只探索不判定（自己判会把自己的 bug 判成正常）
• 巡检三窗口：10 分钟告警风暴 / 1 小时升级决策 / 1 天周期对比
• 反外挂铁律：在线拦规则、离线定罪模型，LLM 不进在线路径
• 阈值判据：看误判的补救成本——不可逆宁可多拦，可逆可以激进
• 客服铁律：查得准 > 答得像，副作用必走人工闸门
• 数据铁律：有 AB 就听 AB，AI 只提假设

内容来源

综合整理：AI 巡检与客服 Agent 自研落地经验、游戏项目自动化测试与反外挂的工程实践观察（2026-08）。

文中窗口参数（10 分钟 / 1 小时 / 1 天）、探索步数阈值（50 步）与样本配比均为经验值，跟业务判断周期强相关，换场景必须重新标定。生成式 AI 的可用率随模型能力快速变化，"内容生产"一节的失效边界需按当期实际复测。

自测：合上资料能说清楚吗？

1. 同一个团队在四个环节用 AI，只有巡检活下来了。结构性原因是什么？这个结论怎么用在选型上？

2. 游戏客户端自动化测试比 Web 难在哪三处？哪一处决定了它必须在项目早期就动手？

3. 自动化测试的「可判定断言」有哪五类来源？它们的共同特点是什么？

4. 对比 在线拦截 与 离线定罪 两条反外挂路线：延迟预算、手段、动作各是什么？为什么 LLM 只能在后者？

5. 客服 Agent 为什么说「查得准 > 答得像」？这句话怎么影响它的评测重点？知识过期怎么治？

6. AI 给出的数据归因与 AB 实验结论冲突，该听谁的？为什么？