#Technology

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

在创业公司，每个人摊上的是大公司几个团队的活，如果不充分利用 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 被训练得非常擅长在这种形态的空间里工作。

用 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 的定位是不是匹配？ 技术角度：技术上能不能做到？成本是不是可控？

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

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 过程的无聊，让工程师的专业度得以延续下去。

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

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

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

很多所谓 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 级别的智能。

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

Memory: 让正确的过去，在正确的时候，以正确的作用域，正确的方式重新出现。

记忆功能常被产品宣传为“越用越懂你”。更准确地说，它解决的是重复交代背景的问题：用户长期使用某个 AI 产品后，一些背景和历史不希望反复交代。模型本身没有长期记忆，产品要做的是从历史交互中提取少量可信信息，用于理解用户和延续任务。

和记忆相关的内容有三类：

• 聊天历史（事情发生过，但不一定该影响未来，可作为 RAG 检索源）
• 当前工作空间的工作记忆（项目进度）
• 长期记忆 Memory（在用户发当前任务之前，默认就能代入上下文、影响结果走向的内容）

关键在于：Memory 系统要做一次准入判断——哪些历史信息可以继续影响未来要做的任务。

以上五类记忆都属于陈述性记忆（declarative memory），记录的是“用户是谁、了解什么、发生过什么”，也就是用户特征、知识背景和历史交互。它们提供的是推理前提，不直接规定 Agent 该怎么做事。WorkBuddy 没有把 Procedural Memory（程序性记忆）纳入长期记忆，是因为程序性记忆记录的是“做事方法”，这类内容一旦作为长期记忆注入，会直接影响 Agent 的推理路径和执行顺序。

例如“用户熟悉 Python”是陈述性信息；“遇到所有调试任务，都先重启服务再查日志”是程序性策略。后者注入上下文后会带来几个问题：

• 局部经验被误升为通用策略：一次任务里有效的步骤，换个项目未必成立；
• 干扰模型推理：模型可能不再根据当前证据选路径，而是复用历史步骤，陷入局部最优；
• 隐性改写 Agent 行为：程序性内容实际上接近动态 System Prompt，却可能缺少版本、评测、审批和回滚；
• 降低泛化与可控性：如果 Agent 从每次任务自动学工作流，又没有稳定的奖励信号和 Eval，系统很难判断它是在改进还是在积累偏见。

Memory 系统按稳定事实、用户知识背景、行为信号、表达偏好和会话延续信息分层存储，仅陈述性记忆进入长期记忆。程序性记忆（做事方法）不纳入长期记忆，以免局部经验被误升为通用策略；验证过的工作方法以 Skill 形式版本化、可评审、可回滚。

复杂性体现在细节之中。当库存被其他订单临时占用时该如何处理？如何应对部分付款？若邮件服务暂时不可用该怎么办？是否需要重试？重试次数应设为多少？若客户在结账过程中会话超时又该如何处理？如何防止订单重复提交？每个答案都会引发更多疑问。累积的决策、边界情况和交互形成了真实的复杂性，没有任何工具或语言能消除这种复杂性。必须有人思考这些场景。这种思考就是软件开发，无论它是以 COBOL、CASE 工具图、Visual Basic 还是 AI 提示的形式呈现。

人工智能改变的是开发者的工作方式，而非消除他们判断力的必要性。复杂性依然存在。必须有人理解业务问题，评估生成的代码是否正确解决问题，考量安全影响，确保其与现有系统无缝集成，并在需求演变时持续维护代码。

人工智能能增强开发者的能力，但它无法取代那些既通晓问题领域又精通技术环境的人。

当 “A/B Test” 成了拍板的主要方式，清晰的产品愿景就变成了可有可无的东西。久而久之，产品团队的角色就变了：判断力慢慢让位于迭代，品味慢慢让位于数据表现。产品还在演进，但已经没有了明确的方向感……只剩下一种惯性往前冲的动量。

你没法轻易量化用户心里的那股怨气。也没法量化他们带着火气狂点按钮、只为关掉又一个"你知道吗"弹窗时的那种暴躁。你没法轻易画出一张图表，标注用户心里冒出这个念头的那一刻：“我以前挺喜欢这产品的，现在怎么这么烦人。“你没法轻易量化信任是怎么一点一点被消磨掉的。