2026-01-13 19:29:28
个人感觉 linux.do 是目前国内内容质量和社区氛围都比较出众的程序员社区，应该和站长的风格也有关系，禁 ai 润色、禁 aff 等，同时加上等级系统和保级压力，以及最近上的 credit 货币系统，大家会有压力和动力去产出更好的内容。
2026-01-07 19:01:18
原文：https://cursor.com/blog/dynamic-context-discovery
作者：Jediah Katz
译者：Claude Opus 4.5
Jan 6, 2026 by Jediah Katz in research
编程智能体正在快速改变软件的构建方式。它们的快速进步既来自于改进的智能体模型，也来自于更好的上下文工程来引导它们。
Cursor 的智能体框架——我们提供给模型的指令和工具——针对我们支持的每个新前沿模型都进行了单独优化。然而，我们可以进行一些适用于框架内所有模型的上下文工程改进，例如如何收集上下文以及在长轨迹中优化 token 使用。
随着模型作为智能体变得越来越好，我们发现通过预先提供更少的细节来取得成功，这使得智能体更容易自己拉取相关上下文。我们将这种模式称为动态上下文发现，与始终包含的静态上下文形成对比。
动态上下文发现在 token 效率上要高得多，因为只有必要的数据才会被拉入上下文窗口。它还可以通过减少上下文窗口中可能令人困惑或矛盾的信息量来提高智能体的响应质量。
以下是我们在 Cursor 中使用动态上下文发现的方式：
工具调用可能会通过返回大型 JSON 响应来大幅增加上下文窗口。
对于 Cursor 中的第一方工具，如编辑文件和搜索代码库，我们可以通过智能工具定义和最小响应格式来防止上下文膨胀，但第三方工具（即 shell 命令或 MCP 调用）原生并没有得到同样的处理。
编程智能体采取的常见方法是截断长 shell 命令或 MCP 结果。这可能导致数据丢失，其中可能包含你想要在上下文中保留的重要信息。在 Cursor 中，我们改为将输出写入文件，并赋予智能体读取它的能力。智能体调用 tail 检查末尾，然后在需要时读取更多内容。
这减少了在达到上下文限制时不必要的摘要操作。
当模型的上下文窗口填满时，Cursor 会触发一个摘要步骤，为智能体提供一个新的上下文窗口，其中包含其迄今为止工作的摘要。
但是智能体的知识在摘要后可能会退化，因为这是对上下文的有损压缩。智能体可能已经忘记了关于其任务的关键细节。在 Cursor 中，我们使用聊天历史作为文件来提高摘要的质量。
在达到上下文窗口限制后，或者用户决定手动进行摘要时，我们会给智能体一个历史文件的引用。如果智能体知道它需要摘要中缺失的更多细节，它可以搜索历史记录来恢复它们。
Cursor 支持 Agent Skills，这是一个用于扩展编程智能体专业能力的开放标准。与其他类型的 Rules 类似，Skills 由文件定义，告诉智能体如何执行特定领域的任务。
Skills 还包括名称和描述，可以作为"静态上下文"包含在系统提示中。然后智能体可以进行动态上下文发现来拉取相关的 skills，使用 grep 和 Cursor 的语义搜索等工具。
Skills 还可以捆绑与任务相关的可执行文件或脚本。由于它们只是文件，智能体可以轻松找到与特定 skill 相关的内容。
MCP 有助于访问 OAuth 保护的安全资源。这可能包括生产日志、外部设计文件，或企业的内部上下文和文档。
一些 MCP 服务器包含许多工具，通常带有冗长的描述，这会显著膨胀上下文窗口。大多数这些工具即使始终包含在提示中也从未被使用。如果你使用多个 MCP 服务器，这个问题会更加严重。
期望每个 MCP 服务器都为此进行优化是不现实的。我们认为减少上下文使用是编程智能体的责任。在 Cursor 中，我们通过将工具描述同步到文件夹来支持 MCP 的动态上下文发现。
智能体现在只接收少量静态上下文，包括工具名称，提示它在任务需要时查找工具。在 A/B 测试中，我们发现在调用 MCP 工具的运行中，这一策略将智能体总 token 减少了 46.9%（统计显著，根据安装的 MCP 数量有较高方差）。
这种文件方法还解锁了向智能体传达 MCP 工具状态的能力。例如，以前如果 MCP 服务器需要重新认证，智能体会完全忘记那些工具，让用户感到困惑。现在，它实际上可以主动让用户知道需要重新认证。
用户不再需要将终端会话的输出复制/粘贴到智能体输入中，Cursor 现在将集成终端输出同步到本地文件系统。
这使得询问"为什么我的命令失败了？"变得很容易，并允许智能体理解你所引用的内容。由于终端历史可能很长，智能体可以 grep 只获取相关输出，这对于像服务器这样的长时间运行进程的日志很有用。
这反映了基于 CLI 的编程智能体所看到的内容，上下文中包含先前的 shell 输出，但是动态发现而非静态注入。
目前尚不清楚文件是否会成为基于 LLM 的工具的最终接口。
但随着编程智能体的快速进步，文件一直是一个简单而强大的原语，比起又一个无法完全预见未来的抽象层，它是一个更安全的选择。敬请期待我们在这个领域分享更多令人兴奋的工作。
这些改进将在未来几周内对所有用户上线。本博客文章中描述的技术是许多 Cursor 员工的工作成果，包括 Lukas Moller、Yash Gaitonde、Wilson Lin、Jason Ma、Devang Jhabakh 和 Jediah Katz。如果你对使用 AI 解决最困难、最雄心勃勃的编程任务感兴趣，我们很乐意听取你的意见。请通过 [email protected] 联系我们。
Author: Jediah Katz
2026-01-06 00:29:51
原文： https://steipete.me/posts/2025/shipping-at-inference-speed
作者： Peter Steinberger
译者： Gemini 3 Pro High
今年“氛围编码（vibe coding）”的发展程度令人难以置信。虽然在五月左右，我还在为某些提示词能开箱即用地生成代码而感到惊讶，但这现在已经成了我的基本预期。我现在交付代码的速度快得不真实。从那时起，我消耗了大量的 Token。是时候更新一下情况了。
这些智能体（Agent）的工作方式很有趣。几周前有一种观点认为，一个人需要亲自写代码才能感受到糟糕的架构，使用智能体会造成脱节——对此我完全不同意。当你花足够多的时间与智能体相处，你会确切地知道某件事应该花多长时间，如果 Codex 返回结果时没有一次性解决问题，我就已经开始怀疑了。
我现在能创建多少软件，主要受限于推理时间和深度思考。老实说——大多数软件并不需要深度思考。大多数应用程序只是将数据从一个表单推送到另一个表单，也许将其存储在某个地方，然后以某种方式展示给用户。最简单的形式是文本，所以默认情况下，无论我想构建什么，它都从 CLI 开始。智能体可以直接调用它并验证输出——从而形成闭环。
真正解锁像工厂一样构建软件的是 GPT 5。发布后我花了几周时间才意识到这一点——等待 Codex 赶上 Claude Code 拥有的功能，并花了一些时间学习和理解它们之间的差异，但随后我开始越来越信任这个模型。这些天我已经不怎么读代码了。 我会看着输出流，有时会查看关键部分，但老实说——大多数代码我都不读。我知道哪些组件在哪里，事物是如何组织的，以及整体系统是如何设计的，通常这就足够了。
现在的关键决策在于语言/生态系统和依赖项。我处理 Web 内容的首选语言是 TypeScript，CLI 用 Go，如果需要使用 macOS 功能或有 UI 则用 Swift。就在几个月前，我甚至完全没考虑过 Go，但最终我试了试，发现智能体非常擅长编写 Go 代码，而且它简单的类型系统使得 Lint 检查非常快。
对于构建 Mac or iOS 应用的朋友：你不再那么需要 Xcode 了。我甚至都不使用 xcodeproj 文件。如今 Swift 的构建基础设施对大多数事情来说已经足够好了。Codex 知道如何运行 iOS 应用程序以及如何处理模拟器。不需要特殊的东西或 MCP。
我正在写这篇文章的时候，Codex 正在处理一个巨大的、耗时数小时的重构，并清理 Opus 4.0 留下的旧烂摊子。Twitter 上的人经常问我 Opus 和 Codex 之间有什么大区别，既然基准测试如此接近，为什么这很重要。依我看，越来越难以信任基准测试了——你需要亲自尝试两者才能真正理解。无论 OpenAI 在后训练阶段做了什么，Codex 在开始之前已经被训练成会阅读大量的代码。
有时它只是静静地阅读文件 10 到 15 分钟，然后才开始写代码。一方面这很烦人，另一方面这又很棒，因为它大大增加了修复正确问题的几率。另一方面，Opus 更加急切——非常适合小的修改——但不太适合较大的功能或重构，它经常不阅读整个文件或遗漏部分内容，然后交付低效的结果或遗漏某些东西。我注意到，即使 Codex 有时在类似任务上花费的时间是 Opus 的 4 倍，我通常还是更快，因为我不必回头去修复那个修复，这在我还在使用 Claude Code 时感觉是很常态的事情。
Codex 还让我摒弃了许多在使用 Claude Code 时必需的伪装。我不再使用“计划模式”，而是简单地与模型开始对话，提出问题，让它去 Google、探索代码、共同制定计划，当我对我看到的内容感到满意时，我写下“构建”或“将计划写入 docs/*.md 并构建这个”。计划模式感觉像是一种黑客手段，对于旧一代不太擅长遵循提示词的模型来说是必要的，所以我们不得不剥夺它们的编辑工具。有一条被高度误解的推文至今仍在流传，这向我表明大多数人并不明白计划模式并非魔法。
从 GPT 5/5.1 到 5.2 的跨越是巨大的。大约一个月前，我构建了 oracle 🧿——这是一个 CLI，允许智能体运行 GPT 5 Pro 并上传文件 + 提示词，并管理会话以便稍后检索答案。我这样做是因为很多时候当智能体卡住时，我会让它把所有内容写入 markdown 文件，然后自己进行查询，这感觉像是重复的时间浪费——也是一个闭环的机会。说明文件在我的全局 AGENTS.MD 文件中，模型有时会在卡住时自行触发 Oracle。我每天使用它多次。这是一个巨大的解锁。Pro 版本在快速浏览约 50 个网站然后进行深度思考方面做得好得惊人，几乎每次都能给出完美的回答。有时它很快，需要 10 分钟，但我也有过运行超过一个小时的情况。
现在 GPT 5.2 出来了，我需要它的情况少多了。我自己有时会用 Pro 进行研究，但我要求模型“询问 Oracle”的情况从每天多次变成了每周几次。我对此并不生气——构建 Oracle 非常有趣，我学到了很多关于浏览器自动化、Windows 的知识，并最终花时间研究了技能（Skills），此前我曾一度否定这个想法。这确实表明 5.2 在许多现实生活中的编码任务上变得有多好。它几乎能一次性搞定（one-shot） 我扔给它的任何东西。
另一个巨大的胜利是知识截止日期。GPT 5.2 到了 8 月底，而 Opus 停留在 3 月中旬——这大约是 5 个月的差距。当你想要使用最新的可用工具时，这一点非常重要。
再举一个例子来说明模型已经发展到了什么程度。我早期的一个高强度项目是 VibeTunnel。一个终端复用器，让你可以随时随地编码。今年早些时候，我几乎把所有时间都投入到了这个项目中，2 个月后它变得非常好用，以至于我发现自己在和朋友外出时还在用手机写代码……于是我决定停止这个项目，更多是为了心理健康。当时我试图将复用器的一个核心部分从 TypeScript 重写，但旧模型总是让我失望。我试过 Rust、Go……上帝保佑，甚至试过 Zig。当然我可以完成这个重构，但这需要大量的手工工作，所以我从未在将其搁置之前完成这项工作。上周我把它重新翻出来，给 Codex 一个两句话的提示词，要求将整个转发系统转换为 Zig，它运行了超过 5 个小时，进行了多次压缩，并且一次性交付了一个可工作的转换版本。
你可能会问，我为什么要把它翻出来？我目前的重点是 Clawdis，这是一个 AI 助手，拥有对我所有电脑、消息、邮件、家庭自动化、摄像头、灯光、音乐的完全访问权限，甚至可以控制我床的温度。当然它还有自己的声音、发推特的 CLI 和它自己的 Twitter 账号。
Clawd 可以看到并控制我的屏幕，有时会发表讽刺性的评论，但我也想让它能够检查我的智能体，获取字符流比查看图像要高效得多……这是否行得通，我们拭目以待！
我知道……你来这里是想学习如何更快地构建，而我只是在为 OpenAI 写营销软文。我希望 Anthropic 正在酝酿 Opus 5，局势能再次逆转。竞争是好事！同时，我爱 Opus 作为通用模型。如果运行在 GPT 5 上，我的 AI 智能体的乐趣会少一半。Opus 有某种特殊的东西，让与之合作成为一种乐趣。我用它来处理我大部分的计算机自动化任务，当然也是它驱动了 Clawd🦞。
自十月份我上次谈论这个问题以来，我的工作流并没有太大改变。
../project-folder，这通常足以让它从上下文中推断出在哪里查找。这对于节省提示词非常有用。我可以只写“查看 ../vibetunnel 并为 Sparkle changelogs 做同样的事情”，因为它已经在那里解决了，而且有 99% 的保证它会正确地复制过来并适应新项目。这也是我搭建新项目的方式。这是我的 ~/.codex/config.toml：
model = "gpt-5.2-codex"
model_reasoning_effort = "high"
tool_output_token_limit = 25000
# Leave room for native compaction near the 272–273k context window.
# Formula: 273000 - (tool_output_token_limit + 15000)
# With tool_output_token_limit=25000 ⇒ 273000 - (25000 + 15000) = 233000
model_auto_compact_token_limit = 233000
[features]
ghost_commit = false
unified_exec = true
apply_patch_freeform = true
web_search_request = true
skills = true
shell_snapshot = true
[projects."/Users/steipete/Projects"]
trust_level = "trusted"
这允许模型一次读取更多内容，默认值有点小，可能会限制它看到的内容。它会静默失败，这很痛苦，他们最终会修复这个问题。另外，网页搜索仍然默认没开启？unified_exec 取代了 tmux 和我旧的 runner 脚本，其余的也很棒。不要害怕压缩（compaction），自从 OpenAI 切换到他们新的 /compact 端点后，这工作得足够好，任务可以在多次压缩中运行并完成。它会让事情变慢，但通常起到了审查的作用，模型在再次查看代码时会发现 bug。
就这些，暂时。我计划再多写点东西，脑子里积压了很多想法，只是太沉迷于构建东西了。如果你想听到更多关于如何在这个新世界中构建的胡言乱语和想法，在 Twitter 上关注我。
2026-01-05 19:22:26
原文：https://x.com/leerob/status/2007203275461009508
作者：Lee Robinson (@leerob)
译者：Gemini 3 Pro High
Lee Robinson (@leerob) - 2026年1月2日
Cursor AI（前 Vercel）
现在是2026年，说起来有些奇怪，但我已经不再真正手写代码了。
我构建了一个完整的基于 Rust 的图像压缩器，它可以编译成 WebAssembly，并使用 SvelteKit 网页应用来拖放图片、压缩和调整大小。我完全没有手写任何代码——全部使用编程代理完成。
我甚至为 Analogue Pocket 构建了一个《太空侵略者》克隆版，而我对硬件工作原理一无所知。我能够与编程代理合作编写 Verilog 代码，并实际对设备上的硬件进行编程。这简直太疯狂了。
六个月前或一年前，我甚至不会尝试这些项目，而现在它们对我来说实际上非常容易完成。
大约九个月前，我发布了一个视频，讲述我如何尝试了一堆文本编辑器和 IDE，最终选择了 Cursor，因为我觉得它有最好的用户体验——我熟悉 VS Code，而且它在 AI 功能方面也做得非常好。
几个月后，我决定真正加入 Cursor。我已经在那里工作了大约六个月，主要是因为我真的能感受到格局在变化。我能感受到软件工程在我脚下发生变化，我想成为探索这种变化的一部分，并帮助教大家如何自己驾驭这段旅程。
就在一年前，编程代理还不是什么流行的东西。Cursor 的代理刚刚推出。然后在2025年，我们看到 Claude Code 和 Codex，以及许多其他编程代理变得非常流行，同时模型本身也在改进。
回顾一年前，在 Sonnet 4 之前，模型经常产生幻觉。它们在遵循指令和调用工具方面相当糟糕。当你看看最新一批模型——Codex Maxi、Opus 4.5——它们已经变得非常好了。现在它们生成代码的能力相当惊人。
老实说，模型在编程方面可能比我想承认的更好。它们可能已经足够好了一段时间，但你无法在大多数软件工程实践中可靠地使用它们。
进入2026年，我可以肯定地说，当前这批模型在编程方面绝对比我更好。它们让我能够承担更有雄心的任务。
这对我来说有点改变：软件工程到底是什么？
写代码从来不是真正的瓶颈，尤其是对于大型项目。所以如果写代码现在基本上是免费的，或者基本上很容易做到，这对软件的其他方面意味着什么？
1. Cursor.com 迁移
我将 cursor.com 从 CMS 迁移到只使用 Markdown 和 MDX 文件。我以为这会花很长时间——也许几周。我们可能需要雇一些承包商或代理机构。但我在几天内就完成了，使用 Cursor Ultra 计划花费非常实惠。这是我第一次体验到：哇，我对编程代理的要求可能可以更加雄心勃勃。
2. Rust 图像压缩器
我完全用编程代理完成了这个项目。我没有手写任何代码。我以为模型肯定不擅长写 Rust——相比 TypeScript 来说是更底层的代码。还要做更复杂的计算机科学的事情，弄清楚这些算法，从头开始编写它们。如果你去看源代码，它做了一些相当疯狂的事情。
3. Analogue Pocket 游戏（太空侵略者）
我有一个 Analogue Pocket，有点像 GameBoy。你可以编写代码并对设备上的硬件进行编程。这是我没有经验的领域。我不是游戏开发者——我用 Python 构建过一些游戏，但那非常不同，抽象层次高得多。我能够向模型提问并在这方面取得显著进展，现在我理解了它的工作原理，可以从头开始构建新游戏。
对所有这些的自然反应是：“是的，我做的这件事模型还不太擅长，所以这意味着模型永远不会变好。”
我曾经对 Rust、底层代码或详细的计算机科学主题也有这种感觉。然后最近，模型在这些方面变得非常好了。
如果我是你，我会预期在未来一年内，模型将在软件工程中你需要编写代码的大多数事情上变得擅长。
这并不意味着软件工程已死或我们不会有工作。我实际上认为恰恰相反——对软件工程师和实际使用这些工具的人的需求将比以往任何时候都大。这有点矛盾，但我认为历史已经证明了这一点。
在学习这些工具时——无论你想用什么编程代理：Cursor、Codex、Claude Code 等等——你将比那些更犹豫或怀疑的人获得显著优势。学会很好地使用它们可以让你大大领先。
使用这些工具来消除所有繁琐的工作——那些你不想做的事情。
很多软件工程实际上是在复制和移动 JSON 文件、弄清楚为什么 shell 脚本不工作、试图调试一些奇怪的错误信息。有很多样板代码，很多你只是从 Stack Overflow 或 Google 复制粘贴的东西。
用编程代理来处理那些事情。摆脱所有无聊的东西，专注于对最终产品真正重要的事情。
既然代码变得廉价，真正重要的是你的品味。作为工程师，越来越多地要成为一个多面手。这不仅仅是代码——还有：我们正在构建什么产品？它看起来怎么样？它如何运作？用户体验如何？我们要如何销售这个东西？我们如何营销这个东西？
去构建东西。成为多面手。实际尝试构建某物的整个过程。
不要只是写代码然后发布——把它推向世界，营销它，获取用户，构建人们喜爱的东西，发展产品，弄清楚要构建什么正确的东西。
作为软件工程师，这些技能在未来一到三年内将对你非常有价值。随着这个职业的变化，那些拥抱 AI 来更好地完成工作的产品工程师将拥有显著的优势。
如果你想了解更多，我有一篇关于产品工程师的完整文章。这个趋势在我2024年写这篇文章时就已经在发生了，但随着 AI 进入2026年，它现在大大加速了。
如果你过度依赖 LLM，它们可能会欺骗你，让你认为你理解了一个话题。你不想把思考委托给代理。你想用它们来变得更聪明。
你怎么做到？向模型问很多问题。就像你身边一直有一个很棒的结对程序员，你可以问无限多的问题，他永远不会生你的气或认为这是个愚蠢的问题。
我最近一直在做的一件事：我会让模型为我生成基本上是一个迷你课程——引导我了解对我来说完全陌生的主题。“向我解释什么是 Verilog 以及语法如何工作。向我解释从硬件到我实际编写的代码的不同抽象层以及它是如何编译的。”
这些东西可以使按需学习变得更加容易，而不必阅读10本教科书。如果你有主动性和意愿去学习这些东西，你现在就可以获得巨大的优势。
我和你们一样在摸索。这有点奇怪——有时候会有一点存在危机感，因为感觉你正在失去你真正热爱的一部分，那就是构建东西。
但对我来说，我必须记住：这不是关于代码的。写代码在很多方面从来都不是瓶颈。这是关于构建伟大的东西，我引以为豪的东西，我认为真正好的东西。而这远不止是代码。
所以现在：既然我有了这个很棒的工具，我该如何使用 AI 来更好地提升我的技艺？
这就是我对2026年的想法。这将是伟大的一年。我很乐观。我认为我们将会有很多积极的事情。
和平。
