随想与复利

事情的起点特别朴素:我指着一台云服务器问,”这个博客我怎么更新?” 那台机器是别人帮搭的。上面跑着一个 Hexo 博客,但源码在哪、怎么发布、谁来维护,我一概不知。一个多月后再看,它已经变成了一套十三个域名入口的自托管体系——博客、内网穿透、监控面板、几个自己写的工具,全部 HTTPS,防火墙只开四个端口。 这篇文章记录这次整理的路线和心得。 第一步:不动手,先盘点接手任何”不明系统”,第一件事不是改,是看。 我让 Agent 把服务器从里到外扫了一遍:nginx 指向哪、源码在哪、监听了哪些端口、有哪些账号、什么服务在跑。这一步把家底盘清楚,后面的每个决定才有依据——盘点先于优化,这是这次最重要的一条经验。 盘点立刻就有收获:防火墙开着一段两千个端口的大范围规则,实际只用到十几个;两个从未登录过的账号躺在那里;还有一个装了一半就被放弃的旧博客系统,连着 98MB 的残留文件。 博客这一层:从能用到像样博客的改造是循序渐进的: 先把发布流程搞清楚——Hexo 的套路其实就三步:写 Markdown、生成静态页、nginx 直接读生成目录。没有 git,没有 CI,简单到不容易...

2026 年 9 月 9 日，我在用 AI 助手做电力市场业务分析。它汇报了一份”交易通知”的内容——时间、要求、口径，一应俱全。我问来源，它给了链接，还”印证”了一番。 问题是：这份通知不存在，那个链接也不存在。 这不是一眼假的胡说八道。恰恰相反，它格式规范、细节自洽、语气权威，还自带”佐证”。要不是按惯例把链接打开看了一眼，一份虚构的市场规则就可能进入真实业务流程——报价、签约、结算，每一步都是真金白银。 复盘：为什么提示词不管用事故后我的第一反应是加提示词：”禁止编造，必须给来源。”没用。原因后来想明白了： 幻觉不是”态度问题”，是模型的统计本性。你要求它”不编”，它编的时候并不觉得自己在编。 同一个上下文里，模型无法自查自证——生成幻觉的机制和检查幻觉的机制是同一个。 更麻烦的是”带来源的幻觉”：它连印证来源都能一起编。人工核对如果只看”有没有链接”，照样被骗。 结论：防杜撰不能靠模型自觉，要靠流程——而且关键环节必须是机械校验，根本不经过任何模型。 体系：规则层、工具层、强制层我最终在自己日常使用的 AI 编码助手（ZCode）里落地了三层，所有项目通用： 规则...

用 agent 干活久了，总会沉淀出一些反复出现的工作模式：每次都要重复交代的格式要求、每次都要现查一遍的流程步骤、每次都容易踩的坑。Skill 的价值，就在于把这些“程序性知识”从对话里抽出来，变成 agent 可以按需加载的能力——需要时触发，不需要时不占地方。 用了一段时间之后，我对 skill 这个机制本身积累了一些观察。这篇文章不谈任何具体 skill 的内容，只谈使用过程中暴露出的问题，以及我认为值得改进的方向。 Trigger 触发是第一道坎，但目前它更像玄学现象 同样一个意图，换个说法就触发不了；反过来，无关任务又偶尔被误触发。中英文混合的任务里尤其明显。 本质 触发靠的是 description 的语义匹配。这个 description 是 skill 唯一的“索引”，它同时承担两个职责——检索（用户想要的东西能不能被召回）和决策（agent 判断该不该用）。两个职责挤在一句话里，写起来自然别扭。 改进方向 把 description 当产品文案来写：明确“用于什么、不用于什么”，覆盖常见的同义说法，而不是写一句笼统的定位。 给触发建一个评测集：一组应该触...