用 AI 代理写程式 (Agentic Coding) 时，有什么重要的关键原则?

先前 E+ 制作了 Cursor 入门到实战与 MCP 应用 线上课程，谈如何透过 Cursor 等 AI 工具来协助提升生产力。在课程上线后，社群持续有许多关于这个领域的新洞见出现，因此在这一期的主题文，我们会进一步来谈在课程中没有涵盖到，或者有延伸观点的内容。

具体来说，我们会着重在 2025 年中开始逐渐成为主流用词的 Agentic Coding (代理驱动的程式撰写)上，来谈在 AI 代理发展愈加成熟时，如何跟 AI 代理互动，能够更有效地让 AI 代理协助完成开发中所遇的不同任务。

人类工程师介入仍很重要

先前在 AI 代理是什么? 一文中，我们有谈到 AI 代理的定义是可以在不用人类介入的状况下，根据指定目标，去完成相关任务 (Agents are autonomous and can act independently of human intervention, especially when provided with proper goals or objectives they are meant to achieve.)。

虽说 AI 代理的定义下，人类理论上不该介入，但是在过去两年的 AI 代理发展中，相比于完全没有人类介入的状况，适时的人类工程师介入 (human-in-the-loop)，往往能够获得更好的成果。

以过去一年相信很多人都听过的 AI 代理工具 Devin 为例，Devin 是在 2024 年初时，软体工程师社群最多讨论的话题之一。当时之所以讨论度高，是因为 Devin 一推出时，就以「全球首个 AI 软体工程师」来宣传，能够在人类指定目标后，就自动运行直到发出一个解决方案的 PR (pull request)。

然而，在 2025 年 Devin 进一步推出 2.0 时，却从原本全自动化，转为人机共同协作。在这个转变发表的同时，Devin 的创办人兼执行长 Scott Wu 在他的贴文提到，要把任务委派给 AI 代理，不会是一次性的过程 (not a single-shot process)。

换句话说，在目前的 AI 代理发展下，还让 AI 代理完成任务，需要在过程中跟 AI 代理互动，然后让代理迭代。相信读到这边，读者可能会问，假如仍需要人类工程师介入，那么具体来说，人类工程师的角色是什么? 要做什么? 以下几点是我们认为人类工程师需要做的。

厘清好问题

首先，在 AI 代理能够帮忙实作的时代背景下，写程式 (或说生成程式码) 的成本比起过去低很多；但是不变的是，「解决对的问题」仍是软体工程最重要的事项之一。程式码本身仅是解决方案，比起解决方案本身，有了这段程式码是为了做到什么事、解决什么问题，会是比程式码本身更重要的。

在《What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not》一文中，其作者谈到，矽谷类公司在看待软体工程师，跟许多传统欧洲、亚洲公司看待的方式有很大的不同。其中一个关键差异在于，矽谷类公司把软体工程师视为解决问题者，而不只是单纯的按照指令写程式的人；这样的差异意味着，矽谷类公司会预期工程师去协助厘清、定义问题，确保解出来的问题是真正重要的。

毕竟，如果没有解决对的问题，就代表花大量的工程资源，却做出没有实质影响力的事。即使 AI 代理让生成程式码解决方案的成本变低，解错问题仍代表白花运算资源让 AI 代理生成无用的程式码。

对此，Cursor 团队的工程师 Adam Hofmann 先前发文说 (连结)「在你足够理解问题以及你想要的解决方案前，不要叫 AI 代理帮你做事 don't ask agent to do something until you understand the problem and solution that you want to see. 」。

当然，厘清问题这件事本身，也可以运用 AI 来协助，例如可以写下你目前对问题的理解，然后问 AI 是否还有遗漏没有想清楚的面向、或者问能否点出潜在的假设漏洞。这边特别推荐，在问题厘清阶段可以使用推理模型 (对推理模型不熟的读者，推荐复习 提示词基础：传统模型 vs. 推理模型，什么时候选哪一个? )。

建置好让 AI 能够成功完成任务的基础

在厘清完目标后，还有一件事是需要让 AI 开始执行任务前，工程师需要先做的事 — 建置好让 AI 能完成任务的基础。

试想，假如今天一个刚加入团队的新成员，即使这位新成员很聪明，但假如该成员不知道团队的程式码库风格、不能使用团队平常有在用的工具，这位成员可能如预期发挥自己百分百的水准吗? 相信会很困难。

对 AI 代理来说也是一样的，因此，务必要在让 AI 代理开始执行任务前，先准备好以下的文件与工具

• 团队程式码库风格指南 (style guide)
• 过去不同功能的设计文件 (design doc)
• 静态检查工具 (例如 linter)
• 在执行任务时会用到的外部工具 (MCP)

假如有提供程式码风格指南，AI 才不会生成出风格不一致的程式码；如果有提供设计文件，AI 在生成程式码时，才能够先理解原本的设计脉络，进而让程式码更符合设计初衷。另外，如果有提供静态检查工具，这样如果 AI 生成出的程式码不符合团队的规范，也能够获得立即的回馈，让 AI 代理能够进一步调整。

上面这些建置，都意味着能够让 AI 更精准地完成我们期望 AI 完成的任务，这样将能够有效减少后续人类的介入与改动。

与此同时，如果有提供外部工具，也将能够进一步拓展 AI 的用途。例如提供 Jira 或 Linear 的 MCP，Cursor 就能自动从 Jira 中抓取相关规格或需求描述，工程师甚至不需要手动输入需求，只需告诉 Cursor「根据 Jira 的某张 ticket 来实作功能」，即可完成任务。

又或者，当我们提供功能描述和规格后，Cursor 可以根据这些内容自动撰写端到端的测试案例。如果我们进一步将 Cursor 与 Playwright 这样的端到端测试工具对接，Cursor 不仅能撰写测试案例，还能透过 Playwright 直接开启浏览器，根据自己生成的测试案例逐步执行测试并完成程式码，来确保 E2E 的测试案例有写对。

任务拆小 + 适时给予回馈

如开头提到，对比起从头到尾的全自动化，目前业界摸索出比较有效的方式，是人与 AI 的共同协作。而要有效做好这件事，先把任务拆小，让 AI 能够去执行不同的子任务，并在子任务的进行途中持续给予回馈，这样获得的效果会比较好。

Atlassian 先前发表的一篇研究《Human-In-the-Loop Software Development Agents》(连结) 就把完整的开发流程拆成以下四个阶段，然后每个阶段都由人类工程师的指示搭配 AI 代理去完成，在他们的研究发现，比起一次要求 AI 完成完整的任务，这种拆小的方式，得出来的品质比较好。

Cursor 团队的工程师 Adam Hofmann 先前也提过一个 Goldilocks 原则，所谓的 Goldilocks 原则是指「刚刚好」，也就是不要太多，也不要太少。他推荐可以透过反覆调整，来测试当前 AI 代理能完成的任务复杂度。如果发现无法一次成功做好，那就试着把任务拆小；反之，如果发现目前能够一次成功完成，那就试着把任务范围加大。这样反覆测试，直到找到那个「刚刚好」的边界。

阅读更多

如果以上的内容对你有帮助，ExplainThis 制作的《Cursor 入门到实战》线上课程有更多更深入的讨论，让读者们能够用最高效的方式使用 AI 程式工具。

感兴趣的读者，欢迎加入 E+ 成长计划观看 (连结)。