从业务样本而不是功能愿望开始
针对“设备型号、手册、告警码和历史维修记录分散在不同位置”，项目启动前抽取不同用户、时间段和异常类型的代表性任务，复原从输入到结果的完整路径。访谈内容与系统日志交叉核对，区分事实、推断和待验证项。对没有数据支撑的判断，先设计采集办法，不把主观感受直接写成项目收益。
例如可以抽取连续20个工作日的任务，记录数量、角色、处理时长、等待节点、返工原因和最终状态。样本量是否足够取决于业务波动与风险，不采用一个“通用正确数字”。
C级 · 能力场景示例
适用于制造、能源、楼宇或工程运维团队，设备资料分散、故障依赖老师傅经验且维修记录难以沉淀的场景。本页为C级能力场景，不代表可以替代专业检测或安全操作规程。 本页不主张已完成某个特定客户项目，也不使用未经授权的客户名称、业绩或经营数据。了解案例证据分级
典型业务挑战
设备型号、手册、告警码和历史维修记录分散在不同位置
同一故障现象可能对应多个原因，缺少上下文会误导排查
传感器异常、通信故障和业务阈值异常容易相互混淆
维修建议如果直接执行，可能引发人身、设备和停产风险
工单关闭后缺少故障原因、处理步骤和效果的结构化沉淀
方案设计思路
01
选择一类关键设备并梳理台账、部件、告警、工单和安全边界
02
清洗手册、SOP、点检标准、历史故障和备件知识
03
连接实时状态或受控快照，区分事实、规则和模型推断
04
输出原因候选、证据、排查顺序和需要人工确认的安全提示
05
经工程师确认后创建工单、领料或升级请求并保留审计
06
使用维修结果修订知识、规则和故障样本，不让模型自行学习
知华可承担的项目职责
联合设备、工艺、安全和IT人员确认系统责任边界
整理设备主数据、告警、手册、工单和故障分类
开发知识检索、状态接入、诊断辅助和工单集成能力
完成错误告警、缺失数据、越权操作和故障回退验证
实施约束与能力边界
01
AI只能提供诊断辅助，停机、拆检和参数调整必须遵循企业安全制度
02
预测性维护需要足够连续、可信且与故障标签关联的数据
03
设备接口协议、采样频率和历史数据质量会限制分析深度
04
涉及高风险设备时应由持证人员确认并保留双人复核
系统能力范围
设备与部件台账告警和状态接入运维知识RAG故障原因候选排查步骤生成安全确认维修工单协同故障复盘看板
可交付成果
PROJECT OUTPUT设备范围与故障分类清单
PROJECT OUTPUT手册SOP和历史记录知识工程
PROJECT OUTPUT设备诊断助手与管理端源码
PROJECT OUTPUTEAM、MES或IoT平台接口
PROJECT OUTPUT规则、权限和安全护栏配置
PROJECT OUTPUT准确性、性能与异常测试报告
PROJECT OUTPUT部署运维与知识维护手册
应形成的工程证据
作为C级能力场景，本页不声称已持有某个客户的项目证据。类似项目实施后，应按合同范围形成以下可核验材料。
VERIFIABLE EVIDENCE设备、部件、测点、告警、故障和工单数据字典
VERIFIABLE EVIDENCE手册、SOP、故障案例、来源版本和知识责任人清单
VERIFIABLE EVIDENCE已知故障、相似故障、缺失数据和错误告警评测报告
VERIFIABLE EVIDENCE状态来源、诊断候选、证据片段和人工确认记录
VERIFIABLE EVIDENCE工单创建、升级、领料、关闭和重复故障审计日志
VERIFIABLE EVIDENCE停机时间、首次定位、重复故障和知识缺口复盘
建议写入合同的验收标准
已知故障样本上的原因候选和排查步骤达到确认基线
每条建议能够区分设备事实、制度依据和AI推断
高风险操作必须经过正确角色确认且不能由AI直接执行
数据缺失、状态冲突或模型不可用时明确提示并转人工
诊断结果、工单处理和最终故障原因可以关联追踪
企业人员能够维护设备知识、规则和故障评测样本
CAPABILITY CASE WALKTHROUGH
能力场景如何落到项目计划
本段继续采用C级能力场景口径，数字为估算方法示例，不代表任何特定客户成果。
将系统能力映射到具体责任
场景中的设备与部件台账、告警和状态接入、运维知识RAG、故障原因候选不会作为孤立模块堆叠，而要对应到业务角色、数据来源、操作权限和异常处理。每个关键状态定义谁创建、谁确认、什么条件可以流转、失败后如何恢复，并明确客户业务团队与实施团队各自负责的资料、审批和系统环境。
原型评审使用真实字段和代表性流程。涉及第三方系统时，在排期前核对接口文档、测试账号、调用限制和联调负责人；无法确认的依赖单列风险，不在开发后期才暴露。
正常、异常和边界任务都要覆盖
验收集至少包括标准流程、字段缺失、重复提交、越权访问、外部接口失败、数据冲突和人工退回。建议形成设备、部件、测点、告警、故障和工单数据字典、手册、SOP、故障案例、来源版本和知识责任人清单、已知故障、相似故障、缺失数据和错误告警评测报告，让每条验收结论能够回到需求、版本、执行记录和最终结果。
若场景包含AI能力，还需固定评测问题、期望结果、引用依据和拒答规则；若包含交易或数据同步，则重点验证幂等、对账、补偿与回滚。
示例数据只用于建立测量方法
假设改造前每周有300项任务、平均完成周期2.5天、人工追问率25%，可以把目标写成“首期上线六周后，在任务复杂度相近的前提下，平均周期下降20%，追问率不高于15%，关键数据完整率达到98%”。这些数字必须在正式项目中由双方依据基线重新确认。
合同验收可重点核对已知故障样本上的原因候选和排查步骤达到确认基线、每条建议能够区分设备事实、制度依据和AI推断、高风险操作必须经过正确角色确认且不能由AI直接执行。业务指标未达到时，需要区分系统缺陷、数据条件、流程执行或外部依赖，不把全部问题简单归因于技术。