好产品 = 操作少

今天一个小感悟：好产品的逻辑只有一个——少操作。

核心断言

上手成本 = 0，产品就赢了。

不是"易上手"，不是"友好"，不是"功能多"——这些都不是关键。关键是用户要做的操作步骤数量。

一个公式

产品好 = 用户的操作步骤 / 完成任务的次数 → 趋近 0

• 用户需要看教程 → 你输了
• 用户需要记命令 → 你输了
• 用户需要点 3 次菜单 → 你输了
• 用户打开就能用 → 你赢了

反例对比

❌ 难用的产品（操作多）

用户想：把图片发到群里
操作：
  1. 打开 app
  2. 找到"图片"
  3. 选"从相册选"
  4. 选"群组"
  5. 输文字
  6. 点"发送"
= 6 步

✅ 好用的产品（操作少）

用户想：把图片发到群里
操作：
  1. 打开 app 直接拖入图片
= 1 步

真正的好产品：用户根本感觉不到操作的存在。

三个检验标准

下次你做完一个东西，问自己 3 个问题：

问题	是 →
新用户能"零说明"直接用吗？	不是 → 重做
完成核心任务需要几步？	> 3 → 合并步骤
有"必须先学"的知识点吗？	有 → 改成"边用边懂"

第 3 条最关键——如果用户必须先学才能用，那是设计问题不是用户问题。

真实案例：facet 的 --split 子命令

我之前设计 facet 的 pnpm facet split 时，本来想加 --target --max-chars --min-chars 一堆参数。

写完才意识到：没人会去查文档调参数。

最终只留了两个参数：

• --input（输入文件，默认 content/example.md）
• --output（输出文件，默认自动算）

默认值就是 AI 算好的最佳值。用户不传任何参数就跑得起来。

• 上手成本：0 命令记忆
• 操作步骤：1 个命令 + 1 个文件名
• 这才是好产品

真实案例：加密交付

之前的 facet 加加密交付时，我想做：

1. 先打开控制台
2. 设置 KV namespace
3. 设置 secret
4. 写 wrangler.toml
5. 部署
6. 客户端输密码

这是 5 步，对用户来说太累。

后来改成：

• 管理员：npx wrangler pages secret put DEFAULT_PASSWORD

• 用户：输 1 个密码 → 直接看

• 管理员操作：1 个命令（set secret）

• 用户操作：1 个密码输入框

两种角色，操作都被压到 1 步。这才是产品设计。

真实案例：echo vs print

echo "hello" vs System.out.println("hello")：

• shell：echo 1 步
• Java：5+ 字符 + 引号 + 类加载

Unix 哲学赢在"少操作"——不是赢在"功能多"。

反模式：好上手 ≠ 好产品

常见误解：

“我们做了 onboarding 教程 / 引导页 / 5 分钟上手指南”

这是把"难用"包装成"看起来好上手"。真正的好产品根本不需要这些。

反模式	好产品
引导页	默认配置就是最优
帮助文档	操作本身不需要解释
教程视频	用户路径短到不需要看视频
"新手模式"切换	只有一种模式，简单到不用切换

你的问题不是"功能不够"，是"操作太多"

很多团队遇到"用户不用我们的产品"，第一反应是：加功能。

正确答案可能是：删功能。

反模式思路	好产品思路
用户不会用 → 加教程	用户不会用 → 删步骤
用户找不到入口 → 加菜单	用户找不到入口 → 只有一个入口
用户配置不来 → 加默认	用户配置不来 → 别让用户配

怎么用这个感悟

下次做任何东西之前，先问自己：

“用户完成这件事，需要几次点击/输入？”

次数	评价
0	完美（用户没意识到在用产品）
1	好
2	还行
3	需要仔细设计
≥ 4	重做

目标永远是 ≤ 1。

---

一句话

好产品的逻辑只有一个：操作少。

删步骤比加功能重要。用户没意识到在用产品 = 完美体验。

—— 今天一个小感悟，记在这里。