C 端要它别问我，B 端要它每一步都能查

同一套 Agent 底座，要同时交付 C 端个人效率 App（免费，看次周留存）和 B 端企业版（按席位付费，要审计日志、权限隔离、流程可配置、可私有化）。研发只够维护一套核心链路加少量差异化层。

这道题看着像架构题，其实是产品决策题：哪些差异可以用配置吸收，哪些一旦让出去就会长成两套内核。答「做两套」或「全做成可配置」都不及格。

本系列第 10/10 篇 · 上一篇：两百份文档、日均八条反馈，飞轮从哪儿转起

五个维度，以及背后的原因

维度	C 端	B 端	为什么
能力边界	默认自主，事后可撤销	默认受控，按角色授权	个人错误自己承担且可撤销；企业错误外溢到同事和客户
交互形态	零设置、开箱即用，尽量不提问	管理员先配置工具白名单与流程，再给员工用	B 端的购买者和使用者不是同一个人
信任建立	靠前几次任务「真的办成了」	靠可审计、可回放、可解释责任归属	企业买的是可追责，不是惊喜
失败处理	轻量重试、一句话说明、悄悄兜底	明确标记失败、留痕、可转人工并带上下文	失败在组织里需要被复盘和归因
成功定义	次周留存、任务完成率	席位活跃、流程耗时下降、事故数为零	一端看用户愿不愿意回来，一端看流程能不能被写进制度

表里最容易被漏掉的是「购买者 ≠ 使用者」。C 端所有设计都在降低第一次使用的摩擦，B 端所有设计都要先让管理员敢签字上线——这两件事经常直接冲突，而不是程度差异。

共用底座与可配置层的判定原则

我的判据只有一句：改动是否影响事实正确性与副作用语义。

• 共用底座（不因客户而变）：检索与引用校验、工具执行与幂等、动作的可回滚实现、权限内核、副作用事件日志、安全与脱敏。这些一旦做成「每家不一样」，就会出现同一个动作在两家客户语义不同，回归测试再也写不出来。
• 可配置层：确认策略、可用工具白名单、留痕粒度与保留期、话术与品牌、SLA 档位、数据驻留位置、审批链。

延伸一条：能在不改运行时语义的前提下用配置表达的，才允许做成配置。比如「确认几次」是配置，「删除到底是硬删还是移入回收站」不是——后者改变了副作用语义，必须统一进底座（这也接回第 1 篇的分级表）。

这条原则的价值在半年后才看得出来：需求一多，最自然的动作是给每个大客户加一个开关；一年后开关互相组合，没人知道哪种组合被测过。把边界划在语义层，能挡住大半这类膨胀。

一个正面冲突：自主 vs 可审计

C 端要「别老问我，直接做完」；B 端要「每一步都能查，最好还能回滚」。第一版我们真的做了两套交互，结果底座里连动作记录都不一致，C 端出了事故查不回现场。

后来的决策是：统一在底座里，所有副作用动作都产生可回放的事件日志和状态快照；差异只放在呈现层——

• C 端不增加一次点击，把确认折叠成「执行后 10 秒内可撤销」的轻提示，日志用户看不见；
• B 端把同一份日志暴露成管理员的审计面板、按人/按动作的授权矩阵和回滚入口。

取舍依据是成本不对称：多记一条日志对 C 端几乎零成本，对 B 端是刚需。把差异放在「看不看得见、要不要点确认」，而不是「记不记录」，就只用一套内核满足了两端。被牺牲的一方也有补偿——C 端没有增加任何设置项和弹窗，撤销条还顺手降低了误操作的焦虑。

这类题我最想听的就是这一步：找到一个两端成本不对称的公共能力，把它沉到底座，把差异收敛到交互层。直接说「按客户定制」的，通常没维护过长期版本。

两端各一个最需要的功能

B 端管理员：动作白名单 + 审计回放。按角色、按动作、按数据范围授权，任何一次代执行都能回放「谁、依据哪条信息、做了什么、影响谁」。放到 C 端是负收益：一堆设置项摆在首次使用前面，转化当场就掉，而且个人用户根本没有「授权给谁」这个概念。

C 端用户：一句话撤销（以及因此带来的零设置开箱即用）。放到 B 端是负收益：绕过审批链、破坏责任归属，出事以后没法回答「这一步是谁批准的」。同一个功能在两端一个降摩擦、一个拆内控，这就是为什么它不能进共用层。

追问：私有化会让哪些假设失效

先列失效的假设：统一模型 API 与集中式密钥、集中日志与跨客户评测、云端缓存与统一身份、自动升级与热修复、按调用量结算的计费口径。

然后说清哪些东西要从「服务」改成「交付物」：

原服务	私有化后的交付物
云端评测与回归	评测集、标注规范、可离线跑的回归脚本
托管索引	索引构建/迁移工具、版本升级包
自动升级	变更说明、兼容性清单、回滚手册
统一监控	客户侧可自查的巡检项与运维手册

商业模式也跟着变：从订阅变成交付 + 维保，版本碎片会长期存在，所以「哪些能力必须共用底座」这条原则在私有化场景下更值钱——底座越统一，需要同时维护的历史版本越少。

我会怎么看答案

及格：列几个差异，说 B 端要权限、C 端要简单。良好：能给出共用/可配置的划分、能举出冲突例子并做取舍。优秀：给出可判定的划分原则（语义 vs 呈现）、找到成本不对称的公共能力沉到底座、说清每个功能为什么对另一端是负收益、并能把私有化答成交付物与商业模式的变化。

常见的失分是「都做成配置项，让客户自己选」。这句话把最贵的架构决策推给了最没上下文的人，和「让用户自己设置能力边界」是同一个毛病。

一套底座服务两端，靠的不是配置足够多，而是把不该配的东西坚决留在底座里。

---

十道题写完，我的判断口径其实只有一条，和这个系列开头那句一样：能不能在具体约束下做出取舍，并把代价说清楚由谁承担。技术深度不是知道多少种方案，是每个选择的代价；业务理解也不是会说商业词汇，是能把代价换算成对方在乎的东西。

面试里真正稀缺的，从来不是答案，是把模糊问题写成可验收条款的能力。