采购需求规范
优先试点这一场景的目标是把业务需求、技术参数、预算、交期整理成需求书、澄清问题和验收要点。
- 输入
- 业务需求、技术参数、预算、交期
- 输出
- 需求书、澄清问题和验收要点
- 验收
- 检查寻源周期、比价覆盖率、交期异常发现率
- 边界
- 参数和验收条件由需求部门确认

采购应用要把寻源、比价、交期和风险材料做扎实,供应商选择与合同承诺由组织审批。
左起第一列是这个岗位可交给 WorkBuddy 的场景; 中间两列是它需要什么、能交付什么;最后一列是必须由人或系统决定的部分 —— 这一列才是评审时真正要看的,因为它决定哪些环节不能自动化。
| 场景 | 需要输入 | WorkBuddy可辅助交付 | 人工或系统边界 |
|---|---|---|---|
| 采购需求规范 | 业务需求、技术参数、预算、交期 | 需求书、澄清问题和验收要点 | 参数和验收条件由需求部门确认 |
| 供应商寻源 | 品类、区域、资质、产能和交期 | 候选供应商、来源和初筛表 | 不能把网络信息等同于已通过资质审查 |
| 供应商尽调 | 主体、股权、司法、质量和履约资料 | 风险摘要、缺口和核验清单 | 关键事实回查官方渠道和原始证明 |
| 比价与方案评估 | 报价、规格、商务条款、总拥有成本 | 可比口径表、差异和敏感性分析 | 最低价不等于最优,权重由采购委员会确定 |
| 招标文件检查 | 需求、模板、法规、评分办法 | 缺项、矛盾、歧义和修改建议 | 正式招标文件由招采和法务审核 |
| 采购合同预审 | 合同、订单、招投标文件、审批规则 | 条款差异、风险和待补附件 | 签约条件和法律判断交法务/ 授权人 |
| 订单与交期跟踪 | 订单、交期、到货、质检和付款状态 | 逾期、缺料、异常和催办清单 | 外部催办和改单需采购确认 |
| 供应商绩效风险 | 质量、交付、价格、服务和投诉数据 | 绩效卡、趋势、风险和改进项 | 淘汰、降级和份额调整不能自动执行 |
| 采购支出分析 | 采购明细、品类、组织、供应商数据 | 支出结构、集中度、异常和谈判线索 | 节省金额需用统一基线计算 |
三个优先场景在各岗位下按同一套方法拆解:明确任务口径 → 收集并检查输入 → 让 WorkBuddy 执行整理、检索或生成 → 输出可编辑结果 → 由岗位负责人复核后进入下一流程。
这一场景的目标是把业务需求、技术参数、预算、交期整理成需求书、澄清问题和验收要点。

这一场景的目标是把品类、区域、资质、产能和交期整理成候选供应商、来源和初筛表。

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