把几万个政务网址合成一个入口，先接不住的是问答
一、入口集中之后，第一个变形的是内容责任而不是页面数
据公开报道，被取代的分散站点数以万计。这个量级只是背景，不是我们做判断的依据。真正值得拆的是另一件事：一个入口要接的从来不是同一种东西，它在技术上至少承接三类对象，而这三类对象的更新驱动力、权威性要求和容错空间完全不同。
| 对象类型 | 更新由什么驱动 | 权威性要求 | 问答层可参与的程度 |
|---|---|---|---|
| 事项办理 | 依据文件修订、流程调整、材料变更 | 每个字段都要能对上正式文件 | 只能指路与列材料，不能下结论 |
| 信息查询 | 事实类内容自身变动 | 允许延迟，但必须带来源与更新时间 | 可以直接答，必须附出处 |
| 政策文件 | 发布、修订、废止 | 版本链必须完整保留 | 只能引用原文，不做解释性改写 |
把这三类混在一个搜索框里，就是答非所问的起点。事项办理的一条材料清单过期，和一份政策文件的旧版本被检索命中，是两个完全不同性质的错误：前者让申请人白跑一趟，后者让答复在字面上无懈可击却依据作废。入口集中不会自动消掉这种差别，它只是把差别挪到了同一个页面上，于是原来的“各站点各自负责”变成了“一个入口全权负责”。对做交付的人来说，这一步改变的是责任归属结构，需要重谈的是一次内容主权认定，而不是导一批 URL。
二、内容清点的四个必答项
一个机构的内容要被接进统一入口之前，有四个问题必须先有明确答案，缺任何一个，后面做的都是表面功夫。
一是该事项归哪个机构。同名事项在不同机构下的办理口径经常不一致，入口层不做归属认定，检索层就会把两个答案同时端出来。二是办事依据的是哪一版文件。这一项要落到具体字段：文件标识、版本、生效与废止状态、原文可访问位置。只存一份正文副本而丢掉版本链，等于把权威内容降级成了素材。三是材料清单与办理时限由谁维护。这两样是最容易被业务侧改、又最少被同步的字段，必须写成“有署名维护人的活字段”，而不是迁移时的一次性快照。四是原站点的存量地址怎么处理。存量地址不是运维细节，它出现在指南、表格、外部链接和纸质材料里，重定向策略要按引用来源逐条盘。
清点结果建议直接落成一张表，每行一个事项，列是事项标识、归属机构、依据文件与版本、材料清单维护人、办理时限来源、原站点地址、迁移状态。这张表的字段设计有一个原则：每一列都必须能被某个具体的人回答，答不出就留空并标为待确认，不要由集成方代填。代填的列在第一次业务检查时就会暴露，而暴露的代价由集成方承担。洹拓做过类似的多源内容合并项目，最后写进合同的交付物就是这张表加一份维护人签字页，比任何功能清单都管用。
三、合并最容易断的五类链
分散站点合并的故障很少出现在首页，都藏在深链和附件里。五类断链按发现难度排序如下。
- 旧地址未重定向。用户从收藏、从别人发的链接进来，落到错误页。这类最容易被测到，因为错误率会立刻反映在访问日志的 404 上。
- 深链接指向已改版页面。地址能打开，但页面结构换了，原本那个具体条款的位置变了，用户以为自己看的是全文，实际落地在栏目页。
- 附件与表单未迁移。正文搬完了，正文里挂的表格、申请书、说明文档还在旧域名上，等旧域名回收才断，往往滞后一段时间才爆发。
- 机构简称与全称在检索里不一致。同一个机构有三种写法，检索按字面匹配时，只输入简称的查询召不回正确条目。这类问题最难归因，用户只觉得“搜不到”。
- 同一事项在两个入口都能进。新旧并行期最常见，两条路径的答复口径不一致，就产生了新的争议源。
前三类可以靠爬虫加链接检查批量发现。第四类要靠同义词表与别名词表，而且这份表要跟着机构更名持续维护。第五类只能靠规则拦，也就是下一节要写的并行期规则。
四、并行期要提前定死三条规则
新旧两个入口同时存在是常态，问题在于并行期没有规则时，一线人员各自解释。三条规则要写在迁移方案里，不是写在客服话术里。
第一条：以哪个入口为准。判定依据不是“哪个新”，而是“哪个条目的依据文件版本更新且维护人明确”。同一事项两个入口都在线时，页面要显式标注以哪一个为准。第二条：以什么时点切换。切换时点必须是公告的一个明确时刻，且这个时刻一到就把旧入口的写权限关掉——保留只读、关闭编辑，避免两边同时改内容。第三条：未在期限内完成合并的条目怎么标。建议直接给三种状态，已合并、待确认、已停用，并把状态展示到结果层。待确认条目要能进检索，但答案里必须带上“本条内容尚未由原机构确认”这句话。
五、问答层的三条边界与答非所问的四类原因
问答层的失败从来不是模型不够强，是边界没划。三条边界要在上线前写成配置而不是写成期待。
一是能答什么类型。信息查询类可以答，事项办理类只能列材料并给链接，涉及资格认定、时限承诺、争议处理的一律不能由机器下结论。这条要落成黑名单事项清单，命中就直接转人工。二是必须给出处。没有可核验出处的回答不允许返回给用户，这是最硬的一条产品规则，比任何回答质量优化都优先。三是不能替代判定。答复里凡出现“您可以办理”“符合条件”这类断言，都应改写为指引与条件原文。
四类常见原因和各自的拦法：
| 原因 | 现象 | 拦法 |
|---|---|---|
| 知识源过期 | 答的内容字面通顺但依据已作废 | 内容版本化，只索引有效版本 |
| 检索召回错条 | 问 A 事项召回 B 事项 | 按事项归属做过滤，不做全域自由检索 |
| 把草稿当正式文件 | 引到未发布或征求意见稿 | 正式与草稿分开索引，默认只查正式库 |
| 缺主体判定 | 不区分申请人身份、地区 | 先做主体确认问答，无法确定则转人工 |
第三类最容易被忽略，因为征求意见稿的文本往往比正式文本更详细，检索分数更高。把草稿单独建索引并在答案里强制标注，是成本最低的一道闸。
六、兜底三档与验收的两条硬指标
兜底不是“答不上来说句抱歉”。三档按可用性从宽到严排列：给出出处与原文链接；给出归属机构与联系电话；明确拒答并转人工。三档里最坏的选择是让模型生成一个流畅但无出处的答案——它读起来最像成功，纠正成本最高，也最容易变成投诉源头。宁可选第三档，也不要在没有出处的情况下返回事项办理类结论。
验收设计也因此不该看回答流畅度。可行的做法是按事项类型分层抽题，每类各出一批题，只统计两条硬指标：是否给出了可核验出处；是否在应该转人工的时候触发了转接。这两条都是二值判定，可以自动化检查，也能周复一周对比。至于“回答得像不像人写的”，放进观察项，别放进验收线。
对外承诺的口径管理同样要落到字段。问答里出现的办理时限和材料清单，必须与正式文件同源生成，不能有一份独立维护的问答文案库。一旦两份数据各自演化，问答就成了新的争议来源，而这类争议的举证责任全在入口运营方。这套做法我们总结成一句话：入口可以集中，责任不能集中；先把每一条内容的维护人写清楚，再谈用机器回答。