如何设计一个 Loop：以登录模块为例

系列第 2 篇 · 前置：第 1 篇Loop Engineering 入门：告别一句句指挥 AI

上一篇讲了 Loop 的三个问题：怎么算合格、不合格告诉 AI 什么、什么时候停。这一篇用一个真实例子------Android 登录模块------完整走一遍这三个问题的设计过程。

一、先选载体：为什么是登录模块

第 1 篇说过：评判标准 = 领域判断力。登录模块最熟的模块之一，所以标准闭眼能列。

假设你的 App 要用邮箱 + 密码登录，登录成功后存 token。现在要让 AI 自动开发这个模块。

二、卡 1：怎么算合格？（评判标准）

这是最关键的一步。很多人卡在这，因为把「合格」写成了形容词。

错误示范（无法执行）：

复制代码

让 AI 写一个好的登录模块

「好」怎么打分？AI 只能说「我写得挺好」，第一轮就自称达标了------假达标。

正确做法：把「好」拆成可验证的条款。

给登录模块定了六条：

bash 复制代码

① 编译通过            ./gradlew assembleDebug → BUILD SUCCESSFUL
② 架构一致            遵循项目现有模式：接口 + Provider + Repository + ViewModel + 依赖注入
③ 状态正确            登录状态（idle/loading/success/error）在 StateFlow 可观察
④ 边界处理            空输入 / 邮箱格式 / 密码长度 / 错误提示
⑤ token 持久化        token 存本地存储，重启仍在，过期自动清除
⑥ 只看状态数据        UI 不维护登录判断，一切由 ViewModel 状态驱动

六条都满足一个共同点：能验证。 能跑编译、能看代码、能测重启。没有一条是形容词。

两个设计要点：

标准必须在生成前定死。先看 AI 写了什么再定标准，标准会被它牵着走，等于没定。
第 ⑥ 条是 Android开发的经验的判断------「状态源分散」是登录模块最常见的架构隐患，UI 自己判断登录状态，后期必出 bug。

三、卡 2：不合格告诉 AI 什么？（反馈内容）

AI 写出来不达标，你怎么反馈？这是第二大坑。

错误示范：

复制代码

再改改，写得不好

AI 不知道哪不好，只能瞎改，改来改去原地打转------空转。

正确格式（位置 + 问题 + 级别）：

csharp 复制代码

[LoginRepository.kt:15] token 用内存变量，重启丢失 | 严重
[MainActivity.kt:20] UI 自己维护登录判断，应靠 ViewModel 状态 | 中等

没有证据的反馈，AI 无法判断自己错在哪，必然空转。 反馈必须具体到「哪个文件哪一行、什么毛病、多严重」。

四、卡 3：什么时候停？（终止条件）

最后一个问题。三个条件组合用：

复制代码

① 六条标准全达标 → 停
② 或 连续 2 轮无新问题 → 停
③ 或 最多 5 轮 → 停

为什么要组合？各有各的作用：

① 是质量目标：真达标了立刻停，是我们最想要的结果
② 是收敛兜底：连续两轮找不出新问题，说明再跑也不会有进展，避免无意义空转
③ 是硬熔断：最多跑5轮，防止标准不合理/任务超能力导致无限循环

只靠①可能死循环，只靠②③可能提前截断质量不足，三个组合就是「质量优先，同时保证一定会停」。

五、判定权：一个最容易漏的坑

「谁来判断达标」？ 这个空位，很多人没填，填了也填错。

复制代码

自评（玩具级，不可靠）：
  AI 写代码 → 同一个 AI 自查「达标吗？」
  → 同一个脑子有固定盲区：写时认为对的，查时还认为对
  → 可能第一轮就「假达标」停了
独立评审（工业级）：
  AI 写代码（生成 Agent）→ 另一个 AI 检查（评审 Agent）
  → 不同脑子，没有「我写的就是对的」预设
  → 能发现真问题

让 AI 自己检查自己，是最大的坑。 就像让考生给自己判卷------要么乐观假达标，要么反向装严格瞎挑。

独立评审的做法：

生成 Agent 按六条标准写代码
评审 Agent 独立验证：读实际文件、真跑编译，不相信生成者的自查
生成 Agent 可以对评审结论申辩 → 评审复核

六、交付物清单：防结构漂移

跑 Loop 还会遇到一个问题------AI 每轮结构不一样：

复制代码

第 1 轮：校验逻辑写在 UI 界面里
第 2 轮：反馈「校验该在 ViewModel」→ AI 挪过去了
第 3 轮：你又发现第 1 轮的界面被改乱了......
→ 结构漂移，每轮在重构，永不收敛

解决办法：定交付物清单------固定核心文件，让每一轮对照同一个文件判定。

复制代码

必须生成的核心文件：
  登录状态 / 登录接口 / 登录实现 / token 存储 / 仓库层
  ViewModel / 登录界面 / 依赖注入注册 / 入口跳转

但清单别定太死，否则限制 AI 发挥。这里分三个档位：

档位1：完全不限制文件结构，AI自由发挥，容易结构漂移
档位2：核心文件必须生成，允许额外增加（但增加要说明理由）
档位3：严格限制只能生成清单内文件，不允许新增，过于僵化

档位 2 最合理，既防结构漂移，又给AI留了合理发挥空间。

七、校准：跑起来，看设计哪里会坏

设计完的三张卡是纸面的，只有真跑一轮才知道哪里坏。三个故障信号，对照自查：

复制代码

故障 1：第一轮就「假达标」
  评审全过，但你自己看明显不行
  → 标准太松，或评审在放水（自己评自己）
  → 修法：加严标准 / 生成和评审分离
故障 2：空转
  每轮有反馈，但改 5 轮还在改同一处
  → 反馈不具体，AI 不知道怎么改
  → 修法：反馈带位置 + 证据
故障 3：永不达标
  跑 8 轮，分数卡着上不去
  → 标准太高，或任务超出 AI 能力
  → 修法：降达标线 / 拆成小任务

校准的心态：设计意图 ≠ 实际行为。跑起来发现不达标，不是设计错了，是「你的标准里藏着 AI 满足不了的条款」------改设计，不是固执按设计来。

八、这一篇总结

设计一个 Loop，七步：

arduino 复制代码

① 选熟载体（评判标准 = 领域判断力）
② 定卡 1：把「合格」拆成可验证条款（六条标准） 
③ 定卡 2：反馈带位置+问题+级别（禁止"再改改"） 
④ 定卡 3：三种终止条件组合
⑤ 判定权给独立评审（禁止自己检查自己） 
⑥ 定交付物清单（防结构漂移）
⑦ 跑一轮校准（根据实际故障调整设计）

每一步都是从踩坑里学来的：假达标、空转、结构漂移、自己评自己------都是真实发生过的坑。

下篇讲最后一块：设计好的 Loop，用文档驱动还是写脚本？ 以及官方的 /goal /loop /workflows /schedule 命令到底怎么用。

下一篇： 文档还是脚本？------让 AI 自动干活的完整指南