市面上的 AI 助手都是"你问我答"——用户发起对话，AI 做出响应。
但管理者的日常不是这样的。他们需要有人主动提醒哪些数据异常了、主动推送明天汇报需要的材料、主动判断什么时候该打扰你。
这篇文章记录了我设计一个"主动型 AI 助手"产品的完整思考过程。从产品定义到架构设计，从用户故事到商业模式，从 POC 规划到风险评估。
产品定义
一句话定义：用户专属的工作管家，根据所掌握的数据，主动跟用户进行对话。
关键词拆解：
- 专属——不是通用助手，而是为某一个人服务的"分身"
- 主动——不等用户提问，而是根据自己的判断选择沟通时机
- 对话——以自然语言为主要交互方式
- 适应——根据对话历史不断调整沟通方式、侧重点和频率
这个产品我暂时叫它 Companion。选这个名字是因为它表达的是"私人的、值得信赖的、长期陪伴的"。在产品没成熟之前，可能需要一个更克制的名字（比如 WorkMate），避免用户觉得被"过度干预"。
解决什么问题
管理者每天面对大量的信息、数据和决策。他们需要：
- 从碎片中提炼——20 个人的工时、多个项目的预算、各种系统的数据，散落在不同的地方
- 在正确的时间获得正确的信息——不是每天打开 10 个系统看数据，而是在需要的时候被推送
- 有人帮忙"盯着"——项目超支了没？有人忘记提交周报了没？哪些指标在恶化？
用户故事
用两组对比来说明这个产品想达到的效果：
没有助手时
一名管理者需要在周一检查团队的工时填写情况。经过对 20 个人逐一查看，发现有人填多了、有人没填写。逐一提醒后，忘了一个人，又忘记复查。下周同样的问题依然存在。
周二要汇报，汇报前才发现上周的资源数据不对，需要到多个系统分别查数据汇总，手忙脚乱。
项目投入即将超支，每天去看经营看板，但难以判断在哪里止损。
有了助手后
周五，助手在约定时间发消息，说明当前团队填写情况，并询问是否需要直接提醒未填写的人。当所有人填完，助手通知管理者。到了周一如果还有人没填，助手再次提醒。并记录每个人忘记填写的次数——当次数达到一定阈值，主动向管理者建议是否需要沟通。
第一次准备汇报材料时，管理者告诉助手模板要求。助手说明哪些数据能自动获取、哪些需要人工补充。后续再需要准备材料，助手会在约定时间主动发送。
项目有超支趋势时，助手主动询问是否需要关注。如果管理者说不用，助手会问"到什么程度需要关注"，然后在达到阈值时再次提醒。如果管理者说完全不用关注，助手就不会再打扰。
核心设计思路：拟人
这个产品最核心的设计理念是拟人——不是技术层面的拟人（语气像人），而是行为层面的拟人（判断像人）。
市面上打着"主动"卖点的 AI，更多是在闲聊层面做到了"可以主动搭话"。每次对话不具备智能的延续性，每次都是一段短期记忆范围内的交互。
我的设计关注的周期是无限长——助手在任意时间都可以基于对用户的长期理解做出判断。比如：
- 用户第二天要请假，但每天有阅读财务报表的习惯。助手主动问：请假这天还要推送报表吗？
- 假期回来后，助手推送报表的同时，附上前一天管理者可能关心的事项
为什么不用模型微调
理论上，通过不断微调大模型也能达到类似的"拟人"效果。但成本、时效和变更三个维度都有问题：
| 维度 | 模型微调 | 动态偏好方案 |
|---|---|---|
| 成本 | 企业级微调 50~100w+，个人更不可控 | 应用层技术 + API 调用 |
| 时效 | 训练周期长，环境可能在训练完前就变了 | 准实时更新 |
| 变更 | 工作内容变化需重新训练 | 数据库记录可低成本裁剪和迁移 |
关键区别在于：微调把"个性化"固化在模型里，而这个方案把"个性化"放在可操作的数据库里。人员离职，微调的模型变成沉没成本；而数据库里的偏好记录可以被迁移或销毁。
产品架构
产品设计中，因为涉及 Agent 的存在，可能有多个大模型协作。为了减少对用户的打扰：
- 单次对话尽可能少地调用 Agent
- 多 Agent 任务时，每个 Agent 完成后跟用户确认结果
- 已确认的节点在后续对话中跳过
POC 阶段的关键技术点：
- Prompt 设计（长期关键成功要素）
- 模型的结构化输出（POC 关键成功要素）
- 向量数据库存储用户偏好
- 使用 LangChain 或 PydanticAI 确保结构化数据质量
分阶段规划
POC：概念验证（~1 个月）
- 提供一个飞书/企微机器人，让 2-3 名用户加入测试
- 给机器人提供特定领域的业务数据
- 必须验证：助手能否自主定义有效的事务规则
- 对话意外终止占比 < 10%
- 至少 1 名用户表示愿意继续
成熟产品：某个角色的分身
- 支持更多用户选择性添加
- 可以注入到内部任意系统，共享用户的权限
- 丰富工具池，让助手更"有用"
- 性能和成本优化
长期产品：和员工"共同工作"
- 设备级行为同步（员工选择哪些可被观察）
- 多重人格（不同场合不同话术）
- 伦理挑战：隐私、组织滥用、员工离职后分身的归属权
商业模式思考
| 场景 | 定价策略 |
|---|---|
| 企业内部 | 按月付费（鼓励快速形成"人格"）或按资源用量 |
| ToB | 隔离部署，闭源售卖 + 付费售后 |
| ToC | 流量计费，等待大模型成本下降 |
核心成本来自三个方面：大模型 token、数据库存储、服务器资源。
更多想象力
前面说的都是 ToB 场景。如果放到 ToC 呢？
- 心理陪伴（对有特定需求的人群提供持续性支持）
- 个人生活助手
- 游戏陪玩
这些场景的共同点是：需要长期记忆、需要主动判断、需要个性化适应。
局限性
诚实地说：
- 大模型是大脑——产品的上限取决于模型能力的演进
- 冷启动期——新用户需要"磨合"时间，这段时间助手可能显得"低智"
- 上下文窗口——长期记忆的有效管理是持续挑战
- 隐私侵入性——如果应用不当可能引发用户反感
- 市面上没有类似产品的原因——大模型的易用性是近一年才普及的；面向个人的产品如果做得不够好，很难被接受
风险评估
最大的两个风险：
- 成本风险：主动型助手的 token 消耗远大于被动问答型。数据维护量也更大。好消息是这两个成本都在快速下降。
- 隐私风险：自驱的助手需要收集大量数据和用户习惯，可能触发隐私问题。需要脱敏方案和免责协议。
如果这个方案可行，它可能会改变一些事情：企业会更偏向结构化数据建设而非体验建设；员工可能会因为花了精力培养一个独一无二的合作伙伴，而把它当作留下来的重要理由。
当然，这也可能带来新的问题——当 AI 真的变成了你的"分身"，你和它之间的关系该怎么定义？
这个问题，可能需要比技术更长的时间来回答。