产品定位
MCP 工具开放是企业协同平台的 AI 基础设施项目。目标是把平台已有的业务能力（日程、任务、考勤、公告等）封装为标准化的 MCP 工具，让 AI 智能体能够理解和调用这些能力，真正完成用户的业务任务。
作为产品负责人，我独立推进从功能现状梳理到 MCP 工具定义、智能体产品定义、场景验证的全链路工作。建立了一套可复用的模块推进方法论，已覆盖日程、文化建设、考勤签到等多个核心模块。
解决了什么问题
平台要让 AI 智能体真正能帮用户办事，需要解决三个层面的问题：
- 能力封装：已有业务接口不等于 AI 可用的工具，需要重新定义输入输出、权限边界和使用限制
- 场景驱动：不能按工具清单堆砌能力，必须从用户真实任务出发定义智能体边界
- 验证闭环：工具定义完不等于能用，需要按场景验证并反推能力缺口
标准化推进方法论
建立了一套"现状沉淀 → 工具定义 → 产品定义 → 场景验证"的四段流程：
- 读操作手册或旧版接口清单，提炼模块功能现状
- 按模块本体定义 MCP 工具（查列表/查详情/新增/修改），明确输入输出、权限、批量支持
- 基于已实现能力收口智能体首版边界，产出产品定义文档
- 新建场景验证表，按用户任务维度验证能力覆盖度，反推缺口
三条核心原则
- 以用户场景定义智能体，不以工具清单定义
- 以已实现能力约束边界，不脱离现实空想
- 以场景验证反推能力缺口，而非"工具先这样就算了"
工具定义的具体规则
这些规则不是一开始就定好的，是在推进中逐步沉淀出来的：
- 先按模块本体写，不按聚合入口写——任务就是任务对象，事件就是事件对象
- 查询拆列表和详情：列表返回摘要，详情返回完整内容，详情支持批量查
- 新增/修改输出带链接：输出中始终带缓存链接和详情 URL（PC + 移动）
- 触发提示词按角色写：尤其查看类要写得更细，因为阅读者远多于创建/修改者
- 先保守落地再校准：平台 MCP 标准还不明确时，先按保守口径写，后续结合代码反馈做校准
智能体产品定义的统一结构
每个模块的产品定义文档都按同一套结构收口：
- 是什么
- 服务对象
- 产品目标
- 当前定义边界
- 当前不作为首版承诺的能力
- 当前依赖的已实现能力
- 用户可感知的能力表达
- 首版提示词
- 给实施方的落地说明
- 版本说明
已覆盖模块
- 日程（含时间安排聚合）
- 计划 / 任务 / 事件
- 领导行程
- 文化建设（公告、新闻、讨论）
- 考勤签到
其中日程、文化建设、考勤签到已完成完整的"产品定义 + 场景验证"闭环。