别把列表操作藏进详情页：用 AI + swipeActions 给 iOS 列表加左滑按钮 (2026)

列表页有个常见坏味道：用户明明只想把一条消息标成已读、收藏一个订单、删掉一条草稿，却被迫点进详情页，再找右上角菜单。页面看起来干净了，操作却绕远了。

今天这一技是让 AI 帮你给 SwiftUI 列表行加 swipeActions。PM 不需要先学手势系统，只要说清楚「哪一行、哪几个动作、哪些动作不能误触」，就能把常用操作放回列表里。

这招解决什么问题

swipeActions 的作用很窄，也正因为窄，特别适合 PM 独立改小体验。Apple 对这个 API 的描述是：给列表中的一行增加自定义滑动操作。1

适合放进去的，是「不必打开详情就能判断」的行内动作：

邮件、通知、待办：标为已读、归档、稍后处理。
商品、内容、联系人：收藏、取消收藏、加入分组。
草稿、记录、临时数据：删除，但要控制误触。

不适合放进去的，是需要用户阅读完整信息才能决定的动作，比如退款审批、复杂编辑、跨页面设置。左滑按钮不是抽屉，塞太多只会让用户更难点准。

技巧原理：把「行内决策」变成「行内按钮」

你可以把它理解成一句产品规则：用户看着这一行就能做判断的动作，才值得出现在这一行旁边。

在 SwiftUI 里，swipeActions() 可以给一行加一个或多个按钮，也可以指定按钮从左侧还是右侧滑出；Hacking with Swift 的示例还说明，滑得足够远时，第一个按钮默认会被直接触发。2

这正是 PM 要特别盯住的地方：收藏、标已读这类可撤销动作，可以允许全滑触发；删除、取消报名、清空记录这类难恢复动作，最好让 AI 写成 allowsFullSwipe: false。Peter Friese 的 SwiftUI 列表文章也提到，全滑默认会触发某个方向上的第一个动作，可以通过 allowsFullSwipe 关掉。3

还有一个小细节：不要只把删除按钮涂红。Apple 把 ButtonRole.destructive 定义为表示破坏性按钮的角色；Hacking with Swift 也建议真正的破坏性按钮用 Button(role: .destructive)，而不是只设置红色。4 2

怎么让 AI 帮你改

先挑一个真实列表页，不要一上来改全 App。订单列表、草稿箱、消息列表、收藏列表都可以。然后按下面四步给 AI 下指令。

1. 先写「动作表」，别先写代码

把每个动作写成这样：

行内动作	放哪边	是否允许全滑	PM 要验收什么
收藏 / 取消收藏	leading	可以	滑出后图标和状态能互相切换
标为已读	leading	可以	点完后这一行视觉状态变化
删除草稿	trailing	不可以	不会一滑到底就删掉，最好有确认或撤销

这张表比一句「给列表加左滑删除」有用得多。AI 看到的是产品意图，不只是一个技术词。

2. 把这段直接丢给 AI 编码工具

请只修改这个 SwiftUI 列表的行视图，为每一行增加 swipeActions。
leading 方向加「收藏 / 取消收藏」，状态取决于当前 item 是否已收藏。
trailing 方向加「删除」，使用 Button(role: .destructive)。
删除动作设置 allowsFullSwipe: false，避免用户一滑到底就误删。
每个按钮都用 Label，文字要能被 VoiceOver 读出来。
不要重写整个页面结构；如果缺少 toggleFavorite 或 deleteItem 方法，先用最小函数占位，并在代码旁标注我需要补真实数据逻辑的位置。

这里的关键句是「只修改行视图」。Peter Friese 的文章提醒，swipeActions 应该加在代表行的视图上；如果加到 List 或 ForEach 上，修饰符可能不会按预期生效。3

3. 让 AI 再做一次「误触审查」

第一轮能跑起来，不代表体验对。继续问 AI：

请检查这组 swipeActions 有没有误触风险。重点看：破坏性动作是否排在第一个、是否允许全滑、是否缺少撤销或确认、按钮数量是否太多、小屏上是否难点。

按钮数量要克制。Peter Friese 提到，虽然一侧似乎可以加很多按钮，但手机横向空间有限；三到四个动作已经是比较理性的上限，再多会难点。3 对 PM 来说，更稳的规则是：第一版每侧最多放两个。

4. 用模拟器验收，不要只看代码

跑起来之后，按这几件事验收：

轻轻滑：按钮能露出来，行内容没有被挤坏。
滑到底：可撤销动作能触发；删除这类动作不能被一滑到底直接触发。
点按钮：行状态立刻变化，比如已读变浅、收藏图标切换、草稿消失。
开大字号：按钮仍然能点，行高没有乱跳。
开 VoiceOver：按钮读出来的是「收藏」「删除草稿」这类明确动作，而不是只读一个图标名。Hacking with Swift 的示例说明，SwiftUI 在滑动按钮里可能只显示图标，但 Label 的文字仍会被 VoiceOver 读出。2

PM 最容易踩的三个坑

坑 1：把所有操作都塞进左滑

如果一个列表行需要五六个操作，问题通常不在 swipeActions，而在信息架构。先问一句：哪些是高频行内动作？哪些应该留在详情页或更多菜单里？

第一版只放一个主动作和一个危险动作就够了。比如「收藏」放左侧，「删除」放右侧。Create with Swift 的示例也展示了可以把动作放在 leading 或 trailing 不同方向，并可以在一行上组合多个动作。5

坑 2：只看颜色，不看语义

红色能提醒用户，但系统真正能理解的是按钮角色。删除按钮该用 role: .destructive，这样 SwiftUI 才能按破坏性动作处理它的展示。4

如果你的 AI 只写了 .tint(.red)，让它补上角色。

坑 3：把隐藏操作当成唯一入口

左滑是快捷入口，不是新手教程。第一次打开列表的用户未必知道能滑。

如果某个动作是核心路径，比如「提交审核」「继续付款」，别只藏在左滑里。可以保留一个可见按钮，左滑只给熟练用户提速。

今天就做这个最小练习

选一个你正在做的列表页，只加一个动作：收藏、标已读、归档，三选一。先别碰删除。

把行视图发给 AI，让它加 swipeActions，再用模拟器验收「轻滑出现、点完变状态、大字号不乱、VoiceOver 能读」。这四项过了，再考虑加第二个按钮。

这招的价值不在于少写几行代码，而是让 PM 能把「常用动作离用户更近」这件事直接落到 iOS 界面上。

别把列表操作藏进详情页：用 AI + swipeActions 给 iOS 列表加左滑按钮