算力与AI基础设施 · 行业场景库

机房值守运维(动环与基础设施)(4) · 智算集群运维(GPU 与高速网络)(3) · 算力运营与客户服务(3) · 售前方案与交付工程(2)

库级说明:这套场景为什么这样切、不做什么、怎么交付

岗位依据

岗位依据与数据 · WorkBuddy · 算力与 AI 基础设施场景库

4 个子角色为什么这样切,依据在哪

公开的组织架构是「动环部 — 集群运维部 — 运营部 — 交付部」各司其职、配 DCIM 与调度平台。但真实情况是另一回事:IDC 机房运维的招聘 JD 写的是「7×24 小时值守及设备巡检、应急故障抢修并做好记录」,中小城市此岗月薪5,000-7,000 元;智算运维 JD 要求「GPU 集群、高性能存储、IB/RoCE 高速网络的 7×24 监控 + SOP/EOP 制定」一肩挑;从业者自述「每天 300 条告警,团队不是看不见,是看见了也不动」、「凌晨误告警手机响个不停,排查完接着睡」;中小 IDC 的客户服务还在「电话找工程师、微信发截图」阶段。在几百人的算力中心里,大厂那套 8-10 个角色的分工是压缩成 4 个人群扛的。

所以这套场景库按算力中心从物理设施到客户交付的主流程环节切分,而不是按职能表:值守机房的(机房值守运维)、运维集群的(智算集群运维)、经营算力与伺候客户的(算力运营与客户服务)、卖算力与交付的(售前方案与交付工程)—— 这四类活在几百人的算力中心里由三四十个人分头扛完,区别只在什么时候来、错了会怎样、产出物是什么。四个角色的场景互相咬合:巡检台账里的空调三次异常接着集群降频事件的根因,降频事件接着 SLA 月报的争议口径,闲置盘点的上架率接着扩容测算的基数 —— 不是四套孤立的演示。

机房值守运维(动环与基础设施)

Facility Duty Operations

把机房每天的物理状态变成可归档、可追责、可上会的记录 —— 巡检、交接、电费、能耗四本账,一本都不能烂

4 个场景

这个子角色为什么真实存在:依据一:IDC 机房运维 JD 原文就是「7×24 值守 + 巡检 + 抢修并做好记录」,中小城市此岗月薪 5,000-7,000 元 —— 最重的记录工作落在最低薪的人手上依据二:巡检表与交接班表的模板栏位(温湿度/UPS/空调 22-26℃/水浸/消防/门禁/复核签名)说明这些表单的第一功能是留证与追责,不是管理依据三:从业者自述台账靠 Excel、工单靠微信群喊、盘点账实不符 8%、审计来了现场翻两天 —— 数据底座不是 DCIM,是一堆 Excel 和纸质表

公开来源:IDC 机房运维 JD 原文:「负责数据中心 7×24 小时值守及设备巡检;对数据中心的设备进行日常巡检、定期维护和应急故障抢修并做好记录」中小城市 IDC 机房值守岗月薪 5,000-7,000 元 —— 最低薪的人在做最重的记录工作机房巡检记录表真实栏位:巡检日期、巡检人、机房环境温度/湿度、UPS、空调(22-26℃)、水浸、消防、门禁、异常记录与处理、复核人签名 —— 来自公开巡检表模板值班交接班记录表真实栏位:班次、日期、交班人/接班人、设备运行情况、未完结告警、待执行变更、客户预约操作、安全隐患及预防措施、双方签名U 位资产管理从业者自述:季度盘点账实不符比例接近 8%;误拔电源「查了三天才知道是外包运维人员干的,但人家说我也没记录啊」;审计突击「留给你的时间往往只有几十分钟」「传统的做法靠纸质工单或者微信群通知,效率低还容易丢」—— 微信群是隐形的生产系统,客户报障、跨班组协作、变更通知大量在里面

它实际在用的数据:「机房巡检记录表」纸质本 / 问卷星式手机表单(每班每次)「交接班记录表.xlsx」+ 纸质本(每班)「电费台账.xlsx」—— 电网 PDF 账单 + 自算分项(谷峰平电量、需量、基本电费)「PUE 日报/月报.xlsx」从动环后台导出,分项计量不全时靠倒推「资产机位台账 U位表.xlsx」随上下架手动更新,实际滞后数月微信群:客户报障、施工协调、空调维修师傅接单全在里面

关键字段与口径:巡检表栏位:机房/日期班次/巡检人/温湿度/UPS/空调 22-26℃/水浸/消防/门禁/液冷快插接头与

CDU 压力温度/异常与处置/复核签名交接班栏位:班次/交班人/接班人/未完结告警/待执行变更/客户预约操作/安全隐患/双方签名电费台账:电度电费=分时电量×分时单价(尖峰平谷四段)+ 基本电费=需量×单价PUE=总耗电量÷IT 设备耗电量(GB 40879 口径)

本组场景:

升为客户真实案例还缺什么:要把这个角色的场景真正跑起来,需要客户补三样:近 3 个月纸质巡检表的照片或扫描件(赶在月度归档粉碎前)、电网电费账单 PDF 原件(含分时电量明细)、动环后台的总表与 IT 进线抄表导出权限

—— 现场第一句话就问「上个月的电费账单原件还在吗」。

这里列的是这个岗位真实会用到的数据类型,不表示已经取得任何客户的生产数据。

智算集群运维(GPU 与高速网络) GPU Cluster Operations

在「故障是常态」的集群里,把每次故障的判断、处置与复盘留下来 —— 换卡台账、RCA 报告、利用率日报,三样都是将来跟客户和厂商对质的证据

3 个场景

这个子角色为什么真实存在:依据一:Meta 万卡集群 54 天 419 次故障、GPU 故障率是 CPU 的 120 倍 —— 行业的对策是checkpoint 压到 5-30 分钟而不是消灭故障,运维的日常是「把故障当流程做」依据二:Xid 79 掉卡 / 48/63/94 ECC / 31客户代码的判断口径与「隐性降速最难查」的从业者实践 —— 判断靠经验台账,而台账在工程师个人电脑里依据三:运维规范要求 24 小时内出 RCA,但「复盘流于形式」是行业公开秘密;商用 GPU 服务器年均故障率 18.7%、单次处置超 90 分钟 —— RCA 和换卡台账是高频刚需文书

公开来源:Meta Llama 3 405B 在 1.6 万卡集群训练 54 天遭遇 419 次意外组件故障、平均每 3 小时一次;GPU 故障率是CPU 的 120 倍 —— 故障是常态不是例外大规模 GPU 集群运维实践:Xid 79 掉卡(需换卡)、Xid 48/63/94 不可纠正ECC、Xid 31 多为客户代码问题;隐性降速(PCIe 降速、GPU 降频)不中断任务最难查 —— 实测 PSU 问题导致 SMClock 从 2GHz 掉到 500MHz、性能降至 1/4 而监控无感运维规范要求一级批量停机、重复频发故障必须 24 小时内完成RCA 复盘报告,但「复盘流于形式、报告完成后不跟进」是行业公开的秘密商用 GPU 服务器年均故障率约 18.7%、单次故障平均处置超 90 分钟 —— 换卡是高频事件,台账值得单独建

它实际在用的数据:Prometheus + DCGM 监控(DCGM_FI_PROF_GR_ENGINE_ACTIVE、XID_ERRORS、clock

throttle)「设备故障维修记录.xlsx」(时间、设备 SN、故障现象、Xid 码、处理人、换卡记录)四类日志:用户日志 /dmesg / K8s Event / 插桩日志换卡备件台账与送修检测报告(维修成本仅为换新 1/3 的比价依据)「算力使用率周

报.xlsx」—— 调度平台导出加手工统计

关键字段与口径:换卡台账栏位:故障时间/设备 SN/Xid 码/故障现象/隔离时间/换卡时间/验收结果/客户通知记录RCA报告栏位:故障概述(时间/影响范围/中断时长)/时间线(发现-响应-处置-恢复)/根因分析(5Why)/直接损失与SLA 影响/责任界定/整改项与责任人截止时间利用率口径:卡时利用率=实际消耗卡时÷(在册卡数×自然小时);注意利用率≠健康(SM Clock 降频与显存碎片在利用率上看不出来)

本组场景:

升为客户真实案例还缺什么:需要客户补两样:近 6 个月「设备故障维修记录」哪怕是纸质或微信截图拼出来的都行、DCGM 的 XID 与 clock throttle 指标的导出权限 —— 没有历史故障数据,换卡台账和 RCA 就是凭空编。

这里列的是这个岗位真实会用到的数据类型,不表示已经取得任何客户的生产数据。

算力运营与客户服务

Compute Operations & Customer Success

把建好的算力卖出去并伺候好客户 —— SLA 月报、闲置盘点、客户沟通,每一份产出都直接连着续约、赔付和老板的决策

3 个场景

这个子角色为什么真实存在:依据一:智算中心 GPU 平均利用率不足 30%、千卡中心年运营成本超 3,000 万、上架率70% 才刚过回本线 —— 算力消纳是老板级痛点,运营角色是智算中心新生且最被低估的依据二:SLA 赔付条款是合同标配(未达 99.9% 双倍赔偿类),且投诉后 24 小时内要出书面报告 —— 月报不是形象工程,是赔钱与续约的依据依据三:中小 IDC 客户服务还在「电话找工程师、微信发截图」阶段,客户经理兼着报价、催款、续约全流程 —— 一人服务 N 个客户,文书全靠加班

公开来源:腾讯云解决方案总经理在 MWC26 上海披露:国内智算中心 GPU 平均利用率不足 30%;信通院 2025 年统计国内智算用算占比仅 36.8% —— 利用率是行业级痛点某千卡智算中心年运营成本超 3,000 万元、上架率不足 50%、实际利用率低于 30%,「亏损成为常态」;西部中小玩家徘徊在利用率 70% 的亏损线上IDC 服务 SLA 赔付条款真实存在:网络可用性未达 99.9% 按宕机时长双倍赔偿、电力未达 99.99% 三倍赔偿;赔付金额=(承诺可用性-实际可用性)×月度服务费IDC 托管 SLA 协议明确约定:受理投诉后 24 小时内向甲方提供第一份书面形式的投诉处理情况报告 —— 故障后的文书压力是合同刚性的中小 IDC 客户服务大量还在「电话找工程师、微信发截图」阶段 —— 上了工单系统但客户还是打电话,说明系统没被用起来算力运营 JD 原文:「负责设计智算中心的算力运营策略,进行运营模式创新,提高业务增长潜能」—— 智算中心新生、传统 IDC 没有的角色

它实际在用的数据:「客户带宽台账.xlsx」「机柜租赁合同台账」—— 运营手动维护SLA 合同扫描件(可用性承诺、赔付阶梯、免责条款藏在第 6 条)监控可用率数据(动环后台导出)+ Excel 工单表的处理时效调度平台的卡时消耗数据(自营算力口径混乱时靠手工统计)客户微信群——报障、问进度、要报告的第一现场

关键字段与口径:SLA 月报栏位:报告期/服务可用率(对比承诺值)/故障清单(次数/时长/根因/赔偿计算)/网络质量/功耗与机柜状态/下月计划/客户确认章赔付口径:赔付金额=(承诺可用性-实际可用性)×月度服务费,或按合同阶梯比例;99.9% 承诺=每月允许约 43 分钟宕机闲置口径:上架率=已上架机柜÷规划机柜;卡时利用率=实际消耗卡时÷(在册卡×自然小时);空转成本=折旧+资金成本+电费分摊

本组场景:

升为客户真实案例还缺什么:需要客户补三样:重点客户的 SLA 合同扫描件(尤其赔付与免责条款那几页)、调度平台近 3 个月卡时消耗导出、现有客户月报的任何一版历史样例 —— 合同条款拿不到,赔付预警就只能算给自己看。

这里列的是这个岗位真实会用到的数据类型,不表示已经取得任何客户的生产数据。

售前方案与交付工程

Presale Solution & Delivery

在客户签单之前替客户把性能验证做实,在签单之后把上架验收做清 —— POC 报告和交付单是算力生意里「技术动作翻译成钱」的两端

2 个场景

这个子角色为什么真实存在:依据一:中小企业售前与交付常合并为一两个人,POC 支持、算力产品方案、上架验收全流程一肩挑 —— 没有专职方案经理依据二:上架交付的规范动作(SN 码核对/压测烤机/机房测试报告/各方签字)与智算中心验收方案目录是公开标准,但实测数据散在工程师个人电脑和微信群依据三:扩容测算的第三方可研报告要价不菲,中小机构普遍「老板拍脑袋+销售催促式扩容」—— 而 AIDC 成本前置收入后置,测算差一个季度就是几百万利息(杰创智能转亏案例)

公开来源:上架交付全流程:到货验收(SN 码/硬件配置/外观状态/配件清单、各方签字)、上架通电、压测烤机、出具机房测试报告智算中心验收方案目录:设备清单核对、到货检验、安装检查、系统联调、性能测试、稳定性验证、安全检查、网络连通性验证 —— 交付件的栏位清单杰创智能因智算云集群投建利息+折旧大幅增加同比转亏;城地香江直言 AIDC「成本前置、收入后置」—— 扩容测算差一个季度就是几百万利息液冷初始投资高 20%-30%(差价

300-450 万),但行业测算年综合节省近 2,000 万、回收期 2-3 个月量级 —— 这笔账厂商各说各话,客户自己没人算得清

它实际在用的数据:POC 测试数据:nccl-tests 带宽、ib_write_bw、训练吞吐截图与日志(客户侧产出+微信传回)「资产机位台账 U位表.xlsx」(与值守共用,滞后数月)「机柜租赁合同台账」+ 销售的客户意向(在客户经理脑子里)历史 POC 报告与基准数据(MLPerf 参考值 + 自家实测)散在个人文件夹动力班的变压器/柴发余量数据(在电工马建国的本子上)

关键字段与口径:POC 报告栏位:测试环境(卡型号/数量/网络拓扑)/测试项(总线带宽/IB 带宽/训练吞吐/MFU)/结果与基准对比/瓶颈分析/结论与商务建议交付验收栏位:服务器 SN 码/硬件配置/外观状态/配件清单/电源线与

PDU 接口类型/上架机柜与 U 位/烤机压测结果/网络连通性/各方签字扩容测算栏位:当前上架率/新增机柜电力需求(液冷柜 60-70kW)/变压器柴发余量/投资回收测算(租金与卡时价格 vs 电费+折旧)

本组场景:

升为客户真实案例还缺什么:需要客户补两样:最近一次 POC 的原始测试输出(nccl-tests/ib_write_bw 的终端日志,截图也行)与一期建设的电力设计资料(变压器容量、柴发余量那一页)—— 没有这两个,POC 报告和扩容测算都是空中楼阁。

这里列的是这个岗位真实会用到的数据类型,不表示已经取得任何客户的生产数据。

不做什么

明确不做的伪需求 · WorkBuddy · 算力与 AI 基础设施场景库

24 个伪需求以及为什么不做

客户看到「四十个场景」的第一反应不是「好全」,而是挑最不靠谱那个来问。

一个伪需求会削弱旁边所有真场景的说服力 —— 所以这一页存在的意义,是让 15 个真场景更可信。

算力基础设施是伪需求的密集区,因为这个行业表面看「全是数据、该自动化」,实际上大量数据躺在没人看的系统里,而真正要紧的文书却靠人手拼。判断只需要三句话:这张表现在有人看吗?这个判定现在由谁签字?如果 AI 明天就把这件事做完了,下游的人会不会因此改变行为?第三句答不上来,就不要做。另有一类是红线:赔付承诺、割接签发、监管报送、生产动作 —— 这些动作挂在合同与监管的签字链上,AI 代替人做等于替人担责,这一组不做不是能力问题,是能让客户在监管核查与 SLA 争议中活下来的姿势问题。

5

法则一 · 一段脚本更快更准更便宜

9

法则二 · 需物理感知或对外担责

9

法则三 · 真实瓶颈不在这一步

!

最典型的一条:办公用品领用登记电子化

它看起来完全合理:纸质登记乱、统计麻烦、月底要追问还剩多少。

但制度里写着「月度汇总提交采购与财务作成本核算依据」——

现实中签完字这件事就结束了,汇总表没有人看。

把一张没人看的表加速录进系统,等于加速垃圾数据入库。

真正有价值的是另一个问题:为什么某个部门的耗材是别人的三倍。

清单逐条说明

最后一列是客户主动提出时的回应口径 —— 不是拒绝,是把他引到真场景上

伪需求命中法则

更优解 / 真实瓶颈在哪客户提出时怎么回应

SLA 赔付金额自动承诺与审批法则二 · 对外承诺担责赔付确认是对外商务承诺,签字权在商务负责人;OP-01 出的是双口径测算与争议点清单,认哪个口径是谈判的事现场话术:我们把两种口径的账都算好了,赔付数字本身得你们和客户谈 —— AI 替你认赔付,出了争议它不替你上谈判桌。割接操作单自动签发 / 高危变更自动执行法则二 · 高危变更担责73% 的数据中心故障源于变更管理失控 —— 越是高危越必须人签;我们能做的是割接方案初稿与受影响客户通知函草拟,签发栏永远留给值班主管现场话术:变更类动作出事的新闻您肯定也看过 —— 我们做的是让方案和通知函半小时就绪,签字那一下必须是人。动火作业 / 施工监护自动审批法则二 · 物理安全消防与施工安全是持证岗的法定职责,审批链涉及消防控制室值班证现场话术:这类审批有法定责任主体,我们连草稿都不代拟 —— 边界清楚才敢用。空调群控 / 制冷系统自动调节闭环法则二 · 物理执行回路制冷自控是 BA/群控系统的领地,AI 不碰执行层;

FA-04 做的是能效分析与冷机序列的优化建议,执行归群控现场话术:执行层的钱该花在群控系统上,我们花在「群控为什么没调好」的分析上。PUE 数据自动向监管报送法则二 · 主体责任报送是企业的主体责任动作,报送单上的签字是要担责的;FA-04 出的是「经得起算的数据 + 口径说明 + 计量缺口清单」,报送本身人来现场话术:监管核查时,一张诚实的计量缺口清单比一个凑出来的漂亮数字安全得多 —— 但报送这个动作,必须你们自己按。GPU 固件 / 驱动自动升级法则二 · 高危变更升级引发的集群故障在从业者实录里屡见不鲜,升级窗口要避开客户训练任务,回滚预案要人审 —— 自动化升级等于把 73% 的变更风险装到自家系统里现场话术:升级影响哪些客户任务、窗口选在哪,这个判断 AI 给建议、人拍板。故障节点自动隔离与重启法则二 · 生产动作隔离与重启是生产动作,踢错一个在跑任务的节点,损失比漏检更大;GP-03 出「建议隔离清单」,执行由集群工程师确认现场话术:我们拦在「建议」这一步

—— 客户的任务在我们机器上跑着,生产动作的最后一道闸必须是自己的工程师。机房门禁放行 / 人身安全判定法则二 · 物理安全门禁与人员安全是安保体系的法定职责,物理世界的事物理世界负责现场话术:这个真的不做,做了也不敢用。设备报废自动核销法则二 · 资产动作资产核销是财务制度动作,OP-02 的价值恰恰是「拦住不该报废的」—— 40 台有租史节点就是例子现场话术:我们管的是「别把还能下蛋的鸡杀了」,杀不杀、怎么销,财务流程说了算。纯阈值告警 / 动环越限监控法则一 · 确定性规则if-else 脚本和动环系统内置功能更快更准更便宜 —— 我们不做监控,我们做监控数据的读者(GP-03 读的是三线交叉,不是越限判断)现场话术:监控是动环系统的事,我们做的是告警之后那一段 —— 聚类、定位、写报告。值班排班 AI 优化法则一 · 确定性约束求解排班是约束求解问题,排班软件更合适;值守的痛点在记录与交接(FA-02),不在排班现场话术:排班软件几千块一年就能买 —— 钱该花在值班的人有没有支撑上。带宽 95 峰值自动核算法则一 · 计费系统职责95 峰值是确定性计费规则,计费系统一算就出;我们要人的地方在「计费口径与合同条款对不上」的判定(OP-01 的领域)现场话术:算数交给计费系统,吵架的活才是我们的。算力价格自动跟盘定价法则一 · 规则化外部数据跟盘定价是外部数据 + 规则引擎;定价策略本身是商业判断,AI 代定等于替老板做经营决策现场话术:价格可以自动监测(这个我们做简报),定价这个字得老板签。告警自动静默 / 工单自动关闭法则一 · 确定性规则 + 担责静默规则是确定性配置;「已解决」的确认连着 SLA 时效考核 —— 自动关单等于自动认结,出了争议没人为那个「已解决」负责现场话术:关单那一秒开始 SLA 时钟就停了,这个责任 AI背不动。运维监控大屏可视化法则三 · 没人看的展示层「参观时打开、平时没人盯」是 DCIM shelfware 教训的核心;大屏解决的是参观问题,不解决运营问题现场话术:先问一句 —— 这块屏除了领导参观,谁每天看?答不上来的钱不如花在日报上。AI 预测故障到小时级法则三 · 瓶颈在数据不在算法真实瓶颈在传感器覆盖与台账准确率(人工盘点准确率仅 70-85%)—— 数据底座不准,预测承诺就是砸自己招牌;GP-01/GP-03 做的是故障发生后的判断与沉淀现场话术:我们不给「明天哪台卡坏」的预言,我们给「这台卡为什么老坏」的台账 —— 后者你现在就能用。通用知识问答机器人(不带私有数据)法则三 · 厂商已覆盖通用大模型原生能力 + 厂商已覆盖,客户用免费产品即可 —— 不构成付费理由;值钱的问答必须长在客户自己的设备台账与历史工单上现场话术:通用问题问免费的就行 —— 我们贵的那部分,是知道你们家 A12 的空调修过三次。前提是「已接入 DCIM 全量数据」的智能运维问答法则三 · 前提不成立中小客户的数据底座是 Excel + 微信群 + 纸质表(盘点准确率 70-85%)—— 假设数据已结构化的方案对这类客户直接死掉现场话术:我们反过来 —— 不等系统建全,先把纸质表和微信记录变成能用台账,DCIM 哪天建好了数据照样能合进来。算力调度算法优化法则三 · 大厂平台的地盘调度优化是大型平台(有规模效应)的战场,中小玩家真实的利用率提升路径是运营侧动作(长协客户 / 算力券对接 / 混池分时)—— OP-02 的方向现场话术:调度算法是万卡平台的军备竞赛,您的痛点是 200 台机器租不出去 —— 这是运营问题,不是算法问题。自动化算力营销 / 获客外呼法则三 ·人性生意算力消纳是老板亲自跑客户与政府关系的生意;AI 能做的是让每一次拜访都有靶子(OP-02 的有租史节点清单)和弹药(SD-01 的 POC 报告)现场话术:大客户签长协看的是信任和背景 —— AI 替老板喝酒的事,真做不到。参观汇报 PPT 一键生成法则三 · 产出无真实消费者参观材料的灵魂是实景与真实数据(机房实拍 / 实时 PUE / 客户案例),模板拼装的 PPT 客户一眼看穿 —— 与大屏同属参观工程现场话术:参观接待我们出「一页纸实景数据单」(FA 系列顺手就有),PPT 美化是设计软件的事。应急预案一键生成法则三 · 模板与现状脱节「预案是验收时编的、设备换三茬预案没动过」—— 瓶颈不在生成在维护:预案要与设备台账联动(设备变更触发预案核对),纯生成只是又造一份过期文件现场话术:一键生成的预案和您现在柜子里那份唯一的区别是日期新一点 —— 有用的是「设备变了预案跟着变」的联动。全量资产自动盘点(纯软件)法则三 · 物理盘点无法软件化U 位盘点是物理动作,账实差异要人到现场核;我们能做的是盘前差异预估(台账 × 上下架记录交叉,把现场核对范围缩小)与盘后差异归因现场话术:盘点还得人去 —— 但我们可以让您的人只去核那 8% 对不上的地方,而不是满机房跑。AI 代写「整改已完成」监管回复红线 · 伪造合规凭证整改完成与否是事实问题不是文案问题;代写「已完成」而现场未整改,是把客户往虚假陈述里推现场话术:整改做没做,得现场照片和复检记录说话 —— 我们帮您把证据链理齐,「完成」两个字您自己填。

声明这套东西不承诺什么

主动讲限制比被问出来强得多

这是演示与验证资产,不是已接入生产系统的软件所有 Live Demo 页面展示的是「应该怎么跑、每一步看什么、交付什么」,使用的是真实业务格式的脱敏构造数据,不冒充任何客户的生产数据。不承诺效率提升百分比本场景库不出现任何「几天压到几分钟」「节省百分之九十」这类数字 —— 没有用客户自己的单据实测过,这种数字说出来就是砸口碑。我们讲的是可核实的能力差异:参与角色怎么变、覆盖范围多大、产出多少条。拿不到的数据会明确说拿不到分项计量缺表、历史工单无记录、需量曲线拿不到 —— 这些情况会在报告里写清「本项无法分析,建议后续建立什么记录」,而不是估一个数填上去。高风险动作只建议不执行对外承诺与赔付确认、割接与变更签发、故障节点隔离与重启、固件升级、监管报送、设备报废核销、合同签署 —— 这几类动作本场景库全部只出清单和依据,不代替人做决定,也不自动执行。产出是初稿与清单,最终签字权在人所有正式交付物都留有编制 / 审核 / 会签 / 批准签批栏,推荐意见、完成质量评定、责任认定这几栏一律留空 —— 自己给自己打分的报告,没人会信。

那哪些是真场景?15 个逐条打过分的场景,全部保留了评分口径可核

回到场景总览 →

来源说明

本场景库的痛点均有公开来源可查。网页版已对来源中的具体机构做了脱敏处理,不再逐条列出。

场景审核

场景审核 · WorkBuddy · 算力与 AI 基础设施场景库

先过场景不急着做素材

共 12 个场景。逐个点「保留 / 待讨论 / 后置」,

结果只保存在本机浏览器,可以复制出来。

建议的判断顺序:先问这件事没做好谁会生气(痛感)→

再问错了能不能当场看出来并改(能不能交给 Agent)→

最后问客户手上现有的文件够不够跑(落地难度)。

需要客户先做数据治理的场景,不要放在第一批。

清空选择

返回总览

值守

机房值守运维(动环与基础设施)

把机房每天的物理状态变成可归档、可追责、可上会的记录 —— 巡检、交接、电费、能耗四本账,一本都不能烂

4 个

FA-01

12.0

机房巡检记录结构化与巡检日报 —— 三个月的纸质表翻出同一台空调报了三次巡检表抄完就锁进铁皮柜 · 真正值钱的隐患记录从此没人再见第二次

保留

待讨论

后置

FA-02

9.0

值班交接班日志 —— 夜班 3 点处理的事,不该在交接本上只剩一行字交接班记录本平时没人翻 · 出了事故追责时所有人都想翻它

保留

待讨论

后置

FA-03

8.0

电费账单核对与需量异常检测 —— 占成本六成的电费,多数中心从没逐月核过账电费占运营成本近六成 · 财务只核总额,运维只抄总表,分项差异没人对

保留

待讨论

后置

FA-04

5.3

PUE 能耗月报 —— 报送监管的数字要经得起算,分项缺口要摊开说清PUE 月报是报送监管的合规品 · 分项计量不全时它是倒推着凑出来的

保留

待讨论

后置

集群

智算集群运维(GPU 与高速网络)

在「故障是常态」的集群里,把每次故障的判断、处置与复盘留下来 —— 换卡台账、RCA 报告、利用率日报,三样都是将来跟客户和厂商对质的证据

3 个

GP-01

8.0

GPU 故障换卡台账 —— 换了 14 张卡,哪些真坏哪些误换,不该没有人说得清GPU 故障率是 CPU 的 120 倍 · 换卡记录却散在工程师个人电脑的 Excel 里

保留

待讨论

后置

GP-02

8.3

故障 RCA 复盘报告初稿 —— 合同给你的 24 小时,不该用来翻聊天记录规范要求 24 小时内出 RCA · 现实是故障一处理完就冲进下一个火场

保留

待讨论

后置

GP-03

6.4

GPU 利用率日报 —— 利用率 93% 的集群正在变慢,这种病监控看不出来监控里利用率一片绿 · 客户的训练任务正在以 1.6 倍的时间烧钱

保留

待讨论

后置

运营

算力运营与客户服务

把建好的算力卖出去并伺候好客户 —— SLA 月报、闲置盘点、客户沟通,每一份产出都直接连着续约、赔付和老板的决策

3 个

OP-01

6.7

客户 SLA 月报与赔付预警 —— 月报是续约与赔付的依据,不是形象工程月报要凑四套系统的数 · 凑完还要跟客户谈「这段算不算免责」

保留

待讨论

后置

OP-02

6.7

闲置算力盘点与资金占用报告 —— 每天一睁眼,两百台机器在替你烧钱利用率 30% 的行业里,闲置不是新闻 · 把闲置折成每天多少钱给老板看才是

保留

待讨论

后置

OP-03

7.2

客户工单回复与进度通知 —— 客户半夜问「机器怎么了」,值班的人不该一个人扛客户问的是「我的任务怎么了」·值班工程师手上是一堆看不懂彼此的监控截图

保留

待讨论

后置

交付

售前方案与交付工程

在客户签单之前替客户把性能验证做实,在签单之后把上架验收做清 —— POC 报告和交付单是算力生意里「技术动作翻译成钱」的两端

2 个

SD-01

6.7

客户 POC 测试报告 —— 测试跑完那天出报告,而不是跑完两周后POC 测试数据散在微信截图和个人电脑里 · 拼报告的功夫比跑测试还长

保留

待讨论

后置

SD-02

5.3

机柜上架率报表与扩容测算 —— 老板拍脑袋扩容的年代,该有个测算底稿了扩容决策是销售在催、老板在拍 · 唯独没有人出过一页测算底稿

保留

待讨论

后置

审核进度未选择 12

交付说明

交付说明 · WorkBuddy · 算力与 AI 基础设施场景库

算力与 AI 基础设施场景库怎么用这套东西

这是一套售前演示与客户验证资产,不是已经接入客户生产系统的软件。

包含 4 个子角色、12 个场景、36 个内容页、

12 个 Skill 包与配套素材和预期输出。

12完整场景

36三件套页面

24明确不做的伪需求

53可核验来源

路径三种人怎么看

客户初次看

从总览按子角色选场,先看「场景引入」。三分钟看清这件事现在什么样、痛点依据在哪、产出是什么。

打开场景总览

现场演示

打开「Live Demo」逐步讲。重点讲 Agent 在哪一步拦住了 ——

一、个会在该停的地方停下来的助手,比一个永远给得出答案的助手可信得多。

看一个完整 Demo

内部选型

在「场景审核」页逐场标保留 / 待讨论 / 后置,复制结果后再决定哪些进入真实素材制作。

打开场景审核

话术现场必备的三句话

开场 · 先说 AI 做不到什么

把限制先摆出来:不承诺效率百分比、拿不到的数据会说拿不到、高风险动作只建议不执行。

主动说限制比被问出来强得多 —— 而且这一句会把后面所有内容的可信度垫起来。

中场 · 用一句话帮客户剔掉伪需求

客户提到某个表单类需求时,问一句:「这张表现在有人看吗?看完做了什么决定?」

答不上来就当场建议先不做。这一下建立的是顾问式信任 ——

客户会开始相信你不是来卖东西的。

收尾 · 三个问题要金额

「上一次客户投诉后 24 小时内交出的那份书面报告,是几个人熬到几点拼出来的?上个月的电费账单,逐项和台账核过一遍吗 —— 需量离超容还剩多少?现在闲着的那些机器,每个月折旧加资金成本是多少,有人算成账本给董事会看过吗?」

三、问都答不上来,场景就成立了。

状态已完成与未冒充完成

已经完成4 子角色 × 12 场景完整内容每场景:场景引入 / Live Demo / 能力沉淀 三页每场景:Skill 包(含输出骨架与渲染脚本)、素材、预期输出痛点逐条挂来源,可点开核对24 个伪需求逐条说明命中哪条排除法则岗位依据页说明子角色为什么这样切

明确未冒充完成尚未接入任何客户的生产系统素材是真实业务格式的脱敏构造数据,不是客户生产数据场景尚未用客户自己的原始文件实跑过(这是下一步)有来源支撑不等于完成客户一手验证没有实测前不出现任何效率提升百分比SLA 赔付确认与对外承诺、割接与变更签发、故障节点隔离与重启、固件升级、监管报送、设备报废核销、合同签署一律人工

下一步怎么往前推

第 1 步过场景12 个逐场标保留 / 待讨论 / 后置

第 2 步选 3 到 5 个按客户类型组合,优先零集成的

第 3 步要一手材料真实文件、审批链、一次出过问题的案例

第 4 步用客户文件实跑记录结果、返工点、真实耗时

第 5 步再谈系统对接此时才评估 API、权限与回写

想在你们企业跑通其中一个?

顾问会帮你判断数据够不够、从哪个场景开始最稳。

返回场景库