第16周：智慧政务与政务大模型专题

本日概要

政务服务数字化的演进可以概括为几个阶段：从把线下窗口搬到网上、到跨部门流程整合、再到以数据共享驱动的主动服务。判断处在哪个阶段，有一个简单的检验：办一件事需要群众自己跑几个部门、提交几份材料、以及这些材料中有多少是政府部门本已掌握的。真正的进步体现在「减材料、减跑动、减时限」这三项可量化指标上，而不是有没有上线一个新平台。所谓从「人找服务」到「服务找人」，前提是数据共享与资格判定能够自动完成，而这依赖跨部门的数据治理，技术只是其中一环。

学习目标

• 能用减材料、减跑动、减时限三项指标评价一项政务服务的数字化水平
• 能梳理一项服务的完整办理流程并识别其中的冗余环节
• 能判断哪些提交材料属于政府部门本已掌握的数据
• 能说明从「人找服务」到「服务找人」所依赖的前提条件

核心讲解

实践任务

选一项具体政务服务，梳理其当前办理流程，统计材料数、跑动次数与时限，并指出哪些材料是政府已掌握的。

• 选定一项具体政务服务，画出当前的完整办理流程，标出每个环节的办理主体与所需材料。
• 统计三项指标：材料份数、跑动次数、办结时限，说明数据来源是官方办事指南还是实际体验。
• 逐份材料判断其信息由哪个部门掌握，标注可通过数据共享获取的部分，并说明障碍属于制度、技术还是数据质量。
• 为该事项设计一个「服务找人」的可能形态，写明所需数据、授权依据、判定规则的可解释方式与异议渠道。

自测与答案

今日完成标准

• 提交完整办理流程图与三项指标的测量结果及数据来源说明
• 提交逐份材料的掌握部门判断与障碍分类
• 提交「服务找人」形态设计，含数据来源、授权依据、可解释方式与异议渠道

常见错误与纠正提示

• 以平台上线数量评价数字化水平，不测量办事体验的变化
• 把可共享获取的材料仍要求群众自行提交，未识别数据传递的冗余
• 设计主动服务时只考虑技术可行性，忽略授权依据与异议渠道

分层任务

关联知识点

• 智慧政务
• 数据治理

延伸阅读

• 国务院关于加强数字政府建设的指导意见（中国政府网政策文件）
• 中华人民共和国个人信息保护法（中央网信办官网发布全文）

本日概要

跨部门办事的难点从来不在界面，而在数据与规则。以一项补贴的「免申即享」为例，要自动完成需要三类条件：一是资格判定所需的数据能够跨部门获取，例如身份、参保、收入、居住等信息分散在不同系统；二是判定规则能够被明确表达为可执行的逻辑，模糊表述（如「生活困难」）必须先转化为可核验的条件；三是有明确的依据支持基于共享数据作出决定，并配套异议与更正机制。三类条件中，技术往往是最容易的一类，数据口径与规则明确化才是主要工作量。

学习目标

• 能拆解一项事项自动办理所需的数据项与来源部门
• 能把模糊的政策表述转化为可核验的判定条件，并标注需要确认的部分
• 能设计判定结果的告知、查询与异议更正机制
• 能识别跨部门数据共享中的口径不一致风险

核心讲解

实践任务

选一项补贴事项，拆解其自动办理所需的数据项、来源部门、判定规则与异议机制，并识别其中的模糊条款。

• 选定一项补贴事项，列出资格判定所需的全部数据项，逐项标注来源部门、字段定义、更新频率与已知偏差。
• 把政策条款拆解为可核验的判定条件，标出其中需要裁量、必须保留人工审核的部分，并注明拆解结果需提交政策主管部门确认。
• 识别至少两处口径不一致风险，说明若直接拼接会导致什么与政策本意不符的结果。
• 设计告知、查询与异议三个环节：告知内容与方式、可查询的数据项范围、异议提交渠道、处理时限与责任部门、更正后的重新判定流程。

自测与答案

今日完成标准

• 提交数据项清单，逐项含来源部门、字段定义、更新频率与已知偏差
• 提交判定条件拆解结果，裁量部分与需确认部分被明确标注
• 提交至少两处口径不一致风险分析与告知、查询、异议三环节的完整设计

常见错误与纠正提示

• 由技术团队自行把裁量条款转化为固定规则，实质上代替政策解释
• 直接拼接多部门字段而不核对定义与时间窗，得到与政策本意不符的结果
• 只设计自动判定不设计异议更正，数据错误长期无法修正

分层任务

关联知识点

• 智慧政务
• 数据库
• 数据治理

延伸阅读

• 国务院关于加强数字政府建设的指导意见（中国政府网政策文件）
• 中华人民共和国个人信息保护法（中央网信办官网发布全文）
• 国家标准全文公开系统（国家市场监督管理总局标准查询入口）

本日概要

政务领域的问答类应用有一条不可让步的要求：每个答案必须能指回具体的政策原文与条款位置。原因很直接——政务答复会被当作办事依据，答错的后果由群众承担。因此这类应用应当以检索增强为基础，而不是依赖模型的参数化知识；同时必须处理政策的时效性：条款会被修订或废止，检索时应默认只召回现行有效版本，并在答案中标注文件名称、文号、条款位置与生效日期。当检索不到可靠依据时，正确的行为是明确说明「未找到依据」并给出人工咨询入口，而不是给出一个看起来合理的概括。

学习目标

• 能说明政务问答为何必须以检索增强为基础而非依赖参数化知识
• 能设计政策文件的版本与效力管理，使检索只召回现行有效条款
• 能实现可定位到条款的引用与关键陈述的一致性校验
• 能设计无依据时的拒答与转人工路径

核心讲解

实践任务

搭建一个政策问答原型，验证每个答案都带可定位引用、失效文件不被召回，以及无依据时的拒答路径。

• 准备一批政策文件，入库时记录文件名称、文号、发布日期、生效日期、失效日期与替代关系。
• 实现检索的效力过滤：默认只召回现行有效版本，验证已废止文件不进入上下文；再验证明确要求查询历史时的例外路径。
• 实现可定位到条款的引用与一致性校验，构造三条关键陈述与引用不符的样例，验证降级行为。
• 构造包含过渡期、版本冲突与超出覆盖范围三类情形的测试用例，验证系统的说明与拒答行为是否符合预期。

自测与答案

今日完成标准

• 提交文件入库记录，含文号、发布、生效、失效日期与替代关系
• 提交效力过滤与历史查询例外路径的验证记录
• 提交引用一致性校验的降级样例，以及过渡期、版本冲突、超范围三类测试用例的结果

常见错误与纠正提示

• 让模型基于参数化知识概括政策，答案无法核对且可能已过时
• 入库不记录效力状态，依据已废止条款作答
• 无依据时给出看似合理的概括，而不是明确说明未找到依据并转人工

分层任务

关联知识点

• 智慧政务
• RAG检索增强生成
• 提示工程

延伸阅读

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（arXiv 论文页面）
• 国务院关于加强数字政府建设的指导意见（中国政府网政策文件）
• OWASP Top 10 for LLM Applications（OWASP GenAI 官方页面）

本日概要

在政务场景中引入能够调用工具的智能体，权限设计必须比一般场景更严格。基本原则有三条：只读与写入严格分级，任何产生外部效果的操作都需要人工确认；智能体的权限不得超过操作它的工作人员本人的权限，避免通过系统绕过既有的授权体系；每一步操作留下完整审计日志，包括操作人、时间、调用的工具、参数、结果与人工确认记录。人机协同的定位应当明确：智能体承担信息整理、材料预审、草稿生成这类辅助工作，涉及权益的决定仍由工作人员作出并署名负责。

学习目标

• 能为政务智能体设计只读与写入分级的工具权限体系
• 能说明智能体权限不得超过操作者本人权限的原因与实现方式
• 能设计完整的审计日志字段，支持事后追溯与责任认定
• 能界定人机协同中哪些工作可由智能体承担、哪些必须由人决定

核心讲解

实践任务

为一个政务智能体定义工具权限分级、人工复核节点与审计日志字段，并验证越权调用被拒绝且留痕完整。

• 为一个政务智能体列出可调用的工具清单，按只读与有副作用两类分级，并说明分级依据。
• 实现权限继承：智能体以操作者身份访问数据；构造一次越权调用（尝试访问操作者无权查看的数据），验证被拒绝并记录拒绝原因。
• 为有副作用的工具实现人工确认节点，验证未确认时不执行，并记录确认人与时间。
• 定义审计日志字段并实际产出一份完整日志，检验它能否回答「谁办的、依据是什么、人做了什么判断」三个问题。

自测与答案

今日完成标准

• 提交工具清单与只读、有副作用两类分级及依据
• 提交越权调用被拒绝的记录与人工确认节点的验证记录
• 提交一份完整审计日志，并说明它如何回答三个追溯问题

常见错误与纠正提示

• 为智能体配置统一高权限账号，绕过既有授权体系
• 把权限分级写死在代码逻辑中，难以审计与调整
• 复核环节设计成只能点击同意，责任被推给系统

分层任务

关联知识点

• 智慧政务
• AI Agent
• AI安全与对齐

延伸阅读

• Tool use with Claude（Anthropic 官方文档）
• 国务院关于加强数字政府建设的指导意见（中国政府网政策文件）
• OWASP Top 10 for LLM Applications（OWASP GenAI 官方页面）

本日概要

政务数据的安全要求高于一般行业，核心是三条：数据分类分级并按级施策、个人信息处理有合法性基础且遵循最小必要、以及关键操作可审计可追溯。落到模型应用上，还要额外回答两个问题：数据是否会离开受控环境（涉及模型部署形态与第三方服务调用），以及日志与缓存中是否留存了不该留存的内容。实践中最容易被忽略的是第二个——为排查问题保存完整请求与响应几乎是默认做法，而这些记录往往包含个人信息，其访问控制却比业务数据宽松得多。

学习目标

• 能对政务数据完成分类分级并说明各级的处理要求差异
• 能梳理模型应用的完整数据流，识别数据可能离开受控环境的位置
• 能检查日志与缓存中的敏感内容留存并给出脱敏方案
• 能把安全措施与具体法定要求对应，形成可核对的整改清单

核心讲解

实践任务

为一个政务模型应用做数据安全评审：梳理数据流、判定分类分级、检查出域与日志留存，并给出整改清单。

• 梳理一个政务模型应用的完整数据流，标出数据的采集、传输、进入上下文、生成、存储与销毁各环节。
• 对涉及的数据做分类分级，为每一级写明访问审批、加密、留存期限与审计强度要求。
• 检查是否存在数据出域路径，若有则列出可出域与不可出域的数据类别，并设计调用前的字段过滤与敏感内容检测。
• 检查日志、缓存与临时文件中的敏感内容留存情况，给出脱敏方案、保留期限与访问控制整改项；把每项措施与对应的法定要求关联，形成整改清单并标注责任人与时限。

自测与答案

今日完成标准

• 提交完整数据流图，标出各环节与可能的出域位置
• 提交分类分级结果与各级的处理要求，以及出域控制的技术手段设计
• 提交日志缓存的敏感内容检查结果与整改清单，每项措施关联对应法定要求并含责任人与时限

常见错误与纠正提示

• 只做业务系统的安全设计，忽略日志与缓存中的敏感数据副本
• 以服务方承诺代替技术控制来保证数据不出域
• 为将来可能的用途扩大数据采集范围，无法说明处理目的

分层任务

关联知识点

• 智慧政务
• 数据治理
• AI安全与对齐

延伸阅读

• 中华人民共和国个人信息保护法（中央网信办官网发布全文）
• 中华人民共和国数据安全法（中央网信办官网发布全文）
• OWASP Top 10 for LLM Applications（OWASP GenAI 官方页面）
• OpenTelemetry: Signals（OpenTelemetry 官方文档）

本日概要

政务场景的项目落地通常从小范围试点开始，这不是保守而是必要——政务系统的使用者是工作人员，其工作流程受制度约束，贸然全面推开容易造成流程混乱。一个可行的试点方案包含五部分：明确的试点范围（哪个部门、哪些岗位、哪类事项）、量化的成效指标与基线、试点期的支持机制（培训、问题响应）、明确的评估节点与继续或终止的判据、以及推广的前提条件。写清楚「什么情况下应当停止」与写清楚成功标准同样重要，它让试点成为一次真正的验证而不是一个必须成功的任务。

学习目标

• 能为政务场景设计合理的试点范围并说明选择依据
• 能定义试点期的量化指标与基线采集方式
• 能设计试点期的培训与问题响应机制
• 能写出继续、调整与终止三类判据，使试点成为真正的验证

核心讲解

实践任务

为「会议纪要自动整理」这类事务性场景设计试点方案，含范围、指标、支持机制、评估节点与终止判据。

• 选定试点范围（部门、岗位、事项类型），说明选择依据与预计的样本量。
• 定义三到四项量化指标与一条质量底线，说明基线采集方式与采集时点。
• 设计试点期支持机制：培训安排、反馈渠道、响应时限与现场走访频次，并把其成本计入试点预算。
• 写出继续、调整、终止三类判据的具体条件与评估节点时间；再写出推广前必须满足的前提条件。

自测与答案

今日完成标准

• 提交试点范围与选择依据，含预计样本量
• 提交三到四项量化指标与一条质量底线，以及基线采集方式与时点
• 提交支持机制方案与继续、调整、终止三类判据及评估节点、推广前提条件

常见错误与纠正提示

• 试点范围过大，问题从多个方向同时出现难以定位
• 不安排培训与问题响应，工作人员遇阻后退回原有方式
• 只写成功标准不写终止判据，试点被拖延为必须成功的任务

分层任务

关联知识点

• 智慧政务
• MLOps
• AI办公

延伸阅读

• 国务院关于加强数字政府建设的指导意见（中国政府网政策文件）
• OpenTelemetry: Signals（OpenTelemetry 官方文档）

本日概要

最后一天把整门课串起来：一个完整的方案自下而上依次是算力底座、数据治理、平台能力、场景应用与成效评估，横向贯穿标准规范与安全合规。这条线索也正是十六周的顺序——从芯片与服务器、操作系统与云原生、中间件与数据、机器学习与大模型、应用与工程化，到硬件产业、城市与政务专题。写总结方案时最有价值的不是把每层都写满，而是说清楚三件事：各层之间的依赖与接口、每个设计决策对应的约束、以及还没有验证的假设。这与第一天强调的要求完全一致——区分事实、推断、建议与待验证假设，是这门课贯穿始终的方法。

学习目标

• 能把课程各周内容组织成一条自下而上的完整技术线索
• 能为一个综合场景逐层给出关键决策并对应到具体约束
• 能说明各层之间的依赖关系与必须提前预留的接口
• 能诚实列出未验证假设并给出验证计划

核心讲解

实践任务

完成一页端到端方案：算力底座、数据治理、平台能力、场景应用、成效指标逐层给出关键决策与其对应的约束，并单列未验证假设。

• 选定一个综合场景（如面向基层的政务智能助手），按算力底座、数据治理、平台能力、场景应用、成效评估五层逐层写出关键决策。
• 为每个关键决策标注它解决的具体约束，检查是否存在无对应约束的设计。
• 画出层间依赖图，标出必须提前预留的接口，并据此排出实施顺序。
• 单列未验证假设一节，逐条写出内容、影响、验证方式与预计成本；最后用一页篇幅完成整体方案的呈现。

自测与答案

今日完成标准

• 提交五层关键决策，每项标注其解决的具体约束
• 提交层间依赖图与据此排出的实施顺序，标明必须提前预留的接口
• 提交未验证假设一节，逐条含内容、影响、验证方式与预计成本

常见错误与纠正提示

• 每层都写得很满但不写层间依赖，方案无法指导实施顺序
• 设计决策没有对应约束，隐藏了未说明的假设
• 通篇确定性陈述，未验证假设被隐去，风险无法被评审发现

分层任务

关联知识点

• AI硬件产业链
• AI城市 · 城市智能体
• 智慧政务

延伸阅读

• 国务院关于加强数字政府建设的指导意见（中国政府网政策文件）
• 国务院关于印发“十四五”数字经济发展规划的通知（中国政府网政策文件）
• 中华人民共和国个人信息保护法（中央网信办官网发布全文）
• 中华人民共和国数据安全法（中央网信办官网发布全文）
• 国家标准全文公开系统（国家市场监督管理总局标准查询入口）