立项与范围
优先试点这一场景的目标是把商业目标、需求、资源和约束整理成项目章程、范围和假设。
- 输入
- 商业目标、需求、资源和约束
- 输出
- 项目章程、范围和假设
- 验收
- 检查纪要漏项率、风险更新及时率、逾期行动项数量
- 边界
- 范围由发起人与干系人确认

项目经理的关键任务是维护范围、承诺、风险和验收,AI智能体帮助信息不丢失。
左起第一列是这个岗位可交给 WorkBuddy 的场景; 中间两列是它需要什么、能交付什么;最后一列是必须由人或系统决定的部分 —— 这一列才是评审时真正要看的,因为它决定哪些环节不能自动化。
| 场景 | 需要输入 | WorkBuddy可辅助交付 | 人工或系统边界 |
|---|---|---|---|
| 立项与范围 | 商业目标、需求、资源和约束 | 项目章程、范围和假设 | 范围由发起人与干系人确认 |
| WBS与计划 | 范围、里程碑、资源、依赖 | WBS、排期、责任和关键路径草案 | 工期估算需责任人承诺 |
| 会议纪要与待办 | 会议转写、议题和成员 | 决策、问题、行动项和负责人 | 会后确认,避免AI错配责任 |
| 风险与问题台账 | 风险、问题、影响和处置记录 | 分类、优先级、应对和升级建议 | 风险接受和预算由治理层决定 |
| 进度周报 | 计划、实际、工时、问题和变更 | 进度、偏差、风险和下周计划 | 不能粉饰延期或遗漏阻塞 |
| 变更管理 | 变更请求、基线、成本和依赖 | 影响分析、审批材料和版本差异 | 未批准不得更新基线 |
| 验收标准 | 合同、需求、场景和基线 | 测试用例、阈值、证据和退出条件 | 演示效果不能代替生产验收 |
| 项目复盘 | 目标、结果、事件、反馈和数据 | 时间线、原因、经验和行动项 | 区分事实、判断和责任 |
| 干系人沟通 | 角色、关注点、决策和状态 | 分层沟通稿、会议和升级路线 | 敏感信息按角色权限发送 |
三个优先场景在各岗位下按同一套方法拆解:明确任务口径 → 收集并检查输入 → 让 WorkBuddy 执行整理、检索或生成 → 输出可编辑结果 → 由岗位负责人复核后进入下一流程。
这一场景的目标是把商业目标、需求、资源和约束整理成项目章程、范围和假设。

这一场景的目标是把范围、里程碑、资源、依赖整理成WBS、排期、责任和关键路径草案。

这一场景的目标是把会议转写、议题和成员整理成决策、问题、行动项和负责人。
同一个岗位的场景会分散在四层里:文件层只用本地文档就能跑, 知识层要先建好有版本、有出处、有权限的资料,系统层要接业务系统, 决策层则必须保留人工批准。先看自己能从哪一层起步。
使用本地文档、表格和模板,结果可人工检查
建立有版本、有出处、有权限的知识资料
通过受控的Connector、MCP或API读写业务系统
展示依据、假设和影响,高风险决定由人批准
推荐先做“会议纪要与待办”。它所需输入是会议转写、议题和成员,目标交付是决策、问题、行动项和负责人。
试点可按四个动作推进:第一,抽取一批真实历史任务作为基线;第二,用同一批输入让人工流程和WorkBuddy流程并行;第三,记录失败、遗漏和人工修改原因;第四,只在结果稳定、权限清楚、可以回滚时扩大范围。
建议验收指标包括:纪要漏项率、风险更新及时率、逾期行动项数量。如果结果需要大量重做、来源无法追溯、系统写入不可回滚,试点应暂停并先修复数据或流程。
把你们这个岗位最耗人的一件事说清楚,我们按上面四层能力给出可切入点、需要对接的系统清单和人工边界 —— 不是通用方案,是照着你们现有流程改的版本。