Notes

你会进入一个良性循环：创作得越多，能做的事情就越多，灵感也会源源不断地涌现。反之，一旦远离创作，就很难重新投入。你会开始胃痛，情绪也会低落。这时你只能全身心投入其中，但这往往很难……

在大公司，个人对公司成长发挥的作用微乎其微，可以说基本为零。甚至个人对团队的贡献，有时候都是微不足道的。很多团队的存在意义，是维持这个系统的/正常运转，而不是创新。相反，如果你因为创新而引发了事故，那么你对团队的伤害往往远大于贡献。

在创业公司，每个人摊上的是大公司几个团队的活，如果不充分利用 AI 的 Coding 速度，根本不可能干完日常的工作。况且创业公司要么没赚钱要么赚的钱不多，而且创业公司的价值在于未来能赚多少钱而不是这个季度赚了多少钱，在这种情况下，走得快比走路姿势稳不稳重要的多……对于一份工作来说，我们当然要保证工作的完成质量，但因为大公司的代码量之大和审批流程之复杂，保证质量这件工作往往相当之无聊。如果环境允许你充分发挥自己的主观能动性，在质量与速度之间，发挥自己的审美和判断力来做取舍，这种工作的创造感其实远高于传统人工编码的时代，但也对实操人的素质提出了更高的要求。

决定 Agent token 效率的变量不只有模型和提示词，还包括Agent面对的操作界面(Interface/Surface)。

说「Agent 想要文件系统」，听上去像拟人化。更准确地说，是今天的大语言模型在训练数据、后训练任务和工具生态里，反复学到了一套非常稳定的工作模式：进入目录 → 列文件 → 搜关键词 → 打开局部内容 → 引用具体行号。

文件系统语义对 Agent 友好，主要不是因为「文件」这个存储介质，而是因为它提供了一种 progressive disclosure（渐进式披露）的交互方式：

• 先低成本发现：ls看有哪些东西，stat看对象卡片，catalog看可查询字段。
• 再按需读取：只有找到目标后，才用read打开内容。
• 搜索可以限定范围：全局grep用来发现线索，目录内grep用来提取证据。
• 路径是稳定句柄：/runs/abc/stdout.log 既是名字，也是后续继续操作的地址。

相比之下，SQL 更像是要求 Agent 先理解一张地图，然后一次性写出正确路线。对于清晰的结构化聚合，这很强；但对于「先找 cohort（样本组），再查日志，再引用证据」的复合探索任务，前置认知成本会变高。

Agent擅长搜索有名字、有层级、可局部打开的空间

很多人谈token成本时，只看输入prompt有多长、输出回答有多长。但对具备推理能力的模型来说，每个工具调用轮次里的一部分预算会花在「我现在看到了什么、下一步该查哪里、这些字段之间怎么关联、刚才的结果是否足够回答问题」上。换句话说Agent不只是在读取数据，它还在不断维护一张临时的任务地图。

如果接口迫使Agent先理解复杂schema、猜join路径、拼blob_ref、回忆哪些id对应哪些日志，那么模型的注意力就会被大量消耗在「拼上下文」和「找路」上。它虽然还在工作，但越来越像一个人一边翻十几张表、一边记临时编号、一边担心自己有没有漏掉关键字段。这种状态下，token不是被花在真正的判断上，而是被花在维持工作记忆上。

文件系统形态的接口会减轻这种负担。路径本身就是稳定句柄，目录天然表达范围，grep返回的是带位置的证据，find和aggregate可以把过滤、排序、limit和字段投影下推给系统Agent不需要在脑子里反复重建「数据在哪里」，而是可以顺着路径逐步缩小搜索空间

一般来讲，只要一个智能体系统高度依赖大量文件、日志、报告、模型、合同、图片、音视频、checkpoint 等外部产物，就会遇到类似问题。可以把这类系统称为 artifact-heavy（产物密集型）Agentic 系统

今天的训练、评测和推理系统会产生大量run、trace、日志、模型checkpoint、指标和配置。作为人的我们会问：「哪组配置最好？」「这批失败任务为什么取消？」「这个采样run到底加载了哪个模型？」这些问题往往不是一条SQL能解决的，而是要在结构化指标、非结构化日志和 artifact 元数据之间来回探索。

从 token efficiency 的角度看，这是一种很差的接口选择：Agent的预算被花在「我该去哪找这份文件、哪个版本才是当前版本、这个摘要对应哪段原文」上，而不是花在法律分析、实验判断或业务决策上。

这就是研究人员认为「文件系统语义」会重新变重要的原因–LLM 被训练得非常擅长在这种形态的空间里工作。

为什么有人能不断打破舒适区重塑自我，而多数人却困在原地？作者认为，区别在于是否把「体验」本身当作目标。

当不再用利弊清单或最终收益来衡量行动时，无论是像 Miles Davis 那样抛弃旧风格寻找新声音，还是允许自己在学习新技能时显得笨拙，你都能在过程中稳赚不赔。

这些技术真正强大的地方，不是自己拥有多少功能，而是它们提供了一层稳定基础，让更多人可以继续建设。

因为一个项目改变软件世界，通常不是因为它自己完成了一切，而是因为越来越多的人开始在它之上创造新的东西。

当一个技术成为别人建设的基础，它就不再只是一个项目。它开始变成基础设施。

当一次尝试变得便宜，尝试的数量就会增加。而大量尝试，才是生态形成的基础。

技术的发展，不只是不断提高能力上限，同样重要的是不断降低参与成本。 性能决定一个工具能做到什么，成本决定有多少人愿意尝试。当一项技术足够便宜、开放、容易实验时，它才有机会从少数人的能力，变成整个生态的能力。

很多改变世界的东西，并不是从一次完美的设计开始，而是从一次成本足够低的尝试开始。

从这个苦涩的教训中，我们应该明白通用方法的巨大力量，即那些随着计算能力的增长而持续扩展的方法。在这方面，似乎可以无限扩展的两种方法是搜索和学习。

苦涩教训中的另一个关键点是，人类心灵的实质内容极其复杂，不可能简化；我们应该放弃试图简单化地理解心灵内容，如空间、物体、多重代理或对称性等概念。这些都是外部世界中任意而复杂的部分，不应该成为我们构建的核心；相反，我们应该构建的是那些能够发现并捕捉这种任意复杂性的元方法。这些方法的核心在于它们能够找到良好的近似，但寻找这些近似的过程应该由我们的方法来完成，而不是我们亲自动手。我们希望 AI 代理能像我们一样具有发现能力，而不是仅仅包含我们已有的发现。将我们的发现直接构建进去，只会使我们更难看清如何实现发现的过程。

用 AI 操作 PowerPoint 去做 PPT 的思路本身不 AI Native，不是说不能操作 PowerPoint，而是做出来不好看，因为目前的 AI 没办法通过“操作”的方式去做出好看的 PPT，它擅长的还是生成。

像 Kimi 那样发明一种 YAML 的中间格式 PPTD (PPT-DSL)，可行，但还不够好。有两个问题：

1. 这种格式没有足够的训练，需要大量的额外说明，所以 Kimi 用了将近 2000 行文档来说明什么是 PPTD，另外这种 YAML 格式本身表达力有限，难以表达完整的格式
2. 不够美观，现在模型设计能力越来越好，但是对于非标准格式效果要大打折扣，模型做设计最熟悉的是 HTML 格式。

也有人说，用模板是不是就可以解决美观的问题。

用模板部分解决了美观问题，但问题是选择会很有限，反而是限制了模型的想象力。

不要忘记《苦涩的教训》：

长期来看，依靠大规模算力和通用学习方法的“笨办法”，终将战胜依赖人类专家知识的“聪明捷径”。

换句话说，与其内置一堆模板，不如让模型自己发挥。

目前 AI 做 PPT 的最佳实践应该是 Claude Design 采用的模式：

• 用 Design System 定义好设计风格
• 使用 HTML 生成网页 PPT
• 将 HTML 导出成可编辑的 PPTX（PPTX 是标准格式）

HTML 可以保证大模型生成 PPT 的美观，可以人工二次编辑，又可以几乎无损（不是绝对）转成 PPTX。

这也是我学到的两条经验：

1. 让 Agent 操作它最擅长的格式
2. 给 Agent 规范，而不是模板（不是说不能用模板，而是不能过于依赖模板）

这个时代由于编程的速度极大地提升，工作分配的颗粒度也大大加粗，上一个时代每个人分到的活可能只是写某个模块甚至是某个函数，你不需要关心最后大家工作内容合并做成的事情是什么。但是如今更多时候是要让你把某件事情做成。而做成一件事情可能分一百个子事情，AI 有能力做完每件子事情，但是 AI 没有能力决定要做哪一百件子事情，这个的上下文可能在老板与你的沟通中，也可能存在你历史积累的工作经验里，还可能是你生活的常识，甚至还可能要预测未来的发展。而 AI 完全没办法通过你聊天窗口那几句话知道这么多上下文信息。

我们和 AI 的区别在于，我们想把事情干成，AI 只想让这个对话完成。

• 编写原则，而非规则
• 提供规则背后的原理可以让智能体思考问题，而不是机械地遵循指令，从而提高泛化能力
• 使反馈足够简单，才能提升技能

可行性分析通常看两个层面：

产品角度：这个功能有没有价值？和 App 的定位是不是匹配？ 技术角度：技术上能不能做到？成本是不是可控？

瓶颈转移到了代码两侧：左边是设计和确认，右边是测试、验证和部署。 这些环节仍然在以人类速度运行，它们才是现在需要优化的地方。

通用 Agent 会吃掉垂直 Agent，Codex、Claude Cowork、WorkBuddy 这些通用型选手，配合 Skill 和 MCP，就能搞定大部分专业任务。很多 AI-native 应用创业，本身就是个伪命题。

不只是通用 Agent 会吃掉垂直 Agent，通用 Agent 这个赛道本身，也会是少数赢家通吃。

我们转向了通用 Agent，这条路如何能够不被大厂吃掉？

1. 即使 AI 大幅提升了写代码的速度，产品本身的技术架构、分层、同类抽象，什么东西放到什么地方能够让后续更好地扩展和解耦，还是需要工程师本身的判断，这一块可以在项目第一个版本跑起来之后，就和你最好的 AI 仔细讨论，设定好对应的架构，并通过可沉淀可修改的文档记录下来，持续跟随项目迭代
2. 我平时更关心测试有没有覆盖那些容易想当然的地方，比如扫描结束以后文件又变了、进程检查失败、命令返回成功但 App 根本没有更新、旧任务很晚才回来覆盖了新结果。正常情况一般不难写，麻烦的是那些看起来没问题、实际上已经错了的情况，怎么及时发现它们
3. 特别是修 Bug 的时候，我会多留一些东西下来，除了把问题修复，还会加一个让旧代码失败的回归测试，然后沿着同类路径去找有没有类似的问题，最后把当时为什么这么改写到规则里面去
4. 测试能记住输入和结果，但记不住当时为什么放弃一种做法，所以项目里还有一批 Rules，主要记录功能边界、历史原因和不能碰的地方。比如为什么某类文件宁可漏掉也不能自动删除，为什么有些看起来重复的组件不能随便合并，哪些系统数据不属于 Mole。Rules 一多又很费上下文，我就按模块把它们拆开，只在改到相关代码时加载，再把经常重复的检查做成 Skills。bugs 会从以前的修复里找同类问题，design-system-review 看界面有没有越写越乱，release 则负责检查签名、公证、远端文件和更新链路，这样不需要每次都从头跟 AI 解释一遍
5. 还有一个对我很有用的法子，就是少做一些没有实际用处的功能。现在 AI 加一个设置项、兼容分支或者后台监听太容易了，几分钟就能写出来，留下来的状态和维护成本反而是腐化最大的原因。比如 Mole 现在给新功能定了一些规则，尽量不增加常驻开销，不增加新的特权和系统权限，有合理默认值就不继续加设置项，更新和清理也不会因为发现一种新的可能性就一直扩范围，很多功能是开发者自以为重要，使用者却完全不在乎的，还是建议从用户中来，到用户中去，如无必要勿增实体
6. 上面这些，假如说有什么特别的地方，我能想到的就是执行流程完全没有我插手干扰，每一步都由 AI 自动执行和验证，出错了 AI 自动去解决，只不过会在不同的时候设置必要的流程卡点，让 AI 主动去验证，得到明确的结果才确定通过，并持续迭代规则，保持现有规则的新鲜度，及时移除旧的逻辑，让校验逻辑和业务代码同步升级。

或许这就是 AI 时代的工程师更需要培养的能力，如何让 AI 写的代码更好维护、更清晰、更好扩展，即使半年、一年、两年都不会腐化，而且会越来越听话，越来越符合开发者的心意，也给多 Agent 合作开发打下一个比较稳的根基。之前手写代码的乐趣已经没有了，好在这件事弥补了一些纯 AI Coding 过程的无聊，让工程师的专业度得以延续下去。

将你的经验、你学到的知识以及你目前认为真实的东西暂时放在一边，重新审视问题。

我仍然想利用这些经验。但很容易在没有真正理解面前的问题之前，就让过去的项目或熟悉的技术限制决定答案。

当我退一步，去问我们实际上在做什么、为什么这很重要、各个部分是如何连接的，我通常会找到比预期更多的前进方式。

一个 2C 软件应该是面向普通老百姓设计的而非精英。如果你和很多人接触过你就会发现，大部分人是没有主动提出问题的能力的，即便要提出，也没有掌握正确的提问方式。

现在的 Agent 希望自己的能力是泛化的，所以一切功能都来自于用户的自然语言输入，而一个人的真实世界行为其实主动发起聊天是极少的场景，大部分我们的数字生活都是被动的。被动被推荐新闻短视频，被动刷 Ins 流，被动决定晚饭吃什么，正是这些被动才使得我们的生活变得轻松，主动的人生是值得追求的但是非常累。

Agent 应该是一种技术实现方法，而不是软件交互方式。

Agent 的技术原理其实很简单，就是「用户输入」-「模型推理」-「工具调用」-「模型推理」- … -「输出结果」。技术上并没有限定输入输出必须是以聊天的方式进行的。

我认为的务实的交互方式是，利用现存软件已经积累的数据资产和 UI ，在背后让软件的实现方式变成 Agent 化。

我们学会理解别人，也从此只能隔着自己去看别人。我们有了语言和文明，也开始用标签替代一个活生生的人。

我们很难只享受其中的便利，却完全不受它的影响。

人类六亿年智能进化带来的五次突破，反而筑起认知牢笼：我们分别心贴标签、心智化以己度人、语言把人压成固化概念。

我们以为在看见别人，其实只是在确认脑中早已存在的意象。

记录，对我们来说意味着什么？

把大脑从那些琐碎的小事中解放出来，去处理更精密复杂的任务？帮助记忆有价值的信息，避免遗忘？又或者是显化内容过滤重组的过程，提升梳理思路的效率……

记录的意义因人而异，但所有的笔记，在记录时都隐藏着一个不被注意到的重要前提，那就是希望知识能被再利用。

潜意识里，我们会觉得记录的创意灵感、知识碎片迟早有一天会派上用场，所以精心地管理个人知识库。但是，你曾记录的笔记被二次查看的频率有多高？你有没有翻阅过去的笔记却惊讶地发现完全不记得曾记录下这件事，收藏了这个知识点？你有没有发现自己难以用上之前记录的知识点？

当一篇笔记完全被遗忘在记忆角落时，它对你的“价值输出”就此停止。

为了用户增长，大部分产品会通过一些手段提供免费额度（比如邀请、试用），黑产由此入手，不止算力可以被这样攻击

目前黑产榨取算力资源主要集中在四条核心路径：

1. 免费额度套利：通过自动化工具批量注册新账号，反复薅取平台的免费试用额度
2. 邀请积分套利：利用邀请奖励机制，循环注册、绑定邀请码、刷取积分
3. 高阶权益拆分超售：通过高阶账号拼车以及团队账户席位超售拆分权益，实现低价算力转售，造成平台资源被过度占用
4. API 逆向寄生套利：逆向 Web/API 接口，将网页端交互封装成廉价 API 对外出售

搜索并不是一种平衡的社交产品形态。它天然站在发起者的角度解决“我想找谁”，却没有解决更重要的问题：“对方为什么要选择我？”

AI 降低了验证成本，但没有降低商业难度。

有人使用、有人留存、有人付费，并不等于一个产品可以持续经营。生产层面的成功，也不会自动转化为商业上的成功。

在一个固定的校园流量池里，第一轮曝光就已经把大部分潜在用户找出来了。那些本来就喜欢认识新朋友、正在找对象、愿意上传照片，也没有太强社交羞耻的人，第一次看到产品时就会注册。他们不会等到第五次宣传，或者换了一套活动文案后才突然产生需求。第一两轮推广往往是效果最好的时候。它不是增长飞轮开始启动，而是高意向人群被一次性转化了。

我们并不是因为产品没人用而停止，也不是因为某次推广效果不好而放弃。恰恰是在留存、付费和短期增长都曾经给出正向反馈之后，我们才逐渐看清：这些数据证明了产品可以被使用，却没有证明它能够成为一门值得持续投入的生意。

能够用相对可控的成本换来这些认知，本身就是AI时代给创业者带来的巨大机会。

对于那些有好奇心、有想法，也愿意执行的人来说，这可能是一个前所未有的时代。创业的资金和技术门槛正在下降，个人能够做的事情越来越多，竞争也会逐渐从“谁能组建更大的开发团队”，转向“谁对问题理解得更深，验证得更快”。

过去，创业者往往需要先凑齐一支团队，才能开始验证想法。现在更合理的顺序可能是：先由一个能力相对全面的人把业务跑起来，确认方向成立之后，再组建真正需要的团队。

我从事产品开发已有10年，开发过一些失败的产品，它们要么过于复杂，要么缺乏鲜明的特色。我在犯过这些错误后，总结出三个限制条件。

1. 能不能把产品介绍写成一页纸的概要？

可以降低复杂性和歧义性

如果一个项目的介绍需要超过一页纸才能写完，那就说明它太复杂了。

2. 核心技术能不能与产品分离？

可以让你聚焦在真正具有影响力和原创性的想法上

开发一项支撑产品而非产品本身的核心技术。核心技术可以是方法、技能、工具，甚至是产品本身，它支持你当前的工作，但即使没有产品本身也能继续运行。它是一种可重用的知识产权，是你长期的投入，它独立于产品的方向。

产品会不断调整方向，而核心技术则始终如一，并持续发展。

将核心技术与产品分离，能迫使你跳出产品本身的局限去思考。

3. 产品有没有一个核心特色？

限制功能随意扩展，并强制保持产品功能的一致性

这意味着用户会时刻看到它并与之互动。这个特色清晰明了，赋予你的产品独特的个性。

你选择的这个特色可以让你缩小决策空间，专注于真正重要的问题。如果你的产品没有特色，或者选择了错误的特色，你就会打造出一个臃肿的产品，试图面面俱到。

建立反馈循环：定义想做的事，AI 帮你做成，你验收；分享出去收反馈；把经验写出来，AI 帮你整素材，输出又倒逼你系统思考。小循环做项目，大循环做分享。循环建起来、越转越快，成长就越来越快。

很多所谓 AI 信息系统，并没有解决信息筛选问题。它们只是把人工阅读的成本，改写成了模型调用的成本。

但我想到一个问题：今日头条早在 2012 年 8 月就上线了。此后十几年，我们又在支付宝、滴滴、浏览器和无数与资讯八竿子打不着的 App 里刷到了个性化信息流。

那个没有 LLM 的时代，到底是怎么做推荐的？

每天从 500 篇 RSS 文章里，捞出和几个固定主题相关的内容。

LLM 会把它理解成一个阅读理解题：读文章、读规则、推理、输出结论。

但它其实也可以被改写成一道几何题：这篇文章，离「科技向善」这个主题有多近？

Embedding 模型会把一段文本转换成一串固定长度的数字，也就是一个向量。你可以把它想象成一台「语义坐标转换器」：文章进去，出来的是它在语义空间中的坐标。

很多人第一次认识 Embedding，是在 RAG 里看它负责召回。这一代应用开发者大多从 LLM 时代进入 AI，起点又在应用层，很容易把 Embedding 当成 RAG 的固定配件：离开知识库问答，就想不起它还能干什么。

其实只要一个任务可以改写成「比较两段东西有多像」，Embedding 就能在许多场景单独派上用场。

Embedding 本身不是分类器。真正的分类器，是「Embedding + 主题锚点（范文） + 相似度 + 阈值」这四样东西拼起来的结果。

但只判断「像不像」时，没必要调用一个会推理、会写作、会解释的大语言模型。

本文讲的内容匹配、向量相似度、关键词检索、聚类、去重和多样性重排，更像上一代推荐系统里的边角技术：它们用于冷启动、内容召回、特征补足、重复控制和排序校正，而不是单独扛起一个今日头条。

可个人日报恰好没有平台的条件。

你没有数亿用户，没有足够密集的 用户—文章行为 矩阵，也不需要预测陌生人下一秒会不会继续滑动。你只有一个人或一小群人的订阅源、几百篇文章，以及一个更朴素的目标：把真正值得看的东西先捞出来。

在这个尺度上，推荐系统的「边角技术」已经够用了。

对从 LLM 时代才进入算法与工程世界的 Vibe Coding 一代来说，这些旧技术值得补课。Embedding、余弦相似度、BM25、n-gram、SimHash、兴趣簇、MMR、FTRL，不如大模型性感，但便宜、稳定，出了问题也知道该从哪里查。

做 Harness 时，我现在会先问一句：这一步的“智能”真的需要 AI 吗？毕竟“智能”这个词早在这一轮 LLM 爆发之前，就已经出现在几乎各类软件和家用电器里了，也许我所需要的根本不是一个 AI 级别的智能。

感觉应该拿豆包办公和 workbuddy 比较，而不是飞书，不过最主要的想说的是产品在生态上受到的约束，IM 作为 Agent 入口只是临时的，这会受到很大限制

Agent 必须大于办公套件，而不是小于办公套件

飞书的问题，是套件太成功了。它希望用户直接说出真正的目标，剩下的工具由它决定——必要时用飞书，必要时用 Office，必要时打开网页，必要时进入企业自建系统。飞书的完整开始变成一层约束。

入口上，Agent 越能独立完成任务，用户越不需要逐个打开飞书里的文档、会议和工作台。指标上，用户少点了十次页面，却更快完成工作，这究竟算飞书活跃下降，还是 AI 效率提高？商业模式上，企业将来买的是飞书席位，还是 Agent 的任务额度、Token 和数字员工？生态上，一个通用 Agent 理应平等连接钉钉、企业微信、Office 和 WPS，飞书却没有理由花大力气培养一个帮助用户离开飞书的入口。

既要形成套件化（自己的多个产品间的连接，不能过于独立），也要有对外（内）可连接的方式，成为别人的基础设置

WorkBuddy 这类产品有一个很准确的定义：它帮助 C 端用户完成 B 端工作。

从简单开始

一个有效的系统总是由一个较小的、有效的系统构建而成

理解是关键

完美是不可能实现的

我们都曾被要求做一些看似简单的改动，但当我们说这需要几周时间而不是别人预期的几个小时时，却不得不承受各种反应。大多数情况下，这是因为代码里藏着一些我们无法理解的复杂陷阱，而我们又害怕去修改。唯一的选择要么是完整的重构，要么是把他当做黑盒绕过他。

Coding Agent 很容易让我们一开始就无法理解整个代码库

如果你连一个想法是否可行都不知道，就去构建一个十年愿景，这是不合理的。你必须清楚自己正在做出哪些权衡。

做一些新的事情

先前的经验实际上会限制认知，导致专家即使知道某些模式并非最优，也会默认使用熟悉的模式。

先攻克难关

开发新产品时，你根本无法预知它需要多长时间才能完成，也无法预知它的效果如何。

无论是在工程层面，还是在产品和业务层面，都秉持着“先做概念验证（POC）再做最小可行产品（MVP）”的理念。

如果我们决定采用某种方法，就必须确保它行之有效。这并非意味着它一定是最佳方案，但至少我们知道它有效。

能排除掉的不可预测因素越多，剩下的事情就越可预测

关注影响力

人们需要更加以客户为中心。优秀的创业软件工程师不会把自己的工作仅仅局限于编写代码。他们不只是解决软件问题，而是深入挖掘，理解客户和业务的痛点。他们运用对软件和技术的理解，找到其他人想不到的解决方案。作为软件工程师，我们通常是团队中最强的系统思考者和批判性思考者，也是最了解技术功能的人。优秀的人懂得如何将这些技能成功运用到编码之外的领域，这在创业公司中至关重要。因为在创业公司里，仅仅解决遇到的第一个问题是远远不够的。解决表面问题不足以克服所有阻碍变革的障碍。要想取得突破，你必须不断挖掘人们的痛点、目标、希望和梦想。

做过某件事，不等于就拥有了对应的经验。真正的经验，是做完这件事之后，能够形成系统性、多维度的思考。

只看过、没亲手做过会形成间接经验，更多停留在理论层面。而实战打磨出来的认知远比理论更深刻。

原型、Demo 可以创造演练的机会。

亲身踩过坑、完整经历过整件事，也依旧不等于拥有经验，只算是拥有经历。

经历沉淀下来，能够梳理、能够表达，心里装得下全盘的考量。再碰到同类任务的时候，清楚当下该怎么设计，明白为什么要这么取舍，知道后续该如何演进，心里有完整的预案，这才是经验。

有了经历之后，一定要多复盘多思考。人的记忆是会消退的，如果不及时总结沉淀，过往的经历慢慢就模糊消散，本该提炼出来的经验就此流失，对自己来说是很大的损失。

这篇文章 读起来很难，很长但感觉信息密度很少，通过 AI 学习如何避免这类表达

• 围绕KV缓存进行设计
  • 保持你的提示前缀稳定
  • 使你的上下文只追加
  • 在需要时明确标记缓存断点
• 遮蔽，而非移除工具
  • 随着代理能力的增强，其行动空间自然变得更加复杂——简单来说，工具数量爆炸式增长。最近流行的MCP只会火上浇油。如果你允许用户自定义工具，相信我：总会有人将数百个神秘工具插入到你精心策划的行动空间中。结果，模型更可能选择错误的行动 或采取低效的路径。简而言之，你武装过度的代理变得更加愚蠢。
  • 一个自然的反应是设计一个动态行动空间——可能是使用类似于RAG的方法按需加载工具。但我们的实验表明了一个明确的规则：除非绝对必要，避免在迭代过程中动态添加或移除工具
    • 在大多数LLM中，工具定义在序列化后位于上下文的前部，通常在系统提示之前或之后。因此任何更改都会使后续所有动作和观察的KV缓存失效。
    • 当先前的动作和观察仍然引用当前上下文中不再定义的工具时，模型会感到困惑。如果没有约束解码，这通常会导致模式违规或幻觉动作。
  • 大多数模型提供商和推理框架支持某种形式的响应预填充，这允许你在不修改工具定义的情况下约束动作空间
• 使用文件系统作为上下文
  • 压缩策略始终设计为可恢复的
• 通过复述操控注意力
  • 通过不断重写待办事项列表，Manus将其目标复述到上下文的末尾。这将全局计划推入模型的近期注意力范围内，避免了"丢失在中间"的问题，并减少了目标不一致。实际上，它使用自然语言来使自己的注意力偏向任务目标——而不需要特殊的架构变更。
• 保留错误的内容
  • 代理会犯错。这不是bug——这是现实。语言模型会产生幻觉，环境会返回错误，外部工具会出现异常行为，意外的边缘情况随时都会出现。在多步骤任务中，失败不是例外；它是循环的一部分。
  • 根据我们的经验，改善代理行为最有效的方法之一出奇地简单：将错误的尝试保留在上下文中。当模型看到一个失败的行动——以及由此产生的观察结果或堆栈跟踪——它会隐式地更新其内部信念。这会改变其先验，降低重复相同错误的可能性。 事实上，我们认为错误恢复是真正代理行为的最明显指标之一。然而，在大多数学术工作和公共基准测试中，这一点仍然代表性不足，它们通常关注理想条件下的任务成功。
• 不要被少样本示例所困
  • 少样本提示是提高LLM输出的常用技术。但在代理系统中，它可能会以微妙的方式适得其反。语言模型是优秀的模仿者；它们模仿上下文中的行为模式。如果你的上下文充满了类似的过去行动-观察对，模型将倾向于遵循该模式，即使这不再是最优的。
  • 解决方法是增加多样性。Manus在行动和观察中引入少量的结构化变化——不同的序列化模板、替代性措辞、顺序或格式上的微小噪音。这种受控的随机性有助于打破模式并调整模型的注意力。
  • 不要让自己陷入少样本学习的窠臼。你的上下文越单一，你的智能体就变得越脆弱。

这是一篇以 AI 就业影响为主题的评论性随笔，使用了大量宏大叙事、抽象名词和连续隐喻，但概念边界不清，事实、推测与价值判断混杂，章节之间存在论证跳跃，因此造成了较强的“深刻感”和较低的信息清晰度。

「忙」变成勋章，「闲」变成耻辱，这套价值观统治了整整两百年。它塑造的不只是工作，是人的自我评价系统：闲下来的时候，很多人会恐慌，觉得自己正在贬值。

从“寻找一个职位”转向“建立自己能独立定价的能力和位置”，除了依赖公司分配职位，也要逐步拥有自己创造机会、获得收入的能力。

不可复制的东西：判断、经历、经验、关系

客户没有因此尊重他，反而看出了他的不悦。会面没有产生任何结果。他牺牲了最重要的东西，只为不得罪人。

第一阶段：你有清晰目标，于是取得成功。 第二阶段：成功让你成为「老好人」，所有人有事都找你。 第三阶段：选项和机会暴增，你的精力被撕成碎片。 第四阶段：你忙得不可开交，却离最初的成功越来越远。

成功，成了失败的催化剂。

这就是「成功的悖论」。对成功的追求，反而瓦解了最初让你成功的那件事。

问题不在于懒惰，而在于一种幻觉：我们可以拥有一切，做好一切。

精要主义不是时间管理。

非精要主义的支柱：

1. 选择泛滥：同时拥有很多个“第一”。
2. 社会压力：技术消灭了沟通的障碍，却放大了别人的期待。智能手机（即时通讯）让「随时在线」变成默认设置。
3. 忙碌崇拜：对于“上两周我每晚只睡 4 小时”不仅不抱怨，还引以为豪

泡沫的本质，是某种资产的价值被荒谬地高估。这次被高估的，是「什么都要做、什么都要有」的妄想。

时间管理教你如何在 24 小时内塞进更多任务。精要主义问的是：这 24 小时里，大部分任务是否根本不该存在？

精要主义不是如何完成更多的事，而是如何做好对的事。它也不是为了少做而少做，而是主张只做必做之事，把时间和精力投资在回报最高的地方。

精要主义不是技巧，而是对「一切重要」这个假设的否定

90%法则

TED 演讲者德雷克·西弗斯有个判断标准：如果不是一个确定的「Yes」，就是一个肯定的「No」。

麦吉沃恩把它升级为 90% 法则。面对任何机会，用一个最重要的标准打分，0 到 100 分。如果低于 90 分，自动降为 0 分，淘汰。

这个法则的残酷之处在于，它逼你承认：70 分和 80 分的机会，和 0 分没有区别。

建立常规，让正确的事自动发生

意志力是稀缺资源，越用越少。真正的高手不靠意志力，靠常规（routine）。

常规的意义在于：把决策成本降到零。

大脑会把重复的行为转交给基底神经节，变成自动行为。省下来的脑力，才能用在真正需要创造力的地方。

常规不是束缚，而是让重要之事变得毫不费力的基础设施。

1. 给所有任务增加缓冲时间
2. 每天问自己一次：「如果一生只能做一件事，我会做什么？」在无限选项中，找到那个真正重要的少数。
3. 练习说「不」：不是粗鲁地拒绝，而是清醒地拒绝。一个模糊的「Yes」比一个明确的「No」更伤人。对你自己，也对别人。