用途 find-the-loop 在迭代开始前运行，产出 Loop Card（模板 templates/loop-card.md），写明测量什么、智能体如何独立测量、测量噪声多大、什么算赢、何时停止。完成的卡片交给实际执行迭代的人，可以是自己、子智能体或 experiment-arms。任务带有迭代性质时使用，如修复、提速、减少、改进、调优或爬山式优化，包括“让编辑器感觉更跟手”这类模糊请求。
适用与不适用 适用：迭代型任务；会话中出现“回路气味”时立即停止当前工作并运行本技能，例如用户已手工粘贴 2 个以上截图、日志或数字；“还是坏的”“还是慢”“还是一样”出现两次；你准备在没有亲自运行的情况下写“请试试”“告诉我是否有效”“现在启动”；仅凭单次运行（n=1）声称百分比提升，或没有基线；人类报告“还是 3 fps”“CI 花了 40 分钟”等测量值；连续 3 次以上修复失败且之间没有新信号。 不适用：一次性机械修改（重命名、文案更改、配置升级）且现有 CI 已能证明正确性；该结果已有 Loop Card，应复用并更新基线；构建模式工作，大型新原型往往尚无信号可爬，应先提 issue 并与 autonomous-delivery 并行，等有真实可测对象再回来。
主要步骤
- 命名可感知的结果：问谁会在变好时注意到、会用秒表、眼睛或表格量什么，用他们的说法写，例如“关键路径上的 PR 到绿灯时间”，而非“任务时长”；代理指标须证明与结果相关。
- 用决策树分类问题，选定回路类型与测量工具；无法匹配或请求模糊时运行回路访谈（最多问五个问题：谁会注意到变好、你会看什么、现在是多少、什么结果会让你说“更糟”、这值得多久）。卡片中 Outcome、Metric、Keep bar 未填前不改代码。
- 先找再建：查找已有测试、基准、评测套件、性能探针、E2E 工具、遥测面板、CI 历史、过去人工决策（已分类 issue、接受/拒绝的评审意见），检查 package.json、Makefile、scripts/、.github/workflows/ 和已安装技能；都不合适才新建。
- 证明自己能独立操作工具：无人类参与端到端运行，留下命令加观察到的输出（数字、失败断言或亲自打开检查的产物路径，包括自己看过的截图或视频）。无法运行（需硬件、凭证或生产环境）须在卡片说明并选最接近的可运行工具。
- 测量噪声底（A/A）：未改代码确定性检查至少跑 2 次，计时类至少 5 次，记录离散度（CV 或最小到最大），据此设定 n 与可检测的最小效应；无变化单次运行已像“赢”说明 n 太小。
- 在固定 ref 上记录基线，注明 n 与日期；防缓存、路径过滤、空提交等假结果，测量变更须走真实路径。
- 首次修改前预登记保留标准：高于噪声底所需效应量、守卫指标（成本、体积、波动率、正确性）和泛化检查（留出集、第二台机器或合并后真实流量）；结果可见后标准只能作为新卡片版本并附理由修改。
- 提议者与裁判分离：改代码的智能体不给自己打分，由工具评分；每次只改一处；提示词与评测回路在爬升前阅读每个 FAIL，因为评分器本身可能是 bug。
- 设定牵引绳、停止规则与自主级别（取自 docs/autonomy.md，本技能不决定谁合并）；先用短运行调 n，工具被证明后再放长。
- 命名台账：在 templates/ledger.md 记录接受与拒绝，拒绝项反馈给提议者避免重试。
- 发布卡片并开始迭代：在会话或 PR 中贴出 Loop Card；合并后在真实流量上复测；结果影响超过本次任务时安排循环，如夜间基线在回归时提 issue。
决策树要点 逻辑 bug：先写失败测试，单元/集成复现，确定性重跑 3 次，标准为复现红转绿且套件全绿。UI/视觉 bug：自运行应用加捕获，E2E 工具加 DOM 断言、亲自打开检查截图或视频，固定视口、数据、主题，断言通过并附前后媒体。TUI/CLI 行为：PTY 脚本化运行，固定终端尺寸与种子，智能体观察到预期输出。UI 性能或卡顿：先 A/A 再探针，回放流程上的 FPS、渲染次数、长任务追踪，同机至少 5 次，p50/p90 超噪声底。CI 或构建速度：配对真实 CI 运行，关键路径 time-to-green p50/p90 加计费分钟，同 SHA、nonce 触及代码与工作流、交错、n≥6（小效应 12）。运行时或引擎性能：experiment arms，基准子集、参考正确性检查、留出集，A/A 离散度、交错 ABBA 重复、bootstrap CI。提示词或智能体行为：预注册评测（金标加金丝雀）k≥3、留出集，评分器校准，留出集通过率差值与泛化检查。分类、分诊或评审：用过去人工决策作标签数据集与留出拆分。数据或分析主张：独立真值，原始源查询并注入已知值，两个独立来源。波动测试或基础设施：重复 N 次统计，预设 N 下 0/N。生产行为：合并后遥测，周环比与队列，窗口内朝正确方向移动。模糊的“让 X 更好”：先做回路访谈，代码前达成卡片一致。
可调项 包括气味敏感度、主指标与守卫、噪声预算、保留标准、泛化检查、回路速度与保真度、牵引绳、并发与 API 预算（来自 .github/lever.yml）、裁判、自主级别、连续性；默认值与选项以资料中的表格为准，如 A/A 先行，计时 n=5、确定性 n=3，保留标准为 p50 和 p90 超过 A/A 离散度等。
输出 填好的 Loop Card（贴在会话、PR 或 issue），加已提交或链接的工具；噪声底与基线的记录行，作为台账首批条目；一行亲自运行证明：ran <command> → <observed result>。
本技能自身的反馈回路 指标是每任务人类收集信号数（用户须提供的截图、数字和“还是坏的”报告），卡片存在后目标为 0。守卫是卡片到接受变更所需轮次；若卡片只增加开销而不缩短该轮次，就针对该问题类简化卡片。记录工具后来被证明说谎的卡片（缓存命中、评分器 bug、未跟踪结果的代理指标），并将陷阱加入 decision-tree.md。
防止的失败模式 人类充当 FPS 表、截图泵或“现在试试”按钮；单次运行的“赢”在 A/A 中消失的发货噪声；基准特例化，提议者给自己评分或用提示词改动拟合单个评测用例；说谎的工具，如空提交 nonce、热缓存、跳过路径、未校准评分器；因未记录拒绝而重蹈死路；合并后悄然死去的回路。
背景案例 某开发者提示中粘贴截图从每月 49 次降到约 0，同期测量与基线语言从约 54 次升到约 292 次；一次应用性能会话中人类在 3 fps 下充当 FPS 表约 9 小时，改为让智能体构建性能测试后帧率 3→32→约 55 fps；一个 185 轮“还是坏的”bug 和约 15 张粘贴截图驱动的 121 轮重写同理。某 CI 提速项目用配对真实 CI 运行测量 79 个勿合并实验 PR，保留 27 个，p50 time-to-green 从 46.3 降至 26.5 分钟（−43%）。诚实回路会说“不”：一次引擎爬山拒绝 3/3 提议为噪声内；一次 3 次重复的 A/A 运行在无任何变更时“发现”胜利，从而确定真实 n。约 1.8k 会话中 23 个卡住的智能体被同一动作救出：“你需要建立反馈回路”。