从日常助手、架构搭档到“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工作树、上下文和专注的任务。
工作流变成了迭代循环：我启动多个开发流，然后轮流查看，审查进度、提供反馈，接着转向下一个，同时智能体们正在实现我的建议。
Claude Code 完成了一项功能：向停用Cora的用户发送邮件寻求反馈——同时它也在创建等待审查的拉取请求。
这种方法需要你扮演双重角色，运用你可能已经具备或观察到的技能：
首先，你需要具备产品经理的能力——将复杂的功能分解成边界清晰、可操作的规格说明。你必须擅长范围界定、优先级排序和精准地沟通需求。如果你写过用户故事（user story）或创建过产品规格书（product spec），你就已经具备了基础。
其次，你需要具备技术主管（tech lead）的技能——高效审查代码、快速发现架构问题、提供清晰的技术方向。在代码库之间进行上下文切换，同时保持一致的愿景，这种能力至关重要。
虽然这种并行运行多个智能体的方法在条件合适时是最快的模式，但它对项目管理技能和专注力的要求也是最高的。上下文切换成了主要挑战，你需要一个强大的结构来防止分心。
这种并行推进方式之所以如此令人兴奋（又充满挑战），是因为我们的工具和大脑还没有为这种工作流做好万全优化。我们还处在探索如何高效管理多个AI开发流的早期阶段。认知负荷很大，但生产力上限却远高于其他任何方法。
传统的软件开发始终受限于顺序执行的流程。即便是人类团队，依赖关系也会制造瓶颈。借助AI智能体，我们可以打破这种模式——并行运行多个开发流，而无需人类团队间那种协调开销。一旦掌握，这种工作流能让单个开发者的生产力提高5到10倍。
这种方法在以下情况效果最佳：
我清楚多个独立任务的“完成”标准。
各个部分有清晰的边界且不会相互干扰。
我需要协调多个工作流。
它是最快的模式——但前提是工作范围界定清晰。
为人类创造力腾出空间
运用大语言模型（LLMs）的目标不是自动化思考，而是为更深层的思考腾出空间。当我的工作流与问题的形态相匹配时，我的进展会更快——以小时而非天为单位加速——更易摆脱困境，并能交付更好的成果。如今唯一的真正阻碍是疲倦、分心或缺乏灵感——这些都是我们可以解决的人为因素。
这些工作流让我能利用多年的工程经验，同时卸下开发的机械性负担。我贡献的是知道需要研究什么的智慧，而AI贡献的是能同时探索多种选择并高效实施解决方案的能力。
我们才刚刚开始。这三种工作流代表了我目前的最佳实践，但我预计下周可能就能发现新模式。这个领域在飞速发展，最好的方法是持续尝试、调整并优化我们与这些强大工具的合作方式。
译者：boxi。
