交付：用测试证明系统可靠

植物照护系统能亮灯、能开泵，只说明它「动了」，不说明它按需求可靠工作。交付前要把需求逐条变成测试，让别人也能重复验证。

五类测试

1. 正常场景：土壤从湿到干，系统在规定条件下提醒并小步浇水。
2. 边界场景：读数在开启与关闭阈值附近波动，水泵不应频繁开关。
3. 延迟场景：浇水后读数缓慢变化，系统会等待而不是连续猛浇。
4. 故障场景：拔掉探头、倒空水箱、断开网络，系统进入安全状态并报警。
5. 恢复场景：修好接线或补水后，系统经过确认恢复，而不是悄悄继续旧任务。

每个测试都要可判断

写清初始条件、操作步骤、预期结果、实际结果和证据。不要写「测试一下传感器」，要写「将探头断开，三次采样内应显示故障，水泵保持关闭，日志记录时间与原因」。

用需求追踪测试

最初写的每条要求旁边标上对应测试编号。若某项没有测试，就没有证据证明做到了；若某个测试对应不了任何需求，可能是在测无关功能。需求和测试一一照应，形成闭环。

记录限制而不是假装完美

例如系统只适用于这类土壤，探头每月要校准，断电后需要人工确认，网络功能只用于查看而不控制水泵。清楚写出边界，比藏起限制更专业。

章末交付物

提交系统框图、传感器校准表、阈值与回差、状态图、故障安全表、一天数据曲线和至少十条测试记录。最后用三句话回答：系统知道什么、不知道什么、最终谁负责。

你完成的不只是一个自动花盆，而是一套从测量到决策、从执行到验证的工程方法。它同样适用于温控箱、机器人、智能家居和科研仪器。