小功能最容易被低估：代码量不大，却可能同时触及查询逻辑、权限边界、分页状态和用户界面。独立开发者要实现可回滚迭代，关键不是让 AI 一次生成完整功能，而是把变更拆成边界清晰、可验证、可撤销的最小单元。

先定义变更边界

以“订单列表增加状态筛选”为例，先写清目标与不做事项：支持既有状态筛选，刷新后保留条件，切换筛选时回到第一页，无结果显示现有空状态；不修改数据库结构、不更换分页方案、不重构无关模块。验收标准应覆盖默认行为、合法状态、非法参数、权限和原有分页。没有这些约束，就无法判断回滚后是否真正恢复了旧行为。

接着让 AI 只读分析项目，找出列表入口、查询逻辑、状态定义、权限校验和已有测试，并列出不确定事项。开发者必须打开关键文件自行确认，尤其要防止遗漏租户隔离、误判分页位置，或把前端显示状态当成真实数据状态。

把实现切成可撤销阶段

确认计划后，在独立分支或隔离工作区中实施，严格限制文件范围。建议先完成服务端参数校验和测试，再处理前端交互；每次修改后查看差异，检查是否出现无关文件、整文件格式化、权限绕过或不必要的依赖变更。变更量明显超出功能本身时，应暂停并重新评估，而不是继续让 AI 扩大范围。

提交也要保持语义独立，例如将查询逻辑、测试和界面交互分开。这样发生问题时，可以定位具体阶段并单独恢复，而不是撤销一份混杂多种修改的大提交。

发布前验证回滚条件

测试至少覆盖默认列表、每个合法状态、非法输入、无匹配结果、筛选后的分页、刷新恢复、权限边界和原有列表回归。AI 可以协助生成测试矩阵和审查差异，但不能替代人工判断，也不能把“测试没有失败”直接等同于功能正确。

发布前应明确恢复哪个提交、哪些文件可单独撤回、旧版本能否处理缺少新参数的请求，以及出现哪些现象立即回滚。若不涉及数据库结构，回滚通常是恢复代码版本后重新运行关键测试；若涉及数据迁移，则必须另行设计兼容和数据恢复路径。可回滚的本质，是让每次迭代都拥有清晰边界、可观察结果和明确退出路径。