最近三个月，我在产研团队内部推广 AI 的使用。越往前推我越觉得，主观上的判断与思辨，比使用哪个具体的 Skill 更重要，也比提示词应该怎么写更重要。很多人表面上是在用 AI，实际上总是被 AI 牵着鼻子走。

前阵子我和团队里一位同事聊一个系统开发进度。我发现他的产出一直不太对劲，细问之后，他告诉我：

我一开始也是照着自己的想法在做，做到一半就有点拿不准了，总觉得哪里不太对。
后来我就把需求和代码一股脑丢给 AI，让它帮我改。
它改完以后，我其实也没完全看懂，只是感觉它写得还挺像那么回事。
我又追着问它为什么要这么改，它就一条一条给我解释。
当时我听着也觉得有道理，就先照着用了。

他反映出的问题其实并不是「会不会」用 AI 工具，而是把判断、思辨以及决策的权力都交给了 AI。

本来应该是人来判断，AI 来提供候选方案。可一旦人开始习惯“拿不准就让 AI 定”，最后就会变成 AI 在做决定，人只是在旁边接受结果。

AI 的表述一定会合情合理，并且语气坚定，说白了就是「一本正经地胡说八道」，这常常让我们着了道。

它不管结论到底靠不靠谱，往往都能给出一套完整、流畅、听上去很像那么回事的解释。只要你自己没有判断标准，这种表达就很有迷惑性。时间一长，人就很容易产生一种错觉：既然 AI 说得通，那就按它的来。

可问题恰恰在这里。AI 并不知道你真正要做什么。

它知道的，只是你喂给它的那点上下文。如果你自己都没想清楚这个功能到底要解决什么问题，有哪些约束，什么结果才算对，那你给出去的上下文一定是不完整的。这样一来，AI 的每一步局部建议都可能看着挺合理，最后拼出来的整体却越来越偏。

我认为，很多人真正的问题，不是提示词写得好不好，也不是会不会用 AI 工具，而是自己没有定义问题的能力。

你没有想清楚目标，AI 就会替你组织目标。
你没有想清楚约束，AI 就会替你补一套看上去合理的约束。
你没有判断标准，AI 说什么你都会觉得有道理。

到最后，问题就不是“AI 用得好不好”，而是你已经把判断权交出去了。

这也是为什么我最近对一个词越来越有感觉：Harness Engineering。

很多人以为问题出在提示词，不是。至少在工程场景里，我越来越觉得，提示词只是很小的一层。真正重要的，是你有没有办法把 AI 放进一个可控的系统里。

OpenAI 之前有个实践很值得注意。他们用 Codex agents 参与构建过一个超过百万行代码的系统。这里真正重要的不是“AI 会写代码”这件事，而是工程师的角色已经在变。

人不再把主要精力放在逐行写代码、逐行改代码上，而是更多地放在系统设计、规则约束和反馈机制上。

这背后对应的，其实就是 Harness Engineering。

说白了，无非三件事。

第一件事是 Context。不是甩一句需求给 AI 就完了，而是要让它知道它现在在什么系统里，代码结构是什么样，接口怎么定义，之前为什么这么实现。你给得越完整，它跑偏的概率才越低。

第二件事是 Constraint。光靠“请你认真一点”是没用的，得让错误根本过不去。lint、测试、CI、架构边界，这些东西过去是给人用的，现在同样也是给 AI 用的。关键不是让 AI 更聪明，而是让明显错误无法通过。

第三件事是 Feedback Loop。以前是人踩一次坑，记住，下次尽量别犯。现在更合理的做法是，AI 出一次错，就把这个错沉淀成规则、检查项、脚本或者模板。这样下次它就不是“尽量别错”，而是“没那么容易再错”。

说到底，我现在越来越不觉得 AI 的关键问题在模型本身，而在它所在的环境。

同一个模型，放在两个团队里，表现可能天差地别。有人用它越用越稳，有人用它越用越飘，差别并不只是谁提示词写得花，而是谁把环境搭得更像一个能收敛的系统。

这也是我最近一个越来越强烈的感受：AI 并没有让能力真正平权，它更像是在放大原有差距。

会思考、能定义问题、知道怎么判断结果的人，会把 AI 变成自己的放大器；本来就缺少判断标准的人，只会更容易把决定权交出去。最后表面上大家都在用 AI，实际上少数人在控制 AI，多数人在依赖 AI。

所以我现在给自己留了一个很简单的判断题：在让 AI 帮我做一件事之前，我先问自己一句，如果没有 AI，我会怎么做？

这个问题并不要求我把所有细节都手写出来，但至少我得知道目标是什么，约束是什么，判断对错的标准是什么。如果离开 AI 我就完全说不清，那我多半也没有真的在使用它，而只是把它当成一个更高级的外包。

我甚至有一种感觉，管理 AI 和管人其实差不了多少。你带一个人做事，要先把背景讲清楚，把目标和边界说清楚，中间要调度，最后还要看结果是不是对。AI 也是一样。你不给它上下文，不做调度，不判断结果，它就一定会往一个看上去合理、但未必是你真正想要的方向跑。

AI 当然很有用，我自己也一直在用。

但我越来越相信一件事：AI 不是来替人思考的，它只是把人的能力放大了。

会思考的人，用它放大能力。
不会思考的人，被它牵着走。

所以在 AI 时代，关键从来不是“会不会用 AI”，而是你能不能控制它。

今天早晨七点多，我开车经过黄埔路。

那时候路上的车已经不少了，但还没有真正堵起来。车流是流动的，人也是流动的。大家都在往各自的方向去，像是默认接受了一种清晨的秩序：从一个起点，尽快抵达另一个终点。

开车的时候，人会很自然地进入一种状态。眼睛只盯着前方，注意红绿灯，注意变道，注意前车距离，注意还有多久能到。至于路两边到底有什么，经过了哪些建筑，街边是不是新开了一家店，某一扇门、某一排窗、某一个转角有没有什么细微的变化，往往根本不会真正进入感知。

我们在穿过一座城市，却并没有真正看见它。

如果换成步行，感觉就完全不同了。

步行的时候，人是慢下来的。你会看到一幢建筑门窗的样子，会留意某家临街店铺的装饰，甚至会记住一个街角的招牌、一道旧墙的颜色，或者某个清晨落在路边树上的光。那些东西看起来都没有什么“用”，但很多时候，真正留在记忆里的，反而正是这些无用的细节。

过了很久以后，回想起某个地方，让人印象深刻的，通常不是“我从这里开过去了”，而是“我曾经认真看过这里”。

开车带来的变化，不只是速度更快了，也是在不知不觉中改变了我们感受世界的方式。

当一个人坐在车里，城市会被迅速压缩。道路、路口、停车位、目的地，这些信息会变得异常清晰；而那些与抵达无关的细节，则会自动退到视野之外。于是，一座原本有肌理、有层次、有生活感的城市，慢慢变成了一张功能性的交通网络。

这也让我突然想到，为什么有时候会觉得南京这座城市看起来很大，但开车时又觉得它似乎没那么大。

因为开车所感受到的，不是城市本身，而是一个个点之间的连接。家、公司、学校、商场、餐馆、停车场，我们记住的是这些目的地，以及通往它们的路线。至于两点之间原本存在的那些东西，常常就被忽略了。

可一座城市真正的气质，往往恰恰藏在这些被忽略的部分里。

那些不被导航标记的街边细节，那些不会影响抵达效率的门窗、招牌、装饰、树影、旧墙，那些走路时才会注意到的停顿和观察，才构成了一个地方真正的纹理。

所以并不是城市变小了。

只是我们与它之间，多了一层赶路的视角。

而我后来又觉得，这种“只看起点和终点”的状态，其实也不只是开车时才有。

它很像我们现在的生活。

我们越来越习惯用结果来理解一切。工作要看结果，学习要看结果，项目要看结果，甚至连休息、读书、锻炼，很多时候也会被我们默默地换算成有没有产出、有没有意义、值不值得。

我们在意的是有没有到达，而不是自己是怎么走到那里的。

久而久之，人就会变得有些钝。不是能力变差了，而是对过程的感受力变弱了。看事情越来越直接奔向结论，做事情越来越只问有没有结果，中间那些原本能够滋养人的东西，反而被当成了可以省略的部分。

可真正让一个人慢慢形成判断的，往往不是最后那个答案，而是在摸索中的迟疑、比较、观察和反复确认。真正让一个人学会一件事的，也不是最终完成的那一刻，而是那些看起来缓慢、重复、甚至有点枯燥的过程。很多认知，不是在终点产生的，而是在路上产生的。

就像认识一座城市，并不是因为你开车穿过了它。
真正的认识，往往来自你愿意慢下来，认真看它一眼。

速度当然有它的价值。现代生活也不可能真的退回到凡事都慢悠悠的时候。只是有时候我会觉得，我们今天失去的，也许不只是慢，而是对过程本身的感受力。

当一个人越来越只在乎从 A 点到 B 点，他得到的是效率；但那些真正细微、真实、能留下来一点痕迹的东西，也可能就在这个过程中被一起略过去了。

而生活里很多重要的东西，偏偏都不在终点。

它们藏在途中，藏在细节里，藏在那些看似无用、却会在日后某个时刻重新浮现出来的瞬间里。

最近看了 Claude 设计负责人 Jenny Wen 的一个视频，标题很直接，叫《The design process is dead. Here's what's replacing it.》。

她讲的那套变化，这两年确实越来越明显：设计不再只是停留在 mockup、prototype、设计稿这些阶段，越来越多的工作，开始直接往实现层走，设计师和工程师之间原来那条很清晰的边界，也在一点点变淡。

我看完之后，倒没有那种“被刷新认知”的感觉。

更像是看到一件自己很多年前就在做的事，终于被更多人认真拿出来讨论了。

因为对我来说，用代码做原型，从来都不是什么新鲜事。

大概二十年前，我就已经开始用 HTML 做原型了。那时候前端远没有今天这么成熟，做页面也没有这么多现成框架和组件体系，但我当时就一直有个很直接的想法：既然最终产品本来就是页面，那原型为什么不能就是页面？

后来有了 Vue.js，我又继续用 Vue.js 做原型。

所以这些年里，我手里的原型，很多时候都不是那种“表达一下意思”的图，而是已经能点、能跳、能切状态、能看出结构问题、甚至已经有一点产品味道的东西。

这也是为什么，我一直对很多标准化的设计流程有一点保留。

不是说我不理解它们存在的原因。

很多年前，我问过一个去了腾讯的同事，腾讯内部大概是什么样的工作流。他回我一句话，我印象很深，大意是：你以为都像你这样啊？团队里有很多角色，每个人都要有自己的交付物，交付物是要继续往下传的。

这句话当然没错。

只要团队一大，角色一多，流程就一定会被切开。产品经理写需求，交互出流程，UI 出视觉稿，研发理解并实现，测试再根据这些东西验证。大家各自站在自己的环节里往前推，中间自然会长出大量交付物。

从组织管理上看，这套东西很合理。

但我这些年一直有种很强烈的感觉：交付物一多，信息就开始在路上损耗。

一个想法从脑子里出来，写成文档，是一次转换。
文档变成原型，是一次转换。
原型变成设计稿，又是一次转换。
设计稿再交给开发理解实现，还是一次转换。

转换越多，偏差越多。

这不是谁做得不认真，也不是谁能力不够，而是只要经过传递，只要经过翻译，理解就一定会发生变化。每个人的经验不同，关注点不同，表达习惯也不同。你觉得自己已经说得很清楚了，对方也觉得自己已经理解了，最后真正做出来的东西，还是经常和最初脑子里的那个状态隔着一层。

所以我一直很看重原型这件事。

在我心里，原型最大的价值，从来都不只是“先画一个出来”，而是尽可能减少这种损耗。离真实产品越近，后面的误差就越少。

这也是为什么，我早年会直接用 HTML 做原型，后来会用 Vue.js 做原型。

因为图太容易把问题藏起来了。

页面结构是不是合理，静态图不一定看得出来。
状态切换顺不顺，图里经常也能糊弄过去。
数据一接进来会不会露馅，设计稿往往也帮不上忙。
很多交互在图里看着很顺，真跑起来却不一定成立。

代码原型有个很直接的好处，它会逼着你更早面对这些问题。

它不太会给你一种“好像已经设计完了”的幻觉。你一旦真的把东西搭成页面，很多原本藏在图里的小问题，马上就会跳出来。按钮状态对不对，层级顺不顺，交互有没有顿挫感，结构能不能撑住真实内容，这些都会比在设计稿阶段更早暴露。

后来我去做低代码平台，其实也是沿着同一条路往前走。

很多人现在提到低代码，第一反应是拖拽、拼装、少写代码。这个理解当然不算错，但如果只停在这里，会把很多真正关键的东西漏掉。

我当时参与做的 Orang，就是一个可以通过拖拽来搭建前端页面，再通过 Blockly 这样的可视化方式去配置逻辑的低代码平台。那段时间我还专门翻译过 Blockly 的文档。平台里不少和架构、DSL、组件库相关的内容，我都实际参与过，也写过不少具体的东西和代码。

所以我后来再回头看这段经历，会觉得 Orang 对我来说很重要，不是因为它最后商业上有多成功。恰恰相反，作为一个“低代码生产程序”的产品，它最后没有走出来。

但这件事没有改变我对它那套思路的认可。

因为在我心里，它始终比 Figma、Pixso 这一类纯做 UI 稿件的工具，更接近“原型”这两个字真正该有的样子。

Figma 当然很好用，我也不是在否定它。它在协作、表达、视觉统一这些方面，确实解决了很多问题。但它给我的感觉，一直更像是把界面描述得更清楚。Orang 这种东西会让我觉得，页面已经搭起来了，逻辑也能往里接了，它离真实产品已经没有那么远了。它不像一张停在中途的图，它更像一个还没有长完整、但已经能继续往前长的东西。

所以前段时间 Pencil 火过一阵，也有朋友给我推荐过一些号称能媲美 Figma 和 Pixso 的免费工具，我连看都没太想看。

不是因为我觉得这些工具没技术含量。

恰恰相反，是因为我越看越觉得，它们解决的还是同一类问题。

Pencil 这条路，我其实并不陌生。
如果往本质上看，它和我当年参与做的 Orang 并没有那么大的差别，都是试图通过一套更高层的表达方式，把界面和逻辑继续往代码上推。说得再直白一点，都是从 DSL 走向代码。Orang 后期其实也已经加过 AI 功能，所以我今天再看这类新工具，并不会觉得它们突然打开了一个完全陌生的新世界。

真正让我在意的，也从来不是“又出了一个更强的 UI 工具”。

问题的根子在别的地方。

如果代码已经是最终结果，本身就可以交付，
那谁还会长期为一个中间结果买单？

这才是我越来越不关心这类 AI UI 工具的原因。

以前大家愿意为设计工具买单，是因为那时候设计稿在工作流里非常重要。它是沟通媒介，是评审对象，是交付节点，是开发前必须经过的一站。谁能把这一步做得更顺、更快、更标准，谁就有价值。

但现在情况已经变了。

页面可以直接搭，交互可以直接做，逻辑也能直接往里接。很多原来必须停留在 UI 稿上的内容，今天已经可以继续往前走。到了这个阶段，我自然很难再对“一个更像 Figma 的工具”产生很高兴趣。因为我关心的，已经不是怎么把中间结果做得更漂亮，而是这层中间结果本身，还有没有那么大的必要。

工作流一旦变了，工具的意义也会跟着变。

过去的链路更像这样：

想法
→ 文档
→ 原型
→ 设计稿
→ 开发实现

现在越来越多时候，它开始变成这样：

想法
→ 页面
→ 交互
→ 逻辑
→ 继续迭代

中间那层专门拿来生产 UI 稿件的工具，价值自然就会被重新审视。

这也是为什么，我觉得 AI 带来的变化，不只是“做图更快了”，而是产品经理和设计师手里的交付物，正在发生变化。

以前我们说产品经理是上游角色，设计师也是上游角色。这个说法在过去很自然，因为他们交出去的东西，大多数时候是需求、原型、设计稿、说明文档。这些东西当然重要，但它们本质上还是“要交给别人继续做”的。

现在慢慢不一样了。

产品经理和设计师手里的东西，开始有机会直接变成页面，直接变成交互，直接变成能演示、能验证、能继续往前推的雏形。

以前你交的是一份说明。
现在你可能直接交出一个页面。

以前你交的是一套设计稿。
现在你可能直接交出一个能演示的交互原型。

以前你交的是流程图和逻辑说明。
现在你可能直接交出一个能跑起来的雏形。

这不是简单的提效。

它改变的是角色和产品之间的距离。

以前产品经理和设计师离产品本体总隔着一层，很多判断、很多想法、很多取舍，都要靠一轮轮传递去落地。今天这层距离在缩短。不是说以后谁都不需要工程师了，事情远没有这么简单。真正复杂的系统、稳定性、架构、性能、长期维护，这些依然是工程能力的核心价值。

但在“把一个想法更快变成可交付的东西”这件事上，产品经理和设计师确实第一次大规模拥有了更直接的手段。

这一点和过去非常不同。

所以我今天回头去看自己这些年的经历，会有一种线索被慢慢串起来的感觉。

二十年前用 HTML 做原型。
后来用 Vue.js 做原型。
再后来参与 Orang 这种低代码平台，去碰架构、DSL、组件库、Blockly，后面连 AI 也加进来了。

一路走下来，我其实一直都在朝一个方向靠：让原型离真实产品更近一点，再近一点。

以前这个方向更多只是少数人的工作习惯。
今天 AI 让它开始变成一种有机会被更多人采用的方法。

这也是为什么，我现在越来越觉得，原型这件事本身也该重新理解一下。

原型不是拿来过渡一下的。
很多时候，它本来就应该是产品的起点。
它不一定非要停在一张图、一份稿、一个中间态里。它完全可以继续长，继续接近真实系统，直到变成产品的一部分。

当这件事真的开始发生之后，大家的价值判断也会慢慢变。

写代码会越来越快。
把页面搭出来会越来越便宜。
把一个功能雏形做出来，也会越来越容易。

真正拉开差距的，反而会重新回到那些更上层、也更本质的东西上：

你有没有理解用户。
你有没有判断市场的能力。
你能不能把混乱的需求收束成一个成立的结构。
你能不能看出哪些是核心，哪些只是噪音。
你能不能把一个模糊的想法推进到能验证、能交付、能继续迭代的状态。

这些东西，过去很重要。
到了今天，价值只会更高。

所以我现在再看那些层出不穷的 AI 设计工具，心里已经没有太大波澜了。

不是因为我觉得它们不聪明，也不是因为我看不到它们在某些场景里的价值。

只是对产品 UI 这个层面来说，我越来越觉得，问题已经不在于“用哪一个工具把中间态做得更好”，而在于这层中间态本身，正在慢慢失去过去那种理所当然的地位。

真正值得关注的，不是谁又做了一个更像 Figma 的东西。

真正值得关注的，是工作流已经开始变了。

而一旦工作流变了，产品经理和设计师，也就不再只是上游交付文档和稿件的人了。

他们开始有机会直接交付产品的一部分。

最近一段时间，有不少朋友来问我一个问题：

小龙虾到底是什么？

有人觉得它是新的 AI 助手，有人觉得它是自动化工具，还有人觉得它是某种“更强的 ChatGPT”。

有意思的是，每个人问这个问题的时候，其实都带着不同的理解。

有人问：

• 小龙虾是不是比 Claude 更强？
  
• 用小龙虾是不是就不用写提示词了？
  
• 小龙虾是不是可以替代 ChatGPT？

聊了几次之后我慢慢意识到一件事：

很多人其实分不清三种完全不同的 AI。

比如：

• ChatGPT / Claude / 豆包
  
• n8n 这样的自动化工具
  
• 最近很火的 OpenClaw（大家习惯叫它“小龙虾”）

在很多人的理解里，这些其实都是同一种东西：

AI。

但如果你真的用过一段时间，就会发现它们之间的差别，其实非常大。

甚至可以说，它们代表的是 三种完全不同的 AI 使用方式。

而理解这一点，其实比学会几个提示词更重要。

第一种 AI：聊天

现在大多数人接触 AI，基本都是从聊天开始的。

打开一个 App，比如 ChatGPT 或 Claude，然后输入一句话：

帮我写一段文案
帮我总结这篇文章
帮我翻译这段话

AI 给出回答，任务完成。

即使现在很多聊天 AI 已经支持了更多能力，比如：

• 上传图片
  
• 分析文件
  
• 生成表格
  
• 执行一些代码

但它的核心形态其实没有改变：

输入问题 → 输出答案。

所以有一句话其实很值得想一想：

今天大多数人以为自己在用 AI，其实只是在用一个“会聊天的软件”。

你能做什么，很大程度取决于：

这个 AI App 的开发者给你做了哪些功能。

在这种模式下，AI 更像是一个能力越来越强的搜索框。

第二种 AI：流程

如果再往前走一步，就会遇到另一类工具，比如：

• n8n
  
• Zapier
  
• Dify

这类工具解决的问题不是聊天，而是：

自动化流程。

举一个很简单的例子。

如果我要写一篇文章，通常需要几个步骤：

1. 收集素材
   
2. 整理文章框架
   
3. 填充内容
   
4. 修改润色
   
5. 发布到平台

在聊天 AI 里，这些事情通常需要你一条条去提示。

而在工作流工具中，这些步骤可以被设计成一个流程，让系统自动执行。

例如：

1
2
3
4
5
6
7

收集信息
↓
AI整理结构
↓
AI生成文章
↓
自动发布

AI 在这里通常只是其中一个节点，比如：

• 用 AI 总结资料
  
• 用 AI 写文章草稿

这种方式确实能提高效率，但它也有一个明显的限制：

所有流程都必须提前定义好。

如果你没有设计某个流程，系统就不会自己去执行它。

第三种 AI：Agent

小龙虾（OpenClaw）代表的是第三种形态：AI Agent。

和聊天 AI 不同，它不只是回答问题；
和工作流工具不同，它也不是完全固定的流程。

它更像是一个：

可以自己规划任务并调用工具的 AI 代理。

例如你给它一个目标：

帮我写一篇博客并发布。

理论上它可以自己完成：

• 收集资料
  
• 整理结构
  
• 写文章
  
• 修改
  
• 发布

AI 不只是生成内容，而是开始 执行任务。

这也是为什么很多人第一次看到 Agent 系统时，会觉得非常震撼。

因为 AI 似乎终于从聊天框里“爬出来”了。

但在我看来，小龙虾现在更像一个玩具

虽然 Agent 的概念非常吸引人，但如果从现实使用角度来看，我个人的判断其实很简单：

现在的小龙虾更像是一个玩具。

这并不是说它没有价值，而是因为整个生态还非常早期。

很多能力：

• 不稳定
  
• 需要大量配置
  
• 依赖各种插件

如果你只是想完成实际工作，很多时候用普通 AI 反而更简单。

但这并不影响它的重要性。

因为小龙虾真正有价值的地方，不在于它今天能做什么，而在于：

它展示了一种新的 AI 使用方式。

你的小龙虾和我的小龙虾不是一个小龙虾

很多人会把小龙虾理解成一个软件，就像 ChatGPT 一样。

但其实并不是这样。

你的小龙虾和我的小龙虾，很可能不是同一个小龙虾。

因为 Agent 的能力其实来自三个层面。

第一层：操作系统

如果你的小龙虾运行在 Mac 上，它可以：

• 添加日历提醒
  
• 打开 Apple Music
  
• 操作本地文件
  
• 打开浏览器

如果它运行在 Linux 上，能力可能就完全不同。

因为系统环境不同。

第二层：模型

Agent 本身并不包含模型。

你可以接入不同的大模型，比如：

• Claude
  
• GPT
  
• DeepSeek

不同模型之间的能力差异会非常明显。

例如有的模型支持多模态：

• 能听声音
  
• 能看图片
  
• 能生成语音

有的模型则只能处理文本。

所以：

模型不同，小龙虾的能力也会完全不同。

第三层：工具

Agent 还可以连接各种工具，例如：

• 浏览器
  
• API
  
• 自动化脚本
  
• 本地软件

这其实有点像：

给 AI 安装应用程序。

插件不同，它的能力也会完全不同。

所以才会有一个很有意思的现象：

你的小龙虾和我的小龙虾，其实不是同一个小龙虾。

AI 的 Android 时刻

如果一定要找一个类比，我觉得小龙虾更像是 早期的 Android。

Android 刚出现的时候：

• 系统不稳定
  
• 生态不成熟
  
• 看起来更像技术爱好者的玩具

但 Android 带来了一个重要变化：

手机不再只是一个应用，而是一个平台。

小龙虾其实也一样。

你可以：

• 换模型
  
• 加插件
  
• 接系统
  
• 扩展能力

AI 不再只是一个聊天应用，而可能逐渐变成一种新的 计算平台。

AI 不只是聊天

很多企业现在都会问一个问题：

“我们公司应该怎么用 AI？”

但在我看来，今天真正需要思考的其实不是：

• 用哪个 AI
  
• 用哪个模型

而是：

自己的工作流程里，哪些地方可以被 AI 重新设计。

因为 AI 的价值往往不在于：

回答问题。

而在于：

改变工作的方式。

也许几年之后回头看，我们会发现今天很多变化，其实都是从这些看起来像“玩具”的系统开始的。

最近我在读《认知革命》。

但说是“读”，其实已经不是那种很传统的读法了。现在有了 AI，我会把书丢进 NotebookLM，让它帮我整理内容、提炼结构，甚至直接生成一段像播客一样的对话音频。这样一来，我走路时能听，洗漱时能听，哪怕没有正经坐在书桌前，也会有一种“我正在接触这本书”的感觉。

老实说，这种体验我并不排斥。我甚至觉得它挺好。它轻松、方便，也确实适合今天这种总被切碎的生活节奏。比起一本书买回来之后一直躺着不动，这当然更进一步。问题是，我最近越来越在意：这种“好”，到底是哪一种好？

AI 确实让一本书更容易入口

这一点我不想假装看不见。

AI 最厉害的地方，就是它会把一本书变得更容易靠近。原本陌生、缓慢、需要耐心进入的内容，会被整理得更顺，更轻，也更像今天的日常信息流。我之前还专门写过一篇文章聊 AI 生成播客，那种“一句话就把文字变成可听内容”的新鲜感，到现在我也还是承认。

如果只是从“让我愿意开始接触一本书”这个角度看，AI 的确帮了我很多。它像一个入口，也像一个陪伴者，让阅读不再那么有门槛。

但这种“好”，未必等于真的读过

问题也恰恰出在这里。

我听 AI 生成的读书播客时，常常会有一种很舒服的感觉：内容流畅，重点清楚，理解成本很低，甚至会让我误以为自己已经“掌握”了这本书。但等我真的翻开《认知革命》去读时，我很快就会发现，两者根本不是一回事。

前者更像是我“经过”了这本书，后者才像是我真的走进了它。

AI 帮我处理过的内容，通常已经被压缩、被整理、被提前解释过了。它给我的，是一个更适合接收的版本。这个版本当然更友好，但它也很容易制造一种错觉：我好像已经懂了。可真到自己面对原文时，很多东西其实并没有真正进入脑子，更谈不上和我的经验、判断发生连接。

从这个角度看，它很像一种更高级的“短视频化”。形式变成了播客，语气变得更自然，甚至更像真人聊天，但底层逻辑还是一样的：更快接收，更轻松理解，更低成本地拿到结论。

阅读真正重要的，往往就是那些不顺的地方

《认知革命》让我重新意识到，读书最麻烦的部分，可能恰恰也是它最有价值的部分。

真正的阅读，不只是接收信息，也不只是记住几个观点。它要求我跟着作者的逻辑一点点往前走，在某些地方停下来，在某些地方怀疑，在某些地方回头重看。很多时候，最后真正留下来的，不是一个结论，而是我曾经怎样被迫参与过那个思考过程。

而 AI 摘要、讲书、读书播客最难替代的，偏偏就是这个过程。

因为它们天然都在替我“处理”那本书。原本曲折展开的内容，会被拉直；原本需要耐心铺垫的部分，会被提前总结；原本那些看起来不够高效的停顿、绕路和迟疑，也会被顺手抹平。

可阅读很多时候不是输送，而是摩擦。正是那些不顺、费劲、甚至让我想分心的时刻，才逼着我真的把注意力放进去。

如果长期只接收处理后的内容，交出去的可能不只是阅读

我最近越来越担心的，也不只是“自己还能不能静下来看书”。

更深一层的问题是，如果我越来越习惯别人先替我消化内容、提炼重点、给出判断，我是不是也会慢慢失去直接面对复杂问题的耐心？

书读不进去，长文看不下去，复杂一点的论证嫌慢，稍微绕一点的表达就想直接看结论。久而久之，一个人就会越来越依赖那些已经被加工好的版本。别人怎么总结，我就怎么理解；别人怎么判断，我就怎么接受。

这种状态很省力，但也很危险。危险不只是“人变懒了”，而是判断力会在一种几乎无痛的过程里慢慢外包出去。我们会以为自己只是在追求效率，只是在适应新的工具，但如果所有内容都必须先经过别人处理，我也就越来越不习惯自己走那段麻烦的路了。

而那段路，原本就是思考本身。

我不会停用 AI，但有些步骤还是得自己来

所以我现在的想法，不是拒绝 AI，也不是回到一种很古典、很纯粹的阅读姿态。说实话，我也做不到。我还是会继续用 NotebookLM，还是会听 AI 播客，还是会看摘要和整理。这些工具已经很自然地进入了我的生活。

但我开始更清楚地把它们放回它们该在的位置：它们适合做入口，做陪伴，做激发兴趣的第一步，却不该轻易冒充“阅读已经完成”这件事本身。

真正重要的部分，可能还是不能省掉。

我还是得自己翻页，自己停下来，自己去和那些不那么顺滑的内容待一会儿。哪怕很慢，哪怕并不轻松，哪怕它一点都不像 AI 生成的内容那样体贴、高效、现代。

因为只有这样，我才会觉得，最后留下来的东西真正属于我。

那不只是一本书读没读完的问题。

也是我有没有把理解世界的主动权，继续握在自己手里。

这几天我完成了一件拖了很久的事：把自己的 Hexo 博客改成双语站点。

但真正让我想清楚的，不是配置怎么写，而是一个更本质的问题：多语言站点的核心不是翻译，而是架构分离。

在改造过程中，我逐渐把问题拆成了三个层级。这也是我这次最大的收获。

一、多语言博客的三层模型

在实践之前，我犯的第一个错误，是把“界面多语言”和“内容多语言”混为一谈。实际上，它们是三层不同的机制。

第一层是界面层（UI 文案），包括菜单、按钮、分页、提示语。这是主题层解决的问题，它只负责两件事：语言切换、文案映射。它不负责内容隔离。

第二层是路由层（URL 结构）。URL 决定语言空间是否被真正隔离。我的设计原则是：默认语言（中文）保持原有 URL 结构；英文内容统一走 /en/...；同一篇文章通过 id 关联；使用 lang 字段区分语言版本。这一层决定的是语言是否成为“路径维度”，而不是“分类维度”。分类只是内容标签，语言必须是路由结构。

第三层是内容层（列表与统计），也是最容易被忽略的一层。默认情况下，首页、归档、分类页、标签页往往会混合所有语言文章。所以我做了三件事：一是自定义生成器，按 lang 过滤列表页；二是分类和标签总览页增加 helper 过滤；三是切换语言时增加兜底逻辑，避免 404。核心原则很简单：当前语言环境，只展示对应语言内容。

二、我踩过的典型误区

第一个误区是把语言当成分类。最初我以为给文章加一个 English 分类即可，后来发现这条路天然不成立。分类是内容属性，不是语言维度。语言必须进入路由层，才能形成稳定可维护的多语言结构。

第二个误区是追求一次性全站翻译。我最开始的心理压力来自“是不是必须一次翻完所有历史文章”。后来我改变了策略：先完成架构，再逐篇补充。语言架构先搭好，内容可以渐进式完善。

三、技术改动概览

我这次的改动可以归纳为四组：

1. Hexo 层：配置 zh-CN + en，修改 permalink 加入语言段，使用统一 id + lang 管理版本。
2. NexT 主题层：启用 language_switcher，补齐自定义语言映射。
3. 内容生成层：自定义 generator 过滤列表页，helper 处理分类与标签统计，body-end 增加语言切换 fallback。
4. 细节修复：修复语言下拉宽度异常，修复移动端表格溢出。

四、AI 在这次改造中的角色

AI 在这件事里的价值，不是“自动写完代码”，而是帮我快速定位问题边界、验证假设、提供实现方向、减少试错时间。最终的架构选择和取舍，仍然由我决定，但效率显著提升。

五、我现在的双语策略

我给自己定下三个规则：第一，先确保界面多语言稳定；第二，内容按价值逐步补英文；第三，用统一 id + lang 管理版本。双语站点不是一个按钮，而是一套清晰的内容管理策略。

六、一个更大的认知收获

这次改造让我意识到，多语言问题本质是信息结构问题。当结构清晰后，翻译变得可控，内容扩展变得自然，维护成本也可预期。

接下来，我会逐步把更有代表性的历史文章补成英文版本，让英文区从“可用”慢慢走向“好用”。

Every time I take a city bus, a very simple question pops into my head: why do city buses not have seat belts?

My intuition is straightforward. City buses have short distances between stops, usually run at lower speeds, and involve frequent boarding and alighting. If everyone had to buckle up, then buckle off at every stop, that whole sequence would slow operations down a lot. More practically, city buses are designed with standing areas. If seated passengers must wear seat belts, what about standing passengers? To fully resolve that contradiction, we would have to remove standing areas, and that would fundamentally change the bus's capacity model.

During this year's Spring Festival period, I happened to take a longer-distance bus route in my hometown, running from the city center to suburban areas. The vehicle looked like a standard coach bus. Every seat had a belt, and passengers were clearly required to sit one person per seat, with no standing allowed. At that moment, the issue became much clearer to me: the key is not a standalone technology choice, but the operating scenario.

Later, I looked up more information, and this judgment broadly holds. The Dutch road safety research institute SWOV, when explaining why seat belts are not mandatory on public transport, highlights two practical reasons. First, frequent stops and high passenger turnover make mandatory seat-belt use hard to enforce. Second, once seat belts are mandatory, standing passengers are effectively incompatible, while standing areas are central to city bus capacity design. That almost directly confirms my original intuition: seat belts would reshape the entire operating logic.

Regulations reflect the same classification logic. China's Motor Vehicle Running Safety Technical Conditions (GB 7258) distinguishes vehicle types by usage and passenger organization. For highway coaches, tourist coaches, or public buses without standing areas, seat belts are generally required for seats. For urban buses that allow standing passengers, different requirements apply. In other words, the standard itself recognizes that a standing-allowed city bus and a fully seated coach are fundamentally different types of transport.

The same pattern appears in long-distance operations. China's Safety Technical Conditions for Commercial Buses (JT/T 1094-2016) requires all seats on commercial buses to be equipped with compliant seat belts. These vehicles usually run on highways or longer routes, do not allow standing, and assign one seat per passenger. Under those conditions, the risk focus shifts from "falling during sudden braking" to "being thrown from the seat in collisions or rollovers." U.S. transportation authorities have emphasized similar logic in seat-belt promotion for over-the-road buses: severe outcomes in high-speed crashes make seat belts especially valuable in reducing casualties.

When I put these two scenarios side by side, the difference becomes clear. City buses prioritize high turnover and convenient boarding, with built-in standing capacity and low-to-medium speeds over short trips. Their risk profile is more about sudden braking, crowding, and falls. Long-distance or high-speed passenger transport, by contrast, is built around keeping each passenger fixed in a seat to reduce secondary injury risk in serious crashes. No standing is allowed, seating is fixed, speeds are higher, and routes are longer, so the value of seat belts becomes much more direct.

So I now see this less as a simple "useful or useless" question, and more as a system-level tradeoff. Safety equipment is never isolated. It is always embedded in a concrete usage context. City buses and long-distance coaches may both be called "buses," but in practice they solve two very different problems.

This is my first English blog. Despite having studied English for several years in school, I still consider myself a beginner in learning the language. Sometimes, I feel confident in my English skills, such as when reading technical documents. But at other times, I become discouraged when I have to speak English during an interview or conversation with a native speaker.

I aim to improve my English proficiency. I want to broaden my perspective and connect with people who speak English, as I believe it will open up new opportunities for me.

To this end, I plan to update this blog once a month, or possibly even once a week. I would be grateful for your help in improving my English, and I welcome any suggestions you may have. Perhaps we share similar interests and can engage in interesting discussions.

In my next blog, I will introduce myself and share more about myself. If you're interested, please reach out to me.

Writing this blog has been a challenging experience for me, and I feel that it may be too short. However, I am hopeful that my writing will improve in the future. I look forward to that day.

每次坐城市公交，我都会冒出一个很朴素的问题，为什么公交车没有安全带？

我的直觉很简单。城市公交站点距离短，车速通常不高，乘客上下车非常频繁。如果每个人都要系安全带，上车、坐下、解开、下车这一整套动作会明显拉低效率。更现实的是，公交车本来就有站立区。坐着的人如果必须系安全带，站着的人怎么办？如果要彻底解决这个矛盾，就只能取消站立区，整辆车的运力结构也会跟着改变。

今年春节期间，我偶然在老家坐上了一辆从城市到城郊的长途公交。车型像标准大巴，每个座位都有安全带，现场也明确要求一人一座，不允许站立。那一刻我才把问题想透，有没有安全带，核心在运营场景，不在某个孤立技术点。

后来我查了一些资料，这个判断基本能站住脚。荷兰交通安全研究机构 SWOV 在解释“为什么公共交通工具上不强制使用安全带”时，提到两个核心现实。第一，公共交通频繁停靠、上下客频繁，强制系带很难执行。第二，一旦强制系带，就意味着不能允许站立乘客，而城市公交的运力设计本来就依赖站立区。这几乎直接验证了我最初的猜测，安全带会牵动整套运营逻辑。

法规层面也有同样的分型思路。中国《机动车运行安全技术条件》（GB 7258）会按车辆用途与乘客组织方式做区分。像公路客车、旅游客车，或者未设置乘客站立区的公共汽车，座椅通常需要配备安全带。允许站立的城市公交，则在安全带配置上采用不同要求。标准本身就在说一件事，允许站立的公交和“所有人固定在座位上”的客车，本质上是两类交通工具。

再看长途客运车辆。《营运客车安全技术条件》（JT/T 1094-2016）明确要求营运客车所有座椅应配备符合标准的安全带。这类车辆常见于高速或长距离线路，不允许站立，一人一座。在这种工况里，风险重点从“急刹时跌倒”转向“碰撞或侧翻时被甩出座位”。美国交通部门在推广长途客车安全带时，也强调过类似逻辑，高速事故虽然不一定高频，但一旦发生后果更重，安全带对降低伤亡有明确价值。

把两种场景放在一起看，差异就很清楚了。城市公交追求的是高周转和便捷上下客，它默认有站立乘客，也默认短距离、低到中速运行，风险更偏向急刹和拥挤导致的跌倒。长途或高速客运追求的则是把每位乘客固定在座位上，尽量降低高速事故下的二次伤害风险。它不允许站立，座位固定分配，速度和里程也更高，安全带收益就非常直接。

所以我现在更愿意把这个问题理解成一次系统权衡，而非一句“有用”或“没用”。安全配置从来不是孤立零件，它总是嵌在具体场景里。城市公交和长途客运看起来都叫“公交车”，但它们在解决的，其实是两套完全不同的问题。

今年过年回镇江，我照例去了西津渡。

下午一点左右到的。这个时间既不是早饭也不是正经的午饭时间，但李嫂面店里已经坐满了人。没有排队，不过几乎没有空桌。负责点单的是一个年轻人，看起来像是老板的儿女。几年前我来时，是一位年纪稍大的女性在店里张罗。

我点了长鱼面。长鱼就是黄鳝。浇头处理得不错，没有腥味，切段整齐，口感也嫩。面里除了长鱼就是豆芽，没有多余配料。

面端上来时，汤色就能看出状态。不是清亮的那种汤，而是发浑、发黏，像是淀粉挂了一层薄糊。第一口下去，汤体明显偏稠。那种稠不是熬出来的厚重，更像是煮面水反复使用后的黏滞感。喝几口之后，我喉咙有点不舒服。

长鱼我吃完了，味道没有问题。豆芽也还可以。但面条泡在汤里越吃越黏，后半碗实在难以下咽，最后剩下了。

走出店门时，店里还是满的。

进店之前，我在西津渡恒顺专卖店里买了三瓶香醋可乐，塑料瓶装，常温的。老婆说带回去给孩子尝尝，我就在街边先开了一瓶。

气味一出来，醋味就很明显。入口之后，酸味压着甜味，碳酸的刺激感并不突出。后味拖得很长，有点像咳嗽糖浆。不是单纯难喝，而是不太协调。我喝完了一瓶。回家之后，孩子把另一瓶喝完了。现在年已经过完，家里还剩一瓶。如果是普通可乐，估计早就喝光了。

除夕中午，我们去镇江的全聚德吃饭。十一点到，因为提前预约，没有等位，坐的是大厅位置。

冷菜点了鸭舌、芥末鸭掌、冰糖葫芦、驴打滚和豌豆黄；热菜有烤鸭、松鼠鳜鱼、咖喱蟹、贝勒爷烤肉和白灼菜心。点菜时服务员提醒咖喱蟹是冰冻蟹，不是新鲜蟹。等菜的时候还送了抽签饼干。

烤鸭片得很好，鸭皮完整，颜色油亮，入口酥脆，技术没有问题。油脂很厚，香气集中。只是吃到后面，鸭皮本身的油脂感比较重。现在大家年纪都上来了，对这种糖油混合物的接受度比以前低一些。

南京烤鸭和北京烤鸭本来就是不同的品种。南京的更偏卤香，肉更湿润；北京烤鸭的皮更脆，油脂更集中。谈不上哪种更好，只是习惯不同。

四个人吃完出来时，门口已经有人在等位。

这次回镇江，吃的几样东西都谈不上惊喜。面店还在，恒顺的醋还在，全聚德的服务也还在。只是具体吃到嘴里的感觉，比记忆里清晰一些。

就这样。

最近在翻旧文章的时候，我突然有一个念头。

这些年我写了不少东西。有些是当时的记录，有些是折腾，也有些是认真写给未来的自己。

但有一件事我一直不知道。你是怎么走到这里的？

是某一次偶然的搜索？ 某个朋友的转发？ 在阅读器里滑到的？ 还是在某个聚合站里看到标题点进来的？

有时候我会想象屏幕那一头的人。也许你已经看了很多年，只是很少留言。也许你是第一次点进来，甚至还不确定会不会再来。

我其实有点好奇。

如果你愿意，留一句话告诉我就好。不用很完整，也不用很正式。

你可以随便写几行，比如下面三件事。

• 你是老读者还是新读者
• 你第一次是从哪里发现我的博客的
• 你现在通常怎么回到我这里

第一次的入口大概就那几类。搜索引擎、朋友或社交平台、某个具体网站的推荐、阅读器订阅、VXNA 之类的聚合。

如果你还记得当时的关键词、网站名字、阅读器名字，也可以顺手写一下。我会很感谢。

有时候我会觉得，博客这种东西很奇妙。它不像社交平台那样喧闹，但也不会完全消失。

它更像一条很长的路。偶尔会有人走过来，停一下，然后继续走。

我只是想知道，你是从哪一个路口拐进来的。

⸻

顺带也交代一下我这边的阅读习惯。

Google Reader 关掉之后，我的阅读器也换过好几轮。更早些时候用过抓虾、鲜果，后来陆续用过 Reeder、Feedly、Folo。VXNA 我也会偶尔刷一眼。

现在我主要还是用 Reeder。它是付费软件，我已经买过了。不过 Reeder 只是客户端，我的订阅源还是放在 Feedly 上。

Folo 我用过一段时间，感觉挺不错。但总觉得他们团队内部可能出了些问题，所以我现在只是偶尔打开一下。说实话我也有点担心，哪天它也突然没了。

订阅的源我没认真数过，大概一百多个。这些年工具换了不少，但订阅这件事好像一直没变。

谢谢你读到这里。

春节前我开始试用 OpenClaw，前后折腾了差不多两周。

这段时间里我最大的收获，是我第一次比较清晰地体会到，OpenClaw 这类东西和 ChatGPT 在本质上确实不太一样。

ChatGPT 更像一个很聪明的“顾问”。它告诉我应该怎么做、帮我找信息、帮我写文字或写代码，但它通常不会替我把事做完。

OpenClaw 则更像一个“个人 AI 助手的雏形”。因为你可以把一台电脑的权限交给它，理论上你能在电脑上完成的事情，它也能替你完成。

当然，这个“理论上”后面有很多坑。于是这两周我给自己定了个小目标。我不看营销故事，只看它能不能在我这台 Mac mini 上把事做完。

因为我刷到的标题常常是这种风格。

• OpenClaw 帮我维护 20 个网站，SEO 自动起飞，一个月赚了 20000 美金
• 我把电脑交给 OpenClaw，第二天醒来它已经把工作都做完了
• 不写一行代码，用 OpenClaw 搭了个 24 小时自动赚钱系统
• OpenClaw + XXX，日更简报自动发布，流量自己来
• 一个提示词让 OpenClaw 替我打工：从此再也不用加班
• 一个 AI 助手顶一个团队：个人助理时代来了

标题写得很热闹，我也会心动。但如果没有证据，我读完通常只会更焦虑，好像别人都在用 AI 捞钱，只有我还在写 TODO。耳听为虚，我准备亲手一探究竟。

第一天我干的事情很简单。我在 Mac mini 上把 OpenClaw 装起来，按照官方文档里的 pnpm 安装方式一步一步操作和配置。

装好之后就得配置模型。OpenClaw 的 token 消耗很猛，我那时就想把成本压下来。正好我有一个 Antigravity Pro 的账号。Antigravity 是 Google 推出的 AI 编程编辑器，我当时用它的 OAuth 授权方式接入模型。我一开始就选了 Opus。

前两天用下来，我对 Opus 的体感很明确。它做事干练，说完就干。用了两天之后突然提示模型需要 cooldown。我起初以为只是用量到了，等等就好。结果一直不可用，我才意识到事情没这么简单。回头一看，Antigravity 账号已经被封了。

原因我就不细写了，总之和我折腾反代之类的配置有关，踩到了 Google 的政策红线。教训也很直接。在成本压力下走“省钱捷径”，学费可能会用更贵的方式交。

后来我把模型切换成 Codex。Codex 的体感更磨磨叽叽一点，像是欲拒还迎。

模型这边先稳定下来之后，我把它接到 Telegram 机器人，然后给它发了一条很朴素的指令。

把我当前的电脑屏幕截屏给我。

它真的把截图发回来了。

听起来很小儿科，但那一刻我突然明白了。它做的是动作，截图就是结果。从那一秒开始，我才把它当成一种不同于聊天工具的东西。

兴奋感很快就被现实按住了。为了让它更像“真的能操作电脑”，我还装了 peekaboo 这类技能。peekaboo 的作用很直白。它可以通过截图理解界面，再用 macOS 辅助功能去点按钮、输入内容。但很快我就发现，UI 操作远比命令操作更消耗 token，也更脆。

这套链路的天花板不在“会不会点”，而在“会不会点歪”。只要 UI 有一点点变化，或者它识别错了一个控件，就可能出现各种微妙的失败。

所以我后来给自己的偏好很朴素。能用命令完成的，就尽量别让它点 UI；真要点，也把预期放低。它更多是在“帮我尝试”，很难做到“稳定代劳”。

接下来我做了一次更“硬核”的验证。我想看看它到底能不能把一条链路跑完。光在对话框里给我“看起来很对”的建议，对我来说不算。于是我让它定时抓取 Hacker News、GitHub Trends 和几个 remote job 平台，对内容做分析和总结，生成页面，并部署到 Vercel。最后的成果是一个小站，链接在 这里。

我更在意的是它能不能把整条流程跑完，这个站本身反而没那么重要。传统做法里，如果我自己用 Python 写抓取，第一步就得人工打开网页看结构，比如哪些页面特征是稳定的、分页怎么走、限流和反爬怎么处理。抓完之后还要写清洗和抽取规则，再把内容变成可读的摘要，最后才轮到渲染页面、部署、定时跑。光想到这串活，就已经够我拖上好几天了。

而这一次，它确实做到了。抓取、分析、编写代码、提交代码，都是它自己定时完成的。

它有没有让我“月入两万刀”？当然没有。我也从来不指望这种故事。

但它至少给了我一个足够实的证据。对我来说，这类个人 AI 助手，并不是只能停留在“聊一聊”或者“写写代码片段”。在一定条件下，它是可以把工作当成工作去做的。

然后我又想试试它能不能当“外置记忆”。为了避免主账号 A 被它误操作，我在这台 Mac mini 上用了 Apple 账号 B。我的设想很简单。我想让它把内容写进 B 的 Apple Notes，再用共享功能把 Notes 共享给 A，这样我在手机和电脑上都能看到。

Apple Notes 这条路“能走通”，但不够自动。我最典型的一次需求大概是这样。

复盘一下最近的聊天，把重要事件汇总成一个简报记录下来。

我等了很久，怎么也没在共享的 Apple Notes 里看到。后来我登录到这台 Mac mini 上，点开 Apple Notes 才发现，它没有写到 iCloud 的共享目录里，而是写在了本地的某个目录里——其他设备当然看不到。

更麻烦的是，它写完之后也不会“记得自己写过什么”。如果我希望它更新原来的内容，往往得先提醒它重新读一遍，才能勉强对上上下文。

我当时有点失望，因为我期待的是那种更省心的体验。我说“你帮我把 xxx 记录下来”，或者“把这两天聊到的 xxx 汇总一下更新原来的那份”，它就能自己找到正确的共享目录，写出对的内容，并且知道下一次该往哪更新。

但现实没那么省心。它更像一个“会写字的实习生”，你得反复告诉它文档在哪、格式是什么、更新规则是什么。

也许更现实的解法，是我应该专门让它做一个“记录用的 skill”。让它固定只往那个共享目录写，固定一套格式，每次更新前先读一遍旧内容再动笔。这样它就不需要我每次都从头提醒。

做完这些实践后，我把日更定时任务都关了。原来我每天会跑三类东西，科技新闻分析、GitHub trends 分析、remote job 分析。

原因很简单。我对这几个任务并没有实际需求，当时更多是想看看它能跑到哪一步。模型用量也很快要见顶了，我浅尝辄止之后就把这些定时任务停掉了。没必要为了“尝试”每天烧 token。

从理性角度看，科技新闻完全可以直接看别人已经做好的简报；GitHub trends 也有很多人会做分析；remote job 平台更是现成的信息源。我并不需要为这些“已经有人做得很好”的事情，再额外花一份钱让 OpenClaw 重新做一遍。

所以我现在的做法是，日更任务先关掉，特定场景需要它出手时再用它。

这里我想补一句。我把定时任务停掉，主要是我这段时间确实没什么值得它每天接管的需求。OpenClaw 在我测试的范围内是可用的。

相反，它已经给出了一个个人 AI 助手的雏形。AI 不仅仅局限在聊天和编写代码，它是可以延伸到“接管一台电脑、跑完一条流程”的。

目前它仍然受限于模型能力、响应速度、稳定性，以及最现实的成本，而不能达到我想象中的预期。

如果有一天这些限制被进一步推开，比如 token 不再敏感、权限边界更清晰、模型响应足够快、记忆足够可靠，那么类似的个人助理就可能从“我偶尔拿来用”变成“我日常真的离不开”。

到那时，AI 也许会更自然地进入那些更具体、更生活化的场景，比如用 IoT 控制设备、定时巡检摄像头、自动开窗、自动喂食、自动施肥……

我不知道那一天离现在还有多远，但这两周至少让我确认了一件事。这个方向不是营销故事，它确实有一条可以跑通的路。

前段时间我才写了 NAS 掉盘的折腾，紧接着打印机的墨盒也到期了。本来以为该消停几天，结果又轮到家里的 UPS 罢工，真是「屋漏偏逢连夜雨」。

这次出问题的是 山特 TGBOX 600。它平时就安安静静放在角落里，存在感不强；但一旦它不工作，心里就会很不踏实——尤其是有些设备我并不希望它突然断电。

最开始的表现是：长时间蜂鸣、亮红灯。我把它关机后再开机，灯又变成了 红绿灯交替闪烁，就是那种“你别指望我正常工作”的节奏。

我第一反应是不瞎猜，先去咨询山特的官方技术支持。对方的建议很明确：先在不开机的情况下充电 4–6 小时；如果还是不行，就按手册打开电池仓，看看电池有没有鼓包、漏液，坏了就换。

我按建议充了一段时间电，但后续情况并没有好转：UPS 依然 大约每 2 秒发出一次声音，听着特别烦，也让我基本确认这事大概率不是“充一充就好”。

最后我还是在拼多多（PDD）上给它下单买了一块新电池，决定直接更换。

如果你也准备自己动手，建议先断开市电和负载，按手册操作，避免短路或误触。

电池仓上其实有标识，提示了可以撬开的受力点：

换电池的过程里，最让我吐槽的是这个电池仓的卡扣设计：有点奇怪，纯粹是大力出奇迹。我对着标识朝着对应方向撬动，才把电池仓打开：

打开后，我把原来的电池拿出来：

新买的电池感觉印刷没有原来的清晰，也不知道真假：

换上新电池后，我顺手拍了一张没盖上电池仓盖子的照片，留个记录：

换好之后我让它充了一会儿电，UPS 终于 亮起了绿灯，算是恢复正常：

这次的结论其实挺朴素：遇到 UPS 蜂鸣红灯、重启红绿交替这类情况，按官方建议先充电，再按手册排查电池状态；如果充电无效，更换电池往往就是答案。

说到底，UPS 这种东西平时安安静静待在角落里；一旦开始蜂鸣报警，就会让人很焦虑。希望这次记录能在你遇到类似情况时，少走一点弯路。

最近给孩子打印的资料有点多，家里的打印机终于“不堪重负”罢工了。

当时的现象是：墨水灯、纸张灯、电源灯三个灯一起快速闪烁，按键也没反应。这两天还要继续打印资料，要是修不好，就得出门找打印店，这就有点麻烦了。

我翻了下 EPSON L220 的手册，故障说明大概是这样：

手册里说可能是扫描部分有问题，但我扫描台上什么都没放，而且以前也遇到过类似情况，所以我更怀疑是另一个常见原因：废墨垫计数满了，需要清零。

这事其实就两件事

后来我确认下来，这类问题大概率绕不开两步：

1. 物理处理：打开打印机后面的废墨仓，把里面的海绵（废墨垫）换新。淘宝上能买到配套海绵。
2. 软件清零：把打印机固件里「废墨垫计数」清零（不然它会一直以为“满了”）。

如果只做软件清零不换海绵，机器是能继续打，但废墨垫真的可能溢出来——我不想把家里搞成案发现场，所以两件事我都做了。

最大的麻烦：清零软件只有 Windows 版

一般修打印机的店里都有那个清零软件（常见叫法是 Adjustment Program 一类），但我手边只有 Mac。

我一开始的想法是“凑合用一下 Windows 就行”，于是找来我老婆很久没用的一台 Intel 的 MacBook Air，插上我很久以前做的 Win2Go U 盘，准备临时救个急。

结果 Win2Go 一登录就开始疯狂闪烁，Explorer 反复重启。我查了下，基本就是显卡驱动不兼容。进安全模式倒是不闪了，但安全模式下 压根识别不到打印机。我折腾了半天，还是没走通这条路。

最后我只好在自己的 MacBook M1 Pro 上装了 Parallels Desktop，在虚拟机里跑 Windows，才把清零软件跑起来。

清零步骤（我这次用的路径）

软件打开后，先选 Particular adjustment mode：

接着最关键的一步是 Port。

Port 要选到打印机对应的端口。我这里是 USB001。如果它一直显示 Auto，基本就意味着系统没识别到打印机——这种情况下你就算硬选了，后面也大概率连接失败。

进入后会看到一个列表，在 Maintenance 里找到 Waste ink pad counter：

勾选 Main pad count，先点右下角 Check，软件会读出当前计数和百分比。一般到这一步，数值都已经很接近上限了（很多人看到都是 95%+）。

然后点 Initialize 执行清零。清零后 point 会变成 0。

我做完清零、重启打印机，三灯闪烁的故障就消失了，打印也恢复正常。

更换废墨垫海绵（物理部分）

虽然清零后已经能用了，但我还是下单换了新的海绵，免得哪天真的溢出来。

更换不复杂，我大致按这个顺序做的：

找到 EPSON L220 背后的一颗螺丝，拧下来，然后把打印机立起来：

将底部向右推，就能打开废墨仓：

拿出旧的海绵，放入新的海绵，装回去，再把螺丝拧上：

写在最后

这次的结论很朴素：遇到三灯狂闪，别急着判死刑，先看看是不是废墨垫计数满了。
我折腾的过程挺绕，但好在最终解决了，打印机也算“续命成功”，孩子的资料也没耽误。

2025 年底，我们部门被裁撤。说不慌是假的，但日子还得往前过。

这段时间我把简历和作品重新整理了一遍，能投的都投，也托朋友帮忙留意。现实很直接：回音不多，合适的机会更少。

我写下这篇，是想简单说下我的近况：我在南京本地或远程寻找机会，也愿意接一些兼职/外包项目。你如果正好需要人手，欢迎联系我。

这段时间我在做什么

我一边找工作（南京本地或远程都可以），一边也在接兼职/外包：一个人能顶的活我自己来；如果你希望有人把产品、设计、研发一起串起来做完，我也可以拉上我们的小团队一起做。

我能做什么（个人）

我这些年主要做产品/设计/前端相关的事。我不太擅长“自我包装”，但我愿意把事情做扎实，尽量少让你来回折腾：

• 把需求聊清楚：要做什么、不做什么
• 画原型、整理页面与交互细节
• 前端页面实现、接口联调，跟到能上线
• 上线后继续改，直到好用为止

如果你需要更具体的经历与作品，我可以单独发你。

我们的小团队能做什么

最近我和几位老同事组了一个兼职小团队：产品、UI、前端、后端都有，配合很顺。适合做这些事：

• App / H5：先把核心流程做出来，尽快上线跑起来
• 企业中后台：权限、表单、流程、数据看板等常见需求
• 微信小程序：业务工具、活动页、小型应用
• 自动化与工作流：Coze、n8n、Dify，把重复的流程跑起来（比如表单 → 审批 → 通知 → 入库/同步）

如果你现在就差人把某个模块补齐、把上线前的坑填完，也可以找我，我们可以先从一个小目标开始。

地点与合作方式

• 地点：南京优先；远程也没问题
• 方式：兼职协作 / 项目外包

联系我

有合适机会的话，留言或邮件联系皆可：hello@tortorse.com。
评论区留言我也会尽快回复。

谢谢你愿意读到这里。

这块希捷酷狼硬盘的 SMART 错误，可能已经发生一周了，但我一直没发现。

直到这两天，照片备份开始出问题，我才意识到不对劲，跑去 QNAP 后台看了一眼：SMART 警告明晃晃地挂在那里。

而且第一次我看到报错的时候，它其实还能读。我当时没太当回事，也没立刻把数据拷出来，心里还在自我安慰：也许只是“提醒一下”，不至于这么快就出大事。

后来我做了什么：查坏道、重启，然后它直接掉盘

我当时的思路很简单：先让 NAS 查找坏道，看看能不能确认问题到底有多严重。

结果它查了半天也没反应，我就开始重启、再重启，想着“重启一下可能就好了”。

最后的结果也很直观：硬盘直接掉盘，状态变成 disconnect。

那一刻我终于确认了一件事：这已经不是“排查”了，这是“救援”。

我去问 ChatGPT：要不要拔盘？能不能接 Mac 读？

如果是以前，我大概率会在网上搜很久：搜 SMART 报错、搜 QNAP 掉盘、搜 macOS 怎么挂载……信息肯定很多，但最后未必能帮我做出决策。

这次我直接把情况一股脑丢给 ChatGPT，问它两件事：

1. 我应该把它从 NAS 里取下来吗？
   
2. 我有一个 HDD 硬盘读取器，能不能把它接到 Mac 上读数据？

它的建议很明确：先断电拔盘，别再让它在 NAS 里反复上电掉线；可以接 Mac 试读，但尽量减少对源盘的写入和折腾。

我照做了：NAS 断电，把硬盘取下来，接上读取器，再插到 Mac 上。

Mac 看得到盘，但分区表已经丢了

很遗憾，macOS 读不出硬盘内容，还弹了警告提示。

我按 ChatGPT 的提示跑了 diskutil list，确实能看到硬盘本体，但分区表已经丢失——你知道它在那，但系统不知道该怎么走进去。

它接着建议我用 ddrescue 把硬盘里的数据先导到另外一个地方。我当时理解它的核心意思就是：先把“还能读到的东西”抓出来，后面的恢复尽量在副本上做。

ddrescue 卡在现实：我没有 4TB 的落脚地

硬盘是 4TB，但我的 Mac 只有 87GB 空间，手头那块移动硬盘也只有 380GB，不够。

在“没地方放镜像”的前提下，我按 ChatGPT 的建议又尝试了 testdisk 和 photorec，但不是没起作用，就是恢复出来的东西太难整理。折腾了一圈，我选择先停下来。

价格再补一刀，但我的决定是：先缓缓

我去京东查硬盘价格，不查不知道，一查吓一跳：

• 我几年前买的 4TB 硬盘 800 多，现在涨到快 1000
• 我买的移动硬盘 400 多，现在也涨到 800 多

于是我又问 ChatGPT：为什么硬盘涨价？有没有机会降？

它的解释大意是 AI 的冷存储需求在增长、HDD 厂商高度集中、再叠加产能和供需因素，价格就被推上去了；至于回落，它的结论是：短期（比如 1～3 个月）基本别指望。

最后我的决定是：硬盘购置也暂缓。毕竟现在经济不好，旧盘里的东西我也不急着用，我先把这块盘离线放好，等我真的需要它的时候，再按“先找落脚地 → 再用 ddrescue → 必要时上新盘/找专业恢复”的路线走。

ChatGPT 没有把我的硬盘救活，但它给了我一颗定心丸：不用在网上翻一晚上也不一定有结论，我至少知道接下来该怎么做、先做什么、别做什么。

虽然身在南京，但红山动物园我去得并不算多。它在我记忆里一直有点复杂：既熟悉，又带着一点说不清的别扭。

十多年前：山坡上的小笼子

我依稀记得十多年前去红山的时候，老虎还被关在山坡上的小笼子里。它在笼子里来回踱步，步子不大，却走得很执拗。我当时说不出什么道理，只觉得心里莫名不适——那种不适不是「不好看」，而更像是「不应该这样」。

后来很长一段时间，我都没有再去。

疫情期间：因为一句“报复性游园”

疫情期间，我看到了沈园长的一席演讲，里面提到“报复性游园”。那一刻我突然被触动：如果一个动物园努力在做更难、但更对的事，那我至少应该去看看，也顺便把自己的偏见更新一下。

那次再去红山，我确实感受到它变了很多。后来听说红山一度经营困难，孩子班级的同学们还专门联系红山动物园组织了一次认养活动，我们认养了东北虎「奇妙」。

这种「认养」对我来说不只是捐一笔钱，更像是一种参与感：我不是站在围栏外评判它好不好，而是愿意为它变好出一份力。

一本书和一只下山的东北虎

这期间我还买了一本花蚀老师编写的《逛动物园是件正经事》，书里盛赞了红山动物园。读的时候我其实半信半疑：文字可以很动人，但动物过得怎么样，还是得看现场。

后来我再次到红山，看到一只东北虎从山头一步步下山的场景，真的令人震撼，也令人宽慰。那种感觉很难形容：你会突然意识到，它不是被摆在你眼前的「展品」，而是有自己节奏、有自己路径的生命。相比多年前笼子里来回踱步的景象，这已经是完全不同的世界。

我也去了书里提到的狼谷。看到群狼嬉戏的样子，我再次感到那种巨大的差异：原来蜷在笼子一角的沉默，和现在奔跑、互动的活力，是完全两种气息。

今年夏天：没看到大猩猩，却看到了更多变化

今年夏天我听说红山从荷兰引进了大猩猩，就兴冲冲赶去了。问了门口的志愿者才知道，大猩猩刚到，场馆还没有建好。那一瞬间我当然有点小失望，但很快又被另一种情绪盖过去：距离上一次游红山又过了几年，它又在悄悄变。

一只白面僧面猴「杜杜」早成了网红，红山的游客也早就人山人海了。我最喜欢的还是冈瓦纳区：那里的丰容很棒，即便有些场馆是在室内，但地面材质、温度、植被，都让我有种身处雨林的错觉。

地面奔跑的小犰狳是我最喜欢的。

躲在落叶里的陆龟也很漂亮。

一点多虑：角落里的红猩猩

大猩猩没看到，我就去看了黑猩猩和红猩猩。有只叫乌豆的黑猩猩没有合群，独自在一个房间里。隔着玻璃我也能感到它很聪明，而且很享受玩床单的过程——那种专注，反而让我停下来多看了一会儿。

红猩猩的室内场馆不大。它背对着玻璃坐在房间的一角，我当时忍不住想：它是不是因为空间太小而不开心？甚至还冒出一个念头：要不要给红山捐些钱，帮着改造一下红猩猩的居住环境。

结果我一出来才发现，外面有很大一片场地，树上还有两只红猩猩幼崽在玩耍。那一刻我有点尴尬，也有点释然：纯粹是我多虑了。我被自己的第一眼牵着走，却忘了先把整个空间看完整。

前阵日子，新的非洲区落成了，四只大猩猩也安顿了下来。等我再得空，一定要再去一次——不是为了集齐「看过哪些动物」，而是想再确认一次：这个城市里，有一个地方在努力让动物过得更像动物，而我也愿意用自己的目光和脚步，继续见证它的变化。

今天早上我突然意识到：很多焦虑并不是事情本身有多严重，而是我脑子里那团没被理清楚的「如果……怎么办」在疯狂增殖。只要我肯停下来认真想一想，焦虑往往就会松开一点。

忘带药之后，我差点开始埋怨

早上出门时我发现血脂康没带。本来我是记得的，还在心里提醒自己：先拿牛奶，等会儿再拿药。结果刚好邻居也出门，我老婆又催着赶紧上电梯，我一慌就把这事忘了。送完孩子之后才想起来，心里一下子就紧了：怎么这么大人了还会忘？今天要是没吃会不会有影响？要不要回去拿？会不会耽误工作？

我第一反应其实是想埋怨：要不是被催、要不是赶电梯、要不是……但这个念头刚冒出来，我自己也觉得有点好笑——我到底是在解决问题，还是在给焦虑加码？

我就逼着自己做了一个很简单的动作：把事拆开，问清楚三个问题。

第一，最坏会怎样？少吃一顿，真的会立刻出大事吗？冷静下来想，其实不太可能。

第二，能不能补救？当然能。回家补上也行，不回家也可以今天再买一盒，甚至直接外卖送到家。

第三，我现在要做什么？答案很明确：别在路上自责，先把今天的安排按部就班做完，必要的话下单买药就行了。

那一刻我的情绪就明显往下掉了一格。不是因为我变得更「自律」了，而是因为我把一个模糊的恐惧，变成了可操作的几件小事。焦虑最怕的就是「不确定」，而认真思考恰好能把不确定往可控的方向推一推。

阳台上的旧车机：我给自己定了一个处理规则

另一个让我长期焦虑的小东西，是拆下来的旧车机。

之前我一直觉得扔了可惜，卖又不知道卖给谁，就这么放在阳台上。它不占太多地方，但它有一种很烦的存在感：我每天看到它，都像被提醒一次「你还有件事没处理」。那种拖着不决的感觉，慢慢就变成了一种持续性的焦虑。

后来我想明白了：让我难受的不是旧车机本身，而是我一直不肯做决定。

所以我给自己定了一个简单粗暴的规则：拍个照，挂到闲鱼上；有人要就卖掉；两周没人要，我就把它扔了。

这条规则的意义不在于「能不能卖出去」，而在于我终于给这件事画了一个截止线。它从「无限期悬而未决」变成了「我已经安排好了，接下来只需要等两周」。当我做完这一步，我甚至能感觉到心里空出来一点点位置。

认真思考不是说教，是对自己更划算

我越来越觉得，认真想清楚并不是在给自己上价值，也不是逼自己变得完美，而是一种很现实、很划算的自我照顾方式。

我当然还是会忘事，也还是会纠结，但我希望自己越来越熟练地做到两点：

第一，别急着找人背锅，包括我自己。埋怨除了让情绪更糟，通常并不能把事情变好。

第二，把焦虑翻译成行动：最坏后果是什么？能不能补救？下一步做什么？只要能回答出来，心里就会踏实很多。

少吃一顿药也好，阳台上的旧车机也好，最后都只是生活里很小的插曲。真正消耗我的，是我在这些小事上反复内耗。既然如此，那我就更愿意把力气用在「想清楚」上——让焦虑停在门口，而不是让它在心里住下来。

我在珠江路附近工作了十多年，每天上班几乎都要从九华山隧道穿过去。隧道的名字很熟，可“九华山”这座山到底在哪里，我一直说不清楚——它像是城市里一个被反复提起、却从未真正见过的地名。

这段时间因为一些事情，我经常改走北京东路。某天在路口一拐，突然看见一块路牌写着“九华山路”。我顺着这条岔路往里走，不久就遇到“九华山公园”的第一道牌坊，像是一个不经意的入口，把我从车流里带进了另一段节奏。

继续往里，路变得更安静。走到尽头又出现第二道牌坊，牌坊后面就是上山的台阶——那一刻我才意识到：原来“九华山”不是一个抽象的名字，它真的有一段需要用脚去丈量的坡度。

台阶到顶的两侧有两尊石像：左边长髯、手持青龙偃月刀，看起来就是关公；右边执锏，我猜是秦琼。两位“武将”一左一右站在山门前，气势很足，但也让我有点困惑——既然前方是寺院，为什么守门的不是佛教常见的护法形象，而是更熟悉的民间英雄？

拾阶而上来到一个开阔的平台，“玄奘寺”就在眼前。它不算宏大，却有一种安定的气场，像是把城市的噪声隔在了背后。

走近一些再看，寺门、匾额、屋檐的细节都更清晰了。我站在门前，忍不住又回头看了一眼关公和秦琼：也许在这座城市里，信仰与民间叙事本来就常常交织在一起，谁来“守门”并不那么绝对；但这份“不按套路”依然让我觉得有趣。

如果再向右拐，还有一条山路，据说可通玄武湖和明城墙。我沿着路往前走了一段，忽然在树影间看到一尊很大的金色弥勒像——之前我在小红书上见过类似的照片，有人说那是在头陀岭。

我不确定这里是不是“头陀岭”的那一尊，也许两边各有一处；但站在这尊金色像前，我能明显感觉到：这条路已经不只是“公园散步”，它更像是一段真正的山路，通往更长的线路和更多的风景。

之后再往前走就是上山了。我心里猜测，这一带大抵就是“九华山”吧，另一头可能是太平门。只是当时想着路途可能有点远，又担心体力跟不上，最后还是作罢，从原路返回下山。

这趟小探没有走到尽头，但对我来说已经足够：十几年里每天路过的“九华山”，终于从隧道名、路牌名，变成了一段真实的台阶、一座寺、以及一条我下次还想再走远一点的山路。