Theo 的 AI 编程工作流程如何改变

五个月前，我介绍过以 Cursor、Opus 和详细计划为中心的工作流程。此后我的工具和习惯发生了很大变化。现在，我把大量工作组织为与编程智能体的对话；我想用真实项目展示这种方式，而不是假装旧建议永远适用。

例子是 Lakebed，一个当时主要由我独自开发的全栈平台。处理运行时、后端、数据和部署等部分，让我能够比较不同模型、运行框架和项目指令。独立项目是一个重要前提：更大的团队可能需要不同的协调与审查方式。

录制时我主要使用 GPT-5.5，但模型偏好很快就会过时。我的订阅还享有特殊的十倍促销额度，因此我的用量限制体验不能代表标准方案。可用性、价格和额度都可能变化，应以个人实际方案为准。

运行框架是让模型检查文件、运行命令和修改内容的应用及工具层。我经常使用 Codex 运行框架，因为我喜欢相对简洁的 CLI 及其周边功能。同一个模型在不同框架中可能获得不同工具和指令，因此模型名称只是体验的一部分。

我的团队开发的 T3 Code 是管理智能体运行框架的界面；它与 T3 Chat 是不同产品，本身也不是底层运行框架。Julius 完成了大部分实现，我显然对自家产品有偏向。我也认为 Codex 桌面应用很有用，尤其适合在项目和任务会话之间切换。

我喜欢这种界面，因为它能让我看到对话、项目和工作，不必一直待在编辑器侧边栏中。我对各个应用、稳定性和团队的评价反映的是视频录制时的个人体验。其他开发者也完全可能偏好不同界面和工作流程。

我还讨论了订阅限制，以及第三方界面可能与官方客户端采用不同计费方式。这些细节只针对当时讨论的产品和条款，不是当前价格指南。选择工具前应核对供应商现行规则和实际方案。

远程工作对我很重要，因为我希望关上笔记本后智能体继续运行，之后还能重新连接并查看结果。持续运行的远程机器把执行环境与随身设备分开，也意味着我需要可靠的方法检查工作并重新连接会话。

我尝试通过 Codex 桌面应用控制 Mac mini，遇到了模型选择器消失、历史和终端输入缓慢，以及图片粘贴不稳定的问题。这些是我在当时配置中观察到的问题，并不代表每种远程连接或后续版本都一样。

随后我尝试 T3 Code 的远程和浏览器托管界面，觉得终端输入及图片粘贴在我的工作中更可靠。还有用户展示了在 Replit 上运行实例并从平板控制的方式。这些是使用示例，并非独立性能基准。

我提到 Tailscale 是一种跨网络连接设备的方式，可以避免把服务直接暴露给整个公共互联网。当时产品提供移动网页访问，团队也在开发原生应用。任何远程设置仍需要按机器和数据的情况配置合适的访问控制。

传统 SSH 终端工作流可能需要处理会话保持、会话与 worktree 切换，以及图片的变通方案。我经常粘贴截图，所以这些摩擦对我很重要。我仍会用 CLI 完成快速本地任务；偏好桌面或浏览器界面是一种工作选择，并不证明终端不适合其他人。

离开办公桌时，我越来越多地在远程机器上运行任务；直播或本地协作时，也可能使用自己的电脑。对我而言，重要的是能够恢复和检查任务，而不必让笔记本一直保持打开。

上下文管理是工作流程的重要部分。为 Lakebed 处理身份验证时，我克隆了以前的 Shoo 项目，并把其实现路径提供给智能体作为参考。相关仓库可以提供具体示例，这些示例有时很难仅靠模糊描述传达。

Lakebed 最初的会话从一段较长的语音转文字目标描述开始。对于大型改动，我仍然喜欢规划，但更偏好允许智能体调查、有时做原型的对话，而不是把规划和编辑完全割裂。我也承认智能体可能过早行动，因此合适的边界取决于具体任务。

我先解释期望的结果：一个全栈 TypeScript 系统，让智能体能构建和部署小型应用，而不必反复操作控制台。我要求模型在继续之前批评这个想法。由于项目范围很大、风险尚不清楚，这个提示包含了更多上下文。

智能体提出异议：这个方案把运行时、数据库、同步、存储、部署、安全等多项工作放在了一起。我阅读回复，讨论哪些反对意见我接受、哪些我不同意，并缩小想法。对话有价值，是因为它暴露了假设，而不是因为模型第一次回答就必然正确。

我最强烈的建议是阅读智能体说了什么。如果输出太长或难以理解，就要求它用更有用的格式表达，再回应其中的实质内容。只看生成的代码，可能会错过对真正目标的分歧，或对设计决策的警告。

人们会问我使用哪些特殊技能或提示框架。我通常先直接提问，只在需要解决反复出现的问题时才增加机制。我确实为一种批评提示设置了快捷方式，但更广泛的观点是，直接交流往往已经足够。

对于 Lakebed，我亲自编写了 AGENTS.md，简要说明项目目的、受众和工作假设。它更像一封信，而不是每个文件的目录。当我发现反复出现的误解时，就完善共享上下文，让未来的请求可以保持简洁。

当智能体质疑难以证明合理的想法时，我也会听取意见，有时甚至放弃这些想法。规划方面，带图表的 HTML 文档比大段文字更便于我审阅。第一个版本经过大量反馈，包括带标注的截图，才变得有用。

当仓库中有了好的计划示例，智能体也有了有用的项目上下文后，后续任务经常会遵循相同约定。这可以减少重复指导，但既有示例也可能传播错误，因此仍需要审查并更新指令。

项目期间我开了许多会话，但几乎都是在主检出目录上顺序进行，而不是同时运行大量 worktree。并行工作可能有用，但在这个独立项目里，我发现追踪许多并发改动会分散注意力。合适的并行程度取决于团队、依赖关系和风险。

一个简短请求询问如何部署服务端环境变量。智能体建议把本地文件作为事实来源：增加内容就创建值，修改内容就轮换值，删除内容就在部署时移除。我喜欢这个设计，于是让它实现。替换语义是一项设计选择，团队应考虑删除和密钥处理的后果。

另一个任务中，我要求制作管理用户表，支持按用户覆盖限制。我提供了更多细节，因为权限和用户体验很重要。好的提示可以简洁，同时仍明确决定结果是否可接受的目标和约束。

项目指令中的术语表帮助区分谁在说话、谁在行动：构建 Lakebed 的智能体、构建它的人、使用它的开发者，以及这些开发者的智能体。当同一个词可能指向系统的多个层次时，共享词汇尤其有用。

面对新的关注点时，我会开启新会话，避免旧对话历史不必要地影响下一个任务。智能体需要重新探索仓库，但我觉得这种代价可以接受。重新开始是用保留的上下文换取更少无关上下文，两种选择都不是放之四海皆准。

我通常描述想要的结果，而不是提前指定文件。智能体可以搜索相关实现，我也可能发现自己对正确文件的第一判断是错的。但当具体位置、约束或权限很重要时，仍然需要明确告知。

处理复杂的自定义域名问题时，我给出了已部署项目、域名、CNAME 和期望用户体验的具体例子。我询问如何处理证书，同时避免成本过高。对我而言，这个例子比冗长的抽象解释更清楚地表达了问题与约束。

最初的回答没有提供足够的成本细节，于是我要求列出明细，再更具体地描述偏好的用户流程。如果准备实施，我会让智能体写一份计划、审阅它，再把结果交给新会话。这个过程是反复迭代，而不是依赖一个完美提示。

要让智能体有办法验证自己的工作：可以使用合适的命令、测试、日志或实际界面检查。在我的配置中，计算机使用工具让它能在部署后检查应用。我觉得这提高了自己对完成结果的信心，但智能体的自我验证不能替代适当的人类审查或生产环境保护。

我估计这个项目中的大多数会话第一次就满足了自己的预期，但这是非正式回忆，并非受控成功率研究。我还展示了一项匿名部署改动：审查反馈促成修复，合并前也解决了冲突。

开始新改动时，我会估计复杂度，决定留在当前检出目录还是使用 worktree。如果讨论发现任务比预想大，我可能新建 worktree 和会话，带上最初请求及已经得到的经验。隔离是管理改动的工具，不是每项任务的必需条件。

在我的独立项目里，使用的拉取请求比很多人可能想象的少，但对涉及安全和托管层的改动，我确实寻求了额外审查。自动审查工具和其他智能体可能发现问题，我再让智能体处理。它们的发现仍需判断，审查流程也应符合风险和团队规则。

轻松创建拉取请求也有缺点：共享项目可能积累大量无人打算合并的过时提案。当 PR 是有意创建的审查材料时，一键流程很有用；但如果每个未完成实验都使用它，就可能产生噪声。

我让智能体比较一个旧的管理功能分支与最新 main，并只在改动仍有价值时解决冲突。它报告相关工作已经以更新的形式进入 main，于是中止合并并建议关闭分支。这是一个有用的例子：在继续做更多工作前，先检查工作是否仍然需要。

我的总体建议是保持工作流程易于理解，聚焦期望结果，阅读智能体的回复，并给它验证的方法。我现在很满意这套配置，但工具变化很快，我的偏好也可能再次改变。团队应按照自己的审查要求和项目情况调整做法。

我偏爱以对话为中心的工作界面，也鼓励大家尝试。重要的不是照搬我使用的应用或放弃代码审查，而是建立足够的共享上下文以推进有用的工作，并检查最终软件是否真正满足需求。