作为和华为云打过交道的人，简单记录一下狗屎一般的经历吧：

1. 华为云所有的核心开发都在国内，不管华为云的机房在哪，要上新模块必须通过国内的核心开发团队；

2. 当时一个和华为云的合资公司准备先上一个他们开发的模块，很基础的一个功能，搞了整整一年上不去；

3. 我们当时不知情，准备上我们的模块，就去合资公司那请教经验。去之前见过当地的华为老大，还说一定重视这次合作；

4. 去了之后发现就是屎上加屎。和华为安排对接，华为说他们会把对接的人都叫上。

5. 会开始了，来开会的华为哥们说这块不是他负责的，他也不知道谁负责，但他知道谁认识负责这块业务的人。于是请他去联系，结果这么套娃了两次，最后找到负责这块业务的人。但来不了会。

6. 这样的会开了好几回。最后总算摸透了华为的方案，实在太折腾了。我们最后放弃了，合资公司的模块最后也没上线。

7. 当然最后的结果是华为云整个被踢了。

#ai

24 年决定转行的时候，一直犹豫不决，感觉也许是自己 overthinking，担心不做出改变会很快失业。再三思考以后，决定走一条深入了解实际问题本身的职业路线。当时想应该是一个很容易赢得的赛跑。

两年后的现在看来，甚至比之前预想的来的还要快，从创新，到工程，没有一项不被渗透的。

我统计了我们的研发部门对 AI 的使用，他们对于 AI 的依赖可以说已经无可替代了。很多人说 AI 创新的问题，现实逻辑其实是，很多时候组合创新很有效，而这个是 AI 很擅长的，比如一个领域没有出现过 Monte Carlo 这种方法，我有个同事就通过跟 AI 聊天发现了 Monte Carlo 并且有了代码实现，而他有了更多的时间来思考更高层次的问题。这是问题本身抽象，然后数学表示，然后解决数学问题，最后翻译回结论，这样的传统工作流需要很多的经验，但是 AI 加持下极大的降低了这条路经的门槛。

工程更是渗透地可怕，我身边没有哪个 sensor swe 不在 vibe coding 。vibe coding 三要素：定义、工程栈与设计哲学、测试和验证，只要其中一项足够熟悉，就可以堆出不错的屎山。像是 GitHub 的各种深度整合，工作流变成了提出 issue，交给 copilot，等待，review 代码，迭代。有很大的概率无需自己写任何代码。

到最后，知道问题的价值，了解技术栈与好的设计，懂得如何验证结果，不管是从创新层面，还是从工程层面，都在卷起来了。

我自己选择的路线是：做距离问题最近的管理+全栈，说实话也不知道是不是一条正确的路。最近我采访了我们一线的各种职位的员工，目的就是减少来告诉我什么是重要问题的中间人。而我有时间这样做也是因为 AI 的加持。

除了这些，能够在急速迭代中保持身心健康，不在迭代中迷失方向，也是很核心的。我经常听到同事朋友说迭代太快人有些 burnout 了。


感想触发：

https://x.com/slow_developer/status/2020064994101014727

发现新加坡政府旗下的 govtech 搞了个内容发布系统，大大简化了发布流程：

https://www.developer.tech.gov.sg/products/categories/content-management/optical/how-it-works

本来制作邮件模版基本是手工活，现在基本全靠代码。

我用的是 resend，先在本地安装 bun install resend，然后在 resend 上生成一个 api key。

之前已经做了一些网页设计，所以直接拿这些素材丢给 claude 之类的 agent，让它设计合适的邮件模版。

本地预览了之后还算满意，就让 claude 写了一个上传的脚本，并且清理之前的版本。

整个流程都在代码里，不需要手工在后台拖拽，而且还还有版本控制。方便太多了！

有朋友问我现在还用不用 IDE，最近基本不怎么用了，返璞归真，回到了 terminal 里。主要是因为 claude code 的 vs 插件和claude code 本身还是有区别，直接在 terminal 里跑，感觉功能更全面。

1. 在一台Mac mini 上配置了 tmux + claude code + codex cli。这样所有的任务都跑在 tmux 里，开了两个 claude session 和一个 codex session。两个 claude 写不同的功能，codex 审核。

2. 用一台机器上还有 orbstack + lm studio，可以随时编译各种服务，调用本地模型测试 prompt 的效果。前端，后端都在 tmux 里跑着，supabase 跑在容器里。因为这台 Mac min 是顶配 M4 Pro，所以编译起来比 MacBook 快多了。

3. 同一台机器上跑着 tailscale + mosh，这样远程可以随时连上去，也不怎么需要折腾多个环境。另外的好处是，即使睡觉了，这台机器也随时跑着；就算回国了，也可以无障碍使用 claude 等服务。

4. 前阵子收了一台翻新的 MacBook Air M4，出门的时候就背这台，15寸的屏幕，13寸 MacBook pro 的重量，性能不是问题。

朋友问我要不要专门买 Mac mini 折腾成这样，我觉得其实手头有闲置的机器都可以折腾，没必要专门买。如果要大内存的机器，在闲鱼上可以看看有没有断头 Mac，性价比可能更高。

最近感觉 bug 越修越多，让 claude 和 codex 分别分析了一下，大概40%的时间在 debug 上。

我自己的感觉是：

1. AI slop 确实存在，很多代码越写越烦琐，写得越来越复杂，tech debt 越来越多；

2. 就我本身而言，一下子要学这么多新东西，根本学不过来。后端算是半路出家，前端完全零入门。选了 reflex 作为前端，原本以为是 python 生态下的容易上手，结果一半 python 语法，一半 js 语法，连 agent 都难以上手；

3. agentic engineering 大大压缩了开发时间，短时间可以写出更多的功能，也意味着暴露更多的 bug。也许 bug 总量的变化不大，但是因为在相对短的时间内爆发，所以让我感觉疲于奔命

把两台 magic trackpad 当作分体式键盘用

https://x.com/anomalog/status/2027025988182474796

https://github.com/disarmyouwitha/AppleMagicTouchstreamLP

前几天看到这条，试了试在 nanobot 下面跑，结果总是失败，能开 thread，但是一直回复到主对话里。

让 nanobot 自己修复也不行，问 claude 怎么办，看了看代码，说是 nanobot 暂时还不支持，但是调用的 python-telegram-bot 支持的，改几行代码就行。于是让它改了，瞬间就好了。

https://t.me/reorx_share/6479

终于设置了我的 claw，选用了 比较简单的的 nanobot，几千行代码，不像 openclaw 几十万行。

本地分装成 docker，部署到了 orbstack 上跑，限死了权限。本来想部署到另外一台闲置的老机器上跑，然后用 lm-studio 新发布的 lm-link 调用远程的模型，但配置起来更复杂，暂且就这样吧。

模型选了在 lm-studio 上跑最近刚发布的 qwen/qwen3.5-35b-a3b （Q4_K_M, 22G 显存），基本够用。

选了 telegram 作为入口；开启了 claude-code mcp 和 OpenAI's Codex CLI 官方的 codex mcp。

这样一来，可以用本地跑的 qwen 3.5 指挥 claude code 和 codex 干活。既然我本来就订阅了 claude 和 ChatGPT，这样的配置没有额外的开销。

不知道今晚会不会发布更强劲的 Mac mini，也许跑可以跑更强的本地模型。

telegram 实现了 streaming msg，这样一来，nanabot 也可以像其他 llm app 一样流式地显示消息

https://core.telegram.org/bots/api#sendmessagedraft

昨天看到一个逆向工程 Apple ANE 的项目，于是顺手丢给 Claude 改了改跑 Qwen 3.5 的 dense model。

一开始效果一般，只能跑通 0.8b 的模型，4b 和 9b 都跑不起来。因为 ANE 有119 kernels 的限制。

今天看到 ANE-LM 这个项目，有更多的创新，于是又让 Claude 改了改，这下三个模型都能在 M4 Pro 上跑起来了。

效果见截图，模型越大，ANE 的优势越明显。

- Opt 1: Saves ~64KB zeroing × 96 calls/forward → minor latency reduction
- Opt 2: Eliminates 320 powf/cosf/sinf calls per layer → measurable CPU savings
- Opt 3: Removes inner loops in conv1d hot path → tighter CPU code
- Opt 4: Saves 1 ane_eval + 1 IOSurface round-trip per layer → ~36ms total for ANE mode (biggest win)
- Opt 5: Eliminates MPS object allocation per matvec → GPU mode overhead reduction

最后再贴一个项目：

https://github.com/vipuldivyanshu92/ANEgpt

逆向工程 ANE


https://cra.sh/public_html/strlcpy3/iosmacos-exploit-chain-cve-2022-32845-32948-42805-32899-weightbufs


一个 Rust 的实现

https://github.com/computer-graphics-tools/ane

周末开始跑 Karpathy 的新工具，试了两个场景，一个是 SEO 优化，一个是爬虫数据的清洗。

步骤很简单：

1. 让 agent 读取 autoresearch 的文档和代码；
2. 让它根据你的需求改写条件和目标，审核之后，就开始跑。

很适合跑多种组合+明确目标+快速迭代的实验。

https://github.com/karpathy/autoresearch

Shopify 的老板 Tobias Lütke 基于上面的框架，发布了 pi-autoresearch，并且用这个工具把 Shopify 依赖的 liquid 的性能大幅提升：

53% faster parse+render, 61% fewer allocations

https://github.com/davebcn87/pi-autoresearch

https://github.com/Shopify/liquid/pull/2056

仔细想想，这个和机器学习里的 grid search 理念有点相似。

grid search 是在机器学习中找 hyperparameter 时常用的方法。即暴力穷举各种可能，然后开始跑 cross validation。当然一次只能针对一个算法跑，所以局限在机器学习的场景里。

最近碰到清洗数据的问题，最早用了基于规则的方法清洗，几乎所有 agent 给出的最先方案都是这些。当然拿来做 baseline 也不错。但很快就遇到瓶颈。于是我想着本地能跑的模型性能也还不错，不如再加上 llm，这些是现在业界常用的清洗方法。

两种方法各有长短：

1. 基于 regex 的规则写起来快，处理速度也快，但是维护起来困难，而且非常容易 overfit

2. nlp 写起来慢，处理起来也慢，但是维护起来相对容易，也更容易拓展到新数据上。

上面的截图里，baseline 是基于 regex 写的规则，抽取率是 31%。我希望达到的目标是提高抽取率，同时慢慢用 nlp 取代冗长的 regex 规则，经过 A - G 轮的迭代，抽取率从 31% 提高到了68%，直接翻番。

全程我就是定义了目标，让 claude 自己读取文档，然后根据数据写 regex，写 nlp 算法，然后自行组合做 auto-research，半天时间就把抽取率翻倍，这在以前想都不敢想！

把博士论文用到的 R 代码丢给 Claude，让它重构一遍。不到半小时，砍掉了 68% 的重复代码 🤣

最近帮朋友优化 Wordpress，不得不感叹，有了 agent 之后简单太多了：

1. 让 claude 写了一个 Wordpress MCP，直接可以读取/更新文章，不用再去 Wordpress 后台一篇篇贴；

2. 朋友把所有相关文档存在 google drive 里，问 claude 怎么可以批量获取数据，推荐了 mcp 和 rclone 两个方案，选了后者。一步步在 google cloud 上配置好权限之后，我们就顺利获得了文件；

3. 朋友的品牌设计林林总总好多个文件，字体文件，PDF 等等不同的格式。让 claude 读取了之后，直接生成一个 token.json 和 vi.html，所有视觉设计的要素就浓缩成几十 kb 的两个文件了。

Cline 出了自己的 kanban 调度系统，可以调用 claude / codex 之类的 agent。也是基于 worktree 设计的。

npm i -g cline

https://cline.bot/kanban

以前在各种后台改配置，最怕的就是不知道去哪里改，改完之后发现改错了。

现在准备了这么一个修改记录，每一步都问 AI，改完之后再让 AI 记录，这样一来，相当于有了一份 git 记录，即使改错了，也可以改回去。不同的改动有冲突也容易发现。