他把 AI 塞进 IRC，当起自己作品集的“数字门卫”
一个不想再“复读简历”的 AI
现在的个人作品集网站，几乎都快被同一种 AI 聊天框占领了：页面右下角一个气泡，点开以后，它能把作者的经历重新说一遍，换几种措辞，再加一点热情洋溢的语气词。听起来很聪明，实际上像一个把 LinkedIn 资料背熟了的接待员。你问它“这个人怎么做测试”，它往往回你一句“他非常重视软件质量与测试覆盖率”。这类回答的问题，不在于错，而在于空。
美国开发者 George Larson 显然也受够了这种“简历复读机”。于是他干了一件非常 2026、又非常 1996 的事：在一台月租 7 美元的 VPS 上，部署了一个 AI agent，把它接进自己的 IRC 服务器，再让它去读自己的 GitHub 代码仓库。访客来到他的网站，不是对着一份被模型润色过的履历提问，而是直接向一个“数字门卫”发问。这个门卫如果被问到“你的测试怎么做”，不会只说价值观，而是会去 clone 仓库、查看测试文件、读 CI 配置，然后给出更接近事实的回答。
这听起来有点像科幻小说里的门房大叔：你问他住户是做什么的，他不背宣传册，而是带你去看工作台、工具箱和电费账单。对今天这个 AI 叙事泛滥、但可信度却越来越稀薄的技术世界来说，这种做法格外有意思。
这不是聊天机器人，而是一道精心设计的边界
Larson 给这个系统起了两个名字：面向公众的叫 nullclaw，面向私密信息的叫 ironclaw。前者是门卫，后者是后勤。两者被放在不同机器上，中间有明确的安全隔离。nullclaw 负责在公开频道里接待访客、回答项目问题、访问公开 GitHub 仓库；ironclaw 则待在更私密的环境里，掌握邮件、日历以及更深层的个人上下文，处理预约通话之类的请求。
这样的设计很朴素，但恰恰因为朴素，才显得专业。过去一年，太多所谓“AI 代理”演示喜欢把所有能力堆在一个 agent 上：能读邮件、能发消息、能调日历、还能连数据库。看上去像全能管家，实际却是把风险集中在一颗大炸弹里。Larson 的方案反其道而行之，强调边界、权限和可损失性：公开那台机器就算出事，损失也被控制在一个 IRC 机器人和每天 2 美元的推理预算里，而不会一路连到个人隐私数据。
这个思路其实比“我的 AI 能做一切”更接近真实世界的软件工程。工程不是炫技，而是控制爆炸半径。尤其在 AI agent 这个阶段，大家都在讨论能力上限，真正稀缺的却是对失败场景的想象力。Larson 的方案打动人的地方，不是模型多先进，而是他先问了一个成熟工程师才会问的问题：如果它被滥用、被攻击、被绕过，会发生什么？
为什么偏偏是 IRC？老协议在 AI 时代突然返场
这套系统最有趣的部分，可能不是模型，也不是 GitHub，而是通信层竟然选了 IRC。是的，就是那个诞生于 1988 年、很多年轻开发者只在技术史里听过名字的老协议。今天大多数人想到聊天接口，会先想到 Discord、Telegram、Slack，或者干脆自己写一套 WebSocket 前端。Larson 没这么做。他把网页聊天直接嵌进一个 Web IRC 客户端，再通过自建的 Ergo IRC 服务器和 agent 对话。
表面看，这像是一种极客趣味：他的网站本来就是终端风格，IRC 的气质很搭。可更深一层，它其实代表了一种越来越稀缺的互联网观念——我拥有整个栈，我不依赖任何平台的脸色。没有第三方 API 临时改规则，没有机器人接口说收紧就收紧，也没有平台哪天突然决定“这个功能即将弃用”。对于想做长期实验的人来说，这种自治能力的价值，正在重新上升。
过去十几年，互联网被平台化得太彻底了，以至于开发者很容易忘记，很多基础协议本来就足够好用。IRC 简单、稳定、无厂商锁定，几乎没有“SDK 版本地狱”。而 AI agent 恰恰需要一种低摩擦、可观察、可替换的通信方式。一个机器人能通过网页 IRC 客户端和访客对话，也能通过终端里的 irssi 和主人对话，这种统一性非常迷人。某种程度上，这也是对当下“凡事都要包成平台”的轻微反讽：最适合 AI 门卫的交通工具，竟然是三十多年前的老路面电车。
真正重要的，不是模型多大，而是它什么时候该闭嘴、什么时候该查代码
Larson 在模型选择上的态度也很值得聊。他没有追求“全程最强模型”，而是做了分层：日常寒暄和简单分流，交给更便宜、更快的模型；真正需要读代码、跨文件综合判断时，再调用更强的模型。这个设计听起来很节俭，实则是一种相当清醒的产品判断。
今天很多 AI 产品都有一个毛病：拿大模型做所有事，像请米其林主厨煮每一碗泡面。结果就是成本高、响应慢，而且用户并没有得到更好的体验。对一个作品集网站来说，访客要的不是“史上最聪明的哲学回答”，而是快、准、别乱说。你问“他用什么语言”，系统最好一秒内回答；你问“测试结构怎么设计”，那它才有必要多花点时间去翻仓库。把不同层级的任务匹配给不同层级的模型，这比盲目堆算力更像真正的产品设计。
更关键的是，这个系统开始把“可验证性”拉回到 AI 对话里。过去两年，AI 聊天机器人最大的结构性问题就是：它说得越像真的，用户越难分辨它到底有没有依据。Larson 的门卫至少试图给出另一条路——不是让模型更会说，而是让模型在必要时去读证据。这当然还远谈不上完美，clone 仓库、读测试文件也不能自动等于“理解项目”，但它已经比大量只会重新包装简历的 AI 页面前进了一大步。
从个人作品集到行业信号：AI agent 开始回到“工具”而不是“表演”
这件事为什么值得关注？因为它击中了当前 AI agent 领域一个很尴尬的现实：我们见过太多 demo，见过太多“帮你订票、发邮件、安排行程”的大话，但真正进入日常、又能在成本和安全上说得过去的应用，依然不多。Larson 的这个数字门卫并不宏大，它甚至有点小题大做——为了一个个人网站，搞了 IRC、Cloudflare、Tailscale、A2A 协议、双机隔离、审计日志和预算上限，工程味浓得像一锅熬过头的汤。但正因为如此，它比很多华丽的代理演示更真实。
它让人看到，agent 真正有生命力的地方，也许不是替你一键完成所有复杂事务，而是在一个足够窄、足够明确的场景里，承担“可信入口”的角色。它先把简单问题处理掉，必要时再升级给更高权限的系统，同时保留边界、日志和可追踪性。这种架构思路，很像企业客服、内部 IT 助手、开发者文档助手未来更现实的演进路线。不是一个全知全能的 AI 员工，而是一串职责清晰的数字岗位。
当然，这里也有值得警惕的地方。所谓“读取代码给出答案”，很容易制造一种比普通聊天机器人更强的权威幻觉。用户可能因为它引用了仓库、提到了 CI，就默认它的判断一定可靠。但代码解释本身也是高风险任务：仓库未必完整，测试文件未必代表质量，模型也可能断章取义。换句话说，这类系统提升了可信度，却也提升了“看起来很可信”的危险程度。以后我们恐怕得学会一种新的媒介素养：不仅问 AI 说了什么，还要问它到底查了什么、漏了什么。
从更大的行业背景看，这也是“自托管 AI”潮流的一个缩影。随着云端大模型接口逐渐标准化，越来越多开发者开始把竞争点放在外围基础设施上：怎么接入真实数据、怎么做最小权限、怎么留下审计线索、怎么控制成本。模型本身越来越像电力，真正决定体验差异的，是配电系统。Larson 这个小项目像一张微缩地图，提前画出了未来很多 AI 产品要补的工程课。
一个有点复古、却很像未来的互联网角落
我喜欢这个故事，还有一个更私人一点的原因：它带着一种久违的互联网手工感。不是大厂发布会上的“重新定义交互”，也不是融资稿里的“下一代智能代理平台”，而是一个开发者认真地给自己的网站装了一位门卫，让它别再胡乱吹牛，而是学会去翻代码、查记录、再回答问题。这种克制，比夸张更难得。
你甚至能从里面闻到一点老派个人主页时代的气味。那时候，网站是人的延伸，而不是社交平台模板的复制品。现在，AI 又给了个人网站一次重新长出个性的机会。问题是，绝大多数人选择了最省事的路线：接一个聊天框，喂给它几页个人资料，然后等它帮自己“显得更聪明”。Larson 的做法提醒我们，AI 真正有意思的地方，不是装饰门面，而是把网站变成一个能检索、能解释、能建立信任的活系统。
如果说这个“数字门卫”有什么象征意义，我会把它理解为一种回潮：旧互联网的自治精神，遇上新一代 AI 的能力层。一个 1988 年的协议，托着 2026 年的 agent 在频道里接客；一台廉价 VPS，撑起比很多 SaaS 聊天插件更有说服力的体验。这画面多少有点黑色幽默，也有点浪漫。科技史经常不是靠最时髦的东西向前推进，而是靠那些被重新放回正确位置的旧东西。