四类访谈输入
业务侧讲任务与人工流程；IT/安全侧讲环境、身份与网络；法务/合规侧讲数据授权与留痕；管理层讲预算与时间窗口。四类信息缺一类，排序结论就会失真。
SOLUTIONS · OnvergeAi
咨询诊断
咨询诊断服务：需求访谈、现状盘点、场景排序、风险清单、初步路线与预算区间，以及交付物与排除项。
服务 01 · 咨询诊断
需求访谈、现状盘点、场景排序、风险清单、初步路线与预算区间；先诊断，再决定投入。
回答四个问题：要不要做、先做哪一个、需要什么前提、大致投入区间。诊断以访谈与盘点为输入，以价值—可行性—风险三维排序为方法，输出一份可评审的诊断报告与 PoC 建议书：写清楚建议启动的场景、暂缓的场景及理由、数据与合规前置条件、需要客户哪几个角色参与、以及投入与周期的区间口径。诊断不做效果承诺，也不把预算区间当报价；它的价值是把后续投入的不确定性压缩到可以被客户内部审批的程度。
服务范围构成
标准服务 4 项 · 可选服务 0 项
排除项 0 项 · 前置条件 2 项
排除项 0 项 · 前置条件 2 项
计价与报价口径
按阶段包计价
按人天或阶段固定包：展示报告章节与交付日，不给出行业均价
按人天或阶段固定包：展示报告章节与交付日，不给出行业均价
服务属性
默认纳入标准范围
证据等级 C · 复核周期 90 天
证据等级 C · 复核周期 90 天
服务范围（我们做什么）
内容包括：业务/IT/法务/安全四类接口人访谈（60—90 分钟/场）；数据与环境现状盘点（数据源、量级、权限、机房与算力、运维制度）；任务清单与场景排序（价值、可行性、风险三维打分）；合规与数据边界初判（数据分类分级、授权与使用目的、留痕要求）；模型与部署路线初选（私有化、混合、云端、托管）；投入与周期区间估算（人天、软硬件口径分离）；风险清单与退出条件建议。
交付内容
- · 诊断报告（文档）：现状盘点、场景排序矩阵、风险清单、路线建议与投入区间
- · 场景排序矩阵（表格）：按价值、可行性、风险三维打分，含暂缓场景与理由
- · PoC 建议书（文档）：试点范围、测试集与指标口径、退出条件、所需客户配合
- · 数据与合规前置条件清单（清单）：需要客户确认的授权、来源、保留期与责任人
- · 访谈与盘点记录（记录）：接口人清单、访谈纪要、现状盘点表
前置条件（需要客户提供）
- · 业务负责人参与：需业务侧定义任务、使用人群与人工审核规则，否则排序无依据
- · 明确数据边界与使用目的：客户说明数据来源、权利归属、可用范围与禁止用途
- · 提供接口人清单：业务、IT、法务/合规、安全至少各一名对接人
- · 确认项目目标与决策链：谁提需求、谁批准预算、谁负责上线后的运维
责任边界（我们不承担什么）
诊断结论不构成对效果的承诺；报告中的预算区间为设计参考，不是报价，也不构成行业均价。诊断期内不接触生产数据的处理与迁移，客户资料的接收范围、保留期与销毁方式在诊断启动前书面约定。
内容体系
诊断不是一个会议，而是一套把模糊诉求拆成可审批事项的工作结构。四类输入、五项方法、六份产出构成完整的诊断内容体系。
现状盘点四张表
数据清单（来源、量级、责任人、保留期）、环境清单（服务器/算力/机房/网络）、权限现状（角色与账号体系）、运维现状（监控、备份、变更与值班）。
场景排序矩阵
把候选任务按业务价值、数据可行性、工程复杂度、合规风险四个维度打分并排序，同时给出暂缓项与理由，避免“全都想做、一个都落不了地”。
路线与投入区间
按任务特征初选纯私有化／混合／云端／托管路线，并给出软件实施、硬件与算力分离的投入区间口径，供内部审批参考。
风险与前置条件清单
逐项列出数据授权、来源合法性、保留期、日志范围、账号隔离、第三方调用等前置条件，明确责任人与完成时点。
PoC 建议书
定义试点范围、样本与测试集来源、指标口径与基线、退出条件与扩围条件，使试点结果可复算、可评审。
场景矩阵
诊断阶段最常见的四类诉求，以及我们对应的动作与产出。客户可以据此对标自己的处境。
| 典型情形 | 客户处境与我们的动作 | 产出与责任人 |
|---|---|---|
| 完全没有基础 | 只有“想用大模型”的诉求，没有任务清单与数据准备。动作：从现有业务中筛出高频、文本密集、人工重复度高的 3—5 个候选任务，做可行性初判。 | 场景排序矩阵 · 业务负责人确认 |
| 已有本地模型 | 已经买了服务器或跑通开源模型，但效果与业务脱节、无人使用。动作：评估现有算力与模型适配度，定位是数据、检索、提示还是流程接入问题。 | 现状盘点表 + 优化路线 · 技术负责人确认 |
| 已在用云模型 | 业务已用公有云模型，但部分资料不允许外发，需要划清可外发与不可外发的界限。动作：设计数据分级与脱敏规则，给出本地/外部的任务切分方案。 | 数据边界方案 · 法务与 IT 确认 |
| 预算与责任不清 | 需求方与 IT、法务、财务对范围与预算口径不一致。动作：把范围拆成各自可验收的服务项，软硬件与实施费分列，形成可走采购的边界。 | 服务与预算边界说明 · 管理层确认 |
※ 诊断输出的是决策依据，不是方案承诺；报告评审通过后再进入设计或 PoC，未经评审不进入实施。
能力底座
诊断结论的可信度来自方法而不是话术：我们用什么依据判断一个场景现在能不能做。
任务—方法匹配表
把任务类型（检索问答、摘要抽取、文书草稿、结构化审阅、流程编排）与可选方法（RAG、提示工程、LoRA 微调、工作流编排）对应，说明各方法的适用前提与失败模式。
数据可行性判定
从样本量、文本质量、结构一致性、更新频率、权限粒度五个维度判定数据是否支撑目标，而不是只看“文档有多少份”。
许可与合规核验框架
模型权重许可、代码许可、训练与输出使用限制、商用条件与地域限制逐项核验；法规要求转成项目动作，不转成合规标签。
算力口径估算
按参数量、精度、上下文长度、并发、批处理、缓存与冗余共同估算显存与吞吐，拒绝“70B 需要几张卡”这类通用答案。
行业知识沉淀
律所与专业服务、财税、金融、教育、政务五类行业的常见数据形态、审批结构与风险点已形成检查项，可直接对标。
交付与验收经验
六阶段流程、17 项验收材料、P1/P2/P3 SLA 框架，使诊断结论可以直接衔接后续项目的验收口径。
工程实现
从签约到报告评审的完整动作序列，包含客户配合节点与时间分布（按 2 周包口径）。
- 1
第 1 步：立项与保密（D1—D2）
签署 NDA、确认范围与资料清单、锁定四类接口人与访谈排期。此阶段不接触生产数据。
- 2
第 2 步：访谈（D3—D5）
按业务、IT/安全、法务/合规、管理层四类分别访谈，记录原始诉求与约束，形成访谈纪要并回签确认。
- 3
第 3 步：盘点（D4—D7）
按四张盘点表逐项核对数据、环境、权限与运维现状；客户以清单形式提供，避免直接导出生产数据。
- 4
第 4 步：排序与初判（D8—D10）
完成场景排序矩阵、数据可行性判定、合规前置条件初判与路线初选，标注每项结论的证据来源或待确认项。
- 5
第 5 步：投入区间与风险（D10—D12）
给出软硬件分离的投入区间口径与主要风险项，明确哪些结论依赖客户尚未提供的信息。
- 6
第 6 步：评审会（D13）
与客户评审诊断报告，逐条确认结论、修正偏差，形成会议纪要与待办清单。
- 7
第 7 步：下一步动作（D14）
输出 PoC 建议书、硬件选型建议或“暂不启动”结论；若暂不启动，说明重新评估的触发条件。
治理保障
诊断阶段的治理重点是资料边界与结论可追溯：我们不需要生产数据，也不给出无法复核的判断。
- 资料最小化
- 只接收清单、统计口径与制度类材料；确需查看样本时使用脱敏或截断样本，并在书面确认后使用。
- 结论可追溯
- 报告中的每条关键结论标注依据（访谈、制度文件、公开法规或客户提供材料），无法核实的写为待确认项。
- 不越界判断
- 合规部分仅做条款整理与项目动作映射；法律、税务、审计结论由客户或第三方专业机构出具。
- 人工复核节点
- 排序矩阵、投入区间、路线建议均需客户业务负责人与技术负责人分别确认，避免单方口径进入审批。
- 资料归还与销毁
- 项目结束后按约定归还或销毁客户资料，出具销毁记录；未获授权不得用于任何训练或演示。
- 内容复核周期
- 本页所述方法与模板每 90 天复核一次，法规与许可类结论以最新官方文本为准。
解决什么问题
诊断要解决的往往不是技术问题，而是“说不清、批不了、启动即返工”的组织问题。
- “要不要做”说不清
- 现状：需求来自不同部门，各说各的价值与风险，管理层无法判断优先级。我们的动作：用统一打分口径做场景排序，给出暂缓项与理由。
- “先做哪一个”定不下来
- 现状：都想做，等于都不做。我们的动作：以高频、文本密集、人工重复、失败成本可控四项筛出首个试点任务。
- 预算区间没有依据
- 现状：供应商报价差异极大，无法判断是否合理。我们的动作：把投入拆成软件实施、硬件、算力与运维四段，并说明每一段的估价变量。
- 合规要求落到项目就断链
- 现状：知道有法规要求，但不知道对应哪些项目动作。我们的动作：把条款翻译成数据授权、脱敏、权限、日志、保留期五类可勾选动作与责任人。
- 启动后才发现缺前提
- 现状：项目中途因数据授权、机房条件或接口人缺位而停摆。我们的动作：诊断报告前置列出全部前置条件与完成时点，作为项目启动闸门。
- 试点做完不知道算不算成功
- 现状：感觉“好像还行”，无法向管理层汇报。我们的动作：PoC 建议书预先定义样本、基线、指标与退出条件，让结果可以被复算和评审。
客户价值与优势
诊断的价值在于把不确定性前移：用两周的投入，避免在错误场景上投入数十周。
可审批的决策依据
输出一份带排序、区间、前置条件与风险项的诊断报告，可直接用于内部立项与预算申请，不必让管理层凭印象拍板。
范围与责任可拆分
诊断结论把后续工作拆成各自可验收的服务项，软硬件与实施费分列，责任主体清晰，避免“打包价里说不清谁负责”。
合规动作可勾选
法规要求转成五类项目动作与责任人，法务与安全可以在同一张表上确认，而不是在项目末期补材料。
失败成本可控
先做小范围试点并预定义退出条件：试点失败按约定回退，不必进入生产实施才发现不可行。
不绑定单一技术路线
选型矩阵与许可核验同时给出候选与排除理由，客户可自行询价比对；我们不以排他承诺换取订单。
后续服务可衔接
诊断产出直接对接数据治理、模型选型、PoC 与部署的输入要求，客户换供应商也能带着边界与指标重新报价。
※ 以上为服务能力与边界说明，不构成对具体项目效果的承诺；实际范围与交付以书面方案和合同为准。
标准服务
需求访谈与接口人确认
诊断阶段标准动作，60—90 分钟
现状盘点（数据/环境/权限）
按客户提供的资料清单执行
场景排序与风险清单
输出价值—可行性—风险三维排序
诊断报告与 PoC 建议书
诊断阶段主要交付物
前置条件
需明确业务目标与负责人
——
需明确数据边界与使用目的
——
服务过程
① 立项与保密（范围、数据授权、角色确认）→ ② 访谈（业务/IT/法务/安全）→ ③ 现状盘点（数据、环境、权限、运维）→ ④ 场景排序与风险清单 → ⑤ 路线与投入区间 → ⑥ 诊断报告评审会 → ⑦ 输出 PoC 建议书与下一步动作（PoC、硬件选型或暂不启动）。