从设计到实现：登录模块的 Loop 实战记录

系列第 3 篇 · 前置：第 1 篇 → 第 2 篇 → 第 3 篇

理论讲再多，不如真做一遍。用 Loop Engineering 从零实现一个登录模块的完整过程------包括设计、踩坑、独立评审发现缺陷、修复。

第一章：为什么从零建项目

决策：不碰旧项目，新建 LoginDemo

一开始打算在已有项目上加登录模块，但遇到一堆问题：

markdown 复制代码

已有项目的麻烦：
  - 有残留的半成品登录代码（改坏了影响别的）
  - git 状态混乱
  - 别人的模块在开发，怕冲突

干脆新建一个「只有登录」的项目：
  - 无历史包袱
  - 功能边界清晰（登录就是登录）
  - 正好是练 Loop 设计的理想载体

教训：学新技术时，选一个「干净、你熟、边界清晰」的载体，能少踩一半坑。刚开始选了不熟领域的项目，结果连「什么算合格」都说不出来------后来才知道，评判标准 = 领域判断力，选你熟的领域才能设计出标准。

第一步：建立保护点（git）

新项目第一件事不是写代码，是 git 化：

csharp 复制代码

git init
git add .
git commit -m "Initial: LoginDemo skeleton"

为什么先 git 化：后面所有改动都可能出错，有一个「能回滚的点」才有安全感。这其实就是外层「记忆持久化」------给项目一个可恢复的存档。

使用Worktree 隔离也可以

第二章：设计三张卡（写下来，不是想出来）

需求定义

css 复制代码

A. 邮箱 + 密码登录（表单 + 校验）
B. token 持久化（重启还在，过期清除）
C. 登录状态管理（idle/loading/success/error）
D. 退出登录
E. 假登录实现（无真实后端）

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

关键是把「好」拆成可验证的条款，不是形容词：

复制代码

① 编译通过
② 邮箱+密码登录（空输入/格式/长度校验）
③ token 持久化（SharedPreferences，7天过期）
④ 状态管理（ViewModel 可观察）
⑤ 只看状态数据（UI 不自己判断登录）
⑥ 退出登录
⑦ 架构一致（Compose+MVVM）
⑧ 测试通过

卡2：反馈内容（不合格时说什么）

css 复制代码

[文件:行号] 问题 | 严重级别 → 证据

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

复制代码

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

三张卡看起来简单，但这是整个 Loop 的灵魂。 我一开始也想跳过，直接写代码------后来发现，没有卡1的「什么算合格」，AI 第一轮就自称「做好了」，根本没法验收。

第三章：六构件------把 Loop 放大成系统

设计完三张卡，还有六个「外围构件」要定。这不是理论，是每个都要落地的：

先解释「六构件」是什么：这是 Loop 系统的六个组成部分（Automations 触发 / Worktrees 隔离 / Skills 知识 / Connectors 连接 / Sub-agents 分工 / 记忆持久化）。三张卡回答「单个 Loop 怎么转」，六构件回答「Loop 系统怎么搭」，对应 Claude Code 官方能力。

objectivec 复制代码

① Automations：谁触发？→ 手动（开发阶段你在场）
② Worktrees：在哪跑？→ 隔离副本（git worktree：同一仓库检出多个分支到不同目录）
③ Skills：靠什么知识？→ CLAUDE.md + SKILL.md
④ Connectors：连什么？→ 暂不需要（对话交付）
⑤ Sub-agents：谁写谁查？→ 3 Agent 协作
⑥ 记忆持久化：记住做到哪？→ progress.md

每个构件都有「为什么这么选」：

手动触发：因为是一次性开发，不需要定时
Worktree 隔离：这里是为了掌握 git worktree 而加------单人练手项目本不需要，但多人协作时它让每个分支有独立目录，不用反复 stash。
Skills：因为 Agent 需要知道「按什么规范写」，不能每轮问

第四章：3 Agent 协作------核心设计

这是整个 Loop 最有价值的部分。不是「一个 AI 写完自查」，是多个独立 Agent 分工：

复制代码

生成 Agent → 测试 Agent → 评审 Agent
  写代码       跑测试       对照卡1判定

不达标 → 评审输出问题清单 → 反馈给生成 Agent → 重写 → 再测 → 再评

为什么是 3 个而不是 4 个：最初设计了「诊断 Agent」（需求分析）------但登录模块需求已经完全明确（A-E 五能力 + 八条标准写死了），诊断 Agent 只会「复述需求」，不产生新信息，是冗余。所以砍掉它，保留真正有价值的三个：

复制代码

生成 Agent：写代码（核心）
测试 Agent：跑测试客观验证（防假达标）
评审 Agent：对照标准判定（独立评审）

这里有个真实教训：需求明确的简单任务，不要为了「看起来高级」硬加 Agent。 一开始加了诊断 Agent，被独立评审指出「冗余」，才砍掉。多 Agent 协作的价值在于分工，不在「数量多」。

为什么必须分开：同一个 AI 又写又查，会有「我写的就是对的」的预设------假达标。分开后，测试 Agent 独立跑测试、评审 Agent 独立对照标准，才能发现真问题。

数据怎么传：

流程数据：显式传参（生成→测试→评审）
状态数据：共享文件（代码/进度/测试报告落盘）

第五章：踩坑------独立评审发现了我没看到的问题

设计完、脚本写好后，做了一件关键的事：让一个独立 Agent 审查设计。

结果它发现了 一堆没想到的问题------这就是「自己看自己」的盲区：

blocker（会导致失败）

javascript 复制代码

1. 记忆持久化是「假实现」！
   脚本里用 require('fs')，但脚本是 ESM 格式 → require 未定义
   → 抛错被 try/catch 吞掉 → progress.md 永远写不出来
   → 你设计的「记忆持久化」整个落空，而且跑完你都不知道

major（影响质量）

markdown 复制代码

2. 测试 Agent 写的测试「从未被运行」！
   只跑编译（assembleDebug），没跑 ./gradlew test
   → 逻辑错（比如假登录规则写反）也能顺利通过验收

3. 「三样全记」只实现了一项，而且坏了；续跑没实现

4. 假登录规则只有 SKILL.md 有，评审 Agent 够不着 → 无法客观判定
   （假登录规则 = 邮箱含 @ 和 . + 密码 ≥6 位 → 成功，否则失败）

注：评审还提过「worktree 隔离没实现算缺陷」------后来判断这是误判：单人项目本不需要 worktree，保留它只是为了掌握 worktree 工具，所以「没实现」反而不算缺陷。

独立评审还抓到我一个更本质的问题 ：重写脚本时，又「声称修好」但实际上没修------

lua 复制代码

我删了 require，但没真实现写盘（writeProgress 只 log 不落盘）
我加了卡1⑧，但没同步进设计文档（三处一致性被破坏）
   「三处」= 设计文档 / SKILL.md / workflow 脚本，
   三处都写着卡1，改一处必须同步另两处，否则互相矛盾

= 我假装修复，实际没修

这比「没发现 bug」更糟------因为它让你以为修好了。诚实面对这个，重写了记忆落盘（用 Write 工具真写文件到 progress.md）、同步了三处文档（卡1⑧进入三处）。

核心教训：

设计完一定要「独立评审」------自己看自己会漏
修复要「真修」，不要「声称修好」------假修复比不修更危险

第六章：文档还是 workflow？（过程最后的思考）

做完整套，停下来想了一个问题：登录模块是一次性开发，为什么要写 workflow？用文档驱动不行吗？

答案是------完全可以，效果一样。但有一个区别：

markdown 复制代码

文档驱动：单 Agent + 你在场当评审
workflow：多 Agent 自动协作（你不在场）

差别不在「结果」（都能做出达标的登录模块）
差别在「过程」：你想看多 Agent 协作 → 需要 workflow
              只想做登录模块 → 文档就够

最终认知（经过一轮独立评审补充的更准确版本）：

ini 复制代码

文档 = 规则说明书 → 指挥主 Agent（可轻量调子 Agent）
workflow = 可执行调度器 → 编排独立 Agent

升级到 workflow 的判断标准（4 条，有一条就该上）：
  ① 需要并行执行
  ② 需要异常自动回退
  ③ 需要脱离对话独立运行
  ④ 需要状态持久化

都没有 → 文档 + 主 Agent 就够，硬上 workflow 是过度工程化

第七章：这个过程的真正收获

做完这个项目，最有价值的收获不是「登录模块代码」，是这几条：

markdown 复制代码

1. 评判标准 = 领域判断力
   选你熟的领域，才设计得出「什么算合格」

2. 设计完一定要独立评审
   自己看自己会漏掉 blocker（记忆假实现、测试没跑）

3. 修复要真修，不要声称修好
   假修复比不修更危险------它让你误以为没问题

4. 文档 vs workflow 是取舍，不是好坏
   一次性任务 → 文档；要自动化/并行/持久化 → workflow

5. 设计决策要固化到产物
   设计文档 + SKILL.md + workflow 脚本 = 可交接的产物
   任何会话读到，都能接着做

结语

Loop Engineering 不是玄学，是「让 AI 反复干活到达标」的工程方法。真做一遍，比看十篇教程有用------因为你会在过程中踩到教程不会写的坑：假达标、假修复、设计决策没落地、三处不一致。