Yibie 的自我策展

我整理之前发过的帖子，这些是值得推荐一看的。也顺道向你暴露我的世界观、性格、兴趣和观点，有机会的话交个朋友😊

✨ AI 与新世界

得到 Prompt 系列（共 18 个） ⭐️已被“提示词图书馆收录”
m.okjike.com

Promopt: 文章精炼大师
web.okjike.com

Promopt: 概念卡片制作专家
web.okjike.com

Promopt: PPT 大纲制作助手 ⭐获得即刻精选推荐
web.okjike.com

Promopt: Kiweb. 文章精华浓缩专家
web.okjike.com

开发 12 Weeks LifeRPG 背后的过程与思考
web.okjike.com

用 AI 帮忙总结笔记（测试了 ChatGPT、Gemini、Kiweb.、豆包）
web.okjike.com

微软 CTO Kevin Scott 接受 every 访谈
web.okjike.com

吴恩达总结 AI 工程师制作 Promopt 的经验
web.okjike.com

OpenAI 2024 年春季发布会源文件， 包括演讲稿和演示用代码
web.okjike.com

视频内容识别是 Gemini Pro 1.5 的杀手锏
web.okjike.com

Perplexity 的官方 Promopt
web.okjike.com

大模型公司对 Token 的计算方法都不一样
web.okjike.com

AI 与创作者经济
web.okjike.com

------------------------------------

🤔我对这个世界有点看法

every 长文: AI 将冲击广告业, 后果很严重
web.okjike.com

Vision Pro 之我见
web.okjike.com

社会生活的趋同让人恐惧
web.okjike.com

「探索式」笔记法 ⭐获得即刻精选推荐
web.okjike.com

子弹日记法
web.okjike.com

商业价值的 3 个重要特征
web.okjike.com

Arc 这家公司的特点
web.okjike.com

新产品形态: Jina AI 将 URL 变为 API
web.okjike.com

------------------------------------

📒囤了一些清单

值得推荐的豆瓣小组
web.okjike.com

包豪斯设计的精华链接
web.okjike.com

Design Engineer 的 Twitter List
web.okjike.com

------------------------------------

📖️那些值得推荐的好书

读完斯多葛主义代表人物塞涅卡的书信集 <短暂的生命>
web.okjike.com

程序员超强大脑笔记
web.okjike.com

读完<巨人的工具>
web.okjike.com

读完<为什么伟大不能被计划>
web.okjike.com

精要主义读书笔记
web.okjike.com

读《了不起的盖茨比》
web.okjike.com

------------------------------------

💭️脑海里闪过的一句话

天才税
web.okjike.com

高度抽象的现代生活损害人类天生的类比能力
web.okjike.com

你能列出充分反映时代精神的 3 家公司吗？
web.okjike.com

解决拖延症的办法是找出之前最想完成但一直没做的事
web.okjike.com

美 = 深刻的简洁
web.okjike.com

尊重常识 = 不犯基本错误
web.okjike.com

与其花 1 小时如昙花一现, 不如花 10 倍时间震惊四座
web.okjike.com

这个世界有种人，以好人为食。
web.okjike.com

最难沟通的，是被灌输了标准答案的人
web.okjike.com

拖延 = 甩锅给未来的自己
web.okjike.com

折腾的定义
web.okjike.com

------------------------------------

🛠喜欢折腾工具

开启 Mac 系统自带白噪音音乐的方法
web.okjike.com

20-20-20 护眼原则
web.okjike.com

用哔哩哔哩替代网易云音乐
web.okjike.com

中国著名羽毛球运动员郑思维学习英语的工具和方法
web.okjike.com

------------------------------------

📁未归类的答案

「参考答案」的策展原则
web.okjike.com

我已经看到在本地训练一个 Jev 模型的案例，所以，Jev 将会是以后本地模型另外一个范式？

本地 Jev + 线上 Fable/Astra + 一大堆 Grok Bot

这就是未来的一人公司的标配吗？

不能理解为什么到哪儿都用全量这个词儿，所有，全部，统统，这些正常的中文不能表达同样的意思？

我按「Jev 到底在做什么决策」整理了公开可查的项目与讨论，目前收录 46 条：

· Notra（170⭐）生产环境用开关把分类器从 LLM 切到 Jev，目标 300ms p50

· vercel/eve 把 typesafe-ai/jev 作为默认 eval 模型

· browser-use/jev-ultrafast（1046⭐）用它决定浏览器每一步点哪里

· 马里奥、MuJoCo 无人机、星际争霸都用 Jev 做决策等

📂 github
github.com

其实在我手里，Agent 能力都很强，很快就能把问题搞定。

我不知道某些大 V 为何隔三岔五地抱怨这个降智，那个降智的——是因为观众爱看？

还是，这些大 V 解决问题的水平就那样。

写了新的博客，提到了我封存 SPEC-AGENTS 的原因，以及回应网友的邮件： www.gtdstudy.com

所有人离开上一家 AI 公司的时候，是不是都习惯地发布一番「末日预言」？

哈哈哈哈，读书人的事情怎么能叫抄呢？

via 知乎

让 AI 发挥更好，最重要的是干净的上下文。

大家都在问：怎么让 AI 发挥得更好？很多人第一反应是「用更强的模型」。我的答案是：不是。

先说模型。luna 确实流口水，但我可以用 astra low——在某些任务上 astra low 的智商甚至超过 sol ultra。

有朋友说，medium 的性价比最高，我同意，但只让它负责 coding 就大材小用了，我直接让它作为 leader agent，表现也相当不错。

我认为，绝大部分任务没必要开 max 最高档推理——除非真的很难。如果故意推高推理挡位，会让大模型思虑过多，反而产生大量不必要的 token，塞进了上下文，影响大模型的判断。

大模型的上下文就像一个仓库，什么都堆在里面，大模型是依靠自己的注意力机制在这个杂货库里翻找出自己要用的信息。如果这个仓库堆得太乱，注意力机制就会受到影响。

基于以上实践中的体感，我正式放弃 spec-drive（也就是"spec 流派"）的开发方式——已经进历史博物馆了。那种流派让太多内容进入上下文，导致上下文污染严重，干扰 llm 的智商水平。你以为在「描述需求」，实际是在给模型制造噪声。

那怎么做？我的做法很朴素：

我不分割上下文。就是把不相关的任务，尽量派给不同的 agent 来处理。agent 也不必太多——3-4 个就够了，多一个出来，专门干各种临时发现的杂活儿。我不用 worktree。

成本上也有惊喜：astra low 的缓存命中比 sol 准确很多，所以用 low 的时候，它的成本可能比 sol 还便宜。

一句话：好模型是前提，但真正拉开差距的是上下文管理——少塞内容、任务分流、按需开档。

老文新读：

《迁移：技术债唯一可扩展的解药》

---

Migrations: the sole scalable fix to tech debt

作者：Will Larson（前 Uber 工程副总裁，Staff Engineer 作者）

我参与过的最有意思的迁移，是 Uber 从 Puppet 管理的服务迁移到完全自助的供给模型——公司里任何工程师都能两下点击起一个新服务。他们不仅做到了，而且做到了：迁移完成时，每天都有多个服务被创建，每个新入职的工程师第一天就能从零拉起一个服务。

这次迁移之所以有意思，在于它的体量。我们开始时，起一个新服务大约需要两周的日历时间和两天的工程时间，而且我们每一天都在落后更多。当时这是有点压力的，但它也是一个完美的实验室，让我学习如何运行大规模软件迁移：规模大得足以看清微小变化，时间长得足以让我们尝试各种方法。

随着代码库老化和业务增长，迁移既是必要的，又频繁得令人沮丧：大多数工具和流程只支持约一个数量级的增长就失效，所以快速增长让它们成为一种生活方式。这不是因为它们是坏流程或差工具——恰恰相反：某样东西在规模显著增大时失效，正说明它被设计得适合之前的约束，而不是过度设计。

因此你会经常换工具，而你迁移到新软件的能力，很容易成为你整体速度的决定性约束。鉴于它们的重要性，我们却很少谈论如何运行迁移——让我们来弥补这一点！

为什么迁移重要

迁移之所以重要，是因为它们通常是就技术债取得有意义进展的唯一可用途径。

工程师讨厌技术债。如果有一个他们个人能做的简单项目来减债，他们会自己接手。工程经理也讨厌技术债。如果有一个团队能独立执行的简单项目，他们会排期。总体上，这导致一个动态：几乎没有什么低垂的果实能减少技术债，剩下的大多数选项需要许多团队协同实现——那就是迁移。

每次迁移的目标是创造技术杠杆（"你的索引不再需要放进单一台服务器！"）或减少技术债（"你确认的写入在主机故障切换后保证持久"）。它们占据一个尴尬的地位：今天减少直接贡献，换取明天更多能力。这让它们难以排期，而且随着系统变大，它们变得更贵。

传说中 Google 人有一句话："Running to stand still"（原地奔跑），用来形容一个团队的全部能力都消耗在升级依赖和模式上，以至于无法在他们负责的产品/系统上取得进展。把全部时间花在迁移上是极端的，但每个中型公司都有一长串无法配备人手的迁移队列：从 VM 到容器、推出熔断、换到新构建工具；这个清单可以轻松延伸到日落。

迁移是公司成长和代码增长时有效管理技术债的唯一机制。如果你不擅长软件和系统迁移，你就会困在技术债里。（而且以后仍然得做一次，只不过那可能是一次彻底重写。）

如何运行好迁移

好消息是：虽然迁移很难，但有一个相当标准、效果显著的剧本——去风险，赋能，然后完成。

第一阶段：去风险

迁移的第一阶段是消除它的风险，尽可能快、尽可能便宜地做。写一份设计文档，拿给你认为最难迁移的团队看。迭代。拿给有异型模式和边缘情况的团队看。迭代。拿给未来六到十二个月的路线图测试。迭代。

方案进化之后，下一步是嵌入到最有挑战的一两个团队，与这些团队并肩工作，一起构建、演进并迁移到新系统。不要从最简单的迁移开始——那会带来虚假的安全感。

有效的去风险至关重要，因为每个认可迁移的团队都相当于在你身上下注：赌你会把这件事干完，而不是留给他们一个迁到废弃系统的迁移、还得回滚。如果你留下一个半成的迁移，人们会极其怀疑是否参与下一个。

第二阶段：赋能

一旦你验证解决方案能解决预期问题，就该开始磨工具了。很多人一开始就为团队生成追踪工单，但更好的做法是放慢速度，构建工具来程序化地迁移"容易的百分九十"。这极大地降低迁移对整个组织的成本，从而提高他们的成功率，并创造更多未来的迁移机会。

在处理完尽可能多的程序化迁移后，想想你能提供哪些自助工具和文档，让人们在不卡住的情况下完成必要变更。最好的迁移工具是增量且可逆的：如果出了错，人们应该能立即回到之前的行为，并且有必要的表现力来消除他们特定迁移路径的风险。

文档和自助工具是产品，在同样的机制下蓬勃发展：坐下来和一些团队一起观察他们按照你的说明走，然后改进。找另一个团队，重复。在大迁移中特意多花两天让文档干净、工具直观，可以节省数年。做！

第三阶段：完成

迁移的最后一个阶段是废弃你已经替换的遗留系统。这需要达到百分之百的采用率，而这可能相当有挑战性。

从止血开始：确保所有新写的代码都使用新方法。这可以是在你的 linter 里装一个棘轮，或者更新你的文档和自助工具。这永远是第一步，因为它让时间成为你的朋友。你不再默认地落后，而是默认地在进步。

好，现在你应该开始生成追踪工单，以及一个把迁移状态推送给需要迁移的团队和总体管理结构的机制。给更广泛的管理层迁移上下文很重要，因为他们是需要为迁移排优先级的人；如果一个团队没有在做迁移，通常是因为他们的领导没有优先安排它。

这时你离完成很近了，但还有怪异的或无人手的长尾。你现在的工具是：自己收尾。这未必有趣，但达到百分之百需要领导迁移的团队自己钻进犄角旮旯。

我最后一个关于完成迁移的建议是关于认可。在迁移进行中庆祝很重要，但大部分的庆祝和认可应该留给它的成功完成。特别是，开始但未完成的迁移往往背上大量技术债，所以你的激励和认可结构要小心避免反向激励。

你见过什么让迁移更有效的做法？你经历过哪些反模式？

感谢 Ingrid、Jorge 和 Julia 塑造了这篇文章。

原文：lethain.com