AI

假设你现在真的有一个 agent，能把一件事从头做到尾——拉数据、写代码、跑测试、发 PR、改文档，一条龙。它不需要你在旁边一句一句喂提示词。你晚上把任务丢给它，去睡觉。 ...

最危险的简报，可能一条内容都没有 早上打开每日简报，页面上显示 0 条新内容。也许昨夜确实风平浪静；也可能是 RSS 路由坏了、API 开始返回空页，或者凭据在凌晨过期。从读者这一端看，这几种完全不同的状态只有同一个样子：安静。 ...

一个人究竟养得起多大的 Agent 舰队？ 这个问题听起来像是在数进程，其实是在找一个错误的单位。一个 Agent 可能只抽取一段文字，也可能搜索二十分钟，或者经过八十次工具调用才完成一次仓库重构。真正有意义的单位不是“Agent 个数”，而是一个被验收的任务，以及它背后的输入、输出、工具、重试和人工善后。 ...

一个反直觉的信号：它开始反过来提示你 假设有一天，你打开工作台，Agent 没有等你输入下一条命令，而是先说： 我注意到昨天那份方案的第三节还没有收尾。我按你上周的口径起了一个草稿，现在要看吗？ ...

如果你搭一个 AI，让它追某个领域的论文、发布、benchmark、观点和 changelog，它到底能替你走到哪一步？从 2026 年 1 月到 6 月，我持续试用了自己能接触到的一批资讯聚合、页面监控和自动简报工具。这个样本不覆盖市场上的全部产品，也不是严格的横向测评；它只是我在同一套技术资讯任务上的长期观察。结论是：AI 很擅长搬运和整理；但缺少用户目标、工作上下文与结果反馈时，它不能可靠替代最终判断。 ...

一年过去了，为什么大多数人的 AI 还停在原地 过去一年，写文案、翻译、总结和分析都用上了 AI。但诚实地问一句：它真的接管了业务环节，还是每次仍由你重新交代背景、判断输出、决定下一步？ 模型变聪明了，反复切换上下文和担责任的人往往没变。 ...

聊了很久，手里留下了什么 我也有过这样的晚上：本来只想把一个选题想清楚，结果和 AI 从标题聊到商业模式，又从商业模式聊到人生。对话很顺，窗口关掉之后，文章仍是一片空白。 这不说明对话无用。它只提醒我：探索和执行是两种不同的工作。 ...

一个让我后背发凉的信号 先分享一句话，它出自一个每天重度使用 AI 的人的复盘，读到时我后背有点发凉： 当我跟 AI 聊得很开心，说明这天我大概率是没有成长的。 他解释得很清楚：因为聊得开心，往往意味着没遇到摩擦。而真正的成长，一定伴随某种不舒服——把一个模糊的念头逼成一句清晰的话，把一个想不通的问题硬啃下来，被一个反对意见硌得重新思考。这些都不"爽"。他一直在用 AI 消除摩擦，越用越顺、越聊越开心，可停下来发现：摩擦恰恰是他最需要、却被自己亲手删掉的东西。 ...

「能跑」不等于「可靠」 大多数人搭个人 AI 系统时，第一条验收标准是：能不能跑？ 能写出一篇文章，能改完一段代码，能把十页资料压成一页，看起来就算完成了。但用久以后，真正折磨人的是无声的错误：结构工整，语气笃定，结论却悄悄偏离了事实。 ...

先别造宫殿，先跑通一条路 很多笔记系统的问题，不是功能太少，而是入口、目录、插件和自动化同时开工。最后系统很漂亮，自己却不敢改；AI 一旦批量重命名，更不知道哪里出了错。 ...

创作，是向外的那一半 我们走到了最后一层。信息被降噪，记录被沉淀，知识被结构化成能反复调用的能力——但到此为止，所有工序解决的都是你自己的问题。知识让你变强，却不会自动变成别人愿意看的东西。 ...

越堆越大，越来越没用 到第三层了。信息被采集降噪，记录被写下、精修成半成品——现在要回答的是：怎么把这些半成品，变成真正的知识？ 先说知识的定义。知识是和你相关的、结构化的、能反复调用的东西：某种思维模型、某几项技能、某套方法论，还有你的判断、定位、价值观。它的关键词是可复用，它解决的是你自己的问题。 ...

被塞进"知识"那一格的半成品 在大多数人的心智模型里，笔记只有三档：看到信息 → 变成知识 → 拿去创作。中间那个"记录"的动作，被默默塞进了"知识"这一格。 ...

信息的默认状态，是噪音 上一篇立了框架：信息、记录、知识、创作是四道工序。这一篇只谈第一道——信息。 关于信息，最重要的一个认知是：它的默认状态是噪音。 我们对信息有一种天然的贪婪。看到一篇好文章就想收藏，看到一个金句就想存下来，看到别人推荐的书单就想加进待读。每一次"存"都给我们一点"我在进步"的错觉。但存这个动作，本质上只是把信息从别人的仓库搬到了你的仓库，它没有经过你这台机器的任何加工。 ...

四个名字，代表四种不同的工作 我过去的笔记只朝一个方向生长：向内。链接进来，碎片堆积，目录反复改名，仓库越来越重。我把“拥有”错认成了“加工”。 AI 让这种错误变得更便宜。模型可以快速生成、摘要、分类和改写文字，但速度不会自动把来源变成证据，把观察变成知识，也不会把初稿变成我应当发布的东西。它完全可能把仓库撑得更大，而机器一点没变强。 ...

先给答案：信任是证据，不是平台技巧 一页内容可以技术健康、结构清楚、方便引用，却仍然没有被答案引擎展示为来源。这不证明背后有一道神秘“信任闸门”拒绝了它。页面可能根本没被选中，另一份来源可能更贴合问题，答案可能吸收了它的事实却没有给链接，也可能只是平台在这一次运行里表现不同。 ...

open-lovable 看起来像一句很短的产品承诺：给它一个网址，得到一个可继续修改的 React 应用。真正值得读的却不是生成结果，而是它怎样把抓取、模型输出和不可信代码执行接成一条可控链路。 ...

「Software is eating the world.」 —— Marc Andreessen, 2011 「Now, AI is eating software, and the question for the rest of us is: what’s left for one human, alone, in front of a screen?」 —— 我于 2026 年的某个凌晨，在台灯下问自己。 ...

架构图是一张承诺清单；源码审计要问的是，其中哪些箭头已经有了重量。 这篇文章的旧版把 Relay 写成一个公开的开源方案，还说它的 Agent 层尚未开工。到 2026 年 7 月 31 日，这两个判断都不再成立：旧文引用的公开 GitHub 地址返回 404，而我能够核对的是一份私有本地检出。 ...

上下文工程（Context Engineering）是在 LLM 每一次推理时，对进入上下文窗口的最优 token 集合——系统提示、检索文档、对话历史、工具定义与记忆——进行筛选、排序与淘汰的一整套工程策略。 它与提示词工程的区别一句话讲清：提示词工程优化「一句话的措辞」，上下文工程优化「整扇窗口的布线」。这个定义来自 Anthropic 的工程文章，Karpathy 也公开背书了这次改名。下文把这门正在成形的学科完整拆开。 ...

「Agent loop 是 10 行代码，Agent engineering 是 10 万行代码。」 这句话不是代码审计结论，更像一把拆系统的刀。它戳破了一个常见错觉：把 prompt 写好、把 LLM API 调通，只能证明 loop 能转；要让系统在无人值守时仍可恢复、可追踪、可约束，主要工作在 loop 外。 ...

关于 AI 智能体身份连续性的哲学边界与工程实践 引言：先把“身份”降到工程可讨论的尺度 Agent 失忆，最先伤害的不是拟人感，而是合作成本。 一次会话里表现出色，并不等于下次还能沿用同一套判断。用户要重新说明偏好，团队要重新交代约束，系统也很难解释某个决定从哪里来。长期合作所依赖的信任，恰好建立在这些看似琐碎的连续性上：它记得什么，忘掉什么，为什么改变，以及谁批准了改变。 ...

帕斯卡在 17 世纪写过一句话：「人类所有的不幸，都源于一件事：他们不能安静地待在一个房间里。」 三百多年后，我在拉萨的一个深夜想起这句话，补了一条：他们不确定，那个待在房间里的，究竟是谁。 ...

这篇笔记来自我对开源 AI 系统的长期拆解：先跑起来，再读迁移文档，最后记录抽象在哪些地方成立，又在哪些地方开始漏水。 问题从来不是“记得越多越好” 只要对话还装得进上下文窗口，LLM 就能维持短暂的连续感。但这不是长期记忆，更不是可靠的应用状态。会话结束之后，模型不会自然记住用户偏好简短回答、上个月换了工作，或者已经放弃某个计划。 ...

桌面智能体最容易给人留下印象的，是“它真的点了那个按钮”。但按钮被点中，只是演示成立；任务能否稳定结束，才是系统成立。 微软 UFO 项目几年的演进，恰好沿着这条分界线展开：2024 年的 UFO v1 证明视觉语言模型可以操作 Windows；2025 年的 UFO² 把操作提升为一个有状态、有工具、有应用边界的桌面运行时；同年末发布的 UFO³ Galaxy，则把单机能力接入跨设备编排。 ...

推荐系统最容易制造一种错觉：模型越新，系统就越先进。 真正做过推荐的人会知道，模型只是水面上的一小部分。水面之下还有曝光偏差、延迟预算、特征新鲜度、库存约束、探索风险和反事实评估。大语言模型（LLM）确实给推荐系统增加了新的语义入口，却没有替我们消除这些旧问题。它甚至会带来新的麻烦：成本更高、输出不稳定、解释可能看似合理却与排序依据无关。 ...

2026 年 7 月 16 日，Google 正式把 NotebookLM 更名为 Gemini Notebook。 名字变了，最值得保留的问题没有变： 我能不能沿着一段答案，走回一份自己愿意相信的证据？ 这才是 Gemini Notebook 与普通聊天工具真正不同的地方。普通对话从一个宽广模型出发，靠提示词收窄范围；Gemini Notebook 先让你圈定来源，再围绕这些来源提问、比较和生成结果。它最有价值的不是“更会写”，而是缩短了生成主张到检查原文之间的距离。 ...

当被测函数只是把两个数字相加时，测试驱动开发很好解释：先写一个失败测试，让它通过，再在行为不变的前提下改善实现。困难出现在函数开始调用大模型之后——同一个问题可能有五种都算正确的回答，今天通过的结果，明天也可能因为模型、检索索引或服务端推理环境变化而不同。 ...

文档转换器是一座桥，不是真相本身。真正重要的不是输出第一眼是否整洁，而是下一套系统需要的证据有没有过桥。 MarkItDown 的演示很简单：装一个包，传入文件，得到 Markdown。困难往往从下一分钟开始。一个 PDF 可能同时包含可选文字、扫描页、图表和复杂表格；一份演示文稿的关键数字可能藏在截图里；一个工作簿的含义可能依赖公式、合并单元格与空间关系。它们虽然都叫“文档”，却不该走同一条转换路径。 ...

这个项目是一场持续的开源学习：每天向前一点，用真实项目训练解决复杂问题的能力，也把判断变化的过程留下来。 项目学习清单 ...