为联机故障设计表单时，“单机正常，联机超时”是一个需要保留的现象，不能直接变成“网络故障”。如果让用户先选宽带、服务器或客户端责任，后续处理就可能围绕未经核实的结论展开。
这篇文章讨论一个更小的设计目标：让下一位接手的人知道尝试了哪个入口、观察到什么、改变了哪些条件，以及还差哪项证据。下面的字段和判定表是工单设计建议，不是已经上线的软件或游戏实测结果。
最小字段记录观察，不强迫填写原因
幻兽帕鲁官方说明中，专用服有 IP 与端口加入方式，社区服有列表入口。入口不同，目标信息也不同；不能把两种尝试都压成一个“点了联机”字段。Palworld 官方连接说明
可以先收集六组信息，再根据证据整理处理状态：
| 字段组 | 最少记录什么 | 设计取舍 |
|---|---|---|
| 入口 | 朋友世界、地址加入、社区列表，或未知 | 允许未知，不把它默认为某种入口 |
| 目标 | 世界或服务器代号；地址加入时，受权限控制的目标地址与端口 | 公开交接用代号；定位所需信息与公开展示分开 |
| 环境 | 游戏版本、网络类型；不知道的项目如实标未知 | 不收密码、管理凭据、玩家实名或无关设备标识 |
| 观察记录 | 时间、记录来源、失败阶段、报错原文或实际加入结果 | 记录来源用玩家、服主等角色；原文公开前检查敏感内容 |
| 变化清单 | 相比上次，哪些条件改变、哪些保持不变、哪些未确认 | 多项变化照实列出，不强制选出一个“有效改动” |
| 下一步 | 待核条件、负责角色、需要补回的结果 | 分配检查责任，不提前认定故障责任 |
未知也应有明确含义：未询问、对方不知道、尚未核对，不能被当作“正常”或“没有问题”。入口、目标或观察时间缺失时，工单仍可保存，但应标待补信息，暂不把它作为可比较的一次连接结果。原始报错也要保留，不能用这个状态覆盖用户的描述。
服务端信息由有权限的人补充。官方参数中，-port 控制实际监听端口，-publicport 是社区服对外端口声明，后者不会改变实际监听端口。因此，“实际监听”与“对外声明”应分开记录，分别允许未知，不能共用一个已确认标记。Palworld 官方启动参数说明
玩家不需要为了提交工单而获得服务器管理密码。本文也不提供未经验证的端口变更命令。
处理状态与验证结果分开
处理状态回答“下一步做什么”，验证结果回答“实际观察到了什么”。两者不适合塞进同一个“已解决”字段。例如，客服已经回复，工单可以转给玩家复测，但连接恢复仍然没有证据。
处理状态可以使用“待补信息、待服主核对、待玩家复测、待继续定位”。验证结果单独保留“未取得复测结果、本次可加入、本次未能加入、本次加入后中断”，并绑定目标、入口、时间和记录来源。原因假设另行记录依据，不由这些状态自动生成。
下表中生成某次连接观察结果的行，以目标、入口、时间和记录来源齐全为前提。条件不足时先补信息，不据不完整记录生成验证结论，也不覆盖已有结果。
| 新收到的证据或事件 | 处理状态怎样变 | 验证结果怎样变 |
|---|---|---|
| 入口、目标或观察时间仍缺失 | 待补信息 | 不生成可比较的结果；保留原始描述 |
| 客服回复，尚无新的连接观察 | 按回复中可执行的下一步移交；没有明确下一步则继续补信息 | 保留原结果，不改成恢复 |
| 服主仍未核对监听或访问条件 | 待服主核对 | 不因机器开机而改成可加入 |
| 目标和入口明确，玩家提供一次进入世界的记录 | 如仍需观察或排查，继续安排下一步 | 只记本次可加入，不记稳定游玩 |
| 明确目标的一次尝试未进入世界 | 按尚未确认的条件分配下一步 | 记本次未能加入，不自动归因宽带或服务器 |
| 已进入世界，随后观察到中断 | 待继续定位，并收集中断时的上下文 | 记本次加入后中断，不改写成从未加入 |
这里没有从“收到回复”直接跳到“连接恢复”的转换，也没有从“服务器开机”跳到“玩家可加入”的转换。需要核对的是事件携带的证据，而不是按钮名称或某个参与者说“已处理”。
结果可以记录，原因仍可能未知
变化清单解决的是比较范围。如果目标、客户端版本和其他条件都可对照，单项变化前后的结果可以提供继续排查的线索；它仍不能自动证明某项变化是唯一原因。
同时改变网络和客户端版本后成功加入，验证结果可以如实记为本次可加入，但原因不能填成“换网络修复”。其他条件未确认时也应保留这项未知，不能把未记录的变化当成不存在。没有稳定差异，就继续保留未定位，不为完成工单强行选择一个原因。
多人同期失败可以先请服主核对共同目标，单人失败可以先收集该玩家环境。这只是检查顺序；多人可能共享其他条件，单人失败也不能排除服务端访问条件。
用虚构记录检查判定是否自洽
下表全部是虚构示例，用于复核上面的设计约束。服务器 A 是代号，不包含真实地址；这些时间和结果没有发生过，也不证明任何改动对游戏有效。B—E 假定工单已明确用地址加入服务器 A，并已注明记录来源；表内只列新增信息。其他未记录的条件仍是未知，不能用省略项证明前后相同。
| 虚构输入 | 应保留的结果 | 不应生成的结论 |
|---|---|---|
| A：报告超时，但入口未知、发生时间未提供 | 原始超时描述保留；待补信息 | 默认地址加入，或宽带故障 |
| B：客服说已处理；玩家尚未再连接服务器 A | 有明确下一步才移交；否则补问下一步，验证结果不变 | 连接已经恢复 |
| C：14:10 同时更换网络和客户端版本，进入服务器 A | 本次可加入；变化清单保留两项 | 换网络是唯一有效原因 |
| D：14:20 只改变一项玩家侧条件，成功加入一次，没有后续游玩记录 | 本次可加入；只覆盖这次观察 | 稳定游玩，或该变化必然有效 |
| E：14:30 已进入服务器 A，14:35 中断 | 本次加入后中断；继续收集上下文 | 从未连接成功，或已经定位断线原因 |
实现表单或后台时，可以把这些行作为输入与预期行为逐项核对：缺失信息是否被默认为正常，回复是否误触发恢复，多项变化是否仍被强行单因归因，成功范围是否被扩大，中断是否覆盖掉之前的加入记录。本文没有实现或运行这套校验程序，不能把示例表称为已通过的软件测试。
这份工单设计追求的是证据可交接：保存原始观察，限定验证范围，再分配下一步。它不替代服主的实际监听与访问条件核查，也不替代玩家复测；未知原因可以保留到取得足够证据为止。
本文由 AI 根据文中官方资料起草，并由 AI 复核事实边界与内容；未进行实机联机或加速效果验证。
