加倍网从日常助手、架构搭档到“CTO”：用AI为开发提效10倍

编者按：本文作者现身说法，戳破“万能AI提示词”的营销泡沫，分享其基于任务类型（日常编码/宏观设计/并行开发）精准选用AI工作流的实战经验。通过三种分层协作模式，作者将编程效率提升至新维度，为开发者提供了极具参考价值的LLM应用范式。文章来自编译。

过去需要我花一周时间编程的工作，如今几小时就能完成。诀窍在于弄清楚哪种AI工作流最适合你的问题。

我上周在X平台上花了三个小时，看着那些提示词大师推销他们最新的“万能灵药”：

“用这个ChatGPT提示词，就能取代你整个工程团队。”

“搭配这个秘密系统提示词来使用Claude，就能超越所有开发者。”

“我这份497美元的提示词库，能让你成为效率10倍的码农。”

与此同时，我给Cora（我们的AI邮件助手）推出了五个新功能，里面用到了Anthropic、Google以及OpenAI这三家提供的模型，但上述“神奇提示词”一个都没有用。我没找到一个完美的提示词或工具来包揽我所有工作。事实上，我已经不再寻找这种“万能钥匙”了。相反，我根据手头要解决的具体问题来选择不同的工具。

这种方法彻底改变了我的代码交付方式。我设定目标并明确规则，然后我所有的拉取请求（pull request）百分之百都是由像Claude Code这样的AI工具开启的。每一个研究任务都会经过ChatGPT和Claude的处理。AI帮我完成了30%的代码审查工作，并解决了我遇到的一半bug。过去需要我整整一周编程的事情，现在几小时就能搞定。

我知道这有点自相矛盾：我一边在批评那些“一刀切”的AI解决方案，一边自己也在打造一款AI产品。但Cora可没承诺包办你所有的邮件工作——它只是帮你把时间从不重要的部分节省出来。我用AI工作的原则也一样：清除那些机械性的编程任务，从而专注于真正需要思考的部分。

在多年大语言模型（LLMs）开发实践中（最近项目是邮件智能分诊回复系统Cora），我提炼出三种优化认知负荷的核心编程模式。正是这套方法论，让我从 X 上的“AI大师”吐槽者，蜕变为午休前就能交付新功能的开发者。

日常编码搭档：Windsurf 和 Cursor（心流伴侣）

当我进入程序员的“高效状态”——清楚知道要开发什么，准备好动手编程时——我就会用 Windsurf 和 Cursor，配上像 Claude Sonnet 4 或 Gemini 2.5 Pro 这样的思考模型。这套组合适用于：

在现有代码基础上做增量开发

解决已理解透彻的问题

在编码时保持专注和心流状态

这个工作流的特别之处在于轻量和响应迅速。我用简单的话口述编程指令——“添加一个验证电子邮件地址的函数”——AI就把它们翻译成代码。AI编辑器不会打扰我的专注，减少了我的意图与实现之间的摩擦。在这个模式下，我是思考者，AI纯粹是执行者。所有决策都是我推动的，而AI处理编码的机械性部分。我对架构和设计选择保持完全控制。

举个实例：我需要给Cora添加一个新的筛选选项，类似于“所有邮件”视图，但只显示重要信息。这工作很简单——我手动敲20分钟就能搞定。但我更想把这20分钟花在规划下一个功能上。所以，我待在编辑器里，用自然语言描述了我的需求——只显示重要邮件、高效地编写查询、检查索引、确保它能干净利落地接入现有上下文——然后看着AI实现。20分钟的编码，对比2分钟和编辑器的对话——哪个更划算，一目了然。

Cursor 为我构建了一个“重要邮件”收件箱——证明它能处理常规的编码杂务。

表面上看着似乎跟“氛围式编程”（vibe coding）很像，但在意图上有重要区别。氛围式编程是由外及里的：你告诉AI你希望软件做什么，让它自己想办法实现。我的方法是由里及外的：我既知道目的地，也知道路线。我已经决定了架构、模式和具体的实现细节。我只是把将决策转化为语法的机械性工作委托出去。AI是我的双手，而非我的大脑。

关键优势在于速度，且不牺牲质量或准确性。我说出来，AI就将我的意图转化为代码。感觉就像和一个永不疲倦的搭档进行结对编程。

这种模式在风险不高、方向明确时的效果最好。我不依赖AI做重大的架构决策——我用它来实现我自己也能编写、但更愿意委托出去的解决方案。

我在以下情况会选用这个工作流：

我确切知道“完成”是什么样子。

我正在处理一个单一的、专注的任务。

我需要高效开发，同时不打断心流状态。

当开发冲刺（sprint）进行到一半，或者接近尾声只需要持续推进时，这是我默认使用的模式。

利用搜索和推理模型进行宏观思考：架构师之道

当我面对一张白纸——从头开始一个项目、设计一个新的系统架构，或者梳理复杂的遗留代码时——我需要不同的方法。这时就用到了我专注于研究和探索的工作流，使用：

ChatGPT（搭配 o3 与工具）

RepoPrompt 或 Claude Code agentic search（一种工具，能让AI全面了解你的代码库，而不是盲目工作）

并行使用多个模型（Claude 4 Opus, Gemini 2.5 Pro, o3）

跟日常编码我主导每个细节不同，在这里我把AI当作真正的思考伙伴。我以开放的心态开始，并刻意避免向任何方向施加过大的推力。目标就是收获惊喜——发现我自己根本想不到的方法和解决方案。

最近，我们在想办法解决如何让营销网站与Cora应用跑在在同一个地址上，好让访问者能在两者间无缝切换。我完全不知道从何入手。我们是该加一个转发流量的“前门”服务器（反向代理），在离访问者更近的数据中心运行轻量级代码（使用边缘函数），还是仅仅调整我们的网址设置（DNS）将人们指向他们需要去的地方？

我把问题抛给了三个不同的模型，但没有规定解决方法：“我们需要把营销网站放在 cora.computer，同时让应用也保留在根域名（root domain）。有什么选项？”

ChatGPT 列出了托管选项——展示了AI在为大方向选择进行头脑风暴时的价值。

每个模型对同样的核心方法给出了略为不同的看法，但各自的解决方案框架不同。ChatGPT 按照每个选项的构建难度来组织输出。Claude 关注哪个方案运行最快。Gemini 则担心哪些方案可能会破坏我们现有的设置。

这些解决方案提供了足够的差异性，给了我选择的空间，这正是以这种方式编程时你所期望的。随着深入探索，我的问题变得更加具体：“给我演示一下Cloudflare Workers如何处理认证透传（authentication passthrough）”，或者“在这个用例中，使用worker（边缘函数）对延迟有什么影响？”对话从“我有哪些选择？”演变为“哪个方案最适合我们的特定约束条件？”

这种工作流的核心是发现和探索。我用这些工具来研究API、最佳实践和架构模式——那些经过时间考验的方案，详细说明了各个组件该放在哪里以及它们如何连接。通过把同样的提示词喂给多个模型，我可以比较它们的建议，找出盲点，并综合得出一个更全面的方法。

其实我是在知道如何做之前，先找到并理解我想要做的东西。我试图定义问题空间本身。

我把这些回复当作草稿，把最好的想法整合在一起，剔除重复内容，并将集体的输出重塑成一个连贯的计划。当我开始看到想法雏形浮现时，我的流程也随之改变。我转入精炼模式，深入更多细节的同时，修剪边缘、简化内容、不断提炼，直到触及解决方案的核心。这个逐步聚焦的过程至关重要——先广撒网，然后逐步聚焦，直到得到精准且可操作的东西。

举个实例：我想把一个模糊的功能构想变成具体计划，于是我让ChatGPT创建一个实施方案或产品需求文档（PRD）。几秒钟后，右侧窗格就填满了一份可直接编辑的文档——目的、背景、目标和后续步骤——而我们简短的聊天记录留在左侧用于后续调整。一条提示词，计划就完成了80%。

ChatGPT 将零散的笔记转化为整洁的计划——展示了AI在梳理行动清单方面的天赋。

当我满意这个方向后，我就把这项研究转化为详细的实施方案或PRD，然后用我的日常编码工作流来执行。

这种方法的关键区别在于，你一开始要给AI宽松的自由度。与日常编码工作流注重具体性不同，这种方法最初得益于一定的模糊性。让模型用你未曾考虑过的方向给你带来惊喜，然后随着计划的成形，再逐步优化和聚焦。

我在以下情况会选用这个工作流：

我还不太确定“完工”是什么样子。

各组件紧密交织，需要彼此协作才能工作。

我在动手开发前需要思考和探索。

当问题庞大到感觉自己的脑子hold不住时，我就会选用这个方案。

Claude Code、Devin或Cursor智能体三管齐下：CTO之道

我最具实验性（也最令人兴奋）的工作流是同时处理多个功能，这很像CTO监督多个工程团队的方式。我确信这代表了软件开发的未来，尽管目前因为这种做法是全新的、实验性的，所以也最难掌握。还没有任何既定的最佳实践，因为我们还没来得及总结出来。

在以下情况下，CTO方法能行得通：

你有多个可以独立开发、彼此不依赖的组件。

每个组件都有清晰的边界和规格说明。

你已经提前完成了架构层面的思考。

我的做法是：先把一天的工作分解成独立的任务，为每项任务创建详细的规格说明，然后将它们委派给不同的AI智能体——可以是Devin（它能创建完整的拉取请求），也可以是配合git工作树（git worktrees）的Claude Code，或者是OpenAI的Codex，或者Cursor后台智能体（Cursor Background Agents）来处理代码库的不同部分。

可以把它想象成拥有5到10名熟练的工程师同时处理不同功能，而你负责提供指导和审查。这有望带来巨大的潜在生产力提升——顺序执行可能需要一周的工作，在并行模式下可以压缩到一天完成。

实际上大概是这样的：在完成了几个Cora功能的研究阶段后，我得到了五个需要构建的独立功能或修复的清晰规格说明。我同时启动了多个后台智能体：一个智能体修复了我们的晨间简报发送时间的bug。另一个改进了我们评估邮件分类准确率的方式。第三个执行系统升级，应用上更新的AI模型。每个智能体都有自己的git工作树、上下文和专注的任务。

工作流变成了迭代循环：我启动多个开发流，然后轮流查看，审查进度、提供反馈，接着转向下一个，同时智能体们正在实现我的建议。