修复混乱应用：先定义状态，再向智能体下指令

Devin Chasanoff 正在按照详细实施计划构建一款私人教练应用。训练中的界面本应方便用户在运动时使用，但目前的行为令人困惑。

完成一组训练后，应用会打开休息计时器，却没有清楚推进训练进度。两个控件可以导航到同一位置，额外的未来组信息让页面拥挤，而超级组还需要在不同运动之间交替。他希望这些交互作为一个整体协调工作。

逐个修复孤立问题可能产生互相冲突的行为，让旧问题再次出现。因此，他把抱怨清单改写成系统规格，描述展示、组件、状态、显示条件和用户操作。

首先，他列出标签、布局等视觉改动，再确定组成页面的各个部分。这些名称有助于描述界面，也能帮助智能体定位改动；它们不一定都需要成为独立代码组件。

接下来，他区分页面级和运动级状态。页面记录当前组和是否处于休息模式，并可推导后续组、当前组是否为第一组或最后一组；单项运动则记录某一组是否完成。

他定义了休息模式和训练期间各应显示哪些元素。最后一组需要特殊状态：完成后已经没有当前组，但训练尚未记录。列出这些情况可以明确预期的状态转换。

对于当前组卡片，未完成时数值应当可以编辑，完成后则显示为文本。按钮应根据状态从完成组变为编辑组。他也为后续组预览和导航控件指定了规则。

操作规则将用户点击与结果状态连接起来。完成普通组时，应用标记其完成并进入休息模式，但不会立即改变当前组；休息结束或被跳过后才前进。最后一组则走不同路径。

为了防止后续改动破坏这些行为，Chasanoff 将规格贴进 Gemini，要求生成测试用例。他既希望检查显示与状态，也希望测试从操作到界面结果的小型用户流程。

他决定留在已有的 Google Antigravity 会话，而不是开始新会话。这样智能体能利用之前的实现上下文，将他提出的变量与实际代码对应起来，然后继续整体实施计划。

他要求智能体暂停计划，实现规格并覆盖生成的测试。他说 Gemini 工作了约七分钟，生成的测试全部通过；随后他亲自检查应用。

修改后的休息界面显示计时器和接下来的训练。已完成的组可以提供此前重量和次数的参考。如果用户尚未完成当前组就按下一组，菜单会提供标记完成、跳过、预览下一组或返回等选择。

他逐步检查最后几组：随着剩余组数减少，后续预览也会缩短；完成最后一组后会出现完成卡片。他确认并保存训练，并认为先定义系统有助于一起解决相互关联的行为。