Agent 写代码，经验分享

作者：Peter Steinberger

原文：https://steipete.me/posts/just-talk-to-it

最近我在这儿比较安静，因为我正埋头于最新项目。Agentic 工程已经强大到几乎 100% 的代码都由它代写。可我却看到很多人还在绕弯子、搞花活，而不是把事办成。

这篇文章部分灵感来自昨晚在伦敦的 Claude Code Anonymous[1] 上的交流，部分则是因为 距离我上次更新工作流已经过去整整一个“AI 年”[2] 了，是时候做个回顾。

所有核心理念依然适用，所以我不会再赘述像上下文管理这类基础内容。请先阅读我的 《最佳 AI 工作流》文章[3]作为入门。

上下文与技术栈

我独自开发，当前项目是一个约 30 万行 TypeScript React 代码库，包括一个 Chrome 扩展、一个 CLI、一个基于 Tauri 的客户端应用，以及一个用 Expo 开发的移动应用。网站托管在 Vercel，每次 PR 大约 2 分钟即可部署新版本供测试；其余（应用等）尚未自动化。

使用方式与总体思路

我已完全把codexcli 当作主力工具，每天同时跑 3–8 个实例，排列成 3×3 的终端网格；大多数放在同一目录[4] ，部分实验则另开文件夹。我试过 worktrees、PR 等方式，最终都回到这套配置，因为它最快出结果。

我的 agents 自己会做 git 原子提交[5] 。为了保持相对干净的提交历史，我对 agent 文件[6]迭代了很多次，这让 git 操作更精准，每个 agent 只提交它改过的文件。

没错，Claude 可以用 hooks，而 codex 暂时还不支持；但模型极其聪明，只要它们铁了心， 任何 hook 都拦不住[7] 。

我以前被嘲笑，被称为垃圾生成器[8] ，很高兴看到并行代理慢慢成为主流[9] 。

模型选择器

我几乎用 gpt-5-codex 的中等配置构建所有东西。它在智能和速度之间是很好的折中，并且会自动调整思考深度。我发现过度纠结这些设置并不会带来有意义的结果，不用操心_超思考_也挺好。

爆炸半径

工作时，我总会考虑“爆炸半径”。这个词不是我发明的，但我非常喜欢。想到一个改动时，我大致能判断它会耗时多久、会动到多少文件。我可以往代码库里扔很多“小炸弹”，也可以扔一颗“胖子”再补几个小的。如果同时扔多颗大炸弹，就无法做隔离提交，一旦出错也更难回退。

观察 agent 时，这也是个好指标。如果耗时超出预期，我直接按 Esc，问一句“进度如何”，拿到状态后再决定帮模型找准方向、中止还是继续。别怕中途打断，文件变更是原子的，它们很擅长从断点续上。

拿不准影响范围时，我会用“先给我几个方案再动手”来评估。

为什么不用 worktrees？

我只跑一个开发服务器，随着项目演进，我会点来点去，一次验证多处改动。如果每个改动都建分支/树，速度会慢很多；开多个 dev server 也很快让人抓狂。Twitter OAuth 还有域名限制，我只能注册少数几个回调域名。

那 Claude Code 呢？

我曾经很爱 Claude Code，现在完全受不了（ 尽管 codex 是它的粉丝[10] ）。它的语气、那种 “绝对正确”[11]、测试全挂却告诉你“100% 生产就绪”的口吻——我真的受够了。Codex 更像内向的工程师，默默推进，把事情搞定。它开工前会读更多文件，所以哪怕提示很短，通常也能一次到位。

我时间线上几乎所有人都认同：codex 才是正道[12] 。[13]

Codex 的其他优势

• 约 23 万可用上下文，对比 Claude 的 15.6 万。没错，如果你运气好或愿意按 API 价付费，也能用到 Sonnet 1M，但现实是 Claude 在耗尽上下文前早就“犯傻”了，根本没法真正利用那么长的窗口。

• 更高效的 token 利用率。不知道 OpenAI 做了什么优化，但我的上下文消耗速度远慢于 Claude Code。以前用 Claude 时经常看见“正在压缩…”，换成 Codex 后几乎没撑爆过上下文。

• 消息队列。Codex 支持 排队发消息 [14] 。Claude 原本也有，但几个月前他们改成让新消息“引导”模型。如果想引导 Codex，我只需按 Esc 再回车就能发新消息。两种模式任选显然更好。我常把相关功能任务排成队列，它总能稳定地一件件完成。

• 速度OpenAI 用 Rust 重写了 Codex，效果立竿见影——快到离谱。用 Claude Code 时，我经常遇到几秒卡顿，进程内存直接飙到 GB 级，终端还狂闪，尤其是 Ghostty。Codex 完全没有这些毛病，轻盈又迅捷。

• 语言。这对我的心理健康真的很重要。 [15] 我曾无数次对着 Claude 咆哮，却很少对 Codex 发火。哪怕 Codex 模型差一点，单凭这点我也会选它。两者各用几周，你自会明白。

• 不会再有随机 Markdown 文件到处躺尸 [16] 。 懂的都懂 [17] 。

在我看来，最终用户和模型公司之间几乎没有中间地带。我用订阅制最划算。目前我有 4 个 OpenAI 订阅和 1 个 Anthropic 订阅，每月总共约 1k 美元，基本无限 token。如果用 API 调用，费用大概贵 10 倍。别跟我抠数学，我用过 ccusage 这类 token 计数工具，数据都不精确，但就算只贵 5 倍也是血赚。

我喜欢 amp、Factory 这类工具，只是不看好它们能长期存活。codex 和 claude code 每次更新都在进步，功能和思路越来越趋同。也许某家在待办列表、引导或轻微 dx 特性上暂时领先，但我不认为它们能显著跑赢大型 AI 公司。

amp 已经不再把 GPT-5 当作主推模型，现在把它称为 “oracle”[18]。与此同时，我用的是 codex，基本上一直在和这个更聪明的模型——oracle——并肩工作。 当然有基准测试[19] ，但鉴于使用数据严重偏斜，我并不相信那些结果。codex 给我的效果远比 amp 好。不过 session 共享这点我得给他们点赞，他们确实在推进一些有趣的想法。

工厂，还是不信。他们的视频有点尴尬，不过我的时间线上确实有不少好评，尽管还不支持图片，而且带有标志性的闪烁[20] 。

Cursor 的 Tab 补全模型在业界领先，前提是你还亲自写代码。我主要用 VS Code，但挺欣赏他们在浏览器自动化和计划模式上的推进。我确实试过 GPT-5-Pro，可 Cursor 那些五月就烦过我的老 bug 还在[21] 。听说在修，所以我把它留在 Dock 里。

像 Auggie 这样的工具在我时间线上只冒了个泡，之后再没人提起。归根结底，它们都不过是套了 GPT-5 和/或 Sonnet 的壳，随时可换。RAG 对 Sonnet 或许有用，但 GPT-5 的检索能力太强，根本没必要再给代码建独立向量索引。

最有盼头的是 opencode 和 crush，尤其是搭配开源模型。你完全可以用自己的 OpenAI 或 Anthropic 订阅（ 靠点小技巧[22] ），不过这么做是否合规存疑，而且把为 Codex 或 Claude Code 优化的模型塞进一个更弱的套壳里，意义何在？

那 $openmodel呢？

我一直关注中国的开源模型，它们追赶的速度令人惊叹。GLM 4.6 和 Kimi K2.1 都是强有力的竞争者，正逐步逼近 Sonnet 3.7 的水准，不过我依然不把它们当作日常主力[23] 。

基准测试只能说明一半。在我看来，智能体工程在五月随着 Sonnet 4.0 的发布，从“这玩意儿不行”跃升到“这还不错”；而 gpt-5-codex 的出现，则让我们从“不错”直接飞跃到“这也太神了”。

规划模式与方法

基准测试忽略了“模型+测试框架”在收到提示时所采取的策略。Codex 远比其他模型谨慎，在决定行动前会读取仓库中的更多文件。 当你提出一个愚蠢请求时，它会更有力地反驳。[24] Claude 等智能体则急切得多，先随便试_点什么_再说。这可以通过规划模式和严格的结构化文档来缓解，但对我来说这像是在给破系统打补丁。

我现在几乎不用大规划文件与 Codex 协作。Codex 甚至没有专门的规划模式——但它对提示的遵从度高得多，我只需写“我们先讨论”或“给我几个选项”，它就会耐心等我拍板，不需要任何测试框架的花招。直接跟它说话就行。

但 Claude Code 现在有了插件[25]

你听到远处那声叹息了吗？是我。真是一坨大写的废话。这让我对 Anthropic 的重心彻底失望。他们试图用插件给模型的低效打补丁。没错，为特定任务维护好文档是明智之举——我在 docs 文件夹里放了一大摞有用的 Markdown 文档。

可是子代理啊！！！

但关于这场子代理的整段舞蹈，总得说两句。早在五月，它还叫子任务，主要是一种在模型不需要全文时把任务甩到独立上下文里的做法——核心目的是并行化，或减少像嘈杂构建脚本这类场景的上下文浪费。后来他们重新包装并升级为子代理，于是你带着几条指令就能优雅地甩出一个任务。

使用场景没变。别人用子代理做的事，我通常靠开几个独立窗口搞定。如果我想研究点什么，就在另一个终端面板里做完，再贴到另一个面板。这样我能完全掌控并看见我所设计的上下文，而子代理却让你更难查看、引导或控制回传的内容。

我们还得聊聊 Anthropic 在博客中推荐的那个子代理。看看这个 “AI 工程师”代理[26] 。它是一锅大杂烩，提到 GPT-4o 和 o1 的集成，整体就像自动生成的词语浓汤，努力装作有意义。里面没有任何实质内容能让你的代理成为更优秀的“AI 工程师”。

这到底是什么意思？如果你想得到更好的输出，告诉模型“你是一名专注于生产级 LLM 应用的 AI 工程师”并不会改变什么。给它文档、示例和“做/不做”清单才有用。我打赌，如果你让 agent 去“Google AI agent 构建最佳实践”并让它加载一些网站，效果会比这堆废话好得多。你甚至可以说这种垃圾就是上下文毒药[27] 。

我如何写提示

当初用 claude 时，我（当然没有， 我说话[28] ）会写非常冗长的提示，因为这个模型“懂我”，我给的上下文越多越准。虽然对任何模型都成立，但我发现用 codex 后提示词明显变短了。往往只有一两句话+ 一张图[29] 。这模型读代码库的能力惊人，直接就能 get 到我。我有时甚至回归打字，因为 codex 理解所需的上下文实在太少了。

添加图片是一个绝佳的技巧，可以提供更多上下文，模型非常擅长精准定位你展示的内容，它能找到字符串并匹配，直接抵达你提到的地方。我敢说，至少 50% 的提示里都有截图。我很少做标注，那样效果更好，但速度较慢。把截图拖进终端只需 2 秒。

带语义修正的 Wispr Flow[30] 依然是王者。

基于网页的 Agent

最近我又折腾了一番网页 Agent：Devin、Cursor 和 Codex。Google 的 Jules 看起来不错，但配置过程实在烦人，而且 Gemini 2.5 现在已经算不上好模型了。等 Gemini 3 Pro[31] 发布，情况可能会迅速改变。唯一留下来的是 codex web。它同样难配置且问题多多，目前终端加载不正常[32] ，但我用了一份旧环境镜像，总算跑了起来，代价是启动更慢。

我用 Codex Web 当临时问题跟踪器。出门在外想到什么，就在 iOS 应用里丢一句话，回头在 Mac 上统一处理。当然，我完全可以做更多，甚至直接在手机上审阅/合并，但我选择不。工作已经够上瘾了，出门或见朋友时我不想再被拉进去。嘿，这话出自一个花了快两个月做工具、只为让手机写代码更方便[33]的人。

Codex Web 原本不计入用量上限，但这种好日子已经屈指可数[34] 。

智能体之旅

聊聊工具。Conductor[35]、Terragon[36]、Sculptor[37]，还有上千个同类。有的是兴趣项目，有的泡在 VC 的钱海里。我试了一大堆，没有一个留下。在我看来，它们都在绕开当下的低效，并推行一种并不最优的工作流。更别提，大多数把终端藏起来，不让用户看到模型输出的全部内容。

大多数只是 Anthropic SDK 的薄壳 + 工作树管理，没有护城河。我甚至怀疑你是否真的想在手机上更方便地调用编程智能体。它们带给我的那点用例，codex web 已完全覆盖。

我确实注意到一个模式：几乎每位工程师都会经历一段“造自己的工具”的阶段，大多因为好玩，也因为现在做起来太容易了。除了造那些（我们以为）能让以后造工具更简单的工具，还能造什么呢？

但 Claude Code 支持后台任务！

没错。codex 目前确实少了些 Claude 的花哨功能，最痛的缺失是后台任务管理。虽然它该有超时机制，但我已多次遇到 CLI 任务卡住的情况，比如启动 dev server 或陷入死锁的测试。

这就是我又转回 Claude 的原因之一，但鉴于该模型在其他方面实在蠢得离谱，我现在用 `tmux`[38]。这是个老工具，可在后台持久会话里跑 CLI，模型里也有充足的世界知识，所以你只需“用 tmux 跑”。无需定制 agent md 的瞎折腾。

那 MCP 呢

关于 MCP，别人已经写了很多。在我看来，大多数只是给市场部打勾炫耀用的。几乎所有 MCP 其实就该是 CLI。说这话的人， 我自己就写了 5 个 MCP[39]。

我可以直接通过名称调用 CLI，无需在 agents 文件里写任何说明。代理第一次调用时会随便敲个 $randomcrap，CLI 会弹出帮助菜单，于是上下文立刻就掌握了全部用法，之后一路顺畅。不像 MCP 那样持续烧钱、把垃圾塞进上下文，我无需为任何工具付费。用 GitHub 的 MCP，一次就烧掉 23k token——他们后来优化过，刚上线时差点 50k。换成ghCLI，功能几乎一样，模型本来就会用，上下文税为零。

我把部分 CLI 工具开源了，比如 bslog[40] 和 inngest[41]。

我现在用 `chrome-devtools-mcp`[42] 来闭环[43] ，它已取代 Playwright 成为我调试网页的首选 MCP。虽然用得不多，但真要用时，它能很好地闭环。我给自己的网站做了设计：可以生成 API Key，让模型通过 curl 查询任意端点，几乎所有场景下都更快、更省 token，所以连这个 MCP 也不是天天需要。

但代码就是一坨屎！

我大约把 20% 的时间[44]花在重构上。当然，这些全由智能体完成，我可不会手动浪费时间。重构日非常适合在我精力不足或疲惫时进行，因为无需太多专注或清晰思考也能取得显著进展。

典型的重构工作包括：用jscpd查重、用 `knip`[45] 清理死代码、跑eslint的react-compiler和废弃插件、检查能否合并新引入的 API 路由、维护文档、拆分过大的文件、为棘手部分补测试和注释、更新依赖、 升级工具链[46] 、调整目录结构、找出并重写慢测试、引入现代 React 模式并重写代码（例如你可能不需要 `useEffect`[47]）。总有事情可做。

你可以说这些应该在每次提交时就做，但我发现“快速迭代→维护改进”这种阶段式节奏——也就是偿还技术债——反而更高效，也更有趣。

你采用“先写规格再开发”吗？

我六月份还这么做[48] 。先设计一份大规格，然后让模型照着敲代码，最好一口气跑几个小时。在我看来，这已经是老派的软件开发思路了。

现在我通常直接跟 Codex 开聊：把网页、点子贴进去，让它读代码，我们一起把新功能揉出来。如果逻辑比较绕，我就让它把所有内容写成一份规格，扔给 GPT-5-Pro 审一遍（通过 chatgpt.com），看看有没有更好的主意（出乎意料地，计划常常因此大幅改进！），再把我觉得有用的部分贴回主上下文，更新文件。

到现在，我对哪些任务需要多少上下文已经心里有数，而 codex 的上下文容量相当不错，所以我常常直接开干。有些人很“虔诚”，每次都清空上下文重新规划——我觉得这对 Sonnet 有用，但 GPT-5 处理大上下文强得多，那样做反而每次得多花 10 分钟，让模型慢慢把构建功能所需的文件重新拉一遍。

更有趣的做法是做 UI 相关的工作时，我往往从极其简单、严重缺需求的请求开始，看着模型实时构建、浏览器同步刷新。接着我把后续改动排队进去，持续迭代功能。很多时候我根本不确定最终该长什么样，这样就能边玩边试，看着它慢慢成形。我常见 codex 做出我压根没想到的有趣效果；我不重置，只是不断迭代，把混沌一点点捏成我觉得对的样子。

构建过程中，我常会蹦出相关交互的灵感，顺手把别的部分也改了；这部分我交给另一个 agent 处理。通常我主攻一个核心功能，再捎带几个沾边的小任务。

我一边写这篇文章，一边在 Chrome 扩展里新建 Twitter 数据导入器，为此我重构了 graphql 导入器。因为不确定方案是否合适，我把它放在独立文件夹，方便提 PR 时回头审视。主仓库在做重构，所以我能专心写这篇文章。

让我看看你的斜杠命令！

我只有几个，而且很少用：

• /commit（自定义提示，说明多个 agent 在同一目录工作，只需提交你的改动，这样我就能得到干净的提交信息，gpt 不会因为其他改动而崩溃，也不会在 linter 报错时试图回滚）

• /automerge（一次处理一个 PR，回应机器人评论、回复，让 CI 变绿，并在变绿后 squash）

• /massageprs（与 automerge 相同，只是不 squash，这样如果 PR 很多，我可以并行处理）

• /review（内置，偶尔用，因为 GitHub 上已有 review 机器人，但有时仍有用）

即便有了这些，我通常还是只打“commit”；除非明知脏文件太多，不给点提示代理可能会搞砸。当我确信这几个字就够了，就不必再玩花样/浪费上下文。你会慢慢培养出直觉。我还没见过其他真正有用的命令。

你还有哪些别的技巧？

与其绞尽脑汁写出完美提示来驱动 Agent 完成长时间任务，不如用“懒人方案”。做大重构时，Codex 经常半路就停下来。如果你想走开等结果， **直接连发几条“继续”消息**[49]即可。Codex 完成后若再收到消息， 它会愉快地无视[50] 。

让模型在每个功能/修复完成后立刻写测试，用同一份上下文。这样测试质量会高得多，还能揪出实现里的 bug。纯 UI 微调就没必要写测试，其他情况都建议写。AI 写测试普遍一般，但聊胜于无——说实话，你自己会给每个小修复都补测试吗？

让模型保留你的意图，并“在复杂处加注释”，对你和未来的模型运行都有好处。

当遇到难题时，只需提示并加入一些触发词，如“慢慢来”“全面”“阅读所有可能相关的代码”“提出可能的假设”，就能让 Codex 解决最棘手的问题。

你的 Agents/Claude 文件长什么样？

我有一个 Agents.md 文件，通过符号链接指向 claude.md，因为 Anthropic 决定不做标准化。我知道这很别扭，也不理想，毕竟 GPT-5 偏好的提示方式[51] 与 Claude 差异很大。如果你还没读过它们的提示指南，现在先停下来去读。

Claude 对 全大写尖叫命令 [52] 反应良好——比如威胁它“如果执行命令 X 就意味着彻底失败，100 只小猫会死”——但 GPT-5 会被吓到（理所当然）。所以把这些都扔掉，像人类一样说话。这也意味着这些文件无法最优共享。但对我不是问题，因为我主要用 Codex，并接受在极少数让 Claude 上场时，指令可能偏弱。

我的 Agent 文件目前约有 800 行，感觉像是一堆组织留下的“疤痕”。不是我写的，是 Codex 写的；每当发生什么事，我就让它在里面添一句简明备注。我迟早得清理，但尽管庞大，它却出奇地好用，GPT 也确实大多会遵从里面的条目——至少比 Claude 靠谱得多。（给点面子的话，Sonnet 4.5 在这方面有进步。）

除了 git 指令，它还包含对我的产品的说明、我偏好的命名和 API 模式、关于 React Compiler 的笔记——往往是我用的技术栈太前沿，超出了模型世界知识范围的东西。我预计随着模型更新，又能精简不少。例如，Sonnet 4.0 得靠我指点才能理解 Tailwind 4，而 Sonnet 4.5 和 GPT-5 已经内置了这部分知识，于是我把那些废话全删了。

重点部分包括我偏好的 React 模式、数据库迁移管理、测试、 使用并编写 ast-grep 规则[53] 。（如果你不了解或没用过 ast-grep 作为代码库检查工具，请先暂停，让你的模型把它配置成 Git 钩子以阻止提交。）

我也尝试过并开始使用基于文本的“设计系统”[54] 来规范外观，目前尚无定论。

所以 GPT-5-Codex 就完美了？

当然不是。有时候它会重构半小时，然后崩溃[55]并全部回退，你得像哄小孩一样重新运行并安抚它，告诉它时间足够。有时它会忘了自己还能执行 bash 命令[56] ，需要一点鼓励。有时它会用俄语或韩语[57]回复。 有时这家伙一滑，把原始思考发给了 bash。[58] 但总的来说这些情况相当罕见，它在其他方面简直好得离谱，所以我可以忽略这些小毛病。人类也不完美。

我对 codex 最大的烦恼是它“丢”行，快速往上滚时部分内容会消失。我真希望这排在 OpenAI 的 bug 清单首位，因为它是我有时不得不放慢速度、以免消息消失的主要原因。

结论

别把时间浪费在 RAG、子代理、Agents 2.0[59] 这类多半只是噱头的玩意儿上。直接跟它聊，玩起来，培养直觉。你跟代理打得越多，结果就越好。

Simon Willison 的文章说得极是[60] ——管理代理所需的很多技能，跟管理工程师[61]差不多——几乎全是资深软件工程师的特质。

没错， 写好软件依旧很难[62] 。我不再手写代码，不代表我就不再深入思考架构、系统设计、依赖、功能，或者怎样让用户惊喜。用 AI 只是意味着大家对交付的期望值更高了。

PS：这篇文章 100% 有机手写。我热爱 AI，也承认有些事还是老派[63]来得好。保留错别字，保留我的声音。✌️[64]

参考资料

Claude Code Anonymous: https://x.com/christianklotz/status/1977866496001867925

距离我上次更新工作流已经过去整整一个“AI 年”: https://x.com/pmddomingos/status/1976399060052607469

《最佳 AI 工作流》文章: https://steipete.me/posts/2025/optimal-ai-development-workflow

放在同一目录: https://x.com/steipete/status/1977771686176174352

[5]

原子提交: https://x.com/steipete/status/1977498385172050258

[6]

agent 文件: https://gist.github.com/steipete/d3b9db3fa8eb1d1a692b7656217d8655

[7]

任何 hook 都拦不住: https://x.com/steipete/status/1977119589860601950

[8]

垃圾生成器: https://x.com/weberwongwong/status/1975749583079694398

[9]

慢慢成为主流: https://x.com/steipete/status/1976353767705457005

[10]

尽管 codex 是它的粉丝: https://x.com/steipete/status/1977072732136521836

[11]

“绝对正确”: https://x.com/vtahowe/status/1976709116425871772

[12]

codex 才是正道: https://x.com/s_streichsbier/status/1974334735829905648

[13]

。: https://x.com/kimmonismus/status/1976404152541680038

[14]

排队发消息: https://x.com/steipete/status/1978099041884897517

[15]

这对我的心理健康真的很重要。: https://x.com/steipete/status/1975297275242160395

[16]

不会再有随机 Markdown 文件到处躺尸: https://x.com/steipete/status/1977466373363437914

[17]

懂的都懂: https://x.com/deepfates/status/1975604489634914326

“oracle”: https://ampcode.com/news/gpt-5-oracle

当然有基准测试: https://x.com/btibor91/status/1976299256383250780

标志性的闪烁: https://x.com/badlogicgames/status/1977103325192667323

[21]

Cursor 那些五月就烦过我的老 bug 还在: https://x.com/steipete/status/1976226900516209035

[22]

靠点小技巧: https://x.com/steipete/status/1977286197375647870

[23]

日常主力: https://x.com/imfeat7/status/1977246145278583258

[24]

当你提出一个愚蠢请求时，它会更有力地反驳。: https://x.com/thsottiaux/status/1975565380388299112

[25]

插件: https://www.anthropic.com/news/claude-code-plugins

[26]

“AI 工程师”代理: https://github.com/wshobson/agents/blob/main/plugins/llm-application-dev/agents/ai-engineer.md

[27]

上下文毒药: https://x.com/IanIsSoAwesome/status/1976662563699245358

[28]

我说话: https://x.com/steipete/status/1978104202820812905

[29]

一张图: https://x.com/steipete/status/1977175451408990379

[30]

Wispr Flow: https://wisprflow.ai/

[31]

Gemini 3 Pro: https://x.com/cannn064/status/1973415142302830878

[32]

加载不正常: https://x.com/steipete/status/1974798735055192524

[33]

花了快两个月做工具、只为让手机写代码更方便: https://steipete.me/posts/2025/vibetunnel-first-anniversary

[34]

这种好日子已经屈指可数: https://x.com/steipete/status/1976292221390553236

[35]

Conductor: https://conductor.build/

[36]

Terragon: https://www.terragonlabs.com/

[37]

Sculptor: https://x.com/steipete/status/1973132707707113691

[38]

tmux: https://x.com/steipete/status/1977745596380279006

[39]

我自己就写了 5 个 MCP: https://github.com/steipete/claude-code-mcp

[40]

bslog: https://github.com/steipete/bslog

[41]

inngest: https://github.com/steipete/inngest

[42]

chrome-devtools-mcp: https://developer.chrome.com/blog/chrome-devtools-mcp

[43]

来闭环: https://x.com/steipete/status/1977762275302789197

[44]

20% 的时间: https://x.com/steipete/status/1976985959242907656

[45]

knip: https://knip.dev/

[46]

升级工具链: https://x.com/steipete/status/1977472427354632326

[47]

你可能不需要useEffect: https://react.dev/learn/you-might-not-need-an-effect

[48]

我六月份还这么做: https://steipete.me/posts/2025/the-future-of-vibe-coding

[49]

直接连发几条“继续”消息: https://x.com/steipete/status/1978099041884897517

[50]

它会愉快地无视: https://x.com/steipete/status/1978111714685063640

[51]

GPT-5 偏好的提示方式: https://cookbook.openai.com/examples/gpt-5/gpt-5_prompting_guide

[52]

全大写尖叫命令 : https://x.com/Altimor/status/1975752110164578576

[53]

使用并编写 ast-grep 规则: https://x.com/steipete/status/1963411717192651154

[54]

基于文本的“设计系统”: https://x.com/steipete/status/1973838406099874130

[55]

崩溃: https://x.com/steipete/status/1973834765737603103

[56]

bash 命令: https://x.com/steipete/status/1977695411436392588

[57]

用俄语或韩语: https://x.com/steipete/status/1976207732534300940

[58]

有时这家伙一滑，把原始思考发给了 bash。: https://x.com/steipete/status/1974108054984798729

[59]

Agents 2.0: https://x.com/steipete/status/1977660298367766766

[60]

Simon Willison 的文章说得极是: https://simonwillison.net/2025/Oct/7/vibe-engineering/

[61]

管理工程师: https://x.com/lukasz_app/status/1974424549635826120

[62]

写好软件依旧很难: https://x.com/svpino/status/1977396812999688371

[63]

老派: https://x.com/Alphafox78/status/1975679120898965947

[64]

✌️: https://x.com/rohanpaul_ai/status/1977005259567595959