Changes for page ITIL v5:6C AI能力模型先别背,用它做一次“AI用例体检”
Last modified by superadmin on 2026/05/27, 20:33
Change comment:
There is no comment for this version
Summary
Details
- Page properties
-
- Content
-
... ... @@ -145,194 +145,401 @@ 145 145 === 四、6C体检清单:每个C问这几件事,就能快速识别缺口 === 146 146 147 147 148 -下面进入最关键的部分:把6C变成体检清单。 148 +下面进入最关键的部分:把6C变成体检清单。 为了可操作,这里用“每个C三到五个问题”的方式呈现,读者可以直接把自己的用例逐条过一遍。 149 149 150 150 151 -==== ====151 +==== C1:Creation(生成)——AI产出的内容与建议到底用来干什么 ==== 152 152 153 - == 第一种能力:生成(Creation)—— 让AI"创造"新内容==153 +这一类能力关心“AI产出什么、产出是否可用”。 体检要问: 154 154 155 - >**官方定义**:AI根据提示或触发器生成全新的输出。包括制作内容、代码、文档或任何其他之前不存在的工件。155 +**产出类型是什么** 156 156 157 - **Creation是大多数组织最先接触到的能力**。生成文本、摘要、说明、草稿,这是生成式AI最直接的应用方式。157 +• 是文本(例如工单回复、知识条目),还是结构化结论(例如分类、优先级),还是行动建议(例如排障步骤) 158 158 159 -** 在ITSM场景中,Creation的典型用例:**159 +**产出使用场景是什么** 160 160 161 -* 对用户的问题生成答案 162 -* 为沟通生成个性化文本,调整信息以适应利益相关方的语言、角色和偏好 163 -* 根据结构化的发布数据,自动生成发布说明、变更公告和部署计划 164 -* 起草服务描述或服务级别协议(SLA) 165 -* 根据已定义的条件或业务规则生成工作流 161 +• 面向内部员工,还是面向外部客户 166 166 167 - **这一层的关键不是AI"能不能生成",而是三件事:**163 +• 产出一旦错误,会带来什么后果 168 168 169 -* 输入是否干净:记录是否完整、字段是否规范 170 -* 输出是否可控:是否有人工审核与修改权 171 -* 责任是否清晰:生成内容谁负责发布 165 +**产出验收标准是什么** 172 172 173 - 如果没有这些控制,Creation很快会从"省时间"变成"制造错误"。167 +• 什么叫正确、可用、合规 174 174 175 - ----169 +• 如何验证,谁负责验证 176 176 177 - ==第二种能力:整理(Curation)—— 让AI帮你"收拾烂摊子" ==171 +• 是否存在“看起来很好、实际上不可用”的风险 178 178 179 - >**官方定义**:AI通过识别冗余、过时信息、不一致或不合规之处来改善现有数据或知识的质量、组织结构和相关性。173 +• 例如语气自然但事实错误 180 180 181 - 很多组织跳过这一层直接冲别的,但如果你不整理数据底座,后面的能力就都是空中楼阁。175 +• 例如回答完整但不符合组织政策 182 182 183 - **Curation的典型用例:**177 +如果这一关说不清,后面就别谈自动化,因为你连“产出是否合格”都无法判断。 184 184 185 -* 检测并标记过时的知识库文章 186 -* 检测和清理产品和服务管理数据库中的重复记录 187 -* 突出服务级别协议与供应商补充合同之间的差异 188 -* 通过检查与已批准的公司政策和规则的一致性来验证文件 189 189 190 - **在ITSM中,Curation的典型场景包括:**180 +==== C2:Curation(筛选与治理)——知识与数据是否干净,是否可追溯 ==== 191 191 192 -* 知识条目去重与合并 193 -* 将事件与问题、已知错误关联 194 -* 把历史处理经验整理成可复用知识 182 +这一类能力关心“输入与知识资产是否可靠”。 体检要问:• 195 195 196 -** 这一层的能力要求是:**184 +**输入与知识从哪里来** 197 197 198 -* 知识有生命周期 199 -* 内容有版本与责任人 200 -* AI的建议只是输入,不是最终裁决 186 +* ((( 187 +数据与知识来源是什么 188 +))) 189 +* ((( 190 +来自工单、变更记录、监控告警、知识库,还是外部文档 191 +))) 192 +* ((( 193 +是否区分人工沉淀、系统记录、外部引入、AI 生成内容 194 +))) 201 201 202 - 没有Curation,生成式AI只会让知识库更"吵"。196 +**输入是否满足质量门槛** 203 203 204 ----- 198 +* ((( 199 +数据质量是否达标 200 +))) 201 +* ((( 202 +准确性、完整性、一致性是否满足要求 203 +))) 204 +* ((( 205 +关键字段是否缺失 206 +))) 207 +* ((( 208 +指标口径、术语定义是否统一 209 +))) 205 205 206 - == 第三种能力:解释(Interpretation)—— 让AI帮你"看懂"信息 ==211 +**输入是否可追溯、可审计** 207 207 208 ->**官方定义**:AI通过总结、改写、重组或翻译,帮助用户查找、理解、定位或改进现有内容。 213 +* ((( 214 +是否可以追溯到具体来源 215 +))) 216 +* ((( 217 +是否有版本信息与更新时间 218 +))) 219 +* ((( 220 +是否支持审计与事后核查 221 +))) 209 209 210 - 这是教材中6C模型的第三种能力(注意:不少文章把这一层误写为"Classification分类",这是不准确的)。223 +**输出是否“有据可查”** 211 211 212 -**Interpretation的典型用例:** 225 +* ((( 226 +能否证明某次输出基于哪些数据或知识 227 +))) 228 +* ((( 229 +是否能回答“你凭什么这么说” 230 +))) 213 213 214 -* 为管理报告总结复杂的事件工单 215 -* 将知识文章重写以便更易理解 216 -* 使用自然语言提示语,根据特定的上下文生成摘要报告 217 -* AI增强的IT成本分类和归因,以实现准确的成本分配、分析和报告 232 +**知识是否存在污染风险** 218 218 219 -**在ITSM场景中,解释能力的价值:** 234 +* ((( 235 +是否混入未经验证或低可信内容 236 +))) 237 +* ((( 238 +AI 生成内容是否会回流到知识库 239 +))) 240 +* ((( 241 +回流前是否有审核机制与明确责任人 242 +))) 220 220 221 -* 把海量的事件日志变成管理层能看懂的摘要 222 -* 将技术语言翻译成业务语言 223 -* 帮助非技术人员用自然语言查询数据 244 +**错误输入的风险评估** 224 224 225 -**这一层的边界:** 246 +* ((( 247 +如果输入本身是错的,AI 是否会放大错误 248 +))) 249 +* ((( 250 +是否存在“越用越脏”的风险 251 +))) 226 226 227 -* AI做的是"翻译和提炼",不是"下结论" 228 -* 解释的准确性需要人来验证 229 -* 过度依赖AI解释可能导致信息失真 253 +这是AI用例最常见的“隐形瓶颈”。很多团队一上来就做Creation,结果被Curation卡死:数据不干净,输出自然不稳。 230 230 231 ----- 232 232 233 -== 第四种能力:认知(Cognition)——让AI帮你"发现隐藏的模式"==256 +==== C3:Communication(沟通)——AI如何与人协作,如何避免误导与信任损耗 ==== 234 234 235 - >**官方定义**:AI识别数据中的模式、异常或隐藏的见解,从而实现主动检测、预测和分析。258 +这一类能力关心“AI输出如何被理解与使用”。 体检要问: 236 236 237 - 注意:不少文章把这一层写成"Calculation计算",这也是偏差。教材原文是**Cognition(认知)**,它不是做数学运算,而是发现数据中人类不容易察觉的模式。260 +**输出是否足够透明** 238 238 239 -**Cognition的典型用例:** 262 +* ((( 263 +AI 的关键假设是否明确说明 264 +))) 265 +* ((( 266 +使用了哪些前提条件或默认判断 267 +))) 268 +* ((( 269 +是否清楚区分事实、推断与建议 270 +))) 240 240 241 -* 分析重大事件以更好地理解可能的原因和后果 242 -* 检测反复出现的事件趋势,这表明存在更深层次的问题 243 -* 识别流程或价值流中的瓶颈 244 -* 识别复杂环境中因变化引起的潜在问题 245 -* 根据历史使用模式和季节性趋势,预测系统工作负载的增加情况 272 +**不确定性是否被显式表达** 246 246 247 -**在ITSM中,认知能力对应的是:** 274 +* ((( 275 +是否提示置信度、适用范围或不确定性 276 +))) 277 +* ((( 278 +是否说明哪些地方可能是猜测、近似或补全 279 +))) 248 248 249 -* 异常检测 250 -* 根因推断候选路径 251 -* 趋势预测 252 -* 告警聚类与降噪 281 +**人机协作关系是否清晰** 253 253 254 -**这一层最容易被滥用:** 283 +* ((( 284 +人在这个环节中扮演什么角色 255 255 256 -* AI给出的是"发现和建议",不是"结论和判决" 257 -* 误报率需要持续校正 258 -* 如果直接让AI自动执行基于认知的决策,而没有质量门槛与回滚机制,风险会被迅速放大 286 +审核者、执行者,还是最终决策者 287 +))) 288 +* ((( 289 +哪些情况下必须人工介入 290 +))) 291 +* ((( 292 +哪些输出只能作为参考而不能直接执行 293 +))) 259 259 260 - ----295 +**对用户体验的真实影响** 261 261 262 -== 第五种能力:沟通(Communication)—— 让AI做"沟通界面" == 297 +* ((( 298 +输出更快是否真的带来更好的体验 299 +))) 300 +* ((( 301 +是否引入新的摩擦 263 263 264 - >**官方定义**:AI作为一种沟通性界面,帮助用户与服务和系统自然地互动。303 +反复确认 265 265 266 -这是智能服务台最常被寄予厚望的一层能力。 305 +表达含糊、解释成本上升 306 +))) 307 +* ((( 308 +用户是否更容易理解和行动 309 +))) 267 267 268 -** Communication的典型用例:**311 +**误导与权威错觉风险** 269 269 270 -* 聊天机器人帮助用户获得技术支持 271 -* 虚拟智能体协助提交服务请求 272 -* 为终端用户提供个性化的重大事件沟通,调整信息以适应他们的语言、角色和偏好 273 -* AI智能体进行调查、收集反馈,并应用情感分析来评估和报告利益相关方的满意度 313 +* ((( 314 +错误输出是否容易被当成“权威结论” 315 +))) 316 +* ((( 317 +是否存在“说得很像专家但其实是错的”风险 318 +))) 319 +* ((( 320 +是否通过措辞、展示方式降低误导性 321 +))) 274 274 275 -** 这一层的关键边界:**323 +**纠错与升级机制是否存在** 276 276 277 -* AI可以解释与引导 278 -* AI不应做关键承诺 279 -* 对外表达必须有模板与限制 325 +* ((( 326 +用户是否有明确的纠错入口 327 +))) 328 +* ((( 329 +是否支持升级到人工处理 330 +))) 331 +* ((( 332 +错误被发现后是否能被修正、反馈、闭环 333 +))) 280 280 281 - 成熟组织往往先让AI"解释系统在发生什么",而不是"代表组织承诺结果"。335 +很多AI用例的失败不是因为“答错”,而是因为“让人误以为答对”。 信任损耗一旦发生,恢复成本很高。 282 282 283 ----- 284 284 285 -== 第六种能力:协调(Coordination)——让AI"执行和编排操作"==338 +==== C4:Coordination(协同与编排)——AI如何触发行动,如何把工作编排起来 ==== 286 286 287 - >**官方定义**:AI自主在系统间执行、协调或触发操作,通常是响应事件、请求或模式。340 +这一类能力关心“从建议到行动”的链路是否可控。 体检要问: 288 288 289 - 这是很多组织真正开始感受到AI价值的层级,也是风险最高的一层。342 +**AI 输出会触发哪些动作** 290 290 291 -**Coordination的典型用例:** 344 +* ((( 345 +自动分派、自动升级、自动通知、自动补救等 346 +))) 347 +* ((( 348 +是建议型输出,还是直接触发执行 349 +))) 292 292 293 -* 对用户请求进行分类,并将其分配给最合适的团队 294 -* 基于实时分析自动升级高影响事件 295 -* 检测到特定错误、事态或趋势后触发补救工作流 351 +**自动执行的触发条件** 296 296 297 -**这一层的硬前提是:** 353 +* ((( 354 +触发条件与安全阈值是什么 355 +))) 356 +* ((( 357 +哪些条件满足才能自动执行 358 +))) 359 +* ((( 360 +是否区分高风险 / 低风险动作 361 +))) 298 298 299 -* 工作流清晰 300 -* 权限与责任明确 301 -* 所有动作可追溯、可回滚 363 +**异常与失控时的处理机制** 302 302 303 -没有清晰工作流,AI只会把混乱编排得更快。 365 +* ((( 366 +触发异常时如何停止与降级 367 +))) 368 +* ((( 369 +是否支持人工中断 370 +))) 371 +* ((( 372 +是否有兜底路径 373 +))) 304 304 305 - ----375 +**与现有工作流的对齐程度** 306 306 307 -== 用6C做"AI用例体检":一张真正实用的清单 == 377 +* ((( 378 +与现有工作流如何对齐 379 +))) 380 +* ((( 381 +是否会制造新的交接与等待 382 +))) 383 +* ((( 384 +是否引入隐形瓶颈 385 +))) 308 308 309 - 作为ITSM或平台负责人,你可以用6C模型做三件非常现实的事:387 +**与现有工具链的兼容性** 310 310 311 -**第一件:盘点现状——我们在哪几层已经有能力,哪些只是概念** 389 +* ((( 390 +是否与现有工具链冲突 391 +))) 392 +* ((( 393 +是否绕过原有控制点 394 +))) 312 312 313 -|=能力|=典型场景|=我们做到没有|=成熟度 314 -|生成|自动生成事件摘要、变更说明|☐|低/中/高 315 -|整理|知识条目去重与合并|☐|低/中/高 316 -|解释|为管理报告总结事件工单|☐|低/中/高 317 -|认知|检测事件趋势、识别瓶颈|☐|低/中/高 318 -|沟通|聊天机器人技术支持|☐|低/中/高 319 -|协调|自动分派、自动升级|☐|低/中/高 396 +**问责与授权机制** 320 320 321 -**第二件:排定顺序——下一步补哪一层最有价值、风险最可控** 398 +* ((( 399 +自动执行动作的授权人是谁 400 +))) 401 +* ((( 402 +授权是一次性的,还是持续有效的 403 +))) 404 +* ((( 405 +出错时责任链路是否清晰 406 +))) 322 322 323 - 6C模型的价值在于:它给你一个很合理的推进顺序。不是"先上哪个技术",而是"先建哪类能力"。先夯实数据与责任(生成→整理→解释),再引入认知与协调,AI才会成为放大组织能力的杠杆,而不是放大风险的放大器。408 +Coordination做不好,AI就只能停留在“聊天机器人”层,无法形成真正的效率闭环;但Coordination做得太快,又会把风险放大,所以治理边界必须同时到位。 324 324 325 -**第三件:对齐治理——哪些层级必须加强人工确认与审计** 326 326 327 - ITIL第5版强调治理,不是为了给你加审批,而是为了让AI能力可控、可追溯、可纠偏。对AI能力来说,治理至少要回答四个问题:411 +==== C5:Control(控制与治理)——风险边界、授权、问责、可审计性是否完整 ==== 328 328 329 -* **责任**:AI建议错了谁负责,自动操作错了谁负责 330 -* **边界**:哪些场景允许自动,哪些必须人工确认 331 -* **审计**:决策依据如何记录,事后如何追溯 332 -* **纠偏**:模型如何被反馈、如何更新、如何防止旧错误复发 413 +这一类能力关心“在可控范围内获得收益”。 体检要问: 333 333 415 +**风险边界是否明确** 334 334 417 +* ((( 418 +哪些决策可自动化 419 +))) 420 +* ((( 421 +哪些必须人工批准 422 +))) 335 335 424 +**授权与权限控制** 425 + 426 +* ((( 427 +授权机制是否清楚 428 +))) 429 +* ((( 430 +谁是授权人 431 +))) 432 +* ((( 433 +授权条件是什么 434 +))) 435 + 436 +**问责机制是否可执行** 437 + 438 +* ((( 439 +谁承担问责 440 +))) 441 +* ((( 442 +如何追溯到决策链路 443 +))) 444 +* ((( 445 +是否存在“无人负责区” 446 +))) 447 + 448 +**可审计性是否满足要求** 449 + 450 +* ((( 451 +输入、决策、执行证据是否完整 452 +))) 453 +* ((( 454 +是否支持事后审计与复盘 455 +))) 456 + 457 +**违规与异常处理机制** 458 + 459 +* ((( 460 +违规与异常如何处理 461 +))) 462 +* ((( 463 +触发器是否明确 464 +))) 465 +* ((( 466 +升级路径是否清晰 467 +))) 468 +* ((( 469 +是否具备纠偏机制 470 +))) 471 + 472 +Control是“必修课”的核心。没有Control,前面四个C做得越好,风险放大得越快。 473 + 474 + 475 +==== C6:持续改进(持续改进)——上线之后如何变得更好,而不是更乱 ==== 476 + 477 +这一类能力关心“长期可持续”。 体检要问: 478 + 479 +**度量体系是什么** 480 + 481 +* ((( 482 +端到端周期时间、等待占比、返工次数、满意度是否纳入 483 +))) 484 +* ((( 485 +指标口径是否明确、能否长期稳定采集 486 +))) 487 + 488 +**误差与偏差如何被捕捉** 489 + 490 +* ((( 491 +误差与偏差如何被捕捉 492 +))) 493 +* ((( 494 +是靠抽检、反馈、对照实验,还是自动监测 495 +))) 496 + 497 +**哪些场景最容易出错** 498 + 499 +* ((( 500 +哪些场景最容易出错 501 +))) 502 +* ((( 503 +是否识别高风险/高复杂度场景并单独监控 504 +))) 505 + 506 +**错误类型如何分类与统计** 507 + 508 +* ((( 509 +错误类型如何分类与统计 510 +))) 511 +* ((( 512 +是否能区分“事实错误、策略不符、流程不匹配、体验误导”等类别 513 +))) 514 + 515 +**复盘节奏是什么** 516 + 517 +* ((( 518 +复盘频率 519 +))) 520 +* ((( 521 +参与角色 522 +))) 523 +* ((( 524 +输出物是什么(结论、行动项、变更清单等) 525 +))) 526 + 527 +**迭代策略如何制定** 528 + 529 +* ((( 530 +迭代策略如何制定 531 +))) 532 +* ((( 533 +先修数据还是先调策略 534 +))) 535 +* ((( 536 +先收缩边界还是先增加控制点 537 +))) 538 + 539 +持续改进缺失时,AI用例常见路径是:上线初期看起来很强,三个月后被噪声与例外打垮,最后回到人工兜底,组织对AI产生疲劳与不信任。 540 + 541 + 542 + 336 336 === 五、体检结论怎么写才有用:给出“能做、怎么做、先做什么” === 337 337 338 338