简介：这份120页PDF报告来自厦门大学，聚焦DeepSeek大模型在政府数字化转型中的应用，面向各级政府公务员、管理人员、技术人员以及关注智慧政务的研究者与从业者。报告以“大模型是什么”为起点，系统讲解大模型的发展历程、分类体系（通用大模型、推理大模型、L0/L1/L2层级）以及国内外代表性产品，随后转入政务场景，重点展开智能咨询、智能审批、公文处理、政策解读等应用案例，并剖析DeepSeek一体机在政府本地化部署的优缺点、经济效益和数据安全应对措施，结尾还讨论了AI与公务员的角色分工与以人为本的协作原则。资源包内为1个PDF文件，共120页，大小约12.98MB，目录结构清晰，可逐章学习大模型基础、政务应用与AIGC实践。已有219人浏览学习，适合希望系统理解AI技术并落地智慧政务、同时关注安全合规的读者。
1. 120页的DeepSeek政务材料，先别急着翻正文，先想清它解决什么问题
数据局的朋友转给我一份PDF，题目很长：2025厦门大学：DeepSeek大模型赋能政府数字化转型-120页。我说这不就是一份汇报材料吗？他说你错了，最近一周已经有三个区县的同事在问他同一个问题：这份材料里讲的DeepSeek大模型，到底能不能直接用到我们现在的政务系统里。这其实是很多政务信息化项目当下的共同处境：模型是现成的，工具链也成熟了，但一落到“数据不出域、系统要对接、结果要担责”的真实环境里，很多人就卡住了。这份材料的意义，不在于告诉你大模型多聪明，而在于把“概念”翻译成了“场景、路径和约束条件”。它适合三类人：给政府客户做方案的系统集成商、政务云和大数据中心的运维团队、还有想在大模型方向上立项但还没想清楚边界的业务处室负责人。先别急着翻正文，带着“它能帮我回答哪个问题”的预期去读，才不亏。
2. 为什么是DeepSeek：选型硬约束把“好用”变成了“能用”
2.1 政务场景选大模型，先看四个硬约束，再看模型本身强不强
很多团队选模型，拿着榜单比来比去。政务场景不是这么玩的。我参与过的数字政府项目里，客户第一句问的从来不是“你用的模型排名第几”，而是“这个模型能不能部署在我们自己的机房里”。
这是政务场景和互联网场景最大的不同：数据不出域是硬约束。办事群众的信息、企业法人的登记数据、12345热线的工单内容，这类数据只要出域，哪怕只是过一道外部API，合规风险立刻升高。所以政务场景里，闭源API路线天然受限，而DeepSeek这类提供开源权重的模型，就成了优先考察对象——因为它的核心能力可以完整落在政务云或本地机房，数据链路不离开管理边界。
第二个约束是成本。不是买不起卡，是算力预算的审批逻辑。政务项目要的不是“峰值性能”，是“稳定可报销”。开源权重意味着部署形态灵活，从一台双卡机器做内部试点，到多节点集群做全市级服务，预算弹性大，项目容易立项。用量化版跑通演示的成本，可能只是买一张消费级显卡的钱，这在政务信息化项目里是很少见的低门槛。
第三个约束是生态和工具链。模型再强，如果周边工具不成熟，实施团队就要自己造轮子，项目周期拉长，风险加大。在我接触的项目里，DeepSeek系列模型的周边支持已经相当完善：量化和部署框架、中文向量模型、RAG框架、微调方案都有成熟路径，很少遇到“文档查不到、社区没人踩过坑”的情况。
第四个约束是中文场景的实际效果。政务材料的特点是长文本多、格式固定、术语密集，比如政策文件、会议纪要、办事指南。一个模型在英文基准上分数再高，也不见得能把“一网通办”这类语境下的语义理解对。从实践反馈看，DeepSeek在中文指令跟随和长文档理解上表现稳定，尤其适合政策问答、材料摘要、文书生成这类任务。
这四个约束叠加起来，结论很清晰：这个场景要的不是“最强的模型”，是“能落地、可交付、敢担责”的模型。开源权重加本地部署，是当前最现实的解。
2.2 拿到120页材料先别通读：按五个关键词拆，二十分钟抓到主线
120页的PDF听起来吓人，其实是典型的政务汇报材料结构。我拿到这类文档的习惯是：不做通读，直接按“背景、底座、数据、场景、安全”五个关键词跳读。材料里有些页面是政策背景的介绍，有些是技术架构图，有些是场景示意图，真正对你下一步动作有用的，集中在少数几页。下面这张表是我拆解这类材料时用的固定框架，可以照抄：
| 关键词 | 这部分通常在讲什么 | 你要提取什么 |
|---|---|---|
| 背景 | 为什么现在要做大模型赋能，政策驱动和业务痛点 | 项目立项的核心理由，写方案时直接引用 |
| 底座 | 算力、云环境、部署形态，是集中式还是分布式 | 判断自己的机房环境差在哪，缺什么资源 |
| 数据 | 数据资源目录、知识库建设、数据治理方式 | 自己能拿到哪些数据，哪些数据还在“路上” |
| 场景 | 典型应用案例：热线工单、政策问答、公文辅助 | 挑一个自己业务里最容易复制的场景，不要贪多 |
| 安全 | 数据安全、模型安全、内容审核、责任边界 | 识别哪些是红线，哪些需要提前找安全厂商配合 |
用这个框架过一遍材料，你会发现大部分内容是在论证“该做”，真正影响你“怎么做”的，可能只占两三成。把这两三成抠出来，再决定下一步读哪一页。
2.3 材料的应用主线：同样是“大模型+政务”，背后其实是三种完全不同的技术形态
很多读者把“大模型赋能政府数字化转型”理解成一个东西。实际上，这类材料里讲的应用，拆开看基本都是三种形态的排列组合。第一种是“问答检索型”，比如政务知识库问答、政策咨询机器人。用户问“开餐饮店需要什么材料”，系统先在大模型里检索材料的关联政策，再生成回答。它的核心是RAG（检索增强生成），技术成熟度最高，最适合作为第一个落地场景。
第二种是“内容生成型”，比如公文起草、会议纪要整理、报告摘要。这类应用在业务上很有价值，但因为生成内容需要承担行政责任，流程上必须设计“人工审核”环节，不能做成全自动。很多项目在这里翻车，不是模型不行，是忘了留审核岗。
第三种是“流程执行型”，让模型理解用户意图，调用后端系统的接口完成任务，比如“帮我查一下我这件业务的办理进度”。这种形态最有想象空间，但对系统集成和权限管理的要求也最高。政务场景里，第三种形态往往只开放给内部工作人员使用，面向公众的系统会保守很多。
读这份材料的时候，我建议你把每一个应用案例对号入座，先判断它属于哪一种形态，再看它对基础设施的要求。这样读下来，材料就不再是PPT，而是一张可执行的技术地图。
3. 从材料到可运行：政务环境部署DeepSeek的最小路径与关键参数
3.1 没有全新GPU集群也能起步：先搞清“演示级”和“生产级”部署的差距
我在政务项目里被问得最多的一个问题是：“我们单位没有A100，是不是就没法用了？”答案是：如果你只是想跑通一个内部知识问答的演示，一台普通服务器甚至一台高性能PC机就够了；但如果你想做成一个每天上千人访问的服务，那确实需要认真规划算力。
政务场景里，我把部署分成两个等级。演示级部署的目标是“验证效果”：在内部小范围使用，让业务处室直观感受模型能力，用于向上汇报和申请预算。这个阶段用Ollama这类工具就足够，它把模型下载、量化、启动、API封装都做成了几条命令的事，特别适合没有专职算法工程师的团队。
生产级部署的目标是“稳定服务”：要支持并发请求、要监控延迟和吞吐、要能配置权限和审计日志。这个阶段我一般会建议用vLLM这类推理框架，它支持动态批处理和连续批处理，能把GPU的利用率提上来，同样的硬件配置下吞吐量明显更高。
演示级部署的最小命令长这样：
# 拉取开源权重，以支持本地推理的蒸馏版本为例 ollama pull deepseek-r1:7b # 启动交互式命令行，直接测试效果 ollama run deepseek-r1:7b # 启动兼容OpenAI格式的本地API服务，端口默认11434 ollama serve这里的逻辑是：先通过Ollama把模型跑起来，确认业务效果满足需求，再考虑迁移到生产级框架。第一次做试点，不建议直接上复杂方案。参数说明：模型名中的“7b”表示70亿参数规模的蒸馏版本，对显存要求友好，适合在单卡或消费级显卡上跑通验证。如果你的机器显存充足，可以考虑更大的参数版本，效果会更好，但部署复杂度也会同步上升。
关于显存，有一个经验公式很好用：参数量乘以每个参数占用的字节数，再乘1.2左右的冗余系数。以7B模型为例，如果用INT8量化，每个参数约占1字节，那么7GB显存是底线，实际建议预留12GB以上。量化等级的选择遵循一个原则：演示用INT4，测试用INT8，追求稳定效果就上FP16。别一上来就用最小量化版本，很多效果问题其实是量化压出来的。
3.2 RAG三段链的政务化改造：让模型只回答它“确实知道”的内容
政务场景落地大模型，90%以上会用到RAG：先把政策文件、办事指南、历史工单等文档灌入知识库，用户提问时先检索相关资料，再把资料和问题一起交给模型生成答案。它的价值在于：模型不再凭空发挥，而是基于给定的材料回答，这叫“可溯源的生成”。
RAG的完整链路包含三个环节：切分、召回、生成。看似简单，但政务场景里每个环节都有专门的讲究。切分环节，不能按固定字数简单切，要尽量按文档结构切——一个条款、一个章节保持完整，否则政策文件里的“以上”“以下”这类指代词会失去指代对象。召回环节，要控制返回片段的数量和相关性阈值，太少了答案不完整，太多了把无关内容塞给模型，反而干扰生成。
下面是一份我常用的RAG参数配置，可以直接作为起点：
{ "chunking": { "strategy": "by_section", "chunk_size": 512, "overlap": 64 }, "embedding": { "model": "bge-large-zh", "dimension": 1024 }, "retrieval": { "top_k": 6, "score_threshold": 0.5 }, "generation": { "temperature": 0.1, "max_tokens": 1024, "cite_source": true } }参数说明：chunk_size设为512适合政策文件，过大容易包含多个主题，过小则语义不完整；overlap取64个字符，防止关键信息正好落在切分边界上。top_k设为6意味着每次最多取6个片段拼进上下文，太少答不全，太多会超上下文窗口。score_threshold是召回相似度阈值，政务场景建议从0.5开始，如果发现答非所问就调高到0.6以上，如果答不全就适当调低。
最关键的参数是temperature。政务场景建议固定为0.1甚至更低，因为它的作用是控制输出的随机性，政务回答追求的是稳定和严谨，不是创意发散。我在项目里见过有人直接沿用通用场景默认的0.7，结果同一份政策问三遍，三遍表述都不一样，评审会上直接被点名。这个问题其实就是temperature没调好。另外把cite_source打开，让模型在回答时引用材料中的文件编号或条款号，政务场景里这个动作能解决一半的信任问题。
3.3 让模型按政务格式说话：提示词里写清身份、任务、输出格式
模型部署完之后，第一件要做的不是写业务代码，而是设计一套稳定的提示词模板。政务场景的提示词，和通用场景的“聊天式”提示词完全不同，核心诉求是三个：角色限定、任务明确、格式固定。角色限定告诉模型“你是谁”，而不是让模型自由发挥；任务明确是告诉它“你这次要做什么”，不给它发散空间；格式固定则是为了保证输出结果能被业务系统直接解析。
我习惯把政务问答的提示词模板设计成固定结构，然后通过代码拼装参数，而不是让用户自由输入。一个面向事项问答的模板大概长这样：
{ "messages": [ { "role": "system", "content": "你是某市政务服务中心的智能咨询助手。你只能依据知识库中给定的政策文件和办事指南回答问题。如果知识库中没有相关信息，你必须回答“暂未查询到相关信息，请拨打12345咨询”，禁止自行编造。回答时需注明依据的文件名称和条款。" }, { "role": "user", "content": "请根据以下材料回答问题：【材料内容】……【用户问题】在厦门开一家餐饮店需要办理哪些许可证？" } ] }这段模板做对了几件事：第一，用“你是……助手”锁定模型身份，不给它当“百科全书”的机会；第二，用“只能依据知识库回答”限制信息来源；第三，对无法回答的情况给出了兜底话术，这一步非常关键，政务场景不怕模型说“不知道”，怕的是模型“不知道还编”。第四，要求注明依据，相当于给回答上了一个“可追溯”的保险。这个模板可以复用一整类场景，把“餐饮店”换成“药店”“培训机构”，它照样能工作。
提示：政务问答类应用，模型“拒绝回答”的机制一定要在提示词层面就设计好。宁可多答几次“暂未查询到”，也不要让模型在不确定的情况下硬答。
4. 政务场景落地DeepSeek的避坑指南：五条可复现的排障记录
4.1 同一份政策问三次给三种答案，原因不在模型笨，在检索链不稳定
现象：知识库上线后，业务测试人员对同一个问题反复提问，得到的答案每次都不完全一样，有时甚至引用不同条款。最典型的场景是“开餐饮店需要哪些材料”这类事项问答，上午答三项，下午答五项。
原因：模型生成环节本身加入了随机性，前面说过temperature没设到低位；更隐蔽的原因是检索环节不稳定——知识库被重复灌入、向量化后的相似度排序出现抖动、或者top_k附近的几个片段分数接近，导致每次召回的上下文不一致。
解决：我按三个步骤排查。第一步，确认generation的temperature已调到0.1以下；第二步，检查知识库有没有重复文档，政务项目经常出现同一份政策文件被多人上传多次，库里几十个相似片段，检索时自然“随缘”；第三步，把score_threshold略微提高，过滤掉低质量片段，保证每次召回的都是同一批高置信度内容。排查完这三步，大多数“答得不稳”的问题都能解决，再不行就要检视切分策略是否合理。
4.2 演示很流畅，上线第一天并发直接打满，问题出在没做压力测试
现象：项目试点阶段一切正常，结果系统正式开放的第二天，业务高峰期延迟暴涨，界面转圈，运维群里开始刷屏。领导问“你们不是测试过吗”，实施团队很委屈：“测试的时候好好的”。
原因：测试只验证了功能逻辑，没有验证性能边界。我在很多项目里看到，内部测试是几个人轮流提问，模型当然响应及时；但政务系统一旦开放，瞬时并发可能到几十甚至上百，GPU是并行处理请求的，并发上来后推理队列堆积，首字延迟会成倍放大。量化模型能跑通，不代表它在高并发下能扛住。
解决：上线前必须做一轮粗暴的压力测试，用脚本模拟多用户同时提问。重点看两个指标：首token延迟，也就是用户从发起请求到看到第一个字的时间，政务体验建议控制在2秒内；以及吞吐量，也就是每分钟能处理多少个请求，这决定了你要准备多少台机器。如果压测结果显示当前硬件只能扛20并发，那就老老实实做限流，给API网关配置并发限制，并在前端提示“系统繁忙请稍后再试”。比上线后崩溃好得多。
4.3 模型回答内容没问题，但业务系统解析不了输出格式
现象：智能问答系统接入了政务服务的统一受理平台，结果发现模型返回的内容没法直接入库存表。有的回答多了一行“如果您还有其他问题”的客套话，有的在JSON输出里夹杂了自然语言解释，导致解析失败。
原因：模型遵循了内容要求，但没有约束输出格式。业务系统是“格式化”的，模型是“自然语言”的，两者之间缺少一道翻译关卡。尤其是用OpenAI兼容API时，很多人以为返回内容就是最终落库内容，完全没考虑到模型可能追加额外文字。
解决：两个办法配合使用。第一，在提示词里明确要求“只输出JSON，不输出任何解释性文字”，并给出JSON字段的示例；第二，在代码层面对模型输出做解析和校验，解析失败则自动触发一次重试。更稳妥的做法是使用支持结构化输出能力的推理框架，它在解码阶段就保证输出符合预设的JSON Schema，基本杜绝格式漂移。我在政务项目里的经验是：永远不要信任大模型能自动输出“恰好”符合业务格式的东西，“生成后才校验”这个兜底必须做。
4.4 以为接入大模型就能“全网知识”全知道，这是最贵的误解
现象：业务处室提需求时说“能不能让系统自动检索最新的政策法规”，项目团队给出的方案却可能直接调用外部在线API，把群众问题转发到第三方模型服务。第三方确实能给出看似合理的回答，但项目未通过安全评审，被要求整改。
原因：没搞清楚“外部API”和“私有化部署”的边界。政务场景对数据流向审查非常严格，公众提交的咨询内容一旦离开政务网络边界，哪怕是通过加密通道，也可能被判定为数据出域。有些模型API条款还允许使用对话数据做训练改进，这在政务场景是直接触及红线的问题。
解决：把使用范围分为两类。涉及公众信息的问答场景，一律使用本地或政务云上私有化部署的模型，数据推理全程不离开管理边界；只有处理公开信息、不涉及个案数据的场景，才允许走外部API。这个边界要在项目设计阶段就写明，不要等到评审时被翻出来。另外，即便是私有化部署，敏感数据推理过程也要记录日志，保留审计线索。
4.5 模型跑通了，但没人敢对输出结果负责，这是政务项目特有的坎
现象：功能都开发完了，业务处室却拒绝验收。理由很直接：“系统给出的办理建议如果错了，谁负责？”这个问题不是技术问题，也不是大家不愿意担责，而是流程上确实缺少一道“安全兜底”的设计。
原因：政务应用天然带有行政责任属性，模型输出的内容如果直接作为业务依据，出了问题难以追溯。材料里可能写了“大模型赋能”“提质增效”，但没写“模型答错了怎么办”。落地团队如果只做“正向功能”不做“负向兜底”，项目就永远走不到验收环节。
解决：在架构设计里增加“审核层”。面向公众的自助问答，模型回答必须是参考信息，页面明确标注“以窗口工作人员答复为准”；面向内部工作人员的辅助生成，必须增加“人机协同”流程，模型生成初稿，人工确认后生效。技术上要做的，是把审核动作记录进系统日志，形成“模型生成、人员确认、系统留痕”的闭环。有了这层兜底，业务处室才敢签字。
5. 从通用到专用：微调时机、智能体闭环与评测集打分
5.1 别急着微调：先判断是不是“知识不够”，再判断是不是“表达不对”
很多团队拿到大模型第一反应是“我们要微调”。但在政务场景，微调是手段，不是目的。我见过一个项目的真实情况：模型对特定领域的政策文件回答不准，团队花了三周做微调，效果提升有限，最后发现只是知识库没灌入对应的政策全文，做一个RAG检索就解决了。先RAG、后微调，这是我反复强调的顺序。
那什么时候才需要微调？判断标准有两个。一是知识密度极高且表达高度格式化的场景，比如特定部门的公文写作，要求模型严格遵循本部门的文种格式、用语习惯，这类固定风格靠提示词很难“锁住”，微调更有效。二是模型需要长期稳定地完成某个特定任务，比如把业务系统里的工单描述自动转成标准分类，这种任务的输入输出模式完全固定，非常适合微调。
微调数据集不需要很大，但要精。一条标准的微调样本长这样：
{ "instruction": "将以下工单内容转为标准服务分类。", "input": "小区门口路灯连续三天不亮，晚上出行很不方便，希望尽快维修。", "output": "一级分类：公共设施；二级分类：道路照明；建议部门：市政管理部门。" }这个例子的说明：每条样本的input是真实业务里采集并脱敏的工单原文，output是人工标注的标准分类结果。微调本质上是在教模型“同样的输入，按我的格式输出”。政务场景微调优先用LoRA这类参数高效微调方案，它只训练一小部分参数，对显存和时间的要求远低于全量微调，许多团队的实践里效果已经够用。数据规模从几百条开始就能看到变化，重要的是质量和覆盖度，不是数量。
5.2 智能体最小闭环：让大模型“听懂人话”，让业务系统“办成事”
前两种形态，都是模型“说话”给人听。智能体形态更进一步：模型“说话”给系统听，系统替用户把事办了。举一个典型的政务场景：公众打电话进热线说“我社保卡丢了要怎么补办”，传统IVR系统需要用户按一堆菜单键；智能体方案是话务员把用户原话粘贴给系统，模型自动识别关键信息、调用相关业务系统的查询接口，返回办理指引。
这个闭环里有四个环节：意图识别、实体抽取、工具调用、结果生成。意图识别负责理解“用户想办什么事”，实体抽取负责从话里抓关键参数，比如身份证号、事项编号，工具调用负责向后端业务API发起请求，结果生成负责把系统返回的数据翻译成普通人能看懂的话。四个环节里，最容易出问题的是工具调用。
有个真实场景值得一提：模型向业务API发起查询请求时，业务API没有在模型等待时间内返回结果，对话进程就会报错退出，错误信息类似于“tool calls need immediate results”。我在项目里第一次遇到这个报错，排查了很久才发现是后端接口响应超时。解决方式是在API网关层做超时控制，给后端接口设定明确的响应时限；如果确实有业务接口响应很慢，就不能直接走同步调用，要改成异步任务模式，先返回“正在查询”再推送结果。这是智能体落地时最容易踩的性能暗坑，很多人以为是大模型本身的问题，其实是工程链路的问题。
工具调用的权限边界也是政务场景的红线，模型只能调用白名单内的查询类接口，任何写操作必须经过审批流程。技术上可以给每个工具定义一组“允许入参”，模型调用工具前先通过参数校验，防止模型被恶意提示词诱导而调用越权接口。智能体的每一步调用都要留痕，这一点在做架构设计时就要想好。
5.3 效果验证：不要用“感觉挺好”交差，建一份评测集打分
政务项目验收时，最怕听到“效果不错，但说不出哪里好”。大模型项目的效果评估一直有“黑匣子”的感觉，但正规的落地流程里，这份感觉要变成一套可重复执行的评测集。评测集就是从历史真实业务数据中抽取一批有标准答案的样本，用它来反复测试模型的效果变化。
评测集不需要太大，几百条就够了，覆盖四类必测内容：普通咨询类问题、带复杂上下文的问题、材料中没有答案的问题（考验模型会不会乱编）、以及带有诱导性的问题（考验模型会不会给出越权或不安全的内容）。最后这两类是政务场景特有的“负向评测”，专门测试系统的拒绝能力和安全兜底能力。
构建评测集的步骤是：第一步，从历史工单和政策问答记录中抽取原始问题，做脱敏处理；第二步，由业务骨干标注标准答案，每条包含“答案要点”“依据文件”“是否应该拒绝回答”三个字段；第三步，用自动化脚本把评测集批量喂给系统，记录回答结果；第四步，由人工按维度打分。评分维度建议固定为四个：准确性（答案对不对）、完整性（要点全不全）、合规性（有没有乱答不该答的）、格式规范（能不能被系统解析）。用一张表记录每个版本的效果变化：
| 评测维度 | 权重 | 说明 |
|---|---|---|
| 准确性 | 40% | 核心要点是否正确，是否有事实性错误 |
| 完整性 | 20% | 关键要素是否遗漏，比如材料清单是否齐全 |
| 合规性 | 25% | 是否存在编造信息、越权回答、不安全内容 |
| 格式规范 | 15% | 输出是否稳定，能否被下游系统正常解析 |
评测集要随版本迭代，每个模型版本、每调整一次提示词，都跑一遍，跑完记录分数，对比前后变化。这套流程看起来笨重，却是政务项目里最有说服力的交付物。我刚做第一个大模型项目时也觉得评测集麻烦，后来在评审会上，一份完整的评测报告比任何PPT都管用。模型可以继续调优，但评测集一定是先于模型存在的。
6. 把120页变成落地清单：三个“后悔药”技巧
第一个技巧：把材料里的场景按“成熟度”分三档。第一档“现在就能做”，比如政策问答、知识检索这类以RAG为核心的应用，工具链最成熟，风险最低。第二档“可以试点”，比如公文辅助起草、会议纪要整理，价值明确，但必须设计人审环节。第三档“先别碰”，比如直接用大模型做行政审批决策、自动化出具法律意见，这类场景责任边界还没厘清，技术再先进也推不动。在这个方向上，正确的做法是：盯住第一档项目，快速缩短见效周期，用成果养后续的深度投入。千万别把战线拉得太长。
第二个技巧：把材料里的架构图翻译成“数据流、权限流、审核流”三张图。材料里的架构图是为了汇报好看，你要把它改成能落地的工程图。数据流回答“数据从哪来、在哪个环节被模型处理、结果存在哪”，权限流回答“谁能用这个系统、能触发哪些模型能力、不能碰哪些数据”，审核流回答“模型输出在哪个环节被人确认、确认动作有没有留痕”。画完这三张图，项目的实施边界和部门分工就自然清晰了。
第三个技巧：写一张“不做清单”。我拿到任何一份政务向的大模型材料，会先逼自己列一件事：哪些事情是这次坚决不做的。不做自动办件审批、不做面向公众的开放式自由问答、不做与现有业务系统深度耦合的智能体……这些“不做”看起来保守，但它是项目能按期验收的保障。先做窄做深，再做宽做广，这个顺序在政务大模型项目里几乎不会错。
这三个技巧是我做了几个政务大模型项目之后总结出来的后悔药。尤其是“不做清单”，当年要是早点写，能省下不少返工的功夫。希望帮到你。
本文还有配套的精品资源，点击获取
