如果想用自然语言生成一局轻量任务游戏第一版不要只写“生成一个漂亮的奇幻小镇让玩家送信”。小镇、道路、邮局和信封可以很快出现在画面里但它们不能自动组成一条可完成的任务。一个可验收的最小闭环应该是邮局接单→核对包裹→规划路线→送达地址→获得签收→返回邮局结算。本文固定一个小范围案例1 名邮差、5 个地址、6 个包裹、10 分钟时限以及 1 个邮局返航点。第一版不加入战斗、开放世界、随机城镇和多人配送先验证订单、取件、背包、地址校验、签收、失败恢复和重开能否稳定运行。图注邮票、信封与奇幻小镇可以建立投递任务设想但地址映射、背包状态、签收记录和返航结算仍需运行验证。这张素材不能证明角色可控制、道路可通行、包裹可拾取、地址可以交互、背包库存真实存在或任务能够完成。画面中的宣传文字也不是玩法证据。发布到 CSDN 时需要将本地图片上传至平台并替换为站内图片地址。第一条订单、地址、包裹和十分钟时限必须唯一第一步不是设计房屋外观而是固定系统需要识别的数据地址address_01至address_05包裹parcel_01至parcel_06邮局返航点depot_01总时限600 秒玩家1 名邮差。每个包裹只能绑定一个合法地址。5 个地址可以接收 6 个包裹但必须在订单表中明确哪一个地址接收两件不能根据房屋位置或画面颜色临时判断。订单表至少包含order_id | parcel_id | address_id | parcel_type | reward | order_stateHUD 显示当前订单、背包中的包裹、已签收数量、剩余时间和返航状态。重开或重载后地址与包裹编号不能改变否则系统无法稳定判断“送的是哪一件、送到了哪里”。建议状态game_state: ready → running → success / failed order_state: available → accepted → completed第二条接单和取件必须分开提交接单只创建任务关系不能直接把包裹放入背包。只有玩家在邮局对具体包裹完成取件操作后parcel_state才能变化。建议把包裹状态写成at_depot → in_inventory → delivered ↓ dropped → in_inventory ↓ lost / damaged → at_depot恢复后接单与取件分开有两个好处一是玩家可以先查看路线和容量再决定带哪些包裹二是发生取消、背包已满或加载失败时不会出现“订单已接但包裹凭空进入库存”的状态。每次取件都要有唯一请求编号。快速连按、长按交互键或重复回调只能产生一次有效状态变化。取件失败时包裹仍留在at_depot并显示明确原因例如“背包容量不足”或“该包裹已经被取走”。第三条背包容量和包裹状态要分别记录第一版背包最多容纳 3 个容量单位普通包裹占 1 格易碎包裹占 2 格。这里建议使用capacity_cost不要把它直接写成重量。容量和重量是两套不同规则一件体积很大的轻包裹可能占两格却并不重。如果第一版只验证背包格数就不要同时引入角色负重和移动速度惩罚。取件前计算current_capacity capacity_cost 3超过上限时拒绝取件不改变包裹状态也不创建半完成的库存记录。HUD 至少显示parcel_id | parcel_type | capacity_cost | parcel_state | current_location主动放下、意外遗失、重新取回和损坏都要有独立状态与事件不能简单从数组中删除模型。画面中看不见包裹不等于系统已经正确更新库存。第四条地址校验不能只看玩家站在哪里玩家来到某栋房屋门口并不代表当前包裹一定可以交付。一次合法投递至少同时满足四个条件当前包裹绑定的address_id与目标地址一致玩家进入规定的交互距离当前对象是该地址的合法接收对象玩家背包中真实存在这件包裹且状态为in_inventory。还可以根据玩法需要增加遮挡检查防止玩家隔着墙或楼层交付。地址不匹配时系统不能扣除包裹也不能创建完成事件应显示“地址不匹配”距离太远时显示“请靠近收件点”对象错误时显示“这不是当前订单的收件人”。错误原因越具体玩家越容易理解操作失败在哪里开发者也更容易区分地址映射、交互距离和库存数据问题。第五条签收和奖励只能结算一次每次合法签收创建唯一的delivery_event_id并记录delivery_event_id | run_id | parcel_id | address_id | delivered_at | reward_applied签收成功后包裹从in_inventory变为delivered订单进入completed奖励只绑定第一次有效签收事件。以下操作都不能重复领奖快速连续点击收件人离开地址后再次返回暂停再恢复卸载区域后重新加载重复发送同一个签收事件。如果包裹已经是delivered再次交互只能显示“该包裹已签收”不能重新创建事件或增加完成数量。签收动画、音效和奖励跳字只是反馈不是结算已经完成的证据最终要以状态和事件记录为准。第六条迷路、损坏和超时要有可恢复结果一局投递任务不仅要规定正确路线还要说明失败后如何继续。角色出界角色跌出场景或进入不可达区域时返回最近安全点。订单、背包和已签收记录按规则保留角色位置和移动速度恢复正常。不能把玩家送到尚未到达的地址也不能因此重复生成包裹。易碎包裹损坏易碎包裹受到规定的跌落或碰撞后进入damaged。玩家必须把损坏包裹带回depot_01或在系统回收后返回邮局领取替换件。更换一次扣除 60 秒并记录损坏与替换事件。损坏条件必须具体例如从超过设定高度跌落或受到超过阈值的碰撞。不要根据动画看起来“摔得很重”就直接判断损坏。超时600 秒归零后停止新的取件与投递操作进入失败状态并记录final_result timeout失败界面应显示未完成包裹、已完成数量和失败原因。玩家仍可查看日志或选择重开不能卡在输入锁定或半完成状态。第七条返航、暂停和重开必须统一管理6 个包裹全部签收并不等于任务已经完成。玩家还需要返回depot_01系统确认return_state returned后才进入胜利状态。胜利条件应同时满足delivered_count 6 return_state returned remaining_time 0暂停时统一冻结600 秒倒计时取件与签收交互进度损坏处理计时角色移动与任务状态推进。恢复后从暂停前的状态继续不能补执行暂停期间本应发生的事件。完整重开则要恢复订单状态6 个包裹的位置与状态背包容量和内容5 个地址的签收状态奖励与损坏记录600 秒倒计时玩家位置和返航状态成功、失败和临时提示。每次新局创建新的run_id。成功或失败只允许结算一次旧局的包裹、奖励和签收记录不能进入新局。可直接复制的提示词下面这段提示词的重点不是让 AI 自由补充更多内容而是让每条规则都能被检查。请生成一局单人奇幻邮差任务原型。第一版只验证投递闭环不加入战斗、开放世界、随机城镇或多人配送。 固定数据 - 玩家1名邮差 - 地址address_01 至 address_05共5个唯一地址 - 包裹parcel_01 至 parcel_06共6个唯一包裹 - 邮局与返航点depot_01 - 时限600秒 - 每个parcel_id只能绑定一个address_id - 背包容量上限为3格普通包裹占1格易碎包裹占2格。 请严格实现并逐项报告以下七条规则 1. 唯一编号与计时订单、地址、包裹和depot必须有唯一编号。HUD显示订单、背包内容、已签收数量、剩余时间和返航状态。 2. 接单与取件接单只创建订单玩家在邮局成功取件后parcel_state才从at_depot变为in_inventory。快速连按和重复请求不能重复生成包裹。 3. 背包容量取件前检查current_capacity capacity_cost 3。超出容量时拒绝取件并显示原因。放下、遗失、损坏和取回使用独立状态与事件。 4. 地址校验投递必须同时检查parcel绑定的address_id、交互距离、合法接收对象和背包中的包裹状态。地址错误、距离不足或对象错误时不扣包裹、不创建完成事件并显示具体原因。 5. 签收防重复每次合法签收创建唯一delivery_event_id。包裹进入delivered后重复点击、离开返回、暂停恢复或区域重载均不能重复签收或重复发奖。 6. 异常恢复角色出界后回到最近安全点易碎包裹满足规定的跌落或碰撞条件后进入damaged回depot_01更换并扣除60秒600秒结束时停止投递并显示具体失败原因。 7. 返航、暂停与重开只有6件包裹全部签收并且玩家返回depot_01才算胜利。暂停冻结倒计时、交互进度、损坏计时和角色状态。完整重开恢复订单、包裹、背包、地址、奖励、倒计时、玩家位置和返航状态。成功或失败只能结算一次。 请为每条规则输出具体数值、触发条件、玩家可见反馈、失败处理以及“已实现未实现待验证”标签。 同时输出 - 订单表 - parcel_state状态机 - 背包字段 - delivery_event字段 - run_id、parcel_id、address_id、inventory_state、delivery_event_id、remaining_time、return_state和final_result日志。 不要用小镇画面、投递动画或奖励特效证明库存、签收和返航逻辑已经成立。没有运行记录的功能必须标记为“待验证”。如果使用 3D Agent可以先搭建邮局、道路、地址牌和邮差角色再把上述规则作为功能约束输入。但场景原型不等于地址映射正确也不能证明背包、库存、签收和返航逻辑已经通过验收。三轮验收怎么做第一轮正确路线按订单取件规划路线依次送完 6 个包裹再返回depot_01。确认包裹全部签收时不会提前结算只有返航后才显示胜利。第二轮错误和异常分别测试送错地址、超出背包容量、重复签收、主动放下包裹、损坏易碎包裹和角色出界。确认错误投递不扣库存超容取件不会生成半完成记录重复签收不重复发奖损坏包裹可以回邮局更换出界后回到合法安全点。第三轮暂停、失败和重开分别在取件、送达、损坏处理和结算时暂停、失败或重开。检查倒计时和交互是否按规则冻结失败原因是否明确新局是否残留旧包裹、旧签收、旧奖励或旧弹窗。每轮至少记录run_id | parcel_id | address_id | parcel_state | inventory_state | delivery_event_id | remaining_time | return_state | final_result最终检查卡地址、包裹、订单和返航点编号唯一接单与取件分开一次取件只改变一次状态背包按容量单位判断超出上限时不产生半成品记录投递同时校验地址、距离、接收对象和背包状态每件包裹只能签收一次奖励不能重复领取出界、损坏和超时都有明确结果与恢复方式6 件包裹全部签收并返航后才胜利暂停冻结相关计时和状态重开恢复统一初始状态没有旧局残留。写奇幻邮差任务的提示词时真正需要描述的不是“小镇看起来多丰富”而是每件包裹从邮局到收件地址再回到结算系统的完整状态变化。编号、容量、校验、签收、异常恢复和返航都能被记录投递玩法才算形成闭环。你写投递任务提示词时更容易漏掉地址校验、背包容量还是重复签收