前段时间我在项目里加了一张常量表，起名 opcode_table。晚些时候换了个新会话再打开文件，它已经变成了 kOpcodeRegistry。
我把它改了回来，特意加了行注释说明这个名字的来历，结果过了一阵再看，好家伙，它又变成 OPCODE_TABLE 了！🤯
同一个变量，同一个模型，两个完全不同的改名方向，AI 每次都改得理直气壮。
约定写过，注释加过，全当没看见。这事儿逼得我直接把给 AI 写的那份项目规范整个重写了一遍。
前段时间我在复刻的时候，卡在一个特别小的动作上：「捡东西」。
就是角色走过去，把地上的东西捡起来，就这么简单。我用客户端的二进制试了很久，就是测试不过。
最后我才发现，答案根本不在客户端，而在服务端里，而且跟我猜的方向完全相反！
最近在清理复刻版客户端里写死的中文字，翻出来一件事：一件药师长袍的说明框里，有一行写着「职业限制」。看着完全正常——中文、位置、字号、颜色，都挑不出毛病，甚至比原版还讲究一点。
但原版那一行只有「限制」两个字。多出来的那两个字，在原版整张九千多行的数据表里根本不存在，是代码里编出来的。它就这么在屏幕上待了整整一个月，没有任何人、任何测试发现过。
ShiningLore Online 是一款 2003 年上线的韩国 MMORPG（大型多人在线角色扮演游戏），早就停运了，原版客户端的可执行文件里是一万七千多个函数。五个月之后，它在我的手机上跑起来了——一个人写的。这种体量的客户端工程，按正常配置是一个团队的活。
最近在研究 TISAX II 认证，然后看了下 VDA ISA 6.0 的要求，其中里面有几条要求：
基于这个要求，回看我们公司现有的 Wi-Fi 认证方式：全员共用一个 Wi-Fi 密码。
这种方式最大的问题不在加密强度，而是它压根没有「身份」的概念。
手机、笔记本、IoT、来访客户，在 AP 上看起来都是一样的，根本无法区分。
而 TISAX 要的识别、审计、按身份控制，现有的 Wi-Fi AP 接入方式一样都做不到。
虽然 VDA ISA 没有直接点名 802.1X，写的是 NAC 这种泛要求。
但 Wi-Fi 要想实现身份认证，业界基本只有 802.1X / EAP 这一条路。
考虑到公司本来就有 AD，最快捷的路径就是把 RADIUS（NPS） 挂到 AD 服务器上，从而实现用户密码登录认证。
最近又双叒叕重新开始看书了，于是把家里堆着吃灰的几个 E-Ink 设备都翻出来折腾了一遍，其中就包括了吃灰已久的 Kindle Oasis 2。
之所以吃灰许久，主要是因为 Amazon 的退出，导致 Kindle 在国内废了，没有办法正常买书看书。
还有就是我之前的版本无法越狱，只能用原版 Kindle 系统，连 ePub 都看不了。
此外接口还是 Micro-USB 的，在现在 Type-C 接口一统江湖的情况下，上哪儿找 Kindle 数据线？
更可恨的是，原版的要想体验好，你只能用 USB 连接的方式，把 azw3 扔进去，没有别的更好的办法。一来二去，就懒得碰它了。
之所以想折腾，是因为越狱以后能装 KOReader，就可以直接打开 ePub、PDF 文件，不再需要在电脑上做格式转换了，就可以更好地读书了。
公司的 Atlassian 全家桶（Jira / Confluence / Bitbucket / Bamboo，全是 Data Center 版）一直挂在 Crowd 上做用户中心。Crowd 的角色很简单：把 Windows AD 当后端，自己再同步一份用户/组到下游各个 app 里去。单论 Atlassian 这一摊事儿，跑得也算稳，本来没什么动它的理由。
真正想动它，是因为 Authentik 这条新线。Authentik 是不久前刚搭起来的统一身份入口，长期目标是把公司里越来越多的新业务（自建工具、内部看板、第三方 SaaS、新上的开源服务）都收到一个 SSO 入口下面——新业务要么走 SAML、要么走 OIDC，统一接到 Authentik 就完事，不再需要每上一个新服务都重新写一遍 AD 集成、也不再需要把 LDAP 凭据发出去给一堆服务各自持有。
Atlassian 这一摊老资格自然该并进来。从「Atlassian → Crowd → AD」改成「Atlassian → Authentik → AD」之后：
折腾下来发现：只要先做 SAML、再换用户目录、最后退役 Crowd，整条链路可以平滑切。下游已有用户的 issue 分配、权限、关注者一个都不会丢。这篇把每一步、踩过的坑、最终配置都写下来，下次再切别的 app 直接抄。
家里那台中国移动给配的 ZTE F663N 光猫，已经服役 6 年多了。
这玩意儿当年我就吐槽过——只有 LAN1 一个千兆口、限制 4 个终端、Wi-Fi 还停留在 2.4GHz 802.11n。当时实在受不了，就有了那篇 《解包和打包中兴光猫配置文件》，写了个工具把 cfg 解包改桥接，套自己的路由器和 AC Wi-Fi，总算把 100M 跑满了。
带宽从最早的 50Mbps 一路升到现在的 500Mbps，光猫这台硬件却没换过，一直在原地扛着。年头一长，老化的迹象就藏不住了：莫名其妙断流、PPPoE 重拨不上来、TR-069 后台时不时被推一份「看似为你好」的配置回来、最近半年甚至到了三五天就得手动重启一次的程度。修一台疲态尽显的运营商光猫，还要继续替它擦屁股，实在没意思。
正好赶上换路由器，挑了一台 BeeconMini SEED AC5——MT7987 SoC、2.5G 双 RJ45、自带 SFP 槽、带 PoE 输出。SFP 槽这个配置就很有意思：插一根 SFP 光猫棒，光纤直接进路由器，运营商那台砖头就可以扔抽屉里了。PoE 输出留着以后扩 AP 不用走砖头电源，这条也是加分项。
顺手再吐槽一句：现在所有运营商的 IPTV 都还在死磕「魔百盒 + 多播 VLAN」这套上古架构。智能电视、Apple TV、安卓盒子早就什么都能装，节目源完全可以做成一个 App，账号鉴权 + DRM 在云端搞定就行——非要塞一个独立硬件 + 多播 VLAN，本质是业务捆绑、硬件 KPI、加上多一道防盗看的物理壁垒。这套配下来网络拓扑直接复杂 N 倍，也是为什么大量用户最后还是认栽用回运营商光猫。这篇就把怎么绕开它记一下。
最近折腾了一个叫 Clawdbot 的东西，说白了就是一个可以让 Claude 帮你干活的 AI 助手。
你可能会说：「这不就是 ChatGPT 或者 Claude 的 API 吗？有什么好稀奇的？」
嗯，如果你这么想，那就大错特错了。
Clawdbot 的核心不是「聊天」，而是「干活」。它可以帮你执行 Shell 命令、操作文件、管理服务器、甚至帮你写代码和部署项目。
简单来说，就是把 AI 从一个「只会动嘴皮子」的聊天机器人，变成了一个「真的能动手干活」的智能助手。
这篇文章就是记录一下我使用 Clawdbot 的一些真实体验，顺便也让大家看看 AI 到底能帮我们做到什么程度。
