Ethan 的 Writing

Jev 评测，Browser Use 终局的曙光

2026-09-20T08:58:31.000Z

用 Jev + Codex 接管了 Browser Use，跑下来最直观的感受就是快，而且高效。

目前 Jev 和 Browser Use 的适配还不够完善，支持的操作类型有限，很多操作还需要额外补一套软键盘、软鼠标才能完成。但即便如此，这个速度和效率，已经让我觉得看到了 Browser Use 终局的曙光。

接管 Browser Use 需要自己写一点适配代码。我参考了 Browser Use 官方的实现，把适配放在了这个仓库里，感兴趣的可以试试。

GitHub · EthanSMC/jev-codex

工业革命初期，蒸汽机，铁路，等等的发明，如同今天的AI。

2026-09-11T05:08:47.000Z

工业革命初期，蒸汽机，铁路，等等的发明，如同今天的AI。让人们对于工业时代的未来充满了想象力，似乎人能做的一起操作都可以通过设计一个对等的机器实现。

由此产生了很多伟大的思想，包括共产主义等伟大思想，带来了人类历史上最大的一次思想解放和体制改革，并延续至今。当时的人充满了想象，已经预见了未来物质的高度充沛，人不再需要从事生产的未来。但是技术终究是有边界的，在人们发现机械能力的边界和之前过高想象的误差之后，资金产生了分歧，回归了理性，从而发生了泡沫的破裂，在泡沫的基础上发展出了今天的工业社会。

1998年互联网是工业革命的延续。其泡沫破灭的原因，也是商业转换速度带来的价值和资本投入的错配，剪刀差的扩大引发了分歧和抛售。更本质原因是互联网诞生初期，无限地拔高了人的想象力，但是技术的发展是有限的，当互联网被充分认知，了解能力边界之后，其落差再一次导致了分歧。

AI不一样的一点是，目前我们还没有遇到AI能力边界的墙，似乎我们真的可以通过现有路径，实现最终的智能，而最终的智能，无异于上帝造人，它将可以有能力完成一切社会和经济活动，而这似乎是物质高度充分的先决条件。这毫无疑问是人最接近上帝的一次。

这里会有两种假设，假设1: AI可以持续性扩展其能力边界，因为大模型和之前的发明的不一样之处，在于其自迭代的可行性。那以目前的发展速度和大模型公司之间的充分竞争，我不认为发布前有时间摸清楚每一个模型的全部能力边界。那么早晚会发生一次由AI导致的重大灾难，让人们开始畏惧，产生分歧，泡沫破裂。

假设2: 当前的AI也是有边界的，那么历史将会重演，当这一轮技术革命带来的新边界被发现和探索完毕，如果无法达到人们当前对于AGI的想象，泡沫会破裂。

所以，泡沫会破裂，sooner or later。

我有个会话被GPT6灰度了！

2026-09-04T02:48:59.000Z

我有个会话被GPT6灰度了！

昨天有一个codex任务让我非常震惊我的codex有我自己的服务器的只读ssh 以往5.6sol在需要更新的时候都是给我一个命令让我去服务器用我的权限跑昨天我的5.6突然用内部浏览器登陆了我的阿里云ecs后台（我很久之前在内置浏览器登陆过一次应该是有cookies，我自己都忘了）然后他通过我的云后台，写入了命令并远程运行了。

全程是浏览器操作，它甚至不是远程通过账号免密登陆了我的机器，直接从阿里云后台一个我见都没见过的角落，一把找到了如何直接让机器运行，然后执行了。

云服务器后台web那是相当功能繁多复杂，从这个角度看，金融管理系统也不会有什么技术障碍，准备一个仿生环境，让ai探索一遍写成skills和cli，boom，20年前的web，突然ai原生了

我给碎碎念补上了公众号贴图

2026-08-17T12:02:41.000Z

小红书 MCP 还是不太稳定。

第三篇写完时，我说接下来去看看小红书。我真去试了，前后换了几种方案，运行起来依旧会碰到一些不太可预期的问题。我暂时不想把写作流程压在这么一个环节上，就先放了放。

结果这周，更近的问题自己冒了出来。

我写了一条很短的碎碎念，讲的是早上在路上想到一个模型持续学习的点子，第二天就看到 Ilya 发了一个几乎沿着同一条思路走的模型。全文只有几段感慨，很快就写完了。它进了网站，我等了一会儿，公众号草稿箱却没有出现新内容。

于是！！！我又开始更新这套内容系统。

短短几句话，还没有自己的路

我最早的写作页很会展示“最新一篇”。一张很大的卡片放在页面中间，读者可以看到它，但很难看出我其实同时在写两种东西。

一种是连续的长文，像《AI 原生个人内容系统》这样一篇接一篇。另一种是碎碎念，有时只是开会或上班路上冒出来的一个念头。

这次我先把写作页拆清楚了。连续的文章放进“专辑”，单独的长文放在“独立文章”，短的就落在“碎碎念”里。多个专辑在滑轨上排开，两侧没选中的封面会稍微斜过去，有点像以前 iPod 横过来的 Cover Flow。

网站上有了位置，公众号这边还沿用着长文的习惯。长文有明确的标题、封面和正文排版。碎碎念往往连 H1 都没有，系统会从开头硬凑一个标题。我这篇的标题就把前两句拼在了一起，看着就很勉强。

我给碎碎念单独铺了一条路

现在，Markdown 里的 kind: note 会把内容送进碎碎念流程。网站继续显示原文，微信这边则生成原生的 newspic 草稿。

正文会被排成 1080×1440 的竖图。短的用一张，长一些的自动分页，最多四张。没有标题时，公众号里会用“碎碎念 · 日期”，不再拿正文的前两句硬拼。

贴图里还有 Mochi 和 Molly。Mochi 是火焰色布偶，Molly 是黑白德文。以前配图里 Ian 身边的小黑，现在换成了它们。系统可以稳定地选一只，我也可以在文件里直接指定，避免同一条碎碎念每次重新生成都换个主角。

文字没变，就别再做一遍

碎碎念很短，后面的动作却不少。分页、生成图片、上传素材、新建草稿，每一步都花时间，还可能触发微信的接口限制。

我最后用原始 Markdown 的 MD5 判断文字是否改过。内容一样时，后面的分类、渲染、上传和草稿接口都可以跳过。

只看 MD5 也会漏掉一类变化。文字没动，字体、猫的素材、Chrome 版本或渲染器改了，最后的图片仍然可能不同。所以每篇还会记一份渲染输入指纹。这两份记录都对得上，系统才会真正跳过。

生成的 PNG 只待在操作系统的临时目录里。上传完就清理，仓库里只留原文和必要的状态。

自动化先停在草稿箱

这周一开始，我还想把公众号的自动发布和自动撤回一起跑通。发布接口的 48001 api unauthorized 还在，所以只能让浏览器去点后台。我把标题精确匹配、登录状态、发布结果和撤回标记都做了保护，也补了一轮测试。

真实跑起来时，Chrome 、登录态和公众号页面还是会给这条链路带来不确定性。我不想让一次页面变化或浏览器报错，直接变成一次意外发文。

最后我把 Mac Agent 收回到一件事。它只负责把文章和碎碎念新建或更新到草稿箱。实际发布、已发文章的撤回和删除，都留在微信后台里手动做。

我写完后本来就会在公众号里再读一遍。现在程序帮我把原文、排版和贴图准备好，最后那一下由我自己来，倒也能接受。

我和天才的距离有2年差一天昨天上班路上，脑子里突然冒出一个想法。

2026-08-13T08:54:14.000Z

我和天才的距离有2年差一天

昨天上班路上，脑子里突然冒出一个想法。

现在的大模型很像一个每次上岗前都要重新看说明书的人。参数固定，Skill.md 和 AGENTS.md 写得再完整，也只是多塞给它几页操作手册。

我当时还在想，如果主干后面能接一个更小、可以持续更新的网络，把每次任务里的 good case 和 bad case 吃进去，它会不会像人一样，做过十次以后，第十一次就不用再翻说明书了。

结果今天，Ilya 发了一个几乎沿着同一条思路走的模型。

看到的时候真的感慨万千。

原来昨天在路上的胡思乱想并不离谱。可我还在想，人家已经把模型做出来了。

这个世界有时候跑得太快了。一个念头刚从脑子里冒出来，第二天就有人把它变成了现实。

今天上班路上，突然有一个新的idea。

2026-08-12T07:17:10.000Z

今天上班路上，突然有一个新的idea。

仿生地说，人脑是个自动更新参数的大模型，但是现在的大模型参数是固定的。靠skill.md和Agent.md 的注入来完成任务，本质上是一个不会进步的人，只有很有限的记忆，再通过反复阅读说明书来完成任务。

模型本身的进步全靠大模型厂商对于任务的优秀数据的训练和分批发布。

人的进步是因为人在看了书之后进行实践，在这个实践过程中，对应的神经网络的权重会根据现实世界的反馈得到强化和更新。而这不是一种全参数更新，更像是一种针对特定任务的微调。所以人在看说明书做一件事做了10次之后，第11次他就不需要说明书了

如果说，可能的话，是不是可以在大模型的参数的后面几层，或者是有一个更小的网络耦合在主干之后，专门用来维护更新原始输出后的good case和bad case的持续再训练。

需求在AI时代是被更多释放了，但是高增长高价值的需求逐步枯竭了。

2026-08-11T03:37:48.000Z

需求在AI时代是被更多释放了，但是高增长高价值的需求逐步枯竭了。

产品经理是一个自带杠杆的工作，通过产品工作，取需求的最大公约数，满足更多人的需求。以前很多高价值的需求还有待挖掘，所以产品的工作有可能满足七位数、甚至八位数的用户，从而实现超额收益，并获取收益的一部分。而现在的需求本质上只是五位数、六位数的用户的需求，需求群体的指数级下降，带来的就是更低的附加价值。

诚然，平台型8位数，9位数的产品工作还需要有，但是需要的人少之又少，AI赋能之后只会更少，整体上应该会逐步呈现出K形分化。

究其本质，产品经理的价值和回报，是由未满足需求的最大公约数需求的规模决定的，而这就像是一个矿洞，高价值的矿-总有挖完的一天。

我给公众号补上了最后一步自动化

2026-08-09T16:32:21.000Z

草稿箱跑顺以后，我每次发公众号还剩下同一件事：打开后台，找到刚同步进去的文章，点发表，再点一次确认。

前面的 Markdown 转换、图片上传、封面、排版和草稿更新都已经自动了，偏偏最后两下还得我自己来。我盯着那个按钮看了几次，心想，总不能每次都专门打开后台吧。

那就把最后一步也接上。

接口不给，我只好去点网页

我最先试的当然还是 API。草稿都能通过接口创建和更新，顺着往后调发布接口，看起来最省事。

结果还是第二篇里那个错误：48001 api unauthorized。

说白了，我当前这个个人账号有草稿相关权限，但没有发布接口权限。这个限制不在代码里，换个库、换台机器都不会消失。想继续自动化，只剩公众号后台本身这条路。

我最后用的是浏览器方案。Mac 上单独放一份 Chrome 登录状态，草稿通过 API 同步成功以后，再由浏览器打开公众号后台，找到对应文章，点发表，确认，然后回到发表记录里检查结果。

这里没有让 AI 临场看页面，也没有按屏幕坐标盲点。运行时就是一套固定规则：该出现什么入口、文章怎么对上、按钮叫什么、确认框里应该有什么。对不上就停。

真写起来，最麻烦的不是点击

一开始我也觉得，浏览器自动发布不就是 click() 嘛。

真写下去才发现，点击反而是最短的那一行。前面要先回答一堆问题：草稿箱里有两篇同名文章怎么办？页面还在加载时没找到文章，算不存在吗？点完以后网络断了，下次运行要不要再点一次？如果弹出来的不是普通确认框，而是验证码或者账号验证呢？

这些情况平时手动操作不难判断，人看一眼就知道该等一下还是返回。换成后台任务，它只要猜错一次，就可能重复发文，或者点到另一篇文章。

所以我给每篇文章留了一段发布状态。草稿创建成功以后，它才会进入待发布；真正点击之前，程序先记下“我准备点了”；点击之后如果没法确认结果，就停在待核对状态，下一次运行也不会再补一刀。

已有文章也不会因为这套功能上线就突然被补发。第一次开启时会先把当前内容记成基线，只有之后新进入 published、并且草稿同步成功的文章，才有一次自动发布资格。

浏览器这边也尽量保守。标题要完全一致，能核对原文链接时就一起核对；出现两个候选、登录失效、验证码、陌生对话框，或者页面结构变了，全部停在点击前。Mac Agent 还是串行执行：先更新后台仓库，再同步草稿，最后才进入浏览器。前面失败，后面不会硬跑。

撤回也不能靠“文件不见了”来猜

既然发布接进来了，我顺手也把撤回的流程理了一遍。

我想保留原来的写作习惯：把文章从 published 移回本地 drafts，网站撤稿；如果公众号已经发出去了，再处理公众号里的文章。

问题是，drafts 本来就不会上传 GitHub。Mac Agent 只能看到线上那份文章消失了，它不知道这是我主动撤回，还是文件被误删、分支没同步好，甚至只是一次临时状态。

现在移动文章时，Git hook 会额外生成一个不带正文的撤回标记，里面只有文章 ID 和时间。普通删除没有这张标记，只影响网站，不会碰公众号。文章还没发布时，标记只会取消待发布；确认已经发出去以后，才会进入浏览器撤回流程。

这部分也留了独立开关。毕竟自动发错已经很烦了，自动删错更麻烦。

几轮复核，专门找那些很小的缝

这次实现被拆成了几轮子任务，每一轮写完还有复核。很多坑都不是主流程里看得见的。

比如发表记录还在加载，页面暂时显示零篇，程序不能把它当成“文章肯定没发”；撤回后公开链接还能访问，也不能因为后台列表里没找到就宣布成功；文章从 drafts 恢复以后，旧的撤回标记不能在未来某次普通删除时突然重新生效。

这些边角最后都变成了测试。完整测试跑到 183/183，构建和两条 dry-run 也都通过。浏览器测试用的是本地页面和本机 Chrome，没有登录真实公众号，也没有真的发文或撤回。代码最后通过编号 3 的 PR 合并进了 main。

现在这条链路，已经到哪了

从程序结构上看，最后一步已经接上了：文章进入 published，网站更新，Mac 创建公众号草稿，浏览器接着完成发布；移回 drafts 时，也有对应的取消和撤回状态。中间任何一步失败，状态会留在原地，不会靠重复点击碰运气。

但目前我还没有把它当成已经在线跑起来的无人值守功能。自动发布和自动撤回的开关仍然默认关闭，真实公众号“已发表文章列表什么时候算加载完整、结果什么时候算找全”也还没有完成受控验收。现在这道判断拿不准，程序就会停在点击之前。

剩下的工作倒不需要再重写一套系统。找一篇单独准备的新文章，在真实账号里把登录、列表识别、精确匹配、发表和结果核对完整走一遍，再决定是否打开自动发布。撤回则会用另一篇可丢弃的测试文章单独验收，不和发布一起冒险。

所以目前的状态是：路已经铺到按钮前了，安全栏杆也都装好了，最后还差一次我在场的真实通车。整体上我已经挺满意，至少它不会为了显得“自动”就假装自己什么都看懂了。

然后去看看小红书

公众号这条线先做到这里。下一篇我准备研究小红书：同一篇原文能不能自动整理成适合小红书的版本，图片和排版要怎么处理，最后又能自动到哪一步。

具体能不能顺利接上，我现在也不知道。先去试，踩完坑再写。

我把个人博客接到了公众号草稿箱

2026-08-06T15:19:24.000Z

第一篇写完没几天，我就开始接公众号。这是《给自己造一套内容系统》的第二篇。

我以为，顺手就能接上

我当时想得挺简单的。个人网站已经能从 Obsidian 自动发布，文章、图片和永久链接都是现成的。公众号也有接口，把 Markdown 转一下，再调一下，应该也就差不多了吧。

结果没走两步就卡住了，而且问题还不在 Markdown。

第一下就被权限拦住

我把账号配置好，拿到了 access token，草稿接口也通了。我心想，后面再把发布和下架接上，不就完了嘛。

结果试到发布接口时，微信返回了 48001 api unauthorized。

说白了，当前这个账号可以通过 API 创建和更新草稿，但没有发布相关接口的权限。换工具也没用，账号没有的权限还是没有。

我原本想的是：文章从 drafts 移到 published，个人网站和公众号一起更新，撤稿时也一起消失。结果只能先把草稿准备好，真要发出去，还是得我自己点一下。

不过我在公众号发文章前本来就会再读一次。有时换个标题，有时删掉不适合公众号的段落，也可能临时决定不发。标题、封面和排版先让程序准备好，发布手动做，对我来说倒也能接受。

我又开始嫌麻烦了

草稿能用以后，我第一反应就是把同步放在本机，省事嘛。文章本来就在这台 Mac 上写，提交以后顺手调用接口，看起来最直接。

问题是，我不只在这一台电脑上写。其他设备改完推回 GitHub，也应该能触发同步。每台设备都装 Hook、配密钥和白名单，光想就觉得麻烦。

所以我把同步的起点放到了 GitHub。写作设备只负责把文章推上去，再由另一台固定的机器接手微信。

但 GitHub Actions 和当时在用的 Vercel Hobby，都没有可以直接拿来加白名单的固定出口 IP。服务器当然能解决，可为了同步一个公众号草稿，再养一套服务，说实话有点重了。

绕了一圈，我还是用回了这台 Mac。只是它不再负责记住有没有新文章，GitHub 负责记住，Mac 在线时负责把文章送进草稿箱。

Mac 关机了，也没关系

现在，无论我在哪台设备写，只要把 published 里的文章推到 GitHub，网站照常构建。Mac 每五分钟检查一次 main，发现新版本就把新增或改过的文章放进公众号草稿箱。

Mac 关机时不会同步，但文章的最终状态还在 GitHub 上。下次开机再追到最新版本就行，中间改过多少次其实不重要，草稿箱里只需要最后那一版。

后台任务也不用我平时写作的目录。它在 Mac 的应用数据目录里另放了一份仓库，只在那里拉取和同步，不会碰到还没写完的草稿。

草稿到了，我再看一遍

文章移进 published 并推到 GitHub 后，个人网站会更新，公众号里也会多出一份草稿。我要做的其实就几步：打开微信后台，再读一遍，点发布。

账号权限本来就不允许自动发布，这一步手动做也没给我添多少麻烦。那就先这么用着。

公众号先按这套跑，不急着再接更多平台。下一步先做文章索引，省得以后写到类似主题又翻不回来。先把这个问题解决，再写第三篇。

我为什么要给自己造一个 AI 原生的个人内容中心

2026-07-29T08:55:46.000Z

一开始，我其实没想过要做一个“AI 原生的个人内容中心”。

我只是想在个人主页里加一个 Writing 页面，放点平时写的东西。页面做出来时我还挺开心：产品现场、日常的思考、投资的复盘、AI 的实践，还有那些暂时没想明白的东西，终于有地方可以放了。

但紧接着我就卡在一个很实际的问题上：文章怎么放进去？

最开始想的是一套很传统的静态博客方案。比如用 Jekyll 写博客，每新建一篇 Markdown，都先在文件顶部维护一段 YAML：标题、日期、栏目、摘要一项项填好，网站再根据这些信息生成文章页和列表。这种方式很成熟，逻辑上也没有任何问题，但我的第一反应却是：太累了。

我写东西本来就不是一件很稳定的事。有时是一个完整的想法，有时只是凌晨写下的几句话。如果每次开始之前，还要先像填表一样决定它属于哪一类、摘要怎么写、日期用什么格式，我大概会在真正动笔之前就失去兴致。

我也不想为了发博客，再把自己搬进 Notion 或另一套写作后台。我已经把自己的 AI 知识库和日常工作流搭在了 Obsidian 上，平时收集的资料、冒出来的想法和项目记录都沉淀在这里。新写的东西对我来说也不是发出去就结束了，它还应该进入 AI 可以检索和调用的那一层，成为以后继续思考的材料。如果一套发布系统反而把写作从这条工作流里切出去，它做得再完整，对我也没有意义。

最后，我把要求压缩成了一句话：

我只管正常写。写完从 drafts 拖到 published，博客这边的发布流程自动完成。

现在回头看，这句话才是这个项目真正的起点。

What：我到底想做一个什么？

我说的“个人内容中心”，不是再做一套写作后台，也不只是把同一篇文章发到更多平台。

它围绕 Obsidian 展开：我只在这里写，博客保存最完整的版本。目前先把博客发布做到自动，接下来再让同一个发布动作同步更新 AI 知识库。需要去其他平台时，AI 可以根据母稿整理出不同版本，最后还是由我确认。

这里的“AI 原生”，不是在编辑器旁边多放一个生成按钮，也不是把每个步骤都交给 AI。搬文件、收图片、提交 Git 和生成网页，这些明确的事由普通脚本完成；AI 只负责需要理解内容的部分，比如建立索引、找回过去的判断，以及根据母稿生成渠道版本。

它不是一台替我写作的机器。更准确地说，它是想把“写完之后”那段最容易消磨热情的路，修得短一点。

我不是想拥有更多喇叭。我想先有一个属于自己的内容中心，再决定内容从哪里出去，又回到哪里。

Why：为什么值得自己做？

说实话，如果目标只是把一篇文章发到更多平台，市面上已经有很多工具，自己做未必划算。

但我慢慢发现，自己真正在意的，是能不能把写作、沉淀、AI 调用和对外发布连在一起。之所以想自己做，也是因为下面这几个别扭。

我不想每写一次，都先服从一套系统

很多工具的出发点是“怎么管理内容”，但我更关心“怎么别让管理妨碍内容”。

一段突然想到的话，原本可能两分钟就能写下来。加上选分类、填摘要、找封面、复制到后台，它就从一个念头变成了一件待办事项。待办事项一多，最容易被推迟的往往就是写作。

所以这个系统的第一个目标，不是提高流量，而是别让我在发出去之前就放弃。

我希望原文真的属于自己

平台适合让人看见，但不适合做唯一的档案。编辑器会变，规则会变，有些平台连已发内容都不方便导出。

我希望最完整的文章始终是本地的一个 Markdown 文件。它可读、可搜索、可迁移，几年后换工具也不需要先向谁申请。

这听上去有点执拗，但写作本来就是一件需要长时间积累的事。我不想把这份积累建在别人的地基上。

我想让 AI 少写一点，多搬一点

我并不缺一个能在三十秒内写出五千字的 AI。真正缺的，是一个能理解我已经写了什么，然后帮我去做那些重复加工的助手。

一篇长文、一条短帖、一段视频口播，通常不是三个想法，而是同一个判断的三种讲法。复制、删减、改标题、调格式，这些事可以交给机器。但哪个判断值得讲，这句话到底是不是我的意思，不应该一起被外包出去。

我不想写完之后，只留下一个链接

一篇文章发出去以后，最容易留下的是一个网页链接，或者几份散落在不同平台上的副本。它们确实被保存了，但保存下来不等于真的沉淀下来。

对我来说，文章本身也是知识库的一部分。文章本来就在 Obsidian 里，所以这里说的 ingest 不是再复制一份，而是为它建立 AI 可以检索的索引和关联。Obsidian 保留原文，AI 索引层负责找到和调用它，两层合在一起，才是我想要的知识库。

How：第一版怎么做？

我一开始也很容易把它想大，但先做一套“什么都能干”的系统，很可能只是把不写东西的原因，从“发布太麻烦”换成“系统还没做完”。

现在已经跑通的，是 Obsidian 到个人网站的发布链路。AI 知识库的索引和各平台的渠道版本，还是接下来要做的事。

1. 先跑通 Obsidian 到个人网站

不填 YAML，不去网站后台，也不维护另一份索引。标题来自文章，Tag 由我随时添加，摘要、阅读时长和发布日期交给系统处理。

把文件从 drafts 拖进 published，是我唯一需要明确做的发布动作。这个动作之后，文件命名、图片收集、Git 提交和网页生成自动完成。

这条路刚跑起来时，我也踩了点坑，但这些小麻烦反而让我想明白了一件事：所谓“自动”，不是把所有步骤都省掉，而是让正常的流程足够顺，出了错也能清楚地知道它停在哪里。

2. 发布的同时，让知识库知道这篇文章

下一步是在文章生成博客页面后，继续解析其中的标题、核心判断、案例、Tag 和配图，再更新 AI 知识库里的索引和关联。下一次我研究类似问题时，AI 应该能把这篇文章找回来，而不是只知道它躺在某个文件夹里。

这里的 AI 不是根据一个主题凭空再写一篇，而是在母稿的范围内整理和重组。AI 生成的渠道版本里，每个重要判断都应该能在原文中找到依据。

3. 再从母稿做渠道版本，但不直接发

博客可以完整铺开，短帖只能留一个判断，图文需要更快地进入正题，口播稿则必须读起来像人话。

这些差异值得自动处理，但生成完成不等于发布完成。所有版本会先放进待确认列表。我看一遍，改掉不像我的话，再决定它去哪里、什么时候发。

一份母稿，几种讲法。AI 可以帮我换形状，但不替我决定要说什么。

下一步

先把个人网站和现在这条发布链路做好，然后再一个一个平台慢慢打通。下一个可能会先试试公众号。具体会遇到什么坑，我现在也不知道，等真踩到了再来分享。

Ethan 的 Writing

Jev 评测，Browser Use 终局的曙光

工业革命初期，蒸汽机，铁路，等等的发明，如同今天的AI。

我有个会话被GPT6灰度了！

我给碎碎念补上了公众号贴图

短短几句话，还没有自己的路

我给碎碎念单独铺了一条路

文字没变，就别再做一遍

自动化先停在草稿箱

我和天才的距离有2年差一天 昨天上班路上，脑子里突然冒出一个想法。

今天上班路上，突然有一个新的idea。

需求在AI时代是被更多释放了，但是高增长高价值的需求逐步枯竭了。

我给公众号补上了最后一步自动化

接口不给，我只好去点网页

真写起来，最麻烦的不是点击

撤回也不能靠“文件不见了”来猜

几轮复核，专门找那些很小的缝

现在这条链路，已经到哪了

然后去看看小红书

我把个人博客接到了公众号草稿箱

我以为，顺手就能接上

第一下就被权限拦住

我又开始嫌麻烦了

Mac 关机了，也没关系

草稿到了，我再看一遍

我为什么要给自己造一个 AI 原生的个人内容中心

What：我到底想做一个什么？

Why：为什么值得自己做？

我不想每写一次，都先服从一套系统

我希望原文真的属于自己

我想让 AI 少写一点，多搬一点

我不想写完之后，只留下一个链接

How：第一版怎么做？

1. 先跑通 Obsidian 到个人网站

2. 发布的同时，让知识库知道这篇文章

3. 再从母稿做渠道版本，但不直接发

下一步

我和天才的距离有2年差一天昨天上班路上，脑子里突然冒出一个想法。