2025 年。编程智能体不是魔法,但它已经是我们手上最接近魔法的东西了。这里汇集了来自客户和我们自己实践的顶级经验。
时值 2025 年。编程智能体不是魔法,但它们差不多是我们手头最接近魔法的东西。 我们注意到:有些工程师——尤其是资深到 Staff 级别的——比其他人更快地用出了成效。这里分享一些来自客户与我们自身经验的顶级心得。
讨论的技巧能帮你在任何编程智能体上取得成功。
给出我们最喜欢的、可直接行动的建议。
编程智能体对很多人有价值,但本指南是面向工程师写的。
开发者工具一直在飞速进化。把这条时间线拉开看:
十年前,是自动补全和 IntelliSense,能建议方法名、执行程序化重构。四年前,是 copilot 和 tab 补全,能替你写出接下来的几行代码。两年前,是生成式聊天机器人,能协助开发、替你生成整个文件。今天,是自主智能体(autonomous agents),能把最初的描述,在几乎无需人工干预的情况下,变成最终的 Pull Request。
过去两年里,我们一直专注于通过构建 Devin 来实现这一愿景。如今,人们对自主智能体的兴趣正达到新高,尤其是随着一批类似产品的近期发布。
虽然「人 + AI 助手」的组合能比任何单独的 AI 做得更多,但自主智能体端到端处理任务的能力,带来了一种新层级的多任务并行——把每一位工程师都变成了一名工程经理(turning every engineer into an engineering manager)。
适应与这些新的「AI 同事」高效协作,需要一些时间。有意思的是,我们观察到:资深到 Staff 级别的工程师,往往最快上手并精通这些工具。最终,这些工具会在所有工程层级里变得普遍。基于我们的经验和客户反馈,我们想分享一些关键洞见和教训,帮助每个人把这些工具成功融入自己的工作流。
下面这些基本准则,能帮你在 2025 年有效地和编程智能体打交道。如果别的都不记,至少记住这几条。
把智能体想象成一个初级编程搭档,它的判断力不太可靠。简单任务可以直接描述;但对更复杂的任务,要从一开始就清楚地勾勒出你偏好的实现路径。把整体架构和逻辑预先交给智能体,不仅提高它成功的概率,也减少你 review 代码的时间——因为你已经熟悉了预期的方法。
想想如果是你自己来做,会从哪儿入手。即便你不知道具体的文件名或函数名,也要提及相关的仓库、相关文档、和涉及的关键组件。明确指出这些要素,能把无谓的试错和困惑降到最低。
想象把同一条提示交给一个新来的实习生。哪里最可能产生困惑或出错?预判这些点,主动澄清你的指令,避免歧义。
智能体的很多「魔力」来自它修正自己错误、对着报错信息迭代的能力。通过类型检查器、linter、单元测试等工具提供强反馈回路,会极大提升它的表现。
考虑用带类型的 Python 而不是纯 Python,用 TypeScript 而不是 JavaScript——类型信息让智能体能在运行前就发现错误。教会你的智能体如何运行常见的检查和测试,确保它有所有必需的包和访问权限。如果智能体能操作浏览器,就给它清晰的说明,告诉它怎么运行你的前端开发环境。
当你熟悉自己的代码库时,上面所有事都会变得更容易。即便是简单任务,也能从你「验证逻辑与结果」的能力中获益。
归根结底,代码最终是否正确,责任在你。即便这些工具越来越精密,「所有权」与「验证」仍将是人类工程师至关重要的职责。
一旦掌握了和智能体对话的基础,就该把这些 AI 帮手带进日常工作流了。下面是把智能体变成日常一部分的几种实用方式:
想象一个队友发消息给你:「嘿,我们能不能快速搭一个 X?」或「我们得调一下 Y。」与其让它打断你的心流,不如直接发一条简短提示给自主智能体,让它去调查或做改动。这让你能继续专注主线任务。有个有意思的副项目点子?需要快速做个原型、爬点数据、或复现一篇研究?委派给智能体,稍后再回来看。
设想你在通勤或旅途中,突然冒出一个紧急 bug,或你意识到代码里可能留了个错误。别担心!自主智能体常常支持移动端访问,让你能即时处理这些问题。无论是通过 Slack 的移动 app,还是专门的移动 app,许多智能体都让你在路上就能解决问题——哪怕你的 wifi 不太稳。
卡在二分查找老 commit、或给新功能更新文档上?把这些重复性任务交给智能体。你能省下宝贵时间,专注于更有创造性、更有影响力的工作。
纠结一次重构到底会不会真的简化代码?在两种架构方案之间选不出来?让智能体把两个方案都实现出来。 有了具体的例子可以对比,决策就变得直截了当——而且丢弃一个方案也不会伤到任何人的感情。
把你的 CI/CD 流水线设置成:每个新 PR 自动创建一个预览部署,给你一个即时的线上 URL。在 review AI 智能体完成的前端任务时,这尤其顺手。
当你的 PR 规模和复杂度超出寥寥几个文件时,想一次性搞定就变得困难。然而,掌握如何委派中到大型任务(通常是 1–6 小时的工作量),正是自主智能体回报最高(ROI 最高)的地方。 你省下的不再只是几分钟,而是几小时的生产力。小任务也许毫不费力就能完成,但把智能体的能力拉伸到处理更大任务,才带来最大的回报。
对于体量较大的任务,用自主智能体先打一个 PR 初稿,能启动进展、大幅削减你的工作量。这里成功的关键,在于预先清楚地传达你想要的方法。把自己想象成指导初级开发者的架构师。清晰、详尽的指令能避免在「纠正智能体代码里的根本性误解」上浪费时间。
| 领域 | 起草(Drafting) | 精修(Refining) |
|---|---|---|
| 新闻业 | 记者收集初始信息,写出文章初稿。 | 编辑审阅初稿、核查事实、润色,最终定稿发表。 |
| 餐厅 | 线厨备料、做出初步的菜品。 | 副主厨加调味、调整口味,然后才端给食客。 |
| 写代码 | 自主智能体基于初步计划开工,创建初稿解决方案。 | 人类开发者审阅初稿 PR、给反馈、合并前加上人工精修。 |
记住,大任务现在还做不到完全免手动。对更有挑战的任务,要预期多个反馈循环,也要预料到为了打磨需要一些人工精修。一个现实的目标是约 80% 的时间节省,而非完全自动化——你的专业能力在验证和最终质量保证上依然至关重要。
对于复杂或定义模糊的任务,和你的自主智能体协作、共同创建一份详细计划,会非常有效。一开始你不知道每一个细节或需求,这完全没关系。先让智能体去探索一些发现性问题,比如「我们的认证系统是怎么运作的?」或「哪些服务可能受影响?」你也可以让智能体替你找出具体相关的代码目标,让你早早确认。
某些智能体,如 Devin 和 Claude Code,提供专门的规划模式(planning modes),专注于阅读和探索现有代码,而不是立刻去改它。如果你想在委派任务前做更深的准备,专门的代码库搜索工具(如 deepwiki.com 和 Devin Search)能快速给出对你代码库的洞察,帮你理顺流程。
对于多部分的任务,尤其是涉及多个代码库的,沿途设立清晰的检查点:
明确要求在每个重要阶段之后暂停,尤其是跨多层构建的复杂功能(比如数据库、后端、前端)。用这些检查点来确保实现符合你的预期、澄清疑问(例如「解释一下认证流程,并确认它的安全性」)、及早纠偏,避免问题层层叠加。
// 一个分阶段委派的真实提示链:
"我想让你实现这个横跨数据库、后端和多个前端界面的功能。
请先规划需要的数据库 schema 变更,完成后告诉我,以便我应用迁移。"
→ "现在请实现后端改动,并加上测试确保 XYZ 能工作。完成后告诉我。"
→ "现在在我们的 web 和 mobile 界面里都实现改动,去调用新的后端端点。"
给反馈时,别只是指出问题(「这个函数不工作」)。要清楚地说明你的测试流程,让智能体未来能独立验证任务。对于你会频繁重复的测试模式,把它们整合进智能体的永久知识库(见「往智能体知识库里加东西」)。
目前,智能体还没能力交互式地彻底测试所有场景。在被 AI 大量修改的区域增强测试覆盖率,能让你对智能体的产出更有信心。扎实的测试意味着:看起来正确的代码,可以放心合并、无需担忧。
智能体能比人更快地响应到来的事件,而且比人类同行更愿意做无聊、重复的活。
工程团队经常遇到重复、例行的任务。这些都是用智能体自动化的完美候选。常见例子包括:
要高效搭建这套机制,通常由一名有经验的工程师创建一个稳健、可复用的提示模板,针对这些场景反复运行。
虽然有专门做快速代码审查的工具,但自主智能体可以是一个有意思的选项,能给出更准确的洞察——尤其当它们已经索引了你仓库的功能时。
你也可以设置自主智能体,让它们针对特定事件自动触发。例如,Devin 提供了一个可访问的 API,其他智能体也能通过 CLI 命令集成进自定义工作流。这类设置和 MCP 配合得尤其好,可以摄入第三方的错误日志。
说到在生产服务里分诊问题,AI 的调试技能其实不太行。与其让 AI 在问题出现时端到端地去修 bug,更实际的做法往往是:只让 AI 标记出最可疑的错误、变更等,把判断交给人。
没有什么比一个不完整或不匹配的环境更能拖慢智能体了。为了让一切顺畅运行,把智能体的环境配置得和你团队的完全对齐。这包括语言版本、包依赖、和自动化检查。
例如,pre-commit 应该装在智能体的环境里;环境配置(密钥、语言版本、虚拟环境、浏览器登录)应该用 .envrc 或自定义的 .bashrc 配置自动加载。
MCP 已经广泛可用,搭建和试验「把智能体连到外部工具」都很快。但很多人忽略了为智能体搭建简单的 CLI 脚本。
举个简单例子:你可以给智能体一个脚本,根据工单 ID 拉取某个 Linear 工单的信息。你也许还想给智能体一个工具,可靠地执行工作流里的常见环节,比如一个重启本地开发环境的脚本。
如果你的智能体犯了一些常见错误,这正是把你的反馈固化进知识库的好时机。在 Devin 里有专门的知识管理系统;许多产品提供 .rules 文件、.md 文件供智能体永久摄入。
不要只给它你所用框架的指引,还要告诉它你项目的整体架构。告诉它:不同类型的任务通常做哪种测试、如何运行重要的命令、你推荐用哪些工具。
Bug 报告可能具有欺骗性的简单。但许多 bug 往往不仅需要访问数据库和日志,还需要一种超出当今大多数 AI 智能体水平的调试能力。如果用 AI 辅助调试,我们建议让它列出一份可能的根因清单,而不是让它自己去调试并修复一切。然后由人凭自身经验判断哪个才是真正的根因。但一旦根因明确,智能体在实现修复上仍然相当有用。
总体而言,当今模型在「匹配设计稿截图或 Figma mockup」所需的细节层级上,视觉推理能力并不强。它们在能用代码层级描述的视觉上最可靠(例如把 Figma 导出的代码给它)。如果你想让它匹配你的视觉风格,应该使用一个带可复用组件的良好设计系统。
每当你想用一个新库时,都应该明确把它指向最新文档。否则,由于预训练基座模型的知识截止,大多数智能体会沿用这些库的旧模式。一个好的智能体在你指它看文档后能克服这点,但你必须有意识——记住,智能体甚至不知道这些库已经有了新版本。
你用智能体的每一次,并不都会成功。在 2025 年,这些智能体的结果存在真实的方差(variance)。这份工作的一部分,就是学会以一种「最大化撞上成功结果、同时最小化浪费的时间和 token」的方式来使用智能体。
新手常犯的一个错误是:即便智能体的工作已经跑偏,仍执意要把这次交互救成功。如果你发现自己在想「它在无视我的指令」或「这玩意儿在原地打转」,那么你应该能够坦然地中止这次对话、或手动接管。
继续发更多消息,更可能说明:你任务的内在复杂度高于智能体的能力——而不是某个可以纠正的简单错误。
如果你刚开始和智能体打交道,我们建议一开始就分散下注。尝试一系列不同的提示和点子。在那些你看到智能体天然表现好的任务类型上加码——在它们做不好的那些上止损。不必非要逼着智能体每次都成功。
和智能体打交道时,「推倒重来」是正确答案的频率,远高于和人类打交道时。如果你给了智能体一个任务,而它在处理反馈或纠偏上挣扎,那么用一个新智能体、把所有指令预先一次性给全,重新开始,往往能更快抵达成功。
智能体「修复一个被搞乱的环境」的能力,远逊于它「从零吐出全新代码」的能力。所以与其在烂摊子上缝缝补补,不如让它在干净的起点上重新生成。
一个一次性的邮箱有助于安全地测试网站。如果智能体需要访问云资源,为它创建自定义的 IAM 角色。
理想情况下,智能体使用和你团队工程师相同的测试设置。我们建议完全避免给它访问生产服务的权限。使用远程智能体时,你可以在智能体的远程机器上跑完全隔离的测试环境。
在可能的情况下,给它只读访问权。我们发现,任何与外部服务交互的脚本,仍然由人来手动运行会更稳妥。
我们坚信:软件工程师不会消失。 即便编程智能体变得更聪明、更有能力,深厚的技术专长和对自身代码库的亲密了解,仍然无比宝贵。对你的项目、你的系统、你的代码拥有真正的「所有权」,如今比以往任何时候都更关键。
在我们团队今天,工程师被期望监管多个系统,同时仍保持深刻的理解与审慎的判断。随着自动化放大你的影响力,「同时处理多个并行任务」的能力不仅会变得可能——它会变得必不可少。
我们很高兴分享在为自己的组织准备迎接这场转变时所积累的洞见,好让你和你的团队,也能在不断演进的软件开发世界里茁壮成长。