新增可观察能力
可观察功能需要在公共接口上定义具体行为，说明调用方应该能够完成什么。先为该行为编写失败测试，再实施使其通过的最小修改，通过这样的增量推进功能。测试关注对外结果，避免只验证某种私有实现方式。
TDD by Matt Pocock
使用 Matt Pocock 的 TDD，分步实现并验证新功能或缺陷修复。先约定需要测试的公开接口，再编写一条会失败的行为测试，补足使其通过的最小实现，然后根据反馈选择下一步工作。
用失败测试逐项实现行为
明确可以观察的行为和适合测试的公共接口，将请求限定到一条失败测试及其最小实现。无关整理和针对私有细节的断言不混入这个增量，让修改与需要验证的行为对应。
带入 Floatboat 的请求
请求可预览和复制，不会从此处自动发送。
参考来源: TDD https://github.com/mattpocock/skills/blob/main/skills/engineering/tdd/SKILL.md 先阅读原始说明并核对当前环境与依赖。需要安装或连接新工具时，先提出方案。 我的任务: 使用 Matt Pocock 的 TDD 完成结账折扣修改，先提出公开测试边界，再用失败测试逐项实现行为。 期望交付: 逐项对应验收行为的失败测试、最小实现与验证结果。
关于 TDD
TDD 是 Matt Pocock 面向测试先行实现发布的参考 Skill，强调通过公开接口验证行为。它要求用户与 Agent 在写测试前先约定测试边界，使工作聚焦于有意义的能力，而不是私有实现细节。每轮先写一条失败测试，再完成使其通过的最小实现，并依据反馈选择下一项小任务。当前原文明确把重构放在审查阶段，而非混入红灯到绿灯的实现循环。集合提供测试与模拟参考资料；接口本身尚未确定时，还需参考 codebase-design 的共同术语。使用仍依赖项目已有测试环境，以及可独立判断的预期行为。
TDD Skill的使用场景
公共接口上的失败测试，才能保护调用者真正依赖的行为。TDD 可以围绕功能增量、原始缺陷和关键集成建立反馈，让最小实现有明确目标，避免过度绑定私有实现细节。
保护缺陷修复
缺陷修复需要使用触发输入重现原始问题的回归测试。选择真正能够观察到错误外部结果的测试入口，验证测试在修复前失败、修复后通过。针对无关内部细节的断言，不能代替对这次故障的保护。
覆盖关键集成
关键集成测试需要跨越有实际意义的边界，并使用已知的预期结果。明确哪些依赖真实运行、哪些由替身代替，再核对组合后的行为。测试应能够发现边界协作失败，而不是只确认各个独立组件曾经被调用。
重组代码前保护已有行为
结构调整不应改变调用方已经依赖的行为。先识别需要保护的公共结果，并在独立重构开始前建立有意义的测试。修改后沿用相同检查，断言继续关注可观察结果，避免仅因内部代码移动，就让原本正确的实现被测试误判。
如何用 TDD 实现行为
每个 TDD 增量都需要对应一项可观察行为。约定公共测试边界后，让最小实现通过一条失败测试，再单独评估更广泛的整理，避免同时改变多个问题而失去可靠反馈。
约定测试边界
提供行为要求与测试命令，确认重要公开接口及每条测试能捕获的问题。
完成一轮红灯到绿灯
编写因目标问题而失败的测试，再仅实现使其通过的必要行为。
继续迭代并另行审查
依据上一轮证据选择下一项小任务，在目标行为可用后另行审查重构。
探索更多 Agent Skills
查看其他 Skill 指南，并在使用前核对原始来源。
TDD 常见问题
安装这个 TDD Skill 会获得什么？
它为 Agent 添加指令与参考资料，不会自动安装测试运行器或配置项目依赖。
为什么写测试前先约定边界？
边界指通过哪个公开接口观察行为。预先约定有助于聚焦关键路径，避免测试依赖私有细节。
是否应该先写完所有测试？
原文主张纵向小步：一条测试跟随一份实现，再随理解深入继续。批量设想测试可能过早固定错误结构。
最新版要求每轮都重构吗？
不要求。当前原文将重构放在审查阶段，而非红灯到绿灯的实现循环。较早摘要可能沿用较宽泛的三段式说法。
什么样的预期结果可信？
依据独立于实现的规范、推导示例或已知正确值。断言中重写同一算法可能掩盖相同缺陷。
什么时候需要 codebase-design？
公开接口或模块深度尚未确定时可参考它。集合将其作为共同设计术语，而非额外访谈流程。
它能保证测试覆盖完整吗？
不能。它指导测试选择与实现，仍需根据项目风险选择行为并验证测试有效性。