最近在做两个工具，有些许收获，也有许多云里雾里，细枝末节的太多，直接挑重点来展开讲讲吧。
事先声明，对于标题这个问题，我还没有答案，以下仅为探索过程中的记录。
01
在做一个能帮我挖 insights 的工具，我希望它不仅能帮我找到材料中有价值的信息，还要帮我把那些信息映射到我的工作或是关注的话题上，甚至可以嵌入几个现实中的例子——我把它取名为 LumiLens，目前测试的结果还不错。
但过程中出现了一个意外，让我有点惊喜也有点隐隐的担忧——我在检查它嵌入的案例来源是否真实时，打开的页面竟然是 rss.xml 文件——一个 RSS feed——我有点不解，我以为来源总会是链接，它咋就能抓到 RSS 链接了呢？
也就是，我点击上图中的「来源 2」就跳转到了对应的 XML 源码视图，下图就是它引用内容的「来源」：
然后意识到，哦，RSS 本来就是给机器读取信息的订阅源，那对 AI/Agent 来说，能读到是再正常不过的事情。只是我好像忘了，我们习以为常的 AI/Agent 也是机器的一种。
于是，我在想，那我在做内容的时候，是不是也可以做一个给 AI/Agent 读取我的内容的入口呢？
RSS 就是这个入口的方式之一。
但我又想到，如此一来，有心的人们——那就更容易反向给 AI/Agent 喂毒了。
假如，我懒得去检查来源，懒得去看来源的链接对应的是谁的 RSS，懒得去看这个 RSS 和谁的播客内容有关——那么我就永远不知道 LumiLens 给我的举例是否真实。
哦得解释一下，LumiLens 读到的内容案例来自于一个产品经理做的播客信息深度解读网站中的某一期，目测这是 ta 用 AI 做的针对于某期播客的深度解读——所以，LumiLens 拿到的并不是一手播客信息源，那么我要验证信息的真实性，还得回到播客节目源本身，而不仅仅停留于这个网站解读的内容。
02
尝试做一个图文卡片生成工具，分享些啥内容固定下来模板也省事儿。做着做着发现，哎哟，效果还真不错，看起来干干净净的（极简风格）：
但麻烦的问题来了。
某些时刻——打开本地预览测试的时刻，不知道为什么，电脑的小风扇开始疯狂转（虽然看不到，但它那声儿响得…听着我也替它着急）——这下我知道了，肯定是电脑的 CPU 被谁给吃了——前车之鉴是 OpenClaw 的 Gateway 搞过我的 CPU。
然后去打开活动监视器来看，到底是谁在搞活儿。奇了怪了，眼睛只看到了 Kernel Task 占掉了百分之一百多两百多的内存…所以罪魁祸首到底是谁？
对电脑啥啥不懂的我只能去找 Codex 帮忙，结果它找着找着原因…把我电脑给整白屏，然后卡了一会儿直接重启了。
好嘛，我去找 CC 帮我优化系统，猜猜怎么着？😊
嘿嘿！比起 Codex 有过之无不及，白屏的时间我也没算到底有几分钟，反正我就在电脑前捧着手机搜小红书 & 问 ChatGPT 咋回事儿…等重启之后，我再也不敢轻易打开任何一个本地预览。
在此之前，我见证了 Kernel task 占用 CPU 达到了百分之两千多…这个数字简直疯了🥲虽然只是几秒的功夫，但你知道我那个心惊胆战哦！就 Agent 上一秒才开启一个预览就被我下一秒给关掉了…
对了，Kernel Task 是啥呢？简单来说，它是 MacOS 系统核心的一部分，当电脑过热、CPU 快被程序占满或者功耗过高时，它会故意占用 CPU 调度资源阻止别的程序瞎搞——嗯，保护系统。
再再（不知道几个「再」了😂）一轮电脑重启之后，我去找 Antigravity 之前（帮手真的很多哦），先去看了看活动监视器，然后看到那烦人的 OpenClaw Gateway…一气之下直接让 Antigravity 卸载掉这玩意儿（明明早前就让它帮我给强制关掉了，居然还会出现？！）——反正最近也没咋用，虽然 Hermes 不怎么经用，但起码 token 消耗是真良心（怪不得不怎么经用，但普通任务也够用了 hhh），然后顺便把所有情况都和 Antigravity 又说了一遍，让它帮我看看到底该怎么解决。
我还特意叮嘱它，千万别乱扫描我的项目文件，别乱开本地预览！
它鼓捣了几下之后告诉我，我的 16G 内存，已经有超过 15G 被占用，傻眼了——可是活动监视器里占用 CPU 最高的连 25% 都不到，是谁让这机子的物理内存只剩下 800MB 左右的？？
然后，文件缓存？自动腾退？？
还有，手动重启居然比自动重启还有效？还真是第一次经历。（学会了！
手动重启之后还有 bug？然后，终于！Antigravity 救场成功。
以上，你问我干了啥？我是真不知道，哭不出来。。。
这啊那的，看得我…更是悔恨自己啥啥都不懂，太难为这些 Agent 们为我「擦屁股」了。🤦♀️
那经此一难，我学到了什么？实话说，虽然 ChatGPT 给了好多解释，我还是…（尖叫）脑子你快回来！别不理我呀...
03
前阵子靠 Poke 的 Recipe 功能了解到一个新词汇，叫「生成式语义危机」。它告诉我——AI 速成的界面代码，很多时候是「形似」但「无神」。
比如说，Coding Agent 能很快写出来一个漂亮的按钮或者菜单，但是底层的 HTML 标签缺乏正确的语义描述，于是，类似屏幕阅读器这类辅助阅读工具无法读取这个页面——这里有多个名词，具体就不解释了，说句大白话就是，有时候 Coding Agent 写出来的界面，我们人类看着是爽了，但 AI/Agent 却读不出来那是什么结构的东西。
这里我想到一个叫做 DOM 的东西，我在做 LumiFlow 过程中，不仅发现 Gemini Chat 界面如此难抓取，而且在我安装上插件之后某个时刻——公众号后台的排版莫名崩溃，然后搞了半天才解决掉这个问题。当时得到的解释是说，LumiFlow 的代码污染了公众号后台——这下子应该是语义冲突了吧？🤔
偶然刷到 Brian Chesky（Airbnb CEO）在 X 上发的帖子，他说，Airbnb 目前的界面对 AI 来说并不是最佳选择，以及他觉得，未来的界面一定是 convertional 的，在视觉表现上的需求会比如今的文字交互多得多——他们还在寻找解决方案，试图让 AI 更懂人话，通过文字理解意图然后输出视觉化语言，以帮助人做决策——就像，看地图一定比文字指路更能易于我们走路。
回到以上 01、02 的语境，一个是「我在读内容（文字），但 AI/Agent 读的是 RSS 结构」，另一个是「我只是想开个预览，而 Coding Agent 前中后做了什么我浑然不知」，再加上 03 这里的「机器底层读不到我看到的 UI 界面」——
综合来讲，我们人类看到的，或者说感知到的，大多时候只是表层的——UI 界面、内容或者动作等可见的东西，而机器（AI、Agent）能读懂的是协议、进程或 DOM 等语义树——就人 VS 机器，二者需要对齐啊！
那问题就来了，如何能让人更清楚地知道机器在干什么呢？最近在死磕「AI 如何才能不给我开盲盒」——还在尝试吧。。。
其实回过头来发现，依旧还是啥都不懂，一阵无声苦笑 ：）