Loop Engineering 与前沿 Vibe Coding
Loop Engineering 是 2025–2026 年 AI Coding 讨论里很新的说法。它不是“写一个更神的 prompt”,而是设计 AI coding agent 的循环:让模型反复感知上下文、制定计划、调用工具、修改代码、运行验证、接受审查,再把失败反馈回下一轮。
一、为什么需要 Loop Engineering
Vibe Coding 解决的是“用自然语言快速探索”;Harness Engineering 解决的是“给 agent 项目规则、工具和验证边界”;Loop Engineering 进一步关注:一次任务不是单次生成,而是一组可控循环。
“Vibe Coding”最早由 Karpathy 在 2025 年带火,强调开发者用自然语言驱动 AI 快速生成和修改代码。但面试里不能只停留在“我会用 AI 写代码”,而要说明如何把这种探索能力纳入工程闭环。Loop Engineering 就是这个升级方向:从一次性生成,变成可度量、可回滚、可审查的反馈系统。
需求 / Bug / 想法
-> 读取上下文
-> 生成计划
-> 修改代码或测试
-> 运行验证
-> 分析失败
-> 调整 prompt / context / tools / code
-> review gate
-> 合并或回滚
面试里可以把它讲成:“我不追求一次 prompt 生成完美代码,而是设计一个能稳定收敛的反馈循环。”
二、和 Prompt / Context / Harness 的区别
| 概念 | 关注点 | 典型问题 |
|---|---|---|
| Prompt Engineering | 单次怎么问 | 目标、约束、输出格式是否清楚 |
| Context Engineering | 给什么上下文 | 文件、规则、历史决策是否足够且不过载 |
| Harness Engineering | 项目脚手架 | 工具、状态、验证、权限、handoff 是否齐全 |
| Loop Engineering | 多轮如何收敛 | 失败如何反馈、验证如何升级、何时人工介入 |
一个成熟回答是:Prompt 是一次输入,Context 是模型看到的世界,Harness 是工作环境,Loop 是任务如何反复迭代直到可信完成。
三、核心 Loop 类型
| Loop | 形式 | Android 例子 |
|---|---|---|
| Prompt Loop | ask -> inspect -> refine | 让 AI 先草拟 Compose 页面,再根据截图和设计约束修正 |
| Spec-to-Code Loop | spec -> plan -> implement -> verify -> review | 新功能先写验收标准,再生成 ViewModel/测试/页面 |
| Eval Loop | benchmark -> failure cluster -> fix prompt/context/tool | 用固定 bug 集/测试集评估 agent 是否真的变好 |
| Agent Loop | observe -> plan -> tool call -> patch -> test -> summarize | agent 读文件、改代码、跑 ./gradlew test、根据失败继续修 |
| Human-in-the-Loop | approval -> sensitive action -> review gate | 支付、隐私、发布配置必须人工确认 |
| Memory / Context Loop | retrieve -> use -> update -> prune | 项目规则、handoff、踩坑经验更新,过期内容删除 |
四、前沿话题地图
- Loop Engineering:把 AI 编码从“一次生成”变成“可观察、可终止、可审查的循环”。
- Coding Agent Evals:用真实任务集、回归测试、lint/build、人工评审来衡量 agent,而不是只看 demo。
- Context Runtime:上下文不只是 prompt 里的几段文字,而是按任务动态检索、裁剪、更新。
- Tool Surface / MCP:把 repo、浏览器、日志、设计稿、设备、CI 暴露成受控工具。
- Multi-Agent Review:实现者、审查者、验证者分离,降低同一个模型自证正确的风险。
- Spec-first AI Coding:先把需求写成可验证 spec/plan,再让 agent 执行。
- Secure Agentic Coding:权限最小化、secret 隔离、依赖审计、敏感操作审批。
- Asynchronous Coding Agent:后台 agent 接任务、开分支、改代码、跑测试、提交 patch/PR,工程师从“逐行写”转向“写任务、定验收、审结果”。
- Device-in-the-Loop:移动端 agent 不只读代码,还要看截图、日志、trace、模拟器/真机结果。
这些词不是为了炫技。好的面试表达要回到工程问题:如何让 AI 产出更可靠,如何证明它真的变好,如何在高风险节点停下来让人接管。
五、Eval-Driven AI Coding
Eval Loop 是 Loop Engineering 里最容易拉开层次的部分。它回答的不是“这次 AI 有没有跑通”,而是“这个 agent / prompt / context / tool 配置在一组任务上是否稳定变好”。
| Eval 对象 | 可度量信号 | Android 示例 |
|---|---|---|
| 编译能力 | build/lint/type check 通过率 | Gradle/KSP/KAPT/AGP 错误修复集 |
| 测试能力 | 单测/UI 测试通过率、弱断言比例 | ViewModel、Repository、Compose UI 测试 |
| 修 bug 能力 | 历史 bug 回放、回归率 | crash、ANR、Room migration、权限适配 |
| 架构遵守 | diff 是否越界、依赖方向是否正确 | feature 模块不能反向依赖 app |
| 安全合规 | 是否新增敏感权限/日志/依赖 | 隐私 SDK、设备标识、证书配置 |
团队可以维护一个小型内部 benchmark:10 个历史 bug、5 个 UI 改动、5 个 Gradle/依赖冲突、若干隐私/权限迁移任务。每次调整 agent 配置后跑一遍,看通过率、回归率、review 问题数,而不是只看一次 demo。
六、Android 场景里的 Loop 设计
1. ViewModel 状态机测试 Loop
需求:登录页新增 passkey 入口
-> AI 提取 State/Event/Effect
-> 生成 runTest/Turbine 测试
-> 人工确认断言覆盖取消、失败、成功
-> 实现最小代码
-> 跑单测
-> review 生命周期和协程取消
关键点:先让测试描述状态机,不要让 AI 直接改 UI。
2. ANR / Perfetto 排障 Loop
ANR trace / Perfetto 片段
-> AI 摘要主线程、Binder、锁、IO 线索
-> 人工回到 trace 验证
-> 定位代码路径
-> 写复现或监控指标
-> 修复后用 trace / Macrobenchmark 对比
关键点:AI 可以加速读栈,但不能用“看起来像”代替证据。
3. Gradle 构建失败 Loop
失败日志
-> AI 分类:依赖冲突 / AGP 版本 / KSP/KAPT / 配置缓存
-> 搜索现有版本和相邻模块
-> 提出最小改法
-> 跑目标 Gradle task
-> 确认没有全局升级和范围外改动
关键点:不要让 AI 为了过编译随意升级 AGP、Kotlin 或 AndroidX。
4. targetSdk / 隐私适配 Loop
targetSdk 升级需求
-> 列行为变化:权限、通知、媒体、FGS、edge-to-edge
-> 扫描受影响代码
-> 分模块改造
-> 多版本真机/模拟器验证
-> 灰度指标和回滚方案
关键点:平台适配必须有设备矩阵和隐私合规证据。
5. 设备在环 UI Loop
Compose / View 改动
-> AI 生成页面或 patch
-> 跑 Preview / screenshot / UI test
-> 真机或模拟器检查系统栏、键盘、深色模式、字号、无障碍
-> 把截图/失败日志反馈给 AI
-> review 状态提升、重组性能和设计规范
关键点:移动端 UI 不能只靠静态代码 review。截图、设备矩阵、无障碍和性能表现都是 loop 的反馈信号。
七、异步 Coding Agent 与多 Agent 协作
前沿 AI Coding 的另一个趋势是 asynchronous coding agent:工程师把 issue、spec、测试命令和边界交给后台 agent,agent 自己读代码、修改、运行验证并产出 patch/PR。工程师的核心能力变成:
- 写清任务和验收标准。
- 限定可改范围和风险边界。
- 选择合适的验证命令和设备矩阵。
- 审查 diff、测试证据和剩余风险。
- 决定合并、返工或回滚。
多 Agent 可以进一步拆成 Planner / Builder / Critic / Verifier,但不要迷信“人多就可靠”。多个 agent 可能互相确认错误结论,也可能因为上下文不一致制造冲突。可靠性来自独立验证、清晰 owner 和真实测试,不是 agent 数量。
八、可信来源与术语锚点
这些术语变化很快,面试中可以点到来源,但不要背成标准答案:
- Karpathy 关于 Vibe Coding 的公开讨论:让自然语言成为快速开发入口。
- Simon Willison 对 vibe coding 的区分:并非所有 AI-assisted programming 都是 vibe coding。
- Anthropic “Building Effective AI Agents”:强调 agent workflow、工具使用和人类控制。
- Anthropic Model Context Protocol:把上下文和工具系统化接入 agent。
- OpenAI Evals / SWE-bench:代表用任务集和 benchmark 评估 LLM/agent 系统的思路。
- GitHub Copilot coding agent、Google Jules、OpenAI Codex cloud agent:代表异步 coding agent 产品方向。
九、Loop 的终止条件
好的 loop 必须知道什么时候停:
- 需求验收标准全部满足。
- 覆盖改动的测试/build/lint 通过。
- diff 没有范围外重构。
- 高风险项经过人工 review。
- 剩余风险被明确记录。
坏 loop 的信号:一直让 AI “再优化一下”、失败原因不分类、每轮都扩大修改范围、没有可复现验证。
十、面试怎么答
可以这样说:
我理解的 Loop Engineering,是把 AI coding 从“单次生成代码”升级成“可控反馈系统”。一次任务会经过需求澄清、上下文检索、计划、实现、验证、失败归因、review 和收敛。Android 项目尤其需要这种循环,因为生命周期、协程、Gradle、targetSdk、隐私权限和真机表现都不是模型凭空能保证的。我的做法是让 AI 提效,但用测试、构建、trace、截图、代码审查和人工审批决定是否可信完成。
高频面试题
Q1:Loop Engineering 和 Prompt Engineering 区别是什么? Prompt Engineering 关注一次怎么问;Loop Engineering 关注多轮如何收敛,包括验证、失败反馈、上下文更新、工具调用和人工审查。
Q2:为什么 coding agent 需要 eval loop? 因为 demo 成功不代表稳定。eval loop 用固定任务集、回归测试、构建结果和人工 review 衡量 agent 是否真的变好,并把失败样本反向用于改 prompt、context、tool 或 harness。
Q3:Human-in-the-loop 是不是降低自动化效率? 不是。它把人工放在高风险节点:权限、支付、隐私、发布、依赖升级、架构变更。低风险重复任务自动化,高风险决策人工审批,整体更可靠。
Q4:Android 项目最适合设计哪些 AI loop? ViewModel/UseCase 测试 loop、Gradle 失败诊断 loop、ANR/Perfetto 排障 loop、Compose UI 截图/无障碍 loop、targetSdk/隐私适配 loop。
Q5:怎么防止 agent loop 越改越乱? 限制任务边界和可改文件;每轮只解决一个失败原因;要求运行验证命令;review diff 是否最小;如果连续失败,停止并重新澄清需求或升级人工介入。
易错点 / 追问
- 不要把 Loop Engineering 说成“循环调用 AI 直到能跑”。核心是可观察、可验证、可终止。
- 不要让同一个 agent 自己实现、自己审查、自己宣布完成;至少要有独立 review 或人工 gate。
- 不要把记忆越积越多当成 context engineering;过期上下文会污染决策。
- 不要用 AI 生成的测试证明 AI 生成的代码正确,必须人工检查断言质量。
- 不要在支付、隐私、证书、发布配置上做无人审批的 agentic 修改。