第十三章 社区治理：惠民政策的最后一公里
章首：政策为什么找不到人
重阳节前一周，社区办公室的桌上摊着一摞政策文件。区民政局转来的《重阳节困难老人慰问方案》，市民政局转来的《高龄津贴发放办法》，再加上最低生活保障、医疗救助的申请指南——每一份文件都写明了适用对象与办理条件：年满65周岁，属于低保户、特困人员或空巢老人；户籍在册，家庭人均收入低于当地标准；患有慢性病，常年服药。白纸黑字，清清楚楚，每一个字都认识。
可社区干部心里明白，文件上的条件，要跟辖区里几千户人家的实际情况一一对上，靠的是一双腿、一张嘴。翻户籍台账，逐户核对年龄；打电话询问，确认家庭状况；实在联系不上的，只能入户走访。一轮排查下来，能覆盖多少户，全看人手多少、时间多紧。碰上政策更新，又要重来一遍。手工比对，效率低，遗漏多，这是基层治理里人人知道、人人默认的难题。
于是就有了一个耐人寻味的现象：惠民政策的善意从不缺席，缺的是把善意送到具体的人手上的那条路。老人不知道自己在政策覆盖范围内，干部不知道哪一户该享受哪一项，两头的信息各守一端，中间隔着一条信息差。这条信息差，就是惠民政策的最后一公里——文件已经发到社区，距离兑现成老人手里的一袋米、一桶油、一张银行卡，只差一次准确的比对、一次及时的告知、一次上门的办理。
把这个问题再往深里问一层：信息差的根源，在于制度的表达方式与人的生活方式的错位。政策以条文为语言，条文要求精确，精确要求分类——满65周岁是一类，低保户是一类，空巢老人又是一类；而人的生活是连续的、具体的、不肯被分类的——张阿姨今年六十四岁半，李大爷上个月刚把户口迁走，王婆婆独居多年却不愿被登记为空巢。政策要精准，就必须分类；人要享受政策，就必须把自己装进某个分类里。数智化要做的，正是把这个"装进去"的过程变得尽可能省力——让居民少填一张表，让干部少翻一次台账。
政策体系的复杂性，让这条信息差几乎无法靠人力填平。Simon在1962年讨论复杂性的结构时指出，复杂系统的组织方式是层级式的：系统由稳定的子系统构成，子系统再逐级分解，每一层都封装着下一层的细节[1]。惠民政策正是这样的层级系统——国家层面的政策管方向，省市层面定标准，区县层面出细则，落到社区，才变成可以逐户执行的具体条款。层级越多，信息在传递中的衰减越厉害：文件到达社区时，已经厚成一摞，每一层的表述差异、每一项的适用条件，都增加了比对的成本。复杂系统的层级结构带来了稳定性，也带来了信息损耗；对政策体系而言，损耗的末端，正是最需要保障的人群。
本章要解决的，就是把这最后一公里用数智化的方式走通。走通的办法并不玄妙：把居民的信息整理成结构化的画像，把政策翻译成机器可判定的规则，用匹配引擎逐条比对、命中即推荐，再把匹配结果变成落实任务，派给社区工作者上门办理、回传结果。画像、规则、匹配、落实，四个环节连成一条链，政策就从"人找政策"变成"政策找人"。第一节讲这条链要解决的问题——最后一公里的信息差；第二节讲方法链本身——画像、规则、匹配与落实闭环；第三节走进实训平台，看银铃福利通与社区治理AI总控台如何把方法链变成日常工具；第四节退后一步，审视"政策找人"背面那双"数据识人"的眼睛——数据伦理与治理的颗粒度。
第一节 最后一公里的信息差
政策写在文件里
惠民政策从出台到落地，要走完一条长长的路。以高龄津贴为例：国家层面有老龄事业的政策框架，省里规定发放的基本条件，市里确定补贴标准，区县负责具体发放，社区承担申报受理与资格核实。政策文件在每一个层级都会细化一层，最终到达社区干部手里的，是几页纸的实施方案加一张申请材料清单。方案写得越细，执行越有依据；可对居民来说，细化的另一面是门槛：满多少周岁、户籍在哪、收入怎么算、材料交几份、找谁办，每一个问题都可能拦住一位老人。
拦住的往往正是最需要帮助的人。独居老人没有子女帮忙打听，困难家庭没有余力研究政策条文，慢性病患者常年在家，消息最闭塞。政策术语本身也是门槛——"特困人员""低保对象""生活救助"，这些词在文件里是准确的法律概念，在居民耳朵里却是绕口的陌生词。一位老人可能同时享受三项政策，自己却一项都说不上来；干部问起来，他只知道"每个月卡里多了几十块钱"。
这样的情形，在基层走访记录里反复出现。一位老人住院花去大半积蓄，出院后才知道医疗救助可以在定点医院直接结算——政策一直在，报销通道也一直开着，缺的只是有人告诉他"你符合条件"。再比如高龄津贴，多数地区实行"到龄即享"，前提是老人的信息在册；信息不在册的，津贴就静静躺在预算里，等一个永远不会到来的申请。政策落地靠的是信息流动，而信息流动的末端，常常堵在最后一米——从文件到老人的耳朵。
银铃福利通的首页上挂着25项政策，其中9项国家级。25项，对于一个城市社区来说，数字不大；可每一项背后，都对应着辖区里某一类人群可能错过的保障。9项国家级政策覆盖高龄津贴、最低生活保障这些最基础的兜底项目，地方政策则细到重阳节慰问、医疗救助对接这样的具体安排。政策的总数以十计，需要政策的人以百计、以千计，手工比对要做的，就是让这两组数字精确对上——这几乎是一项不可能完成的任务。
手工比对的局限
社区干部的日常工作里，政策比对从来都是一场消耗战。政策文件来了，先通读，再对照户籍台账逐户筛查；筛查出疑似符合条件的，逐个电话确认；确认不了的，安排入户。一个网格几百户，一户人家可能同时涉及四五项政策，每项政策又有各自的条件与材料。把这项工程做一遍，靠的是加班；做两遍，靠的是政策更新；长期做下去，遗漏就成了必然。
遗漏的代价，落在最不该承担它的人身上。高龄津贴漏了一个月，老人不会知道，因为没人告诉过他该有这笔钱；重阳节慰问漏了一户，志愿者不会知道，因为台账上那户人家的状况没人更新。信息差造成的损失是沉默的——沉默到连"损失"都难以统计。这正是基层治理最棘手的地方：问题看得见，规模却摸不清，因为漏掉的那些人，恰恰是声音最小的人。
Simon的层级复杂性分析在这里给出了一个判断：靠人脑维护一个层级嵌套的复杂系统，必然顾此失彼[1]。政策的层级结构决定了信息天然分散，居民的实际情况又时时变动——今天退休了，明天住院了，后天户籍迁走了。台账永远滞后于生活，手工比对的速度永远追不上台账滞后的速度。要填平这条信息差，先要把比对从人脑搬到机器，把政策从文件变成规则——这正是第二节要展开的方法链。
在平台上验证
打开银铃福利通（https://zhenyuonline.cn/welfare-policy/），首页顶部显示"25项政策总数、9项国家级"。逐条浏览政策列表，点开任意一项，看它的适用条件、发放标准与办理材料——这就是"政策写在文件里"的原始形态。留意政策列表的分类：现金类（高龄津贴、最低生活保障，直接发钱）、服务类（医疗救助，对接就医报销）、物资类（重阳节困难老人慰问，发放实物并上门送达）。这个按 delivery_type 所做的分类，已经是政策规则化的第一步——把一份份文件，归置成可以计算的条目。
第二节 方法链：画像、规则与落实闭环
用户画像：把居民变成可计算的结构
方法链的第一步，是给居民建立画像。在银铃福利通里，这对应着"我的信息"：年龄、户籍、收入、健康状况，几个字段构成一份基础档案。字段不多，却每一项都指向政策的判定条件——年龄对应高龄津贴的门槛，户籍对应属地政策的适用，收入对应低保的核算线，健康状况对应医疗救助的对接范围。
画像的意义，在于把"人"翻译成机器可以比对的结构。政策比对的前提，是比对的双方处在同一套语言里：政策的规则是结构化的（满65周岁、低保户、特困人员），居民的实际情况也必须结构化成同样的字段。画像做得准，匹配才谈得上准；画像缺字段，匹配就只能在残缺的信息上碰运气。这也解释了为什么画像字段的设计要跟着政策走——先有政策的判定条件，才有画像的字段清单，次序不能颠倒。
这里值得停下来想一想画像与标签的分界。画像服务于一个明确的目的：让该享的政策一项不落。字段的采集以政策的判定条件为限，多一个字段都是负担。一旦画像的目的从"落实政策"滑向"预判这个人会怎样"，画像就变了性质——从服务工具变成评价工具，从帮居民办事变成替居民做主。这个分界，第四节还要回到。
画像的维护，是方法链上最容易被低估的环节。政策会更新，人的状况也在变：退休了，收入结构变了；生病了，健康字段要改；户籍迁走了，属地政策就换了适用。画像一旦陈旧，匹配的结论就失真——引擎再准，喂给它的也是过期的事实。因此画像需要定期刷新：居民自己更新、社区干部走访时核实、政策落实过程中顺带校正。画像是一份填完就封存的表格，还是一条持续流动的信息流，决定了方法链的起点稳不稳。
政策库规则化：把文件翻译成"如果—那么"
方法链的第二步，是把政策库规则化。25项政策，逐条拆解：适用对象、条件门槛、发放标准、材料清单，全部翻译成"如果—那么"的判定规则。以"重阳节困难老人慰问"为例——区县级政策，生活救助类，由成华区民政局制定，规则可以写成：如果年龄满65周岁，且属于低保户、特困人员或空巢老人，那么每年重阳节发放大米10kg、食用油5L与重阳糕一份，由社区志愿者上门送达。一条政策，变成一条清晰的规则；25项政策，变成一组可以逐条执行的规则库。
把复杂政策拆成原子规则，正是Simon所说的层级分解在治理领域的应用：复杂系统由稳定的子系统构成，子系统内部再逐级分解[1]。政策条文是复杂的，判定条件却是原子的——年龄、身份、收入、健康，每一个条件都可以独立判定，再按"与""或"组合成完整规则。拆解之后，政策的执行不再依赖某个干部的熟悉程度，而依赖规则本身是否完备；规则写清楚了，谁来执行，结果都一样。
规则化还有一个副产品：透明。文件里的政策，居民看不懂；规则化的政策，机器可以逐条给出结论——命中，显示"✓ 全国性政策，适用"；未命中，给出未命中的原因，以及补齐什么材料可以达标。结论可解释，居民才信得过；规则透明，比对的公正才看得见。这项技术最可贵的地方，恰恰在于它把政策从文件里的条文变成了可解释的结论。
匹配引擎：一次全库扫描
方法链的第三步，是匹配引擎。引擎的工作方式朴素而彻底：拿居民的画像字段，对政策库里的每一条规则逐条评估，命中的政策按适配程度排序展示，未命中的给出原因。一次匹配，就是一次全库扫描——25项政策，每一条都要过一遍画像，快的几秒钟，慢的也就是一次页面刷新。
匹配结果的排序也有讲究。命中的政策，按适配程度与重要程度排列：直接决定居民现金收入的现金类政策排在前，需要居民主动办理的次之，纯信息类的告知排在最后。适配度高的规则命中，结论明确标注"✓ 全国性政策，适用"；边缘情况——比如年龄差几个月、材料差一份——引擎给出提示与下一步建议，不简单判负。居民还可以把关心的政策收藏起来，政策更新时收到提醒。匹配引擎给出的，始终是一个可解释、可追问的结论，一套干巴巴的命中清单解决不了信任问题。
（如图13-1所示）画像、规则库、匹配引擎、任务派发、落实反馈，五个环节首尾相接，构成"政策找人"的完整闭环——居民信息进入画像，画像驱动匹配，匹配生成任务，任务推动落实，落实的反馈又回到画像，让下一次匹配更准。
图13-1 惠民政策的"政策找人"闭环
匹配的判定过程，可以用"重阳节困难老人慰问"这条规则走一遍（如图13-2所示）：引擎先查年龄，满65周岁进入下一层判定；再查身份，属于低保户、特困人员或空巢老人三者之一即命中；两层都通过，输出适用结论并生成落实任务。任何一层不满足，引擎都给出未命中的原因——年龄不够，提示"年满65周岁后可享受"；身份不符，提示"符合条件后可在社区登记"。规则透明，结论就可解释。
图13-2 匹配引擎的"如果—那么"规则流（以重阳节困难老人慰问为例）
落实闭环：从"知道"走到"办成"
匹配只解决"知道"，落实才解决"办成"。方法链的第四步，是把匹配结果变成落实任务，送进社区工作台。工作台为网格长与网格员分了工：网格长负责建台账、派任务、看进度，网格员负责接单、上门、回传结果。每一项任务都有时间戳与状态——已派发、办理中、已完成——帮扶工作第一次有了可追溯的完整闭环。
以物资类政策为例，任务闭环看得最清楚：匹配引擎命中重阳节慰问规则，生成任务，网格长在工作台确认并派单，网格员接单后带着大米、食用油与重阳糕上门，送达后在系统里回传结果，任务状态变为已完成。从命中到送达，每一步都有记录，谁办的、何时办的、办到什么程度，随时可查。现金类政策同样走这条链：高龄津贴匹配命中，任务派发，社区协助申报，发放后回传凭证。服务类政策略有不同——医疗救助的"落实"是长期的，任务闭环记录的是每一次对接与跟进。
落实闭环沉淀下来的，是服务过程的数据。Siemens与Long在2011年讨论学习分析时指出，把教学过程中产生的数据系统地收集起来，教学就变得可以测量、可以优化[2]。社区服务同理：任务耗时、办理成功率、重复申报率、反馈集中的政策类型，这些数据从落实记录里长出来，成为改进服务的依据——哪类政策落实慢，哪类人群反复漏报，数据会说话。服务过程的数据化，让最后一公里第一次有了量尺。
在平台上验证
在银铃福利通（https://zhenyuonline.cn/welfare-policy/）里走一遍完整的方法链：填写一份模拟居民画像——比如一位68岁的空巢老人——观察匹配引擎如何逐条命中政策，输出"✓ 全国性政策，适用"式的结论；再进入"我的落实"，看匹配结果如何变成带状态的落实任务；最后切到社区工作台，以网格长的视角建台账、派任务，以网格员的视角接单、回传。画像、匹配、派单、回传，四个动作做完，方法链的每一步都有了直观的落点。
第三节 平台实战：银铃福利通与社区治理AI总控台
银铃福利通：五个功能区一条链
银铃福利通的功能区，正好对应方法链的四个环节，外加一个浏览入口。我的信息，是画像的落点：年龄、户籍、收入、健康，字段不多，逐项填写；政策匹配，是引擎的落点：一次扫描，逐条给出命中结论；政策浏览与收藏，是居民自主学习的入口：25项政策随时可查，关心的政策收藏起来；我的落实，是任务的落点：居民能看见自己的任务走到哪一步；社区工作台，是管理的落点：网格长与网格员在这里完成台账、派单、接单、回传。
社区工作台是这条链上最接近"治理"的一环。网格长在台账视图里看到的不只是单条任务，还有辖区政策的覆盖情况：哪些政策落实率高，哪些政策几乎无人命中，哪些网格的任务积压——这些视图让最后一公里的堵点第一次可视化。任务派发也有轻重缓急：现金类政策按期办理，物资类政策赶在节日前完成配送，服务类政策按居民的时间表约访。工作台把网格长的经验，沉淀成了可以复用的派单节奏。
（如图13-3所示）平台把"画像—匹配—任务—落实"串成一条可见的流水线：居民填一次画像，引擎跑一遍规则，任务在社区工作台里流转，落实结果回到"我的落实"供居民查看。
平台设计上有一个容易被忽略的细节：居民的视角与干部的视角，落在同一套数据上。居民看"我的落实"，看到的是自己享受了哪些政策、任务进行到哪一步；网格长看工作台，看到的是辖区任务的总体进度。两套视角共享同一份数据，进度对居民透明，办理对干部留痕——透明与留痕，是同一枚硬币的两面。
社区治理AI总控台：18个Agent的方法论分层
惠民政策的落实，嵌在社区治理的更大图景里。政策匹配解决"该给谁"，社区治理还要回答"怎么建"——社区品牌怎么立、志愿服务怎么组织、民主协商怎么开展、慈善基金怎么运作。这些问题的答案，社区治理AI总控台（https://zhenyuonline.cn/community-ai/，基于《社区品牌AI实战手册》）用18个在线Agent组织起来，分三层。
第一层，认知与方法，7个Agent：认知地基、快速上手、品牌把脉、品牌定位、护城河、品牌变现、品牌运营。这一层回答"社区品牌是什么、怎么建"——从认知地基打底，到品牌把脉诊断现状，到品牌定位确定方向，再到护城河、变现与运营，七个Agent把一套完整的建设路径拆成可逐步执行的环节。
第二层，场景应用，9个Agent：信义治理、志愿服务、民主协商、为老服务、儿童服务、慈善基金、慈善阵地、慈善项目、社区文化。这一层把方法落进具体场景，每一个Agent对应一类社区事务——为老服务对接银铃福利通的惠民落实，志愿服务组织动员居民力量，民主协商化解邻里分歧，慈善基金与慈善项目把社区公益做成可持续的事业。
第三层，支撑体系，2个Agent：数据安全、方法迁移。数据安全把合规要求做成随时可查的清单，为所有场景划定底线；方法迁移负责把一套场景里跑通的经验复制到新场景，让方法论在社区之间流动。
三个层次之间的关系，也值得细看。认知与方法层管方向，场景应用层管落地，支撑体系层管底线。方向不清，为老服务做得再热闹，也聚不起社区认同；方法讲得再透，落不进信义治理、民主协商这些具体事务，就只是纸面文章；而方向与方法跑得再快，缺了数据安全这条底线，一切都会失去根基。三层的次序，本身就是社区治理方法论的浓缩。
（如图13-4所示）三个层次各有分工：认知与方法层提供路径，场景应用层对接事务，支撑体系层守住底线，18个Agent共同构成社区治理的方法论底座。
图13-4 社区治理AI总控台18个Agent的方法论分层
18个Agent背后，每一个都是一段可以调用、可以复用的方法资产。这与本书反复强调的技能化思维，是同一件事在社区场景里的回响：把一次性的经验沉淀为可复用的能力，再让能力在下一个场景里重新出发。总控台与银铃福利通的集成，正是这条思路的落地——福利通管"政策找人"的执行，总控台管"怎么治理"的方法，执行与方法在一个工作台里相遇。
（如图13-5所示）社区治理AI总控台页面中，18个Agent按三层排列在线，并集成银铃福利通入口，惠民政策匹配与社区方法论在同一个界面里完成衔接。
在平台上验证
先回到银铃福利通（https://zhenyuonline.cn/welfare-policy/），完成一次"我的信息—政策匹配—我的落实—社区工作台"的完整走查：填一份画像，看匹配结论，生成一条任务，到工作台派单并回传。再打开社区治理AI总控台（https://zhenyuonline.cn/community-ai/），浏览18个Agent的三层结构，找到"为老服务"Agent，观察它如何与银铃福利通集成——一个管惠民落实，一个管服务方法，两个平台在"为老"这个场景里合流。走完这两步，方法链与方法论，就都有了具体的坐标。
第四节 数据伦理与治理颗粒度
敏感个人信息的边界
社区治理的数据，与金融、电商的数据有一个根本差异：它直接指向真实的人，而且是相对弱势的人。金融数据指向账户，电商数据指向消费，社区数据指向的是老人的年龄、病人的健康状况、困难家庭的收入——每一类数据背后，都是一个具体的人的生活处境。匹配引擎要跑得准，靠的正是这些最私密的字段；而引擎每用一次这些字段，就多一次触碰隐私的风险。
法律为这条边界画了线。《中华人民共和国个人信息保护法》（2021年施行）把健康信息列为敏感个人信息，确立了最小必要、知情同意等基本原则[4]：处理个人信息应当具有明确、合理的目的，并限于实现目的的最小范围。落到社区场景，这条原则可以翻译成三句话：能用一个字段解决的，就不要采集五个字段；能留在社区的数据，就不要上传云端；能由居民自己确认的信息，就不要替居民做主。《中华人民共和国数据安全法》（2021年施行）则从数据分类分级的角度提出要求——重要数据与一般数据分开管理，安全责任落到具体环节[5]。对社区来说，这意味着数据流向要有章法：居民信息在哪个环节产生、在哪个环节使用、在哪个环节销毁，每一步都要有安排。
银铃福利通的实践，可以看作这条边界的正面样本：匹配逻辑做成透明规则，居民能看见结论与原因；落实进度开放给居民查看，居民知道自己的信息被用来做了什么。让居民既是数据的提供者，也是服务的主人——透明，是数据伦理最朴素的实现方式。
治理的颗粒度：该用与该怎么用
"政策找人"的背面是"数据识人"。匹配越精准，越要追问一句：这个信息，该用吗？该用到哪一步？这两个问题，指向治理的颗粒度——技术能力与伦理边界的平衡点。
颗粒度的第一层，是采集的粒度。画像字段以政策的判定条件为限：判定高龄津贴需要年龄与户籍，采集这两项就够；判定医疗救助需要健康状况，采集到"是否属于特困人员、低保对象"这一层就够，无需记录病史细节。字段多一寸，风险多一尺，而匹配精度并不会因为多采集的字段而提高——多出来的字段，只是多出来的风险。
颗粒度的第二层，是使用的边界。居民的数据用于落实政策，天经地义；用于别的目的，就要打一个问号。居民的反馈与评价同样构成数据——Pang与Lee在2008年的综述中系统梳理了意见挖掘的方法，从情感分类到观点抽取，让散落的文字意见变成可统计的信号[3]。社区服务里，这类数据有正当的用途：哪类政策落实慢、哪类人群反馈集中，从回访与评价文本中读出来，用于改进服务。可同样的数据，一旦从"改进服务"滑向"给居民分级"，用途就变了质。数据使用的边界，由治理允许什么决定；技术能做什么，只是把选择摆到桌面上。
颗粒度的第三层，是时间的维度。数据用完之后怎么办？政策落实完毕，画像是否还保留？保留多久？给谁看？数据安全法要求数据分类分级管理，个人信息保护法要求个人信息处理有明确的期限与目的[4][5]。对社区而言，最稳妥的做法是"用毕即删"——任务办结，数据使命完成，留存期限一到，就清空。数据记得越久，风险累积越多；忘得越快，治理越干净。
把这三层颗粒度放在一起看，会得到一个朴素的方法：每一项数据决策，都先问三个问题——采集它，是为了哪项政策？使用它，止步于哪个环节？留存它，到什么时候为止？三个问题答得清楚，数据的每一步就都在明处；答不清楚的字段，一开始就不该采集。社区治理的伦理，就藏在这些具体的、琐碎的回答里，藏在一份画像表单的字段设计里，藏在一张任务单的访问权限里。
技术能力越强，克制的分量越重。数据能识别一个人享受哪些政策，也能识别一个人处于什么处境——后一种识别，恰恰是技术应当止步的地方。社区数智化的目标，始终落在人身上：让该享的政策一项不落，让该有的尊严一分不少。数据是手段，人是目的；技术越深入社区，这句话越要常念常新。
章末小结与追问
本章把惠民政策的最后一公里拆开，走了一条从问题到方法再到平台的完整路径。第一节看清问题：政策写在文件里，老人不知道，干部比不动，信息差是沉默的损失；第二节搭起方法链：画像把居民变成结构，规则把政策变成逻辑，匹配把两者接通，落实把结果送回居民[1][2]；第三节走进平台：银铃福利通把方法链做成五个功能区，社区治理AI总控台用18个Agent沉淀社区治理的方法论；第四节退回伦理：数据越细，服务越准，风险越大，治理的颗粒度是能力与边界的平衡[3][4][5]。
回望这条链，会发现一个朴素的收束：数据技术越是深入社区，越是回到人的原点。画像服务于人，规则服务于人，匹配服务于人，落实更是直接走到人面前。技术负责精准，人负责尊严——惠民政策的最后一公里，机器走完了匹配与派单，剩下的上门、问候与陪伴，仍然要由人完成。这正是社区治理与其他行业数智化最不同的地方：这里的产出，最终要由一位老人亲手接住。
留三个问题给你想一想：
- 手工比对与规则匹配的本质差别在哪里？规则化之后，社区干部的哪些工作被替代了，哪些工作反而加重了？
- "政策找人"的数据，来自居民自己填写。如果画像改为由系统从其他渠道自动拼装，匹配会更准，风险也更大——这个权衡，你会怎么选？
- 设想你所在城市的一项惠民政策，试着把它写成"如果—那么"规则，并指出：哪些条件容易判定，哪些条件需要居民自证？自证的部分，如何既守住边界又不添负担？
参考文献
- [1] Simon H A. The architecture of complexity[J]. Proceedings of the American Philosophical Society, 1962, 106(6): 467-482.
- [2] Siemens G, Long P. Penetrating the fog: Analytics in learning and education[J]. EDUCAUSE Review, 2011, 46(5): 30-40.
- [3] Pang B, Lee L. Opinion mining and sentiment analysis[J]. Foundations and Trends in Information Retrieval, 2008, 2(1-2): 1-135.
- [4] 中华人民共和国个人信息保护法[Z]. 2021-08-20 通过，2021-11-01 施行.
- [5] 中华人民共和国数据安全法[Z]. 2021-06-10 通过，2021-09-01 施行.
数据与平台：本章实训绑定 zhenyuonline.cn 真实应用（银铃福利通 / 社区治理AI总控台）。页面渲染图均为平台实测截图。