kaychung17/arknights-base-skill/ark-base-schedule

明日方舟基建布局与排班

本 Skill 使用“模型解释目标、脚本枚举与计算、求解器全局分配、模拟器复算、审计器检查”的混合流程。

强制执行门禁

以下规则优先于本 Skill 的其他流程：

1. 先检查输入完整性，再运行任何求解命令。 若关键输入缺失、互相矛盾或无法从用户文件中确定，先用一条集中问题列出缺失项，等待用户补充。此时不得生成排班、估算每日收益、套用布局模板或启动求解器。
2. 使用版本化基建默认值。 稳态项目默认按控制中枢 5 级、已清理区域、无人机上限 235、右侧四设施均 3 级且不可逆、宿舍按各自等级满氛围处理；解析结果在 _resolution.assumptions/source_map 记录默认来源。用户显式填写的账号值优先；声明 account_state.fully_cleared=false 时转为必填并校验实际值。禁止询问或设置单名干员每日固定工时上限；可工作时长由上线区间、技能心情消耗、宿舍床位与恢复、控制中枢恢复效果和重复日闭环共同决定。长期重复日采用 steady_state，当前心情、当前无人机库存和当前资源库存可以省略，求解器自行选择可闭环的循环相位；首日启动、有限周期和库存续航分析才读取这些账号快照。源石碎片与赤金默认以日净变化 0 为目标；balance_policy 必须显式区分 hard 与 soft。软目标使用带惩罚的短缺变量，输出实际短缺；已提供库存时再输出库存消耗速度和可维持天数。存在库存安全线时另写 hard_minimum。软目标低于目标时，候选仍可参与效率排序，模拟结果必须标记为 inventory_consuming_candidate；只有日净流量非负的方案才能标记为 sustainable_repeating_day。
3. 右侧设施等级是不可逆硬约束。 会客室、办公室、训练室和加工站各固定只有一间，默认均为 3 级，右满固定耗电 190。布局搜索只能调整可降级设施，不得降低右侧等级换取电力。右侧人员倾向仍需通过 right_side_schedule 提供。
4. 最终方案必须来自仓库完整入口。 使用 python arkbase.py run project.json --output-dir ... 运行布局搜索或固定排班。攻略模板、常用组合、手工效率排序和人工算术只能用于解释或对照，不能代替求解器输出。
5. 求解后必须验证输出。 只有同一次运行生成的 result.json、audit.json、coverage.json、summary.json 和 config.resolved.json，以及 result.json 中的逐区间模拟结果均完成检查后，才能提供最终排班和收益。
6. 执行失败时停止给结论。 环境检查失败、输入标准化失败、求解无可行解、电力不可行、模拟不可行、审计失败、关键技能数据缺失或运行产物不完整时，只报告失败阶段、错误信息和需要补充或修复的内容，不得改用手工方案填补。读取 solver-failure.json，区分 milp_infeasible、time_limit_no_incumbent、input_constraint_conflict、post_simulation_rejection_exhausted 和外层候选全部失败。时间限制且没有 incumbent 时先让完整入口自动运行缩减候选库可行性保底；禁止直接提高到长时限反复运行，也禁止执行弹性不可行诊断。只有 HiGHS 明确返回 infeasible 时报告约束族及 minimum_relaxation。
7. 所有数值必须可追溯。 最终回答中的无人机、电力、龙门币、赤金、源石碎片、合成玉、材料消耗和工时数字必须能够定位到本次运行的结构化输出字段。禁止把经验值或另一次运行的数字混入结果。
8. 叠加语义必须结构化。 生产相关“同种效果取最高”需要 effect_key 与 stacking；“特殊叠加规则”需要交互规则和优先级；只有确认属于同一技能槽的升级阶段才能归入同一 variant_group。不同名技能允许同时解锁时必须分别保留，并对跨技能联动整体建模；孑 E1 的摊贩经济与市井之道共同结算为“有效订单上限 × 4%”。缺失任一项时不得发布已验证排班。
9. 仅在用户明确要求粗略估算时允许脱离求解器。 此类输出必须标记为 manual_estimate，列出全部假设，并且不能称为排班结果、最优候选或已验证收益。
10. 长期排班必须显式安排宿舍。 逐区间给出每间宿舍的休息名单，限制每间最多 5 人，并证明每名工作干员的重复日心情闭环。禁止以每日重置为 24 心情、空宿舍名单或仅检查单日不红脸代替闭环。基础机制见 references/dormitory-scheduling.md。
11. 攻略图片只能提供候选结构。 颜色、百分比、主班/替班和“必须同时上班”标记需要先转成结构化 bundle 并逐名核对本地技能；用户上线节点之外的动态换班不得计入收益。图片整理规则见 references/user-guide-image-insights.md。
12. 借鉴外部工具时只迁移可验证机制。 跨班错峰组可用 110、101、011 工作模式表达；同主目标候选可比较最低班次收益和班次方差。MAA 自动填床、外部效率百分比和预算口径不能替代本地宿舍名单、技能数据和经济约束。规则见 references/maatool-principles.md。
13. 贸易订单必须按节点事件复算。 每次上线先收取已完成订单，正在生成订单保留剩余基础分钟；孑 E0 按当前已完成订单数逐单重算 4% × (订单上限 - 已完成订单数)，队列满后停产。队列数量与订单进度精确追踪，随机订单品质使用期望值并明确标记。无人机在节点内加速后立即收取，可连续生成订单，同时不得推进裁缝暖机。
14. 裁缝、效率清零和特殊订单保持独立层。 裁缝暖机绑定“干员 + 贸易站 + 工位”，换人或换位归零；采用有证据的 3h/5h 经验概率表，禁止线性相加到 100%。巫恋“低语”按其他工作干员每人 45% 计算，清零这些干员提供的订单效率，同时保留进驻基础效率、站外控制中枢加成、特殊订单和心情效果。特殊订单按逐订单条件和 佩佩 > 可露希尔 > U-Official > 但书 > 龙舌兰 优先级解析，一份订单只应用一种特殊订单。U-Official 固定 2 赤金且不视作违约，直接阻止同站但书触发；可露希尔固定 2 赤金特别订单，使同站龙舌兰失去原始 4 赤金加价对象；但书追加赤金后的订单仍是违约订单，不能触发龙舌兰。龙舌兰只给原始 4 赤金且非违约订单加价。候选生成排除 U-Official + 但书、可露希尔 + 龙舌兰 与 但书 + 龙舌兰 同站组合，分别保留可露希尔效率体系、但书体系和龙舌兰裁缝体系。
15. 中间产物按实时、非消耗转换。 一份感知信息可以同时转化为一份思维链环和一份无声共鸣；先汇总当前班次所有有效设施来源，再分别派生下游计数。按技能文字逐级取整，例如黑键 E2 为 floor(无声共鸣 / 2)%。宿舍人数、办公室等级和进驻干员变化后立即重算，禁止把中间产物跨班累计或在多条转换链间扣减。
16. 全局资源按班次快照重算。 热情值、人间烟火和木天蓼只读取当班实际在岗与宿舍占用；换班后立即重算，不跨班累计。晨曦生成的虚拟发电站只进入“自动化”技能的设施计数，不增加供电、无人机恢复或真实作业平台数量。
17. 条件技能读取实际房间状态。 “同站”“进驻控制中枢”“进驻发电站”和“进驻岁干员的设施”等条件只读取当前区间的实际进驻表；阵容拥有状态不满足进驻条件。按设施计数的技能需保留独立贡献层，以执行自动化·α的清除例外。仓库容量转生产力读取每名干员最终容量增量；大就是好！覆盖回收利用。
18. 会客室和办公室倾向必须先确认并写入求解输入。 在排班求解前询问用户是否指定会客室线索倾向、固定双人组合、轮换顺序，以及办公室固定人员或轮换人员；将答案按班次写入项目根字段 right_side_schedule。右侧人员必须进入同班互斥、全局联动、心情消耗和宿舍恢复计算。最终 schedule.json 的 meeting/hire 只能由结构化求解结果导出，禁止导出后补写。
19. 每次上线只能选择一个无人机加速房间。 同一节点的全部无人机分配必须落在同一个 room_id，可以在该房间内连续加速、收取并继续加速。求解器需约束每节点至多一个目标，导出器发现同节点多目标时必须拒绝生成；禁止用班次说明文字补写模板无法执行的第二个目标。
20. 默认每次上线用完当前可用无人机。 每个操作节点的投放量必须清空节点库存，连续恢复模型仅允许小于 1 架的舍入余量；全天总使用量等于总恢复量仍需通过逐节点清空检查。
21. 最终排班禁止审计后人工修改。 schedule.json 必须与同次运行的 result.json 确定性导出结果逐值一致，并通过 run-manifest.json 哈希检查。会客室、办公室、宿舍或生产房间发生任何改动时，旧验证立即失效，必须重新运行求解、模拟、导出和验证链。
22. 授予型效果不得扁平化为成员个人技能。 由控制中枢或其他干员授予的效果必须保留授予者、实际进驻条件、目标分组、计数设施、上限和特殊叠加规则，并用 granted_effect_skill_names 登记游戏内效果别名。成员数据不得重复携带这些别名的独立 base_bonus_pct。发布前还要扫描同一干员多个技能槽中的单例联动标签，防止旧占位记录与正式技能同时生效。
23. 跨房间联动使用组合包保护候选。 将攻略组合先记为 discovery_only，核对完整公式、设施条件、技能阶段和叠加规则后再升为 verified_formula。候选生成器只保护已验证组合包的必选成员、备选成员和分组成员，并保留满足同房间成员条件的完整组合；组合包不强制入选，最终仍按硬约束和完整模拟资源流排序。组合包数据见 assets/synergy-bundles.json。
24. 被覆盖技能必须计算全局机会成本。 特殊订单优先级或效率清零导致高价值技能失效时，记录 effect_resolution，保留同收益占位替代候选。求解后先释放被覆盖干员，再尝试其他房间和班次的全日反事实重排；每次变化重新检查互斥、工时、宿舍、无人机和经济流。发布产物必须包含 opportunity_cost_postprocess，剩余风险需要明确受候选截断或目标权重限制。
25. 每个结构化 tag 必须登记消费者。 scripts/tag_registry.py 是统一注册表；生产、订单、心情、资源或求解控制 tag 必须声明运行模块与语义角色。validate_data.py 遇到未注册 tag、重叠注册或缺少消费者时阻止发布。导入技能后必须先重建资产，再通过该门禁。
26. 自动化按技能阶段和独立贡献层计算。 异客、森蚺、温蒂分别读取已解锁同槽最高阶段的每发电站 5%/10%/15%；自动化清零同站其他干员的生产力贡献，设施数量贡献继续保留。森蚺与 Lancet-2 的虚拟发电站只服务自动化计数。温蒂“自动化·β/仿生海龙”和锏“威压/不怒自威”属于已核对的同槽替换。
27. 上线时刻优化必须实际求解全部保留候选。 online_schedule.mode=optimize 时，逐组建立 24 小时区间并完整运行布局、MILP 和模拟；按模拟后的等价龙门币效用选择，输出 online_time_search.evaluated 与失败候选。全局网格结束后按预算逐级细化到 1 分钟；max_candidates 与 refinement_max_candidates 是明确搜索上限，达到上限时不得声称时间域全局最优。
28. 产品可在操作节点切换。 布局搜索默认开启 search.allow_product_switching；制造站可在赤金、经验、碎片间选择，贸易站可在龙门币与合成玉订单间选择。每个班次的产品来自所选组合，资源平衡与无人机档案按该产品计算；贸易产品切换会重置原产品订单队列。
29. 截断候选库需要自适应扩张。 任一房间截断时，求解器按配置扩大 top_k 与干员池，直到候选完整、规模稳定或达到轮数/规模上限。控制中枢全局贸易和制造效果需要折算为下游代理收益参与 MILP；最终选择继续使用完整模拟复算。
30. 随机订单与日内库存同时报告均值和风险。 订单分布传播龙门币、赤金、耗时方差和协方差；库存按上线节点即时无人机操作、区间末自然产出收取生成事件线，报告最低库存、爆单区间和已知库存下的正态近似断供概率。设置 search.random_order_trials 后，以固定种子逐单抽样，随机耗时会改变完成单数、爆单与库存，并输出分位数、断供频率和样本订单序列。当前进行中的订单未知时从期望队列起算。

31a. 明确搓玉必须保留碎片制造链。 当目标或配置明确要求合成玉/源石碎片贸易时，产品分配至少保留 1 座源石碎片制造站；max_shard_factories=0 在该场景直接触发预检冲突。只有显式允许不生产合成玉时，才允许枚举 0 座碎片制造站。源石碎片软平衡不能覆盖这条生产链存在性约束。

1. 固定加成必须有无条件文字证据。 base_bonus_pct 只保存技能文字中不依赖其他干员、设施、库存、时长或中间产物的直接百分比。条件收益进入 tag、effect、mechanism 或 special rule；导入合并不得用旧资产的非零数值覆盖全量技能表解析出的零值。validate_data.py 出现固定加成证据冲突时停止求解。
2. 关键跨设施联动进入联合选择模型。 控制中枢组合与贸易站、制造站、发电站组合先按同时进驻状态复算，再按相同收益差压缩为 cross_facility_interaction 二元变量；收益差进入目标、资源平衡与无人机恢复，订单上限差保留在交互状态和逐节点队列复算。尚未生成交互状态的跨设施机制继续标记为模拟边界。
3. 多布局搜索使用筛选后精炼。 每个布局先以 top_k≤6、operator_pool_size≤8、单代理候选和最多4秒完成可行性筛选，按完整模拟效用选择第一名，再只对第一名构造用户请求规模的候选库。精炼失败时保留通过全部硬约束与模拟的筛选解，写入 verified_screening_fallback 和失败诊断；禁止让每个布局都构造大型候选模型后再比较。
4. 求解后由大模型完成语义审阅。 脚本只输出当前排班的结构化事实、技能生效证据、空闲干员清单和经过完整模拟的反事实候选；大模型判断干员搭配是否合理、是否存在机会成本和正收益空位，并提出纠正动作。每个纠正动作必须交回脚本复算，通过硬约束、资源、心情、宿舍和无人机检查后才能接受。详见 references/llm-postsolve-audit.md。
5. 挂件位参与全局分配。 根据技能的实际进驻条件，比较加工站、空闲训练室、回收站和宿舍空位。加工站及空闲训练室按零持续心情消耗计算，回收站按工作设施计算，宿舍挂件占用真实床位并恢复心情；活动室排除。候选联动收益进入 MILP，求解后还尝试“迁移挂件＋替换原生产队伍”的联合动作，接受前复算全日目标和硬约束。训练室默认开放协助位；base_state.training_room_trainees 记录已确认满足精二及未满专精条件的训练位人选，training_room_active=true 关闭训练室自动挂件位。搜索边界与导出字段见 references/support-slots.md。

决策职责

大模型负责：

• 把用户自然语言转换为明确目标和硬约束。
• 核对建筑状态、上线时间、无人机容量和可接受亏损；仅在首日、有限周期或续航分析中核对账号当前库存。
• 在机制可能更新时检索当前来源，并将采用的规则转为结构化证据。
• 选择布局搜索、固定排班或培养搜索模式。
• 比较攻略基线、求解器候选和不同经济档位。
• 解释偏离攻略的原因、收益和风险。

脚本负责：

• 绑定用户实际拥有情况、精英化和等级。
• 排除没有本地版本化数据或已验证外部证据的生产技能。
• 枚举合法单房间组合。
• 处理房间容量、同一时间干员互斥、心情循环和资源下限。
• 对同组/大组候选保持成套进出，避免把组合技能拆成独立干员排序。
• 建模无人机恢复、库存、节点使用、溢出和重复日闭环。
• 复算全局联动、仓库、经济与保守心情。
• 按操作节点分配宿舍床位，使用实际工作消耗与宿舍基础恢复验证逐干员重复日心情。
• 记录候选库截断、MILP 状态、gap 和时间限制 incumbent。
• 自动扩大截断候选库，并记录每轮规模与停止原因。
• 复算候选连续失败时增加代理尝试，并在候选库截断时触发后置扩张；保留每次拒绝的真实约束违规。
• 主模型不可行时执行按约束族的弹性诊断，只报告最小放宽量，不自动修改用户约束。
• 完整模型超时且没有 incumbent 时自动缩小候选库求可行排班；保底候选仍通过完整模拟，并记录原模型规模、缩减参数和受限最优性声明。
• 对可切换产品逐班建模，按节点生成日内库存事件线与随机订单二阶矩。
• 拒绝最终模拟违反硬约束的候选。
• 生成求解后审阅所需的结构化证据：房间搭配、技能生效/覆盖、空闲干员、空座位、局部替换和跨房间交换候选，以及每个候选的完整模拟差值。
• 执行大模型提出的纠正动作，复算全日收益、资源、心情、宿舍、订单、无人机和硬约束；拒绝无法验证的动作。
• 生成可复现清单、审计结果和中文报告。

大模型在求解后负责：

• 审阅技能条件、特殊订单优先级、联动组合和干员机会成本。
• 判断空闲干员填入空座是否值得，判断低效率占位是否应被替换。
• 在反事实候选之间做全局取舍，并说明采用或放弃每个纠正动作的理由。
• 只提交结构化纠正请求，不直接编辑 schedule.json；每次修改都等待脚本复算结果。

攻略模板必须作为比较候选时使用，但不得成为搜索边界。

首选入口

必须使用项目配置运行完整流程；底层脚本仅用于调试和定位失败阶段：

python arkbase.py run project.json --output-dir output/my-project

输出必须包含：

• schedule.json：面向用户和 MAA 的独立排班文件，使用 description、planTimes、plans、title 及房间数组结构。
• result.json
• report.md
• audit.json
• coverage.json
• summary.json
• config.resolved.json

report.md 只用于阅读，result.json 只用于追溯。最终回答必须把 schedule.json 作为“排班表文件”直接交付。禁止把嵌套的 selected.plan、报告或结果总包称为最终排班表。

需要从已有结果补导时运行：

python scripts/export_schedule_template.py result.json \
  --template assets/template.json \
  --format maa \
  --output schedule.json

MAA 文件的房间键、产品英文值、无人机节点和每班字段以 MAA 排班格式为准；每个上线区间对应 plans 中的一班。需要仓库正式模板结构时使用 --format formal。

首次使用先运行：

python arkbase.py doctor

必要输入与询问规则

在运行前必须取得以下关键输入：

• 已拥有干员、精英化等级和当前等级，并确认用户文件中的近期变更已经写入。
• 求解模式：布局搜索、固定布局排班或培养搜索。
• 目标优先级及硬约束，例如合成玉优先和每日龙门币净变化下限。赤金与源石碎片默认目标为日净变化 0；询问用户采用硬底线或带短缺惩罚的软目标，并记录可接受的库存消耗方式。
• 贸易站、制造站、发电站、宿舍和右侧设施的实际等级；右侧四项需要用户明确确认等级而不是房间数量，固定排班还需要逐房间产品配置。
• 会客室安排偏好：缺失线索优先、指定派系倾向、固定双人组、按班轮换或明确交由求解器优化；办公室安排偏好：固定干员、轮换名单或明确交由求解器优化。需要按当前练度核对实际解锁技能，会客室最多 2 人、办公室最多 1 人。
• 每天可操作的上线次数。上线时刻可固定，也可由 objective.online_schedule.mode=optimize 搜索；上线次数是操作节点，不自动等分成班次。
• 无人机持有上限。持有上限来自基建区域清理进度；发电站数量和等级不决定持有上限。steady_state 不询问当前无人机库存，首日启动或 finite_days 才需要首节点库存。
• 长期稳态只需要资源日净变化目标。当前龙门币、赤金、源石碎片、固源岩库存仅用于首日执行、有限周期和库存续航分析；用户明确要求这类分析时再询问库存、期限和安全线。
• 是否需要经验书，以及允许存在的产品线。
• 宿舍等级与氛围，以及是否启用菲亚梅塔；长期稳态的工作时长由心情闭环求出。
• 回收站是否建造及当前等级（0 表示未建造）；记录到 base_state.recycle_station.level。等级不可降级，独立舱室不占九宫格、不耗电。默认免费运转；材料转化为独立产出，用户明确给出材料估值后才参与经济比较。转化提效所需的材料投入须显式确认。
• 求解长期重复日时所采用的心情口径、宿舍等级与氛围、菲亚梅塔状态。steady_state 从宿舍和工作消耗求循环心情起点，并将该起点回灌心情阈值技能复算，不要求练度表包含“当前心情”列；首日或有限周期执行才读取当前心情。

输入检查分为三种状态：

• ready：关键输入完整，可以创建配置并运行仓库求解器。
• needs_input：存在缺失项。只向用户询问缺失信息，不执行求解，不输出候选排班或收益。
• conflict：用户输入互相矛盾。指出冲突字段并等待用户选择，不自行覆盖。

horizon.mode=steady_state 时写入 initial_state_policy=cyclic_phase_free。当前心情、base_state.initial_drone_stock 和 base_state.inventory 的缺失不形成 needs_input；仍需验证无人机日循环、逐干员心情循环、宿舍床位以及资源日净流量。finite_days 写入 initial_state_policy=account_snapshot_required，并要求首节点无人机、资源库存和执行起点心情。

询问时优先一次列出全部关键缺失项，避免逐项来回。用户只给出上线次数时，可以进入上线时刻优化模式，也可以继续询问是否固定时刻。用户只说“保留龙门币收益”时，必须继续询问可接受的每日龙门币净变化下限或库存安全线。右侧设施中的“1”只表示房间数量时，需要继续询问 Lv.1/Lv.2/Lv.3。会客室和办公室只给出设施等级时，仍需询问人员与线索倾向；用户明确表示不关注后，记录为 unimportant 并自动选择合法轮换。

“库存充足”允许把对应资源配置为软目标；仍需记录短缺惩罚和库存消耗速度。未获得放宽授权时，把 minimum_originium_shard_balance 与 minimum_pure_gold_balance 解析为硬目标 0。精确等于 0 受离散订单和生产批次影响，可出现小额结余。

用户同时看重合成玉和龙门币时，按机制常量 1 合成玉 = 160 龙门币 统一比较，即固定采用 20 合成玉 = 3200 龙门币；直接读取 mechanics.json/economy_constants，禁止询问用户、写入项目配置或允许覆盖该比例。objective.economic_values 只配置源石碎片与赤金短缺价格。允许资源小幅负平衡时使用 soft，并按补库存的机会成本设置 shortfall_penalty；最终候选按模拟得到的等价龙门币收益排序，平分时依次优先龙门币净收益、合成玉和经验。

对 08:00,14:00,20:00，区间是 6h、6h、12h。同一房间可以跨前两个区间保持同一队伍，14:00 可以只收取产物和订单；这属于求解器可选择的操作方式，不应预先固定为人工排班规则。

模式选择

布局搜索

用户询问“我的练度适合什么布局”时，布局必须作为决策变量。使用：

{
  "mode": "layout_search",
  "profiles": {"mode": "representative"}
}

representative 比较常见代表配置。需要更完整的房间等级搜索时使用：

{
  "profiles": {
    "mode": "level_grid",
    "layouts": ["252", "342", "333"],
    "max_profiles": 120
  }
}

level_grid 枚举选定布局的非递增房间等级多重集，先按电力过滤，再按结构优先级保留 profile。必须报告总可行 profile、实际求解数量和是否截断。

合成玉优先且要求长期经济可持续时，至少保留：

• 一座三级合成玉贸易站。
• 一座龙门币贸易站。
• 一条三级源石碎片线。
• 一条赤金线。

用户不需要经验书时，经验书产线必须为零。

固定排班

用户已经给定布局和建筑等级时，使用 fixed_schedule。不要用攻略建筑等级覆盖用户实际建筑。若建筑状态不完整，只能输出候选和缺失信息。

培养搜索

用户允许提高练度时，使用 upgrade_search：

1. 用相同经济约束求当前练度。
2. 求全部已拥有干员基建技能解锁上限。
3. 只保留上限候选实际使用的更高技能，生成定向最低解锁 roster。
4. 对孑、冬时和覆盖同站效率等非单调技能执行状态对照。
5. 可使用 marginal_limit 对前 N 项培养进行留一法复算。

培养建议只评价基建性能，不代表战斗培养优先级；未提供培养成本数据时不得声称投资回收最优。

标准底层流程

1. 校验数据

python scripts/validate_data.py

2. 标准化输入

python scripts/normalize_input.py \
  --roster roster.xlsx \
  --goal 赚钱+搓玉 \
  --layout 342 \
  --online-count 3 \
  --online-times 08:00,14:00,20:00 \
  --preferences preferences.json \
  --output decision-context.json

3. 枚举房间组合