MaiYangAI - AI, Cursor, Gopher, OpenSource Fans, 成长之路有我相伴。

已更新至	最近更新时间	主持人	简要介绍	订阅方式
131 期	2020-09-23	张晶、徐涛、冯兆音 ⭐⭐⭐⭐	两个驻美记者主持的播客，带你看不一样的世界。	声东击西 Overcasts Google Podcasts
69 期	2020-09-22	梁杰 ⭐⭐⭐⭐⭐	程序员的闲聊节目。	ggtalk Apple Podcasts
48 期	2020-09-18	黄海、Rio ⭐⭐⭐⭐⭐	从投资视角探讨商业现象背后的本质。做最好的中文商业类播客。	疯投圈 Apple Podcasts
60 期	2020-09-17	Rio、吴涛 ⭐⭐⭐⭐⭐	一档由 Rio 和吴涛主持的科技播客。号称硬核，可也没什么干货。想听的人听，不想听的人就别听。	内核恐慌 Apple Podcasts
40 期	2020-09-14	阿乐 ⭐⭐⭐⭐⭐	一档探索内心、接纳自我、努力变优秀的播客，讲述来自各行各业小人物的工作、思考与生活，不限于欧洲生活、高效工作、海外求职、读书电影、美食旅行。	小人物 Apple Podcasts Google Podcasts Spotify Overcast
18 期	2020-08-19	Manjusaka, Adam Wen, 赖信涛, laike9m ⭐⭐⭐⭐⭐	聊聊 Python，聊聊编程，聊聊人生。	捕蛇者说 Apple Podcasts Google Podcasts Spotify Overcast
20 期	2020-05-19	迈凯伦车迷俱乐部 ⭐⭐⭐⭐⭐	一档由麦克拉伦车迷做的 F1 主题播客节目。	麦迷说 Apple Podcasts Google Podcasts Spotify Overcast
95 期	2020-03-24	Terry Tai, Daniel Lv, DingDing Ye, Kevin Wang ⭐⭐⭐⭐⭐	Teahour.fm 专注程序员感兴趣的话题，包括 Web 设计和开发，移动应用设计和开发，创业以及一切 Geek 的话题。	Teahour Apple Podcasts Overcast

Golang Channel

Sun, 11 Oct 2020 07:21:00 +0800

YouTube

Golang Channel	Intro	Subscribers
justforfunc: Programming in Go	Series of talk recordings and screencasts mainly about Go and the Google Cloud Platform	33.1K subscribers
The Go Programming Language	Videos about working with the Go Programming Language.	26K subscribers
Gopher Academy	Gopher Academy	20.1K subscribers
dotconferences dotgo	Tech Conferences, re-invented.	17.9K subscribers
GopherCon UK	GopherCon UK	8.35K subscribers
Go In 5 Minutes	This channel has weekly 5 Minute Screencasts that each contain a focused, self contained tip, best practice or pattern related to programming with the Go programming language (http://golang.org).	6.48K subscribers
package main	“package main” is all about Go - for beginners or advanced engineers, everyone is welcome an I hope everyone can find something useful and interesting. It contains real-world tutorials, where we'll build real things together.	5.47K subscribers
TalkGo	Weekly Go Online Meetup via Bilibili	4.07K subscribers
Asta Xie	Gopher China 大会的一些视频回看	3.37K subscribers
Singapore Gophers	Singapore Gophers	2.99K subscribers
Bo-Yi Wu	http://blog.wu-boy.com/	2.16K subscribers
Changkun Ou	Science and art, life in between.	1.56K subscribers
GopherCon Europe	GopherCon has arrived to Europe on 2018 and we're traveling the continent: 2018 - Reykjavik, Iceland 2019 - Tenerife, Canary Islands 2020 - Online 2021 - Berlin, Germany	1.36K subscribers
Go Northwest	Go Northwest is a single day, community-driven conference devoted to the Go programming language held in the Pacific Northwest. https://gonorthwest.io/	836 subscribers
GopherCon Israel	GopherCon brings the Israeli Go community together through its events. The GopherCon brand is well known and respected for its high standards and diverse appeal.	677 subscribers
Golang Taiwan	Golang Taiwan 是由一群熱愛 Go 語言的台灣 Gopher 所組成的開發者社群，定期舉辦跟 Go 相關的技術活動，醞釀 Go 開發社群能量	411 subscribers
Forge Utah	The Utah FORGE team at the University of Utah is committed to publicizing and improving basic knowledge of geothermal energy and EGS technologies.	148 subscribers
Utah Golang User Group	Presentations from the Utah Golang User Group (#UTGO)	92 subscribers

Bilibili

Golang Channel	Intro	Subscribers
土妹编程	硅谷老年(senior)程序员，认真做对技术人有帮助的干货视频！	1.7 万粉丝
Go 夜读	所有与 Go 相关的技术知识、架构实践，TalkGo 读书会的阅读清单，读书笔记，读书小结等。	1.4 万粉丝
eggo-tech	公众号：幼麟实验室。我们师徒二人，就想做点儿形象通透的编程教程。	5674 粉丝
面向加薪学习	专注于Go、Java、Flutter、Vue、React、Taro、小程序、Android、项目管理、软件架构	3202 粉丝
GopherChina	GopherChina	2396 粉丝
欧长坤	https://changkun.de	725 粉丝

我的书单

Thu, 07 May 2020 21:00:00 +0800

计划读

书名	评价
《客户成功》
《第一性原理》
《开放式组织》
《从优秀到卓越》
《请停止无效的努力：加速升级你的眼界、心智和能力》
《大国政治的悲剧》
罗素《幸福之路》	来自于拼多多黄铮
《三十岁：一切刚刚开始》
《分析与思考：复旦大学的经济学课》

已读（部分）

仅列出我使用『阅读记录』 App 所记录的已读书籍，。

书名	评价
《暗时间》	强烈推荐，书中有很多心理认知理论和阐述都让我有了新的了解。
《见识》	强烈推荐，吴军老师写的书都值得我们互联网从业者仔细阅读。
《数学之美》	强烈推荐
《香侬传》	了解香侬的一生，也能了解到咱们计算机发展历史。
《卓有成效的管理者》	管理者可以变成卓有成效的一些实践经验分享。
《终身成长》	成长思维
《极简主义》	本书一般，看书摘的几个阐述跟文中所述完全不一样。
《重新理解创业》	强烈推荐。
《未来架构：从服务化到云原生》	一些概念普及而已，不值得精读，不了解云原生的，可以快速过一遍。
《Linux 性能优化实战》	倪朋飞老师的极客时间专栏，跟着 TalkGo 读书会的小伙伴们一起在2个月内读完，非常不错的专栏。
《Google SRE：运维解密》	DevOps 与 SRE 究竟有何不同？
《深入理解计算机系统》	计算机领域的龙书，必须精看。有兴趣参与活动点击链接
《数学之旅》
《人生中必要的失去》	每当我们见到他人并尊重其高尚人格时，就是在帮助周围的人。
《活法》	我们人生的意义是什么? 人生的目的在哪里？对于这个人生最基本的问题，我认为必须从正面回答。我的答案是：提升心性，磨练灵魂。怎样才能成为自然型的人呢？喜欢自己的工作。
《有限与无限的游戏》	世上有且只有一种无限游戏。
《价值》	每一个不善于学习的孩子都有强大的帮助别人学习的内在力量。
《如何高效阅读一本书》	实操手册
《解密 Instagram：一款拍照软件如何改变社交》	前面几章可以看看，后面都是一些勾心斗角权衡利弊的小故事，但是这些故事又不深入，不值得看。
《不拘一格》，Netflix 的用人观

想读（部分）

书名	评价
《思考，快与慢》	刚开始看，书中对于快与慢有不少有意思的案例。比方说，小学三年级数学题：和差问题。
《哈佛家训》	子女教育的鸡汤书，可以慢慢看完它。
《谈判》	看过前面4章，然后就中断了（已经几个月了），但是这本书我一定要花时间把它看完。
《瓦尔登湖》
《第一性原理》
《开放式组织》
《从优秀到卓越》
《请停止无效的努力：加速升级你的眼界、心智和能力》
《大国政治的悲剧》
罗素《幸福之路》	来自于拼多多黄铮
《三十岁：一切刚刚开始》
《分析与思考：复旦大学的经济学课》

想读的真的太多了，但是我们不能贪心，所以我就不罗列他们了。

「阅读之美」免费知识星球

我会将阅读笔记以及一些感受，分享到「阅读之美」知识星球，欢迎大家一起来分享和交流。

关于我

Fri, 13 Jul 2018 10:00:00 +0800

2025 年 5 月，成为 Cursor 中国区首位 Ambassador，并举办了 10+ Cursor 官方活动
2021 年 9 月，我回到深圳，加入了一家全球化电商 SaaS 创业公司。
之前在 2c 赛道做过将近 9 年，一直在技术和管理方向，经历过大大小小各种复杂的应用场景（秒杀、亿级 API 调用、百亿级的数据量存储、微服务架构等）。
对 Go 情有独钟，也是一个开源爱好者，Go，TiDB，logkit, kingshard 等多个开源项目的 Contributor，Go 夜读社区发起人，TGO 深圳董事会成员，任职 2 年 TUG 华南区 Leader，多次深圳地区 Gopher meetup 的组织者和分享嘉宾。
最近这2年疯狂的喜欢上了 F1，偶尔也看看 NBA 和欧洲足球比赛，偶尔也会徒步，带着家人到处旅行（多次 1700+ 公里的驾驶经历）。

如何评审一份让听众真正有收获的分享 PPT

Fri, 29 May 2026 19:33:00 +0800

如何评审一份让听众真正有收获的分享 PPT

这套方法来自于我最近的一次真实大会分享经历。

PPT 在线版： https://cursor-insider.com/talks/ai-maker-summit-2026/

我曾在 AI Maker Summit 上做过一次关于 AI、Coding Agent 和 Cursor 实践的分享。为了这次分享，我自己完整演练过，也根据现场节奏做过调整。在此之前，我其实已经以评审者视角，参与过多次大中小型各种大会内容评审。

我既作为演讲者站在台上表达，也作为评委去看别人如何组织内容、传递观点、打动听众。同时，我还把我的分享内容讲给培训部门的同事听，并收到了非常直接的反馈。

这些反馈让我重新意识到：一份分享型 PPT 不能只看信息量，也不能只看视觉设计。真正重要的是，听众听完之后有没有收获，有没有理解你最想传达的核心问题，有没有产生“我也想试试看”的冲动。

培训同事给我的反馈就是大多数人会遇到的典型问题：内容很大，但留下的收获点不多；那我的分享内容来说，我的标题后半段是：Coding Agent 新范式，从试讲来看，它听起来体感不强，有些昏昏欲睡；相比抽象概念，他更想知道 Cursor、Agent、Context Engineering 这些东西到底怎么和自己的日常工作连接起来。

这其实点出了分享型 PPT 最容易犯的问题：主题看起来很高大上，内容也很完整，但听众不知道和自己有什么关系。

其实评审一份分享型 PPT 还有诸多可以注意的地方，接下来，我就尝试把我自己的经验提炼总结，并且也开源一份 Skills，希望它可以帮助到我，也可以真的帮助到你。

好了，我认为我们应该优先看七件事：

1. 标题是否足够鲜明和落地

标题不是包装，而是承诺。

一个好的标题应该让听众知道：这场分享到底解决什么问题，和我有什么关系，我听完可能获得什么。拿我前面所讲到的这个分享主题来说，如果内容真正讲的是 Context Engineering，而标题还停留在宽泛的 AI Coding 新范式，就会让预期和内容错位。

评审标题时，可以直接问：

这个标题是否切合实际内容？
这个标题是否太大、太虚、太像概念？
听众看到标题后，能不能判断自己为什么要听？

2. 个人介绍是否服务于分享

个人介绍页不应该是头衔陈列，而应该回答一个问题：为什么由你来讲这个主题？

为什么我可以讲 Cursor 相关话题？一方面，我是 Cursor 用户，另一方面，我是 Cursor 中国区首位 Ambassador。

能帮助听众理解你视角的信息才需要出现。比如你是实践者、演讲者、评委，或者做过内部宣讲并收集过反馈，这些信息就有价值，因为它们解释了这套方法不是纯理论，而是来自真实场景。

反过来，如果某个头衔不能帮助听众理解这场分享，或者不能增强内容可信度，就没有必要放上去。除非一个人资历非常丰富，头衔本身能形成足够强的信任感，否则个人介绍应该尽量简练。

3. 开场是否建立问题感

分享不应该一上来就进入概念，而应该先让听众进入一个共同问题。

这个问题可以来自一个反问、一个互动、一个数据、一个真实场景，或者一个具体冲突。例如：

为什么有些 PPT 信息很多，但听完之后大家还是不知道该做什么？

这个问题一旦成立，后面的内容才有承接。听众不是为了听你展示知识而来，而是为了理解一个和自己有关的问题，并找到一个可能的解法。

4. 结构是否围绕一个核心要点展开

一般的分享 PPT 最好不要试图同时讲太多东西。大会分享尤其如此，听众时间有限，注意力也有限。

好的结构通常是总分总：

先抛出核心判断
再分层展开论据、案例和方法
最后回到 Takeaway

大纲的每个部分最好单独占一页，让观众知道自己走到了哪里。结构不是为了显得完整，而是为了帮助听众跟上节奏。

如果一份 PPT 看起来覆盖很多主题，但听众听完只能记住“内容很多”，那就说明核心没有收住。

5. 页面是否帮助演讲，而不是替代演讲

PPT 页面不应该承担讲稿的职责。

页面上的文字应该是观众需要记住的锚点，而不是完整讲稿本身。复杂观点应该靠讲述展开，PPT 负责提供节奏、重点和记忆点。

因此，评审时要特别注意几类问题：

是否有大段文字
是否出现“下一页”“One more thing”“回扣 Act 2”这类讲者提示
是否出现讲起来很拗口、但放在页面上又很抽象的句子
是否把解释性内容放错了层级

如果一句话你自己演练时都接不住，或者讲起来不自然，那它大概率也不适合放在 PPT 上。

6. 听众是否能带走可迁移经验

对于 AI 工具、Coding Agent、Cursor 这类主题，听众不只是想听概念。他们更想知道：

我明天能怎么用？
我应该从哪里开始？
有什么坑？
有什么判断标准？
这个经验能不能迁移到我的日常工作？

所以，比起讲“新范式”，更应该讲清楚一个具体经验：如何给 Agent 提供上下文，如何拆任务，如何评估输出，如何把它接入自己的日常流程。

这也是“内容有体感”的来源。体感不来自概念本身，而来自真实案例、演练经验、失败教训、现场反馈和可执行路径。

7. Takeaway 是否完成收束

好的总结不是重复前文，而是把整场分享重新提炼成几个可以带走的判断。

Takeaway 最好回到开头提出的问题，并给出清晰的行动方向。过程中如果有金句或核心观点，也应该在最后被重新提炼回来。

最后的升华可以引用一句话、一个行业判断，或者一个更高层的问题，但前提是它和前面的内容自然连接，而不是为了显得有高度。

一套简化评审标准

评审一份分享型 PPT 时，可以按以下维度打分：

标题落地性：标题是否准确表达核心内容和听众价值
听众匹配度：内容是否匹配目标听众的经验、需求和场景
开场吸引力：是否快速建立问题感和注意力
结构清晰度：是否总分总，是否有清楚的章节节奏
页面表达质量：是否精炼、可讲、无讲者提示、无大段文字
经验可迁移性：是否提供可复用方法、案例、路径或行动建议
总结有效性：是否把核心观点收束成清晰 Takeaway

如果只能保留一个评审原则，我会保留这一句：

不要只评审 PPT 做得好不好看，而要评审它是否围绕一个核心问题，带领听众从理解走向行动。

一份好的分享 PPT，应该让听众在结束时至少带走三样东西：一个新的判断，一个可复用的方法，一个愿意尝试的下一步。

如果你也想用这套标准评审自己的分享 PPT，我把完整评审流程整理成了一个 Cursor Skill，放在 GitHub 上：presentation-core-review。在 Cursor 里引用这个 Skill，就可以按同一套标准做结构化评审。

从一个念头到上架 Store：我是如何做出 Lock Time 的？

Tue, 17 Mar 2026 21:29:00 +0800

起因

事情最早发生在今年我在家 remote 的那段时间。

我每天都在 Mac 上工作，也每天都在锁屏、解锁、离开、回来。

但有一个问题我一直不知道答案：我一天到底锁屏了多久？

你可能会觉得这不重要，但我后来越来越觉得，这其实是一个很有意思的数据。

锁屏，意味着中断。解锁到下一次锁屏之间，意味着一段连续工作的时间。

如果这些东西能被记录下来，它至少能帮助我更诚实地看待自己的工作节奏，而不是只靠感觉。

Raycast 是我每天都会打开很多次的工具。所以当我想到这个需求的时候，第一反应不是“去 App Store 找找有没有现成产品”，而是：

要不，我自己做一个 Raycast Extension 试试看。

这个想法当时就种下了。

真正把它做出来，是在过年期间。

那几天我刚好有一段比较完整的时间，也想试试看：借助 AI，我能不能把这样一个自己真会用到的小工具，尽快做成一个可用的版本。

这就是 Lock Time 的起点。

也是我第一次认真写一个 Raycast Extension 的起点。

先把问题想清楚

这次我没有一上来就写代码。

我先写了一份很小的 PRD。原因也不复杂：越是这种“小工具”，越容易边做边歪。你本来只是想解决一个很具体的问题，写着写着就想加统计、加分析、加建议、加同步，最后把自己拖进泥潭。

我当时只想清楚了三件事：

我要记录什么？
我怎么知道系统现在是不是锁屏？
数据应该存在哪里？

最后收敛下来的答案也很朴素：

记录今日累计锁屏时长
记录上一次锁屏持续了多久
记录上一次连续工作了多久

检测方式先用轮询，数据存本地，用 Raycast 的 LocalStorage，完全 local-first，不碰网络。

边界一旦清楚，事情就会轻很多。

我不做复杂分析。我不做跨设备同步。我也不做那种“根据你的锁屏习惯给你人生建议”的功能。

我只想把时间事实记录清楚。

第一个版本，比我想得快

Raycast 给新手的第一印象其实非常好。

我用 npx create-raycast-extension 把项目拉起来之后，基本没怎么折腾环境。npm run dev 跑起来，改完代码，Raycast 里就能实时看到效果。

这种反馈速度很重要。

你会明显感觉到，它不是那种“先研究半天平台规则，才能开始写功能”的扩展生态。相反，它更像是在说：来，先做出来，我们后面再慢慢把细节做好。

而且 Raycast 的 API 设计很克制。

List、Detail、Action、MenuBarExtra 这些组件不算多，但够用了。对于我这种第一次接触的人来说，这种“够用但不过度复杂”的感觉非常舒服。

加上那段时间我也一直在比较重度地用 AI 协助开发，所以第一个 MVP 出来的速度，比我预想中快很多。

不到一天，我就已经能在本地看到一个真正能工作的版本了。

说实话，那一刻是很上头的。

因为你会突然意识到：

原来一个自己每天都想用的小工具，真的可以在一个周末里长出来。

真正难的，不是写出来，而是把它做对

真正的难点，出现在第一个版本跑起来之后。

这也是我后来越来越喜欢这种“小产品”的原因。它们表面上很小，但只要你想把它做得靠谱一点，问题就会一个接一个冒出来。

MVP 做出来很快，但后面这些坑，确实来来回回花了我不少时间。

第一个坑：macOS 26 上锁屏检测完全失效

在一开始就发现一个严重问题：

在 macOS 26 上，所有时间指标几乎都是 0。

这不是“有点不准”，而是“完全不能用”。

后面一路排查下来，我才慢慢意识到，问题不在业务逻辑，而在我最初采用的那套检测方案上。更准确地说，这套方案本身也不是我自己拍脑袋定的，很多实现思路和排查方向其实都是 AI 给出来的。

但问题就在这里。

因为我自己对这部分偏系统层的能力并没有那么熟，AI 给的方案虽然能快速帮我起步，也能不断给出新的尝试方向，但一旦踩进坑里，我其实很难第一时间判断它到底哪里不对。

所以后面基本就是靠 Cursor debug，再加上多个 AI 模型来回试、来回查，才一点点定位到问题。最后确认是 JXA 的 ObjC bridge 在这个系统版本上并没有稳定工作，桥接到 CFDictionary 这一步就已经不可靠了。

最后改成 Swift 原生调用 CGSessionCopyCurrentDictionary()，问题才真正解决。

第二个坑：首屏加载慢得离谱

锁屏检测修好之后，又来了第二个问题。

每次打开 Lock Stats，都要等大概 3 秒。

3 秒看起来不长，但放在 Raycast 这种“我按下快捷键就想立刻看到结果”的场景里，已经很难接受了。

继续拆之后发现，瓶颈不在 React，也不在数据处理，而在 Swift 解释器的启动开销。

也就是说，功能没问题，但用户感知就是慢。

后来我换了一个思路：

不要让用户每次都等“最新结果”出来。先把缓存展示出来，再在后台异步刷新。

也就是一个很朴素的 stale-while-revalidate 策略。

改完之后，首屏体验立刻顺滑很多。

这件事让我再次确认了一点：

很多时候，性能优化不是让程序更快，而是先让用户别等。

功能做完之后，上架 Ryacast Store 又是另一道坎

等功能能用了、体验也顺了之后，我开始准备把它真正送去 Raycast Store。

一开始我其实有点犯怵。

因为“上架”这两个字，天然会给人一种很重的感觉。你会下意识以为，审核流程很长、规范很多、仓库很大、门槛很高。

但等我真的做起来，才发现它也不是那种“照着文档过一遍就结束”的事情。

虽然有 AI 的帮助，也有官方文档可以参考，但实际跑下来也不是一次就能过。第一次准备 Store 的时候，你还是会不断去确认：这里到底是不是硬性要求，那个文件要不要补，这种格式写法会不会不过，截图和图标是不是还得重新弄。

不过，换个角度看，相比 Apple 那种更偏黑盒的审核，Raycast 这套已经算清楚、友好多了。

我自己最先撞上的，就是 lint 和构建。

这听起来像废话，但真不是。

我就碰到了 @raycast/eslint-config 升级之后的兼容问题，直接报：

`1`	`TypeError: Unexpected array.`

最后是手动 flatten 配置才过掉。

这种问题如果你不在本地把 npm run build 和 npm run lint 跑干净，等 CI 再告诉你，节奏就会一下子断掉。

接下来就是那些看起来不难、实际上很花时间的东西：CHANGELOG、README、截图、图标、命名、描述。

你平时本地自己用的时候，不太会在意这些细节。真要上 Store 了，它们就一个都绕不过去。

尤其是 README 要英文、CHANGELOG 要按它的格式、截图和图标也都有讲究。这些地方你很难说哪一项最难，但它们会把你一点点拉进“这已经不是我自己本地用的小工具了”的状态里。

提交 PR 这一步，我也研究了挺久

等前面的东西都准备好之后，真正提交到 raycast/extensions 仓库，还是比我最初想的顺了一些。

我原本以为，面对一个那么大的 monorepo，我得先完整 clone 下来，再研究半天目录结构，最后才能开始提 PR。

后面才知道，没必要把自己吓住。

通过官方文档里的 sparse checkout 方式，你其实只需要拿到必要的部分就够了。

如果你也准备提自己的第一个 PR，我非常建议先看这两篇：

我自己实际走下来，大概就是 Fork、clone、把扩展目录整理进去、本地确认能过、然后提 PR。

说起来不复杂，但我前前后后其实也研究了不少时间。

而且最后我能顺利把 PR 提上去，社区里的帮助也非常关键。比如 @alexi_build，他是 100daysofraycast 的作者，现在也在做 Raycast weekly newsletter。他提醒我不用傻乎乎地把整个仓库完整拉下来，这种信息对于第一次提 PR 的人来说，真的很有用。

所以回头看，这一步不是“很轻松就搞定了”，而是我自己先摸索了挺久，最后在社区帮助下把路走通了。

提交 PR 之后，才发现真正的 review 才刚开始

我原来以为，PR 提上去，CI 过了，接下来就是等人工审核。

后来才发现，事情没有那么简单。

Raycast 那边的 review 里还有 AI Code Review，Greptile 这一类自动化审查也会参与进来。于是整个过程并不是“一次提交，然后等结果”，而是来来回回改了好几轮。

这种 review 体验其实有点折腾。

你会感觉要求确实不低，很多细节并不会因为“这是你第一次提扩展”就被轻轻放过。

但换个角度看，也正是这些来回修改，才让它最后不像一个仓促拼出来的版本。

社区这件事，这次我是真切感受到了

以前我也知道文档重要，知道开源生态重要。

但这次自己从头走完一遍之后，感受会更具体一些。

比如文档确实能帮你少走很多弯路，已有扩展也能给你很多参考。再比如有人一句话提醒你 sparse checkout 怎么弄，可能就直接帮你省掉半天时间。

这种帮助不一定有多宏大，但对第一次做的人来说特别重要。因为很多时候，卡住你的不是代码本身，而是你不知道下一步该往哪里走。

“Raycast is a lifestyle”

2026 年 1 月 11 日，我在 Raycast Meetup Shenzhen 现场听到 Thomas Paul Mann 说了一句话：

Raycast is a lifestyle.

那一刻我其实挺有共鸣的。

以前我听到这句话，更多是觉得它说得挺好。

但这次自己真的从一个小念头开始，把 Lock Time 做出来、提上去、改 review、最后上架之后，我会更能理解那种感觉。

因为 Raycast 对我来说，已经不只是一个启动器了。它确实变成了一个“我想到一个小需求，就愿意顺手把它做出来”的地方。

最后

回头看，从一个很小的念头，到真正成为一个 Raycast Extension Author，中间其实没有什么特别戏剧化的故事。

如果只看 MVP，本质上就是过年期间很快做出来的一个版本。

但如果看完整旅程，它绝不是一个“周末项目”那么简单。

大概是这样一个节奏：

在家 remote 时想到这个需求
过年期间借助 AI 很快做出 MVP
来来回回修掉锁屏检测和首屏性能这些坑
花不少时间研究 Raycast Store 提交规范和准备材料
在社区帮助下成功提交 PR
经过多轮 review 和等待，最终真正上架

在这个过程中，没有 AI 就没有这个 Extension 的成功上架， AI 正在切实的改变我们的构建过程。

未来，人人都是 Builder。

至少对我来说，它最大的价值不是“替我写完”，而是让我在很多本来会犹豫、会卡住的地方，能继续往前走。

正式成为 Raycast Extension Author 的时间，是 2026.03.03。

当时我还发了一条推特动态： I became a Raycast author

现在回头看，Lock Time 是我的第一个 Raycast Extension，但大概率不会是最后一个。

因为当你真的把一个脑海里很小的需求，做成一个自己每天都能用到的东西之后，那种满足感还挺直接的。

如果你也一直想做自己的第一个 Raycast Extension，我的建议其实只有一句：

不要上来就想做一个很大、很完整、很厉害的东西。

先找一个你自己每天都会遇到、但还没人替你解决好的小问题。

从那里开始，就够了。

用 Warp AI 秒杀 Python 依赖问题：从 2 小时到 2 分钟

Tue, 06 Jan 2026 12:15:00 +0800

起因

今天中午在更新一个本地构建的工具代码库之后，遇到一个很典型的 Python 依赖冲突问题。运行 make sync 时，uv 抛出了这样一个错误：

1
2

× Failed to download and build `rcpy @ file:///Users/xxx/.cache/uv/git-v0/checkouts/2c7e3387374b92cc/rcpy`
  ╰─▶ The source distribution has no subdirectory `../rcpy`

说实话，我看到这个错误的第一反应就是又是烦人的依赖路径问题。如果是以前，我可能需要：

检查 pyproject.toml 配置（几分钟）
翻看 uv.lock 文件（几分钟）
逐个检查此项目的所有子依赖配置（20-30分钟）
Google 搜索类似问题（20分钟）
尝试各种清缓存、重新安装的方案（40分钟）

保守估计，至少要 1-2 小时才能搞定。而且如果对项目不熟悉，可能要更久。因为很多时候你不太了解全貌，且近期可能是第一次遇到，之前的经验可能也忘记的差不多了，又是一番骚操作你可能才会慢慢想起来最佳实践。

但这次不一样

其实在这次使用 Warp AI 之前，我在几个月前同样也有一个寻找本地安装包要删除干净的问题。当时也是直接给 Warp AI 下达任务。任务完成的很不错。这一次，我也是直接把错误信息丢给了 Warp AI。

没有搜索，没有翻文档，甚至没有怎么仔细思考。就是简单地把错误日志粘贴过去，然后看着 Warp AI 开始思考并直接开始工作。

AI 的解决过程

Warp AI 的处理过程让我印象深刻：

1. 快速诊断（30秒）

它首先检查了项目的 pyproject.toml，确认依赖配置正常：

1
2

[tool.uv.sources]
rcpy = { path = "../rcpy", editable = true }

然后验证本地目录确实存在。

2. 精准定位（1分钟）

接着它做了一件我可能要花很长时间才会想到的事：检查子依赖的配置。

它 grep 搜索了所有相关项目，发现了真正的问题源头：

1
2

$ grep -r "rcpy.git" ../lolwpy/ ../slcrawler/ ../lolrd/
../slcrawler/pyproject.toml:rcpy = { git = "ssh://git@github.com/xxx/rcpy.git" }

原来是 slcrawler 把 rcpy 配置成了 git 依赖，而主项目配置的是本地路径依赖。这种冲突导致 uv 无法正确解析。

3. 直接修复（30秒）

找到问题后，AI 直接修改了 slcrawler/pyproject.toml：

1
2
3

[tool.uv.sources]
-rcpy = { git = "ssh://git@github.com/xxx/rcpy.git" }
+rcpy = { path = "../rcpy", editable = true }

然后依次同步依赖：

1
2

cd ../slcrawler && uv sync
cd - && uv sync --all-extras

问题解决。

总耗时：不到 3 分钟。

为什么 Warp AI 这么快

回过头来想，AI 能这么快解决问题的原因是：

1. 系统性思维

人类排查问题往往是线性的：看到错误 → 检查配置 → 试试清缓存 → 不行再找其他原因。

AI 则是并行思考：同时检查主项目配置、子依赖配置、缓存状态、文件系统，然后综合判断。

2. 无需上下文切换

我不需要在终端、编辑器、浏览器之间反复切换。AI 直接在 Warp 里完成所有操作：读文件、执行命令、修改代码。

3. 经验积累

这类依赖冲突问题对 AI 来说见过太多次了。它知道：

uv 的 git cache 可能导致什么问题
子依赖配置不一致会怎样
该按什么顺序排查

而对我来说，可能半年/一年才遇到一次这种问题，每次都像第一次。

更深层的价值

这次体验让我意识到，AI 工具的价值不只是"提效”，更重要的是降低尝试成本。

对于 Python 实验性项目，或者依赖复杂的项目：

以前：看到一堆依赖错误就想放弃，“算了，不折腾了”
现在：直接丢给 AI，“帮我搞定”

这种心态上的转变，会让我们更愿意去尝试新项目、新工具、新技术栈。

不用担心配置地狱，不用害怕依赖冲突，因为知道有 AI 兜底。

什么时候 AI 才真正有用

我用过很多 AI 工具：Poe、ChatGPT、Cursor、Claude Code、Perplexity…

但真正让我觉得"离不开"的，是那些融入日常工作流程的 AI。

Warp AI 的优势就在这里：

它不是独立的聊天窗口，而是集成在终端里
它能直接执行命令、读写文件，而不只是给建议
它看得到我的工作目录、git 状态、执行结果

AI 不需要成为超级智能，它只需要在我卡住的时候，推我一把。

总结

遇到技术问题时：

过去：Google → StackOverflow → 试试看 → 再 Google → 放弃或继续折腾
现在：把错误丢给 Warp AI → 看它解决 → 继续干活

从 2 小时到 2 分钟，这不是 100 倍的效率提升，而是心智负担的巨大减轻。

有时候，技术的进步不在于它能做多么复杂的事，而在于它能让简单的事变得足够轻松。

P.S. 如果你也经常被 Python 依赖问题折磨，不妨试试 Warp。它是免费的，而且真的很好用。

Cursor 设计总监 Ryo Lu 的设计哲学

Mon, 24 Nov 2025 20:15:00 +0800

本文源自于 Y Combiator x Ryo Lu For Design Review. Cursor Head of Design Roasts Startup Websites

《Ryo Lu Design System》 —— 构建面向 Builder 的极简、清晰、可信赖的产品设计体系

制作方法：根据 YC 访谈视频的大量 design review，总结提炼而成。

Ⅰ. 设计哲学（Design Philosophy）
Ⅱ. 设计准则（Design Principles）
Ⅲ. 审美标准（Aesthetic Criteria）
Ⅳ. 反模式（Anti-patterns）
Ⅴ. Builder 向的设计工作方式（The Ryo Working Style）
Ⅵ. 一句话总结 Ryo 的设计体系

Ⅰ. 设计哲学（Design Philosophy）

Ryo 的设计世界观

1. 设计的核心不是“好看”，而是“减少阻力”

Ryo 多次强调：

“Design is removing friction.”

他在点评所有 YC 产品时的第一反应永远是：

“用户会卡在哪里？”
“为什么我看 1 秒钟还不知道这个页面让我干嘛？”
“这个按钮的位置为什么会让我犹豫？”

他的审美本质是一种 “路径阻力最小化”审美。

2. 产品要以“1 秒钟懂你”作为目标

每次批评一个界面不清晰时，他会说：

“I should know what this does in one second.”

这代表了 Ryo 的底层设计原则：

用户第一次看到产品时不需要学习
信息架构必须天然暴露价值
任何需要“解释”的设计都是失败的

3. 简洁不是少，而是“意味清晰”

他对“干净却没有信息”的 UI 非常反感。

“Minimalism is not emptiness. It's clarity.”

Ryo 认为的简洁是：

你删掉了所有会让用户犹豫的东西
你保留了所有让用户顺畅行动的变量

他经常对 YC 产品说：

“你把重要内容藏起来了。”
“你试图做简洁，但你删掉了意义本身。”

4. 用户路径必须“自动引导”

在所有 review 中，他最常讲的一句话是：

“The page should pull me forward.”

意味着路径必须自带引导感，用户无需思考下一步操作。

他对引导感做了几个核心要求：

下一步必须显而易见
主行动（Primary Action）必须自动吸引注意力
不允许界面呈现“平等的按钮”导致用户犹豫

Ⅱ. 设计准则（Design Principles）

Ryo 在 review 中使用的实际判断框架，这里总结成一套公式，可直接用于审查自己的产品。

1. 清晰原则（Clarity Rule）

1 秒钟价值可辨。

检验点：

读标题是否能 instantly 理解产品解决什么问题
页面上的第一视觉点是否就是最重要的信息
所有 icon 必须能直接被理解，不允许抽象化图形

常见批评：

“Your hero section says nothing.”
“I cannot tell what the product does.”

2. 信息优先级原则（Hierarchy Rule）

页面必须形成 强层级结构 —— 主次明确、权重区分。

检验点：

字重与字距是否能体现层级
CTA 是否明显且只出现一个最主
是否存在“全部一样重要”导致的 UI 平铺

Ryo 的典型评论：

“This page has no hierarchy. Everything screams.”
“You need one single obvious action.”

3. 内容稀释原则（Density Rule）

信息密度必须自然、可呼吸，但不能稀薄。

他反对：

产品介绍太空
whitespace 被误用成“设计感”
hero 区域只有一句 vague slogan

他要求内容必须：

有结构
有支点
有承载价值的例子和截图

4. 语义明确原则（Semantic Rule）

文字必须说人话、说行动、说结果。

他在字幕中数十次批评 YC 产品的文案：

“This is generic.”
“What does this actually mean?”

Ryo 的文案框架：

不要写“我们是全新的 AI 平台”
要写“用一行语句生成日报，节省 90% 时间”
文案必须体现 action + outcome

5. 一致性原则（Consistency Rule）

一致性包括：

spacing
grid
组件语义
颜色用途
icon 风格

但 Ryo 特别强调的是：

“Consistency is not about pixel perfection, but about trust.”

一致性是为了让用户觉得产品可靠。

6. 反馈原则（Feedback Rule）

所有动作必须可感知地“发生了”。

常见批评：

“I clicked this but nothing moved.”
“The UI feels dead.”

他对动效的要求是：

subtle
purposeful
never decorative

Ⅲ. 审美标准（Aesthetic Criteria）

Ryo 对“好看”的真实定义，在大量 review 中可以看到他的审美有三个特征：

1. 美来自结构，而不是颜色

他很少评论配色，更多评论：

对齐
排版
信息分组
组件之间的逻辑关系

“Good design is structural clarity.”

2. 美来自行动通顺

他认为“顺”就是美，“卡”就是丑。

3. 美来自减少犹豫感

他会不断问：

这个按钮会让我犹豫吗？
我知道自己即将发生什么吗？
为什么这个表单看起来这么可怕？

犹豫就是设计噪音。

Ⅳ. 反模式（Anti-patterns）

Ryo 在 YC 产品中最常批评的错误

1. Hero 区域没有说人话

反例：

“Reinventing the future of collaboration.”

他会说：

“This tells me nothing.”

2. 所有元素权重一样

反例：

左右两个按钮一样大
所有卡片一样重
所有文本一样深

这是信息架构失败。

3. 图标比文字重要

他最讨厌这种反例：

一个写不明白含义的 icon
没有标签
图标抽象化

4. AI 产品的“Fake Intelligence”

比如：

一堆漂浮 UI
半透明玻璃
科幻装饰

他会直接说：

“Remove the fake AI. Just make it work.”

5. 做设计，而不是做产品

他会指出：

“This UI is more designer-focused than user-focused.”
“You’re polishing the wrong layer.”

Ⅴ. Builder 向的设计工作方式（The Ryo Working Style）

1. 先做信息架构（IA），再做 UI

他会先问：

用户要完成什么？
信息顺序是什么？
下一步在哪里？

只有这些明确后才进入 UI。

2. 永远从“首页”和“首屏”开始

因为这是产品认知的入口。

3. Demo-first

所有界面都必须展示真实内容，而不是 lorem。

4. 快速迭代，不做艺术工程

他会说：

“You don’t need perfect. You need clarity now.”

UI 是不断修正，而不是“一稿定乾坤”。

Ⅵ. 一句话总结 Ryo 的设计体系

Ryo 设计体系的核心是：清晰、引导、可信赖。
少做装饰，多做结构。
不是让产品“更漂亮”，
而是让用户“更不犹豫”。

如何解决 macOS 系统里面 System Data 占比巨大的问题？

Thu, 20 Nov 2025 20:00:00 +0800

当你的电脑使用蛮长时间之后，是不是磁盘空间越来越不够用了？特别是有一个 System Data 占比了 100 GB 以上，这个问题如何解决？

常规的解决办法，肯定是直接把你不需要的文件删除，简便的方法是：

点击屏幕左上角，About This Mac
点击 More Info…
找到 Storage, 点击 Storage Settings…
让程序运行一会儿，系统会自动计算出每个部分的磁盘大小占用
点击 ! 即可自主的清理你不需要的文件。

如果你已经把以上大文件和不怎么需要的文件都清理了，此时依旧没有解决你的磁盘问题。那就需要上强度了。

强度一

去 Mac App Store 找一些磁盘分析管理软件。

强度二

上命令行。（杀手锏）

命令：

> df -h | grep Gi

df -h | grep Gi
/dev/disk3s1s1   460Gi    11Gi    24Gi    32%    447k  256M    0%   /
/dev/disk3s6     460Gi   4.0Gi    24Gi    15%       4  256M    0%   /System/Volumes/VM
/dev/disk3s2     460Gi   7.2Gi    24Gi    23%    1.3k  256M    0%   /System/Volumes/Preboot
/dev/disk3s4     460Gi   2.0Mi    24Gi     1%      64  256M    0%   /System/Volumes/Update
/dev/disk3s5     460Gi   412Gi    24Gi    95%    5.1M  256M    2%   /System/Volumes/Data

命令：查看挂载的盘占用最多的一个： “/System/Volumes/Data”，查看详情。

`1`	`> du -h /System/Volumes/Data \| grep "G\t" \| sort`

给他一些时间，我们就能够发现，它能帮我们列出来一大堆偏系统层面和一些程序隐藏文件。

可能会包括你过往试过的各种软件，删除软件，但是残留了一些缓存、运行日志、运行过程中下载的一些文件、资源等等。

经过这样一顿操作，我的磁盘一下子就剩 140 GB 了，太爽了！

df -h | grep Gi
/dev/disk3s1s1   460Gi    11Gi   119Gi     9%    447k  1.3G    0%   /
/dev/disk3s6     460Gi   5.0Gi   119Gi     5%       5  1.3G    0%   /System/Volumes/VM
/dev/disk3s2     460Gi   7.2Gi   119Gi     6%    1.3k  1.3G    0%   /System/Volumes/Preboot
/dev/disk3s4     460Gi   2.0Mi   119Gi     1%      63  1.3G    0%   /System/Volumes/Update
/dev/disk3s5     460Gi   317Gi   119Gi    73%    4.6M  1.3G    0%   /System/Volumes/Data

Reference

24 岁就能采访顶级大佬：Dwarkesh 如何用 AI 做深度准备？ -- 从「平台式交易」到「网络质量关系」，我学到的一套可复用学习框架

Wed, 22 Oct 2025 20:46:00 +0800

最近我在系统地研究一个播客主：Dwarkesh Patel。

如果你平时听播客或者关注 AI 圈，大概率最近在某个地方见过他的名字。他采访过的人包括 Mark Zuckerberg、Tony Blair、Marc Andreessen、Demis Hassabis、Andrej Karpathy 等一串顶级嘉宾。我一开始只是好奇：一个 20 多岁、没有大公司光环的人，怎么可以约到这些 AI 圈的顶级大佬？

往下挖之后，我发现他背后有一套非常有效的「学习和准备方法论」。其中一篇叫做《The Dwarkesh Method: Deep Preparation Beats Platform Volume》的文章，把他的思路解释得非常清楚——文章本身则是基于他和 Every.to 创始人 Dan Shipper 的一次访谈整理出来的。

在那次访谈里，Dwarkesh 详细讲了他是如何把 AI 工具融入到自己的学习过程，让 AI 真正变成学习的加速器，而不是一个新鲜玩具。

作为一个从后端工程师转到要带人的管理者，我也一直在思考一个问题：**在信息越来越多的情况下，怎么保证自己还有真正“学进去”的能力？**这篇文章，是我对 Dwarkesh 学习方法的一次整理，也是在给自己搭一个可以复用的学习框架，也希望它可以对你有一些参考价值。

核心理念：用“网络质量关系”对抗“平台式交易”

第一次读《The Dwarkesh Method》时，我被里面两个概念卡住了：

network‑quality relationships（网络质量关系）
platform transactions（平台式交易）

后来我发现，这两个概念基本上就是他整套方法的内核。

如果用一个程序员/工程师比较熟悉的比喻：

平台式交易：像是疯狂收藏 GitHub 仓库、公众号文章、知乎回答 —— 数量巨大，但很少真正深入，用完即走。（read it later, never read it）
网络质量关系：更像是你长期维护的几个核心项目/合作伙伴 —— 投入多、节奏慢，但彼此之间有信任，也会产生复利。

放在学习上，平台式交易就是我们经常干的那件事：“看过很多，想不起什么”；网络质量关系则是：愿意和少量重要的书、论文、作者，建立长期的「往返关系」，持续投入时间和注意力。

Dwarkesh 的方法，可以理解为：

用极度深入的准备，去构建一小撮高质量的“知识关系”和“人物关系”，而不是追求内容的数量。

AI 如何将学习效率提升 10 倍

如果说深度准备是心法，那么 AI 就是他修炼这套心法的利器。Dwarkesh 将大型语言模型（特别是 Claude）融入了他的学习流程，极大地提升了信息处理和知识内化的效率。

1. AI 是“可对话的书架”，实现深度解构与重建

传统的阅读是被动的。而 Dwarkesh 把 AI 变成了“可以追问的书”。他会把整本书、多篇论文或复杂的资料上传给 Claude，然后像与作者本人对话一样，不断追问、深挖其中的核心概念。

他的流程大概是这样：

把一本书、几篇论文或一堆材料丢给 LLM（他常用的是 Claude）
然后假装作者坐在对面，围绕每一章不停地问：
- 这段想表达的核心是什么？
- 和上一章的关系是什么？
- 如果我要反对这个观点，有哪些角度？

这样的阅读方式有几个好处：

不懂就即时追问，用自己的语言再解释一遍
把相近概念拉出来对比，避免只记一个模糊印象
主动让 AI 站在“唱反调”的角度，帮自己做一次轻量的反驳

这不仅仅是阅读，而是一个主动的、实时的知识解构与重建过程，强迫自己更深入地思考。对我来说，这种方式有点像把「一次性通读」改成了「不断 review 和 refactor」：每一章都要被质询、拆解、再组织一遍。

2. AI 是“记忆加速器”，用间隔重复对抗遗忘

“读过就忘”是学习最大的敌人。

我自己的体验是：看的时候觉得很好，合上书就只剩下两个形容词——“有启发”、“有帮助”。

受研究员 Andy Matuschak 的启发，Dwarkesh 成为“间隔重复记忆法”（Spaced Repetition）的坚定拥护者。他利用 AI 将阅读过的核心内容，快速生成精炼的抽认卡（Flashcards）。

读完一章内容，让 AI 帮你抽取 10–20 个关键问题
每个问题都有一个简短、明确的答案，可以塞进 Anki、RemNote、Obsidian 等工具
后续按照间隔重复的算法定期复习

这相当于把一本厚书，拆成很多「最小可记忆单元」，然后用系统来帮你维护「知识缓存」。长期下来，新知识不再只是一次性消费，而是会变成你后续思考的基础设施。

3. AI 是“世界观连接器”，将知识织成网络

孤立的知识点是脆弱的。Dwarkesh 强调，学习的最终目的是要将新的信息融入自己已有的世界观。他会从一个概念或一本传记入手，然后利用 AI 的语境扩展能力，不断追问：

“这个观点如何与 X 领域（如历史、经济学）的理论联系起来？”
“这个技术决策背后反映了怎样的商业思考？”

这种“系统性思维”的训练，能将点状的信息编织成一张理解世界的认知网络。知识不再是孤立的，而是成为了解释和预测世界的框架，这正是深度理解的标志。

对我来说，Dwarkesh 的方法不是一个「一学就能复制」的模板，更像是一种提醒：

在信息越来越多、工具越来越强的时代，深度准备这件事本身，反而变得更有价值。

Dwarkesh 的学习方法论：

（这几条主要来自《The Dwarkesh Method》那篇文章，我在原文基础上做了一些整理和概括。）

极度深入的准备 (Deep Preparation)：这是他最核心的价值。为了采访 DeepMind 的 CEO，他会花费数周时间阅读该公司过去几年的大部分论文，并咨询十几位人工智能研究员。这种准备让他能提出嘉宾都未曾听过的新颖问题。像 Patrick Collison 这样的嘉宾之所以愿意接受采访，是因为他们相信 Patel 的深度准备能保证这次对话是值得的。这正是从“交易”思维转向“关系”思维的典型表现。
构建信任与网络效应 (Building Trust & Network Effects)：他的第一位嘉宾是经济学教授 Bryan Caplan，由于对访谈质量非常满意，Caplan 将他推荐给了另一位知名经济学家 Tyler Cowen，从而开启了网络效应。顶级嘉宾（如马克·扎克伯格、Demis Hassabis）之所以愿意接受他的采访，是因为他的深度准备保证了对话的质量和价值，不会浪费他们宝贵的时间。
质量优先于数量 (Quality over Volume)：在一个播客数量超过500万的世界里，Dwarkesh 认为数量是信任的敌人。他专注于创造具有高信息密度和思想深度的内容，而非追求更新频率。
挖掘原创思想与系统性思维 (Uncovering Original Thinking & Systems Thinking)：他擅长识别并引导嘉宾分享他们的原创思想。同时，他具备系统性思维，能够理解不同知识领域之间的关联，尤其是在探讨像人工智能这样复杂且影响深远的话题时。
拥抱先进的学习工具与技术：Patel 不仅是努力，更是聪明地学习。他积极拥抱 AI 工具（如 LLMs）来帮助自己快速阅读、消化和整合海量信息。同时，他深受研究员 Andy Matuschak 的启发，广泛使用“间隔重复”(Spaced Repetition) 记忆法来巩固知识，确保长期记忆效果。

我的行动清单：如何应用 Dwarkesh 学习法？

综合 Dwarkesh 的理念与实践，我尝试为自己整理了一份可以试一试的操作步骤：

选择一本难啃但重要的书
- 标准：和你未来 1–3 年的工作/决策高度相关，而不是朋友圈最热门的那本
- 最小行动：选定后，先只上传前 1–2 章给 Claude，做一次「对话式阅读」小实验
生成抽认卡
- 最小行动：每章不超过 10 张卡片，否则你会很快放弃
- 工具无所谓，Anki / Notion / Obsidian / 飞书表格都可以，关键是能每天刷 5–10 分钟
练习“追问”：在学习新知识后，主动向 AI 提问：“这个观点如何影响我对 Y 的看法？”或者“它与我之前了解的 Z 有什么矛盾之处？”，刻意训练知识的迁移和整合能力。

Dwarkesh 的方法，本质上是用深度准备的“慢”功夫，构建起坚实的信任和理解基础，再用 AI 工具的“快”效率，打破信息处理的瓶颈。这套组合拳，或许能帮助我们每个人在信息过载的时代，重新夺回学习的主动权。

Reference

MacBook Air 刘海屏救星 - 开源免费的菜单栏管理神器 IceMenuBar app，用过的都说好！

Fri, 17 Oct 2025 21:46:00 +0800

也不知道从何时起，苹果电脑上的菜单栏就显示不下了，时不时都只能通过大屏幕来把常用（新装）的 app 菜单栏图标移动到最右侧。

有一段时间（具体时间我也忘了），实在受不了了，我就去网络上找解决方案，当时有一个推荐： HiddenBar （免费工具）。

算是我的救星！ ta 解决了我蛮长时间的小困扰。

不过，没过多久（印象中），我升了一次苹果系统。当我新安装的 app 有出现在菜单栏时，它显示不全，无法将其挪动到最右侧常驻。痛苦又开始了，当你想用的时候根本点不到，这简直就是一场灾难！真不知道苹果最牛逼的设计师是否不面临这个问题。。

一直在等待一款可以拯救我的 app，最近得到同事的推荐，我发现 Ice 这款 App 真的是非常之实用。它能完美的解决刘海屏显示，或者说菜单栏放不下的显示困惑。

接下来，我也简单介绍一下它，希望它能够帮助到大家。

Ice 是什么？

Ice 是一款免费、开源的 macOS 菜单栏管理工具。它的核心功能非常直接：帮你整理和隐藏那些不常用的菜单栏图标，让你的桌面/菜单栏瞬间变得清爽干净。

我为什么爱不释手？

1. 告别杂乱，一键隐藏

这个基本上菜单栏的最基础功能，Ice 肯定也是标配，设置起来超级简单，或者说不需要特别设置即可生效。你需要显示哪个，你直接像拖动文件一样，就可以把想显示的图标拖到 Ice 的分隔线后面，它就显示了，反之亦然。

2. “刘海屏”的终极解决方案：Ice Bar

开启后，它会在你的主菜单栏下方生成一个独立的、隐藏的工具栏。所有被你隐藏的图标都会收纳在这里。当你需要它们时，只需将鼠标悬停在菜单栏的空白区域，这个独立的 Ice Bar 就会浮现出来，完美避开了刘海的遮挡区域。再也不用担心图标丢失了！

3. 免费、开源，设置简单

作为一款完全免费且开源的软件，Ice 真的非常良心。你可以通过 Homebrew 命令 brew install jordanbaird-ice 快速安装，也可以直接从它的官网或 GitHub 页面下载。

整个设置过程不超过五分钟。虽然目前界面只有英文，但选项都非常直观，跟着感觉走基本就能配置好。第一次打开时根据提示授予所需权限，之后它就会在后台安静地运行，几乎感觉不到任何系统资源的占用。

总结

自从用上了 Ice，我的菜单栏再也没有因为图标过多而混乱不堪，刘海屏带来的烦恼也烟消云散，它简单好用，最重要的是解决了我的核心痛点。（苦廉颇久已啊！）

如果你也和我一样，看不惯混乱无序的菜单栏，或者正在被 MacBook 的刘海设计所困扰，我强烈建议你立刻去试试 Ice。它是一个能实实在在提升你日常使用幸福感的小工具。它是能提高你使用的幸福指数的。

Reference

停更近四年，我以：“一年后我重听 Perplexity CEO Aravind Srinivas 的访谈学习”为题，宣布回归！

Sun, 12 Oct 2025 14:46:00 +0800

三年半以前，我的博客停更了。不是没内容，也不是没想法。只是不知道要在博客上写点什么，于是慢慢就停下了。

这一段时间，我其实并没有真的停止输出内容，反而还可以说写的更多。我折腾过「知识星球 - Go 夜读、阅读之美」、「墨问专栏」，也尝试过 DailyCards （21 天读书打卡）等等。

https://talkgo.dev/

最近，我开始重新思考“学习”这件事。 2024 年 8 月 30 日，我在「知识星球 - Go 夜读」上推荐过一个视频播客—— Lex Fridman 访谈 Perplexity CEO Aravind Srinivas。

YouTube: https://www.youtube.com/watch?v=e-gwvmhyU7A
【【精校3-1】perplexity CEO 3小时长篇访谈 @ Lex 2024.6 【中英】】 https://www.bilibili.com/video/BV1HM4m1U7St
【【精校3-2】perplexity CEO 3小时长篇访谈 @ Lex 2024.6 【中英】】 https://www.bilibili.com/video/BV1Xx4y1b7AX/
【【精校3-3】perplexity CEO 3小时长篇访谈 @ Lex 2024.6 【中英】】 https://www.bilibili.com/video/BV1h6421Z7tw/

那时我很激动。我在知识星球的文章中说到：“我接下来也多用用 Perplexity。” 结果一年过去，我依然在用 Google 和 AI (ChatGPT, DeekSeek, Poe…)， Perplexity 几乎没打开过（平均下来每个月可能就个位数的使用频率。

我食言了。

但也正因为这个，我把近期的一些思考和这一反思结合起来了，我开始重新看自己。

虽然 Perplexity 没有用起来。但是 Lex Fridman 访谈 Aravind Srinivas 的那期视频我看了不下三遍。每一次都被打动。

Aravind 是那种典型的 “Google 派” 工程师：底层逻辑清晰、学术背景强、对系统的理解深入。当他说——

“Google 的弱点在于，它的商业激励和用户激励并不一致。”

我几乎拍案叫绝。那一刻，我觉得他看透了一个时代。

他还提到 David Deutsch 在《The Beginning of Infinity 无穷的开始》中的那句话：

“知识是无止境的，我们只能不断地学习与成长。”

我记得当时就想：是啊，这就是我要追的状态。

注：我近期还用微信读书听了前面十章，但是实在听不下去了，完全听不懂、听不明白。（陷入了自责和沉思）

但后来我发现，那种“被启发”的感觉，其实很像“精神鸦片”。

我听得越多，越觉得自己在成长；可实际上，我只是反复在感受别人的思考。没有实践，没有改变。

就像现在的短视频讲电影、拆剧情：你看多了，也没有什么意义。

我开始反思：听播客、看访谈、读书 —— 这些我都在做，但我有没有真的留下什么，好像并没有意义。

于是，我决定重新开始。

从今天（本周）起，我不再追求完美系统、流程、工具，也不追求多，不追求快。我只做一件事： 只要我看过、听过、想过，就应该要留下点什么。

不管深浅，不管长短。这一系列，我暂且叫它 Real Learn Journal。学得不多，但是真实。 learn in public，learn as myself。

🎧 本周我听了

Lex Fridman × Aravind Srinivas

💡 我捕捉到的一个想法

TODO

🪞 我的共鸣

TODO

✍️ 我做了一个小动作

TODO

最后

三年多没更新博客。不是因为我不想写，而是因为我不知道要干嘛。

现在，我找到了。

我不打算做一个完美的版本，只想做一个更真实的自己。

凤凰涅槃，不是要重生，而是要带着旧的灰烬重新出发。

📍Shenzhen · 2025-10-12

纳瓦尔深度洞察：对待 AI 你得行动起来！

Mon, 29 Sep 2025 21:00:00 +0800

下面这段话，是我在 #CursorMeetupXiamen Cursor Meetup 厦门站上分享最后环节的汇总。 MaiYangAI Twitter source

对待 AI 你得行动起来！

人们常常陷入一个误区，以为成功的第一步是埋头钻研各种成功学方法论——我们不妨称其为“成功学色情片”。它提供短暂的快感，却无法带来真实的创造。这就好比一个人读遍了所有的游泳手册却从未跳进泳池，而迈克尔·菲尔普斯的教练在他小时候看中的，正是他跳入水中后那种近乎本能的驱动力。

那么，驱动成功者义无反顾的核心引擎是什么？是一种压倒性的渴望。这种渴望，在埃隆·马斯克身上体现得淋漓尽致。当他卖掉PayPal获得巨额财富后，他并没有去享受生活，而是将全部身家投入当时看似天方夜谭的太空探索（SpaceX）和电动汽车（Tesla）领域。这种“非做不可”的渴望，源于他内心对于人类未来的终极关切，而非单纯的商业利益。

于是，他们“只是去做了”。行动在这里被提到了至高无上的位置。想想马克·扎克伯格在哈佛宿舍创建Facebook的最初版本——“Thefacebook”。他并没有等待一个完美的商业计划，也没有去申请一堆专利，他只是看到了一个连接校园的需求，便连夜敲代码将其实现。产品在上线后爆火，他面临的每一个问题（服务器扩容、功能迭代）都成了他“即时学习”的最佳教材，推动着他和公司飞速成长。

如何判断你拥有的是否是这种真正的渴望？这里有一个残酷而有效的试金石：它会让你夜不能寐吗？史蒂夫·乔布斯对于产品完美细节的偏执，就达到了这种境界。他会因为一个电路板的设计不够优雅或一个用户界面像素的偏差而大发雷霆，彻夜难眠。这种对“创造完美”的渴望，远远超过了对于市场销量的追求。

最后，我们必须警惕那些虚假的动力来源：半心半意的犹豫，或是模仿他人而产生的“模仿性欲望”。真正的成功，源于一次深刻的自我诚实。杰夫·贝索斯在创建亚马逊前，看到的正是互联网应用的巨大浪潮，但他没有去模仿当时已有的任何商业模式。他清晰地自问：“在此时此刻，我真正想要的是什么？”答案是利用互联网为消费者创造前所未有的便利与价值。这个内在的、清晰的答案，促使他放弃了优渥的华尔街工作，从在线卖书开始，开启了一场伟大的冒险。

因此，当你找到那个让你夜不能寐、愿意像这些开创者一样all-in的答案时，你才会调动起自己全部的能量与智慧。那一刻，才是你真正起飞的时刻。正如Naval所言，你需要的不是旁观者的指导，而是行动者的决心。

与君共勉！💪

2022 年年终总结

Sat, 31 Dec 2022 21:08:00 +0800

2022 年年终总结

2022 年眨眼之间就结束了，今年过的很不寻常。一个月之前还在天天查核酸，绿码、行程码，到现在已经全部拆除得干干净净，还留有一些尾巴（不少人还处在阳和阳康的过程中）。

三年，说长不长，说短也不短。人生能有多少个三年。小朋友从不会说话到会说话，光阴似箭，时光如梭~

今年这个年终总结，来得比以往更不一样。因为疫情，因为家人，因为阳了康复过程中又出现了肺炎，小朋友住院了。

~~话不多说~~

直接上一批数据：

GitHub Star 11K
bilibili 粉丝数 3.6 万
YouTube 订阅数 7.04K
微信视频号关注数 1千+
微信公众号关注数 ~2万
talkgo.org 全年访问量突破 80 万
talkgo.fm「Go 夜聊」全年共 2 期播客节目
talkgo.dev 当前 PV 1247，UV 593
Go 夜读知识星球 1112 篇主题， 2,833 个赞
「一叶知秋」，15 人订阅，累计总阅读数 464

以上各项，你对哪一项比较满意，对哪些项不满意呢？真诚接受大家的评论。

Go 夜读

Go 夜读从第 125 期到第 141 期，全年一共 17 期，今年分享的内容涵盖 Go 语言的各个方面，特别是 Go 1.18 泛型和 pdqsort 算法优化，相信不少小伙伴已经从中获得不少收获吧。

在 2022 年，我全年共发布了 23 个视频，总播放量达 10.2 万次。累计获赞 3705 次。在播放量和获赞这方面还有待提升。

其中有几期节目是跟 AfterShip 合作制作的，涉及到的内容也是以学习和讲述个人成长史有关，目前从反馈来看还是不错的。如果大家喜欢的话，我在 2023 年也试着给大家更多这方面的分享。

每日打卡

虽然这个活动每周都在继续，但是确实从运营的角度来看是失败的，但是如果说从我们参与的情况来看，那还是非常成功的，我们长期维持 27 个人，从来没有人打卡失败过，每个人都在不断的学习，不断的提升自己。

如果你也想要了解的话，可以登录 https://talkgo.dev 查看并加入。

接着 2021 年的年终总结来说，我发起这个每日打卡活动，主要是受到《刻意练习》和《微习惯》、《原子习惯》的影响。

每天 +1%，一年以后就是 37 倍，每天 -1%，一年就是近乎于零。

在 2021 年阅读过的书📚：

《刻意练习》
《被看见的力量》
《TED 演讲的秘密：18分钟改变世界》
《漫画算法1、2》
《微习惯》
《沸腾新十年》
《解密Instagram：一款拍照软件如何改变世界》
《不拘一格：网飞的自由与责任》
《认知觉醒》
《读书是一辈子的事》

在 2022 年全年 365 天，每天都打卡阅读，共阅读超过 26 本📚：

《管法》
《一往无前》
《Salesforce 传奇》
《30 不设限》
《纳瓦尔宝典》
《软银孙正义的 PDCA 工作法》
《亚马逊你想工作法》
《可能性的艺术》
《半小时漫画计算机》
《黑客与画家》
《学会自学》
《趣说中国史》
《PDCA 循环工作法》
《上瘾》
《像外行一样思考，像专家一样实践》
《亿万负翁：WeWork 及其创始人的极速崛起与陨落》
《曼巴精神》
《Go 语言定制指南》
《饿了么质量体系搭建实践》
《神秘的程序员》
《贝佐斯如何开会》
《费曼学习法》
《如何管理 10 人以下小团队》
《刻意练习》
《沸腾新十年》
《三十岁，一切刚刚开始》

有了微信阅读墨水屏，我在通勤路上也读得更多的，我希望在 2023 年能读的更多，也能吸收的更多。

Go 夜读知识星球

在这里，我依然会第一时间分享 Go 语言的相关新闻，以及一些不错的 GitHub 项目推荐，还有一些资料，推荐阅读的分享。

今年我新开了一个打卡：#Go历史上的今天#，简单记录了每一天 Go 团队所合并的 commit 个数。

我也试着写了几篇短文，可能对大家帮助不是特别大，也确实在 Go 夜读知识星球上投入的时间和精力都比较少，希望在明年能好好用心经营一下，让它对付费的朋友真正产生一些价值。如果你还在支持我的话，也欢迎你来吐槽我。

佛系半年更节目 - 「Go 夜聊」

「Go 夜聊」全年 2 期节目，今年有一个非常值得开心的事情，那就是我们的播客节目被推上苹果播客首页 - 科技板块。

「Go 夜聊」在小宇宙上的数据：订阅数 1625，总播放数 6584，完播率 50.6%，15% 的人选择在早上 11 点到 12 点收听我们的节目，这个时间点倒是很让人意外哦。

2022年共被播放 387 小时，其中第 7 期：依赖与管理，被播放了 216 小时。

「一叶知秋」

我从 2022 年 7 月 16 日开始创刊了「一叶知秋」，并选择竹白作为我的 newsletter 平台，虽然我在持续创作了超过 23 期，也没有获得什么关注数，但是我依然坚持做着个人整理，不期盼一定能得到什么，但是我要的是一个记录，要的是整理过程给我个人带来的一些梳理和帮助。

如果这些又恰好给你带来一些帮助，那可能就更好了。

以上就是我在 2022 年的一些总结和所做的一些事情~

个人部分

待补~

工具：从只使用 Notion，到开始尝试 logseq 记录个人日志。

明年会如何？

明年一定会更好，每个人都可以开开心心的过年，开开心心的旅游。因为疫情真的终将过去了，我们能获得真正的自由，终于可以自由的呼吸和到处走走了。

与我而言，坚持做有价值的事，「Go 夜读」，我一定会带来更有价值的内容给大家，我也会更加努力的学习、阅读从而来充实我自己。

推荐有价值项目、知识
读书分享会

新年愿望：希望 b 站粉丝可以在 2023 年突破 10 万。

最后的最后，我祝大家新年快乐，心想事成，天天开心，日益精进！

茶歇驿站

一个可以让你停下来看一看，在茶歇之余给你帮助的小站，这里的内容主要是后端技术，个人管理，团队管理，以及其他个人杂想。

2022 F1 英国银石大奖赛冠军：赛恩斯（多图）

Mon, 04 Jul 2022 00:45:00 +0800

2022 英国银石大奖赛的比赛太精彩了

从开场起跑，周冠宇遭遇赛道的严重赛车事故，再到后面的红牛、法拉利对战，以及维斯塔潘赛车受损，奥康赛车坏在赛道上引发的安全车，再次把比赛带入精彩的高潮，真的是一场非常精彩且有故事的比赛，我估计我会二刷、三刷此次比赛。

法拉利赛恩斯夺冠

哈斯米克·舒马赫第 8 名，生涯首次获得积分

周冠宇比赛事故

茶歇驿站

一个可以让你停下来看一看，在茶歇之余给你帮助的小站，这里的内容主要是后端技术，个人管理，团队管理，以及其他个人杂想。

2021 年年终总结

Fri, 31 Dec 2021 09:00:00 +0800

2021年终总结

光阴似箭，时光如梭

2021年马上就要结束了，赶在最后一天做个总结，应该是很多人的做法，我也不免俗。我也来简单总结总结。

在开始总结之前，我想对支持和帮助我的朋友说声：谢谢。这份总结不是我个人的，因为其中很多部分都是我的朋友，以及社区各路大佬鼎力相助所产出的。人数太多，我就不一一列出。感谢每一位曾经帮助过我、指导过我们的朋友，以及为 Go 夜读贡献的讲师，组织者以及志愿者等等。

~~话不多说~~

直接上一批数据：

GitHub Star 10.1K
bilibili 粉丝数 2.6 万
YouTube 订阅数 5.9K
微信视频号关注数 1千+
微信公众号关注数 1万+
talkgo.org 全年访问量突破 100 万
talkgo.fm「Go 夜聊」全年共 4 期播客节目（😌）
talkgo.dev 当前 PV 280，UV 188（😭）
TalkGo 算法之美举办了第 3、4、5、6、7 期
TalkGo 读书会仅举办了第 4 期
Go 夜读早读/夜读室坚持直播了 54 天
Go 夜读知识星球 450 篇主题，1536 个赞，打卡阅读 Go 代码累计 106 天

以上各项，你对哪一项比较满意，对哪些项不满意呢？真诚接受大家的评论。

Go 夜读

Go 夜读从第 108 期到第 124 期，全年一共 17 期，除了我们的老朋友：Florin Pățan&范圣佑、曹春晖、万俊峰、Kippa 给我们带来新的主题分享外，我们还新增了 10 位分享嘉宾，它们分享的内容涵盖 Go 语言的各个方面，相信不少小伙伴也能从中有不少收获吧。接下来，我们也非常欢迎有更多的讲师可以抽空来分享你的经验和思考。

全年之最《Go 夜读第 115 期理论结合实践详解 B+ 树存储引擎》

YouTube 观看数最高的是《#115 理论结合实践详解 B+ 树存储引擎（InnoDB、BoltDB、BuntDB）》，观看数 1.1K。

Bilibili 观看数最高的是《#115 理论结合实践详解 B+ 树存储引擎（InnoDB、BoltDB、BuntDB）》，播放数 7232 次。

微信视频号

因为视频号的开通是需要一个微信来作为主管理员的，而一开始我就用了我个人的私人微信，一开始取名「茶歇驿站」，我也通过它分享了一些我的个人生活（跑步打卡），也做了几场直播。但是说实在的，我个人不太擅长面对摄像头，所以这个号也就尝鲜试了试，也很感谢刚开始就关注我的朋友。

后面有段时间，我又在这个号上发布了一些粤语经典歌曲、F1 精彩集锦，获得了不少流量（最大的播放次数超过 7万），但是随着微信对原创视频的重视，有几个也是几万播放的视频被下架了，逐渐的我也就失去了兴趣。

视频号后面灰度开放了推流功能，我也试着将 Go 夜读也能通过微信视频号分享给一些有需要的朋友，所以后面我们每次直播都在视频号上直播。

我不自量力的拿我们跟「极客时间小盖」做一个对比。

视频号	主题	观众总数	最高在线	平均观看	总热度
「极客时间小盖」	陈皓	1.8万人	2127人	14分32秒	4871
「极客时间小盖」	张雷	4014人	532人	10分48秒	1650
「Go 夜读」	某一期	1154人	116人	6分54秒	0

微信公众号真能水啊！！！

我们的公众号今年一共发布了 115 篇文章，我还真没有想到，我也能每 3 天就水一篇，希望明年把质量提高提高，尽量不要水大家。

Go 夜读公众号在今年发布了 4 期招聘，但是我听招聘方反馈好像没有什么效果，现在招人可是真的难。另外，我们的 talkgo.org 招聘专栏有近 30 个 Go 开发岗位的招聘。

Go 早读室 - 每日打卡

这是一个在年中尝试的项目，一方面是想培养自己的习惯，一方面也是想看看直播对 bilibili “吸粉”有没有帮助，结果自不必说了，大家应该都知道的。

不过，我个人觉得在这 54 天的直播自习室也聚集了一些小伙伴，我们到现在也还在进行着每日打卡，虽然直播活动结束了，但是这个打卡还在持续进行着。

如果你想要了解打卡的内容，可以登录 talkgo.dev 查看。

当初启动这个项目是受到《刻意练习》和《原子习惯》的影响。

每天 +1%，一年以后就是 37 倍，每天 -1%，一年就是近乎于零。

配上一张复利的图

下面是我在2021年阅读过的书📚：

《刻意练习》
《被看见的力量》
《TED 演讲的秘密：18分钟改变世界》
《漫画算法1、2》
《微习惯》
《沸腾新十年》
《解密Instagram：一款拍照软件如何改变世界》
《不拘一格：网飞的自由与责任》
《认知觉醒》
《读书是一辈子的事》

Go 夜读知识星球

在这里，我第一时间分享 Go 语言的相关新闻，GitHub 项目推荐，分享资料，推荐阅读，打卡阅读 Go 代码等等。其中打卡阅读 Go 代码累计打卡 106 天。

佛系季更节目 - 「Go 夜聊」

「Go 夜聊」全年 4 期节目，幸好只是4期节目，不然欧神剪辑可能会剪🤮。因为每一期欧神都要花费至少 5-10 倍音频的时间。

下面是我们在小宇宙上的数据：订阅数 893，总播放数 3817，完播率 50.5%，通常是在早上通勤路上收听我们的播客节目。

2021年共被播放 2132 此，共被播放 911 小时 36 分钟，其中第 3 期：漫谈写作和个人成长，被播放了 564 小时。

我们在 2021年1月8日第一次登上了新星榜。

以上算是我以及我们在2021年的一些总结和一些小故事，如果你觉得有趣，有感触，不妨给我来个赞赏啊~

个人部分

待补~

明年会如何？

2021年马上就结束，疫情反复无常，我们的生活依旧要继续。不管疫情或怎么，我们还是要迎来 2022 年了。

我想它一定带给我们的是机遇与挑战，我们每个人跟时间做朋友吧，凡事都多坚持一下，你可能会有意想不到的收获。

我们算是不错的证明。

见前文所述各种数据。

可能，你觉得这没有什么价值。但是它对我意义重大。

好了，该说的也罗列的差不多了，字数也凑得七七八八，勉强算是一篇年终总结了吧。

接下来我们来切个题，明年会如何？

此时，我就拿出我的微信签名是坚持做有价值的事。

态度算是表了，我也说点实际的吧，你也不想想上面那几个域名也要花不少钱，但是我们都续费了，所以，我们一起期待明年吧。

最后的最后，我祝大家新年快乐，心想事成，天天开心，日益精进！

茶歇驿站

一个可以让你停下来看一看，在茶歇之余给你帮助的小站，这里的内容主要是后端技术，个人管理，团队管理，以及其他个人杂想。

虽然一个人可以走的很快，但是只有一群人才能走的很远。

Thu, 30 Dec 2021 09:50:00 +0800

if you want to go fast go alone. if you want to go far go together. – african proverb

参考资料

https://andrewwhitby.com/2020/12/25/if-you-want-to-go-fast/

茶歇驿站

一个可以让你停下来看一看，在茶歇之余给你帮助的小站，这里的内容主要是后端技术，个人管理，团队管理，以及其他个人杂想。

2021 F1 总冠军：维斯塔潘（多图）

Sun, 12 Dec 2021 23:45:00 +0800

2021 赛季 F1 的比赛太精彩了

每一场比赛都有它的故事，我全程观看了整个赛季。

谢谢家人给我足够的时间，让我可以安心的追逐这些精彩的比赛。

话不多说，我接下来就来 share 一些精彩的照片。

一整个赛季，都是这样的格局：

Max 夺冠

感谢佩雷斯，如果不是他，这个冠军悬念可能早就没有了。

比赛历程

我以我看比赛过程中的视频截图来展现整场比赛

不知道大家会怎么看这场比赛，但是我个人觉得整个赛季都是非常精彩的。我也偏向于喜欢维斯塔潘获得最终的总冠军，现实也是如我所愿。非常的开心。

但是汉密尔顿也非常值得尊敬，特别是巴西站获得的胜利。👍🏻

。。。

茶歇驿站

一个可以让你停下来看一看，在茶歇之余给你帮助的小站，这里的内容主要是后端技术，个人管理，团队管理，以及其他个人杂想。

一行代码搞定 GitHub 访问徽章

Tue, 05 Oct 2021 17:30:00 +0800

一行代码搞定你的 GitHub 访问徽章

相信对于使用 GitHub 的小伙伴来说，以上 GitHub 徽章（badge）应该都不怎么陌生吧。如果你想快速用起来，找到你想要的徽章代码 ctrl+c & ctrl+v ，再修改对应的 GitHub username/repo_name 即可。

今天我要跟你分享的是这其中的一个小徽章 - GitHub 访问徽章。

一行代码搞定!

这么简单就接入了，那它是怎么实现？它还有其他什么特性呢？

urlstat 简介

urlstat 提供了跨网站的 pv/uv 统计。适用于 blog.changkun.de, golang.design/research 等网站的统计。

用法一：普通模式

在页面上添加以下代码：

`1`	`<script async src="//changkun.de/urlstat/client.js"></script>`

该脚本将查找 ID 为 urlstat-page-pv 和 urlstat-page-uv 的元素，并在找到后更新信息。

1
2

<span id="urlstat-page-pv"><!-- info will be inserted --></span>
<span id="urlstat-page-uv"><!-- info will be inserted --></span>

以下是一个 golang.design/research 例子 golang.design/research 例子

用法二：GitHub 模式

用户 query 参数： mode=github&repo=talkgo/night，例如：

`1`	`![](https://changkun.de/urlstat?mode=github&repo=talkgo/night)`

源码分析

入口函数 urlstat.go

我们可以看到该项目所用到的技术： net/http, embed.FS , MongoDB 构建了一个使用 MongoDB 存储数据的 HTTP Server。

核心的 API: handler.go

/urlstat: 记录访问数据
/urlstat/dashboard: urlstat 的后台管理系统
/urlstat/client.js: 提供给 html 页面使用的 client.js 代码
代码的主要逻辑就是去请求数据，然后将其填充到页面的两个 span 中。

2 个结构体：stat, visit 就囊括了 urlstat 的基本数据结构。

type stat struct {
	PagePV int64 `json:"page_pv"`
	PageUV int64 `json:"page_uv"`
}

type visit struct {
	Path    string    `json:"path"    bson:"path"`
	IP      string    `json:"ip"      bson:"ip"`
	UA      string    `json:"ua"      bson:"ua"`
	Referer string    `json:"referer" bson:"referer"`
	Time    time.Time `json:"time"    bson:"time"`
}

API 还加了 allowOrigin, allowGitHubUser，用于避免不受信的来源创建统计记录。

/urlstat 对应的 handler 是 recording

在这个函数里面通过 mode 来判断其使用的是网页版还是 GitHub 徽章版。

函数逻辑也很简单，首先解析数据，然后 saveVisit，然后再 countVisit，并将其结果返回。

徽章渲染 drawer

对于我们使用的徽章模式，项目通过 drawer 来渲染出一个 image/svg+xml badge，想要了解详细代码实现，可以参考这段代码: https://github.com/changkun/urlstat/blob/main/renderer.go

渲染出来的这个是怎么在 GitHub 上显示的呢？那我们就必须得了解一下 GitHub 匿名 URL：https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-anonymized-urls

文中提到 GitHub 使用 Camo，那 Camo 又是什么呢？Camo 为每个文件生成一个匿名 URL 代理，它对其他用户隐藏您的浏览器详细信息和相关信息。 URL 以 https://<subdomain>.githubusercontent.com/ 开头，根据你上传图像的方式具有不同的子域。

以 GitHub talkgo/night README 为例，我们访问 GitHub 主页，就可以得到 camo 渲染代码：

<a target="_blank" rel="noopener noreferrer" href="https://camo.githubusercontent.com/142682259b230dd9ed8d7382509ecf5eab5cc54aea56d1ea7c4871292adfff8a/68747470733a2f2f6368616e676b756e2e64652f75726c737461743f6d6f64653d676974687562267265706f3d74616c6b676f2f6e69676874"><img src="https://camo.githubusercontent.com/142682259b230dd9ed8d7382509ecf5eab5cc54aea56d1ea7c4871292adfff8a/68747470733a2f2f6368616e676b756e2e64652f75726c737461743f6d6f64653d676974687562267265706f3d74616c6b676f2f6e69676874" alt="" data-canonical-src="https://changkun.de/urlstat?mode=github&amp;repo=talkgo/night" style="max-width: 100%;"></a>

为什么要使用 camo

任何在 GitHub README.md 文件（或其他呈现的 HTML 格式）中呈现的图像都将使用 camo 呈现。

有几个原因：

性能：GitHub 为大量用户提供服务，如果不这样做，页面加载时间会很糟糕。
隐私：让回购所有者嵌入跟踪图像是不可接受的。
DDoS 角度：在外部托管图像允许恶意存储库所有者拥有相当流行的存储库，只需加载其中一个图像即可对他们选择的任何站点进行 DDoS 攻击。

至此一个简单的 urlstat 就算是完成了。

茶歇驿站

一个可以让你停下来看一看，在茶歇之余给你帮助的小站，这里的内容主要是后端技术，个人管理，团队管理，以及其他个人杂想。

新旅程 - AfterShip

Mon, 13 Sep 2021 09:30:00 +0800

【决定】

在9月1日我正式回到深圳。当时就有很多朋友关心我去了哪。

现在我来跟大家汇报一下，我加入了一家做海外电商 SaaS 的公司 AfterShip。

她“出生”于香港，“成长”于深圳，团队和业务遍布美国、欧洲、澳大利亚、印度等世界各地。 AfterShip 是一支追求极简高效、工程师文化的国际化团队。 AfterShip 为 Amazon、eBay、Facebook、IKEA 等海外 10 万余位客户提供自动化和智能化的电商 SaaS 服务。

【为什么加入 AfterShip】

💪首先，非常看好电商 SaaS 赛道。

2021 年 4 月宣布获得全球顶级基金 Tiger Global 领投，高瓴跟投的 4.3 亿人民币的 B 轮融资，刷新电商 SaaS 赛道 B 轮融资记录，是少数受国际资本市场认可、高速发展且营收健康的科技公司。

📈其次，公司快速发展，且盈利能力强。

公司自 2012 年上线以来，0 推广费飞速发展。2014 年起实现 100% 翻倍盈利，最近几年每年的收入都至少翻倍增长。

核心业务已经走出了一条非常稳健、快速增长的曲线，Shopify Top 50 的 APP 有 4 个出自 AfterShip ，并且还在快速上升中。

develop a company as a product

develop a office as a product

我很感谢你愿意听我分享我的公司，我更期待未来与你们一起奋斗。

招聘

目前 AfterShip 处于飞速发展期，公司各个部门都需要大量的人才，包括研发部、设计部、人力运营部、SRE、客户成功部、财务部、大数据、市场部、产品部、销售部等各部门的各职位均有 HC。

如果你对电商、国际化、SaaS 感兴趣，喜欢你找我聊聊，我期待与你一起共事，AfterShip 一定是你值得来的地方。

💰推荐成功有 5000-50000 的伯乐奖，欢迎自荐或推荐，如果你现在还不方便，我们可以先交个朋友，深圳随时约饭😋。

简历投递方式：扫第二张图的二维码或直接私信我都可以，你怎么方便就怎么来。

求贤若渴[抱拳][抱拳]

茶歇驿站

一个可以让你停下来看一看，在茶歇之余给你帮助的小站，这里的内容主要是后端技术，个人管理，团队管理，以及其他个人杂想。

MaiYangAI - AI, Cursor, Gopher, OpenSource Fans, 成长之路有我相伴。

推荐播客

播客客户端推荐

我主要收听的播客节目

Golang Channel

YouTube

Bilibili

我的书单

计划读

已读（部分）

想读（部分）

推荐书单

「阅读之美」免费知识星球

关于我

如何评审一份让听众真正有收获的分享 PPT

如何评审一份让听众真正有收获的分享 PPT

1. 标题是否足够鲜明和落地

2. 个人介绍是否服务于分享

3. 开场是否建立问题感

4. 结构是否围绕一个核心要点展开

5. 页面是否帮助演讲，而不是替代演讲

6. 听众是否能带走可迁移经验

7. Takeaway 是否完成收束

一套简化评审标准

从一个念头到上架 Store：我是如何做出 Lock Time 的？

起因

先把问题想清楚

第一个版本，比我想得快

真正难的，不是写出来，而是把它做对

第一个坑：macOS 26 上锁屏检测完全失效

第二个坑：首屏加载慢得离谱

功能做完之后，上架 Ryacast Store 又是另一道坎

提交 PR 这一步，我也研究了挺久

提交 PR 之后，才发现真正的 review 才刚开始

社区这件事，这次我是真切感受到了

“Raycast is a lifestyle”

最后

用 Warp AI 秒杀 Python 依赖问题：从 2 小时到 2 分钟

起因

但这次不一样

AI 的解决过程

1. 快速诊断（30秒）

2. 精准定位（1分钟）

3. 直接修复（30秒）

为什么 Warp AI 这么快

1. 系统性思维

2. 无需上下文切换

3. 经验积累

更深层的价值

什么时候 AI 才真正有用

总结

Cursor 设计总监 Ryo Lu 的设计哲学

《Ryo Lu Design System》 —— 构建面向 Builder 的极简、清晰、可信赖的产品设计体系

Ⅰ. 设计哲学（Design Philosophy）

1. 设计的核心不是“好看”，而是“减少阻力”

2. 产品要以“1 秒钟懂你”作为目标

3. 简洁不是少，而是“意味清晰”

4. 用户路径必须“自动引导”

Ⅱ. 设计准则（Design Principles）

1. 清晰原则（Clarity Rule）

2. 信息优先级原则（Hierarchy Rule）

3. 内容稀释原则（Density Rule）

4. 语义明确原则（Semantic Rule）

5. 一致性原则（Consistency Rule）

6. 反馈原则（Feedback Rule）

Ⅲ. 审美标准（Aesthetic Criteria）

1. 美来自结构，而不是颜色

2. 美来自行动通顺

3. 美来自减少犹豫感

Ⅳ. 反模式（Anti-patterns）

1. Hero 区域没有说人话

2. 所有元素权重一样

3. 图标比文字重要

4. AI 产品的“Fake Intelligence”

5. 做设计，而不是做产品

Ⅴ. Builder 向的设计工作方式（The Ryo Working Style）

1. 先做信息架构（IA），再做 UI

2. 永远从“首页”和“首屏”开始

3. Demo-first

4. 快速迭代，不做艺术工程