我认为很多想要开发新软件项目的人在项目启动之初常常会遇到困难，因为从零开始创建一个空白的代码库似乎令人望而生畏。 因此，我想快速介绍一下我最新的工作流程，它大大降低了入门所需的精力和时间门槛。 最重要的部分是要有一个好主意，或者要制作一个如果真的能正常运作并很好地完成其想要做的事情，就能对很多人真正有用的东西。 这部分我帮不上什么忙，不过从解决自身（非小众）痛点入手是个很好的方法，这的确是个不错的起点。我发现自己总是会冒出很多项目创意。 总之，下一步是用非正式的方式把想法写下来，就像你给好朋友发一封简短的电子邮件一样。 你不需要把它变成一个正式的计划，只需要用最快的方式传达基本思路和它的作用，并具体说明你知道要使用的技术栈或库的任何部分。 附件截图展示了我几天前偶然想到的一个想法的范例。我大概花了10到15分钟就写完了。文章不需要很长，可以引用其他资料来保持简洁。 这段初始描述会成为 GPT-5 Pro 的提示。运行过程通常至少需要 15 到 20 分钟（有趣的是，比编写提示所需的时间还要长）。您可以尝试其他模型，但它们的效果会差很多。 我通常会把同样的提示交给 Grok4 Heavy 或 Opus4.1 进行测试，并将测试结果反馈给 GPT-5 Pro，鼓励 Pro 采纳其他提案中任何有价值的想法。如果这些方案中确实包含一些巧妙的设计，GPT-5 Pro 就会识别并加以整合。 然后我会让 Pro 根据其第一个回复创建一个详细的、细粒度的 markdown 计划文档，并将其保存为一个新创建的项目文件夹中的文件。 然后我通常会反复修改几次，在 Web 应用程序中发起一个新的 Pro 对话，提供完整的 markdown 计划文件，并告诉它以各种方式增强该计划，使其更可靠、更健壮、性能更佳、更直观、更用户友好，以及其他好的形容词。 我会鼓励 Pro 对最新的文档、博客、教程等进行详尽的网络研究，以找到更好的库或实现方法。 然后我会将提出的修改意见粘贴到 Codex 中，并要求 Codex 将这些修改意见整合到现有的 Markdown 计划文档中。 经过两三轮这样的反复推敲，事情就会稳定下来，最终形成一个非常完善的计划。这才是关键所在，因为在计划阶段，由于还没有编写任何代码，调整和改进起来要容易得多。俗话说，三思而后行。 以下是根据最初的想法而生成的最终计划文档的链接： https://t.co/mXHOZH9b2p 此时，我开始添加 AGENTS dot md 文件；我从现有的一个文件开始，并要求 Pro（在编写最新计划文档的同一会话中）针对这个新项目和技术栈对其进行自定义，同时保留任何通用内容。 如果有一些至关重要的库，我有时也会创建专门的最佳实践指南（例如，如果您正在创建一个 MCP 服务器，我会生成一个专门针对 fastmcp 库的最佳实践指南，其中还会详细说明如何构建项目等等）。 此时，我要求 codex 在一次会话中开始构建项目结构，创建文件夹和空白占位符文件，创建 .gitignore 文件等。 我的流程与典型方法截然不同。我首先使用 Steve Yegge 的 Beads 项目，并指示 Codex 使用 Beads 将计划文档转换为一系列任务和子任务。 然后我使用 tmux 创建了一堆 Codex 会话，一次最多可以创建 8 个（我认为数量更多应该也没问题）……
然后我启动我的 mcp 代理邮件项目，告诉他们注册邮件并向其他代理介绍自己，完整阅读 AGENTS dot md 和计划文档（按名称引用此文件），并在初始邮件中查看 beads 任务。 之后，就只是循环播放同样的预设信息，我告诉他们选择一个任务并开始做，鼓励他们反复完成几次，然后检查他们的工作，然后查看他们的经纪人邮件并回复任何需要回复的消息，以及与他们的其他经纪人沟通他们的工作进展。 我昨天录制了一个 23 分钟的视频，展示了这篇文章中示例项目的这一部分是如何工作的，视频里把这一切都解释得很清楚了： https://t.co/KedUEzSRRG 录完之后，我琢磨出了如何自动化最后这部分操作，这样我就可以用 tmux 广播命令，自动将大量消息排入队列发送给所有客服人员，让他们忙上好几个小时。我会在下面附上那篇文章的链接。 这就是基本流程。如果你按照这个流程来做，你可以在几天内创建出极其复杂且功能强大的软件，可能只需要一两个小时的实际“人工时间”，但却需要大量的代理工时（类似于人工工时）。 当自主代理不使用 gpt-5-codex 指令进行工作时，其每小时的工作量可能相当于人类的 10 到 20 小时。它们的思考和打字速度真的很快！
这是我关于使用 tmux 实现自动化闭环的帖子链接：
以下是 MCP Agent Mail 项目的链接，正是这个项目让这一切成为可能： https://t.co/aXsf08Pms7