花大价钱买一台性能旗舰，然后立刻亲手把它降速——这听起来像是在浪费钱。但创始人 Guilherme Campos 就这么做了：他买了一台 iPhone 17，然后马上给它套上层层限制，让它变得迟钝、笨拙、不那么"好用"。
这不是冲动消费后的后悔，而是他与 doomscrolling（无止境刷屏）长期斗争后得出的一个反直觉结论：对抗成瘾的最佳武器不是断网，而是摩擦。
常见方案的失败模式
Campos 试过几乎所有"正统"解决方案：
- 彻底断网——短期能戒断，但渴望本身没有被处理，一旦恢复网络，反弹更猛。
- App 拦截工具——屏蔽了入口，但心里知道"只要关掉拦截就能刷"，这种心理后门让拦截形同虚设。
- 纯意志力——在算法面前，人类意志力是可预测的稀缺资源，推送通知比你更懂你的弱点。
这些方案有一个共同缺陷：它们试图消除接触，而不是改变接触的质量。就像戒酒的人把家里所有酒扔掉，但没改变对酒精的渴望——下次路过便利店，三秒就破防。
Campos 的思路不同：不切断管道，而是让管道变窄、变慢、变涩。
摩擦力的心理学
为什么"慢"能对抗成瘾？核心机制是降低即时满足的剂量。
刷屏成瘾的循环是：打开 → 瞬间加载 → 新刺激 → 再打开。每一个环节都丝滑无阻，算法只需要 0.3 秒就能给你下一个 dopamine hit。如果你在"打开"和"新刺激"之间插入 3 秒的等待、一次额外的操作、一个丑陋的界面，循环就断了——不是物理断开，而是心理上"不值得了"。
这和公路设计的道理一样：直路开 120km/h，加几个弯道和减速带，自然就降到 40km/h。你不需要封路，只需要让路不那么好走。
Campos 的做法本质上就是在数字高速公路上装减速带。
实操：给 iPhone 装减速带
Campos 对 iPhone 17 做了什么？根据他的实验思路，可以提炼出一套可复用的"降速配置"：
1. 开启 Guided Access（引导访问）
这是 iOS 内置的功能，能把手机锁在单个 App 内，还能禁用触摸区域。Campos 用它来限制自己只能在特定 App 里操作，而且故意禁用那些容易跳转的区域。
设置路径：设置 → 辅助功能 → 引导访问。开启后，在任何 App 里连按三次侧边按钮即可激活。
2. 用 Shortcuts 自动化制造延迟
更硬核的做法是用 iOS Shortcuts 给"打开社交媒体"这件事加一层确认和等待：
快捷指令流程：
1. 接收到"打开 Instagram"的触发
2. 弹出确认框："你确定要刷吗？已经刷了 XX 分钟了"
3. 如果确认 → 等待 10 秒 → 再弹出一次确认
4. 第二次确认 → 打开 App
两次确认 + 10 秒等待，足够让冲动冷却。
3. 用 Screen Time 粗暴限速
不是温和的"提醒"，而是硬性上限：每天社交类 App 总共 15 分钟，到时间直接锁 App。关键是密码交给别人设，或者写在一个你需要走 5 分钟才能拿到的地方。
在开发环境里制造摩擦：一个可运行的 Python 实践
Campos 的思路不只适用于手机。如果你是开发者，整天泡在终端和浏览器里，同样可以给自己的工作环境装减速带。下面是一个 Python 脚本，实现"慢通知"——把即时推送变成延迟推送，强制打断 dopamine 循环：
#!/usr/bin/env python3
"""
slow_notify.py — 慢通知器：把即时消息变成延迟消息
用法：python slow_notify.py "刚收到一条 Slack 消息"
效果：不是立刻告诉你内容，而是先提醒"有消息"，等冷却期后才显示内容
"""
import sys
import time
import json
from pathlib import Path
COOLDOWN_SECONDS = 120 # 冷却期：2 分钟
STATE_FILE = Path.home() / ".slow_notify_queue.json"
def load_queue():
if STATE_FILE.exists():
return json.loads(STATE_FILE.read_text())
return []
def save_queue(queue):
STATE_FILE.write_text(json.dumps(queue, indent=2))
def enqueue(message):
queue = load_queue()
queue.append({
"message": message,
"enqueued_at": time.time(),
"deliver_at": time.time() + COOLDOWN_SECONDS
})
save_queue(queue)
print(f"⏳ 消息已排队，将在 {COOLDOWN_SECONDS} 秒后送达。先去做点别的。")
def deliver_ready():
queue = load_queue()
now = time.time()
ready = [item for item in queue if now >= item["deliver_at"]]
pending = [item for item in queue if now < item["deliver_at"]]
for item in ready:
wait = int(now - item["enqueued_at"])
print(f"📬 [{wait}s 后] {item['message']}")
save_queue(pending)
if pending:
next_at = min(item["deliver_at"] for item in pending)
remaining = int(next_at - now)
print(f"⏳ 还有 {len(pending)} 条消息等待，最近一条在 {remaining} 秒后送达")
if __name__ == "__main__":
if len(sys.argv) > 1:
enqueue(sys.argv[1])
else:
deliver_ready()
使用方式：
# 收到消息时，不看内容，只排队
python slow_notify.py "Slack: @你 的新消息"
# 过两分钟后，检查可送达的消息
python slow_notify.py
# 可以设一个 cron 每分钟自动检查
# crontab -e 加入：
# * * * * * /usr/bin/python3 ~/slow_notify.py
这个脚本的哲学和 Campos 一致：不阻断信息，但强制延迟满足。你知道有消息来了，但看不到内容——焦虑感被保留（你不会忘记去看），但冲动被冷却（两分钟后你往往已经不在刷屏状态了）。
给网络本身加减速带
如果你在 macOS 上工作，还可以用系统级命令给网络加物理摩擦——让加载变慢：
# macOS 网络限速（需要 sudo）
# 下载限速到 500Kbps（约 0.5Mbps），足够收邮件，但刷视频会卡到不想看
sudo dnctl pipe 1 bandwidth 500Kbit
sudo pfctl -e
sudo pfctl -f /etc/pf.conf
# 在 /etc/pf.conf 中加入：
# dummynet in on en0 all pipe 1
# dummynet out on en0 all pipe 1
# 恢复正常速度：
sudo dnctl flush
sudo pfctl -d
⚠️
dnctl和pfctl是 macOS 内核级网络控制工具，配置不当可能断网。建议先在测试环境验证，或用networkQuality命令确认限速生效。
500Kbps 下，文字工作几乎无感，但 Instagram 的图片加载要 3-5 秒，短视频基本没法看——这正是你想要的摩擦量。
减速带的边界与代价
这套方法不是没有代价：
- 效率损失是真实的。限速后，查资料、看地图、回紧急消息都会变慢。你需要区分"需要快的场景"和"需要慢的场景"，不能一刀切。
- 摩擦会磨损。人对任何障碍都有适应能力。两次确认用三个月后，你会肌肉记忆般地按"确认"，摩擦失效。需要定期更换摩擦形式。
- 社交压力。别人秒回，你两小时才回，关系会受影响。Campos 的做法是提前告知同事"我刻意降速了"，把预期对齐。
最关键的一点：减速不是目的，夺回注意力才是。如果你发现限速后只是换了个方式发呆（比如盯着墙看），说明问题不在手机速度，而在更深层的行为模式——这时候需要的是行为治疗，不是 dnctl。
一份自查清单
在动手降速之前，先回答这几个问题：
- 你刷屏最多的 3 个 App 是什么？ 先只对这三个加摩擦，别全盘降速。
- 哪些场景你必须快？ 导航、紧急通讯、支付——这些不能慢。分开配置。
- 你的摩擦谁来设？ 密码、配置权限交给别人，还是自己？自己设的话，至少把密码写在需要走动才能拿到的地方。
- 你打算多久换一次摩擦形式？ 设一个日历提醒，比如每月换一次 Shortcuts 流程或 Screen Time 规则。
- 降速后空出来的时间做什么？ 没有替代活动，降速只会制造无聊，无聊会把你推回刷屏。
Campos 的实验揭示了一个被忽视的事实：现代设备的"快"不是中性的——它是一种精心设计的成瘾机制。你花大价钱买来的性能，有一半在为算法服务，不在为你服务。把那部分性能降下来，不是浪费，而是夺回控制权的第一步。