OpenClaw作者Peter Steinberger的20条Vibe Coding方法论，以及，Codex和Opus怎么选？

OpenClaw作者Peter Steinberger的20条Vibe Coding方法论，以及，Codex和Opus怎么选？ OpenClaw作者Peter Steinberger的20条Vibe Coding方法论，以及，Codex和Opus怎么选？ Modified February 18 我写这篇文章的时候，codex 正在啃一个耗时数小时的大型重构，用来修复 Opus 4.0 早期欠下的技术债。Twitter 上经常有人问我，Opus 和 codex 的大区别是什么，为什么这很重要，因为基准测试分数如此接近。在我看来， 越来越难信任基准测试了 ——你需要亲自尝试两者才能真正理解。不管 OpenAI 在后训练中做了什么，codex 已经被训练成在开始之前阅读 大量 代码。 有时候它只是 默默地阅读文件 10 到 15 分钟 ，然后才开始写代码。一方面这很烦人，另一方面这很棒，因为它大大增加了它修复正确东西的几率。另一方面，Opus 更加急切——适合小修改——不适合大功能或重构，它经常不读整个文件或错过某些部分，然后交付低效的结果或遗漏东西。我注意到，即使 codex 有时候花的时间是 Opus 的 4 倍来完成可比的任务，我反而更快，因为我不需要回去修复那个修复——这在我还在用 Claude Code 的时候感觉很正常。 codex 还让我改掉了许多在 Claude Code 时代必要的"把戏"。不再是" 计划模式 "，我只是 开始和模型对话 ，问个问题，让它去谷歌搜索、探索代码、一起创建计划，当我对看到的东西满意时，我就写"build"或者"write plan to docs/ .md and build this"。计划模式感觉像是早期模型时代的黑客方案——那些模型不太擅长遵循提示，所以我们不得不拿走它们的编辑工具。有一条我被高度误解的推文至今还在流传，这表明大多数人并不理解计划模式并不神奇。 Oracle 从 GPT 5/5.1 到 5.2 的跨越是巨大的。我大约在一个月前构建了 oracle 🧿 ——这是一个 CLI，允许 agent 运行 GPT 5 Pro，上传文件和提示，并管理会话以便稍后检索答案。我这样做是因为很多时候当 agent 卡住时，我让它把所有内容写进一个 markdown 文件，然后我自己去查询，这感觉像是重复浪费时间——也是一个闭环的机会。指令在我的全局 AGENTS.MD 文件中，模型有时候会在卡住时自己触发 oracle。我每天都用好几次。这是一个 巨大的解锁 。Pro 在速通约 50 个网站然后深入思考方面好得离谱，几乎在每种情况下都能击中正确答案。有时候很快，花 10 分钟，但我也有运行超过一个小时的。 现在 GPT 5.2 出来了，我需要它的场景少了很多。我自己确实有时候用 Pro 做研究，但我让模型"问 oracle"的情况已经从每天多次降到了每周几次。我对此并不生气——构建 oracle 超级有趣，我学到了很多关于浏览器自动化、Windows 的知识，最后终于花时间研究了 skills——这个想法我之前曾相当长时间地拒绝过。它确实展示了 5.2 对许多现实世界的编码任务变得有多好。它几乎能 一发入魂 我丢给它的任何东西。 另一个巨大的胜利是 知识截止日期 。GPT 5.2 的知识截止到 8 月底，而 Opus 卡在 3 月中旬——差了大约 5 个月。当你想使用最新可用工具时，这很关键。 一个具体例子：VibeTunnel 再给你一个例子，说明模型进步了多少。我早期的强度项目之一是 VibeTunnel。一个终端多路复用器，让你可以在外出时编码。今年早些时候我几乎把所有时间都投入其中，两个月后它变得太好了，以至于我发现自己和朋友外出时用手机编码……然后决定我应该停止这样做，更多是为了心理健康而不是别的。当时我试图把多路复用器的核心部分从 TypeScript 重写出来，老模型 consistently 让我失望。我试过 Rust、Go……天哪，甚至 Zig。当然我本可以完成这个重构，但这需要大量的手工工作，所以在我把它搁置之前一直没完成。上周我把它从灰里捞出来，给 codex 一个 两句话的提示 来把整个转发系统转换成 Zig，它跑了 5 个多小时，经过多次压缩，一次性交付了一个可用的转换版本。 你问我为什么要把它从灰里捞出来？我目前的重点是 Clawdis （译者注：OpenClaw前身），一个 AI 助手，它在我所有电脑 上有 完全访问权限 ，包括消息、邮件、家庭自动化、摄像头、灯光、音乐，见鬼，它甚至能控制我的床的温度。当然它还有自己的声音、一个用来发推的 CLI 和自己的 clawd.bot。 Clawd 能看到并控制我的屏幕，有时候会说些刻薄的话，但我也想让它有能力检查我的 agent，而获取 字符流 比看图片效率高得多……这是否可行，我们拭目以待！ 我的工作流 我知道……你来到这里是为了 学习如何更快地构建 ，而我（看上去）只是在写 OpenAI 的营销文案。我希望 Anthropic 正在酝酿 Opus 5，让局势再次逆转。竞争是好事！同时，我 爱 Opus 作为通用模型。我的 AI agent 如果运行在 GPT 5 上不会有一半这么 有趣 。Opus 有一些特别的东西让它用起来 很愉悦 。我用它来做大部分电脑自动化任务，当然它也驱动着 Clawd🦞。 我的工作流程和我去年 10 月的上次分享 相比没怎么变。 • • 我通常同时处理 多个项目 。根据复杂度，可能是 3 到 8 个。上下文切换可能会很累，我真的只有在家工作、安静且专注的时候才能这样做。需要转换的模型很多。幸运的是大多数软件都很无聊。创建一个 CLI 来检查你的外卖配送不需要太多思考。通常我的焦点是一个大项目加上几个卫星项目一起推进。当你做了足够多的 agent 工程，你就会对什么东西会简单、模型可能会在哪里挣扎产生直觉，所以经常我只是丢进一个提示，codex 就会埋头干 30 分钟，我就得到了我需要的东西。有时候需要一点摆弄或创造力，但大多数事情都很直接。 • • 我广泛使用 codex 的 队列功能 ——当我有新想法时，我把它加到管道里。我看到很多人在实验各种多 agent 编排系统、邮件或自动任务管理——目前我不太觉得有这需要——通常 我自己才是瓶颈 。我构建软件的方法是快速迭代的。 我构建东西，玩一玩，看看它"感觉"如何，然后得到新的想法来完善它。我很少在脑子里有完整的图景 。当然，我有一个大致想法，但通常随着我探索问题领域，这个想法会发生剧烈变化。所以那些 把 完整想法 作为输入然后交付输出的系统对我来说不太好用 （译者注：这里讲的是Spec Driven的开发模式和相应的Agents） 。 我需要玩它、摸它、感受它、看见它，这就是我让它演进的方式。 • • 我基本上 从来不回滚 或使用检查点。如果某件事不是我喜欢的方式，我就让模型改它。codex 有时候会重置一个文件，但更多时候它只是撤销或修改编辑，很少需要完全回退，相反我们只是换了个方向走。 构建软件就像爬山。你不会直直地往上走，你会绕着山走、转弯，有时候你会偏离路径不得不往回走一点，这不完美，但最终你会到达你需要去的地方。 • • 我只是 直接提交到 main 。有时候 codex 觉得太乱了会自动创建一个 worktree 然后把改动合并回来，但这很少见，我只在特殊情况下才会提示这样做。我觉得 必须在脑中思考项目中不同状态的额外认知负担是不必要的 ，我更愿意线性地演进它。更大的任务我留到分心的时候做——比如写这篇文章的时候，我在这里对 4 个项目运行重构，每个大概要花 1 到 2 小时完成。当然我可以在 worktree 里做，但那只会造成大量的合并冲突和次优的重构。注意事项：我通常一个人工作，如果你在更大的团队，那这套工作流显然行不通。 • • 我已经提到过我规划功能的方式。我 经常跨项目引用 ，特别是如果我知道我已经在别的地方解决了某个问题，我会让 codex 去看 ../project folder，这通常足够让它从上下文中推断出该看哪里。这对节省提示词非常有用。 我可以直接写"look at ../vibetunnel and do the same for Sparkle changelogs"，因为它已经在那里解决了，有 99% 的把握它会正确地复制过来并适应新项目。我也是这样搭建新项目的。 • • 我见过很多人用来引用过去会话的系统。这是另一件我从来不需要或使用的东西。我在每个项目的 docs 文件夹 里维护子系统和功能的文档，并使用一个脚本加上一些指令 在我的全局 AGENTS 文件中强制模型阅读某些主题的文档。项目越大这越值得，所以我不在所有地方都用它，但它对保持文档更新和为我的任务设计更好的上下文有很大帮助。 • • 说到上下文。我曾经非常勤奋地为新任务重启会话。 有了 GPT 5.2 这就不再需要了。即使上下文更满，性能也非常好，而且通常在速度上有帮助，因为当模型已经加载了大量文件时它工作得更快。显然这只有在你序列化你的任务或让目前的改动保持足够分散以至于两个会话不太会互相触碰时才有效。codex 没有像 claude code 那样的"这个文件改了"的系统事件，所以你需要更小心——但另一方面， codex 在上下文管理方面要好得多，我觉得在一个 codex 会话中能完成的事情是在 claude 中的 5 倍 。这不仅仅是客观上更大的上下文尺寸，还有其他东西在起作用。我的猜测是 codex 内部思考得非常浓缩以节省 token，而 Opus 非常啰嗦。有时候模型会搞砸，它的内部思考流泄露给用户，所以我有好几次看到这个。说真的，codex 有它自己的说话方式，我觉得莫名地有娱乐性。 • • 提示词。我曾经用语音输入写很长、很详细的提示词。用 codex 后，我的 提示词变得短多了 ，我经常打字，很多时候我会加图片，特别是在迭代 UI（或用 CLI 时的文本复制）时。如果你给模型展示什么是错的，只需要几个词就足够让它做你想做的事。是的， 我就是那种拖一张 UI 组件的截图进去说"fix padding"或"redesign"的人 ，很多时候这要么解决了我的问题，要么让我走得相当远。我曾经引用 markdown 文件，但有了我的 docs:list 脚本后就不再需要了。 • • Markdown。很多时候我写" write docs to docs/ .md "， 直接让模型自己选文件名 。你为模型训练的内容设计的结构越明显，你的工作就会越容易。毕竟， 我设计代码库不是为了让我自己容易导航 ，我是为了让 agent 能在其中高效工作而工程化它们。 和模型对抗通常是浪费时间和 token 。 工具和基础设施 • 什么仍然很难？ 选择正确的依赖和框架是我会花相当多时间的东西。这东西维护得好吗？peer 依赖怎么样？它流不流行 = 会有足够的世界知识所以 agent 能轻松处理？同样，系统设计。我们会通过 web sockets 通信吗？HTML？我把什么放在服务器里，什么放在客户端？如何以及哪些数据从哪里流向哪里？通常这些是对模型来说有点难解释的事情，也是研究和思考有回报的地方。 • 因为我管理很多项目，我经常让一个 agent 直接在我的项目文件夹里运行，当我想出一个新模式时，我让它" 找到我最近的所有 go 项目 "并在那里也实现这个改动 + 更新 changelog。我的每个项目在那个文件里都有一个升高的 patch 版本号，当我重新访问它时，一些改进已经在等着我测试了。 • 当然我 自动化一切 。有一个 skill 用来注册域名和修改 DNS。一个用来写好前端。我的 AGENTS 文件里有一条关于我的 tailscale 网络的说明，所以我可以直接说"去我的 mac studio 更新 xxx"。 • 说到 多台 Mac 。我通常在两台 Mac 上工作。我的 MacBook Pro 接在大屏幕上，另一个屏幕上是到我的 Mac Studio 的 Jump Desktop 会话。有些项目在那里运行，有些在这里。有时候我在每台机器上编辑同一个项目的不同部分，通过 git 同步。比 worktree 简单，因为 main 上的漂移很容易调和。还有一个好处是任何需要 UI 或浏览器自动化的东西我可以移到我的 Studio，它不会用弹出窗口烦我。（是的，Playwright 有无头模式，但有足够多的情况那不管用） • 另一个好处是任务在那里 继续运行 ，所以每当我出差时，远程变成我的主要工作站，任务即使我合上 Mac 也继续运行。我过去曾实验过像 codex 或 Cursor web 这样的真正异步 agent，但我想念可控性，而且最终工作会以 pull request 结束，这又给我的设置增加了复杂性。我更喜欢终端的简单性。 • 我曾经玩斜杠命令，但从来没觉得太有用。Skills 替换了其中一些，剩下的我继续写" commit/push "，因为花的时间和 /commit 一样，而且总是有效。 • 过去我经常花专门的日子来 重构和清理 项目，现在我做这件事更加即兴。每当提示词开始花太长时间或者我在代码流中看到丑陋的东西飘过，我会立刻处理它。 • 我试过 linear 或其他 issue 追踪器 ，但什么都没坚持下来。重要的想法我会立刻尝试，其他的事情我要么会记住，要么它就没那么重要。当然我有公开的 bug 追踪器给使用我开源代码的人用，但当我发现一个 bug 时，我会立刻提示它——这比写下来然后之后不得不切换上下文回去要快得多。 • 无论你构建什么， 先从模型和 CLI 开始 。我脑子里有这个Chrome 扩展来总结 YouTube 视频的想法很久了。上周我开始做 summarize，一个把任何东西转成 markdown 然后丢给模型做总结的 CLI。首先我把核心做对，一旦效果很好，我一天就构建了整个扩展。我相当爱它。在本地运行，免费或付费模型都可以。本地转录视频或音频。和本地守护进程对话所以超级快。来试试！ • 我的首选模型是 gpt 5.2 codex high 。Again，KISS。除了慢得多之外，xhigh 没什么好处，我也不想花时间思考不同的模式或"ultrathink"。所以几乎所有东西都跑在 high 上。GPT 5.2 和 codex 足够接近，换模型没意义，所以我就用这个。 我的配置 这是我的 /.codex/config.toml ： Code block Plain Text Copy model = "gpt 5.2 codex" model reasoning effort = "high" tool output token limit = 25000 在 272 273k 上下文窗口附近留出原生压缩的空间。 公式：273000 (tool output token limit + 15000) 当 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 脚本，其他的也不错。别被压缩吓到，自从 OpenAI 切换到他们新的 /compact 端点后，这工作得足够好，任务可以跨多次压缩运行并完成。它会让事情变慢，但经常起到审查的作用，模型在再次看代码时会发现 bug。 暂时就这些。我计划写更多东西，脑子里有相当多的想法积压，只是 玩得太开心了 在构建东西 。如果你想听更多碎碎念和在这个新世界构建的想法，在 Twitter 上关注我(译者注： @steipete )。 我写这篇文章的时候，codex 正在啃一个耗时数小时的大型重构，用来修复 Opus 4.0 早期欠下的技术债。Twitter 上经常有人问我，Opus 和 codex 的大区别是什么，为什么这很重要，因为基准测试分数如此接近。在我看来， 越来越难信任基准测试了 ——你需要亲自尝试两者才能真正理解。不管 OpenAI 在后训练中做了什么，codex 已经被训练成在开始之前阅读 大量 代码。 有时候它只是 默默地阅读文件 10 到 15 分钟 ，然后才开始写代码。一方面这很烦人，另一方面这很棒，因为它大大增加了它修复正确东西的几率。另一方面，Opus 更加急切——适合小修改——不适合大功能或重构，它经常不读整个文件或错过某些部分，然后交付低效的结果或遗漏东西。我注意到，即使 codex 有时候花的时间是 Opus 的 4 倍来完成可比的任务，我反而更快，因为我不需要回去修复那个修复——这在我还在用 Claude Code 的时候感觉很正常。 codex 还让我改掉了许多在 Claude Code 时代必要的"把戏"。不再是" 计划模式 "，我只是 开始和模型对话 ，问个问题，让它去谷歌搜索、探索代码、一起创建计划，当我对看到的东西满意时，我就写"build"或者"write plan to docs/ .md and build this"。计划模式感觉像是早期模型时代的黑客方案——那些模型不太擅长遵循提示，所以我们不得不拿走它们的编辑工具。有一条我被高度误解的推文至今还在流传，这表明大多数人并不理解计划模式并不神奇。 Oracle 从 GPT 5/5.1 到 5.2 的跨越是巨大的。我大约在一个月前构建了 oracle 🧿 ——这是一个 CLI，允许 agent 运行 GPT 5 Pro，上传文件和提示，并管理会话以便稍后检索答案。我这样做是因为很多时候当 agent 卡住时，我让它把所有内容写进一个 markdown 文件，然后我自己去查询，这感觉像是重复浪费时间——也是一个闭环的机会。指令在我的全局 AGENTS.MD 文件中，模型有时候会在卡住时自己触发 oracle。我每天都用好几次。这是一个 巨大的解锁 。Pro 在速通约 50 个网站然后深入思考方面好得离谱，几乎在每种情况下都能击中正确答案。有时候很快，花 10 分钟，但我也有运行超过一个小时的。 现在 GPT 5.2 出来了，我需要它的场景少了很多。我自己确实有时候用 Pro 做研究，但我让模型"问 oracle"的情况已经从每天多次降到了每周几次。我对此并不生气——构建 oracle 超级有趣，我学到了很多关于浏览器自动化、Windows 的知识，最后终于花时间研究了 skills——这个想法我之前曾相当长时间地拒绝过。它确实展示了 5.2 对许多现实世界的编码任务变得有多好。它几乎能 一发入魂 我丢给它的任何东西。 另一个巨大的胜利是 知识截止日期 。GPT 5.2 的知识截止到 8 月底，而 Opus 卡在 3 月中旬——差了大约 5 个月。当你想使用最新可用工具时，这很关键。 一个具体例子：VibeTunnel 再给你一个例子，说明模型进步了多少。我早期的强度项目之一是 VibeTunnel。一个终端多路复用器，让你可以在外出时编码。今年早些时候我几乎把所有时间都投入其中，两个月后它变得太好了，以至于我发现自己和朋友外出时用手机编码……然后决定我应该停止这样做，更多是为了心理健康而不是别的。当时我试图把多路复用器的核心部分从 TypeScript 重写出来，老模型 consistently 让我失望。我试过 Rust、Go……天哪，甚至 Zig。当然我本可以完成这个重构，但这需要大量的手工工作，所以在我把它搁置之前一直没完成。上周我把它从灰里捞出来，给 codex 一个 两句话的提示 来把整个转发系统转换成 Zig，它跑了 5 个多小时，经过多次压缩，一次性交付了一个可用的转换版本。 你问我为什么要把它从灰里捞出来？我目前的重点是 Clawdis （译者注：OpenClaw前身），一个 AI 助手，它在我所有电脑 上有 完全访问权限 ，包括消息、邮件、家庭自动化、摄像头、灯光、音乐，见鬼，它甚至能控制我的床的温度。当然它还有自己的声音、一个用来发推的 CLI 和自己的 clawd.bot。 Clawd 能看到并控制我的屏幕，有时候会说些刻薄的话，但我也想让它有能力检查我的 agent，而获取 字符流 比看图片效率高得多……这是否可行，我们拭目以待！ 我的工作流 我知道……你来到这里是为了 学习如何更快地构建 ，而我（看上去）只是在写 OpenAI 的营销文案。我希望 Anthropic 正在酝酿 Opus 5，让局势再次逆转。竞争是好事！同时，我 爱 Opus 作为通用模型。我的 AI agent 如果运行在 GPT 5 上不会有一半这么 有趣 。Opus 有一些特别的东西让它用起来 很愉悦 。我用它来做大部分电脑自动化任务，当然它也驱动着 Clawd🦞。 我的工作流程和我去年 10 月的上次分享 相比没怎么变。 • • 我通常同时处理 多个项目 。根据复杂度，可能是 3 到 8 个。上下文切换可能会很累，我真的只有在家工作、安静且专注的时候才能这样做。需要转换的模型很多。幸运的是大多数软件都很无聊。创建一个 CLI 来检查你的外卖配送不需要太多思考。通常我的焦点是一个大项目加上几个卫星项目一起推进。当你做了足够多的 agent 工程，你就会对什么东西会简单、模型可能会在哪里挣扎产生直觉，所以经常我只是丢进一个提示，codex 就会埋头干 30 分钟，我就得到了我需要的东西。有时候需要一点摆弄或创造力，但大多数事情都很直接。 • • 我广泛使用 codex 的 队列功能 ——当我有新想法时，我把它加到管道里。我看到很多人在实验各种多 agent 编排系统、邮件或自动任务管理——目前我不太觉得有这需要——通常 我自己才是瓶颈 。我构建软件的方法是快速迭代的。 我构建东西，玩一玩，看看它"感觉"如何，然后得到新的想法来完善它。我很少在脑子里有完整的图景 。当然，我有一个大致想法，但通常随着我探索问题领域，这个想法会发生剧烈变化。所以那些 把 完整想法 作为输入然后交付输出的系统对我来说不太好用 （译者注：这里讲的是Spec Driven的开发模式和相应的Agents） 。 我需要玩它、摸它、感受它、看见它，这就是我让它演进的方式。 • • 我基本上 从来不回滚 或使用检查点。如果某件事不是我喜欢的方式，我就让模型改它。codex 有时候会重置一个文件，但更多时候它只是撤销或修改编辑，很少需要完全回退，相反我们只是换了个方向走。 构建软件就像爬山。你不会直直地往上走，你会绕着山走、转弯，有时候你会偏离路径不得不往回走一点，这不完美，但最终你会到达你需要去的地方。 • • 我只是 直接提交到 main 。有时候 codex 觉得太乱了会自动创建一个 worktree 然后把改动合并回来，但这很少见，我只在特殊情况下才会提示这样做。我觉得 必须在脑中思考项目中不同状态的额外认知负担是不必要的 ，我更愿意线性地演进它。更大的任务我留到分心的时候做——比如写这篇文章的时候，我在这里对 4 个项目运行重构，每个大概要花 1 到 2 小时完成。当然我可以在 worktree 里做，但那只会造成大量的合并冲突和次优的重构。注意事项：我通常一个人工作，如果你在更大的团队，那这套工作流显然行不通。 • • 我已经提到过我规划功能的方式。我 经常跨项目引用 ，特别是如果我知道我已经在别的地方解决了某个问题，我会让 codex 去看 ../project folder，这通常足够让它从上下文中推断出该看哪里。这对节省提示词非常有用。 我可以直接写"look at ../vibetunnel and do the same for Sparkle changelogs"，因为它已经在那里解决了，有 99% 的把握它会正确地复制过来并适应新项目。我也是这样搭建新项目的。 • • 我见过很多人用来引用过去会话的系统。这是另一件我从来不需要或使用的东西。我在每个项目的 docs 文件夹 里维护子系统和功能的文档，并使用一个脚本加上一些指令 在我的全局 AGENTS 文件中强制模型阅读某些主题的文档。项目越大这越值得，所以我不在所有地方都用它，但它对保持文档更新和为我的任务设计更好的上下文有很大帮助。 • • 说到上下文。我曾经非常勤奋地为新任务重启会话。 有了 GPT 5.2 这就不再需要了。即使上下文更满，性能也非常好，而且通常在速度上有帮助，因为当模型已经加载了大量文件时它工作得更快。显然这只有在你序列化你的任务或让目前的改动保持足够分散以至于两个会话不太会互相触碰时才有效。codex 没有像 claude code 那样的"这个文件改了"的系统事件，所以你需要更小心——但另一方面， codex 在上下文管理方面要好得多，我觉得在一个 codex 会话中能完成的事情是在 claude 中的 5 倍 。这不仅仅是客观上更大的上下文尺寸，还有其他东西在起作用。我的猜测是 codex 内部思考得非常浓缩以节省 token，而 Opus 非常啰嗦。有时候模型会搞砸，它的内部思考流泄露给用户，所以我有好几次看到这个。说真的，codex 有它自己的说话方式，我觉得莫名地有娱乐性。 • • 提示词。我曾经用语音输入写很长、很详细的提示词。用 codex 后，我的 提示词变得短多了 ，我经常打字，很多时候我会加图片，特别是在迭代 UI（或用 CLI 时的文本复制）时。如果你给模型展示什么是错的，只需要几个词就足够让它做你想做的事。是的， 我就是那种拖一张 UI 组件的截图进去说"fix padding"或"redesign"的人 ，很多时候这要么解决了我的问题，要么让我走得相当远。我曾经引用 markdown 文件，但有了我的 docs:list 脚本后就不再需要了。 • • Markdown。很多时候我写" write docs to docs/ .md "， 直接让模型自己选文件名 。你为模型训练的内容设计的结构越明显，你的工作就会越容易。毕竟， 我设计代码库不是为了让我自己容易导航 ，我是为了让 agent 能在其中高效工作而工程化它们。 和模型对抗通常是浪费时间和 token 。 工具和基础设施 • 什么仍然很难？ 选择正确的依赖和框架是我会花相当多时间的东西。这东西维护得好吗？peer 依赖怎么样？它流不流行 = 会有足够的世界知识所以 agent 能轻松处理？同样，系统设计。我们会通过 web sockets 通信吗？HTML？我把什么放在服务器里，什么放在客户端？如何以及哪些数据从哪里流向哪里？通常这些是对模型来说有点难解释的事情，也是研究和思考有回报的地方。 • 因为我管理很多项目，我经常让一个 agent 直接在我的项目文件夹里运行，当我想出一个新模式时，我让它" 找到我最近的所有 go 项目 "并在那里也实现这个改动 + 更新 changelog。我的每个项目在那个文件里都有一个升高的 patch 版本号，当我重新访问它时，一些改进已经在等着我测试了。 • 当然我 自动化一切 。有一个 skill 用来注册域名和修改 DNS。一个用来写好前端。我的 AGENTS 文件里有一条关于我的 tailscale 网络的说明，所以我可以直接说"去我的 mac studio 更新 xxx"。 • 说到 多台 Mac 。我通常在两台 Mac 上工作。我的 MacBook Pro 接在大屏幕上，另一个屏幕上是到我的 Mac Studio 的 Jump Desktop 会话。有些项目在那里运行，有些在这里。有时候我在每台机器上编辑同一个项目的不同部分，通过 git 同步。比 worktree 简单，因为 main 上的漂移很容易调和。还有一个好处是任何需要 UI 或浏览器自动化的东西我可以移到我的 Studio，它不会用弹出窗口烦我。（是的，Playwright 有无头模式，但有足够多的情况那不管用） • 另一个好处是任务在那里 继续运行 ，所以每当我出差时，远程变成我的主要工作站，任务即使我合上 Mac 也继续运行。我过去曾实验过像 co