我使用编码智能体来构建智能体，从而自动化了我工作中的一部分内容。以下是我在更高效地与编码智能体协作方面的一些经验总结。
作者：Tyler McGoffin
排版：Alan Wang
我可能刚刚把自己"自动化"进了一份完全不同的工作......
这在软件工程师中其实很常见：出于灵感、挫败感，甚至有时只是因为"偷懒"，我们会构建各种系统来消除重复劳动，把精力投入到更具创造性的工作中。而最终，我们往往又会成为这些系统的负责人和维护者，让身边的其他人也能享受到自动化带来的收益。
作为一名 AI 研究员，我最近把这件事推进到了一个此前难以实现的程度------我将自己的"脑力劳动"也自动化掉了。现在，我反而在维护这样一个工具，让 Copilot 应用科学团队的同事们也能够做到这一点。
在这个过程中，我学到了很多关于如何高效地使用 GitHub Copilot 进行创建与协作的经验。将这些经验应用之后，我不仅为自己构建了一个极其高效的开发闭环，也让团队成员能够快速打造符合各自需求的解决方案。
在详细介绍我是如何实现这一切之前，先让我为这个项目的诞生背景做一个铺垫，这样你可以更好地理解使用 GitHub Copilot 所能达到的能力边界。
动机
我工作的很大一部分，是基于标准化评测基准（例如 TerminalBench2 或 SWEBench-Pro）来分析编码智能体的性能。这通常需要仔细查看大量被称为"轨迹"的数据------本质上就是智能体在执行任务过程中，其思考过程和行动步骤的列表。
评测数据集中的每一个任务，都会生成一条对应的轨迹，用来展示智能体是如何尝试解决该任务的。这些轨迹通常是包含数百行代码的 .json 文件。当你把这些数据扩展到一个基准测试中的几十个任务，再叠加每天需要分析的多次评测运行时，就意味着需要处理数十万行代码。
这显然不是一个人能够独立完成的任务，因此我通常会借助 AI 来协助分析。在处理新的基准测试结果时，我发现自己不断重复同一个流程：先使用 GitHub Copilot 从这些轨迹中提取模式，然后再由我自己进行深入分析------这样就能把需要阅读的代码量从数十万行缩减到几百行。
但作为一名工程师，我看到这种重复性的工作时的第一反应是："我想把它自动化。"而智能体正好为自动化这种"脑力劳动"提供了手段，于是eval-agents 项目也就应运而生了。
计划
工程团队与科研团队协同工作时，往往能发挥更大的价值。这也是我在着手解决这个新挑战时所秉持的核心原则。
因此，在这个项目的设计与实现策略上，我设定了几个目标：
-
让这些智能体易于分享和使用
-
让创建新的智能体变得简单
-
让"编码智能体"成为主要的贡献方式
前两个目标可以说是 GitHub 的核心基因，也是我在职业生涯中积累的重要理念与能力，尤其是在担任 GitHub CLI 开源维护者期间。
不过，真正对项目影响最大的是第三个目标。我发现，当我借助 GitHub Copilot 来高效构建这个工具时，也无形中让这个项目本身变得更易于使用和协作。这段经历让我总结出了一些关键经验，而这些经验也以出乎意料的方式，进一步推动了前两个目标的实现。
让编码智能体成为你的主要贡献者
我先介绍一下我的智能体编程环境配置：
-
编码智能体：Copilot CLI
-
使用模型：Claude Opus 4.6
-
IDE：VSCode
另外值得一提的是，我还借助了 Copilot SDK 来加速智能体的创建------而它底层正是由 Copilot CLI 驱动的。这让我可以直接使用现成的工具和 MCP 服务器，同时也能方便地注册新的工具与技能，以及获得一整套开箱即用的智能体能力，而无需从零开始重复造轮子。
在此基础上，我通过遵循几个核心原则，很快就将整个开发流程大幅简化：
-
提示策略：当你以对话式、信息充分的方式与智能体交互，并在进入执行模式前先使用规划模式时，智能体的表现最佳。
-
架构策略：频繁重构、频繁更新文档、频繁清理代码。
-
迭代策略："信任但验证"已经演变为"把问题归因于流程，而不是智能体"。
当我逐步总结并践行这些策略后，出现了一个令人惊讶的现象：新增智能体和功能变得又快又简单。项目中有 5 位成员第一次参与进来，在不到三天的时间里，我们就创建了：
-
11 个新的智能体
-
4 个新的技能
-
以及一种名为 eval-agent workflows 的新概念（可以理解为"科学家式推理流程"）
这些改动总计涉及 345 个文件，代码变更达到 +28,858 / -2,884 行。
简直不可思议！
接下来，我会详细讲解这三大原则，以及它们是如何促成如此高效的协作与创新的。
提示策略
我们知道，AI 编程智能体在解决边界清晰的问题时表现非常出色，但在面对更复杂、通常只有资深工程师才会处理的问题时，仍然需要一定程度的引导与"手把手"指导。
因此，如果你希望你的智能体表现得像一名工程师，那就要用对待工程师的方式去对待它：引导它思考、充分解释你的假设，并利用它极快的检索与研究能力，在真正开始修改代码之前先完成规划。
我发现，比起给出一个简短的问题描述或直接的解决方案，把我在思考问题时的一些"意识流式"的想法写进提示词，并在规划模式中与 GitHub Copilot 交互，效果要好得多。
下面是我为了给这个工具增加更健壮的回归测试而写的一个提示示例：
/plan I've recently observed Copilot happily updating tests to fit its new paradigms even though those tests shouldn't be updated. How can I create a reserved test space that Copilot can't touch or must reserve to protect against regressions?
这个问题最终引发了一系列来回讨论，并逐步形成了一套类似契约测试的防护机制，这些测试只能由人类进行更新。我一开始有一个大致的想法，而通过与 Copilot 的对话，它帮助我逐步逼近了正确的解决方案。
事实证明，让人类工程师高效工作的那些方法，同样也是让这些智能体高效工作的关键。
架构策略
工程师们，可以欢呼了！还记得那些你一直想做但没时间做的重构吗？那些为了让代码库更易读而想调整的结构？那些一直没补上的测试？以及那些你在入职时希望就已经存在的文档？
在"智能体优先"的仓库中，这些工作现在反而成为最重要的任务。
过去那种"为了新功能不得不降低这些工作优先级"的时代已经结束了，因为当你拥有一个维护良好、以智能体为中心的项目时，通过 GitHub Copilot 交付功能变得极其简单。
在这个项目中，我的大部分时间都花在重构命名与文件结构、为新功能或模式编写文档、以及为过程中发现的问题补充测试用例。我甚至还会花一些精力清理那些智能体（就像你的初级工程师一样）在实现新功能时遗漏的"死代码"。
这些工作让 Copilot 能够像任何一名工程师一样轻松地理解并在代码库中导航。
我甚至可以直接问："如果现在重新设计，你会怎么做？"然后我可以在 Copilot 的帮助下，真正回过头去重新架构整个项目。
这简直是梦想成真！
而这也自然引出了我最后一条建议。
迭代策略
随着智能体和模型能力的提升，我的心态也从"信任但验证"逐渐转变为一种更偏向信任、而非怀疑的方式。这也类似于行业中对人类团队的管理理念："把问题归因于流程，而不是个人"。这是高效团队运作的方式，因为人一定会犯错，所以我们要围绕这种现实去构建系统。
这种无责文化的核心，是为团队提供心理安全感，使其能够持续迭代与创新，而不必担心犯错会带来指责。其基本原则是：我们通过流程与防护机制来避免错误发生；而当错误真的发生时，我们会从中学习，并引入新的流程和防护机制，确保团队不会重复同样的错误。
将同样的理念应用到智能体驱动开发中，是释放高速迭代能力的关键。这意味着我们会为智能体构建流程与"护栏"来防止它出错；而当它确实犯错时，我们不会简单止步，而是进一步增加新的护栏和流程------例如更严格的测试、更精细的提示词，从而让同样的错误不再发生。再进一步，这也意味着必须认真实践 CI/CD 的最佳原则。
严格类型校验等实践能够确保智能体符合接口规范。功能强大的代码检查工具会为智能体设定实现规则，使其始终遵循优良的编程范式与开发准则。此外，集成测试、端到端测试以及契约测试------这类测试若手动构建往往成本高昂------在智能体的辅助下实现起来会更为经济高效，同时也能让你确信新的代码变更不会破坏现有功能。
当 GitHub Copilot 在开发循环中拥有这些工具时，它甚至可以"自我检查工作"。你实际上是在为它创造成功条件，就像你为团队中的初级工程师搭建一个良好的成长环境一样。
整合起来
当你的代码库已经为"智能体驱动开发"做好准备时，这一切意味着你的开发循环会变成如下流程：
-
使用 GitHub Copilot 的
/plan来规划一个新功能-
对这个计划进行迭代优化
-
确保计划中包含测试设计
-
确保计划中包含文档更新，并且在代码实现之前完成这些更新------这些文档也可以作为与计划并行存在的额外约束与指导
-
-
让 Copilot 使用
/autopilot来实现该功能 -
触发 Copilot Code Review 智能体进入评审循环，通常流程是：请求评审 → 等待结果 → 处理相关评论 → 再次请求评审，如此循环，直到没有新的有效反馈
-
人工最终审查：这是我用来强化前文提到那些架构与流程原则的关键环节
此外，在功能开发循环之外，我还会持续且尽早地让 Copilot 执行以下"检查型任务"：
-
/plan检查是否存在缺失测试、被破坏的测试以及死代码 -
/plan检查代码是否存在重复，或是否有抽象机会 -
/plan检查文档与代码，识别文档缺口，并更新copilot-instructions.md以反映相关变化
这些任务我通常会每周自动运行一次，但在新功能或修复不断进入时，我也经常在一周内多次手动触发，以持续维护我的智能体驱动开发环境。
带走这些思考
最初，我只是因为一个重复性极强、几乎无法忍受的分析任务而感到困扰，但最终，这件事演变成了一个更有意思的结果：一种关于我们如何构建软件、如何协作以及如何成长为工程师的新思维方式。
以"编码智能体优先"的思维方式构建智能体，彻底改变了我的工作方式。这不仅仅是自动化带来的效率提升------尽管看到四位"科学家"在不到三天内交付 11 个智能体、4 个技能以及一个全新概念，本身就已经非常惊人------更重要的是，这种开发方式迫使你去优先关注那些真正重要的事情：清晰的架构、完善的文档、充分的测试，以及深思熟虑的设计------这些我们一直知道很重要，但却总是没有时间去做的事情。
"初级工程师"的类比在这里被不断验证。你会为他们提供良好的入职引导，给出清晰的上下文，构建防护机制以避免错误演变成灾难，然后逐步信任他们成长。如果出了问题，就归因于流程，而不是个人或智能体。如果说我希望你从中带走什么，那就是：让你成为优秀工程师和优秀团队成员的那些能力，也正是让你能够用 Copilot 构建出色系统的能力。技术是新的，但原则不是。
所以，去整理你的代码库吧，去写那些你一直拖延的文档吧，并开始把 GitHub Copilot 当作团队中最新的一名成员来对待。你可能真的会把自己"自动化"到职业生涯中最有趣的那一类工作里。
觉得我在胡说？那就试试这个：
-
下载 Copilot CLI
-
在任意仓库中启用 Copilot CLI：
cd <repo_path> && copilot -
输入以下提示词：
/plan Read <link to this blog post> and help me plan how I could best improve this repo for agent-first development