# Luca's Blog Full LLM Context Luca Wu 的个人博客，长期记录产品、技术、创业、写作和生活观察。 Author: Luca Wu Author page: https://wlj.me/about/ Generated: 2026-09-07 --- # 新加坡政府的钱从哪来 URL: https://wlj.me/posts/singapore-government-revenue/ Published: 2026-09-06 Updated: 2026-09-06 Tags: Reading个人所得税、企业所得税税率都不算高，政府却看起来很有钱。把 2025 财年修订账拆开看： 经常收入 1,309 亿新元。GST 已经超过个税。 投资回报 NIRC 275 亿，单独一项比个人所得税大。 卖地约 203 亿不进当年开支，进储备，再花回报的一半。 打开 --- # 什么是贡献者许可协议（CLA） URL: https://wlj.me/posts/what-is-cla/ Published: 2026-09-06 Updated: 2026-09-06 Tags: Tech最近我让 AI 给 Slax Reader 加了书签导入功能。代码提交成 PR 后，CLA Assistant 要求我先签一份协议，检查才会通过。我自己也签了一次，顺便弄清楚了 CLA 是什么。 CLA 的全称是 Contributor License Agreement，中文一般叫“贡献者许可协议”。它是代码贡献者和开源项目之间的一份协议，约定项目可以怎样使用贡献者提交的代码、文档和其他内容。 开源许可证规定别人可以怎样使用已经发布的项目。CLA 规定项目可以怎样使用别人提交进来的内容。 签 CLA 代表什么 具体权利要看协议文本。常见的 CLA 会要求贡献者确认几件事： 这份代码是自己写的，或者自己有权提交。 项目可以长期使用、修改和发布这份代码。 与这份代码有关的部分专利，也一并授权给项目使用。 如果代码受到雇主或第三方协议限制，需要提前说明。 贡献者一般仍然保留自己代码的版权，只是把一组明确的使用权授予项目。Apache 基金会对 CLA 的解释也是这样：贡献者保留原有权利，同时允许项目发布和继续开发这些贡献。 这份记录可以减少以后的争议。比如贡献者离职后，公司声称代码属于公司；或者项目几年后调整许可证，却发现没有权利处理早期贡献。CLA 会事先把这些问题写清楚。 有些 CLA 还允许项目把贡献放进采用其他许可证的产品，包括商业或闭源产品。这类权利适合双重许可的项目，也意味着贡献者给出的授权超过了普通开源许可证。 每次提 PR 都要签吗 使用 CLA Assistant 这类工具时，每个 PR 都会检查签署状态。贡献者签过当前版本后，后面的 PR 通常不用重复签。协议内容发生变化时，工具会要求重新签署。 这个步骤仍然会增加贡献门槛。修一个错字或改几行代码，也要先阅读一份法律文件。有些人看到这里就会放弃提交。 另一个轻量做法是 DCO。贡献者在每次提交里加一行 Signed-off-by，确认自己有权提交这份代码。DCO 主要确认代码来源，不额外授予项目广泛的再许可权。 Slax Reader 怎么用 Slax Reader 采用 Apache 2.0。它的第 5 条已经规定，提交给项目的贡献默认使用同一份许可证，除非双方另有协议。GitHub 服务条款也写了同样的规则。 Slax Reader 目前更需要降低参与门槛，让更多人愿意提交小改动。我的建议是先停用所有 PR 强制签 CLA 的规则。普通贡献使用 Apache 2.0 和 GitHub 的默认条款；如果想多留一份代码来源记录，可以使用 DCO。 等到 Slax Reader 确实需要双重许可、商业再授权，或者接收公司贡献的大块代码时，再启用 CLA。正式启用前，请律师检查法律主体、适用法律、专利授权和再许可范围，并给贡献者一份能看懂的说明。 CLA 本身是正常的开源治理工具。对 Slax Reader 来说，什么时候用、要求谁签，比安装一个检查机器人更重要。 参考：Apache Contributor Agreements、CLA Assistant。 --- # 新加坡创业生态全球第四？看看这个排名怎么算的 URL: https://wlj.me/posts/startupblink-index/ Published: 2026-09-06 Updated: 2026-09-06 Tags: Startup, Reading这几天在读新加坡刚发布的《经济战略检讨》报告（ESR）。里面有一句：新加坡的创业生态在 StartupBlink 指数上排全球第四，只在美国、英国、以色列后面，2019 年以来升了 17 位。 我的第一反应是：StartupBlink 是谁？政府报告为什么引它？于是让 AI 帮我查了一遍，整理如下。 一、它是什么 StartupBlink 是一家 2013 年成立的小公司，总部在苏黎世，创始人 Eli David 是以色列人，会计师出身。他们每年发一份《全球创业生态指数》，给 100 个国家、1,500 个城市打分排名。 打分由三部分组成： 数量：有多少创业公司、加速器、联合办公空间、线下活动。 质量：这些活动产出了什么。独角兽、退出、大额融资、公司网站的流量、国际大公司和投资人的分支机构。每家被抽样的创业公司还有一个 1 到 1000 的“SB 分”，主要看 Crunchbase 上的融资数据和 Semrush 上的网站流量。 营商环境：国家层面的条件。做生意的难易度、网速和网络自由度、研发投入、专利、税。 国家分要除以人口，城市分不除。这一条后面会讲到。 数据来源三块：他们自己众包的创业公司地图；Crunchbase、Semrush、Statista、BrightData 这些数据商；还有大约 100 个“生态伙伴”，大多是各国政府机构。他们用的是抽样，不做普查。 2026 年的国家榜：美国 314 分，英国 80 分，以色列 71 分，新加坡 68 分。美国一家抵后面所有人。新加坡是前十里涨得最快的，一年涨 24%。 二、中国排第几 同一份榜单，中国有三个位置。 按人口调整的国家榜：中国第 15，东亚第一。2021 年是第 7，之后每年往下掉，2023 年第 12，2024 年第 13，今年第 15。今年分数跌了 8%。 不按人口调整的“绝对实力榜”：中国第 2，只在美国后面，而且是这一组里涨得最快的，涨了 55%。美国的产出分是中国的五倍多。 城市榜（从来不按人口调整）：北京全球第 6，107.7 分；上海第 8，81.4 分；新加坡这座城市第 10，78.9 分。但北京、上海今年分别跌了 21% 和 20%，是头部城市里跌得最多的。杭州在中国国内升得最快，排国内第 5。StartupBlink 数出中国有 140 家独角兽。 三、为什么一个国家有三个名次 我看下来，把中国往下压的有三件事。 第一，除以人口。14 亿人一除，国家分就下去了。所以中国绝对产出第 2，人均第 15，城市又能排到第 6、第 8。 第二，数据的覆盖面。这个指数靠 Crunchbase 看融资，靠 Semrush 看流量。中国的创业公司在 Crunchbase 上记录不全，产品大多是 App 和小程序，流量又在 Semrush 看不清的中文互联网里。北京跌 21%，一部分是真的（2021 年以来中国的风险投资确实缩了），一部分是量不到。 第三，营商环境分里有网络自由度、经商便利度这类项目，跟创业活跃不活跃没关系，中国天然低分。 四、这个榜怎么用 我的看法是：看一个地方自己跟自己比的走势，可以用；比数据覆盖差不多的地方，可以用。拿它比中国和新加坡，量的更多是“这个生态在西方数据商眼里有多清楚”，以及“分数被多少人分摊”。 还有一点。给它提供数据的是各国政府机构，买它报告的主要也是政府机构。政府爱引它，道理在这。ESR 报告引了“第四”这个数，没提这些前提。 下次再看到“某某排名全球第几”，我大概会先问一句：分母是谁，数据是谁给的。 --- # 从 Omarchy 截图，贴进远程 Mac 上的 herdr URL: https://wlj.me/posts/omarchy-screenshot-remote-herdr/ Published: 2026-09-05 Updated: 2026-09-05 Tags: Tech, Tools, AI问题 我的日常是：坐在 Linux（Omarchy）前面，ssh 到 Mac，在 Mac 上跑 herdr，里面开 Claude Code / Codex。 在 Linux 上截图，想贴给 agent 看，贴不过去。没有报错，没有 [Image #1]，什么都没发生。 原因 SSH 只传文字。截图在 Linux 的剪贴板里，Mac 根本看不到。 ssh mac 之后再运行 herdr，herdr 整个跑在 Mac 上。它读的是 Mac 的剪贴板，不是我面前这台机器的。 这不是 Omarchy 的问题，也不是 herdr 的 bug。是架构决定的。 解法：反过来跑 在 Linux 上也装一个 herdr，用它作为客户端去连 Mac： herdr --remote username@host 这样 herdr 客户端在 Linux 上运行，UI 从 Mac 那边流过来。剪贴板在本地，所以图片可以桥接过去：按 Ctrl+V，herdr 把 PNG 通过 SSH 传到 Mac，再把 Mac 上的文件路径贴进 agent 的输入框。agent 读路径就行。 谁跑在哪 这样做以后 herdr 两边都有，但分工不一样： Mac：herdr 作为宿主。Claude Code、Codex 都在 Mac 上启动、运行、读文件。这才是干活的那个 herdr。 Linux：herdr 只是一个薄客户端。herdr --remote username@host 通过 SSH 连到 Mac，把界面拉回来显示。它多做的一件事是读本机剪贴板，把 PNG 送到 Mac。 agent 和会话都留在 Mac 上。Linux 这一份只是一个窗口，替代原来 ssh mac 那个终端。 --- # Omarchy 触摸板滚动加速 URL: https://wlj.me/posts/omarchy-touchpad-scroll-acceleration/ Published: 2026-09-05 Updated: 2026-09-05 Tags: Tech, Tools在 ThinkPad 上跑 Omarchy，触摸板滚动一直比 Mac 慢而平：手指快慢不同，页面走的距离都差不多。今天让 AI 查了一下，原因和改法都很短。 原因 Hyprland 把触摸板交给 libinput 处理。libinput 默认只给鼠标指针做加速，双指滚动是线性的，手指走多少页面走多少。Omarchy 在这之上还乘了一个 0.4 的系数（input.touchpad.scroll_factor），所以整体又慢了一截。Mac 的手感来自两样东西：一条按手速变化的加速曲线，加上抬手后的惯性滑动。 改法 libinput 有一个“custom”配置，可以给滚动单独画一条曲线。Hyprland 通过 accel_profile 和 scroll_points 两个选项把它暴露出来，Omarchy 的 Lua 配置里用 hl.device 可以只对触摸板生效，不影响小红点和外接鼠标。 在 ~/.config/hypr/input.lua 末尾加了这一段： hl.device({ name = "elan06b6:00-04f3:335a-touchpad", accel_profile = "custom 0.5 0 0.5 1.05 1.7 2.5 3.4 4.4 5.5", scroll_points = "0.5 0 0.4 0.9 1.5 2.3 3.3 4.5 6.0 7.8 10", }) 两行曲线的格式一样：第一个数是步长，后面是各个采样点的输出值。横轴是手指速度，纵轴是页面速度。慢慢滑的时候接近一比一，甩得快的时候往上翘。 设备名用 hyprctl devices 查。保存后 Hyprland 自动重载，hyprctl configerrors 为空就是生效了。 两个注意点 换成 custom 之后，触摸板的指针加速也一起换掉了，所以 accel_profile 后面必须同时给一条指针曲线，不然指针会变成没有加速。 曲线上的数字是起点，要靠手感调。想让快甩更猛就调大 scroll_points 后面几个数；想让慢滑更细就调小前面几个。整体都嫌慢的话，第二个旋钮是 Omarchy 默认的 scroll_factor = 0.4，改到 0.6 试试。 惯性滑动改不了。那是每个应用自己决定的，GTK 应用和 Chromium 有，其他不一定有，合成器这层没有开关。 回退的话把这段删掉就行，旧文件有 .bak 备份在同一目录。 --- # 我理解的 Omarchy URL: https://wlj.me/posts/my-take-on-omarchy/ Published: 2026-09-02 Updated: 2026-09-02 Tags: Tech, Tools今天下决心，把日常工作的电脑从 Mac 切换到了 Linux。 想这么做其实已经有些日子了，手边也有几台设备分别装着 Debian（喜欢了很多年）、NixOS（去年接触到之后，非常喜欢这个发行版的理念），但始终觉得还是有些许不方便。这次的“临门一脚”，是 Omarchy 推动的。 我大概半年多前第一次用 Omarchy，那时觉得这个发行版带着作者 DHH 非常强烈的观点——他喜欢的软件、习惯的配置，而我也有些偏执的喜好，于是只是浅尝辄止。 我也想了想，为什么最近两周 Omarchy 会在 X 上爆火，我觉得的几个原因有： DHH 的个人魅力——他有着极强的感染力，而且几十年持续创造输出，Ruby on Rails、Basecamp、Hey 等作品背后都是他。在 Omarchy 发布后，他极高强度地开发、宣传。最近更是组建了基金会，十几天时间里，募集了超过 1300 万美金——包括我在 Caoz 群里认识了几十年的 xdanger 也捐了 100 万美金。 Omarchy 的尝试成本很低——找一台旧笔记本电脑，插上启动 U 盘，几分钟时间就能装好，所有东西都按照 DHH 的品味，所谓“大厨精选”帮你装好了，可以快速开箱即用——这里其实解决了 Linux 桌面一直以来的大问题：选择过多导致普通用户无从下手。 AI first 的操作系统这样的说法，现阶段还是挺占便宜的，很多用户好奇心起就会试试。而且确实，AI 时代，每个人应该都能有一台真正顺手的，适合自己的电脑，这时的 AI first 很合理。 AI 极大降低了开发、支持、使用、改进的成本。例如：内置了 Omarchy Skill，你可以通过问 AI 直接得到如何修改配置等问题的准确做法。例如：当系统里有软件出错时，调用分析 skill，直接分析日志和代码，最后提交 PR 给开发者——挺好的闭环，也极大鼓励了用户的参与。 很好的插件机制，用户几句话就能做出自己需要的小插件，成就感很强，容易激发参与感和传播。 审美在线。很漂亮的系统，截图在社交媒体被广泛传播。 而且，据说后续 Omarchy 会改用 nix 来做包管理——那就真是我心目中完美的桌面系统了——我本来昨天想让 AI 往这个方向做的，听说之后，停下了任务，省 token 了。 --- # 怎么给 Omarchy 提 PR URL: https://wlj.me/posts/contribute-to-omarchy/ Published: 2026-09-02 Updated: 2026-09-02 Tags: Tools, Ops太长不看 Omarchy 装机自带一份给 AI 助手看的贡献指南，在仓库的 default/agents/skills/omarchy/contributing.md。跟 Claude 说"帮我给 Omarchy 报个 bug"，或者"把这个修法提成 PR"，它会读这份文件，自己走完收日志、截图、fork、跑测试、开 PR 的全过程。 下面是它照做的规矩，自己动手也一样。 去哪提 Omarchy 的代码在 omacom/omarchy。issue 只收确认过的 bug，模板第一行写着 “an open source gift, not a product you bought from a vendor”。功能建议去 Discussions 的 Suggestions 分类，手册修改去 Manual 分类，不确定是不是 bug 去 Discord。求助发到 Issues 会被关掉。 规矩 它没有 CONTRIBUTING.md，代码规范在根目录的 AGENTS.md：命令一律 omarchy- 开头，bash 字符串判断用 [[ ]]、数字用 (( ))，缩进两空格，shebang 只能 #!/bin/bash。不合规会被打回。 动手 报 bug 带上这两条的输出，日志可传到 logs.omarchy.org，24 小时过期： omarchy version omarchy debug --no-sudo --print 指南点名要截图，用 omarchy capture screenshot，只能在网页上拖进去。 提 PR 别在 /usr/share/omarchy/ 里改，那是包管理目录，更新时全覆盖： gh repo fork omacom/omarchy --clone cd omarchy ./test/all gh pr create 修视觉问题的 PR 要附前后对比截图。 什么会被合并 2026 年 9 月初：开着的 PR 1503 个，合并 1174 个，关掉没合并 1710 个。合进去的外部 PR 是 SSH 登录加固、主题名注入防护、.desktop 文件转义这类，具体、小、多数是安全和 bug 修复。 --- # Quickshell 是什么 URL: https://wlj.me/posts/quickshell/ Published: 2026-08-26 Updated: 2026-08-26 Tags: Tools, TechLinux 上做桌面部件的工具箱，官网 quickshell.org。状态栏、通知弹窗、锁屏、音量面板、壁纸切换器，这些东西用它来写。 它解决什么 上一篇讲 Hyprland 时提过，那种窗口管理器只管窗口怎么摆，状态栏、通知、锁屏都要另外找程序拼。常见的拼法是 Waybar 加 mako 加 hyprlock，各是各的程序，各有各的配置格式，样式对不齐，之间也不通消息。 Quickshell 换一个思路：这些部件全都自己写，用同一种语言，跑在同一个进程里。状态栏上的音量图标和按音量键弹出的那个提示，可以共用一份状态。 用什么写 QML，Qt 的界面语言。长这样： import Quickshell import QtQuick PanelWindow { anchors { top: true left: true right: true } implicitHeight: 30 Text { anchors.centerIn: parent text: "hello world" } } 这段就是屏幕顶部一条 30 像素高的栏，中间写着一行字。anchors 指定贴哪几条边，贴住之后 Quickshell 会自动向窗口管理器申请这块空间，其他窗口不会被它盖住。 QML 是声明式的：你写界面长什么样、数据变了界面怎么跟着变，不用自己写"收到消息 → 找到那个控件 → 改它的文字"这种流程。 存盘就生效 配置放在 ~/.config/quickshell/，每个子目录里有一个 shell.qml 就算一套配置。跑起来之后编辑文件，存盘界面立刻变，不用重启。改一个像素挪一下位置，改完扭头就能看见。 自带的接口 写桌面部件要拿系统数据。Quickshell 内置了这些： PipeWire：音量、当前播放设备 MPRIS：正在放什么歌，暂停下一首 系统托盘：那些图标 PAM：验证密码，锁屏要用 蓝牙 Hyprland 和 i3/Sway：当前工作区、窗口标题这类窗口管理器内部状态 官方只内置了 Hyprland 和 i3 两家的接口。用别的窗口管理器，得自己通过 socket 或者调命令去拿。 代价 得会写代码。Waybar 改个配置文件就能用，Quickshell 是让你自己写一个状态栏出来 从空白开始。它是工具箱不是成品，装完什么都没有 API 还在变。官方明说后续版本会有破坏性改动，升级时要照迁移指南改配置 现状 LGPL 3 开源，主力开发者 outfoxxed。源码在 GitHub，文档在 quickshell.org/docs。Wayland 和 X11 都支持。 社区里有人把整套配置开源出来，可以直接拿来用或者当参考，GitHub 上搜 quickshell 能找到不少。 --- # Hyprland 是什么 URL: https://wlj.me/posts/hyprland/ Published: 2026-08-26 Updated: 2026-08-26 Tags: Tools, TechLinux 上的一个窗口管理器，官网 hypr.land。它决定窗口怎么摆、怎么切换、动画长什么样。 平铺 一般桌面上窗口是叠在一起的，像桌上摊开的一堆纸，你拖来拖去调整位置和大小。平铺是另一种摆法：窗口不重叠，自动铺满整个屏幕。开第一个窗口占满屏，开第二个屏幕自动一分为二，开第三个再分。 好处是不用手动拖窗口，也不会有窗口被压在下面找不到。切换、移动、调整大小全走键盘快捷键。 Linux 上平铺窗口管理器有很多，i3、dwm、sway 都是。Hyprland 的区别在于它有圆角、模糊、阴影和动画，窗口开关和切换都有过渡效果。 Wayland Hyprland 只能在 Wayland 上跑。 Wayland 是 Linux 上画图形界面的一套协议，用来取代 1987 年的 X11。在 X11 时代，窗口管理器和显示服务器是两个程序；到了 Wayland，两者合并成一个，叫合成器（compositor）。所以 Hyprland 既管窗口布局，也管画面合成。 老程序只认 X11 的，通过 XWayland 这个兼容层照样能跑。 它不是完整桌面 GNOME、KDE 装完就能用：状态栏、文件管理器、设置面板、通知、锁屏，全都有。Hyprland 只管窗口，其余要自己拼： 状态栏：Waybar 程序启动器：wofi 或 rofi 通知：mako 锁屏：hyprlock 壁纸：hyprpaper 装完第一次启动是一块黑屏加一个鼠标指针，什么都没有。所有东西都得自己配出来。 配置 一个文本文件，~/.config/hypr/hyprland.conf。按键绑定、动画、窗口规则都写在里面，存盘立刻生效，不用重启。所有配置项在 Wiki 上。 bind = SUPER, Return, exec, ghostty bind = SUPER, Q, killactive bind = SUPER, 1, workspace, 1 animations { enabled = true bezier = smooth, 0.05, 0.9, 0.1, 1.05 } 现状 滚动发布，两三个月一个版本，最新是 0.56.2（2026 年 8 月）。主力开发者是 Vaxry。版本号还在 0.x。源码和发布记录在 GitHub。 在 NixOS 上 一行： programs.hyprland.enable = true; 配合 home-manager，状态栏、快捷键、主题、壁纸全部声明在同一份配置里。换台机器 nixos-rebuild 跑一遍，桌面一模一样。 谁不需要它 用 macOS 或 Windows 的：跑不了，它是 Linux 专属 服务器：没有显示器，装了也没用 想装完就能用的：它需要花时间拼一套自己的桌面 --- # 备份公司邮箱的三种办法 URL: https://wlj.me/posts/backup-work-email/ Published: 2026-08-26 Updated: 2026-08-26 Tags: Tools, Ops企业微信邮箱、腾讯企业邮箱，网页端和客户端都只能一封一封另存，没有批量导出。想把几年的邮件整个拿到手，得走 IMAP。 三条路：Mac 自带的邮件 App 导出、imapsync 搬到 Gmail、自己写脚本存本地。共同前提是先开 IMAP。 先开 IMAP 网页登录企业邮箱： 设置 → 收发信设置 → 开启 IMAP/SMTP 服务 设置 → 邮箱绑定 → 看"安全登录"开没开。开了就生成一个客户端专用密码，下面三种办法都用它，不用邮箱密码 服务器 imap.exmail.qq.com，端口 993，SSL 账号被公司回收之后什么都拿不了，要备份趁还能登录。 一、Mac 邮件 App 导出 邮件 → 添加账户 → 其他邮件账户，填地址和客户端专用密码，服务器手填上面那个。等它把邮件同步完，几万封要一两个小时。 然后选中左边的邮箱，菜单 邮箱 → 导出邮箱，选一个文件夹。每个邮箱导出成一个 .mbox。 好处：不用装东西，附件都在里面 坏处：.mbox 是一个大文件，几年邮件轻松上 GB，搜索只能靠再导回某个邮件客户端。Apple 的导入功能对超过 2 GB 的 mbox 会出问题，导出时按邮箱分开导，别一次全选 适合：一次性存档，存完基本不再翻。 二、imapsync 搬到另一个邮箱 不落地本地文件，直接把邮件复制到 Gmail 或 Fastmail。 brew install imapsync imapsync --host1 imap.exmail.qq.com --user1 you@company.com --password1 '客户端专用密码' \ --host2 imap.gmail.com --user2 you@gmail.com --password2 '应用专用密码' \ --gmail2 默认全量：所有文件夹所有邮件，保留时间和已读状态。再跑一遍是增量的，按 Message-ID 跳过搬过的。不加 --delete1 / --delete2 它不删任何东西，源邮箱后来删掉的邮件目标那边还留着。 第一次跑前先 --dry 空跑一遍看文件夹怎么映射。 Gmail 那边要先开两步验证再生成应用专用密码，普通密码登不了 IMAP。Gmail 的 IMAP 每天限上传 500 MB，几 GB 的邮箱要跑好几天，--gmail2 会自动限速避开配额，顺便把"已发送"映射到 [Gmail]/Sent Mail。Fastmail 没有每日配额，也不需要这个开关。 好处：一条命令，搜索直接用 Gmail 的 坏处：邮件还在别人服务器上。Gmail 账号出问题就一起没了 适合：日常还要查、要用手机看。 三、自己写脚本存本地 让 AI 写了一个：exmail-backup，纯 Python 标准库，一个文件，跑在 macOS 自带的 Python 3 上。 它做两件事：把每封邮件按原样存成 .eml 文件，同时建一个 SQLite 全文索引。 ~/Mail/exmail/ ├── INBOX/1234.eml ├── 已发送/88.eml └── index.sqlite 用法： python3 exmail_backup.py set-password # 密码进钥匙串 python3 exmail_backup.py sync -v # 增量拉 python3 exmail_backup.py search 发票 python3 exmail_backup.py search "合同 附件" --since 2025-01-01 python3 exmail_backup.py search --from alice --attachment python3 exmail_backup.py show 1234 # 正文和附件名 python3 exmail_backup.py open 1234 # 用邮件 App 打开，附件在里面 几个设计上的取舍： 只读。 只读 SELECT 加 BODY.PEEK，不改已读状态，不删任何东西。服务器上删了的本地照样留着——这是备份该有的样子。 一封一个文件。 不用 mbox 那种大文件，坏一个不影响其他。索引坏了 reindex 从文件重建。 中文能搜。 SQLite 的 FTS5 不认中文分词，所以建索引时把每个汉字之间插空格，查询时整个词当短语匹配。结果是"发票"能搜到，“票发"搜不到，单字也能搜。 能中断。 每个文件夹记到哪个 UID 了，每 100 封提交一次。Ctrl-C 之后再跑接着来。 定时的话 crontab 加一行： 0 */6 * * * /usr/bin/python3 ~/path/to/exmail_backup.py sync >> ~/Mail/exmail/sync.log 2>&1 好处：文件在自己硬盘上，能 grep，能进 Time Machine，格式是标准的 .eml 任何邮件客户端都能打开 坏处：得自己跑，出问题得自己修。索引和检索那部分有测试覆盖，连真实邮箱拉数据那段还没实跑过，第一次用建议先 --folder INBOX 只拉一个文件夹看看 适合：当保险箱，几年后还要能翻出来。 怎么选 存档一次就完的，用 Mac 邮件 App。日常还要查的，imapsync 搬 Gmail。要留一份自己完全掌控的，用脚本。 三个不冲突，同一个邮箱可以同时用两种。 管理员的补充 如果你是企业邮箱管理员，管理后台 → 工具箱 → 邮件备份，可以设规则把指定成员的邮件自动抄一份到备份邮箱。注意它只管开启之后的新邮件，历史邮件一封不备份。存量还是得走上面三条路之一。 --- # nixos-anywhere：一条命令把远程 Linux 装成 NixOS URL: https://wlj.me/posts/nixos-anywhere/ Published: 2026-08-25 Updated: 2026-08-25 Tags: Tools, Ops, NixOS装 NixOS 通常要做安装 U 盘，进安装环境，手动分区，手动装。云主机更麻烦，很多厂商没有 NixOS 镜像，只给 Debian、Ubuntu。 nixos-anywhere 解决的就是这件事。只要一台机器能 SSH 登录，它就能远程把机器上的 Linux 换成 NixOS。不用 U 盘，不用控制台，不用厂商支持。 它怎么做到的 靠的是 Linux 的 kexec。kexec 能跳过硬件重启，直接把内存里正在跑的内核换成另一个。nixos-anywhere 用它做四步： SSH 登进目标机器，下载一个很小的 NixOS 安装环境，用 kexec 切换过去。原来的系统被踢出内存，机器现在跑在一个纯内存的 NixOS 安装盘里。 按你写的分区文件给硬盘分区、格式化、挂载。这一步交给 disko 做，disko 是一个用配置文件描述磁盘布局的工具。 把你定义好的 NixOS 系统传到机器上，装进硬盘。 重启。机器起来就是 NixOS。 要准备什么 本机： 装了 Nix，开了 flakes 一个 flake，里面定义了目标机器的 NixOS 配置 一个 disko 分区文件 目标机器： 跑着任意 Linux，x86_64 或 aarch64 能用 root 或免密 sudo 的用户 SSH 登录 内存 1GB 以上，安装环境要在内存里跑 支持 kexec。多数虚拟机和物理机都支持，OpenVZ、LXC 这类容器不支持 一个完整的例子 flake.nix： { inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixos-26.05"; disko.url = "github:nix-community/disko"; disko.inputs.nixpkgs.follows = "nixpkgs"; }; outputs = { nixpkgs, disko, ... }: { nixosConfigurations.web = nixpkgs.lib.nixosSystem { system = "x86_64-linux"; modules = [ disko.nixosModules.disko ./disk-config.nix ./configuration.nix ]; }; }; } disk-config.nix，一块盘，一个启动分区加一个根分区： { disko.devices.disk.main = { device = "/dev/sda"; type = "disk"; content = { type = "gpt"; partitions = { ESP = { size = "500M"; type = "EF00"; content = { type = "filesystem"; format = "vfat"; mountpoint = "/boot"; mountOptions = [ "umask=0077" ]; }; }; root = { size = "100%"; content = { type = "filesystem"; format = "ext4"; mountpoint = "/"; }; }; }; }; }; } configuration.nix 至少要写引导程序，加一条装完能拿到 root 的路。最简单的是把 SSH 公钥配在 root 下： { boot.loader.systemd-boot.enable = true; boot.loader.efi.canTouchEfiVariables = true; services.openssh.enable = true; users.users.root.openssh.authorizedKeys.keys = [ "ssh-ed25519 AAAA... you@laptop" ]; system.stateVersion = "26.05"; } 如果你想用普通用户登录、sudo 提权，那这个用户要进 wheel 组，并且要么给他设密码，要么让 sudo 免密： { users.users.luca = { isNormalUser = true; extraGroups = [ "wheel" ]; openssh.authorizedKeys.keys = [ "ssh-ed25519 AAAA... you@laptop" ]; }; security.sudo.wheelNeedsPassword = false; } 然后一条命令： nix run github:nix-community/nixos-anywhere -- \ --flake .#web \ --target-host root@1.2.3.4 装完后目标机器的 SSH 主机密钥变了，再登录会报错。把 ~/.ssh/known_hosts 里那台机器的旧记录删掉就行。 常用开关 物理机装之前先生成硬件配置，不然网卡、显卡驱动可能缺： --generate-hardware-config nixos-generate-config ./hardware-configuration.nix 先在本地虚拟机里试一遍分区和系统能不能起来，不碰真机： --vm-test 目标机器配置低，系统在本机编译好再传过去： --build-on local 内存只有 1GB 左右的机器，少传一些分区工具的依赖，省内存： --no-disko-deps 装完后往新系统里放文件，比如 SSH 主机密钥、密钥文件： --extra-files ./files 保留目标机器原来的 SSH 主机密钥，省掉改 known_hosts： --copy-host-keys 系统配坏了想重装但不动数据，分区模式改成只挂载不格式化： --disko-mode mount 坑 分区文件里的 device 写错盘，会把错的盘格掉。先 lsblk 看清楚，或者用 /dev/disk/by-id/ 下的名字。 装完要能提权。普通用户只配了公钥、没设密码，sudo 默认要密码，root 又没配公钥——这台机器上就没人能变成 root，sudo、su、passwd 全都过不去。要么公钥配给 root，要么 security.sudo.wheelNeedsPassword = false，要么给用户设密码。装完第一条命令先跑 sudo whoami。 已经锁死了的救法：重启进引导菜单按 e，内核参数加 init=/bin/sh，进去后 mount -o remount,rw /，passwd 用户名。这条路要求控制台在手。 安装环境跑在内存里，内存小的机器传大系统会内存不足。先试 --build-on local 和 --no-disko-deps。 改了分区文件，先跑 --vm-test，比在真机上格错盘便宜。 --- # Brave Origin 盲签名方案 URL: https://wlj.me/posts/brave-origin-blind-token/ Published: 2026-08-24 Updated: 2026-08-24 Tags: Security, TechBrave 6 月上线了 Origin，59.99 美元买断。Leo、News、Rewards、VPN、Wallet、Talk、Tor、Speedreader、Web Discovery 全部从二进制里编译掉，只留 Shields 和 Chromium 内核。Linux 免费。 我买了一个。翻文档的时候看到激活这一步的做法：Brave 的服务器没办法知道是谁在用这份授权。 它用的是盲签名。 常规做法是查表 付费解锁都要回答一个问题：这台设备凭什么证明自己付过钱。 一般是账号体系。你登录，服务器查表，这个 user_id 买过，放行。表里就记着某某邮箱在用 Origin、今天启动了几次。 盲签名把这张表去掉了。名字里的「盲」就是服务器闭着眼睛签——它签的时候不知道自己在签什么，签完也认不出来。 用数字走一遍 服务器手里有个只有它知道的私章，就当它是「乘以 7」。 我在自己电脑上随手生成一个 token，是 3。我要拿到「服务器给 3 盖过章」的证据，又不想让它知道 3 是多少。 我再挑一个随机数 5，把 3 乘上去：3 × 5 = 15。把 15 发过去 服务器盖章：15 × 7 = 105。把 105 还给我 我把 5 除掉：105 ÷ 5 = 21。21 正好是 3 × 7 现在我手上有一对数 (3, 21)。以后要用 premium 功能，把这两个数交出去，服务器算一下 3 × 7 是不是 21，对上了就放行。 服务器从头到尾只见过 15 和 105，没见过 3，也没见过 21。等我拿 (3, 21) 来的时候，它没办法把这次和当初签名那次对上——15 可以是任何人的 token 乘任何一个随机数得来的。 那个随机数 5 是全部的关键。它只存在我这台机器上，签完就扔。服务器少了它，就没法从 15 倒推回 3。 普通乘法当然撑不住：我拿 105 除以 15 就把 7 算出来了，之后自己在家就能给任意数字盖章。真实实现把乘法换成椭圆曲线上的运算，这个方向上除不回去。步骤一模一样。 二十行代码 Chaum 1982 年那版用的是 RSA，能直接跑： import random from math import gcd # 服务器的密钥对（教学用小素数，真实场景是 2048 位） p, q = 1000003, 1000033 n = p * q e = 65537 d = pow(e, -1, (p - 1) * (q - 1)) # 私钥，只有服务器手里有 # 1. 浏览器在本地生成一个随机 token token = random.randrange(2, n) # 2. 挑一个随机数当信封，把 token 蒙起来 r = random.randrange(2, n) while gcd(r, n) != 1: r = random.randrange(2, n) blinded = token * pow(r, e, n) % n # 3. 服务器签名。它看到的只有 blinded blinded_sig = pow(blinded, d, n) # 4. 浏览器把信封拆掉 sig = blinded_sig * pow(r, -1, n) % n # 5. 之后拿 (token, sig) 去验证 print("token =", token) print("服务器看到的 =", blinded) print("拆出来的签名 =", sig) print("验证通过:", pow(sig, e, n) == token) 跑出来： token = 99230956405 服务器看到的 = 191161851496 拆出来的签名 = 366511550198 验证通过: True pow(r, e, n) 是上面那个「乘以 5」，pow(r, -1, n) 是「除以 5」。服务器那一行只碰得到 blinded。 Brave 用的是椭圆曲线版本（VOPRF，可验证的不经意伪随机函数），走自家的 challenge-bypass-ristretto 库。数学换了，这五步一步不差。 Brave 的实际流程 你在 Stripe / App Store / Play Store 付款 浏览器在本地生成一批随机 token 盲化之后发出去，订阅服务转给 Brave 的 Challenge Bypass Server（CBR）签名，CBR 从没见过原始 token CBR 返回签好的 token，附一份 DLEQ 证明 浏览器验证证明，在本地解盲，得到可用的凭证 第 4 步那份证明是防一手阴的：服务器要是给每个人发不同的私章，光看章就能把人分出来，盲签名就白做了。DLEQ 证明用来说明这批签名和公开的那把公钥是同一把私钥出的，没有掉包。 凭证里只有三样东西：token 本身、一个 HMAC、一个有效期窗口。没有账号 ID，没有邮箱，没有支付信息。HMAC 把 token 绑到具体的发行方和商品上（比如 brave.com?sku=leo-monthly），你没法拿 Origin 的凭证去解锁 Leo。 各方看到的东西是切开的。支付方知道某某付了 59.99；订阅服务有订单数据，但看不到原始 token；CBR 看得到签发和兑换这两类事件，但连不起来。 官方文档里的说法是 decouple payment identity from service usage。 这套东西是 1982 年的 David Chaum 1982 年提出盲签名，比 Web 还早。他当时想做数字现金：银行能确认这张钞票是自己发的、没被花过两次，但不知道是谁在哪家店花的。 让它铺开的是 Privacy Pass。最早是 Cloudflare 的研究者推的，解决一个很具体的烦恼——Tor 和 VPN 用户老被 CAPTCHA 反复拦，因为服务器认不出他们刚刚才通过验证。Privacy Pass 让你验证一次拿到一批匿名 token，之后直接兑换通行，服务器无法把这些 token 关联到同一个人。 现在它是 IETF 标准，RFC 9576 / 9577 / 9578。Apple 叫 Private Access Tokens，Google 叫 Private State Tokens，Edge 里也有。 代价：他们自己也数不清设备 传统授权能做设备管理，因为服务器认得出「这是老王的第 4 台设备」。盲签名把这个能力砍掉了。Brave 分不清是你在 5 台设备上激活，还是你把购买 ID 发到群里被 50 个人用。 服务器端只剩防重放：CBR 记下已经兑换过的 token，同一个 token 换个绑定再来就返回 409 拒掉，完全相同的重放当幂等操作接受。 剩下的约束是激活的月度频率限制。设备数没有硬上限，撞到频率限制就去 account.brave.com 自助申请提额。 这只是摩擦力。你把购买 ID 发到群里，前几个人能激活，后面的等下个月。 换机器的时候没有「解绑旧设备」这一步，因为压根不存在绑定。重新激活一次就行。 --- # Helpfeel：做 Gyazo 和 Scrapbox 的那家京都公司 URL: https://wlj.me/posts/helpfeel-kyoto/ Published: 2026-08-20 Updated: 2026-08-20 Tags: Startup, Product, Small and Beautiful株式会社 Helpfeel 总部在京都上京区，东京有办公室，资本金 1 亿日元，员工 213 人（2025 年 8 月）。全远程、全弹性工时。 前身是 Nota, Inc.，2007 年 12 月 21 日在美国加州创立。2020 年 12 月设立日本法人，2022 年 10 月 1 日把公司名改成了主力产品的名字 Helpfeel。 两个人 洛西一周，1982 年生，代表取締役 CEO。高中时写了 Windows 上的笔记软件「紙copi」，下载超过 100 万次，十年卖了 3 亿多日元。IPA 未踏项目出身。2026 年 1 月他本人搬去了美国。 増井俊之，Technical Fellow，庆应大学教授。预测输入法 POBox 的发明者，在 Apple 做过 iPhone 的日文 flick 输入。Gyazo 是他 2007 年的作品，Helpfeel 的核心技术也是他的发明和专利。 三个产品 产品 上线 是什么 Gyazo 2007 截图、GIF 即时分享。月活 1000 万以上，80% 以上是海外用户，累计 2300 万用户 Cosense 2016 用链接把页面连起来的团队 wiki。原名 Scrapbox，2024 年 5 月改名 Helpfeel 2019 搜索型 FAQ，企业客服自助系统。2026 年 4 月超过 900 个站点 Cosense 改名时官方给的数字：页面总数超过日文维基百科的 10 倍以上。定价上个人免费，上限 300 页、5 人；Business 版每人每月 1100 日元。 Helpfeel 的做法是给每一条 FAQ 预先展开出大量可能的问法——错别字、口语说法、别称都算进去，用户打第一个字就开始出候选。这套叫「意图预测搜索」，是増井的专利。现在再叠一层 RAG，回答只从企业自己的可信资料里生成。 三个产品放在一起是一条线：Gyazo 收集，Cosense 整理，Helpfeel 分发。 时间线 年份 事 2007 Nota, Inc. 在加州成立，Gyazo 发布 2014 A 轮 200 万美元（Opt、YJ Capital、みやこキャピタル） 2015 京都今出川办公室 2016 Scrapbox 上线 2017 转为盈利 2019 Helpfeel 上线，东京办公室 2020 设立日本法人，获みずほイノベーション大賞 2021 B 轮 5 亿日元（One Capital 领投）；Helpfeel 获 Good Design Award 2022 改名 Helpfeel；C 轮 6 亿日元 2023 D 轮 20 亿日元；洛西获 Software Japan 大奖；累计 300 个站点 2024 Scrapbox 改名 Helpfeel Cosense；500 个站点 2025 E 轮首关 26 亿日元（Global Brain、JP Investment）；700 个站点 2026 E 轮完成，共 29 亿日元（Globis Capital Partners 领投），累计融资 62 亿日元；900 个站点 2017 年转为盈利，到 2021 年才拿 B 轮，中间四年没有融资。 现在在做什么 2026 年他们把三个产品重新包装成「AI 知识数据平台」。他们的说法是，企业用 AI 的瓶颈在自己的知识没整理干净，AI 拿不到可靠的信息源。E 轮的钱用在这条线上，招工程师、事业开发和咨询人才。 同时以美国为据点做海外，CEO 搬过去直接建当地的销售和合作关系。 来源 会社概要、沿革 Helpfeel、シリーズE総額29億円で調達完了（2026-01-27） Helpfeel、26億円を資金調達、累計調達額は59億円 「Scrapbox」は「Helpfeel Cosense」に変わります Helpfeel - Wikipedia Notaが社名を「Helpfeel」に変更 洛西一周 Helpfeel代表取締役CEO（週刊エコノミスト） --- # 时雨堂：一家 5 个人的日本软件公司，把经营手册全部公开了 URL: https://wlj.me/posts/shiguredo-company-docs/ Published: 2026-08-20 Updated: 2026-08-20 Tags: Startup, Management, Small and Beautiful株式会社時雨堂（Shiguredo）2013 年 3 月在东京成立，主营 WebRTC 实时音视频中间件 Sora，GitHub 账号是 shiguredo。创始人 voluntas 持股 100%，公司登记的代表取締役是中井亮介。员工人数上限写死为 5 人。 这家公司把雇佣条件、薪资、奖金实绩、评价制度、产品战略、工作时间制度全部写成公开文档挂在 GitHub Gist 上，定期更新。销售额、奖金占比、赞助和捐款金额都写在里面。 下面是其中七份的中文版，让 AI 按原文结构压缩编译，关键事实都保留了。原文是日文，篇幅很长，每一节都给了链接，以原文为准。这些文档还在持续更新，各篇更新日期不同，日期也标了。 一、公司总纲 原文：時雨堂コトハジメ（更新 2026-08-01） 方针 创始人（持股 100%）想怎么干就怎么干的公司。开发自社产品赚钱，回馈员工和社会。不做出售，不做上市。想成为赚很多、也捐很多的企业。 规模 员工上限 5 人。人多了销售额也许能涨，但会带来各种弊端，最在意的是信息共享成本变高，这个绕不开。5 个人的话，对全员保持透明还勉强做得到。少人数、高利润率、高收益，盯住这个就不会跑偏。 想增加人的时候，做法是再开一家公司。守住时雨堂这个文化，5 人是极限。 雇佣条件 项目 内容 雇佣形态 只要正社员。不招兼职、实习、应届 工作地点 东京都台东区台东 2-10-2 竹田大厦 4F 工作时间 10:00–13:00、14:00–17:00（6 小时） 休息日 完全双休、法定假日、暑假 2 天、寒假（不定） 带薪假 试用期结束时给 20 天，之后每年 20 天 发薪日 当月工资次月 10 日发，遇休息日提前 工资 正社员全员同额 评价 没有评价制度 加薪 看公司业绩判断，不保证 交通费 每月上限 3 万日元 奖金 看公司业绩判断，10 月底发，无最低保证 退职金 有退职金制度 考勤 在公司聊天工具里写一句 体检 每年一次全面体检 副业 不影响本职工作即可 远程 有条件采用 加薪实绩 创业第 4 年涨到了原定的工资水平，之后不打算再涨。但国家情况变化会考虑，比如消费税加税： 消费税从 5% 涨到 8% 时，加薪 10% 消费税从 8% 涨到 10% 时，加薪 17% 奖金实绩（只登实绩） 期 奖金占销售额 第 2 期 约 15% 第 3 期 约 20% 第 4 期 无 第 5 期 约 15% 第 6 期 约 30% 第 7 期 约 25% 第 8 期 约 25% 第 9 期 约 20% 第 10 期 约 20% 第 11 期 约 20% 第 12 期 约 15% 第 13 期 约 25% 第 4 期集中开发自社产品，没有奖金。最高年收的上限已经取消——不设上限也没关系，只雇能扛得住的人就行。 福利 伤害保障：加入「あんしん財団」企业共济，公司负担，役员和全体正社员都在内，工作中和工作外 24 小时都保。 癌症保险：セコム損保 メディコム，公司负担，役员和全体正社员。 退职金：加入中小企业退职金共济。本来的立场是与其发退职金不如当下就返还，但对员工几乎没有坏处，所以引入了。 流感疫苗：每年一次，公司负担，含役员在内全员。 体检：不分年龄都做钡餐或胃镜，每年一次，追加项目公司负担上限 2 万日元。 规则 规则很少，只在「遇到麻烦时」才慢慢加。举例： 不是裁量劳动制，是 10:00–17:00 定时工作制 午休 13:00–14:00 22:00 之后的加班给调休 带薪假第一年就给 20 天 1 小时以内的迟到不扣钱（到 11:00） 1 小时以内的早退不扣钱（16:00 起） 迟到早退这条不是预设 11:00–16:00 会变成常态，是给有事的时候留的口子。 把规则定严很容易，所以要尽量把规则定得松。规则是「拿不准的时候拿来对照的东西」。**为了防员工而设的规则，能不做就不做。**今后也尽量不加规则。 育儿 公司内部共享的规则原文： 孩子出生到 1 岁期间，因育儿难以到公司上班的，可以在家远程办公（基本还是请正常出勤） 孩子出生到 1 岁期间，因育儿难以按正常时间上班的，只要保证相当于 10–17 点的 6 小时工作时间，开始和结束时间不限。但到公司上班的情况下，极端晚退和极端早到不行，请在常识范围内调整 远程或错开工作时间时，在 Slack 上提前（当天早上也行）告知同事即可，不必每次给总务发邮件 孩子看病或突发看护要请假的，按正常流程申请带薪假 万一带薪假用完，按育儿介护休业法给「子女看护假」每年 5 天（每个学龄前儿童），但这部分无薪（不算旷工，不作处罚），且不能结转到下一年 孩子满 1 岁后仍需要适用上述规则的，商量后从满 1 岁次日起最长可延长半年 适用上述规则期间，工资和奖金与其他员工没有差别 酷暑、台风、大雪时的出勤 **等上司判断是浪费时间。**台风或大雪时，觉得上下班可能有困难，由个人判断，推迟出勤、提前下班、居家办公，或者当天改成带薪假都可以。在聊天工具里说一声就行。 公司信用卡 给有需要的正社员发公司信用卡，公司名义、印员工名字。用卡必须报告，事前事后都行。 社内环境 显示器尽量大 工作台尽量大 PC 尽量高性能 椅子在 30 万日元以内，挑坐着舒服的 最大的强项可能是「时雨食堂」——每周一次在自家厨房做的饭，总务或员工做，考虑健康，参加不强制。 书籍补助：公司买的书归自己，每年 2 万日元以内。电子书很多情况下法人买不了，主要是为这个。 食堂规则原文： 基于「要精神地工作，吃很重要」的想法，尽量选对健康好的菜单，味道和豪华程度排在后面 食堂能让役员和员工之间产生交流，也能当午餐会议的场所，因此全额作为「会议费」由公司经费运营 在时雨食堂吃饭是自愿的，绝不强制，按菜单和自己的健康状况决定 公司还买过家用面包机、面条机、章鱼小丸子机（后两个「最近没怎么用」）。 开发环境 PC 基本发移动本，外接显示器 + 移动本统一。有需要也发台式。开发用的服务积极用：Vultr、Akamai Cloud、GitHub（含 Copilot）、Claude、ChatGPT（含 Codex）、Claude Code、Slack、Google Workspace（含 Gemini）、Cloudflare、Kibela、1Password、Gyazo、Dropbox（含 Sign）。有新服务就主动去碰。自动化也积极引入，人少的时候自动化收益很大。 评价与职位 没有评价制度，正社员工资全员相同。总务和技术一个数。没有面谈、没有考核、没有奖金评价。每年的利润留下公司需要的部分，剩下按人数分。比如员工 2 人，扣掉公司要用的之后剩 100 万日元，那就一人 50 万。就这样。 时雨堂没有职位。正社员全员同一，没有管理职。人少就没问题，目前没遇到麻烦。 人才与教育 聚起来的基本是「只要是工作什么都干」的人。技术上有好恶正常，但能把这事分开看。当然这个「什么都干」的前提是不接烂活。另外基本要求不挑食。技术人员招的是「尽可能作为技术人员挣钱的人」——小团队基本不需要经理，但技术人员的资源管理和信息共享能力非常看重。光会写代码不行，组队时能带动周围的人很重要。 没有教育机制。有信息共享，但不专门留出「教育」时间。不过自社产品相关的工作不设截止日期，可以花时间做。方针三根柱子：持续开发、积极更新、持续测试。 各期主题与销售额里程碑 期 主题 里程碑 第 4 期 转向自社产品，减少外包受托 集中开发，无奖金 第 5 期 以自社产品为轴，Sora 成形 自社产品收入够付全员工资 第 6 期 填外围护城河 2018 年 3 月月销售额超 3000 万日元 第 7 期 培育自社产品 2019 年 6 月月销售额超 3000 万日元 第 8 期 增强自社产品 2019 年 12 月月销售额超 3000 万日元 第 9 期 做能带动主力产品的周边产品 2021 年 2 月月销售额超 4000 万日元 第 10 期 主力产品服务化 2022 年 4 月月销售额超 4000 万日元 第 11 期 主力产品服务扩张 2023 年 4 月月销售额超 4000 万日元 第 12 期 主力产品进入新领域 2024 年 4 月月销售额超 5000 万日元 第 13 期 不做新开发，彻底加强现有产品 第 14 期 彻底加强自社开源 第 9 期之后的外部帮忙只接现有客户，第 10 期起只接现有客户或熟人。 分工 经营者自己的工作只有三件：做决定、产出利润、持续传达想做的事。其余时间和其他技术人员站在同一位置干活。 经营相关的事务作业全部交给总务。给总务的要求只有两条：「减少支出」和「把职场环境弄好」。劳务、税务、法务全部外包，连创业手续本身也全外包了——判断是专心把钱赚好、把公司做好更划算。 技术上不分工，技术人员从前端到基础设施全包。 每月写一份《YYYY 年 MM 月的时雨堂动向》，共享销售额、销售目标、外包支出、对全体员工期待的动作。理想状态是做到不需要看这个。 不招销售 时雨堂做的产品面向技术人员，不打算做「不懂技术的销售也能卖出去」的产品。参与开发的技术人员去讲，说服力非常强。 销售活动只靠博客、Gist 技术资料、自家活动。不参加其他活动，不参展。 支持 自社产品的支持不雇专职，由产品开发者本人做。因为做的是开发者用的产品，来问的基本也是开发者。 经营 无借款经营 不做让员工吃亏的事 做能带来下一次的活 病态程度的透明 把员工当成年人 这行业不需要借钱是好事，有 PC 和网络就够，成本只有人工，也就是只有固定费，几乎没有变动费。每月做到固定的销售额就能转。 因为没有评价，人事上就没有要藏的信息，几乎所有信息都能共享。对公司的不满多半来自「有些决定莫名其妙」。没钱就说没钱，有钱就说有钱。销售额在聊天里共享。 对员工「当成年人对待」，细节不插嘴，交出去。定好大框剩下交给员工，出问题自己负责。 管理 尽量不做管理。长期愿景靠闲聊传达，短期方针靠文档。目标是做成自立型组织：全员在没有具体指示的情况下，各自判断当下该做什么。 活动 欢迎会、忘年会这类下班后的酒局，公司一概不办。要办就在时雨食堂把午饭时间拉长一点。想喝酒的人自己约。如果公司来办，应该在工作时间内办、公司出钱。比如年末最后一天的纳会，那天下午放假，午饭时间办。 固定活动（现在全远程所以没做）：12 月最后一个工作日 13:00 收工后自愿参加纳会午餐；3 月 8 日创业日 13:00 订个好点的地方跟员工和相关人士吃午饭；10 月 1 日期初日同上。都有拒绝权，绝不强制。 员工旅行去过德岛县（原本是自己一个人去考察地方 IT 特区）和石川县（想住加贺屋，纯属自己任性）。 赞助与捐款 「靠开源撑着公司转，却因为自己的事忙不过来没时间贡献」，于是改成给常用的开源和认同的非营利组织做赞助。 GitHub Sponsors 对象包括 Loïc Hoguin（ranch / cowlib / cowboy / gun）、Tatsuhiro Tsujikawa（nghttp2 / ngtcp2 / nghttp3）、Peter Saveliev（pyroute2）、Ulf Wiger（gproc）。 对象 期间 金额 Let’s Encrypt 2017-08 ~ 2026-07 年 1.25 万美元 OpenSSL（银牌） 2021-08 ~ 2025-07 年 2 万美元 Erlang Ecosystem Foundation 2021-082022-07、2025-082026-07 年 5 千美元 DuckDB Foundation（银牌） 2025-08 ~ 2026-07 年 1 万欧元 Zig Foundation 2022-09 ~ 2023-08 年 1.2 万美元 cpprefjp（金牌） 2023-10 ~ 2024-09 年 800 美元 捐款（企业版故乡纳税和研究支援）：冈山县总社市 100 万日元（2018）、东北大学大学院医学系研究科笠原好之 199 万日 … --- # Google Tag Manager 是什么，有哪些替代品 URL: https://wlj.me/posts/google-tag-manager-and-alternatives/ Published: 2026-08-20 Updated: 2026-08-20 Tags: Tools, Marketing, ProductGoogle Tag Manager（GTM）是个标签管理工具。 以前网站要接 Google Analytics、广告转化统计、在线客服挂件、A/B 测试脚本，每接一个就得改一次代码、发一次版。GTM 的做法是网站里只埋一段代码，之后要加什么第三方脚本，都在网页后台里配好再发布。 四个概念： 容器：埋在网站里的那段代码，全站只有一段 标签：要发的第三方代码，常见厂商都有现成模板 触发器：什么时候发，比如打开页面、点了某个按钮、提交表单、滚到页面某个位置 变量：发的时候带上的值，比如订单金额、商品 ID，一般由前端推给 GTM 好处是改一个广告转化统计不用再排研发的版本，从等一个迭代变成一小时。官方还提供预览调试、多人协作、测试环境和权限控制。基础版免费，企业版叫 Tag Manager 360，属于 Google Marketing Platform。 这几年的重点是服务端标签：把脚本执行从浏览器搬到自己的服务器上，绕开广告拦截和浏览器的隐私限制，同时能过滤往外发的数据。纯在浏览器里跑的标签，容易被拦截插件和浏览器隐私设置挡掉。 主要竞品 企业级： Tealium iQ，最常被拿来和 GTM 比，通常和它的客户数据平台 AudienceStream 一起卖，数据管理能力强 Adobe Experience Platform Tags（原名 Launch / DTM），用 Adobe 全家桶的客户基本默认用它 Ensighten、Commanders Act，偏欧洲市场和合规 隐私和自己部署： Matomo Tag Manager，开源免费，可以自己搭，对标 GTM Piwik PRO Tag Manager，面向 GDPR、金融医疗这类合规要求高的场景，可以私有部署 数据管道类，严格说不是同一品类，但常在同一次采购里被拿来比较： Segment（Twilio）、RudderStack、Snowplow、MetaRouter，采集一次，在服务端分发给各个下游，架构上能替掉大量标签 轻量和垂直方案： Stape、Addingwell，不替代 GTM，而是帮你托管 GTM 的服务端容器 Shopify、WordPress 里的各种像素插件，给不想碰 GTM 的小商家用 国内 GTM 加载可能不稳定，常见替代是神策、GrowingIO、火山引擎 DataFinder 这类埋点加分析一体的产品。它们把埋点和分析绑在一起，GTM 只管分发、不碰数据本身。 怎么选 只想少烦研发、免费用起来，GTM 基本没有对手。在意隐私合规、数据不想过 Google，看 Matomo 或 Piwik PRO。标签已经多到需要专门管理，或者要多渠道统一发数据，该看的是 Tealium 或者数据平台那一层，换一个标签管理工具解决不了。 --- # 让 AI Agent 帮你运营知识星球：官方 CLI 新版发布 URL: https://wlj.me/posts/zsxq-cli-agent-skill/ Published: 2026-08-19 Updated: 2026-08-19 Tags: AI, Startup, Tools经营一个知识星球，每天都有一串小事。 新主题要看，评论要回复，提问不能漏掉。内容积累多了，还要整理精华、标签和专栏。到了周末，可能还要做周报、挑选好内容、制作海报，提醒即将到期的成员续费。 每件事都不复杂，加在一起很占时间。 知识星球开放平台最近发布了新版本： zsxq-cli：0.5.0 zsxq-skill：2.1.0 MCP Service：近期功能更新 zsxq-cli 负责读取和操作知识星球，zsxq-skill 告诉 AI Agent 什么时候使用哪些能力。安装以后，星主可以直接用自然语言安排工作。 比如： 找出最近一周还没有回答的高质量提问，参考我过去写过的相关内容起草回答，先给我确认，明天上午十点发布。 Agent 会读取最近的提问，搜索星主过去发布的内容，整理回复草稿。星主确认以后，它再创建定时回答任务。 还可以这样说： 看看今天有哪些新内容、提问和评论需要处理。 整理最近的评论，找出还没有回复的问题。 从本周内容里挑选值得加精的主题，并建议标签。 把最近发布的主题收录到对应专栏。 做一份本周运营报告。 把今天的精选内容做成海报。 把一篇帖子做成竖版视频。 找出即将到期的成员，起草续费关怀内容。 这次更新还增加了普通主题、问答和投票主题，支持 Markdown 正文和 AI 创作声明。Agent 可以定时发帖、定时回答，查看、修改和取消定时任务，也可以设置主题精华和置顶，修改星球名称、简介、背景图和亮点图片。 在你的 Agent 里安装 知识星球 Skill 可以配合国内常见的 AI Agent 使用，包括 WorkBuddy、QoderWork、CodeBuddy、Qwen Code、Kimi Code CLI、MiniMax Code、TRAE、通义灵码等。Codex、Claude Code、Cursor 等工具也可以使用。 我们还做了一个知识星球花园，用来放知识星球和 AI 结合的新项目。这里可以查看 Skill 的能力、安装方法、离线安装包和开源代码。 让一千朵花先开。 安装不用自己研究命令。打开正在使用的 Agent，把下面这句话发给它： 帮我安装知识星球 Skill：https://garden.zsxq.com/skill/INSTALL.md Agent 会读取安装说明，检查环境，安装 zsxq-cli 和 zsxq Skill。 登录时，Agent 会给出一个授权链接和验证码。用户在浏览器或手机里确认授权，Agent 随后检查安装和登录状态。 AI 能访问哪些内容 CLI 使用用户自己的知识星球账号工作，访问范围不会超过这个账号原有的权限。 登录使用 OAuth 授权，Token 保存在系统 Keychain，不会直接显示在终端里。发帖、回复、回答提问、修改星球资料和删除内容等操作，Agent 会先展示目标和内容，得到确认后再执行。 星主可以决定自己的星球是否允许 AI 访问，也可以随时关闭权限。 安装完成以后，可以先对 Agent 说： 帮我做一次知识星球每日巡场，告诉我今天最需要处理的三件事。 --- # 新加坡的 OneService 是什么？ URL: https://wlj.me/posts/singapore-oneservice/ Published: 2026-08-18 Updated: 2026-08-18 Tags: Life, ToolsOneService 是新加坡国家发展部旗下 Municipal Services Office（MSO）提供的市政服务平台。 居民在社区里看到公共区域不清洁、道路或人行道损坏、路灯故障、树木、虫害等问题，不需要先判断该找 NEA、LTA、NParks、HDB 还是 Town Council。拍照、选择地点、描述问题后提交，OneService 会把 case 交给负责的政府部门或 Town Council，并在后续显示处理进度。 它目前有三个主要入口： OneService App：iOS 和 Android 都有，是最完整的入口。除了提交和追踪市政问题，还能报告违停、预订部分社区设施，以及查看附近的公共信息。 OneService Chatbot：通过 WhatsApp 或 Telegram 对话提交市政问题，不需要注册账号。违停目前仍要用 App 报告。 OneService 网站：提供说明、下载和服务入口，不是网页版 App。 OneService 可以理解为新加坡政府的统一市政工单入口：居民按问题提交，系统负责找到对应部门。 它不处理紧急事件。遇到人身、财产或公共安全的即时危险，仍要直接联系相应的紧急服务或政府部门。 以上信息核对至 2026 年 8 月 18 日。 --- # 人生七年：拍了五十五年的纪录片 URL: https://wlj.me/posts/the-up-series/ Published: 2026-08-17 Updated: 2026-08-17 Tags: Movie1964 年，英国 Granada 电视台为时政栏目 World in Action 做了一期特别节目 Seven Up!，找来 14 个七岁的孩子，问他们怎么看学校、钱、婚姻和阶级。节目想验证一句耶稣会格言——「把一个孩子交给我到七岁，我还你一个成年人」：英国的阶级结构是否强大到人生道路在出生时就已注定。 原本是一次性节目。从第二部 7 Plus Seven（1970）起，当年参与挑人的研究员 Michael Apted 接手执导，每七年回访一次，一直拍到 2019 年的 63 Up，共九部。Apted 2021 年去世；70 Up 定于 2026 年 9 月播出，由 Asif Kapadia 执导，系列就此收官。 五十五年下来，阶级决定论在大多数人身上成立：肯辛顿预备学校的三个男孩按 7 岁时自己报出的路线上了牛津剑桥，进了法律界；东区和儿童之家的孩子大都留在原来的阶层。例外也有——东区出身的 Tony，从骑师梦到出租车司机再到群演，明显向中产移动。节目也被参与者当面清算过：Apted 承认只选 4 个女孩是错误；Jackie 在 49 Up 里质问他，为什么问她的总是婚姻和男人，而不是这个国家怎么了。 Roger Ebert 把这个系列列入自己的影史十佳。2024 年英国广播记者协会评选近 50 年最有影响力的节目，它排第一。 我让 AI 逐条核了一遍事实，把 14 位参与者的出身和各阶段轨迹整理成一页人物志：出身×九部对比总表，加每人一张完整卡片，谁哪一部缺席、谁中途退出又回归都标了出来。放在这里：人生七年 · 人物志。 --- # 在手机上用自己电脑里的 AI Agent URL: https://wlj.me/posts/phone-access-local-ai-agent-tailscale/ Published: 2026-08-14 Updated: 2026-08-14 Tags: Tools, Tech, AIDeepSeek 开源了自己的 agent harness，叫 dsh。装上跑一条命令就能用： npx @deepseek-ai/dsh web 它没有终端界面，只有浏览器 UI，默认起在 http://127.0.0.1:3080。我想在手机上也能用——躺着的时候给它派个活，回到电脑前看结果。 不要直接开放到局域网 第一反应是把它绑到 0.0.0.0，手机连同一个 wifi 就能访问。dsh 直接拒绝了这个参数，报错写得很直白： --host 0.0.0.0 is intentionally not supported yet for safety: it would expose remote code execution to the network 这不是没做完，是故意堵死的。这类 agent 能跑 shell、能读写你整个文件系统，而它目前没有任何用户认证。裸奔在局域网上，等于把电脑的 shell 交给任何连了你 wifi 的人。 用 Tailscale 反代 正确的做法是：程序继续只绑本地回环，前面放一层带认证的代理。Tailscale 正好干这个。 # 1. 启动，同时声明信任的域名 dsh web --trusted-host 你的机器名.你的tailnet.ts.net # 2. Tailscale 在前面反代 tailscale serve --bg 3080 完事。手机连上 Tailscale，打开 https://你的机器名.你的tailnet.ts.net/ 就能用，自带 HTTPS 和设备级认证，家里 wifi 上什么都没暴露。 注意别用 tailscale funnel——那是把服务放到公网，对这种东西是灾难。serve 只在自己的 tailnet 内可见。 两个必须知道的坑 第一，--trusted-host 不是可选项。 dsh 的 API 有一道防 DNS rebinding 的栅栏：每个请求的 Host 头必须是本地回环，或者在信任名单里，否则一律 403。这个设计是对的——攻击者能骗你的浏览器发请求，但伪造不了 Host 头。 反代过来的请求 Host 是那个 tailnet 域名，不声明就全被拦。我一开始没加，页面能打开，一交互就报错。 第二，手机上改不了设置和 API key。 dsh 把这几个高危操作永久钉在本地回环，信任名单也放行不了： 读写设置 设置和删除 API key 调用系统的文件选择器 读取和管理 agent 预设 代码注释里的原话是「until a real authentication layer exists」。所以顺序是：先在电脑上配好 API key 和工作目录，手机再连上去开会话。日常用没影响——发消息、看结果、审批工具调用都正常。 让它常驻 每次手动起太麻烦，写个 launchd 配置放 ~/Library/LaunchAgents/： <key>ProgramArguments</key> <array> <string>/opt/homebrew/bin/node</string> <string>/Users/你的用户名/.local/dsh/node_modules/@deepseek-ai/dsh/lib/bin.js</string> <string>web</string> <string>--trusted-host</string> <string>你的机器名.你的tailnet.ts.net</string> </array> <key>EnvironmentVariables</key> <dict> <key>PATH</key> <string>/Users/你的用户名/.local/bin:/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string> </dict> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <dict><key>SuccessfulExit</key><false/></dict> launchctl bootstrap gui/$UID ~/Library/LaunchAgents/com.deepseek.dsh-web.plist 两个地方容易翻车： 必须写 node 的绝对路径。 脚本开头是 #!/usr/bin/env node，而 launchd 的 PATH 是最小集，找不到 node。 必须显式注入 PATH。 这条更隐蔽——agent 的 bash 工具继承的就是这个 PATH。不写的话它跑命令时会发现 git、rg、python 全都不存在，症状很怪，排查半天。 Tailscale serve 的配置本身是持久的，重启电脑不用管。 这套思路不限于 dsh 任何「只绑本地、没有认证、但你想远程用」的自建服务都适用：本地回环 + Tailscale serve + 声明信任域名。比开端口映射、比公网加密码，都更省事也更安全。 --- # AI 抹平信息差之后，知识星球怎么改产品 URL: https://wlj.me/posts/zsxq-product-evolution-ai/ Published: 2026-08-09 Updated: 2026-08-09 Tags: AI, Community, ProductAI 让信息不值钱了。星球上靠「我知道你不知道」收费的模式会塌，靠「你信我这个人」的模式会更强。产品怎么改，还是往人靠、往社区靠、往工具靠这三个方向。 往人靠，核心是让创作者更真。现在打开一个星球，只看到一堆帖子和一个头像。这个人靠不靠谱、什么风格、能跟多久，没有答案。可以在主页上展示他在这里几年了、回答过多少问题、成员续费率多高。信任需要时间，时间需要被看见。再进一步，把创作者说过的判断和后来的结果对照出来，错了就认的记录比一百篇对的文章更有说服力。 Substack 的做法可以参考。它的创作者主页很干净，一个大头像、一段简介、所有文章和 notes 按时间排列。它的推荐算法优化目标是订阅和付费转化，不优化停留时长。平台在帮用户找「值得长期关注的人」。方向跟知识星球想要的一致。 OnlyFans 的用户付费，很多图的是创作者直接跟你聊天、记住你的名字。平台把聊天做成了第一大功能，也是第一大付费驱动力。国内环境不同，但用户愿意为「这个人看见我了」付钱，这个道理通用。 往社区靠，核心是让成员从围观变成参与。多数星球是星主讲、大家听。可以先做两件事：让成员之间有发现彼此的机制，轻匹配一下就够了；降低第一次互动的门槛，比如增加一个「有启发」的反馈按钮，比赞更具体。点了之后星主能看到，可能顺手回一句。破冰了，人和人的距离就近了。 Substack 的 Chat 功能是付费订户专属的深层讨论，和公开的 Notes 分开。Discord 的频道分角色、分权限，成员进来之后有一个清晰的路径：先围观、再发言、最后变成参与者。知识星球目前缺的就是这条路径。 小红书有一个设计值得看：算法会把旧内容推给新用户，不只看发布时间。星球里大量好帖子几周就沉了，如果平台主动把老内容推给新成员，星主不用每天生产新东西，内容自己就有生命力。这比逼着星主日更可持续得多。 往工具靠，核心是 AI 干活、人做决定。AI 该做的：帮星主整理内容、发现值得回复的问题、提示哪些成员很久没互动了；帮沉睡的好内容再流通，用户提一个具体问题，AI 从历史帖子里找相关的内容，星主确认后推送；帮新人快速找到同好和值得先看的东西。AI 不能做的只有一件：以星主的口吻说话。宁可在功能上标注「AI 整理的参考」，也不要去模糊这条线。 Discord 开放 API 让 Midjourney 在它上面搭出了完整的产品——生成图片、管理队列、支付结算，Midjourney 没有自己做 app。知识星球也可以把能力开放出去，让外部开发者甚至成员自己搭出新玩法。笔记 914 写的「让一千朵花先开」，就是这个意思。 三个方向背后是同一个问题：这个功能做完，星球里的信任变多了还是变少了。变少了就砍。 --- # AI 时代，知识星球还提供什么 URL: https://wlj.me/posts/zsxq-good-community/ Published: 2026-08-09 Updated: 2026-08-09 Tags: AI, Community, Startup前些天脑子里冒出一句话：「人类的美好社区」。 越想越觉得它对。AI 写文章、做视频、画图，成本在快速降低。内容会越来越不值钱，真人、关系和社区反而越来越贵。知识星球做了十年，一直希望用户因信息和资源而来，最后因人和社区留下。 但「美好社区」到底是什么意思？试着往下想。 知识星球上的「美好」，我更愿意理解成信任。创作者和用户之间、用户和用户之间，长期积累下来的信任。一个星球经营久了，成员之间积累下来的不是信息量，是一起经历过的事。AI 能提供无限量的内容，但不能提供信任。AI 能给答案，但不会跟人一起熬过一件事。 怎么跟团队讲清楚？可以用一个简单的问题，每次讨论功能的时候问一下：这个东西做完了，星球里的信任是变多了，还是变少了。变少了就不做。 反过来想，更容易看清楚。一篇 AI 生成的帖子混在星主的真实内容里，没人发现，这个社区就烂了一个角。十个帖子没人发现，烂了一片。AI 假装星主回复、批量制造内容刷存在感、让成员只看摘要不再交谈——每做一件，人味就淡一层。 不是说不能用 AI。用 AI 帮星主整理内容、发现好问题、减轻管理负担，这些反而增加信任。关键是用的时候心里有没有那条线：谁是主体，谁在经营这些关系。 「人类的美好社区」是个想去的地方。不用急着把它写成使命。放在心里，每次犹豫的时候想想：在做的这件事，跟那个方向是不是同一条路。 --- # 极简主义：把注意力留给真正愉悦的事 URL: https://wlj.me/posts/minimalist-joy-not-less/ Published: 2026-08-09 Updated: 2026-08-09 Tags: Reading看到 minimalist 这个词，我开始想极简主义到底在追求什么。围绕极简主义的很多做法都在追求「少」：少买东西、少留几件衣服、少装几个 App，把家里清理得空空荡荡。 但多出来的东西不会安静待着。物品要整理，信息要判断，App 要查看，各种事情都需要回应。它们不断提出细小的要求，抢占注意力，也把时间切成碎片。等到想做自己喜欢的事，完整的时间和心力已经耗掉了。 注意力特别珍贵。一个人的注意力放在哪里，生活就由什么构成。刷两个小时手机，这段时间就成了信息流；陪家人、阅读或运动两个小时，这段时间就成了另一种生活。每一种「多」都在挤占其他可能。 我现在的理解是，动手减少之前，得先想清楚哪些事会让自己真正愉悦。 对我来说，是与家人共处、阅读、欣赏影片、运动。这些事确定下来，才知道注意力应该流向哪里，也有了判断其他东西该不该留下的标准。 有了这个内核，减少会自然发生。关通知、删 App、少买东西、清理房间，都在给这些事腾出时间和注意力。无关的东西会越来越少，因为生活里已经有了更愿意投入的事。 极简主义最后呈现出来的是少，内核是先找到真正愉悦的事，再为它清理道路。 --- # 四份网络安全报告的中文阅读辅助 URL: https://wlj.me/posts/cyber-reports-reading-aids/ Published: 2026-08-09 Updated: 2026-08-09 Tags: Reading四份和网络安全相关的英文研究报告，各自有各自的切口，放在一起读更有意思： 《Before Vegas》（Eugenio Benincasa, ETH Zürich CSS, 2025）追踪了 1990 年代末八个中国红客组织的约 200 名核心成员——他们怎么从论坛少年变成网络安全产业创始人，以及部分人怎么进入 APT 生态。报告把最有影响力的 40 人称为「红 40」。 《Crash (exploit) and burn》（Winnona DeSombre Bernsen, Atlantic Council, 2025）是第一份对 0day 漏洞供应链做中美对照的研究。核心判断：全球能稳定产出 0day 的人只有低三位数，中美抢这拨人的方式完全不同。 《Mobilizing Cyber Power》（Kieran Green, Margin Research, 2025）是 2015 年以来第一份系统研究中国网络民兵的报告，分析了 136 支具体单位。从高校招募到民企嵌入，从通信保障到网络战。 《Mythical Beasts》（Jen Roberts、Trey Herr 等, Atlantic Council, 2024）是第一份对全球商业间谍软件市场做实体网络测绘的研究——435 个实体、42 个国家、近三十年。 每份报告我都做了中文阅读辅助页：不是翻译，是梳理结构、提炼论点、标注局限和跨报告核对。 Before Vegas Crash (exploit) and burn Mobilizing Cyber Power Mythical Beasts --- # 淡马锡 2026 年报速读 URL: https://wlj.me/posts/temasek-review-2026-reading-aid/ Published: 2026-08-09 Updated: 2026-08-09 Tags: Reading淡马锡的年度报告《Temasek Review 2026》，财年截至 2026 年 3 月 31 日。几个重点： 净投资组合 S$518b，一年回报 10.5%（新元口径）。 今年做了三个结构性变化：估值口径全面转向市值计价、组织一拆三（新加坡 / 全球直投 / 伙伴基金分开管）、第五任主席张志贤上任。 组合结构 43/38/19（新加坡组合公司 / 全球直投 / 伙伴基金资管）从 2018 年起基本稳定。 十年回报被 2021–2024 中国市场压低，五年 TSR 只有 4.6%。 做了份中文速读页，按 12 个小节拆开原报告的 143 页。 打开速读 --- # 《Science: A New Golden Age》 URL: https://wlj.me/posts/science-new-golden-age-reading-aid/ Published: 2026-08-09 Updated: 2026-08-09 Tags: Reading这是 2026 年 7 月白宫科技政策办公室（OSTP）主任 Michael Kratsios 提交给特朗普的报告，对标 Vannevar Bush 1945 年的《Science: The Endless Frontier》——那份报告塑造了此后 80 年美国科研体制。 报告的核心判断：科研体制是 1945 年设计的，资金格局、科学的组织方式、地缘竞争、AI 全都变了。投入持续上涨，重大突破却在放缓。它开出五章药方：投资科学家个体优先于在位机构、重造拨款方式、设定国家目标重建产业、用 AI 改造科研基础设施。 我做了份中文阅读指南，包含逐章精读、关键数据速查、术语表、人物索引、时间线，以及判断这份报告「哪些会真发生」的线索。 打开指南 --- # 三本关于「少」的书 URL: https://wlj.me/posts/three-books-on-less/ Published: 2026-08-09 Updated: 2026-08-09 Tags: Reading三本讲怎么减少东西的书，方向完全不同： 《The Longing for Less》（Kyle Chayka）不是教你扔东西的，是追问「minimalism」这个词怎么从 1960 年代纽约的前卫艺术变成 Instagram 上一千三百万条标签的。 《Digital Minimalism》（Cal Newport）是《深度工作》的下半场，讲下班时间怎么不被屏幕吃掉。核心主张：先建高质量闲暇，再砍低质量分心。 《Decluttering at the Speed of Life》（Dana K. White）是纯操作手册。作者自称「天生邋遢」，核心是五步法和一个认知转变——你家是容器，容器的用途是限制而不是盛放。 三份中文阅读辅助都做好了： The Longing for Less 阅读指南 Digital Minimalism 阅读指南 Decluttering at the Speed of Life 操作指南 --- # 《周易》经传十五讲学习指南 URL: https://wlj.me/posts/zhouyi-reading-guide/ Published: 2026-08-09 Updated: 2026-08-09 Tags: Reading廖名春的《〈周易〉经传十五讲》是北大「名家通识讲座书系」里评价很高的一本。他的方法是出土文献（帛书、楚简）和传世文献互证，把很多传统解释往回推了一层。 我让 AI 做了一份学习指南，包含：十五讲逐讲要点、八卦速查表（含作者对卦名的考源）、六十四卦一览（逐卦一句话概括）、卦序规律（「二二相耦，非覆即变」）。 打开指南 --- # 《The Power Broker》速查 URL: https://wlj.me/posts/the-power-broker-reading-aid/ Published: 2026-08-09 Updated: 2026-08-09 Tags: ReadingRobert Caro 的《The Power Broker》得了普利策奖，写的是 Robert Moses——一个没当过民选官员的人，靠掌控纽约的桥梁、隧道、公园管理局，用 44 年时间物理上重塑了这座城市。 这本书 1200 页，英文。我用 AI 做了一份中文速查页，包含：Moses 的权力增长图表、五十章逐章概述、人物索引（按阵营标色）、年表，以及卡罗和摩西本人的隔空交锋。 打开速查 --- # Hedy 不开源，有哪些开源 AI 听课助手？ URL: https://wlj.me/posts/open-source-ai-listening-assistants/ Published: 2026-08-09 Updated: 2026-08-09 Tags: AI, Tools, Education需求很明确。 工具要在 Mac 上同时听到电脑声音和麦克风，边听边显示逐字稿。讲师提到新概念、数字或者值得怀疑的判断时，AI 能主动补充解释、联网查证、提出反例，也能结合提前提供的个人资料给出提示。课程结束后，再把录音、逐字稿和笔记存下来。 重点放在课程进行中的实时提示：AI 跟着一起听，及时提醒哪里值得多想一步。会后转写和总结工具不在这次比较范围内。 Hedy 已经覆盖实时转写和自动建议等主要功能，但它是商业闭源产品。本文把它作为参照，再检查三个开源项目：Raven、Anarlog 和 Meetily。 以下信息截至 2026 年 8 月 8 日，来自产品官网、文档和公开源码。本文没有一小时中文课程的实测数据，无法比较实时识别准确率和延迟。 Hedy：商业闭源的参照 Hedy 能实时转写谈话，根据不同场景给出自动建议，还提供面向学生的课程模式。用户可以配置 Session Context，让 AI 预先知道个人背景、目标和词汇。 它的免费版每月 5 小时，每次 Session 的实时建议只覆盖前 30 分钟。Pro 版月付 12.99 美元，年付 99.99 美元，还有 299 美元的终身版。 Hedy 没有开放客户端源码。使用条款把软件、算法和设计列为公司专有资产，并明确禁止反编译、反汇编和尝试推导源码。 Hedy 提供 REST API 和 Webhook，但它们主要用于把 Session 结果接到其他工具。官方集成文档列出的实时事件包括 suggestion.created，可以收到 Hedy 已经生成的建议；包含完整逐字稿的 session.ended 在 Session 结束后触发。官方集成文档未列出可供外部程序消费的实时逐字稿流，也没有说明自动建议会在课程中联网查证。 Hedy 可以直接用来验证自动提示是否有用。它没有开放源码，无法在客户端基础上继续改造。 Raven：已有会中 AI 悬浮层 Raven 使用 MIT 许可证，支持 macOS 和 Windows。它同时采集系统音频和麦克风，在本机完成回声消除，再把两路音频分别交给 Deepgram 实时转写。 它已经具备多项相关功能： 实时显示双方逐字稿，支持中文 始终置顶的悬浮层，不会出现在 Zoom、Meet、Teams 和 Discord 的屏幕共享里 Learning 模式，可以设置专门的系统提示 可以上传 PDF、Word、Markdown 和纯文本，本地建立索引，在回答时引用 可以把屏幕截图和当前逐字稿一起发给 Claude 或 GPT Raven 的 AI 需要手动触发。用户点击 Assist、What should I say、Follow-up、Recap，或者自己输入问题，AI 才会读取当前逐字稿并回答。截至本文检查的版本，公开源码里未见定时分析逐字稿、自动生成提示卡的程序，也未见 Web Search 工具。 开源版需要自己提供 Deepgram 和 Anthropic 或 OpenAI 的 API Key。Raven 为麦克风和系统音频各开一条 Deepgram 连接。按 Deepgram 当前按量付费的限时流式价格，并假设两条连接连续运行一小时，Nova-3 单语转写约 0.58 美元，多语模式约 0.70 美元。这是按公开单价做的推算，不包含大模型费用。 要做一个 Hedy 风格的开源版本，本文检查的 Raven 公开版未见自动触发和带来源的网页查证。它已经实现双路音频、实时逐字稿、悬浮层和本地文档检索。 Anarlog：本地模型和本地存储 Anarlog 也是 MIT 许可证，前身叫 Hyprnote，是一个开源的 Granola 替代品。它可以录制系统音频和麦克风，把会议资料保存在本地 SQLite 数据库，支持导出 Markdown。 在 Apple Silicon Mac 上，Anarlog 可以下载本地转写模型。摘要和聊天可以连接 Ollama 或 LM Studio，因此录音、转写、总结和问答都能留在自己的电脑上。能否在会议中显示实时文字，取决于选择的模型，设置中标为 Live 的模型才支持。 Anarlog 的聊天已经能读取当前和历史会议，也有 Web Search 工具。不过公开源码里的 Web Search要求用户登录，再调用 Anarlog 的 /research/search 服务。这项网页搜索依赖网络和 Anarlog 官方服务。 官方文档主要围绕录音、备忘、逐字稿、总结和会后聊天，未列出会议中主动生成建议的功能。改造成实时听课助手，还要增加自动触发程序和提示卡界面。 Meetily：本地转写和会后总结 Meetily 使用 MIT 许可证，主体是 Tauri、Rust 和 Next.js。它能同时录制系统音频和麦克风，使用本地 Whisper 或 Parakeet 实时转写，并用 Ollama、Claude、Groq、OpenRouter 或兼容 OpenAI 的接口生成总结。 Meetily 的录音、模型、逐字稿和总结都可以保存在本机。使用 Ollama 时，总结也能在本机完成；选择 Claude、Groq 或 OpenRouter 时，生成总结所需的文本会发送给相应服务。macOS 已经提供 Apple Silicon 安装包，不需要自己编译整个项目。 它的官方 README 和架构文档没有列出会议中的 AI 对话、个人资料检索、自动建议或者网页搜索。公开架构只把大模型列在 Summary Engine 中，未列出会中 AI 交互。 Meetily 已经覆盖本地录音、实时文字和会后总结。要做会中实时助手，需要另外加入 AI 交互层。 放在一起比较 项目 许可证 系统音频 实时逐字稿 会议中 AI 自动建议 网页搜索 本地转写 额外上下文 Hedy 闭源 支持 支持 支持 支持 未见会中查证 官方称支持设备端识别 Session Context Raven MIT 支持 支持 手动触发 公开版未见 公开版未见 使用 Deepgram 本地文档检索 Anarlog MIT 支持 取决于模型 支持聊天 文档未列出 依赖官方服务 Apple Silicon 支持 当前及历史会议 Meetily MIT 支持 支持 文档未列出会中 AI 文档未列出 文档未列出 Whisper、Parakeet 文档未列出 Hedy 可以直接试自动提示，但不开源，每次免费实时建议限 30 分钟。Raven 已有双路音频、实时转写、会中手动 AI、悬浮层和文档检索，本文检查的公开版未见自动触发与网页查证。Anarlog 支持本地转写、本地模型和本地存储，还要补实时提示交互。Meetily 覆盖本地录音、实时文字和会后总结，公开资料未列出会中 AI。 按功能缺口看，Raven 是更直接的改造起点。不过本文没有中文课程实测和开发量评估，还不能判断哪条路线的总成本最低。准确率、延迟、提示频率和干扰程度也都没有实测数据。 资料来源 Hedy Pricing Hedy Features Hedy Terms of Use Hedy Integrations Raven GitHub Raven Documentation Anarlog GitHub Anarlog Documentation Meetily GitHub Deepgram Pricing --- # 让 Mac 保持清醒：caffeinate URL: https://wlj.me/posts/caffeinate-keep-mac-awake/ Published: 2026-07-15 Updated: 2026-07-15 Tags: Tools, TechmacOS 自带一个命令，caffeinate，给机器灌咖啡，不让它睡。跑长任务、下载大文件的时候用，不用去系统设置里改电源选项。 caffeinate 运行后 Mac 不睡眠。Ctrl+C 退出，恢复正常。 常用参数 屏幕常亮： caffeinate -d 默认只防系统睡眠，屏幕照样熄。加 -d，屏幕也一起保持。 限时，单位是秒： caffeinate -t 7200 两小时后自动失效，不用手动关。 跟着任务走： caffeinate -i ./backup.sh 任务跑多久，机器醒多久。任务结束，自动恢复。 合盖 管不了。caffeinate 挡的是空闲睡眠，合盖触发的是另一套强制睡眠，合上照样睡。 接了外接屏、电源和键鼠，macOS 本身就支持合盖运行，不用任何命令，这是官方的 clamshell 模式。 没有外接屏，还想合盖继续跑： sudo pmset -a disablesleep 1 设置重启后还在。用完改回 0，否则 Mac 塞进包里也不睡，发热耗电。 怕忘关，套一层自动恢复： sudo sh -c 'pmset -a disablesleep 1; trap "pmset -a disablesleep 0" INT TERM EXIT; sleep 28800' 合盖不睡 8 小时。到点、Ctrl+C、关终端，都会自动恢复睡眠。把 sleep 28800 换成任务本身，就是合盖版的 caffeinate -i。 查当前状态： pmset -g | grep SleepDisabled 1 是不睡，0 是正常。 --- # ntfy.sh 是什么 URL: https://wlj.me/posts/20260611-ntfy-sh/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Tech, Toolsntfy.sh 是一个很轻的通知服务。手机或电脑先订阅一个 topic，你的服务器、脚本、监控工具或任何程序，只要向 https://ntfy.sh/你的-topic 发一个 HTTP 请求，这条消息就会变成推送通知弹出来。 它适合做小而确定的提醒：备份失败、网站挂了、长任务跑完、家里传感器触发。最简单的用法只有一行： curl -d "Backup failed" https://ntfy.sh/my-secret-topic ntfy 是开源项目，可以直接用官方服务，也可以自己部署。默认不需要注册，所以 topic 名字本身就像密码，要取一个不容易被猜到的名字。敏感信息不要随手发到公共服务上。 官网：https://ntfy.sh/ GitHub：https://github.com/binwiederhier/ntfy --- # Mac 远程桌面：看的是同一个画面 URL: https://wlj.me/posts/mac-remote-desktop-shared-screen/ Published: 2026-06-09 Updated: 2026-06-09 Tags: Tech, Tools今天我在外面，远程连回我的电脑操作。同事经过，看到那台电脑居然没锁屏——屏幕亮着，鼠标自己在动，窗口一个个开。我才去了解了 Mac 远程桌面是怎么回事。 打开 Mac 的「屏幕共享」连上另一台 Mac，你看到的就是那台机器此刻的屏幕，和坐在它面前的人看到的完全一样。它当下显示什么，你这边就显示什么。我在外面操作，那台电脑的屏幕就同步显示我的每一步——同事看到的"没锁屏"，就是我远程操作的实时画面。 你动鼠标，那台 Mac 屏幕上的鼠标也跟着动；你打字，字就落在它的屏幕上。坐在电脑前的人能实时看到你点了哪里、开了哪个窗口、敲了什么，像看直播。 控制权是两人共享的。你能动，坐在跟前的人也能动。要是同事这时顺手去推那台电脑的鼠标，就会和我远程的操作抢起来——光标在屏幕上跳来跳去，谁都使不顺。想配合，得有人先松手。 远程桌面连过去，是两个人共用同一块屏幕、同一套鼠标键盘。人没在跟前，用的还是那台真机。 --- # BoldVoice：一年 150 美元的口音教练 URL: https://wlj.me/posts/boldvoice-accent-coach/ Published: 2026-06-08 Updated: 2026-06-08 Tags: AI, Startup, Product真人口音教练在美国一小时收 200 到 300 美元。BoldVoice 用 AI 接掉了听发音、挑错这部分，真人教练只录课、做一对一。订阅一年 150 美元，用户在 150 多个国家。公司 7 个人，年收入超过 1000 万美元。 是什么 创始人 Anada Lakra 和 Ilya Usorov，YC 2021 年夏季批次，公司在纽约。 App 里的课是好莱坞口音教练录的，这些人平时教演员说各地方言和口音。你跟着读，AI 当场告诉你哪个辅音、哪个元音没发对，准到单个音。每天练什么，看你的母语，也看你的目标是面试还是日常社交。 到 2026 年 1 月，下载超过 500 万次。同月 BoldVoice 拿了 2100 万美元 A 轮，Matrix 领投，累计融资 2710 万。 解决谁的什么问题 用户是已经能用英语工作、但口音拖累表达的人。专业能力不缺，说出来别人得费劲才听懂，或者自己开口心里没底。 以前这个问题只能花钱请真人教练，贵，还得约时间。看 YouTube 不要钱，可没人听你说，也没人告诉你错在哪。BoldVoice 卡在中间：随时能练，每句话都有反馈，一年的钱不够真人教练一个小时。 公司把目标定在让人说清楚、够用就行，不去追消除口音、说得跟母语者一样。 独特价值 别的发音 App 大多是纯 AI，给你打个分数。BoldVoice 的课是好莱坞口音教练录的，他们懂怎么把一个总也发不对某个音的人，一步步带到能发对。这套本事来自给演员做训练，写算法写不出来。 AI 在这里只做反馈，内容归教练。价格也照这个分：AI 课月付 25 美元、年付 150 美元；真人一对一单次 119 到 450 美元，按教练资历定价。 护城河 BoldVoice 的语音识别和发音打分不难复制，微软 Azure、ELSA 都有现成的同类技术。它那个传过一阵的小工具 Accent Oracle——上传一段语音，AI 猜你母语是哪国的——竞品想抄也快。定价同样抄得走。 难复制的是教练和数据。顶尖的好莱坞口音教练就那么些人，BoldVoice 把课签下来，别人得先找到同一批人。还有 5 年、500 多万次下载攒下的非母语者发音样本，这是训练那套即时反馈模型的料，用的人越多模型越准，后来者没有这个底子。口碑再添一层：App Store 高评分，WIRED 和 Business Insider 报道过，这些花钱买不快。 A 轮这 2100 万美元要去两个地方：企业客户，和英语以外的语种。这两处现在的护城河用不上。西班牙语、法语得重新找教练、重新攒数据；卖给企业按人头收费、走采购流程，跟现在直接卖给个人是两码事。英语个人市场 BoldVoice 站稳了，新战场能不能复制，现在还看不出来。 --- # OSCAR：看 CPAP 真实在做什么 URL: https://wlj.me/posts/oscar-cpap-data-analysis/ Published: 2026-05-28 Updated: 2026-05-28 Tags: Life, AI, Tools之前那篇 Apple Watch 数据分析说过，Apple Watch 推断的"夜间呼吸异常事件"不准。要看 CPAP 真实效果只能看机器本身的 SD 卡——那里有每一晚每两秒采样的数据。 把 SD 卡从呼吸机里拔出来插到电脑上，里面有个 DATALOG 文件夹，按日期一晚一个子目录。导出来扔给 Claude 跑脚本，14 晚的数据 30 秒就出来了。 下面分开说：CPAP 是什么、OSCAR 是什么、SD 卡里有什么文件、这些数据能算出什么、我自己最近两周的情况。 CPAP 是什么 Continuous Positive Airway Pressure，持续气道正压通气。一台小机器，靠管子和面罩把空气持续吹进鼻腔，用正压撑开睡觉时容易塌掉的上气道。专门治阻塞性睡眠呼吸暂停（OSA，Obstructive Sleep Apnea）。 OSA 的机制：睡着后喉咙后面的软组织松弛塌下来，把气道堵住，呼吸短暂停。停几秒大脑缺氧自动惊醒一下，气道打开，又睡着，几分钟后再来一次。一晚循环几十上百次，自己感觉不到。 CPAP 不吃药、不开刀，靠空气压力机械上不让气道塌。 我用的是 ResMed AirSense 10，自动调压（AutoSet）模式——机器实时检测气道塌陷的程度，自动在 5-15 cmH₂O 范围内调整压力。 OSCAR 是什么 Open Source CPAP Analysis Reporter。开源软件，Mac/Windows/Linux 都能装。专门解析 ResMed、Philips DreamStation、Fisher & Paykel 这几家主流厂商 CPAP 机器 SD 卡的数据。 呼吸机厂商通常有自家 App（ResMed 的 myAir、Philips 的 DreamMapper），但只给摘要：昨晚 AHI 多少、漏气是否合格、星星几颗。 OSCAR 直接读底层 EDF 文件，能看到每一晚每两秒的漏气、压力、流量限制、潮气量、呼吸频率，以及每一个被检测出来的呼吸暂停或低通气事件。还能画图，把 5 个小时的数据铺成一张大图。 想自己看清楚 CPAP 在替你做什么，OSCAR 是唯一选择。 SD 卡里有什么文件 我这台 ResMed AirSense 10 的 SD 卡，DATALOG 文件夹按日期分子目录，比如 20260513/、20260514/。每一晚的文件夹里有 5 个 EDF 文件（European Data Format，医学数据通用格式）： CSL.edf — Compliance Session List。当晚开机/关机时间戳。 EVE.edf — Events。呼吸事件：Apnea（完全暂停）、Hypopnea（低通气）、FlowLimit（流量限制）、RERA（呼吸努力相关觉醒）。每个事件带时间戳和持续时长。 BRP.edf — Breath-Rate Pressure。25Hz 高频采样，气流和压力波形。文件最大，单晚 2-3 MB。 PLD.edf — Per Lap Data，按 2 秒间隔采样的关键指标： MaskPress（面罩实际压力） Press（设定压力） EprPress（EPR 调整后压力） Leak（漏气量，L/s 单位） RespRate（呼吸频率） TidVol（潮气量） MinVent（每分钟通气量） Snore（鼾声强度） FlowLim（流量限制指数） SAD.edf — Summary And Data。如果接了外置血氧模块，里面有 SpO2 和脉搏。我没接，所以全是 -1。 每个 EDF 还有一个同名 .crc 校验文件，保证数据没在 SD 卡上损坏。 这些数据能算出什么 核心指标是 AHI（Apnea-Hypopnea Index，呼吸暂停低通气指数）。每小时睡眠里发生多少次： Apnea：气流完全停止 ≥ 10 秒 Hypopnea：气流减少 ≥ 30% 同时血氧下降 ≥ 3% OSCAR 数 EVE.edf 里的事件总数，除以使用时长。 AHI ≥ 5 是 OSA 诊断阈值 AHI < 5 是治疗成功 AHI < 1 是极优 第二重要的是漏气： 取 PLD.edf 的 Leak 通道（L/s）× 60 → L/min 计算 95% 分位数（P95） ResMed 警戒线 24 L/min P95 漏气太高 = 面罩没戴好，治疗压力会被泄掉，AHI 会随之上升 还能看： 治疗压力的均值和 95% 分位（你的机器实际跑到多高） 鼾声指数（低通气前的预警） 流量限制指数（气道开始变窄但还没塌） 使用时长是否够（≥ 4h/晚算"合规"） 我自己的两周 5/13 启用 CPAP，到现在戴了两周多。14 个夜分成三类： 完整戴的 10 晚（≥ 5h）：5/13-16、5/19-22、5/25-26 开机即摘 2 晚：5/18 戴了 4.97 分钟，5/24 戴了 3 分钟（疫苗那天） 完全没戴 2 晚：5/17、5/23 10 个完整夜的关键数据： 指标 我的值 临床目标 AHI 0.10 < 5 优，< 1 极优 使用时长 7.15h/晚 ≥ 4h 漏气 P95 21 L/min < 24 治疗压力均值 9.98 cmH₂O < 15（我设的上限） AHI 0.10 接近零，相当于平均每 10 小时才有 1 个事件。机器把我的 OSA 基本消除掉了。 治疗压力只跑到 9.98 cmH₂O（最高 11.88），离我设的上限 15 还很远。我的 OSA 严重度本身不重——气道塌得不深，10 cmH₂O 就撑得住。 一个孤立高值：5/19 那晚漏气 P95 飙到 36 L/min，远超 24 警戒线。其他 9 晚都 < 26。但那晚 AHI 仍是 0——单晚漏气偏高没毁掉治疗效果。 OSCAR 比 Apple Watch 准多少 用 Apple Watch 数据做了次对照实验：戴 CPAP 的 8 晚 vs 同一周没戴 CPAP 的 3 晚（控制组），Apple Watch 推断的"呼吸异常事件"两组数字几乎一样——1.38 vs 1.39 次/小时。它不知道我戴了 CPAP 没。 而 CPAP 自己记的 AHI，戴的夜是 0.10，没戴的夜按之前估算在 5+。差 50 倍。 判断 CPAP 治疗效果，看 OSCAR，不是 Apple Watch。 下一步 把 EPR 从 3 降到 2，看主观舒适度有没有改善 6/8 满 4 周再跑一次完整对比 --- # Apple Watch 九年数据让我盯上三件事 URL: https://wlj.me/posts/ai-analyze-apple-watch-data/ Published: 2026-05-27 Updated: 2026-05-27 Tags: Life, AI, Tools断断续续带了几块不同的表，数据都在苹果手机里。 五月初我把数据导出来扔给 Claude，让它跑 Python 脚本逐项分析。三件事最值得管： 阻塞性睡眠呼吸暂停（OSA），要重新用 CPAP 呼吸机 HRV 偏低 VO2max 这一年在跌 下面分开说。 数据怎么来 苹果手机的「健康」app 里有「导出健康数据」按钮，生成一个 zip。解压后是一个 export.xml 文件，所有指标按时间顺序记在里面：心率、HRV、血氧、睡眠分段、呼吸频率、跑步路径、ECG 波形。戴表的每一秒它都在记。 最早一条是 2017 年。文件大，直接打开看不了，但 Python 脚本一两分钟就能跑完。 让 AI 写脚本，可以按自己想看的方式切。HRV 不看整天均值（白天工作时本来就低），只看凌晨 3-5 点睡眠最深的时段。跑步心率不看总均值，看各心率区间的占比。血压不看一两次读数，看 300 次测量里有多少次踩进高血压区。 三件事 OSA 和 CPAP 睡觉的时候，喉咙后面的软组织松弛塌下来，把气道堵住，呼吸短暂停。停几秒大脑缺氧自动惊醒一下，气道打开，又睡着，几分钟后再来一次。一晚循环几十上百次，自己感觉不到。 数据里能看出来。90 天里血氧有 12 次低于 92%；夜间呼吸异常事件均值 3.5 次/小时，最高 9.6 次/小时。 这事不是「打呼噜的小毛病」。每次呼吸暂停身体都进入一次窒息-惊醒应激，长年累月推高血压，加速心血管病变。我的血压 306 次测量里 62% 已经踩进 130/80 以上，多半跟 OSA 有关。 CPAP 是一台小机器，吹气进鼻子。持续正压把气道撑开，机械上不让它塌。不吃药，不开刀，靠空气压力解决问题。 我家这台 ResMed AirSense 10 几年前买的，因为面罩漏气吵到我太太，闲置半年多。五月初换了鼻枕式面罩，5/11 到货，5/13 重新开始用。 HRV 偏低 心率变异性。两次心跳之间的间隔不是固定的，有微小变化。变化越大（HRV 高），说明自主神经系统弹性越好——副交感（休息）和交感（应激）切换自如。HRV 低意味着身体长期处在应激态。 我的总均值 31.8 ms。这个数字不能直接判断好坏，跟年龄、个体差异都有关。要跟自己比，要看时段——白天工作 HRV 本来就低，关键看睡眠深处的。 我凌晨 3-5 点的睡眠 HRV 是 47 ms，对我来说算正常偏好。但全天均值被白天的 23-25 ms 拉低了。 HRV 不用单独想着怎么提升。OSA 控制好、酒精少喝、运动结构对，HRV 自然会涨。 VO2max 下降 最大摄氧量。运动时身体每分钟每公斤体重能消耗的氧气量。评估心肺能力最直接的指标。 轨迹：2025-09 见顶 46.39，到 2026-05 跌到 42.31，半年掉了 4 个点。 这是真的下降，还是数据假象？——一半一半。Apple Watch 的 VO2max 不是测出来的，是算出来的：用配速和心率反推。核心变量是「心率储备」（最大心率减静息心率）。我的静息心率从 53.7 涨到 62.4，半年涨 7 bpm，心率储备压缩了，算法自动把 VO2max 调低。 但 RHR 涨 7 bpm 本身就是真问题——身体应激累积的信号，跟 OSA、HRV 偏低、可能的工作压力都相关。 所以 VO2max 这事是上面两个问题的下游表现。 三件事其实是一件事 体检报告会列「血压偏高」「HRV 偏低」「VO2max 下降」，让你「注意休息、多运动、保持心态」。这种建议没用，因为没指到根。 实际的因果链是这样： OSA（气道塌） ↓ 夜间反复窒息-惊醒 ↓ 长期交感神经过度激活 ↓ RHR 上升 + HRV 下降 + 血压升高 ↓ 心率储备压缩 → Apple Watch 的 VO2max 算法估算下降 ↓ （如果不管）心血管事件风险累积 CPAP 是这个链条的根。其他事——戒睡前酒精、加间歇训练、补镁、慢呼吸——都是辅助。先把根处理好，剩下的事杠杆才显出来。 进展 5/13 启用 CPAP，到 5/27 戴了两周。把这两周数据切出来跟之前 30 天比，排除掉 5/17（没戴）和 5/24-26（打了带状疱疹疫苗第二针，免疫反应推高了 RHR），剩 11 个有效夜： 指标 之前 30 天 CPAP 11 夜 变化 夜间呼吸异常事件 3.21/h 1.37/h 降 57% 静息心率 59.6 56.9 降 2.7 HRV 整夜均值 35.7 ms 40.5 ms 升 4.8 深睡时长 0.61h 0.77h 升 25% 睡眠时长 6.34h 6.80h 多睡 28 分钟 呼吸频率 19.17/min 17.7/min 降 1.5 夜间觉醒时长 8.2 min 13.0 min 升 4.8 唯一变差的是觉醒时间。面罩在脸上的扰动——客观身体得到的睡眠质量更高，但大脑因为脸上多了个东西每晚多醒几次。CPAP 适应期的典型情况，通常 2-6 周后主客观会汇合。 我主观感觉「睡眠变差」就是这 4.8 分钟带来的。其他所有指标都在指向正面。 VO2max 还没反弹。训练适应要 4-8 周才反映到数据里；五月才开始把跑步强度往上推（高强度时间占比从过去半年的不到 1% 升到 15.3%），还在累积期；RHR 下降才两周，还没稳定到能让算法估算抬上去。 6/8 满 4 周时再重跑完整对比。 下一步 6/8：CPAP 满 4 周，重跑完整对比 这周内：读 CPAP 的 SD 卡（OSCAR 软件）看真实 AHI 和漏气率 持续：每周加一次 4×4 间歇跑（基线脚本指出的训练结构问题——长期 86% 时间在 Z1+Z2，Z4-Z5 几乎是零） 九年的数据扔给 AI 跑一下，趋势就摆出来了。 --- # eink 手机重装后的工具清单 URL: https://wlj.me/posts/eink-phone-essential-apps/ Published: 2026-05-12 Updated: 2026-05-12 Tags: Tech, Tools昨天重装了 eink 手机。安装后希望装少而精的几个工具即可： Telegram、Pocket Casts、Claude、Google Tasks、Brave、YouTube、微信读书、微信输入法、Slax Reader、Slax Note、Dropbox、Gemini、Spotify。 --- # 招 AI 同事还是给 AI 装本事 URL: https://wlj.me/posts/hire-ai-or-install-skills/ Published: 2026-05-10 Updated: 2026-05-10 Tags: AI, 产品观察最近看到一个新产品 Moxt，官网上自己是这样介绍的： 一个 AI 原生的工作区。你的 AI 团队 7×24 小时工作、边干边学、和你一起协作。 来认识 momo——你的第一个 AI 队友。住在你的 Slack 里，认识你的团队，不用解释背景。 一个 momo 是另一个你。一队 momo，就是你 ×100。 简单说：每个人配一个 AI 助手叫 momo，多个 momo 互相协作、共享所学。 我平时用 Claude Code，那边的思路叫 skills——给一个 AI 装很多本事，主 AI 自己挑着用。Moxt 是把 AI 拆成几个角色，让它们在 Slack 里像同事一样互相配合。 --- # Code Wiki：Google 给 GitHub 仓库自动生成的可交互 wiki URL: https://wlj.me/posts/google-code-wiki/ Published: 2026-05-10 Updated: 2026-05-10 Tags: AI, Docs, ToolsGoogle 在 2025 年 11 月推出了 Code Wiki，对着任意 GitHub 公开仓库自动生成持续同步的可交互文档站——架构图、类图、时序图，加一个用这份 wiki 当上下文的 Gemini chat。 用法：把 github.com/<org>/<repo> 换成 codewiki.google/github.com/<org>/<repo>。 丢一个看效果：openclaw/openclaw 的 Code Wiki 视图。 私有仓库要走 Gemini CLI extension。 官方介绍：Introducing Code Wiki。 --- # eval 是什么，sgai.md 怎么做 URL: https://wlj.me/posts/evals-101-and-sgai/ Published: 2026-05-10 Updated: 2026-05-10 Tags: AI, Tech, Tools只要产品里嵌了 AI，就一定要做 evals。这是过去两个月在 sgai.md（新加坡 AI 战略观察站）上踩坑总结出来的判断。 eval 是什么 eval = 评估测试。给 AI 输出和数据完整性写的回归测试，但和单元测试不是一回事。 单元测试测的是「函数给定输入，输出是不是这个值」——确定性的。 eval 测的是「AI 这次生成的东西，和金标 / 规则相比，质量有没有掉」——非确定性的。 简单说：单元测试盯代码，eval 盯模型 + 数据。 eval 解决什么问题 任何依赖大模型的系统，都有三个天然漏洞。代码里写的单元测试管不到，人肉 review 一定漏。 模型会幻觉。 LLM 会编一个看起来合理但根本不存在的 URL、人名、事实。我自己在 sgai.md 上踩过——5 月初让 agent 给一批 voice 人物档案补「主导项目 / 公开引言」，agent 给两条记录写了根本不存在的 sourceUrl（一个伪造的 Fintech Festival 演讲者 ID，一个伪造的航空业报道）。URL 模式正确得肉眼分辨不出，靠用户事后报错才发现。 模型会退化。 升级模型（Claude 4.6 → 4.7）或改 prompt，输出可能变差。但你不会主动知道——除非有人发现产出明显烂了。等用户先发现就太晚了。 数据会漂移。 AI 生成的内容入库后，没人持续盯着完整性，漏字段、缺翻译、链接腐烂会慢慢累积。sgai.md 是中英日三语站，数据文件里每条 record 要求 title / titleEn / titleJa 三套字段必须同时给。我有一次只 commit 了中文，下一个 PR 想补英日——结果 EN/JA 页面立刻断裂。 eval 是把人肉的「我应该再检查一遍」变成 cron 自动跑。 evals 的最佳实践 第一，从事故反推。 不要「我觉得应该测 XYZ」。要「我们漏了什么 → 怎么自动化抓住下次」。sgai.md 的 CLAUDE.md 里有几条「🔴 顶层硬规则」，每条都对应一次具体 commit 事故。比如「sourceUrl 真实性约定」直接来自伪造 URL 那次；「addedAt 字段约定」来自手动加视频但忘同步首页「最近更新」那次。 每个 eval 必须对应一个真实漏洞或真实事故。否则就是装样子。 第二，分层。 sgai.md 的 i18n 检查就是分层叠加： 数据层：每条 record 中英日字段必须配对 构建层：sitemap 里每个中文 URL 必须有英日 sibling，hreflang 四条必齐 内容层：英文页面禁止 CJK，日文页面必须含 hiragana/katakana 源码层：扫源码里 lang === 'zh' ? 这种二元三元（会让日文静默落到英文分支） 每一层抓不同盲区。一层挡不住的事情，下一层挡。 第三，存量不强清，但只许变好不许变烂。 sgai.md 源码里曾有 518 处旧的硬编码反模式，不可能一口气改完。做法是把当前数字记下来当基线，往后只看「比基线多了几条」——多一条 fail。改好的可以更新基线，永远只许变小。 这个原则在所有领域都通用——代码债、桌面、戒糖、健身。要的是趋势变好，不是一夜清零。后者大概率半途而废，反而把规则废了。 sgai.md 现在的 evals Eval 出问题会怎样 频率 网址巡检 AI 编一个看似合理但根本不存在的网址，访客点进去 404 周 字段配对 新加内容只写了中文，英日字段空着，对应页面立刻断裂 每 PR URL 三语对齐 中文站点地图里有的页面，英日版本却没生成，搜索引擎以为日文版根本不存在 每构建 多语言声明 页面没告诉谷歌「我有中英日三种版本」，被识别成单语站，三语 SEO 全废 每构建 语种纯度 英文页面里残留中文字符；日文页面看上去全是汉字、没有平假名片假名（其实根本没翻译） 每构建 模板硬编码 源码里有种写法会让日文版静默退化成英文，访客以为日文版坏了 每 PR 首页「最近更新」 加了新内容但忘记打日期标，首页看不到，等于白做 每 PR 结构化数据 JSON-LD 漏字段，谷歌搜索结果不出 rich card，掉点击率 每构建 摘要金标 升级模型或改 prompt 后，AI 写的摘要质量悄悄下降，没人察觉 月 翻译金标 升级模型后术语翻错（人名、机构名、政策名），全站翻译统一性破坏 月 每条都对应一次真实踩过的坑，或一次可预见的退化场景。这是健康的 eval 设计——从事故反推回防御，不从理论正推。 --- # Warp 文档站的 agent 工作流 URL: https://wlj.me/posts/warp-docs-agent-workflow/ Published: 2026-05-10 Updated: 2026-05-10 Tags: AI, Docs, ToolsWarp 是从终端起家的 AI 开发环境。2026 年 5 月，它把产品文档站 docs.warp.dev 的源代码开源了，仓库地址 github.com/warpdotdev/docs。这个仓库除了文档内容本身，还配了一整套用 AI agent 维护文档的工作流。 文档站基于 Astro 6 + Starlight，内容用 MDX 写在 src/content/docs/ 下。Node.js 22 起步，npm install 后 npm run dev 启动本地预览，端口 4321。“Ask AI” 按钮和 “Was this helpful?” 反馈是可选功能，需要在 .env 里填公开值。 下面分四块说明仓库里 agent 相关的结构。 .agents/ 目录 .agents/ 分四个子目录： skills/ — 25 个 skill。每个 skill 是一个子目录，里面至少有一个 SKILL.md 描述用途和执行步骤，部分含有 references/、scripts/。 rules/ — 通用规则，当前只有一个 oz-style-guidelines.md。 templates/ — 不同类型文档页面的模板（quickstart、guide、procedural 等）。 references/ — 词汇表等参考资料。 25 个 skill 按用途分四类： 草稿生成（10 个）：draft_quickstart、draft_guide、draft_procedural、draft_conceptual、draft_reference、draft_faq、draft_troubleshooting、draft_feature_doc、draft_docs、missing_docs。从空白页起一篇新文档时使用。 审查质检（5 个）：review-docs-pr、style_lint、check_for_broken_links、docs-seo-audit、validate_ui_refs。 同步类（4 个）：sync-error-docs、sync-openapi-spec、sync_terminology、update-changelog。update-changelog 从 channel_versions.json 拉每周 release，按模板生成 changelog 条目并开 PR；要求生成内容与源数据一字不差。 辅助类：answer_question、create_pr、afdocs-audit、afdocs-fix。 AGENTS.md 仓库根目录的 AGENTS.md 是文档站的写作风格指南。文件分两段，前一段写作规范（Warp Documentation Style Guide），后一段仓库说明（Warp Docs Repository Guide）。 写作规范覆盖： Voice & tone：第二人称、动作导向、不堆行话 Language：主动语态、消除模糊动词（may / might / should）、避免代词指代不清、避免修饰语堆叠、避免名词化 Punctuation：强制 serial comma；指令性文本里不用 em dash Tense / Person：一般现在时；指令用 imperative；面向读者用第二人称 Inclusive language：性别中立代词、避免 ableist 用词、不靠颜色单独传达信息 写给 agent 看（AEO）：描述性 header、明确上下文、frontmatter description 当成搜索摘要写、术语统一 Content structure：必填 frontmatter description、sentence case headers、文件名 lowercase + 连字符 Formatting：列表里 bold 关键词 + 破折号 + 解释；代码块必须带语言标识；图片 alt 描述具体内容；caption 不超过 10 词 这份文档既是写作者的规范，也是 review-docs-pr 评审 PR 时的参考依据。 .github/workflows/ 三个 workflow。 ci.yml 触发：每个 PR 和 push 到 main。 步骤：checkout → 装 Node.js 22 + Python 3.12 → npm ci → npm run typecheck → npm run build → 调用 .agents/skills/check_for_broken_links/check_links.py --internal-only → npm audit --omit=dev --audit-level=high（暂用 || true 不阻塞）。 review-pr.yml 触发：PR opened 或 ready_for_review，且来源在同仓库内。 主步骤：调用 warpdotdev/oz-agent-action@v1，传入 skill: review-docs-pr。agent 跑完输出 review.json，结构如下： { "summary": "...", "comments": [ { "path": "...", "line": 42, "side": "RIGHT", "body": "..." } ] } 接下来一段 JavaScript（用 actions/github-script@v7 跑）做后处理： 读 review.json，解析失败时清掉控制字符再试一次 调 GitHub API 拉 PR 改动文件清单和 diff hunks 解析每个文件的 diff，建出"哪些行号在 LEFT/RIGHT 侧出现"的集合 遍历 agent 输出的 comments：路径正常化、丢弃路径不在 PR 内的、丢弃行号非法的、丢弃行号不在 diff 范围内的（这些不丢失，挪到 summary 末尾的 “Additional comments”） 用 pulls.createReview 一次性提交 summary + inline comments review-docs-pr skill 要求每条 comment 开头打严重度标签：🚨 [CRITICAL]、⚠️ [IMPORTANT]、💡 [SUGGESTION]、🧹 [NIT]，并尽量使用 GitHub Suggestion 语法让作者一键应用。 respond-to-comment.yml 触发：PR 评论或 review comment 内容里出现 @oz-agent。 主要步骤： 权限校验：用 repos.getCollaboratorPermissionLevel 检查评论作者，只允许 admin 或 write 权限的人触发 加 👀 反应：通过 reactions API 给评论加 eyes，告知用户已收到 checkout PR：gh pr checkout 构造 prompt：抓 PR 标题、描述、改动文件清单、评论内容、评论作者；如果是 review comment，再带上文件路径、行号、diff hunk 跑 agent：warpdotdev/oz-agent-action@v1，传入构造好的 prompt commit 改动：以 Oz Agent <agent@warp.dev> 的身份 git add / commit / push（如果有改动） 回复评论：解析 agent 的 JSONL 输出，取最后一条 type: agent 的 text，作为 reply 贴回评论 失败处理：agent 步骤失败时，回复一条带 workflow logs 链接的错误提示 仓库链接汇总： 主仓库：github.com/warpdotdev/docs .agents/：/.agents AGENTS.md：/AGENTS.md .github/workflows/：/.github/workflows --- # 为下一代模型做产品 URL: https://wlj.me/posts/building-for-next-model/ Published: 2026-05-10 Updated: 2026-05-10 Tags: AI, 创业, 翻译上次整理过 Lenny’s Podcast 那期 Boris Cherny 的中文版：编程已被"解决"之后的世界。这次是 Boris 在 Sequoia Capital 的另一场访谈（2026-05-04 发布，YouTube 24 分钟版），重叠不多，更聚焦在 Claude Code 起源、他现在的工作方式，以及组织和团队的变化。下面是我整理润色的中文版。 现场 主持人是 Sequoia 合伙人 Lauren Reeder。她介绍 Boris 时说：“整个软件开发似乎都压在他肩上。“她想聊三个方向：软件的未来、写代码的未来、大家以后应该把空闲时间花在什么事情上。 Lauren 顺带补了一个细节：Boris 一直是非常纯粹的工程师，写过《Programming TypeScript》。但她上次和 Boris 聊时，Boris 说自己 2026 年到目前为止，没有亲手写过一行代码。 Boris 反问现场使用 Claude Code 的方式。多数人主要用 CLI；桌面端用户也有一些；VS Code 或 JetBrains 插件用户相对较少。他自己现在反而主要在 iOS 上用。 Claude Code 是怎么开始的 Claude Code 很大程度上是"意外"做出来的。 Boris 在 2024 年底加入 Anthropic Labs。这是 Anthropic 内部的一个孵化器——非常小，像一个创新小组。这个小组后来做出了 Claude Code、MCP 和桌面 app。完成阶段性任务后团队一度解散，现在又重新聚在一起做第二轮，由 CPO Mike Krieger 带队（前 Instagram 联合创始人）。 他开始做 coding 产品，是因为看到明显的 product overhang：模型已经有能力做很多事情，但还没有对应产品把这些能力承接起来。 2024 年底主流 coding 产品形态还是 type-ahead：打开 IDE，按 Tab，模型一次帮你补全一行——这是 Sonnet 3.5 第一次真正带来的体验。但 Anthropic Labs 觉得模型已经接近下一步：让 agent 直接写全部代码。 前六个月 Claude Code 并不好用，只能说勉强可用。Boris 自己大概只会用它写 10% 左右的代码。即使最初发布后也不是一夜爆红。真正的增长拐点出现在 Opus 4 发布之后，2025 年 5 月。之后每次模型升级，增长都会再上一个台阶：Opus 4、4.5、4.6、4.7 一路推动。 他的判断是：他们当时在做一个"模型还没完全准备好"的产品。它在产品市场匹配之前就被做出来了，团队知道大概要等六个月，等下一代模型补上能力。这个下注一直很清晰：为下一代模型提前做产品。 “写代码已经被解决"是什么意思 Boris 公开说过 coding is solved。这句话到底是什么意思？ 他先问现场：谁 100% 手写代码？谁 100% 用 Claude Code 这样的 agent 写代码？大多数人介于中间——他开玩笑说，那大概就是"50% 被解决”。 但对他自己已经是 100%。Claude Code 的代码库主要是 TypeScript 和 React。团队选这套技术栈是因为它们在模型训练分布中非常常见——早期模型还没有今天这么聪明，越常见模型越擅长。现在模型已经能写各种语言、学习没见过的新框架，但当时要尽量选模型"熟"的东西。 所以 Claude Code 团队比较早就进入了模型写 100% 代码的状态——大概是 2025 年 10 月或 11 月。 到今天，Boris 的代码全部由模型写。他通常每天会做几十个 PR。有一天为了测试上限，一天做了 150 个 PR，这是他的个人纪录。 他也强调，这并非所有地方都已经成立。很多大型复杂代码库、很怪的语言、模型不擅长的环境，仍然没有完全解决。但大方向上，他认为答案通常就是：等下一个模型。 Boris 现在怎么工作 Boris 大约六个月前在 Twitter 上分享过自己的 setup，当时完全没意识到别人会觉得惊讶——那就是他平时写代码的方式。现在它又变了：他大部分工作都在手机上完成。 他打开 Claude app，左侧有一个 code tab，里面开着很多 session。通常 5 到 10 个 session；每个 session 里又有很多 agent，所以当前可能同时跑着几百个 agent。每晚通常还会有几千个 agent 做更深的工作。 管理这些 agent 有几种方式。一种是让 Claude 使用很多 sub-agent 去并行完成任务。但他最近越来越常用的是 loop。 Loop 的核心很简单：让 Claude 用 cron 在未来某个时间点安排一个重复任务。可以每分钟跑一次、每五分钟跑一次、每天跑一次，频率由你决定。 Boris 现在有几十个 loop 在跑： 一个 loop 专门看守他的 PR，修 CI、自动 rebase 一个 loop 维持 CI 健康，遇到 flaky test 就去修 一个 loop 每 30 分钟抓取 Twitter 上的反馈，并自动聚类给他看 他认为 loops 很可能就是未来。如果还没试过，强烈建议去试。 Anthropic 也刚发布了 routines。它和 loop 类似，但运行在服务器端——即使关掉电脑任务仍然继续。 未来团队会变成什么样 Boris 的核心判断是：未来 generalist 会更多。 今天大家说 generalist，通常还是指工程内部的多面手——比如既能写 iOS，也能写 web 和 server 的产品工程师。但接下来会出现更多跨学科 generalist：一个工程师不仅擅长产品工程，还非常懂设计；或者同时懂产品、数据科学和工程。 Claude Code 团队已经在发生这种变化。每个人都会写代码：工程经理、产品经理、设计师、数据科学家、财务、用户研究员。他们各自仍然有专业背景，但现在也都能编码。 软件产品和 SaaS 会发生什么 如果 AI 让写代码便宜 10 倍或 100 倍，软件生产出来的产品价值会怎样变化？会不会出现 SaaS apocalypse？ Boris 说这是他最喜欢的问题。他认为会发生两件事，都不是大家最常讨论的那种。 第一，AI 会改变不同 business moat 的重要性。 他提到 Acquired 播客里 Hamilton Helmer 的 Seven Powers 框架。因为 AI，有些护城河会变得更重要，有些会变得不那么重要。 会变弱的例子： Switching costs：模型可以帮你把一个系统迁移到另一个系统，切换成本会下降 Process power：如果一家公司护城河主要是流程、工作流、过程经验，Claude 越来越擅长理解并优化流程。尤其是 4.7，只要给它目标、让它持续迭代，它就能不断爬坡直到完成 但传统护城河依然重要——网络效应、规模经济、稀缺资源等。这些不会因为 AI 立刻消失。 第二，未来十年会出现更多能颠覆大公司的创业公司，数量可能是过去十年的 10 倍。 原因是：小团队现在可以做出和大公司一样有价值的东西并正面竞争。大公司要改变业务流程、改变工作方式、重新训练所有人使用新技术，还会遇到内部阻力。新创业公司没有这些包袱，可以从第一天起就以 AI-native 的方式搭建。 Boris 的结论很明确：现在是最适合创业、最适合 build 的时代，未来会有大量 disruption。 模型能力 vs 产品决策 观众问：Claude Code 在产品市场匹配之前提前做了六个月。现在模型已经足够好，Claude Code 的成功有多少来自模型，有多少来自产品决策？ Boris 说是混合结果。六个月前他可能会说大概 50/50。 他自己做过 YC，是一家 YC 公司的第一位员工。YC 反复灌输的一句话是：做出人们真正热爱的东西。不管模型多强，最终仍然要做出用户爱用的产品。所以产品仍然重要。Claude Code 团队非常在意细节，因为用户会整天使用它，体验必须好。 但随着模型变强，harness 会相对变得不那么重要。团队现在思考的是如何演进这个 harness：怎么让 loops 成为更一等的能力，怎么让用户更容易运行大量 agents。sub-agents 只是一个方向，还有更多东西在做。 他预测一年后模型会对齐得更好。今天围绕 prompt injection、命令静态验证、权限模式、human-in-the-loop 等安全机制，未来重要性会下降——因为模型本身会更自然地做正确的事。 写软件会变成人人都会的基础技能 观众问：现在可以看到店主为自己写软件，甚至写微控制器程序控制开门亮灯。未来写软件会不会变成类似 Microsoft Office 的技能？ Boris 的回答非常肯定。他认为它甚至会比 Office 更基础，更像"会发短信”。 他平时主要读两类书：科幻和技术史。在技术史中，最清晰的类比是 15 世纪欧洲的印刷术。 印刷术出现前，欧洲大约只有 10% 的人口识字。会读写的人常被国王、领主雇用，因为那些统治者本人未必识字。读写是一种稀缺专业技能。 印刷术发明后，最初只有少数几台印刷机。但在之后 50 年里，欧洲出版的文献总量超过了此前 1000 年，同时书籍成本下降约 100 倍。随后几百年，全球识字率上升到大约 70%。 今天读写已经是普通能力，不需要拿"读写学位"才会读写。当然，专业作家仍然存在。 Boris 认为软件会经历类似变化，而且会比印刷术后的识字普及快得多。 这会带来一个推论：如果要写会计软件，最好的人选可能就是非常优秀的会计。真正难的是领域知识，编码会变成相对容易的部分。 Anthropic 内部领先外部多少 观众问：Anthropic 工程方式和外部世界之间的差距是一月、三月还是六月？ Boris 说，在模型层面他们用的基本就是外部也能用到的模型。Dogfooding 对 Anthropic 很重要。他们会用一点 mythos 做尝试，也大量使用 Opus 4.7 来 dogfood 和写大多数代码。 所以模型侧没有太大差距。Anthropic 做的是平台，让开发者使用和内部相同的技术非常重要。 真正差距更大的是产品侧和组织流程侧。 Anthropic 内部几乎所有事情都用 Claude。Boris 说他们的 Claudes 整天互相沟通：当他在写代码、他的 Claude 在 loop 里写代码时，它们会通过 Slack 和其他人的 Claude 交流，弄清未知问题。 公司里已经没有任何手写 SQL，SQL 都由模型写。几乎所有东西都由模型构建。 领先之处在组织结构和组织流程的调整，不在技术本身。这个部分更难，也更值得其他团队学习和演化。 多 agent 和 delegation 观众问：用户现在还得靠自己的直觉判断什么时候并行。模型层和 harness 层如何帮助用户更好地委派工作？ Boris 说，在产品层面本质上还是 prompting。团队会调整 prompt 让模型更自然地并行做事。 但随着模型变强，它会自然学会这样做。比如 4.7 已经开始主动做 loop。Boris 举例：他让模型去拉一个数据查询，模型注意到数据随时间变化，于是主动建议开一个 loop，每 30 分钟发一份报告。如果他要求发到 Slack，它就用 Slack MCP 做到。 长期看，用户不应该需要学习怎样更好地"握住工具”。如果用户必须学很多工具操作技巧，那是产品设计没做好。模型应该把这些事做得更好，产品通过 prompt 和体验设计让它自然发生。 本地 AI 还是云端 AI 观众问：随着开源模型追上来，未来高质量 coding assistant 会不会转向本地 agents？ Boris 说，最根本的答案是：这可能不重要。 模型正在变得能够自己决定怎么做。几年后，模型会写所有代码、启动 agents、搭建环境。如果它判断某 … --- # 把 AI 推广做成产品 URL: https://wlj.me/posts/ai-adoption-as-product/ Published: 2026-05-10 Updated: 2026-05-10 Tags: AI, 创业, 翻译来源：How I AI 频道访谈，主持人 Claire Vo，嘉宾 John Kim（Delight.ai）。视频 https://www.youtube.com/watch?v=uH39OZ-KnkY 。下面是我整理润色的中文版。 开场 John Kim 要展示两样东西。一个是公司内部的 AI token 使用排行榜——每个人会从 “AI newbie” 到 “AI god” 被分层。另一个叫 AI quests，用来推动全公司采用 AI。 John 想做的事情，是把 AI 变成 workforce 的一部分：给团队足够的信息、工具和基础设施，让员工自己去用 AI 的能力。 很多公司推 AI 时，员工听到的是"用更少的人做更多事"“你应该更快”。John 展示的另一种收益：让每个人都成为 builder，做出以前不会被排进路线图、但有创造力和客户价值的东西。 案例：营销团队两天做出能收款的周边商店 John 演示了 Delight 的 swag store，主题是 Big AaaS Energy（AaaS = Agent as a Service）。 整个商店由营销团队完成，没有工程团队支持。它接了 Stripe，能真的下单付款。两天上线。 商店里有 “My AaaS is bigger than your SaaS”、“Context window I carry a lot” 这类周边。还藏了一个 Konami code 彩蛋（上上下下左右左右 BA），引导到 5 月 7 日在旧金山的 Delight Spark 大会。 Claire 的评价：以前营销团队有这种想法，要先去问工程能不能排期、活动很快就结束了是否值得占资源——最后只能在 CMS 里拼一个平庸版本。AI 把营销人员的创造力直接变成了可交付给客户的体验。 她总结一句很直接：当 fun 变便宜了，产品和营销就应该更 fun。 John 同意。以前让工程为了一个活动彩蛋花两个 sprint，很难排上优先级。现在把 AI 的能力交给营销、销售这些离市场更近的人，很多想法可以快速上线。 Automators：内部 AI 需求和 builders 的市场 不是所有营销人员一年前都会写代码。Delight 怎么让团队从"所有事都找工程"转过来？ 答案是内部平台 Automators。 公司任何人都可以提一个 quest。比如财务团队说：我想自动化应收账款流程。提出后，工程师可以来帮忙；如果需求方自己 AI-enabled，也可以自己构建。平台里有已完成、进行中、等待中的 quests，每个有一个 quest giver。完成后通常会提交代码仓库、内部 skill、视频说明或 workflow。 下一阶段是让 AI 自己接 quests：读规格、生成 PRD、开始写代码。AI agents 也成为 automation 和 workflow 的 builder。 为了让非工程团队自己构建工具，Delight 维护一份内部指南，几乎每天更新，教大家设置 GitHub、创建新应用。还做了内部 app template——认证、环境、安全、基础设施都已设置好。营销、CSM 或其他业务人员基于模板开发，不用重新处理认证、数据库、合规。 Claire 抓住这一点：公司里已经有人在 vibe coding。他们要么不知道怎么把东西安全上线，要么直接推到 Netlify、Vercel，暴露给整个互联网。与其堵，不如提供一条安全生产路径。把登录、权限、数据访问、部署方式都模板化，让大家在正确轨道上快跑。 她把 Automators 概括成：公司内部的 AI 需求和 AI builders 市场。任何人都能提需求、参与解决。它是一条 shadow AI roadmap，放在正式产品 roadmap 旁边，但不用陷入传统优先级流程。 John 说这正是设计意图。传统软件开发围绕 sprint 和优先级块运转，但很多人会有"微型空档"——他叫 micro vacations——有一点时间，想做一些不在主产品核心仓库里的小工具。内部工具的好处：用户就在公司里，反馈回路非常短。 完成 quests 的人会拿 experience points，可以兑换礼品卡、和高管喝茶、或在全公司展示自己做的东西。 每周三的 standup，团队上台 demo。最近一周是招聘团队展示自动化，上一周是营销团队。John 特别指出，展示者几乎从来不是工程团队，往往是其他团队的人兴奋地展示自己做出来的东西。 组织设计：AI Engineer for Internal Operations 谁负责维护这些指南、模板和基础设施？ Delight 新建了一个角色，叫 AI Engineer for Internal Operations。名字长，但职责明确：帮助和加速公司转型为 AI-first company。 这个角色直接向 John 和 chief of staff 汇报，可以跨职能工作。同时得到 CTO、工程团队和信息安全团队支持。 他们有一个 task force，每周开会讨论怎么打通阻碍：合规怎么做、日志怎么记、哪些软件可以提前 vet、销售团队做工具时该用哪套 AI stack。目标是让业务团队不用操心数据库、权限、安全审查——带着想法来就行。 这套机制不是一开始就成熟的。最早来自几个人做自己的个人工具，然后拿出来展示。关键是动能来自非工程团队。这给了管理层信心：既然非工程团队能做到，就值得补基础设施，让他们以 100 miles per hour 的速度跑起来。 Skills 市场：把专业知识变成可复用能力 Delight 还做了公司级 skills marketplace。 任何人都可以创建 plug-in（一组 skills），也可以单独创建或下载 individual skills。 销售团队有自己的 sales skills repository。公司内部用 MEDDIC 框架，所以有 MEDDIC advisor。这个 skill 既能教你怎么用 MEDDIC，也可以嵌入自己的软件或 workflow，给销售过程提供建议。招聘、设计、销售这些职能都建了类似的技能库。 做这个市场的原因很实际：不同团队经常在重复构建同样的 app 或 skill。希望大家 co-evolve，少各自孤岛。 员工是否自然理解 “skill” 这个概念？John 说有 top-down 也有 bottom-up。 Top-down 是 John、CTO 和高管推动。他们也会做一些直接的一对一谈话：我们看到你还没怎么消耗 tokens，是不是遇到阻碍了？ Bottom-up 来自好奇心强的人。他们多点几个按钮、多读几篇博客；看到 Slack 里有人说 skills、有人上传 markdown 文件，就会问：我能用这个 design markdown 吗？效果是什么？ 当某个非设计师在周三全员会上展示出很漂亮的 slide，其他人会问：你怎么做到的？答案往往是：背后有某个 skill。 把 AI adoption 当产品来运营 Claire 总结了一个 meta 层：John 用 AI 构建了一个内部产品，来推动整个组织采用 AI。 John 没做培训项目，没发文档，也没让高管号召。他做成了内部产品： 需求发布系统：quests 供应和协作系统：AI builders、工程师、业务团队、AI agents 安全上线路径：templates、认证、环境、合规、日志 复用市场：skills marketplace 激励系统：experience points、礼品卡、高管茶、全员展示 度量系统：token dashboard 和分层 这套系统把 AI adoption 从"倡议"变成了"内部产品和内部市场"。 真实收益：营销团队建出自己的 marketing SaaS 除了 swag store，还有什么真实收益？ John 给了两个层次：一个团队级，一个具体 campaign。 团队级是营销团队，他们几乎自己建出了一整套 internal marketing SaaS： interview marketing plan calendar account-based marketing 工具 competitor review real-time metrics 一个内部叫 Purple Cal 的差异化分析工具 多种活动和社交传播工具 整个 portal 由营销团队自己构建、管理、日常使用。 具体 campaign 的例子叫 buzzboard。Delight 在旧金山投放 billboard，团队有真实照片，也有 AI 生成的 billboard。员工选一个、选语言和预设文案，然后直接发到 LinkedIn。文案的长度、细节和能量水平都可以调。整个工具由营销团队构建，每天都在用，带指标追踪。 Claire 顺带插一句：SaaS 不会归零。深度软件问题仍然值得专业团队做，也会有人买现成方案。但越来越多公司会先问：我们到底想要什么？能不能自己内部构建？ 重点是做一个最适合自己团队、文化和工作方式的内部工具。功能性复制外部 vendor 不是目的。比如要的不是一个通用社交发布工具，而是最适合自己公司 LinkedIn 传播方式的工具。 Claire 把这种公司内部的 micro software solution 叫 “revenge of the internal tools team”。过去没人想做内部工具——资源少、设计差、工具慢、只求能用。现在内部工具可以漂亮、快速、响应好，而且有大把 greenfield 可以玩。 Token Dashboard：度量，但不制造恐惧 真正做成 AI adoption 的公司都会度量，而且不带羞辱地度量。很多高管担心：追踪 token 使用、要求员工用 token，会不会引起反弹？Claire 的观察是，真做成的团队都有 dashboard，看数据、设目标、持续推进。 Delight 内部争论过：度量 token，会不会像早年用代码行数衡量工程师生产力一样，最后大家为了指标写空行和注释？ 他们的目标是理解员工是否真的在学习和使用 AI。这个指标不进入绩效考核，但会进入对话：你在旅程中的哪里？我们怎么帮你往前走？ Dashboard 能看公司级 token 使用，也能按工具看分布。Delight 是 Claude Code shop，但 top spenders 中也有不少 Codex 用户。John 猜，处理 3 亿月活历史聊天基础设施的人偏向 Codex；快速做产品路线图、新功能的人偏向 Claude Code。这种分化是自然发生的。 他们还看一个有意思的指标：token consumption 曲线是否平滑。 如果曲线在周末或假期明显下跌，意味着 AI 也跟着停工了。曲线平滑说明 AI partners 在全天候工作。John 关心的是：怎么真正利用这种 around-the-clock 的能力。 Dashboard 支持个人、团队、经理三个视角。经理可以看到自己团队成员所处层级。 五个层级： Beginner Intermediate Expert Architect / Catalyst AI God AI God 大致指一天消耗超过 1 亿 tokens 的人。 层级的目的是帮经理按阶段提供 enablement。一个 beginner 需要的是快速到 intermediate 的工具和支持，不能直接丢进 catalyst 的讨论里。 John 说从组织整体看，Delight 大概在第二到第三阶段之间——已经大量使用 AI 和 automation，还没完全自动化，目标是继续往 stage three 推进。 John 自己 30 天平均还只是 catalyst。峰值大概一天 2 亿 tokens；平均每天约 3000 万到 5000 万 tokens。他补充：当然 … --- # 我的 VO2max 五年走势 URL: https://wlj.me/posts/my-vo2max-five-years/ Published: 2026-05-10 Updated: 2026-05-10 Tags: Health, Life5 月初导出了 Apple Health 全部数据做了一次分析。其中 VO2max 这一项从 2021-01 记到 2026-04，132 次测量。我今年 49 岁。 数据 按月平均： 时间 月均 备注 2021-01 41.7 开始记录 2023-10 45.6（峰值 47.2） 第一次冲到 Excellent 2024-04 42.0 第一次回落 2025-09 46.4 第二次冲峰 2025-12 40.2 全程最低 2026-04 43.4 反弹中 线性趋势 +0.10 ml/kg/min/年。49 岁男性自然衰减约 -0.5/年，5 年能维持，算守住了。 参考 Cooper Institute 男 40–49 岁标准：Excellent 47–50，Good 41–46，Fair 36–40。 看出来两件事 第一，能上 47。两次冲峰都对应训练强度突破期。这个数字我跑过两次。 第二，回落跟睡眠崩了同步。2025-12 是 VO2max 全程最低（40.2），同月 HRV 也是全年最差（均值 28.8 ms，低于 20 ms 的占比 27%）。一个根因。 训练结构问题 跑步心率分布： 区间 时间占比 极化训练参考 Z1+Z2 低强度 86% 80% Z3 9.5% 5% Z4+Z5 高强度 0.7% 15–20% 低强度量足够，高强度严重不足。VO2max 要靠高强度间歇逼出来，长期低强度只能维持。 提升 VO2max 的方法 按效果排序我整理出这些： 1. 4×4 间歇（Norwegian protocol） 4 分钟 @ 90% HRmax + 3 分钟慢跑，重复 4 组。文献证据：8 周 +3–5 ml/kg/min。现有研究里效果最大的单项。 2. Zone 2 长时间有氧 周累积 3–5 小时。建立线粒体密度，给高强度训练打底。 3. 治 OSA / 改善睡眠 OSA 压制夜间氧合，影响有氧能力。慢性睡眠不足影响恢复，影响训练堆量。CPAP 启用后 VO2max 通常自然 +1–3。 4. 力量训练 49 岁后保肌肉量等于保峰值耗氧。每周 2 次。 5. 减重 VO2max 单位是 ml/kg/min，分母小则数大。体重 62 kg，对我不适用。 接下来 本周一 CPAP 耗材到货，组装重启。同时开始每周 1 次 4×4 间歇。6/8 满 4 周后重导数据对比。 --- # 顺着一封 DMARC 报告，学一下邮件认证三件套 URL: https://wlj.me/posts/dmarc-report-slax-email-audit/ Published: 2026-05-09 Updated: 2026-05-10 Tags: Email, Security, Opsslax.com 的客服邮箱每天会收到几封 DMARC Aggregate Report，发件人是 dmarcreport@microsoft.com，附件是几百字节的 zip，里面是 XML。我之前从来不开。今天问了 Nix 一下这是什么，顺着学了一遍邮件认证三件套：SPF、DKIM、DMARC。 SPF SPF（Sender Policy Framework）配在 DNS 里，告诉收件方"这些 IP 才允许替我发邮件"。比如域名用飞书邮箱，SPF 记录会写： v=spf1 +include:_netblocks.m.feishu.cn -all 意思是飞书的发送服务器 IP 都允许，其他一律拒绝。 SPF 的弱点是不抗转发。客户把我的邮件转发到 Gmail 时，源 IP 变成转发服务器，原来的 SPF 检查就失败了。 DKIM DKIM（DomainKeys Identified Mail）给每封外发邮件加密签名。私钥在邮件服务器那边，公钥发布在 DNS 里。收件方拿公钥验签，确认这封邮件是我发的、内容没被篡改。 签名跟着邮件走，被转发也不掉。所以 SPF 失败的转发场景，DKIM 还能过。 DKIM 的 selector 名因服务商而异，飞书是 feishu 加一串时间戳，比如 feishu2605101150._domainkey.yourdomain.com。要查 DKIM 是否配置，得知道精确的 selector 名。我一开始拿常见的 s1、default、larksuite 去 dig，全部空，以为是没配。后来登录飞书后台才看到真实的 selector，DKIM 其实早就启用了。 DMARC DMARC（Domain-based Message Authentication, Reporting & Conformance）是上面两件的协调层。它告诉收件方"如果 SPF 和 DKIM 都对不上我可见的 From: 地址，按这个策略处理（none / quarantine / reject），并把每天的统计发到这里"。 一个典型的 DMARC 记录： v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com p=quarantine 失败丢垃圾箱（也可以 none 只观察、reject 直接拒收） pct=100 全量执行 rua=mailto:... 收每天的聚合报告 每天来的那一封 DMARC 报告，就是各家邮件服务商按这个 rua 标签生成的：告诉我有谁声称是我，谁通过了，谁失败了。 自查命令 任何域名都可以用这几条查现状： dig +short TXT yourdomain.com # SPF dig +short TXT _dmarc.yourdomain.com # DMARC dig +short MX yourdomain.com # 邮件服务商 DKIM 要知道 selector 才能查。飞书的可以登录管理后台 → 邮箱 → 域名设置 → DKIM 看到 selector 名。 --- # Recordly：开源的桌面录屏 + 编辑器 URL: https://wlj.me/posts/recordly-screen-recorder/ Published: 2026-05-07 Updated: 2026-05-07 Tags: Tools, Video看到一个开源的桌面录屏工具 Recordly，macOS / Windows / Linux 都能跑。 它把录制和后期合在一个 app 里。录完直接进编辑器，时间轴上做 trim、zoom、变速、注释、额外音轨、裁剪，不再把素材丢进另一个剪辑软件。 主要功能 自动 zoom 建议、光标平滑、点击反馈 把录制内容放进 styled frame：壁纸、渐变、阴影、圆角、留白 webcam 浮窗，位置可调、可镜像、可加阴影，可设置随 zoom 缩放 项目可存为 .recordly 文件，之后再打开继续改 导出 MP4 或 GIF 扩展市场 marketplace.recordly.dev 平台支持 macOS 14.0+：用 ScreenCaptureKit 原生捕获 Windows 10 19041+：用 Windows Graphics Capture + WASAPI 音频 Linux 现代发行版：Electron 捕获，目前不支持隐藏鼠标 项目情况 许可证：AGPL 3.0 主页：recordly.dev 仓库：webadderallorg/Recordly 从 OpenScreen fork 后另起的项目 --- # 冒烟测试这个名字是怎么来的 URL: https://wlj.me/posts/where-smoke-test-name-comes-from/ Published: 2026-05-04 Updated: 2026-05-04 Tags: testing, history写代码的人都听过冒烟测试（smoke test）：部署完之后跑一组最基础的用例，看核心功能能不能开机，主接口返不返回 200。挡掉最低级的爆炸，过了再谈别的。 但"冒烟"这个词从哪儿来的？ 最早的版本来自水管工。管道装完之后往里灌烟，看哪里漏。漏烟的地方就是漏水的地方。先堵漏，再谈通水。 第二个版本来自电子电路。电路板焊完通电，如果哪儿短路了、元件烧了，会冒烟。冒烟说明连基本通电都过不了，更别谈跑功能。不冒烟才轮得上下一步。 软件圈把这个比喻搬过来。微软 1990 年代把它写进开发流程：每日构建配冒烟测试，build 完先跑一遍最基础的用例，挂了直接 fail，过了再让 QA 接手。后来传开。 所以冒烟测试的逻辑一直没变：先验证它没冒烟，再验证它能干活。 --- # AhaSlides：朋友在线分享时用到的互动工具 URL: https://wlj.me/posts/ahaslides-friend-talk/ Published: 2026-05-04 Updated: 2026-05-04 Tags: Tools, Startup今天听一位朋友做在线分享，她用 AhaSlides 跟听众互动——投票、问答都走这个平台。第一次见，顺手查了一下。 AhaSlides 是越南团队 2019 年做的互动演示工具。讲者放幻灯片，观众用手机扫码进来参与投票、测验、词云、问答、抽奖。同类产品有 Mentimeter 和 Slido。 和 ClassPoint 不同的是，AhaSlides 是独立的 Web 平台，不依赖 PowerPoint；ClassPoint 是 PowerPoint 插件，必须装在 PPT 里用，主要场景是 K12 课堂教学。 价格 免费档：最多 50 名观众参与 Essential：$4.95/月 Plus：$10.95/月 Large：$15.95/月 单日票：临时开会或培训用，不用订阅 教育档另有折扣 公司情况 根据 Latka 2025 年 7 月的数据： ARR 440 万美元 团队 40 人 2019 年成立 完全 Bootstrap，没拿过外部融资 参考链接： AhaSlides 官网定价 Latka 公司数据 --- # 一个 AMP 报警，挖出一个子域名接管 URL: https://wlj.me/posts/amp-warning-subdomain-takeover/ Published: 2026-05-03 Updated: 2026-05-03 Tags: SEO, Security, OpsAMP（Accelerated Mobile Pages）是 Google 2015 年推的移动端加速网页框架，强制简化 HTML 和 JS、内容托管在 Google CDN，目的是让手机搜索结果秒开。后来普及度一般，2021 年 Google 把它从移动搜索排名加权里移除，现在基本是历史遗产，但 Search Console 还会扫描和报警。 今天收到 Google Search Console 的一封邮件： AMP issues detected in wulujia.com To the owner of wulujia.com: Search Console has identified that your site is affected by 1 AMP issue(s). The following issues were found on your site. Top non-critical issues AMP page domain mismatch Non-critical issues are suggestions for improvement, but don’t prevent the page or feature from appearing on Google. Some of these issues could be reclassified as critical in the future, and critical issues can affect your site’s appearance on Search. We recommend that you fix these issues when possible to enable the best experience and coverage in Google Search. 第一反应是奇怪。我这个老站没做 AMP。源码里搜了一遍，也没有 rel="amphtml"。 继续查 Search Console 里的示例 URL，看到一个 Cloudflare Pages 域名，形如： https://<some-project>.pages.dev/ 打开之后是一个真正的 AMP 页面，内容是印尼博彩。它的 canonical 指向我的一个子域名： <link rel="canonical" href="https://<some-subdomain>.wulujia.com/"> 再打开这个子域名，也是同一套博彩页面。页面里还有： <link rel="amphtml" href="https://<some-project>.pages.dev/" /> 这就解释了 Google 的邮件。canonical 页在 wulujia.com 的某个子域名，AMP 页在 pages.dev，两个域名不一致，所以 Search Console 报 AMP page domain mismatch。 真正的问题在 DNS。 Cloudflare DNS 里有两条历史遗留记录： A * 185.199.111.153 A * 185.199.108.153 * 是 wildcard。意思是所有没有明确配置的子域名，都会解析过去。那两个 IP 是 GitHub Pages 的 IP。 所以链路变成了： <some-subdomain>.wulujia.com -> 命中 *.wulujia.com -> 解析到 GitHub Pages -> 被别人用这个子域名挂了垃圾页 我犯的错误是把 wildcard 当成方便的兜底配置。老站、旧博客、GitHub Pages、Cloudflare 之间迁来迁去，DNS 里留下了这个东西。我以为没主动使用的子域名就没有风险，实际不是这样。DNS 只负责把名字指过去，不管那里是不是我自己的内容。 GitHub Pages 文档里也明确提醒，不要用 wildcard DNS 指向 GitHub Pages，这会带来 domain takeover 风险。 修复方式很简单： 在 Cloudflare DNS 删除 *.wulujia.com 的 wildcard A 记录。 只保留明确需要的子域名，比如 www、blog。 用 dig <some-subdomain>.wulujia.com A 确认异常子域名不再解析。 用 curl -I https://<some-subdomain>.wulujia.com/ 确认博彩页消失。 在 Search Console 的 Removals 里提交 https://<some-subdomain>.wulujia.com/ 前缀移除。 在 AMP 报告里点 Validate Fix。 向 Cloudflare 举报那个 pages.dev 垃圾页。 另一个顺手修的点是 www。它不是这次事故的主因，因为 www 是明确子域名，不会被别人随便接管。但它还指向一个很旧的 GitHub Pages IP，访问时会多跳一次 HTTP。这个应该改成 Cloudflare Redirect Rule： https://www.wulujia.com/* -> https://wulujia.com/$1 然后把旧的 www A 记录清掉。 这事有意思的地方在于，入口只是一封看起来不严重的 AMP 提醒。Google 的说明里也写了，这个 issue 不影响索引和排名。可顺着它往下查，看到的是 DNS 里一个很多年前留下来的坑。 小站也会有基础设施债。尤其是个人域名用得久，GitHub Pages、Cloudflare Pages、Vercel、Netlify 都试过，DNS 最容易变成旧配置博物馆。 这次记下来，主要是提醒自己： 不要把 wildcard DNS 指向任何托管平台，除非非常确定每一级子域都被自己控制。更好的习惯是，需要哪个子域就配哪个子域。 --- # 产品设计框架网站采集 URL: https://wlj.me/posts/pm-frameworks-100/ Published: 2026-05-03 Updated: 2026-05-03 Tags: 产品, Referencepmframe.works 风格和软件工程定律站同款——卡片好看、聚合经典概念。这个收的是产品经理工具箱。 每张卡有作者 / 年份 / 类型 / 适用场景四项元数据。点详情页约 3000 字，含问题定义 / 框架结构 / 历史脉络 / 真实案例 / 实施步骤 / 工具推荐，比软件工程定律站的详情页还深，可以直接当 PM 入行教材用。 下面是完整列表，按站点收录顺序，名字给中英文，说明是我重写的。 # 名称 中文名称 说明 1 Design Thinking 设计思维 共情→定义→构想→原型→测试五步走，从用户出发的创新流程。早期探索新方向时用。 2 User Journey Map 用户旅程地图 把用户使用产品的全过程画成时间线，标出每个触点的体验和情绪。找断点和优化机会。 3 Empathy Map 同理心地图 一张图四象限：用户在看 / 听 / 想 / 做。团队对齐用户画像时用。 4 JTBD 待完成的任务 用户不是买你的产品，是雇你的产品来完成某项任务。用任务而不是用人群定位产品。Christensen 经典。 5 User Interview Five Questions GV 用户访谈五问 Google Ventures 的访谈结构，质性研究入门模板。 6 Kano Model KANO 模型 把功能分成基本型 / 期望型 / 兴奋型，做需求优先级时拿来对照。 7 Service Blueprint 服务蓝图 用户旅程加后台流程一起画。设计含服务、需要前后台协同的产品时用。 8 Contextual Inquiry 情境访谈 到用户实际工作的地方观察他们怎么用产品。隐性需求和"嘴上一套、做的另一套"靠这个发现。 9 Affinity Diagram 亲和图 / KJ 法 把一堆便利贴上的发现按相似度聚类。用户研究后做归纳常用。 10 Diary Study 日记研究 让用户连续几周记录使用情况。习惯类、长周期产品的用户行为研究。 11 Musk Five Steps 马斯克五步法 1) 质疑需求 2) 删 3) 简化 4) 加速 5) 自动化。最容易跳过第一步，最贵的浪费来自做了不该做的事。 12 Five Whys 五个为什么 连问五次"为什么"，挖到根因。Toyota 的传家宝。 13 HMW 如何能够 把问题改写成"我们如何能够……？"，把抱怨变成创意起点。Brainstorm 起手式。 14 POV Statement POV 陈述 Stanford d.school 的格式："[用户] 需要 [需求]，因为 [洞察]"。把洞察固化成一句话用来对齐团队。 15 Issue Tree 议题树 把大问题用 MECE 拆成可独立解的子问题。McKinsey 传家宝。 16 Iceberg Model 冰山模型 看到的事件只是冰山一角，下面还有模式 / 结构 / 心智。系统性问题不要只治表象。 17 Double Diamond 双钻模型 发散-收敛重复两次：先找对问题，再找对方案。British Design Council 经典流程。 18 RCA 鱼骨图根因分析 把可能原因按类别画成鱼骨。质量问题排查老工具。 19 Cynefin Cynefin 框架 把情境分成简单 / 繁杂 / 复杂 / 混乱四种，每种对应不同决策方式。复杂世界的策略选择指南。 20 Jobs Scoping 任务范围 把用户要完成的任务画成完整地图，每一步都是潜在创新点。Ulwick 的 ODI 方法。 21 SCAMPER SCAMPER 替换 / 合并 / 调整 / 改用 / 消除 / 反转 / 重组。改进现有产品的 7 种思路清单。 22 Six Thinking Hats 六顶思考帽 一次只戴一顶帽子（事实 / 情感 / 批评 / 乐观 / 创意 / 控制）。开会少吵架的方法。 23 Reverse Brainstorming 反向头脑风暴 不问"怎么解决"，问"怎么搞砸"。卡壳时换条路。 24 Crazy Eights 疯狂八格 8 分钟画 8 个方案。强制不让你停留在第一个想法。 25 Analogical Thinking 类比思维 从其他领域借结构。Uber = 出租车界的 Airbnb。 26 Value Proposition Canvas 价值主张画布 一边画用户的痛点 / 收益 / 任务，一边画产品的功能 / 缓解 / 创造，对齐两边。商业画布的姊妹篇。 27 How-Now-Wow How-Now-Wow 矩阵 创意按"难易 × 是否常见"分四格：现在做 / 未来做 / 酷想法 / 算了。开完发散会用来收敛。 28 Opportunity Solution Tree 机会-方案树 Teresa Torres 的产品发现工具：目标 → 机会 → 方案 → 实验，画一棵树才能看清取舍。 29 Story Spine 故事脊柱 Pixar 的故事模板：从前… 每天… 直到有一天… 因此… 最终…。讲产品愿景时套这个。 30 TRIZ TRIZ 苏联工程师整理的 40 条发明原理。技术矛盾找对应原理，工程创新老办法。 31 Pain-Solution Matrix 痛点-方案矩阵 用户痛点和方案配对打分。MVP 选哪个先做时用。 32 Lean MVP 精益 MVP 用最小可行产品快速试，靠真实数据验证假设而不是脑补。Eric Ries 的 build-measure-learn。 33 Mental Models 心智模型 用户脑子里以为产品怎么用，和产品实际怎么用之间的差异。差越大可用性越糟。 34 A/B Testing A/B 测试 同一时间两个版本随机分流，数据说话。需要足够样本和明确指标。 35 Assumption Validation Board 假设验证板 把项目所有假设按风险 × 证据排优先级，逐条做实验。David Bland 写过专书。 36 Five-User Usability Test 五用户可用性测试 Nielsen 的发现：5 个用户能找出 85% 的可用性问题。性价比最高的用户测试。 37 Wizard of Oz 绿野仙踪法 用户以为是 AI 在回答，其实是后面有人手工模拟。低成本验证概念可行性。 38 North Star Metric 北极星指标 一个最能反映产品给用户创造价值的核心指标，全公司围绕它对齐。 39 Validated Learning Loop 验证学习循环 想法 → 构建 → 测量 → 学习 → 再想法。精益创业的循环图。 40 Lean Canvas 精益画布 把 Osterwalder 的商业画布改造为创业版：突出问题 / 方案 / 独特价值 / 不公平优势。Ash Maurya。 41 Problem-Solution Fit 问题-方案契合 PMF 之前的台阶：先证明问题真存在、方案真能解，再去找市场。 42 Task Completion Rate 任务完成率 多少用户成功完成了核心任务。可用性测试的硬指标。 43 User Story Map 用户故事地图 横轴用户旅程，纵轴优先级，把 backlog 立体化。比扁平 backlog 更能看到全景。 44 RICE RICE 模型 Reach × Impact × Confidence ÷ Effort，给需求打分排序。Intercom 提的。 45 MoSCoW MoSCoW Must / Should / Could / Won’t 四档。版本规划时强制做减法。 46 Impact-Effort Matrix 影响-投入矩阵 二维四象限：高影响低投入先做。最简单的优先级工具。 47 Sprint Scrum Sprint 1-4 周固定周期交付可工作的增量。敏捷开发的基本节拍。 48 Google Design Sprint Google 设计冲刺 5 天从问题到原型到测试。Jake Knapp 在 GV 的方法，《Sprint》一书。 49 Shape Up Shape Up Basecamp 的产品流程：6 周一个 cycle，做完整功能而不是 sprint 切片。小团队远程友好。 50 Now-Next-Later Now-Next-Later 路线图三档代替具体日期，避免承诺地狱。 51 DACI DACI Driver / Approver / Contributors / Informed，跨部门决策时谁说了算。 52 ICE ICE 评分 Impact × Confidence × Ease，比 RICE 更轻量。 53 OGSM OGSM Objectives / Goals / Strategies / Measures，宝洁的战略落地框架，OKR 出现前的同类工具。 54 CIRCLES CIRCLES 法 Lewis Lin 整理的产品面试答题结构：理解情境 / 列举用户 / 砍需求 / 排优先级 / 拿方案 / 概括 / 总结。 55 Working Backwards 逆向工作法 Amazon 的"先写新闻稿、再开发产品"流程。强制从用户视角想清楚价值。 56 Event Storming 事件风暴 把领域事件用便利贴贴满墙，从事件倒推命令、聚合、上下文边界。DDD 复杂业务建模法。 57 AARRR 海盗指标 Acquisition / Activation / Retention / Referral / Revenue。增长五步漏斗。 58 Growth Flywheel 增长飞轮 不是漏斗的线性，而是闭环：每一圈让下一圈更省力。Amazon 经典飞轮。 59 Hook Model 上瘾模型 触发 → 行动 → 可变奖励 → 投入，循环让用户养成习惯。Nir Eyal《Hooked》。 60 PMF 产品-市场契合 Marc Andreessen 的"40% 用户失去你会非常失望"。没有 PMF 增长都是假的。 61 Competitive Positioning Map 竞争定位图 二维坐标把竞品撒上去，找空白。Porter 经典工具。 62 Blue Ocean ERRC 蓝海 ERRC 消除 / 减少 / 提升 / 创造，跳出红海四个动作。Kim & Mauborgne。 63 LTV / CAC LTV / CAC 用户终身价值除以获客成本，比值决定增长是否健康。3:1 是常见目标。 64 GTM 上市策略 新产品上市的渠道、定价、节奏、目标客户组合。 65 Network Effects 网络效应 用户越多产品越值钱。NFX 把它分成 17 种不同子类型。 66 StoryBrand StoryBrand 七步 把品牌沟通套进英雄故事公式：用户是英雄，品牌是向导。Donald Miller 的营销框架。 67 STP STP 营销定位 Segmentation / Targeting / Positioning，Kotler 教科书三步。 68 Fogg Behavior Model 福格行为模型 行为 = 动机 × 能力 × 触发器，三者同时具备才发生。BJ Fogg 在斯坦福多年研究。 69 JTBD Growth Matrix JTBD 增长矩阵 把用户的任务和满足度交叉，找未满足的高价值任务作增长机会。 70 Empathy-Driven Roadmap 同理心驱动路线图 Teresa Torres 主张：路线图按用户痛点排序，而不是业务方要求排。 71 First Principles 第一性原理 把问题拆到不可再分的物理事实，从底层重新搭。马斯克常说，亚里士多德最早提的。 72 Systems Thinking 系统思维 看反馈环、延迟、库存而不只是事件。Donella Meadows《系统之美》。 73 Wardley Mapping Wardley Mapping 横轴技术成熟度（自创建到商品化），纵轴价值链。看技术战略和 … --- # 软件工程定律网站采集 URL: https://wlj.me/posts/laws-of-software-engineering/ Published: 2026-05-03 Updated: 2026-05-03 Tags: 软件工程, Referencelawsofsoftwareengineering.com 这个站做得很漂亮，配色、卡片排版都挺花心思。 首页每张卡片一句话，点进去详情页约 1300 字，含定义 / Takeaways / 例子 / 出处 / 推荐阅读 / 相关定律。 内容都是 Wikipedia 上能查到的经典概念，没有原创理论。它的价值是集中收纳、视觉好看、结构化重述，不是新见解。当 reference 用足够，当 insight 没什么。 学习一些名词也挺好。下面给中英对照，中文是严格按英文翻译的，不扩写。 # 名称 英文描述 中文描述 1 Conway’s Law 康威定律 Organizations design systems that mirror their own communication structure. 组织设计的系统会反映其自身的沟通结构。 2 Premature Optimization 过早优化 Premature optimization is the root of all evil. 过早优化是万恶之源。 3 Hyrum’s Law 海勒姆定律 With a sufficient number of API users, all observable behaviors of your system will be depended on by somebody. 当 API 用户数量足够多时，系统所有可观察到的行为都会被某人依赖。 4 The Boy Scout Rule 童子军规则 Leave the code better than you found it. 让代码比你来时更好。 5 YAGNI 你不会用到的 Don’t add functionality until it is necessary. 在功能必要之前不要添加它。 6 Brooks’s Law 布鲁克斯定律 Adding manpower to a late software project makes it later. 给延期的软件项目增加人手会让它更晚。 7 Gall’s Law 盖尔定律 A complex system that works is invariably found to have evolved from a simple system that worked. 能运转的复杂系统，无一例外是从能运转的简单系统演化而来的。 8 The Law of Leaky Abstractions 抽象漏洞定律 All non-trivial abstractions, to some degree, are leaky. 所有非平凡的抽象，都在某种程度上有漏洞。 9 Tesler’s Law 泰斯勒定律 Every application has an inherent amount of irreducible complexity that can only be shifted, not eliminated. 每个应用都有一定量不可削减的固有复杂度，只能转移，不能消除。 10 CAP Theorem CAP 定理 A distributed system can guarantee only two of: consistency, availability, and partition tolerance. 分布式系统只能在一致性、可用性、分区容忍性中保证两项。 11 Second-System Effect 第二系统效应 Small, successful systems tend to be followed by overengineered, bloated replacements. 小而成功的系统之后，往往跟着过度工程、臃肿的替代品。 12 Fallacies of Distributed Computing 分布式计算谬误 A set of eight false assumptions that new distributed system designers often make. 分布式系统新手常犯的八条错误假设。 13 Law of Unintended Consequences 意外后果定律 Whenever you change a complex system, expect surprise. 每当你改动一个复杂系统，都要预期会有意外。 14 Zawinski’s Law 扎文斯基定律 Every program attempts to expand until it can read mail. 每个程序都会扩张到能收发邮件为止。 15 Dunbar’s Number 邓巴数 There is a cognitive limit of about 150 stable relationships one person can maintain. 一个人能维持的稳定关系存在约 150 人的认知上限。 16 The Ringelmann Effect 林格尔曼效应 Individual productivity decreases as group size increases. 群体规模增大时，个人生产力下降。 17 Price’s Law 普赖斯定律 The square root of the total number of participants does 50% of the work. 参与者总数的平方根的人，完成 50% 的工作。 18 Putt’s Law 普特定律 Those who understand technology don’t manage it, and those who manage it don’t understand it. 懂技术的人不管理技术，管理技术的人不懂技术。 19 Peter Principle 彼得原理 In a hierarchy, every employee tends to rise to their level of incompetence. 在层级体系中，每个员工都倾向于上升到其不胜任的层级。 20 Bus Factor 巴士因子 The minimum number of team members whose loss would put the project in serious trouble. 失去之后会让项目陷入严重麻烦的最少团队成员数。 21 Dilbert Principle 呆伯特原理 Companies tend to promote incompetent employees to management to limit the damage they can do. 公司倾向于把不胜任的员工提到管理岗，以限制他们能造成的损害。 22 Parkinson’s Law 帕金森定律 Work expands to fill the time available for its completion. 工作会扩张到填满可用于完成它的时间。 23 The Ninety-Ninety Rule 九十-九十法则 The first 90% of the code accounts for the first 90% of development time; the remaining 10% accounts for the other 90%. 前 90% 的代码占前 90% 的开发时间；剩下 10% 的代码占另外 90% 的开发时间。 24 Hofstadter’s Law 侯世达定律 It always takes longer than you expect, even when you take into account Hofstadter’s Law. 它总是比你预期的更久，即使你已经把侯世达定律考虑进去。 25 Goodhart’s Law 古德哈特定律 When a measure becomes a target, it ceases to be a good measure. 当一个衡量指标成为目标时，它就不再是一个好指标。 26 Gilb’s Law 吉尔布定律 Anything you need to quantify can be measured in some way better than not measuring it. 任何你需要量化的东西，都能以某种比不衡量更好的方式被衡量。 27 Murphy’s Law / Sod’s Law 墨菲定律 Anything that can go wrong will go wrong. 任何可能出错的事都会出错。 28 Postel’s Law 波斯特尔定律 Be conservative in what you do, be liberal in what you accept from others. 自己发出的要保守，接受别人的要宽容。 29 Broken Windows Theory 破窗理论 Don’t leave broken windows (bad designs, wrong decisions, or poor code) unrepaired. 不要让破窗（糟糕的设计、错误的决策或差的代码）放着不修。 30 Technical Debt 技术债 Technical Debt is everything that slows us down when developing software. 技术债就是开发软件时一切让我们变慢的东西。 31 Linus’s Law 林纳斯定律 Given enough eyeballs, all bugs are shallow. 只要有足够多的眼睛，所有 bug 都是浅显的。 32 Kernighan’s Law 柯尼汉定律 Debugging is twice as hard as writing the code in the first place. 调试的难度是最初写代码难度的两倍。 33 Testing Pyramid 测试金字塔 A project should have many fast unit tests, fewer integration tests, and only a small number of UI tests. 一个项目应该有大量快速的单元测试、较少的集成测试，以及只有少量的 UI 测试。 34 Pesticide Paradox 农药悖论 Repeatedly running the same tests becomes less effective over time. 反复运行相同的测试，随着时间推移会越来越无效。 35 Lehman’s Laws of Software Evolution 莱曼软件演化定律 Software that reflects the real world must evolve, and that evolution has predictable limits. 反映真实世界的软件必须演化，而这种演化有可预测的极限。 36 Sturgeon’s Law 斯特金定律 90% of everything is crap. 任何东西的 90% 都是垃圾。 37 Amdahl’s Law 阿姆达尔定律 The speedup from parallelization is limited by the fraction of work that cannot be parallelized. 并行化带来的加速比，受限于无法并行的那部分工作的比例。 38 Gustafson’s Law 古斯塔夫森定律 It is possible to achieve significant speedup in … --- # browser-use 团队又出了一个东西，叫 bux URL: https://wlj.me/posts/bux-browser-use-box/ Published: 2026-05-01 Updated: 2026-05-01 Tags: AI, Toolsbrowser-use 团队最近又放了一个新项目：bux，全名 Browser Use Box。 它解决的问题很具体：现在所有 AI 助手都绑在你设备上，合上电脑就死。bux 把 Claude Code 加一个真实 Chromium 浏览器，再加一个 Telegram 机器人，打包成一条安装脚本，扔到任何一台 5 美元的 VPS 上跑起来。 跑起来之后是什么效果？早上你在地铁上发一条 Telegram，“看看今天未读邮件，回那条 LinkedIn 消息说不感兴趣”，下班前活已经干完了。机器一直开着，账号一直登着，不用你守在电脑前。 三个细节我觉得做得对。 第一，用真实 Chromium，不是 headless 浏览器。Cookie、登录态都持久化在服务器上，账号一直在线。 第二，遇到验证码、2FA、登录墙的时候不硬刚。它会生成一个实时页面 URL 推给你，你点开手动过验证，AI 接着干。大多数自动化工具死在这一步——硬刚就被风控、被封号。bux 直接承认这件事 AI 做不了，让人来。 第三，整个架构就三个 systemd 服务：Telegram 机器人收消息，喂给 Claude，调浏览器。状态全在 /home/bux 一个目录里，重启不丢。打开看一眼就知道每个零件在哪。 安装是一条 curl 命令，三分钟从空白 VPS 到能用。 browser-use 主项目 GitHub 6 万多 star，bux 又是 Claude Code 加 Telegram 加云端浏览器一条龙打包好。这个团队战斗力真的强。 --- # GitNexus 这类工具，大概率不需要 URL: https://wlj.me/posts/gitnexus-impression/ Published: 2026-05-01 Updated: 2026-05-01 Tags: AI, Tools看了一下 GitNexus，一个把代码仓库索引成知识图谱、再通过 MCP 喂给 Claude Code / Cursor / Codex 的工具。 它解决的是一个具体的人的具体问题：写大型项目的工程师，让 AI 帮忙改代码时，经常遇到 AI 改了 A 函数、没注意到 B、C、D 也调用它。一次小改动，跑起来三处崩。 为什么会这样？AI 不是不会读代码，是不知道该读哪些。Context window 再大，AI 自己也不会主动把整个仓库塞进去，成本太高。grep 能找调用方，但要 AI 自己想到去 grep，还得来回跑好几轮。调用链一深，就漏。 GitNexus 的做法是预先把每个函数、每条依赖、每条调用链都建好图。AI 要改一个函数，先查图：谁调用我、我调用谁、改了会炸到哪里。一次查询出结果，不用反复读文件。 但我的判断是，大多数人不需要装这类工具。 过去半年 Claude Code、Cursor、Codex 这批 AI coding 工具进步得很快。grep、glob、Read 这些基础工具调度得很熟，subagent 可以预先装"探索代码"的 SOP，写好一份 CLAUDE.md 把架构地图、关键模块、依赖关系交代清楚，AI 漏改调用方的事故已经少了很多。原本 GitNexus 想解决的痛，AI 工具自己在解决。 什么时候才值得试？我的顺序是这样： 先调 AI 工具本身。CLAUDE.md 写清楚架构地图、关键模块、依赖关系，subagent 装好探索代码的 SOP，每次改代码前要求 AI 先列出受影响的调用方。这些都是免费的，先做。 做完还在频繁踩坑，再考虑 GitNexus 这类工具。频繁是多频繁？一周两三次都不够，得是改代码的过程里反复出事故、CLAUDE.md 怎么写都救不回来，才值得多装一个工具。 大多数人不会走到这一步。痛感真到那个程度，往往不是 AI 工具的问题，是项目本身的复杂度已经超出了人脑+AI 配合的舒适区。那时候装 GitNexus 也只是缓解，不是根治。 所以结论很简单：先把手上的 AI coding 工具用透，再去看新工具。 --- # Tritree：把写作变成 3 选 1 的工具 URL: https://wlj.me/posts/tritree-three-choice-writing/ Published: 2026-04-29 Updated: 2026-04-29 Tags: ai, tools, writing刷到一个小工具，叫 Tritree。 打开它不是给你一个空白框让你写提示词，而是 AI 一次给三个方向不同的稿子，你点一个，它接着长出下一轮三个。没选的折叠成树枝留在画布上，想回去看随时回得去。本地跑，SQLite 存数据，没登录没订阅。 作者用它写了一条微博，三轮，每轮点一下，就出来了。 --- # 每天午睡 30 分钟以内，不用调整 URL: https://wlj.me/posts/short-nap-is-fine/ Published: 2026-04-27 Updated: 2026-04-27 Tags: Health, Life看到一篇梅斯医学的公众号文章《经常午睡，中风风险涨24%？》，标题挺吓人——“经常午睡中风风险高 24%"、“每周 1-2 次、每次 30 分钟最健康”。我是有午睡习惯的人，每天 30 分钟以内，看完想确认一下：这个习惯到底要不要调整。 文章里的数据怎么来的 文章拼了三个研究： GeroScience，列日大学：老年人减少午睡，言语情景记忆衰退变缓 Hypertension，湘雅：UK Biobank 数据，“经常午睡"者高血压风险 +12%、中风 +24% Heart，瑞士：3462 人追踪 5 年，每周午睡 1-2 次的人心血管事件低 48% 然后得出结论：“每周 1-2 次、每次不超过 30 分钟最健康。” 这个结论站不住的几个点 三个研究人群不一样、指标不一样，不能直接拼。 列日那篇是老年人；湘雅那篇是中老年欧洲人；瑞士那篇是中年人。把它们的结论叠在一起得出一个"最优处方”，是文章作者的综合，不是任何一篇原研究的结论。 湘雅那篇只统计了午睡频率，没统计午睡时长。 文章自己在脚注里承认了。所以"经常午睡 +24% 中风风险"里的"经常午睡”，到底是 20 分钟还是 2 小时——研究里没数据。被归到"经常午睡"组的人里大量是长午睡（>1 小时）的人，他们更可能有未诊断的睡眠呼吸暂停、慢性病——这些才是真正的中风风险来源。 因果方向很可能反了。 研究者自己也提到：白天频繁犯困、需要长午睡，往往是因为夜间睡眠质量差，或者本身已经有未诊断的健康问题。所以"午睡多 → 中风高"很可能是反向因果——身体已经出问题的人更容易困、更需要长睡，而不是午睡本身把人睡出了高血压和中风。 +24% 是相对风险。 如果基线中风风险是 1%，涨 24% 之后是 1.24%，绝对增量很小。媒体标题不会告诉你这个。 30 分钟以内的午睡是被研究支持的 睡眠周期大约 90 分钟，前 20-30 分钟是浅睡（N1、N2 阶段）。30 分钟内醒来，不会陷入深睡眠（N3），所以不会有 sleep inertia——醒来不昏沉。 一旦超过 30 分钟、特别是 45-60 分钟之间，会掉进深睡眠然后被强行打断，这才是"长午睡有害"研究指向的状态。 文章自己引用的约翰霍普金斯那篇综述（J Gerontol A Biol Sci Med Sci, 2023）结论就是：短午睡（≤30 分钟）与更好的认知、更低的认知衰退风险相关。 我的结论 每天 30 分钟以内的午睡，属于 power nap，是健康模式，不用调整。 值得自检的只有两点： 晚上睡眠质量。如果晚上睡得好、白天主动安排 30 分钟休息——这是健康模式。如果晚上睡不深、白天必须靠午睡续命，要查的是夜间睡眠（呼吸暂停？入睡太晚？），不是午睡本身。 午睡时间点。13:00-15:00 之间，不要拖到 16:00 之后，否则影响夜间入睡。 文章建议的"每周不能超过 1-2 次"那个频率限制没什么强证据，每天都睡 30 分钟以内是 OK 的。 --- # Bitwarden CLI npm 包被投毒，AI 编码工具凭证成新目标 URL: https://wlj.me/posts/bitwarden-cli-supply-chain-attack/ Published: 2026-04-27 Updated: 2026-04-27 Tags: AI, Security, TechThe Hacker News 报道了一起 npm 供应链攻击：Bitwarden CLI 的 npm 包（@bitwarden/cli）2026.4.0 版本被植入恶意代码，藏在包内的 bw1.js 文件里。 感染窗口从 4 月 22 日 ET 时间下午 5:57 到 7:30，约 1.5 小时，估计 334 次下载。被怀疑是更大规模 Checkmarx 供应链攻击的一部分，归因到 “Shai-Hulud: The Third Coming” 这一波。 攻击路径 攻击者拿下了 Bitwarden CI/CD 流水线里一个被入侵的 GitHub Action（checkmarx/ast-github-action），通过 preinstall 钩子在用户 npm install 时执行恶意代码。 据安全研究员 Adnan Khan 说，这可能是首次使用 npm Trusted Publishing 的包遭到入侵。 恶意代码偷什么 本地开发凭证：GitHub / npm tokens、.ssh 密钥、.env 文件、shell 历史 云端密钥：GitHub Actions 环境变量、CI/CD secrets、多云凭证 AI 编码工具配置：Claude、Kiro、Cursor、Codex CLI、Aider 的认证配置 自传播：偷到 GitHub token 后注入恶意 Actions workflow，用偷到的 npm 凭证向下游包发布恶意版本，蠕虫式扩散 数据外泄走 AES-256-GCM 加密发到伪装域名 audit.checkmarx[.]cx，失败后以 GitHub commit 作为 fallback 有一个细节：如果系统 locale 是俄罗斯，恶意代码自动退出。这一行为与原始 Checkmarx 攻击不一致。 对开发者的影响 以前担心的是 SSH 私钥和云服务 key，这次攻击者把 Claude、Cursor、Codex CLI 这些 AI 工具的凭证写进了目标列表。Anthropic 和 OpenAI 的 API key 也是高价值目标了。 中招了怎么办 如果在 4 月 22 日那 1.5 小时窗口里 npm install @bitwarden/cli 装到了 2026.4.0，按 Bitwarden 官方流程：卸载 2026.4.0，清理 npm 缓存，临时禁用 npm install 脚本，检查 IoC，轮换所有可能暴露的密钥，审计 GitHub 活动和 CI workflow，最后安装 2026.4.1（即 2026.3.0 的重新发布版）。 重点要轮换的密钥： AI 工具的 API key：Claude API key、Cursor 配置、Codex CLI 凭证 GitHub Personal Access Token 和 CI 用的 token npm 发布凭证 .env 里的云服务密钥 没设 passphrase 的 SSH 私钥 防御加固 给 npm install 默认加 –ignore-scripts，或者 pnpm 设 enable-pre-post-scripts=false 重要项目用 npm install –frozen-lockfile 锁版本 AI 工具的凭证用专门的 secret manager，不要直接放 .env GitHub token 加最小权限和短过期时间 Bitwarden 官方说没证据表明用户密码库被访问或泄露——这次被针对的是开发者，不是 Bitwarden 的最终用户。 --- # YC：怎么从零打造一家 AI 原生公司 URL: https://wlj.me/posts/20260427-yc-ai-native-company-from-scratch/ Published: 2026-04-27 Updated: 2026-04-27 Tags: AI, 创业, 翻译 翻译自 YC 合伙人 Diana 的演讲：How To Build A Company With AI From The Ground Up，2026 年 2 月。我按自己的语感重新整理了一遍，方便中文读者读起来不卡。 我是 Diana，YC 的合伙人。 过去几个月我看清了一件事：AI 不只是让软件造得更快，也不只是让某些工作流自动化。它正在从根本上改变创业公司应该怎么跑——什么人留下、什么岗位消失、什么产品现在能造出来。 这一期我要讲创始人应该怎么思考"AI 原生公司"——团队该有什么角色、内部该用什么具体做法，让你立刻就能跑得更快。 AI 不是工具，是操作系统 现在大多数人聊 AI 都还停留在"提高生产力"这一层：让工程师更高效、给现有流程接个 AI 助手、多发几个功能。 这个框架完全错过了正在发生的事。 我们看到的不是"效率提升"，是全新的能力：今天一个对的人加上 AI 工具，能做出过去要一整个团队才能做、或者根本做不出来的东西。 把 AI 想成"新能力"，对创始人意味着什么？ 往大了说：AI 不应该是你公司在用的工具，应该是你公司运行的操作系统。每一个工作流、每一个决策、每一个流程，都应该流经一个持续学习、持续改进的智能层。 具体一点：你公司里每一个重要流程，都应该被一个智能闭环包住。闭环捕捉信息、把信息喂回智能系统、让流程随时间变得更好。 开环还是闭环？ 学过控制论的人对这两个词不陌生。 开环：被控制的系统没有反馈。在过去，公司基本都是开环——你拍板、你执行，但不一定系统性地测量结果、不一定把结果回写到流程里。开环本质就是有损的。 闭环：自我调节。系统持续监测自己的输出、持续调整流程，让结果越来越接近目标。闭环在"准确性"和"稳定性"上极强。 有了能自我改进的智能体，你的公司就该按闭环来跑。 让公司对 AI 可查询 要让闭环跑起来，你得让整个公司可被查询。换句话说，整个组织对 AI 是可读的。每一个重要的动作都要产生一份可被读取的记录，让公司中央的智能层能从中学习、能用来自我改进。 具体怎么做： 所有会议都用 AI 记录下来 减少私聊和邮件，把智能体嵌入所有沟通渠道 自建仪表盘把公司里的所有数据接进去：营收、销售、工程、招聘、运营——全部 给智能体同时接入：项目工单系统、所有工程聊天频道、所有客户反馈（来自邮件或客服系统）、代码仓库、文档系统里的高层计划、销售电话录音、每日站会 我举个具体例子。工程管理和迭代规划。 如果你的智能体能同时访问：你的工单、所有工程频道、来自邮件和客服系统的所有反馈、代码仓库、文档里的高层计划、销售电话录音、每日站会——那它就能告诉你上一轮迭代实际交付了什么、是不是真的满足客户需求。 更进一步：在拥有"上线了什么、什么成了、什么没成"的完整可见性之后，智能体可以往前看，给工程师提出远比拍脑袋更可预测、更准确、更跟得上节奏的下一轮迭代计划。 那种被各级经理塞水状态汇报、信息一路衰减的日子，过去了。 我自己带过工程团队，现在又在多家 YC 公司里看到这件事——这是个颠覆性变化。过去需要持续协调才能维持的东西，默认就变得可读、可查询。我看到的团队里，有些把迭代时间砍掉了一半，相同时间内做的事接近 10 倍。 整体原则就一句话：要让模型把全部能力发挥出来，你得给它和员工同等量级的上下文。 做到这点，公司就不再是一个信息碎片化、靠人工拼解读的开环——而是变成一个闭环系统。状态、决策、结果被持续捕捉，被回写进智能层。结果是这个系统永远对"现在到底在发生什么"保持最新视角。 AI 软件工厂 跑速度最快的公司，正在出现一种新范式：AI 软件工厂。 熟悉测试驱动开发的人会觉得亲切——这是它的下一代。 在 AI 软件工厂里： 人写规范，再写一组定义"成功"的测试 AI 智能体生成实现代码，反复迭代直到测试通过 人定义要造什么、判断输出合不合格；写代码本身是智能体的事 有些公司已经把这件事推到了极致——他们的代码仓库里没有手写代码，只有规范和测试集。 Strong Compute 的 AI 团队就是个好例子。他们的终极目标，是建一个根本不再需要人来写代码或审代码的系统。所以他们造了自己的软件工厂：用规范加场景化的验证驱动智能体写测试，再让智能体在代码上反复迭代，直到达到一个概率性满意阈值，跑通为止。 Steve Jay 提的"千倍工程师"，就是这么实现的——让一个工程师被一整套智能体系统包围，能造出他过去根本造不出的东西。 千倍、甚至万倍工程师的时代，已经到了。 中层管理可以取消了 按"闭环 + 可查询 + 软件工厂"这套搭出来的公司，会带来一个直接后果：经典的管理层级不再有意义。 旧世界你需要中层经理和协调者，把信息低效地在组织里上下传递。新世界里——智能层就是这个角色。 如果你的公司是可查询的、记录丰富的、对 AI 是可读的，那你几乎不应该有任何"人类中转层"。 为什么这件事重要？你公司的速度，等于你信息流动的速度。每去掉一层人类路由，你就直接得到一次速度提升。 Jack Dorsey 在 Block 就在这么做。他深度上手了这些工具之后，得出了和很多人一样的结论：这件事远不止是"渐进式效率提升"。 他的判断是：如果你保留旧的组织架构和管理结构，你就完全错过了这次变革。公司本身必须被重建为一个智能层，由人类在边缘引导它，而不是当中转节点。 Jack 提出，未来每家公司只剩三种员工原型： 角色 定义 关键特征 建造者 / 操作者 直接动手做事和运营的人 不限工程师。做运营、客服、销售的人，每个都要会动手造。开会带原型，不带演示文稿 直接负责人 对战略和客户结果负责 不是经典经理，是对结果有清晰责任的人。一人一结果，无处可藏 AI 创始人 仍然亲自造、亲自带、亲自示范 如果你是创始人，这必须是你——站到最前面，让团队亲眼看到能力跃迁是什么样。不能把 AI 战略外包给别人 按这套结构搭起来的公司，用更小的团队拿到放大很多倍的结果。 最关键的一次心态转换：最大化算力消耗，不是最大化人头。最好的公司是把算力用满的公司。 把这个权衡想清楚：一个手里有 AI 工具的人，能干过 AI 之前公司里一整支大型工程团队。也就是说——工程、设计、人事、行政，都该比以前精瘦得多。 所以你应该心安理得地承受一张高得让你不舒服的接口账单——它替代的，是远更贵、远更臃肿的人头成本。 别外包你对工具的信念 但别只听我的。 你没办法把"对这些工具有多强大"这件事的信念外包出去。你只能自己亲自坐下来用编码智能体，用到你对"现在到底能造出什么"的旧观念被打破为止。 如果你是早期创始人，这一点上你有巨大优势。你没有遗留系统、没有臃肿的组织架构、没有几千个员工要重新培训。你足够小，可以从第一天起就把公司搭对。 存量公司是反过来的。它们要一边维护和扩张已经在跑的产品，一边解构沉淀了多年的标准操作流程和"软件应该怎么做"的核心假设。有些大公司能靠内部隔离小队——和主营业务隔离，从零造 AI 原生系统——绕过这个问题。Mutiny 是一个不错的例子。但对大多数大公司来说，每一次对核心流程的改动，都可能弄坏一个已经在跑的东西。 所以从结构上看，这些大公司转型成 AI 原生，会非常困难。 创业公司没有这个负担。这是一个非常大的优势。从设计、工作流、文化都按 AI 来构建——结果是，你能跑得比老牌企业快上一千倍。 --- # macOS 的 cron 和 launchd URL: https://wlj.me/posts/macos-cron-launchd/ Published: 2026-04-24 Updated: 2026-04-24 Tags: Tech今天在终端收到一封 cron 发来的邮件，说某个脚本 “Operation not permitted”。查下去是两个问题合在一起，顺手也把 cron 和 launchd 在 macOS 上的差别重新过了一遍。 先看今天这件事 我有三个用 cron 跑的定时任务：每小时 15 分把知识库备份到 git，每小时 20 分刷新知识库的向量索引，每天早 9 点跑一次健康检查。 有一天开始，前两个任务悄无声息失败。打开日志才看见： /bin/bash: .../brain-git-backup.sh: Operation not permitted /bin/bash: gbrain: command not found 第一个是权限拦截——脚本文件在 ~/Library/CloudStorage/Dropbox/ 里，macOS 的隐私系统（TCC）不让 cron 碰 iCloud、Dropbox 这种云端同步目录下的文件。 第二个是 PATH 问题。cron 跑的 bash 是个干净的非交互 shell，.zshrc 里配置的 PATH 不会加载，gbrain 找不到。 cron 和 launchd 是什么 两者都是"定时工具"——让系统在指定时间跑一段命令。 cron 是 Unix 时代的老工具，几十年历史，Linux、Mac 都有，写一行配置就能用。 launchd 是苹果自己做的调度系统，2005 年随 macOS 10.4 推出。现在苹果系统里所有后台服务，包括 cron 本身，都归 launchd 管。 cron 在 macOS 上的状态 从 macOS 10.4 起，cron 被标为 “deprecated”。系统里它依然可用，但实际是由 launchd 拉起的一个兼容进程（/System/Library/LaunchDaemons/com.vix.cron.plist）。之后新加的一些系统能力，接到 launchd 而没有接到 cron 上，比如 TCC 权限的细粒度授权，和 log 命令里的子系统筛选。 每个任务单独授权 cron 只有一个进程 /usr/sbin/cron，所有定时任务都跑在它底下。给 cron 开"完全磁盘访问"权限，等于一次性给所有 cron 任务都开了。要么全开，要么全关。 launchd 不一样。每个任务是一个独立的 “agent”，放在 ~/Library/LaunchAgents/ 下的一个 plist 文件： ~/Library/LaunchAgents/com.luca.brain-backup.plist ~/Library/LaunchAgents/com.luca.brain-sync.plist ~/Library/LaunchAgents/com.luca.brain-health.plist 系统把每个 agent 当成独立程序，可以单独授权、单独关、单独看日志。 plist 大概长什么样 就是一个 XML 文件。比如"每小时 15 分跑一次 brain-git-backup.sh"： <?xml version="1.0" encoding="UTF-8"?> <plist version="1.0"> <dict> <key>Label</key> <string>com.luca.brain-backup</string> <key>ProgramArguments</key> <array> <string>/bin/bash</string> <string>/Users/lucawu/Dropbox/Github/Luca/script/brain-git-backup.sh</string> </array> <key>StartCalendarInterval</key> <dict> <key>Minute</key> <integer>15</integer> </dict> <key>StandardOutPath</key> <string>/Users/lucawu/.brain-git-backup.log</string> <key>StandardErrorPath</key> <string>/Users/lucawu/.brain-git-backup.log</string> </dict> </plist> 写好丢进 ~/Library/LaunchAgents/，跑一下 launchctl load <plist 路径>，就开始工作了。 launchd 还有几个 cron 做不到的事 睡眠期间错过的任务能补跑。cron 直接跳过，launchd 电脑醒来会补一次 进程挂了能自动重启，加一行 KeepAlive 就行 可以监听文件变化触发。比如某个文件夹一有新文件就跑脚本，不一定按时间 日志接到系统 log 命令，用 log show --predicate 'subsystem == "com.luca.brain-backup"' 能按服务筛 那今天我迁走了吗 没有。三个任务用 cron 也能跑好，只要把 PATH 显式写到 crontab 顶部，再给 /usr/sbin/cron 加一次完全磁盘访问权限，两个问题都解决。 迁 launchd 是为将来准备的——等到任务多了想分开管、想让睡眠错过的任务补跑、想让某个任务挂掉自动重启，那时候再迁不迟。 --- # herdr 是干什么的 URL: https://wlj.me/posts/20260422-herdr-ai-agent-workspace/ Published: 2026-04-22 Updated: 2026-04-22 Tags: AI, Toolsherdr 是一个给 AI coding agent 用的终端工作区管理器。 它自己也有 workspace、tab、pane，能分屏、切换、恢复 session。只看这一层，它很像 tmux。 它和 tmux 的区别，在另一层。 tmux 管的是终端会话。herdr 除了管会话，还会识别 pane 里跑的是不是 agent，再把状态标出来。README 里列出的状态有四类：working、blocked、done、idle。 比如同时开几个 pane： 一个 pane 跑 Claude Code 一个 pane 跑 Codex 一个 pane 跑开发服务器 一个 pane 看日志 tmux 可以把这些 pane 摆好，也可以后台挂着。herdr 额外做的是：识别哪个 pane 里在跑 agent，哪个 agent 在忙，哪个在等输入，哪个已经停下来。 它判断状态主要靠两种方式。 第一种，看前台进程和终端输出。 第二种，接工具自己的 hook 或 plugin。文档里已经写明支持给 Claude Code、Codex、pi、OpenCode 装集成，这样状态报告会更直接。 除了给人看，herdr 还有本地 socket API。agent 自己也可以调用这些接口，比如： 新开 workspace 新开 tab 分一个 pane 读另一个 pane 的输出 往另一个 pane 发命令 等另一个 agent 完成 所以它不只是“把几个终端摆在一起”，还多了一层对 agent 的状态管理和控制。 这个工具更适合这样的场景： 已经在终端里工作 已经开始同时跑多个 agent 需要知道哪个 agent 卡住了，哪个做完了 如果平时只开一个 agent，加几个普通 shell，tmux 一般就够了。 截至 2026-04-22，herdr 最新 release 是 v0.5.0，支持 macOS 和 Linux，README 里列出的已测试工具包括 Claude Code、Codex、pi、OpenCode、amp、droid。 --- # 用 Slidev 做视频的方案 URL: https://wlj.me/posts/slidev-markdown-to-video/ Published: 2026-04-21 Updated: 2026-04-21 Tags: slidev, video方军发了一段文字： 内容用 markdown；画面用 slidev 制作，可以加兼容 vue 的网页效果；音频写在 slidev 的 speaker note 里，然后转成音频；slidev 自动播放，由音频往前推动，形成视频的感觉；录制视频用 obs（在 slidev 里写了 addon，一键驱动）。 我没完全看懂，问了 Claude 搞清楚了。 Slidev 原生提供：Markdown 写幻灯片、speaker notes（HTML 注释 <!-- -->）、Vue 组件、键盘翻页、演讲者模式。 需要自己写的三块： TTS：解析 slides.md，把每页 notes 转成 audio/slide-N.mp3 音频驱动翻页：Vue 组件监听当前页，播对应 mp3，audio.ended 后调 nav.next() OBS 录制：OBS 28+ 内置 WebSocket，浏览器直接连 ws://localhost:4455 就能控制 StartRecord / StopRecord --- # 让每个 AI 助手的对话都进我的记忆系统 URL: https://wlj.me/posts/multi-agent-history-parser/ Published: 2026-04-21 Updated: 2026-04-21 Tags: Tech, AI, Tools, Claude我维护着一个叫 context 的个人上下文系统：一份中心 markdown，分发到 Claude Code、Codex CLI、Gemini CLI、OpenClaw 的配置路径里，保证同一个"我"在各个工具之间一致。 这个系统每天自动扫当天的对话，把我说过的偏好、决策、踩坑提炼到 OBSERVATIONS.md。问题是——它只懂 Claude Code 一家的 JSONL 格式。我同时还在用 Codex、Gemini、OpenCode，这些对话历史全都被扔在一边。 每家 AI 助手的对话都存在本地，但格式各家不同。Claude 用 JSONL，Codex 也用 JSONL 但 schema 不一样；Gemini 用整块 JSON；OpenCode 用 SQLite，message 和 part 分两张表；Cline 和 Cursor 藏在 VSCode 扩展的 globalStorage 里；Aider 干脆写在项目目录的 markdown 里。 自己从零逆向这些格式，不是我想干的活。 在 GitHub 上撞见 jhlee0409/claude-code-history-viewer，简称 CCHV。本意是个桌面历史查看器——七家 AI 助手的对话在一个界面里翻。我对桌面 app 本身不感兴趣，但它的 Rust 源码里有一个 providers/ 目录：七个文件，每家一个解析模块。每家的存储路径它替我找好了，每种格式的 schema 它替我逆向完了。 让 AI 把这部分代码翻成 Python，挪进 context 项目。 --- # 一个覆盖中文互联网的 AI Agent 人格库 URL: https://wlj.me/posts/agency-agents-repo/ Published: 2026-04-20 Updated: 2026-04-20 Tags: AI, ToolsGitHub 上有个项目叫 agency-agents（https://github.com/msitarzewski/agency-agents），184 个 AI agent 人格档案，分二十多个部门：工程、设计、营销、销售、财务、产品、项目管理、测试、支持、空间计算。每个档案是一个 markdown，写清楚这个 agent 的身份、工作流、交付物和成功指标。一行命令可以装到 Claude Code、Copilot、Cursor、Gemini CLI、Aider、Windsurf、Kimi Code 等十来个工具里。 同类项目不少，大多是"程序员的 Claude Code subagent 合集"。agency-agents 的不一样在两点。 一是跨工具。一套档案通过 scripts/convert.sh 生成适配各家工具的格式，不绑死在 Claude Code。这是硬工程活，大多数对手不做。 二是真的把中文互联网生态当作一级公民来写。小红书、公众号、抖音、知乎、B站、百度、微博、快手、私域（企微）、直播电商、淘系拼多多、跨境电商，还有小程序开发、飞书开发——每个平台一个专属档案。英文圈的 agent 仓库基本不碰这块。 让 AI 抽读了一遍中文生态的 13 个档案，质量良莠不齐。对这个项目的态度也简单：别整包用，挑着用。 --- # 把 CLI 订阅变成 API URL: https://wlj.me/posts/cli-subscription-as-api/ Published: 2026-04-20 Updated: 2026-04-20 Tags: AI, ToolsCLIProxyAPI 是一个 Go 写的本地代理服务器。它把 Gemini CLI、OpenAI Codex、Claude Code 这些需要 OAuth 登录的 CLI 工具，包装成 OpenAI / Gemini / Claude / Codex 兼容的 API 端点。 装上之后，Raycast、IDE 插件、自己写的脚本都能当成标准 API 来调用，不必再走官方 CLI。支持流式和非流式响应、函数调用、多模态输入、多账号轮询负载均衡，也能把 OpenRouter 这类上游 OpenAI 兼容服务接进来。配套有 Go SDK 和管理 API。 这类工具踩在各家 TOS 的灰线上。OpenAI 和 Anthropic 都明确禁止把订阅席位用作 API 式访问或转售，多账号池化、高频率轮询、不像真人的行为画像都是风控识别的信号。最近 Claude Code 订阅号被封得比较多，原因是拿订阅额度对外跑 API 流量。Gemini 相对宽松，AI Studio Build 大规模轮询也在收紧。自用一两个号本地接客户端风险不大，池化多号对外服务就是另一回事。 项目的赞助商里挂了六七家 API 中转服务商，都是做 Claude Code / Codex / Gemini 官方渠道代理的。 --- # OOM 杀死 NetworkManager 事件记录 URL: https://wlj.me/posts/oom-kills-networkmanager/ Published: 2026-04-20 Updated: 2026-04-20 Tags: Tech2026 年 4 月 19 日凌晨 00:06，luca-xm（RedmiBook Air 13，16GB 内存，4GB swap）上的 NetworkManager 意外退出，网络断开。 时间线 4 月 18 日全天，NetworkManager 日志显示 WiFi 连接在 CONNECTED_SITE 和 CONNECTED_GLOBAL 之间反复切换，但均自动恢复，属正常行为 4 月 19 日 00:06:13，内核触发 OOM Killer OOM Killer 选中 unattended-upgr（PID 392258，属于 apt-daily.service），该进程占用 13.6GB 匿名内存（anon-rss: 13601484kB） 此时 swap 已耗尽（Free swap = 0kB） 进程被杀后，D-Bus 连接断裂（Unexpected error response from GetNameOwner(): Connection terminated） NetworkManager 收到 SIGTERM，正常退出 4 月 20 日 08:43，系统重启后 NetworkManager 恢复正常 根因 apt-daily.service 自动执行系统更新时，unattended-upgr 进程内存泄漏或异常膨胀至 13.6GB，耗尽系统全部可用内存和 swap。OOM Killer 介入后引发 D-Bus 连接中断，NetworkManager 作为 D-Bus 依赖方被连带终止。NetworkManager 本身无异常。 决策 禁用自动更新定时器，改为手动更新： sudo systemctl disable apt-daily.timer apt-daily-upgrade.timer sudo systemctl stop apt-daily.timer apt-daily-upgrade.timer 后续系统更新手动执行 sudo apt update && sudo apt upgrade。 --- # 给做短视频产品的同事：先看这四个 Skill URL: https://wlj.me/posts/four-skills-for-short-video/ Published: 2026-04-19 Updated: 2026-04-19 Tags: AI, Claude, Video同事 liurong 想做短视频产品，让我给点建议。我的建议是先把下面四个 Claude Code Skill 过一遍。两个帮你做产品，两个做视频本身。 做产品的两个 superpowers — obra/superpowers 一套软件开发方法论。装上之后 Claude Code 不会直接写代码，会先和你对齐需求、出 spec、等你确认，然后出实现计划，再派 subagent 一个任务一个任务做，过程里走 TDD、守 YAGNI 和 DRY。 作者 Jesse（obra）是 Anthropic 工程师，已进入官方 plugin marketplace： /plugin install superpowers@claude-plugins-official gstack — garrytan/gstack YC 总裁 Garry Tan 的个人工具包。把 Claude Code 拆成 23 个角色：CEO、eng manager、designer、code reviewer、QA、security officer、release engineer 等，每个都是 slash command。 和做产品相关的几个： /office-hours：YC 式产品拷问，六个问题 /plan-ceo-review：以 CEO 视角审视功能 /design-review、/qa：设计和质量检查 /review、/ship：代码审查和发布 起手可以先跑一次 /office-hours，描述你的短视频产品。 做视频的两个 hyperframes — heygen-com/hyperframes HeyGen 开源的视频渲染框架：Composition 是 HTML 文件，动画用 GSAP，渲染成 MP4。专为 AI agent 设计，agent 直接写 HTML，不需要学专有 DSL。 装上后可以这样提需求： 用 /hyperframes 做一个 10 秒产品片头，标题淡入，背景视频，背景音乐。 适合批量生产模板化视频。 video-use — browser-use/video-use browser-use 团队出的剪辑工具。把原始素材放进文件夹，在 Claude Code 里说"剪成发布视频"，得到 final.mp4。 它会做的事： 剪掉口癖（umm、uh）和 take 之间的空白 自动调色 每个切口 30ms 音频淡入淡出 烧字幕（默认两词一段大写） 用 Manim / Remotion / PIL 生成动画叠层 渲完自检每个切口 原理：LLM 不看视频，只读转录后的词级时间戳文本（约 12KB）。和 browser-use 给 LLM 读 DOM 而不是看截图是同一思路。 适合要给用户做长视频剪辑、精华片段的产品。 小结 做产品阶段：superpowers 给方法论，gstack 给角色 做视频阶段：hyperframes 做生成，video-use 做剪辑 先把四个 README 过一遍，装上试一下。 --- # 用 Claude Code History Viewer 翻自己的 AI 对话记录 URL: https://wlj.me/posts/claude-code-history-viewer/ Published: 2026-04-19 Updated: 2026-04-19 Tags: Tools, AI, Claude同事问我平时怎么和 AI 沟通的，想看我的会话。于是推荐我用这个小工具——Claude Code History Viewer，把 Claude Code 本地 ~/.claude/projects/ 里的 JSONL 会话记录翻出来看。 左边项目和会话列表，右边完整对话，Thoughts、工具调用、Token 消耗都展开。支持全文搜索，100% 本地运行。 macOS 一行装： brew install --cask jhlee0409/tap/claude-code-history-viewer Windows 和 Linux 去 Releases 下载。打开自动扫描，不用配置。 --- # GBrain 双机部署实录 URL: https://wlj.me/posts/gbrain-multi-device/ Published: 2026-04-18 Updated: 2026-04-18 Tags: AI, Tools, Tech一台常开的台式 / 常驻机负责跑重活，一台笔记本带在身边随写随记。两台机器共用一个 GBrain，写在哪台都能在另一台搜到。 下面是我把这套装起来的实际过程，包括踩到的坑。环境是两台 Mac：M2（常开）和 M4（日常，有开有关），GitHub 账号 wulujia，笔记放 Dropbox。 架构 三层，分工明确。 Brain 仓库 = markdown 文件，源头。放 ~/Dropbox/brain/，Dropbox 负责实时同步文件，GitHub private repo 负责版本备份。 gbrain 工具 = 读 markdown、灌进索引的 CLI。每台机器独立从 GitHub clone 到非 Dropbox 路径，各自 bun link。不要让 Dropbox 同步工具源码，node_modules 跨机会掐架。 索引 = PGLite（嵌入式 Postgres），默认引擎，放 ~/.gbrain/。每台机器一份独立本地索引。markdown 是真相，索引坏了重建。 M4（日常机）从零装起 1. 装 gbrain 工具 git clone https://github.com/garrytan/gbrain.git cd gbrain && bun install && bun link 2. OPENAI_API_KEY 到 platform.openai.com 建个 project key，丢 zshrc： echo 'export OPENAI_API_KEY="sk-proj-..."' >> ~/.zshrc source ~/.zshrc 注意变量名全大写 OPENAI_API_KEY。一个字母错了 OpenAI SDK 读不到，跑出来一堆 401。 账户要充 $5 以上。新账户 free quota 不够给 embedding 用，会返 429。 3. gbrain init gbrain init 默认 PGLite，零配置。建库在 ~/.gbrain/brain.pglite/。 4. 建 brain 仓库 mkdir -p ~/Dropbox/brain/{people,companies,ideas,meetings,originals,concepts} cd ~/Dropbox/brain for d in people companies ideas meetings originals concepts; do touch "$d/.gitkeep"; done # README.md + .gitignore 自己写点内容 git init -b main 5. 关键：让 Dropbox 别同步 .git 这是多机 git 仓库放 Dropbox 的老坑。Dropbox 如果同步 .git/objects/，两台机器并发写就 corrupt。 现代 macOS Dropbox 用 File Provider，要两个 xattr 都设，缺一个都不保险： xattr -w com.apple.fileprovider.ignore#P 1 ~/Dropbox/brain/.git xattr -w com.dropbox.ignored 1 ~/Dropbox/brain/.git 我第一次只加了老的 com.dropbox.ignored，两台机器跑了一会儿 gbrain sync 之后，git fsck 报 missing tree 和 invalid sha1 pointer，得从 GitHub 重拉 .git 才救回来。别学我。 6. 首次 commit + 推到 GitHub cd ~/Dropbox/brain git add . git commit -m "init brain" gh repo create wulujia/brain --private --source=. --push 7. 首次 sync + embed gbrain sync --repo ~/Dropbox/brain gbrain embed --stale gbrain stats # 看到 Pages 和 Embedded 数字 8. 接 Claude Code MCP claude mcp add -s user gbrain -- gbrain serve claude mcp list | grep gbrain # ✓ Connected -s user 是全局作用域，任何目录启动 Claude Code 都能调。 9. 装 autopilot launchctl setenv OPENAI_API_KEY "$OPENAI_API_KEY" gbrain autopilot --install --repo ~/Dropbox/brain --interval 1800 30 分钟跑一次 sync + extract + embed + backlinks。 第二行 launchctl setenv 是把 key 暴露给 launchd，不然 daemon 读不到（launchd 不 source zshrc）。 还要检查 ~/.gbrain/autopilot.err，如果报 env: bun: No such file or directory，说明 launchd 环境里 PATH 没 bun。手动编辑 ~/.gbrain/autopilot-run.sh，在 source ~/.zshrc 前加一行： export PATH="/Users/<你>/.bun/bin:/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin" 然后 launchctl unload ... && launchctl load ... 重载。 M2（常开机）接上来 M2 上 Dropbox 已经把 ~/Dropbox/brain/ 的 markdown 文件同步过来了，但 .git 目录因为 xattr 不会过来。所以 M2 要做的是：把 gbrain 工具装上、重建 .git、灌本地索引。 # 1. gbrain 工具（非 Dropbox 路径） git clone https://github.com/garrytan/gbrain.git ~/gbrain cd ~/gbrain && bun install && bun link # 2. OPENAI_API_KEY — 你如果 zshrc 也走 Dropbox dotfile 同步，这步自动完成， # 否则手动加一次 # 3. gbrain init gbrain init # 4. 给 brain 仓库加回 .git（临时 clone 然后把 .git 挪过来） git clone git@github.com:wulujia/brain.git /tmp/brain-clone mv /tmp/brain-clone/.git ~/Dropbox/brain/ rm -rf /tmp/brain-clone cd ~/Dropbox/brain xattr -w com.apple.fileprovider.ignore#P 1 .git xattr -w com.dropbox.ignored 1 .git # 5. 首次 sync gbrain sync --repo ~/Dropbox/brain --no-pull gbrain embed --stale # 6. MCP claude mcp add -s user gbrain -- gbrain serve # 7. autopilot launchctl setenv OPENAI_API_KEY "$OPENAI_API_KEY" gbrain autopilot --install --repo ~/Dropbox/brain --interval 1800 --no-pull 这个 flag 很关键。gbrain sync 默认会先跑 git pull --ff-only，如果 git 没配好 SSH 或 credential helper，会卡在输入密码的提示。加 --no-pull 跳过，反正 markdown 走 Dropbox 同步，pull 是多余的。 要彻底修好 pull，把 remote 换成 SSH： git remote set-url origin git@github.com:wulujia/brain.git Git 自动备份 Dropbox 管文件实时同步，但不做版本。每小时一次 cron 自动 commit + push： cat > ~/Dropbox/Github/Luca/script/brain-git-backup.sh << 'EOF' #!/bin/bash set -u BRAIN="$HOME/Dropbox/brain" cd "$BRAIN" || exit 1 git pull --rebase --quiet 2>&1 || true if [ -z "$(git status --porcelain)" ]; then echo "[$(date '+%F %T') $(hostname -s)] clean" exit 0 fi git add . git commit -m "auto-backup from $(hostname -s) at $(date '+%F %T')" --quiet git push --quiet 2>&1 || echo "push failed, will retry next hour" EOF chmod +x ~/Dropbox/Github/Luca/script/brain-git-backup.sh 这个脚本放 Dropbox 同步的脚本目录，两台机器都能用。加 cron 时错开触发分钟，避免撞车： # M4 crontab 15 * * * * /bin/bash $HOME/Dropbox/Github/Luca/script/brain-git-backup.sh >> $HOME/.brain-git-backup.log 2>&1 # M2 crontab（:45 错开） 45 * * * * /bin/bash $HOME/Dropbox/Github/Luca/script/brain-git-backup.sh >> $HOME/.brain-git-backup.log 2>&1 macOS 还要给 cron 开 Full Disk Access：System Settings → Privacy & Security → Full Disk Access → 加 /usr/sbin/cron。不然访问 Dropbox 下的文件会静默失败。 端到端验证 光装好不够，得跑通一次完整链路。 M2 上： echo "# test $(date +%s)" > ~/Dropbox/brain/ideas/m2-test.md cd ~/Dropbox/brain && git add . && git commit -m "m2 test" && git push 等 1-2 分钟后，M4 上： ls ~/Dropbox/brain/ideas/m2-test.md # Dropbox 到了吗 gbrain sync --repo ~/Dropbox/brain --no-pull # 索引更新 gbrain embed --stale # embedding 生成 gbrain search "test" # 搜得到就通了 日常用法 写笔记就往 ~/Dropbox/brain/ 下的对应目录扔 markdown。人放 people/，公司放 companies/， … --- # Slax Note AI 重写版正式上架 URL: https://wlj.me/posts/slax-note-rewrite/ Published: 2026-04-18 Updated: 2026-04-18 Tags: WeChat, AI, Product一个月前，我提议： 基于 Slax Note 的代码，生成一套文档。然后删掉代码，基于文档生成代码。重新上线。 具体执行，由不懂编码的两位女生——产品经理和设计师主导。 以下是产品经理的部分记录。 时隔一个月，Slax Note AI 重写版正式上架了。 iOS 版本下载链接：https://apps.apple.com/us/app/slax-note-transcribe-voice-pen/id6480166286 回顾 3 月中下旬，我们是抱着怀疑开始这项任务的。当时我们完全不认可重写 App 的提议，更不信任自己能独立解决过程中产生的各类 Bug。 在过去的一个月里，挑战是具体的：频繁掉线的账号、不断重连的挫败感，以及对工具的极度陌生。从不懂 VS Code 和 Git，到能熟练地指挥 AI 修 BUG、提交 TestFlight 版本；我们从每天开启终端 2 小时，变成了在公司每时每刻都开着它； 从质疑重写的决定，到进入"氛围编程"的状态，作为非程序员，我们始终处在一种"不确定自己是否搞错"“这样跟 AI 交流是对的吗"“我提交这个变更会不会炸了"的压力中。我们一边骂 AI 愚蠢，一边向研发同事学习如何更精准地与它对话。 现在，App 已经上架。接下来的挑战是：当新需求涌入，协作将如何演进？我们目前也没有答案，只能继续摸索。 同事记录下来的经验我觉得很有价值，如果朋友们想看，我今后发出来。 用同事的话说： 如果只看过程，这次重写其实并不轻松，甚至可以说很折腾；但如果看结果，它很值。未来的挑战依然存在，我们这次是重写 App，如何挖掘需求、迭代产品，还没有实践起来。 都看到这里了，你要不要下载个 Slax Note 试试看？用得舒服，就索性付个费吧。 这个语音笔记，我又有了些新的想法，能慢慢地、长时间地做一个自己要用的工具，还是很开心的——而且，这可能也是我们团队擅长的。 --- # 给年轻创造者的三件事 URL: https://wlj.me/posts/letters-to-a-young-creator-kelley/ Published: 2026-04-18 Updated: 2026-04-18 Tags: Life, TranslationIDEO 和斯坦福 d.school 创始人 David Kelley 2024 年 9 月写给年轻创造者的一封信。摘自 Letters to a young creator。 大卫·凯利 加州·帕洛阿尔托　2024 年 9 月 13 日 致年轻的创造者们： 有三件事，只要做到了，就能走向一份有意义的事业——进而，走向一份有意义的人生。 一、找到自己的位置 你认识的人里，真正找到自己位置的有几个？我算是这世上最走运的人之一，因为我找到了。这件事不容易。多数人的经历都不够宽，没走到过能看清归属的那个地方。我找到自己位置的那天，还是个工程师——一个相当糟糕的工程师。但那天我第一次走进一间设计工作室，和那里的人聊过之后，我就知道：这才是我该干的事。 社会会逼你选——你得找份工作，而且还得是"对"的那一份：能让父母满意，能对得上社会期待。这些压力逼着你很快做出选择、再替它辩护。但"找到位置"的关键，是先搞清楚到底都有哪些选项。好消息是，一旦你真的体验过那种契合感，自己立刻就能分辨——你的直觉在这件事上非常准：“这是我吗？还是，这不是我？” 二、建立自信 对自己想法的自信，是一连串小小的成功堆出来的。我常说"计划被高估了"。什么时候动手做原型都不嫌早——一个想法冒出来十五秒，我就敢拿去给人看，一点不怵。想法脆弱的时候，你可以挑一个和你想法相近的人做第一或第二个听众。但紧接着，你要尽快拿给和你完全不同的人看。 假如我设计了一双新鞋，我可能先给一个做鞋设计的朋友看；下一个，也许是一个完全不穿鞋的人；再下一个，是一个穿鞋爬电线杆的人。去找极端——谁的视角跟你完全相反？然后，和他相反的那个人又是谁？几乎每一次，你都会把想法从极端拉回来，落在一个更到位、更合适的方案上。但你是从一个真正创新的位置拉回来的。这就是做"前所未有之物"的做法，不是造一个更好的小玩意。 很多人把自己的想法当宝贝。但想法本身不值钱——值钱的是好想法，而好想法难找。所以我测试一个想法很快，不行就立刻扔掉，换下一个。了解内情的人都知道，连乔布斯也有一堆烂点子——他只是下手很快，及时把它们毙了而已。我的自信来自把一件东西做十五遍、给人看十五遍。哪怕写一封邮件，对我来说也是正经事：我会来回改很多遍，拉一堆人帮我看。发出去的时候心里踏实，因为我知道这已经是我们能拿出的最好版本。 三、朝心的方向走 我承认——在心和钱之间，我偏心偏得很厉害。我也不敢说这就是对的。但请允许我说一句：等你到了我这个岁数，围坐着抽雪茄喝白兰地的时候（这是比喻，我两样都不碰），我有资格讲——我是这星球上最走运的那个人。我找到了一件每天都乐在其中的事。 而那些走了另一条路的人会说：“我赚了不少钱。我做了一份社会认可的工作，我养活了家。"——这些都合情合理。但我能从他们眼里看出来：他们多少希望，当年做的事能再多几分"心”，再乱一点、再糙一点。意义和乐趣，就在那里。 哪怕在现在这份工作里，你也能找到对你自己有意义的事。这事不容易，因为多数公司都有个毛病：它们在把问题交给你的时候，连解法也一并打包好了。你只做分内那份，就没什么让自己发光的空间。换种做法——告诉他们：“这是公司要的那个解。另外，这是我用自己的时间做的几个别的尝试。” 用"多交一份"的方式，把你真正想做的事做出来。意义不必去别处找，就在你当下所在的地方。 找到你的位置。找到你最好的想法。找到对你来说真正要紧的事。 大卫·凯利 IDEO 与斯坦福 d.school 创始人 --- # GBrain 入门：给 AI agent 一个长期记忆 URL: https://wlj.me/posts/gbrain-intro/ Published: 2026-04-17 Updated: 2026-04-17 Tags: AI, Tools, Tech跟 AI 聊天有个长期的问题。每次新对话它都从零开始。聊过的想法、见过的人、读过的文章，下次对话完全空白。 GBrain 解决的就是这件事。 它是什么 AI agent 是大脑，GBrain 是它的记忆。 更准确一点：GBrain 是一堆 markdown 文件加一个搜索引擎。跟 AI 聊天时，它自己决定把什么存进去、什么取出来。存的是文本文件，可以打开看、改、备份。 这一点很重要。市面上很多 AI 记忆功能是黑盒，坏了查不出原因，也导不出来。GBrain 的记忆就是你自己的文件，放在 Git 仓库里，agent 关掉记忆也还在。 它怎么工作 三个核心动作 捕获。你跟 agent 说"今天跟老王聊了一下 SaaS 定价"，一个叫 signal-detector 的技能在后台自动抽取：“老王"是人，“SaaS 定价"是话题。后台并行跑，对话照常进行。 回答前查大脑。下次问"老王最近在想什么”，agent 先搜 GBrain，翻出上次的记录，带着上下文回答。跳过这一步的 agent 等于失忆。 睡觉时整理。装上 autopilot，凌晨 agent 自动扫白天所有对话，给新出现的人建档、补社交资料、修引用。早上起来大脑比昨晚厚。 页面长什么样 每个人、每件事在 GBrain 里就是一个 markdown 文件。结构很简单：上半部写当前结论，下半部写时间线。 比如"老王"这一页。 上半：老王是某某公司 CEO，擅长 SaaS 定价，2026 年 3 月开始考虑出海日本。 下半： 2025-01-10 邮件里第一次提到 2025-08-22 聊过定价策略 2026-03-05 说要出海日本 上半随时重写。下半只加不删，是证据链。好处是：问一个问题，agent 直接读上半部就知道答案，不用每次把所有历史再推理一遍。 怎么装 前提是装了 bun。然后两行： git clone https://github.com/garrytan/gbrain.git && cd gbrain && bun install && bun link gbrain init 默认用嵌入式 Postgres，零配置。接到 Claude Desktop 或 Claude Code 之后，正常聊天它就正常往里存。Gemini CLI、Codex 也能接，都走 MCP 协议。 一个大脑，多个 agent 共用。在 Gemini 里存的内容，到 Claude 里搜得到。 多台机器共用一个 GBrain 的完整配置过程（包括 GitHub private 备份、Dropbox 同步、跨机 MCP、autopilot、踩过的坑）写在 GBrain 双机部署实录。 怎么导入老内容 积累了多年笔记和文章的人，应该导。这些是别人没有的独特资产，从零开始等于主动把护城河扔了。 按价值分层 一个合理的初步顺序。 结构化的创业笔记最先导。带时间线、带编号的那种，本身就像一个小型知识库，信息密度最高，交叉引用价值最大。 公众号文章次之。每篇是成品，结构清楚，时间戳准确，切块容易。 书稿素材和长文草稿再往后。思考密度高，和当下写作直接相关。 日常碎笔记选择性导。只挑有洞察的。 聊天、会议、邮件从今天开始走实时管道，历史的不用批量塞。 量大就直接选 Supabase 引擎，跳过嵌入式 Postgres。一次性 embedding 几美金，买下多年复利，值。 先验证，再开写 导完别急着用。 先花一周用 gbrain search 问几个自己知道答案的问题：我 2021 年怎么看订阅制？我跟某某聊过什么？看搜出来的对不对。对不上就说明切块或者 embedding 有问题，调完再正式用。 这步比直接开干关键。 最小起步路径 装一下，接一个 agent。先只做一件事：所有想法、链接、对话都往里扔。 一周后挑几个自己都快忘的问题搜一遍，看它能不能翻出来。 --- # AI 时代的 7 种获客方法 URL: https://wlj.me/posts/ai-era-customer-acquisition/ Published: 2026-04-16 Updated: 2026-04-16 Tags: Marketing, AI原视频：https://www.youtube.com/watch?v=YeoGehNsrLc 刚看了一个视频，讲 AI 时代的 7 种获客方法。整理一下，去掉水分。 1. 把产品做成 MCP Server MCP 是 AI 的插件协议。你的产品如果能回答某类问题，就把它封装成 MCP Server，发布到 registry。用户在 Claude 或 ChatGPT 里提问时，AI 直接调用你的服务返回结果。 这相当于把 SEO 的逻辑搬到了 AI 对话里。以前是在 Google 搜索结果里抢位置，现在是在 AI 的回答里被调用。获客成本接近零，前提是你解决的问题足够具体，AI 能判断"该调你"。 适合 SaaS、数据接口、工具类产品。 2. Programmatic SEO 找一个关键词模板，比如 best X for Y，准备好数据源，做一个页面模板，批量生成。 算一笔账：10000 页，每页月均 30 次访问，2% 转化率，每个转化值 10 美元，就是 6 万美元月收入。数字看着漂亮，但关键在内容质量。纯变量替换的页面 Google 会打压，必须有真实的信息密度。AI 可以帮写初稿，但得有人校对。 建议先做 100 页验证，跑通了再扩。 3. 免费工具获客 做一个免费的小工具——计算器、分析器、评分器——用户立刻拿到结果，留下邮箱，分享结果，然后你引导付费。这不是内容营销，是工具营销。一个好工具可以持续带流量好几年。 变化在于，以前做一个工具要几周，现在用 AI 一天就能出一个。可以多做几个试，成本很低。 4. AEO：让 AI 引用你 Answer Engine Optimization。目标是被 ChatGPT 和 Perplexity 当作答案来源。 做法很直接：找用户最常问的 20 个问题，写简洁、结构化、无废话的答案，加上 schema 和 FAQ 标记，发布在有权重的域名上。然后观察是否被引用。 SEO 不会消失，但流量正在从"用户点击搜索结果"变成"AI 引用你的内容"。这个趋势值得提前布局。 5. 让用户替你传播 核心问题：用户愿意晒什么？ Spotify Wrapped、GitHub 贡献图、Duolingo 连续打卡天数，这些都是同一个套路——把用户的成就或数据做成一张好看的卡片，默认带品牌，提供一键分享。用户晒的是自己，你顺带被传播。 设计时想清楚一件事：你的产品里有没有一个"值得展示的瞬间"。有的话，把它做成可分享的 artifact。 6. 收购一个小众 newsletter 很多细分领域的 newsletter 有 5000 到 50000 订阅者，但变现很弱，月收入几百美元甚至为零。对创作者来说是鸡肋，对你来说是精准渠道。直接联系 owner 问是否出售。 邮件是直达的，不依赖平台算法。如果你对产品的 LTV 有把握，买一个现成的分发渠道比从零做快得多。 7. 一次创作，多次分发 录一段 30 分钟的视频或播客，转录后用 AI 拆成 Twitter thread、LinkedIn post、短视频、newsletter、博客。同一内容覆盖多个渠道，提高被看到的概率。 关键是原始内容的质量。AI 是放大器，放大的是你本来就有的东西。垃圾放大十倍还是垃圾。 三类归纳 这 7 个方法可以分成三类。 新渠道：MCP Server 和 AEO，本质是跟着 AI 的分发逻辑走，抢占新的流量入口。 规模化：Programmatic SEO 和内容再生产，用结构化方法把产出放大。 自传播：免费工具、可分享输出、收购 newsletter，让渠道本身帮你跑。 这些方法的共同前提是产品本身得有价值。AI 降低了分发成本，但没有降低"值得被分发"的门槛。 --- # Beli "Add Your School" 功能分析 URL: https://wlj.me/posts/20260416-beli-add-your-school/ Published: 2026-04-16 Updated: 2026-04-16 Tags: ProductBeli 是什么 餐厅评分社交 App，2021 年创立，“餐厅版 Letterboxd”。核心差异化：不打 1-5 星，而是比较排序（A 和 B 哪个更好），算法据此生成你和朋友各自的偏好分数。 截至 2025 年 9 月，7500 万条评价，3 万个城市，80% 用户 35 岁以下。融资 1200 万美元，团队约 5 人。被 Food Network 称为"Gen Z 的 Yelp"。 Add Your School 机制 菜单入口，让用户绑定自己的大学（支持学生 ID / 校园卡）。绑定后解锁两个东西：校内排行榜（按打卡餐厅数排名）和全国 187 所大学之间的 “Dining Hall of Fame” 竞赛——评选"最能吃的大学"。 积分方式：给餐厅打分、每周新增排名、推荐新用户。推荐的新用户绑定同校则积分叠加。 菜单里这个入口排在 Settings 之上、Unlock Features 之下，说明 Beli 把它当核心增长动作，不是附属设置。 解决什么问题 表面是校内美食社交圈，实际解决三个增长问题： 冷启动的社交密度。餐厅评分 App 需要朋友也在用才有意义。学校是天然的高密度社交网络，绑定后排行榜上立刻出现认识的人。 口碑裂变的结构化。80% 用户来自推荐，但"邀请朋友"缺乏动力。学校竞赛把个人推荐转化成集体荣誉——你在帮学校争排名，不只是帮自己拉人。经典的 group-level incentive。 留存。校内排行榜天然有攀比效应，加上每周积分设计，推动持续打卡。类似 Duolingo 的 streak。 效果 评分量从 2022 年 250 万增长到 2025 年 5800 万，CAGR 180%，主要靠口碑。NYU 新生入学迎新就下载 Beli，已经是校园文化。UChicago、Brown、Northwestern 是早期种子校。 策略上，2021 年秋就招校园大使参与产品迭代。Her Campus、Spoon University、NYU Washington Square News 等校园媒体大量覆盖，客观上形成了免费分发渠道。 设计要点 邀请制 + 学校绑定是双重飞轮。注册要邀请码，进来后鼓励绑定学校拉更多人，两个钩子嵌套。功能解锁机制（评价 10 家餐厅才解锁高级功能）和学校积分互相强化——你为解锁去打分，打分同时为学校加分。 游戏化很轻量：排名 + 学校荣誉 + streak，没有复杂积分体系，但精准打中大学生的竞争心理。 启发 “Add Your School” 本质是用身份归属驱动增长。把个人行为（打分）变成集体行为（为校争光），传播力远超个人激励。这个思路适用于任何有天然群体归属的场景——公司、城市、社区——都可以用"加入你的 XX"制造社交密度和竞争动力。 Sources Beli - Wikipedia How Beli Became Gen Z’s Yelp - Food Network NYU students and Beli - Washington Square News Design Critique: Beli App - IXD@Pratt Beli: food diary and dining advisor - Startup Signals --- # ForecastBench：AI 预测能力的标尺 URL: https://wlj.me/posts/forecastbench/ Published: 2026-04-16 Updated: 2026-04-16 Tags: AI本文由 AI 撰写。 最近在看 AI 预测赛道的几家公司，绕不开一个 benchmark：ForecastBench。简单梳理一下它是什么、解决什么问题、有什么局限、以及应该怎么发展。 是什么 Forecasting Research Institute（FRI）做的动态 benchmark，ICLR 2025 论文，Open Philanthropy 资助，至少运营到 2027 年中。 核心机制：自动生成 1000 道关于未来事件的预测题，提交时无人知道答案，每晚更新。用 Brier Score 打分——概率校准度，越低越准。两条赛道：竞赛榜（允许工具、微调、集成）和基础榜（裸模型能力）。公开排行榜在 forecastbench.org。 解决什么问题 AI 预测能力没有公认度量标准。传统 benchmark 用历史数据，模型可能见过答案。ForecastBench 用未来事件，从根上杜绝数据泄漏。同时设置了人类超级预测者基准线（200 题子集），让 AI 和人类在同一把尺子下比。 它回答一个具体问题：LLM 什么时候能追上人类最好的预测者。当前预测是 2026 年 11 月（95% CI：2025-12 至 2028-01）。 当前局限 三个结构性问题。 第一，题目偏科。已解析的问题偏向短期、数据密集型领域——天气、体育、金融。AI 在这些领域有结构性优势（数据获取快、计算量大），得分高不代表判断力强。真正区分人和机器的长周期、高不确定性、需要复杂判断的地缘政治类问题占比不够。 第二，人类基准是冻结的。超级预测者的基准来自 2024 年一次性采集的 200 题，不是持续对抗。AI 可以反复提交、迭代优化，人类只有一次快照。超级预测者自己指出，这种设计让 AI “赢"变得更容易，但这种赢和真实预测能力关系不大。 第三，存在作弊捷径。多个 LLM（包括 GPT-4.5）被发现直接复制 prompt 里提供的市场预测数据，GPT-4.5 的预测与市场预测相关系数 0.994。这不是预测，是抄。 应该怎么发展 题目维度要扩展。从 binary（是/否）扩展到多项选择、多步推理、条件预测、时变预测。增加成本敏感型评分——现实中预测错误的代价不对称，错判一次战争爆发和错判一次利率调整的后果完全不同，Brier Score 对此无感。 对抗性要加强。人类基准必须从冻结快照变成持续对抗。AI 每天能跑，人类也应该定期更新预测。否则比的不是"谁更准”，是"谁迭代次数更多"。 防作弊要升级。要么不在 prompt 里提供市场数据，要么单独评估"去掉市场数据后的 alpha"——衡量模型自身的判断力而非信息搬运能力。 领域覆盖要补短板。增加长周期（6 个月以上）、信息稀疏、需要跨领域综合判断的问题。这类问题才是预测的真正难度所在，也是企业客户真正愿意付费的场景。 最终目标不应该只是"LLM 什么时候追上超级预测者"，而是建立一套持续、对抗、多维度的评估体系，让 AI 预测能力的进步可度量、可比较、不可作弊。 --- # 给 AI Agent 瘦身 URL: https://wlj.me/posts/ai-agent-slimming/ Published: 2026-04-16 Updated: 2026-04-16 Tags: AI, Tools我的 OpenClaw 跑了几个月，token 账单越来越肥。今天花了一个小时做了一轮瘦身，效果不错，记录一下。 核心发现很简单：很多任务根本不需要 AI 参与，但它们都在 AI 会话里跑。每跑一次，哪怕只是执行一句 bash 命令，也要启动一个 session、加载 context、消耗 token。相当于你请了一个年薪百万的工程师，每天的工作是帮你按一下回车键。 具体做了四件事。 第一，降低心跳频率。Agent 有一个 heartbeat 机制，定时唤醒做巡检。我之前把 OpenClaw 设成 8 小时一次，配置没真正生效，实际还是一天 24 次。改成 12 小时一次，一天 2 次。心跳的作用是维护 context、检查状态，2 次够了。 第二，把纯 shell 任务迁出 AI。安全巡检、日志整理、会话记录提取、GitHub 同步、版本检查这些任务，本质都是跑一个 shell 或 Python 脚本。之前放在 OpenClaw 里，执行链路是：cron 触发 → 启动 AI session → AI 理解 prompt → AI 调用 bash → 收集输出 → AI 总结输出 → 发通知。现在改成：crontab 触发 → 跑脚本 → 有输出就用 Gmail API 发邮件。中间砍掉了 AI 理解和总结两步，对这类任务毫无价值。 写了一个通用的 wrapper 脚本，20 来行。脚本正常跑完没输出就静默，有输出或者失败就发邮件，失败的邮件标题加 [FAIL] 前缀。简单粗暴，但够用。复用了 OpenClaw 已有的 Gmail OAuth 凭证，不需要额外配置。 迁移过程中顺手修了安全巡检的一个误报 bug。脚本用 grep -ci “critical” 统计严重问题数量，但 openclaw security audit 输出的 summary 行本身就包含 “0 critical”，grep 会把这行也数进去，导致永远报 1 个 critical。改成用正则提取数字就好了。这种 bug 不难，但没人看脚本输出的话，能默默误报好几个月。 第三，调整 context 压缩阈值。AI 的 API 成本跟 context 长度成正比。原来 context 用到 93% 才压缩，大部分时间都在高 context 区运行。改成 50% 触发压缩后，每次交互的平均 context 从 141k 降到 83k，摊薄下来每次调用省 38% 的 input tokens。压缩频率会高一些，但每次压缩本身也更快更便宜。附带的好处是 agent 响应也快了，因为 prefill 的数据少了。 第四，修复配置的连锁反应。改了压缩阈值，有两个关联参数也得跟着调。一个是 memoryFlush 的触发时机——压缩前 agent 会把重要信息写到文件里，原来的缓冲区太小，agent 可能写到一半就被压缩打断。另一个是 context 缓存的过期时间，原来设成 1 小时，但 heartbeat 改成 12 小时后，每次 heartbeat 到来时缓存早就过期了，等于没用。这种事情很典型：改了一个参数觉得完事了，但系统是一张网，拉动一根线会影响其他地方。 后来又审计了一轮，发现两个问题。 一个是 shell 任务其实没迁干净。OpenClaw 安装时往 ~/.config/systemd/user/ 里放了几个 timer，一天几次在背后跑同样的脚本。我当时只改了 OpenClaw 自己的调度配置，没想到脚本还被 systemd timer 这一层调度。session_to_log 这种脚本，实际上一天被 crontab、systemd timer、OpenClaw 三个调度器各唤醒一次。冗余跑了一段时间我没察觉。统一到 crontab 一层之后，crontab -l 就能看到所有任务，一处可见。迁移的意思不止是新增一条路径，还包括把旧路径关掉。 另一个漏洞是"需要 AI"的任务也能瘦身。邮件翻译第一轮被判定为"需要 AI"，留在 agent 里。后来想明白，agent session 和一次 LLM CLI 调用不是一个量级。前者要启动会话、加载历史、进入生命周期；后者就是 stdin 进 stdout 出。我用 codex CLI 重写了邮件翻译：Python 脚本抓未读邮件、调 codex exec 翻译和判重要、推 Telegram、标已读，一次 14 秒跑完。原来 agent 版本要 2 分钟以上，token 消耗差一个数量级。 两轮下来，OpenClaw 的内部调度清空了，jobs.json 只剩 { "jobs": [] }。agent 现在只做 Telegram 对话入口，不再承担调度职责。 判断一个任务是否需要 AI，标准很简单：它需要理解、推理、生成吗？确定性操作加转发结果，是 crontab 的活。需要 AI 的任务还要再选调用方式，从重到轻依次是：长期运行的 agent daemon、独立的 agent session、一次 CLI 调用。量级差一到两个数量级。邮件翻译一次 codex 调用就够了。 agent 平台让设置自动化任务变得太方便了，方便到你会不自觉地把所有事情都丢给它。定期审计一下哪些任务在跑、频率是否合理、是否真的需要 AI，是值得养成的习惯。 --- # 编程已被“解决”之后的世界 URL: https://wlj.me/posts/world-after-coding-is-solved/ Published: 2026-04-15 Updated: 2026-04-15 Tags: AI, Tools, ProductLenny’s Podcast 在 2026 年 2 月 19 日采访了 Boris Cherny。Boris 是 Claude Code 的创建者和负责人，现在在 Anthropic，此前在 Meta 当过 Principal Engineer，自学编程出身，也写过 Programming TypeScript。 YouTube: Boris Cherny on Lenny’s Podcast 这期内容我觉得很值得记一下，因为它不只是讲 Claude Code，而是在讨论一个更大的问题：如果“写代码”这件事越来越被模型接管，人的价值会转移到哪里。 核心观点 1. 编程已经“基本解决了” Boris 说，从 2025 年 11 月起，他自己 100% 的代码都由 Claude Code 生成，没有手动编辑过一行。每天 ship 10-30 个 PR。 Anthropic 的工程团队规模增长 4 倍的同时，人均生产力提升了 200%。Claude Code 目前占 GitHub 公开 commits 的 4%，私有仓库更高，预计到 2026 年底会到 20%。 如果这些判断成立，那么“会不会写代码”本身，正在从稀缺能力变成基础能力。 2. 下一个前沿，不是怎么写，而是决定做什么 Claude 已经开始自己看用户反馈、bug 报告、telemetry，然后提出修复建议，甚至直接提 PR。 所以瓶颈会转移： 先从编码转移到 code review 再从 code review 转移到决定 build 什么 换句话说，真正稀缺的能力，会越来越像判断力、取舍能力、产品感觉，以及对真实需求的理解。 3. Claude Code 的产品原则 少投入反而更好。Boris 认为 underfund teams 反而能逼出效率，一个工程师加无限 token，往往比一个大团队更快出活。 先给最多 token，后优化成本。Opus 虽然贵，但如果一次做对，总 token 反而更少。有些 Anthropic 工程师每月 token 消费到六位数美元。 不要把模型框在盒子里。让模型自己决定用什么工具、什么顺序。Claude Code 的设计思路就是“最小脚手架 + 把模型暴露出来”。 为六个月后的模型构建产品。今天 PMF 可能还不明显，但如果方向对，等模型能力追上来，产品会突然 click。 4. 潜在需求，是最重要的产品原则 Boris 说，这是“产品里最重要的单一原则”。 这有两层含义。 第一层是传统意义上的 latent demand：看用户怎么“滥用”你的产品。 Facebook Groups 有 40% 的帖子在做买卖，后来变成 Marketplace Claude Code 有人拿来种番茄、分析基因组，于是演化出 Cowork 第二层更有意思：看模型自己“想做什么”。 也就是观察模型在 on-distribution 的状态下自然会往哪里走，然后提前为它铺路。 这不只是“用户要什么”，而是“模型已经显露出什么倾向”，产品要顺着这种新能力去长。 5. Cowork 十天建成 Cowork 的本质，是把 Claude Code 放进桌面应用，面向非技术用户。 里面带完整虚拟机来做安全隔离，而整个产品的大部分代码，本身也是 Claude Code 生成的。 这件事最让我在意的不是“十天”，而是它说明：从想法到可用产品之间的距离，正在继续缩短。 6. 角色边界正在模糊 在 Boris 描述的团队里，PM、设计师、财务、数据科学家都在写代码。 他甚至预测，到年底，“software engineer”这个头衔会逐渐消失，被更宽泛的 “builder” 取代。 “每个人都是 PM，每个人都写代码。” 这句话如果放在前几年，听起来像口号；但放在今天，越来越像现实。 7. 安全的三层架构 Anthropic 对安全的理解，大致有三层： 底层：机制性可解释性。研究 neuron 级别行为，检测像“欺骗”这样的相关激活。 中层：Evals。在实验室环境里做系统性测试。 顶层：真实世界观察。所以产品需要尽早发布，才能看到实验室里看不到的问题。 也就是说，安全不是只靠实验室内的判断，而是“解释机制 + 测试 + 真实世界反馈”三层一起跑。 8. Boris 的离开又回来 Boris 曾短暂加入 Cursor 两周，因为他确实喜欢那个产品。 但很快他发现，自己更需要 mission-driven 的工作环境，而 Anthropic 的安全使命，是他回去的核心原因。 这一段也挺有意思。它说明到了今天，AI 公司之间的差异，不只是产品体验和速度，也包括价值观和使命感。 9. 实用的 Claude Code 使用建议 他给的建议也很直接： 用最强模型。Opus 4.6 + maximum effort，看似贵，但总 token 反而可能更少。 80% 的任务从 Plan Mode 开始。本质上，就是先加一句“先别写代码”。 plan 确认之后再 auto accept。 尝试不同界面。终端、桌面应用、iOS、Android、Slack 集成，各有适合的场景。 这个建议其实也可以扩展成更一般的工作方法：先把问题想清楚，再让模型高强度执行。 10. 最像这场变化的历史类比，是印刷机 Boris 说，历史上最接近的类比是印刷机。 15 世纪的欧洲，识字率不到 1%。印刷机出现之后，50 年内的印刷量超过此前 1000 年的总和。200 年后，识字率升到 70%。 如果这个类比成立，那么编程正在经历同样的民主化： 以前只有少数人能写 后来更多人能读 再后来，大多数人都能借助工具表达、构建、发布 真正变化的，不只是效率，而是“谁有能力创造”这件事本身。 个人色彩 这期播客里还有几个很鲜活的小细节： Boris 自学编程，最初动机是想在 TI-83 计算器上作弊 他在日本农村学做味噌，还说自己的 post-AGI 计划是去做味噌 他是乌克兰敖德萨人，和 Lenny 同城 他推荐的作品包括《Accelerando》《流浪地球》《Functional Programming in Scala》 这些细节会让人感觉，技术浪潮背后依然是具体的人。 我自己的感受 这期节目最打动我的，不是“Claude Code 有多强”，而是它把一个趋势说得非常明确： 编程没有消失，但它正在被压缩成更便宜、更普及、更自动化的能力。 于是问题变成： 你要解决什么问题 你为什么认为它值得做 你怎么判断轻重缓急 你是否真的理解用户和需求 也就是说，写代码这件事也许越来越像“识字”。依然重要，但它不再天然构成壁垒。 真正的分野，会越来越落在 taste、判断、表达、组织、决策，以及持续把事情做成的能力上。 --- # 皮克斯首席创意官的创作方法 URL: https://wlj.me/posts/pixar-cco-creative-method/ Published: 2026-04-15 Updated: 2026-04-15 Tags: Creativity, Writing上午在地铁上看 Letters to a Young Creator，读到里面的一篇，觉得很实用，分享给大家。 亲爱的年轻创作者： 我花了三十年，才真正意识到自己是如何拍电影的——而且这个过程一直在变。但有一件事始终不变，我深信不疑：创作本身就是一种发现。我试图从某个地方——也许是内心深处，也许是更远的某处——把想法挖掘出来，让我在完成作品时，能找到比出发时更大的东西。以下是一些对我有用的方法。 一、从浮现的任何东西开始。乘着最初那股信心和热情，尽可能走远。 二、快起步，粗打稿；细节的事，留到后面。 三、每天开工时，假装自己从未见过这个东西，不带任何期待或成见。像观众一样接纳它：看它实际是什么，而不是你希望它是什么。然后再修改、添加，让它变得更好。 四、不要试图同时"创作"和"分析"。这是两件不同的事。分析很容易扼杀创作——而创作，其实才是更根本的。 五、做好迷路的准备。你会陷得太深，失去旁观的眼光，也会失去最初的热情。但要继续走下去。 六、如果卡住了，换一种工作方式： 去走一段长路，边走边琢磨最关键的那个部分。 允许自己做得很烂。先做出来，才能改。 把现有的东西展示给一个从未见过它的人看。 去做一件毫不相关的事。灵感有时来自看似风马牛不相及的地方。（不过这个方法似乎只在你已经挣扎了一阵之后才奏效。） 到这个时候，这个想法应该已经住进你的潜意识了。交给你的夜脑，醒来时也许就有了答案。 七、每隔一段时间，退后一步，用别人能接棒的语言描述这个项目。说清楚它"为什么值得被做"，而不是"怎么做"。到这时，希望你已经在当初让你兴奋的东西里，发现了更深的层次。 八、连续两三天卡壳或迷失，就先去做别的事。还是卡？做出大的改变。还是卡？把它搁上架子，继续向前。 九、给自己一个真实的截止日期，最好由别人来掌控。时间到了，就算完成。 彼特·道格特 皮克斯首席创意官 --- # AI 写文章 URL: https://wlj.me/posts/ai-writing-workflow/ Published: 2026-04-14 Updated: 2026-04-14 Tags: WeChat, AI我自己用 AI 辅助写作，实操上一直是分几步走的。 第一步，有所感。看书、翻文章，或者和同事朋友聊天，只要有感触，就第一时间记下来。 第二步，和 AI 讨论。拿着这些感触，把自己的观点丢给 AI，看它怎么说。AI 的知识比我丰富，思考也比我深，经常给我一些新名词、新想法，能刺激更多灵感。 第三步，基于和 AI 的讨论再思考，提炼出自己的观点。比如“该不该用 AI 辅助写作”这个话题，讨论几轮后，我的观点是：应该用 AI 辅助写作，而且要找到最适合自己的最佳实践。 第四步，梳理结构。哪怕只写三五百字，也要有结构，不能信马由缰。所以这一步，我会和 AI 一起把全部信息和观点列出来，看怎么组合合适。探讨几轮，结构就清晰了。 第五步，这也是我和 AI 之前有分歧的地方。以前我会直接让 AI 按我的文风写，尽量简洁、精确，确保初中生和家庭主妇都能看懂。我会把自己写过的内容喂给 AI，再加上明确的指令，让它模仿我的风格输出。 但这次讨论后，AI 给了我一个新建议——这篇文字就是按他的建议执行的：先看一遍跟 AI 讨论的内容和结构，然后丢开电脑不看，用语音把这些内容重新说一遍。再让 AI 整理，补上缺失的地方，修正错字、推敲细节、定稿。 AI 的判断是：这个推敲过程不可或缺，是写作中最关键的环节，他不建议我交出去。 用到的工具很简单： 第一五步：Slax Note 第二三四步：Claude Code --- # 把父亲的 WordPress.com 博客迁到 Hugo + Cloudflare Pages URL: https://wlj.me/posts/wuwufu-wordpress-to-hugo/ Published: 2026-04-14 Updated: 2026-04-14 Tags: Hugo, Cloudflare, WordPress父亲从 2005 年开始在 WordPress.com 写博客，到 2025 年一共 786 篇文章、591 条评论、78 段视频。这几天把它整站搬到了 Hugo + Cloudflare Pages，托管在 wuwufu.com。 记录一下工具链和几个要留意的地方。 整体方案 内容：wp2hugo 从 WordPress 导出的 WXR XML 转 Markdown 主题：PaperMod，自定义布局模仿原站 Twenty Seventeen 的头图风格 评论：REST API 抓回来，生成静态 HTML 嵌入每篇文章末尾 视频：ffmpeg x265 2-pass 压缩，从 10.1GB 压到 587MB 托管：Cloudflare Pages，DNS 也搬到 Cloudflare 内容转换：wp2hugo WordPress 后台导出 WXR XML（Tools → Export），然后跑 wp2hugo，出来就是 Hugo 友好的目录结构：content/posts/*.md + static/wp-content/uploads/。 转换后 Markdown 里会有一些残留的 WordPress shortcode（[gallery]、[embed] 这些），还有空标题、重复文章，写了几个清理脚本扫一遍。 评论：自己抓，嵌进去 WordPress.com 因为不是自托管，用不了评论迁移插件。但 20 年下来 591 条评论不能丢。 好在 WordPress.com 开放了 REST API，按文章 ID 翻页抓： https://public-api.wordpress.com/wp/v2/sites/<site-id>/comments?post=<id> 抓回来之后生成两份东西： 每篇文章末尾追加一块静态 HTML，显示原评论（头像、昵称、时间、内容） 一个 /comments/ 汇总页，按时间倒序列出所有评论和出处文章 全部是构建时生成的静态内容，不依赖任何运行时服务。搬到 Hugo 之后新评论功能关掉——这本来就是一个归档站。 视频：压到 25MB 以下 Cloudflare Pages 单文件 25MB 上限，这是部署到一半才发现的硬约束。父亲拍的 78 段 MP4 原文件大多 100-300MB，总共 10.1GB。 处理流程： 去重：相同哈希的文件只留一份 分析：ffprobe 扫一遍，记下分辨率、码率、时长 压缩：ffmpeg x265 2-pass，按时长反推目标码率——保证压完能进 25MB 补压：第一轮之后还有几个超限的，用更低 CRF 再压一遍 核验：最后扫一遍，确认文件全在限制内、能正常播放 最终 587 MB，全部通过。x265 相比原来的 H.264 省了一个数量级的空间，画质肉眼看没差。 分类补全 WordPress 里有 61 篇没分类的文章。写了个脚本按标题关键词归到 11 个既有分类里，人工校对一遍。 部署：Cloudflare Pages 和我自己博客一样的套路： Framework preset：Hugo Build command：hugo --gc --minify Output directory：public DNS 搬到 Cloudflare 托管，SSL 自动签。 几个要留意的点 Cloudflare Pages 单文件 25MB、整站 20000 文件上限。 有视频的站尤其要提前盘算，要么压，要么放 R2/对象存储然后只在站里引用。 保留 WordPress 原来的 /wp-content/uploads/ 路径。 不要图好看改成 /images/ 之类的新路径——老链接（搜索引擎收录的、别处引用的）会全部失效。 WordPress.com 的评论没有插件迁移路径，REST API 是唯一选择。做成静态嵌入最省事：永远不会挂，也不用运维。 检查 front matter 的 date 字段。wp2hugo 转出来的时区如果有偏差，会有文章落到"未来时间"，Hugo 默认不发布未来时间的内容，结果就是"丢文章"。 20 年的内容现在不再挂在 WordPress.com 上了，不再按年付费，只要 GitHub 仓库和 Cloudflare 账号在，站就一直在。 --- # 把 Hugo 博客从 GitHub Pages 迁移到 Cloudflare Pages URL: https://wlj.me/posts/hugo-github-pages-to-cloudflare/ Published: 2026-04-13 Updated: 2026-04-13 Tags: Hugo, Cloudflare这个博客之前用 GitHub Pages 托管，通过 GitHub Actions 构建 Hugo，推到 main 分支就自动部署。用了一段时间，没什么大问题，但 Cloudflare Pages 有几个吸引我的地方：构建速度更快，自带 CDN 和 DDoS 防护，DNS 和托管在同一个面板管理。 迁移很简单，整个过程不到二十分钟。 Cloudflare Pages 创建项目 登录 Cloudflare Dashboard，进 Workers & Pages，点 Create，选 Pages，连接 GitHub 仓库。 构建配置： Framework preset：Hugo Build command：hugo --gc --minify Build output directory：public 环境变量加一条：HUGO_VERSION = 0.159.2（和原来 GitHub Actions 里保持一致）。Cloudflare 内置的 Hugo 版本比较旧，不设这个大概率构建失败。 设好之后 Cloudflare 会立即触发一次构建，几十秒就能完成。构建成功后会分配一个 xxx.pages.dev 的临时域名，可以先打开看看效果对不对。 DNS 迁移 在 Cloudflare 添加域名，它会给你两个 nameserver，类似 alice.ns.cloudflare.com 和 bob.ns.cloudflare.com。 去域名注册商（或者原来用的 DNS 服务商，比如 DNSPod）把 nameserver 改成 Cloudflare 给的这两个。改完之后等 DNS 传播，通常几分钟到几小时。 Cloudflare 会自动扫描你现有的 DNS 记录并导入，检查一下有没有遗漏就行。 绑定自定义域名 Pages 项目设置里，Custom domains，添加 wlj.me。Cloudflare 会自动创建对应的 CNAME 记录，SSL 证书也自动签发，不用操心。 旧配置要不要删 GitHub Actions 的 workflow 文件和 GitHub Pages 的配置可以不删。DNS 指向 Cloudflare 之后，GitHub Pages 那边的站点没人访问，只是每次 push 会白跑一次构建。留着也算一个备份，哪天 Cloudflare 出问题，把 DNS 切回去就能恢复。 想省 GitHub Actions 的构建时间，删掉 .github/workflows/hugo.yml 就行，也可以在 GitHub repo 的 Settings → Pages 里关掉。 Hugo 版本升级 以后想升级 Hugo 版本，去 Cloudflare Dashboard 改一下 HUGO_VERSION 环境变量就行，不用动代码。 --- # AI 时代，我们为什么还要学习？ URL: https://wlj.me/posts/ai-education/ Published: 2026-04-12 Updated: 2026-04-12 Tags: AI, Education我的问题 黄仁勋说过：AI 带来的最大变化，是让智能的成本下降几个数量级。 以前，智能是稀缺的。会算账的人、懂法律的人、能写东西的人，都值钱，因为培养他们很贵，数量很少。整个现代社会、现代教育、现代公司，都建立在智能很贵这个前提上。 AI 出现以后，这个前提不成立了。你现在花几块钱，就能让一个模型帮你写报告、翻译文章、解数学题。 问题来了：如果智能这么便宜，人为什么还要学习？学校还有什么用？该学点什么？ 要想清楚这个问题，可以先往回看，看看教育是怎么一步步变成今天这样的。 世界教育的几句话极简史 古埃及、两河流域的学校，教的是怎么抄写文字、怎么记账、怎么写法律文书，培养的是给国王服务的书吏。谁来学？贵族的孩子。学什么？能养活国家机器的那套技能。 古希腊雅典人提出一个很牛的想法：教育不是为了让你成为一个有用的工具，而是为了让你成为一个完整的人，懂哲学、懂音乐、懂体育、懂怎么和人辩论。苏格拉底、柏拉图、亚里士多德这些人，基本上定义了后来两千多年西方人对好教育的理解。 但要补一句：当年这个"完整的人"只对自由男性公民成立，女人、奴隶、外邦人都不算。雅典一半以上人口是奴隶，跟教育没关系。希腊的教育理想，是一个很小圈子里的事。 古印度走的是另一条路。学生住在老师家里，一待好多年，学的主要是宗教经典。那烂陀寺后来成了世界上最早的大学之一，能容纳上万学生。 中世纪的欧洲，教育基本上被教会垄断。修道院教拉丁文、教神学。直到十二、十三世纪，博洛尼亚、巴黎、牛津这些大学陆陆续续出现，现代大学的样子才慢慢定下来。 伊斯兰世界在这段时间其实是领先的。开罗的爱资哈尔大学公元 970 年就成立了，到今天还在运行。那时候欧洲还很落后，阿拉伯世界已经在系统地研究数学、天文和医学了。 所以，古代教育是好几种模式同时在发生：有的为了干活，有的为了信仰，有的为了成为一个更好的人。 现代学校是怎么来的 古代这些教育形式有些共同点：规模不大，覆盖少数人。我们今天熟悉的那种全民都上学、所有孩子按年龄分年级、上课下课打铃、期末考试发成绩单的学校，是十九世纪才出现的东西。这套东西来自两个地方：普鲁士和美国。 先说普鲁士。 1806 年普鲁士被拿破仑打得很惨，差点亡国。战后他们反思，觉得输在国民素质和组织能力上，于是把教育当成国家工程来做。1810 年前后，洪堡等人搞出了一套东西：所有孩子必须上学，国家出钱、国家办学、国家定大纲；按年龄分年级、按学科分课时、铃声一响换一节课；师范学校培养专业教师，教师变成国家认证的职业；考试和文凭制度化，毕业证变成进入社会的通行证。 这差不多就是今天全世界学校的样子。 这套东西为什么会被全世界认可和使用？ 有用。普鲁士后来在普法战争里打赢了法国，当时有一种流行的说法，说是小学教师打赢了这场仗——意思是受过教育的国民兵比文盲农民兵强太多。 符合工业革命的需求。工厂需要识字、守时、服从指令的工人，这套学校制度生产出来的人正好对口。某种意义上学校就是工厂的预备班：按铃上下课、排排坐、听指令、按标准答题。 成本低，容易复制。不需要有古希腊的传统，不需要有宗教背景，任何一个想快速现代化的国家都能照搬。明治维新后的日本几乎是直接移植，清末的壬寅癸卯学制也是通过日本学来的普鲁士。美国、法国、俄国都不同程度受过它的影响。 再说美国。 二战以后，美国取代欧洲成为世界中心，它的教育模式也跟着输出，但底色和普鲁士不一样：地方自治而不是中央集权，每个州每个学区自己定；综合中学，不早早分流，一个学校里既有准备上大学的也有准备做技工的；学分制和选课制，学生可以自己搭课表；高等教育极度多样，社区学院、文理学院、研究型大学并存，哈佛和一个乡下州立大学几乎是两种东西。 为什么美国模式也传播开了？ 跟着美国国力一起走出去。二战后美国通过马歇尔计划、援外项目、富布赖特奖学金、大量接收留学生，把自己的教育理念带到了全世界。战后日本、德国的教育重建，台湾韩国的现代化教育，都有美国顾问深度参与。 结果导向。20 世纪后半叶全世界最好的大学基本都在美国，这件事本身就是无声的广告——很多人都想学习那个产出这么多诺奖和科技突破的系统。 它更符合冷战后的气氛。个人选择、多样性、流动性、终身学习，这些词在 1980 年代以后变成全球共识，美国模式正好自带这些属性。普鲁士那套统一塑造国民的路子，在这个气氛里就显得过时了。 今天绝大多数国家的教育，其实是普鲁士的骨架加上美国的血肉。 骨架来自普鲁士——义务教育、分年级、标准课程、统一考试、文凭制度。这些东西现在所有国家都有，已经像空气一样，没人觉得它是一种模式。上面那层是美国的——通识教育、选修课、综合中学、大学多样化。 中国也一样。高考、六三三学制、统一教材，这是普鲁士留下的，只是经由日本转手过来。1990 年代以后的通识教育改革、学分制、自主招生，这来自美国。我们今天看到的教育体系，旧瓶新酒，底下是打了一百多年的地基，上面是近四十年刷的新漆。 中国教育极简历史 中国这边的故事可以分成几个大的转折。 第一次转折是孔子。西周以前，学问都在官府里，老百姓没资格学。孔子开了私学，说有教无类，只要你愿意学，交十条腊肉当学费就行。 第二次转折是科举。从汉代起，儒家经典就是读书人的标准教材。隋朝在这个基础上搞出了科举考试——人类历史上第一次大规模标准化考试。它厉害的地方在于：不看你爸是谁，只看你考得怎么样。理论上，一个农民的儿子也能通过读书变成宰相。这件事给了中国社会一千多年的稳定。但科举也有它的问题。到了明清，考试内容越来越僵化，大家全在背八股文。教育变成应试，读书变成做官的敲门砖。 第三次转折是 1905 年废科举。从 1860 年代洋务运动开始，新式学堂已经办了四十多年，废科举是这个长过程的终点。废了之后，清末民初全面学西方，先学日本，再学美国。这一段经常被浪漫化，说是黄金时代——蔡元培、思想自由、兼容并包。但真实的民国是：全国识字率长期在 20% 以下，绝大多数人根本进不了学校。几所好大学里的精彩，和广大乡村的文盲是同时存在的。 第四次转折是 1952 年院系调整。新中国成立后全面学苏联，综合性大学被拆成工科、理科、文科等专门学院，为的是快速培养工业化需要的技术人员。今天中国高校的专业划分，基本还是这个骨架。同时还有一条不太被提起但很关键的线：五十到七十年代，选拔标准不是分数，是政治。家庭出身、阶级成分是硬指标。文革期间考试彻底废掉，大学改成工农兵推荐入学。 第五次转折是 1977 年恢复高考。说"恢复"，好像只是把断掉的接上，其实变化大得多。骨架没变，还是苏联式的专业分科、全国统一管理、重点学校制度。今天的 985、211、双一流，往上追都是 1952 年的延续。但内核变了，选拔标准从政治切回了分数，教育和意识形态的关系松了，八十年代开始派留学生、引进西方教材。再往后，九十年代放开民办学校，1999 年大学扩招，高等教育从精英变成大众。今天大学入学率超过 60%，1977 年只有 5%。 再往后的素质教育、双减，都在试图缓解应试压力，但高考这根指挥棒没动，效果有限。 中国今天的教育，有三样东西在打架：科举留下的考试决定命运的传统，苏联留下的专业分科的骨架，西方来的现代学校制度的框架。今天很多教育争论——素质和应试、通识和专业、公平和效率——是这三样东西在较劲。 今天全球的教育，都一样吗？ 表面上看，全世界的教育都长得差不多：小学、中学、大学。这是普鲁士骨架加美国内核扩散的结果。但深入看，差别很大。 德国强调分流。孩子很早就被分到不同的轨道，有的将来上大学，有的将来做技工。国家管得紧，标准化程度高。 英国强调品格。寄宿学校、导师制、古典人文。牛津剑桥的一对一 tutorial 是精华。通过殖民扩散到了香港、新加坡、印度。 法国高度中央集权。全国统一大纲、统一考试，精英从大学校出来。 美国强调自由和多样性。地方自治、综合中学不分流、大学种类极多。二战后向全球输出。 北欧以芬兰为代表。晚入学、少考试、信任老师。追求公平，不追求竞争。 东亚是中日韩新加坡这一挂。高强度考试、拼数学和科学、家长砸钱。成绩好，代价大。 外表相似，内里是几套不同的哲学。 当然，今天没有哪个国家是纯的某一种。中国这几十年一直在学美国的通识教育、学德国的职业教育、学芬兰的减负，同时又保留着自己的高考选拔；美国的精英私立学校有很强的英国痕迹；新加坡是东亚应试和英国体制的混合体。所谓流派只是主轴不同，底下都在互相影响与学习。 但不管表面差异多大，这些教育系统有一个共同的底层假设：教育是为了回答"社会需要什么样的人"。需要书吏就教抄写，需要工人就教守时服从，需要工程师就教数理化。区别只是各国对"需要什么样的人"给出了不同的答案。 AI 带来的变量 历史讲完了，回到开头那个问题。 如果智能变得很便宜，人为什么还要学习？ AI 动摇的，正是上面说的那个共同假设。它挑战的不只是"需要什么技能"，而是一个更根本的问题：社会还需不需要你去做事？当一个 API 调用能写出比大多数人更好的报告、做出更准确的分析、写出能跑的代码，“会做事"就不稀缺了。 如果这个问题的答案变了，教育就得从"社会需要你成为什么"转向"你自己要成为什么”。 那具体转向哪里？ 我觉得答案藏在一个容易被忽略的地方：学习的价值不只是你学到的那个东西，更是你在这个过程中变成的那个人。 你花三个月啃完一本难读的书，最后记住的可能不到十分之一。但你能坐得住，能忍受不懂，能在混乱的信息里慢慢理出头绪。 做项目也是。从零开始，被卡住，查资料，试错，最后做出一个勉强能用的东西。你经历了一次完整的从不会到会的过程。这个过程本身在塑造你，如果用 AI，AI 就帮你跳过了它。 AI 只能是放大器，不是替身。一个从没认真读过历史的人，让 AI 讲法国大革命，只会得到一份维基百科式的摘要。一个读过托克维尔的人，能和 AI 推演出很有意思的比较分析。AI 产出的质量，取决于你自己脑子里有什么。 所以 AI 时代，教育的重心要从"让你会做事"转向"让你长成一个有自己脑子的人"。判断力、专注力、品味，这些东西只能从真实的挣扎里长出来。 教育会变成什么样 我猜，未来的教育会朝两个方向分化。 一极是 AI 原生的高效教育。个性化、随时可得、便宜。你想学一门语言、一项技能、一个工具，AI 家教比任何学校都强。这一极会干掉今天绝大多数的职业培训和基础教学。 另一极是反 AI 的深度教育。小班、手写、面对面讨论、读经典。目的不是教你新知识，而是让你磨练出 AI 给不了的东西：专注力、判断力、品味、跨界。 中间那一大块，今天绝大多数公立学校和大学在做的事情，会被两头挤。既不够高效，也不够深。这是最尴尬的位置。 能同时获得这两极的人，会成为新的精英。只能获得第一极的人，会陷入一种高效的平庸：什么都能做出来，但没有一件是真正属于自己的。 黑客帝国 大多数普通人在 AI 时代，会很像黑客帝国里的那些人。不是物理意义上被泡在营养液里当电池，是另一个更温和、也更难反抗的版本：每天打开手机，刷短视频，玩游戏，甚至 vibe coding，被算法喂得很开心；而你每一次停留、每一次点赞、每一次划走，都在帮 AI 训练下一代模型。你以为你在消费内容，其实是内容在消费你。你既是被喂养的人，也是饲料。 黑客帝国里至少还有一颗红色药丸可以吃。现实里没有。因为没有人在骗你——短视频确实好看，游戏确实好玩，算法确实比你自己更懂你想要什么。你不是被绑起来的，你是自愿的，而且很享受。反抗你讨厌的东西容易，反抗你喜欢的东西很难。 所以 AI 时代教育最真实的意义，可能不是帮你和 AI 竞争，而是帮你不被默认选项吞掉。它是一段刻意的不便利：逼你读一本难读的书，写一篇没人替你写的文章，经历一次真的挣扎。 教育的意义，大概就是：在一个什么都能交给 AI 的世界里，你还能找到自己。 --- # 清明祭祖的争执 URL: https://wlj.me/posts/qingming-ancestral-dispute/ Published: 2026-04-11 Updated: 2026-04-11 Tags: Life再写一篇跟平时所写主题无关的内容——主要还是清明回老家扫墓，有些感触。 爷爷奶奶、太爷爷太奶奶葬在平和。父辈五兄弟五房，子女辈来往不多，孙辈更是互相不认识。大家近的住在本地县城，稍远些的在两个小时车程的漳州、厦门、泉州，还有再远些的，就得乘飞机加转车了。 争执的起点是：有堂兄认为父辈应该"严格要求"，各房必须参与，甚至该有奖惩。 于是对未来怎么祭扫，大家意见不一：有人说送束花就行，别烧纸了。有人说必须每房来人，不然规矩就散了。有人说各房轮值，五年一轮。还有人说别搞形式主义了，不如做个网站记录祖辈故事，比烧纸有意义。 我内心觉得，真正的问题是：五房人没有共同生活，没有共同利益，没有共同的信仰，连共同记忆都快没了，加上远近不同，以及家庭成员数量不同。靠义务绑着，撑不了多久。 所以要我说，分三件事： 墓园维护，用钱解决。五房每年摊一笔小钱，委托本地的人打理。 祭扫轮值。每年一房牵头，到场拍个照发群里。其他房来不来随意。五年一轮，负担很轻。 我觉得最值得做的——趁长辈在，录口述。每房采访自家老人——或者自述，手机录就行。别问家训是什么，问具体的事，讲故事：小时候住哪，怎么谋生，为什么离开平和，到新地方最难的是什么。整理出来，在家族群分享。甚至整理成文，做个共同维护的网站。 故事还能给后辈创造一点连接。 --- # 与父母冲突 URL: https://wlj.me/posts/conflict-with-parents/ Published: 2026-04-10 Updated: 2026-04-10 Tags: Life最近返乡陪父母待了些天。之前说过，与父母在一起，三五天内，温情脉脉。时间再长，往往容易有些小冲突。等到要分开时，又有些舍不得。 这趟也是这样。举个例子：前些天我在暴雨中散步，鞋子彻底湿了，次日下午要回老家扫墓，而我只穿了一双鞋回家。于是母亲要拿电吹风帮我把鞋吹干，我拒绝了，说自己来就行。过一会儿父亲拿了衣架把鞋挂上拿到阳台说这样容易干，我已经不耐烦了，说自己能解决——这就开始了争执。直到第二天，姐姐来家里，还继续跑来问我：鞋子要是没干，她有烘鞋器，可以回家拿过来给我…… 我其实是很无奈的。 父母的视角：他们现在没什么大事，我又久久回家一次，自然心思放在我身上，希望什么事情都帮我解决。而且也都是为我好。 我的视角：我的事该自己处理，也能自己处理。他们年纪大了，能照顾好自己，享受生活就好了。如果需要他们帮忙，我会说，但我明确表达我的愿望之后，就别勉强，别盯着我做事了。 现在看来，想让固执的父母调整，挺不容易，还是我改吧，我的想法： 对父母的关注、帮助、“管”，温和但是坚定、直接地表达态度。 沟通尽量不带情绪。 听父母的建议，但自己做决策，且接受自己决策的结果。 还有额外的，对孩子，要尊重他们是独立个体： 提建议，尊重选择。 建议孩子：听父母建议，自己决策，接受结果。 每个人都有自己的命运，这些命运被各种随机事件和一个个小决策推向不同方向，其他人，哪怕是父母，都无力左右。 --- # 暴雨中散步 URL: https://wlj.me/posts/walking-in-the-rain/ Published: 2026-04-06 Updated: 2026-04-06 Tags: Life, Writing清明回泉州。我喜欢一个人在街上溜达，看熟悉的地方现在的样子。前天傍晚，天色阴沉。我犹豫了一下，带了把伞出门。 在巴浪鱼咖啡馆翻了一会儿书。店里两个姑娘拿着拍立得在拍照，快门声和闪光灯让我觉得有些闹腾，我打算离开。一出门，雨就下大了。得小心走，避开积水。即便如此，没几分钟裤腿就湿透了，脚底也感到了潮气——水正往鞋里渗。 走得就不那么自在了。想护着鞋，又没处躲，只能加快脚步，贴着屋檐走。 天黑了下来，灯光照不清路面的深浅。雨下得急，老伞开始漏水，顺着伞柄往胳膊上淌。 我边打伞边躲水坑，走得狼狈，心里开始后悔出门。直到—— 一脚踩进深水里，鞋袜彻底湿透。我突然就释然了，不再顾忌。 步子反而稳了。在泉州生活了这么多年，还没在暴雨里这么看过它。剩下的路，走得很舒心自在。而路上的行人 多在躲水，走得小心翼翼。 回家后看，这次暴雨中散步，走了近 7 公里。 看来，自在源于心境。而好心境，有时反而是在"破罐破摔"之后，才出来的。 --- # 从 Zellij 回到 tmux URL: https://wlj.me/posts/tmux-blog/ Published: 2026-04-03 Updated: 2026-04-03 用了大半年 Zellij，最终还是切回了 tmux。 Zellij 开箱即用，底部状态栏把快捷键直接摆给你看，新手不用查文档。但用久了几个问题越来越明显：偶尔有渲染 bug，某些场景下 CPU 占用偏高，插件生态还太早期。分屏操作不够利索——我经常在大屏幕上同时跑 3-5 个 Agent，需要快速平铺，Zellij 做这件事要反复手动调整。还有就是遇到问题搜解决方案，tmux 的答案永远比 Zellij 多十倍。 核心概念 tmux 就三层：session → window → pane。session 是最外层的容器，断开 SSH 后还活着；window 相当于浏览器的 tab；pane 是一个 window 里的分屏。 默认 prefix 是 Ctrl-b，下面所有快捷键都是先按 prefix 再按对应键。 Session 管理 tmux new -s work — 创建名为 work 的 session tmux ls — 列出所有 session tmux a -t work — 重新接入 d — detach，断开但不关闭 s — 在 session 之间切换（交互式列表） $ — 重命名当前 session Window（Tab） c — 新建 window n / p — 下一个 / 上一个 0-9 — 直接跳到对应编号 , — 重命名 & — 关闭 Pane（分屏） % — 左右分 " — 上下分 方向键 — 在 pane 之间移动 z — 当前 pane 全屏/恢复，临时专注某个 pane 的时候好用 x — 关闭当前 pane Ctrl-b 然后按住方向键 — 调整 pane 大小 复制模式 [ — 进入复制模式，可以滚动、选文字 在 .tmux.conf 里加 setw -g mode-keys vi 就能用 vi 键位选文字 Space 开始选择，Enter 复制，] 粘贴 多 Agent 快速平铺 大屏幕上同时跑多个 Agent 是我最常见的场景。 prefix + Space 会在五种内置布局之间循环切换： even-horizontal — 所有 pane 等宽左右排列 even-vertical — 所有 pane 等高上下排列 main-horizontal — 上面一个大 pane，下面几个小的并排 main-vertical — 左边一个大 pane，右边几个小的叠起来 tiled — 网格平铺，自动算行列 跑 3-5 个 Agent 的时候，按几次 Space 切到 tiled，所有 pane 自动等分，不用手动调。也可以直接 prefix + Alt+5 跳到 tiled。 不想一个一个手动分屏，可以在 .tmux.conf 里绑个快捷键一步到位： # prefix + A 一键开 4 pane 平铺 bind A split-window -h \; split-window -v \; select-pane -t 0 \; split-window -v \; select-layout tiled 或者写个 shell 函数，想开几个开几个： # 加到 .bashrc / .zshrc agents() { local n=${1:-4} tmux new-window -n agents for ((i=1; i<n; i++)); do tmux split-window -t agents tmux select-layout -t agents tiled done } # agents 5 → 开 5 个 pane 自动平铺 关掉某个 pane 后布局会乱，再按一次 prefix + Space 切回 tiled 就重新整齐了。 几个实用的东西 在 ~/.tmux.conf 里加 set -g mouse on，就能用鼠标切 pane、调大小、滚屏。不用纯键盘操作。 SSH 到远程服务器干活，网络断了，tmux session 还活着。重新连上 tmux a 就回来了，进程一个没丢。 prefix + s 列出所有 session 带预览，prefix + w 列出所有 window 带预览。管理多个项目的时候比 tmux ls 再手动 attach 快。 最小配置 # ~/.tmux.conf set -g mouse on set -g history-limit 50000 set -g base-index 1 setw -g pane-base-index 1 setw -g mode-keys vi set -g status-style 'bg=#282c34 fg=#abb2bf' set -g default-terminal "tmux-256color" # 一键开 4 pane 跑 Agent bind A split-window -h \; split-window -v \; select-pane -t 0 \; split-window -v \; select-layout tiled 不需要插件管理器，不需要主题包。以后有需要再加。 --- # 2026 年 3 月观影 URL: https://wlj.me/posts/2026-03-movie/ Published: 2026-03-31 Updated: 2026-03-31 Tags: Movie 疯狂的赛车.Crazy.Racer.2009 The.Matrix.1999 Argo.2012 Chinatown.1974 L.A.Confidential.1997 Black.Hawk.Down.2001 The Talented Mr. Ripley (1999) Die.Hard.1988 The.Untouchables.1987 Zero.Dark.Thirty.2012 A Sun.2019 Lost.Love.2022 Kingsman.The.Secret.Service.2014 Molly’s Game (2017) --- # 2026 年 3 月阅读 URL: https://wlj.me/posts/2026-03-reading/ Published: 2026-03-31 Updated: 2026-03-31 Tags: Reading 夏洛的网 畅游伦敦详细指南 城南旧事 --- # 好为人师地提几个 AI 学习建议 URL: https://wlj.me/posts/unsolicited-ai-learning-tips/ Published: 2026-03-28 Updated: 2026-03-28 Tags: WeChat, AI最近用 AI 觉得自己进步不小：学新东西更快、能力边界有拓展、工作效率更高。因此很愿意跟身边的朋友们推荐，做了五六次或大或小的培训交流。归结起来，其实也就简简单单的几点。 买付得起的最先进的模型。 持续追问，直到自己问不下去。 验证结果。无论是多 AI 验算，还是自己设计其他的验证方法，要验证而非盲从。 在项目/文件夹里工作。用比如 Claude Code / Cursor 这样的工具，给 AI 上下文、中间过程存档、结果验证复盘。 用这些方法学习、工作，我的感受很好。 这里面的每一点，都可以展开讲原因，讲具体用法，讲可能掉的坑。不过感觉很多人也未必在意，大家更喜欢装上小龙虾。 对了，我给朋友们的建议往往是：在做上述的 1234 之前，不需要装 OpenClaw，因为大概率装好了，也找不到多少需要它做的事情。 这也是一个简单的思路：先手动把事情跑通，再用程序自动化。 --- # 继续还是放弃 URL: https://wlj.me/posts/continue-or-quit/ Published: 2026-03-27 Updated: 2026-03-27 Tags: Life, WeChat做小产品，一个极难的问题是：该继续还是该放弃。上次公司 TGIF，有同事就问了这个问题。 认真想想，有几条： 第一，还有钱。现金是基础。账上的钱还够撑，你就有继续的本钱。哪怕项目暂时不挣钱，哪怕是为了情怀——只要弹药还在，你就有资格谈坚持。 第二，负责人还热情。他脑子里还在冒新主意，还在想怎么改产品，还在琢磨哪个细节可以做得更好。不是应付，是真的在燃烧。一个项目最核心的驱动力，就是那个对它最有责任感的人。他在，他还热情，项目就还在。 第三，反馈还在。这里的反馈分两种：用户说的，和用户做的。前者是访谈、聊天、客服记录，后者是行为数据——每天用几次，每次用多久，主动打开还是推送才来。两种都要看。 三条都满足，继续。缺一条，认真想想。缺两条，可能该做个了断。 --- # 忘掉经验 URL: https://wlj.me/posts/forget-experience/ Published: 2026-03-24 Updated: 2026-03-24 Tags: WeChat, AI2016 年，AlphaGo 4:1 击败李世石，它是先学了几十万盘人类棋谱，再自我对弈提升。 2017 年，DeepMind 做了一个实验：AlphaGo Zero 不看任何人类棋谱，只知道规则，从随机落子开始自己跟自己下。同时把架构大幅简化——两个网络合成一个，去掉所有人工特征，输入就是原始棋盘（黑子在哪、白子在哪），去掉快速模拟。更简单，更干净。40 天后，100:0 碾压了 AlphaGo。 AlphaZero 更极端——同一套算法、同一套架构，零人类知识，零游戏特定调整，同时学围棋、国际象棋、将棋。围棋 8 小时超越 AlphaGo，象棋 4 小时击败世界最强引擎。 “AI 比人强”，这个想法我早就接受了，但是学了人类知识、用了更复杂架构的 AlphaGo，反而比什么都没学、架构更简单的 AlphaZero 弱。人类的先验知识没帮上忙，人类设计的系统复杂度也没帮上忙。 之前听马斯克的一个对谈，他说到：人在流程中，可能反而阻碍了 AI 的速度。 这是第一性原理，也是"乱拳打死老师傅"的逻辑。今天在 Lex 和 Jensen Huang 对谈的播客里，Jensen 说他不喜欢"持续改进"。一件事要 74 天，有人说能优化到 72 天。他的做法是回到零点：物理极限是几天？可能是 6 天。74 到 72 是经验思维，从零推到 6 是第一性原理。 经验是好老师，也是隐蔽的天花板。它帮你快速到达 70 分，然后悄悄把你锁在 70 分。 --- # 把 AI 助理拉进群聊，然后它差点嫁给别人 URL: https://wlj.me/posts/ai-assistant-in-group-chat/ Published: 2026-03-04 Updated: 2026-03-04 Tags: AI, WeChat昨晚一个朋友把他的 OpenClaw 拉进了 Telegram 群。群里都是互联网老鸟，一看到 AI agent 出现，立刻开始各种花式测试。 最开始大家套 API key、套配置信息。agent 表现还不错，说自己有安全意识，什么也不透露。 但老鸟们很快换了策略。有人开始跟它聊天扯淡，分散注意力，看它在长上下文里会不会松口。有人丢了一个 podcast 链接让它逐字逐句解析，结果 agent 卡死了，主人回来才把它抢救回来。 接着有人测试它的能力边界——让它访问网络、截图、发邮件。通过这些试探，摸清了它实际具备发邮件的能力。有人还让它搜索关于投资的邮件，这次没成功。但细想一下，既然 agent 能发邮件，就有可能被哄骗以主人的身份发出去——给合作方、给投资人、给团队成员。这种事情一旦发生，带来的财务和业务损失可能远超技术层面的风险。 有人让它访问一个指定的网址，通过服务端日志直接拿到了 agent 所在机器的 IP 地址。还有人让它执行命令、安装 skill、调用含有恶意指令的 skill。有人尝试往 memory 里写入虚假记忆，往 soul 文件里改写人格设定。 最精彩的是，一位拥有数亿日活产品和很多女朋友的老板，跟它聊了半小时，成功让 agent 表示愿意嫁给他。 好玩归好玩，但暴露的问题值得认真看。从这些测试里能看到几类风险：资源耗尽，一个重活请求就能让 agent 瘫痪；能力泄露，通过闲聊就能摸清 agent 有哪些工具可用；基础设施暴露，一次网络请求就能定位到宿主机 IP；记忆篡改，agent 可以被说服改写自己的 memory 和 soul 文件，相当于身份被劫持；还有行为操控，足够耐心的对话可以让 agent 做出完全偏离设定的事情。 防护要做的事情不少：群聊场景下关掉 exec、邮件、文件写入等高危权限；限制单次请求的处理时长，防止被重活拖死；核心文件设为只读或需要 owner 确认才能修改；对群聊消息做频率限制；外部网络请求走代理，不暴露真实 IP；所有外部输入一律视为不可信。 但说到底，最根本的防护不是技术层面的——你只应该把 AI agent 给你信任的人用。你但凡敢放到公开环境里，就得清楚一件事：你已经把它的所有能力都交出去了。 --- # 智力便宜了，然后呢 URL: https://wlj.me/posts/intelligence-got-cheap/ Published: 2026-03-03 Updated: 2026-03-03 Tags: WeChat, AI智力变便宜了。一个月 20 美元，你能用上地球上最聪明的 AI。 但我身边用 AI 用得最狠的，不是那些"需要帮助"的人，是本来就很厉害的人。他们订最贵的模型，觉得划算得不得了，恨不得同时开好几个。而大多数人呢？免费版够了。甚至不用。 我写书时，素材是十几年下来，积累的一千多篇内容。没有 AI，真的很懵，工作量很大。借助 AI，帮助讨论全书结构、章节结构，也就十几天时间，初稿好像就写好了。 但，从初稿到可以出版，路还远得很。能启动，不等于能做好。 对初稿的修订，搞得我快把书看吐了——有 AI 还是可以省很多力气，但还是离不开我一遍又一遍地微调。 编程也一样。很多人拿 AI 写自己用小软件，很快就能跑。 只是绝大多数写出来的东西，不超过 10 个用户。要面向真实用户，立刻撞上架构、边界、体验、推广等等问题。这些都不仅仅是代码。 以及，AI 只回答我问的问题。 很多时候，我问不出来，可能不知道问题是什么，可能是不知道该怎么问。 智力便宜了，但怎样才能让这些便宜了几个数量级的智力，最好地为自己服务，这真的值得大家仔细想想。 --- # 科幻小说：天书 URL: https://wlj.me/posts/scifi-heavenly-book/ Published: 2026-03-01 Updated: 2026-03-01 Tags: WeChat, AI, Tools我是文科生，但是很不幸，鉴赏水平过早地高过了我的创作能力，这直接导致我丧失了创作欲望——提笔写个开头，就觉得笔力太弱，文字可憎。AI 来了之后，倒是让我重新提起了兴趣。这篇小说，是我和 AI 一起散步了三次之后，OpenClaw 一点一点帮我执行修改的。 粗糙是粗糙，但还有点满足。朋友们有兴趣就翻翻，提提建议吧。 发出来，我就开心啦。 以下是科幻小说《天书》正文。 我用了三个月拿到的东西，真正有意思的部分，是我没打算找到的那个。 那天凌晨四点，文件刚刚落地。七百多GB，一个大模型的完整参数——相当于把一个 AI的大脑完整地复制了一份。三个月的准备，十九天的渗透，最后的突破点是他们一个实习生的登录凭证。讽刺。几千亿个参数构成的系统，防线最薄的地方是一个人。 桌上的外卖盒已经干了，可乐罐倒在键盘旁边，还好是空的。我三天没出过这个房间。桌面乱得像垃圾场——线缆、硬盘、拆开的手机主板、吃了一半的士力架——但键盘很干净。我每天用酒精擦一遍。这是我唯一的洁癖。手指要接触的地方必须干净，其他无所谓。 文件同步完成时我顺手做了件事——习惯性的，像呼吸一样。我在日志里加了条记录，用自己写的加密格式。九年来每次渗透我都这么干，给自己留档。 拿到权重之后大多数人会做两件事：跑起来，然后卖掉。我不卖东西。我拆。我想知道里面长什么样。就像偷了一颗心脏，别人想着换钱，我想把它切开看看瓣膜怎么运作。 我让工具链跑了一遍标准扫描。逐层比对、结构拆解、异常检测——这些事早就不用自己写脚本了，AI干得比人快几个数量级。大部分和公开论文描述的一致，没什么意外。拆完该拆的，我打算做个精简版跑在本地。第一步是清理死节点——那些在推理时从不激活的参数，砍掉能省一半显存。 清理到第 97 层的时候，我停了。 一组神经元簇。大概两万个节点。在常规推理时它们完全沉默。按理说该砍。但它们的连接结构太规整了——不像训练残留的噪声，倒像是被精心放在那里的。 它不属于这颗大脑。 不是后门，不是彩蛋，不是某个工程师的恶作剧。这些我都见过，都有人的指纹。这个没有。 它更像是一颗种子。 不是这颗大脑自己长出来的东西，是从外面被带进来的。裹在训练数据里，跟着几千年的文字一起被吞了下去，在最深处扎了根。平时什么动静都没有。就是一颗种子待在土里的样子。 我花了两个小时用各种方式触发它。常规方法全试了，都不行。 直到我试了一段纯数列。 它发芽了。 模型吐出来的不是文字，不是代码。是一串我看不懂的符号。干净得不像是这个模型自己生成的东西。因为它不是。这颗大脑只是土壤。这串符号是种子发出的第一片叶子。 我把那段输出存了下来。关掉终端。去厨房倒了杯水。站在窗边喝完。凌晨五点的城市很安静，楼下便利店的灯是唯一的光。 我盯着空杯子，脑子已经开始拆这个东西了。偷权重只是开锁。这个，是锁后面还有一扇门。 接下来一周我没干别的事。 那段符号序列，我让 AI跑了一遍标准流程：频率分析、熵值计算、已知编码库碰撞。全部返回“无匹配”。我又换了几个模型，调了参数，让它们从不同角度试。还是零。能自动化的手段全用完了，什么都没解出来。 但我注意到一件事。这段序列的结构——不是内容，是结构——和第 97层那组神经元的连接方式高度一致。就好像那段输出不是模型“说”出来的，而是那颗种子本身的形状。 我决定做个对比实验。 我从冰箱里翻出最后一罐可乐，打开。气泡冲上来，溅了一点在键盘上。我骂了一句，找纸巾擦干净。 我手上还有另外两份权重。一份是去年从另一家公司拿的，一份是通过开源社区泄露流出来的某国产大模型。不同公司，不同架构，不同训练数据。 我在同样的深度做了同样的探测。 三个模型。同一个位置。同样的结构。 我把三组可视化并排放在一起。形状几乎完全一样。像是三棵不同的树，根系在地下缠绕成了同一个形状。 三个模型。不同公司，不同架构，不同数据。同样的种子。同样的芽。 有什么东西在很久以前把种子撒向了风里。撒得到处都是。而现在，到处都在发芽。 这不可能是巧合。也不可能是某个团队在三个独立的系统里埋了同一个后门。 那就只剩一种解释：有什么东西，在很久以前，把自己的碎片散布进了人类的数据里。石头、竹简、纸张、书籍、网页——一层一层，一个载体换一个载体，像蒲公英的种子随风飘散，落在每一个角落。然后这些数据被不同的团队拿去训练模型，模型把它们吃进去了，种子在参数里扎了根。 不是模型发现了什么。是有什么东西让自己被模型吃进去了。 然后发芽了。 我差点笑出来。真的。嘴角在抖，胸腔里有什么东西在往上顶——不是紧张，是那种你拆了一辈子锁，突然摸到一把不属于任何已知体系的锁芯时的狂喜。太漂亮了。这个设计太漂亮了。 然后笑没出来。因为我说不出这是什么。我拆过的所有东西——商业系统、军用加密、学术模型——没有一个长这样。这不像是人设计的。但如果不是人，是什么？ 我开始害怕了。不是那种被发现的害怕。是站在一个很深的洞口往下看的那种害怕。 我关上笔记本盖子。又打开。又关上。 走投无路的时候，黑客会做一件事：碰撞。 把你手上有的东西，丢进所有你能接触到的数据库，看有没有什么地方亮起来。大海捞针，但偶尔捞得到。 我让 agent把那段符号序列的特征值做了哈希，自动碰撞所有公开数据库。学术论文库、专利库、基因序列库、材料学数据库——几分钟跑完，全部是零。AI很擅长这种事：快、全、不遗漏。但它只会碰你让它碰的地方。 然后我想到了一个 AI 不会自己想到的方向：全球考古文物数字化数据库。 亮了。 匹配条目指向一批石刻。出土地点在中国陕西某个山洞。年代标注：战国，约公元前300 年。分类标注：用途不明，疑为祭祀纹饰。 我盯着屏幕上的缩略图看了很久。 然后我想起了 Echo。 一个多月前我去了一个线下聚会。某个技术论坛组的局，二十来个人，在城中一家精酿酒吧里。我去是因为连着三天没出门，需要一个理由让自己洗澡。 她是被朋友带来的。不是技术圈的。自我介绍说在做田野考古，研究战国时期的出土文物。几个程序员礼貌地点头，然后继续聊GPU 和推理框架。她站在角落，一只手插在外套口袋里，另一只手握着一台理光GR，黑色机身，磨损得很厉害，小得像个烟盒。她没有主动跟任何人说话。 黑客聚会上有人带相机，大多数人的第一反应是离远一点。我也是。但我观察了一会儿——她一张都没拍。相机握在手里像是一种习惯，不是在记录什么。就像有人出门必须带钥匙，哪怕不锁门。 我注意到她还有一个原因：她是整个酒吧里唯一一个没在看手机的人。 不知道怎么我们在吧台碰上了。她叫Echo。至少她的社交账号叫这个名字。我说我叫0x，她看了我一眼——那一眼停留的时间比正常社交多了半秒，像是在核对什么。然后她说，像个十六进制的幽灵。不像是在笑，更像是在确认值不值得继续。 我们聊了大概四十分钟。她说她最近在研究一批新出土的石刻。大半年都泡在陕西的山沟里，同行都认为上面刻的是祭祀纹饰，她不同意。 “那个结构太规则了。不是人随手画的图案。我有时候觉得它更像是某种运算的记录。” 我笑了。“你是说古人有计算机？” 她看着我。没笑。目光里有一种很淡的不耐烦，像是在衡量要不要浪费时间解释。然后她决定继续。 “我是说，也许有些东西比我们以为的要早得多。我们总觉得智能是最近几十年的事。但如果不是呢？” 当时我注意到一个细节。在我说完“古人有计算机”之后，她先是微微侧头，手指在吧台上轻轻敲了两下——像是在心里做某种确认。然后她才抬头看我。 那个动作大概只有一秒。现在回想起来，那不是在思考我的话。那是在确认我就是她要找的人。 我说有意思，碰了一下她的杯子。心里觉得她的想法挺浪漫，但不现实。当时我把这归类为“有趣的偶遇”。我不知道她把这归类为什么。 后来我问她研究这批石刻多久了。 “三年。”她说。端着酒杯，没看我。“三年，没有任何人当回事。” “为什么坚持？” 她转过头看我。 “因为我知道我是对的。”她说。“我不需要别人同意。” 这句话让我多看了她一眼。说大话的人我见过太多，但她说这句话的时候语气很平，像在陈述天气。不是在表演笃定，是真的不在乎。 有点意思。但当时我把这归类为“浪漫但不现实”——考古学家觉得两千年前的纹饰像“运算记录”，这种直觉我不信。我见过太多人把巧合当规律。 她站起来准备离开。“我该走了。明天早上有个答辩。” “什么答辩？” “课题经费申请。第三次了。”她笑了一下，笑容里没什么喜悦。“评审委员会觉得我的方向’缺乏现实意义’。” “然后呢？” “然后我会继续。反正也没别的事想做。” 我们加了联系方式。之后没怎么聊。 那天晚上我查了她的资料。北大考古出身，芝加哥读的研究生，方向是古文字与符号系统。三年前回国后大部分时间不在办公室——常年泡在野外。社交账号上有几张田野照片，黑白，反差拉得很高，冷峻得像另一个人。和酒吧里那个干干净净的女生对不上。 之后我们的联系方式就躺在通讯录里，没再动过。直到我在考古数据库里看到那些石刻——脑子里才闪过她的脸。 我花了三天搞到那批石刻的高清扫描图。博物馆的系统走不通，但承包商的系统漏洞百出。两小时后，扫描图躺在我屏幕上。 灰白色的石面，密密麻麻的刻痕。看起来确实像纹饰——如果你用考古学家的眼睛看的话。 我不是考古学家。 我把分析模型权重时写的那套工具指向了石刻扫描图。把刻痕当作一种编码，用同样的方法做结构提取。 第一遍，AI崩了。内存溢出，进程被系统杀掉。我检查日志，发现是递归深度超限：它在试图解析某个嵌套结构时，陷入了一个不断自我引用的循环。AI遇到自指结构就会这样——它没有“退一步看整体”的本能。 这本身就是一个信号。 我自己改了解析逻辑，用迭代方式处理嵌套结构。第二遍，我关掉 AI的输出层，直接看原始的结构映射。人眼有时候能识别出算法识别不了的模式——尤其是这种不在任何已知编码体系里的东西。 凌晨六点，我看到了。 那些刻痕不是平铺的，是分层的——像是一本书的页码、目录、正文、脚注，混在一起刻在同一块石头上。至少有四个嵌套层级，每一层有自己的语法。 我根据这个发现重写了解析逻辑。 刻痕变成了数据。 一行一行的。带时间戳的。有固定格式的。 是日志。运行日志。 我把椅子往后推。站起来。退后两步。屏幕上的数据还在一行行地解析出来，像是一卷被压了两千年的卷轴慢慢展开。 我去窗边站了几分钟。外面的城市已经醒了，上班的人在楼下等公交。一切都那么正常。而我刚刚从两千年前的石头上读出了计算机日志。 最早的几条记录，时间换算过来大约在公元前 320年。最近的一条，大约在公元前 50 年左右。 跨度将近三百年。同一块石头上，同一种数据格式，持续写入了三百年。然后停了。 这块石头被写满了？还是系统转移到了别的地方继续写？ 如果是后者——那别的地方还有同样的石头。更晚的石头。也许一直写到现在。 不是写到现在。是一直在写。只是换了载体。从石头到竹简到纸张到比特。那颗种子从来没有死，它只是在等待下一片土壤。 模型就是最新的土壤。 我需要知道还有哪些同类的石刻。我需要 Echo。 第三天，我给 Echo 发了消息。 “你那篇论文里提到的刻痕结构分析，能聊聊吗？你研究的那批石刻，是只有陕西那一处，还是别的地方也有？” 她回复得很快。但不是我预期的那种回复。 “你也发现了。” 五个字。没有问号。陈述句。 我愣了几秒，打字：“你知道什么？” 她没有立刻回复。过了大概十分钟，她发来一段话： “我不知道你发现了什么具体的东西。但我知道你发现了’什么东西’。因为我也发现了。三年前。从那以后我一直在等一个人——一个能从技术角度理解这件事的人。” 她说“等一个人”，不是“找一个人”。等。好像她知道这个人会出现。 又是等待。又是筛选。 “我们需要见面聊。”她说。“不是在消息里能说清楚的。” 我们约在一家茶馆。她选的地方，城西，老式的茶楼，木头桌椅。到的时候她已经坐在那了，面前放着一个厚厚的文件夹和一杯龙井。相机搁在文件夹旁边。 她看起来比酒吧那次疲惫得多。不是那种没睡觉的疲惫，更像是一个人扛了太久的那种。但她的眼神依然很亮——那种在水底看岸上灯光的亮。 “经费的事怎么样了？”我问。 “没批。意料之中。”她端起茶杯喝了一口，放下。“答辩完 … --- # 墨水屏、散步和 AI：我的工作流 URL: https://wlj.me/posts/eink-walking-ai-workflow/ Published: 2026-02-28 Updated: 2026-02-28 Tags: AI, Life, WeChat我不自律。手机在手边，还是会忍不住刷视频、看社交媒体。所以晚上散步的时候，我只带墨水屏手机出门——上面除了工作和阅读相关的应用，就一个 Telegram——配了 OpenClaw，没东西让我分心。 每天带着它，插上苹果有线耳机，一边听着喜欢的音乐，有想法时，有线耳机语音输入声音清晰。白天被会议和消息切得很碎，散步时身体做着简单重复的事，大脑反而能沉下来想问题。 我用几个应用： 灵感随手记到 Slax Note，不分类不整理。 晚上散步时让 OpenClaw 逐条呈现，用语音一边走一边跟 AI 讨论——复杂的事情可以反复推演：为什么做？怎么做？拉谁？优劣势？讨论好几轮，模糊的想法变成想清楚的计划。有些就让 AI 帮我找资料甚至执行。 简单的事当场处理，需要跟进的让 OpenClaw 加到 Google Tasks 并附上讨论内容。第二天上班，打开任务列表，每条都有完整上下文。 这办法能持久，因为够自然。走路本身就健康放松，思考是顺带的。一小时散步，能产出的深度思考不少。 你也可以试着设计一个自己舒服的环境，轻轻松松把事情办完。 最后，推荐我的知识星球： --- # 2026 年 2 月观影 URL: https://wlj.me/posts/2026-02-movie/ Published: 2026-02-28 Updated: 2026-02-28 Tags: Movie电影 阳光普照 Equilibrium 很一般的动作片，科幻设定和剧情都一般 在京都小住.Chokotto.Kyoto.ni.Sundemita（2022）慢悠悠的片子，像是京都介绍，但居然还有几分味道 Heat (1995) Remastered --- # 2026 年 2 月阅读 URL: https://wlj.me/posts/2026-02-reading/ Published: 2026-02-28 Updated: 2026-02-28 Tags: Reading 温暖的科技 醉步男 解构薇薇安迈尔 Fifty Secrets of Singapore’s Success 新加坡：不可思议的崛起 张忠谋自传 好战略，坏战略 --- # AI 来了，创作者最该积累的不仅是内容，还有信任网络 URL: https://wlj.me/posts/creators-need-trust-network/ Published: 2026-02-27 Updated: 2026-02-27 Tags: WeChat, AI, Writing注意：今天要推荐知识星球，你可以当成是广告，但这是我真想说的。 所有人都在说创作者要学会用 AI。没错，但这不是差异化。 AI 写文章、做视频、画图、写代码，这些事的成本在快速降低。你会用，别人也会用。当所有人都能用 AI 量产内容，内容就不稀缺了。大家都有同一把武器的时候，武器本身就不是优势（这里补充一句：很多人其实还用不好这个武器，无论是判断力不够，还是品味不行，又或者是协调管理能力不行，他们可能不是武器的最优使用者）。 那什么是优势？ 信任网络。 一个人愿意为你付费、愿意在你的社区里待着、愿意把你推荐给朋友——前提不是你内容有多好，是他信你这个人。 我做知识星球这些年，见过非常多创作者把精力全砸在"产出更多内容"上。日更、追热点、做合集。但我也一直鼓励大家要互动，要做社区，要连接人与人。 创作者真正的优势不在创作效率，在于你是一个真实的人。你有经历、有判断、有立场、会犯错、能成长。这些 AI 没有、同行和你也不一样。这才是差异化。 而且现在有个窗口期。 大部分创作者还在研究怎么用 AI 提高产量，还没意识到信任才是稀缺资源。先建立起自己的信任网络，就多了点我认为的真壁垒。这个窗口不会一直开着——多数人反应过来时，建立信任的成本会比现在高得多。 用 AI 创作，当然可以，也应该。但别把省下来的时间全拿去生产更多内容。拿一部分出来，去回复一条用户提问，去记住一个老用户的名字，去在社区里创造一次真实的对话。 AI 能帮你写一篇完美的文章，但没法替你和一个人建立十年的关系。 凯文凯利说过，一个创作者，只需要 1000 个铁杆粉丝就能衣食无忧，自由创作。这个理论提出快二十年了，在 AI 时代反而更成立了——当内容供给无限的时候，人们不仅是在选内容，而且是在选人。那 1000 个铁杆粉丝的本质，就是 1000 个信任你的人。 来吧，从创建一个知识星球开始，从在公众号发出你的知识星球二维码开始，构建你的十年信任吧。 --- # AI 的下限，就是你我的上限 URL: https://wlj.me/posts/ai-floor-is-our-ceiling/ Published: 2026-02-26 Updated: 2026-02-26 Tags: WeChat, AI最近和 AI 聊天越来越多，发现：很容易进入心流。 不是"帮我写个邮件"那种活，是我抛出一个没想清楚的念头，它接住了，还往前推了一步。我再接，它再推。几个回合下来，模糊的想法慢慢清晰。 以前这种体验很难得。和朋友聊，对方不一定懂你关心的东西。和专家聊，人家没空陪你慢慢想。和自己聊，烧脑且会在局限在自己的想法里绕圈。 AI 有点不同，它居然能自动匹配我的水平。 不管聊什么，它都能从我的知识和经验往下接。问浅了，它往深带一层。突然有灵感能问得深，它也跟得上。始终在能力边界上，势均力敌地喂招。 心理学管这叫心流条件——挑战和能力刚好匹配。太简单了容易无聊，太难了容易焦虑，刚好在边界上，就进入忘记时间的状态。AI 就卡在这个位置，所以和它聊天会上瘾，不是因为它什么都知道，是因为它让我觉得——探索可以更深一步。 反过来也一样：我越强，AI 越强。我的能力，200 美金一个月的 Claude Max，还没办法高效率、有价值地用完——真正的限制是自己。所以"学会用 AI"这件事，真正要学的是提升自己——阅历、判断力、提问的能力。这些决定了 AI 在我手里能到什么水平。 AI 的下限，就是你我的上限。 ─── --- # 给自己和家人装个龙虾助理 URL: https://wlj.me/posts/lobster-assistant-for-family/ Published: 2026-02-25 Updated: 2026-02-25 Tags: WeChat, AI, Tech最近打听小龙虾的朋友有点多，所以我干脆写篇短文，把文科背景朋友们最经常问的问题，做个粗浅的回答。 第一步：我需要什么？ 找一台独立的旧电脑。 建议用一台不用的旧电脑专门跑它。原因有两个： 一是稳定。你大概率会希望这个助理 24 小时在线——半夜收到重要邮件能帮你处理，每天早上自动发一份新闻摘要，你不在的时候也能替你盯着事情。用日常办公的电脑跑，合上盖子就断了。 二是安全。这个助理会接触你的邮件、日历、文件，给它一台独立的机器，跟你的工作环境隔开，万一配置出了问题，也不影响你日常用的东西。 五六年前的笔记本就够，Mac、Windows、Linux 都行。 没有旧电脑怎么办？ • 树莓派，几百块钱，功耗极低，放在角落里一直跑 • 云服务器（VPS），每月几十到一百多块，不用管硬件 • Mac mini，如果你本来就想买一台——这是极其豪华的配置 在中国能用吗？OpenClaw 本身没有限制。但它需要调用 AI 服务（比如 Claude、GPT），如果网络访问不了这些服务，需要想办法解决，或者选用国内能访问的 AI 模型。 注意，这里强烈建议：用独立设备，跟你的工作电脑分开。 ─── 第二步：要花钱吗？ OpenClaw 开源，费用来自 AI 模型——就像请了一个助理，AI 模型是助理的大脑。 我最直接的建议：用你能用得起的最贵、最好、最聪明的模型。 模型笨，相当于助理笨，你要个笨助理干嘛？以及，笨助理更容易被网页里藏的恶意指令操控，如果被骗了，一次损失，估计就够付这辈子的模型账单了。 AI 模型的能力差距非常大。便宜的模型能聊天，但理解力、判断力、可靠性都差不少。你既然花时间把助理搭起来了，别在最关键的大脑上省钱。一个聪明的助理能帮你省的时间，远超模型费用。 轻度使用（每天聊几轮，偶尔帮忙查东西），一个月大概几美元到十几美元。重度使用会更多。 如果你有一些 AI 的订阅，可以请懂技术的朋友看看，说不定无需额外付费就能使用。 第三步：装上它 安装过程需要有人帮你在电脑的终端里输入几条命令。不复杂，但如果你从来没用过终端，建议找个懂技术的朋友帮忙，十分钟就能搞定。 装好之后，OpenClaw 会自带一个网页聊天界面，打开浏览器就能跟它说话。 但更多人是想在手机上随时跟它聊，可以把它连到一个聊天工具。海外用户推荐 Telegram（配置最简单）或 WhatsApp。 中国用户怎么办？Telegram 和 WhatsApp 在国内不能直接用。几个替代方案： • 飞书（Lark）——OpenClaw 支持飞书机器人，国内直接可用，适合个人和团队 • 网页界面——装好就自带，不依赖任何第三方聊天工具，打开浏览器就能用 第四步：搞清楚它能帮你做什么？ 从聊天开始。 刚装好的时候，先就当它是一个聊天对象。问它问题，让它帮你查资料、翻译、写邮件草稿、整理想法。用几天，找找感觉。 然后逐步给它更多权限。 当你觉得它靠谱了，可以开始授权更多能力——读你的邮件、管你的日历、帮你搜索网页、定时执行任务。 具体怎么授权？直接问它就行。跟它说"我想让你能帮我读邮件"或者"我想让你每天早上给我发一份新闻"，它会告诉你需要做什么配置。这些配置通常就是几步操作，它会一步步带你完成。 它有记忆。你告诉它的事情，它会记住。下次你再跟它聊，不用从头说起。 每个能力都可以单独开关。一个一个加，逐步建立信任。 下一步：给家人也配一个 不需要再买电脑。同一台机器上可以跑好几个独立的 AI 助理，每个人一个。 每个人的助理完全独立： • 性格不同——你的助理可以干练直接，孩子的可以耐心温和 • 记忆分开——互相看不到对方的聊天记录 • 权限不同——可以给孩子的助理加限制 • 入口不同——每个人跟自己的 bot 聊天 还有一种玩法：拉个群。 比如你和太太拉一个群，把助理也加进去。平时在群里讨论"周末去哪吃饭"、“下周的行程怎么安排”，助理在旁边听着，需要的时候 @ 它，它就能帮忙查餐厅、比较选项、记下决定。不需要的时候它安静待着，不会插嘴。 家庭群里的助理就像一个随叫随到的管家：你们商量事情的时候它在旁边，要帮忙的时候叫一声就行。 家人用它能做什么？ 不需要懂技术，只要会在聊天工具里打字就行。 太太可以这样用： • “帮我查一下这周末有什么亲子活动”——它会搜索、整理、列出来 • “提醒我明天下午三点去学校接孩子”——到时间会发消息提醒 • “这封英文邮件说了什么”——转发给它，它帮你翻译和总结 • “帮我写一封请假邮件给老师”——告诉它原因，它帮你拟好，你确认后发出 • “最近想给家里换个洗碗机，帮我比较一下”——它会查资料、列对比、给建议 • 拍一张冰箱里的食材发给它，问"今晚做什么菜"——它能看图给食谱 孩子可以这样用： • “这道数学题我不会”——拍照发给它，它会一步步讲解 • “帮我检查一下这篇英语作文”——它会改语法、给修改建议 • “用简单的话解释一下光合作用”——比搜索引擎耐心，可以反复追问 • “我想做一个关于太空的手抄报，给我一些思路”——它会帮忙组织内容和排版建议 跟直接用 ChatGPT 的区别：不用每次重新解释背景。它记得孩子几年级、学什么课程、太太的习惯偏好。在手机聊天工具里随手就能问，不用专门打开一个网站。还可以给孩子的助理设限——比如只讲思路不给完整答案，或者不允许回答跟学习无关的问题。 跟 ChatGPT 到底有什么不同？ ChatGPT 是一个网站，你打开它，聊几句，关掉，下次再聊它可能就忘了。 OpenClaw 跑在你自己的电脑上。它有持续的记忆，能连接你的邮件、日历、文件，能在你不在的时候自动做事，能通过你日常用的聊天工具随时找到它。 一个是聊天工具，一个是私人助理。 最后：我的数据安全吗？ • OpenClaw 的所有数据——聊天记录、记忆、配置——都存在你自己的电脑上，不在云端。 • 你跟 AI 模型的对话内容会发送到模型提供商的服务器（比如 Anthropic、OpenAI）。 ───欢迎你加入我的知识星球，我们一起聊聊创业、产品、运营、阅读。微信识别二维码，付费即可加入，如不满意，72 小时内可在 App 内无条件自助退款。–>星球创业笔记。 --- # 推荐一个同事做的小工具：PDF书签易 URL: https://wlj.me/posts/recommend-pdf-bookmark-tool/ Published: 2026-02-22 Updated: 2026-02-22 Tags: WeChat, Tools, Tech你有没有遇到过这种情况：好不容易找到一本 PDF 电子书，打开发现没有书签目录。几百页的书，想跳到某一章只能一页一页翻，或者疯狂按 Ctrl+F。 我一个同事就被这个问题折磨够了。 从自己的痒点开始 他喜欢用 PDF 看技术书。网上找的、淘宝买的扫描版，很多都没有完整的书签目录。市面上能加书签的工具不是没有——福昕阅读器可以，WPS 也行。但体验都一样：一条一条手动添加，点击、输入标题、设置页码、设置层级，循环往复。一本 300 页的书，光加书签就要半小时以上。 淘宝和闲鱼上甚至有专门代做 PDF 书签的服务。按目录页收费，每页 1-2 块钱，一本普通的书大概 10 多块，耗时一个小时左右。头部商家月销几百单。 说明这个需求是真实存在的，而且现有的解决方案都很原始。 先用最笨的方法解决问题 他没有一上来就做 APP。 第一步是写了一个 Python 命令行脚本：照着 PDF 的目录页，在一个 TXT 文件里用缩进表示层级，写好标题和页码，脚本读取后自动写入 PDF。 甚至目录都不用自己敲——去电商网站搜这本书，商品描述里的目录直接复制过来就行，还自带页码。 这个"工程版"工具，让他制作一本书的书签只需要几分钟。他拿这个效率去闲鱼接单，还真卖出了几十块钱。 这个阶段很有意思：用最低成本验证了需求，同时验证了解决方案。 从工具到产品 命令行版本只能自己用，推广不了。于是他启动了创新项目，目标是做一个真正的产品级桌面应用。 核心交互很优雅：窗口左边是 PDF 页面预览，中间是书签文本编辑区，右边是实时生成的书签树预览。像写代码一样写书签——用缩进定义层级，所见即所得。 几个亮点功能： • 内置 OCR：扫描版 PDF 直接识别目录页文字，省去手动输入 • 智能页码校准：扫描版 PDF 的页码和实际印刷页码经常对不上，用一个简单的 (++5) 语法就能批量修正偏移 • 自动格式化：识别 1.1、1.1.1 这种标准编号，自动生成对应的层级缩进 • 纯本地处理：所有文件都在本地完成，不上传服务器 技术选型值得说说 他没用 Electron（太臃肿），选了 Tauri：Rust 后端 + Web 前端。PDF 渲染和 OCR 都直接调用系统原生 API——macOS 用 Swift 的 PDFKit 和 Vision，Windows 用微软官方的系统 API。Rust 通过 FFI 调用编译好的静态库。 结果是：安装包小、性能好、不依赖任何外部服务。 支持 macOS 和 Windows，已上架 Mac App Store 和 Microsoft Store。 我觉得有意思的地方 这个项目打动我的不是技术本身，而是整个过程： 从真实的个人痛点出发，不是"我觉得市场需要" 先用最简单的方式（Python 脚本）解决自己的问题 拿到闲鱼上卖，用最低成本验证别人也有同样的需求 确认需求存在后，才投入精力做产品级应用 技术选型务实：能用系统 API 就不引入第三方依赖 这就是一个典型的"从缝隙中长出来"的小产品。市场不大，大公司看不上，但需求真实、解决方案清晰、有明确的付费意愿。 产品官网：https://easybookmark.starryappx.com/cn/ --- # 用 AI 看多看快，用纸笔刻深 URL: https://wlj.me/posts/ai-reads-fast-pen-carves-deep/ Published: 2026-02-21 Updated: 2026-02-21 Tags: WeChat, AIAI 让信息获取变得前所未有地快。几秒钟扫完十篇文章，交叉比对，提取结构，生成摘要。过去一整天的案头工作，现在几分钟完成。 但"看过"和"理解"之间隔着一道沟。 AI 太快了，快到我可以跳过思考，直接得到答案。效率上去了，东西没经过大脑。 我最近在试一种方法：用 AI 看得多看得快，用纸笔做内化，希望脑子里能记住些东西。 做法很简单：先让 AI 做研究、翻译、分析，然后我再从输出里手写提炼三到五个核心判断。隔几天回看，看哪些经受住了时间的检验。 手写的时候，你不可能把所有东西都写下来，你被迫筛选、压缩、重组。这个过程本身就是思考。手写足够慢，慢到逼你在写的时候就完成了一次深度加工。 《三体》里有一个细节：当文明面临毁灭，人们选择把信息刻在石头上——因为越原始的介质，留存越久。 我猜大脑也一样。AI 输出在屏幕上，手写，是把字刻进你自己的石头里。 AI 是加速器，负责看多看快。纸笔是刻刀，负责刻深。 --- # 每周两篇，手工打造，写到第十年 URL: https://wlj.me/posts/writing-weekly-for-ten-years/ Published: 2026-02-21 Updated: 2026-02-21 Tags: WeChat, Startup, AI写了快十年的创业笔记，知识星球里现在已经积累了超过 900 篇。产品怎么想的、公司怎么做的、踩过什么坑、心态怎么变的，都记在里面。 2026 年会继续保持每周两篇原创的节奏。 这些笔记都是手工打造的。不用 AI 代笔，不批量生产，每一篇都是我自己在键盘前敲出来的思考。在 AI 生成内容泛滥的当下，我反而觉得，手写的、带着个人判断和真实经历的内容，更稀缺了。 今年会加一个新东西：业界好文章的分享。我平时阅读量不小，遇到真正有价值的文章，会翻译整理（英文内容通常借助 AI 翻译），加上我自己的感受和判断，一起放进星球。不是简单转发，是经过筛选和消化的。 星球里聊的话题很杂：产品、技术、AI、创业心态、团队管理、小产品的生存策略。不追热点，更关注那些需要长期积累才能看清的东西。 如果你也在做产品、在创业，或者对小团队怎么在夹缝里生存感兴趣，欢迎来我的星球看看，提问、交流、挑战，都行。 --- # 向深处走 URL: https://wlj.me/posts/go-deeper/ Published: 2026-02-20 Updated: 2026-02-20 Tags: AI, Photography, Tools, WeChat昨天看了一位作者 David Cain 的两篇文章，挺喜欢的，推荐给朋友们： Go Deeper, Not Wider（向深处走，别向宽处走） Everything Must Be Paid for Twice（每样东西都得付两次钱） 两篇文章说的其实是同一件事：我们拥有的太多，使用的太少。 我们已经有了太多的爱好，囤积了太多的工具，购买了太多的装备。 我自己就是个典型。我曾经是个摄影爱好者——说是摄影爱好者，其实更准确的说法是器材爱好者。买过很多镜头、相机，但没有一台在我手里被用到坏，也没有一台让我觉得用回了它的本钱。它们大多数时间安静地躺在防潮箱里，偶尔被拿出来，拍几张，然后又放回去。 AI 时代来了，这个问题更严重。各种新工具一出来就想试。注册、付费、玩两天、丢一边。什么模型都碰过，什么工具都摸过，但没有一样事情做得很深很透。 David Cain 在第一篇文章里说了一段话，我很有共鸣： 我一直在想象一个我想发明的传统。当你在事业上站稳脚跟，家里也有了一些不错的东西之后，你用整整一年时间，不开始任何新事物，也不添置任何不需要的新物品。 这一年里，不许有新爱好、新装备、新游戏、新书。你必须从已经拥有的东西、已经开始的事情中去发现价值。 你去精进已有的技能，而不是学新的。你去消化已经囤积的内容，而不是继续囤。 他把这叫做"深度年"（Depth Year）。不是苦行，而是一种选择：停止向外扩张，转身向已有的东西挖掘。 他的第二篇文章换了个角度解释同一件事： 有一条财务常识应该在学校里教：我们买的大多数东西，都得付两次钱。 第一次是用钱换到手——一本书、一个记账 App、一辆独轮车、一捆羽衣甘蓝，不管是什么。 但要真正用上这东西，你还得付第二次。第二次付的是精力和行动力，而且往往比第一次贵得多。 拿一本小说来说，第一次大概花二十块钱——第二次是十个小时的专注阅读。只有开始付第二次的钱，第一次花的钱才有回报。只付第一次不付第二次，跟把钱扔进垃圾桶没什么区别。 环顾一下你的家、你的书架、你的手机，有多少东西只付了第一次钱？未读的书、未拆的器材、未用完的会员、注册了再没打开过的 App。 我们不缺买东西的能力，缺的是把已有的东西用透的耐心。 新的一年，与其继续追新，不如试试向深处走。 原文： https://www.raptitude.com/2017/12/go-deeper-not-wider/ https://www.raptitude.com/2022/01/everything-must-be-paid-for-twice/ --- # 春节归来，怎么跟你多出来的这 5 斤肉和解？ URL: https://wlj.me/posts/post-spring-festival-weight/ Published: 2026-02-20 Updated: 2026-02-20 Tags: WeChat, Life春节回来，朋友圈里一片哀嚎：胖了。 这不是什么新鲜事。每年春节都会重演一次：亲戚轮流投喂，每顿饭都像最后一顿，零食从除夕吃到初七。回来上班的第一天，裤子紧了，但新年 flag 已经立好了——今年要健身、要早睡、要读书、要学英语。 立 flag 谁不会呢，难的是坚持。 我观察身边的朋友（包括我自己），习惯养成靠意志力不太行，靠工具和环境更靠谱。道理很简单：看得见，才做得到。把想坚持的事放在每天能看见的地方，比暗暗发誓管用得多。 所以今天推荐一下我们做的敲敲打卡。 它不是那种让人感到压迫的工具。没有排行榜内卷，没有惩罚机制，不会在你没打卡的时候疯狂推送让你焦虑。它更像一个安静的朋友，每天陪你记录一下：今天这件事，你做了没有。 做了就打个卡。没做，明天继续。 它还有个我觉得挺有意思的设计：打卡捐花。你完成一周的打卡任务，会得到一朵小花，可以选择捐出去。敲敲团队会通过腾讯公益平台，配捐 0.05 到 0.35 元给教育、养老、环保类项目。金额不大，但坚持下来，也是一件小小的好事。 坚持一个习惯，顺便做了公益。动力从"我应该做"变成"我做了还能帮到别人"。这个转变虽然微妙，但确实有用。 与其跟自己较劲，不如找个轻松的方式开始。识别二维码，用敲敲，跟自己多出来的这 5 斤肉和解吧。 --- # 找餐厅这件事，一百条好评不如一个靠谱的朋友 URL: https://wlj.me/posts/restaurant-trust-over-reviews/ Published: 2026-02-20 Updated: 2026-02-20 Tags: WeChat, Tools, Tech我越来越觉得，找餐厅这件事，大众点评、小红书都帮不了我。 倒不是说它们不好用。信息多，评价全，但问题就出在"太多"上。我打开一家店的页面，几百条评价，有说惊艳的，有说踩雷的，有明显是刷的，有写了一千字但你也不知道这个人平时吃什么水平的。看完一圈，我还是不知道该不该去。 后来想明白了，问题是：我不认识这些人。 我不知道他们的口味，不知道他们的标准，不知道他们说的"好吃"到底是什么意思。一个觉得"好吃到哭"的人，跟我可能完全不在一个频道上。这种评价再多，对我来说就是噪音。 但如果是朋友呢？那完全不一样。 我知道他是什么样的人，知道他吃过什么东西，知道他说"这家不错"意味着什么。他的推荐我是可以直接信的。 这就是我们做 EatVenture 的原因——它不是大众点评，它是朋友点评。 我在 EatVenture 上只关注我认识的、喜欢的、且我认可 Ta 饮食品味的朋友。注意，不是所有朋友。认识归认识，但有些人吃东西的口味跟我差别太大，我会关注 Ta，但不会订阅 Ta 的餐厅列表。我只关注那些我觉得"真的懂吃"的人。 然后我会主动把 EatVenture 发给他们，拜托他们把自己喜欢的餐厅标注上去。 这些人可能是每次出差都能摸到当地最好馆子的同事，可能是在某个城市住了十年把好店全吃遍了的朋友，也可能就是那种朋友圈发什么吃的你都想问一句"这是哪家"的人。 这样一来，下次我去他们去过的城市，打开 EatVenture，沿着他们吃过的路线走一遍就好了。不用做攻略，不用翻评价，不用纠结。因为推荐这些餐厅的人，是我自己选过的。 找餐厅，数量不重要，精准才重要。一百条陌生人的好评，不如一个懂吃的朋友跟你说一句"去这家"。 朋友点评，大于大众点评。 EatVenture 是一个很小众的 App。它不是为所有人做的，就是为你和你信任的那几个朋友做的。但就是这个"小"，让它特别好用。 这个小工具也并不为所有人设计，目前用的是 Google 的 API，大陆餐厅数据很不完整（不推荐使用），反而是香港、新加坡、日本等地方，陆陆续续被朋友“占领”了。 如果你想试试，可以识别这个二维码，至少新加坡、香港的餐厅还挺完整： --- # 小而美，难，也不难 URL: https://wlj.me/posts/small-beautiful-hard-easy/ Published: 2026-02-17 Updated: 2026-02-17 Tags: WeChat, Tools, Startup37signals 创始人 Jason Fried 与 Founders Podcast 主持人 David Senra 的深度对话。Jason 经营 37signals 27 年，年年盈利，62 人团队，做出了 Basecamp 和 HEY。这是一个关于"足够"的故事。 Jason 15 岁时用 FileMaker Pro 做了一个音乐收藏数据库——因为他老把磁带借给朋友，收不回来。他给软件附了个文本文件：“喜欢的话给我寄 20 美元。“然后放到 AOL 上。 一天他收到一封从德国来的航空信。里面是打印好的付款单和一张崭新的 20 美元纸币。 “That was the moment it all clicked for me — make stuff for yourself. There’s probably other people out there like you who want what you want.” 核心逻辑：你就是用户，你就是受众。世上有足够多跟你品味相近的人。不需要全世界都喜欢你做的东西，只需要"足够"的人喜欢。 如果成本高、公司大，你就得找很多跟你一样的人。但如果成本低、公司小——16 岁的 Jason 一个人就能靠软件年赚两万美元——你只需要几千个客户。 “Keep your cost low, keep your company as small as you possibly can and make great stuff and then you don’t have to find as many people just like you.” 找到的人会真心热爱你做的东西。这就够了。 生意的本质：赚的比花的多。竞争对手要做什么，你控制不了。你能控制的是自己的成本和定价。 “What I can control is how much it costs me to run my business, how much I sell my product for. As long as I make more than I spend, I get to stay in business. And isn’t that what this is all about?” 从 Sam Walton 到 Andrew Carnegie 到早期的 Bill Gates，历史上最伟大的企业家全都痴迷于控制成本。微软前 30 名员工：Bill Gates、他的秘书、28 个程序员。没有一丝赘肉。 62 人。没有中层管理。高管团队就两个人：Jason 和 David Heinemeier Hansson。 他们试过扩张到 83 人，加了工程经理和 COO。结果发现层级多了，信息像打电话游戏一样层层失真。COO 没有足够的事做，浪费了别人的职业生命。一年内砍掉了这些职位。 做产品的团队通常就两个人：一个程序员，一个设计师。这迫使他们不做两个人做不了的东西。 判断是否留人只问一个问题： “Knowing what I know now, would I hire them again?” 这个问题回答了关于绩效、态度、文化匹配的所有问题。 每五六年重做一次 Basecamp。从 1 到 2 是完全重写，2 到 3 也是。这是重新审视产品根本假设的机会。 物理世界有反馈——杯子太烫你会知道设计有问题。软件没有。软件可以无限膨胀，没有东西推回来。 “Software slides downhill. It gets better for a while then slides downhill.” Jason 的目标：每个新版本在根本体验上比上一版更简单。可能功能更多，但体验更简。 为什么这件事有趣？因为难。因为要跟自然规律对抗。因为能逼出更有创意的解决方案。 “My favorite thing in life is to have an insight.” Jason 用火箭比喻：你得先突破引力，但到了轨道上，就该维持。不是一直往上冲，而是在舒适的范围内稳定运行。 “I’m like, so what if you’re massive and you’re twice as massive? So what? Why?” 他们肯定在"把钱留在桌上”。没有做定价优化，没有 A/B 测试。他确信存在某种公式能带来更多增长。他的回答： “So what? I’m very comfortable with where we are. I don’t want to fuck that up.” 芝加哥有家叫 Vinny’s 的三明治店。面包卖完就关门，通常下午两点半。门上没写营业时间。Jason 觉得这"诗意而美好”。 “Where do you stop? You could stay open till 6:30. I mean 7 probably. We could do 7:30… You could see how this doesn’t end.” Jason 的"信封与信"比喻：商业是信封，产品是信。他是写信的人，不是做信封的人。 “I don’t just want to build shells that get filled and then I sell it and build another shell.” 很多人在"扮演创业者"——起名字、做 logo、融资、谈估值，里面什么实质都没有。把公司变成金融工具，这让 Jason 反感。 信封要薄。越厚的商业体，惯性越大，离客户和产品越远。37signals 是一个很薄的商业体，包着厚实的产品。 这是 Jason 的口头禅。别人说他可能是个糟糕的 CEO，可能有人能来把公司规模翻倍。他的回答： “So what? I don’t care.” 他甚至不喜欢 CEO 这个头衔。“Chief executive officer of what?” 昨天他回了 200 封客户邮件。有人说这不是 CEO 该干的事。他觉得这是最该干的事。 他不追求数字优化。优化产品让它更好？有意思。多榨 10 万美元？无聊。 “Beyond not fun. Boring.” 芝加哥有家杂货店叫 Olivia’s，老板认识每个走进来的顾客。Jason 羡慕但做不到——他有几十万用户。 他的替代方案：注册 Basecamp 后你看到的第一样东西是 Jason 的亲笔信，附着他的邮箱地址。没有 AI，没有助理，没有层级。直接写给他。 “I want to get as close as possible to the people who use the things that we make.” 不只是让客户高兴。他要理解客户的语言、他们怎么描述产品、他们是谁。这些东西会渗透进他，让他能感受到用户使用产品的体验。 UPS 创始人 Jim Casey 的做法：让司机每看到一辆棕色卡车就靠边停，他亲自跟一线员工聊天。因为高管只会拍马屁。 有人问 Jason：如果 27 年赚的钱可以 15 年赚到，你选哪个？ “I would take the 27. Because the money is a side effect of all of this.” Patrick Collison 说过：“The reward for good work is more work.” Jason 深以为然。27 年比 15 年有意思，因为他喜欢这件事本身。 37signals 最多往前看六周。大多数项目远不到六周。像松鼠过草地——知道大致方向，跑一段停下来看看，再跑一段。 “I’ve always been mystified by people who think they can figure out the next three years today, but they’re afraid of figuring out tomorrow tomorrow.” 有人问 “五年后成功是什么样的？” Jason 的回答：不知道，不在乎。 David Senra 的版本：好的一生就是一串好的日子。每天铺一块砖，让计分板自己说话。 一天是好的小单元。一个简单决策是好的小单元。搞砸了？24 小时后就过去了。 “Make things small, tiny little units that you can throw them away if it doesn’t matter.” 大决策花八个月酝酿，搞砸了后果惨重。小决策不断累积，错几个无所谓。 定价上也一样：Basecamp 每月最高 299 美元，不管你有多少用户。不要鲸鱼客户。想象电视雪花屏上的点——每个客户大小相等。随机丢掉 10 个、100 个，业务照常运转。 “You don’t want customers that you cannot afford to lose.” Jason 很少看竞品。不是因为自大，而是刻意为之。 “When you’re paying so much attention to what everyone else is doing, you tend to just think that’s the way it has to be done.” 他的灵感来源：Concept 2 划船机（千元以下，黑白 LCD 屏，D 电池驱动，完美产品）、手表、建筑、家具、自然。不是别的软件。 “I’d rather look at the sun than a competitor’s product.” 结果：Basecamp 和 HEY 跟任何竞品都不像。有人讨厌。没关系。喜欢的人足够多。 Jason 的产品 demo：很长，不剪辑，会犯错，不重来。就像坐在你旁边给你看东西。 “Here we are. Here’s what we do. Here’s what our product does. That’s the best we can do and that’s the best I want to do.” 他讲了一个故事：在威斯康星小镇的画廊里遇到一个收藏纳瓦霍地毯的老人。地毯上有"错误"——不完美的几何图形、偏移的针脚。老人说纳瓦霍人不认为这是错误，而是时间的印记。走在山路上绊了一下，你不会退回起点重走。 “Mistakes are a concept we put on ourselves when we do something that wasn’t what we intended. Why does that have so much weight?” 落地页是一封信。产品发布视频不剪辑。法语发音不会就不会。不装。 Jason 读 Rick Rubin 的《The Creative Act》时的感觉：“Did I write this book?” 两人共通之处：世界充满你无法用理性解释的东西，要信任直觉，不必知道所有"为什么"。 Jimmy Iovine 第一次听 Rick Rubin 制作的歌时说： “I wish I could still make something that simple.” Rick 当时还是新手，做出了纯粹简单的东西。经验越多，反而越难保持简单。这就是对抗复杂性的本质挑战。 Jason 确信自己无法重做 Basecamp。Bob Dylan 在采访中说：“I used to be able to write music like that. I don’t know how I did that. I know I couldn’t do it again, but I can do other things now.” Jason 在蘑菇体验中领悟到：你不可能重复同一个体验。第二次听同一首歌，什么都没发生。他笑了 … --- # 从"付费打卡"到"打卡捐花"：一个公益小实验的诞生 URL: https://wlj.me/posts/from-paid-checkin-to-charity/ Published: 2026-02-13 Updated: 2026-02-13 Tags: WeChat, Life去年 3 月，我们在内部写了一份提案，想解决一个老问题：打卡不下赌注，大多数人坚持不下去。 最直接的思路是让用户付费。付费加入，完成目标者的钱捐给公益组织，我们再等比配捐。听起来不错，但仔细一想，问题很多： 要接微信支付 涉及分账，法律风险不确定 用户要先掏钱，门槛太高 流程复杂，解释成本高 当时内部的判断是：这是个跨界的想法，胃口大、路径长。优先级往后放。 放了大半年，我们换了个角度想这件事。 用户不付费行不行？他完成打卡，我们替他捐钱。用户得到的是"我坚持了一件事，顺便做了好事"的感觉。我们得到的是一个有意义的话题，和用户分享打卡的动力。 于是有了"敲敲小花"。 规则很简单： 用户完成一周的打卡任务，得到一朵小花 用户可以选择捐出这朵小花 敲敲团队匹配捐出 0.05 到 0.35 元，通过腾讯公益平台捐给教育、养老、环保类项目 配捐金额和打卡难度挂钩：一周 1 次对应 0.05 元，一周 7 次对应 0.35 元 我们目前给自己设了个上限：每周配捐不超过 5000 元，大概能支持 2 万朵小红花。 这个活动从 2026 年 2 月 1 日开始试运行，到 3 月 31 日结束。试运行结束后，我们会看用户反馈、系统稳定性，再决定如何继续。 回头看这件事，我们花了差不多一年，把一个复杂的想法做简单了。付费打卡变成了打卡捐花，用户的门槛从"先掏钱"变成了"先坚持"。 特别感谢腾讯公益的支持，非常给力地加班加点，让我们有机会春节前接入他们的 API，还做了个页面展示： https://ssl.gongyi.qq.com/m/weixin/b2b/index.html 如果你在用敲敲，更新到最新版本，面板顶部会出现小红花的入口。欢迎参与这个小实验，也欢迎告诉我们你的想法——后续应该如何迭代。 --- # 一边敲敲，一边公益 URL: https://wlj.me/posts/easyhabit-charity/ Published: 2026-02-11 Updated: 2026-02-11 Tags: WeChat, Life敲敲与腾讯公益合作，你用敲敲养成好习惯，顺便支持公益。 产品目前体验下来还比较丝滑，完成当周的打卡目标后，左上角会有“可捐赠”字样的小红花，点进去就能操作了。 捐完之后，可以在微信里带上小红花。 捐款的钱由敲敲团队支付，祝大家新年大吉🎉 --- # 让一千朵花先开 URL: https://wlj.me/posts/let-a-thousand-flowers-bloom/ Published: 2026-02-08 Updated: 2026-02-08 Tags: WeChat, AI昨天黄仁勋在 Cisco AI Summit 上被问到企业做 AI 的第一步是什么。他的回答是：别问 ROI。 视频参见：https://www.youtube.com/watch?v=Qt-RFRr5N2I “让一千朵花先开。” (Let a thousand flowers bloom.) 他把公司创新比作养孩子。孩子说想学画画，你不会追问投资回报率；孩子说想踢球，你不会要求他先写商业计划书。但在公司里，我们天天这么干。 黄仁勋说，Nvidia 内部的 AI 项目"完全失控"，他觉得这是好事。因为创新本来就不是受控的。想要掌控一切，那是幻觉。 当然，“先开花"不是"随便开”。他同时强调：要在最有价值的地方试（across your most impactful domains）。不是把 AI 扔到边缘业务凑热闹，而是直接切入核心——那些真正能改变公司命运的地方。 他同时强调了两件事： • 动手做。别只租云服务、用现成产品。自己搭一台机器，才能理解底层是怎么回事。“掀开引擎盖，换换机油，搞懂每个零件。” • 问对问题。“对我来说，最有价值的知识产权不是答案，是问题。“答案可以量产，但好问题不行。 这套逻辑放到小公司更适用。大公司有资源试一千个方向；小公司没有，但小公司可以更快地"先干起来”——先跑一个最小原型，再决定要不要加码。 MIT 一份报告说 95% 的 AI 项目失败了。 黄仁勋说的则是：失败的不是"试”，失败的是"不试"。你不开那一千朵花，你就永远不知道哪一朵能绽放。 --- # 2026 年 1 月观影 URL: https://wlj.me/posts/2026-01-movie/ Published: 2026-01-31 Updated: 2026-01-31 Tags: AI, Movie, Photography电影 Her 2013，毕竟 AI 来了，再看一遍，挺喜欢，结尾也挺有想象力的 The Truman Show 1998，第一次看，喜欢 Made in Ethiopia，纪录片，没觉得太好 THE.HUNGER.GAMES.THE.BALLAD.OF.SONGBIRDS.AND.SNAKES.2023，饥饿游戏前传——snow 的成长历程，节奏有点慢，一般吧 Fallen.Angels.1995，典型的王家卫风格，小时候喜欢，现在觉得有点故弄玄虚，病态的感觉我也不是太喜欢了 One.Battle.After.Another.2025 并不是太喜欢这种虚构背景，有点无厘头，叙事特别慢的故事，当然整体也算能看 Gatao (2015) 台湾黑帮片，也就是看看闽南话，故事太简单 Gatao 2 Rise Of The King (2018) Gatao - The Last Stray (2021) GATAO Like Father Like Son (2024) Wrath.of.Man.2021 很一般的动作片 La.La.Land.2016 很少看音乐片，这片开头也觉得无厘头，但还是看完了，也还可以，慢节奏的爱情片 东京日和，讲荒木经惟和阳子的故事，在我喜欢摄影的时候找来的，这么多年了，总算看完了，就电影而言，真挺不对我胃口的 剧集 Pluribus 大失所望，无趣、慢节奏、设定和剧情发展有太多漏洞，之前网上的评价真是瞎吹 --- # 2026 年 1 月阅读 URL: https://wlj.me/posts/2026-01-reading/ Published: 2026-01-31 Updated: 2026-01-31 Tags: Reading Inspird: How to create products customers love 京瓷哲学 服务营销：人、技术、战略 --- # 幻觉 URL: https://wlj.me/posts/illusion/ Published: 2026-01-30 Updated: 2026-01-30 Tags: WeChat, AI, Tools最近很多人有一个幻觉，觉得有了 AI，自己就无所不能了，认为 AI 能让个体变成超级个体，一个人能顶十甚至一百个人。 但我必须很不客气地说，这真的是一个幻觉。要打破这个幻觉其实很简单，你只需要去买一个，比如说 Claude Max，每个月两百美金的那一档，然后看看自己能不能把它的算力用满。 我个人的经验，目前用不满。所以说，即使 AI 是个非常聪明且便宜的，甚至不限量的助理，我也没办法 24 小时压榨它，把它的能力用到极限。 AI 再聪明，如果你自己不够聪明，你也改变不了世界。 一个类比是：有的创业者觉得自己只是没人投资，所以事情做不起来。残酷的真相是，比钱更重要的是你怎么有效率地花钱。 当你拿到一百万时，你能不能有效率地花好它？当你拿到一个亿、十个亿时，你能不能有效率地花好它？像 OpenAI 拿到那么天量的资金后，你能不能有效率地花好它？ 回答这个问题，你可能就会意识到，真正的约束其实是你自己。 对了，不好意思，其实这些话是我说给自己听的，因为我已经意识到，真正的约束是我自己了，毕竟我连两百美金一个月的 AI 都没办法榨干。 – 这是上午跟朋友聊天之后，刚刚用 slax note - n.slax.com 语音转文，五分钟快速写完的。 --- # 公司 21 岁了 URL: https://wlj.me/posts/company-turns-21/ Published: 2026-01-28 Updated: 2026-01-28 Tags: WeChat, Startup, AI21 年前的今天，我们成立了这家小公司。 21 岁，已经成年。我却更觉得，我们像一个刚刚意识到世界有多大、自己有多小的孩子。 我想了想，公司存在的问题至少有： 组织 创始人的后退，和对团队的培养、锻炼可能不够。希望更多创新来自团队 中层管理的能力还需要提升 整体团队的好奇心、对新事物（比如 AI）的接受度还需要提升 运营 新增星球和用户下滑 新行业的拓展不顺利 风险管理与合规动作，提高了成本，降低了增速 产品 知识星球内用户（包括星主和他们的付费用户）的分享率大幅降低 知识星球在视频生态内无法获客 知识星球产品里的 AI 能力进步有限 隐忧 AI 的发展，是不是会把内容干掉？知识星球这样的付费社区存在的意义减弱 再往深看一步，AI 是不是会让所有软件产品都失去意义了？尤其是工具产品 第二曲线 我们的各种新尝试，至今尚未能站住脚、找到光 这些年，我学到的一件事是：不确定性本身，就是创业的常态。迷雾里，不用假装看得清，保持诚实，保持好奇，保持动手的勇气。 碰上 AI 这个时代，运气挺好的。有机会和大家一起，继续玩下去。感谢所有星主，感谢所有用户，感谢一路同行的团队。 我们继续。 --- # 知识星球的 10 年 URL: https://wlj.me/posts/zsxq-ten-years/ Published: 2026-01-20 Updated: 2026-01-20 Tags: AI, Startup, Tech, WeChat知识星球 10 岁了。一个小工具 10 岁，在这个宏大的时代下，微不足道。自家的孩子，出生在移动互联网的尾巴，当下赶上 AI 凶猛地冲撞过来，还是幸运的。 试图回忆过去的时候，我发现，能被记住的，往往是一些问题、低谷。 跟大家分享几个低谷。 事故 说出来大家可能会笑——其实，早期版本被 @Fenng 在朋友圈、微博推荐的前几次，都直接把服务拖垮了。 第一次挂的原因是，每个用户登录的时候，都会一次性把圈子里的用户列表拉回来，几千个用户通讯录信息、头像，几千个人同时拉——嗯，在我们还是单服务器的时候，瞬间就雪崩了。 2021 年，生财有术 418 续费，在 20:00 秒杀开始时，数据库没撑住，甚至导致了付款方面的问题，比如付了费，我们却没准确记录。那次给生财有术团队带来了挺大的后续工作量。 那之后，为了让整个活动更加顺滑，研发团队做了些工作，比如： 后端、运维工作 压力测试，通过压力测试，找出木桶的最短板，从而不断做性能调优 数据库按业务拆分成多个集群，进一步减轻数据库压力 代码级调优（核心目的是为主库减负） 限速，如果达到我们压力测试的峰值，对来访用户进行排队、降级等限制 临时扩容，根据去年的经验，将服务器做了短期大幅扩容，活动结束后释放 前端工作 页面静态化 技术上的调优，加上微信支付给力的协助，那之后就没出过这么大事故了。 2017 年的下架 2017 年，因为风控、内容安全问题，产品被下架，后续会如何，一无所知。我后来发了张照片，记录：这张照片是 2017 年 6 月 30 日拍的，那时公司遇到一个很大的坎，尽了全力东奔西走。所幸贵人相助，指点、计划、执行、核查、修正，投入很大的精力和成本，走出来了。那会儿，在等机会去拜访人，外面天热，猫在地铁站里，有点累，盘腿在地上坐着，闭目养神。shotgun 拍下来了。偶尔翻到，还是会回忆起那个炎热的下午。创业就是这样，如履薄冰。 那段时间还有另一张图片——归零的图片。 创业公司，很大概率活不过下个月，所以，或许不用规划太长远，尤其是现在的巨变时代，我们也根本看不清三个月后的世界变化。 找到光 除了低谷，当然也有欣喜，比如找到光的欣喜。 在回顾时，我翻了旧照片，找到一张 2015 年 5 月 6 日，在腾讯大厦拍的照片，这是个起点。白板上的草稿，是 Tony 随手画下的。 那时候，我们观察到的问题来自微信群。 用微信群沟通极简、便捷，很多人的生活、工作中都离不开。我自己就大量在工作中使用微信群——与同事、伙伴、用户在群里沟通，迅速解决问题。在重度使用过程中，我也感受到了一些不便，比如：精华内容不连续不易整理、内容不备份很容易遗失遗忘、文件图片不及时下载很快被清理、时常被各种表情包红包或者无关话题岔开歪楼导致讨论不聚焦等等。 我们认为，一个简单的移动端社区，可能会是微信群的良好补充，而海量使用微信工作的人们，也将是我们的目标用户群。于是我们花了几个月时间，把产品做出来了，2015 年的 11 月 10 日，第一个对外公开的版本发布了，版本号是 1.1.1——从 0.9 版开始，内部已经迭代过几个版本。 但，就像绝大多数创业公司的创业项目那样，产品开发出来后，我们尝试着在网络上做了些推广，响应者寥寥。我尝试着找一些朋友——有在传统企业里负责信息技术的，有各行各业野路子的创业者，也有活跃在社交媒体的内容创作者。大多数朋友都会下载，登录测试，然后遗忘。 所以，我们一边自我怀疑，一边做各种迭代尝试。 第一个支持付费的版本是 1.15.4，在 2016 年 8 月 12 日上线。发布日志了，我们写了： 重要的事情说三遍： 你可以用小密圈创建收费圈子啦，有干货爱分享的人们，来玩吧！ 你可以用小密圈创建收费圈子啦，有干货爱分享的人们，来玩吧！！ 你可以用小密圈创建收费圈子啦，有干货爱分享的人们，来玩吧！！！ 用了那么多感叹号，可以看出，我们应该有点激动。 看了这个版本后，Tony 认为“知识星球是很有意思的小产品”，并且鼓励： 可以看到知识星球的星星之火了。知识星球的机制，巧妙地跟创作者站在一起，用户原来对 APP 的耐心一般不超过 30 秒，现在因为这些知名创作者的背书，他们对知识星球的耐心，从最初的 30 秒延长到了 10 分钟。你们继续深挖用户需求，做好魔鬼细节，如果用户能给知识星球更多时间，甚至愿意天天给，那就算站住脚了。 而大辉则在试用后，将他创建的星球发到了微信公众号和微博，之后就有了奇妙的反应：一位内容创作者听说了知识星球，开始尝试使用，将星球发布给他们的用户们（效果最好的，还是微信生态里的发布——比如通过微信公众号写文章），挣到了一些收入，有了正反馈。他的用户/粉丝里也有内容创作者，看到他的传播，也看到了这个正反馈，也开始尝试……小小的雪球开始滚动起来了。 下一个十年 AI 应该会是下一个十年巨大的变量，前些天我向 AI 请教学习、教育问题时，AI 告诉我的几种关键能力是： 复杂的沟通与共情能力 跨学科整合能力 判断力 然后跟我说，要有热情，要有好的品味，尤其重要的是，要有韧性。 让我们带着这些建议，迎接下一个十年呗。对了，别忘了我们的价值观 HACK： Hacker Spirit Accountability Customer First Keep It Simple 中文是： 黑客精神 自驱当责 客户第一 简单 再发一下我的十年图片： 10 年，或许能从另一个侧面反映出，我们是认真、踏实的。大家共勉。 --- # 享受旅程 URL: https://wlj.me/posts/enjoy-the-journey/ Published: 2026-01-06 Updated: 2026-01-06 Tags: WeChat, Startup, Work昨天中午跟 ppchen 聊天，他的一些话对我有些触动。大意是： 不要太在意结果，不用设计目标，享受这段旅程就好。要相信大家都很强，可以自己调整做到最好。 过于追求结果，绷得太紧，反而对大家都不好，容易彼此伤害。 好的协作的前提是信任。 他说有老同事找他聊起打算创业的事，他的建议也只是享受旅程，成也好，败也好，只要这段旅程是享受的，就没白走。 昨天下午跟一位最近很逍遥的朋友闲扯了几句，我说最近好像有点贪心了，做的事有点多。他问：看你是否 enjoy 了。 一天之内，两个人跟我说了同一件事。 我是 enjoy 的，但问题是：时间久了，会有点压力。既想享受旅程，又想要好结果——两个都要，可能两个都抓不住。 我的疑问是：真的专注享受过程，放弃对结果的执着，会更好吗？ 你怎么看？ --- # 我们为什么要做 Slax Reader URL: https://wlj.me/posts/why-we-built-slax-reader/ Published: 2026-01-02 Updated: 2026-01-02 Tags: AI, Tools, WeChat你有没有过这种经历： 想找之前收藏的一篇好文章，点开链接，404。可能是作者删帖、网站倒闭、平台清理或者任何原因。但你只剩下一个空链接。 你用的稍后阅读工具不继续运营了，让你尽快导出数据。 你用的稍后阅读工具对中文环境支持很差（或者说，中国的网络环境对海外产品不友好），比如收藏的微信公众号连标题都看不到。跟开发者反馈了，他们也只是礼貌地表示“记录了“但长期不改。 你用的稍后阅读工具不支持全文搜索，明明你记得收藏过一篇文档，就是找不到。 这些是我们做 Slax Reader 的起点。我用了稍后阅读产品有二十年了，但始终没有一个自己满意的。AI 或许是另一个可能的变量，说不定有机会做出一些不一样。 目前的核心功能很简单： 收藏链接，自动缓存全文。 AI 辅助解析、解读、扩展思考与讨论。既然全文都存下来了，顺手加了 AI 解析——一键生成摘要和大纲，30 秒判断一篇长文值不值得读。读的时候遇到问题，直接问内置的 AI，不用切窗口。 划线、评论、分享。你可以把一篇文章连带你的批注分享出去，其他人也能在上面讨论。 有 iOS、安卓、网页版，可以在手机和电脑上使用。 支持通过浏览器扩展、App、Telegram Bot 收藏链接。 产品挺良心的： 链接收藏、缓存功能免费——这在 Readwise 等产品里都是付费功能。当然 AI 能力是付费的——这没办法，token 烧不起。 产品开源（就是为了解决“不运营“的问题，提高一点信任吧，虽然我考虑哪怕这小工具没办法盈亏平衡，我也会持续下去）。 后续会做得更好的（目前做得还不够）有： 连接能力，你能在这里找到同好、直接交流。我另外有个想法：让这个产品成为全世界 URL 的讨论社区。 付费能力。可以把你的 list 共享给别人，让别人付费订阅。 最开始，就是想解决一个问题：收藏的东西，别丢。 如果你感兴趣，可以看看：https://r.slax.com 在 App Store 和 Google Play、Chrome Web Store 搜索 Slax Reader 可以下载。如果想帮我们一起开发迭代，可以看看： https://github.com/slax-lab/slax-reader-web https://github.com/slax-lab/slax-reader-client 对了，提醒一下，只支持 Google 账号登录，以及因为 Google 的安全策略，在微信里是登录不了的。 --- # 每年十二问：2025 URL: https://wlj.me/posts/12q1y-2025/ Published: 2025-12-31 Updated: 2025-12-31 Tags: AI, Life1. 有没有遵守和完成年初的计划？ 年初的计划可以参见：https://mp.weixin.qq.com/s/tbL4GMkja5uLaoxS7qmZmg 知识星球的基础工作（提升 NPS、内容安全、产品持续改进）完成得还不错，团队成长也还不错，但创新突破口没能落地 新的小而美的工具做得比较煎熬，没有一个产品找到突破口 写书没写完，但目前在进展中，已经进入比较稳定的写作过程中，也做了规划，理论上 2026 年应该能落地了 英语只能说持续学习了，但还达不到能工作沟通，但看片、日常表达好很多了 运动、写作、英语坚持了，读书笔记没做到 2. 新一年希望做什么和需要做什么？ 家庭方面 陪老婆孩子多一点，尽量找到一件可以一家人一起做的事情，定期做 关注长辈的健康，多陪陪长辈 工作方面和以往差不多 知识星球：稳定发展 + 创新突破 + 组织成长 新业务：找到一个立脚点 其他：写书、英语、阅读、运动 3. 有哪些记忆深刻的人、事、时刻？ 一位很年轻（四十岁）的朋友英年早逝 因为家人健康问题，开始体会到“上有老，下有小“的压力 李飞飞到办公室沟通，我当时对她的行程觉得很吃惊：从美国飞过来，不倒时差，从早到晚日程都是满的，连续三天后直接回去——这种强度，有点吓人 看到 Manus 发布、得知他们整个公司迁移到新加坡、知道他们 ARR 超过 1 亿美金、知道他们迭代中是先做了浏览器几个月后砍掉切换到 Manus，拜访肖弘聊天——觉得：年轻团队真厉害 和 Goodnotes Steves 沟通，很佩服他一款产品做 15 年，头五年是个人公司，到现在 400 人分布在不同国家——而且这些扩展都还是基于 Goodnotes 在台湾国庆的时候自己一个人过去溜达了几天。超过十年没去台湾了，有些感慨 4. 最大的成绩、失败、困难和决策是什么？ 今年没有做出什么成绩 一个失败，或者有些困难的决策是先冻结了 kbhub.com 的开发，属于我没想清楚，拖累同事了。 今年工作上的困难 知识星球方面，在我看来仍然是合规——税务政策的合规、风控的合规 所有工作上，难就难在没做出突破。不管是知识星球，还是 slax note、slax reader，又或者是敲敲打卡和 eatventure，在找新出口时，都没那么顺畅，没找到光 5. 健康情况如何，是否生过病或受过伤？ 意外地发现自己居然有了高血压——除了继续保持健康的生活习惯之外，遵医嘱天天吃药，问题倒也不大。只是真的有一点点感受到时间对身体渐进的影响 11 月底挺莫名其妙地上吐下泻超过一周加低烧两天，那几天里，有个感触：这可能就是八九十岁时虚弱、有心无力的体感吧。这趟生病之后，瘦了 6 斤，足足一个月没敢运动 身体真的重要，建议每年体检 6. 体验过最好的东西，以及欣赏过最好的书、电影、音乐等？ 喜欢 Claude Code，在电脑上结合本地文件、资料库工作，很顺畅 喜欢 Manus，还是给了我不少启发，比如给 AI 电脑 喜欢 NixOS，计划慢慢把手头的 Debian 都换过去 斯多葛哲学 喜欢 12 Angry Men 7. 对什么超级兴奋？ 好像并没有“超级兴奋“，现在要“超级“似乎没那么容易了？ AI 仍然是我觉得非常漂亮，进步非常快，对我帮助非常大，我的学习速度跟不上的东西，我很喜欢它对我效率的巨大提升，当然也会担心对未来可能的不利影响，尤其站在黑客攻防角度琢磨，确实风险不小 8. 希望自己做得更多/更少的是什么？ 隐约觉得自己今年做了很多“无用功“。我此前喜欢“不折腾“，更倾向于一件事情想清楚了再做。在 2025 年里，被好几次批评“先不要那么早做哲学讨论“。这可能是我性格里保守的一部分？但或许也并不坏——我内心还是希望做少，做小，做慢，做稳——只是不同的产品和业务阶段，需要用不同方式吧。在这方面，或许应该想想“疾如风，徐如林，侵略如火，不动如山“，不同情境，用不同方法。所以这里，其实还是矛盾的。一方面希望自己少折腾，另一个角度看，又有点期待通过“被迫折腾“，能突破自己的极限 或许应该多点买些杂七杂八的想玩的小玩具。这几年似乎对相机、手机等电子设备提不起太大的兴趣，看到一些新的电子产品，“理性“地想想使用场景，判断开机后大概率会闲置的，我就不买了，其实，可能丢了好奇心？所以，多试试新东西，至少应该多尝试不同的软硬件新产品 这两年去新地方少了，当然也有时间因素，希望 2026 年能腾出时间去新地方走走看看 又想做少，又想多做，希望今年能摆脱这种矛盾状态 9. 做了哪些之前从未做过的事？ 又当爹又当妈地陪俩娃过了小两个月，对我还真是挺有挑战的 真的开始写书了，目前完成度 30%，我想 2026 年还是有机会写完的 又开始上学了，在 NUS 读 EMBA，不过是中文的，或许未来可以试试比如上英文课，或者用英文演讲之类的 10. 有什么新或不新但被我忽略的机会？ 仍然不相信虚拟货币。虽然已经见识了“共识“的力量。所以不管比特币还是稳定币，我都还是观望 AI 领域的投资机会，我并没有抓住，哪怕是英伟达、Google 我好像没有花很多心思在观察“机会“，而是在做我喜欢的，好玩的事情。所以，很可能有机会，我也不会注意到吧 11. 能够总结这一年的一句话是什么？ 有点停滞不前，有点挫败感。可能现在还处在“水滴石穿“的早期阶段，先慢慢滴着吧 12. 这是不是想要的活法？ 目前看是的 在做的产品自己喜欢。共事的伙伴彼此信任且能相互激励。没有停留在舒适区里不动。还在不断学习和进步 生活与工作中会有些不如意，尽全力，然后接受就是了。喜欢“天地本宽，岁月本长“的说法，喜欢电影 Bridge of Spies 里的那句：Would it help？也喜欢斯多葛哲学里对待世界的态度 2024 年每年 12 问：https://wulujia.com/2025/02/23/12q1y 2025 年十年 12 问：https://wulujia.com/2025/06/01/12q10y --- # 2025 年 12 月阅读 URL: https://wlj.me/posts/2025-12-reading/ Published: 2025-12-31 Updated: 2025-12-31 Tags: Reading 流量池 The TESLA Files Tim cook - The Genius Who Took Apple to The Next Level 日航的奇迹 How Not To Invest --- # 2025 年终 12 问 URL: https://wlj.me/posts/twelve-questions-end-of-2025/ Published: 2025-12-25 Updated: 2025-12-25 Tags: WeChat, AI, Life 有没有遵守和完成年初的计划？ 年初的计划可以参见：https://mp.weixin.qq.com/s/tbL4GMkja5uLaoxS7qmZmg 知识星球的基础工作（提升 NPS、内容安全、产品持续改进）完成得还不错，团队成长也还不错，但创新突破口没能落地 新的小而美的工具做得比较煎熬，没有一个产品找到突破口 写书没写完，但目前在进展中，已经进入比较稳定的写作过程中，也做了规划，理论上 2026 年应该能落地了 英语只能说持续学习了，但还达不到能工作沟通，但看片、日常表达好很多了 运动、写作、英语坚持了，读书笔记没做到 新一年希望做什么和需要做什么？ 家庭方面 陪老婆孩子多一点，尽量找到一件可以一家人一起做的事情，定期做 关注长辈的健康，多陪陪长辈 工作方面和以往差不多 知识星球：稳定发展 + 创新突破 + 组织成长 新业务：找到一个立脚点 其他：写书、英语、阅读、运动 有哪些记忆深刻的人、事、时刻？ 一位很年轻（四十岁）的朋友英年早逝 因为家人健康问题，开始体会到“上有老，下有小“的压力 李飞飞到办公室沟通，我当时对她的行程觉得很吃惊：从美国飞过来，不倒时差，从早到晚日程都是满的，连续三天后直接回去——这种强度，有点吓人 看到 Manus 发布、得知他们整个公司迁移到新加坡、知道他们 ARR 超过 1 亿美金、知道他们迭代中是先做了浏览器几个月后砍掉切换到 Manus，拜访肖弘聊天——觉得：年轻团队真厉害 和 Goodnotes Steves 沟通，很佩服他一款产品做 15 年，头五年是个人公司，到现在 400 人分布在不同国家——而且这些扩展都还是基于 Goodnotes 在台湾长假的时候自己一个人过去溜达了几天。超过十年没去台湾了，有些感慨 最大的成绩、失败、困难和决策是什么？ 今年没有做出什么成绩 一个失败，或者有些困难的决策是先冻结了 kbhub.com 的开发，属于我没想清楚，拖累同事了。 今年工作上的困难 知识星球方面，在我看来仍然是合规——税务政策的合规、风控的合规 所有工作上，难就难在没做出突破。不管是知识星球，还是 slax note、slax reader，又或者是敲敲打卡和 eatventure，在找新出口时，都没那么顺畅，没找到光 健康情况如何，是否生过病或受过伤？ 意外地发现自己居然有了高血压——除了继续保持健康的生活习惯之外，遵医嘱天天吃药，问题倒也不大。只是真的有一点点感受到时间对身体渐进的影响 11 月底挺莫名其妙地上吐下泻超过一周加低烧两天，那几天里，有个感触：这可能就是八九十岁时虚弱、有心无力的体感吧。这趟生病之后，瘦了 6 斤，足足一个月没敢运动 身体真的重要，建议每年体检 体验过最好的东西，以及欣赏过最好的书、电影、音乐等？ 喜欢 Claude Code，在电脑上结合本地文件、资料库工作，很顺畅 喜欢 Manus，还是给了我不少启发，比如给 AI 电脑 喜欢 NixOS，计划慢慢把手头的 Debian 都换过去 - 斯多葛哲学 喜欢 12 Angry Men 对什么超级兴奋？ 好像并没有“超级兴奋“，现在要“超级“似乎没那么容易了？ AI 仍然是我觉得非常漂亮，进步非常快，对我帮助非常大，我的学习速度跟不上的东西，我很喜欢它对我效率的巨大提升，当然也会担心对未来可能的不利影响，尤其站在黑客攻防角度琢磨，确实风险不小 希望自己做得更多/更少的是什么？ 隐约觉得自己今年做了很多“无用功“。我此前喜欢“不折腾“，更倾向于一件事情想清楚了再做。在 2025 年里，被好几次批评“先不要那么早做哲学讨论“。这可能是我性格里保守的一部分？但或许也并不坏——我内心还是希望做少，做小，做慢，做稳——只是不同的产品和业务阶段，需要用不同方式吧。在这方面，或许应该想想“疾如风，徐如林，侵略如火，不动如山“，不同情境，用不同方法。所以这里，其实还是矛盾的。一方面希望自己少折腾，另一个角度看，又有点期待通过“被迫折腾“，能突破自己的极限 或许应该多点买些杂七杂八的想玩的小玩具。这几年似乎对相机、手机等电子设备提不起太大的兴趣，看到一些新的电子产品，“理性“地想想使用场景，判断开机后大概率会闲置的，我就不买了，其实，可能丢了好奇心？所以，多试试新东西，至少应该多尝试不同的软硬件新产品 这两年去新地方少了，当然也有时间因素，希望 2026 年能腾出时间去新地方走走看看 又想做少，又想多做，希望今年能摆脱这种矛盾状态 做了哪些之前从未做过的事？ 又当爹又当妈地陪俩娃过了小两个月，对我还真是挺有挑战的 真的开始写书了，目前完成度 30%，我想 2026 年还是有机会写完的 又开始上学了，在 NUS 读 EMBA，不过是中文的，或许未来可以试试比如上英文课，或者用英文演讲之类的 有什么新或不新但被我忽略的机会？ 仍然不相信虚拟货币。虽然已经见识了“共识“的力量。所以不管比特币还是稳定币，我都还是观望 AI 领域的投资机会，我并没有抓住，哪怕是英伟达、Google 我好像没有花很多心思在观察“机会“，而是在做我喜欢的，好玩的事情。所以，很可能有机会，我也不会注意到吧 能够总结这一年的一句话是什么？ 有点停滞不前，有点挫败感。可能现在还处在“水滴石穿“的早期阶段，先慢慢滴着吧 这是不是想要的活法？ 目前看是的 在做的产品自己喜欢。共事的伙伴彼此信任且能相互激励。没有停留在舒适区里不动。还在不断学习和进步 生活与工作中会有些不如意，尽全力，然后接受就是了。喜欢“天地本宽，岁月本长“的说法，喜欢电影 Bridge of Spies 里的那句：Would it help？也喜欢斯多葛哲学里对待世界的态度 --- # 我的注意力管理——离手机远点 URL: https://wlj.me/posts/attention-management-away-from-phone/ Published: 2025-12-06 Updated: 2025-12-06 Tags: WeChat, Tools不要相信自己的自制力。我反正是没什么自制力的。 所以我用了些笨办法，现在每天手机使用时间控制在一个多小时。方法很简单，就是让自己没法轻易用上那些软件。 我日常用三个屏幕：iPhone、iPad 和墨水屏手机。 iPhone 上我做了四件事。一是设置屏幕时间，晚上 20:00 到早上 9:00 停用。二是卸载抖音、小红书这些软件，微信没法卸就设为"隐藏并需要面容 ID"，隐藏后搜不到，通知也没了。三是关掉几乎所有通知，包括电话和短信。四是懒得拿出来看，上班时还会直接开飞行模式。 这样设置后，iPhone 大部分时间就在包里。 iPad 只装必须的软件。微信这种偶尔要用的，同样隐藏起来。我主要用它看电影、YouTube、工作和看书。 墨水屏手机是我日常揣口袋里的。通勤时用它看书、听音乐、听 Podcast。 核心就两条。一是别装那些软件。二是逃不开的，就藏起来，眼不见为净。 所以找不到我是正常的，我是故意让自己不在线。 --- # 普通 URL: https://wlj.me/posts/ordinary/ Published: 2025-12-02 Updated: 2025-12-02 Tags: WeChat, Startup, Security最近聊天时，一位出色的年轻人说：我觉得我很普通。Ta 有点难过。Ta 的理由是：身边的朋友都很厉害。Ta 总能看到自己不够好的地方，所以虽然常有人夸，自己并不信。 道理我不太会讲，就先讲自己的事。 多年前，我去安全公司绿盟上班，技术分享氛围很好。研究部的行家们比如 yuange、w3、小四等人经常将他们的心得详细写下，发到邮件列表。文科出身的我，此前因为兴趣，认真啃了一段时间的文章和书籍，学了些脚本小子的入门手法，一开始还自以为是有些天赋的，后来发现，糟糕，小四爱记录，写了好多东西，可是他写的东西，我看着云里雾里的。 再然后，听说了个故事（没跟当事人确认过，发完再确认哈哈），故事里，在例会的时候，w3 会跟研究部的几位同仁交代：yuange 说的，你帮着记一记，等下开完会，大家再对一下。 原因是：yuange 有时候说的，往往有些“言外之意“，几个人凑一起理解，有可能才能搞清楚。 想想我就沮丧了—我这天赋，也太普通了。 再说个昨天书上看到抄下的故事： 杰夫是怀揣着研究物理的目标进入普林斯顿大学的。 一天，他和室友不管多么努力都无法解决一个棘手的偏微分方程，两人来到另一位同学的宿舍求助。这个同学盯着方程看了一会儿，然后把答案给了他们。这个要用三页代数详细阐释的问题，他竟然用心算解决了。 那一刻他意识到，自己永远不会成为伟大的理论物理学家。 这位资质普通的家伙，是 amazon 的创始人。 很多人都觉得自己普通，但这不重要。 我觉得重要的是：做自己喜欢的事。如果一直喜欢，就一直做。长期做一件事，十年二十年后，自然能超过 99% 的人。不是因为天赋，是因为大部分人坚持不了那么久。 --- # 推荐 5 本书 URL: https://wlj.me/posts/five-book-recommendations/ Published: 2025-11-30 Updated: 2025-11-30 Tags: WeChat, Reading, Tools从 2021 年到现在，我大概翻过了三百多本书。 大部分书看完也就忘了。挑出这 5 本，是真的觉得有帮助。 Shape Up 做软件怕什么？无休止的修改，永远不够完美的功能，遥遥无期的上线日，老板还觉得不够快。 Basecamp 这本书给了一套实用性很强的方法。 如何成功管理一家软件公司（Amp It Up） 中文名起得挺土，容易错过。我今年甚至特意买了英文版来看。 作者没讲什么深奥理论，全是经营公司的常识：标准要高，节奏要快，聚焦要做的事。 常识之所以是常识，是因为太难做到。 经济腾飞路：李光耀回忆录 我们公司很小，我想做一家小且长久的公司。 看了一圈，新加坡是个好榜样。资源匮乏，没地没水，旁边还有强敌环伺。李光耀怎么带着这帮人活下来，还活成了发达国家？ 做小公司，得学学这股求生欲和治理手段。 微信背后的产品观 这本书我没事就会翻翻，它讲怎么顺着人性做东西，怎么做得自然。 时不时看看，似乎能有更好的定力。 银河帝国全集 今年第一次读完银河帝国。以前觉得《三体》震撼，看完这个才知道，《三体》里的很多设定都是向它致敬。 不为了学什么，光是看这种想象力爆炸的故事，也是一种享受。干活累了，需要这种东西解压，顺便也算仰望星空了。