项目背景
本案例基于可公开的项目名称与职责边界进行去敏化整理。项目关注既有 IM 能力如何服务新的业务协作场景；内部流程、策略参数与业务数据不在当前公开范围内。
核心问题
迁移并不等于复制。需要先判断用户在新场景中的沟通目标、关系链和任务节奏，再决定哪些能力可以复用、哪些交互必须重构。
我的角色
参与能力盘点、场景拆解与方案协作，重点从用户任务出发组织需求，并帮助团队区分通用能力与场景定制能力。
用户与业务痛点
- 相似的沟通入口背后，用户身份、任务目标和时效要求可能完全不同。
- 直接复制既有交互容易带来能力冗余，也可能让关键动作被弱化。
- 迁移过程需要兼顾学习成本、体验一致性与业务侧的实际约束。
产品方案
- 以用户任务链而非功能清单梳理消息、会话、提醒与状态反馈。
- 将能力拆成可复用基础层与场景化表达层，明确每项能力的触发条件。
- 用关键路径和异常路径共同评估方案，避免只覆盖顺畅流程。
AI 方案
- 本项目不以 AI 为必要解法；核心判断是先用稳定、可解释的产品能力解决沟通问题，避免为了技术标签增加复杂度。
遇到的困难与解决方式
遇到的困难
- 相似功能在不同场景中可能承担不同责任，边界判断容易被表面一致性干扰。
- 公开案例不能披露内部业务规则，因此需要保留方法论而去除敏感细节。
解决方式
- 通过场景—任务—能力映射表讨论迁移范围，让方案评审围绕用户目标而非页面差异。
- 以去敏化的关键路径呈现判断过程，保留个人贡献和产品思考。
项目结果
- 形成了可复用的能力迁移分析框架，并让方案讨论拥有更清晰的场景边界。
- 具体业务指标未在当前公开材料中确认，可在获得授权后补充量化结果。
面试官可能追问的问题
为什么不直接复用原有 IM 产品？
我会这样回答
我会先验证用户关系、任务目标和信息时效是否一致。能力可以复用，但触发方式、信息层级和异常处理需要由新场景重新决定。
你在项目中的核心贡献是什么？
我会这样回答
我的重点是把功能迁移问题转化为场景和任务问题，协助团队明确哪些是通用能力、哪些必须针对用户路径重新设计。