公司今年碰到三次同样的情况，经过都差不多：
系统演示了，功能点也一项项测过，采集效果对方也认可，技术和小领导都很满意。但是方案报上去，大领导回复说是：现在AI都能写代码，没必要花这个钱，让技术人员自己拿大模型写一套。
碰到这种情况，我们很无奈，但是也没办法。
这个判断其实也不能算外行。因为以现在模型的能力，一个功能齐全，还能点击操作、能翻页、能检索、能导出、界面还挺好看的前台，几天就能迭代出来。只从这一方面看，大模型自建确实省钱。
这个账只算了看得见的那一半。剩下的部分要系统跑起来才看得见，也不在预算表上。
01 大模型开发的：前台功能齐全美观成本低
这一点先认下来，展示层确实是自建的强项。
具体说，一个检索框加几组筛选条件、列表带关键词高亮、导出和分页，这些以前要排期的活，现在描述清楚，几个小时就能出一版。改版式更快，领导说按钮往左挪、主色换深一点，几分钟的事。界面审美上，大模型版本普遍比我们做得好看，这一点不用争。
自建还有一点，是采购流程替代不了的：需求能直接改。业务部门说这个字段要加、那个筛选项要去掉，当天就能动。走采购的项目，需求变更要评估、排期、确认工作量，一轮下来一两周。
所以前台这一块，自建确实比我们做得好。
图1 前台展示页
分类、订阅、检索、分析、专题、问答、报告，前台该有的这些栏目用大模型开发出来确实都不难。
但前台只是展示层。摆什么，取决于后面有多少数据、全不全。界面做得再顺手，点进去只有三成内容，用户用两周就会发现不对劲，而且他说不清哪儿不对，只觉得这套系统不靠谱。
前台真正的复杂度也不在页面上，在背后要处理多少种规则。一条信息分到哪个二级子类、标签怎么打、同一事件的不同来源怎么合并、不同权限的人看到的内容差在哪，这些规则一条都不画在界面上，却决定了界面上每条数据长什么样。我们前台14个功能模块，相当一部分是这类规则，不是页面。规则不在代码里，在业务判断里，模型照着描述能画出页面，写不出这些规则。
02 细节功能是被长期应用磨炼出来的
一个模块用满三个月，才会长出真正的需求。
功能做到有，和做到顺手，中间隔着几百处小细节的打磨。这些打磨不是设计出来的，是用户在具体场景里问出来的。
举个具体的。信息分类这个模块，第一版按来源分、按时间分，看着没问题。用到第三个月，做研究的人提出来：能不能按装备型号把我订阅的东西归到一起。加上之后又发现型号有别名，同一个东西英文一种写法、俄文一种写法、音译成中文又一种，不合并还是散的，于是要做别名表。别名表做完，又发现有些型号在不同国家的编号体系里根本不是一回事，只能人工确认。
这一串没有一条是坐在办公室能想到的。都是有人在用的时候，用到某个具体的坎上，提了一句能不能怎样。
我们后台有个词典管理，军事、航天、科技的专业词库要定期更新，就是这个来路。通用分词会把“导弹旅”切碎，会把装备型号当成乱码或者人名，检索直接召不回来。这件事只有天天搜的人知道疼，而天天搜的人往往不是提需求的人。
工程化系统那几百个细节，来源是十几年里一个个用户的具体抱怨，抱怨一次补一条，补完还要验证有没有影响别的地方。自建系统的细节来源，是建设者自己想到的部分，加上上线之后慢慢暴露的部分。当然后者也可以积累，但要花时间。
03 后台管的是三个关键点
这一块不产生任何看得见的产出。
后台这块，两种做法的差距拉得最开，也最少有人提。
多数人理解的后台是“管理内容”，实际上一套情报系统的后台要管四件事。
第一件是信息源管理。几千个目标站点，每个要有类型、国家地区、语种、置信等级、启停状态，还要按主题分组。新站要能发现、能加进来、能试采。
图2 信息源管理
分组按主题走，一个组几个源到上百个源。哪一组这周少了几条，从这里能看出来。
分组解决的是按业务看，置信等级解决的是按质量看，后者更麻烦。同一个源，刚加进来只能先按C记着，跑够一段时间，看转载率、原创率、有没有频繁改版，再往上升。哪个源权威、哪个源爱转载、哪个源三天两头改版，都得有记录。否则报告里引了一条小道消息，从后台看不出来，出事的时候也查不回是哪一环松的。
第三件是权限和留痕管理。谁能看哪个目录、谁能改哪个源、谁动了哪条配置，出问题要能倒查。审计日志记操作类型、对象ID、操作人、IP、结果，连被拒绝的登录也在里面。
图3 操作权限管理
改的是哪个分组、谁改的、几点几分，一条一条留着。验收会上不会有人提，出事第一个被问。
第三件是运维监控。服务器负载、任务调度、代理池可用率、导出记录、待审队列。
这四件事都不产生看得见的产出。系统跑得好的时候没人打开后台，出了问题第一件事就是打开后台。
自建难补这一块，不是因为技术。这些页面都不复杂，一个列表加几个开关，让模型写很快。问题是需求方看不见。
提需求的是使用方，他能提的只有“我被什么困扰过”。被报告格式困扰过，就提模板定制；被搜不到困扰过，就提检索优化。PG和ES漂移这种事他没碰到过，因为还没发生在他身上，他甚至不知道有这种东西存在。没发生过就想不到要提，需求里没有，prompt里自然也没有。
模型很听话，你说什么它写什么，描述里没有的，它不会替你想。这跟能力没关系，问题在信息不对称。
图4系统运维监控
自建系统的后台，往往长这样：内容管理有，那是最直观的；源管理有个列表，但没有等级和分组模板；监测几乎没有；权限和审计是最后补的，补的时候已经积了一批说不清来源的数据。我们后台12个管理模块，基本是出了问题之后一件件补的，这个先后顺序本身就是经验。
04 采集：人工配置和模型智能获取的区别
采集这段最好验证，两种做法的差别在这里也最明显。
人工定向配置，每个信息源单独过一遍：抓列表页还是详情页、翻页怎么翻、翻到第几页停、多久抓一次、字段对应页面哪个位置、要不要带登录态、附件下不下、走哪个地区的代理、要不要按发布时间往前回溯。规则可能是一条或者几条定向配置，也可能是一个定制的小工具，也可能混着用。
碰上不规整的站，工作量还会翻几倍。比如同一个站不同页面结构不一致、表头两行合并的、单元格跨列的、一页四千行的大表等等。数据也不一定在页面上：有的在JS源码里，有的在XML数据里，有的要等XMLHTTP请求回来才填进下拉框，还有的放在远程FTP的文本文件里。编码要认GB2312、GBK、BIG5、ISO-8859-1，认完还要转简繁。再往下是地域限制、频率限制、防盗链、把数字做成图片、登录过期、验证码。
大模型能做的是通用抓取。给一个结构规整的新闻列表页，它写的parser能用，而且不差。这类站点在公开信息源里占相当比例，政府机构和媒体官网里比例更高。论坛、社交账号、要登录的内部平台、结构乱的老站点，通用抓取基本没办法。
真正的区分不在覆盖率，在输出来的东西是什么性质。
人工配的规则是确定的。同一个规整页面，今天解析出37条，明天还是37条，每个字段落在哪一列是写死的。出错能定位，改一条xpath再跑一遍，你清楚自己改的是什么。
模型抽取是每次重新理解页面。同一张列表页，上午跑出32条，下午可能38条。多出来的常是“下一页”“查看更多”这类导航文字被当成条目，少掉的是模型判断为不重要的短讯。字段错位更常见：把更新时间填成发布时间，把栏目名认成作者，把合并单元格里的内容重复填进下面每一行。单看一两条，这种错一眼能看出来；库里躺着上万条的时候，没人看得出来。
连带的问题是增量判断。工程化采集判断“这条是不是新的”，靠一根水位线：记着上次抓到的最大ID或最新时间，下次从那个点往后取，前提是解析结果稳定。模型抽取的结果不稳定，去重只能退回全文比对，页面改个标点就当成新条目，同一条信息在库里躺三份。
图5 回溯补采
发布时间2021年3月，采集时间2026年11月。中间这五年半，是往回翻出来的。
所以客户问“能不能把2019年以来的都补回来”，人工配置的回答是能，给出时间区间、给出页面能翻到多深、给出哪些年份站点已经没有存档。通用抓取的回答通常是先试试,试完发现只能拿到最近几页。
还有一件事只有交付时才会被提起：清单。几百上千个源里，多少个已经配好、多少个待配、多少个配不上、配不上是因为要登录还是因为数据在图里。这张清单是验收依据，也是第二年报预算的依据。人工配置给得出来，因为每个源都是人过了一遍。自动抽取给不出这张表，它只能给一个成功率，而成功率的分母是什么，说不清。
05 每天需要的增量采集
上线只是开始，真正的活是每天的增量采集动作。
系统布署完之后，每天要做的事是一样的：把清单上每个站过一遍，看有没有新的，有就抓回来、解析、清洗、入库。
这事听着简单，做起来是个笨活。站点一多就出窟窿：哪个源今天没进数据，这一天对应的国家和机构就是空白。
其实采集配置失效是常态，源站改版、加反爬、换登录方式、字段挪位、换CDN之后返回空页面，每个月都在发生。一个信息源一年动两三次算稳定，动十几次的也有，比如脸书等。
改版之后的现象很有特点：任务还在跑，进程正常退出，日志看都是成功，但是抓回来的正文是空的，或者标题那一列填的是发布时间。发现的方式通常是第二天早上翻库，看见某一路采集量掉到零。
图6 入库趋势
比如上图，中间低谷那一段是11月03日，可能就是几个源失效，数据没进来，任务日志还是绿的。
所以长期运行要的不是“能抓”，是一套监测的东西：每路采集量要有基线和波动区间，掉到一定比率就要预警；入库前做字段校验，看关键字段非空率、时间格式、正文长度、重复率；双写对账，看PG和ES差多少条；站点结构定期截屏比对，判断有没有改版；再加上服务器负载、代理池可用率、调度失败率，以及一个待审队列。
这些功能写起来都不难，难在要一直开着，还得有人看。告警发出来没人处理，等于没设。
这是自建系统比较难过的一关。模型只在被调用的时候存在，没有进程常驻在那儿，早上八点去看一眼昨晚的采集量；也没有机制在源站改版的当天把异常报出来。
图7采集可视化管理
要做好这件事，关键还是得有人。要么使用单位自己养一个专业的人，得对需求和技术都熟，学习和摸索估计要几个月，每天的工作是看数据、改配置、处理告警；要么把这块外包给天天干这些活、熟悉整个流程的人。两条路都要花钱，只是记在不同的账上。
06 三笔成本账对比
建设、运行、兜底，三笔账记在不同的地方。
成本这件事，合起来算和拆开算，结论差很远。
第一笔，建设成本。大模型开发自建这一笔几乎为零，是真实优势。工程化的外购系统一次性投入不小，这也是它最容易被打回的原因。
第二笔，让数据持续正确的成本。信源要配、要盯、要重配。告警要人看，误报要人调阈值。待审队列会积压。这一笔按月发生，和源的数量基本成正比。
给个量级：一个规整的新闻列表页，包含配置、测试和调度上线，大约1-2小时能配完；一个要登录、要翻页、表头分单双行的政府站点，顺利小半天，不顺利反复测试修改前后要几天。两千个源的项目，配置阶段的人月投入按十个往上算，运行阶段每个月还得有人盯着。
并且用模型抽取也不是零成本，只是换了个名字。每抓一页要过一次模型，token按量计费。碰上论坛、大表、长正文、附件下载、视频下载，一天几万条跑下来，这笔账不比人工便宜，而且随源数量线性涨，人工配置是一次性的。
第三笔，故障兜底的成本。原始网页快照、解析日志、操作留痕、导出记录、补采能力。这一笔很少有人想起来，因为它在出事之前不产生任何可见产出，预算表上也没有对应的行。可一旦有人拿着一条数据问“这条哪来的、什么时候抓的、有没有改过”，缺了它，整套东西的说服力就没了。
图8 报告生成
比如有一份报告14个章节、信源29条，生成状态要逐条留着。这些数字背后是每条引证能不能回到原文。
自建省的是第一笔。第二笔和第三笔一样要花，只是花在自己人身上：工资照发，活是加出来的，不会出现在任何一张预算表上。这也是“自建便宜”这个结论在头一年总成立的原因——第一年往往还停在能用的阶段，问题没集中爆发。
按三年算，账肯定是翻过来的。采购是每年一笔看得见的维护费；自建是几个人几年里被慢慢吃掉的时间，再加上数据不全、报告被打回、重复返工这些隐性损失。两笔钱不好直接比大小，但说自建一定便宜，站不住。
07 结论
这件事没有统一答案，但有分界线。
六个方面比下来，落到实际就是三种情况。
第一种，自己写就够。源在二十个以内，都是结构规整的大站，数据只对内看，结论错了不影响对外，单位里也确实有人天天盯着。这种情况几个脚本加定时任务完全够用。为一次行业汇总上采购流程，划不来，也没必要。
第二种，该走工程化。报告要交给外部单位，结论被质疑时要能回到原始网页；源在几十个以上，里面有动态、文献、数据类、社交账号等各种类型，并且还有需要要登录的、需要检索等类型平台；系统要连续跑多年，可能中途会换人的。如果这几条占两条以上，自建省下的那笔钱，时间长了（半年后）通常会以返工、补采、报告被打回的形式还回来。
第三种最麻烦，也最常见。信息源很多，需求也具体，但单位里没有专职的人盯数据。这种情况两条路都不通：自己写的没人维护，买了系统也可能没人用。得先把专项对接的人定下来，再谈系统。这件事比选哪条路更要紧。
你的情况 | 选哪条路 | 主要代价 |
源20个内，只对内，有人盯 | 自己写 | 换人即断档 |
源几十上百，含论坛社交站 | 工程化系统 | 一次性投入高 |
源多，但没人专职盯 | 先定人或外包运维 | 建了也难长期跑 |
怎么判断自己属于哪一种？问三个问题就够了：
1、任务报成功的时候，你们怎么确定数据是合格的（全和准）？
2、源站改版以后，一般多久能发现，靠谁发现？
3、一到两年下来，这套系统长期稳定运行要占几个人、多少工时？
问完，两边都会给出答案。多数时候是答案决定选哪条路，而不是先选路再找理由。
说个我自己的看法：大模型能把一套情报系统的前台做得很美观，这个能力是真实的，以后还会更强。但它做出来的是一套软件的界面和一部分功能，不是一套能长期运行的情报系统。差别不在写代码的能力上，在谁为第二天的数据负责。
既使把模型接进去当采集器，也还是得有人在后台盯着采集和入库。能连跑一年还在正常收全量数据的，后台的采集管理和监控一般都很完善。这些活，模型替不了。
