如果，我是说如果。 假如我的 followers 里有相对年轻的求职者，正好在找工程方向的工作。 我相信你的简历里一定有一些自己做过或者正在做的项目，不管是不是 vibe 的，当下这个时间节点大概率做的可能靠 agent 方向多一点。 或者是个 workflow，或者是之前的 dify 二开等。 概率比较大。 每个面试官可能角度不一样，有的也许就爱看你做出几十个应用，洋洋洒洒。 但从偏向技术和工程的角度，我建议你不要贪多。 这个时代多没什么用，花点钱买点 token 的事。 做了什么爆款，也许有人会看重一些，但相信我，价值优先。 毕竟小猫补光灯都能上榜一。 我还是建议你打磨好一个项目。越是这个容易 vibe 出东西的时代，你在一个项目上打磨，投入的心血，对这个方向的理解，都价值连城。 哪怕方向在当下看起来也许是错的或者不受欢迎——比如简历上我看的每个人都碰过 RAG，一问为什么今天看起来有点日渐式微，很多人答不上来。 也不是说 RAG 就是错，如果你坚定的在这个方向上打磨，尝试过各种策略，把你的经验，踩过的坑，benchmark，结论，你做过的尝试——这些能和人描述出来—— 你知道你在一个真正想招工程师的面试官眼里有多发光吗？ （以上不是说 RAG 不行，RAG 是个涵盖超广的概念，其实 grep 也算 RAG 的手段，狭义广义的我就不展开了） 真的干过，思考过，一个方向折腾过——哪怕一路都是借助 AI，都是你的加分项。 巨大的加分项。

memory 系统目前测下来，设计的越复杂越精妙的—— 也越烂。 有些时候它能表现出来真的很不错的“记忆和召回”，但脆弱的要命。 短平快糙的看起来一堆毛病，实际跑起来还好一些。 当然不管哪种，如果你追求那种 human like 的 memory，想极力借助 memory 和 loop 来让人跳出干预，那反正是死路一条，换啥系统都没差。 至少此时此刻的现在，就是死路一条。得看下半年了。

我现在的一个习惯是，能够让 AI 通过操作得出来的东西，就绝不让它用生成。 就比如配置文件要换格式或者干什么的，哪怕很简短，也应该让它通过正则或者 whatever 各种工具来操作。 也不是说就一定不信任 AI，我就敢让 AI 帮我做各种架构设计。尽管很多人都说让 AI 做细节，自己来设计，但我无所谓，我觉得 AI 的架构设计的往往比我好，因为它看过的东西比我多。 反而是在细节上。如果一个事情需要 100% 的正确率，那我就必须用能达到 100% 正确的工具来做。 让非 100%概率和确定的东西各自待在自己的舒适区里，对我而言也很舒适。

我好像有点懂了，那些说自己现在不看代码的人，他们其实原本就是软件的消费者，他们本不应该成为生产者。 我为什么会有前两条推那种感受？因为我在做的是框架、工具库或者基础服务。对我来讲，交付软件本身就是目标，所有软件工程的事也仍然存在。 但有些人他纯粹就是要实现业务逻辑的，对他来讲，能不写代码实现业务逻辑就最好。选型哪个框架跟他也没关系，他本来就不应该写代码，是低代码的受众。对他来讲，不用写代码就是一种优化。这好像也合理。

发现codex 在 4 个小时前发了个这个 which means： 之前 codex-cli 主要通过 `codex` 命令来在 shell 里做交互，现在结合到 zsh 里去，以后可以在 zsh 里直接用 codex 能力了。命令补全，上下文感知之类的。 这个 artifact 将会在后续下游进 codex 的主包的分发流程。 望周知。

张鑫旭的 blog 是我唯一愿意刷，且信得过，且有人味的，中文的前端技术的信息源了。 但我一般并不关心他每次更新又介绍了什么新的特性，而是看他又去哪里钓鱼了……

Google Workspace CLI 这项目当时我还转发过，没想到几个月过去，作者 Justin Poehnelt 因为这个项目被开除了。 Justin 在 Google 干了将近七年，岗位是 Workspace 开发者关系工程师。今年 3 月初，他用 Rust 写了一个 Google Workspace CLI，放在了 Google 官方 GitHub 组织下（ Gmail、Drive、Calendar 等所有 Workspace 服务，还内置了 MCP 服务器，AI agent 可以直接调用。 Addy Osmani 3 月 5 日发推介绍了这个项目。然后就爆了，Hacker News 第一名，GitHub star 数冲到两万多，几天之内就有了几千个实际用户。 Google 内部的反应是两极的：有总监和高管主动来问这个工具能教他们什么；同时法务开始盘问他，为什么项目上有 Google 的 logo 和品牌色。 4 月 22 日到 24 日的 Google Cloud Next 大会上，Google Workspace 官方博客宣布官方 Workspace CLI 即将推出。两天后，Justin 被开除了。 他怀疑是 Workspace 的某些管理层和项目害怕被 AI agent 颠覆，而这种恐惧不只是针对他的 CLI，是针对整个 agent 对 Workspace 意味着什么。 Hacker News 上对这件事的观点两极分化。一派认为这是 Google 官僚主义碾压创新的典型案例，七年老员工做了个用户真正想要的东西，然后被自己公司干掉了。另一派指出，Google 有一套非常明确的开源发布审批流程，用公司品牌发布未经批准的项目，在任何大公司都可能被开除。 Justin 本人在 Hacker News 回复里的说法是：作为 DevRel 工程师，开源发布审批本来就是他日常工作的一部分，而且这个流程文档不清楚，还一直在变。 这个项目本身还活着。最新一次更新是 6 月，GitHub 上 26000 多颗星，InfoQ 和 BetterStack 都有详细的教程。Justin 被开除后还在继续写技术博客，最近一篇是用 Claude Code 的 subagent 做 Gmail 分类。 对于正在用这个 Workspace CLI 的开发者来说，眼下倒不用太担心，项目还在 Google 的 GitHub 组织下正常维护。

虽然不怎么看代码了，但我仍然会隔两天，离开终端，跑到IDE里面去看一下文件树。 这个东西很有意思，它看起来就是一些文件夹跟文件摆在那，但它们怎么组织，是否有矛盾冲突不合理的地方，一眼就能看得出来，把这个丢给AI，稍微聊两轮，你就可以接下来帮助他纠偏，帮AI把控一下方向。 当然，如果你不想自己看，你也可以让AI来看这个事情，就是在不看代码的情况下，只看代码文件是怎么摆的。 这个结构里面可是有非常多的信息的。