firebase-ios-sdk 的 Autonomous TDD Loop：多智能体驱动的严格 TDD 工作流实践

firebase-ios-sdk 的 Autonomous TDD Loop多智能体驱动的严格 TDD 工作流实践【免费下载链接】firebase-ios-sdkFirebase SDK for Apple App Development项目地址: https://gitcode.com/GitHub_Trending/fi/firebase-ios-sdk本指南基于 firebase-ios-sdk 仓库中的 .agents/skills/autonomous-tdd-loop/SKILL.md 技能文档系统讲解如何以多 Agent 协作方式在大型 iOS 工程中编排一套严格的红绿循环Red-Green-Refactor开发流程。读者将掌握从环境检查、编写失败测试、双阶段验证到代码评审与知识沉淀的完整闭环并理解其在 Firebase SDK 这类大型仓库中落地时的关键约束包括 Swift 并发测试陷阱、验证范围裁剪与记忆迁移机制。一、技能定位与适用前提Autonomous TDD Loop 是一个面向 AI 编码 Agent 的编排型技能skill其核心思想是主 Agent 不直接“写完代码再验证”而是把“写测试”“验证失败”“实现修复”“验证通过”“回归确认”“定性评审”拆分为多个阶段分派给不同角色的子 Agentsubagent执行从而在严格的测试纪律与代码质量门槛之间建立可重复的机械化流程。1.1 前置要求技能运行的前提是仓库根目录存在一个agents.md文件用于定义两个关键角色与测试命令Verifier验证者只负责构建与运行测试返回二进制的通过/失败结果Reviewer评审者负责对改动进行主观、严格的代码评审。在 firebase-ios-sdk 中这一约定真实落地于根目录的 agents.md角色定义见 agents.md 的 “AI Subagent Personas” 一节其中 “Objective Code Verifier” 明确“严格运行构建与测试套件、报告二进制 pass/fail 结果、除非明确指示否则不修复代码”“Rigorous Code Reviewer” 则被要求聚焦 Swift 6 严格并发、内存管理如 retain cycle、API 设计依据docs/firebase-api-guidelines.md与整体架构一致性测试命令相关约定包括SPM 流程使用./scripts/setup_spm_tests.sh开启测试 scheme 后再跑xcodebuildCocoaPods 流程使用pod gen Podspec --local-sources./生成 workspace格式检查使用./scripts/style.sh。若仓库中不存在agents.md、AGENTS.md或REVIEW_GUIDELINES.md则工作流必须暂停显式询问用户提供构建与测试命令不得猜测环境。从仓库结构看本仓库除根级 agents.md 外还提供了 .agents/REVIEW_GUIDELINES.md 作为评审标准两个文件相互配合是 TDD Loop 得以运转的“规则库”。1.2 配套技能同一.agents/skills/目录下还有两个协作技能与 TDD Loop 构成完整工具链.agents/skills/style_and_commit/SKILL.md提交前统一格式化与 Conventional Commits 规范.agents/skills/ios-simulator-test-recording/SKILL.md在 iOS 模拟器上运行xcodebuild测试并录制演示视频。二、工作流全景七个阶段逐层拆解技能要求按照以下阶段严格按序执行任何阶段不可跳跃阶段名称执行者核心目标Phase 0环境检查主 Agent确认文档与测试命令来源Phase 1适用性评估与测试编写Worker编写一条可复现的失败测试Phase 2首次健全性检查Verifier证明测试确实失败红Phase 3实现修复Worker应用最小修复绿Phase 4二次健全性检查Verifier证明修复通过校验绿Phase 5严格 TDD 回退循环Worker Verifier回退修复后测试必须再次失败Phase 6定性评审Reviewer主观代码质量评审与迭代Phase 7关键学习与收尾主 Agent记忆迁移、CHANGELOG、PR三、Phase 0环境检查在调用任何子 Agent 之前主 Agent 必须先确认环境步骤为检查文档查看仓库根目录是否存在AGENTS.md、agents.md或REVIEW_GUIDELINES.md回退到用户若三者都不存在立即暂停工作并显式询问用户该项目的构建与测试命令使用命令后续阶段给 Verifier 的指令必须使用用户提供的命令而非自行猜测。在 firebase-ios-sdk 中Phase 0 可直接读取根级 agents.md其 “Setup Commands” 与 “Running Tests” 两节给出了可复制的真实命令例如# SPM 流程先开启测试 scheme ./scripts/setup_spm_tests.sh # CocoaPods 流程为单个模块生成开发 workspace pod gen FirebaseStorage.podspec --local-sources./ --auto-open --platformsios # 格式检查 ./scripts/style.sh FirebaseStorage/Sources/四、Phase 1适用性评估与失败测试编写Worker这是整个 TDD 循环的质量源头包含两个动作4.1 评估适用性与验证范围先判断用户目标是否适用单元/回归测试若不适用的测试则记录原因与验证范围直接跳到 Phase 4。同时评估验证范围validation scope例如一个纯空白字符修复只需快速跑./scripts/check_whitespace.sh而完整的功能改动才需要整套xcodebuild测试。范围评估直接决定 Phase 4 中 Verifier 执行命令的裁剪粒度避免在每个小改动上都跑全量测试套件。4.2 编写失败测试不应用修复为问题编写一条必然失败的测试且在 Phase 3 之前不得应用修复。技能文档特别强调了 Swift 并发场景的一条“铁律”关键规则Swift Concurrency / AsyncStream / URLSession Cancellation当测试要验证AsyncStream在终止时是否正确清理资源、或是否取消了底层网络请求时不要 mock 一个“自然结束”的延迟任务。原因有二URLSession内部的缓冲会掩盖超时而自然结束的 mock 操作会触发系统级清理从而掩盖“缺少显式取消”这一缺陷。正确写法是将流的消费包装在一个消费者Task中短暂yield或Task.sleep例如 100ms等待初始化完成显式对消费者Task调用.cancel()断言底层被 mock 的资源确实收到了取消信号例如调用了stopLoading()。这条规则在仓库源码中有直接可对照的实现范式。以 FirebaseAuth/Sources/Swift/Auth/AuthAsync.swift 为例AuthStateChangesSequence.Iterator用AsyncStreamUser?包装状态监听并在continuation.onTermination中移除监听器stream AsyncStreamUser? { continuation in let handle auth.addStateDidChangeListener { _, user in continuation.yield(user) } continuation.onTermination { Sendable _ in auth.removeStateDidChangeListener(handle) } }这正是 Phase 1 规则所指向的“正确资源清理”形态——取消发生在onTermination闭包内不依赖任何自然结束的时序。在 .agents/REVIEW_GUIDELINES.md 中也有对应评审项“严格验证非结构化Task或AsyncStream是否在onTermination闭包中正确处理取消以防资源泄漏”。因此为这类逻辑编写测试时必须模拟“迭代中途被取消”而非“自然消费完毕”。五、Phase 2 与 Phase 4双阶段健全性检查Verifier5.1 Phase 2证明测试失败红主 Agent 通过invoke_subagent调起 Verifier角色为 “Objective Code Verifier”并给出明确指令“阅读本仓库根目录的agents.md或使用用户提供的测试命令找到测试执行命令运行测试。你唯一的目标是验证我刚刚添加的这条测试当前确实失败。不要尝试修复它。基于此返回二进制的通过/失败结果。”随后等待 Verifier 响应若测试没有失败则必须修改测试直至其失败。这是“红”阶段的可证伪性保障——失败的测试才是修复目标的唯一锚点。5.2 Phase 4证明修复通过绿Phase 3 应用修复后向同一个Verifier 子 Agent 发消息指令要点是使用agents.md或用户提供的命令运行测试/检查按 Phase 1 确定的验证范围做裁剪优化——例如纯空白修复只跑样式脚本而不跑全量测试套件验证所需检查现在通过。若 Verifier 报告失败则回到实现迭代重复本阶段直至通过。六、Phase 3 与 Phase 5实现修复与严格回退验证6.1 Phase 3实现应用修复前先阅读 .agents/REVIEW_GUIDELINES.md若存在确保实现符合仓库特定的编码规范。该文件的核心标准包括Swift-First不引入新的 Objective-C 公开 API新异步 API 一律使用async/awaitTask 取消严格验证非结构化Task/AsyncStream的取消处理严格类型公开 Swift API 拒绝Any、AnyObject与NS前缀类型错误建模新失败状态必须加入模块专属的 Error enum可扩展性可能扩展的值集合优先用带静态工厂方法的struct而非enum避免新增 case 造成破坏性变更测试与文档修复 bug 必须附带回归测试新公开 API 必须用 Swift-flavored Markdown 文档化。6.2 Phase 5严格 TDD 回退循环若 Phase 1 添加了测试则本阶段不可跳过其目的是证明测试与实现的因果绑定临时注释掉或回退修复的核心逻辑通知 Verifier“我已临时回退修复请再次运行测试确认完全相同的那些测试再次失败”Verifier 确认失败后取消注释/重新应用修复。这一步杜绝了“测试本来就一直通过”或“测试与其他代码耦合”的假阳性是 TDD 纪律在自动化工作流中的最后一道闸门。七、Phase 6定性评审Reviewer主 Agent 再次通过invoke_subagent调起 Reviewer角色为 “Rigorous Code Reviewer”指令要点“阅读根目录agents.md与本仓库的REVIEW_GUIDELINES.md若存在。对我的改动进行严格、主观的代码评审聚焦并发、内存管理、API 设计标记所有问题。”评审迭代直到 Reviewer 依据标准rubric认可改动为止。在 firebase-ios-sdk 语境下这意味着要对照 .agents/REVIEW_GUIDELINES.md 与根级 agents.md 的 “API Surface” 章节逐条核查例如新 API 的Sendable符合性、available平台标注、case-less enum 常量组织以及docs/firebase-api-guidelines.md中定义的公开 API 设计原则。八、Phase 7关键学习、记忆迁移与收尾循环的最后阶段负责把单次开发中获得的经验沉淀为长期资产系统性记忆若遇到系统性摩擦如模拟器偶发不稳定、反复出现的构建怪癖、误导性的旧文档将其追加到工作区根目录的.agents/MEMORY.md文件知识迁移若该摩擦是仓库的永久性特征而非本地瞬时问题应显式询问用户“我在本地.agents/MEMORY.md中记录了 [主题]。我建议将其永久加入仓库的agents.md让所有贡献者受益需要我这样做吗”——这一步把个人经验转化为团队知识更新 CHANGELOG在相关产品的CHANGELOG.md顶部新建# Unreleased章节并写入改动描述。根级 agents.md 的 “Best Practices” 一节也强调“任何 PR 的 changelog 条目都必须放在新的顶层# Unreleased节中若该节不存在则须先创建”二者口径一致PR 与收尾若用户要求创建 PR使用ghCLI 创建并等待 CI/人工反馈否则通知用户循环已完成。九、落地建议与注意事项综合技能文档与仓库配套文件在 firebase-ios-sdk 中运行 Autonomous TDD Loop 时有几点实践提示验证范围先行改动越局部验证越轻。样式类改动可只跑./scripts/style.sh避免在大型 SDK 上浪费整轮构建时间根级 agents.md 提供的FIREBASECI_USE_LATEST_GOOGLEAPPMEASUREMENT、FIREBASE_SOURCE_FIRESTORE等环境变量也可用于处理依赖版本不匹配的测试场景。并发测试务必显式取消凡涉及AsyncStream、URLSession或非结构化Task的测试遵循 Phase 1 的取消规则而不是依赖 “等它自然结束”对照 FirebaseAuth/Sources/Swift/Auth/AuthAsync.swift 的onTermination模式检查实现对照 .agents/REVIEW_GUIDELINES.md 检查评审口径。评审标准是活文档.agents/REVIEW_GUIDELINES.md 末尾注明“将其视为活文档团队发现新的摩擦点即可补充新标准”意味着 TDD Loop 的评审质量会随仓库演进持续强化。记忆要分层瞬时问题记入本地.agents/MEMORY.md永久特征才迁移到仓库级agents.md避免噪音污染所有贡献者共享的上下文。【免费下载链接】firebase-ios-sdkFirebase SDK for Apple App Development项目地址: https://gitcode.com/GitHub_Trending/fi/firebase-ios-sdk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考