命令应按使用场景分组而非按开发模块分组
别名: 按任务分组菜单 · 模块式菜单 · command grouping
概念解释
人打开菜单是在问「我现在要做的这件事在哪」，不是在问「这段代码属于哪个包」。按使用场景分组（task-based menu grouping）把命令放进用户正在进行的活动：改稿、看版面、导出、协作；按开发模块分组把同一批命令按 SyncService、Renderer、Billing 切开。后者在仓库里干净，在菜单栏上等于把组织架构图贴到了用户脸上。菜单栏要提供一份完整清单是另一件事；这里只谈清单内部怎么切组。
机制
查找命令是一次带预期标签的搜索：人先有一个任务名，再去顶栏找最像那个任务的词。场景名（文件、编辑、视图、分享）和任务名共享词汇，第一跳经常命中。模块名是实现边界，与任务名的重叠是偶然的——「把这段发给同事」可能拆在网络层、权限层和编辑器层，三处菜单里各有半截。分错组的代价不是「多点一次」，而是第一跳进错顶栏项之后，人会以为功能不存在，转去设置或搜索引擎。场景也会重叠（打印既像文件又像视图），所以分组依据应是「发起这件事时人怎么称呼它」，而不是「哪边的类拥有这个方法」。
怎么研究
用卡片分类：把命令名写在卡片上，不给模块名，让目标用户分成他们会去找的几堆，再对比现有菜单切分。也可以做查找任务：给定任务口述，记录第一击点了哪个顶栏项。
自变量：分组依据（场景 / 对象 / 开发模块）、顶栏项命名是否来自用户词汇、命令是否跨模块才能完成。 因变量：首次命中正确顶栏项的比例、错误第一跳之后的放弃、完成时间、主观「在不该出现的地方」。
开发者当被试会把模块分组判为合理，这测的是实现模型，不是使用模型。分类结果还依赖被试是否见过旧菜单——长期用户会按记忆重画现有结构，要用没见过该产品的人，或把命令改写成任务句再分。
边界
极小工具只有一个顶栏项时，分组问题退化成排序。专家用户会记住坐标（「第三个菜单的倒数第二项」），错误分组对他们是效率税，不一定是发现失败。插件把第三方命令整组塞进「工具」或自建顶栏项，场景分组会被打破，这是可发现性与可扩展性的对冲。对象主导的应用（选中图形再改属性）按对象分组有时比按场景更贴，前提是对象类型对用户可见。
怎么落地
- 用目标用户的任务名做顶栏项和分隔线，不要用代码包名、服务名、团队名。
- 一条命令跨两个场景时，放在人更常发起它的那一组，另一处用指向或重复项，不要各放半截。
- 新增命令先问「用户会把它叫做哪一类事」，再入库；禁止「先挂在开发该功能的那个菜单下」。
- 验证：写下十条真实任务，遮住界面只留顶栏词，问没参加过开发的人会点哪一项。第一跳错的任务，就是切组按了模块而不是场景。再打开工程目录对照：菜单结构若能在包图上叠合，通常已经偏了。