第112章　游戏内交易：确认对象、数量与结果

先把交易说成一笔具体的事

一笔可核对的约定应有物品名称、数量单位、付款或交换内容、交付方式与双方游戏标识。可以写“我用自己确认的这份材料，交换你明确同意的另一份材料”，再补上实际数量。不要只凭一句给你一组作完整交易；组的单位和物品类型没有对齐，后来争议就很难只靠各自记忆解决。

商店界面与玩家交易分开

在/shop或/sellgui等实际可用界面中，核对显示的是买入还是卖出、数量如何选择和当前价格。玩家之间议价则以双方明确约定为准。服务器商店标价不自动决定所有玩家报价，也不证明所有材料都能收购。第一次使用不熟悉的出售入口时，先读范围说明，避免把想保留的物品一并处理。

/sellall尤其先看作用范围

原表说明/sellall涉及出售背包、手持或指定物品，完整分支与配置没有提供。不能把它当成只卖掉某件杂物的无风险按钮，也不能凭名称直接确认本服会出售哪些物品。需要使用时先阅读实际帮助，整理自己要保留的物品，确认作用范围后再决定是否操作。这里没有新增一段未经本服核验的出售参数。

转账前的两次核对

清单列有/pay和/balance等入口。先核对对方完整游戏标识与实际约定，再核对当前界面或帮助要求的数额与参数。不要用群备注替代游戏对象；也不要在断线前后的结果不明时立刻重复付款。已付款的反馈和实际余额变化应能互相核对，差异留给相关者与管理调查，不靠连续重试填平。

一个完整但不设固定价格的例子

假设两人约定交换一批石料与一批木材。甲先说明确切品类、数量及交付位置，乙确认自己理解相同，再各自准备属于自己的材料。完成后双方确认收到的是约定物品，并说明是否还有未交部分。这里没有假定某种货币或统一价格；例子的重点是让交易在开始、交付和收尾三个阶段都能被另一人理解。

出错以后保留什么

保留约定消息、实际交付对象、时间、界面反馈和还能核对的余额记录。涉及物品就补位置与数量，涉及支付就补接收标识。发现可疑错误先暂停后续交易，不公开辱骂相似昵称的其他玩家。管理拥有何种记录和能否纠正结果，需要根据本次实际条件决定，不能把安装经济插件当成全额找回保证。