核心论点：B端与C端的差异不在"AI不AI"，在谁承担agent出错的成本。
引言
AI产品的讨论中，一个常见的分类是"B端产品"和"C端产品"。但大部分讨论停留在用户群体层面------B端是企业用户，C端是个人用户。这个分类没有触及真正的分化机制。
本章要讲的是：B端和C端的根本差异不在用户是谁，而在谁承担agent出错的成本。这个差异决定了产品走两条完全不同的路线------B端走governance路线，C端走safety-by-design路线。
本书聚焦B端。C端只在必要的对比中提及。
风险承担者决定一切
当AI agent犯错时（输出错误、遗漏关键步骤、执行了不该执行的操作），谁来承担后果？
B端：企业承担。 一个AI客服agent给了客户错误的退款承诺，损失由企业买单。一个AI编码agent引入了安全漏洞，修复成本由企业承担。企业有能力也有动力去治理这种风险------设权限、做审计、建回滚机制。
C端：个人承担。 一个写作助手给了你一段不通顺的文字，你自己改。一个旅行规划AI给你排了一个不合理的行程，你自己调整。个人没有能力也没有工具去治理AI的风险------你能做的只是"小心点用"。
这个差异看似简单，但它决定了产品设计的几乎所有方面。
图5-1：B/C端分化机制------风险承担者不同，导致B端走governance路线、C端走safety-by-design路线。
B端：governance路线
核心矛盾：可控性 vs 价值密度
B端AI产品的核心矛盾是：你希望agent做得越多（价值密度高），风险敞口就越大（ 可控性 低） 。
一个只做建议的agent风险很低（建议不好可以不听），但价值也低（你还是得自己做）。一个自主执行多步任务的agent价值很高（帮你省了大量时间），但风险也高（一步走错可能连锁反应）。
B端产品设计的核心工作就是在这条曲线上找到最优平衡点。
信任基础设施是采购前提
企业采购AI产品时，评估的不是"AI有多聪明"，而是"我敢不敢让它碰我的系统"。
已发生：Claude Code的permission tier设计就是这个逻辑的体现。它把操作分成不同的权限等级：
- 读取文件 → 自动允许
- 修改代码 → 请求确认
- 删除文件 → 强制确认
- 执行网络请求 → 默认拒绝，需要显式授权
这不是功能设计，这是治理设计。企业需要看到这种治理机制，才敢让AI进入自己的系统。
企业AI产品的信任基础设施包含四个核心组件：
| 组件 | 作用 | 例子 |
|---|---|---|
| Permission scope | 控制agent能做什么、不能做什么 | Claude Code的permission tiers |
| Audit log | 记录agent做了什么、为什么做 | Devin的session replay |
| Revert/rollback | 出错时能恢复 | git commit + revert |
| HITL（Human-in-the-loop） | 关键决策由人做 | Cursor的review-before-apply |
判断：这四个组件是企业AI产品的采购前提，不是nice-to-have。缺少任何一个，企业的IT安全团队都不会批准采购。这解释了为什么很多AI创业公司在企业销售上碰壁------它们有最好的模型能力，但没有信任基础设施。
业务系统的治理设计实例
已发生：Salesforce Agentforce 在2024年发布时专门推出了"Trust Layer"------一个独立于agent能力的安全治理层。它包含数据屏蔽（agent处理客户数据时自动脱敏PII字段）、毒性检测（防止agent生成不当内容）、审计追踪（每次agent操作记录到Event Monitoring）、权限继承（agent的权限不超越调用它的用户）。这不是功能设计，是治理设计------Salesforce很清楚，没有Trust Layer，企业客户不会让Agentforce碰自己的CRM数据。
已发生：ServiceNow 的AI Agents 设计内置了"escalation by confidence"机制------当agent对自己回复的置信度低于阈值时，自动escalate给人工。同时，每次agent操作都生成audit trail，企业管理员可以回溯agent为什么给了这个回复、参考了哪些知识库条目。这是HITL + Audit log的组合实现。
判断：钉钉AI和飞书智能伙伴在OA场景的治理设计走了一条不同的路------它们不强调细粒度的permission scope（因为OA场景的操作风险相对可控），而是依赖企业已有的审批流基础设施。agent生成的请假单、报销单走的是传统审批流，只是发起方从人变成了AI。这是"把agent嵌入已有治理框架"而非"为agent新建治理框架"的策略------对于风险较低的场景，这可能是更务实的路径。
B端的销售特征
B端买家和用户不是同一个人。采购决策者（CTO、VP Engineering）关心的不是"AI好不好用"，而是：
- ROI证据：能算清楚"省了多少人力"或"快了多少天"
- Case study：类似企业已经成功部署了
- 安全合规：通过SOC2、GDPR等认证
- 可控性演示：能看到permission/audit/revert的实际效果
这意味着B端AI产品的销售周期长、客单价高、但需要大量信任建设。
C端：safety-by-design路线（简要对比）
C端用户自己承担agent出错的成本，但他们没有permission scope、没有audit log、没有revert机制。所以C端产品的设计逻辑完全不同：不是"建治理基础设施"，而是"在设计层面让错误成本可接受"。
C端的核心矛盾是简单性 vs 情感深度------用户要的是简单好用的体验，但越深度的AI参与意味着越高的错误风险。
C端的突破路径主要有：
- 低风险高频：写作、翻译、摘要------错误容易发现、容易修复
- 情感陪伴：Character.ai------错误是"不够懂我"而不是"造成损失"
- 创意生成：Midjourney、DALL-E------没有"正确答案"，错误是"不同风格"
本书不深入展开C端路径。但值得B端产品团队注意的是：B端用户也是C端用户------他们习惯了ChatGPT的简洁交互，会对过于复杂的B端界面失去耐心。
B/C交叉趋势
判断：B端和C端正在交叉，但不会收敛到同一形态。
B端需要C端体验。 员工习惯了ChatGPT、Midjourney的简单交互，回到复杂的企业管理软件会有强烈的落差感。Cursor的成功部分归因于这一点------它的UI比传统IDE简洁得多，更接近消费产品的体验。
C端需要B端能力。 用户不满足于"AI聊天"，希望AI真的能干活。ChatGPT的code interpreter、file analysis功能都是这个方向的尝试。
但风险承担者的差异是结构性的，不会因为功能交叉而消失。企业承担风险的机制（governance）和个人承担风险的机制（safety-by-design）是两条不同的路线。
判断：未来胜出的B端产品可能是"B的能力+C的体验"------治理基础设施完整，但交互层尽可能简单。这对产品团队的设计能力提出了更高要求。
反例与边界
本章论点的边界条件：
B端内部也有分化。 大企业和中小企业的governance需求差异很大。一个10人团队可能不需要完整的audit log和HITL------老板就是审批者。但随着企业规模增长，governance需求只增不减。
C端也有"重治理"的场景。 涉及金融交易、医疗建议的C端AI产品，错误成本可能极高，需要类似B端的治理机制。但这些场景目前更多走B2B2C路线而非纯C端。
"风险承担者"不总是清晰的。 在SaaS-to-B模式中（如Notion AI），产品服务企业客户但面向个人用户。这种混合形态需要同时兼顾两条路线，设计难度更高。
小结
B端和C端的根本差异是风险承担者不同。B端企业承担错误成本，走governance路线（permission/audit/revert/HITL）；C端个人承担错误成本，走safety-by-design路线。
本书聚焦B端。信任基础设施是B端AI产品的采购前提，不是锦上添花。核心矛盾是可控性与价值密度的平衡。
下一章讨论商业模式------当agent替代的是可计价的人力时，定价单元会怎么变化。