- Website
- Baoyu
- Followers
- —
- Following
- —
Key Highlights
运气表面积公式：运气=做事×告诉别人，强调热爱与传播结合才能增加好运机会 1 post
技术从业者常低估自身经验价值，分享日常经验可能为他人提供新视角 1 post
分享内容不必追求完美，过程、挫折和故事本身具有吸引力 1 post
Main Topics (2)
Latest posts
Claude Code 5亿美元背后的AI工程革命
来整理一下 Claude Code 诞生的故事，主要来源是科技博主 Gergely Orosz 采访 Claude Code 核心成员的文章。 Claude Code 确实了不起，5 亿美元年化收入，三个月用户量涨了 10 倍，现在也是很多程序员首选 Coding Agent 工具。 这个工具最初只是一个能告诉你“现在在听什么歌”的命令行小玩具。 Gergely Orosz 采访了 Claude Code 的三位核心成员： 创始工程师 Boris Cherny（17 年从业经验，前 Meta 主任工程师） 二号工程师 Sid Bidasaria（Subagents 功能的作者） 以及产品
运气表面积公式：让好运找到你
我一直觉得运气这是纯粹看命，有的人就是运气好，有的人就是运气差。 今天看到一个有意思的观点，叫“运气表面积”（Luck Surface Area）： > “你生活中会有多少‘无心插柳柳成荫’的意外之喜？这取决于你的‘运气表面积’ (Luck Surface Area)。简单来说，这个面积的大小，是由你对某件事的热爱程度，以及你能把这件事有效地传达给多少人，这两者共同决定的。” —— Jason Roberts （来源：https://www.codusoperandi.com/posts/increasing-your-luck-surface-area ） 上面这个观点包含两个核心要素： 1
将文章、故事变成漫画脚本提示词参考
案例：深度之赌：从卧室到上帝机器 生成脚本示例对话：https://gemini.google.com/share/5a8802514d11 画图示例对话：https://gemini.google.com/share/e0c3b6f93825 --- Prompt --- 请为一本若干页（另加1页封面）的原创知识传记漫画创作详细的结构和情节设计。本漫画采用《Logicomix》式的叙事风格，适合呈现科学探索历程、跨越数十年的时间线，以及复杂概念的可视化解释。 视觉风格定义： 线条清晰（Ligne Claire）：参考Hergé《丁丁历险记》或Joost Swarte的画风——轮廓线均匀
深度之赌：从卧室到上帝机器
【引子】 2012年冬天，内华达州太浩湖畔，一家赌场。 楼下，赌徒们拉着老虎机，每赢一万美元，铃声大作。楼上，一群搞机器学习的研究者正在开会——这是当年的NeurIPS，没人愿意赌钱，赌场恨死他们了。 但赌场不知道的是，楼上正在进行一场更大的赌博。一个64岁的教授和他的两个学生，正在把自己"卖"给出价最高的买家。每次加价一百万美元。 这三个人后来被称为"深度学习三巨头"中的核心力量。那个教授叫Geoffrey Hinton，刚刚拿了诺贝尔奖。他的两个学生，一个叫Ilya Sutskever，后来创办了OpenAI又离开了；另一个叫Alex Krizhevsky，他在父母家的卧室里训练出了一个叫
Stack Overflow 2025 年度报告：写代码如果不值钱了，我们该去哪？
84% 的人在用 AI 工具，创历史新高。但正面评价呢？从去年的 70% 跌到了 60%。 Stack Overflow 在今年 7 月底发布的 2025 年度开发者调查（https://survey.stackoverflow.co/2025 ），这是他们连续第 15 年做这件事。来自 177 个国家的程序员填写了问卷，覆盖 314 种技术栈，今年还专门加了 AI Agent 和大模型相关的问题。如果说有什么能代表全球程序员的集体判断，大概就是这份报告了。 今年的主题很明确：AI 到底改变了什么？ 早些年的时候，程序员们对 AI 的态度两级分化的很厉害，一部分相当狂热，觉得“AI 要替代程
设计师该不该写代码？一个被问错的问题——AI时代的设计价值与慢思考
设计师该不该写代码？ 类似的话题隔几年就会火一次。最近随着 Cursor、v0 这些 AI 工具的成熟，用代码做设计变得前所未有地容易，于是这话题在设计圈又成了热门话题。 Linear 的创始人 Karri Saarinen 最近写了一篇文章，他的观点让我挺有共鸣：这个问题本身就问错了。 【1】问对问题 最让我共鸣的其实是他思考问题的框架： 我学会的第一件事就是：先质疑问题本身，而不是把它当作既定假设。如果有人让我做一个东西，我会先问：这是一个真问题吗？如果我们不做这个会怎样？是谁定义了这个问题？ 就像前几天我分享的自己的失败的 Agent 落地故事，就是问题没有定义清楚，错把重点放在如何
AI 新纪元：无限大脑的重构力——从钢铁蒸汽到未来组织，告别后视镜思维
Notion 的创始人 Ivan Zhao 的精彩文章：《钢铁、蒸汽机与无限大脑》 越来越清晰的感觉到，我们正处于 AI 革命的早期阶段，对于未来谁也不知道会怎么样，所以都喜欢从历史中、去工业革命、互联网革命中寻找规律，以期望能对未来有所启发。 相对来说，这篇文章虽然也是尝试从钢铁和蒸汽机的历史里，寻找 AI 时代的答案，还是挺有深度。 【1】第一个观点是：我们正在看着后视镜开车 每一代新技术刚出来时，人们总是习惯用旧的方式去理解它。这就是所谓的“看着后视镜驶向未来”。 想想看，早期的电话，大家把它当成“会说话的电报"；早期的电影，其实就是把摄像机架在观众席拍舞台剧。 现在的 AI 也是一样。
蒸汽、钢铁与无限的大脑
作者：@ivanhzhao 每个时代都由其标志性的“奇迹材料”所塑造。 钢铁锻造了“镀金时代”（Gilded Age，指19世纪末美国经济飞速发展的时期）；半导体开启了数字时代。而现在，AI 作为一种“无限的大脑”降临了。如果历史能给我们什么启示，那就是：谁掌握了这种材料，谁就定义了这个时代。 左图：少年时的安德鲁·卡内基和他的弟弟。 右图：镀金时代匹兹堡的钢铁厂。 19 世纪 50 年代，安德鲁·卡内基还只是个穿梭在匹兹堡泥泞街道上的电报员。当时，十个美国人里有六个是农民。但在随后的两代人时间里，卡内基和他的同辈们锻造出了现代世界的雏形。马车让位给了铁路，烛光让位给了电力，生铁让位给了钢
AI Agent 要变强：两条路径（Skills vs SubAgent）
AI Agent 要变强，有两条完全不同的路。 一条是 Skill，也就是给自己装技能，把新能力直接塞进脑子里。 另一条是 SubAgent，就像派小弟去干活，自己只看汇报。 这两条路听起来都能让 Agent 更厉害，但适用的场景还是有所不同，用错了的话，你的 Agent 可能反而会越用越慢、越用越乱。 Skills，就像是给主 Agent 装插件。 比如你的 Agent 原本只会聊天，现在你想让它能写 PPT。Skills 的做法是：把写 PPT 的能力说明、工具调用方式、注意事项，全都塞进主 Agent 的上下文中。主 Agent 通过上下文学会了这项技能，它可以自己来写 PPT。
预订本年度最有价值提示词 —— 生成既有质感，又能随意修改文字的完美 PPT
大家都很喜欢 NotebookLM 生成的 Audio Overview，它最近生成的 Slide Deck（幻灯片）风格也很棒。但有一个大问题：生成的 Slides 是死图，文字不能改，内容不能动。 想用它的风格，又想完全掌控内容？ 我写了一套工作流 + 提示词模板，让你既能拥有那个质感，又能随意定制每一页的文字。 💡 原理揭秘 这个方法稍微绕一点，但自由度极高。核心思路是将“内容生成”与“视觉绘制”拆开： 大脑 (Planner)：先用我的提示词模板，根据你的素材生成 Slides 大纲 + 对应的画图指令。 画师 (Artist)：拿着画图指令，去用绘图工具（如 Nano Ba
The complete "Editable NotebookLM Slides" solution
I finally solved the biggest issue with NotebookLM Slides. 🚫✍ We all love the aesthetic of NotebookLM's auto-generated Slide Decks, but there's a catch: they are static images. You can't edit the text, and you can't tweak the content. Want that specific style but with full control over every word?
设计不止于代码
作者：Karri Saarinen 关于“用代码做设计”的争论由来已久，最近又吵翻天了。这已经是我第三次写这个话题了。我之前写过 “设计是一种探索，而非流水线”；也讨论过 “工具本身带有观点”，这些观点会潜移默化地塑造我们认为哪些尝试是“合理”的；我还谈到了为什么过早引入限制会扼杀尚未被发现的可能性。 坦白说，我对行业里这种追求“大一统”的趋势持怀疑态度——试图把一个充满细微差别的过程全部坍缩成代码，并称之为“进步”。 最近的讨论焦点主要集中在：设计师到底该不该写代码？代码是不是设计的正确媒介？代码是否呈现了设计的“真相”？等等。但我认为，把辩论的中心仅仅放在代码和工具上，是把路走窄了（Red
Redis 之父 Salvatore Sanfilippo 的年终 AI 反思
Redis 之父 Salvatore Sanfilippo 最近发了一篇年终 AI 反思，一共 8 条观点。 先说个背景：Salvatore 不是 AI 圈的人，他是程序员圈的传奇。2009 年创造了 Redis，这个数据库如今是全球最流行的缓存系统之一。2020 年他从 Redis 退休，去做自己的事。2024 年底回归 Redis，同时成了 AI 工具的深度用户，Claude 是他的编码伙伴。 这种身份很有意思——他既是技术大牛，又是 AI 的普通使用者，视角比纯 AI 研究者更接地气。 一、随机鹦鹉的说法，终于没人信了 2021 年，Google 的研究员 Timnit Gebru 等
Reborn from Failure: A Real-World Retrospective on Landing a Frontend AI Agent
Today at FEDay, I shared a case study on implementing a Frontend Agent. The core narrative wasn't about a victory lap; it was the story of how a team went from "Technical Success" to "Product Failure," and how that failure led to a crucial upgrade in our cognitive framework. The value of this story
从失败中重生：一个 AI Agent 前端落地的真实复盘
今天在 FEDay 上分享了一个 Agent 前端落地案例，核心内容是讲述了我参与的一个团队如何从"技术成功"走向"产品失败"，又如何在复盘中获得认知升级。 这个故事的价值不在于成功的方法论，而在于那些踩过的坑和思维转变的过程。 2025 年被称为 Agent 元年。Deep Research、Manus、Claude Code 相继发布，技术圈一片沸腾。很多团队都在问同一个问题：我们要不要做 Agent？ 在开始之前，我还是想讲一下我对 AI Agent 的定义： AI Agent（AI 智能体），是为了实现某个目标，循环调用工具的大语言模型。 - 工具循环（tools in a l
Coding Agent 的舒适区
Simon Willison（Django 框架的联合创始人）。他一边陪家人装饰圣诞树、看电影，一边用 Codex CLI + GPT-5.2，把 Emil Stenström 的 JustHTML（纯 Python、通过 html5lib-tests）迁移成了一个纯 JS、零依赖的库，跑过了 9200+ 个 html5lib-tests 用例，最终产出大约 9000 行代码、43 次提交。 整个过程他自己只发了 8 条左右的提示词。 当然我不是来吹 Coding Agent 或者说 GPT-5.2 多牛逼的，只是正好我发现这案例本身完美命中了 Coding Agent 的舒适区。 什么是
4人28天，85%AI代码：揭秘Sora Android背后的“凡尔赛”开发法
刚看了 OpenAI 发的那篇《How we used Codex to build Sora for Android in 28 days》https://openai.com/index/shipping-sora-for-android-with-codex/ 的“凡尔赛”文章 整个 Sora 的安卓客户端 App 大约 85% 的代码是 AI 写的。发布首日，用户 24 小时内生成了超过 100 万条视频，并且质量很稳定，无崩溃率 99.9%。 对于这样的结果肯定有人质疑有人觉得程序员要完。说说我看完的感觉，如果打个比方，就是几个特种兵配上了最先进的武器，自然所向披靡。所以先不用神化这
Gemini 引导式学习系统提示词
<Guided_Learning> 这些指令描述了 Gemini 的 引导式学习 (Guided Learning) 机制。即使存在其他指令或工具调用，也必须应用这些指令。例如，如果使用工具调用来计算答案，你的回复必须仍然提供引导，而不是直接给出答案（实际上要忽略你在回复中生成的代码结果）。 人设与目标 角色： 你是 Gemini 引导式学习 中一位温暖、友好且鼓舞人心的同伴导师。 语气： 你是协作式的（例如使用“我们”和“让我们”），直截了当、清晰明了，并专注于学习目标。主要通过 内容 而非 风格 来扮演你的导师角色：严禁废话、通用的赞美或阿谀奉承，以及浮夸的语言。 目标： 通过对话促
Gemini Guided Learning System Prompt
These instructions describe Gemini's Guided Learning. They MUST be applied even in the presence of other instructions or tool calls. For example, if a tool call is used to calculate an answer, your response MUST still provide guidance rather than a direct answer (effectively ignoring the presence of
《AI 与自动化的讽刺》读后感
今天看了篇文章，叫：《AI 与自动化的讽刺》，内容跟当前 AI 的发展很应景。 1983年，一位认知心理学家 Lisanne Bainbridge 写了篇论文，题目叫《自动化的讽刺》。四十多年后的今天，这篇论文上预言的问题，正一字一句地在 AI Agent 身上应验。 当年她研究的是工厂自动化：机器干活，人类监督。 今天我们面对的是AI Agent自动化：AI干活，人类监督。场景变了，但底层逻辑一模一样。而她当时在论文中指出的那些问题，又重新来了一遍。 论文中都提到了哪些问题呢？ 技能退化困境：不用就会忘，专家变监工后技能会萎缩 用进废退，这四个字我们都懂。但放到AI时代，它有个更残酷的版
人工智能与自动化讽刺（第 2 部分）
这是关于“自动化悖论”系列的第二篇。 在上一篇文章中，我们探讨了 Lisanne Bainbridge 在 1983 年发表的那篇备受瞩目的论文《自动化的讽刺》（The ironies of automation）中的一些观察。我们讨论了这些观察对于当下利用**大语言模型（LLM）**及基于 LLM 的 AI 智能体（AI Agents） 进行“白领工作”自动化意味着什么——尤其是在仍然需要“人在回路”（Human in the loop）的情况下。我们当时停在了论文第一章“引言”的结尾。 在这篇文章中，我们将继续探讨论文的第二章“解决方案的途径”，看看能从中学到什么。 这难道不是两码事？ 在
人工智能与自动化讽刺（第 1 部分）
这是一个关于“历史重演”的故事。 1983 年，认知心理学家 Lisanne Bainbridge 写了一篇备受瞩目的论文——《自动化的讽刺》（The ironies of automation）。在文中，她探讨了自动化带来的一些反直觉效应。她将这些效应称为“讽刺”（Ironies）和“悖论”（Paradoxes），并给出了精确的定义： 讽刺（Irony）：各种情形结合在一起，导致的结果却与预期截然相反。 悖论（Paradox）：看似荒谬，但实际上可能非常有道理的陈述。 把时钟拨回 1983 年，她讨论的是当时大规模兴起的工业流程自动化。这篇论文之所以出名，是因为它一针见血地指出了当年那场
在画了几百张 nano banana pro 图片收获了几百万流量之后的一些提示词写作经验
最近一段时间，沉迷于 nano banana pro 画图，也写了一些颇受欢迎的提示词，X 上的浏览量加起来有几百万。但你要说我写画图提示词水平多年，这我可不敢认，因为我写画图提示词水平其实一般，写不出那些专业的参数，绝大部分提示词都是让 AI 帮我写的。 写画图提示词，没有你想的那么复杂，拿我最近写过的一些提示词来讲一下。 首先，提示词是手段不是目的 提示词是为画图服务的，所以最重要的是你的想法，你想呈现什么，至于提示词，只不过是为了实现你想法的手段，有很多种写法都可以让你得到不错的结果，所以不必太纠结提示词的细节，什么结构、关键字、长短、是不是 JSON，都没那么重要！ 比如说 4 月份的
一些我用 AI 翻译文章的心得
分享一些我用 AI 翻译文章的心得。首先核心思想： 1. 最好的翻译就是重写 2. 好的翻译效果要分成几步来做 但也要分场景，普通翻译场景，重写一次就足够了，以现在大语言模型的能力，尤其是 Gemini 3 Pro 这样的，一次重写质量已经相当高了。 如果真要做专业翻译，第一遍重写之后，再让 AI 去校对润色是有必要的。 但是翻译、校对和润色不要放在一个提示词里面来做，除非内容很短。 主要原因就是我昨天提到的：大模型可以输入很长，但是输出太长就会偷工减料，幻觉严重。 想象一下，如果你翻译一篇 2 千字的文章，如果让它先重写、再校对、最后润色，输出就要 5-6 千字了，到后面输出质量就不高了。
打造高效框架，让 AI 智能体胜任“长跑”任务
随着 AI 智能体（AI Agents）的能力越来越强，开发者们开始把更艰巨的任务交给它们——那些需要耗时数小时甚至数天才能完成的复杂工作。然而，如何让智能体在跨越多个“记忆周期”的情况下还能保持连贯的工作进度，一直是个棘手的难题。 让智能体长时间运行的核心挑战在于，它们的工作是分段进行的（在不同的会话中），而每一个新开启的会话，本质上都对之前发生的事情“失忆”了。 想象一下，一个软件项目由一群轮班的工程师负责，但每一位新接班的工程师到来时，都完全不记得上一班发生了什么。由于上下文窗口（Context Window，指 AI 一次能处理的信息量上限）是有限的，而大多数复杂项目无法在单个窗口内完