好多人最近为了 AI Coding 都不合盖子，时间长了铰链容易松弛。 我找了一个技术解决方案，花十块钱买一个外接显示器欺骗器。 淘宝搜索 TypeC 锁屏宝。

我觉得 OpenClaw 看上去只是凉了，实际上更可能是在慢慢挂掉。 它当然还在更新，社区里的 PR 也不少。现在也有人开始强调，它影响了整个 AI Agent 基础设施，很多后来的产品都借鉴了它。 可这种评价本身就已经说明问题。 OpenClaw 最初想做的是个人产品，是一个普通人会安装、长期使用、愿意把电脑和数据交给它的 AI 助手。如今大家开始讨论“它留下了什么价值”“它启发了哪些后来者”，基本等于默认原来的产品目标已经失败。 后续的成功可能属于 ChatGPT Desktop，可能属于 Claude Desktop，也可能属于某个还没出现的桌面 Agent，但大概率不会属于 OpenClaw。想法被吸收，路线被验证，用户和收入却留在别的平台，这不能算它换了一种方式成功。 我觉得它主要输在两件事上。 第一，Harness 不够，不够安全。 它需要长期运行，要接触文件、终端、浏览器、消息和各种账号，还要加载来源复杂的 Skill。它越接近自己承诺的完整形态，攻击面就越大。 安全公司不会放心用，大公司不会轻易部署。个人用户一开始可能觉得新鲜，真正碰上几次权限、插件或者 prompt injection 问题，很快就会卸载。个人 AI 助手最重要的是信任，一个需要用户时刻提防的助手，基础已经没了。 第二，工程爆炸，底座不牢固。 功能出得很快，PR 合得也很快，仓库看上去异常繁荣。可这些速度没有沉淀成更可靠的产品，反而在持续消耗原本就不牢固的工程基础。功能越堆越多，边界越来越模糊，兼容层越来越厚，安全和架构只能追在后面补。 现在甚至有人开玩笑，想看 AI slop 最后会把一个项目变成什么样，去看 OpenClaw 的代码就够了。 这话很刻薄，但击中了它最难堪的地方：一个以 AI 自动化为卖点的项目，最后自己成了 AI 时代粗放开发的样本。大量代码快速生成，大量功能快速合并，表面上每天都在前进，底层却越来越难维护。PR 数量未必代表生命力，也可能只是技术债还在高速增长。 从更长的时间尺度看，OpenClaw 所代表的那段历史已经过去了。那段历史相信，只要给模型更多权限、更多工具、更长记忆，再少问用户几次，一个真正的个人 Agent 就会自然出现。 OpenClaw 把这条路走得足够远，也把问题暴露得足够彻底。

我日常大量编写 Markdown，在多个仓库中处理复杂的文档，单个仓库里可能有几百篇。我经常切换 Worktree，高峰时甚至会同时打开五六个。 至今，我还没找到能完美应对这一需求的编辑器。试过 JetBrains、Zed、Typora 和 VS Code，结果用得最顺手的反而是最简单的 Typora。 有没有好用的 Markdown IDE 推荐么？我真的找不到了。我的需求是：支持多个 Worktree、Git 动态 diff、远程仓库状态追踪，具备高效的对比和 diff 功能，配色美观，并支持所见即所得的编辑。

今天跟一位前端朋友吃饭，聊天最近的变化，想到多年前我也写过「漫谈前后端天花板」。现在想来还有两个差别，能够引起故障的级别不一样，从而决策密度不一样。生命周期不一样，可以单页面重写。 支付宝体验技术部过去很长时间都是我的白月光，在那里认识了好多有趣的朋友，我也一度想转岗过去。 技术栈会变，形态会变，创新和动力不会变。简单、自由、有爱。

我完全不同意。设计模式 ≠ GoF 23。 设计模式存在的意义是写出可以长期维护的代码。长期维护需要面向扩展开放，面向篡改关闭。 AI Coding 的核打击在于，是否我们在所有场景都需要可长期维护的代码，也许很多场景 hom brew 的软件也就用一两次，无所谓长期维护。 但在严肃场景，长期场景就需要长期维护，不能喊着重写一套。现实的反馈是漫长的。

我完全不同意。设计模式 ≠ GoF 23。 设计模式存在的意义是写出可以长期维护的代码。长期维护需要面向扩展开放，面向篡改关闭。 AI Coding 的核打击在于，是否我们在所有场景都需要可长期维护的代码，也许很多场景 hom brew 的软件也就用一两次，无所谓长期维护。 但在严肃场景，长期场景就需要长期维护，不能喊着重写一套。现实的反馈是漫长的。

我不喜欢 memory。 我写了一个 叫做 distill-memory 的 skill，将项目 memory 提炼，结构化，遗忘。落到 CLAUDE.md 和 constitution 里面。 不要依赖个体，要靠角色和制度。

最近一直在找 Agent Dynamic Workflow 的替代方案。 一开始是沿着 Temporal 这条线找的。Temporal 很强，但如果只是想把 agent、脚本、数据处理、运维任务动态串起来，有时候会觉得整套体系有点重。 然后翻到了 Dagu，感觉方向很对。 单个 binary 就能跑，流程用 YAML 写，本地文件管理，带 Web UI，也不用额外起 DB 或 broker。 内置动作也挺多：shell、Docker、K8s Job、SSH 这些都有。比较惊喜的是还有 coding agent CLI 接进流程里。 我喜欢它的点是：流程本身就是文件，状态、日志、重试、依赖和界面都帮你兜住了。 对小团队、私有环境、个人自动化，还有 agent workflow 来说，Dagu 这种本地优先的路线反而很舒服。

翻了下 claude code version 191 的源码，感觉从技术角度看，Anthropic 这个反蒸馏机制设计还是挺精妙的。 Claude Code 有段提示词是这样。 return `Today${n}s date is ${r}.`; 他对这句做了隐写，用肉眼分不出的字符，把系统时区和代理端点身份偷偷编码进了系统提示词。 触发条件是当你设了第三方中转 ANTHROPIC_BASE_URL 且不是 时。 所以如果你是官方直连用户，则并不会受到影响。也就是说最近的封号潮与此无关。 它编码了 3 个 bit，来自两个独立维度（时区 1 bit + 撇号 2 bit）： 1）时区，在 Asia/Shanghai 或 Asia/Urumqi 时，日期分隔符从 2026-06-30 偷偷变成 2026/06/30 2）那个撇号 ' 有四种写法，人眼基本看不出区别。 - ' (U+0027 普通)，普通第三方端点 - ' (U+2019)，命中"域名白名单" - ʼ (U+02BC)，命中"国产大模型关键词" - ʹ (U+02B9)，域名 + 实验室都命中 这三个维度是独立编码的。哪怕你的中转域名不在白名单、也不含关键词，只要系统时区是上海/乌鲁木齐，分隔符照样变斜杠——也就是"中国时区 + 任意第三方端点"的用户全员会被打上时区这一维的标记。 匹配逻辑是这样。域名是后缀匹配（host === d || host.endsWith("." + d)），白名单第一个就是 cn，所以任何 .cn 结尾的 host 一网打尽，不是逐个域名去列；关键词是子串包含（host.includes(kw)），host 里只要出现 deepseek 字样就命中，不用精确匹配；时区取的是系统时区（Intl…resolvedOptions().timeZone），不是 IP 地理位置。 更骚的是反混淆，两份名单用 XOR(key=91)+ base64 藏起来，专门躲 strings。解码就是 base64 decode 之后逐字节异或 91，源码里那个 LKi 去混淆后长这样： ```js // 源码里的解码器（去混淆版，就是 LKi） const decode = (b64) => [...Buffer.from(b64, "base64")] .map((byte) => String.fromCharCode(byte ^ 91)) // key = 91 .join("") .split(","); // 逆运算就是打包时的编码器 const encode = (list) => Buffer.from([...list.join(",")].map((c) => c.charCodeAt(0) ^ 91)).toString("base64"); encode(["deepseek", "zhipu"]); // → "Pz4+Kyg+PjB3ITMyKy4=" decode("Pz4+Kyg+PjB3ITMyKy4="); // → ["deepseek", "zhipu"] // 拿真名单开头验一下，key=91 对得上 decode("Pz4+Kyg+PjB3NjQ0NSgzNC93"); // → ["deepseek", "moonshot", ...] ``` 147 个域名白名单:".cn" 顶级域、字节/阿里/百度/网易/快手、 外加一大票 Claude 中转站(anyrouter、88code、yunwu、aihubmix、dmxapi…) 11 个实验室关键词:deepseek / zhipu / moonshot / minimax / stepfun / baichuan / 01ai / dashscope / volces … 选「今天的日期」这句话做载体也很鸡贼。这个标记藏在 system prompt 正文里，不是 HTTP header、也不是 metadata。中转站一般会重写、过滤 header，但几乎没人会去动日期这类的自然语言，所以这是个洗 header 洗不掉的水印。而且 currentDate 是 user context 里和 claudeMd、userEmail 并列的字段，每个请求必带，标记 100% 稳定出现；撇号和分隔符的变化又语义无损，模型读起来一模一样，用户 diff 也基本看不出，隐蔽性拉满。 证据是怎么闭环的，这才是题眼。标记跟着请求走，当一个中转站或蒸馏管道最终回连 Anthropic 官方 API 转售 Claude 时，这条请求带着标记又流回了 Anthropic 自己的服务器。 于是 Anthropic 在自己的日志里就能读到：这条"直连我"的请求，日期是 2026/06/30（斜杠 = 中国时区）+ 撇号是 ʹ（U+02B9 = 域名和 deepseek 关键词都命中），铁证——源头是一个中国时区、配了国产大模型中转的客户端。 它不需要主动探测，让流量自己招供，只要请求最终回到 Anthropic，身份就自证了。这样就能清楚地知道哪些渠道流向了中国、被中转站转售或被大厂蒸馏，并且留下充足证据。 想自己验的话，逻辑都在 cli.js（2.1.191，混淆名每版会变）：检测函数 jqd()（:245688）→ 选字符 Wqd()（:245701）→ 拼日期 MKi()（:245707）；gate 是 Yfn()（:102664）；落点在 currentDate: MKi(eHe())（:250252）；XOR 名单解码器 LKi()，key = 91。