云谦的博客

🔒 622 - 《AI Coding：模型自由》

supercc — Fri, 06 Feb 2026 00:23:22 GMT

AI 编程最重要的是：模型自由。

🔒 会员专享内容

此文章的完整内容仅对会员开放。

→ 点击查看完整内容

需要登录并验证邮箱才能访问受限内容。

🔒 621 - 《AI Coding FAQ》

supercc — Thu, 05 Feb 2026 00:01:31 GMT

对群里的问题做下快问快答。可以评论里接着问，新问题的答案我会补充到前面。

🔒 会员专享内容

此文章的完整内容仅对会员开放。

→ 点击查看完整内容

需要登录并验证邮箱才能访问受限内容。

译：Karpathy：关于 Claude 编程的笔记

supercc — Tue, 27 Jan 2026 09:22:23 GMT

原文：https://x.com/karpathy/status/2015883857489522876
作者：Andrej Karpathy (@karpathy)
译者：Gemini 3 Flash

过去几周里，我一直在大量使用 Claude 进行编程，这里有一些随机笔记。

编程工作流

鉴于大语言模型（LLM）编程能力的最新提升，和许多人一样，我在 11 月还处于大约 80% 的手动+自动补全编程和 20% 的智能体（Agent）编程，到了 12 月就迅速转变为 80% 的智能体编程 and 20% 的编辑与润色。也就是说，我现在基本上是在用英语编程，甚至有点不好意思地告诉 LLM 要写什么代码……用文字来表达。

这虽然有点伤自尊，但在大型"代码操作"中操作软件的能力实在是太有用了，特别是当你适应它、配置它、学会使用它，并搞清楚它能做什么和不能做什么之后。这无疑是我近 20 年编程生涯中对基本编程工作流最大的改变，而且它就在几周内发生了。我预计类似的转变也发生在两位数比例的工程师身上，而在普通人群中，对此的认知度似乎还处于个位数百分比。

IDE / 智能体集群 / 易错性

在我看来，无论是"不再需要 IDE"的炒作，还是"智能体集群"的炒作，目前都有些过头了。模型肯定还是会犯错的，如果你有任何真正关心的代码，我建议你在旁边开一个好用的大型 IDE，像鹰一样盯着它们。

错误的类型发生了很大变化——它们不再是简单的语法错误，而是微妙的概念性错误，就像一个略显马虎、匆忙的初级开发人员可能会犯的那样。最常见的一类是模型代表你做出了错误的假设，然后不加检查就直接执行。它们也不会管理自己的困惑，不会寻求澄清，不会揭示不一致之处，不会权衡利弊，在应该反驳的时候不会推辞，而且仍然有点过于迎合用户。

在计划模式下情况会有所好转，但仍需要一种轻量级的行内计划模式。它们还非常喜欢把代码和 API 复杂化，让抽象变得臃肿，不清理自己产生的废弃代码等等。它们可能会用 1000 行代码实现一个低效、臃肿且脆弱的结构，这时就需要你跳出来说：“嗯，你不能换成这种做法吗？”，然后它们会回答：“当然可以！”，并立即将其精简到 100 行。

即使与当前任务无关，它们有时仍会作为副作用更改或删除它们不喜欢或不完全理解的注释和代码。尽管我尝试通过 CLAUDE.md 中的指令进行了一些简单的修复，但这些情况仍然会发生。尽管存在这些问题，它仍然带来了巨大的净改进，很难想象再回到手动编程。长话短说（TLDR），每个人都有自己的开发流程，我目前的方法是：左边是几个在 ghostty 窗口/标签页中的 CC（Claude Code）会话，右边是一个用于查看代码和进行手动编辑的 IDE。

韧性

观察一个智能体坚持不懈地处理某件事是非常有趣的。它们永远不会疲倦，永远不会气馁，它们只是不断地尝试，而换做人类可能早就放弃，改天再战了。看着它纠结于某件事很长时间，最后在 30 分钟后获得成功，这真是一个"感受到 AGI"的时刻。你会意识到，耐力是工作的核心瓶颈，而有了 LLM，这个瓶颈已经得到了极大的缓解。

加速

目前还不清楚如何衡量 LLM 辅助带来的"加速"。当然，我确实感觉到在处理原本要做的事情时速度快得多，但主要的影响是我做的事情比原本打算做的多得多，原因在于：1）我可以编写各种以前不值得花时间去写的代码；2）由于知识或技能问题，我以前无法触及的代码，现在也可以尝试了。所以这确实是加速，但可能更多地是一种能力的扩展。

杠杆作用

LLM 非常擅长通过循环直到达到特定目标，而这正是大多数"感受到 AGI"的神奇之处所在。不要告诉它该怎么做，而是给它成功标准，然后看它发挥。让它先写测试，然后通过测试。把它与浏览器 MCP 放在同一个循环中。先写一个极有可能是正确的朴素算法，然后要求它在保持正确性的同时进行优化。将你的方法从命令式转变为声明式，以便让智能体循环更久并获得杠杆作用。

乐趣

我没有预料到，有了智能体，编程会变得更有趣，因为大量的填空式繁琐工作被移除了，剩下的则是极具创造性的部分。我也觉得没那么容易卡壳了（卡壳的感觉可不好受），而且我感到更有勇气，因为几乎总有办法与它携手合作并取得一些积极的进展。我也看到过其他人的相反观点；LLM 编程将根据那些主要喜欢编码的人和那些主要喜欢构建的人来划分工程师。

萎缩

我已经注意到，我手动编写代码的能力正慢慢开始萎缩。大脑中"生成"（写代码）和"判别"（读代码）是不同的能力。很大程度上由于编程涉及的所有那些细微的语法细节，即使你写起来很吃力，你也仍然可以很好地审查代码。

垃圾代码大爆发（Slopacolypse）

我正准备迎接 2026 年，这一年将是 GitHub、Substack、arXiv、X/Instagram 以及所有数字媒体中"垃圾内容大爆发"的一年。在真正的改进之外，我们还将看到更多人工智能炒作式的"效率演戏"（这真的可能吗？）。

问题

我脑海中的几个问题：

"10倍工程师"会发生什么变化——平均水平和顶尖水平工程师之间的生产力差距会如何？这个差距很可能会大幅增加。
有了 LLM 的武装，全才是否会日益优于专才？ LLM 在"填空"（微观）方面比"大战略"（宏观）要强得多。
未来的 LLM 编程感觉像什么？像是在玩《星际争霸》？玩《异星工厂》？还是在演奏音乐？
社会中有多少部分正被数字知识工作所瓶颈化？

总结（TLDR）：这一切将把我们带向何方？

LLM 智能体能力（特别是 Claude 和 Codex）在 2025 年 12 月左右跨越了某种连贯性阈值，并引发了软件工程及其相关领域的阶段性转变。智能部分突然感觉比其他所有部分都领先了一大截——包括集成（工具、知识）、新的组织工作流和流程的必要性，以及更广泛的普及。2026 年将是高能的一年，因为整个行业正在消化这种新的能力。

译：我的 AGENTS.md 文件

supercc — Mon, 19 Jan 2026 22:17:35 GMT

原文：https://www.aihero.dev/my-agents-md-file-for-building-plans-you-actually-read
作者：Matt Pocock

大多数开发者最初对 AI 代码生成持怀疑态度。似乎 AI 不可能像你一样理解你的代码库，或者匹配你多年经验积累下来的直觉。

但有一项技术改变了一切：规划循环（planning loop）。你不再是直接要求 AI 编写代码，而是通过一个结构化的循环来工作，这会显著提高你获得的代码质量。

这种方法将 AI 从一个不可靠的代码生成器转变为一个不可或缺的编程伙伴。

规划循环：四步流程

现在，每一段代码都要经过相同的循环。

首先与 AI 进行规划。在编写任何代码之前，共同思考方法。讨论策略并在你要构建的内容上达成一致。

通过要求 AI 编写符合规划的代码来执行。你不是在要求它弄清楚要构建什么——你们已经共同完成了这一步。

共同测试代码。运行单元测试，检查类型安全，或进行手动 QA。验证实现是否符合你的规划。

提交代码并为下一部分再次开始循环。

为什么这很重要

这个循环对于从 AI 获取像样的输出是完全不可或缺的。

如果你完全放弃规划步骤，你实际上是在阻碍自己。你是在要求 AI 猜测你想要什么，最终你会陷入与幻觉和误解的斗争中。

规划强制要求清晰度。它使 AI 的工作变得更容易，也让你的代码变得更好。

创建优秀规划的规则

以下是我 CLAUDE.md 文件中使规划模式有效的关键规则：

## Plan Mode
- Make the plan extremely concise. Sacrifice grammar for the sake of concision.
- At the end of each plan, give me a list of unresolved questions to answer, if any.

这些简单的准则将冗长的规划转变为可扫描、可操作的文档，使你和 AI 保持同步。

将它们复制到你的 CLAUDE.md 或 AGENTS.md 文件中，享受更简单、更具可读性的规划。

或者，运行此脚本将它们附加到你的 ~/.claude/CLAUDE.md 文件中：

mkdir -p ~/.claude && cat >> ~/.claude/CLAUDE.md << 'EOF'
## Plan Mode
- Make the plan extremely concise. Sacrifice grammar for the sake of concision.
- At the end of each plan, give me a list of unresolved questions to answer, if any.
EOF

译：使用 Agent 编程的最佳实践

supercc — Mon, 19 Jan 2026 21:14:40 GMT

原文：https://cursor.com/blog/agent-best-practices
作者：Cursor Team
译者：Claude Opus 4.5

编程 Agent 正在改变软件的构建方式。

模型现在可以运行数小时，完成雄心勃勃的多文件重构，并不断迭代直到测试通过。但要充分发挥 Agent 的作用，需要理解它们的工作原理并开发新的模式。

本指南涵盖了使用 Cursor Agent 的技术。无论你是 Agent 编程的新手，还是想了解我们团队如何使用 Cursor，我们都将介绍使用 Agent 编程的最佳实践。

#理解 Agent 运行环境 (Harness)

Agent 运行环境由三个组件构建而成：

指令 (Instructions)：引导 Agent 行为的系统提示词和规则
工具 (Tools)：文件编辑、代码库搜索、终端执行等
用户消息 (User messages)：指导工作的提示词和后续跟进

Cursor 的 Agent 运行环境为我们支持的每个模型编排这些组件。我们根据内部评估和外部基准，专门为每个前沿模型微调指令和工具。

运行环境之所以重要，是因为不同的模型对相同提示词的反应不同。一个经过大量 shell 工作流训练的模型可能更喜欢 grep 而不是专门的搜索工具。另一个模型可能需要在编辑后显式指令来调用 linter 工具。Cursor 的 Agent 会为你处理这些，因此随着新模型的发布，你可以专注于构建软件。

#从计划开始

你能做出的最有影响力的改变就是在编码前进行计划。

芝加哥大学的一项研究发现，经验丰富的开发人员更有可能在生成代码之前进行计划。计划迫使你清晰地思考正在构建的内容，并为 Agent 提供具体的工作目标。

#使用计划模式 (Plan Mode)

在 Agent 输入框中按 Shift+Tab 切换到计划模式。Agent 不会立即编写代码，而是：

研究你的代码库以找到相关文件
针对你的需求提出澄清问题
创建包含文件路径和代码引用的详细实施计划
在开始构建前等待你的批准

计划模式实战：Agent 提出澄清问题并创建一个可审查的计划。

计划以 Markdown 文件形式打开，你可以直接编辑以删除不必要的步骤、调整方法或添加 Agent 遗漏的内容。

提示： 点击 “Save to workspace” 将计划存储在 .cursor/plans/ 中。这可以为你的团队创建文档，方便恢复中断的工作，并为将来处理同一功能的 Agent 提供背景信息。

并非每个任务都需要详细的计划。对于快速更改或你已经做过多次的任务，直接交给 Agent 处理即可。

#从计划重新开始

有时 Agent 构建的内容不符合你的预期。与其尝试通过后续提示词来修复它，不如回到计划。

撤销更改，改进计划以更具体地说明你的需求，然后再次运行。这通常比修复进行中的 Agent 更快，并且能产生更整洁的结果。

#管理上下文

随着你越来越习惯让 Agent 编写代码，你的工作变成了为每个 Agent 提供完成任务所需的上下文。

#让 Agent 寻找上下文

你不需要在提示词中手动标记每个文件。

Cursor 的 Agent 拥有强大的搜索工具，并按需获取上下文。当你询问 “身份验证流程 (authentication flow)” 时，Agent 会通过 grep 和语义搜索找到相关文件，即使你的提示词中没有包含这些确切的词。

即时 grep 让 Agent 可以在几毫秒内搜索你的代码库。

保持简单：如果你知道确切的文件，就标记它。如果不知道，Agent 会找到它。包含无关文件可能会让 Agent 混淆重点。

Cursor 的 Agent 还有一些有用的工具，比如 @Branch，它可以让你向 Agent 提供关于你正在处理的任务的上下文。"检查此分支上的更改"或"我正在处理什么？"成为引导 Agent 了解你当前任务的自然方式。

#何时开始新对话

一个最常见的问题：我是应该继续这段对话，还是重新开始？

在以下情况下开始新对话：

你正在转向不同的任务或功能
Agent 似乎感到困惑或一直犯同样的错误
你已经完成了一个逻辑单元的工作

在以下情况下继续对话：

你正在迭代同一个功能
Agent 需要讨论早期的上下文
你正在调试它刚刚构建的内容

漫长的对话会导致 Agent 失去焦点。经过多次往返和总结，上下文会积累噪声，Agent 可能会分心或转向无关任务。如果你注意到 Agent 的效率下降，那就是时候开始新对话了。

#引用过去的工作

当你开始新对话时，使用 @Past Chats 来引用之前的工作，而不是复制粘贴整个对话。Agent 可以有选择地从聊天记录中读取内容，只拉取它需要的上下文。

这比复制整个对话更有效率。

#扩展 Agent

Cursor 提供了两种自定义 Agent 行为的主要方式：适用于每个对话的静态上下文 Rules (规则)，以及 Agent 在相关时可以使用的动态能力 Skills (技能)。

#Rules：项目的静态上下文

Rules 提供了持久的指令，塑造了 Agent 处理代码的方式。可以将它们视为 Agent 在每次对话开始时都会看到的"常驻"上下文。

在 .cursor/rules/ 中将规则创建为 markdown 文件：

# Commands

- `npm run build`: Build the project
- `npm run typecheck`: Run the typechecker
- `npm run test`: Run tests (prefer single test files for speed)

# Code style

- Use ES modules (import/export), not CommonJS (require)
- Destructure imports when possible: `import { foo } from 'bar'`
- See `components/Button.tsx` for canonical component structure

# Workflow

- Always typecheck after making a series of code changes
- API routes go in `app/api/` following existing patterns

让规则专注于核心：要运行的命令、要遵循的模式以及指向代码库中典型示例的指针。引用文件而不是复制其内容；这样可以保持规则简短，并防止它们随着代码更改而过时。

Rules 中应避免的内容：

复制整个代码规范指南（请改用 linter）
记录每个可能的命令（Agent 了解常用工具）
为极少出现的边缘情况添加指令

提示： 从简单开始。只有当你注意到 Agent 反复犯同样的错误时，才添加规则。在了解你的模式之前，不要过度优化。

将你的规则提交到 git，以便整个团队受益。当你看到 Agent 犯错时，更新规则。你甚至可以在 GitHub issue 或 PR 上标记 @cursor，让 Agent 为你更新规则。

#Skills：动态能力和工作流

Agent Skills 扩展了 Agent 的能力。Skills 封装了特定领域的知识、工作流和脚本，Agent 可以在相关时调用。

Skills 在 SKILL.md 文件中定义，可以包括：

自定义命令：在 Agent 输入中使用 / 触发的可重用工作流
钩子 (Hooks)：在 Agent 操作之前或之后运行的脚本
领域知识：Agent 可以按需拉取的针对特定任务的指令

与始终包含的 Rules 不同，Skills 是在 Agent 决定它们相关时动态加载的。这保持了你的上下文窗口整洁，同时让 Agent 能够访问专业能力。

#示例：长时间运行的 Agent 循环

一个强大的模式是使用 Skills 来创建长时间运行的 Agent，不断迭代直到实现目标。下面介绍如何构建一个钩子，让 Agent 一直工作到所有测试通过为止。

首先，在 .cursor/hooks.json 中配置钩子：

{
  "version": 1,
  "hooks": {
    "stop": [{ "command": "bun run .cursor/hooks/grind.ts" }]
  }
}

钩子脚本 (.cursor/hooks/grind.ts) 从 stdin 接收上下文，并返回一个 followup_message 以继续循环：

import { readFileSync, existsSync } from "fs";

interface StopHookInput {
  conversation_id: string;
  status: "completed" | "aborted" | "error";
  loop_count: number;
}

const input: StopHookInput = await Bun.stdin.json();
const MAX_ITERATIONS = 5;

if (input.status !== "completed" || input.loop_count >= MAX_ITERATIONS) {
  console.log(JSON.stringify({}));
  process.exit(0);
}

const scratchpad = existsSync(".cursor/scratchpad.md")
  ? readFileSync(".cursor/scratchpad.md", "utf-8")
  : "";

if (scratchpad.includes("DONE")) {
  console.log(JSON.stringify({}));
} else {
  console.log(
    JSON.stringify({
      followup_message: `[Iteration ${
        input.loop_count + 1
      }/${MAX_ITERATIONS}] Continue working. Update .cursor/scratchpad.md with DONE when complete.`,
    })
  );
}

这种模式适用于：

运行（并修复）直到所有测试通过
迭代 UI 直到匹配设计原型
任何结果可验证的目标导向型任务

提示： 带有钩子的 Skills 可以与安全工具、密钥管理器和可观察性平台集成。有关合作伙伴集成，请参阅 hooks 文档。

Agent Skills 目前仅在 nightly 发布渠道中提供。打开 Cursor 设置，选择 Beta，然后将更新渠道设置为 Nightly 并重启。

除了编码之外，你还可以将 Agent 连接到你日常使用的其他工具。MCP (模型上下文协议) 让 Agent 可以读取 Slack 消息、调查 Datadog 日志、调试 Sentry 错误、查询数据库等。

#包含图像

Agent 可以直接从你的提示词中处理图像。你可以粘贴截图、拖入设计文件或引用图像路径。

#设计转代码

粘贴设计原型图，让 Agent 实现它。Agent 能看到图像并匹配布局、颜色和间距。你也可以使用 Figma MCP server。

#视觉调试

对错误状态或非预期的 UI 进行截图，让 Agent 进行调查。这通常比用语言描述问题更快。

Agent 还可以控制浏览器进行截图、测试应用程序并验证视觉更改。详情请参阅 Browser 文档。

浏览器侧边栏让你能够同时进行设计和编码。

#常用工作流

以下是适用于不同类型任务的 Agent 模式。

#测试驱动开发 (TDD)

Agent 可以自动编写代码、运行测试并进行迭代：

让 Agent 根据预期的输入/输出对编写测试。明确告诉它你正在进行 TDD，这样它就会避免为尚不存在的功能创建模拟实现。
告诉 Agent 运行测试并确认测试失败。明确要求它在此阶段不要编写实现代码。
对测试满意后，提交这些测试。
让 Agent 编写通过测试的代码，并指示它不要修改测试。告诉它持续迭代，直到所有测试通过。
对更改满意后，提交实现代码。

当 Agent 有明确的迭代目标时，表现最好。测试允许 Agent 进行更改、评估结果并逐步改进，直到成功。

#理解代码库

在熟悉新代码库时，利用 Agent 进行学习和探索。问它一些你会问同事的问题：

“这个项目中的日志是如何工作的？”
“如何添加一个新的 API 端点？”
“CustomerOnboardingFlow 处理了哪些边缘情况？”
“为什么我们在第 1738 行调用 setUser() 而不是 createUser()？”

Agent 使用 grep 和语义搜索来查看代码库并找到答案。这是快速上手陌生代码的最快方法之一。

#Git 工作流

Agent 可以搜索 git 历史记录、解决合并冲突并自动化你的 git 工作流。

例如，一个 /pr 命令，用于提交、推送并开启 pull request：

Create a pull request for the current changes.

1. Look at the staged and unstaged changes with `git diff`
2. Write a clear commit message based on what changed
3. Commit and push to the current branch
4. Use `gh pr create` to open a pull request with title/description
5. Return the PR URL when done

对于每天运行多次的工作流，使用命令是理想的选择。将它们作为 Markdown 文件存储在 .cursor/commands/ 中并提交到 git，以便整个团队都能使用。

我们使用的其他命令示例：

/fix-issue [number]：通过 gh issue view 获取 issue 详情，找到相关代码，实施修复并开启 PR
/review：运行 linter，检查常见问题，并总结可能需要注意的事项
/update-deps：检查过时的依赖项并逐一更新，每次更新后运行测试

Agent 可以自主使用这些命令，因此你可以通过单个 / 调用来委派多步工作流。

#审查代码

AI 生成的代码需要审查，Cursor 提供了多种选择。

#生成过程中

观察 Agent 的工作过程。diff 视图会实时显示更改。如果你看到 Agent 朝着错误的方向进行，请按 Escape 中断并重新引导。

#Agent 审查

Agent 完成后，点击 Review → Find Issues 来运行专门的审查。Agent 会逐行分析建议的编辑并标记潜在问题。

对于所有本地更改，打开 Source Control 选项卡并运行 Agent Review，将其与你的主分支进行比较。

AI 代码审查直接在 Cursor 中发现并修复 bug。

#用于 pull requests 的 Bugbot

推送到源代码控制系统，以获得 pull requests 的自动审查。Bugbot 应用高级分析，尽早发现问题并在每个 PR 上提出改进建议。

#架构图

对于重大更改，可以让 Agent 生成架构图。尝试提示：“创建一个 Mermaid 图表，显示我们身份验证系统的数据流，包括 OAuth 提供程序、会话管理和令牌刷新。”这些图表对于文档很有用，并且可以在代码审查之前发现架构问题。

#并行运行 Agent

Cursor 让你能够轻松地并行运行多个 Agent，而不会互相干扰。我们发现，让多个模型尝试解决同一个问题并从中选择最佳结果，可以显著提高最终输出的质量，尤其是对于较难的任务。

#原生 worktree 支持

Cursor 为并行运行的 Agent 自动创建并管理 git worktrees。每个 Agent 在各自的 worktree 中运行，文件和更改相互隔离，因此 Agent 可以编辑、构建和测试代码，而不会互相干扰。

要在 worktree 中运行 Agent，请从 Agent 下拉菜单中选择 worktree 选项。当 Agent 完成后，点击 Apply 将其更改合并回你的工作分支。

#同时运行多个模型

一个强大的模式是同时在多个模型上运行同一个提示词。从下拉菜单中选择多个模型，提交提示词，然后并排比较结果。Cursor 还会建议它认为最佳的解决方案。

这对于以下情况特别有用：

不同模型可能采取不同方法的难题
比较不同模型系列的代码质量
发现一个模型可能遗漏的边缘情况

当并行运行多个 Agent 时，请配置通知和声音，以便你了解它们何时完成。

#委派给云端 Agent (Cloud Agents)

云端 Agent 非常适合处理你本来会添加到待办事项列表中的任务：

在处理其他事情时出现的 bug 修复
对近期代码更改的重构
为现有代码生成测试
文档更新

你可以根据任务在本地和云端 Agent 之间切换。从 cursor.com/agents、Cursor 编辑器或手机启动云端 Agent。当你离开座位时，可以通过网页或手机查看会话。云端 Agent 在远程沙盒中运行，因此你可以合上电脑，稍后再查看结果。

从 cursor.com/agents 管理多个云端 Agent

以下是云端 Agent 的底层工作原理：

描述任务和任何相关的上下文
Agent 克隆你的仓库并创建一个分支
它自主工作，完成后开启一个 pull request
完成后你会收到通知（通过 Slack、电子邮件或网页界面）
审查更改并在准备好时合并

提示： 你可以在 Slack 中通过 “@Cursor” 触发 Agent。了解更多。

#用于棘手 bug 的调试模式 (Debug Mode)

当标准 Agent 交互难以解决某个 bug 时，调试模式提供了一种不同的方法。

调试模式不是猜测修复方案，而是：

生成关于可能出现问题的多个假设
在代码中插入日志语句（插桩）
要求你复现 bug，同时收集运行时数据
分析实际行为以精确定位根本原因
基于证据进行针对性修复

这最适用于：

你可以复现但无法理解的 bug
竞态条件和时序问题
性能问题和内存泄漏
以前正常工作但现在出现的回退问题 (Regressions)

关键是提供关于如何复现问题的详细上下文。你提供的越具体，Agent 添加的插桩就越有用。

#建立你的工作流

从 Agent 中获益最多的开发人员通常具备以下几个特质：

他们编写具体的提示词。 有了具体的指令，Agent 的成功率会显著提高。比较一下 “为 auth.ts 添加测试” 和 “为 auth.ts 编写一个覆盖注销边缘情况的测试用例，使用 __tests__/ 中的模式并避免使用 mock”。

他们不断迭代配置。 从简单开始。只有当你注意到 Agent 反复犯同样的错误时，才添加规则。只有在你确定了想要重复的工作流后，才添加命令。在了解你的模式之前，不要过度优化。

他们仔细审查。 AI 生成的代码可能看起来正确，但实际上有细微的错误。阅读 diff 并仔细审查。Agent 工作得越快，你的审查过程就越重要。

他们提供可验证的目标。 Agent 无法修复它不知道的问题。使用静态类型语言，配置 linter 并编写测试。为 Agent 提供关于更改是否正确的清晰信号。

他们将 Agent 视为有能力的合作者。 索要计划。请求解释。拒绝你不喜欢的方法。

Agent 正在飞速改进。虽然模式会随着新模型的出现而演变，但我们希望这些能帮助你在今天使用编程 Agent 时更具生产力。

立即开始使用 Cursor’s agent 来尝试这些技术。

Author: Cursor Team

译：如何在一天内彻底改变你的生活

supercc — Mon, 19 Jan 2026 09:02:08 GMT

原文：https://x.com/thedankoe/status/2010751592346030461
作者：DAN KOE (@thedankoe)
译者：Claude Opus 4.5

如果你和我一样，你也会觉得“新年愿望”很愚蠢。

因为大多数人改变生活的方式完全错误。他们制定这些愿望只是因为别人都在这么做——我们在地位游戏中创造出一些肤浅的意义——但这些愿望并不符合真正改变的要求。真正的改变比说服自己今年要变得更自律或更高效要深刻得多。

如果你也是其中一员，我并不是要贬低你（我在写作时往往有点刻薄）。我放弃的目标比我实现的目标多 10 倍。我认为对大多数人来说情况都是如此。但事实依然是：人们试图改变生活，却几乎每次都以彻底失败告终。

然而，尽管我认为新年愿望很蠢，但反思你所讨厌的生活，从而让自己投身于更好的事物，这始终是明智的，正如我们将要讨论的那样。

所以，无论你是想创业、重塑体型，还是想在不半途而废的情况下冒险追求更有意义的生活，我都想分享 7 个关于行为改变、心理学和生产力的观点，你可能以前从未听过，这些观点能帮你实现在 2026 年的目标。

这将是一份全面的指南。

这不属于那种看完就忘的信件。

这是你会想要收藏、做笔记并专门花时间思考的东西。

结尾处的协议（旨在深入挖掘你的心理并揭示你真正想要的生活）大约需要一整天才能完成，但其效果将持久得多。

让我们开始吧。

第一部分：你不在你想去的地方，是因为你还不是那个能到达那里的人

在设定大目标时，人们通常关注成功的两个要求之一：

改变行动以朝着目标前进（最不重要，二阶因素）
改变你是谁，让你的行为自然而然地发生（最重要，一阶因素）

大多数人设定一个表面的目标，在最初几周亢奋地保持自律，然后就不费吹灰之力地回到了老样子。这是因为他们试图在腐烂的基础上建立伟大的生活。

如果这听起来难以理解，让我们来看一个例子。

想象一个成功人士。他可能是一个拥有完美体格的健身者，一个身价数亿的创始人/CEO，或者一个极具魅力、能毫无焦虑地与人群谈笑风生的男人。

你认为健身者为了吃得健康必须“死磕”吗？CEO 为了到场领导团队必须强迫自律吗？在你看来，表面上似乎是这样，但事实是他们无法想象自己以任何其他方式生活。健身者要吃得不健康才需要死磕。CEO 必须强迫自己睡过闹钟，而且他们讨厌那一分一秒。

对某些人来说，我自己的生活方式似乎有点极端和自律。但对我而言，这很自然。我只是喜欢这样生活。

如果你想要生活中特定的结果，你必须在达到它之前很久，就拥有创造该结果的生活方式。

如果有人说想减掉 30 磅，我通常不相信他们。不是因为我认为他们没能力，而是因为有太多次同一个人会说：“我等不及减完肥，好重新开始享受生活了。”如果你不终身采取那种让你减轻体重的社交方式，你就会直接回到起点。

当你真正改变自己时，所有那些不能让你朝着目标前进的习惯都会变得令人厌恶。因为你深刻地意识到，这些行为会复合成什么样的生活。

第二部分：你不在你想去的地方，是因为你并不想去那里

“只相信行动。生命发生在事件层面，而非言语层面。相信行动。” —— 阿尔弗雷德·阿德勒

如果你想改变你是谁，你必须理解心智是如何运作的，这样你才能开始对其进行重编程。

所有的行为都是以目标为导向的。这是目的论。大多数时候，你的目标是潜意识的。你向前迈出一步是因为你想到达某个位置。

在更深层的潜意识和更复杂的层面上，你会追求那些可能伤害你的目标，但你会以社会可接受的方式为自己的行为辩解。如果你无法停止拖延，你可能会以缺乏自律为由进行辩解，但实际上，你可能是在保护自己免受完成并分享作品后带来的评判。

真正的改变需要改变你的目标。目标是对未来的投射，它充当了感知的透镜。

第三部分：你不在你想去的地方，是因为你害怕到达那里

“你需要记住的重要一点是，你如何得到这个想法或它来自哪里根本不重要……如果你接受了一个想法……而且，如果你坚信这个想法是真的，它对你的控制力就像催眠师的话语对受试者的控制力一样。” —— 麦克斯韦·莫尔茨

身份的解剖：

你想要实现一个目标
你通过那个目标的透镜观察现实
你只注意到“重要”的信息（学习）
你采取行动并接收反馈
你不断重复直到自动化（条件反射）
这种行为成为你对自我认知的一部分
你捍卫自己的身份以保持心理一致性
你的身份塑造了新的目标

这个过程始于童年。你拥有生存的目标。你依赖父母并顺从他们的信念以避免惩罚。

当你的身份感到受到威胁时，你会进入“战斗或逃跑”状态。如果你对某种政治意识形态或宗教有强烈的认同感，当受到挑战时你会感到压力。当你潜意识里把自己视为一名律师、一名游戏玩家，或者是一个不会采取行动追求更好生活的人时，情况也是如此。

第四部分：你想要的生活存在于特定的意识层面

心智通过可预测的阶段进化（基于马斯洛、格罗伊特、螺旋动力学等）：

冲动型 — 冲动与行动之间没有分离。
自我保护型 — 世界是危险的；只顾好你自己。
从众型 — 你就是你的群体及其规则。
自我意识型 — 你注意到内在生活与外在世界不符。
尽责型 — 你建立了自己的原则体系。
个人主义型 — 你看到你的原则是由背景塑造的。
战略家型 — 在意识到自己参与其中的同时，与系统协作。
建构意识型 — 你将所有框架视为有用的虚构。
统一型 — 自我与生命之间的界限消解。

跨越这些阶段遵循一定的模式。

第五部分：智力是过上你想要的生活的能力

“智力的唯一真正测试是看你是否得到了你想要的生活。” —— 纳瓦尔·拉维康特

成功公式：能动性 + 机会 + 智力。

控制论（源自 kybernetikos，意为“操舵”）是“获取所想之物的艺术”。

设定一个目标。
朝着它行动。
感知你所处的位置。
将其与目标进行比较。
根据反馈再次行动。

高智力是迭代、坚持和理解全局的能力。低智力是无法从错误中学习。

为了变得更聪明：

拒绝已知的路径
潜入未知
设定新的、更高的目标
拥抱混乱
研究普世原理
成为深度全才

第六部分：如何开启全新的生活（在 1 天内）

真正的改变发生在紧张感积累之后：

不协调 – 对缺乏进展感到厌烦。
不确定性 – 不知道接下来会发生什么。
发现 – 发现要追求的目标并取得飞速进展。

第一阶段：早晨 – 心理挖掘

你已经习惯忍受的那种沉闷且持久的不满是什么？
你反复抱怨但从未真正改变的事情是什么？
关于你目前的生活，有哪些真相是让你难以启齿承认的？

反向愿景：

描述一下如果一切照旧，5 年后的一个普通周二会是什么样子。
描述一下 10 年后的样子。
在你生命的尽头，保持“安全”的代价是什么？

愿景 MVP（最小可行性愿景）：

如果你可以打个响指，在 3 年后过上不同的生活，那个周二会是什么样子？
为了让那种生活感觉自然，你必须对自己抱有什么样的信念？

第二阶段：全天 – 中断自动驾驶状态

为这些问题设置提醒：

上午 11:00：我现在正在逃避什么？
下午 1:30：如果把过去 2 小时拍成电影，观众会得出我想要什么的结论？
下午 5:00：我正在假装不重要的最重要的事情是什么？

第三阶段：晚上 – 综合见解

经过今天，关于你为何停滞不前，什么感觉最真实？
写下一句话，概括你的“反向愿景”和“愿景 MVP”。

将目标视为一种视角：

一年视角： 一件能证明你打破了旧模式的具体事情。
一月视角： 为了让一年目标保持可能，必须实现什么？
每日视角： 那个你正在成为的人会简单执行的 2-3 个行动。

第七部分：把你的生活变成电子游戏

整理你的见解：

反向愿景 = 输掉/放弃的代价。
愿景 = 获胜的方式。
一年目标 = 任务。
一月项目 = Boss 战。
每日杠杆 = 任务/日常。
约束条件 = 规则。

你玩得越多，抵御干扰的力场就越强。

🔒 620 - 《Agent Browser》

supercc — Sun, 18 Jan 2026 19:56:07 GMT

昨晚用了下 Agent browser，感觉还是挺惊艳的，做下记录。他可以把现有的浏览器给利用起来。开一个 remote port 的端口，启动之后，就可以用这个库来连接它，并且做相应的控制。然后背后去接大模型，就能够通过 AI 去控制你现有的浏览器去做很多的事情。

🔒 会员专享内容

此文章的完整内容仅对会员开放。

→ 点击查看完整内容

需要登录并验证邮箱才能访问受限内容。

🔒 619 - 《Google 账号》

supercc — Tue, 13 Jan 2026 13:06:55 GMT

🔒 会员专享内容

此文章的完整内容仅对会员开放。

→ 点击查看完整内容

需要登录并验证邮箱才能访问受限内容。

🔒 618 - 《Linux DO》

supercc — Tue, 13 Jan 2026 11:29:28 GMT

🔒 会员专享内容

此文章的完整内容仅对会员开放。

→ 点击查看完整内容

需要登录并验证邮箱才能访问受限内容。

🔒 617 - 《如何获取 Agent 提供的能力或 Tools》

supercc — Wed, 07 Jan 2026 13:58:55 GMT

Wrote copilot with AI.

🔒 会员专享内容

此文章的完整内容仅对会员开放。

→ 点击查看完整内容

需要登录并验证邮箱才能访问受限内容。

译：动态上下文发现

supercc — Wed, 07 Jan 2026 11:01:18 GMT

原文：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 中使用动态上下文发现的方式：

将长工具响应转换为文件
在摘要过程中引用聊天历史
支持 Agent Skills 开放标准
高效加载仅需要的 MCP 工具
将所有集成终端会话视为文件

1. 将长工具响应转换为文件

工具调用可能会通过返回大型 JSON 响应来大幅增加上下文窗口。

对于 Cursor 中的第一方工具，如编辑文件和搜索代码库，我们可以通过智能工具定义和最小响应格式来防止上下文膨胀，但第三方工具（即 shell 命令或 MCP 调用）原生并没有得到同样的处理。

编程智能体采取的常见方法是截断长 shell 命令或 MCP 结果。这可能导致数据丢失，其中可能包含你想要在上下文中保留的重要信息。在 Cursor 中，我们改为将输出写入文件，并赋予智能体读取它的能力。智能体调用 tail 检查末尾，然后在需要时读取更多内容。

这减少了在达到上下文限制时不必要的摘要操作。

2. 在摘要过程中引用聊天历史

当模型的上下文窗口填满时，Cursor 会触发一个摘要步骤，为智能体提供一个新的上下文窗口，其中包含其迄今为止工作的摘要。

但是智能体的知识在摘要后可能会退化，因为这是对上下文的有损压缩。智能体可能已经忘记了关于其任务的关键细节。在 Cursor 中，我们使用聊天历史作为文件来提高摘要的质量。

在达到上下文窗口限制后，或者用户决定手动进行摘要时，我们会给智能体一个历史文件的引用。如果智能体知道它需要摘要中缺失的更多细节，它可以搜索历史记录来恢复它们。

3. 支持 Agent Skills 开放标准

Cursor 支持 Agent Skills，这是一个用于扩展编程智能体专业能力的开放标准。与其他类型的 Rules 类似，Skills 由文件定义，告诉智能体如何执行特定领域的任务。

Skills 还包括名称和描述，可以作为"静态上下文"包含在系统提示中。然后智能体可以进行动态上下文发现来拉取相关的 skills，使用 grep 和 Cursor 的语义搜索等工具。

Skills 还可以捆绑与任务相关的可执行文件或脚本。由于它们只是文件，智能体可以轻松找到与特定 skill 相关的内容。

4. 高效加载仅需要的 MCP 工具

MCP 有助于访问 OAuth 保护的安全资源。这可能包括生产日志、外部设计文件，或企业的内部上下文和文档。

一些 MCP 服务器包含许多工具，通常带有冗长的描述，这会显著膨胀上下文窗口。大多数这些工具即使始终包含在提示中也从未被使用。如果你使用多个 MCP 服务器，这个问题会更加严重。

期望每个 MCP 服务器都为此进行优化是不现实的。我们认为减少上下文使用是编程智能体的责任。在 Cursor 中，我们通过将工具描述同步到文件夹来支持 MCP 的动态上下文发现。

智能体现在只接收少量静态上下文，包括工具名称，提示它在任务需要时查找工具。在 A/B 测试中，我们发现在调用 MCP 工具的运行中，这一策略将智能体总 token 减少了 46.9%（统计显著，根据安装的 MCP 数量有较高方差）。

这种文件方法还解锁了向智能体传达 MCP 工具状态的能力。例如，以前如果 MCP 服务器需要重新认证，智能体会完全忘记那些工具，让用户感到困惑。现在，它实际上可以主动让用户知道需要重新认证。

5. 将所有集成终端会话视为文件

用户不再需要将终端会话的输出复制/粘贴到智能体输入中，Cursor 现在将集成终端输出同步到本地文件系统。

这使得询问"为什么我的命令失败了？"变得很容易，并允许智能体理解你所引用的内容。由于终端历史可能很长，智能体可以 grep 只获取相关输出，这对于像服务器这样的长时间运行进程的日志很有用。

这反映了基于 CLI 的编程智能体所看到的内容，上下文中包含先前的 shell 输出，但是动态发现而非静态注入。

简单的抽象

目前尚不清楚文件是否会成为基于 LLM 的工具的最终接口。

但随着编程智能体的快速进步，文件一直是一个简单而强大的原语，比起又一个无法完全预见未来的抽象层，它是一个更安全的选择。敬请期待我们在这个领域分享更多令人兴奋的工作。

这些改进将在未来几周内对所有用户上线。本博客文章中描述的技术是许多 Cursor 员工的工作成果，包括 Lukas Moller、Yash Gaitonde、Wilson Lin、Jason Ma、Devang Jhabakh 和 Jediah Katz。如果你对使用 AI 解决最困难、最雄心勃勃的编程任务感兴趣，我们很乐意听取你的意见。请通过 [email protected]">[email protected] 联系我们。

Author: Jediah Katz

译：以推理速度交付

supercc — Mon, 05 Jan 2026 16:29:51 GMT

原文： 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 vs Opus#

我正在写这篇文章的时候，Codex 正在处理一个巨大的、耗时数小时的重构，并清理 Opus 4.0 留下的旧烂摊子。Twitter 上的人经常问我 Opus 和 Codex 之间有什么大区别，既然基准测试如此接近，为什么这很重要。依我看，越来越难以信任基准测试了——你需要亲自尝试两者才能真正理解。无论 OpenAI 在后训练阶段做了什么，Codex 在开始之前已经被训练成会阅读大量的代码。

有时它只是静静地阅读文件 10 到 15 分钟，然后才开始写代码。一方面这很烦人，另一方面这又很棒，因为它大大增加了修复正确问题的几率。另一方面，Opus 更加急切——非常适合小的修改——但不太适合较大的功能或重构，它经常不阅读整个文件或遗漏部分内容，然后交付低效的结果或遗漏某些东西。我注意到，即使 Codex 有时在类似任务上花费的时间是 Opus 的 4 倍，我通常还是更快，因为我不必回头去修复那个修复，这在我还在使用 Claude Code 时感觉是很常态的事情。

Codex 还让我摒弃了许多在使用 Claude Code 时必需的伪装。我不再使用“计划模式”，而是简单地与模型开始对话，提出问题，让它去 Google、探索代码、共同制定计划，当我对我看到的内容感到满意时，我写下“构建”或“将计划写入 docs/*.md 并构建这个”。计划模式感觉像是一种黑客手段，对于旧一代不太擅长遵循提示词的模型来说是必要的，所以我们不得不剥夺它们的编辑工具。有一条被高度误解的推文至今仍在流传，这向我表明大多数人并不明白计划模式并非魔法。

Oracle#

从 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#

再举一个例子来说明模型已经发展到了什么程度。我早期的一个高强度项目是 VibeTunnel。一个终端复用器，让你可以随时随地编码。今年早些时候，我几乎把所有时间都投入到了这个项目中，2 个月后它变得非常好用，以至于我发现自己在和朋友外出时还在用手机写代码……于是我决定停止这个项目，更多是为了心理健康。当时我试图将复用器的一个核心部分从 TypeScript 重写，但旧模型总是让我失望。我试过 Rust、Go……上帝保佑，甚至试过 Zig。当然我可以完成这个重构，但这需要大量的手工工作，所以我从未在将其搁置之前完成这项工作。上周我把它重新翻出来，给 Codex 一个两句话的提示词，要求将整个转发系统转换为 Zig，它运行了超过 5 个小时，进行了多次压缩，并且一次性交付了一个可工作的转换版本。

你可能会问，我为什么要把它翻出来？我目前的重点是 Clawdis，这是一个 AI 助手，拥有对我所有电脑、消息、邮件、家庭自动化、摄像头、灯光、音乐的完全访问权限，甚至可以控制我床的温度。当然它还有自己的声音、发推特的 CLI 和它自己的 Twitter 账号。

Clawd 可以看到并控制我的屏幕，有时会发表讽刺性的评论，但我也想让它能够检查我的智能体，获取字符流比查看图像要高效得多……这是否行得通，我们拭目以待！

我的工作流#

我知道……你来这里是想学习如何更快地构建，而我只是在为 OpenAI 写营销软文。我希望 Anthropic 正在酝酿 Opus 5，局势能再次逆转。竞争是好事！同时，我爱 Opus 作为通用模型。如果运行在 GPT 5 上，我的 AI 智能体的乐趣会少一半。Opus 有某种特殊的东西，让与之合作成为一种乐趣。我用它来处理我大部分的计算机自动化任务，当然也是它驱动了 Clawd🦞。

自十月份我上次谈论这个问题以来，我的工作流并没有太大改变。

我通常同时在多个项目上工作。根据复杂程度，可能在 3-8 个之间。上下文切换可能会很累人，我真的只能在家里、安静且精神集中的时候这样做。这需要在大脑中切换很多心理模型。幸运的是，大多数软件都很无聊。创建一个 CLI 来检查你的外卖并不需要太多思考。通常我的重点是一个大项目和一些伴随进行的卫星项目。当你做了足够多的智能体工程，你会对什么是容易的、模型可能在哪里挣扎产生一种感觉，所以通常我只是输入一个提示词，Codex 会运行 30 分钟，我就得到了我需要的东西。有时需要一点微调或创造力，但通常事情都很直截了当。
我广泛使用 Codex 的排队功能——当我有新想法时，我把它加入管道。我看到许多人尝试各种多智能体编排系统、电子邮件或自动任务管理——到目前为止，我没看到这有多大必要——通常瓶颈在我自己。我构建软件的方法是非常迭代的。我构建一些东西，玩一下，看看它“感觉”如何，然后获得新想法来改进它。我很少在脑海中对想要的东西有一个完整的图景。当然，我有一个粗略的想法，但随着我探索问题领域，这个想法通常会发生巨大的变化。所以那些以完整的想法作为输入然后交付输出的系统对我来说效果不佳。我需要把玩它，触摸它，感受它，看到它，这就是我演进它的方式。
我基本上从不回滚或使用检查点。如果有些东西我不喜欢，我会要求模型更改它。Codex 有时会重置文件，但通常它只是简单地回滚或修改编辑，我很少需要完全回退，相反我们只是转向不同的方向。构建软件就像登山。你不会直直地走上去，你会绕着它转，转弯，有时你会偏离路径，不得不往回走一点，这并不完美，但最终你会到达你需要去的地方。
我只是简单地提交到 main 分支。有时 Codex 认为太乱了，会自动创建一个 worktree 然后将更改合并回来，但这很少见，我只在特殊情况下提示这样做。我发现必须考虑项目中不同状态的额外认知负担是不必要的，我更喜欢线性地演进它。更大的任务我留到我分心的时候做——例如在写这篇文章时，我在这里运行 4 个项目的重构，每个大约需要 1-2 小时完成。当然我可以在 worktree 中做，但这只会导致大量的合并冲突和次优的重构。警告：我通常独自工作，如果你在更大的团队中工作，这种工作流显然行不通。
我已经提到了我规划功能的方式。我一直在交叉引用项目，特别是如果我知道我已经在其他地方解决了某个问题，我会让 Codex 查看 ../project-folder，这通常足以让它从上下文中推断出在哪里查找。这对于节省提示词非常有用。我可以只写“查看 ../vibetunnel 并为 Sparkle changelogs 做同样的事情”，因为它已经在那里解决了，而且有 99% 的保证它会正确地复制过来并适应新项目。这也是我搭建新项目的方式。
我见过很多系统是为了让人们引用过去的会话。这是另一件我从不需要或使用的东西。我在每个项目的 docs 文件夹中维护子系统和功能的文档，并在我的全局 AGENTS 文件中使用一个脚本 + 一些指令来强制模型阅读关于特定主题的文档。项目越大，回报越高，所以我并非在所有地方都使用它，但这对于保持文档最新和为我的任务设计更好的上下文非常有帮助。
说到上下文。我过去非常勤奋地为新任务重启会话。有了 GPT 5.2，这不再需要了。即使上下文较满，性能也非常好，而且通常这有助于提高速度，因为当模型已经加载了大量文件时，它的工作速度更快。显然，这只有在你串行化任务或保持更改间隔较远以至于两个会话互不影响时才有效。Codex 没有像 Claude Code 那样的“此文件已更改”的系统事件，所以你需要更加小心——反过来说，Codex 在上下文管理方面要好得多，我觉得在一个 Codex 会话中完成的工作量是用 Claude 的 5 倍。这不仅仅是客观上更大的上下文窗口，还有其他因素在起作用。我的猜测是 Codex 内部思维非常精简以节省 Token，而 Opus 非常啰嗦。有时模型会搞砸，其内部思维流会泄露给用户，所以我已经见过好几次了。真的，Codex 的措辞方式我觉得奇怪地有趣。
提示词。我过去常用语音听写写很长、详尽的提示词。有了 Codex，我的提示词变得短了很多，我经常重新打字，而且很多时候我会添加图片，尤其是在迭代 UI（或带有 CLI 的文本副本）时。如果你向模型展示哪里出了问题，只需几个字就足以让它做你想做的事。是的，我就是那种拖入某个 UI 组件的截图并附上“修复填充”或“重新设计”的人，很多时候这要么解决了我的问题，要么让我取得了相当大的进展。我过去常引用 markdown 文件，但有了我的 docs:list 脚本，这不再必要了。
Markdown。很多时候我写“将文档写入 docs/*.md”，然后简单地让模型选择文件名。你为模型训练的内容设计的结构越明显，你的工作就越容易。毕竟，我不是将代码库设计成便于我导航，我是为了让智能体能高效地在其中工作而设计它们。与模型对抗通常是浪费时间和 Token。

工具与基础设施#

==什么依然很难？ 选择正确的依赖项和框架来构建是我投入相当多时间的地方。这个维护得好吗？对等依赖项怎么样？它流行吗 = 是否会有足够的世界知识让智能体轻松上手？同样，系统设计。我们要通过 Web Socket 通信吗？HTML？我把什么放在服务器端，什么放在客户端？数据如何流向哪里？通常这些是向模型解释起来有点难的地方，研究和思考会有回报。==
由于我管理很多项目，通常我让一个智能体简单地在我的项目文件夹中运行，当我找出一个新模式时，我会要求它“找到我所有最近的 Go 项目并在那里也实施此更改 + 更新变更日志”。我的每个项目在那个文件中都有一个提升的补丁版本，当我重新访问它时，一些改进已经在等着我测试了。
当然我自动化一切。有一个 Skill 是注册域名和更改 DNS。一个 Skill 是编写好的前端。我的 AGENTS 文件中有一个关于我的 Tailscale 网络的注释，所以我可以直接说“去我的 Mac Studio 更新 xxx”。
说到多台 Mac。我通常在两台 Mac 上工作。我的 MacBook Pro 在大屏幕上，另一个屏幕上是通过 Jump Desktop 连接到我的 Mac Studio。一些项目在那里运行，一些在这里。有时我在每台机器上编辑同一个项目的不同部分，并通过 git 同步。比 worktree 简单，因为 main 分支上的偏差很容易协调。额外的好处是，任何需要 UI 或浏览器自动化的东西我都可以移到我的 Studio 上，它不会用弹窗打扰我。（是的，Playwright 有无头模式，但有足够多的情况那行不通）
另一个好处是任务保持运行，所以每当我旅行时，远程就成了我的主要工作站，即使我合上 Mac，任务也会继续运行。我过去确实尝试过像 Codex 或 Cursor web 这样真正的异步智能体，但我怀念那种可操控性，而且最终工作结果是拉取请求（PR），这又给我的设置增加了复杂性。我更喜欢终端的简单性。
我过去常玩斜杠命令（slash commands），但从未觉得它们太有用。技能（Skills）取代了其中一部分，对于其余部分，我坚持写“commit/push”，因为它花费的时间与 /commit 相同，而且总是有效。
过去我经常花专门的日子来重构和清理项目，现在我更多是临时做这件事。每当提示词开始耗时太长，或者我看到代码流中有丑陋的东西飞过，我会立即处理它。
我尝试过 Linear 或其他问题追踪器，但没有坚持下来。重要的想法我会立即尝试，其他所有东西我要么记得住，要么它不重要。当然，对于使用我的开源代码的人，我有公开的 bug 追踪器，但当我发现一个 bug 时，我会立即提示它——比写下来然后稍后必须切换上下文回去处理要快得多。
无论你构建什么，首先从模型和 CLI 开始。我脑海中有一个总结 YouTube 视频的 Chrome 扩展的想法已经很久了。上周我开始开发 summarize，这是一个 CLI，可以将任何内容转换为 markdown，然后将其提供给模型进行总结。首先我把核心部分搞定，一旦那个工作得很好，我在一天内构建了整个扩展。我很喜欢它。在本地、免费或付费模型上运行。在本地转录视频或音频。与本地守护进程对话，所以速度超快。试一试！
我首选的模型是 gpt-5.2-codex high。再次强调，KISS 原则。除了慢得多之外，xhigh 几乎没有什么好处，我不想花时间思考不同的模式或“过度思考”。所以几乎所有东西都在 high 上运行。GPT 5.2 和 Codex 足够接近，更改模型没有意义，所以我只用那个。

我的配置#

这是我的 ~/.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年，AI写了我大部分的代码。然后呢？

supercc — Mon, 05 Jan 2026 11:22:26 GMT

原文：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 代码，并实际对设备上的硬件进行编程。这简直太疯狂了。

六个月前或一年前，我甚至不会尝试这些项目，而现在它们对我来说实际上非常容易完成。

我加入 Cursor 的历程

大约九个月前，我发布了一个视频，讲述我如何尝试了一堆文本编辑器和 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 构建过一些游戏，但那非常不同，抽象层次高得多。我能够向模型提问并在这方面取得显著进展，现在我理解了它的工作原理，可以从头开始构建新游戏。

我对2026年的4条建议

建议一：期待模型在所有领域都变得擅长

对所有这些的自然反应是：“是的，我做的这件事模型还不太擅长，所以这意味着模型永远不会变好。”

我曾经对 Rust、底层代码或详细的计算机科学主题也有这种感觉。然后最近，模型在这些方面变得非常好了。

如果我是你，我会预期在未来一年内，模型将在软件工程中你需要编写代码的大多数事情上变得擅长。

这并不意味着软件工程已死或我们不会有工作。我实际上认为恰恰相反——对软件工程师和实际使用这些工具的人的需求将比以往任何时候都大。这有点矛盾，但我认为历史已经证明了这一点。

在学习这些工具时——无论你想用什么编程代理：Cursor、Codex、Claude Code 等等——你将比那些更犹豫或怀疑的人获得显著优势。学会很好地使用它们可以让你大大领先。

建议二：消除繁琐的工作

使用这些工具来消除所有繁琐的工作——那些你不想做的事情。

很多软件工程实际上是在复制和移动 JSON 文件、弄清楚为什么 shell 脚本不工作、试图调试一些奇怪的错误信息。有很多样板代码，很多你只是从 Stack Overflow 或 Google 复制粘贴的东西。

用编程代理来处理那些事情。摆脱所有无聊的东西，专注于对最终产品真正重要的事情。

既然代码变得廉价，真正重要的是你的品味。作为工程师，越来越多地要成为一个多面手。这不仅仅是代码——还有：我们正在构建什么产品？它看起来怎么样？它如何运作？用户体验如何？我们要如何销售这个东西？我们如何营销这个东西？

建议三：成为多面手，构建完整产品

去构建东西。成为多面手。实际尝试构建某物的整个过程。

不要只是写代码然后发布——把它推向世界，营销它，获取用户，构建人们喜爱的东西，发展产品，弄清楚要构建什么正确的东西。

作为软件工程师，这些技能在未来一到三年内将对你非常有价值。随着这个职业的变化，那些拥抱 AI 来更好地完成工作的产品工程师将拥有显著的优势。

如果你想了解更多，我有一篇关于产品工程师的完整文章。这个趋势在我2024年写这篇文章时就已经在发生了，但随着 AI 进入2026年，它现在大大加速了。

建议四：花时间真正学习

如果你过度依赖 LLM，它们可能会欺骗你，让你认为你理解了一个话题。你不想把思考委托给代理。你想用它们来变得更聪明。

你怎么做到？向模型问很多问题。就像你身边一直有一个很棒的结对程序员，你可以问无限多的问题，他永远不会生你的气或认为这是个愚蠢的问题。

我最近一直在做的一件事：我会让模型为我生成基本上是一个迷你课程——引导我了解对我来说完全陌生的主题。“向我解释什么是 Verilog 以及语法如何工作。向我解释从硬件到我实际编写的代码的不同抽象层以及它是如何编译的。”

这些东西可以使按需学习变得更加容易，而不必阅读10本教科书。如果你有主动性和意愿去学习这些东西，你现在就可以获得巨大的优势。

资源

leerob.com/ai - 关于 LLM 底层工作原理的简洁文章
cursor.com/learn - 编程 AI 基础课程（tokens、上下文窗口等）

结语

我和你们一样在摸索。这有点奇怪——有时候会有一点存在危机感，因为感觉你正在失去你真正热爱的一部分，那就是构建东西。

但对我来说，我必须记住：这不是关于代码的。写代码在很多方面从来都不是瓶颈。这是关于构建伟大的东西，我引以为豪的东西，我认为真正好的东西。而这远不止是代码。

所以现在：既然我有了这个很棒的工具，我该如何使用 AI 来更好地提升我的技艺？

这就是我对2026年的想法。这将是伟大的一年。我很乐观。我认为我们将会有很多积极的事情。

和平。

译：仅使用 TypeScript 中的 bash 和文件系统构建 AI 代理

supercc — Sun, 04 Jan 2026 15:10:45 GMT

原文： https://turso.tech/blog/agentfs-just-bash
作者： Pekka Enberg
译者： Gemini 3 Pro High

2026年1月2日

Bash 是你能给予 AI 代理的最有效工具之一。基础模型在训练过程中接触过大量的 Shell 脚本，因此它们能够熟练使用 grep、sed、awk 和 cat 等命令。给代理一个 Bash 访问权限，它就能探索数据、处理文本和操作文件，而无需为每个任务使用自定义工具。

问题在于，真正的 Bash 需要真正的 Shell 和文件系统。这意味着要么在具有适当隔离的服务器上运行，要么启动容器，或者接受让代理在你的机器上运行命令的安全风险。如果你想在像 Cloudflare Workers 这样的轻量级环境中部署代理，或者想避免容器编排的成本和复杂性，这些选项都不太适用。

然而，来自 Vercel 的 Malte Ubl 最近发布了 just-bash，它通过完全用 TypeScript 重新实现 Bash 解决了这个问题。它不是一个真正 Shell 的包装器——它是对编码代理实际使用的命令（grep, sed, awk, jq, cat, ls 等）的从头实现。你把它作为一个工具提供给你的代理。代理运行 Shell 命令。这些命令在你的 JavaScript 进程中执行，无法访问你的宿主文件系统。

如何工作？

just-bash 包在 TypeScript 中实现了 Bash 及其许多命令。默认情况下，它使用内存文件系统，但也提供了一个可插拔的文件系统接口，这使其成为 AgentFS 的一个明显的集成点。

它的工作原理是，当你的代理执行诸如 cat /README.md 之类的命令时，just-bash 会向 AgentFS 请求该文件，而 AgentFS 使用 Turso 从 SQLite 数据库文件中读取它。代理并不知道它没有运行真正的 Shell。但每个文件都存在于数据库中，每一次更改都被捕获，代理无法逃逸到你的宿主文件系统。

示例：AI SDK 集成

以下是在 AI SDK 中如何将 just-bash 与 AgentFS 连接起来：

import { agentfs } from "agentfs-sdk/just-bash";
import { createBashTool } from "just-bash/ai";
import { streamText } from "ai";

const fs = await agentfs({ id: "ai-agent-1" });
const bashTool = createBashTool({ fs });

const result = streamText({
  tools: { bash: bashTool },
});

如你所见，我们首先打开一个 agentfs 文件系统，然后使用 just-bash 包创建一个 bash 工具，并将其提供给 AI SDK 供基础模型使用。

虽然 AgentFS 是建立在 Turso 之上的，但同样的方法通过 agentfs-sdk/cloudflare 集成也适用于 Cloudflare Workers，该集成使用 Cloudflare 的托管 SQLite。你使用 just-bash 和 AgentFS 的方式完全相同，只是用到了一些 Cloudflare Worker API：

import { DurableObject } from "cloudflare:workers";
import { streamText } from "ai";
import { createBashTool } from "just-bash/ai";
import { AgentFS } from "agentfs-sdk/cloudflare";
import { agentfs } from "agentfs-sdk/just-bash";

export class Agent extends DurableObject {
  private fs = AgentFS.create(this.ctx.storage);

  async chat(message: string) {
    const bashFs = await agentfs({ fs: this.fs });
    const bashTool = createBashTool({ fs: bashFs });

    const result = streamText({
      tools: { bash: bashTool },
    });

    return result.toDataStream();
  }
}

何时使用 just-bash

AgentFS 根据你的需求支持不同的集成模式：

直接 SDK 调用 最适合构建自定义工具（PDF 解析器、代码分析器）时使用。你在工具实现中直接调用 AgentFS，这给了你完全的控制权。

agentfs run 或 agentfs mount 赋予你宿主系统的全部能力。将 AgentFS 挂载到文件系统，你的代理就可以使用任何工具：git、ffmpeg、语言运行时。这需要系统级设置，但对可用命令没有限制。

just-bash 是折衷方案。代理获得透明的 Bash 访问权限——它认为自己正在运行 Shell 命令——但一切都停留在 TypeScript 中。没有容器，没有特定于平台的配置，可在任何 JavaScript 运行的地方运行。权衡在于你仅限于 just-bash 实现的内容，这涵盖了常用命令但并非全部。

对于许多代理应用来说，just-bash 是正确的选择：对模型透明，包含在你的进程中，可部署在任何地方。

开始使用

just-bash 和 Cloudflare Worker 集成在 AgentFS 0.4.1 中可用。有关完整示例，请参阅 GitHub 仓库。

译：Boris Cherny 的 Claude Code 使用指南

supercc — Sat, 03 Jan 2026 23:56:06 GMT

原文： https://threadreaderapp.com/thread/2007179832300581177.html
作者： Boris Cherny
译者： Gemini 3 Pro High

我是 Boris，我创建了 Claude Code。很多人问我是如何使用 Claude Code 的，所以我想稍微展示一下我的设置。

我的设置可能出奇地普通！Claude Code 开箱即用，效果很好，所以我个人并没有对其进行太多定制。使用 Claude Code 没有一种所谓的"正确"方式：我们特意将其构建为您可以随意使用、定制和修改的方式。Claude Code 团队中的每个人使用它的方式都截然不同。

那么，开始吧。

1. 终端中并行运行多个 Claude 实例

我在终端中并行运行 5 个 Claude。我将标签页编号为 1-5，并使用系统通知来获知 Claude 何时需要输入。

参考文档： 优化您的终端设置

当您的终端配置得当时，Claude Code 的效果最佳。请遵循这些指南以优化您的体验。

2. Web 端与本地端协同工作

我还在 claude.ai/code 上并行运行 5-10 个 Claude，与我本地的 Claude 一起运行。当我在终端中编写代码时，我经常会将本地会话移交给 Web 端（使用 &），或者在 Chrome 中手动启动会话，有时我会在两者之间使用 --teleport 来回切换。我还在每天早上和一天中的其他时间通过手机（使用 Claude iOS 应用程序）启动一些会话，稍后再查看它们。

3. 使用 Opus 4.5 with Thinking

我使用带有思维链的 Opus 4.5 处理所有事情。这是我用过的最好的编码模型，尽管它比 Sonnet 更大且更慢，但因为你需要更少地引导它，而且它更擅长使用工具，所以最终它几乎总是比使用较小的模型更快。

4. 团队共享 CLAUDE.md 文件

我们的团队为 Claude Code 仓库共享一个 CLAUDE.md 文件。我们将它检入 git，整个团队每周都会多次贡献内容。每当我们看到 Claude 做错事时，我们都会将其添加到 CLAUDE.md 中，这样 Claude 下次就知道不要再这样做了。

其他团队维护他们自己的 CLAUDE.md。保持文件更新是每个团队的工作。

5. 代码审查中使用 Claude

在代码审查期间，我经常会在同事的 PR 上标记 @.claude，以便作为 PR 的一部分向文件中添加内容。我们为此使用 Claude Code Github action (/install-github-action)。这是我们版本的复利工程 CLAUDE.md。

参考文档： Claude Code 概览

了解 Claude Code，这是 Anthropic 的代理编码工具，驻留在您的终端中，帮助您以前所未有的速度将想法转化为代码。

6. Plan 模式的重要性

大多数会话都从计划模式开始（按两次 shift+tab）。如果我的目标是编写 Pull Request，我会使用计划模式，与 Claude 反复沟通，直到我满意它的计划。之后，我会切换到自动接受编辑模式，Claude 通常可以一次性搞定。一个好的计划真的非常重要！

7. 使用斜杠命令提高效率

对于我每天需要执行多次的每个"内循环"工作流，我都使用斜杠命令。这使我免于重复提示，并让 Claude 也能使用这些工作流。命令已检入 git 并位于 .claude/commands/ 中。

例如，Claude 和我每天都要使用几十次 /commit-push-pr 斜杠命令。该命令使用内联 bash 预先计算 git 状态和其他一些信息，以使命令快速运行并避免与模型来回交互。

参考文档： Bash 命令执行

8. 子代理自动化工作流

我经常使用几个子代理：

code-simplifier：在 Claude 完成工作后简化代码
verify-app：包含端到端测试 Claude Code 的详细说明
等等

与斜杠命令类似，我认为子代理是自动化我在大多数 PR 中所做的最常见工作流。

参考文档： 子代理

在 Claude Code 中创建并使用专门的 AI 子代理，以用于特定任务的工作流并改进上下文管理。

9. 使用 PostToolUse 钩子格式化代码

我们使用 PostToolUse 钩子来格式化 Claude 的代码。Claude 通常开箱即可生成格式良好的代码，而该钩子处理剩下的 10% 问题，以避免稍后在 CI 中出现格式错误。

10. 权限管理最佳实践

我不使用 --dangerously-skip-permissions。相反，我使用 /permissions 预先允许我知道在我的环境中是安全的常见 bash 命令，以避免不必要的权限提示。其中大多数已检入 .claude/settings.json 并与团队共享。

11. 工具集成与 MCP

Claude Code 为我使用所有工具。它经常：

搜索并发布到 Slack（通过 MCP 服务器）
运行 BigQuery 查询以回答分析问题（使用 bq CLI）
从 Sentry 获取错误日志
等等

Slack MCP 配置已检入我们的 .mcp.json 并与团队共享。

12. 长时间运行任务的处理

对于运行时间非常长的任务，我会：

(a) 提示 Claude 在完成后使用后台代理验证其工作
(b) 使用代理停止钩子更确定地执行此操作

我也经常在沙箱中使用 --permission-mode=dontAsk 或 --dangerously-skip-permissions 来避免会话的权限提示，这样 Claude 就可以在不被我阻塞的情况下大展身手。

参考资源：

13. 最重要的建议：验证工作

最后一个提示： 从 Claude Code 获得出色结果的最重要的一点——给 Claude 一种验证其工作的方法。如果 Claude 拥有该反馈循环，它将使最终结果的质量提高 2-3 倍。

Claude 使用 Claude Chrome 扩展程序测试我提交到 claude.ai/code 的每一项更改。它打开浏览器，测试 UI，并不断迭代，直到代码正常工作且 UX 感觉良好。

每个领域的验证看起来都不同。它可能就像：

运行 bash 命令
运行测试套件
在浏览器或手机模拟器中测试应用程序

请务必投入精力使其坚如磐石。

参考文档： Chrome 扩展

希望这有所帮助！您使用 Claude Code 有什么技巧？接下来您想听什么内容？

🔒 616 - 《AI 羊毛 04》

supercc — Sat, 03 Jan 2026 23:18:29 GMT

1、随时跑路公益站。

🔒 会员专享内容

此文章的完整内容仅对会员开放。

→ 点击查看完整内容

需要登录并验证邮箱才能访问受限内容。

译：效率悖论：为什么让软件更容易编写意味着我们将编写指数级更多的软件

supercc — Wed, 31 Dec 2025 14:45:09 GMT

原文： https://addyosmani.com/blog/the-efficiency-paradox/
作者： Addy Osmani
译者： Gemini 3 Pro High

December 29, 2025

每当我们让软件编写变得更容易时，结果我们编写的软件数量都会呈指数级增长。

当高级语言取代汇编语言时，程序员并没有少写代码——他们写的代码量增加了几个数量级，去解决以前在经济上不可能解决的问题。当框架抽象了底层架构时，我们并没有减少产出——我们构建了更宏大的应用程序。当云平台消除了基础设施管理的负担时，我们并没有缩减规模——我们为那些以前根本不值得建立服务器机房的用例启动了服务。

@levie 最近阐述了为什么这种模式即将在我们前所未见的规模上重演，并以杰文斯悖论（Jevons Paradox）为框架。这个论点引起了共鸣，因为它正在我们的开发工具中实时上演。每个人最初问的问题都是“这会取代开发人员吗？”，但只要看看实际发生了什么。采用这些工具的团队并不总是缩减工程人员编制——他们扩大了产品覆盖范围。以前只能维护一个产品的三人初创公司现在维护着四个。以前只能尝试两种方法的企业团队现在尝试七种。

被移除的约束不是能力，而是开始新事物所需的活化能。想想那个你一直推迟的内部工具，因为“它需要某人两周时间，而我们抽不出人手”？现在它只需要三个小时。那个你一直推迟的重构，因为风险/回报计算不划算？现在计算结果变了。

这一点很重要，因为软件工程师处于独特的地位，能够理解即将发生的事情。我们以前看过这部电影，只是在较小的领域。每一个抽象层——从汇编到 C 到 Python 到框架再到低代码——都遵循相同的模式。每一层本应意味着我们需要更少的开发人员。相反，每一层都使我们能够构建更多的软件。

在我看来，这里有一个值得更多关注的部分：门槛的降低不仅仅是关于更快地编写代码。它是关于哪些类型的问题在用软件解决时变得在经济上可行。想想你们公司里所有不存在的内部工具。不是因为没有人想到它们，而是因为投资回报率（ROI）的计算从未达标。那个能让一个团队效率提高 10% 但需要一周时间构建的自定义仪表板。那个能解锁洞察力但需要专业知识的数据管道。那个能理顺工作流程但涉及三个不同系统的集成。

这些项目未能通过成本效益分析，不是因为效益低——而是因为成本高。将成本降低“10倍”，突然之间你就有了大量可行的项目。这正是人工智能辅助开发正在发生的事情，而且它将比以前的转变更加剧烈，因为我们正在使以前“不可能”的工作成为可能。

当你考虑到每一个新工具都会创造对更多工具的需求时，二阶效应就变得非常有趣了。当我们让构建 Web 应用程序变得更容易时，我们不仅得到了更多的 Web 应用程序——我们得到了一个完整的监控工具、部署平台、调试工具和测试框架的生态系统。每一个都衍生出了自己的生态系统。这种复合效应是非线性的。

现在将这个逻辑应用到每一个我们正在降低准入门槛的领域。每一个解锁的新能力都会创造对支持能力的需求。每一个变得易于处理的工作流程都会创造对相邻工作流程的需求。经济上可行的范围在所有方向上都在扩大。

具体对于工程师来说，这改变了我们要从事什么工作的计算方式。目前，我们被训练成对我们要构建的东西极其挑剔，因为我们的时间是稀缺资源。但是，当构建成本急剧下降时，限制因素变成了想象力、“品味”和判断力，而不是实现能力。技能从“考虑到我的限制，我可以构建什么？”转变为“考虑到限制在某种程度上已经消失，我们应该构建什么？”

这里的元观点是，我们一直在犯同样的预测错误。每当我们提高某件事的效率时，我们预测这意味着对该事物的需求会减少。但效率的提高并没有减少需求——它们揭示了以前因不经济而未被满足的潜在需求。煤炭。计算。云基础设施。现在是知识工作。

这种模式是如此一致，以至于举证责任应该转移。与其问“人工智能代理会减少对人类知识工作者的需求吗？”，我们应该问“我们将看到知识工作产出增加多少个数量级？”

对于软件工程师来说，这是我们已经成功度过几次的同一种转变。那些蓬勃发展的开发人员并不是抵制更高级别抽象的人；而是那些利用这些抽象来构建更宏大系统的人。同样的逻辑现在也适用，只是规模更大了。

真正的问题是，我们是否准备好迎接一个瓶颈从“我们能建造这个吗？”转变为“我们应该建造这个吗？”的世界。那是一个根本不同的问题空间，它需要根本不同的技能。

我们将要发现当知识工作的成本下降一个数量级时会发生什么。历史表明我们（也许）不会少做工作——我们会发现我们一直在大规模地对知识工作投资不足，因为做所有那些实际上值得做的事情太贵了。

悖论不在于效率创造了富足。
悖论在于我们总是对此感到惊讶。

这篇文章最初是对 Aaron Levie 关于杰文斯悖论和人工智能的帖子的回应。我的原始回应发布在 X/Twitter 上。

译：使用 Claude Code 和 Codex 等异步编程智能体进行代码研究项目

supercc — Wed, 31 Dec 2025 14:14:06 GMT

原文：https://simonwillison.net/2025/Nov/6/async-code-research/
作者：Simon Willison
译者：Gemini 3 Pro High

2025年11月6日

我最近一直在尝试一种 LLM 使用模式，效果非常好：异步代码研究任务。选一个研究问题，启动一个异步编程智能体，让它去运行一些实验，并在完成后回来报告。

代码研究 #

软件开发从我所说的代码研究中获益良多。关于代码的问题，最棒的一点是，它们通常可以通过编写和执行代码来得到确定的回答。

我经常在论坛上看到一些问题，暗示提问者缺乏这种技能。

“Redis 能用来支持我应用的通知流吗？”就是一个很好的例子。答案_永远_是“视情况而定”，但更好的答案是，一个优秀的程序员已经拥有了回答这个问题所需的一切。建立一个概念验证（PoC），模拟你在生产环境中预期的模式，然后运行实验看看它是否行得通。

长期以来，我一直是代码研究的积极实践者。我的许多最有趣的项目最初都只是几十行实验代码，用来向自己证明某件事是可行的。

编程智能体 #

事实证明，像 Claude Code 和 Codex 这样的编程智能体也非常适合这类工作。给它们一个正确的目标和一个有用的环境，它们就能在没有任何进一步监督的情况下完成一个基本的代码研究项目。

大语言模型（LLM）会产生幻觉并犯错。但这对于代码研究任务来说不那么重要，因为代码本身不会撒谎：如果它们编写并执行代码，且代码做出了正确的事情，那么它们就向它们自己和你证明了某件事确实行得通。

它们无法证明某事是不可能的——仅仅因为编程智能体找不到做某事的方法并不意味着它不能被完成——但它们通常可以在几分钟的运算内证明某事_是_可能的。

异步编程智能体 #

我已经使用像 Claude Code 和 Codex CLI 这样的交互式编程智能体做了一堆这样的事情，但今天我越来越多地转向使用它们的异步编程智能体家族成员。

异步编程智能体是一种基于“发射后不管”（fire-and-forget）模式运行的编程智能体。你给它布置一个任务，它就在某处的服务器上忙活，当它完成后，它会向你选择的 GitHub 仓库提交一个 Pull Request。

OpenAI 的 Codex Cloud、Anthropic 的 Claude Code for web、Google Gemini 的 Jules 和 GitHub 的 Copilot coding agent 是这种模式的四个杰出代表。

这些是进行代码研究项目的_绝佳_工具。想出一个明确的目标，把它写成几段提示词，放手让它们去干，十分钟后再回来看看它们搞出了什么。

我现在每天都要启动 2-3 个代码研究项目。我自己投入的时间很少，而它们经常带回有用或有趣的结果。

给它们一个专用的 GitHub 仓库 #

你可以针对现有的 GitHub 仓库运行代码研究任务，但我发现拥有一个单独的、专用的仓库来让你的编程智能体运行项目要自由得多。

这使你不再局限于仅针对已编写的代码进行研究，也意味着你可以对让智能体做的事情少一些顾虑。

我有两个用于此目的的仓库——一个公开的，一个私有的。我使用公开仓库进行无需保密的研究任务，而私有仓库则用于任何我还未准备好与世界分享的内容。

让它们尽情使用无限的网络访问权限 #

专用仓库的最大好处是，你不需要对在该仓库中操作的智能体能做什么而小心翼翼。

Codex Cloud 和 Claude Code for web 都默认在锁定环境中运行智能体，严格限制它们访问网络的方式。如果它们是针对敏感仓库运行，这完全合理——致命三连击（lethal trifecta）类型的提示注入攻击很容易被用来窃取敏感代码或环境变量。

如果你是在一个新的、非敏感的仓库中运行，你完全不需要担心这个！我已经将我的研究仓库配置为全网络访问，这意味着我的编程智能体可以安装它们需要的任何依赖项，从网络上获取数据，并且通常可以做我在自己的电脑上能做的任何事情。

我的 simonw/research 合集 #

让我们看一些例子。我的公开研究仓库在 GitHub 上的 simonw/research。目前它包含 13 个文件夹，每个文件夹都是一个独立的研究项目。我两周前才创建它，所以我已经平均每天将近一个了！

它还包含一个 GitHub Workflow，使用 GitHub Models 自动更新 README 文件，添加每个新项目的摘要，使用了 Cog、LLM、llm-github-models 和这段 Python 代码。

以下是仓库中的一些研究项目示例。

node-pyodide 展示了一个 Node.js 脚本的例子，它在内部运行 Python 的 Pyodide WebAssembly 发行版——这是我为了寻找在服务器上的 WebAssembly 沙箱中运行 Python 的好方法而进行的持续尝试中的又一次尝试。

python-markdown-comparison (记录) 提供了七个不同 Python Markdown 库的详细性能基准测试。我启动这个项目是因为我偶然发现了 cmarkgfm，这是一个围绕 GitHub 的 C 语言 Markdown 实现的 Python 绑定，我想看看它与其他选项相比如何。这个项目生成了一些图表！cmarkgfm 以显著优势名列前茅：

这是我用于该项目的完整提示词：

Create a performance benchmark and feature comparison report on PyPI cmarkgfm compared to other popular Python markdown libraries—check all of them out from github and read the source to get an idea for features, then design and run a benchmark including generating some charts, then create a report in a new python-markdown-comparison folder (do not create a _summary.md file or edit anywhere outside of that folder). Make sure the performance chart images are directly displayed in the README.md in the folder.

创建一份关于 PyPI cmarkgfm 与其他流行 Python markdown 库的性能基准测试和功能比较报告——从 github 检出所有库并阅读源代码以了解功能，然后设计并运行基准测试，包括生成一些图表，然后在一个新的 python-markdown-comparison 文件夹中创建报告（不要创建 _summary.md 文件或在该文件夹之外进行任何编辑）。确保性能图表图像直接显示在文件夹中的 README.md 中。

请注意，除了 cmarkgfm 之外，我没有指定任何 Markdown 库——Claude Code 运行了一个搜索并自己找到了其他六个。

cmarkgfm-in-pyodide 要有趣得多。将所有研究项目放在同一个仓库中的一个好处是，新项目可以建立在以前项目的基础上。在这里，我决定看看让 cmarkgfm（它有一个 C 扩展）在 Node.js 内部的 Pyodide 中工作有多难。Claude 成功编译了一个 88.4KB 的 cmarkgfm_pyodide-2025.10.22-cp312-cp312-emscripten_3_1_46_wasm32.whl 文件，其中包含必要的 C 扩展，并证明了它可以加载到 Node.js 内部的 WebAssembly 中的 Pyodide 里。

在最初的尝试失败后，我在笔记本电脑上使用 Claude Code 运行了这个项目。起始提示词是：

Figure out how to get the cmarkgfm markdown lover [typo in prompt, this should have been “library” but it figured it out anyway] for Python working in pyodide. This will be hard because it uses C so you will need to compile it to pyodide compatible webassembly somehow. Write a report on your results plus code to a new cmarkgfm-in-pyodide directory. Test it using pytest to exercise a node.js test script that calls pyodide as seen in the existing node.js and pyodide directory
\n> There is an existing branch that was an initial attempt at this research, but which failed because it did not have Internet access. You do have Internet access. Use that existing branch to accelerate your work, but do not commit any code unless you are certain that you have successfully executed tests that prove that the pyodide module you created works correctly.

弄清楚如何让 Python 的 cmarkgfm markdown lover [提示词中有拼写错误，这本应是“library”（库），但它还是理解了] 在 pyodide 中工作。这会很难，因为它使用 C 语言，所以你需要以某种方式将其编译为 pyodide 兼容的 webassembly。将结果报告和代码写入一个新的 cmarkgfm-in-pyodide 目录。使用 pytest 测试它，以运行一个调用 pyodide 的 node.js 测试脚本，就像在现有的 node.js 和 pyodide 目录中看到的那样。
\n> 有一个现有的分支是这项研究的初步尝试，但由于没有互联网访问权限而失败了。你有互联网访问权限。利用那个现有的分支来加速你的工作，但不要提交任何代码，除非你确定你已经成功执行了证明你创建的 pyodide 模块工作正常的测试。

这个项目进行到一半就放弃了，抱怨说 emscripten 会花太长时间。我告诉它：

完成这个项目，实际运行 emscripten，我不在乎花多长时间，如果成功就更新报告

它又忙活了一会儿，抱怨说现有的 Python 库使用了 CFFI，而这在 Pyodide 中不可用。我问它：

你能想出如何重写 cmarkgfm 以不使用 FFI，而是使用一种对 pyodide 友好的方式来集成该 C 代码吗？

……结果它做到了。你可以在这里查看完整的记录。

blog-tags-scikit-learn。暂时从 WebAssembly 中抽身出来，我想让 scikit-learn 在针对我博客的文本分类任务上大显身手，这应该很有趣：

Work in a new folder called blog-tags-scikit-learn
\n> Download https://datasette.simonwillison.net/simonwillisonblog.db—a SQLite database. Take a look at the blog_entry table and the associated tags—a lot of the earlier entries do not have tags associated with them, where the later entries do. Design, implement and execute models to suggests tags for those earlier entries based on textual analysis against later ones
\n> Use Python scikit learn and try several different strategies
\n> Produce JSON of the results for each one, plus scripts for running them and a detailed markdown description
\n> Also include an HTML page with a nice visualization of the results that works by loading those JSON files.

在一个名为 blog-tags-scikit-learn 的新文件夹中工作
\n> 下载 https://datasette.simonwillison.net/simonwillisonblog.db——一个 SQLite 数据库。看看 blog_entry 表和关联的标签——很多早期的条目没有关联标签，而较晚的条目有。设计、实现并执行模型，基于对较晚条目的文本分析，为那些较早的条目建议标签
\n> 使用 Python scikit learn 并尝试几种不同的策略
\n> 为每种策略生成结果的 JSON，加上运行它们的脚本和详细的 markdown 描述
\n> 还要包含一个 HTML 页面，通过加载这些 JSON 文件来对结果进行漂亮的可视化。

这产生了七个 .py 文件，四个 .json 结果文件和一份详细的报告。（由于某种原因，它忽略了关于带有漂亮可视化的 HTML 页面的部分。）对于在手机上输入的几分钟闲暇好奇心来说，这还不赖！

这只是目前仓库中十三个项目中的三个。如果你想看它们是如何展开的，每个项目的提交历史通常会链接到提示词，有时还会链接到记录。

最近，我在仓库中添加了一个简短的 AGENTS.md 文件，为我的研究智能体提供了一些额外的提示。你可以在这里查看。

当然，这完全是粗制滥造 #

我对 AI slop（AI 垃圾内容）的首选定义是：未经人工审核就发布的 AI 生成内容。我自己并没有非常仔细地审核这些报告，通常也不会在没有认真编辑和验证的情况下将它们发布到网上。

不过，我想分享我正在使用的这种模式，所以我决定将它们隔离在这个公开的 simonw/research 仓库中。

给 GitHub 提一个小小的功能请求：我希望能够将仓库标记为"从搜索引擎索引中排除"，这样它就会被添加 <meta name=\"robots\" content=\"noindex\"> 标签。我仍然希望将 AI 生成的内容排除在搜索之外，以避免为死亡互联网贡献更多内容。

亲自尝试一下 #

开始尝试这种编程智能体研究模式非常简单。创建一个免费的 GitHub 仓库（公开或私有），然后让一些智能体在上面自由发挥，看看会发生什么。

你可以在本地运行智能体，但我发现异步智能体更方便——特别是我可以运行它们（或从手机上触发它们），而不用担心它们会损坏我自己的机器或泄露我的任何私人数据。

Claude Code for web 在限定时间内（截至 2025 年 11 月 18 日）为其每月 20 美元的用户提供免费的 250 美元额度。Gemini Jules 有免费层级。还有很多其他编程智能体可以尝试。

如果你的研究智能体带回了什么有趣的东西，请告诉我！

🔒 615 - 《基于 Neovate Code 的 AI 编程最佳实践》

supercc — Tue, 30 Dec 2025 21:01:45 GMT

注：AI 辅助创作，但观点是自己的。

🔒 会员专享内容

此文章的完整内容仅对会员开放。

→ 点击查看完整内容

需要登录并验证邮箱才能访问受限内容。

译：Superpowers 4

supercc — Mon, 29 Dec 2025 14:24:03 GMT

原文： https://blog.fsck.com/2025/12/18/superpowers-4/
作者： Jesse Vincent
译者： Gemini 3 Pro High

很高兴宣布 Superpowers 4.0 发布。

这个版本的主要改进包括：

子 Agent 驱动的开发变得更好了

Superpowers 所围绕的软件开发流程一直都在每个实现步骤后有一个“代码审查”步骤。代码审查现在已被拆分为两个独立的 Agent，每个 Agent 都有自己的任务。首先，“规范审查” Agent 会评估工作，以确保它实现了计划中要求构建的内容。只有在规范审查 Agent 批准后，代码审查 Agent 才会深入研究代码质量。

这两个步骤现在都已正式成为循环，而不是被写成潜在的一次性流程。（协调 Agent 现在知道，在实施者修复了第一次代码审查的问题后，需要重新运行代码审查。）

子 Agent 驱动的开发非常出色，以至于我快要移除旧的“双窗口”工作流了，该工作流需要你充当实施 Agent 和协调者之间的桥梁。目前，阻碍这一变化的最大因素是 OpenAI Codex 尚不支持子 Agent。我已经有了解决方案，但还没有完全准备好发布。

技能触发和描述的变更。

从 Opus 4.5 开始，Claude 似乎更有可能根据描述猜测它已经知道某个技能的作用。这表现为它声称要使用某个技能，然后……在没有实际阅读该技能的情况下即兴发挥。我相信这主要是由于技能 description 字段除了说明何时使用技能外，还解释了技能的作用。

为了缓解这个问题，我修改了技能描述，使其仅包含有关何时使用该技能的信息。例如，头脑风暴技能的描述从：

Use when creating or developing, before writing code or implementation plans - refines rough ideas into fully-formed designs through collaborative questioning, alternative exploration, and incremental validation. Don't use during clear 'mechanical' processes.

变为

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

另外，有些人已经开始遇到 Claude Code 的技能描述字符数隐藏限制，超过该限制后 Claude 会开始隐藏某些技能。

为了缓解这个问题，我将一些实际上不需要作为独立技能的技能压缩为更通用技能的渐进式披露部分。test-driven-development 现在包含 testing-anti-patterns。事后看来，testing-anti-patterns 是一个糟糕的技能，因为它是关于不做什么，而不是关于做什么，并附带有关危险模式的说明。

同样，systematic-debugging 技能现在包含来自 root-cause-tracing、defense-in-depth 和 condition-based-waiting 的内容。

内部开始有了测试套件。

这还不是一个合适的评估套件，但我们现在有一些基本的端到端测试，确保 Agent 运行完整的头脑风暴 - 规划 - 实施流程并验证技能使用情况。我们要利用这一点来改进 Superpowers 的技能触发。

更多地使用 GraphViz

这不太可能对用户可见，但 Superpowers 内部更多地依赖 GraphViz ‘dot’ 符号来进行流程文档记录。dot 是一种图形和流程符号，读起来有点像 ASCII 艺术。作为一种稍微形式化的符号，dot 比散文的歧义要少一些。Claude 特别擅长遵循用 dot 编写的流程。

题外话 #

我制作并免费提供 Superpowers，是因为我喜欢构建帮助人们制作软件的工具。我最近启用了 GitHub Sponsorships，让人们可以赞助我的开源工作。你没有义务赞助我或为 Superpowers 支付任何费用，但如果你在工作中从中获得了价值，并想给我一些支持，我将非常感激，这将有助于激励我继续制作并免费提供工具。你可以在这里赞助我的工作

谢谢！