Frontier Engineering：10 条核心原则

原文来源：https://kiro.dev/topics/frontier-engineering/
术语说明：文中保留 agent、prompt、context、steering file、skill、MCP、vibe coding、CI、PR 和 guardrail 等 AI 与工程术语。

概述与宣言

软件开发者正在分成两类：一类人改变了自己与 AI agent 协作的方式，另一类人只是换了编程工具。如今，AI agent 已经能够自主编写代码、运行测试、修复失败并继续迭代，而且越来越能在没有人类介入的情况下连续工作数小时。开发者的工作也随之发生了变化。那些实现生产力跃升的开发者，并不是用了比别人更好的编程工具，而是采用了不同的工作方式：他们不再直接构建软件，而是构建一套能让 agent 完成软件开发的工作体系。

本指南写给一线从业者（管理者另有指南）。如果你已经在使用 AI 编程助手，交付速度却没有明显提升，这篇指南会告诉你需要改变什么。先提醒一句：这是一项工程投资，不是打开一个开关就能完成的事。你需要花几周时间培养直觉、编写 steering file、重构代码库，并学习如何把工作拆解给 agent。如果你不准备改变工作流程，却期待立刻见效，结果会让你失望。最初几周可能反而更慢，之后速度才会显著提升。

10 条原则一览

1. 你是架构师，不是打字员
2. 尽可能延长 agent 的工作时间，减少你的介入
3. 为 agent 建设代码库
4. 为 agent 建立快速反馈循环
5. 执行成本很低，方向决定一切
6. 把代码当作可丢弃的产物
7. 用要求人类的标准要求 AI 产出
8. 信任边界，而不是 agent
9. 让 agent 参与所有工作，而不只是写代码
10. 持续调校你的 agent 工作体系

Frontier Engineering 不是 vibe coding

Frontier Engineering 不是 vibe coding，也不是把 prompt 粘进聊天框后碰运气。它是一套严谨、有章法的工程实践，把传统工程纪律与 AI agent 带来的杠杆效应结合起来。长远来看，你需要持续锻炼的能力，是管理自己的注意力。随着 agent 接手越来越多的执行工作，你要承担同时在多个 agent 之间切换 context 的认知负荷；一切加速时，仍要有意识地守住质量标准；吃饭或到了深夜，还得克制自己，不要反复查看 agent 的进度。你的工作变成了不断判断：什么需要你关注，什么不需要。

Frontier Engineering 仍处于早期采用阶段。现在还没有多少开发者以这种方式工作，这套实践也仍在成熟：怎样审查 agent 的产出最有效，怎样为 agent 而不是人类设计工具和测试基础设施，这些问题都还没有公认答案。因此，这种工作方式仍然依赖直觉：什么该交给 agent，任务范围该怎么划定，又该在什么时候介入。这些直觉来自实践，也来自最初几周编写 steering file、重构代码库和学习拆解任务的过程。一旦掌握了这种工作方式，你的交付速度会显著提高，也能着手完成过去无暇顾及的工作：原本超出范围的功能、迟迟没有进行的架构调整，以及一直没空补上的测试和工具。此后，收益还会继续累积：agent 的能力每提升一步，都建立在你已经积累的经验之上。这种工作方式仍在形成，而现在采用它的开发者也正在参与定义它。从今天开始改变你的工作方式。

01. 你是架构师，不是打字员

这份工作的重点不再是写代码，而是写清楚意图。我们看到，前沿开发者亲手编写的代码不到其产出总量的 1%，其余代码来自他们指挥、引导和审查的 agent。

工作可以归结为两件事：定义什么算“完成”（包括需求、约束和验收标准），以及验证产出是否符合你的意图。

把意图写清楚并不是新要求，但现在已经不能省略。你要说明期望的行为、需要考虑的边界情况，以及如何验证结果是否正确。例如，“给这个 API 加上身份认证”并不是清楚的意图；你需要说明哪些角色能访问哪些 endpoint、token 过期时如何处理，以及怎样测试未授权访问。然后让 agent 编写代码。

过去，你的大部分时间用于写代码；现在，这些时间会用来明确意图、确定方向，并有针对性地审查 agent 的产出。

02. 尽可能延长 agent 的工作时间，减少你的介入

许多开发者始终和编程助手待在同一个循环里：给 agent 一条 prompt，等 60 秒，拿到代码，手动测试，再把错误粘回聊天框，然后重复这一过程。这样不可能获得很高的开发速度。

前沿开发者会把执行时间更长的任务交给 agent，并在任务中写明验证步骤：“实现这个功能，编写测试并运行，确保测试通过，新代码的覆盖率达到 90%。”随后，agent 可以工作 30 分钟甚至更久，而你去处理别的事情。agent 中途会犯错，这很正常。让它继续循环、自我修正，逐步收敛到正确结果。

让多个 agent 并行处理持续到来的任务，并异步审查它们的产出。现在限制生产力的不再是打字速度，而是你能让多少个 agent 同时承担有意义的工作。

随着工具逐渐完善，你对这种方式也更有信心，可以进一步延长 agent 的运行时间：让它连续工作数小时或通宵，也可以让 agent 启动其他 agent，第二天早上再检查结果。目标是逐步把自己移出执行循环，最终只负责确定方向和验证结果。

03. 为 agent 建设代码库

agent 的表现很大程度上取决于它所面对的代码库。先打好那些对人类也有帮助的基础：完整的 README 和架构文档、能够说明预期行为的测试、清晰的模块边界、强类型，以及速度快、错误信息明确的构建流程。面对大型遗留代码库时，应当一次整理一个模块，并把 agent 的工作范围限制在已经准备好的模块内，而不是直接让它处理整个代码库。

如今，这些投入的回报远高于以往，因为新的人类成员只需要完成一次 onboarding，而 agent 每个 session 都要重新 onboarding。人类记在脑中的信息，需要明确提供给 agent：用 steering file 说明约定和编码标准；通过 skill 按需加载特定任务的操作流程；用脚本自动设置环境；通过命令行工具和 MCP server 获取 context、执行操作。

让 agent 把自己的工作记录下来，供后续 session 使用。agent 应当记录设计决策，并在代码中留下足够的注释，作为持久记忆。这样，下一个 agent session 继承的不只是代码，还有代码背后的理由。

04. 为 agent 建立快速反馈循环

如果 agent 不能在本地运行测试，并在你查看代码之前自行修正，那么瓶颈就是你。前沿开发者会投入精力，把验证流程做得快速、本地化且可自动执行，让 agent 能在紧凑的循环中反复测试。

agent 应当能够使用代码检查工具和单元测试，能够通过浏览器渲染界面并直观检查 UI 改动，能够使用依赖服务的本地 mock 进行集成测试，也能够在笔记本电脑上启动完整技术栈，执行端到端测试。如果你会使用某项工具验证自己的工作，agent 也应当能够使用它。这样它就能自行验证，而不需要你在不同工具之间复制粘贴输出。

属性测试在这里尤其有用：它能验证实现是否符合你的意图，还能发现一些 agent 不会主动为其编写具体测试用例的边界情况。agent 应当能够自行验证工作、发现失败并加以修复，不需要你留在循环中。

没有这些投入，代码生成得更快，只会带来更多失败的构建和缺陷。有了这些能力，代码库的整体质量反而会提高，因为 agent 的验证往往比许多人实际执行得更全面、更一致。

05. 执行成本很低，方向决定一切

当代码一个下午就能写完，困难的部分就不再是实现，而是判断该解决什么问题、该构建什么，以及什么时候应该改变方向。实现细节的修改成本很低，但系统设计、API 契约、依赖关系和架构取舍仍然代价高昂。把精力放在这些影响长久的决策上。

在设计阶段，可以把 agent 当作头脑风暴的伙伴：让它研究可选方案、探索不同路径，并找出你思路中的漏洞。如果两种设计都可行，可以让 agent 分别制作原型并进行比较。过去只能靠争论决定的问题，现在可以用证据来判断。

方向确定以后，采用 spec 驱动的开发方式：先与 agent 一起写出清楚的 spec 和需求，减少它开始生成代码之前的歧义。如果只给 agent 一个含糊的 prompt，它会自行决定如何取舍，而你撤销这些决定花费的时间，可能比跳过 spec 省下的时间更多。

迭代过程中，把注意力放在最重要的问题上：架构能否承受真实负载，原先的设计取舍是否需要重新评估，以及当前产物是否已经可以交到用户手中。

06. 把代码当作可丢弃的产物

如今，代码的成本很低。你需要不断判断正在构建的东西是否值得发布，以及它是否值得后续的运维和维护成本。现在，你可以用一天做出原型，然后选择放弃；也可以用两周把产品做到接近可发布的状态，发现方向不对后再重新开始。

过去，丢弃代码很难，原因有两个：代码是自己花几个月写出来的，所以很难割舍；重新开始，又意味着再花几个月。现在，这两个原因都不复存在。重要的是交付正确的东西，而不是勉强把初稿送进生产环境，也不是因为已经投入了成本，就回避必要的架构调整。

不再有用的代码，就把它丢掉。agent 可以在当天结束前构建出下一个版本。

边界处的测试是例外。单元测试会和代码一起被丢弃，但那些让重新开始仍然安全的测试需要保留：验证行为的端到端集成测试、验证不变量的属性测试，以及验证大规模性能和并发能力的负载测试。它们共同构成了任何重写版本都必须满足的契约。

07. 用要求人类的标准要求 AI 产出

只有速度，没有质量，只会增加生产环境中的风险。无论代码由谁或什么生成，只要以你的名义发布，责任就在你。刚开始时，这意味着要逐行审查 agent 的产出，逐渐弄清模型擅长什么、容易在哪些地方出错，从而建立信心。

时间久了，逐行阅读所有代码无法扩展到更大的工作量，因此你需要构建一个 AI reviewer 来分担审查工作，检查团队在意的问题，例如正确性、安全性、可维护性、测试质量和常见缺陷模式。在创建 PR 之前，先用 AI reviewer 检查本地改动，然后在 CI 中再运行一次。AI reviewer 逐渐成熟后，可以让它处理前几轮反馈。

把人的注意力放在最擅长判断的问题上，例如设计和架构是否合理，改动会怎样影响上下游系统，以及安全边界是否可靠。

不要让 agent 的工作循环止于合并。让它监控部署、验证生产环境中的实际行为；如果出现回退或异常，就自动开始处理修复。对结果负责，意味着跟进一项改动进入生产环境的全过程，而不是在 PR 阶段停下。

08. 信任边界，而不是 agent

要让 agent 长时间自主运行，就需要不依赖人工监看的 guardrail。不要接受这样的虚假二选一：要么任由 agent 在你的电脑上不受限制地运行，要么对每一次 tool call 都点击“接受”。更好的做法是把 agent 的权限限制在它实际需要的文件、工具、网络和凭据内，然后让它在无需监督的情况下运行。

一开始把范围收紧，随着你对这些限制更有信心，再逐步扩大权限，最终只对无法撤销的操作设置确认。对生产环境尤其要谨慎：除非你明确、审慎地授权，否则 agent 不应拥有生产账号或部署凭据。

再加入确定性的检查，捕获普通测试不容易发现的问题：用静态应用安全测试发现漏洞，用凭据扫描发现泄露的密钥，并通过自动推理，以数学方式验证 agent 的产出是否符合你的意图。每自动化一项 guardrail，你就少一个必须留在循环中的理由。

09. 让 agent 参与所有工作，而不只是写代码

建立起前面提到的习惯和基础以后，可以把同样的做法用到各类工作中。过去需要一周完成的设计文档，现在一个下午就能完成；过去耗时数小时的运维调查，现在几分钟就能完成。进度更新、Sprint 总结、oncall 报告和文档，都可以采用同一套流程。

提供 context，定义预期结果，让 agent 起草，然后在对外分享之前进行审查和修改。

真正的提速来自把 agent 用在整个开发生命周期中：规划、开发、测试、部署和运维。这份宣言里的原则同样适用于这些 agent：给出清楚的意图、快速的反馈循环和受限的访问权限。pipeline agent、oncall agent、文档 agent 和第三方 agent 应当共享大部分基础配置与 context。给它们相同的 steering file 和工具，让它们无论执行什么任务，都能保持一致的行为。

10. 持续调校你的 agent 工作体系

每当 agent 走错方向，或不必要地把你拉回执行循环时，都问问自己：怎样防止同样的事情再次发生？解决办法可能是在 steering file 中增加一条规则，用 skill 记录它没有正确执行的流程，用命令行工具把手动步骤自动化，用 MCP server 获取合适的 context，或者扩大它对某项此前无法访问的工具或系统的权限。agent 的每次失误和打断，都是进一步提高其自主性的机会。

这就是 Frontier Engineering 新的日常习惯：你不仅在构建产品，也在不断改进那套构建产品的系统。

这种习惯会逐渐产生复利。最初，agent 只有在你明确给出 prompt 后才会运行，而且经常需要你介入。随着 steering file 和工具逐渐成熟，agent 会变得更加自主，能够在后台运行：无需你发起任务，就主动发现并修复缺陷、清理技术债、改善代码质量。

随着模型改进，新的 agent 可以清理旧模型生成的内容。新模型发布时，重新检查过去为了弥补旧模型弱点而采用的变通方案是否还有必要。steering file 和工具都是持续演进的产物，其变化速度会和模型一样快。