智能角色功能的交付验收

先把对象说清楚

沈砚舟处理游戏客户端里的“智能角色功能的交付验收”时，通常不会先讨论工具多不多，而是先把任务压到一个具体场景：谁在什么条件下发起操作，系统需要留下什么结果，哪一步出错必须停止。只要这个场景还说不清，后面的架构图和参数表就很容易变成装饰。落地时，先把会被谁使用、输入从哪里来、输出落到哪里写进任务说明。不要把一个宽泛的需求拆成很多漂亮的名词；真正需要确认的是每个动作是否会改动状态、是否依赖外部服务，以及失败后用户会看到什么。把这些问题放到实现前，比上线后靠日志猜原因省事得多。

处理这类问题时，我会先挑一条最常见的路径跑通，再故意让它遇到缺字段、超时、权限不足和重复提交。记录的重点不是“测试通过”，而是当时的输入、版本和结果。能复现的记录才能帮助后来的人判断改动影响。

NPC 的感知、记忆、决策和动作里，最难的通常不是把主路径跑通，而是明确谁能改状态、失败后留下什么，以及怎样复现判断。下面只围绕一个可落地的做法展开。

原型之后补边界

原型证明主路径可行，交付还需要输入限制、状态保存、错误提示、监控和维护入口。先确定谁会使用、谁会排错，再补完整流程。

放到这个主题里，模型可以给出意图或候选动作，寻路、战斗结算和任务发奖仍由游戏规则层执行。把可见目标、任务阶段、冷却状态和可调用动作作为结构化输入；输出只接受动作名、目标标识和理由码，服务端再校验前置条件。

验证不要只看一次结果

将原型的假设列成待办，逐条用真实输入验证，不能成立的假设就缩小功能范围。

准备巡逻、战斗、任务中断和无可行动作四类固定场景，检查 NPC 是否只使用当前允许的动作。

把验收拆成玩家能感知的结果

验收表里不要只写“行为正确”。巡逻角色要能在指定路线、被阻挡和目标消失三种情况下停在合理的位置；战斗角色要在技能冷却、仇恨切换和撤退条件变化后更新动作。每个场景都要保存进入场景时的任务状态、角色属性和配置版本。这样某次行为不对时，策划、客户端和服务端讨论的是同一份上下文，而不是各自回忆当时发生了什么。

对于模型参与的部分，先检查它给出的候选动作是否落在白名单内，再看理由码是否能帮助定位输入缺失。不要把自然语言解释当作判定依据。真正决定动作的是规则层返回的校验结果，例如目标是否存在、距离是否满足、任务阶段是否允许。被拒绝的动作也要计数，但日志里只保留必要字段，避免把整段对话和玩家数据塞进调试记录。

发布时留一个收口

首版不需要覆盖所有 NPC。选择一类任务角色先灰度，开关按场景或任务配置，而不是散落在脚本里。上线后观察拒绝率、超时和人工兜底次数；数字异常时先回到固定场景复现，再判断是提示输入变化、规则遗漏还是服务不稳定。能关闭、能还原、能解释，才算完成交付。

留下可接手的记录

记录本次使用的版本、配置、样本范围和已知限制。这样下次调整时，可以先复核假设，而不是从一段看似正常的结果里猜当时的取舍。

智能角色功能的交付验收