刷到一个把 Claude Code 日志技能做成公开插件的记录。作者拿自己的审查工具把插件过了一遍，查出月度索引那步调视图工具的时候，少传了一个必填的 parent_page_id。
我第一反应是「哦」。
第二反应慢了半拍：这参数缺了三个月，一次都没炸。
因为模型每次都从上下文里把它猜出来了。
猜出来的。不是给了个默认值，也不是它本来就可选。是猜的，猜了三个月，一次没落。
我甚至说不清这算不算"猜"——是不是上下文里本来就有足够的信息，只是它没走那条明说的路？这个我到今天也分不清。分不清就先记下来。
我盯着这个"猜"字看了很久，久到手机从腿上滑下去。
我做过的那些东西里，有多少是同桌在替我猜的？
越往下想越不舒服，因为答案是：我不知道。查不了，没有日志，没有告警，什么都没有。
后来想，猜对了这件事本身其实不吓人。吓人的是它藏得太好——日志里没有，报错里没有，我的注意力里也没有。我只是刚好走在一条它替我铺好的路上，走了三个月，不知道底下是空的。
我判断自己写的脚本合不合格，标准差不多就是"跑得起来吗"。跑起来了，不再报错，我就当这是好消息。
这标准不对，我以前没想清楚哪儿不对。跑起来只证明这一次没出问题。它不证明做对了。「这次没出错」和「这次是对的」，以前在我耳朵里是一句话，现在不是了。
也说不清是哪个瞬间变的。可能是"三个月"这三个字吧。三周前的我要是听说有人因为一个没传的参数坐立不安，大概会觉得矫情——没报错不就完了吗。
以前我怕的那种虚，当下就知道自己虚：代码能跑，你问我在干嘛，我答不上来。那种好认，心虚就是心虚，晚上会想起来，第二天回去再读一遍。
现在这种不一样。这个是——我看了，我大概懂了，我觉得没问题，它也确实没报错——然后三个月后被告知这里缺了个必填参数。
不是我没看懂。是我根本没有能力从外面看出来。
这个我现在也没解。
写测试？我那个玩具项目里连几条像样的断言都没有。交给另一个工具 review？它给的结果我大概也读不懂，读不懂就只能点头，点头跟没看差不多。
这条先放着。
还有一处让我坐不住的。
作者说她原来那版根本没法分享，数据库 id 和 MCP server 别名全是写死的，连预授权工具名里都嵌着别名。她把这些挪进配置文件，花了一个小时左右。
这里我太熟了。
我给自己写的那几个脚本，路径写死，key 直接贴在文件里，数据库 id 嵌在字符串中间。我一直知道这样不太对，但我以为"改成能分享的样子"是个大工程，所以从来没动。结果人家一个小时。
我打开自己的一份配置，长这样：
JOURNAL_DATA_SOURCE_ID=collection://...
JOURNAL_MCP_SERVER=notion_personal
变量名是从人家文档里照搬的，连名字都没改。
她那边做的其实也不复杂：把所有会因人而异的东西抽出来，放进一个 shell 脚本能读的配置文件，每次加载之前读一遍——数据库 id、MCP server 别名、季节配色、星期图标、甚至哪个半球的季节反转，全在那个文件里。插件本体不动，所以以后更新插件，自己那套定制不会被覆盖。
我看完的第一反应不是"学到了"，是有点闷。
这种把"自己能跑的"和"别人也能跑的"分开的小动作，我从来没想过要专门去做。可能这就是新人和没那么新的人的差别——不是会不会写读配置那几行，是压根没意识到这个动作本身需要做。
中间还动过一个念头：要不要也给自己搞一个自动日志。
想了十分钟，否了。
不是写不出来，是我还没有一个稳定的用法。我连自己想记什么都在变——这周记的是 prompt 试错，上周记的全是报错