先说个我差点犯的错
前阵子我想做一个很小的工具：几台机器的网络体检，续费前、换IP后跑一遍，看看IP干不干净、DNS漏不漏、流媒体解不解锁。需求特别清晰。
然后我第一个念头就是——给它接个大模型，让它自动出结论，顺便还能生成一段人话总结，多酷。
我在脑子里把这套方案走了一遍，越想越不对劲。接模型意味着我得管API key、管额度、管海外账号，还得把别人的检测数据往第三方服务送一道。
一个本来一两百行就能搞定的小工具，瞬间背上了一堆运营包袱。说真的，那一刻我停下来了。
真正点醒我的是看到有人开源的一个单文件Python工具NetPulse。它干的就是这事：SSH到你的几台VPS上跑检测，IP纯净度、原生IP、DNS泄露、流媒体解锁、几家AI的API可达，全查一遍。
但它自己一个模型都不接。加个`--json`参数输出结构化结果，你复制粘贴丢给Claude或者Codex，让它们出中文总结就行。
工具只负责把事实查清楚，下结论的活儿留给你手里现成的AI。
看完我把自己那套"内置模型"的草图删了。这篇就想掰扯清楚：为什么检测类小工具，把模型留在外面，反而是更聪明的做法。
取数据和下结论，为什么必须是两件事
先想想这两件事的性质有多不一样。
取数据是确定性的。 IP的ASN注册地是哪、DNS有没有漏、延迟中位数多少，这些要么查得到、要么查不到，没有模糊地带。
NetPulse处理得挺克制：延迟三次采样取中位数，测速响应不足1MB直接判error，不把错误页算成速率；AI可达走API端点探针，401算可达，首页403很多时候只是反爬，它就不拿来当证据。查不到的，直接标unknown，绝不编一个"风控分"这种听着唬人、其实没依据的自创指标。
下结论是带判断的。"这台机器适不适合搬去做某件事""这个IP的解锁情况算好还是差"，这才是需要语义理解、需要权衡的部分。
一旦你把模型塞进采集工具里，这两件性质完全不同的事就被焊死在一起了。更糟的是，模型有个毛病：它不太会说"我不知道"。
你让一个确定性的检测流程去迁就一个爱脑补的模型，查不到的地方它可能给你圆一个看着合理的答案，这对体检类工具是致命的——用户要的恰恰是"哪里查不到"这个事实，而不是一段流畅的猜测。
所以把它们拆开，不只是工程上干净，是责任边界上干净。工具对事实负责，AI对解读负责，各管各的。
决定工具能不能被AI接住的，是输出格式
这是我觉得最反直觉、也最值得独立开发者记住的一点。
我们做工具习惯比功能：我检测项比你多，我图表比你花哨。但在"工具+AI"这个组合里，决定你这工具好不好用的，往往不是功能多少，而是输出格式干不干净。
一份结构清晰、字段明确、该是unknown就老老实实unknown的JSON，大模型一口就能接住，总结得又快又准。反过来，哪怕你检测项再全，输出是一坨给人看的花花表格、带颜色带emoji带各种对齐，模型读起来就费劲，还容易误读。
换句话说，你不是在做一个"给人看的报告"，你是在做一个"给AI吃的原料"。原料干净,下游随便哪个模型都能加工;原料脏，再贵的模型也救不回来。
这个视角一旦建立，你做工具的优先级会整个变过来：先把数据结构设计对，再谈别的。
不接模型，反而在三件事上占了便宜
我原来以为"不内置AI"是个减分项，是功能上的妥协。真算下来，它在三个地方反而更占便宜。
第一是成本。你不接模型，就没有API账单这回事。
这不是小钱。最近就有人反馈某家的订阅在一次重置后，体感额度明显掉了，一天就干掉半周的量（具体缩水比例属个人体感，待核实）。
你要是把模型做进工具、按调用量给用户兜底，这种波动随时会把你的成本结构打乱。而把下结论这步推给用户，等于让用户用他自己的额度，你一分钱不花。
第二是信任。检测类工具碰的都是敏感数据——IP、机器、网络状况。
NetPulse特意强调所有检测都在你本机或你自己的VPS上跑，IP数据不经过第三方网页服务。这句话的分量很重。
一旦你内置了模型，数据就得往外送一道，用户心里那道坎立马就起来了。不接模型，"数据不出门"就是你天然的卖点，不用解释。
第三是分发。市面上围着大模型转的东西，普遍绕不开海外账号、key配置、甚至代充这类灰色周边（我看到有人专门在做GPT会员代充，说明门槛确实卡了一批人）。
你的工具但凡依赖这些，用户的使用链条就断在第一步。而一个"下载即用、数据本地、输出一份JSON"的工具，谁拿到都能跑，传播起来阻力小得多。
这套怎么在VicroCode上落地
讲完思路，说点能直接上手的。如果你也想做这类"只采集、不下结论"的小工具，整个链路可以这么搭。
采集脚本本身，用Python写最顺手，几十上百行就够。你不用自己配环境、折腾依赖，直接把脚本丢到Python在线运行里跑，调通输出格式，确认unknown该出的地方都出来了，再往下走。
确定性的事实采集，这一步是全部重点。
接着是我特别想强调的一环：把历次检测结果存下来。体检类工具最有价值的瞬间，是"换IP前后对比""续费前再查一遍"。
你光跑一次意义不大，攒成时间线才有判断依据。拿个轻量数据库存就行，平时想翻看某台机器的历史记录，用SQLite编辑器直接打开表看字段，哪次检测掉了解锁、哪天延迟突然飙上去，一目了然，不用另写查询界面。
最后是分发。工具调通了，想发给同行一起跑，不必让他们装环境、配一堆东西。
做个简单的前端页面，用Web应用托管发个链接出去，别人点开就能用。 NetPulse就是在官网首页放了一句现成的prompt，复制粘贴就能把JSON丢给AI出总结——这个细节很值得抄，你把"怎么把数据喂给AI"这步也替用户想好，门槛就又低了一截。
说清楚边界，别过度承诺
也得泼盆冷水。这套"不内置模型"的打法，不是说AI就不重要了，而是把AI的位置挪对了。
真正的语义判断——这台机器到底适不适合干某件事、这组检测结果意味着什么风险——这步还是得人或者AI来做,工具本身给不出来，也不该假装给得出。你要是指望一份JSON自动变成决策，那又绕回到"让工具脑补"的老路上了。
工具的本分就是：把事实查准，把格式理干净，把该说不知道的地方诚实标出来。到此为止。
另外，Python采集、SQLite存档、Web托管这套在VicroCode上能跑通，但具体到你那些检测项的数据源准不准、第三方接口稳不稳，这些得你自己实测，我这边没法替你打包票。
今天就能做的一件小事
如果你手上正好有个检测、监控、体检类的小想法，别急着想"怎么把AI做进去"。
先干一件事：把你这工具要输出的那份数据，手动写成一份干净的JSON，字段定清楚，查不到的地方老实写unknown。然后把这份JSON复制给你手里的Claude或者GPT，让它出一段总结。
看它接得顺不顺、读得对不对。接得顺，说明你的数据结构设计对了，后面照着实现就行；接得别扭，那恭喜你，在写一行采集代码之前，就提前发现了最该改的地方。