Frontier Engineering 十条工作原则：人定方向，Agent 执行

Frontier Engineering 的十条工作原则：人定方向，Agent 执行 当 AI Coding Agents 可以自主写代码、跑测试、修 bug、连续数小时不需要人介入时，开发者的工作方式应该怎样彻底改变？ [@kirodotdev](https://x.com/kirodotdev) 团队 [@clare\_liguori](https://x.com/clare_liguori) 把这种变化方向叫做 「Frontier Engineering」，反复强调它不是 vibe coding。并给出了 Frontier Engineering 的十条工作原则。 [kiro.dev/topics/frontie…](https://kiro.dev/topics/frontier-engineering/) 1. 你是架构师，不是打字员 这是整个体系的世界观基础。给出一个惊人的数字：前沿开发者手写的代码占其产出总量的不到 1%，其余全部来自他们“指导、引导和审查”的 Agent。 工作因此压缩成两件事：定义“完成”是什么（需求、约束、验收标准），以及验证产出是否符合意图。 2. 最大化 Agent 时间，最小化你的介入 这条批评的是大多数人的现状：发一条提示 → 等 60 秒 → 拿回代码 → 手动测试 → 把报错贴回聊天窗。这种“贴身循环”永远快不起来。 正确做法是给 Agent 内置验证步骤的长任务，例如：“实现这个功能，写测试，跑测试，确保通过，新代码达到 90% 测试覆盖率”——让 Agent 持续工作 30 分钟以上并自我纠错收敛，你去干别的。 进阶形态是：多个 Agent 并行、异步审查产出、让 Agent 跑通宵、让 Agent 启动其他 Agent。此时瓶颈不再是打字速度，在于你同时能让多少个 Agent 保持有意义的工作状态。终点是把自己从循环中移除，只保留“设定方向 + 验证结果”。 3. 为 Agent 构建你的代码库 关键洞察是 ROI 的变化：人类新成员只需入职一次，而 Agent 每次会话都要重新“入职”一遍。 因此文档、规范这些投入的回报率被放大了无数倍，包括： · 基础工程卫生：README 与架构文档、描述预期行为的测试、清晰的模块边界、强类型、快速构建与信息丰富的报错 · 显式上下文四件套：steering files（规范）、skills（按需加载的操作流程）、scripts（自动化环境搭建）、CLI 工具与 MCP 服务器（获取上下文、执行操作） · 面对遗留大库：一次只准备一个模块，把 Agent 的工作范围限定在已准备好的模块内 · 让 Agent 留下推理过程——记录设计决策、大量写注释，让下一个会话继承的不仅是代码，还有代码背后的“为什么” 4. 给 Agent 快速反馈回路 一句话点破瓶颈：“如果你的 Agent 不能在本地跑测试并在你看代码之前自我修正，你自己就成了瓶颈。”凡是你在验证自己工作时会用的工具，Agent 也应该能用：linter、单元测试、浏览器（视觉验证 UI）、依赖服务的本地 mock、在笔记本上起完整技术栈的能力。 特别推崇属性测试：它验证的是“实现是否符合意图”，且能捕捉 Agent 自己想不到要写显式用例的边界情况。这段有一个很实在的对比：不投入的话，更快的代码生成只会带来更多坏构建和 bug；投入了的话，代码库质量反而会提升——因为 Agent 验证代码比很多人类更彻底、更一致。 5. 执行廉价，方向决定一切 当代码一个下午就能写完，实现本身不再是难题，难题变成：该解决什么问题、该构建什么产品、何时调整方向。成本结构发生了倒挂：实现细节改起来很便宜，而系统设计、API 契约、依赖关系、架构取舍这些“持久性决策”改动代价高昂——精力应该花在这里。 两个具体实践：把 Agent 当头脑风暴伙伴（调研方案、探索替代路径、挑你思路的漏洞，两个方案都拿不准就让 Agent 各做一个原型用实证代替争论）；以及规格驱动开发 (SDD)，在生成代码之前先写清规格。 给 Agent 含糊的提示，它就会替你做各种取舍，而你之后推翻这些决定所花的时间，会超过当初省下不写规格的时间。 6. 把代码视为可丢弃的 这是心态上最激进的一条。既然代码生成成本趋近于零，就应该持续评估“这东西值不值得发布、值不值得长期维护”——可以一天做个原型直接扔掉，可以花两周做到接近生产级后发现方向不对就推倒重来。过去舍不得扔代码的两个理由（感情上的沉没成本、重写要几个月）如今都不成立了。 但有一个重要例外：位于系统边界的测试必须保留——端到端集成测试（验证行为）、属性测试（验证不变量）、负载测试（验证大规模性能）。这三类测试构成一份“契约”，任何重写版本都必须满足它。这是让“从头再来”变得安全的先决条件。 7. 以人类标准要求 AI 产出 责任归属清晰：凡是署你之名上线的代码，无论谁写的，你都要负责。路径是渐进的：早期逐行审查 Agent 产出，建立对模型能力边界的直觉；规模化后构建 AI 审查器（检查正确性、安全性、可维护性、测试质量、常见 bug 模式），pre-PR 本地跑一遍、CI 再跑一遍，逐渐放手让它处理前几轮反馈；人类注意力集中在最擅长的判断上——架构是否正确、变更对上下游系统的影响、安全边界是否健全。 这条的结尾很有分量：“对结果负责意味着要伴随这项变更一直到生产环境，而不是在 pull request 处就停下来”——让 Agent 监控部署、验证生产行为、发现回归就自动着手修复。 8. 信任边界，而非 Agent 这是关于安全的第四条。要让 Agent 长时间自主运行，前提是有一套不依赖人盯着看的护栏。 明确否定了两个极端：放任 Agent 乱跑，或每次工具调用都手动点“接受”——那是个虚假两难。正确做法： · 最小权限：只让 Agent 访问真正需要的文件、工具、网络、凭证，从窄权限起步，随信任建立逐步放宽，最终人工只把关“无法撤销的操作” · 红线：Agent 绝不应访问生产账号或部署凭证，除非明确且审慎地授予 · 确定性检查层：SAST（安全漏洞）、凭证扫描（泄漏密钥）、自动化推理（数学方式验证产出是否符合意图） “你每自动化一道护栏，就少一个必须留在监督循环中的理由。”注意这个精妙的换位：信任的对象从 Agent 本身转移到了边界体系。 9. Agent 不只用于代码 同样的模式（提供上下文、定义期望结果、让 Agent 起草、审查打磨）推广到一切：一周的设计文档变一个下午，数小时的运维调查变几分钟，状态更新、冲刺总结、值班报告、文档都适用。关键主张是一致性：流水线 Agent、值班 Agent、文档 Agent 应共享同一套 steering files 和工具——“清晰的意图、快速的反馈回路、受限的访问”这三原则对所有 Agent 一视同仁。 10. 持续调优你的 Agent 配置 收束全篇的元原则，提出了一个“新日常习惯”：每当 Agent 走错方向或把你拉回流程，就问“怎样防止这种情况再次发生？”答案可能是加一条 steering 规则、创建一个 skill 固化之前做错的流程、写个工具自动化手动步骤、搭个 MCP 服务器收集上下文，甚至是放宽一条被证明过严的权限限制。每一次失误都是扩大 Agent 自主权的机会。 由此产生复利：从“需要明确提示才动、频繁要人输入”的 Agent，演进为能在后台自主发现并修 bug、清理技术债的 Agent。还有一层时间维度：新模型发布时要重新审视——为旧模型弱点搭的变通方案还有必要吗？steering files 和工具是“活的产物”，要随模型一起演进。 十条原则之间的结构 · 角色 - 1、2、5 人不再是执行者，而是方向和调度 · 系统 - 3、4、10 代码库、反馈环、工具链要让 agent 能独立闭环 · 质量与风险 - 6、7、8 实现可弃，契约和边界不可弃；对人负责，对模型不盲信 · 范围 - 9 同一套方法覆盖整个研发生命周期 少任何一层都不行。只有角色、没有反馈环，就是远程指挥一个看不见对错的实习生。只有速度、没有边界，就是把生产事故的频率一起放大。只有文档、没有持续调优，steering 会迅速过期，agent 会反复犯同一类错。   Clare Liguori@clare\_liguori I just published a manifesto for all the developers out there who use an AI coding tool, but feel like they're not shipping much faster I wrote 10 principles for changing how you build software with AI, based on what I've seen work for teams across Amazon [kiro.dev/topics/frontie…](https://kiro.dev/topics/frontier-engineering/) [🔗 View Quoted Tweet](https://x.com/clare_liguori/status/2097836812958097915)