症状
Creep 不移动
Creep 看起来停在原地时，先区分命令没有被接受、没有可用路径、fatigue 阻塞，还是目标与距离逻辑有问题。
快速排查
- 保存 moveTo() 或原始动作的真实返回值，不要只观察坐标有没有变化。
- 检查 creep.fatigue、目标对象与目标房间是否仍然有效。
- 如果返回 ERR_NO_PATH，继续检查地形、出口、CostMatrix 与 callback 约束。
- 下一 tick 再核对位置和返回值，确认这是持续故障还是单 tick 状态。
SCREEPS DIAGNOSTIC CENTER
先说“哪里不对”，再定位错误码
这里不是另一份错误码字典。它从你能直接观察到的症状开始，把排查过程连接到真实返回值、API、对象 Hub、专题教程、浏览器本地工具与已接受的 Runtime Verification。
SYMPTOM-FIRST DIAGNOSTICS
从你在房间里看到的现象开始
不需要先记住错误码。先选择可见症状，执行快速排查，再进入最相关的返回码、API、专题教程、工具与已接受 Runtime Verification；次要关系按需展开。
症状
Creep 不采集资源
harvest() 没有效果时，优先确认返回码、目标类型、距离、WORK 部件与资源是否可采，而不是直接重写角色逻辑。
快速排查
- 保存 creep.harvest(target) 返回值并确认 target 不是失效缓存。
- 检查目标是否为该 API 支持的可采集对象，以及资源是否仍然存在。
- 检查 Creep 是否有可用 WORK 部件并满足动作距离。
- 动作返回 OK 后，在后续 tick 核对 Store、Source 或 Mineral 状态是否变化。
最可能的返回码
主要 API
主要对象 Hub
更多相关对象 Hub
专题教程
实用工具
症状
Spawn 不生产 Creep
Spawn 队列没有产出时，先判断是 busy、Energy、body/name 参数还是 RCL 能力边界，不要把所有失败都归因于队列。
快速排查
- 保存 spawn.spawnCreep() 的 dryRun 与正式返回值。
- 检查 spawn.spawning、房间可用 Energy、body 成本和 body 长度。
- 确认 Creep 名称没有冲突，Memory 与 opts 参数结构有效。
- 如果涉及结构或 body 能力，核对当前 Controller RCL 是否满足要求。
最可能的返回码
主要 API
主要对象 Hub
更多相关对象 Hub
专题教程
实用工具
症状
Controller 快降级或升级异常
Controller 风险通常不是单一 API 问题，需要把 ticksToDowngrade、Upgrader 能量、距离、运输与实际升级返回值放在同一条诊断链里。
快速排查
- 先读取 controller.ticksToDowngrade，并确认风险是否真实存在。
- 保存 creep.upgradeController(controller) 返回值，检查 Upgrader 是否有 Energy。
- 检查 Upgrader 到 Controller 的距离以及上游 Container/Link/运输是否持续供能。
- 跨多个 tick 核对 upgrade progress、能量流和 ticksToDowngrade 是否朝安全方向变化。
最可能的返回码
主要 API
主要对象 Hub
专题教程
实用工具
症状
Link 不传能量
Link 没有传能时，把 cooldown、发送方库存、接收方容量、目标对象和实际 transferEnergy() 返回值一起检查。
快速排查
- 保存 link.transferEnergy(target, amount) 的真实返回值。
- 检查发送 Link 的 Energy、cooldown 与目标 Link 的 free capacity。
- 确认 target 仍然是同房间内预期的 Link，而不是失效 ID 或错误对象。
- 下一 tick 核对两端 Store 与 cooldown，确认动作是否真正产生状态变化。
最可能的返回码
更多可能的返回码
主要 API
主要对象 Hub
更多相关对象 Hub
专题教程
实用工具
症状
Market 交易失败
Market deal/createOrder 失败时，需要同时检查订单参数、Credits、资源、Terminal 与交易 Energy 成本，不能只看目标价格。
快速排查
- 保存 Game.market.deal() 或 createOrder() 的真实返回值与关键参数。
- 检查订单是否仍有效、amount 是否合理、房间名和资源类型是否正确。
- 同时计算 Credits、Terminal 库存和交易 Energy 成本是否都满足。
- 失败条件变化后再重试，并确认新返回值是否进入不同分支。
最可能的返回码
症状
CPU 使用过高
CPU 过高通常没有单一错误码。先测量实际热点、bucket 与 tick 负载，再决定是减少扫描、缓存结果还是拆分跨 tick 工作。
快速排查
- 用 Game.cpu.getUsed() 在关键代码段前后测量，而不是只看整 tick 总量。
- 同时记录 bucket 与不同房间/角色/管理器的工作规模。
- 优先排查每 tick 全量扫描、重复寻路、重复排序和可缓存计算。
- 修改后跨多个 tick 比较 CPU 与 bucket 趋势，避免用单 tick 样本下结论。
最可能的返回码
这个症状没有单一返回码可以定义，应直接测量运行时状态。
症状
资源运不过去
资源物流停滞时，要区分取出、携带、移动、转移和目标容量中的哪一段断了，并逐段保存返回值。
快速排查
- 分别保存 withdraw/pickup、moveTo 和 transfer 的返回值，不要用一个 role 状态概括整条链。
- 检查来源 Store、Creep free/used capacity 与目标 free capacity。
- 检查路径、fatigue、距离和目标对象是否仍有效。
- 跨多个 tick 核对来源、Creep、目标三处 Store，确认资源实际流向。
最可能的返回码
症状
Builder 不建造或不维修
build() 或 repair() 没有产生预期效果时，先检查真实返回值、目标类型、距离、WORK 部件、Creep Energy 与目标状态。
快速排查
- 分别保存 creep.build(target) 或 creep.repair(target) 的真实返回值。
- 确认 build 的目标仍是有效 Construction Site，repair 的目标仍是可维修结构。
- 检查 Creep 是否有可用 WORK、足够 Energy，并满足动作距离。
- 返回 OK 后在后续 tick 核对 Construction Site progress 或结构 hits，确认状态是否真实变化。
最可能的返回码
更多可能的返回码
主要 API
主要对象 Hub
更多相关对象 Hub
专题教程
实用工具
症状
Tower 不攻击、治疗或维修
Tower 没有产生预期动作时，先确认目标、Energy、所有权与真实动作返回值，再判断距离衰减和多塔输出是否满足预期。
快速排查
- 保存 tower.attack()、tower.heal() 或 tower.repair() 的真实返回值。
- 检查 Tower Energy、目标类型与目标是否仍存在，不要只看视觉效果。
- 需要比较输出时，再结合距离衰减与多个 Tower 的叠加效果。
- 返回 OK 后用目标 hits、事件日志或后续 tick 状态确认动作是否实际生效。