M2.13.2compound-command execution order设计研究
复合指令的执行顺序影响结果
别名: 指令顺序 · order sensitivity · 不可交换指令
概念解释
几件事挤在一句里时，先做哪件会改变世界。「先关灯再锁屏」若先锁，语音被关掉，灯就不再听指挥。「把空调设到二十六再关客厅灯」交换后结果相同。「发给妈妈然后把这条删掉」顺序就是内容。系统按技能注册表顺序、或并行全开，会办成用户没要的那个世界。这里谈的是已经识别出多件之后怎么排，不是有没有把多件听全。
机制
口语顺序常常是意图中的执行顺序（顺序象似性）：先说的先做。有的动作会关掉后面动作的通道（锁屏、关机、离家一键）；有的有语义前置（先注水再加热）；有的是社交脚本（先说发给谁，再说删草稿）。并行执行把这些依赖摊平。按内部优先级（安全技能总是先跑、媒体总是先跑）等于用产品目录覆盖用户的动词顺序。
确认若插在第一件之前等第二件也点头，第一件就被推迟，顺序同样被改。用户说「马上关灯，顺便设个闹钟」，灯的「马上」被确认轮吃掉。所以顺序不仅是执行器排队，也包括确认和追问插在哪一件前面。
怎么研究
构造成对指令：交换后世界不同的（顺序敏感）对交换后相同的（可交换）。看系统是否保持口语句序，以及用户把错误顺序感知成「没听懂」还是「听懂了但做错」。再画技能依赖图：哪些动作禁用语音、断电、改变权限。因变量是顺序敏感对上的结果一致率，以及系统重排时是否说出来。
日志里找含「先 / 再 / 然后」的句子，对照实际执行时间戳。实验室脚本不要把复合指令拆开逐句说，那测的就不是顺序问题。
边界
两盏灯、两个无关插座，交换无差别，默认可交换。用户说「顺便」时顺序被故意标成弱，系统可以先做主件。安全策略可以强制与口语相反的顺序（先开锁再撤防），但必须说出来，否则用户以为没做后一件。尚未识别出第二件时，谈顺序没有对象。跨好几轮才插入的新任务是挂起与恢复，不是一句里的排队。
怎么落地
- 默认按口语句序执行；只有依赖图要求时才重排。重排必须说：「要先开锁才能关灯，我改了顺序。」
- 列出会禁用后续技能的动作（锁、关机、飞行模式、离家），复合指令里若含它们，按口语把它们放在能放的最晚位置，或拒绝组合并说明为什么。
- 不要为了第二件去卡住第一件的执行：能先做的马上做，其余再确认。
- 验证：跑「关灯然后锁屏」与反过来各一次。先锁导致后一件失败的，要在失败里点明顺序，而不是只报「关灯失败」。用户明确说了「先 / 再」却被内部优先级打乱且不解释的，算缺陷。