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

我是 MaiYang（杨文），Cursor 中国区首位 Ambassador，Go 夜读发起人，AI Builder。现在也是一名持续 Build in Public 的开发者和 AI 产品实践者。

过去一年多，我把大部分业余时间都投入到了 AI，持续在构建产品，也在探索如何借助 AI Coding，把想法更快地变成真正可以交付的产品。目前专注于 AI Coding、Context Engineering 和工程实践怎么结合。我的判断是：AI 不该只停在更好用的工具，它得能进到工程协作里，成为真正能一起干活的伙伴。

社区和开源

对 Go 情有独钟，也是一个开源爱好者。Go、TiDB、logkit、kingshard 等多个开源项目的 Contributor。开源和技术社区这件事，我投入了很长时间。

2018 年 3 月 21 日发起「Go 夜读」，GitHub Star 12k+，并持续在 Bilibili 和 YouTube 频道上更新视频内容，超过 160+，微信群人数超过 5000+；
TGO 深圳董事会成员，任职 2 年 TUG 华南区 Leader，多次深圳地区 Gopher meetup 的组织者和分享嘉宾；
2025 年 5 月成为 Cursor 中国区首位 Ambassador，并持续举办过十余场中国大陆地区的 Cursor 官方活动；
创建了 Cursor Insider 中文社区。

产品

创建了 Contextly macOS App，用来追踪上下文切换次数、专注读写时间，并集成了 Quick Note；
创建了 AI Leaders 网站 CastMind.ai；
创建了 ContextEcho iOS App，一款克制的播客音视频学习统计工具；
创建了 TweetQuote，让每一次引用，都带上完整的上下文；
创建了 Chrome 插件 NotebookLM Batch Importer，一键批量导入 YouTube 视频到 NotebookLM；
macOS 菜单栏语音输入工具，开源项目：SpeakPaste；
AI 实战 · 微信话题订阅阅读器，支持订阅管理、即时刷新、阅读计数、本地缓存，开源项目：weixin-topic-reader；
鼎革千年 · 中国历代权力更迭脉络：https://chinese-dynasty-timeline.pages.dev/。

目前我会在 X 上进行 Build in Public，记录产品构建过程中的成果、思考、弯路和失败。我还写过一篇帖子，在 X 上获得了 13 万+ 阅读。

说回 AI Builder 身份。我用 Cursor 开发的 ContextEcho iOS App 上线后，很快进入教育类付费榜第 23 名，却在排名上升期间遭遇突然下架。这个过程让我完整踩了一遍独立开发、App Store 审核和中国区 ICP 备案的坑。我也写过一篇复盘。

工作

职业生涯很长一段时间里，我都在技术和管理两条线上。Go、分布式系统、工程效率和质量建设，是我待得最久的几件事。

2021 年 9 月，我回到深圳，加入了一家全球化电商 SaaS 创业公司；
之前在 2c 赛道做过将近 9 年，一直在技术和管理方向，拥有超过 10 年的研发管理经验，能 hold 住各类开发应用场景：秒杀、亿级 API 调用、百亿级的数据量存储、微服务架构等。

写代码之外

我也是一名 F1 赛车迷，同时跑马拉松和越野赛，大家也可以赛道上见。

偶尔看看 NBA 和欧洲足球，偶尔徒步。也喜欢带着家人到处旅行，有过多次 1700+ 公里的驾驶经历。

怎么找到我

听的时候全懂，一动笔全废：硅谷徐老师大师课上的 EQ × TQ × IQ

Mon, 17 Aug 2026 23:00:00 +0800

起因

今天晚上，我花了 4 个小时，把 Stay Superlinear 的第一场大师课看了两遍。

第一遍是当听众看的。认真听，跟着想，徐老师讲的、课代表补充的、每一位提问者的问题和两位老师的回答，我都过了一遍。看完的感觉很好——都懂了。

第二遍我打开一个空文档，开始记。

然后就废了。

「Superlinear 一方面是复利，一方面是突破」，我第一遍听的时候点头如捣蒜。第二遍要写下来，我发现我说不出复利指什么、突破指什么，也说不出为什么这两个词能凑成一个概念。IQ = Intelligence + Intensity 我记住了，EQ = Emotion + Eyeball 我也记住了，可整张 slide 是 EQ × TQ × IQ，TQ 是什么我根本没记下来——听的时候它就那么滑过去了，我甚至没意识到自己漏了一个字母。

这就是那件事：你听了，你懂了，实际上并没有。

有时候大脑是会骗你的。它把「跟得上」当成了「学会了」。真正会了的东西是不用刻意去记的，反过来，那些你一停笔就消失的，说明它压根没进去过，你只是当时忘了自己不懂而已。

这几天网上还流传一句话，说 AI 时代变化那么快，你跟不过来，那你就不跟嘛，再过一年你会发现自己也没缺什么，因为过程中学的那些东西早就过期了。这话我一半同意。会过期的是工具的用法，不会过期的是判断力。麻烦在于，光靠「听懂」这个动作，你攒下来的全是前者。

所以下面这篇，是我第二遍的产物：徐老师 slide 上的原话和我现场记下的东西照原样摆出来，我事后查证补上的背景放在引用块里，最后是我真正打算改的三件事。

先交代一下我自己的位置，这决定了我在这场课里听见了什么。我是 Cursor 中国区首位 Ambassador，2018 年发起 Go 夜读并一直做到现在，之前的时间主要花在 Go、分布式系统和工程效率质量建设上，现在盯的是 AI Coding 和 Context Engineering。所以这场课里凡是讲到「工程效率到底换来了什么」和「上下文决定建议的好坏」的地方，我的反应都比别处大。

这场课和这个人

Stay Superlinear 是课代表立正主理、鸭哥长期参与教学的付费社区。我是从课代表刚开始做 B 站视频的时候就在关注他了，后来开了大会员，这次社区上线我也果断加入。

第一场大师课的嘉宾是 Howie Xu，中文名号是硅谷徐老师。

他现在是 Gen Digital 的 Chief AI & Innovation Officer，同时是斯坦福大学的 guest lecturer。这次用的 PPT，就是从他在斯坦福的一场分享改编来的。

他自己那张 My Journey 是倒着看的，从右往左：

VMware 网络业务的创始人和负责人，Greylock 的 EIR（驻场创业者），自己创办 AI 安全公司 TrustPath 并做到被 Zscaler 收购，然后是三家纳斯达克上市公司的 AI 一号位。

我盯着这张图看了一会儿。这四段经历跨了大公司、VC、创业和上市公司高管，中间没有一段是同一种玩法——他后面讲的那些话，分量是从这张图上来的。

时间上说明一下：社区官网写的是 8 月 7 日，我记的是 8 月 8 日。这两个不冲突，是美西时间和北京时间的差。直播我没赶上，看的是录播。

主题一句话：AI 时代怎么先 survive（活下来），然后 thrive（长起来）。

Career Ladder vs. Superlinear

开场第一张对比。

一边是 career ladder，职业阶梯：一级一级往上爬，付出和回报大体成正比。另一边是 superlinear，超线性：回报不跟着投入线性走。

徐老师给的解释是两个词——一方面是复利，一方面是突破。特别一流的作品能带来超线性的回报。

这句话我第二遍才想明白它在说什么。它其实在说：如果你的回报是线性的，那你这辈子的上限就是你的工龄乘以时薪；能让你跳出这条直线的只有两样东西，一个是会自己滚的东西（复利），一个是跨过某个门槛之后世界对你的对待方式突然变了（突破）。

Superlinear 这个词的出处：Paul Graham 2023 年 10 月的文章《Superlinear Returns》。他的观点是，现实世界里的回报几乎从来不是线性的，做到「足够好」和做到「最好」之间差的不是一点点，而是量级。他给了两个造成超线性的机制：exponential growth（指数增长）和 thresholds（阈值）。前者是雪球会自己滚，今天多攒一点明天滚得更快；后者是过了某条线，世界对你的对待方式会突然切换，比如比赛只有第一名被记住。这两个机制正好对上徐老师说的复利和突破。

另外要拆开的是：课代表在 Q&A 里提到的「怎么做 great work，最重要的是提出一个好问题」，出自 PG 的另一篇《How to Do Great Work》（2023 年 7 月）。两篇是同一年的姊妹篇，主题连着，但不是一篇。

FAANG → MANGOS

徐老师用一组缩写的更替来说改朝换代这件事：以前大家挤破头想进的是 FAANG，现在这张名单已经换成 MANGOS 了。

两份名单：FAANG 是 Facebook（现 Meta）、Amazon、Apple、Netflix、Google（现 Alphabet），这个缩写 2013 年由 Jim Cramer 先提出 FANG，后来加进 Apple。MANGOS 是 Meta、Anthropic、Nvidia、Google、OpenAI、SpaceX。

摆在一起看才有冲击力：六家里只有 Meta 和 Google 是从上一份名单活着走过来的。掉队的那几家并没有变弱，是这份名单在回答的问题换了——从「谁掌握流量和分发」，换成了「谁掌握模型和算力」。

每隔一段时间就会改朝换代。所以要 rethink，要 reimagine。

他举的例子是马车。马车不是被更好的马车取代的，是被汽车取代的。然后他把问题落到今天：白领会不会消失？

课代表在这里划了重点，说这一段是徐老师自己的想法和思考。我把这个标注留着，因为它决定了这段话的分量。

Skills → Trust

徐老师的判断是：skill 终究会被 AI 蒸馏进去。

所以每个人都应该花很多时间去提升自己的 AI literacy（对 AI 的基本掌握程度），但真正留在你手上的不是 skill，是别人对你的信任。

怎么赢得信任？他说这是长期的事情，然后讲了 Sam Altman 和 Greg Brockman 的故事：很多 relationship 都是在不经意间建立的。当年一笔对 Stripe 的投资牵起的关系，后来变成了 OpenAI 的联合创始人；再到 2023 年 OpenAI 那场董事会风波，Greg 是第一个站出来支持 Sam 的人。（完整的时间线我放在文末附录里。）

我对这条的反应最大，因为它把我这些年做的一件事解释清楚了。

Go 夜读从 2018 年做到现在，中间没赚到什么钱，也谈不上什么规划。如果按 skill 算账，我从中获得的那些 Go 语言知识，今天让模型两小时就能讲得比我全。这八年真正沉下来的东西是另一样：一群人知道「杨文这个人靠谱，他说要做的事会做完」。这个 AI 蒸馏不走。

skill 会被蒸馏，trust 不会。这是我今晚认下来的第一条。

领航：earn trust 到底怎么做

领航是硅谷华人朋友之间互帮互助的一个活动，大家在里面聊职场，性质上更接近一个 coaching academy。徐老师是从这里讲 earn trust 的。

他先划了一条界：Jobs、Elon 这种人可以自己创造机会，但那是极少数。绝大多数人需要的是一个群体。你的 trust 和 reputation 是在群体里长出来的，不是自己给自己发的。

然后是两条很具体的建议。

第一条，参加一堂课、一个活动，就要抱着「我要从这里挖到多少东西」的心态去。 学到多少，其实是跟你付出成正比的。

第二条，一年之内不打算换工作，不代表你不该去看外面的机会。 要去建立连接，了解市场。不然机会真来的时候，你也不知道怎么选。

这条他讲了个亲身经历。有个 recruiter 找他，说：即使你现在不找工作也应该聊，因为等你以后真的想动的时候，机会摆在面前，你都不知道怎么去 calibrate 它。

calibrate：校准。意思是你手上得有一把尺子，才能判断一个机会到底是好是坏。一年不看市场，尺子就没了。

这里有个小插曲。我笔记里还记着「recruiter 用到的一个词是 angle」，这是从 AI 翻译字幕上抄下来的，我认为字幕在这里错了。跟 calibrate 配套的词应该是 anchor（锚点）——校准需要一个参照锚，这是仪器校准的固定搭配，angle（角度）在这句话里讲不通。两个词发音又近，AI 转写听岔的概率不低。

顺带说，这就是 AI slop 的一个活标本：一个词错了，整句话的意思还能勉强站着，所以你不会停下来，就这么滑过去了。我第一遍看的时候完全没觉得别扭。

他最后给 networking 下的定义是：这是一种很长期的、有价值的回报。

24 小时不会变，signal 和 noise 会

徐老师的话很朴素：每个人的时间都是 24 小时，这是不会变的。AI 时代真正变的是 signal（信号）和 noise（噪声）的比例——内容的生产成本塌到接近零，噪声就会涨到淹掉信号。所以你把时间花在哪里，这个决定变得比以前重要得多。

他的收束是：一个人最终的成功，不管在公司还是创业，其实都是一件 time management 的事。

AI slop：字面是「AI 泔水」，指 AI 批量生产的低质量内容——车轱辘话、看起来完整但没有信息量的文章、凑数的图。这个词 2024 年之后火起来，用来骂内容农场。

我笔记里在这附近还记了「person of the year AI」几个字，说的是 AI 已经无处不在了，文字、音频、视频，每一种介质都被灌满。这是 AI slop 之所以要紧的前提：你没有一处干净的地方可以躲。

我记这段的时候，正好在干一件很讽刺的事——我在花 4 个小时看一场两小时的课。但我认为这恰恰是他这句话的正解：噪声涨潮的时候，正确的动作是少看、看透、留下能带走的东西。看两遍一场好课，好过刷二十条 AI 快讯。

Career Impact = EQ × TQ × IQ

这是整场课的核心公式，也是我第二遍才补全的地方。

原来的版本是 Career Impact = IQ × EQ。徐老师把它拆开重新定义，再加了一项。

IQ = Intelligence + Intensity

Intensity 就是卷。徐老师的判断是：未来，卷的能力要比以前更重要了。

这句话我犹豫了一下要不要原样写出来，因为它在国内的语境里太容易被误读。但我觉得他说的和「加班」不是一回事——在执行成本被 AI 压到很低之后，人和人之间在「愿意把一件事推到什么程度」上的差距会被放大，而不是被抹平。

EQ = Emotion + Eyeball

Eyeball 就是注意力。他在这里玩了个梗：

Attention is all you need.

这句原本是 Transformer 那篇论文的标题，被他借过来说注意力经济。抓住别人的注意力，这件事在后面的 Q&A 里又被强调了一次。

TQ = Token Quotient

把 AI 用好的能力。这就是我第一遍整个漏掉的那一项，笔记里只剩两个孤零零的字母。IQ 是你脑子多好，TQ 是你能指挥多大的算力。

想把 TQ 弄明白，别只看这一张 slide。 课代表立正和徐老师有一期专门拆解 TQ 的访谈，比大师课上这一笔带过的定义细得多：B 站 BV1HuMk61ECq。我是先看的大师课、后补的这期，顺序反了，建议你倒过来。

三项相乘，落在最后那张 slide 上：

Win hearts. Command tokens. Show intensity.

赢得人心、指挥 token、拿出强度，分别对应 EQ、TQ、IQ。

Gold Collar Era 和 Founder Era

两张连着的 slide，一张说身份的变化，一张说责任的变化。

Gold Collar Era 那张写的是 Above routine white-collar work: judgment, taste, leverage. 白领往上走，变成金领，留给人的是三样东西：judgment（判断）、taste（品味）、leverage（杠杆）。这三个词的共同点是，都没法写进 JD，也没法用工时衡量。

Gold Collar：这个词本身不新，1985 年 Robert Earl Kelley 写过一本《The Gold-Collar Worker》，指高知识含量的从业者。徐老师用它的方式是重新定义过的：分界线跟学历和职级都没关系，只看你干的活能不能被流程写下来。能写下来的，就会被自动化。

Founder Era 那张只有一句：

Own the outcome, not the task.

小团队，full stack accountability（全栈担责）。你交付的不再是任务，是结果。

这两张放在一起看，其实是同一件事的两面。当执行本身不再稀缺，「我把任务做完了」就不构成交付；能证明你存在的只剩下你对结果的判断和你为结果兜的底。

History is all you need to watch

又是一个 all you need 的梗。

徐老师说：every platform shift changes work before it changes titles——每一次平台迁移，先改变的是工作内容，头衔的变化远远滞后。

他的建议是学历史。学数理化肯定是必须的，但也要学历史，学什么？就是永远不要去跟历史做斗争。

我笔记里在这句旁边写了雷军那句「在风口上，猪都能飞」。放在一起看很有意思：雷军那句常被理解成「运气很重要」，但配上徐老师这句，它的意思其实是「不要在逆风的方向上证明自己有多能干」。

Reimagination Era：1880 年那盏电灯

这是全场我最喜欢的一段，也是我第二遍才真正听懂的一段。主题句是 From workflow automation to workflow redesign.，从「把现有流程自动化」到「重新设计流程」。

徐老师用了电的例子。1880 年前后电被用进工厂，工厂原来的布局是以蒸汽机、发电机的位置为中心排的；用上电之后，如果还照着老办法围着动力源排，那就白用了，因为电线可以走到任何地方，布局应该由业务和工作流来决定。

我第一遍听的时候，脑子里想的是「哦，这个道理我懂」。第二遍我发现我并不懂，因为我说不出「围着蒸汽机排」到底是怎么排的。查完之后我把完整版放在文末附录里，那段历史比这句总结有力得多。

对着今天看：大部分公司引入 AI 的做法，还停留在把原来的流程原样保留、每一步塞一个 AI 进去。这是 workflow automation。Redesign 是承认有些步骤根本不该存在了。

Q&A 里我记下来的话

选方向不可能百发百中。 最终去看结果的时候，往往都是把一件事做得很精、很好的那些人。做 startup 经历风风雨雨很正常，关键是百分之百投入，而不是不认真地投。

三十年河东，三十年河西。 这句他说得很轻，但接在「选方向不可能百发百中」后面，分量不轻。

课代表补充：你自己要有一个比较强的 mental model。 不能当墙头草。听别人的意见，要听取对你有用的部分，而不是别人说什么你就变成什么样，把自己完全否定掉或者改掉。你要吸收别人的精华来补自己。

mental model：你脑子里那套用来判断事情的框架。有框架的人，别人的意见进来是被过滤和吸收；没框架的人，别人的意见进来是直接覆盖。同样是听建议，前者变强，后者变形。

判断自己有没有的办法很简单：听完一个和你观点相反的人讲完，你能不能说清「他哪里对、我哪里还是不改」。说不清，就是没有。

复合型人才。 以前你具备某一种能力就能进大厂，现在光有这个不够了。

提问题要从不同角度问。

关于「不要做大模型创业，去做 agent 开发」这句话，课代表专门做了澄清。 因为这句话被单独拎出来传播是会引起误解的。他给的关键词是 highly contextual——创业建议高度依赖具体情境，对你是好建议，对另一个人可能就是坏建议。

这个词让我坐直了。我现在做的 Context Engineering，做的就是同一件事的工程版：给 agent 的建议好不好，从来不取决于 prompt 写得多漂亮，取决于你把哪些上下文放进去了。人和人之间传递经验也是同一个问题——大部分「过来人的建议」失效，不是因为建议错，是因为上下文没跟着一起传过来。

然后他接了一句我很喜欢的：真正属于你的、正确的非共识，是挺重要的。

非共识：投资圈的框架，完整说法是 right and non-consensus，既正确，又和大多数人不一样。四种组合里只有这一种能带来超额回报：和大家一样且对，回报被摊薄；和大家不一样但错，亏钱；和大家一样还错，最惨。Peter Thiel 那道著名的面试题问的是同一件事——有什么重要的真相，是很少有人同意你的？

课代表加的限定词是「真正属于你的」，这个限定很关键。硬找一个和大家不一样的观点不难，难的是它同时还是对的、还是你自己想明白的。

这和徐老师说的「要提出一个好问题」是同一件事。

关于 coding agent 和 FDE：研发并不是效率越高越好，能不能让公司的 revenue 有增长，这才是重要的。

FDE = Forward Deployed Engineer，前线部署工程师。这个岗位是 Palantir 发明的：工程师不待在总部写通用产品，而是直接进到客户现场，把产品和客户的真实业务缝在一起。现在 OpenAI、Anthropic 这类公司都在大量招这个岗。

这句是今晚扎我最深的一句，我放在下面单独讲。

深入思考 AI slop。 要转化为 outcome，要转化为客户对我们的信任。

创业小团队面临的核心问题：一是方向判断——用户用不起来，到底是用户不喜欢，还是自己做得还不够好；二是竞争。

抓住别人的注意力，非常重要，也是一个很重要的能力。

徐老师的人生观 slogan：fool me once, shame on you; fool me twice, shame on me.（第一次被骗是你不对，第二次被骗是我不对。）

我抄走的三条

第一条：skill 会被蒸馏，trust 不会。

前面讲过了。对我的直接影响是，我要重新看待 Go 夜读和社区这件事的价值——它一直被我放在「业余爱好」那一栏，但按这个框架，它是我资产里唯一 AI 拿不走的部分。

第二条：研发效率不等于 revenue。

这条打的是我自己的饭碗。我这些年的工作重心是工程效率和质量建设，我们这行的默认叙事是「效率提升了就是好」——构建快了多少、缺陷少了多少、交付周期短了多少。

徐老师这句话把这个默认叙事掀了：研发并不是效率越高越好，关键是有没有让 revenue 涨。

我不是说效率指标没用，但我承认一件事：我过去交付的报告里，能把效率提升和收入变化连起来的，一份都没有。 中间那一段因果，我一直是绕过去的。这是我今晚最难受的一条，也是最该改的一条。

第三条：TQ 是可以单独练的。

IQ 基本定了，EQ 长得慢，TQ 是这三项里唯一能在短期内拉开差距的。作为 Cursor 中国区的第一个 Ambassador，我自认为在这条上有点位置，但徐老师的 Command tokens 这个说法还是提醒了我：TQ 不是「我会用哪个工具」，是「我能同时指挥多大规模的活」。这两件事差得远。

你今晚可以做的一件事

如果这篇你只带走一件事，那就是我今晚做的这件事本身：

找一场你最近觉得「讲得真好、我全懂了」的课或者播客，关掉它，打开一个空文档，把它的主线默写一遍。

不要回看，不要暂停，就默写。写不出来的地方原地打个问号，别跳过去，也别自己圆一个。

我今晚这么干，写出来的东西里到处是问号。那些问号才是我这 4 个小时真正的产出，「听懂了」的爽感不是。

徐老师那句「学到多少东西，其实是跟你付出成正比的」，说的就是这件事。你不去写、不去问，它就只是一场视频。

附：两段我查完之后想完整讲的背景

蒸汽机、电和四十年的滞后

蒸汽机时代的工厂长什么样？一台巨大的蒸汽机是全厂唯一的动力源，动力通过天花板上一根很长的传动轴（line shaft），再用皮带一条条分下来带动每一台机器。这带来几个后果：机器必须离主轴足够近，所以要挤；为了缩短传动距离，工厂要盖成多层的；机器怎么摆，取决于它离动力源多远，而不是取决于工序顺序。整座工厂是围着那台蒸汽机长出来的。

电来了之后，第一代做法是什么？把那台蒸汽机换成一台大电动机，传动轴、皮带、多层结构、拥挤的布局，一样不改。结果是生产率几乎没有提升。

真正的提升发生在几十年后。当每台机器配上自己的小马达（unit drive），传动轴可以整个拆掉，工厂就能改成单层的、宽敞的、按工序顺序排布的样子，也就是流水线。这时候生产率才起来。

经济学家 Paul David 1990 年那篇《The Dynamo and the Computer》讲的就是这个滞后：从电气化开始到生产率真正兑现，中间隔了大约四十年。四十年花在哪儿了？花在人们终于想明白「不用再围着动力源排」这件事上。

（年份我按徐老师说的 1880 年记的，作为参考：爱迪生的珍珠街发电站是 1882 年投运。）

所以 from workflow automation to workflow redesign 说的是：现在绝大多数公司用 AI 的方式，就是那台「换了个大电动机的老工厂」。

Sam 和 Greg 这条线有多长

我笔记里只有半句话：「投资 stripe，然后找 greg 加入他们公司，sam 就去帮忙做了链接」。补全之后是这样。

Sam Altman 在 YC 的时候，YC 投了 Stripe。Greg Brockman 当时是 Stripe 的 CTO，两个人的关系就是从这笔投资来的。

2015 年 OpenAI 成立，Greg 离开 Stripe 去做联合创始人，后来做到总裁。

2023 年 11 月，OpenAI 董事会突然解雇 Sam。Greg 是第一个站出来的人——他自己也被移出董事会，当天就辞职，公开站在 Sam 这边。

一笔投资牵起的认识，先是变成了创业伙伴，八年后又变成了对方最危险那几天里第一个站出来的人。

我在笔记边上写了一句：这种关系，建立的那天看起来毫无用处。

这就是「trust 是长期的事情」最硬的注脚。你没有办法在需要它的那一天才去建立它，因为它的计价单位是年。

写在最后

这篇是我今晚 4 小时的全部残渣。第一遍听的时候我以为我能写出一篇通透的解读，第二遍写完，我交出来的是一堆问号和三条判断。

这样的课，Stay Superlinear 一年有 12 场以上，前 3,000 位年费 $149 / ¥999。我从课代表开始做 B 站视频起就在看他，这次社区上线我是果断加入的，所以我的立场摆在这儿，你自己判断。

剩下两处我还没核准的，如果你看过直播，麻烦告诉我一声：

recruiter 那个词到底是 angle 还是 anchor（我看的是 AI 翻译字幕，我倾向于是字幕错了）；
「1880 年」这个年份是徐老师原话还是我记岔了。

也欢迎你来吐槽我，尤其是「研发效率不等于 revenue」那条——如果你手上有把效率提升和收入变化真正连起来的做法，那是我现在最想要的东西 🤔

0% 是机会，20% 是陷阱：Jeff Dean 离职前那场 YC 访谈里，我抄走了三条判断

Tue, 11 Aug 2026 22:20:00 +0800

起因

8 月 5 日，Google 宣布 AI 组织调整，Jeff Dean 在待了 27 年之后离职。他和 Sanjay Ghemawat、Quoc Le、Oriol Vinyals 一起出去做一家叫 Discovery Loop 的公司，Google 以创始投资人和 Cloud 合作方的身份继续支持。Alphabet 股价当天跌了大约 4%。

我是看到这条新闻，才回头去翻 YC 在 7 月底放出的那场访谈：《Jeff Dean: The 1% Rule for Building in AI》，Startup School 2026 现场录的，播客版 8 月 1 日上线，57 分钟（录制的具体日期我没查到，只能确认发布时间）。

看完我记下的第一句话是：他在这场访谈里已经把 Discovery Loop 要做的事整个讲完了，只是当时没人往那个方向听。

Diana Hu 问他「2027 年版的大胆预测是什么」，他的回答是：让 ML 系统自己跑大量实验来提升自己的能力，把问题拆成子问题，每个子问题丢进一个自动化的实验循环，再把结果拼回去。五天后公布的 Discovery Loop，官方说法是用 AI 自动化科学与工程里的实验流程，让机器并行地提出、执行、分析上千个实验。

同一件事，说了两遍。

所以这篇读后感我会写得具体一点。先摆两个人的资历——不摆清楚，后面那条 1% 规则的分量就出不来；然后是我真正抄走的三条判断，以及我要给 1% 规则加的两个前提。

这两个人的资历，得先摆一下

Jeff Dean

1999 年加入 Google，当时公司二三十人（Diana 在访谈里说 20 人，CNBC 的报道写「大约第 30 号员工」，我没能核实到底哪个准）。他自己在 X 上说，这段旅程里 Google 从大约 25 人长到 19 万人以上。今年 58 岁。

他的东西你大概率每天都在间接用：MapReduce、BigTable、TensorFlow、TPU、Gemini。2011 年联合创办 Google Brain。离职前的头衔是 Google 首席科学家。

还有两份不算论文但流传更广的东西：

「Latency Numbers Every Programmer Should Know」——一份延迟数字清单，cache miss 多久、磁盘寻道多久、一个网络包从加州到荷兰多久。Diana 说这份东西被无数分布式系统工程师打印下来贴在工位上，当《圣经》用；
《Performance Hints》——他和 Sanjay 写的内部性能调优文档，内部版约 30 页，2025 年 12 月对外公开在 abseil.io/fast/hints.html，里面的示例改动最早能追到 2001 年。

访谈里有个细节我挺喜欢：他是带着感冒来的，开场第一句就说 I'm afraid I've lost my voice. I don't normally sound quite like this, but we'll do what we can. 嗓子哑着讲了 57 分钟。

Diana Hu

主持人不是来念题的，她的资历得单独说。

智利人，Carnegie Mellon 电子与计算机工程本硕，方向是计算机视觉和机器学习。之后在 Intel Labs 做 ML 研究，在 OnCue 做数据科学（OnCue 后来被 Verizon 收购）。

2017 年她联合创办 Escher Reality（YC S17），做的是 AR 后端。2018 年被 Niantic 收购，她进去负责 AR 平台，把 AR 交付给了 1 亿以上的 Pokémon GO 玩家。她自己形容那次收购像是从 Seed 直接跳到 Series B。

2021 年以 Visiting Group Partner 的身份回 YC，2022 年转全职 Group Partner，2026 年 6 月升 Managing Partner。YC 的数据：带过近 230 家公司、18 个 batch，2100 多小时 office hours，这些公司加起来价值约 70 亿美元。

我把她的资历写这么细，是因为这场访谈的质量有一半来自她。后面我会单独讲她的提问手法。

判断一：0% 是机会，20% 是陷阱

这是整场访谈里唯一一条能直接拿去做决策的判据。Jeff 的原话：

So look for something where the model succeeds 0% or 1% of the time, not 20%.

我的翻译：去找通用模型成功率 0% 或 1% 的问题，不要去碰 20% 的。

反直觉的地方在后半句。20% 听起来是好事——说明路子对了，再优化一下就能到 80%。Jeff 的判断正好相反。他的原话是，如果模型「kind of able to do some of it but not very well」，那大概率说明这个能力已经开始在模型里出现了，接下来只要更多训练数据或者更大规模，它自己就会变好。

换成我的说法：20% 是通用模型已经踩进你这块地的信号。你在上面盖的东西，下一个版本发布就被平掉了。

0% 是机会，20% 是陷阱。

顺手澄清一件事：标题里的 1% 和复利那个 1% 完全不是一回事。我自己以前写过「每天 +1%，一年以后就是 37 倍」，那是讲积累。Jeff 这个 1% 是一条筛选阈值，讲的是别去做模型已经会做一半的事。两个 1%，方向相反。

他给了两种具体的 0% 形态：

你有模型拿不到的数据。 他举的例子是帮用户整理他自己的个人信息——通用模型没有这个访问权限，你的产品有，这就是优势；
你能训一个很窄但很准的模型。 他举 AlphaFold：一个只解蛋白质折叠的模型，别的什么都不会，但在那个域里准到能重塑整个学科。他说材料科学、芯片设计这类地方还有同形状的机会。

判断二：taste 听起来最虚，但他给了唯一能练的方法

Diana 问：如果每个创始人都学会同时跑上百个 agent，代码都由 agent 写，那时候稀缺的技能是什么？

Jeff 的回答是 taste——挑什么问题给 agent 做的品味。他把这个类比成做研究：一个研究者可以有全部的工具和技术，但大部分胜负在于你决定把时间花在哪个问题上。他的原话是，把一个相当无聊的问题研究得赏心悦目，远不如挑对问题然后解掉它。

到这一步我还嫌虚。让我抄下来的是 Diana 追问「how do you make it concrete」之后，他给的第二种练法：

Another way you can get more experience for yourself is to just write down a bunch of things you think might be important in the next 12 months. Maybe you pick one of them to work on, but go back and evaluate in 12 months which of these other things actually seemed important.

写下你认为未来 12 个月重要的一批事。挑一件去做。12 个月后回来看剩下那些：哪些真的重要了，哪些被别人做出来了，哪些根本没发生。

我认为这条是整场访谈里最可执行的一句。因为它把 taste 从「天赋」改成了「样本量」——你判断得准不准，取决于你手上有多少条已经结算过的判断。大部分人从来不结算，所以永远在攒第一条样本。

我今晚就建了这个清单。写了 9 条，2027 年 8 月回来打分。

他还给了第三种练法：做疯狂的思想实验。他现场举的那个例子挺震撼——芯片行业 60 年来的默认假设是「同一设计造出来的每一颗芯片都必须一样，一个 bit 都不许翻」，但在分布式系统这一层，我们从来不这么假设，我们是拿不可靠的零件搭出可靠的大规模文件系统。所以：如果你故意去造一种一天出 20 次错的晶体管，而不是一百万年出一次，整个设计方法会变成什么样？他自己补了一句 I'm not saying we should go do this，但这就是那种值得每隔一段时间回去捅一下的假设。

判断三：写清楚要什么，这件事的价值反而涨了

这条对我做交付和 QA 的日常最有用。

常见的想法是：agent 越聪明，我就越不用把需求写清楚。Jeff 的判断反过来。他说计算机科学从一开始就在教「写软件之前先说清它要达成什么」，现在有了能替你写的 agent，把要什么说清楚的重要性其实上升了——因为以前你是交给一个有上下文、还会反过来问你问题的聪明人。

他给的例证很硬：为什么今天的模型做跨语言迁移做得那么好？

In that case, you actually have an incredibly detailed specification. You have the whole software that says what the system is supposed to do.

因为那种任务里，你手上有一份完整到极致的 spec——整套代码，加整套测试。Python 实现要转 Go，模型可以把 Python 的测试翻成 Go 的，跑通，再逐条比对两个实现的行为差异直到没有差异为止。

所以「agent 在第 30 步跑飞了」这个问题，很多时候要往规格上查：你给的那份东西只够撑 10 步。

Diana 也问了 agent 跑飞的事。Jeff 的解释是：模型被训过的东西是一个分布，你一旦稍微走出那个分布，性能就会开始骤降，离舒适区越远掉得越快。他给的两个对策，一是用 skills 和 hints 把模型往它熟悉的亮路上引，二是搞多 agent：几个 agent 各试一种路子，再让另一个模型评估哪条有戏，砍掉跑飞的。

他自己也在写 skill。他说前几周和 Sanjay 一起，把他俩做微基准性能优化的那套人肉流程——测当前性能、改、重跑、跑更大一组基准、量 cache footprint——写成了一个 skill 教给模型，让它自己迭代。他的原话是 It really just is us giving the approach we would use as people to the model in a form that it could use.

然后 Diana 直接问了一句我很欣赏的话：这个 skill 别人能拿到吗？Jeff 说，那份《Performance Hints》已经公开了，有人把它喂给模型，模型在性能推理上就变好了。

那份文档因此有了第二种用法。你可以自己读，也可以塞进 CLAUDE.md 或者 skill 里给 agent 读。

我要给 1% 规则加两个前提

到这里都是我认同的。下面是我不太认同、或者我认为他没说透的部分。

第一，1% 规则是第二道筛子，不是第一道。

大家传播这条规则的时候，普遍把它当成选题公式：跑一遍模型，成功率 0% 的就是好机会。但 Jeff 自己在同一段回答里，把它明确放在了第二位。他的第一条是：

The most important thing is to pick something you're super excited about and want to build and you think would be useful in the world.

漏掉这句，1% 规则就会变成一台专门生产「无人区里的无人问题」的机器。模型成功率 0% 的问题海里去了，绝大多数是 0% 是因为没人要，不是因为没人做得到。这两种 0% 长得一模一样，但一个是机会，一个是坑。

1% 规则筛掉的是会被模型平掉的题，它筛不出值得做的题。

第二，0%/1% 是一张快照，快照守不住明天。

Jeff 自己给了对冲：他说通用模型正在覆盖越来越广的范围，你得判断你做的这件事，是前沿模型未来 6 到 12 个月就会做好的，还是两三年都做不了的。

所以真正要算的不是今天的成功率，而是这个成功率的爬升速度。今天 0%、明年 60%，和今天 0%、三年后还是 5%，在快照上完全一样。这一层他点到了但没给方法，我也没有。这里我承认没底：我暂时不知道怎么在事前可靠地估出爬升速度，只能想到一个笨办法——把同一组测试用例，每次模型发新版就重跑一遍，攒自己的曲线。有更好的做法欢迎来告诉我。

Diana Hu 的提问方式，我单独学一段

这场访谈里她做了三次同样的动作，我认为这是采访的手法，值得单独拆出来。

她每次都是：先把 Jeff 的一段历史，压成一个可复用的动作，然后原样抛回去问「2026 年的版本是什么」。

2001 年他和 Sanjay 算出整个搜索索引能装进全部机器的内存，几天就把 RAM 版搜索上了线，Google 搜索从此变快。她压成一个问句：2026 年那个「it fits in memory」的时刻是什么？ Jeff 的答案是高性能、低能耗的推理硬件；
那份延迟数字清单。她压成：给我们一个 AI 版的。 Jeff 现场给了——加速器主存到片上内存到乘法单元的带宽、一次乘法的能耗、芯片间互联带宽、能连多少颗、以及从 500 颗扩到 1 万颗时带宽的衰减；
TPU 的餐巾纸计算。她压成：今晚在座的人应该算一道什么样的餐巾纸算术？ Jeff 的答案是去找你眼前的瓶颈，别被「今天它是怎么解的」锚住，从第一性原理想有没有一两个数量级的做法。

对照我以前写评审 PPT 那篇里的判断，她做的正是同一件事：不让概念停在概念层，一定要落回听众明天能动手的那一层。区别是她在现场做，一小时里做了三次。

如果你要采访人，这个手法可以直接抄：别问「你怎么看 X」，去问「你当年那件事的今年版本是什么」。

顺手记几个数

访谈里砸出来的数，我认为都值得抄进笔记（以下全部是他在现场讲的，我没有二次核实）：

2013 年那次餐巾纸计算：如果每个 Google 用户每天对手机说 3 分钟话，服务器规模得翻一倍。这条算式最后长出了 TPU；
深度学习语音模型把错误率砍了一半，相当于语音识别 20 年的进展，只用了几个月调模型、加规模、换更好的数据；
第一代 TPU 比同期 CPU 和 GPU 能效高 30 到 80 倍，延迟低 20 到 30 倍；
做一次数学计算大约 1 皮焦耳，把数据搬进来要一千倍。这个一千倍就是 batching 存在的全部原因——你没法消掉它，只能用 batch size 去摊薄它。也所以极低延迟和 batching 天生打架；
他同事十年前做的一件事：拿密度泛函理论模拟器的输入输出去训一个神经网络近似，把一次要跑一整晚的验证变成快 30 万倍、精度接近的东西。他的评价是，这直接改变了做科学的方式——1000 万个候选，以前要凑半年算力，现在吃个午饭回来就跑完了；
今天的大模型看到的数据量，大概是一个 18 岁的人的一千倍，但那个 18 岁的人在很多事上还是更强。所以他认为数据效率极高、能持续学习的算法，是一个很值得做的方向。

还有一条不是数字，但是我最想抄的：他说 2014 年他和 Geoff Hinton、Oriol Vinyals 那篇讲蒸馏的论文，被 NeurIPS（当时叫 NIPS）拒了，理由是 it's unlikely to have significant impact。他们放到 arXiv 上，然后全行业都在用，Gemini 的 flash 系列就是从更大的 pro 模型蒸出来的。

他对这件事的态度是 so it gets rejected every so often; that's fine，没有一句抱怨评审。这一点比那篇论文本身更值得学。

你明天能怎么用

我把这篇能落地的部分收成四件事，都是今晚或者这周能动的：

给你手上正在做的功能量一个成功率。 拿最强的通用模型，别接你自己的提示词工程，跑 20 到 30 个真实用例，数它成功几次。落在 20% 到 60% 这个区间的，认真想想值不值得继续投；落在 0% 到 1% 的，再问一句「它 0% 是因为难，还是因为没人要」；
建一个 12 个月清单。 写下你认为未来 12 个月会变重要的事，不用多，5 到 10 条。写上日期，明年同一天回来给每条打分：真的重要 / 别人做了 / 没发生。这是给你自己的 taste 攒可结算的样本；
挑一件你重复做过五次以上的手工活，写成 skill。 Jeff 和 Sanjay 写的就是他们做性能优化的那套流程。你的可能是复现一个 bug、发一次版、review 一类 PR。判断标准很简单：如果你能对一个新同事口述这套流程，你就能写成 skill；
把《Performance Hints》读一遍，然后喂给你的 agent。 它主要讲单个二进制内的性能调优，明确不覆盖分布式系统和 ML 硬件，示例大多是 C++。读完你自己的性能直觉会长一截，塞给模型之后它在性能问题上的推理也会好一截。

写在最后

如果把这一小时压成三句话，我会留下：

别去做通用模型已经会做两成的事，去做它一点都做不了的事——但先确认那件事有人要。
taste 不是天赋，是你结算过的判断的条数。今晚就开清单。
agent 越强，把要什么写清楚这件事越值钱。

最后回到开头那件事。他在访谈里说的 2027 年预测，五天后变成了他自己的公司名。我的判断是：这跟巧合没什么关系。一个人真正相信的东西，你问他任何问题，他都会绕回去。所以听访谈的时候，值得多留意一句——他反复绕回的那件事是什么。

以上是我的读后感。这三条判断里，你最不认同哪一条🤔 也欢迎你来吐槽我，尤其是第二个前提那里我确实没底。

原视频：Jeff Dean: The 1% Rule for Building in AI，文字版在 ycrootaccess.com。本文引用的英文原句都来自这份文字版，中文是我自己的翻译。

如何从自己写过的文章里提炼写作风格：我翻了 12 篇旧文，最后只有 2 篇能当骨架

Thu, 06 Aug 2026 21:40:00 +0800

起因

我最近让 AI 帮我写工作文档，交上来的东西大概是这个长相（我把几份文档的共同毛病捏成了一句）：

通过体系化的能力建设，进一步赋能团队完成端到端的交付闭环，显著提升整体交付质量。

一句话里有四个词我自己从来不说：体系化、能力建设、赋能、闭环。而且它很自信——「显著提升」后面没有一个数。

这种东西我删了不少。删到某一天我才反应过来：我一直在用提示词治它。「说人话」「别用黑话」「口语化一点」——这次听了，下次照旧。

后来我看到宝玉老师那篇《别再用提示词去 AI 味了，方向就是错的》。他的判断是：靠提示词去不掉，你得给 AI 一份写下来、能持续更新的写作风格 Skill。他用做菜打比方——提示词是每次口头跟厨子喊「少放盐」，Skill 是一份写在纸上的菜谱。

我认同这个方向。于是我干了一件事：把自己从 2019 年到今年写的博客翻出来，让 AI 逐字读，反推出我自己的风格。

结果比我想的难。这篇文章记录我踩的四个坑，和最后留下的取舍。

我具体做了什么

动作很简单：挑 12 篇文章交给 AI，让它读原文，归纳我的用词、句式、结构、语气，产出一份 Skill。

最后的产出是三个文件：

SKILL.md —— 底味 5 条 + 骨架 2 套 + 一节红线
references/banlist.md —— 忌口表，47 条，分 9 类
references/voice-samples.md —— 12 组我自己的原文切片

12 篇里，真正拿到逐字原文的只有 8 篇；能当骨架用的，最后只剩 2 篇。

下面说为什么。

坑一：摘要没用，语料必须逐字

第一次抓取的时候，工具擅自把 4 篇文章压成了英文摘要。我拿到的是这种东西：

The author draws parallels between Formula 1 and business strategy, emphasizing that major decisions have cascading consequences.

它对应的是我原文里的一行 bullet：

牵一发而动全身时，做决定时要慎重。

意思保住了，风格全丢了。

丢掉的是：我写的是 bullet 不是段落；我用成语，不用解释性长句；我没写「因此」这类连接词；整句 12 个字。

风格恰恰全在这些地方。 标点、段落长度、有没有连接词、小标题是名词还是问句、emoji 放在哪——摘要一律不保留。

所以第一条规矩：语料必须是原始 Markdown，逐字。我后来直接在本地 blog 仓库里读文件，比抓网页可靠得多，也快得多。

坑二：不要把全部文章拿去平均

我一开始的想法是「文章越多越准」。读完之后我改了主意。

我的年终总结那一类，说实在的写得挺水。数据砸出来不解读——2022 年那篇我列了 26 本书的书名，一句都没说哪本改变了我什么。「个人部分」那一节我只写了两个字：

待补~

《带你开始探究 Go iota》那篇里，「言归正传」出现了两次，是我当时自己没检查。

这些毛病如果一起丢进去平均，AI 学到的会是「列清单、砸数据、不下判断」。这恰好是我最想让它别干的事。

所以最后的取舍是按维度分层取，不是按篇数取：

骨架只学 2 篇：《如何评审一份让听众真正有收获的分享 PPT》和《带你开始探究 Go iota》。这两篇的结构是我自己最满意的。
语气从年终总结那一类里取。那些文章结构不行，但自贬和认账写得最真。
剩下的只作参照，不进范文库。

宝玉那篇里说「发你最满意的三到五篇」，这是对的。我要补一句：满意的篇数不够时别凑数，改成按维度分层。你的结构最好的那篇，和你语气最真的那篇，通常不是同一篇。

坑三：忌口表只能让 AI 不难吃

47 条忌口表列出来的时候我还挺满意。赋能、抓手、闭环、颗粒度、护城河、飞轮、深耕、老兵、范式，一条条禁掉。

然后我回头去看 AI 之前给我写的那些文档，发现一个问题：就算这 47 个词一个都不出现，它写出来的东西照样不像我。

它的开头永远是这个类型：

本次分析基于近三个月的交付数据，从流程、人力和技术三个维度展开。

一个禁词都没有。但这不是我的开头。我的开头是这样的：

这就要从我最近遇到的一次 protobuf 解析报错说起，错误信息如下：cannot parse reserved wire type

培训同事给我的反馈就是大多数人会遇到的典型问题：内容很大，但留下的收获点不多。

差别在哪？AI 先立框架再找例子填，我是从一件真实发生过的事出发。

这才是 AI 味的根，不在词上。词只是症状。忌口表能保证它不难吃，保证不了它像你做的菜。

所以我把 SKILL.md 的顺序倒过来写了：骨架排第一，忌口表排后面。骨架长这样：

1. 触发事件 —— 具体到一条报错、一句话、一个数
2. 我踩了什么坑 —— 包括做错的部分
3. 可核对的数字
4. 我的判断 —— 用「我」
5. 你明天能怎么用 —— 具体到第一步做什么
6. 我不确定的地方

你现在读的这篇，就是照这个骨架写的。

坑四：别人的忌口表不能照抄

宝玉的忌口表里禁「不是 A，而是 B」这个句式，理由是它是 AI 最爱用的招牌句。

我照抄了。抄完之后回头核对我自己 7 月那篇《先做一个自己每天离不开的 App》，发现里面用了两次：

我不是跑步时顺便听播客，而是为了听播客，才开始去跑步的。

观察一：AI 时代，个人开发的瓶颈不是写代码，而是敢不敢砍

两次都成立，而且是那篇里我自己最喜欢的两句。

我又核对了《Go iota》，发现我在句中写过「说实话，我用 Go 这么久，还是第一次见 -iota」——而我的忌口表里，「说实话」是整个禁掉的。

所以规则我改了两条：

「不是 A，而是 B」不全禁。判断标准是 A、B 两边是不是具体名词。「标题不是包装，而是承诺」可以留，包装和承诺都是实词；「不是简单的优化，而是系统性的重构」必须删，两边都是空词。另外整篇限量，一到两次，AI 会每三段来一次，那就出味了。
「说实话」禁的是当开场废话，不禁句中使用。

忌口表要用你自己的原文去核对，不能抄一份就完事。 一条规则如果和你写得最好的那句话冲突，改规则，别改句子。

我加的一节：不许替我编

这是我和宝玉那套方法最大的不同。

他那篇是给个人写作用的。而我 80% 的产出是工作文档：风险分析、技术方案、QBR、给 leadership 的材料。

在博客里编错一个数，丢脸。在给老板的材料里编一个「预计降低 30% 交付风险」，是要出事的。

所以 SKILL.md 里单独有一节红线，优先级高于所有风格规则：

数字不许估算成确定值，没有就写 [数据待确认]
判断和承诺不许代我下
人名和归属不许猜，不确定就写 [owner 待确认]
风险等级不许自己定 P0/P1，给我依据，等级我定
引用我文章、邮件、报告里的原话必须逐字，不许改写后当引用

其中我最想单独点出来的，是这一类翻译：

AI 写的	它真正的意思
建议持续关注	我不知道
相关团队跟进	我不知道谁负责
后续尽快推进	我不知道什么时候
存在一定风险	我不知道会坏在哪

把「我不确定」包装成一条行动项，是我见过最恶劣的一种 AI 味。 它比黑话危险，因为黑话一眼能看出来，这个看不出来，还会被当成结论往上传。

不知道就写不知道。这一条我在博客里一直做得到——

网上还有阐述（但是我并未能考证，保留至此，以供大家参考）

注意：此处的 ConstExpr 是在 Go 仓库 master 上才有，在当前 go1.16.3 是没有这个申明的。

工作文档里更该做到。

你明天能怎么用

如果你也想从自己写过的东西里提炼一份，我的流程是这样，一小时能跑完第一版：

挑 3 到 5 篇你自己最满意的。 必须是你自己写的，不是 AI 帮你写的。找不到 5 篇就找 2 篇，别凑数。
拿原始 Markdown。 不要摘要，不要抓网页，直接从你的仓库或备份里读。
让 AI 先归纳骨架，再归纳词。 问它这几个问题：我的开头第一段通常是什么？我的小标题是名词还是问句？我在哪里下判断，用的是什么人称？我在哪里承认自己不行？
拿一份最近真要写的东西试。 别拿虚构题目试，虚构题目试不出问题。
手动改。 不要在对话里跟 AI 说「这里改一下」，自己动手，一句一句改成满意的样子。
做 diff，把规律回灌。 熟悉 git 就 git diff；不熟悉就把 AI 原文和你的修改版一起给它，让它归纳你改了什么、为什么改，然后更新忌口表和骨架。

第 5、6 步是唯一真正让它变准的动作。前四步只是起点。

另外一个小提醒：忌口表别无限长。规则太多会互相矛盾，也会挤占上下文。到六十条左右就该让 AI 帮你归纳合并成规律——有了规律，就不需要那么长的清单。

我不确定的地方

说实在的，我这份 Skill 现在还是「读出来的」，不是「改出来的」。

宝玉说他自己那份迭代了好几个月、150 多行，是改了几十篇文章之后慢慢磨出来的。我才刚跑完第一轮，改稿回灌一次都还没做。所以它现在大概能挡住黑话和空洞框架，离「AI 写出来比我自己写的还像我」差得远。

还有 4 篇文章我只拿到了摘要，没进范文库。补齐之后我会更新。

Skill 的三个文件我会整理到 github.com/yangwenmai/skills（上次那份 presentation-core-review 也在这里），具体路径待补~

以上就是我这一轮的全部取舍。哪一条你觉得有道理，哪一条你觉得我想多了？欢迎来吐槽我 🤔

先做一个自己每天离不开的 App：我用 Cursor 三个月上架 App Store 的三个一手观察

Fri, 17 Jul 2026 22:00:00 +0800

先交代一下背景。

我每天都会花 30 分钟到 2 小时听音频、看视频：跑步和通勤时听中英文播客，练力量时看 B 站长视频。说得更诚实一点，我不是跑步时顺便听播客，而是为了听播客，才开始去跑步的。

但市面上大多数音视频 App 都在做「发现」和「推荐流」，这并不符合我的信息输入习惯。我更需要的是一个安静、稳定的工具：把自己主动选择的内容放在一起，随时接着上次的位置继续听，同时能够看到长期积累。

于是我开始想：要不自己做一个？

最初，我只是和 ChatGPT 讨论想法、产品定位以及该如何实现。随着方向逐渐清晰，第一版产品规划也慢慢成形。后来，我用 Cursor 开始真正写代码，并把这个产品命名为 ContextEcho。

ContextEcho 是一款克制的 iOS 音视频播放工具。它不做节目发现、不做社交、不做推荐流，也不做 AI 总结，只专注于两件事：

稳稳地听；
看见自己的积累。

这里的「积累」包括连续使用天数、累计时长、节目排行和收听热力图。是的，你应该已经看出来了，我是一个数据控。

从第一行代码到 App Store 上架，我用了 76 天，提交了 468 个 commit，最终写下约 4.8 万行 Swift。整个过程几乎都在和 Cursor 结对完成。

这篇文章不打算介绍每一个开发细节，也不是为了「求下载」。我更想记录这三个月里真正改变了我对 AI 编程、个人产品和独立开发看法的三个观察。

观察一：AI 时代，个人开发的瓶颈不是写代码，而是敢不敢砍

AI 极大提高了代码产出速度，但它没有替我解决最难的问题：什么不应该做？

开发 ContextEcho 的过程中，我先后做过三次定位调整。最激进的一次，是删掉当时最让我兴奋的全部 AI 功能，包括 AI 注解、自动回顾和「回声库」，一次净删了近 3000 行代码。

原因说出来有些尴尬：这些功能虽然做得很费劲，我自己却根本不会打开。

我每天真正会用的，只有两个部分：打开 App 接着听，以及查看自己的收听统计。既然连开发者本人都不使用，那些看起来先进的功能就没有留下来的理由。

AI 的默认倾向往往是做加法。你让它继续完善一个功能，它通常可以给出更多方案、更多页面和更多代码，但它很少主动告诉你：「这个功能没有必要，删掉吧。」

是否砍掉一个功能，最终仍要依靠真实使用中的判断。

上架前，我已经连续使用 ContextEcho 72 天，累计收听约 158 小时。这个过程让我确认，它不是一个只存在于 PRD 和截图里的 Demo，而是已经进入了我自己的日常生活。

这也是我三个月里最大的收获：

先做一个自己每天离不开的东西，再谈给别人用。

对个人开发者来说，AI 可以把「能不能做出来」的门槛降得很低，但产品取舍、真实需求和长期使用，依然只能由人来判断。

观察二：流量会围观你的里程碑，但不会替你验证需求

ContextEcho 上架前后，我在 X 上陆续发了十几条相关内容。把数据放在一起看，会发现一个非常明显的差异：

里程碑式内容的阅读量很高：

冲上付费榜：13.4k；
正式上架 App Store：11.3k；
发布真机演示视频：5.7k。

但日常使用内容的阅读量完全是另一个量级：

分享「连续听了 20 天」：229；
装上开发者版本并邀请内测：275；
分享自己跑步时听的单集：147。

结论很直观：大家更愿意围观一个有明显节点的故事，例如「正式上架」「冲进榜单」或者「第一次做出完整产品」；至于普通的使用记录，通常很难产生同等传播。

下面三条内容，分别对应真机演示、正式上架和冲上教育类付费榜：

但传播不等于需求验证。

正式上架的推文有 1.1 万阅读，而我更早公开邀请内测时，几乎没有人报名。那时心里确实有些凉：大家在评论区觉得想法不错，真正愿意装起来用的人却很少。

真正推动我上架的，是一次 Cafe Cursor Shenzhen 线下活动。十几位朋友当面体验后给出的认可和鼓励，让我下决心购买 Apple Developer Program 账号，把产品送进 App Store。

上架后，ContextEcho 首发排在教育类付费榜第 125 名，后来最高升到第 23 名。更重要的是，内测群里开始出现真实用户，他们会直接告诉我哪里不好用、哪里有 Bug、还希望解决什么问题。

这和自己埋头使用是完全不同的状态。

X 可以帮我扩散故事，但产品究竟有没有价值，最终仍要交到用户手里才能知道。阅读量、点赞和评论可以带来信心，却不能替代留存、反馈和真实使用。

坦白说，ContextEcho 目前的下载量并不算多。但它确实帮助到了一小群和我有类似需求的人。对我的第一款 App 来说，这已经是一个很有价值的起点。

观察三：中国区 App Store 的 ICP 备案，越早准备越好

第三个观察与产品设计无关，却是独立开发者很容易忽略的现实问题：中国区 App Store 的 ICP 备案。

中国区 App Store 已开始要求 App 提供 ICP 备案信息。我第一次上架时没有准备备案，靠着政策过渡期暂时正常销售。后来，在数据表现最好的时候，我提交了 1.2.0 版本更新，结果触发备案要求，App 直接从中国区下架。

好消息是，个人开发者也可以完成 App 备案，并不要求公司主体。

我后来选择通过阿里云代为提交，主要流程包括：

购买一个可备案的域名；
购买符合备案要求的轻量应用服务器；
按引导填写 App 和开发者资料；
接听备案审核电话；
收到工信部短信后，在 24 小时内完成核验。

因为我已经不再享受新用户优惠，域名和服务器一共花了 300 多元。整个流程前后大约 6 天。拿到备案号后，我将它填入 App Store Connect，十几分钟后，App 就恢复上架了。

完整的补办过程和注意事项，我另外整理在这篇文章里：我的 App 被中国区下架后：一次 App Store ICP 备案紧急补办实录及实践指引。

这次教训可以浓缩成一句话：

如果准备在中国大陆上架 App，请尽早办理 ICP 备案。

老应用可能暂时处于过渡状态，但提交新版本时就可能被要求补齐备案。不要像我一样，等榜单数据刚有起色、兴冲冲发布更新时，才发现产品被下架。

写在最后

回头看这 76 天，写代码反而不是最难的部分。

Cursor 让我能够在没有完整 iOS 开发经验的情况下，把一个想法快速做成可运行、可迭代、最终能够上架的产品。但产品定位要不要调整、辛苦做出的功能该不该删除、社交平台上的热度是否代表真实需求，这些问题仍然需要自己面对。

如果要把这三个月的经历再压缩一下，我会留下三句话：

先做一个自己每天离不开的产品。
把流量当作传播，不要把它误认为需求验证。
面向中国区上架，尽早准备 ICP 备案。

这是我第一次完整经历从想法、开发、内测到 App Store 上架的全过程。产品还很小，我也仍然是一个新手 builder，但正因为亲手踩过这些坑，它们才值得被记录下来。

ContextEcho 官网（含产品截图和完整介绍）：https://www.contextecho.top/

我的 App 被中国区下架后：一次 App Store ICP 备案紧急补办实录及实践指引

Tue, 14 Jul 2026 22:00:00 +0800

先说结论：如果你的 App 要在中国大陆上架，趁早把 ICP 备案办了。我就是没提前准备，结果在数据最好的时候被下架，才被迫紧急补办。这篇文章是我自己的一份记录，也希望能给同样踩坑的独立开发者一个参考。

整个流程我主要参考了这篇很棒的实践文章 App Store 中国大陆 ICP 备案最佳实践，在此基础上补充我自己遇到的额外问题和踩过的坑。

起因：更新一个版本，App 就被下架了

我的 App 叫 ContextEcho。一开始上架的时候我并没有准备 ICP 备案，第一次上架后数据其实很不错：

教育榜单最高冲到第 23 名；
应用榜单也进过 100 多名。

拿到这个数据后，我很快做了一轮优化，发布了 1.2.0 版本。没想到，更新之后我的 App 直接被下架了。排查下来，原因就是 ICP 备案——因为缺少备案，App 在中国区被下架了。

这里有一个很关键、也很容易被忽略的点：

我原本其实可以不用申请备案的，但因为我做了一次版本更新，就触发了备案要求，导致被下架。

也就是说，老应用可能因为政策的过渡期还能苟着，但一旦你提交新版本更新，就很可能被要求补齐备案。所以别抱侥幸心理，早办早安心。

备案选择：个人开发者首推阿里云

理论上，你可以自己通过工信部的国家互联网基础资源管理系统去备案。但流程繁琐、资料要求多，对不熟悉的人来说很容易出错、失败。

所以我的建议是走「网络接入服务提供商」，也就是阿里云、腾讯云、华为云这类云服务商代为提交。它们和管局对接顺畅，成功率更高。

在国内，我个人还是首推阿里云，简单方便，文档完善，跟着走基本不会错。如果你已经在某个云厂商有域名或服务器，直接用那家就行；没有的话，随便选一家即可。下面都以阿里云为例。

购买域名：注意个人实名认证要时间

第一步是从阿里云万网买一个域名。

需要注意的是，购买域名要做个人实名认证，这一步是需要一些时间的，别卡在最后一刻才办。

另外，这个域名你不一定真的要在 App 里用，它只是备案的一个必要条件。如果只是为了备案，选一个便宜的后缀即可；如果确实要用，那就认真挑一个。购买前记得看清楚说明，避免买到不能备案的域名后缀。

购买云资源：我买的是轻量应用服务器

除了域名，备案还需要一个符合要求的云资源。

我买的是轻量应用服务器。不过要提醒的是，我这次的费用是 300 多元，因为已经没有新用户权益了。如果你是新用户，价格会便宜很多。轻量应用服务器后续可以关联多个备案 App，对个人开发者来说够用了。

同样地，云资源也不一定要真的拿来用，它也是备案的必要条件之一，但不能乱买，得满足备案的最低配置要求，否则关联不进备案申请。

填写备案信息：跟着阿里云文档走就行

买好域名和云资源后，就进入填写备案信息的环节。入口在这里：

阿里云备案控制台：https://beian.aliyun.com/pcContainer/myorder

阿里云的流程引导非常清晰，基本上就是跟着它的文档一步步填，关联好对应的域名和云资源，做完实人认证后提交即可。这里我就不赘述具体的每个字段了，照着提示来几乎不会错。

等待审核：这几个坑一定要注意

提交之后，剩下的基本就是等，但等的过程里有几个坑值得说一说。

坑一：确保你的电话畅通

阿里云会有备案审核专员打电话跟你核实信息。我就吃了个亏——当时人在地铁里，手机不知道为什么没响，硬生生漏接了阿里云的电话。

幸好我后来看到了未接来电和短信提醒，短信内容大致是这样（已脱敏）：

【阿里云】备案审核专员现需与您核实信息，但未能联系到您/已联系到您但未能核实身份信息。您可点击 https://t.aliyun.com/ZZZZZZ 申请立刻回电；稍后我们也会再次联系您，请耐心等待并注意接听。

我重新点链接申请了回电，才顺利完成核实。所以备案期间务必保持手机畅通、注意接听陌生来电。

坑二：收到工信部短信后 24 小时内完成验证

阿里云核实完信息、把订单提交管局后，会发来这样一条短信（已脱敏）：

【阿里云】备案订单 20307YYYY5079 已经提交管局，请备案负责人（杨*: 1867****YYY）收到工信部短信后，务必在 24 小时内完成验证，否则会被退回。管局将在 20 个工作日内完成审核，备案结果管局会直接通知您，请耐心等待。

之后就是等工信部的两条关键短信，一条是验证码，一条是审核通过通知（均已脱敏）：

2026-07-08 【工业和信息化部】验证码：YYYYYY。您的新增备案已提交，核验链接：beian.miit.gov.cn，有效期 1 天【工信部 ICP 备案】

2026-07-14 【工业和信息化部】尊敬的用户 YYY，您的 ICP 备案申请已通过审核，备案/许可证编号为：粤 ICP 备 20260ZZZZZ 号，审核通过日期：2026-07-14。特此通知！【工信部 ICP 备案】

收到验证码短信后一定要在有效期（1 天）内完成核验，否则会被退回，白等。

整体耗时：大约 6 天

从提交到拿到备案号，我这次整体大概花了 6 天。核心时间其实都花在等管局审核上，这一步谁也加速不了太多。

恢复上架：填入备案号，10 来分钟就好了

拿到工信部下发的 ICP 备案号后，把它填到 App Store Connect 后台对应的备案配置里就行。填完之后，大概 10 来分钟，我被下架的 App 就恢复了。

这里补充一个别人踩过的坑：如果你直接填管局短信里的备案号，可能会遇到「ICP 备案号与中国工业和信息化部（MIIT）记录不符」的提示。这时候到工信部备案查询查一下自己的备案号，复制 ICP 备案服务信息里的那个（一般后面会带 -1A 之类的后缀）再填进去即可。

省钱与避坑：这些付费服务基本没必要

在整个过程中，阿里云会不断给你推销各种付费的备案增值服务。我的结论是：对个人开发者来说基本都没必要，自己填几乎零成本。

我遇到过的几种：

备案智能助理，99 元/次：备案智能助理
备案管家服务，600 元/个：备案管家服务

说实话，自己填材料几乎是零成本，时间也花不了多久，因为核心还是在等工信部审核。这些付费服务顶多帮你在阿里云这端加速一点点，大概也就差 1 天多的时间——工信部那边你照样得等。所以我个人觉得完全是浪费钱。当然，如果你确实很赶时间、又不差这点钱，那也可以买，看个人取舍。

时间线小结

把我这次的关键节点简单捋一下：

提前：从阿里云购买域名（个人实名认证）+ 轻量应用服务器（约 300 多元）；
提交：在阿里云备案控制台填写并提交备案信息，做实人认证；
核实：接到阿里云审核专员电话核实（我一度漏接，靠短信重新申请回电）；
提交管局：阿里云短信通知订单已提交管局；
2026-07-08：收到工信部验证码短信，在有效期内完成核验；
2026-07-14：收到工信部审核通过短信，拿到粤 ICP 备案号；
恢复：把备案号填入 App Store Connect，约 10 分钟后应用恢复上架。

整体约 6 天。

写在最后

回过头看，这次下架完全是可以避免的——只要我一开始就把备案办好。所以还是那句话：要在中国大陆上架，就早点把 ICP 备案办了，别等到数据起来、正兴冲冲发版本更新的时候被下架。

流程本身其实不复杂，跟着阿里云的引导一步步走就行，真正考验人的是耐心和信息畅通（尤其是电话）。希望我这份记录能帮你少走一点弯路。

Reference

如何评审一份让听众真正有收获的分享 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 名，生涯首次获得积分

周冠宇比赛事故

茶歇驿站

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

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

推荐播客

播客客户端推荐

我主要收听的播客节目

Golang Channel

YouTube

Bilibili

我的书单

计划读

已读（部分）

想读（部分）

推荐书单

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

关于我

社区和开源

产品

工作

最近在分享什么

写代码之外

怎么找到我

听的时候全懂，一动笔全废：硅谷徐老师大师课上的 EQ × TQ × IQ

起因

这场课和这个人

Career Ladder vs. Superlinear

FAANG → MANGOS

Skills → Trust

领航：earn trust 到底怎么做

24 小时不会变，signal 和 noise 会

Career Impact = EQ × TQ × IQ

Gold Collar Era 和 Founder Era

History is all you need to watch

Reimagination Era：1880 年那盏电灯

Q&A 里我记下来的话

我抄走的三条

你今晚可以做的一件事

附：两段我查完之后想完整讲的背景

蒸汽机、电和四十年的滞后

Sam 和 Greg 这条线有多长

写在最后

0% 是机会，20% 是陷阱：Jeff Dean 离职前那场 YC 访谈里，我抄走了三条判断

起因

这两个人的资历，得先摆一下

Jeff Dean

Diana Hu

判断一：0% 是机会，20% 是陷阱

判断二：taste 听起来最虚，但他给了唯一能练的方法

判断三：写清楚要什么，这件事的价值反而涨了

我要给 1% 规则加两个前提

Diana Hu 的提问方式，我单独学一段

顺手记几个数

你明天能怎么用

写在最后

如何从自己写过的文章里提炼写作风格：我翻了 12 篇旧文，最后只有 2 篇能当骨架

起因

我具体做了什么

坑一：摘要没用，语料必须逐字

坑二：不要把全部文章拿去平均

坑三：忌口表只能让 AI 不难吃

坑四：别人的忌口表不能照抄

我加的一节：不许替我编

你明天能怎么用

我不确定的地方

先做一个自己每天离不开的 App：我用 Cursor 三个月上架 App Store 的三个一手观察

观察一：AI 时代，个人开发的瓶颈不是写代码，而是敢不敢砍

观察二：流量会围观你的里程碑，但不会替你验证需求

观察三：中国区 App Store 的 ICP 备案，越早准备越好

写在最后

我的 App 被中国区下架后：一次 App Store ICP 备案紧急补办实录及实践指引

起因：更新一个版本，App 就被下架了

备案选择：个人开发者首推阿里云

购买域名：注意个人实名认证要时间

购买云资源：我买的是轻量应用服务器

填写备案信息：跟着阿里云文档走就行

等待审核：这几个坑一定要注意

坑一：确保你的电话畅通

坑二：收到工信部短信后 24 小时内完成验证

整体耗时：大约 6 天

恢复上架：填入备案号，10 来分钟就好了

省钱与避坑：这些付费服务基本没必要

时间线小结