--- title: 250615-Coding Agents 入门指南 description: 来自 Devin 团队的实战经验总结，涵盖提示技巧、工作流程集成、大任务委托、自动化和性能优化的完整指南 author: Cognition Team source: https://devin.ai/agents101#introduction date: '2025-06-15' category: 01-core-concepts tags: - Coding Agents - Devin - 提示工程 - 工作流程自动化 - AI 辅助开发 --- # Coding Agents 入门：真正完成工作的艺术 **作者：Cognition Team** **原文：[查看原文](https://devin.ai/agents101)**
现在是 2025 年。**`Coding Agents` 不是魔法，但已经足够改变很多团队的工作方式**。我们注意到，有些工程师，尤其是资深工程师，往往更快摸索出高效用法。下面这些经验，来自客户实践，也来自我们自己的使用总结。 ## 关于本指南 ### 产品无关 这里讨论的方法，适用于大多数 `Coding Agents`。 ### 战术性 我们会尽量给出可以直接上手的建议。 ### 技术性 虽然 `Coding Agents` 对很多角色都有价值，但这份指南主要写给工程师。 开发者工具一直在快速演进。十年前，主流还是自动补全和智能感知，能补方法名、做一些程序化重构。四年前，Copilot 和 Tab 补全开始流行，模型已经能接着你往下写几行代码。两年前，生成式聊天机器人进入开发流程，开始帮你产出整份文件。到了今天，自主代理已经可以在较少人工干预的情况下，把一句需求推进到一个可提交的 PR。 过去两年，我们一直在通过构建 Devin 推动这个方向。现在，大家对自主代理的兴趣已经来到一个新高点，尤其是在更多同类产品陆续出现之后。除了 Devin，近期还出现了 OpenAI 的 Codex、Google 的 Jules。像 Cursor、Claude Code 这样的本地代理，也能通过并行工作区实现类似效果。这类代理的形态很多样：可以是 Web 应用、移动应用，也可以集成进 Slack、GitHub、Linear、Jira 这样的常用工具里。 人类和 AI 搭档协作，本来就比单独使用 AI 强得多；而自主代理能端到端处理任务这件事，又把并行推进工作的上限往上抬了一大截。很多时候，你更像是在编排多个任务，而不只是亲手写每一行代码。 学会和这类新工具高效配合，确实需要一点适应期。很有意思的是，我们观察到高级、资深工程师通常最先摸清它们的用法，而且上手速度也最快。长期看，这些工具会在各个层级的工程实践里普及开来。基于我们自己的经验和客户反馈，我们整理了这些关键心得，希望能帮你更顺利地把它们纳入日常工作流。 --- ## 提示基础 这些基本指南将帮助你在 2025 年更有效地与 `Coding Agents` 协作。如果你只能记住一件事，那至少应该记住这些。 ### 说清楚*如何*做，而不仅仅是做什么 可以把代理理解成一位需要明确上下文的编码搭档。简单任务，直接描述目标通常就够了；但任务一旦复杂，从一开始就把你偏好的做法讲清楚，会明显提高成功率。把整体架构和关键思路先交代出来，不只是为了提高一次做对的概率，也能减少后续审查代码的成本。 **例子**： 不要说"添加单元测试"，而是指定要测试的功能，识别重要的边缘情况，并澄清需要模拟什么（如果有的话）。 ### 告诉代理从哪里开始 想想如果你自己处理任务会从哪里开始。即使你不知道具体的文件或函数名，也要提及仓库、相关文档和涉及的关键组件。清楚地指明这些元素可以最大限度地减少浪费的努力和混淆。 **例子**： "请为我们的代码添加对 Google 模型的支持。你应该查看最新文档，并在模型组目录中创建新的实现文件" ### 练习防御性提示 可以把提示先在脑子里过一遍：如果把同样的话交给一个刚加入项目的人，哪里最容易误解？把这些可能的歧义提前补齐，往往能省下后面很多来回沟通。 **例子**： "请修复我们搜索模块的 C++ 绑定以通过新的单元测试。小心，你可能需要在每次更改代码后重新编译绑定才能测试。" ### 给予访问 CI、测试、类型检查器和代码检查器的权限 代理的魔力很大程度上来自于它们修复自己错误并根据错误消息迭代的能力。通过类型检查器、代码检查器和单元测试等工具提供强大的反馈循环大大增强了它们的性能。考虑使用类型化的 Python 而不是普通 Python，或者使用 TypeScript 而不是 JavaScript。教你的代理如何运行常见的检查和测试，确保它拥有所有必要的包和访问权限。如果代理可以与浏览器交互，提供关于运行前端开发环境的清晰指令。 **例子**： 我们的团队从大部分非类型化 Python SDK 迁移到类型化 SDK（这类迁移本身也很适合交给 `Coding Agents` 处理）。 ### 利用你的专业知识 当你熟悉你的代码库时，以上所有一切都变得更容易。即使是简单的任务也受益于你验证逻辑和结果的能力。人类监督仍然必不可少——最终，你要对代码的最终正确性负责。所有权和验证将继续是人类工程师的关键职责，即使这些工具变得越来越复杂。 --- ## 在工作流程中使用代理 一旦你掌握了与代理交谈的基础，是时候将这些 AI 助手带入你的日常工作流程中了。以下是一些让代理成为你例行工作的实用方法： ### 立即接受新任务 想象一下队友给你发消息，"嘿，我们能快速构建 X 吗？"或者"我们需要调整 Y"。不要让它打断你的流程，只需向自主代理发送一个快速提示来调查或进行更改。这让你能够专注于主要任务。有有趣的副项目想法？需要快速制作原型、抓取数据或重现研究？委托给你的代理，稍后再回来处理。 **例子**： 许多团队在讨论错误修复或次要功能更新时只需在 Slack 上标记 @Devin。 ### 随时编码 想象一下你在通勤或旅行时突然出现紧急错误，或者你意识到代码中可能留下了错误。不用担心！自主代理通常支持移动访问，让你能够立即解决这些问题。无论是通过 Slack 的移动应用还是专门的移动应用，许多代理都让你随时随地解决问题，即使你的 wifi 不稳定。 **例子**： 拥有这种选择权使我们的团队在乘车和飞行时变得更有生产力。 ### 交出你的杂务 陷入为旧提交进行二分查找或为新功能更新文档的困境？将这些重复性任务交给你的代理。你将节省宝贵的时间，并专注于更有创造性和影响力的工作。 **例子**： 在我们的团队中，工程师经常在发布更改后让代理更新所有相关文档和面向用户的文本。 ### 跳过分析瘫痪 困在决定重构是否真的会简化你的代码？无法在两种架构方法之间选择？让你的代理实现两个选项。通过具体的例子进行比较，决策变得简单明了，而且丢弃一个解决方案不会伤害任何感情。 **例子**： 当在文本框的 Lexical 和 Slate 之间选择时，我们让代理实现每一个。Slate 因为提供更好的最终结果而胜出。 ### 设置预览部署 设置 CI/CD 管道，为每个新 PR 自动创建预览部署，给你一个即时在线 URL。这在审查 `Coding Agents` 完成的前端任务时特别方便。 **例子**： Vercel 是一个让预览部署变得超级简单的部署平台。 --- ## 委托更大的工单 当一个 PR 的规模和复杂度开始超过几个文件时，一口气自己扛完会越来越吃力。真正能拉开收益差距的，反而是把中大型任务（通常需要 1 到 6 小时）交给自主代理来推进。这里节省的不是几分钟，而往往是几个小时。小任务当然也适合交给代理，但越能驾驭大任务，回报越高。 ### 自动化你的初稿 对于重要任务，让自主代理先起一个 PR 初稿，通常能把事情迅速推起来，也能显著降低你的体力活。成败关键仍然在于：你得一开始就把期望的方法讲清楚。你可以把自己看作是在带一个执行力很强的搭档——方向交代得越清楚，后面返工就越少。 | 领域 | 起草 | 完善 | | :----- | :--------------------------------------------- | :------------------------------------------------------ | | 新闻业 | 记者收集初始信息，撰写文章初稿 | 编辑审阅草稿，事实检查，润色并最终确定出版 | | 餐厅 | 配菜厨师准备食材并制作初步菜肴 | 副厨师添加调味料并调整菜品以更好地调味，然后送给用餐者 | | 编码 | 自主代理基于初始计划开始任务并创建初稿解决方案 | 人类开发者审查草案 PR，提供反馈，并在合并前添加手动完善 | 记住：大任务现在还远远谈不上“全自动免提”。更有挑战的任务通常会经历多个反馈回合，也往往需要你亲自做最后一层打磨。一个更现实的目标，是把 80% 的时间省下来，而不是追求 100% 自动化；验证结果、把住最终质量，仍然要靠你的专业判断。 ### 共同开发 PRD 对于复杂、边界还不够清晰的任务，先和代理一起把计划磨出来，往往比直接开写更有效。如果你一开始并不清楚所有细节，这完全正常。你可以先让代理去做探索：比如“我们的认证链路是怎么工作的？”“这次改动可能影响哪些服务？”也可以让它先圈出相关代码位置，方便你尽早确认方向。 有些代理（比如 Devin、Claude Code）提供专门的规划模式，重点是先读代码、理清上下文，而不是立刻动手修改。如果你想在正式委托前做更充分的准备，像 `deepwiki.com`、Devin Search 这样的代码库搜索工具，也能更快帮你建立整体认识。 ### 设置检查点 对于多部分任务，特别是涉及多个代码库的任务，沿途建立清晰的检查点： 计划 → 实现块 → 测试 → 修复 → 检查点审查 → 下一个块 明确要求在每个重要阶段后暂停，特别是对于在多个层（例如，数据库、后端、前端）构建的复杂功能。使用这些检查点确保实现符合你的期望，澄清疑问（例如"解释身份验证过程并确认其安全性"），并及早纠正路线以避免级联问题。 **例子**： "我希望你实现这个将跨越我们数据库、后端和多个前端界面的功能。请首先规划所需的数据库模式更改，并在完成时让我知道，这样我就可以应用迁移。" → "现在请实现后端更改并添加测试以确保 XYZ 工作。让我知道完成时" → "现在在我们的 web 和移动界面中实现更改以调用新的后端端点" ### 教它验证自己的工作 在给出反馈时，不要仅仅指出问题（"这个函数不工作"）。清楚地表达你的测试过程，使代理能够独立验证未来的任务。对于你将经常重复的测试模式，将这些集成到代理的永久知识库中。 **例子**： 在 Devin 中，我们主动提示用户将基本测试程序保存到代理的持续记忆中，简化未来的互动。 ### 在 AI 热点增加测试覆盖率 目前，代理还没有能力完全彻底地交互测试所有场景。在 AI 大量修改的区域增强测试覆盖率确保了对代理输出的更大信心。可靠的测试意味着看起来正确的代码可以放心地合并而不用担心。 **例子**： 我们的团队在信任 AI 将实现从 Python 转换为 C 之前，加强了代码库关键部分的单元测试。 --- ## 自动化工作流程 代理可以比人类快得多地响应传入事件，而且它们比人类对应物更愿意做无聊、重复的工作。 ### 为你最重复的工作创建快捷方式 工程团队经常遇到重复、例行的任务。这些是代理自动化的完美候选者。常见例子包括： - 功能标志移除 - 依赖升级 - 在新功能 PR 上修复和添加测试 为了有效地设置这个，有经验的工程师通常创建一个强大、可重用的提示模板。在 Devin 中，这些称为 playbooks，可以为这些场景重复运行。 **例子**： 我们的一个客户在开发新功能时自动触发三个专门编写单元测试的代理。 ### 智能代码审查和强制执行 虽然存在用于快速代码审查的专业工具（如 Greptile 和 CodeRabbit），自主代理可以是提供更准确洞察的有趣选择，特别是如果它们已经索引了你仓库的功能。 **例子**： 在 Cognition，我们喜欢维护一个工程师最常见的错误列表，并将此列表提交到代码库。然后，不是编写传统的 lint 规则来捕获这些（通常不可能），我们让代理在每个新 PR 上运行以检查这些错误。 ### 钩入事件和警报 你也可以设置自主代理在响应特定事件时自动触发。例如，Devin 提供了一个可访问的 API，其他代理可以通过 CLI 命令集成到自定义工作流程中。这些设置与 MCPs 一起工作特别好，可以摄取第三方错误日志。 ⚠️ 当涉及到对生产服务问题进行分类时，AI 的调试技能不是那么好。与其要求 AI 在错误出现时端到端地修复错误，通常更实际的是要求 AI 只是标记最可疑的错误、更改等。 --- ## 定制和提高性能 ### 环境设置 没有什么比不完整或不匹配的环境更能减慢代理速度。为了保持事情顺利进行，将代理的设置与你的团队完全对齐。这包括语言版本、包依赖和自动检查。例如，pre-commit 应该安装在代理的环境中，环境配置（秘密、语言版本、虚拟环境、浏览器登录）应该使用 .envrc 或 .bashrc 的自定义配置自动获取。 **例子**： 我们用预认证登录设置了代理的浏览器，消除了手动认证的麻烦，使测试更容易。 ### 构建自定义 CLI 工具和 MCPs MCPs 广泛可用，并且设置快速，实验连接你的代理到外部工具。但很多人忽视了为代理设置简单的 CLI 脚本。作为一个简单的例子，你可以给你的代理一个脚本，根据工单 ID 提取关于 linear 工单的信息。你可能还想给你的代理一个工具来可靠地执行工作流程的常见部分，比如重启本地开发环境的脚本。 **例子**： 我们有一个客户在创建一个 CLI 工具方面取得了很大成功，该工具只在测试套件中显示第一个失败的测试。CLI 提示代理只专注于那个测试并带有详细错误信息，这个 CLI 导致代理在长任务上有更高的成功率和更快的完成时间。 ### 添加到代理的知识库 如果你的代理犯了一些常见错误，这是将你的反馈编入代理知识库的好时机。在 Devin 中，有一个专门的知识管理系统。许多产品提供 .rules 文件、代理永久摄入的 .md 文件。不要只给它关于你使用的框架的指导，还要告诉它你项目的整体架构。告诉它不同类型的任务常见的测试类型，如何运行重要命令以及你推荐使用哪些工具。 **例子**： 我们给我们的代理关于添加新服务路线时应遵循的特定程序的知识。信息包括它需要在前端和后端添加样板代码的所有地方。因此，这些任务现在很容易委托给我们的 AI。 --- ## 实际考虑因素 ### 自主代理的局限性 #### 有限的调试技能 错误报告看起来往往很直接，但真正定位问题通常还需要数据库、日志和更完整的系统上下文。如果你打算借助 AI 参与调试，更稳妥的方式通常是先让它列出可能的根因，而不是一上来就要求它端到端完成排查与修复。根因一旦明确，代理在落实修复上依然很有帮助。 #### 细粒度视觉推理差 通常今天的模型在匹配设计截图或 Figma 模型所需细节级别的视觉推理能力方面不是很好。它们在可以用代码级别描述的视觉效果上最可靠（例如给它来自 Figma 的代码）。如果你想让它匹配你的视觉风格，你应该使用带有可重用组件的良好设计系统。 #### 知识截止 每当你想要使用新库时，你应该明确指出最新的文档。否则，由于预训练基础模型中的知识截止，大多数代理会假设这些库的旧模式。如果你指向文档，一个好的代理可以克服这一点，但你必须意识到这一点（记住，代理甚至不知道这些库有新版本）。 --- ## 管理时间和最小化损失 不是每次使用代理都会导致成功。在 2025 年，这些代理的结果存在一些真正的变化。工作的一部分涉及学习如何使用代理，以最大化遇到成功结果的机会，同时最小化浪费的时间和令牌。 ### 愿意更早止损 刚开始使用代理的人的一个常见错误是他们致力于让交互成功，即使代理的工作偏离轨道。如果你发现自己认为"它忽略了我的指令"或"这东西在兜圈子"，你应该可以停止那个对话或手动接管。发送更多消息更可能是你的任务固有的复杂性高于代理能力的标志，而不是一些可以纠正的简单错误。 ### 多样化你的实验 如果你是代理工作的新手，我们建议在开始时多样化你的赌注。尝试一系列不同的提示和想法。加倍投入你看到代理自然表现良好的任务类型——并在它们不行的任务上止损。不要觉得需要强迫你的代理每次都找到成功。 ### 当你没有进展时重新开始 在使用代理时，必要时重开一个新会话，往往比在原对话里反复补救更高效。如果一个任务已经在错误路径上越走越远，带着完整约束重新开始，通常更容易回到正确轨道。相比在混乱上下文里持续修补，大多数代理在清晰起点下的表现会更稳定。 --- ## 安全和权限 ### 为你的代理创建账户 一次性电子邮件有助于安全测试网站。如果代理需要访问云资源，创建自定义 IAM 角色。 ### 给它一个开发/暂存环境 理想情况下，代理使用与你团队工程师相同的测试设置。我们建议完全避免给予对生产服务的访问。当使用远程代理时，你可以在代理的远程机器上运行完全隔离的测试环境。 ### 只读 API 密钥 尽可能给它只读访问。我们发现让人类手动运行任何与外部服务交互的脚本仍然是有帮助的。 --- ## 巨大变化即将到来 我们坚信软件工程师不会消失。即使 `Coding Agents` 变得更智能、更有能力，深厚的技术专业知识以及对代码库的深入理解仍然无可替代。对项目、系统和代码的真实所有权，如今比任何时候都更关键。 在我们团队今天，工程师被期望监督多个系统，同时保持深入理解和深思熟虑的判断。随着自动化放大你的影响，同时处理并行任务的能力不仅将变得可能；它将变得必要。我们很高兴分享我们在为自己的组织准备这一转变时收集的见解，这样你和你的团队也可以在不断发展的软件开发世界中茁壮成长。 --- **原文链接**： [Coding Agents 101](https://devin.ai/agents101#introduction) **来源**： Devin (Cognition AI) **发布日期**： 2025 年 6 月