Next Token｜词元之外 · 博客

当 AI 普遍做到六十分，内容还凭什么被选择

Sun, 18 Oct 2026 16:00:00 GMT

一篇文章通顺，一张封面整齐，一段视频没有明显错误。过去，这些成果可能需要不少制作时间；当生成工具让它们更容易获得，完成制作本身就不再足以解释：读者为什么要选这一份？

第 006 期提到一个尖锐的判断：只要 AI 把一个东西拉到六十分，那六十分就是零分。把它当成分数结论显然不准确。六十分的结果仍可能帮助一个人解决问题；值得讨论的，是当合格作品变多之后，基础制作质量还能带来多少选择优势。

可用价值与选择优势不同

一份只供自己看的整理笔记，结构清楚、信息够用，可能已经完成任务。它不需要比别人的笔记更独特，也不需要吸引陌生人停留。若生成工具降低了整理成本，这份结果的价值并不会因为别人也能做到而消失。

公开发布的内容面对另一种约束。读者可以跳过，可以选择相近主题的其他文章，也可以直接向模型提问。一份作品达到可读标准之后，还需要给读者一个选择它的理由。

因此，六十分变零分更适合被理解为竞争位置的变化，而非使用价值归零。把两者混在一起，会误伤许多有用的日常自动化，也会让公开创作把精力耗在无止境的装饰上。

质量提高，作品仍可能更相像

Anil R. Doshi 与 Oliver P. Hauser 的一项在线故事写作实验，观察了使用生成式 AI 提供故事点子的影响。研究发现，获得 AI 点子的作品在写作与阅读体验评价上有所提升，但这些作品彼此之间也更相似。研究对象是特定的故事创作任务，不能直接据此推断所有文章、图片或视频都会趋同。

它提供的启发是，单篇质量与一批作品的差异程度可以同时朝不同方向变化。每个人都获得了更容易使用的起点，并不保证最终集合里的选择更丰富。论文原文支持这一实验范围内的判断，并没有给出一个适用于所有内容的六十分阈值。

放到编辑工作中，一个值得检查的现象是：几篇稿件分别读都完整，放在同一个列表里，却在解释同一种泛泛的问题，使用相近的结构，得出几乎相同的建议。逐篇润色可以改善句子，未必能解决选题之间缺少差异的问题。

差异可以来自更具体的材料

假设两篇文章都在讨论 Agent 能否提高效率。一篇列出常见好处，另一篇记录某个剪辑任务实际交付了什么、遗漏了什么，以及发现遗漏的方法。后者不必使用更夸张的标题，就已经提供了不同的信息。

差异来自问题和材料的选择。一个清楚的失败案例、一组可复查的条件、对适用边界的解释，都可以让读者知道哪些判断与自己有关。它们不能靠更换形容词补出来，也不一定需要更长的文章。

这种材料可以由人搜集，也可以由 Agent 帮助检索、整理和核对。重要的是它是否真实存在，来源能否支撑相应说法。仅仅把通用内容改写得更像个人口吻，并不会自动获得这些信息。

包装服务于读者要完成的事

提高制作质量仍然有价值。字幕清楚可以降低理解成本，图表可以展示文字不容易比较的差别，结构合理可以帮助读者找到所需信息。它们的价值来自具体用途，而非单纯比上一版更复杂。

同样，增加一段配音、一组转场或一个视频版本，也应回答它帮助谁解决了什么问题。对需要快速查找信息的人，更多播放时长可能增加负担；对需要观察操作过程的人，视频又可能比文字更合适。

这给创作留下一个比追逐固定分数更稳定的判断方式：保留基础质量，再检查作品是否带来了足够具体的信息，是否让目标读者更容易理解或行动。工具越容易做出合格的外观，选择问题、寻找材料与判断用途的工作就越需要认真完成。

中国的个人 Agent，为什么聊着聊着就去服务商家了？

Sun, 18 Oct 2026 16:00:00 GMT

帮一个人安排生活，听起来是 Agent 很自然的用途。可当任务涉及购买、预约、账户和售后时，一句自然语言背后很快就连着多个系统。模型知道应该做什么，只是开始；它还需要能够读取信息、发起操作，并确认结果。

门店经营则提供了另一种起点。订单、评价、营销活动这些事情每天发生，经营者知道哪里费时间，也更容易指出一份报告是否漏掉了问题。第 006 期对个人助理的讨论，最终转向了美团等平台的商家工具。这个转向值得解释，但不能直接推出国内只有商家 Agent 能成立。

商家任务自带一部分上下文

一个陌生的个人用户说帮我安排明天，系统可能还不知道他的工作时间、家庭分工、预算与偏好。相比之下，门店经营任务可以从较窄的问题开始：汇总昨日评价，找出重复出现的投诉，列出需要店长查看的订单异常。

范围较窄并不意味着技术上一定简单，而是业务对象更容易指认。哪家店、哪段时间、哪一组数据、交给谁看，往往可以在现有工作流程中找到答案。用户也能用已有经验判断结果是否相关。

美团官网刊载的 CatPaw 介绍，把数据汇总、异常识别和经营建议列为商家场景，并强调价格等关键决定仍由经营者作出。这是平台对产品用途的说明，不是独立测得的收益数据。它展示了一种务实的边界：先把分散信息整理到经营者可以判断的程度。

接近业务，不等于自动拥有权限

平台服务过大量商家，可以积累对业务流程的理解；某个 Agent 能否使用某家店的数据，仍取决于实际授权和接入。不能因为属于同一个生态，就假设所有账户、订单与操作都能随意调用。

可以用三个问题检查一个落地方案。它能看到完成任务所需的数据吗？它有执行相应操作的入口吗？操作后能否查到结果？这三个问题分别对应信息、动作和反馈，缺少任何一项，都可能停留在给建议的层面。

假设系统能分析差评，却不能修改商品说明，它仍可作为经营助手发挥作用，只是交付物应当是待处理事项，而不能宣称已经改善了商品页面。能力范围说得准确，才便于人接手剩余工作。

这个判断也适用于个人助理。获取旅行建议与完成一笔可查询的预订，是不同的服务深度。模型能力相近的两个产品，可能因为可用接口不同，表现出完全不同的实际用途。

消费者服务提供了反例

阿里巴巴对千问 App 的官方介绍，明确列出了通过淘宝即时零售下单，并在对话中完成支付的消费者场景。无论具体体验是否稳定，这至少说明个人消费任务也在产品的落地范围内，不能把它们概括为没有用武之地。

值得注意的是这些能力接入了已有的商品、交易与支付系统。它们与商家工具共享的条件，是能把意图交给实际业务处理。用户身份一端是消费者，另一端是经营者，并不改变这个基本要求。

因此，比国内外或个人与商家的简单二分更值得研究的，是服务可以深入到哪里。一个平台可以先覆盖自身能提供完整操作路径的任务，独立助理则需要通过授权接口、合作或界面操作接入更多服务。各条路径的成本与可靠性，需要放到具体任务里比较。

商业价值更清楚，也更容易被追问

商家场景的吸引力还在于，使用者通常能说出问题造成的损失：重复整理花了多少时间，哪些异常经常漏看，报告出来后谁来处理。这给产品提供了较明确的评估方向。

不过，报告更快并不自动等于经营更好。减少整理时间、改善决策、增加收入是不同层次的结果。若缺少后续记录，最多只能确认前一层，不能把收入变化都归因于 Agent。

个人助理也有类似问题，只是价值未必都以收入衡量。方便、安心或完成原本搁置的事务，都可能成立。商家任务的优势在于边界和反馈往往更明确，并非个人生活不值得服务。

当 Agent 先进入门店或电商后台，可以把它理解为对现有业务条件的利用。真正决定它能走多远的，仍是可获得的信息、可执行的动作，以及结果能否回到使用者手中。

人类在精简团队，Agent 却开始开会了

Sun, 18 Oct 2026 16:00:00 GMT

一个任务看起来很适合交给 AI 团队：抓取 GitHub Trending 和 Product Hunt 的热榜，整理成内容，再接上语音合成，做成持续播放的播客。

几个 Bot 很快商量出方案。分工明确，彼此通知修改，版本不断增加。旁观这场讨论，会觉得工作已经有条不紊地推进；真正等到执行，却发现耗时很长，Token 也消耗得很快。这是一次使用中的观察，材料没有给出完整耗时和账单，但它足以提出一个问题：群里越来越热闹时，离成品究竟更近了多少？

给角色起名字，比划清任务容易

把技术、产品、营销角色拉进同一个群，很容易获得组织起来的感觉。每个角色都有立场，能够补充意见，也能对其他人的方案提出异议。在产品脑暴里，这种互动确实可能帮助使用者发现自己没有想到的角度。

不过，角色的差异不自动变成执行上的独立性。一个营销 Bot 可以评价标题，一个产品 Bot 也可以评价标题，第三个 Bot 再总结双方意见。如果没有人拥有定稿权，意见越多，标题越难结束。

热榜播客的工作可以按对象拆分：两路信息分别采集，编辑负责选题和脚本，语音环节接收定稿。这样的划分提供了输入和输出的边界。按照职位搭一套组织，则可能让每个角色都参与每个环节，工作从制作内容变成持续讨论如何制作内容。

判断分工是否有效，可以先问一个具体问题：某个 Bot 交回什么东西之后，这一步就算结束？如果答案仍是参与讨论，任务就没有真正被分出去。

并行收益取决于任务之间要等多少次

两路热榜采集可以同时开始；配音需要等待脚本，最终混音又要等待音频。增加执行者，能够缩短独立工作的等待，却无法消除本来就存在的前后依赖。

更麻烦的是人为增加的依赖。假设脚本写完后，五个角色必须逐一同意才能进入配音，那么系统就多出五次沟通机会。任何一次提出新要求，都可能把前面的工作重新打开。这里描述的是一种可能的设计，并不是对那次试验内部实现的断言。

Anthropic 在 2025 年公布的多 Agent 研究系统经验里，也把可并行性作为重要条件：独立方向的广泛检索适合分给子 Agent；大量共享上下文、相互依赖的任务则更难受益。该团队报告，多 Agent 系统在其数据中约消耗普通聊天十五倍的 Token。比较基准是聊天，并非所有单 Agent 工作流；这个数字不能直接套到任何产品账单上。

这份经验支持的判断很有限，也很实用：多 Agent 能购买更多探索容量，但需要足够有价值、可以独立展开的工作来消化它。

脑暴和交付可以采用不同的组织方式

脑暴阶段不必急着消灭所有重复。让几个角色分别挑毛病，有时就是为了延迟收敛，找出被忽略的可能性。使用者从不同视角里获得灵感，也是这一阶段可以接受的结果。

进入交付阶段后，目标变了。谁决定采用哪版方案，谁可以修改已确认的要求，哪些问题需要退回用户，都应该收紧。继续保留一个人人都能随时改方向的群聊，会把探索阶段的开放性带进本应执行的阶段。

一个可尝试的安排是让讨论有终点：先收集若干不同方案，再由明确的负责人定稿；后续执行者可以报告阻碍，但不因个人偏好重开全部讨论。这样的安排仍然允许分工，只是让分工围绕产物推进。

管理一支 AI 团队的快乐，也可以单独成立

角色扮演的乐趣无需伪装成生产力。看不同性格的 Bot 讨论产品、接住一个突然冒出的点子，本身可以是一种娱乐和创作体验。只要使用者愿意为此付出时间与费用，它就有自己的价值。

容易混淆的地方，是把团队的存在感当成交付能力。头像多、发言密、方案整齐，都不足以说明任务完成得更好。若目标是做出一档播客，值得比较的是相同要求下，成品质量、等待时间、费用和人工介入次数如何变化。

组织结构可以很轻。只有在某一块工作值得独立展开、结果可以清楚交接时，再增加一个执行者。让一个 Bot 留在前台回应用户、另一个在后台处理长任务，也是一种明确的分工；它的价值不需要靠一场全员会议证明。

作品开源以后，作者靠什么留下来？

Sun, 18 Oct 2026 16:00:00 GMT

一个 Skill 的名字带着作者前缀，使用者便能直接让 Agent 去仓库安装这一组工具。这个名字先承担检索和调用的功能，也顺带把作者带进了每一次使用。

相比一条很快滑走的动态，这种接触有可能反复发生。但名字出现得多，并不保证作者得到信任；作品被大量转发，也不保证有人愿意长期使用。免费开放作品之后，留下什么，比发布当天有多热闹更值得追踪。

名字让人找得到，作品让人有理由回来

统一前缀有一个直接好处：当多个 Skill 都叫写作、摘要或剪辑时，作者名可以帮助区分来源。它既方便人记忆，也方便在对话里描述要调用哪一套能力。

这样的辨识度仍需要实际体验支撑。第一次安装可能来自一段演示，第二次调用通常需要作品确实解决过问题。如果结果稳定、文档清楚、遇到问题能找到说明，作者名字就有机会成为一种选择线索。

反过来，前缀如果只是挤占界面、不断提醒用户关注，使用者记住的也可能是打扰。署名最好出现在自然的来源位置：仓库、安装入口、说明文档和版本记录。作品首先需要让人顺利完成事情。

从曝光到收入，中间有几次不同的选择

节目里讨论过用游戏、视频或 Skill 获得关注，再寻找商业机会的路径。这条路径存在吸引力，因为作品可以同时展示能力与想法。但其中每一步，都需要使用者做出新的选择。

看到演示，只能说明内容触达了人；打开仓库说明对作品有兴趣；成功运行说明跨过了使用门槛；以后还会回来，才逐渐形成持续关系。至于付费，还需要一个清楚的购买对象，例如托管、维护、定制或其他服务。

这些环节不能用同一个热度数字代替。GitHub 的仓库流量工具分别提供访问、克隆、来源站点和热门内容等信息，而且有观察窗口限制。即使拥有这些数据，克隆也不等于长期使用，更不能直接解释收入。它们适合帮助定位哪一步发生变化，而非给商业成功盖章。

对个人作者而言，一个比关注数更具体的问题可能是：最近来咨询的人，究竟是看过作品，还是已经用过作品？两种联系的需求、期待和后续服务，可能完全不同。

开源后仍然有人需要原作者

代码或 Skill 可以被复制，经验却未必随着一次下载完整转移。新的工具版本出现之后要不要调整，哪些用法曾经失败，什么情况下不该用，这些判断通常会在维护中继续积累。

原作者因此可以保留一条有用的持续关系：维护可运行的版本，解释设计选择，收集真实问题，再把改进返回作品。别人仍然可以做得更好，使用者也没有义务忠于原作者；留下来的理由，需要在之后的工作中持续成立。

这也意味着，开源的价值并不只剩流量。作品可以被团队复用，可以降低别人解决问题的成本，可以吸引贡献者，也可以让作者获得更具体的反馈。是否走向商业化，是其中一种选择，不是所有作品必须抵达的终点。

爆款故事缺少没有被看见的部分

一个作品走红的案例，能证明这条路径有人走通过，却无法说明大多数人照做会得到同样结果。没有走红的尝试、作者此前的积累、原有受众和持续投入，都可能没有出现在传播最广的版本里。

所以，把作品作为一次有限投入的试验，通常比把它当作必然成立的收入公式更诚实。先确定要服务的人、能完成的任务、愿意承担的维护范围，再观察是否出现真实使用。即使没有带来商业机会，作品本身也可能留下可复用能力和公开的工作样本。

如果关注突然增加，下一步也不一定是立刻再做一个爆款。修复安装问题、把常见问题写清楚、说明支持到什么程度，可能更有助于把一次围观变成下一次使用。

作者最终被记住的理由，可以从一个前缀开始，却需要由不断兑现的作品来延续。热度给人一次认识你的机会，之后是否再来，要靠新的使用经验回答。

整理几百本书，是假提效，还是收纳的快乐？

Sun, 18 Oct 2026 16:00:00 GMT

几百本书已经加入微信读书书架，却一直没有认真分组。一次整理把书目拉到本地，让 Agent 提出分类，由用户确认后，再通过 Computer Use 操作 Mac 上的应用，把书一本本放回相应分组。按这次使用记录，一个多小时后，书架整理完成。

这件事很快引出争论：排好之后会怎么看？如果并没有因此多读一本书，算不算假提效？另一种理解则简单得多——这就是一次收纳。

两个判断看似冲突，其实在衡量不同的结果。一个要求整理带来后续产出，另一个把恢复秩序本身当作想完成的事。

先分清这一小时换来了什么

这次任务明确完成的是分类与归位。它没有提供整理前后的找书时间，也没有记录后续阅读量，更没有证明省下了多少人工小时。把一个多小时的执行时间写成节省一个多小时，会偷换比较对象：如果用户原本不会亲自整理，就不存在同等长度的人工工作被替代。

但原本不会做，不代表不值得做。很多个人事务长期搁置，并非毫无意义，只是它们的价值不足以抵消当时的执行成本。工具降低成本后，重新整理书架、把收藏汇总成清单，都可能进入愿意尝试的范围。

这里新增的价值，是以前没有得到的结果。它可以有用，也可以只是让人满意；两者都需要与成本比较，却不必被强行换算成工作效率。

分类应该贴近下一次使用

书架可以按学科、作者、阅读进度分类，也可以按当前正在研究的问题分类。这些方式没有脱离用途的优劣。一个准备写文章的人，与一个想找周末读物的人，可能需要完全不同的入口。

个人信息管理研究长期关注的，正是已经保存的东西如何回到日常活动里。William Jones 在 Keeping Found Things Found 项目的介绍中，把有效的信息管理与日常规划联系起来。这个视角提供了一种提醒：分类系统的意义可以从未来要做的事情反推，而不只是追求目录看起来整齐。

假设某人正在研究城市生活，一本建筑史和一本小说可能值得放在同一组；若严格按出版分类分开，反而增加来回寻找的步骤。反过来，如果用途只是浏览全部藏书，一个稳定、简单的学科分类也可能足够。

Agent 可以降低提出分类方案的成本，用户仍然需要认得这些类别。一个机器解释得很完整、自己下次却想不起来的体系，很难成为长期入口。

收纳有终点，整理也可能成为拖延

把收纳的愉悦承认为价值，并不意味着所有整理都值得继续。分类刚完成，又想统一封面、补齐简介、打上多层标签，接着做阅读计划，一项原本有限的任务可以不断扩张。

若目标就是把混乱书架整理到看着舒服，达到这个状态便可以结束。若目标是更方便阅读，则值得回到真正的使用：需要一本书时能不能找到，刚买的书能不能轻松归位，分类是否还需要经常重做。

这些问题可以在后续使用中回答，无需为了证明提效再建一套复杂仪表盘。挑几个真实的找书场景观察，就比统计新增了多少标签更接近目标。

一次整理若只是带来满足感，也可以如实把它称为整理。真正需要警惕的，是不断扩大的准备工作挤占了原本想做的事，却始终用效率来解释。

个人 Agent 不必只做能写进周报的事

商业工具常用节省工时和增加收入解释价值。个人生活里还有兴趣、舒适、秩序感与探索，它们未必对应产出指标。花时间做一张个人书单，与花时间摆放实体书一样，可以由使用者自己的偏好决定。

不过，这种价值也不能替产品免去检验。一次让人开心的整理，是否足以支撑长期订阅，是另一回事；分类完成的瞬间好看，也不能证明此后仍有用。单次满足和持续使用应分别观察。

对这次书架整理，最准确的结论仍然具体：用户完成了一项想做的收纳工作，后续阅读收益尚未被记录。个人 Agent 的价值可以从这里开始，无需先把每一种生活愿望包装成生产力。

模型越来越强，Skill 里还应该留下什么？

Sun, 18 Oct 2026 16:00:00 GMT

一句话已经能让模型做出视频，还需要安装一套剪辑 Skill 吗？如果要求只是有画面、有声音，也许很快就能得到一个结果。但想沿用自己的字幕、素材、节奏和发布规格，问题就具体得多。

一次 AI 早报制作的分享，呈现了另一种复杂度：用户给出一段提示词，让 Bot 安装四五个已有 Skill，再调用它们完成任务。原本为了省去重复说明而建立的封装，逐渐又需要一层说明才能被使用。Prompt 和 Skill 的边界变得模糊，但用户希望保留下来的东西未必相同。

模型会做，和知道你要什么，隔着一层信息

可以把一套剪辑 Skill 想象成几个不同部分。如何切换镜头、如何生成字幕，属于完成任务的方法；片头文件在哪里、字体用哪一款、横屏和竖屏分别怎样输出，属于项目资料和偏好；哪些片段不能删、成片交给谁确认，则属于具体工作要求。

模型升级可能改变第一部分。过去需要逐步讲解的方法，后来一句话就能可靠完成，旧的长说明便值得重新检查。后面几部分却不会仅因模型更强而自动获得答案。通用模型无法从一般知识中得知某个团队刚确认的片头版本。

因此，判断一个 Skill 是否过时，不能只看模型能否完成同类演示。更有用的比较是：去掉它之后，用户关心的哪些结果会发生变化？若变化只在过时的操作步骤，删减可能让流程更简单；若丢失的是项目规范，仍然需要一个可靠的保存位置。

Skill 可以保存程序和资源

Anthropic 对 Agent Skills 的介绍把它定义为组织在目录中的指令、脚本和资源，并通过逐步加载减少无关内容进入上下文。这个设计说明，Skill 的载体比一段提示词更宽：它也可以把确定的计算交给脚本，把只有部分任务需要的资料放在单独文件里。

例如，假设每次输出都要遵守同一组文件命名规则，并生成几个固定尺寸的封面。把这些要求封装在可重复执行的程序中，就不必每次让模型重新发明处理方法。模型负责理解这次内容，程序负责执行已经明确的变换。

但打包在一起并不意味着一切都该自动运行。资源是否适用于当前项目、脚本依赖是否齐全、生成结果是否满足需求，仍需要检查。一个内容丰富的 Skill，也可能带着错误假设或已经失效的操作路径。

层层封装，容易藏住决定

当一个提示词要求安装多个 Skill，每个 Skill 又引用其他提示词时，最难找的往往不是入口，而是某条决定究竟来自哪里。

设想两套内容 Skill 都规定标题风格，一套要求克制，一套要求强烈吸引点击。单独使用时各有用途，一起加载却可能互相覆盖。再增加一层总提示词，未必能消除冲突，反而可能让使用者更难判断改哪份文件。

拆解这种复杂度，可以从所有权入手：通用制作方法保存在可复用能力里，项目偏好由项目资料管理，这次任务的例外写在任务要求中。每一层负责不同的信息，就不必把同一个字体、同一句标题规则复制到所有文件。

这是一种组织建议，并不是某种格式自带的保证。实际效果还取决于 Agent 能否找到正确资料，以及它如何处理相互矛盾的要求。

清理时，用旧任务做比较

模型更新之后，直接把所有 Skill 删除，或者永久保留所有历史补丁，都缺少依据。更稳妥的做法是挑几个经常发生的任务，在同一组输入上比较：完整 Skill、删掉通用步骤的精简版，以及不使用 Skill 的版本。

需要观察的结果也可以很具体：是否沿用正确素材，是否满足输出规格，哪里需要人重新提醒，完成后是否出现额外返工。这样的比较不能只看一次漂亮的样例；尤其是旧 Skill 曾经修复的失败，要重新放进去验证。

最终留下来的内容，可能越来越少讲模型本来就知道的常识，越来越多记录这项工作特有的事实和约束。Skill 是否值得保留，由它能否稳定传递这些信息来决定。文件叫 Prompt 还是 Skill，远没有其中保存了什么重要。

给 ESP32 装上一个会说话的个人助理

Fri, 09 Oct 2026 16:00:00 GMT

一块几十元的 ESP32 开发板，带屏幕、麦克风、喇叭和陀螺仪，是硬件爱好者手里的电子乐高。过去拿它做点什么，结果多半止步于玩具：AI 能写固件，但对这类硬件不够熟，写出来的东西问题多，用起来也确实不好用。

变化发生在平台开始认真对待这块板子之后。当现成的固件、可改的界面和一段临时搭出来的语音链路凑齐，这块板子从桌面的装饰品，变成了真的会每天被拿起来说话的助理终端。

从自己写固件，到刷上就能用

转折点是通用固件。Muse 为常见的 ESP32 设备提供了针对不同硬件形态的固件：圆形屏的、长方形的都有对应版本，刷进去什么都不用管，直接就能用。连接过程也简化到接近一件正常消费品——在手机应用里打开开发者模式，点加号就连上了。

细节能看出这套固件做得有多完整：中文字体包体积大，过去在内存紧张的小设备上往往要删掉它，而这套固件直接自带中文支持。过去需要绕开的问题，如今在出厂方案里就有答案。

一次具体的桌面改造

有了现成底座，改造就集中在体验层。一次实际的改造包括这几件事：

界面先换成中文，挤在一起的 UI 重新排过。默认角色也换掉了：原来的角色是 64×64 的点阵，只能用代码一笔一笔画；这次让模型直接生成了几张图，做成序列帧塞进固件里播放，类似定格动画——设备在做不同工作时显示不同的动画。从点阵到图片序列帧，小屏幕上的角色一下子生动了很多。

真正缺的一块是语音输出。固件只支持语音输入，回答只能看字，而中文字在小屏幕上非常吃力。固件没有提供语音服务，解决办法是拿一个语音合成服务的 Key，让设备的回传数据经由同一 Wi-Fi 下的 Mac 中转：设备把要合成的文本发到 Mac，Mac 转发给语音服务，音频再原路回来播出来。这条链路是临时搭的，但它管用——设备从此会说话了。

为什么开始真的在用

改造完成之前，这类设备是玩过就不会再碰的玩具；之后的使用状态完全不同：拿起来，说一句话，就有回答。

一个典型的用法是查任务状态。问它昨天让它收集的内容怎么还没到，它会回答：上一个进程正在跑 Memory 的优化。这个问答背后，设备本身没有承担任何计算——重活在云端 Agent 那边跑，小设备承担的只是输入和输出。说话比打字省事，屏幕和声音提供反馈，桌面设备因此成为 Personal Agent 的一个物理入口和出口。

这正是小硬件的价值所在。硬件本身并不稀缺，最近一年各家公司做了大量形态相似的小设备；让一件硬件变得有用的是背后的平台和生态，连上了 Agent，它才有了用途。同样的逻辑可以走得更远：有演示给没有大脑的电动轮椅绑上一块本地算力，轮椅就能自己动起来——算力和模型可以直接成为任何东西的“大脑”。

分工正在改变

通用固件还改变了硬件厂商的处境。设备厂商不必自己做一个 Agent：固件开放之后，硬件可以直接对接大厂的 Personal Agent 生态，做它的“物理外挂”——既是输入的入口，也是输出的出口。已经有硬件创业者在考虑这个方向：与其自己做一套用不起来的 Agent，不如踏实地做那个桥。

对小个人玩家，门槛的变化同样明显。给一块开发板改固件、发到 GitHub 让别人下载刷入，分发比一个手机应用还简单。改造一块桌面设备所需的技能，正在从“懂嵌入式开发”降为“会用 Agent”。

全屋接管是设想，不是现状

沿着“物理外挂”再往外推，就是家庭尺度的想象：这类固件生态里有产品可以作为 Mesh 网关，理论上一个 ESP32 设备就能成为全屋智能的接入点，接管摄像头和各类传感器，学习什么时候开空调、什么时候觉得热，甚至通过家里的音箱主动广播。对照智能音箱时代“关个灯、开个空调”的满足感，Agent 能接手的事情可能复杂十倍百倍。

这里必须分清两件事。桌面尺度的改造已经完成，并且经过了一段时间的真实使用；全屋接管则是设想，中间隔着设备兼容、网关能力、固件权限和语音服务的实际表现，每一项都需要在自己手里验过才算数。本文也不是采购指南——哪块板子配哪个固件、权限怎么给、声音输出要不要自己接，都随设备型号而变，只能实测。

已经验证的与还没走的

这块板子的故事里，已经验证的是桌面尺度：说话进去，回答出来，顺带查一下任务状态。更大的想象在屋子尺度，而那里连第一步都还没有走完。从玩具到助理终端的跨越说明，Agent 时代的小硬件缺的不是算力，也不是创意，而是一个愿意把固件做好的平台。剩下的部分，要靠一次次具体的改造去试。

从收集个人数据到定期回顾

Fri, 09 Oct 2026 16:00:00 GMT

智能手表、录音设备和各类应用每天都在替人记录：心率、训练、对话、睡眠。但多数记录只是躺在那里。记录的价值不在“存了下来”，而在某个固定的时刻有人——或某个程序——回头去看它，对照上一次，发现变化。收集与回顾之间，隔着整套闭环的设计。

记录的门槛正在下降

过去做记录是主动行为：想记什么，得掏出设备、按下按钮、事后整理。传感器把很多记录变成了副产品。Apple Watch 这类设备持续采集心率等数据，不需要任何操作；录音也一样，手表上的录音能力让“随时录一段”不再依赖专门的录音笔或录音卡。过去针对手表录音软件音质的质疑，在这些讨论里被认为可以由本地转录和 AI 降噪化解——声音质量不再是拒绝这种记录方式的理由。

有两点需要保持清醒。其一，录音录下的不只是自己，还有在场的其他人，未经同意的录音不应该因为技术变得容易就成为默认。其二，设备在隐私和转录上的具体表现属于产品承诺，需要逐项核实，不能因为“本地处理”几个字就默认安全。

从存档到每周报告

记录多起来之后，瓶颈转移到整理。一项实际运转中的做法是这样的：力量训练每次都有文字记录——教练负责记，工具 Agent 化之后可以直接拉取结果；有氧数据在手表上，消耗多少也有记录。一个定时任务在 ChatGPT Work 里每周汇总这些，输出一份报告，盯住自己关注的几个指标有没有变化。

另一套类似的机制走得更远：每天早上定时同步一次健康数据，写回自己的 Memory，连同力量训练的记录一起；在此之上再安排定时任务，对数据做分析、生成可视化图表。记录是自动的，回顾也是有日程的——两件事各自固定下来，闭环才成立。缺了回顾这一环，记录只是占空间的日志。

回顾能发现什么

每周报告的价值在于对照。一次被讲述的个人经历是：长期以为头疼是鼻炎引起的，回看记录才发现，头疼与长时间坐着相关，而不是鼻子的问题。这样的发现依赖的正是“积累了一段时间、又被定期看过”的数据——单次体检看不到日常，本人也感觉不出缓慢的因果。

需要划清边界：这是记录回顾发现的个体模式，不是诊断。它提醒的是“有些不适的模式可以从自己的数据里看出来”，接下来该做的仍是去医院检查、由医生下结论。讲述这段经历的人同时点出了另一个现实：医生没有时间细看一个人的全部日常数据，“没病、只是不舒服”的状态通常也不在医疗系统覆盖的范围内。日常数据的定期回顾填补的正是这一段空白——这是个人体验，能否普遍成立因人而异。

保留什么，能不能带走

设计闭环时还要回答：每一层记录保留什么。手表录音的一个细节值得注意：它提供总结，不留原文。摘要便于回看，但原文没了，有些问题就再也问不出来——“当时到底是原话这么说的，还是转写的理解”，只有原文能回答。录音、转写、摘要各自保留到哪一层，决定了这份记录未来还能支撑哪些追问。

另一个问题是归属。血糖仪的数据可以导出，健康数据可以定时写回自己的 Memory——可导出意味着记录跟着人走，换工具、换服务都不必从零开始；反过来，锁在单一服务里的记录，服务一变就成了死档。数据授权也要有自己的线：哪些数据敢让程序自动收集、收集到什么程度，在记录开始之前就值得想清楚。“不会出问题的那些”本身就是一条个人划定的边界。

闭环由此拆成三件事：记录足够省力，省力到不需要意志力维持；回顾有固定的节奏和指标，而不是心情来了才看一眼；数据归自己所有、可以带走。三者齐备，收集来的数据才会变成可用的上下文——缺任何一环，就只是堆积。

手机里的 Agent，限制不止算力

Fri, 09 Oct 2026 16:00:00 GMT

一部旗舰手机可以流畅运行大型游戏，性能与电脑的差距一年比一年小。但让 Agent 在手机上干活，情形完全不同：一条命令都执行不了，文件访问不了，工具调不动。算力在涨，可操作性没有跟着涨。

电脑上的 Agent 靠什么工作

Agent 在电脑上的能力，建立在几十年积累的基础设施上：文件系统、命令行、FFmpeg、Git、Bash。一个具体的场景是：装完一个全新的 Linux 发行版，网络没配好，各种配置无从下手，把 ZCode 装上之后全部交给它操作；有的系统甚至专门写了命令行工具，替 Agent 划定哪些地方能改、哪些不能改，界面崩了、黑屏了，Agent 都能自己修复。

工具链还把产出延伸到代码之外。宣传视频的配乐可以是用 Python 和 MIDI 写出来的，跟着视频节奏走，听不出是程序生成的；借助 Blender 之类的工具，3D 建模和渲染也在同一个可执行的体系里。这些能力有一个共同前提：Agent 能在系统里执行东西。

沙盒挡住了同一套能力

同一套东西在手机上跑不了。Node 和常用的脚手架、组件，在 iOS 和 Android 的应用沙盒里一个都跑不了；Android 的 ADB 等调试通道近年来也管得越来越严。结果是性能过剩的手机上，Agent 访问不了任何东西——只有端侧模型也没有用，模型在本地，手脚被捆住。

一个具体的故障说明了缺口有多小。一个用来替代运动应用、记录骑行并播报公里数的小软件，在电脑上一天半天就开发完了，拿到手机上测试才发现没有申请定位权限，全程记录下来的都是零速度。问题不是算力，也不难解决——如果能直接在手机上调试，改一行加个权限申请就行。难的不是技术，是手机没有给开发者留下这样做的位置。

同样的反差出现在交互方式上。通过语音操作电脑的场景正在变多，实时语音模型密集发布；而在手机上，这类交互基本被限制在单个应用内部——操作系统不给更深的入口，语音再多也只在应用里打转。

上下文也留在电脑一侧

除了执行能力，上下文同样偏向电脑。个人 Memory 可以就是文件系统和文档，挂载一块自己的存储就能自动同步，不必依赖第三方服务；多模态的图像和视频也有地方放。而手机上的信息被锁在一个个应用里，连从云端下载一个文件，找到它都费劲。

于是现实的分工变成了：执行环境放在电脑或者自己掌控的机器上。有人把买来的多套 Coding Plan 装进一台树莓派的虚拟机里，让 Agent 们自己调度、互相补位，定时任务、整理信息、审 PR 都在那台小机器上跑。手机在这一轮分工里，更多是发指令的一端，而不是干活的一端。

系统画出的框，和框上的缝隙

在这些限制下，今天的可行路径都在系统允许的范围内，各有代价：

云端执行是把重活放出去的自然选择，省电也省本地资源，但总有需要与本机信息交互的部分留在手机上，而那正是最难的部分。

厂商自己的通道是特权路径。手机厂商可以用系统级能力把手机上的助手连到电脑，跨设备操作，甚至读到应用里的收藏和相册。这是系统内通道，普通开发者拿不到同等的权限。

解除系统保护确实能放开更多，但代价明确：Root 或解锁之后应用可以检测到，银行类应用直接不可用；开发者模式下的调试接口防范较松，那只是现状，不是可以推广的方案。把“解锁”当成通用解法，风险由用户独自承担。

社区也在找系统留下的缝隙。一个方向是借 iOS 自带的浏览器组件——它是系统组件，权限比普通应用宽——来执行 Node.js 和命令行；另一个方向是从 .swift 文件直接在本地编译、渲染出界面，AI 写一个文件，确认之后应用就跑起来。这两个说法目前都停留在演示和讨论层面，库能否上架、稳定性如何，都还需要工程核验。它们被提及的价值在于指出了问题的性质：限制来自系统策略，不是技术做不到。

算力已就位，环境没跟上

手机与电脑在 Agent 时代的差距，已经不在芯片上。文件、命令、权限模型，这套让 Agent 得以工作的东西，手机要么没有，要么不给。一个骑行软件的故障说明缺口可能只差一次权限申请，厂商通道说明钥匙握在系统手里，社区库说明缝隙存在但未经检验。算力已经就位，剩下的问题是软件环境什么时候跟上——那决定了手机究竟是 Agent 的遥控器，还是它的工作站。

用持续的作品建立信任

Fri, 09 Oct 2026 16:00:00 GMT

一个流传很广的玩笑概括了当下的处境：有了 AI 之后，做文档的文职工作变轻松了，写代码的程序员反而更累了。玩笑背后是一个更认真的问题——当执行层面的工作大量被自动化，人还能提供什么？

答案不会在“产量”里。生成一篇文章、一个界面、一段视频的成本趋近于零，同质内容的供给只会越来越多。在供给过载的环境里，真正稀缺的是另一种东西：有人愿意持续地找到你、认出你、相信你下次交出的东西仍然值得看。这就是信任，而它不是靠单次爆款获得的。

性格需要可以被辨认

在一个人人都能生产的时代，辨识度来自偏好。审美的高低可以争论，但偏好本身就是区别：同样一个题目，不同的人会做出完全不同的东西，有的偏好恰好对上一部分人的需要。

关键在于，这种偏好必须能被外界接收到。品味和性格——这里不评好坏——需要通过发言、内容、产品传递出来，而且要有变化但保持一致。一致不等于一成不变，观点可以演进、风格可以成熟，但长期看下去应该是同一个人，而不是随着热点漂移的声音。这也是“人味”被反复强调的原因：没有人味的内容现在不缺，缺的是能被认出来的那个人。

一致性之所以值钱，是因为它降低了他人的判断成本。读者不需要每次重新评估一个陌生的产出，只需要确认“还是那个味道”。外部关于创作者经济的常识也支持这一点：一个人不需要讨好所有人，能维持一小群深度认可的受众，创作就可以持续。这正是持续作品和短期引流的分野——引流追求一次触达的最大化，作品积累的是可以反复使用的信任。

作品在这里不必是狭义的软件。一篇文章、一档播客、一个 Obsidian 插件，都可以承担这个角色。有的作品上架门槛极低，上架后很快聚起活跃的用户群，正反馈来自真人之间的讨论和使用报告——这种反馈的分量，与单纯的点赞数不可同日而语，因为它意味着真的有人在把作品放进自己的生活。

信任是一种押注，不是定律

有一个说法需要谨慎对待：信任是技术进步不会吃掉的东西。这是一种押注，不是一条定律。

技术同样在改变信任的成本结构。机器生成的内容越来越像真人写的，评论区里也不缺为争夺注意力而设计的声音。伪造“在场感”的门槛在降低，这意味着仅仅看起来像真人，已经不足以构成信任的证明——反过来说，一两处手写的痕迹、一个错别字，也不构成真实性的证据。能支撑信任的，是那些难以一次性伪造的东西：长期的产出轨迹、经得起使用的产品、真人之间持续的互动。

把三者放在一起看：作品提供了可以被检验的记录，一致的偏好提供了可辨认的连续性，真实用户的反馈提供了外部的确认。信任从这三者的叠加中来，缺了任何一层都容易塌。

可复制的东西，和带不走的东西

游戏行业提供了一个极端的测试场景。当一款主机游戏被完整重写到另一个平台上照样运行，当复刻的进度以周为单位推进，一次性买断的商业模式受到的冲击最直接。相比之下，那些围绕账号、角色和持续运营建立起来的服务，受影响的方式完全不同：复刻能带走程序和数据，带不走玩家与角色之间积累的关系。

这个观察来自游戏行业，不能直接推广到所有领域，但它揭示的机制值得记住：越是容易被复制的东西，越难构成壁垒；而关系、共识和持续的服务，复制起来要难得多。对个人创作者来说，这个机制指向同一个方向——把精力放在难以被复制的部分，也就是持续的作品和它与受众之间的连接上。

信任的积累没有捷径，也没有终点。它由一批一批的作品组成，每一件都留下记录，每一次敷衍也都可能留下污点。至于如何在机器越来越擅长模仿真人的环境里，向新受众证明自己的持续在场——这个问题还没有答案，它本身也许就是下一批作品要处理的主题。

把电视遥控器变成电脑的语音入口

Fri, 09 Oct 2026 16:00:00 GMT

电视遥控器上有现成的按键和麦克风，“按住说话”这件事它天生就会。把它连到电脑上，能不能当语音入口用？最近一次试验的答案是：能，但中间缺的那段软件要自己补。

硬件是现成的

试验用的是小米蓝牙遥控器的二代 Pro。它有喷砂铝外壳，按键布局和 Apple TV 遥控器一致，按住即可说话，蓝牙连接，USB 充电，续航按天的粒度掉电。录制时的价格是官方 99 元，网上 89 元，一代更便宜；同期一些主打 AI 语音的专用硬件卖两三百元，壳是塑料的，软件评价也不佳，有的还要占一个 USB 口。型号、价格、续航都是录制时的个例，这里关心的是体验，不是推荐哪一款。

值得注意的其实是生态位：厂商的注意力放在模型和 AI 生态上，并没有把自己的蓝牙遥控器当成电脑外设来经营——没有为它提供电脑端的语音输入软件。这块空位，恰恰是普通人用得上它的地方。

缺的是一段软件

遥控器连上电脑只是开始。要让它变成语音输入工具，两条路：找网上现成的驱动程序，或者按自己的需求写一个。这次试验选了后者——十一假期里用 Codex 开发了一段语音输入程序，定制自己的使用习惯，写完直接投入使用。

这件事本身没有任何技术难度上的新意：蓝牙遥控器是量产硬件，语音识别是成熟能力，写一段输入程序对现在的 Agent 不算难。新的是把它们接在一起之后的感受。

两天的全语音工作

程序就位后，连续两天坐在电脑前做项目，输入基本全靠按住遥控器说话。第三天临时要用键盘打字，出现了没预料到的状况：切输入法的快捷键想不起来了，一种“不会打字了”的陌生感。

这只是一次体验，不是结论。两天不足以证明任何长期的改变，只说明输入习惯建立得比预想快——身体对“开口输入”的适应，可能比自己以为的更彻底。至于长期切换输入方式会怎样，材料里没有答案，也不必急着下判断。

按键和屏幕各自负责什么

这次体验里最具体的部分是掌控感：用键盘时，感觉是在使用一个工具；按住遥控器说话时，感觉是在发号施令——让它干什么就干什么。物理按键给了明确的开始和结束，按下去说话，松开即止，不需要在屏幕上寻找麦克风按钮。对一个以对话为主的 Agent 使用方式来说，这个“握在手里的入口”比界面上的按钮更有存在感。

另一半体验在屏幕上。语音输入如果不能实时显示正在说的话——说了两三分钟什么也看不到，内容一次性吐出来——感受会明显打折，这是另一款语音工具被装上就卸的原因。遥控器解决“说”的入口，屏幕反馈解决“说的时候心里有底”，两者缺一不可：物理入口负责发出指令，屏幕负责让人确信指令被听见了。

谁来把生态位补上

这套组合的每个部分都不新，新的是组合起来的使用感受。厂商如果把这个遥控器单独拿出来卖，再配一个官方的驱动软件，这块空着的生态位未必一直空着。在那之前，这条路的前提是自己补一段程序——这也是为什么它目前更像一次值得记录的试验，而不是一篇可以照做的教程。

什么时候值得把前沿模型换成自己的小模型？

Fri, 09 Oct 2026 16:00:00 GMT

每当有公司宣布用开源模型替换前沿模型、成本大幅下降，评论区总会出现“其他公司是不是也该这么干”的讨论。录制时的判断很明确：这个决定不是技术选型的起点，而是业务成熟度的结果。把顺序弄反，省下的模型费用远抵不上丢掉的质量。

先有资格谈替换

替换模型的前提，是业务闭环已经稳定：产品找到了自己的市场，收入流程跑通，把模型换掉之后整条链路仍然成立。达到这个状态的公司，才谈得上“降本”——因为在替换之前，它们已经能独立回答“质量够用”是什么标准。而绝大多数公司连产品与市场的匹配都还没找到，此时的正确选择是把能力用足，而不是省钱。

新闻容易制造错觉：一家头部公司换了模型，看起来像是所有公司的下一步。实际能走这一步的，是那些已经用前沿模型把业务验证过、把流程打磨好的少数。对多数团队，“不用最新模型就会被竞争对手干掉”的担忧，比“用了太贵的模型会拖垮毛利”的担忧更接近现实。

一个被转述的案例说明了什么

讨论中被反复引用的案例，按转述的口径是：一家法律行业的企业服务公司，早期每收到一美元收入，要向模型厂商支付更高的成本；后来基于一个开源大模型训练了自己的模型，毛利率才转正。收支数字未经独立核实，但这个案例的机制值得拆开：替换发生在模型支出大到影响毛利的时候，发生在任务足够稳定、可以系统性评估的时候，也发生在垂直场景足够封闭、数据足够专有的时候。三个条件同时满足，替换才是理性的。

质量够用，要用场景里的指标定义

“换成小模型效果差不多”这种说法，需要先追问：用什么指标、在哪些环节验证的。录制时转述的另一个例子是，某产品的负责人声称在其场景里，小模型与前沿模型的互动率相当。互动率是一个真实的业务指标，但它是聚合结果——整体互动率相同，不代表每个环节同样可靠；摘要、判断、执行各部分的质量分布，仍可能差异很大。

能做这种验证，本身就是一个资格条件。有真实使用数据、可以对新旧模型做对照测试的团队，才有依据下结论；没有数据闭环的团队，连“差不多”都无法证明。所以合理的顺序是：先定义产品需求和质量标准，建立独立评估，再让替换的决定由评估结果做出，而不是由成本压力直接做出。

垂直和封闭的场景更容易成立

案例里的公司处在法律行业——壁垒高、流程封闭、责任明确。类似的结构还出现在面向医生的医疗、建筑设计这类领域：数据专有，错误代价高，客户为结果而非为模型付费。在这些场景里，模型只是生产要素之一，换掉它不改变产品的根基。

反过来，日常性、通用性的场景——比如视频生成这类大家都能做的垂类——壁垒本来就薄，产品价值与模型能力贴得很近，替换模型的自由度反而小：模型就是产品力本身。判断自己的处境属于哪一类，比研究别人怎么换更重要。

录制时还提到一种配套的产品方向：既然模型能力对多数用户是黑盒，产品可以把模型选择收进去，给用户一个自动档，由产品方负责调度和质量。把模型列表从界面里拿掉，把选择的责任接回产品一侧，本身就是“壁垒在产品”的一种体现。这里还藏着一个检验壁垒的办法：如果换掉前沿模型之后业务依然成立，说明壁垒在产品、数据和流程里；如果一换就垮，说明此前引以为傲的壁垒其实是模型租来的。

时机也是成本问题

替换的收益随时间变化。推理成本整体在下行，而运行 Agent 所需的算力硬件价格在上行，一降一升之间，自训与自建的账要反复重算。硬件那一侧还有一条讨论中引用的老规律：可用性变高会带来更多使用，效率提升并不减少总算力需求。免费产品能支撑大量日常交互，说明小模型已经接得住许多普通任务；但“接得住普通任务”与“接得住你的核心任务”是两回事。

把前沿模型换成自己的小模型，值得做、也做得成的时机是：业务稳定、指标明确、数据在手、垂直场景足够深。四条缺任何一条，更理性的选择仍是继续用最强的模型，把精力花在还没验证的产品假设上。替换是能力验证通过后的结果，不是省钱的起点。

Agent 插件迁移，难在能力不对等

Thu, 08 Oct 2026 16:00:00 GMT

一次顺利的插件迁移是这样的：把一批 Obsidian 插件迁到 DeepSeek Harness 里，让 Agent 自己判断哪些功能与笔记无关并去掉，一次完成，人工几乎不介入。这次迁移成立有一个前提——这批插件用到的能力，目标宿主恰好都有。换成另一批插件、另一个宿主，结果未必相同。

插件迁移的难点因此不在搬运，而在搬运之后还剩下什么。

共识在标准层，分裂在实现层

Agent 插件生态里被普遍接受的，其实只有标准层：MCP 规定了工具怎么接入，AGENTS.md 和 Agent Skills 规定了说明与技能怎么写。再往上，各家插件体系各不相同：Codex 的插件可以固定在侧边栏与用户双向交互，Claude Code 有 Mods，Pi 有 Codemode，DeepSeek Harness 有自己的插件系统。同一个功能，放进不同宿主就是不同格式、不同接口。

这说明生态正在按人群分化：面向普通用户的 Personal Agent 越做越简单，面向生产力场景的 Agent 则不断扩充插件体系，自由度越来越高。插件作为后者的重要扩展方式，天然长在每个平台自己的土壤里。

门槛是宿主暴露了哪些能力

迁移真正的检验是能力对等。有的宿主支持某项能力，有的完全不支持——迁过去功能就被阉割。这种不对等出现在多个层面：

界面层，做 GUI 的插件最脆弱，宿主界面一挪动插件就失效，所以很多适配干脆放弃界面，改做 MCP 或 CLI 这种更稳定的暴露面。更基础的执行能力——宿主是否提供代码运行、能否持久化——决定了插件迁过去是完整功能还是空壳。细粒度功能同样参差，连接器多账号这类能力目前只有部分平台具备。差异未必来自技术限制，很多只是宿主没有做：插件依赖本地执行的那部分功能，在不提供运行环境的宿主里无法落地。

评估迁移时值得先列能力清单：目标宿主暴露了哪些接口、支持哪些文件与执行能力，再决定哪些插件值得跟。清单对不上，格式转换做得再好也没有意义。

上游不稳定，迁移就不是一次性的

即使这次迁成功了，上游一次更新就可能作废。DeepSeek Harness 更新频繁，之前装好的插件多半失效；有插件作者直言自己的库不更新，因为追不上上游。问题的一部分在设计：插件系统把复杂度转嫁给开发者，再配上高速迭代，兼容就成了持续性的成本，而不是一次性投入。

规范层同样需要多线维护：AGENTS.md 之外再维护一份 CLAUDE.md，两边一起改；Agent Skills 则还有宿主没有支持。维护负担直接落在每一个想跨平台的开发者身上。

迁移成本在下降，能力差异不会消失

模型能力让“搬运”本身越来越便宜。一个实际案例是 Markdown 编辑器更换内核：从 Milkdown 迁到 CodeMirror 6，目的是让渲染结果和源码成为同一份事实，而不是两套需要同步的状态。按开发者的估计，这样的工作量原本要以周计；交给模型执行，一次就产出了可用的结果，只需修掉一些遗留 Bug。Obsidian 插件迁移甚至可以整个交给 Agent 判断和执行。

这解决的是怎么搬的问题，不解决搬过去还有没有的问题——能力差异是宿主的产品设计决定的，不会因为转换工具变强而消失。

现成的分发生态

对想分发插件的个人开发者来说，Obsidian 展示了 Agent 官方生态之外的机会：插件上架机制简单，社区插件以开源形式分发，用户社区活跃。一位开发者的 Obsidian 插件两周获得两千多下载，用户群里的反馈直接而具体。

这种机会有它的结构原因。Obsidian 是一个上架的成熟应用，覆盖桌面和手机；插件接上它，等于同时继承了它的用户基数、数据组织和分发通道，不必自己从零积累。有人把它称作“小操作系统”——它自带一套完整的分发生态，开发者接上即可。

这是一次个人体验，规模和速度未必能复制到其他插件或平台。但它说明插件分发的入口不只有各家 Agent 官方市场：成熟的软件生态本身就是渠道，尤其当插件服务的正是这个生态用户的日常。

从规定步骤到对齐目标

Thu, 08 Oct 2026 16:00:00 GMT

为一个 RSS 阅读器开发保存功能，需求是把文章存成 Markdown 或 PDF。功能做完之后，模型多提了一句：用户可能不知道已经保存过了，要不要把这个按钮变成“已完成”的标记。需求没有变，交付多了一层对使用者处境的考虑。这类时刻把一个老问题重新摆到了桌面上：和模型协作时，究竟需要规定到什么程度。

指令执行的尽头

以前与模型协作的常见形态是逐步规定：先做什么、再做什么、格式如何、哪些不许碰。规定得越细，越容易暴露两个问题。一是写全所有步骤几乎不可能，总有没有料到的分支；二是提需求的人自己也可能不懂某些环节，一条外行的字面指令，反而会把执行带偏。

最近的使用体验里出现了变化：模型不再盲从字面要求，按需求做完，还会从全局考虑这个设计最终要服务于什么，必要时指出“不能这么做”。过去那种讨好式的逐步执行，常让协作显得笨拙；现在它更像在理解意图之后给出方案。

对齐取代了步骤清单

反映到日常用法上，写提示词的重心变了。过去是引导、约定、严格限制每一步；现在主要在做对齐——说清楚想做什么、为什么做、做到什么程度算好，至于具体怎么干，不再逐一规定。

这不意味着提示词没有用了，而是两类信息的位置发生了变化。描述“怎么做”的部分在退化，描述“做什么”和“怎么算好”的部分更重要。省下来规定步骤的时间，最好花在把目标本身讲清楚上。

模型变强，需求反而更容易露馅

对齐目标的前提，是目标本身成立。同一时期的观察里有一类典型困境：要求太多、对要做的东西缺乏概念，订阅额度一周耗尽，做出来的东西还不符合要求。模型不会替使用者发明一个清晰的目标；表达混乱时，混乱同样会被执行放大。

专业判断因此没有贬值。一位有开发经验的用户描述过另一条路线：用更快的模型先出一个六七十分的结果，再靠自己的专业判断反复调整到九十五分，总耗时反而更短。判断力和验收标准，仍然长在懂业务的人身上——模型越强，“好”的定义越是由人来给。

边界仍然由人画

把判断交给模型，也要把判断的范围交代清楚。把一整套 Obsidian 插件搬进另一个运行环境时，交代方式是：判断哪些功能与笔记无关，自己决定去掉。模型完成了裁剪和迁移，但“笔记相关”这个范围本身，来自对业务的理解——委托出去的是执行中的判断，画边界的前提仍然是人对事情的理解。

步骤会过时，规则不会

另一个信号来自沉淀下来的流程。有使用者发现，把为旧模型准备的视频制作 Skill 用到新模型上，效果反而下降。这个观察值得记下现象，而不急于推断原因——模型内部为什么受影响，外界无法验证。它至少提醒一件事：为模型当时的能力缺口写的操作步骤，可能随着模型变强变成约束。

沉淀指令时值得区分两类内容。一类是“怎么做”的操作步骤，它们依附于模型当时的能力水平，会过时，需要定期清理；另一类是稳定的业务规则——口径、约束、格式、验收标准，无论模型多强都值得写明。把后者误当成前者一起删掉，和把前者当成长期规则供着，是相反方向的同一种错。

从规定步骤到对齐目标，不是管得更少，而是管的地方变了。仍待回答的问题是，哪些约束值得显式写下来——这没有通用答案，只能按项目逐个判断。

一次 Markdown 编辑器换内核的尝试

Thu, 08 Oct 2026 16:00:00 GMT

所见即所得的编辑器里藏着一个隐蔽的问题：你看到的，和文件里实际存的，可能不是同一份数据。一次把 Markdown 编辑器从 Milkdown 迁移到 CodeMirror 6 内核的重构，就是从这个根源动刀的。

两份状态，数不清的细节

原来的内核里，渲染出来的内容和原始源码是两套状态。改东西的时候，界面上看起来已经改了，源码里可能并没有改。这不是一个孤立的 Bug，而是一类问题的温床：两份表示之间需要同步，同步就有时机、粒度和冲突处理的问题，细节多到数不清，修掉一个又冒出一个。

目标因此很明确：让源码成为唯一的事实，渲染从源码派生。这也是 Typora 等主流编辑器已经验证过的路线。做到这一点最直接的办法，就是把底层内核换掉——在旧的架构上继续修补，等于不断为两份状态之间的缝隙打补丁。

方案是模型提的，工期也由它估

这次重构连方案都来自模型。开发者并不熟悉内核选型，是模型提出换内核、列举了换完能解决的一串问题，并估计工作量“可能需要一周”。开发者反复确认“这个事情我能 Hold 住吗”，得到肯定答复后才动手，使用的模型是当时的 DeepSeek Flash。

一周是按人类的节奏估的。开发者提醒它“你是 AI，一天差不多了”，结果模型一次性写出了迁移的主体，有一些 Bug，但骨架一次成型。预估和执行的落差本身说明了一个变化：过去拦住这类重构的，主要是逐文件改写的工作量；这部分被压缩之后，真正稀缺的变成了判断——要不要迁、迁到哪、怎么算迁完。

“写完了”不等于迁移完成

迁移最容易省略的环节是验收。一次性生成的代码会有 Bug；换完内核后编辑器“巨爽”、解决了一堆旧问题，是使用层面的感受。编辑器质量最终仍要靠长期使用和回归情况说话：旧的编辑行为有没有逐项保留，嵌套结构、粘贴、撤销、表格这些 Markdown 的老大难场景有没有回归。这次尝试没有展示完整的测试覆盖，所以它能支持的结论是“迁移主体完成、使用体验明显改善”，而不是“内核迁移从此很轻松”。

同一晚的讨论里还有一个可以对照的案例：一个游戏项目在更换实现语言之前，先让单元测试把既有逻辑锁住，替换才变得“轻轻松松”。两个案例指向同一件事——行为约束和回归检查，比“重写完了”更能定义迁移是否完成。迁移的产出不只是新代码，还有一套能证明旧行为没有被破坏的依据。

这次经验适用到哪里

同一段讨论里还有另一个迁移：把一整套 Obsidian 插件搬进另一个运行环境，交代方式是让模型自己判断哪些功能与笔记无关并去掉，一次迁完。可见模型能承担的不只是机械改写，还包括迁移中的裁剪判断——前提是把“什么算相关”的范围交代清楚。

讨论中也出现了更激进的感叹，认为不少跨平台技术栈“已经没有市场了”。这句话需要谨慎对待。一个编辑器换内核成功，说明在“双份状态”这个具体病灶上，换掉内核比继续修补更划算；它不能推广成所有框架失去价值。某个框架值不值得用，取决于它解决的问题在当前项目里是否还存在、留在原架构和迁走的成本谁高谁低——这些要按项目逐个算，一次尝试定不了论。

迁移的发起和执行可以交给模型，“什么叫做完”仍然由人定义。这个责任没有因为执行变快而消失，反而因为执行变快，更容易被人忽略。

从一份旧剧本，到一个能玩的游戏原型

Thu, 08 Oct 2026 16:00:00 GMT

一份游戏剧本和世界观设定，在硬盘里放了一年。去年写完就没了下文，今年假期把它交给模型，第一次运行出来的版本就已经能玩。

既有设定替代了从零沟通

这次的起点不是一句模糊的想法，而是现成的剧本和设定。让模型读完之前的剧本设定，直接开始写，第一个版本几乎没有明显缺陷，马上能玩，之后只是迭代了几个版本。

剧本和设定在这里起的作用，相当于一份提前写好的需求文档：世界观、玩法规则、目标都已经落在纸面上，模型不需要从一个笼统的愿望里去猜要做什么。从想法到可玩之间，本来有一段“把设定翻译成开发任务”的路——拆功能、定优先级、写清楚每个系统的行为——这次它被大幅省掉了。

后续迭代里的分工也值得记录：人指出哪些地方需要性能调优、哪些地方的设定逻辑要改，模型把这样一句指令展开成完整的实现。需求可以下得很短，因为上下文已经完整地在项目里——剧本、已有代码和此前每一轮修改，都替代了本该写进需求文档的大段说明。

一次体验描述把这个过程比作“一位年薪几百万的游戏公司 CTO，几十分钟干完几个月的活”。这是体验层面的类比，不是可以复核的基准，它传达的只是迭代速度带来的主观感受。

性能问题出现之后

原型跑起来之后，问题才换成性能。最初的实现用 Canvas 绘制，提出提高性能的要求后，实现换成了 PixiJS。调整过程中，执行方会解释自己正在做什么：CPU 耗时花在哪里、和屏幕刷新率是什么关系、算法路径怎么优化、能赢回多少毫秒。

这是一条典型的原型路径：先让东西跑起来，再按帧时间和关键路径逐项优化。“能玩”优先于“流畅”，性能问题要在能玩之后才有资格出现——对一个验证想法的原型来说，次序反过来就什么也验证不了。

原型之后的岔路

接下来的考虑是上架 Steam 和 App Store，就此询问模型，得到的建议是转向 Godot 引擎。同时，一个已经用某种语言写完、又有足够多单元测试把逻辑锁住的项目，替换实现语言被认为是可以轻松完成的事。

需要划清的是，这些都停留在下一步的设想。到这次尝试被记录时，这个游戏是一个能玩的体验版原型，还没有上架任何平台，也没有确定最终用什么技术栈发行。

“代码很好”目前只能算传闻

围绕这次尝试还有一种说法：出来的代码达到国际水准。这里必须区分证据的层级。出来的是功能，代码本身没有读过；所谓水准，一部分来自使用体验——缺陷少、迭代快、讲解专业，一部分来自他人对模型代码能力的评价。产品体验好，推不出代码质量高；要支持“代码优雅”之类的判断，需要真的读代码，需要项目层面的证据。

在证据补上之前，这次尝试能确认的事情是：从一份旧剧本到一个能玩的原型，实现环节已经被压缩到假期里的几次对话。而判断好不好玩、值不值得继续投入、往 Steam 还是别的方向走，这些决定仍然留在人手里。

还要记得原型验证了什么、没验证什么。它能证明的是，一年前写下的设定可以变成一个运行起来没有明显缺陷的东西；它不能证明这个游戏好玩，更不能证明有人愿意为它付费。玩法手感、内容深度、留存，这些要等更多人玩过之后才有答案——原型把“做出来”的门槛降下去了，“做得值得”的门槛还在原地。

让软件成为 Agent 用得上的工具

Thu, 08 Oct 2026 16:00:00 GMT

用 Agent 建一个 3D 模型，过程可能和想象完全不同：Blender 的界面上毫无动静，一直停在欢迎页面，Agent 在旁边持续写代码——它用的是 bpy，Blender 自带的 Python 接口。过一会儿它说建好了，打开一看，模型已经完成。整个过程对图形界面的依赖，只剩最后打开文件确认结果。

这个案例值得仔细拆解，因为它展示了软件真正“被 Agent 用起来”时发生的事情：操作不走界面，走的是软件暴露的编程接口；结果可以被检查，闭环才能成立。

界面不是给 Agent 的入口

图形界面为人设计，靠可视化和即时反馈帮助人理解状态。Agent 更高效的路径是绕过这层，直接调用接口。一条兜底路线是 Computer Use：模型厂商等不及软件逐个改造，先训练模型去操作人类界面，让它能使用以前的软件。软件自己主动适配是另一条路线，两条并行推进。但只要软件开放了接口，操作界面就只是过渡形态——每次点击背后本来就是一个可调用的能力。

通过接口操作还有效率上的差别。用 bpy 建模几乎不消耗“看界面”的开销，Token 效率高，中间用 MCP 截图确认的次数也很少。Godot 等游戏引擎有类似的结构：做完直接打开就有结果，不存在一个“操作界面”的过程。

这提示了一种分工：让代码负责操作，让界面负责查看。软件可以继续把交互打磨得对人友好，同时为 Agent 的调用效率单独做一套基建——两条通路服务两类使用者，不必互相迁就。

能力接口与可检查的结果

软件对 Agent 的可用性，第一个标准是它暴露了哪些能力接口。命令行工具天然占优：剪辑工作流里，Codex 加 FFmpeg 可以直接完成剪辑——不是因为它操作了某个剪辑软件的界面，而是 FFmpeg 本身就是一套文本接口。相比之下，图形软件如果没有开放接口，同样的工作流就接不进去，无论它的界面做得多么完善。这与某款软件好不好用无关，只是接口开放程度的差别。

第二个标准是结果可检查。Agent 的产出要能被验证，任务才算闭环：模型建好了，打开文件确认；排版生成了，截图比对。可检查性决定了 Agent 能否自我修正，也决定了人需要在哪些节点介入。

内置 Agent 与开放能力是两回事

软件拥抱 Agent 有两种方式，经常被混为一谈。第一种是把 Agent 装进自己的软件：内置一个助手，改善自家产品的体验。剪辑软件出自己的 Agent 属于这一类。第二种是把软件的能力开放出来，让外部 Agent 调用。

两者的差别在封闭性上最明显。一个剪辑软件的案例是：它有类似 Skill 的能力体系，但录制那次讨论时只能用在自己家的 Agent 里，外部的 Codex 调不了。能力是有的，只是锁在自家生态里。另一种做法是 DaVinci Resolve 把能力拆成 MCP，任何模型都能接；当时它还把 MCP 放在付费版里——开放本身成了付费点，说明软件厂商开始把“能被 Agent 调用”当成一种可以定价的能力。

两种方式回答的是不同问题：内置助手服务于自家软件的用户，开放能力让软件进入别人的工作流。对使用多种 Agent 的用户来说，第二种决定了这款软件能不能出现在自己的任务链里。

宿主也要接得住

软件开放了能力，还需要宿主 Agent 有执行环境承接，这一环同样经常缺失。垂类设计 Agent 的反例：接的模型明明有编码能力，产品却主动限制编程；排版的参考图能上传、Agent 也能看到文件夹里有它，真要调用时却调不了——文件系统支持不完整。即使建模软件开放了 bpy，这样的宿主也用不上。临时的虚拟机还带来持久化问题：每次拉起的是不同环境，上下文难以延续。

软件成为 Agent 插件

把两条线索合起来，可以得到一个方向性的说法：原来的模式是软件把 Agent 弄进来，接下来的模式是软件把自己变成 Agent 插件——不再等某个内置助手，而是让自己的能力成为所有 Agent 都能调用的工具。围绕这个方向已经有产品设想，比如为封闭生态的剪辑软件做一个支持外部 Agent 调用的替代品；设想是否成立，要看它能否回答前面列出的三个问题：能力接口是否完整、结果是否可检查、宿主环境是否接得住。

这三条也构成评估任何一款软件“Agent 可用性”的清单。三条都满足，软件才不只是给人用的界面，而是 Agent 工作流里真正用得上的工具。

Vibe Coding 之后的硬盘账单

Thu, 08 Oct 2026 16:00:00 GMT

一台 512GB 的笔记本，换成 2TB 的新机，三个月后一看，1TB 已经没了。这不是下了多少电影，而是 Vibe Coding 改变了生产速率：项目、Worktree、生成的素材和中间产物，以前所未有的速度往硬盘里堆。账单变了，值得算清楚它由哪些部分组成。

空间被谁吃掉了

被吃掉的空间里，相当一部分可以再生。终端里每次装包留下的安装包和依赖、Agent 反复操作浏览器积累的缓存——一次观察中，仅 Chrome 的缓存就达到 60GB 以上；自带浏览器的聊天办公软件各有类似的堆积。这些东西删了会再生成，占的却是最显眼的地方。

另一部分难以再生。做开发的人对系统镜像不陌生：为了在多个系统版本上测试，几套 iOS 和 iPadOS 镜像加起来就是四五十GB，Xcode 本身也不小；聊天工具的本地数据动辄是单项最大——不少人的第一大头是微信。还有 Worktree 和疯狂生成的项目文件，这正是 Vibe Coding 带来的新变量：以前一个月开不了几个项目，现在一天可以并行一堆。

这些数字都来自个人机器上的观察，不是统计结论，不同用法差异极大。但方向是共同的：单机容量从“够用很多年”变成“每年都要重新规划”。

缓存可以删，底稿不能删

对待这些数据不能一把抓。缓存、安装包属于可再生数据，删掉的代价只是重新下载；项目文件和记录属于难以再生的原创数据，删了就没了。

麻烦的是中间地带。做内容的人最清楚：录 10 到 20 分钟的原始视频，按录制规格就是 20 到 30GB。这些底稿“删也不行，不删也不是”——重做成本太高，留着又持续占空间，只能先放着，过段时间再决定。一块硬盘里，可再生与不可再生的数据混在一起，这正是清理变难的原因。

自动清理的风险已经显现：让 Agent“恢复 100GB 以上空间”，它逐个目录找，确实清出来了，代价是几乎所有常用软件都被删掉，最后只好彻底重装。容量焦虑之下，“一键清理”听起来诱人，但区分哪些文件还能再生、哪些是孤本，目前仍是人要做的判断——本文也不提供任何未经复核的清理操作。

存储要分层

既然数据性质不同，存放方式就该分层。

最上面一层是本地热数据：正在跑的项目、频繁改动的文件，留在速度最快的 SSD 上。往下一层是家庭归档：不天天动、但时常要查的东西，放到 NAS——局域网直接访问，延迟不是问题。已经有人在把本地 Memory 挂载同步到 NAS，让个人数据在家里有一份集中存放。

再往下是冷归档：视频底稿这类“肯定不想丢、但一年也取不了几次”的数据。冷存储的设想是：价格比常规网盘低一个量级，代价是不能马上下载——想取回某个卷，发一个请求，等上一天。价格差十倍换等待时间，听起来成立；反对意见同样直接：多数用户连 24 秒都不愿意等，等待会直接杀死需求。这个设想至今仍是设想，没有一个已验证的产品摆在货架上。物理介质的老办法也有局限：一张 DVD 只有不到 7GB，连一期节目的量都装不下。

容量之外的账：备份与找回

硬盘账单不止容量一项。要备份就意味着至少两份：家里买 NAS，硬盘可能坏，做备份就得再买一块盘，成本接近翻倍；用云订阅则按月付费——一个录制时的个例是全家 2TB 的 iCloud 套餐接近用满，再往上一档，每月开销要涨两倍多。这只是个人的账单，不构成对任何人的预算建议。

还有一项更容易被忽略：找得回来。多机器时代，文件开始散落在更多地方——克隆进云电脑虚拟机的工具和产出、交给 Agent 处理的冷备份。把每期节目的冷备份交给 Agent 之后，一个现实的问题是：备份到底落在哪个目录，交托的人并不清楚。存下来了，不等于管得起来；需要恢复的那一刻才发现说不清路径，备份的价值就要打折扣。高频自动同步同样有代价，已有把硬盘读写用到报废的个例。

分层因此不只是省钱，更是风险管理：不可再生的数据放在更稳、有冗余的地方，可再生的数据不占昂贵的地方。至于那些“删也不行、不删也不是”的底稿，真正的答案可能不是更大的硬盘，而是一个取回慢一点也无所谓、便宜得多的去处——它现在还不存在，但需求已经先到了。

Agent 可以替我办事，到哪里应该停下来？

Wed, 07 Oct 2026 16:00:00 GMT

把订酒店这件事整个交出去：告诉助理出行时间和预算，然后等结果。听起来很省事，但中间藏着无数个决策点——住哪个区、什么价位、选哪条取消政策、以谁的名义向谁确认了什么。委托不是一句话，而是一串需要划界的问题：Agent 替人办事，从哪一步开始应该停下来问人？

助理，不是分身

Personal Agent 兴起后，一个老问题重新变得现实：这类产品究竟是用户的助理，还是用户的数字分身？目前这一波产品的共识落在助理上——管理邮件、管理日程、订机票订酒店，这些过去由秘书承担的事务。助理与分身的区别不在能力清单，而在意志：助理执行用户的决定，在重大的地方回头请示；分身则替用户形成判断、替用户表态。

这个定位直接决定权限设计的形状。做助理，意味着 Agent 可以被授予能力，但不应该被默认授予替人做决定的权力。委托的深度也分层：整理邮件、汇总日程，出错可以重来；订错一间房，钱已经花了，行程可能已经变了——风险随不可逆程度上升，请示的点应该跟着风险走。哪些决定仍归主人，需要产品显式划出来，也需要用户自己心里有一份清单。

价格只是约束之一

一种推断是：Agent 能搜遍全网，总能找到更便宜的渠道，订单自然会流向出价最低的一方，渠道格局因此重排。这个推断把订房简化成了一次比价。

实际的使用逻辑更复杂。一次被提出的反问是：便宜若以糟糕的体验为代价呢？用户住完会说，以后别从这个渠道订了，这个渠道每次订得都很垃圾。价格之外还有位置、偏好、取消政策和渠道可靠性，这些信息分散在行程本身和历次反馈里。订房这件事需要知道的，不只是当前行情，还有主人的习惯——理想的状态是这些偏好在下单之前就在上下文里，而不是靠订错一次来补课。

因此反馈回路是委托系统的一部分，而不是附加功能：住过之后的结果要能流回下一次决策，否则 Agent 会一直重复同一种“便宜但不对”的选择。只优化价格的委托，等于把最难的判断悄悄推给了用户自己。

承诺、付款与分享是三件不同的事

把委托拆开看，至少有四个层级，风险各不相同。读取与整理——看邮件、排日程、汇总订单，风险在于隐私。执行与下单——订酒店、买东西，花的是真金白银，通常值得留一个确认点。对外承诺——取消订单、改期、答复别人“明天下午在家”，以用户的名义产生了真实世界的义务，撤回成本发生在现实里。分享信息——把行程、地址、财务状况告诉其他服务或其他人，一旦给出就可能收不回来。

层级不同，授权方式应该不同：读取可以一次授权长期有效，下单逐笔确认，对外承诺和分享信息则应该是最高门槛。这里的产品空间还很大。一个具体的例子是 Instinct 的好友网络：加进来的好友可以向助手询问用户的各类信息，产品方据此建议用户只添加真正的亲密好友。用“亲密好友”来框定信息访问范围，本身就是对分享权限的一次设计尝试——边界要比社交软件好友更窄才安全，这样的设定能否成立，仍有待验证。

站在哪一边

传统中介和代理有自己的利益，订哪个渠道未必只对用户最优。新一代订房助理刻意与这个模式拉开距离，被概括为“完全站在你这边的，以你的权益为核心的”。定位可以这样宣称，立场却不能只靠宣称：收入来自哪里、与哪些渠道有合作，都会影响推荐的中立性。用户可检验的办法不多，反馈与更换的自由是最实际的一种——助理若经不起“下次别用它”的纠正，所谓站在一边就只是说辞。

停下来的地方，就是产品

让 Agent 停下来问，不是能力不足，而是委托关系应有的结构。真正的问题从不是“能不能全部代办”，而是每一类代办对应哪种确认方式：什么一次授权，什么逐次点头，什么永远留在主人手里。助理与数字分身之间那条线，正是一处处停顿连起来的。

把记忆带到下一个 Agent

Wed, 07 Oct 2026 16:00:00 GMT

用了一年的 AI 助手，记得你的项目、写作习惯和常聊的话题。这时出现一个更好用的 Agent，面对的问题不是“要不要换”，而是“带不走”。记忆长在原来的产品里，换工具等于失忆一次。

记忆的归属问题

云端产品的记忆保存在服务端，绑定在账号上。这带来两个麻烦：一是记忆的质量取决于产品愿不愿意做好，做得不好，用户没有别的办法；二是产品与模型本身会变化，数据交出去之后未必拿得回来——今天好用的服务，之后可能改版、调整或关停，而下一个更好用的，读不到这边攒下的东西。

一种应对思路是维护本地的 Memory 和本地上下文，并预期会出现专门的产品把这件事做好。这是对产品方向的判断，尚待验证，但它指向一个立场：个人上下文应该有一份独立于任何聊天窗口、任何产品的存放处。

一套文件系统做底座

已经有人把这种存放处做成了文件系统：数据库加文档，Memory 就是一堆文件。这大概是最不时髦、也最难被任何一家公司锁死的形态——文件在哪里、是什么格式、能不能打开，都一目了然。

同步是第一个要解决的问题。把这套文件同步到 GitHub 私有仓库是一种选择，但实践中的问题很具体：文件数量多而碎，仓库很快变得臃肿；更麻烦的是多模态素材——经常和图像、视频打交道的人，没法把这些东西放进 Git。于是另一种做法出现了：写一个挂载，让本地 Memory 自动同步到家里的小米智能存储，不经过任何第三方服务。

需要说明的是，这是一项个人实践，不是一套经过验证的通用架构。它证明的是“个人可以持有自己的上下文”；至于文件该用什么结构、同步频率怎么定、多种素材如何索引，都还没有标准答案。

工具会换，组织方式可以留下

文件形态的记忆库有一个容易被低估的好处：它可以整体搬家。

一次实际的迁移尝试是把为 Obsidian 开发的一批插件交给 Agent，迁到另一个运行环境里：由 Agent 判断哪些功能与笔记无关、自行去掉，然后一次性迁完。工具换了，积累下来的东西——插件、目录结构、组织习惯——跟着走。这套 Memory 文件夹的组织方式，最初就是从 Obsidian 的笔记文件夹延续下来的；软件可以换，组织方式不依附于任何一款软件。

所谓 Memory，落到实现上就是“一个由 Markdown 和 Git 组成的东西”，或者说，就是文件。越是接近普通文件，迁移成本越低，被单一产品绑架的可能性越小。

记忆里该放什么，交给谁用

一份实际在运转的 Memory 大致分几类：自己的项目、发出的作品和内容、形成的认知，还有生活上的记录。健康数据也在其中，每天定时同步一次，写回 Memory，之后再基于这些数据做分析和可视化。

这套文件系统的另一个用途，是让多个 Agent 共享同一份上下文。一种做法是把几个模型的用量同时装进一台虚拟机，让它们看着安排：谁写得动就谁写，闲着也是一种浪费。任务不再绑定某个特定模型或产品——因为上下文在文件系统里，任何一个 Agent 接进来都能读到。可迁移性改变的因此不只是“换工具”，还有“同时用几个工具”的方式。

同步不等于备份

最后要分清两件事。同步解决的是“每个地方都有最新的一份”，备份解决的是“丢了还能找回来”。自动同步到 NAS 的文件，如果 NAS 只有一块盘，坏一次就全没了；高频读写还会实打实消耗硬盘的寿命——已有重度使用者因为每天写入大量原生数据，把硬盘用到报废的个例。

收集也不等于可靠记忆。往 Memory 里塞东西很容易，塞进去的东西是否还能被找到、是否已经过时、是否值得保留，需要另一次整理。把记忆带到下一个 Agent，靠的不是把文件拷贝过去这个动作，而是一套持续维护、随时可以交出去的资料库——它属于你，才谈得上跟着你走。

邮箱里的生活，微信群里的生活

Wed, 07 Oct 2026 16:00:00 GMT

开学前一天，一款接了邮箱权限的 AI 助手发出提醒：学校来邮件了，明天要穿什么校服、带哪些材料，还有一份需要家长签字的同意书。这件事的技术难度不高，难的是它成立的前提——学校用邮件通知家长。换一个环境，同样的提醒可能藏在一个家长群里，助手就够不着了。

信息在哪里，能力就在哪里

对账单、订单、学校通知都走邮箱的用户来说，把邮箱权限交给助手，就覆盖了生活中相当大的一块信息流。一项试用中，Dots 被一次性放开了 Google 服务的权限，学校邮件里的三件事被自动整理成提醒；这类体验在邮箱生态里是顺理成章的，因为信息集中、接口开放、格式相对规整。

许多国内用户的同类事务则分散在别处：账单在支付应用里，订单在电商应用里，学校的通知很可能在一个微信群里。助手看不到这些位置，再强的模型也只能给出泛泛的回答。这不是模型差距，是信息位置的差距——生活助理的第一道边界，由信息所在的地方划出。

群聊里的待办

群聊承载了一部分这样的生活信息。家长群是常被举起的例子：消息过载是几乎所有群的状态，老师发通知、家委会发接龙，重要的待办淹没在闲聊和转发的洪流里。如果助手能读到这些群，从中找出与自家孩子有关的事项并帮忙跟进，价值显而易见——难处同样显而易见，上下文在平台手里。

平台内助手是另一种路径。录制时的个案：有用户让微信里的小微找到某个群并发一条通知；也有人遇到设备使用问题，直接在微信里问小微就得到了答案。这些能力是按个案发生的，不代表平台接口已经全面开放。平台内助手的好处是入口就在日常软件里，坏处是每一步能力都受接口开放范围的约束，且随时可能变化。

垂直应用先一步解决问题

在通用助手够不着的地方，垂直产品先交出了答案。录制时的观察：让通用 Agent 去淘宝购物，它搞不定，淘宝应用内的 AI 却好得多；旅行订务，飞猪的 AI 顺；问诊咨询，医疗垂直产品答得比通用回答细致。数据、接口和上下文在哪里，能力就在哪里生长。于是有判断认为，真正通用的生活 Agent 目前并不存在——每个场景的上下文都被各自的平台握着。

一个更直接的例子来自金融数据：WorkBuddy 接入了别处读不到的行情数据，用户为这一项能力涌入，其他产品随即跟进对接。收益来自数据与接口的连接，不来自泛泛的对话能力。

开放程度决定谁有资格做生活助理

个体层面的结论是：上下文越多，AI 能帮上的越多。这同样解释了两个市场产品形态的差异。海外信息服务之间的连接相对开放，软件之间可以互相授权，创业公司和大厂都能取得上下文；国内接口分散、数据不共享，创业公司拿不到 Context，“小院高墙”各立门户。于是连接、授权这些环节从技术细节上升为产品成败的关键，助手要在手机系统层争取权限，否则什么都干不了。这些是录制时的观察，接口开放范围逐项在变。

渠道习惯也随之不同。一个被记录的注册体验：海外的订房助理依赖 iMessage 或 WhatsApp 对话，国内用户注册门槛高，进来之后也不知道该跟它聊什么——生活助理脱离了信息所在的渠道，就失去了场景。

结尾

生活助理的竞争，首先是信息位置的竞争。邮箱生态的用户先一步获得完整体验，不意味着另一边永远落后：群聊、小程序和各类 App 里同样埋着完整的上下文，平台一旦开放接口，位置就可能重排。真正悬而未决的问题是，当生活信息散落在十几个互不相通的应用里，谁来负责把它们连到一起——是操作系统，是超平台，还是某个愿意做脏活的助手产品。

从空白聊天框到第一件有用的事

Wed, 07 Oct 2026 16:00:00 GMT

一个新的 AI 应用装好，打开是一个输入框。对每天离不开 Agent 的人来说，这无所谓；对大多数人，这是一个问题：第一句话该说什么？Personal Agent 这一轮产品的核心主张，正是把 AI 交到这些人手里——而它能否被用起来，取决于第一件有用的事何时发生。

第一件事从哪里来

空白输入框隐含着一个假设：用户知道自己想要什么。实际观察与此相反，相当一部分人打开一个 Chatbot 或 Agent，并不知道该让它干什么。起点因此成为设计对象。

一种做法是列场景。一项录制时的体验里，Muse 用一个页签列出具体的生活难题：信用卡被多扣了钱，能不能让 AI 自动把钱要回来；要办一场聚会，能不能让 AI 把物料采购安排好。每个场景点下去就开始执行，不需要用户先想措辞。这些场景都经过挑选，贴近当地生活的真实痛点，而且偏向生活而非工作。另一种做法是推荐：基于长期记忆，为用户挑选可能感兴趣的内容，在不知道干什么的时候提供一个起点。

两种入口的共同点是把“我能帮你什么”翻译成一个可以立刻点下去的第一步。空白聊天框没有消失，只是不再独自承担开场的责任。

生活问题不需要工作台

Personal Agent 之所以能这样简化，与另一条产品线有关：Agent 正在分化。面向生活的产品越来越简单，恨不得进去就能聊；面向程序员和生产力的产品自由度越来越高，插件、模型选择、自定义工作流一应俱全。

这种分化对应着任务性质的差异。生活任务没有项目、没有代码库、没有交付物，用户不需要管理会话，不需要理解上下文窗口，甚至不需要知道背后是哪个模型。生产力工具里的那些自由度，在这里全部是负担。所以 Personal Agent 的交互往往退回对话本身——回到最初聊天即用的形态，把复杂性留在系统内部。

反面例子同样说明问题。一项发布初期被记录的体验里，Dots 被放进一个已经有很多入口的侧边栏，用户分不清它和旁边几个产品的区别，上手反而更难。入口多不等于门槛低；对生活场景来说，每多一个需要理解的概念，就少一个会开始用的用户。这些是录制时的产品状态，各自都会继续演进，不构成对某个产品的定论。

入口的位置也是上手的一部分。一条被记录的产品经验是，用户离不开日常软件里已有的联系人列表——有产品把助手做成微信里的一个“好友”，扫码就能聊，转化成本因此大幅下降；平台内助手遵循同一逻辑，入口就在人们每天打开的应用里，位置本身替用户省去了一次迁移。

交出去之后，人要看得见

第一件事开始之后，体验的分水岭在执行过程。常见的两类挫败都与沟通有关：一类是没帮上忙反而添了新问题；一类是复读——把用户的话复述一遍，不给结论，再建议“你可能应该干这个”。后一种尤其消耗耐心，因为它花费的是用户的注意力和时间。

表现较好的产品在执行结构上做了区分。仍是 Muse 的体验：它内部只有两个角色，一个负责与用户沟通和派任务，另一个在后台执行；屏幕一角有一个小区域，持续显示后台正在做什么、哪些事项等待审批。左边对话不断线，右边状态可查，用户才能放心把事情交出去。

请求协助的方式同样关键。有些环节 Agent 做不了，需要用户补一小步——怎么说这句话，决定用户觉得“它在帮我”，还是觉得“它在指挥我”。这一段交互的质量不取决于模型能力，取决于产品设计是否把人的感受当作一等对象。

会话留给技术，人称留给用户

用得久了会出现组织问题：每件事都要开一个新会话吗？工具类产品按任务切分会话有其道理，但生活里的对话对象是“一个人”，不是一个文件目录。有产品开始把组织方式从会话转向角色：对着同一个人说话，沟通中产生的上下文由系统自动整理提炼。一个可作类比的事实是微信——它的会话列表从来都是人和群，而不是话题和项目。

不过单一会话并非万能。编程、长期项目这类专业工作，仍然需要自己的工作区和隔离的上下文，塞进同一个对话框只会互相干扰。合理的并存方式是：生活交给一个常在的对话，专业工作交给项目化的工具，两者不必强行统一入口。

结尾

从空白聊天框到第一件有用的事，中间隔着三层设计：一个不需要措辞的起点，一段看得见、能纠偏的执行，以及一份不必由用户维护的组织结构。三层都齐了，第二次对话才会发生。上手的定义因此可以改写——不是用户学会了产品，而是产品在最初几分钟里完成了一次闭环。

从卖 Token 到交付服务：AI 应用的利润空间

Wed, 07 Oct 2026 16:00:00 GMT

想在产品里用上一个多模态模型，先要在文档的汪洋大海里找到模型名称，再弄清调用方式；好不容易接通，首字延迟却能达到别家的一百倍量级——这是录制时一次真实对接的经历。买到了 Token，和把 Token 变成体验之间，隔着一整段工程。利润空间的问题，正藏在这段距离里。

转售的账算不过来

最直接的商业想象是转售：拿到折扣价，加价卖出。现实是折扣很薄。录制时有人接到报价：八折转售主流模型的 API。做生意的基本线是四成毛利，两成的差价意味着每做一单赔一单；头部模型的官方渠道自己就能给出折扣，中间商没有任何空间。模型供不应求时更是如此——没有富余产能，厂商就不需要给折扣。

另一种常见的账面处理是预收：把一年套餐的钱一次收齐，放进当期报表。这叫现金流，不叫利润——服务还没交付，成本还在后面。把这些数字当成盈利能力，是那段时间应用层融资故事里常见的误区。市场资金又在向少数赛道集中，靠融资补贴亏损的余地变小，利润问题于是无法回避。

模型便宜之后，才腾出毛利

转机来自供给侧。录制前后的一批低价、高速模型，第一次给了应用层像样的价差空间：同样是完成一次回复、一次判断，成本降到原来的零头，服务定价就有了回旋余地。讨论里转述过一个案例：一家企业服务公司过去每收到一美元收入，要向模型厂商支付更高的成本，换成基于开源模型自训的版本之后，毛利率才转正。这是转述的口径，未经独立核实，但机制是清楚的：模型支出大到吞噬毛利时，应用公司挣的钱其实一直在替模型厂商打工。

这也是“不要羞于卖 Token”这句话的上下文。应用层做的所有工程——界面、缓存、调度、验证——最终都是为了用户愿意在这里消耗 Token。承认这一点，才能算清自己到底挣哪一段钱。

Token 是计量单位，不是产品

把 Token 比作货币的说法在录制时很流行：模型能力成了数字世界的硬通货，连支付公司收购模型路由平台，都被解读为提前布局“Token 结算”。这个比喻有解释力，但也容易误导——货币的价值在于通用，而应用层的价值恰恰在于不通用。

用户付钱买的从来不是 Token 本身，而是 Token 背后的确定性：可用性、延迟、输出格式、出错时的兜底，以及结果可以放心交给下一步的保证。同样的 Token，从云厂商的控制台里取，和从一个顺手的产品里取，体验完全不同。云厂商按 to B 的方式卖接口，使用者却常常只是想让它跑起来——这个落差就是机会。

挣的是“最后一段距离”的钱

于是出现了所谓体验套利：把难接的模型接好，把难调的参数调顺，让用户和 Agent 可以直接调用。多模态和内容生产类模型尤其明显——能力强，接口却散落在各自的文档里，谁把它们组装成顺手的服务，谁就在挣工程与体验的钱。这个位置不缺尝试者，缺的是把接口服务本身当产品做的人；讨论里被看好的方向，是覆盖视频、图像等一整类多模态模型的一站式接口，恰恰因为那部分最难读、最费力。这类机会不需要独家模型，只需要把“能用”变成“好用”的那段距离。

成本结构还在变化。推理成本在下降，而 Agent 规模化运行所需的算力硬件反而在涨价，自建与租用的账随价格实时改写。不变的是位置：单纯转售折扣的业务没有护城河，利润属于那些把 Token 变成确定服务的人。模型越便宜，这段距离的价值越清楚——它才是应用层真正的毛利来源。

给 Agent 一台不下线的电脑

Wed, 07 Oct 2026 16:00:00 GMT

给 Agent 交代一个任务，第二天回来接着用：它昨天装的软件还在吗？登录过的账号还有效吗？生成的文件放在哪里？这些问题的答案，取决于它运行在一个临时沙箱里，还是一台不下线的电脑上。

任务结束后还剩下什么

最常见的执行环境是临时沙箱：每次对话拉起一个虚拟机，不同对话、不同进程拉起的可能是不同的机器。任务一结束，环境就被回收，装进去的东西和中间状态都不保留。这类做法成本低，代价是上下文没有持久化，任务之间无法积累。

不是所有产品都把执行环境留给用户。一些垂类 Agent 干脆不提供运行代码的能力：参考图传得上去，却调不出来，文件系统形同虚设。问题不在模型没有编码能力，而在于产品没有给它一个能操作的环境。也有产品出现过更极端的情况：环境里的内容直接丢失，用户来不及保存任何东西。

在这样的背景下，持久环境的主张显得很直接：给 Agent 的那台电脑应该一直在，用的时候要能承诺数据不会丢。这一步已经不只是功能差异，而是被当成了产品本身——Grok Bot 把这台“云电脑”作为一个有名字的部件放在台面上，而另一些产品里，同样的东西藏在多层入口背后，用户未必意识到自己已经有一台。

沙箱与常驻电脑，是两代产品

Agent 的执行环境这几年走了三步：从只能对话，到能运行一段代码，再到拥有一台自己的电脑——可以装软件、打开网站、用用户的账号登录去操作。前两步里环境是附属品，第三步里环境成了产品的一部分，厂商的思路也随之从“帮你完成一次任务”变成“替你管着一台机器”。

常驻电脑与临时沙箱的差异，在使用中会具体到细节：环境从任务开始到结束一直保持运行，装好的 Skill、登录过的账号状态都还在，下次进来接着用；临时环境每次拉起都是另一个进程，之前的上下文无处可寻。Manus 早期的做法是每个任务分配一台电脑，任务结束即回收——环境有了，持久没有。这两种体验之间隔的不是参数，而是“这台电脑是不是它的”。

不过，“持久”并非所有产品的默认承诺。同为云端环境，Dots 的沙箱更严格：无法 SSH 连接、不允许安装第三方软件，还会频繁重启、重新分配；重启之后写入的内容是否完好，取决于各家实现，需要按版本逐一确认。选择把工作和数据放进哪种环境，持久性是需要单独验证的属性，不是品类固有的保证。

有了不下线的电脑，才有了新的任务类型

临时沙箱适合“跑一次”：给一个任务，等一个结果。不下线的电脑打开的是另一类任务——需要一直在场、按日程执行的工作。

一个被转述的用例来自一位做 Mac 清理软件的独立开发者：他把多平台的营销推广交给一台常驻的 Agent 电脑，定时访问欧美的小众论坛，让 Agent 判断每个论坛的调性——有的喜欢独立开发者讲故事，有的偏好知识性干货——再结合大家浏览的时间段发帖，他只需要提供内容。这类任务的关键不是某一次操作多聪明，而是环境可以一直挂着，定时触发、持续观察。

需要登录态的任务同样依赖持久环境。让 Agent 保持一组账号的登录状态，打开浏览器逐个试用一批产品并记录结果，前提都是这台电脑第二天还是昨天那一台。沙箱做不到，因为每次醒来都是陌生的。

成本：免费送不起的一代

常驻环境贵在时间。临时沙箱用完即毁，云电脑却要一直开着，成本结构因此完全不同：有的产品不设免费额度，进来就要付费，因为起一台虚拟机就是实打实的开销；也有公司以巨大的资源投入，为海量用户同时提供虚拟机和高额的模型用量，把这笔账算成长期入口的投资——Muse 是后一种，而它显然不是所有厂商都能复制的。

成本的差异也开始反映到产品分层上：有没有电脑、电脑是否持久，正在成为 Agent 产品定价与定位的依据之一。开放程度同样在分化——有的产品允许用户在手机上浏览云端虚拟机的完整文件列表、把单个文件下载下来，有的则把权限收得很紧。评估这类产品时，环境归谁控制、文件能不能拿出来，与它跑任务的能力同样重要。

硬件路线也在分化。除了 Linux 虚拟机，出现了用 Mac 整机提供服务的方式：厂商购置一批 Mac Mini，把 macOS 环境连同远程桌面一起接入 Agent。租用 Mac 环境本是一门老生意，如今被接进了 Agent 的执行层。

从一台云电脑到一组电脑

持久环境的第一阶段是一台云电脑：把常用的命令行工具和脚本克隆进去，人在外面用一句话让它查信源、做图、发内容，不必为连回家里那台常驻机专门搭一套通道。第二阶段正在出现：Agent 开始登记和管理多台机器——一台云端电脑之外，再加一台家里常开的 Mac Studio，任务可以落到其中任何一台上。

再往前，是管理一组机器。产品方的规划里已经出现让 Agent 管理整个公司、整个家庭的电脑的想法——这是规划，不是已发布的能力。个人侧的试验也在朝同一方向走：把若干台 VPS 的登录信息交给 Agent 统一管理，让它记录每台机器上跑着什么服务、重启挂掉的服务、在多台机器之间做容灾，相当于多了一个随叫随到的运维工程师。

这条路径的尽头也埋着新的问题。把冷备份交给 Agent 处理之后，备份落在哪个目录、出事时能不能恢复，交托的人未必清楚；管理权交出去越多，对环境的了解就可能越少。给 Agent 一台不下线的电脑，回答的是“任务结束还留下什么”；接下来的问题是，留下的这些东西，谁来清点、谁来负责。

有了公众号，为什么还要写独立博客？

Wed, 07 Oct 2026 16:00:00 GMT

整理一套 AI 信源时会出现一个明显的断层：海外主要的 AI 媒体、播客、公司博客和产品发布页几乎都提供 RSS；国内厂商的官方新闻和产品 Release Notes 普遍没有。有的更新甚至把日期写进标题，正文里连一个时间戳都找不到。对订阅器和自动化工具来说，这是两种完全不同的互联网。

这种差别不是技术能力问题。RSS 阅读器在中文互联网也曾经流行过，抓虾一类的阅读器兴盛一时，后来这一层开放基建被平台竞争消化掉了：内容各自圈进自己的 App，订阅失去了位置。微信公众平台的机制是一个典型——它提供原创保护，发布后别人不能照搬，在一个洗稿成本极低的环境里，这套封闭设计有现实的原因。代价是公众号内容几乎不向站外开放：做 RSS 订阅器的人遇到的最大障碍就是公众号无法订阅，想公开提供抓取服务还会带来合规问题。

独立博客过去输在哪里

从读者经济的角度看，独立博客长期处于下风，而且输得有结构上的原因。过去的读者经平台推荐流分发，独立网页没有自己的分发渠道，只能在搜索结果里排队；公众号背后是国内自媒体最成熟的盈利来源，而开放订阅一直没有找到自己的变现方式——Substack 一类靠 RSS 与邮件订阅的 Newsletter 是少数例外。开放在没有商业支撑的情况下收缩，是上一轮竞争的实际结果。

袁朝发的对比可以当作一个样本：他长期同时运营独立博客和公众号，同样一篇文章，独立博客的阅读量远不如公众号，于是难免怀疑，辛苦维护独立博客是否还不如只发公众号。如果读者只有人类，这个结论很难反驳。

Agent 成为新读者

Agent 的出现给这个问题加了一个变量，它改变了“没有分发渠道”这个前提。Agent 找内容不靠推荐流，只看内容是否可达：一个被反复提到的观察是，让 Agent 查某位只在公众号写作的作者的文章并总结风格，它找不到；换一位有独立博客的作者，它把整个博客读了一遍，风格判断也更有依据。原因不复杂——公众号内容在站外几乎不可检索，而开放网页可以被 Agent 抓取和阅读。Agent 一直在扫描开放内容，这件事不需要人类读者在场也会发生。

“让互联网和 Agent 认识我”，说的就是这种变化：开放的内容多了一批不需要人工操作的读者，它们不参加推荐流的分配，只认地址和格式。

需要说明的是，这目前还是个别的观察，不构成对流量效果的承诺。独立博客在搜索引擎排序中的位置没有因此改变，各家 Agent 如何索引和引用开放内容也仍在变化。把开放网页当成确定性的“AI 流量入口”，超出了现有材料能支持的范围；目前能确认的只是，开放的内容可被读取，封闭的内容连被找到的机会都没有。

用什么形式开放

如果接受“内容应该让 Agent 读到”这个前提，接下来的问题是形式。RSS 仍然是一个低成本的答案：它只是放在那里，任何订阅器或 Agent 都可以自己发现和读取。相比之下，把信源包装成一个 MCP 服务，反而要求使用者先完成安装，多了一道门槛。另一个设想是走公众号 API，把自己授权发布的内容自动同步成一份 RSS——这属于讨论中的方案，能否稳定实现取决于平台接口，不能当成现成能力。

无论选择哪种形式，边界都应该放在自己有权发布的内容上。发布在平台内的内容受平台机制约束，替别人把封闭内容转成开放订阅，超出了个人创作者该做的范围。本站的做法是把内容放在开放网页上：每期节目提供网页版和 Markdown 格式的文字稿，段落带稳定锚点，方便人和 Agent 引用；博客文章同样提供 Markdown 版本。这些都是站点自己有权发布的内容，开放的成本可控。

开放能否获得回报

开放内容在商业上能否成立，上一代互联网没有给出肯定答案：Web 2.0 时代同样有 RSS 标准和订阅习惯，最终因为没有赚起来而退场。这一代是否会不同——新一代更开放的创作者和服务能不能吃到某种红利——是一个还没有答案的问题。

对个人创作者而言，可计算的部分是：在自己有权发布的范围内维护一份开放网页，边际成本不高，而且它同时服务人类读者和 Agent 两类读取者。不可计算的部分是回报。给内容加一份 RSS 的倡议是否会被广泛响应、开放是否会在 Agent 时代重新变得划算，只能留给之后验证。

AI 视频里的故事、作者与观众

Mon, 05 Oct 2026 16:00:00 GMT

一个教育演示值得从远处说起：对着 AI 语音提问“人类是怎么从非洲走出来并进化的”，右边是语音在讲解，左边的画面实时生成、跟着内容变化；中途打断、换一个问题，画面立刻切换到新的主题。放在一年前，这类实时生成还是“像做梦一样”、没有明确主题的模糊画面；现在它已经有了节目的样子。

但这个演示回答的问题是“画面能不能跟得上话”，不是“内容值不值得看完”。把这两件事分开，才能看清 AI 视频现在走到了哪一步。

吸引眼球与讲完故事是两回事

实时生成的视觉冲击力，很大程度来自“画面随话语变化”这个动作本身。第一次看到会惊叹，第二第三次就会习惯——新奇感是一次性资源，撑不起持续观看。

值得看完的视频需要另一层东西。一部短剧或故事片里，音频、视频、每一帧转场是一个整体；把音视频拆开、各自转成文字标注，再交给模型理解，丢失的信息非常多，得出的编排也只能是平庸的。这也是为什么全模态理解模型会被认为是短剧编排和自动化广告的基础设施——它们不生成视频，但能把它当作整体来理解。

生成这一侧同样在发生转变。视频模型过去的比拼集中在单镜头：物理还原、提示词遵循、像素密度，看谁更真实。新的变化是不再只追求把一个镜头做到极致，而是一句话生成多个镜头、组成一个完整的故事。这与代码能力里观察到的变化是同一条线：模型从照指令逐条执行，变成理解意图、从全局安排——先有成片的构想，再落实每个镜头，而不是逐段产出互不相干的画面。

头部作品已经有了作者性

AI 短剧是目前最接近“内容”而非“演示”的形态。被观察到的情况是，短视频平台几乎每周都有爆款 AI 短剧出现，质量高到可以让人忘记它由 AI 制作。一个被提到的数字是，B 站头部 AI 短剧每周播放量能超过一千万——这是对头部作品的观察，不能直接推及全行业；大量低质填充内容同样存在，负责填量的“短剧工厂”与精品是两个不同的市场。

更值得注意的判断是：精美的 AI 短剧不该按传统短剧的逻辑去看，它更像头部网络小说——有自己的作者性和创造性，而不是单纯堆砌爽点。故事讲得好、能按稳定节奏（比如两天一集）连载的作者，被认为可以获得类似网文读者那样的付费观看。顺着这个判断推下去的“类似起点的短剧平台”、月票和按量付费机制，目前都还是设想——现有主流平台仍然偏机构化的投流逻辑，个体作者的回报方式并没有被验证。

观众侧的接受度倒是有一条明确的观察路径：早期 AI 短剧的“AI 味”让人厌烦，但点进去发现剧情尚可，AI 味就会被忽略。观众最终消费的是故事，生成技术只是介质。

一个事件，多种表达

表达能力的普及，在突发事件里最直观。平陆运河成为社会新闻的那段时间，同一题材出现了标准大片式的剪辑、动画风格的 AI 短剧等多种形式，各家的成片质量普遍很高——既有传统团队的剪辑、素材与叙事功底，也有完全由 AI 完成的表达。

半年前，这类事件的表达权还集中在少数有剪辑和素材能力的团队手里。这不是单个团队的进步，而是表达门槛整体下移。它附带一个新问题：观众的注意力是有限的，供给暴增之后，筛选和推荐机制承受的压力比创作者更大。

观众决定它走多远

低门槛解决的是“能做出来”，观众回答的是“值不值得看下去”。持续观看的数据比爆款更能说明问题：有的 AI 剧不算现象级，但数据稳定、一直有人看；稳定意味着可预期的观众和可预期的变现空间，这正是连载内容区别于一次性爆款的属性。

至于创作者的机会结构，目前存在方向相反的两种想象。一种是门槛降低让原本就会讲故事的人获得前所未有的回报——他们缺的从来不是能力，而是把故事变成画面的手段；另一种推想认为，当内容生产高度自动化，机会会向极少数能与 AI 协作的头部集中，普通创作者反而更难被看见。现有的观察既无法证实前者，也无法证伪后者。

能确定的只有两件事：爆款的出现不等于全行业的机会，把个别头部表现当成普遍水平会误判市场；以及故事质量和持续供给——这两样目前还没有被自动化的东西——仍然决定着一部作品能不能被追着看完。

软件做出来之后，还有分发这件事

Sun, 04 Oct 2026 16:00:00 GMT

开发一个软件、做一个 App 卖给别人，长期以来是软件生意的标准想象。这个思路在今天需要重新审视：当创作的门槛降到很低，“做出一个东西”本身越来越难构成价值，作品如何进入用户的生活——分发——反而成了真正的瓶颈。

这不是一个心态问题，而是一个结构性问题。创造的阻力已经基本消失，写一个工具、剪一段视频、生成一部短剧，成本都只剩时间和少量费用。但分发过程中的阻力一个都没少：找到愿意看的人、选对场合、把握时机、建立信任，每一环都还需要人来完成。

供给在涨，注意力没有涨

内容侧的变化最直观。AI 短剧几乎每周都有新的爆款，头部作品的播放量以千万计，质量也高到不能再按“低产能填充物”来理解。而另一边的观察是，这类 AI 剧里数据最健康的不是一夜爆红的那批，而是数据长期稳定、一直有人看的那批——稳定才有变现的可能，前提是它真的稳定。

供给和需求之间出现了明显的不对称：创造的数量在成倍增加，注意力、消费能力和消费者的数量并没有同步扩大。商业层面同样如此，资金集中在少数被验证过的赛道上，留给“先做出来再说”的空间并不大。

这个不对称决定了一件事：把作品做出来只是完成了一半，剩下的一半——让它被看见——不会因为作品质量高而自动发生。

分发正在变成可以拆解的流程

分发是否只能依赖天赋和运气？一个被转述的用例提供了另一种想象。

据转述，一位独立开发者让常驻 Agent 在一台独立电脑上运行，定时访问欧美的一些小众论坛，先让模型判断论坛的调性——有的论坛喜欢独立开发者讲故事，有的偏好知识性内容——再结合大家浏览的时间段决定发帖时机，他只需要提供内容本身，推广的是他自己的软件 Mole，执行的载体是 Grok Bot 这类常驻 Agent。

这个案例需要先说明它的性质：它在本节目中的呈现本身就是一次转述，来自一次线下见面后的复述，原始的推广效果、相关论坛的规则是否允许、社区对机器参与内容的态度，都无从核验。所以不能从它推出“自动发帖能带来增长”这样的结论——这一点没有任何证据支持，而且平台规则和社区规范随时可能构成硬约束。

它值得注意的地方在别处：分发被拆成了可执行的步骤。判断语境、选择时机、投放内容、等待反馈，每一步都有明确的输入输出。过去这类工作依赖营销公司的经验和人手，现在至少在一部分环节上，可以交给程序按流程执行。流程化不等于有效，但只有先流程化，效果才可能被衡量和改进。

用户买的是结果，不是软件

回到最初的判断：开发一个 App 卖给别人，这个套利思路今天已经不太成立。原因之一是工具类需求正在被用户自己用模型解决——既然能自己搭，为什么要买你的软件。

随之而来的区分是：工具、服务和实际结果是三件事。工具是用户需要操作的软件；服务是替用户完成的过程；实际结果才是用户最终关心的——问题被解决、内容被看到、事情被办成。分发恰恰是服务与结果的一部分，而不是软件交付之后的附属动作。AI 剧的例子同样说明这一点：真正积累价值的不是某一部爆红的片子，而是持续的供给和稳定的观看关系。

因此，分发值得被当作产品的一部分来设计，而不是发布当天的一次性动作。它有自己的约束条件：平台规则、社区文化、注意力的稀缺，都不会因为技术进步而自动放宽。

分发不会消失，只会换形态。真正有待验证的问题是：在供给过载的环境里，什么样的分发方式既能被流程化，又不会耗尽受众的信任。这个问题目前还没有答案，值得每一个做完作品的人接着想。

Token 用量之外，团队交付还有一道坎

Fri, 02 Oct 2026 16:00:00 GMT

模型这一侧的提速还在继续：新一代模型不仅生成更快，面对不同意见也更有自己的立场，会坚持论点而不是顺着用户改口。按理说，写代码这个环节被加速之后，软件应该更快做出来。

但一个流传很广的说法恰好相反：许多非技术岗位用上 AI 之后确实省下了时间，写代码的人反而更累了。累的原因不难推断——当单个任务的成本足够低，一个人会同时开更多的项目、尝试更多的想法，需要盯着的东西变多，出错的总量也在涨。提速发生在个人的产出侧，而软件真正到达用户，中间还隔着构建、测试、签名、审核、发布，以及让多个人的改动彼此兼容。这些环节大多不在模型的能力范围内，也基本没有跟着变快。

迭代速度是一种组织能力

从发现一个苗头，到把它做成能用的产品，这段路在不少组织里仍然漫长。一个直接的证据是：拥有最好的模型、最资深工程师的大团队，产品迭代速度却常常落在小团队后面。慢的原因不在模型侧，也不在人才供给——真正难以解释的，是同样的人员配置为什么产出完全不同的节奏。

有人把希望寄托在“用量”上：既然模型按 Token 计费，那就把用量拉满，让 AI 参与尽可能多的环节。但单纯堆高用量并没有换来相应的交付速度。讨论中把这称为 Token Maxxing，结论是它没用——各家公司都做了提效动作，真正的问题“组织到底怎么搞”仍然没有答案。用量衡量的是投入，交付衡量的是结果，两者之间缺的正是组织方式这一环。

协作架构是更难的部分

写代码可以由一个人完成，交付几乎总是需要一群人。人越多，协作就越难，这是一条长期成立的经验。

有两项值得注意的外部观察。其一，从外部看，OpenAI 的 Codex 团队规模不小，却维持着很快的迭代和较少的内部冲突，而另一些曾经很快的同类团队已经慢了下来。这种对比只能说明协作架构存在差异，其内部的具体做法并未公开到可以照搬的程度。其二，海外存在一类设计工程师：同时具备工程能力、设计能力和产品判断，AI 补齐了剩余环节之后，他们可以自己发版。这个角色说明的是闭环的价值——当一项工作从需求定义到最终发布由同一个人把握，交接成本就消失了。

需要强调的是，这两条都不是可以直接套用的组织处方。“每个人都应该成为全栈”不是本文的结论；它充其量指出一个方向：交付慢的组织，瓶颈往往不在个人能力，而在人与人的接缝处。接缝怎么重新设计，目前没有通用答案。

个人侧恰好提供了一个对照。一次使用 Codex 定时任务的体验里，任务好几天没有出结果，让 Agent 自查之后才发现，它在这几天里顺手修掉了几个展示 Bug。单个用户与单个 Agent 之间，闭环可以小到不需要任何组织。组织交付的难处在于，同样的闭环要跨越很多人，而每一个交接点都是一次可能的速度损耗。

判断交付，别只看用量

如果用 Token 消耗量、生成代码行数、调用次数来衡量 AI 带来的进步，衡量的都只是个人产出侧的速度。组织交付能力要看的是另一组指标：从想法到上线的周期有多长，发布环节是否顺畅，多人改动合并时冲突多不多，出了问题多久能修好。

这些指标目前很少被公开讨论，也更难被“用量”叙事掩盖。对正在把 AI 引入研发流程的团队来说，值得先回答的问题也许不是“还能给模型加多少任务”，而是“一个想法从提出到上线，现在要经过几道手”。这道坎不在模型的下一步更新里，而在组织自己的设计里。

用代码、图像和音乐做一支产品宣传片

Thu, 01 Oct 2026 16:00:00 GMT

一支产品宣传片通常意味着一支小团队：脚本、配音、配乐、动效、剪辑各管一段。现在出现了一条不同的路径——整支视频由程序画出来、写出来，乍一看却不像代码的产物。

线索从配乐开始。有人连做两支软件宣传视频，起初以为背景音乐是从素材网站找来的现成曲子——直到发现每支视频的音乐都不一样，而且都能卡在画面的节奏点上。追问来历，答案是 Python 写的。

音乐：先有乐谱，再有声音

以前让 AI 做电子音乐，结果往往是几个音来回重复，鼓点机械地铺在底下，一听就是生成的。这次的写法不同：模型先把音乐写成乐谱，再经 MIDI 转成音频。

乐谱是一种结构化表达，写谱对模型来说接近写代码——每个音符、时值和力度都可以被精确指定。这解释了音乐为什么能跟视频内容卡上点：节奏不是后期对齐的，而是在写谱那一刻就按视频的节拍设计的。声音跟着画面的结构走，而不是先有音乐再迁就画面。

音效也是同一套逻辑。在一支成片里，连打字的音效都落在 BPM 节拍器上——音效不是后期随手铺上去的，而是被当成时间轴上的一个元素来排布。声音层的每个组成部分都服从同一条节拍线，这是成片听起来“完整”的直接原因。

画面：材质、动效与整体编排

让观者“恍惚间不觉得是代码做的”的，是画面里的材质——蜡笔的质感、像纸张一样的噪点。这些通常出现在手工动效或视频模型的输出里，但在这里，每一层质感都是程序画出来的。

另一类常见做法是 SVG 动效：随着音乐生长的草，实际是一段贝塞尔曲线动画；一艘帆船以一镜到底的方式被一条条线画出来，周围的波浪也是用线生成的。这类画面单帧并不逼真，好看靠的是元素如何被编排——何时出现、如何转场、怎样踩住音乐。

编排能力也带来了取舍上的变化。有一个从代码库出发的案例：让模型基于现成的软件代码库做宣传视频，界面组件是已有的，它负责编排页面动作、写配乐、组织节奏，成片质量超出预期。模型厂商自己也在这样发功能视频——发布内容由模型制作，没有人专门在这上面花太多精力，视频却一期比一期丰富。

编排还改变了取舍：新一代模型可以直接从底层的图形库和音效库拼出整支片子，绕开上层工具；过去为宣传视频整理的技能流程反而帮了倒忙——同一任务套用旧的工作流模板，效果不如让它自由发挥。模板固化的是上一代模型的能力边界，模型变强之后，约束就成了负向优化。

图像模型仍在一旁被调用

这条路径不是“全部纯代码”。一个被完整观察过的案例里，制作者只给了脚本和音乐，模型自己选了贴纸风格，从零做出一支有剧情、转场完整的视频——过程中调用了图像模型生成图片，其余动画过程都是纯代码。分工大致是：图像模型负责那些凭代码难以凭空造出的具体形象，代码负责让它们动起来、并维持整支片子的节奏。

图像素材的可控修改同样是短板所在。此前的图像编辑有一个著名问题：拿一张参考图连续生成或修改十多版，画面里的人物会出现轻微偏移，慢慢变样。新一代编辑做到了“不动的东西完全不动”，改哪里其余一个像素都不带偏——但另一些区域会出现伪影、色彩渐渐发脏，离可用还有距离。对宣传素材来说，可预测的局部修改和生成能力同样关键，否则每改一版都要从头检查整张图。

好不好看，是体验判断

“八十分动效水平已经够接单”“跟人写的音乐没有区别”——这类说法都是看过成片之后的观感判断，不是跑分结论。它们传达的信息有限，但可以复核：把成片、提示词和制作耗时放出来，比任何形容词都有说服力。审美在这里不是玄学，而是一组能用眼睛验证的具体问题——质感像不像手绘、卡点准不准、剧情顺不顺。在看到更多公开成片之前，对这些作品的评价都应该停留在“体验报告”的层面，而不是能力评级。

组合出完整作品

回头看这支宣传片的构成：音乐来自乐谱，画面来自矢量动画和少量生成图片，结构来自整体编排。三种素材各有一条最适合的表达方式——声音用乐谱、图形用路径、关键形象用图像模型——再由代码把它们缝进同一条时间轴。

与前几代生成工具相比，真正的变化在编排这一层：它不再逐段生成互不相干的片段，而是像剪辑师一样，动笔之前脑子里先有成片，再决定每个元素何时出现。至于这条路能否稳定复现到每个项目，取决于素材类型和成片要求；可以确定的是，“全用代码做”从来不是重点，重点是每个部分都选对了表达方式。

AI 的记忆，需要一个完成按钮

Tue, 29 Sep 2026 16:00:00 GMT

你随口告诉过 AI 助手一件事，之后几天它反复提起。事情早已过去，或者早已与你后来的生活无关，提醒却停不下来。这不是记性太好，而是系统分不清三件事：哪些只是需要记住的信息，哪些是正在进行的目标，哪些是做完就该结束的任务。

一条记忆，一个目标，一件任务

生活里的事至少分三类。一类是记忆：住在哪里、孩子在读几年级、对什么过敏，这些信息长期稳定，不随周次过期，也谈不上“完成”。一类是目标：正在推进、有终点的事，比如准备一次搬迁、把一个慢性问题弄清楚，需要的是被持续追踪。还有一类是任务：明天交保险、下个月续签，一次行动，做完即结束。

这三类需要的对待方式不同，但把它们一起说给一个聊天框听时，系统往往只有一种处理办法：全部记下来。记忆被存住了，目标被存住了，任务也被存住了，而“这件事什么时候算完”没有存进去。一次产品讨论中提到的例子很典型：告诉助手一件事之后，它“天天跟你磨叨这事儿”，而磨叨的内容早已和用户后来做的事无关。信息没有错，错在它没有一个终止方式。

打勾是在告诉系统：这件事结束了

待办清单上的打勾，表面上是个动作，实际上是一条状态信号：这条关注可以关闭了。一项录制时的产品体验里，Muse 的页面把长期目标拆成列表，事情做完就打勾，打勾之后系统不再惦记这件事。

这个设计的价值不在多了一个清单，而在给记忆装了一个出口：相关的信息可以沉淀下来，但“关于这件事的提醒”应当有办法结束。没有这个出口，用户只剩下一种工具——反复用嘴澄清“这事不用再提了”，而每一次澄清本身又是新的上下文。

反过来说，很多被抱怨“记性太好”的助手，缺的不是更强的记忆模型，而是一个简单到几乎不值得设计的界面元素：一个能让事情从“正在关心”变成“已经结束”的按钮。

纯聊天为什么管不住待办

一次被记录下来的尝试是：放下滴答清单，完全用对话管理待办。一年之后的结论是什么都没管理好，又把清单软件用了回来。

失败的原因不在模型，在聊天的形态。对话是一条向前流动的流，说过的话沉进历史，翻找和确认都要费劲。做完没有地方打勾，没做没有地方排期，隔一天就想不起来昨天让助手做了什么。交互之后，人需要一份可以回看、可以复查的结果——这份结果必须待在聊天流之外的某个地方。最近笔记软件和待办软件反而重新活跃，与这个缺口有关：人们与 AI 交互得越多，越需要一个交互之外可以核对结果的界面。

便签的简单，泛化的难题

待办需求本身非常大众。一位 Google 日历前产品经理在交流中转述过团队的调研：美国普通用户最常用的工具不是任何日历软件，而是贴在冰箱上的便签。把日程排满日历是少数人的需要，大多数人的待办是“明天该交水费”这个级别，用不着方法论，也用不着复杂界面。

难点在于纯程序应付不了泛化。什么算“完成”、什么时候过期、事情改期了怎么跟进、一句话里哪些是任务哪些只是抱怨，规则很难写全；写全了的规则，遇到下一句稍微不同的话就失效。这恰好是模型可以补上的位置：把一句自然的话变成一条有状态、有终点、有出口的记录，再让简单界面负责展示和打勾。程序负责形态，模型负责理解，各做各的擅长部分。这是基于现有产品的方向推断，各产品实际能力以发布为准。

结束，不是遗忘

一个完成按钮解决的不是效率问题，是知情问题：系统终于知道这件事对用户来说已经结束。由此推导出的分层也清楚——信息沉淀为记忆，不设截止；目标挂着进度，随推进更新；任务打勾关闭，提醒随之停止。三者混在一个“记忆”里，助手就只能在所有事情上永远在线。

仍然待回答的问题是边界由谁划：用户打勾之前，系统能否先判断一件事真的做完了；有没有一些事，结束的方式不是打勾而是过期作废。完成按钮只是第一步，任务状态的管理才是它背后真正的产品问题。

一次授权背后的产品设计

Mon, 28 Sep 2026 16:00:00 GMT

让 Agent 规划一次去上海的行程：见谁、几点、在哪个地方。它需要调用地图服务，于是任务在这里停住——用户要去开发者平台申请一个 API Key，复制、粘贴、配置，回来任务才能继续。这类一年可能只用一次的连接，准备成本远高于任务本身，而大多数人会在这里放弃。

授权应该在需要的时刻出现

另一些产品把这一步挪进了任务中间。一项录制时的体验里，Grok Bot 需要读取谷歌邮箱时，界面直接弹出授权卡片，点一下就完成；Muse 更靠前，用户说“帮我总结下该干什么”，它问要不要连接 Gmail，“点确定结束了”。两者共同点是渐进式：需要的时候才展现，需要的时候才授权。

与此相对的是清单式的设计：连接器集中在商店或设置页里，由用户预先挑选、预先配置。问题不只是多几步操作。一个被指出的缺陷是，有些 Agent 甚至不清楚自己有哪些连接器——没连上时只会回答“我没有这个”，而不是提示可以连接。授权入口出现在哪里，决定了用户是沿着任务走，还是先修一段路再出发。

授权一旦顺畅，任务的形态也会跟着变。一项录制时的体验里，用户让 Grok Bot 挨个测试 Product Hunt 排名前十的产品，它真的打开浏览器，在拿到谷歌账号授权之后，逐一登录各个网站去执行测试。这类任务在清单式的授权流程下几乎不会被发起——光是为此准备权限就足以让人放弃。授权嵌入任务，带来的不是省几步操作，而是一类“以前不会开口提”的任务变得可行。

连接这件事，本身可以是一项服务

回到行程规划的例子：申请 Key、配置、乃至向地图服务付费，都可以由产品承担，用户用积分或订阅来交换。一次讨论中的说法是，为此多耗一些积分完全可以接受，为结果付费是自然的交换。任务的价值在结果，让用户为基础设施付出注意力，等于把最难的部分留给了最没有能力处理它的人。多数外部服务一年也用不上几次，为此准备一套配置，无论如何不划算。

顺着这个逻辑往前推是一个更彻底的判断：未来的产品里，MCP、Skill、Connector、Key 这类概念不应该再暴露给用户。这是一种观点而非既成事实，但它指出了方向——普通用户需要的是“事情办成了”，而不是一套集成术语。能力的呈现方式也在此列：同样一项能力，有的产品把它深藏在菜单之下，有的产品给它名字和入口，可发现性完全不同。

减少步骤不等于减少知情

渐进式授权容易被误读成“少授权”或“自动授权”。上面的体验里没有一步省掉了确认：卡片仍然弹出，按钮仍然要点，用户仍然知道 Agent 将以什么身份访问哪个服务。被压缩的是准备成本和术语学习，不是决定权。

这一步恰恰不能省。授权越轻、越频繁地嵌入任务，每一次授权就越需要让人看清自己同意了什么。一个始终要点一下的流程，同时是一次始终可见的告知；把它简化成静默放行，省下的几秒钟会以信任为代价偿还。判断一个产品是否做对了这一段，标准不是步骤数，而是用户在授权时是否清楚发生了什么。

把连接成本计入完整服务

一次授权只是几秒钟的事，但它决定任务能否一口气完成。完整的个人 Agent 服务因此不止是模型能力加运行环境，还包括与外部世界的连接：用户说出一件事，产品负责打通途中所有的关口。评价这一段体验的标准也很具体——数一数一次任务被中断几次、中断后要多久才能继续。授权这一步的产品设计，最终就是用这个数字来计分的。

本地推理的价值，不只有省钱

Sun, 27 Sep 2026 16:00:00 GMT

两台同名设备的用法可以完全不同。一台 128GB 内存的桌面主机装着开源模型，当成本地推理机；另一台 32GB 的同系列设备从不跑本地模型，只当一台常驻的开发机，从买回来就没关过机。录制时的这两个个例说明，“买一台常驻电脑”和“用它跑模型”是两个决定。常驻设备也有自己的约束，但这些约束与模型无关：内存更小的机型在重负载的工程任务上容易触顶，散热先于算力成为瓶颈。讨论本地推理值不值得，最好把混在一起的需求逐项拆开。

省钱这笔账，多数人算不平

本地推理最常被提起的理由是省钱。一次极端测算的结论是：一台高端桌面设备如果每时每刻都在跑模型，大约两年能回本；普通人的实际使用频率下，回本周期要以十年计——因为设备不可能一直满负荷。单纯按省下的 API 费用计算，自建对个人几乎总是不划算。

厂商的算法不同。当请求量足够大，把一部分任务挪到用户设备上反而更省：录制时有厂商在浏览器产品里内置本地模型，装好后自动配置，让特定任务在端上完成；浏览器厂商也长期内置可在线下载的小模型。端侧算力对个人是昂贵的闲置资产，对平台却是分摊成本的抓手——同一套设备，站在两边看，账完全不一样。

能跑什么，由显存和量化决定

本地推理的第一个门槛是显存。参数大一点的模型塞不进单张消费级显卡，多卡方案的成本和复杂度又超出个人范围。量化因此成为关键：录制时流传的一个案例，是对一个 27B 模型做三值量化，体积缩到约 5.6GB，宣称保留 98.2% 的综合性能，能在单张显卡上运行。这类宣称数字来自厂商自己的评测，放到具体任务上是否成立，仍需复测；速度也一样——有使用者在自己设备上跑到每秒约三十个 Token，得出“已经能用”的结论，这是特定设备、特定模型下的个例，不是普遍基准。

参数规模的判断同样随时间变化。录制前后的一波 Flash 档开源模型，让桌面设备的可选项明显变多：有使用者在一台大内存设备上依次试装了好几个开源模型，从中等参数的系列到新款 Flash 档，得出的结论是本机跑得动、速度可以接受。这也意味着本地推理的可行性清单需要定期重算，旧的结论不能直接沿用。

有些价值折不进回本账

只按省钱计算，会漏掉本地推理真正的差异点。数据不出本机：涉及个人记录、私密文件的任务，不必上传给任何服务。离线可用：网络中断或服务下线时，本地的模型和流程照常运转。控制权：自己决定何时升级、何时替换，不受厂商调整影响——云端模型的版本和定价随时可能变化，本地权重不会。

这三项价值高度依赖具体的人和场景。处理敏感数据的职业、网络环境不稳定的场所、对依赖单一定价的顾虑，都会改变天平的位置；对没有这些约束的使用者，它们几乎不值钱。云端模型还有生命周期问题：推理效率提升促使厂商持续下架旧版本，依赖特定版本的工作流随时面临迁移；本地权重不受这类安排影响。这也是为什么同一笔回本测算，不同的人得出完全不同的结论——差的不只是电价，还有这些折不成钱的因素。

端侧和云端是分工，不是替代

本地推理也不必承担所有任务。更现实的分工是：软件里那些机械性、高频的日常操作——整理文件、改个名称、做一次分类——交给端侧的小模型；创造复杂系统和产品的重活，继续留在云端的大模型上。设备常驻在线的价值同样在这里：它随时待命，承接那些不需要顶级智能但要立刻响应的请求。

值得注意的是，常驻执行环境本身正在变成一门独立的生意：云端常驻主机的需求被认为会随 Agent 普及而快速增长，Agent 需要一台“不下线的电脑”，但这台电脑可以租，不必买。对本地的取舍因此更清晰——把隐私、离线、控制权这些非价格价值放回天平，再决定哪些环节值得留在自己手里。

Jev 能用来做什么？把判断交给模型，把结果交给程序

Fri, 25 Sep 2026 16:00:00 GMT

三百多条记忆留在一个 AI 助手里，哪些值得保留，哪些只是已经过时的琐事？让模型写一篇总结，并不能直接完成清理。程序最终需要的是每条记忆的取舍依据：一个分数，或者一个保留与删除的判断。

Jev 所面向的，正是这一类任务。选择、评分、是非判断，都可以成为后续程序直接使用的结果。在一个已经能够理解需求、规划步骤的 Agent 里，这种能力可以承担更细小、也更频繁的一部分工作。

从三百条记忆到一万个好友

一次针对 Cola 的试用，把三百多条记忆交给 Jev 打分。模型整理出了约十八条它认为比较重要的内容，更倾向于保留抽象信息，对零碎琐事则更愿意舍弃。

这个结果提供了一种观察模型的方式：它如何理解“重要”，是否符合记忆主人的需要。十八条是这次筛选的结果，并不是经过评测得出的最优数量。

另一个试验的规模更大：根据聊天记录和共同群组，为约一万名微信好友打标签。候选标签有二十多个，涵盖 CTO、创始人等身份，一个人可以同时符合多项。

任务最初被设想成一次返回多个标签，后来改成逐项判断：是否符合第一个标签，是否符合第二个标签，依次执行。一个多选问题，被拆成了一组是非题。

这种拆法让任务更贴合模型的输出形式。不同好友、不同标签之间没有依赖顺序的判断，可以并行发起，不必等上一项完成才处理下一项。模型负责给出结果，程序负责调度和汇总。

截至这次试验被记录时，一万名好友还没有全部处理完，与其他小模型的对照也没有完成。这个案例已经展示了任务拆分的方式，准确率和完整处理耗时则仍待验证。

高频判断才容易放大收益

给好友打标签只是其中一种用法。扫描每天的聊天记录，找出待办事项和重要信息，同样包含大量重复判断；给联系人按规则评分、辅助整理好友列表，也有类似的结构。

这些任务的共同点是数据量大，而且同一种判断需要执行很多次。单次调用的时间和成本，才会在反复执行中积累成可感知的差异。

反过来，如果某个环节只占总工作量的 1%，即使将它的开销减少 90%，整体也只改善了 0.9%。把工作流里偶尔发生的一次调用换成更快的模型，未必值得为此增加一套接入逻辑。

选择场景时，值得先看清楚判断发生在哪里、一天发生多少次，以及它究竟占了多少开销。记忆筛选便于观察模型的取舍，批量标签更适合检验吞吐量，两者不必用同一把尺子衡量。

返回结果，不等于判断正确

结构化结果解决了程序如何接收答案的问题，但答案是否可信，还需要另一层验证。

一个分类结果可以完全符合格式，却把人分错类别；一个分数可以稳定返回，却不符合使用者对重要程度的理解。程序不再需要为格式错误重试，不代表它可以省去对判断质量的检查。

因此，关于“没有幻觉”的表述需要谨慎理解。若承诺针对的是输出形式，就不能把它扩展成所有答案都正确。好友标签任务最终仍要回到具体问题：哪些人被标错了，哪些标签容易混淆，错误是否影响后续使用。

这次试用所依据的资料还列出了多跳推理、复杂指代、计算与日期处理等限制。一个问题如果需要绕几层关系才能得出答案，就不能仅凭输出简短，把它当成简单判断。无关上下文也可能干扰准确率，前置清理与信息筛选仍有作用。

在现有 Agent 里安排好它的位置

实际接入时，可以先让现有 Agent 阅读模型资料，再结合具体场景搭建原型。但原型能运行之后，还要处理请求类型、调用方式和现有工作流之间的差异。

一个独立演示只需证明某种用法可行，日常工作流则要反复处理真实数据。模型在哪一步被调用、返回什么、结果如何进入下一步，都需要明确。

这也决定了 Jev 值得尝试的位置：规则很难写全、需要语义理解，又要高频执行的判断环节。复杂推理可以继续交给其他模型，确定性的计算可以继续交给程序。至于某一步是否值得替换，应该由这一环节的质量、速度和接入成本共同回答。

从记忆打分到好友标签，真正需要验证的始终是具体任务。能返回一个分数只是起点；这个分数能否帮助程序做出更好的取舍，才决定它能不能留在工作流里。

用 Agent 为什么开始想买带鱼屏？

Thu, 24 Sep 2026 16:00:00 GMT

网页占一块 16:9 的区域，旁边再放下聊天和会话列表。这是一个很具体的工作界面设想，也足以让人开始考虑一块 5K 带鱼屏。

需求来自 Codex 内置浏览器的使用：网页仍然需要足够的显示宽度，对话也需要留在眼前。当浏览器和 Agent 共用一个窗口，过去主要留给网页的空间，就要重新分配。

屏幕变宽，确实可以把这些区域同时摆出来。但工作界面是否顺手，还取决于窗口会在哪里出现，以及眼前这些网页如何与正在做的事情关联。

网页和对话开始争夺空间

独立使用浏览器时，网页可以占据大部分窗口。加入聊天区和会话列表后，如果希望保持原来的网页宽度，就需要在两侧增加空间；如果总宽度不变，就得压缩其中一个区域。

在这样的布局里，宽屏有了很明确的用途：一边查看网页，一边与 Agent 对话，减少反复切换。这解释了为什么使用软件的变化，会引出购买显示器的念头。

不过，把所有区域一直摊开，也会让界面显得拥挤。相关使用反馈中，既有想增加屏幕宽度的需求，也有对区域占地方、窗口反复拆合的不满。它们反映的是同一个界面在不同使用方式下的取舍。

对于需要同时查看网页和对话的工作，更多横向空间可能有用；如果工作过程中频繁改变窗口组合，宽度就只是其中一个因素。

窗口出现的位置，需要可以预期

比空间不足更打断操作的，是点击之后不知道网页会出现在哪里。

这次体验中出现过两种情况：网页有时进入侧边浏览器，有时又弹出独立窗口。合并与拆开的状态也会变化。用户既要处理页面上的内容，又要重新寻找窗口、理解它与当前会话的关系。

这种问题不会随着屏幕变宽自动消失。带鱼屏可以容纳更多区域，窗口行为仍然需要稳定。每次操作的结果能够被预期，空出来的空间才容易被利用。

因此，评估这样的界面，除了看能否同时摆下网页和聊天，还要看打开链接、切换页面时，工作能否顺畅地接着进行。

标签页应该跟着哪一项工作走

浏览器进入 Agent 后，标签页与项目之间的关系也值得重新考虑。

如果一项工作已经有自己的项目和会话，相关网页却仍然散落在另一套标签页列表里，用户就需要自己维持两者之间的联系。把浏览器放进同一个应用，只完成了界面上的靠近。

更进一步的设想是，让标签页与项目联动：切换到某项工作时，相关对话和网页能够作为一组内容被找到。项目提供组织方式，标签页保留实际页面，两者共同组成这项工作的上下文。

这里讨论的是一种工作空间设计，而非当时已经具备的完整功能。它的价值在于减少两套管理方式之间的割裂，让网页跟随任务组织，而不只是多占一个可见区域。

这与增加屏幕宽度可以同时发生。宽屏让更多内容同时可见，项目联动让这些内容彼此有关。空间和组织方式都到位，浏览器与 Agent 才更容易形成连贯的使用体验。

从浏览网页，到围绕任务组织网页

浏览器加入 AI 助手，与 Agent 加入浏览器，有不同的出发点。

前者从既有的浏览习惯出发，在网页旁增加提问或辅助操作的入口；后者从任务和对话出发，把网页作为完成工作时可以打开、查看和操作的内容。

两条路线都可能把网页与聊天放在一起，但界面的组织重心有所不同。对于以任务为中心的使用方式，项目、会话和标签页能否协同，比单独增加一个聊天面板更值得关注。

独立浏览器也仍有自己的使用场景。看视频、刷信息流、阅读文章，并不都需要先建立一个任务。任务中的网页操作，与日常内容消费，可以保留不同的入口。

带鱼屏的念头因此提供了一个具体的观察角度：Agent 的能力进入日常使用后，连屏幕上应该摆什么、放在哪里，都开始发生变化。网页、对话和任务可以共处一屏，接下来的产品问题是，如何让它们也属于同一份工作。

语音识别已经很准了，为什么输入还是不顺手？

Wed, 23 Sep 2026 16:00:00 GMT

一个自己搭转写环境的人，对语音识别的进步有直接的体感：新模型识别专有词汇的能力更强了，处理口语也有提升，而语音方向被认为还留着不少低垂的果实，因为大多数优秀人才都去了语言模型那边。识别这条线确实在变好。

但换到日常输入，情形并不对称。同一段时间里，网易有道等新玩家接连进入这个品类，一个人桌面上却可能同时留着两三款语音输入工具，装上又卸掉。准确率之外，摩擦到底在哪里？

语音工具和输入法绑在了一起

语音输入产品有两种形态：一类是独立软件，一类住在输入法里。两种形态本来各管一段，麻烦出现在越界的时候。

一次手机上的试用是这样的：豆包的语音能力不错，但它把语音和输入法绑在一起，输入法本身的词库、联想还没有做好。用户只想用它的语音部分，打字却连续出错，错了几次之后，想到的不是反馈问题，而是卸载。

这种体验把一个选择摆在了用户面前：语音工具究竟是替代输入法，还是补充输入法？一种务实的答案是按品类各留一个——输入法负责打字，独立软件负责语音，不追求三合一。当用户需要用“留几个”来管理这类工具时，说明产品之间的边界还没有清晰到让人只留一个。

专有词库是识别之外的一公里

模型侧的进步能减少识别错误，但人名、项目名、行话这类专有词汇，往往还是要靠词库兜底。这里的产品缺口反而更明显：微信输入法的语音识别能力已经够用，唯独不支持自定义语音词库。这个功能如果补上，桌面上Typeless这类独立工具对许多用户就不再是必需品。

专有词汇于是成了两条路线的竞争：模型继续进步，从源头减少纠错；或者产品开放词库，让用户不必等模型。目前来看，后者更便宜，也更快，但它恰恰是许多产品没做的那部分。

文字什么时候出现，整理到什么程度

一款语音工具被装上就卸的另一个原因，是说话时看不到字：说了两三分钟，屏幕上什么都没有，全部内容一次性吐出来。对说话的人来说，看不到实时反馈就意味着不知道识别有没有跑偏，长句说到一半发现错了，也只能从头再来。

不过，实时显示并非所有人的硬性要求。当有人抱怨这一点时，另一些用户的第一反应是反问自己常用的工具是不是也这样——他们并没有把这条当作主要痛点。同一个人群对“整理”的偏好分化得更明显：重度用户离不开长文本优化，希望去掉车轱辘话、重新排版；同一类功能在别的工具上，要么被认为做得过猛，要么只做最基础的整理；也有用户觉得各家在转写层面已经差不多，长文本能力没有本质差异。

整理没有统一的标准答案。润色不足，文本还要手动返工；润色过猛，又会替说话人做主、改变原意。这更接近一个应该做成可调的参数，而不是产品替所有人选定的某一档。

手机先卡在系统这一关

电脑上的摩擦是产品层面的，手机上则先卡在系统层面。在 iPhone 上用第三方输入法的语音，需要在设置里来回切权限；改成常驻启动，又带来另一种顾虑。逐次授权和常驻后台都被认为难以接受，最终的结果是一部手机上干脆没法用语音输入——已经习惯开口输入的人，换回 iPhone 会下意识按出错误的操作，然后发现输入框在跳转。

应用内的入口因此成了绕开系统的路径。聊天应用自带的麦克风按钮是许多人在手机上最高频的语音输入方式；电脑版后来加上的长按鼠标说话，也被认为符合直觉。这类入口的问题不在交互本身，而在细节：反复出现的使用提示会让人厌烦。入口的门槛低一分，使用频率就高一截，这是输入法之外的产品自己挣来的位置。

摩擦清单决定谁能留下

把上面的摩擦放在一起，可以看到语音输入的竞争早已不在识别准确率上：词库开放与否、文字是否实时出现、整理力度是否可调、系统权限是否绕得开，每一项都在决定用户留下哪一款、卸载哪一款。

这些问题几乎没有一个需要新技术来解决。它们需要的是产品把选择权交回用户——允许只用语音而不绑架打字、允许自定义词库、允许边说边看、允许调整整理的力度。识别已经够准了，剩下的部分，比拼的是谁先把摩擦拆掉。

图标、配图与出版：AI 生成矢量图的用途

Tue, 22 Sep 2026 16:00:00 GMT

把一张 AI 生成的图片放大几倍，边缘就开始发糊。屏幕上看还可以，一旦进入图标、出版印刷和大屏展示，糊掉的边缘就是废稿。这些场景需要的从来不是“一张图”，而是一组用曲线描述、可以继续编辑的图形——也就是矢量图。

图像生成模型输出的是像素阵列，矢量图形走的是另一条路：SVG 这类格式记录的是路径和形状，放大不失真，每个锚点、颜色随时可以单独修改。生图模型再强，也改变不了输出是像素这个事实。矢量图的生成于是成了一个独立问题。

画一个小图标有多难

界面上常见的 SVG 图标，画起来比看起来难得多。在 Figma 里几十像素见方的画格中，要用钢笔工具逐点勾勒贝塞尔曲线，或者用基础形状切割、做布尔运算。熟练工会快一些，但擅长画图标的人很少——一次被提到的经验值是，二十个图标要画一天。

难点来自尺寸和容错。图标只有几十像素，几像素的偏差已经清晰可见；曲线的弧度差一点，整个字形就歪了。它不像插画那样靠整体氛围容错，而是要求每一笔都精确。更麻烦的是，图标很少单独存在——一套图标共享网格、线宽和圆角规则，改一个就要顾及整组的一致性。这些约束没有一样能靠“画得像”解决，全部落在路径层面。

这正是为什么图标工作难以被生图模型顺带完成：像素输出给不了可调整的锚点，重生成一次，风格就偏一次。贝塞尔曲线和布尔运算才是这套工作的基本词汇，而它们恰恰是代码最擅长操作的对象——路径就是数据，坐标、弧度、组合关系都可以被程序读改。

通用模型在这个任务上的表现一直不算好。日常使用的界面图标，让大模型画，常常形状立不住、细节糊成一团——这是使用中反复出现的观察，不是评测结论。

专用模型演示了什么

一个专画 SVG 的模型（Arrow）的演示给观者留下了深刻印象：一幅鹈鹕骑自行车的图，羽毛一笔一笔勾勒得极细，自行车轮子的辐条夸张而密集，细节密度远超现场对比的通用模型。像“比所有模型强一万倍”这样的评价，是观感上的夸张，不必当真；能确认的部分只是，演示里它对笔画和细节的控制明显超出了大家看惯的水平。

至于它是否全面强于通用模型，目前只有演示，没有系统比较。这个判断应该留给可编辑性和输出质量的实际样例。倒是另一种走向值得考虑：这类能力可能被前沿模型吸收，成为通用能力的一部分——此前已有模型用代码把一张照片描成线条版的先例。专用模型的生存空间取决于成本（参数不大、训练成本不高），以及它能否在设计工作流里占据一个稳定的位置。需求侧确实有迹象：一批面向设计、想替代既有设计工具的 AI 产品正在出现，它们对可编辑矢量素材的供给有真实需求，这可能是专用模型保持独立形态的商业理由。

从图标到出版配图

矢量图的价值不止于图标。出版印刷是最挑剔的场景：付印的配图要适应不同版式和纸张，放大到任意尺寸都不失真，事后编辑还得能改细节。用图片生成做书籍配图并不靠谱，矢量图才是这个行业的母语。

把文本自动转成矢量图的尝试已经存在。一个叫 Napkin 的服务可以把选中的文本转成示意图，但版式相当有限。如果矢量生成模型成熟到可以广泛应用，出版印刷的配图方式会有想象空间——就目前而言，这仍是设想，没有被实际验证。

大屏展示是另一个自然场景。从手机图标到会场大屏，同一套图形要覆盖的尺寸跨度越来越大，可无限缩放的矢量格式是唯一不用重画的方案。

融入工作流的形态

单独为画 SVG 配一个模型，对多数使用者来说并不现实。更顺理成章的形态是以接口提供——比如 MCP 或类似的技能调用，让现有的 Agent 在需要图形时随取随用。一个具体的缺口在演示文稿生成：现有的技能会调用图标库应付常见需求，要画更丰富、更贴合内容的图形时，图标库就不够用了，定制生成恰好补上这一段。

图标库不足时的定制、设计类 Agent 缺少执行环境的问题，是同一个需求的不同侧面：设计工作需要的不只是“生成一张图”，而是生成之后还能改、能进版式、能和其他素材排在一起的完整流程。判断这类模型有没有用，最终看两件具体的事：输出的 SVG 是否干净可编辑，以及在真实版式里经不经得起放大和修改。这两个问题，目前都还等着更多实际输出的样例来回答。

把真实任务放进模型评测

Mon, 21 Sep 2026 16:00:00 GMT

同一个背景调研任务——把几个人在全网的信息各搜一遍——交给两个不同的运行框架，结果相差很远：一个找找就停了，按使用者的估计只有二十分水平；另一个连人工都不容易找全的公众号文章，都能搜到并完整拉回内容。这是录制时的一次个例，却指向评测中常被忽略的事实：决定结果的不只是模型，还有模型外面那层东西。

评测对象：模型加框架的组合

运行框架正是这层东西。录制前后出现的一份编程运行框架评测，比较的就是任务完成率和 Token 成本：把不同框架放进同样的任务，看谁用更少的消耗把事情做完。结果里，同一个模型换个框架，花费可能差出一截；效率高的框架不靠堆功能，反而以提示词更轻、只配备必要工具取胜。

这提醒读者，引用任何评测时，读到的都应该是“某个模型加某个框架在某类任务上的表现”，而不是“某个模型有多强”。框架的提示词多少、工具配置、架构轻重，都会写进最终成绩。脱离使用方式谈模型能力，就像只看发动机参数评价一辆车。

被感知的能力，不代表全部能力

面向公众的模型评测还有一个绕不开的约束：普通用户只能对看得见的东西有感知。于是评测演示越来越卷 3D——它足够复杂，过程和结果都一目了然；某代模型发布时，多项公开评测分数已经接近满分，社区转而用 3D 建模和 3D 小游戏来分辨高下，一次游戏扩展只用掉订阅额度的一小部分。

这类演示有价值：它把抽象的能力差异变成了可以亲眼核对的东西。但它衡量的也是被刻意感知的部分。一个模型 3D 演示出色，说明它在专门强化的方向上投入了训练，不说明写作、检索或长任务执行同样出色。演示是被选择过的能力切片，切片之外的部分仍需要用真实任务去补。

出题的水平，决定分数的含金量

模型厂商会针对公开评测做优化，这已是公开的秘密。讨论中提到一个例子：一个编程评测发布新版本后，各家模型在旧版本的题目上都表现很好，到了没被打榜过的新题上成绩明显下滑，只有个别模型在新旧版本上保持稳定。分数稳定与否，比的其实是出题与打榜之间的时间差。

因此，看评测时值得多问一句：这套题发布多久了，被针对性训练过没有。在新鲜题目上的表现，比在流传已久的题目上的高分更有信息量。

不同能力，需要不同的题

评测不是一场考试，而是按能力分别出题。录制时的体感里，写作和编程几乎对应两批模型：编程榜上领先的模型，写作未必好；一些写作被认可的模型，靠的也不是总分。写作好的模型被整站替换进内容生产流程，检索能力强的框架被留下来做资料调研——各自对应不同的测试任务。

厂商宣称的数字同理。一个量化后的小模型宣布保留了原模型 98.2% 的综合性能，这个口径是厂商自己的评测结果；它是否成立，要放到使用者自己的任务里复测——同一个模型，在你的数据、你的提示词、你的验收标准下，可能表现得更差，也可能更好。

排名的保鲜期越来越短

静态榜单还有一个正在失效的前提：模型版本稳定。厂商先发 Preview 试探口碑、用日期代替版本号、宣布线上持续更新的做法越来越多，有的模型默认一周更新好几次。版本号消失后，榜单失去了固定的评测对象——没法针对某个版本说它烂，反过来也没法说它好。

排名过时得快，替代的验证方式反而更直接：免费试用让每个用户都能低成本形成体感，社区里真实使用者的反馈比榜单更快暴露问题。评测没有消失，而是从少数机构的手里，分散到了每一次真实使用里。

阅读模型信息的可行方式因此变成：先明确自己的任务是什么，再找最接近它的测试或试用，把榜单当成线索而不是结论。评测的单位终究是任务，而不是模型名字。

让 AI 做游戏，先把世界拆成场景

Fri, 18 Sep 2026 16:00:00 GMT

让 AI 建一个“完整的星球”，听起来顺理成章：游戏里不是有一颗星球吗？一次真实尝试的结果是，额度大量消耗，星球却没有建出来。问题不出在模型不够强，而出在任务本身被描述错了。

星球不是一整块建模

游戏世界从来不是按真实尺度建造的。在那次尝试里，需求是“把星球上的建模都建出来”，但游戏实际的实现方式是工程化的：外面是一个星球，玩家进入时播放过场动画，然后加载当前的一个区域，区域有边界。完整的视觉印象，由一个星球外壳加上里面五六个场景拼成。

要求模型按真实星球那样的面积去建模，AI 做不到，人也做不到。任务是“造一颗星球”，还是“做一个由分区加载组成的游戏世界”，规模相差几个数量级——前者在物理上就不可行。任务描述直接决定了任务规模，也决定了它有没有解。

需求错了，代价不只是做不出来。同一时期的使用观察里，一类常见的抱怨是两百美元的订阅额度一周耗尽，做出来的东西还不符合要求；背后的原因正是要求太多、对要做的东西缺乏概念，还有人沿用“你是一个某某”式的提示词模板，用大量文字去规定模型本不需要被规定的部分。

与之对照，另一次使用的消耗小得多：一个 Roguelike 小游戏先花了额度的 3%，再扩展成吸血鬼幸存者那种一直刷怪、不断升级选武器的无限玩法，又用了 2%。5% 的额度对应的是边界清晰、可以分步描述的任务。需要说明的是，订阅额度的百分比不是通用的成本单位，它取决于订阅档位、模型定价和具体任务，换算不出“做一款游戏要多少钱”；它能说明的只是相对规模——同样是让 AI 做游戏，任务表达不同，消耗可以差出很多倍。

给模型一段能写代码的接口

表达方式之外，工具接口也在影响这类任务的成本。

这次 3D 建模表现出色的一个原因，是Blender 过去几年积累的脚本基建。模型建模时用的不是在图形界面上点选，而是 bpy——Blender 自带的 Python 接口。它一直在写代码，界面停在欢迎页没有任何动静，过一会儿告诉你建好了，打开一看模型已经完成。过程中几乎不需要截图确认结果，Token 消耗很低。

游戏引擎也有类似的东西。Godot 引擎同样提供程序化接口，模型做完直接打开就能看到结果，省掉了操作界面的整个过程。对模型来说，用代码描述几何、灯光和场景，比在图形界面里逐步点击更精确，也更省。

这提示软件的一个调整方向：把核心能力做成模型可以直接调用的代码接口，界面留给人看交互和内容。当然，这条路依赖软件本身有成熟的脚本接口，不是每类工具都能照搬；图形创作类软件里，操作界面本身仍是表达的一部分。

从数字模型到实物（延伸）

3D 建模的下游连着 3D 打印。以前打印用的模型基本来自社区，别人建好的模型不符合要求时很难修改：有人做过一个把 iPhone 变成闹钟的充电卡扣，模型是按 iPhone 18 做的，想改成自己的机型几乎改不动。建模能力接上之后，这类修改可以交给模型完成，打印机的配套软件也可以通过操作电脑代为使用，上料、支撑这些过去要专门学习的操作门槛随之降低。

不过建模成功只是第一步。材料、支撑结构、打印参数，这些实物环节仍然决定最终能不能打出来、打出来像不像。从数字模型到物理成品之间，还有一段需要动手验证的距离，建模顺利不能默认打印顺利。

一期播客的 Agent 工作流：从录音到多平台发布

Thu, 17 Sep 2026 16:00:00 GMT

做一期播客，最耗时间的往往不是说话。录音软件要启动，音视频要剪好，五个平台各有各的上传流程，网站还需要一份可检索的文字稿。这些环节里没有一行代码，过去每一件都要人去点。

这是一期节目从录制到发布走过的实际路径。需要先说明的是，它是一次回顾性的经验整理，不是一份操作教程：工具、界面和平台的规则都在变化，单个案例也不构成可复现的配方。它能说明的是，Computer Use 补上了哪些环节，又把什么留给了人。

写代码之外的环节，过去全靠人点

Agent 进入日常工作后，写代码这件事本身已经高度自动化，问题出在前后两端：录制要打开本地软件，发布要操作一堆不熟悉的后台。这些步骤无法通过写代码完成，只能停下当前任务，切换成人工操作。流程被打断的时间，几乎全部消耗在这里。

一次实际的做法是直接把电脑交给 Codex：启动录音软件这样的事，不再自己研究菜单在哪里，而是由 Agent 去移动鼠标、点击完成。剪辑同理——图形界面的剪辑软件用不顺手时，改用 FFmpeg 的命令行处理，反而落回 Agent 本来就擅长的工作方式。同一批体验里，还有人把两个 iOS 应用和 Obsidian 插件的上架资料逐项提交，全部交给 Agent 完成，自己只做验收。

这类委托的价值在于取消切换。任务不再因为“这一步不是代码”而中断，人也不必为每个软件重新学一遍操作。

五个平台，一次发布

第一期节目要上五个平台：小宇宙、B 站、Spotify、Apple Podcast 和 YouTube。负责发布的人此前没有用过其中任何一个平台的创作者后台，也没有逐一研究各平台的功能差异，只提出需求、准备素材，上传和填写由 Agent 完成。

这种做法改变的不只是时间。一个人维护五个平台，过去意味着五套各自的手续；每接入一个新平台，成本都会再涨一次。当操作本身可以委托，平台数量就不再直接等于工作量，选择上哪些平台时可以更多考虑受众，而不是操作成本。

值得注意的是成本结构的另一面。这次发布和网站搭建，用的是当期刚发布的新模型——单价更贵，但试错的次数明显减少，一次就做对的概率更高，总的开销反而可控。模型省下的 Token 和省下的人时，最终是同一件事。

网站与可检索的文字稿

发布之外，网站承担了另一部分工作。每段文字稿带稳定的锚点，文本里出现的关键词可以点击、聚合到同一个标签下，听众从任何一段话都能回溯到出处。这类功能在通用播客产品里并不常见，定制开发的门槛过去很难跨过；这一次，网站连同发布一起被列进了同一份委托列表。

对一期播客来说，可检索的文字稿意味着内容可以被单独引用。文章讨论某段对话时，可以直接链接到确切的段落，而不是笼统地指向一期节目——本文末尾的链接就是这种用法。

一次没有答案的限流

流程也不是全都顺利。五个平台都发布成功，其中一个平台在用 Agent 发布之后出现了限流。原因没有核实过：可能是对内容的判断，可能是对发布方式的识别，也可能与自动化操作无关。把限流直接归因于自动发布，目前只是当事人的一种猜测，不能写成平台确认的处罚原因。

这次经历引出的讨论倒是值得记下：如果平台要抵制低质内容，针对内容本身审查，比针对发布动作审查更合理——同样的几个真人录的节目，不会因为发布方式不同就变成低质内容。这仍是一种主张，不是对任何平台规则的描述。

人还剩下什么

回顾整条链路，人保留的位置有三处：决定做什么内容、准备和把关素材、对最终结果验收。发布到哪些平台、以什么顺序、要不要发，都由人授权。Agent 负责的，是授权之后从启动软件到点击提交的全部动作。

这份经验的样本只有一期节目和一位操作者，结论应该停在个案的范围内。它能说明的是：当写代码之外的操作也可以委托，流程中最耗人的部分从“操作”转移到“决定”。至于哪些平台会长期接受这种方式、不同类型的节目还能省下多少时间，都还需要更多期数来回答。

小团队还要从零写一套 Agent 框架吗？

Tue, 15 Sep 2026 16:00:00 GMT

拆开一个小团队的 Agent 应用，真正差异化的部分通常只在很薄的一层。任务循环、工具调用、上下文拼接这些基础能力，如今已经有多种现成来源：厂商的 Agent API、持续迭代的开源 Harness、可以嵌入自己产品的 CLI。从零写一套框架还剩多少是值得做的，取决于这些替代品各自接管了什么。

loop 很容易，长期用很难

一个能跑的 Agent 循环并不复杂：把任务交给模型，解析它要调用的工具，执行，把结果拼回上下文，再来一轮。真正拉开差距的是长期使用中沉淀下来的细节。Agent 看起来简单，长期使用会发现很难——会话和项目的组织、缓存的命中、与模型协同的优化，都藏在“能跑”之后。

Codex 是这种细节积累的一个样本：它提供专门的工具，可以拉出自己所有的 Project 和 Session、查看进展状态，甚至能定位到某个长对话里出现过的重连问题。这类能力来自架构设计时就为模型训练保留的完整记录，以及长时间的持续迭代。小团队即使写出同样形态的循环，也很难在所有这些细节上投入同等的维护。

复杂度还在增加。自建的 Harness 通常从最简单的 loop 起步，随后不断往里加功能，复杂到一定程度就需要被封装起来——这也正是厂商把它做成托管服务的动机之一。

壳上要做的事，比想象中多

把执行能力交给成熟框架之后，应用团队剩下的部分常被概括为“做壳”。这个概括低估了壳的工作量，一个实际开发过的案例可以说明问题：CodePilot 最早只适配 Claude Code 一家，那时候 Agent SDK 把其他事情做得很好，团队只需要管 UI。但随着各家框架此消彼长，用户今天用这家、明天用那家，壳不得不适配所有后端：做 runtime 路由，把用户输入分发到不同的 CLI 和框架上；处理各家互不相同的 API 格式、返回数据和计费方式；再叠加产品自己的独特功能和历史债务，适配工作越滚越大。

厂商绑定加深让这个问题更严重。Agent 与自家模型越绑越死，各家 Coding Plan 互不兼容，适配成本持续上升。“全都适配”的壳因此越做越难受，却也不敢只适配一家——今天被嘲讽的那家，过几天可能又因为额度或能力翻盘。

三种选择，三种责任范围

可选的路线至少有三种，责任范围各不相同。

第一种是托管服务。Agent API 或官方 Harness 把模型、工具和执行环境打包成闭环，团队只调用服务。代价是深度绑定：模型与 Agent 的组合优化是成对的，支持官方组合的人常举缓存率的例子——同一个模型在官方宿主里的缓存命中更好，尽管具体数字各有说法。组合的优势还包括整合范围——中文信息检索场景里，DeepSeek 官方组合的插件能拿到外部工具拿不到的内容，比如公众号全文。

第二种是 SDK 与 CLI。把执行引擎嵌进自己的产品，模型和基础循环由上游维护，运行形态、界面和数据由自己控制。这是折中方案，但跟随上游本身就是负担：DeepSeek Harness 一天发十几个版本，插件底层一动全部失效；做 GUI 的适配，宿主界面一挪就废，社区因此形成的共识是改做 MCP 或 CLI 这种更稳定的暴露面；想要稳定，就得像 Linux 早期一样等别人打包好的发行版。

第三种才是从零自研。它并没有变得毫无用处——执行环境特殊、安全边界严格，或者产品本身就是框架研究时，自研仍然合理。但对多数面向用户的应用来说，基础执行能力已经有更便宜的来源，自研的判断标准从“别人没有”变成了“这一层是否真的构成产品的差异”。

交给基础设施之后

更进一步的设想是把整个执行层当作基础设施：过去做互联网服务是从云厂商租一台主机部署程序，以后租的可能是“Agent 主机”或 Agent 环境，大量业务由它驱动。这个类比目前还是设想，但方向上的信号已经出现——Agent 越来越被当作技术而非产品，用户不再关心背后是什么模型，服务只暴露自己特殊的部分。

对应用团队，真正留下来的部分因此反而清晰：产品定义、界面、垂直数据与上下文、评测与交付。过去一年许多团队自研 Harness 的投入，事后看更像是交了学费，学费换来的是一个可以据实回答的问题——把可以外包的执行能力外包出去，资源集中在别人替代不了的那一层。至于哪一层对自己不可替代，每个团队要用各自的场景来回答。

模型名没变，工作流为什么变了？

Mon, 14 Sep 2026 16:00:00 GMT

一个 API 模型曾长期只有两个固定名字：一个对应对话，一个对应推理。调用方按名字写好提示词、跑通流程，直到某天发现输出不对了——名字没变，后端模型已经被换过，且没有任何通知。这是录制前一年的普遍体验，也是许多“模型变笨”讨论的起点。

模型名是使用者与服务之间最基础的契约。讨论这个契约为什么松动，需要把混在一起的几件事分开。

版本号正在消失

滚动发版正在成为行业默认做法。厂商先发 Preview 试探口碑；有的用日期代替版本号；有的宣布线上持续更新、不再出版本号，默认一周更新好几次。对厂商，这是把后训练的迭代速度直接暴露给用户；对使用者，这意味着“我调用的是哪个模型”不再有确定答案。

这对评测是一把双刃剑：没法再针对某个版本说它烂，反过来也没法说它好。曾经“某个版本模型能力强”这种可以固化的公共认知，正在失去载体。

厂商对名字的松紧，跟着商业模式的重量走。同一家厂商，早先以“顺手用用”的姿态发布模型，基本不理会用户诉求；随着商业化深入、开始服务企业客户，它对反馈的响应明显变快，有争议的调整也会撤回。一个模型服务越接近公共基础设施，名字的稳定性就越不是技术细节，而是承诺。

名字背后的四件事

用户感知到的“变了”，其实是四件不同的事在各自变化。

一是更新：后端模型悄悄更换，行为随之改变。固定名字的设计初衷是让调用方无感升级，代价是行为差异只能由使用者自己发现。

二是路由：录制前不久发生的一起争议里，一个模型 ID 被临时指向了另一个更便宜的模型，几天后又改回去。名字、价格和实际模型三者短暂脱节，对按名字编程的使用者来说，这就是接口变化。这次操作虽然短暂，讨论里仍指出了它的性质差异：持续更新自己的模型，与把一个 ID 指向别的模型，是两件事——前者是迭代，后者改变了名字本身的含义。

三是计价：面向企业的服务需要价格稳定。模型频繁滚动更新时，一万家企业如何跟着你调定价、调预算，是很麻烦的事。这也是为什么有人认为，愿意挣企业服务钱的厂商，需要提供稳定版本；不愿意做的，等于把这个市场让给第三方——而第三方转售通常要在速度和缓存效率上付出代价。

四是兼容：提示词、插件和工作流都建立在特定行为之上。值得留意的是，提示词在产品中的影响比例这两年其实在下降，更多约束被内化进模型；但工作流对“行为可预期”的依赖没有降低，反而更高了。

“变笨”的争论，先拆成可核对的观察

同一时期，“模型变笨”的讨论在社区反复出现。这个印象本身值得先描述清楚：同一个模型，刚上线时口碑很好，过一段时间却被普遍认为不如从前。流传的解释包括：把简单问题路由给小模型、调控思考量、调整输出策略等。这些说法来自社区对服务的逆向猜测，没有厂商证实，不能当作结论。可以确认的事实要少得多：确实发生过 bug 导致的质量问题——用户大规模反馈后厂商排查修复；对异常使用行为的限制属于产品策略，与模型能力是两回事；而使用者的体感是真实的，值得认真对待。

指控“故意降智”既难以证实，也无助于解决问题。真正缺的是证据：同一任务、同一设置、不同时间的输出记录。有了这组对照，才能区分是模型变了、路由变了，还是使用方式变了。社区口碑在这个过程里反应最快，但样本有偏差，适合当作线索，不适合当作归因。

把失败案例留下来

对依赖模型的工作流，可行的做法是补上厂商没提供的那部分：记录每次调用的版本信息、参数设置和输出结果。出现异常时，先对照记录确认“哪里变了”，再决定是改提示词、锁定第三方稳定版本，还是调整流程。服务商做内部评测，同样需要这种可复现的场景，而不是凭一次体验下结论。

模型名字大概率会越来越抽象——日期、代号、持续更新的大版本。契约松动之后，可靠性的一部分责任转移到了使用者手里：谁留住了记录，谁才有资格判断“到底什么变了”。

便宜模型正在打开新的使用场景

Sun, 13 Sep 2026 16:00:00 GMT

一段视频一边生成一边播放，讲到哪里画面跟到哪里；中途打断、换一个问题，画面立刻重新开始。这样一次实时演示在录制时由 MiniMax 的加速模型与 fal.ai 完成。类似的演示此前也出现过，但大多停在内测阶段：算力消耗惊人，开放时间有限，生成质量也撑不起真实使用。这一次的差别在于成本和质量同时过了线——画面“起码能看了”，按录制时的估算，推理成本也降到了能支撑全天直播的量级。

价格下降最先改变的不是模型聪明了多少，而是哪些事情开始值得交给模型做。

尝试本身是有成本的

一款新模型能否进入真实使用，往往不取决于评测分数，而取决于用户愿不愿意花时间试。试模型要买额度，买不起就可能干脆不试；能力强但贵的模型，用不起就没人关注。录制时几款 Flash 档模型免费开放试用，背后的判断正是如此：让用户先形成自己的体感，社区才会涌现出真实案例，这个循环比广告更有效。

这个思路也被产品沿用。有的产品把免费模型做成每日轮换，用户用完直接反馈哪款好用、哪款不行。按运营方的观察，这类真实反馈比榜单更准，免费期表现好的模型也确实留住了用户。免费降低的不只是钱，还有“选错模型浪费一个下午”的心理成本——当尝试便宜到接近于零，模型才会真正进入普通用户的备选清单。

高频低风险的任务先被让出去

便宜模型最先接手的，是单次价值低、重复次数多的任务。回复一条消息，用贵一点的模型问题不大，因为它只发生一次；但让一个 Agent 跑完整个任务，每一步都调用前沿模型，成本很快就压不住了。单次省下的钱不起眼，放进高频场景就成了决定性差异。

速度在放大这种差异。录制时有使用者描述用 Flash 档模型写代码的体验：每秒几百 Token 的输出，一版不满意立刻重来。快了之后，人的角色从等待变成筛选——有专业能力的使用者可以靠自己的判断把七八十分的结果调到九十五分，前提是试错节奏跟得上思考节奏。这还是一个个例，但它指出了便宜模型真正的用武之地：不是替代最好的模型，而是让“多试几次”变得可以承受。

便宜也不等于单方面妥协。有使用者发现，某些 Flash 档模型反而不谄媚，会坚持自己的论点，不同意时直接说不同意，然后再帮忙执行。输出质量之外，这种“敢说不对”的性格，也是一些用户愿意长期把日常任务交给它们的原因。

向下扩大，而不是向上竞争

把便宜模型理解成前沿模型的低价替身，容易低估其影响。更准确的描述是：便宜和开源模型不参与对顶尖能力的竞争，而是向下扩大使用的人数、场景和体验。过去因价格被挡在门外的事情——实时视频生成、每天调用多次的助手、跑在自己设备上的整理任务——逐个变成日常。

这解释了为什么各家厂商在同一时间段都推出 Flash 档模型。这个称呼沿用了“快”的含义，实际定位已经是小尺寸、低成本的常备档位：参数更小、输出更快、价格更低，能力尽量不缩水。有的大模型因为尺寸太大、运行成本高，反而必须另做一个小档位来覆盖高频场景。

便宜模型的出现也不威胁前沿模型的位置。需要一次性解决复杂任务、修改次数越少越好的工作，仍然值得用最强的模型；两类需求是金字塔的不同层次。便宜模型渗透得越深，下面的人往上转化、开始为更高价值付费的可能也越大。

场景打开了，任务仍是边界

便宜打开了门，门后的路仍由任务决定。实时视频演示再流畅，也有单次生成时长的限制；Flash 模型速度够快，输出变快之后，人发起的尝试也变多，总消耗未必下降。让 Agent 自动在不同价位的模型之间切换，是顺理成章的想法，但目前仍不容易：判断一个任务该用哪个模型本身就是难题，多数时候还是人在切。

对使用者来说，更可行的问题不是“哪个模型最强”，而是自己的任务里哪些判断高频、低风险、可以批量发生——这些位置最先值得交给便宜模型；一次就要结果、错了代价高的环节，留给更强的模型。便宜模型打开的是场景，而不是对所有任务的接管。

Next Token｜词元之外 · 博客

当 AI 普遍做到六十分，内容还凭什么被选择

可用价值与选择优势不同

质量提高，作品仍可能更相像

差异可以来自更具体的材料

包装服务于读者要完成的事

相关资料

中国的个人 Agent，为什么聊着聊着就去服务商家了？

商家任务自带一部分上下文

接近业务，不等于自动拥有权限

消费者服务提供了反例

商业价值更清楚，也更容易被追问

相关资料

人类在精简团队，Agent 却开始开会了

给角色起名字，比划清任务容易

并行收益取决于任务之间要等多少次

脑暴和交付可以采用不同的组织方式

管理一支 AI 团队的快乐，也可以单独成立

相关资料

作品开源以后，作者靠什么留下来？

名字让人找得到，作品让人有理由回来

从曝光到收入，中间有几次不同的选择

开源后仍然有人需要原作者

爆款故事缺少没有被看见的部分

相关资料

整理几百本书，是假提效，还是收纳的快乐？

先分清这一小时换来了什么

分类应该贴近下一次使用

收纳有终点，整理也可能成为拖延

个人 Agent 不必只做能写进周报的事

相关资料

模型越来越强，Skill 里还应该留下什么？

模型会做，和知道你要什么，隔着一层信息

Skill 可以保存程序和资源

层层封装，容易藏住决定

清理时，用旧任务做比较

相关资料

给 ESP32 装上一个会说话的个人助理

从自己写固件，到刷上就能用

一次具体的桌面改造

为什么开始真的在用

分工正在改变

全屋接管是设想，不是现状

已经验证的与还没走的

相关资料

从收集个人数据到定期回顾

记录的门槛正在下降

从存档到每周报告

回顾能发现什么

保留什么，能不能带走

相关资料

手机里的 Agent，限制不止算力

电脑上的 Agent 靠什么工作

沙盒挡住了同一套能力

上下文也留在电脑一侧

系统画出的框，和框上的缝隙

算力已就位，环境没跟上

相关资料

用持续的作品建立信任

性格需要可以被辨认

信任是一种押注，不是定律

可复制的东西，和带不走的东西

相关资料

把电视遥控器变成电脑的语音入口

硬件是现成的

缺的是一段软件

两天的全语音工作

按键和屏幕各自负责什么

谁来把生态位补上

相关资料

什么时候值得把前沿模型换成自己的小模型？

先有资格谈替换

一个被转述的案例说明了什么

质量够用，要用场景里的指标定义

垂直和封闭的场景更容易成立

时机也是成本问题

相关资料

Agent 插件迁移，难在能力不对等

共识在标准层，分裂在实现层

门槛是宿主暴露了哪些能力