月刊（第31期）：基于 Claude 的阅读流 - Airing 的博客

读完之后，发现 Reader/Readwise 以及 Claude/MCP 结合，居然可以做这些个事情，自己的阅读流以及信息整理过程在当下结合 AI 的确可以做些改变了，好的工具让世界更美好，也许也到了切换工具做减法的时候了（feedly 上 RSS feed 太多了，看不过来根本看不过来了），目前自己的几个信息源：X 上的关注，teleg 的几个频道，公众号，书以及 RSS 订阅，RSS 订阅和 teleg 相对重要。

我需要改进的地方，引用和个人相关的笔记，有效形成总结，结合 AI 和自己思考，目前都是通过复制到 Apple Note，然后加上自己的评论，最后发布到博客，如果采用都是在线的做法之后，如何可以方便发布，是另外需要解决的问题，也许通过 AI 总结成每周的一个阅读文摘是个选择，也可以考虑自己写个 Agent，但 Apple Note 我不会丢。

参考如何使用 Readwise MCP：How to use the Readwise MCP - Readwise Docs

通义听吾 https://tingwu.aliyun.com/home 也是结合 AI 的一个好工具，腾讯 ima 以及 Google 的 NotebookLLM 也许也是选择。

17/7 - 又对 reader 失去了热情，我分析是因为用惯了 feedly，发现切换还是有成本，而且 reader 的内置阅读也有些问题（解析不一定好），再想再看，但是设计以及易用性的确是 reader 好。

Reader 不错的地方

• 快捷键操作很友好，网页设计漂亮
• highlight 和 note 功能很好
• 具有 RSS 能力
• 不贵
• 有 Chrome 插件，体验不错

Reader 感觉一般的地方

• AI summary 其实没那么有用，只是简短的 summary
• 有些网页解析有问题，打开一个网页其实没那么方便

Feedly 不错的地方

打开链接方便
highlight/notes 以及 AI 都是收费功能（Pro+），但不贵 （annotated 这个功能还没看到，是付费功能）
有 Chrome 插件，Feedly mini？read it latter, 以及 save to boards 的功能

关于 Boards 功能？这个是面向团队的功能，对于个人好像用处没那么大。

Team boards are private spaces where you and your team save the best articles you discover in your feeds and on the web. You can think of Boards as folders or notebooks in which you and your team can collaborate by organizing the content that matters to you.

如何和 AI 结合，是不是具备和 readerwise 类似的 MCP 能力？目前还没看到，可能要借助于第三方。

Feedly 感觉一般的地方

UI 设计上没有 reader 做的那么好
没有试用（说是可以付钱然后申请退款，达到试用的效果）

＃4 - 和 RSS3 道别的这一周

”但是在 web3 不是这样，从智能合约到量化交易，从一级市场到二级市场，每个方向并没有被划分得很细，通常是需要能力更综合的人，既要懂链，又要懂智能合约，又要懂其他业务知识。工作的内容往往也不是局限的，能接触到各种方向的技术。
并且，由于这个行业离金融市场太近，遍地都是搞钱的机会，那就意味着，你非常有可能获得工资之外的收入。"

Web3 国内还是不稳，还有就是 AI 和币圈了；对于个人找准一个方向真的很重要，好的方向上下限赚的钱都比一些行业顶级人能赚的钱都多。

对话YouMind创始人玉伯：中年创业很难，资本更喜欢00后年轻人

这个是我在回顾之前的一些经历时，反复想的一个问题，我究竟从大厂学到了什么？哪些是有用的？哪些是要小心辩证看的。比如张一鸣说的EGO要小，格局要大，我觉得就是一句要辩证去看的事情，一个创始人如果格局不大是做不成事情的。我说的EGO大，其实是说，人在一些事情上要有执念，有偏好，有偏见，有偏见才有观点。一个没有偏见的人是非常寡淡的，创业也不会有差异化。没有差异化，怎么去竞争、做好产品。所以从这个来讲我是非常认可，人就是要有偏见，你的独特认知，你要很坚持。
我也不知道它是怎么做到的，去飞书时这个对我挺震撼。我听过一些关于张一鸣要求数据准确性的故事。他会问得很细，你只是给他一个笼统的数据，可能是过不了关的，他会问到这个数据究竟是怎么统计出来的，可能就是在这种一年又一年对数据的坚持下，使得所有人都知道造假是没用的。造假可能会被揪出来，那个代价会非常惨，可能直接就开除了。
这是我们要正在做的方向，叫万物化稿，稿生万物。万物化稿就是比如说各种各样的资料，包括录音、本地文件输入后，把这些输入变成稿子、录音，或者采访稿，这是万物化稿，再把稿子通过配图，变音频、视频，甚至直接发出来，就是稿生万物。

玉伯访谈，谈的非常好，受益匪浅，每个特别的人一定是有很强的思考力和行动力的，不然我的观点一定不可能是个世俗意义上成功的人。

图片出处

一顿鲅鱼水饺引发的思考

首先是提升客单价。烟台本地有丰富的海鲜水饺品类，完全可以引入杭州。上个月，老板采纳了建议，开始尝试售卖单价更高的八爪鱼水饺，一份 10 个售价 38 元。这是一个很好的开始。我建议他后续可以继续引入更多有特色的海鲜水饺，逐步将顾客的关注点从「便宜实惠」迁移到「好吃且独特」的海鲜水饺上来。
其次是错峰推行特色水饺。可以尝试按周，比如每周二和周五，限量推出特色海鲜水饺。这样做的考量有几点：像八爪鱼、海肠这类食材，对新鲜度和品质要求极高，冷冻品完全无法保证口感。老板对食材有自己的坚持，这就导致了进货成本和周期的增加，不太可能做到每日供应。每周只卖特定几天，既可以有效管控成本和备货预期，也能在销售过程中不断加深对供应链的理解，从而优化出品和供应之间的平衡。
再者是通过多品类提升客单价。除了在饺子本身下功夫，也可以引入其他品类。例如，将山东特色的电烤肉引入店里。目前店里免费供应的小菜非常受欢迎，完全可以增加几种特色小菜，按照每人 5 到 8 元的价格自助供应，这也能成为新的收入来源。总而言之，目标是让店里的客单价从单一的水饺，扩展到更多有差异化的品类上。
最后是重新选址。老板现在的住处离店面太远，父母每天早出晚归，身体上有些吃不消。既然地铁商业街的房租要翻倍，不如趁此机会在离家近的地方重新选址。这样一来，父母中午还能回家休息片刻。根据我对杭州餐饮模式的了解，只要产品本身过硬，店铺搬迁造成的顾客流失和现金流损失并不会像想象中那么大，而对于这家店的品质，我毫不担心。同时，还有一个策略性的动作：可以拿着已经看好的新店面信息，去和地铁商业街的管理方谈判，看看他们是否愿意承受一个大众点评 4.7 分的优质餐饮店铺的流失。
一顿饭的工夫，我们聊了很多。看着老板一家人勤恳的模样，我由衷地希望这家充满了人情味和家乡味的小店，能够穿越周期，走得更远、更稳。

周五了读到这么一篇文章也是幸事，莫名的感动和心情舒畅，博主是个好人，也是个聪明且有方式方法的人，做任何事情不能凭死劲（一定需要，但是无法做到最好），而是要“聪明的努力”，餐饮行业的一些小店受限于店家的知识水平和能力，博主这样的点拨确实能给店家带去不一样的气象，祝好！

AI 时代如何做独立开发

技术栈和依赖项都比较简单，主要包括：

• 开发基础：typescript / react / nextjs
• 登录注册：next-auth / clerk
• 数据存储：supabase / neon
• 多语言：i18n / next-intl
• 支付：stripe / lemonsqueezy / creem
• 文件存储：s3 / r2
• 项目部署：cloudflare / vercel
• 域名管理：godaddy / namecheap

我认识很多独立开发者，正在干着很多人看不上，看到了都说“真香”的事情。
这件事情叫：AI Wrapper，通俗一点的说法是：套壳
SOP 很简单，主要步骤是：

• 发现热点：hf space + google trends + github trending
• 抢注域名：namecheap + godaddy
• 上线网站：vibe coding + 代码模板 + AI 能力（replicate、fal、openrouter）
• 获取流量：seo + 社媒宣传
• 流量变现：付费订阅 + 谷歌广告

今年 Agent 创业非常火，看到一个说法：所有的 SaaS 产品，都值得用 Agent 重新做一遍。淘金的人越多，对铲子的需求就越大。所以面向 Agent 开发做基础设施是一个可行的方向。
Agent Infra 包括：

• Tools 工具
• Planning 规划调度
• Memory 记忆存储
• Boilerplate 业务模板
• VM / Container 虚拟容器
• Auth 登录鉴权
• Payment 支付收款

非常好的文章，对于个人开发者，涉及的方方面面做了个梳理，从开发、推广和个人产品实现的反思，以及 AI 时代可以做的一些方向，结合自身情况都给出了具体的建议和想法，点赞。

HW-whistleblower/True-Story-of-Pangu: 诺亚盘古大模型研发背后的真正的心酸与黑暗的故事。

几个大厂，依据我个人的一下了解，对于研发管理实在是一言难尽，画饼抱团，真正愿意好好做技术的反而有时候没有空间，这和学术环境一样，需要出成绩没有长期投入的勇气和眼光，也有关系；目前几个大厂的云，销售驱动，啥热门搞啥，其实也没多少自己的东西，技术公司一旦是销售驱动，我一直认为就完了。

菲尔兹奖得主陶哲轩，首次3小时非学术机构访谈来了！

虽然听不懂，还是记录一下，涉及的都是数学大问题。

从零开始的大语言模型原理与实践教程

本项目是一个系统性的 LLM 学习教程，将从 NLP 的基本研究方法出发，根据 LLM 的思路及原理逐层深入，依次为读者剖析 LLM 的架构基础和训练过程。同时，我们会结合目前 LLM 领域最主流的代码框架，演练如何亲手搭建、训练一个 LLM，期以实现授之以鱼，更授之以渔。希望大家能从这本书开始走入 LLM 的浩瀚世界，探索 LLM 的无尽可能。

从零开始的大语言模型原理与实践教程

前阵子想开始学习一些深度学习的原理，从豆瓣上找来了传说中的鱼书第一册《深度学习入门》，马上就看进去了。浅显易懂，把深度学习和神经网络的相关知识都讲解的很好，没有采用类似PyTorch这样框架做为代码用例，而是用更基础的NumPy库来讲解代码原理。随后看了这套系列书的整体评价都很好，所以就全部收集下来打算都看看。总而言之，如果你和我一样之前都是相关领域的门外汉，强推这套书拿来入门，最近也出了第五册讲生成式模型的。

程序员的提示工程实战手册

摘录自 https://weekly.tw93.fun/posts/228-%E5%BD%A9%E8%89%B2%E5%A4%A9%E7%A9%BA，宝玉兄 6 月份的一篇翻译的文章，程序员的提示工程实战手册，一份适合新人的快速入门备忘录。

吴恩达老师分享的这个做 MVP（最简可行产品，minimum viable product） 的技巧 | 宝玉的分享

我想分享一个能帮助你更好地利用AI进行项目实践的小技巧，不论你是在用AI的“积木块”搭建应用，还是借助AI代码助手快速开发强大的程序，这个技巧都能帮助你：

如果你的时间有限，就缩减项目的范围，直到项目小到你在现有时间里能完成为止。
假如你只有一个小时，那就找出你想要实现的某个创意中的一小部分，确保这一小部分能在一小时内完成。借助现代的代码助手（例如我目前最爱的开发工具Anthropic的Claude Code），你可能会惊讶地发现，哪怕只有很短的时间，你也能做出很多有意思的东西。这种方法可以帮助你迅速上手，之后你随时都能继续完善项目。

我在笔记本电脑上保存了很多有趣的创意清单，它们大部分都需要超过几个小时的开发时间。然而，通过不断缩减它们的初始范围，我总能快速启动一些小项目。这 种 “快速起步”的方式 给我带来了以下的好处：

能让我迅速试验创意，并决定哪些值得继续投入精力。
我能够在广泛的项目实践中锻炼不同领域的技能。
更重要的是，这种方法帮助我迅速将想法从头脑里释放出来，让潜在用户能及早接触到产品原型并提供反馈，加速项目的迭代与发展。

希望这个技巧对你也有帮助，下次当你觉得“没有足够时间”时，不妨先试试“从极小的范围开始”！

写代码从来不是瓶颈 | 宝玉的分享

LLM在快速原型开发、脚手架搭建和自动化方面确实带来了真正的价值。然而，它们无法消除清晰思考、谨慎审查以及周密设计的必要性。相反，随着生成代码越来越多，这些基础工作变得更为关键。
是的，写代码的成本确实降低了。但团队一起理解代码的成本并没有降低。
这才是真正的瓶颈。我们不应假装它不存在。

https://github.com/bytedance/trae-agent

学习一下，据说代码写的不错。

「你有目标吗？」 | So!azy

最终，是我与自己达成了和解。我接受了自己的局限，也接受了自己的平庸。说来也怪，最近我频繁地在和各种人探讨这个话题。我的老板、我的下属，甚至我室友的朋友。每一次都不是我主动说教，而是他们无意中将话题引至此处。这让我意识到，或许我身边的人，也都陆陆续续地步入了 30 岁的门槛。人到了这个年纪，好像真的会开始放下许多曾经的执念。 所以，我回答老友的话也很简单：「对啊，为什么要设定目标呢？设定了又可能完不成，不然你以为我为什么会得抑郁症。」
需要说明的是，我所说的「没有目标」，特指的是宏大的人生叙事。我不给自己设定过高的期望，也不再规划遥远的未来。但这并不意味着我在处理具体事务时也漫无目的。恰恰相反，当面对一个具体项目或一项棘手的工作时，为了达成一个明确的结果，我依然会把它细致拆解，设立一个个清晰的里程碑。
这些服务于具体事务的「目标」，是完成任务的工具和路径，但它们与我的人生是无关的。完成一个项目，达成一个季度的 KPI，这些是工作的一部分，却不再被我用来定义自身的价值。把目标的作用限定在事务的层面，而不是让它绑架我整个人生，这才是关键。
对我而言，最重要的要求，就是确保我不会在人生的道路上走得歪斜，不会变成一个连自己都讨厌的人。这样，就足够了。

认识自己的能力边界以及短板，不断“折腾”且持续改进是路径，拓展自己的能力边界以及改进该和能改进地方，而不是好高骛远，怨天尤人。

Multi-Agent 或 Single-Agent 架構討論

Anthropic 的見解: Multi-agent 有其必要性

• Single-agent 在複雜任務上必然會撞到 context window 限制
• 某些研究任務天生就適合平行處理，像是「找出 S&P 500 科技股的所有董事會成員」
• 他們的內部評測顯示，multi-agent 系統比 single-agent Claude Opus 4 效能提升了 90.2%

• 關鍵在於: token 使用量解釋了 80% 的效能差異，multi-agent 能有效擴展 token 預算

  Cognition 的見解: Context 共享才是王道

• Multi-agent 最大問題是 context 無法有效共享，導致子代理人做出衝突決策
• 而大多數現實世界的任務都有許多層次的細微差別，這些 context 細節差異都有可能被 multi-agent 誤解
• 就像兩個工程師各自寫程式但沒溝通，結果 merge 時衝突一堆
• 現階段的 LLM 還不夠聰明去做多 Agents 的有效協作
• 建議用 single workflow 架構搭配 context compression 技術，確保 context 連貫性

谢谢你，Databend；你好，LanceDB

面向底层技术，通过开源持续深耕，佩服（也是自己一直以来希望成为的样子，但是从来没有做到过，包括贡献开源，一方面是自己本职工作的缘故，一方面是自己不够“激情”和“爱好”，也是能力还不足）。

技术大头兵，如何转管理

管理和技术是两个完全不同的工种：

1. 管理本质是要团队利益大于个人利益，人话就是，天天帮助别人，自己不要写代码。团队进展缓慢的原因一般都是需求不明确、沟通信息差、资源卡住了，而管理者应该向篮球后卫一样，在团队里到处乱窜，传球，组织，最后进球
2. 视野不一样：管理要关心他人，从组织管理到每个人的职业瓶颈，组员知识不够要传授看书经验，组员心理遇到问题了，要及时疏导，组员有成绩以后要及时夸奖和给物质激励

3. 有担当：有成绩是团队的，有错误是自己的，时时刻刻照顾好兄弟姐妹，这才是管理，做好救火队员，做好大砖头（哪里需要哪里搬），做好纯牛马。这才是好的管理者

   管理本身就是舍身为人，只有团队好了，管理者才会获得自己的成就和物质回报。
   哪些人不适合当管理者？

4. 自恋的人：获得一点成就就夸夸其谈的，生怕天下人不知
5. 自私的人：帮助他人的发心不对，利用成员的人心恶来操控他人
6. 不会分享的人：先有舍才有得，财散人才聚

赞同，再加上一条慈不掌兵，为什么？我个人的体会是，企业和团队要发展，特别确保公平以及不断进化的前提下，总归会有优胜劣汰的，过程中对于个人的心力考验特别大。（ “慈不掌兵，情不立事，义不理财，善不为官” - 过于仁慈的人不适合带兵打仗，太重感情的人不能做成大事，义气过重的人没办法管理财务，过于善良的人无法做官）

个人业余时间做的产品如何低成本找到用户?

世间一切都没有低成本一说：

1. 做产品要全身心投入，业余做的产品，竞争力怎么比得上别人团队全职做的？
2. 获客推广就是要投入，不管钱和时间，都要持续投入，不舍得钱，怎么能够获客？

3. 那些自媒体每天渲染，别人怎么低成本赚钱，但是他们从来不说别人无数次失败和试错的背后成本。

   不要期望一步登天，也不要期望业余时间和低成本能赚到钱，那都是不是投机，那是做白日梦。

持续投入时间和金钱，不断改进，真心服务好客户，静待花开，这个就是之前老板带着目前这个产品设计开发的心态，挺好，就是可以预见很长一段时间都没收入，这个问题是最要命的，如果需要收入的话，话说不是财务自由，谁不需要钱吗？

在職涯以外，編程和其他相關知識為你的人生帶來了哪些影響？

推友问： 在職涯以外，編程和其他相關知識為你的人生帶來了哪些影響？
我的回答：
好问题

1. 编程思维：严谨的逻辑思维长期训练，生活中遇到的事情也可以受益，比如 2 个月前车被蹭了找不到人，就可以运用逻辑推理，从周边视频、行车记录仪、AI 增强图像、微信挪车、抖音查交通法到和交警周旋，靠技术硬控让对方 2 个小时内赔偿我，而不是自认倒霉 https://x.com/manateelazycat/status/1907809098357420448
2. 产品思维：凡是不要认为是 0 和 1，对和错，要考虑争执后面的利益和需求。这样和我家领导相处时，就知道多给她情绪价值比争对错，更利于家庭和睦
3. 历史思维：做事更看长期，而不是看短期，短期的争对错、相互比较、追求名利都不是认知的问题，而是思想不成熟，不会用冷静的方式去展示力量。多看历史，就知道先贤古圣要比我的认知强很多，坚持走大道，静等花开

看了真是觉得说的好啊，特别是历史思维，自己还是需要多读历史。

Vibe Coding 一段时间后的感受 | Limboy

这里的「迫使」是积极的。Agent 的出现，将程序员从繁琐的具体代码实现中解放出来，让我们能像 Kent Beck 所说的那样，去思考「真正宏大的想法」　 [01:13:36]。我们的核心竞争力不再是写代码的速度或对语言语法的熟练度，而是产品感、架构能力、任务拆解能力和战略眼光。
编程的本质正在回归——将复杂的问题，分解成计算机可以理解并执行的简单步骤。只不过这一次，我们操作的「计算机」拥有了更强的理解力和执行力。这要求我们站得更高，看得更远，专注于创造真正的价值。

还是那句话，编程的门槛提高了。

17分钟带你沉浸式体验攀登珠峰，这也是人类历史上第一次有人拍摄完整的珠峰路线，4K高清_哔哩哔哩_bilibili

在拍摄整个珠峰路线中，我带了9块无人机电池、5个充电宝、一块太阳能板，负重超过氧气瓶的重量。要完成全段的拍摄，我需要从不同的营地起飞，分别是大本营、c1、c2、c3、c4、8848米的顶峰。在拍摄第一段一镜到底的昆布冰川时，9天我共飞行了不下6次，期间我从冰川上滑倒，腰部砸到石头受伤差点断送攀登珠峰的机会。在拍摄c4-顶峰时，第一次是超过70km/H的暴风雪未能完成拍摄也未能完成冲顶，也是这次极端天气后我感染上了严重的肺炎，三天后我再次带病冲顶，我把无人机背到了珠峰顶上，这是我差的最后一个顶峰航拍镜头，可惜当时顶峰已经开始挂暴风雪无法正常起飞和拍摄。下撤回7950米的c4后拍摄C4-顶峰路线时我是咳血状态飞的，顶上山脊的风很大、图传信号也非常不稳定，无人机在飞过8700米后丢失图传终究未能回来。所以8750米后的路线我用的珠峰南面特写视频，上面可以清晰显示剩下的路线。

无比的震撼，佩服 up 主的精神。

(Writing an LLM from scratch 系列)[https://www.gilesthomas.com/2024/12/llm-from-scratch-1]

推荐一下，书和这一系列博客都还没看。

关于 AI 辅助编程的一些实践和思考

采用 AAC 后，开发范式会发生转变，开发者的角色从以「写代码」为主，慢慢转向「设计架构、分解任务、优化 Prompt、Review 代码」。越早适应这种转变，强迫自己提升对应的能力，越能取得优势。

非常好的文章，之前我和不同聊的时候提过一个观点，目前其实对于写代码不是要求变低了，而是趋向更高了，这里高了的意思其实指的是上面这个意思，同时也是说低级编码会越来越没空间。

构建高效 Agent - 译

这些框架通过简化调用 LLM、定义/解析工具以及串联多次调用等标准底层操作，使开发者可以更轻松地入门。但它们往往也会增加额外的抽象层，可能掩盖底层提示与回复，从而导致调试难度上升。此外，这些框架也可能让你陷入一种“添砖加瓦”的诱惑：在一个简单的设置就够用的情况下，去增加不必要的复杂性。
因此，我们建议开发者先直接使用 LLM API：很多模式只需几行代码就可以实现。如果使用框架，一定要了解其底层代码的逻辑。对于底层实现存在错误假设，是导致客户出错的常见原因。

是的，非必要不要用封装好的框架，有助于调试问题也有助于了解整个工作机制。

KubeCon China 2025 见闻

总的来说我今年的感觉是：

• Kubernetes 已经成为一个相当成熟的基座，任何可以在 K8s 上跑的东西最终都会被搬到 K8s 上跑 （

• AI 让 CloudNative 社区焕发了新生，围绕 AI 在过去两年间涌现了许多新的 CloudNative 项目。AI 话题已经成为了 KubeCon 绝对的主旋律。

  • AI 部署部分主要在讨论 AI 推理，关键技术点：分布式推理、扩缩容与 LLM-Aware 的负载均衡以及 AI 模型分发
  • AIOps 也有好几个讨论，简单的用法就是 ChatBot，复杂点的会尝试使用 Multi-Agent 完成更复杂的任务（比如云成本分析优化）。
• 快手尝试在超大规模集群中利用 Logs/Metrcis 为每个服务训练一个模型用于动态调整 HPA，实现 SLA 与成本的平衡（如果我记错了概不负责 hhh）。

• OpenTelemetry 日渐成熟，已经很接近它统一 Logs/Traces/Metrics 三大 Signals 的目标了。

  • 目前已经出现了 Uptrace 之类的大一统观测平台，充分利用了 OTel 的标签来关联 Logs/Traces.
  • 当前的最佳实践是，在 Infra 层面仍然使用传统方式采集 Logs 与 Metrics，而在 APP 层面则改由 OTel 统一采集所有 Logs, Traces 与 Metrics，OTel 会通过 Span ID 把这些数据关联起来， 而且标签语义完全一致。
• WASM 仍在探寻自己的应用场景，今年介绍的场景主要是在边缘侧跑小模型。

说的 OpenTelemetry，有兴趣，需要好好的了解一下，看看如何在发展，其他部分其实不是围绕 K8s 本身，K8s 本身我看着能力其实没啥大的发展，而且对于 K8s 目前其实有很多不同的声音，资源的过度占用以及运维复杂度。

Andrej Karpathy: Software Is Changing (Again)

微信上的总结文章，是个很好的补充：前特斯拉 AI 负责人：随着 FSD 越来越好，神经网络同时也“吞噬”了自动驾驶的软件栈...

还在琢磨中，到底后面自己能干点啥，围绕 AI/LLM?