第 1 题
为什么「接入了多少个部门、建了多少块大屏」这类指标不足以说明项目成效？
尚未检查本题。
查看答案与评价要点
参考答案：它们衡量的是投入而非产出。系统建成后若一线工作流程未改变，平台可能只在事后汇报时被使用，业务实际没有改善。成效应当用业务侧的可量化变化来衡量，例如某类事件的平均发现时间、重复上报率或人工巡查工作量的变化，并在立项时定义基线采集方式。
评价要点：指出这类指标衡量投入而非产出；举出业务未改变的具体表现；提出用可量化的业务侧指标并预先定义基线
浏览器未允许保存进度；当前为只读学习模式。
第 15 周 · 专题
第15周：AI城市与城市智能体专题
城市大脑、数字孪生、一网统管与AI场景闭环
周目标：理解AI城市总体架构、关键平台与场景建设方法，能设计城市治理智能化闭环
课程成果：CO7 CO8
已学习 0 / 7 天
本周 7 个学习日
Day 99
智慧城市到AI城市
建议时长：75 分钟
本日 CO：CO7 CO8
本日概要
早期智慧城市建设的重心在感知与联网——铺设摄像头、传感器，把数据汇聚到中心。它带来的问题是「建了很多系统，但业务没有真正改变」：各系统之间数据不通，展示大屏做得很漂亮，一线处置流程却照旧。所谓 AI 城市，强调的是从「看得见」转向「处置得了」：以具体场景的闭环为单位建设，每个场景都要说清楚感知什么、判断什么、由谁处置、如何核验结果。判断一个项目属于哪一类，最直接的问题是：它有没有改变某个岗位的日常工作方式，以及这种改变能否被量化。
听书与视频
本日听书
5 分钟 · MP3 · 双主持人讲解
B 站讲解
学习目标
- 能说明早期智慧城市建设的典型问题及其成因
- 能用「感知—判断—处置—核验」四段描述一个场景闭环
- 能判断一个项目是否真正改变了业务流程，而非只增加了展示
- 能为一个场景写出可量化的成效指标
核心讲解
从看得见到处置得了
早期建设普遍以设备与平台为交付物：装了多少路视频、接入了多少个部门、建了多少块大屏。这些指标容易统计，也容易验收，但它们衡量的是投入而不是产出。常见的结果是系统上线后使用率很低——一线人员的工作流程没有改变，仍靠电话与纸质台账处置事件，平台只是在事后被用来汇报。
以场景闭环为单位建设，意味着交付物从「系统」变成「某类事件的处置能力」。每个场景要回答四个问题：感知什么（数据从哪来、覆盖率多少）、判断什么（判定规则或模型、误报率如何）、由谁处置（对应到具体岗位与流程）、如何核验（处置结果如何回流、是否闭环）。四个问题都有答案，项目才可能真正改变业务；缺任何一个，最终都会退化成一块展示大屏。
用可量化的改变检验
检验一个项目是否有效，最直接的问题是：它改变了哪个岗位的日常工作方式？改变前后能否用数字说明？例如某类事件的平均发现时间从若干小时缩短到若干分钟、重复上报率下降、或者一线人工巡查工作量减少。这些指标必须在项目立项时就定义好，并明确基线值的采集方式，否则事后无法证明成效。
同时要警惕指标被优化到失真。只考核「事件发现数量」会诱导系统把误报也算作发现；只考核「处置完成率」会诱导把难处理的事件转为不予受理。合理做法与前面几周一致：设计一组互相制衡的指标，例如同时看发现数量、误报率、处置完成率与复发率，并定期做人工抽检核对。
实践任务
用三句话说明 AI 城市与传统智慧城市的差别，并各举一个正反例说明「有闭环」与「只有展示」的区别。
- 用三句话写出 AI 城市与传统智慧城市的差别，要求每句都能指向可观察的区别而非口号。
- 举一个「有闭环」的正例，按感知、判断、处置、核验四段拆解并说明每段的责任主体。
- 举一个「只有展示」的反例，指出它在四段中缺失了哪一段，以及由此导致的实际后果。
- 为正例设计一组互相制衡的成效指标（不少于三项），说明基线值如何采集、由谁核对。
自测与答案
第 2 题
一个城市治理场景的闭环应当包含哪四段？缺失其中一段会有什么后果？
尚未检查本题。
查看答案与评价要点
参考答案：感知、判断、处置、核验四段。缺少处置环节时，系统只能发现问题而无人跟进，退化为展示；缺少核验时，无法确认问题是否真正解决，也无法把结果回流用于改进判断规则，误报会长期存在且无人纠正。
评价要点：完整列出四段；说明缺处置会退化为展示；说明缺核验导致无法改进与纠错
尚未完成自测。
今日完成标准
- 提交三句差别说明，每句指向可观察的区别
- 提交正反两例的四段拆解，明确责任主体与缺失环节的后果
- 提交不少于三项互相制衡的成效指标及其基线采集方式
常见错误与纠正提示
- 以设备数量、接入部门数作为成效指标
- 场景设计缺少核验环节，误报长期无人纠正
- 只考核单一指标，诱导把误报计入发现或把难题转为不予受理
分层任务
基础任务
在教师给出的两个案例中判断哪个有闭环，并指出缺失环节。
标准任务
独立完成正反例拆解与制衡指标设计。
挑战任务
为一个已有的展示型系统设计改造路径：补齐哪一段、涉及哪些岗位、如何验证改造后确实形成闭环。
关联知识点
延伸阅读
- 国务院关于印发“十四五”数字经济发展规划的通知（中国政府网政策文件）
- 国务院关于加强数字政府建设的指导意见（中国政府网政策文件）
学习状态：未学习
Day 100
四横两纵总体架构
建议时长：75 分钟
本日 CO：CO7 CO8
本日概要
城市级信息化方案常用分层加纵向支撑的结构来描述：横向自下而上大致是感知层、网络与算力层、数据与平台层、应用与场景层；纵向贯穿的是标准规范体系与安全保障体系。这个结构的价值不在于图好看，而在于它强制回答两类问题——每一横层的边界与接口是什么，以及两条纵向体系如何在每一层落地。实践中最容易出问题的是数据与平台层：它既要承接下层的异构数据，又要支撑上层多样的场景，边界不清时会变成什么都往里塞的「大杂烩」，最终难以维护。
听书与视频
本日听书
6 分钟 · MP3 · 双主持人讲解
B 站讲解
学习目标
- 能画出四横两纵的总体架构并说明各层职责边界
- 能为每一层定义对外接口与它不应承担的职责
- 能说明标准规范体系与安全保障体系如何在每一层落地
- 能识别数据与平台层边界不清导致的典型问题
核心讲解
四横：各层的边界
感知层负责数据采集，包括视频、物联设备与业务系统上报，它的关键指标是覆盖率、可用率与数据质量，不应承担业务判断。网络与算力层提供连通与计算资源，包括政务网络、云资源与边缘节点，它的关键是可用性与资源隔离。数据与平台层负责汇聚、治理与共享，提供数据目录、质量校验、权限管控与通用能力（如视频结构化、地理信息服务）。应用与场景层面向具体业务，承担场景闭环的落地。
边界不清的典型表现在数据与平台层：把只服务单个场景的业务逻辑写进平台，久而久之平台承载了大量互相冲突的特例，升级困难且没人敢改。合理做法是为平台层设定准入规则——只有被两个以上场景复用的能力才下沉到平台，单场景逻辑留在应用层。这条规则应当写进架构文档并在评审中执行。
两纵：让体系可落地
标准规范体系不是一册放在柜子里的文档，而应当在每一层有具体落点：感知层的设备接入规范与数据格式标准、网络层的编址与安全域划分规范、数据层的元数据与共享交换标准、应用层的接口与服务规范。国家标准全文公开系统可以用来检索相关国家标准的现行版本，引用时应记录标准号与查询日期，因为标准会修订。
安全保障体系同样要逐层落地：感知层的设备认证与固件管理、网络层的分区分域与访问控制、数据层的分级分类与权限审计、应用层的身份认证与操作留痕。个人信息保护与数据安全的法定要求贯穿其中——涉及个人信息的处理需要有合法性基础并遵循最小必要原则，数据分类分级与安全责任也有明确的法律依据。架构文档中应当把每一层的安全措施与其对应的法定要求关联起来，而不是笼统写「符合相关法律法规」。
实践任务
绘制四横两纵架构图，为每一横层标注三个典型组件与对外接口，并说明两条纵向体系在各层的具体落地方式。
- 绘制四横两纵架构图，为每一横层写出职责边界、三个典型组件与对外提供的接口。
- 为每一横层额外写出「本层不应承担的职责」，并为数据与平台层制定能力下沉的准入规则。
- 为标准规范体系在四层各找一个具体落点，其中至少一项通过国家标准全文公开系统检索并记录标准号与查询日期。
- 为安全保障体系在四层各写出具体措施，并把涉及个人信息与数据安全的措施与相应法定要求逐条关联。
自测与答案
第 1 题
数据与平台层边界不清会导致什么问题？应当如何约束？
尚未检查本题。
查看答案与评价要点
参考答案：会把只服务单个场景的业务逻辑写进平台，长期积累大量互相冲突的特例，导致平台升级困难、无人敢改。应设定能力下沉的准入规则：只有被两个以上场景复用的能力才进入平台层，单场景逻辑留在应用层，并把该规则写进架构文档在评审中执行。
评价要点：指出单场景逻辑下沉造成特例堆积；说明后果是升级困难难以维护；给出可执行的准入规则
第 2 题
为什么架构文档中不能笼统写「符合相关法律法规」？
尚未检查本题。
查看答案与评价要点
参考答案：笼统表述无法被检查，也无法指导实施。应当把每一层的具体安全措施与对应的法定要求关联起来——例如涉及个人信息处理的环节要说明合法性基础与最小必要原则如何落实，数据分类分级要对应到具体的管理要求，这样评审时才能逐条核对是否真正做到。
评价要点：指出笼统表述无法检查与指导实施；要求措施与法定要求逐条关联；举出个人信息或数据分级等具体例子
尚未完成自测。
今日完成标准
- 提交四横两纵架构图，每层含职责边界、三个典型组件与对外接口
- 提交每层的「不应承担职责」清单与平台层能力下沉准入规则
- 提交标准与安全两条纵向体系在四层的具体落点，标准项含标准号与查询日期
常见错误与纠正提示
- 架构图只有方框没有接口与边界，无法指导实施
- 把单场景业务逻辑下沉到平台层，形成难以维护的特例集合
- 安全与合规部分只写「符合相关法律法规」，无法逐条核对
分层任务
基础任务
在教师提供的架构图上补齐两层的组件与接口。
标准任务
独立完成四横两纵架构图、边界清单与两条纵向体系的落点。
挑战任务
为平台层写一份能力下沉评审表：申请下沉需提供哪些材料、评审看哪些条件、拒绝时如何反馈。
关联知识点
延伸阅读
- 国务院关于加强数字政府建设的指导意见（中国政府网政策文件）
- 国家标准全文公开系统（国家市场监督管理总局标准查询入口）
- 中华人民共和国个人信息保护法（中央网信办官网发布全文）
学习状态：未学习
Day 101
城市大脑与数据中台
建议时长：75 分钟
本日 CO：CO7 CO8
本日概要
城市大脑这类平台要真正可用，核心不是算法而是数据供给与权责关系。数据侧的难点是「数据在各部门手里、格式各异、更新频率不同、共享需要依据」；平台建设中最耗时的往往是数据接入与治理，而不是模型训练。权责侧的难点是：平台发现的问题由谁处置、跨部门事件如何流转、处置结果由谁确认。技术上可以把平台的能力拆成四类——数据汇聚与治理、态势呈现、辅助研判、以及指挥调度，其中只有前两类是纯技术问题，后两类必须与既有的行政流程对齐才能落地。
听书与视频
本日听书
6 分钟 · MP3 · 双主持人讲解
B 站讲解
学习目标
- 能把城市级平台的能力拆分为四类并说明各自的交付物
- 能识别数据接入与治理中的主要障碍及其应对
- 能说明辅助研判与指挥调度为何必须与行政流程对齐
- 能为跨部门事件设计流转与确认机制
核心讲解
数据供给是主要工作量
平台建设的实际工作量分布常与预期相反：数据接入、清洗、对齐与持续治理往往占大头，模型与算法反而占比较小。原因在于数据分散在不同部门与系统中，格式、口径、更新频率各不相同；同一个「人口数」在不同系统里的定义可能不同，直接汇总会得到无法解释的结果。因此平台建设的第一步应当是数据目录与口径梳理，而不是先做展示界面。
数据共享还需要依据。跨部门调取数据需要明确的授权路径与用途限定，涉及个人信息时还要有合法性基础并遵循最小必要原则。技术上应当支持按字段级授权与用途标记，使「谁在什么授权下为什么用途取用了哪些数据」可被审计。这既是合规要求，也是让各部门愿意共享数据的前提——没有清晰的权限与留痕，数据提供方通常不愿开放。
研判与调度必须对齐流程
四类能力中，数据汇聚治理与态势呈现主要是技术问题：把数据接进来、治理好、以合适的方式展示。辅助研判开始涉及判断：模型给出的风险提示或根因候选，需要有人采信并承担后果，因此必须明确它是建议而非决定，并保留研判依据供复核。指挥调度则完全嵌入行政流程：事件派发给哪个部门、响应时限是多久、超时如何升级、结果由谁确认，这些在既有制度中通常已有规定，平台应当承接而不是另建一套。
跨部门事件是最容易卡住的环节。设计时要明确三件事：首接责任如何确定（避免互相推诿）、跨部门协同时的主办与协办关系、以及处置结果的确认主体。平台的作用是让这些关系可见、时限可计、结果可追溯，而不是替代行政决定。把这一点写清楚，也能避免项目在验收时被质疑「越权」。
实践任务
拆解一个城市级平台应具备的四类能力，为每类写出交付物、依赖条件与权责归属，并识别其中的行政流程约束。
- 把平台能力拆为数据汇聚治理、态势呈现、辅助研判、指挥调度四类，为每类写出具体交付物。
- 为数据汇聚治理列出至少五项数据来源，逐项标注提供部门、更新频率、口径风险与共享依据。
- 为辅助研判设计依据留存方案：模型给出结论时同时保留哪些信息供人工复核。
- 为一类跨部门事件设计流转机制：首接责任确定方式、主办协办关系、响应时限、超时升级路径与结果确认主体。
自测与答案
第 1 题
为什么城市级平台建设的第一步应当是数据目录与口径梳理，而不是先做展示界面？
尚未检查本题。
查看答案与评价要点
参考答案：数据分散在不同部门与系统，格式、口径与更新频率各异，同一指标在不同系统中的定义可能不同，直接汇总会得到无法解释的结果。先梳理数据目录与口径，才能保证展示与研判基于一致的口径；否则界面做得越漂亮，误导性越强。
评价要点：指出数据分散且口径不一；说明直接汇总结果无法解释；指出先做展示会放大误导
第 2 题
平台的指挥调度能力为什么必须承接既有行政流程而不是另建一套？
尚未检查本题。
查看答案与评价要点
参考答案：事件派发对象、响应时限、超时升级与结果确认在既有制度中通常已有规定，另建一套会与制度冲突，导致一线不按平台流程执行，或产生越权争议。平台的作用是让既有关系可见、时限可计、结果可追溯，而不是替代行政决定。
评价要点：指出既有制度已有规定；说明另建流程会导致冲突或越权争议；把平台定位为让流程可见可追溯
尚未完成自测。
今日完成标准
- 提交四类能力的交付物清单与依赖条件
- 提交不少于五项数据来源的部门、频率、口径风险与共享依据
- 提交研判依据留存方案与一类跨部门事件的完整流转机制设计
常见错误与纠正提示
- 低估数据接入与治理的工作量，把重心放在算法与界面上
- 跨部门数据共享无授权路径与用途限定，数据提供方不愿开放
- 平台另建一套调度流程，与既有制度冲突并引发越权争议
分层任务
基础任务
在教师给出的数据来源清单上标注口径风险与共享依据。
标准任务
独立完成四类能力拆解、数据来源梳理与跨部门流转设计。
挑战任务
为字段级授权与用途标记设计审计方案，说明如何回答「谁在什么授权下为什么用途取用了哪些数据」。
关联知识点
延伸阅读
- 国务院关于加强数字政府建设的指导意见（中国政府网政策文件）
- 中华人民共和国个人信息保护法（中央网信办官网发布全文）
- 中华人民共和国数据安全法（中央网信办官网发布全文）
学习状态：未学习
Day 102
一网统管场景设计
建议时长：75 分钟
本日 CO：CO7 CO8
本日概要
一个可落地的治理场景必须是完整闭环，而不是一个识别模型。以占道经营治理为例，闭环包括：前端识别产生疑似事件、系统做初步过滤与去重、事件派发到属地street并明确时限、处置人员现场核实并采取措施、处置结果回传并附现场佐证、系统核验并关闭事件、以及对误报进行标记回流用于改进模型。设计时最容易忽略的是三件事——误报如何被标记与利用、同一地点重复事件如何聚合、以及处置人员的实际工作量是否可承受。忽略任何一件，场景上线后都会很快被一线放弃使用。
听书与视频
本日听书
6 分钟 · MP3 · 双主持人讲解
B 站讲解
学习目标
- 能把一个治理场景拆解为完整闭环的各个环节
- 能为每个环节明确输入输出、责任主体与时限
- 能设计误报标记与回流机制，使模型可持续改进
- 能估算处置侧的工作量并设计控制手段，避免场景被弃用
核心讲解
闭环的每一环都要有主体
识别只是起点。一条完整链路上，每个环节都要写清楚谁负责、输入是什么、输出是什么、时限多久。前端识别输出疑似事件；系统过滤负责去重与置信度筛选，输出待派发事件；派发环节要确定属地与责任岗位；处置环节要求现场核实并记录佐证；核验环节确认问题是否消除；归档环节把结果与误报标记写回。链路上任何一环没有明确主体，事件都会卡在那里。
时限设计要现实。设定过短的处置时限会导致一线为达标而草率处置或直接标记为「无法处置」，指标好看但问题没解决。合理做法是先用一段时间的实际数据测算处置耗时分布，再据此设定分级时限，并对超时情况区分「客观困难」与「未响应」两类分别处理。
误报与工作量决定存续
误报是识别类场景的常态。关键不是消灭误报，而是让误报可以被低成本标记并回流：处置人员到现场发现不属实时，应当能一键标记原因（如识别错误、事件已自行消除、不属于本场景范围），这些标记既用于统计准确率，也作为改进模型的样本。没有这条回路，误报率会长期停在初始水平，一线的信任很快耗尽。
工作量控制同样决定场景存亡。上线前应当估算：按当前识别灵敏度，每天会产生多少事件、分摊到每个处置岗位是多少、是否超出其可承受范围。若超出，可以通过提高置信度阈值、按时段或区域分批推送、或对同一地点的重复事件做聚合来控制。把这个估算写进方案并在试运行中校准，比上线后再补救有效得多。
实践任务
为一个具体治理场景设计完整闭环，逐环节写出输入输出、责任主体与时限，并说明误报处理与工作量控制方案。
- 为选定场景画出完整闭环链路，逐环节写出输入、输出、责任主体与时限。
- 设计误报标记机制：标记选项、操作成本、统计口径，以及标记如何回流用于模型改进。
- 设计重复事件聚合规则：同一地点或同一对象在多长时间窗口内的事件如何合并，避免重复派发。
- 估算日均事件量与分摊到每个处置岗位的工作量，若超出承受范围给出至少两种控制手段，并说明试运行期的校准方式。
自测与答案
第 1 题
为什么误报标记机制对识别类治理场景至关重要？
尚未检查本题。
查看答案与评价要点
参考答案：误报是常态，若处置人员无法低成本地标记误报及其原因，就既无法统计真实准确率，也拿不到改进模型所需的样本，误报率会长期停在初始水平。一线在反复处置无效事件后会失去信任并放弃使用，场景随之失效。
评价要点：指出误报是常态无法消灭；说明缺少标记则无法统计与改进；指出一线信任耗尽会导致场景被弃用
第 2 题
设定过短的处置时限会带来什么后果？应当如何合理设定？
尚未检查本题。
查看答案与评价要点
参考答案：会诱导一线为达标而草率处置或直接标记为无法处置，指标好看但问题未解决。合理做法是先用一段时间的实际数据测算处置耗时分布，据此设定分级时限，并对超时情况区分客观困难与未响应两类分别处理。
评价要点：指出过短时限诱导草率处置或规避；提出基于实际耗时分布设定分级时限；要求区分客观困难与未响应
尚未完成自测。
今日完成标准
- 提交完整闭环链路图，每环节含输入输出、责任主体与时限
- 提交误报标记机制与回流方案，含标记选项与统计口径
- 提交重复事件聚合规则与工作量估算及至少两种控制手段
常见错误与纠正提示
- 只交付识别模型，不设计派发、处置、核验与归档环节
- 无误报标记回路，模型长期得不到改进且一线失去信任
- 不估算处置工作量，事件量超出承受范围导致场景被弃用
分层任务
基础任务
在教师给出的链路骨架上补齐三个环节的责任主体与时限。
标准任务
独立完成闭环设计、误报机制、聚合规则与工作量估算。
挑战任务
设计一次试运行方案：试运行范围、时长、需要采集的数据、以及据此调整灵敏度与时限的判据。
关联知识点
延伸阅读
- 国务院关于加强数字政府建设的指导意见（中国政府网政策文件）
- OpenTelemetry: Signals（OpenTelemetry 官方文档）
学习状态：未学习
Day 103
交通、应急与生态场景
建议时长：75 分钟
本日 CO：CO7 CO8
本日概要
交通、应急与生态三类场景对时效性与准确性的要求差别很大，方案不能套用同一模板。交通类通常数据密度高、反馈快，适合较高频的模型迭代；应急类事件稀少但后果严重，重点不在预测精度而在预案完备与响应可靠，且必须假设通信与电力可能中断；生态类多为长周期监测，重点在数据的连续性与口径一致，指标要能支撑跨年度比较。共同点是都要求把预测结果转化为具体的处置动作——一个只输出风险等级而不说明「谁在什么时候做什么」的模型，在这三类场景中都无法产生实际价值。
听书与视频
本日听书
6 分钟 · MP3 · 双主持人讲解
B 站讲解
学习目标
- 能比较交通、应急、生态三类场景在时效性与准确性要求上的差异
- 能把预测结果转化为分级的、可执行的处置动作
- 能为应急类场景设计通信或电力中断时的降级方案
- 能为长周期监测设计保证口径一致与数据连续的机制
核心讲解
三类场景的不同重心
交通类场景数据密度高、反馈周期短，模型效果可以较快验证并迭代；主要挑战是数据质量（设备故障、覆盖盲区）与高峰期的实时性。应急类场景则相反：事件本身稀少，训练样本不足，模型精度难以显著提升，真正决定成效的是预案是否完备、责任是否明确、以及在极端条件下系统是否仍可用——因此设计时必须假设通信中断、电力受限，并准备离线可执行的处置流程。
生态类场景多为长周期监测，单次数据的时效性要求不高，但要求指标口径在多年间保持一致，否则跨年度比较毫无意义。设备更换、算法升级、点位调整都会造成口径断裂，必须在变更时同时记录并保留可换算的关系。这类场景的失败通常不是技术问题，而是缺少长期的口径管理。
从风险等级到具体动作
一个只输出「高风险」的系统对一线没有帮助。有效的做法是把等级与动作绑定：达到某一级时，由哪个岗位在多长时间内完成哪些具体动作（如布设警示、封闭路段、通知周边、启动排涝设备），并明确升级与解除的条件。这样模型的输出才进入了实际流程，也才能通过动作执行情况来评估成效。
对暴雨内涝这类场景，还要考虑预警的两类错误代价不对称：漏报可能造成人员风险，误报造成的是资源浪费与信任消耗。因此阈值设定应当偏向保守，同时通过分级动作降低误报成本——低等级只做提示与准备，高等级才启动高成本动作。这种设计比追求单一阈值下的最优准确率更符合实际。
实践任务
为暴雨内涝预警设计完整方案：感知数据、预测方法、分级处置动作与成效指标，并说明通信中断时的降级方案。
- 列出暴雨内涝预警所需的感知数据来源，逐项标注覆盖范围、更新频率与故障时的影响。
- 说明预测方法与其局限，明确它输出什么（概率、等级还是时间窗）以及不确定性如何表达。
- 设计分级处置动作表：每一级对应的责任岗位、时限、具体动作，以及升级与解除条件。
- 设计通信或电力中断时的降级方案，并为该场景定义成效指标（含漏报与误报的分别统计与代价说明）。
自测与答案
第 1 题
应急类场景为什么不应把提升模型精度作为主要目标？
尚未检查本题。
查看答案与评价要点
参考答案：应急事件稀少，训练样本严重不足，精度提升空间有限。真正决定成效的是预案是否完备、责任是否明确、以及在通信或电力中断等极端条件下系统与流程是否仍可执行。因此重心应放在分级动作设计、责任落实与离线可执行的降级方案上。
评价要点：指出样本稀少限制精度提升；把重心转向预案与责任落实；要求考虑极端条件下的可用性
第 2 题
生态类长周期监测最常见的失败原因是什么？如何避免？
尚未检查本题。
查看答案与评价要点
参考答案：最常见的是口径断裂：设备更换、算法升级或点位调整改变了指标含义，导致跨年度数据无法比较。避免方式是把口径管理制度化——每次变更同时记录变更内容、生效时间与新旧口径的换算关系，并在数据产品中标注口径版本，使跨期比较时能做相应处理。
评价要点：指出口径断裂导致跨年度不可比；列出设备、算法或点位变更等原因；提出记录变更与换算关系并标注口径版本
尚未完成自测。
今日完成标准
- 提交感知数据清单，含覆盖范围、更新频率与故障影响
- 提交预测方法说明及其不确定性表达方式
- 提交分级处置动作表与降级方案，成效指标含漏报误报的分别统计与代价说明
常见错误与纠正提示
- 把三类场景套用同一套方案模板
- 系统只输出风险等级，不绑定具体的责任岗位与处置动作
- 长期监测中变更设备或算法却不记录口径换算关系
分层任务
基础任务
在教师给出的数据清单上完成分级动作表的填写。
标准任务
独立完成三类场景对比、完整方案与降级设计。
挑战任务
为该场景设计一次桌面推演：设定情景、参演角色、需要检验的环节与判定标准。
关联知识点
延伸阅读
- 国务院关于加强数字政府建设的指导意见（中国政府网政策文件）
- OpenTelemetry: Signals（OpenTelemetry 官方文档）
- 国家标准全文公开系统（国家市场监督管理总局标准查询入口）
学习状态：未学习
Day 104
AI城市项目建设与评估
建议时长：75 分钟
本日 CO：CO7 CO8
本日概要
城市级项目的建设与评估要回答一个很实际的问题：钱花在哪、成效怎么算。常见的失败模式是重建设轻运营——一次性投入建成系统，却没有持续的运维、数据更新与迭代预算，两三年后系统逐渐失效。评估体系应当同时包含建设期指标与运营期指标：建设期看交付完整性与验收标准，运营期看使用率、数据鲜活度、场景成效与运维响应。对中小规模城市尤其重要的是量力而行——先做两三个能形成闭环、能量化成效的场景，比铺开十几个都停在展示阶段更有价值。
听书与视频
本日听书
6 分钟 · MP3 · 双主持人讲解
B 站讲解
学习目标
- 能识别「重建设轻运营」的表现与后果
- 能设计同时覆盖建设期与运营期的评估指标体系
- 能为一个城市规模选择合适数量的场景并说明优先级依据
- 能给出包含持续运营成本的预算结构
核心讲解
运营预算不是可选项
系统建成只是开始。持续投入包括：设备维护与更换、数据接入的适配变更（上游系统升级会导致接口变动）、模型的定期重训与效果校准、以及一线使用支持与培训。这些若没有预算保障，系统会以可预期的方式衰减——数据逐渐过期、模型效果下降、一线遇到问题无人响应，最终回到原有的工作方式。因此立项时就应当明确运营期的年度投入比例与来源。
评估指标要区分建设期与运营期。建设期看交付物是否完整、验收标准是否达成、以及是否具备可运营的条件（文档、培训、运维流程）。运营期看真实使用情况：活跃使用率、数据更新及时率、场景的业务成效、以及故障响应时长。只有建设期验收而没有运营期评估的项目，成效无从判断。
少而闭环胜过多而展示
资源有限时，场景数量的取舍很关键。做三个能形成完整闭环、能量化成效的场景，通常比铺开十几个都停在识别与展示阶段更有价值——前者能积累可复用的数据治理与流程对接经验，后者只能积累演示素材。选择场景时可以用三条判据排序：业务痛点是否明确、数据是否已经可得、以及处置流程是否清晰，三条都满足的优先做。
成效必须量化并有基线。立项时就要定义每个场景的成效指标与基线值采集方式，例如某类事件的平均处置时长、重复发生率、或人工巡查工作量。没有基线，项目结束时只能用「效率显著提升」这类无法核实的表述。基线采集往往需要在建设前就开始，这一点容易被忽略。
实践任务
为一个中等规模城市设计三个 AI 城市场景，给出量化成效指标、建设与运营预算结构，并说明优先级依据。
- 为一个中等规模城市选择三个场景，用业务痛点、数据可得性、流程清晰度三条判据打分并排序。
- 为每个场景定义两到三项量化成效指标，说明基线值的采集方式与采集时点。
- 设计预算结构，明确区分一次性建设投入与年度运营投入，并给出运营占比的估计与依据。
- 设计评估体系：建设期验收项与运营期考核项各不少于四项，说明数据来源与考核周期。
自测与答案
第 1 题
「重建设轻运营」会以什么方式导致系统失效？
尚未检查本题。
查看答案与评价要点
参考答案：缺少运维、数据接入适配、模型重训与使用支持的持续投入后，系统会逐步衰减：数据过期、上游接口变更导致数据中断、模型效果下降、一线遇到问题无人响应，最终使用率归零回到原有工作方式。因此立项时就应明确运营期的年度投入比例与来源。
评价要点：列出至少三类持续投入；描述衰减的具体表现；要求立项时明确运营预算
第 2 题
为什么成效指标的基线值往往需要在项目建设前就开始采集？
尚未检查本题。
查看答案与评价要点
参考答案：成效是相对于建设前状态的改变，没有基线就无法计算改变幅度，项目结束时只能给出无法核实的定性表述。而基线数据通常来自建设前的人工台账或旧系统，一旦开始建设、流程改变，原始状态就无法再复现，因此必须在建设前采集并明确采集口径。
评价要点：指出成效是相对基线的改变；说明无基线只能定性表述；指出建设后原状态无法复现
尚未完成自测。
今日完成标准
- 提交三个场景的三判据打分与优先级排序
- 提交每个场景的量化成效指标与基线采集方式及时点
- 提交区分建设与运营的预算结构，以及建设期与运营期各不少于四项的评估指标
常见错误与纠正提示
- 只编建设预算不编运营预算，系统在两三年内自然衰减
- 同时铺开大量场景，全部停留在识别与展示阶段
- 未在建设前采集基线，结项时无法量化成效
分层任务
基础任务
在教师给出的候选场景中用三条判据完成排序并说明理由。
标准任务
独立完成场景选择、成效指标、预算结构与评估体系设计。
挑战任务
为其中一个场景设计基线采集方案：采集内容、方式、时长与质量控制措施。
关联知识点
延伸阅读
- 国务院关于加强数字政府建设的指导意见（中国政府网政策文件）
- 国务院关于印发“十四五”数字经济发展规划的通知（中国政府网政策文件）
学习状态：未学习
Day 105
AI城市复盘
建议时长：75 分钟
本日 CO：CO7 CO8
本日概要
本周收尾整理一份避坑清单。城市级项目最常见的三类问题是：数据不通——跨部门共享缺少授权路径与口径统一，导致平台拿不到可用数据；重建设轻运营——一次性投入建成后无持续预算，系统逐年衰减；供应商绑定——接口与数据格式私有化，后续扩展与更换成本极高。三类问题都不是技术难题，而是机制问题，因此应对手段也在机制层面：把数据共享依据、运营预算比例、接口开放要求写进立项与采购文件，而不是寄望于实施阶段协调解决。
听书与视频
本日听书
6 分钟 · MP3 · 双主持人讲解
B 站讲解
学习目标
- 能识别数据不通、重建设轻运营、供应商绑定三类典型问题的早期信号
- 能说明这三类问题为何属于机制问题而非技术问题
- 能把应对措施转化为可写入立项与采购文件的具体条款
- 能为一个已在建项目做中期体检并给出整改建议
核心讲解
三类问题的早期信号
数据不通的早期信号是：方案中写着「协调各部门共享数据」但没有具体的授权路径、责任人与时间点；或者数据目录里只有表名没有口径定义。重建设轻运营的信号是：预算表中只有建设费用，没有年度运维、数据接入维护与模型迭代的科目；或者验收标准里没有可运营条件（文档、培训、运维流程）。供应商绑定的信号是：接口协议与数据格式未要求开放、数据导出能力未在合同中约定、或者源代码与配置的归属不明确。
这三类信号都出现在立项与采购阶段，而后果要到实施甚至运营期才显现，这正是它们难以纠正的原因——等到发现时，合同已签、系统已建，纠正成本极高。因此避坑的关键动作发生在项目最前端，而不是靠实施阶段的协调能力。
把应对写进文件
针对数据不通，可写入的条款包括：明确列出需接入的数据项、提供部门与授权依据；要求提供方在约定时间内完成接口开通；要求建立数据目录并包含口径定义与更新频率。针对重建设轻运营，可写入的条款包括：预算中单列年度运营科目并给出比例下限；验收条件包含完整文档、培训完成与运维流程建立。
针对供应商绑定，可写入的条款包括：接口协议与数据格式须采用公开标准或提供完整文档；系统须提供全量数据导出能力并在验收时实测；关键配置与二次开发接口须交付；以及明确知识产权与数据归属。这些条款写进文件后，即使后续更换供应商，迁移成本也在可控范围内。需要说明的是，具体条款的表述与法律效力应由法务与采购部门确认，技术方的责任是提出准确的技术要求。
实践任务
编制一份 AI 城市项目避坑清单，为每类问题写出识别信号、发生阶段、后果与可写入立项或采购文件的应对条款。
- 为三类问题各写出至少两个可在立项或采购文件中直接观察到的早期信号。
- 为每类问题说明它在哪个阶段埋下、在哪个阶段显现，以及为何后期纠正成本高。
- 为每类问题写出两到三条可写入立项或采购文件的具体条款，并标注需由法务或采购部门确认的部分。
- 选一个已在建或已建成的项目做中期体检：逐条对照清单，指出存在的问题与可行的整改建议，区分能整改与已难以整改的部分。
自测与答案
第 1 题
为什么说数据不通、重建设轻运营、供应商绑定是机制问题而不是技术问题？
尚未检查本题。
查看答案与评价要点
参考答案：三者的成因都在立项与采购阶段的约定缺失：缺少数据共享的授权路径与口径要求、缺少运营预算科目与可运营验收条件、缺少接口开放与数据导出的合同约定。技术上都有成熟做法，真正缺的是把这些要求写进文件并作为验收依据，因此应对手段也在机制层面。
评价要点：指出成因在立项与采购阶段的约定缺失；说明技术上已有成熟做法；把应对定位为写入文件与验收依据
第 2 题
供应商绑定的风险应通过哪些具体条款来控制？
尚未检查本题。
查看答案与评价要点
参考答案：包括：接口协议与数据格式采用公开标准或提供完整文档；系统提供全量数据导出能力并在验收时实测；关键配置与二次开发接口一并交付；明确知识产权与数据归属。这些条款使后续扩展或更换供应商时的迁移成本可控。具体表述与法律效力应由法务与采购部门确认。
评价要点：列出接口开放与文档要求；要求数据导出能力并验收实测；提出归属明确并交由法务确认表述
尚未完成自测。
今日完成标准
- 提交三类问题各不少于两个早期信号与阶段分析
- 提交每类两到三条可写入文件的条款，需法务确认部分被标注
- 提交一个真实或假设项目的中期体检结果与整改建议，区分可整改与难整改部分
常见错误与纠正提示
- 把三类问题当作实施阶段的协调问题，错过立项与采购阶段的纠正窗口
- 条款只写原则性要求，验收时无法实测（如未要求数据导出能力实测）
- 越过法务与采购部门自行拟定合同条款表述
分层任务
基础任务
在教师给出的方案文本中找出三类问题的早期信号各一个。
标准任务
独立完成避坑清单与一个项目的中期体检。
挑战任务
为「全量数据导出能力」设计一份验收测试方案：测什么、怎么测、什么结果算通过。
关联知识点
延伸阅读
- 国务院关于加强数字政府建设的指导意见（中国政府网政策文件）
- 中华人民共和国数据安全法（中央网信办官网发布全文）
- 国家标准全文公开系统（国家市场监督管理总局标准查询入口）
学习状态：未学习