同一套业务能力，如何适应不同人的工作方式
装到平台上的会议、事务等模块，可以只提供业务能力和一套默认界面，由外层工作台按每个人的方式组织起来；也可以各自做成一个完整的应用。本文把这两种设计放进同样的场景里对照，说明各自的价值、代价和适用条件，以及我们的倾向。
也就是“轻模块、重工作台”。“每个模块是完整应用”的路线同样成立：它在单个模块内的深度操作上更有优势，责任边界也更清楚。
本文性质：方向建议，尚未批准为架构。文中场景、角色和界面都是说明性示例，不代表已上线功能，也不包含交付承诺。
时间紧可以只看：第 03 节两个场景、第 05 节我们的理由与改判条件、第 06 节需要你们一起做的事。
这几个词在内部讨论里常被混用。下文按这里的含义使用。
讨论两种设计时，最容易把下面三件事绑在一起。它们是三个独立的问题，只有第二个才是两种设计的主要分歧。
两种设计都不变的是：业务数据、权限校验和业务规则始终由模块负责。“轻”不等于把规则交给 AI 或工作台。
下面以会议和事务两个模块为例。两张图画的是职责，不是具体技术实现。
方案 A · 轻模块，重工作台
模块交付能力和默认视图，工作台把它们组织成每个人自己的工作方式。
会议模块提供会议与行动项的查询、新建、修改、删除，以及一套默认视图；事务模块同理。工作台根据使用者是谁、正在做什么，决定首页展示哪些信息、怎么排序、常用操作放在哪里，并在一件工作跨越多个模块时统一处理。
打开工作台，看到与自己相关的会议和事务；既可以直接用模块的默认视图，也可以用按自己习惯配置好的视图（可由 AI 助手草拟，用户确认后生效）。要改什么，既可以在界面上点，也可以对 AI 助手说。
方案 B · 重模块，完整应用
每个模块都是一个完整的应用，工作台负责入口与公共服务。
会议模块自己设计会议清单、会议详情、纪要编辑和页面内的对话流程；事务模块同样自成一体。模块团队对这块业务从数据、界面到对话体验整体负责，可以把专业流程打磨得很深。
从工作台进入会议模块，打开会议清单，点进某场会议，在会议页的对话框里对 AI 助手说“把第三条行动项改给李明”，改动当场标在纪要上。处理个人事务时，再进入事务模块。
一个场景偏向工作台，一个场景偏向完整模块。两个都看，才能看清各自的强项和要补的东西。下面是按示例配置做的设计推演，还没有经过用户实测。
“把本周会议里分配给我、还没完成的事项，和我的个人事务放在一起，按截止时间排好。”
方案 A 怎么做
前提：两个模块都开放了查询和修改，并把“负责人”“截止时间”等字段的含义说清楚；再接入第三个模块时，同样要先登记它的能力说明。
方案 B 怎么做
前提：有一方承担统一协调：模块之间直接对接，或由平台共用的汇总服务承担。后者不改变“用户主要在各模块里工作”这一点。
按这份示例配置，预计方案 A 更顺手。汇总与展示由同一层负责，合并后的清单就是用户的首页，还能按人调整。方案 B 也能做到，差别在于统一协调由谁承担（模块互相对接，或平台共用服务），以及合并清单放在哪个界面；两边接入新模块都要登记或适配。实际体验需要实测。
用户已打开“项目 A 需求讨论”这场会议“把第三条行动项改由李明负责，截止改到下周一，再在纪要里补一句风险说明。”
方案 A 怎么做
前提：会议模块开放足够细的能力（细到“改某条行动项的负责人”），并能提供当前会议的上下文。
方案 B 怎么做
前提：会议模块投入建设完整的编辑界面与对话流程；其他模块要有同等体验，需要各自建设界面与流程，对话与记忆可以共用平台服务。
按这份示例配置，预计方案 B 更顺手。单个模块内的深度操作是完整应用的主场；方案 A 要做到同等体验，依赖模块把能力开放得足够细，或在这一处保留专属界面。实际体验需要实测。
两个场景合起来说明：两种方案各有主场。哪种更适合我们，取决于用户更常遇到哪一类工作，以及专业操作能否用通用界面承接。上面两个“预计”都需要实测，这正是第 05 节的判断和第 06 节建议的对照验证要回答的问题。
灰底的行两种方案相同，不是选择题；其余各行把强项和代价写在一起。表中“通常”指常见做法，不是方案的定义。
| 比较维度 | 方案 A · 以工作台为中心 | 方案 B · 以完整模块为中心 |
|---|---|---|
| 业务数据、权限与规则 | 相同：由模块负责。工作台和 AI 助手都只能通过模块完成操作，不能绕过它的权限和规则。 | |
| 能力开放 | 必须开放，并附准确说明（字段含义、权限、限制、返回结果）。这是方案成立的基础。 | 可选。开放得越多，越容易和其他模块或平台组合。 |
| 用户日常在哪里工作 | 工作台首页与个人视图；需要时进入模块的默认视图或专属界面。 | 各模块的应用界面；工作台主要提供入口。 |
| 模块自带界面的角色 | 默认视图：保证装上就能用、能看懂；可以被工作台重新组织。 | 就是产品本身：模块团队完整设计、持续打磨。 |
| AI 助手与记忆 | 通常一个跟随用户的助手，记忆集中在工作台，按权限使用模块数据。 | 通常按模块组织对话，记忆贴近模块任务；可以共用平台的 AI 与记忆服务，跨模块的记忆需要按统一约定打通。 |
| 个性化由谁提供 | 工作台统一承担，包括把多个模块按人组织成首页；前提是工作台真的把这件事做好（见第 05 节）。 | 各模块提供配置项，可以基于平台共用的个性化服务；把多个模块按人组织成一个首页，需要另有一层承担。 |
| 跨模块工作 （统一协调由谁承担） | 工作台：统一理解需求、组织展示，合并结果直接进入个人首页。接入新模块要登记能力说明。 | 模块之间直接对接，或平台共用的协调服务；装在同一个工作台里不会自动具备。接入新模块同样要登记或适配。 |
| 单模块专业深度 | 通用界面在复杂操作上可能不如专属界面；需要允许保留例外。 | 强项：流程、界面、对话都为这块业务打磨。 |
| 责任与排障 | 一次体验横跨工作台和模块两层，出问题要先分清是哪一层。 | 一个模块团队端到端负责，边界清楚。 |
| 主要风险 | 工作台成为关键依赖：它做得不好，所有模块的体验一起受影响；前期要先建好能力说明、记忆和定制机制。 | 若各模块各自建设对话、记忆和个性化，会重复且难以一致；改用平台共用服务可以缓解，但要求各模块遵守同一套约定。 |
| 更适合 | 用户角色多、同一批能力要服务不同工作方式、跨模块工作常见。 | 模块少、单个模块流程复杂、用户长时间待在一个模块里。 |
真正的差别集中在蓝色标题的两行：用户日常在哪里工作，以及模块自带界面是“默认”还是“产品本身”。其余差别大多由这两点派生，或取决于具体实现怎么选。
这是方向建议，不是已批准的架构。下面写清三条理由、收益需要的前提，以及出现什么情况我们会改判。
以上是我们的判断，还没有经过验证；第 06 节的对照验证就是为了检验它们。
说明性示例，人物与数据均为虚构，不连接真实会议或事务。点击切换角色。
项目负责人的首页
按项目组织会议行动项，突出负责人、截止时间和进度。
执行同学的首页
把会议行动项和个人事务合成一张清单，按截止时间排列，保留来源。
会议组织者的首页
按时间组织会议，把会前准备和上次会议遗留的行动项放在一起。
方案 A 的收益，以工作台把下面五件事做好为前提。其中第 1 项和第 3 项的跨模块部分，是方案 A 要特别承担的职责；其余几项两种方案都需要，区别只在由工作台集中承接，还是由各模块与平台公共服务分别承接。
这些情况下，方案 B，或“以工作台为主、个别复杂操作保留模块专属界面”的组合，可能更合适。这件事不必是全局二选一，具体哪些操作保留专属界面，由验证结果决定。
不论最后偏向哪种方案，下面五项约定都要先定下来。我们希望读完本文的同事帮三个忙。
你们的业务里，有哪些操作用通用界面承接不了、必须由模块完整设计？这决定方案 A 需要保留多少例外。
如果你们负责或规划某个模块，请先回答下面五个问题；答案是“暂不开放”也有价值。
用会议＋事务这组场景，两种方式各做一版，用同样的任务比较结果。
模块提供哪些查询和操作？哪些允许工作台或 AI 助手调用？哪些必须进入专属界面完成？
数据由谁维护、权限由谁校验、规则由谁执行？汇总视图是否直接使用同一份数据，而不是另存一份？
哪些部分允许换视图、改布局、重新组合？哪些专业交互需要由模块保持完整？
工作台和模块各自记住什么？哪些信息在用户授权后可以共享，免得用户重复交代？
无论在界面上点击还是对 AI 助手说，操作都返回明确的成功、失败或待确认，并告诉用户下一步能做什么。
用同一套会议与事务能力，分别做“工作台统一组织”和“模块内完整体验”两个版本，让同一批用户完成第 03 节的两个场景，比较：
这是建议，尚未排期；参与方、时间和范围需要另行商定。
让模块专注可靠的业务能力，
让工作台承接不同人的工作方式。