11. 上线不等于完成：用户反馈才是下一轮开始

从这里开始 ——

2026 年 5 月初 · 上线那一刻。一个不懂代码的"追风少年" · 看着自己的网站第一次出现在公网上 ——

页面终于能打开了。手机也能看了。几个关键页面都是 200。AI 报告里全是 PASS。

他高兴了 30 分钟。

然后他打开自己手机 · 点开网站 · 走完一个新用户路径 —— 他在第 3 步就卡住了。

这一刻他第一次明白 · 上线只是把问题交给了真实世界。

本篇一句话

这一篇写的是 —— 上线只是把网站从自己的电脑里 · 放到真实世界里。真实世界比本地复杂得多。真正的工作不是"上线" · 是从"我觉得用户需要什么" · 进入"用户真实行为告诉我什么"。反馈是候选 · 不是直接修改指令。未完成事项不是丢脸 · 是项目的导航。

结构图 · 上线后的反馈闭环（非监控版本）

这张图说明 —— 上线后不是让 AI 自动改网站 · 是让用户行为进入候选队列 · 经过人工审核和验证后 · 再进入下一轮小批次改进。每一步都要保留中断权 · 没有任何环节是"无人值守"。

1. 上线那一刻 · 最容易误判的 30 分钟

网站上线那一刻 · 人很容易高兴。

• 页面终于能打开了。
• 手机也能看了。
• 按钮不乱了。
• 几个关键页面都是 200。
• AI 报告里全是 PASS。

这个时候最容易产生一个错觉——

终于做完了。

但我后来越来越清楚 —— 上线不是完成。

上线只是把网站从自己的电脑里 · 放到真实世界里。真实世界比本地环境复杂得多。

• 用户不会按我的想象走。
• 用户不会读我想让他读的段落。
• 用户不会理解我工作台里的状态词。
• 用户可能点了一个按钮就走。
• 用户可能在手机上看到某个表格挤成一团。
• 用户可能根本不知道下一步该干什么。

这些问题 · 本地检查不一定能暴露。只有用户真正接触以后 · 才会出现。

所以"上线了" 不是这本书的结尾 · 是另一本书的开头。

2. 网站活着 ≠ 产品成立

上一章（CH10）我写过 —— 线上 smoke 通过只能说明网站"活着"。

但产品成立 · 需要更多证据 ——

• 用户有没有进入关键页面？
• 用户有没有用到核心功能（翻译 · 决策助手 · ranking 下载）？
• 用户有没有填写反馈？
• 用户有没有回来第二次？
• 用户有没有愿意付费？

这些问题比"页面能不能打开"更难 · 但它们才是真正的产品问题。

我以前容易把"建设"当成主任务。后来发现 · "建设"只是第一段。

真正长期的主任务是 ——

用户问题
  → 网站响应
  → 用户反馈
  → 内容 / 功能改进
  → 再验证

如果没有这条链 · 网站就会变成一个静态展板。

哪怕它用了 AI · 也只是一个会动的展板====。

会动的展板比静态的展板更危险 —— 静态展板用户会自己离开 · 会动的展板会让用户误以为"它在回应我"。

3. 反馈不是"用户喜欢吗" · 是 9 个具体问题

很多人说用户反馈 · 常常只问一句 —— "用户喜欢吗？"

这个问题太粗。

真正有用的反馈 · 要拆成 9 个具体问题：

1. 用户从哪个页面进来？
2. 他点了哪个入口？
3. 他在哪一步停住？
4. 他下载了什么？
5. 他复制了什么？
6. 他追问了什么？
7. 他有没有触发错误？
8. 他有没有找人工？
9. 他有没有留下建议？

这 9 个每一个都比"喜欢吗"更具体。每一个都能映射到一个候选任务。

但也有边界——

不希望网站为了"感知力"就什么都收集。尤其不能收集 ——

个人隐私
原始聊天内容
上传文件原文
付款信息
敏感身份信息
未经同意的行为轨迹

这些一律不收。不是"以后再考虑" · 是"从第一天就不收"。

4. 感知不是窥探 · 隐私边界写在前面

感知系统和监控系统 · 技术上很接近 · 但伦理位置完全相反。

• 感知：帮助网站知道自己哪里没做好。
• 监控：帮助网站知道用户是谁、在做什么。

我们做前者 · 不做后者。

边界怎么落地？metadata-first · hash-only——

• 只看聚合·不看个人。
• 只看必要统计·不看用户原始输入。
• 只看 hash·不看明文 query。
• 只看模块级需求·不看私人内容。
• 只生成候选·不自动发布。

这五条不是规则 · 是信任基石==。失守一条 · 网站从"工具"变成"窥探者"==。

而窥探者 失去信任的速度 · 比无用 失去信任的速度快 100 倍。

感知系统第一版必须克制——

页面访问聚合（哪个路由有人看）
模块兴趣聚合（哪个模块有人点）
反馈步骤完成情况（用户在哪一步走完 / 卡住）
下载兴趣（哪类资料被下载）
内容缺口候选（哪些内容应该补 · 候选）
人工边界提醒（哪些事必须人工处理）

这些字段看起来像工程术语 · 但本质都很朴素——

它们只回答"网站哪里没做好" · 不回答"用户是谁"。

5. 候选不是指令 · 反馈如何变成下一轮任务

我现在更喜欢把反馈看成一种候选任务。

不是用户一说 · 网站马上改。

也不是 AI 一分析 · 马上发布。

正确流程是 ——

用户信号
  → 候选问题
  → 来源 / 证据确认
  → 风险边界
  → 人工审核
  → 小批次修改
  → 本地验证
  → 上线前检查（CH10）
  → 继续观察

举三个例子 ——

• ranking 图有人下载多 → 用户可能需要"先看什么"的帮助 → 但不等于马上发布 100 张 ranking。它只说明这个方向值得进入候选队列。
• 用户在反馈页卡住 → 问卷流程可能有摩擦 → 但不等于马上重写整个反馈系统。可能只是某个按钮、某句话、某个步骤不清楚。
• 用户问决策助手类问题多 → 商务文书有需求 → 但不等于立即开通收费 AI 接口。它需要隐私、成本、人工边界和质量评估。

反馈不是直接修改指令。反馈是下一轮判断的输入。

这是 CH07 默认 A 的硬边界 在 post-launch 的延伸 —— 发布是硬边界 · 内容改动是硬边界 · 哪怕用户的反馈也不能跨过。

6. 未完成事项是项目的导航

上线以后 · 还有一个问题特别重要 —— 未完成事项不能消失。

项目越长 · 越容易发生这种情况——

• 某个功能做了一半。
• 某个接口还没生产开放。
• 某个支付流程还没激活。
• 某个 SEO 问题还没处理。
• 某个外部数据接口授权还在边界后面。
• 某个内容候选还没人工审核。

如果这些只留在聊天记录里 · 换一个对话框就没了。

如果只留在某个 AI 的回答里 · 另一个 AI 不知道。

所以它们必须进入 ledger / TODO / site index / evidence index。

未完成事项不是丢脸。未完成事项是项目的导航。

它告诉下一个 AI、下一个工作日、下一个版本 ——

不要从零开始。
不要重复争论。
不要把已经知道的缺口当新发现。
不要把"项目还有 N 个未完成" 当成"项目失败"。

这是 CH06 共享账本 在 post-launch 的延伸 —— 账本不是写完上线就完事 · 账本本身是项目的一部分。

7. 每周只改一小批 · 数据多 ≠ 改得多

普通人做网站 · 最容易被工具诱惑——

Google Analytics / Vercel Analytics / 数据库 / 分析仪表盘 / AI 分析 / 用户画像 —— 听起来都很强。

但真正的问题是 ——

这些数据回来以后 · 你会不会改得更好？

如果不会 · 数据越多 · 只是噪音越多。

我后来给自己定了一条 ——

每周只改一小批。
  - 不要用户一反馈就大改。
  - 不要 AI 一建议就重构。
  - 不要因为看到数据就立刻追热点。

先判断 · 再改。

这是 判断力的预存（CH04） 在 post-launch 的延伸== ——

判断力的预存 · 不是"提前做好所有判断" · 是"提前决定哪些不做"。

• 哪些反馈不做：偶发 / 边缘 / 高风险但低价值。
• 哪些功能不做：超出 T 型柱子 / 没有第三层答案 / 牵扯不可逆数据。
• 哪些热点不追：和网站定位无关 / 监控用户行为 / 一次性话题。

不做 · 比做 · 更需要判断力。

8. 这一章给一个普通人的"上线后"观

如果你也用 AI 做了一个网站 · 上线以后我建议你做三件小事——

1. 写一个 post-launch backlog —— 哪些功能还没完成 / 哪些地方需要人工审核 / 哪些事不能自动做 / 哪些数据还没验证 / 哪些用户反馈要继续观察。
2. 建立最小反馈入口 —— 可以是一个表单 / 一个邮箱 / 一个问卷 · 甚至是你自己手工记录用户问题。只收必要反馈 · 不收个人身份信息。
3. 每周只改一小批 —— 先判断 · 再改。不要让反馈成为新的"确认税"。

外加三条不要——

1. 不要把 fixture / dashboard 当真实用户证明——测试数据不等于用户验证。
2. 不要把用户反馈直接变成自动发布——任何反馈都先入候选队列。
3. 不要为了"感知力"收集不必要的个人信息——窥探换不回信任。

这一切 · 本质上是一句话 ——

上线不是完成 · 是进入真实世界的第一天。

感知不是窥探 · 感知是帮助网站知道自己哪里没做好。

未完成事项不是丢脸 · 未完成事项是项目的导航。

网站不是一次上线出来的。网站是在一轮一轮反馈里长出来的。这就是迭代 在网站这个 surface 上的真实形态。

本篇方法卡

方法 11 · Post-launch 反馈三件套（克制版）

网站上线后立刻建立 ——

A · post-launch backlog（最小 5 行）

```

哪些功能还没完成？

哪些地方需要人工审核？

哪些事不能自动做？

哪些数据还没验证？

哪些用户反馈要继续观察？

```

B · 反馈聚合 6 类标签（只看统计和自愿反馈 · 不收个人身份信息或原始上传内容）

```

页面访问聚合 · 哪个路由有人看

模块兴趣聚合 · 哪个模块有人点

反馈步骤完成情况 · 用户在哪一步走完 / 卡住

下载兴趣 · 哪类资料被下载

内容缺口候选 · 哪些内容应该补

人工边界提醒 · 哪些事必须人工处理

```

C · 候选队列（reflexes ≠ command）

任何反馈 · 先入 候选清单 · 绝不自动改页面。

每个 候选项必须有：证据 / 风险边界 / 负责人 / 下一步。

铁律：

- 感知不是窥探。

- 反馈不是直接修改指令。

- 每周只改一小批。

本篇金句

参考与延伸

核心思想锚 ——

• 李笑来《把时间当作朋友》—— 把反馈变成长期积累 · 而不是情绪波动
• 吴军《信息传》—— 用少量稳定的指标降低系统熵 · 而不是用更多仪表盘制造复杂性
• Stanford Lean LaunchPad —— 上线后的用户反馈 · 才是 MVP 是否成立的核心证据
• Eric Ries《精益创业》—— Build-Measure-Learn 闭环的"克制版"
• Shoshana Zuboff《监控资本主义》—— 感知 vs 窥探的伦理界线
• 老A 本书 CH04《判断力的预存》—— 不做的判断比做的判断更重要
• 老A 本书 CH06《共享账本》—— ledger 在 post-launch 的延伸
• 老A 本书 CH10《"没有做什么" 段》—— 上线后的报告同样需要