体面地说再见：vibe 项目的功能下线实战

导语：敢下线，才是产品成熟的标志

每一个 vibe 开发者都会这一招：看到用户的一个需求，三句话丢给 AI，两天后新功能上线，配一篇 changelog，成就感拉满。但你会发现，三年后产品里躺着十七个功能，其中十个你都快忘了是干嘛的——每个都还要维护：依赖要升级、bug 单里偶尔冒出来、用户偶尔问一句"这个按钮怎么没反应"。这些"僵尸功能"吃掉的时间，比开发新功能还贵。

敢上线、不敢下线，是独立开发者最贵的习惯。上线只需要勇气，下线需要一套完整的执行动作：公告、数据出口、退款、邮件、301、归档、复盘。少做任何一步，都会变成半夜两点的工单、App Store 的一星差评，或者 Google 索引里一堆 404。本文就是把这套动作写成 SOP——下线和上线是对称的工程动作，值得同等认真的对待。

先说清楚这篇的边界。站里已经有三篇姊妹指南，分别覆盖了相邻但不重叠的地盘：vibe-project-api-versioning-deprecation-guide 讲的是 API 层的废弃——URL 版本策略、Deprecation 响应头、breaking 变更判定，那是给机器和开发者看的接口契约；vibe-project-exit-acquisition-guide 讲的是把整个项目卖掉的退出实战——估值、尽调、交接，那是公司层的事；side-project-kill-list 讲的是"杀不杀"的决策清单——帮你判断一个项目值不值得继续。本文默认你已经决定了：某个功能、某条产品线，就是要关。这篇讲的是产品层"决定关掉之后"怎么执行干净，从公告期第一天到复盘最后一页，六步走完才算完。

第一步：下线三问——要不要下，什么时候下，怎么下

下线之前先过三问，每一问都要有数据，而不是凭感觉。

第一问：还有人用吗？打开你的分析后台，看三个数：过去 90 天这个功能的日活用户数、占全站用户的比例、以及趋势是涨是跌。一个常见的经验线：某功能 90 天内活跃用户不足总用户 5%，且连续两个季度下滑，就可以进下线候选。注意不要只看绝对数——一个只有 200 人用、但全部是年付 500 美元企业客户的功能，和一个有 2 万人用但零付费转化的功能，命运完全不同。按"收入贡献 × 活跃趋势"排优先级，别按访问量。

第二问：维护成本到底多少？把过去半年花在这个功能上的时间列出来：bug 修复、依赖升级、客服工单、偶发的线上事故。独立开发者最容易低估的是"认知税"——每次你打开代码库，都要花十分钟回忆这坨逻辑是干嘛的。做一张"功能墓地评审表"，一行一个功能，列：月活、付费用户数、近半年维护工时、上次有意义迭代的时间。四个格子全红的功能，留着它只是在交税。

第三问：关掉的真实代价是什么？代价有三类：用户信任（有没有人是冲着这个功能付费的）、流量（有没有页面在 Google 排在前三）、法律（有没有 SLA 承诺或合同条款）。如果答案是"有十几个年付用户、有 3 万自然搜索流量"，那下线方案就要按"迁移"而不是"关闭"来设计。三问过完，你会得到一个清晰的结论：直接关、迁移后关、还是再观察一轮。

第二步：时间线倒排——把下线当成一次发布来做

下线最忌讳的是"某天早上起来把开关拔了"。正确做法是把下线当成一次小型发布来倒排：公告期、只读期、正式下线，三个阶段。

公告期：免费功能至少 30 天，付费功能至少 90 天。为什么是 30/90？这是行业惯例的下限：Dropbox 2015 年 12 月宣布关停 Mailbox，正式下线日是 2016 年 2 月 26 日，整整给了 80 天；Google 2026 年 10 月 9 日停止销售 Gemini Code Assist 新订阅时，给现有订阅的安排是续约到 2027 年 1 月底（年付）乃至 2027 年底（月付），迁移窗口以"年"计。你的用户基数小，但道理一样：公告期必须覆盖至少一个完整的用户账单周期，年付用户必须给到 90 天以上，否则退款和投诉会把你淹没。

公告期第一天要同时做四件事：站内横幅上线、告别邮件发出、changelog 条目发布、FAQ 页面上线。注意顺序——先发公告再关入口，千万别反过来。公告期内关闭新用户入口：新注册、新订阅、新 API Key 全部停掉，老用户不受影响。这一步很多人会忘，结果是公告发出后还有新用户进来，然后下线日这些人骂得最凶。

只读期：停写入，保留读取和导出。功能进入只读模式：用户不能再创建新数据，但历史数据可看、可导出。只读期的长度取决于数据复杂度，至少两周。这一阶段你的导出按钮要放在最显眼的位置，导出功能本身要单独测试三遍——下线日当天导出服务崩了，是灾难级的信任事故。

正式下线日：关入口、停计费、清 cron。这一天的 checklist：前端入口隐藏、路由返回 410 或 301（下一节细讲）、订阅计费停止、相关 cron 任务和 webhook 全部关闭、第三方服务（短信、邮件、对象存储的子 bucket）解约或降级。Google 关 Code Assist 时给了一个值得抄的细节：区分"停止销售"和"停止服务"两个时间点——先停售（不再产生新承诺），再按合同逐步停服。solo 开发者同样适用：先关新入口，再动老用户。

第三步：数据出口——导出、迁移、删除，一个都不能少

用户可以接受功能没了，但不能接受"我的数据没了"。数据出口有三条路，按优先级排序：导出（用户自助拿走）→ 迁移（帮用户搬到别处）→ 删除（用户要求彻底清除）。

导出是底线。提供一键导出，格式至少给 CSV 和 JSON 两种：CSV 给普通用户（Excel 能直接打开），JSON 给技术用户（结构完整）。导出内容要完整：用户创建的全部数据、元数据（创建时间、标签、关联关系）、以及附件的下载链接。下面是一个可以直接用的导出脚本骨架——按用户 id 打包，写成 zip，上传到对象存储返回下载链接：

import csv, io, json, zipfile
from datetime import datetime, timedelta

def export_user_data(user_id, db, storage, retention_days=180):
    """导出单个用户在某功能下的全部数据，打包成 zip。"""
    rows = db.query(
        "SELECT * FROM feature_records WHERE user_id = %s", (user_id,)
    )
    buf = io.BytesIO()
    with zipfile.ZipFile(buf, "w", zipfile.ZIP_DEFLATED) as zf:
        # 1. JSON：结构完整，给技术用户
        zf.writestr("records.json", json.dumps(rows, ensure_ascii=False,
                                               indent=2, default=str))
        # 2. CSV：Excel 可直接打开，给普通用户
        if rows:
            text = io.StringIO()
            writer = csv.DictWriter(text, fieldnames=list(rows[0].keys()))
            writer.writeheader()
            writer.writerows(rows)
            zf.writestr("records.csv", text.getvalue())
        # 3. 说明文件：导出时间、数据范围、联系方式
        zf.writestr("README.txt",
            f"导出时间: {datetime.utcnow().isoformat()}Z\n"
            f"数据范围: 功能 sunset 前的全部记录\n"
            f"下载链接有效期: {retention_days} 天\n"
            f"问题请联系: support@example.com\n")
    key = f"exports/{user_id}/{datetime.utcnow():%Y%m%d}.zip"
    url = storage.upload(key, buf.getvalue(),
                         expires_in=timedelta(days=retention_days))
    return url

注意三个细节：第一，导出链接的有效期——下线后至少保留 6 个月，公告里写清楚"你的数据在 X 年 X 月 X 日之前都可以下载"；第二，导出功能要和下线开关解耦，下线日当天导出服务必须还活着；第三，大用户的数据量可能很大，导出做成异步任务+邮件通知下载链接，别让用户在页面上干等超时。

迁移是加分项。如果市面上有成熟的替代品（哪怕是竞品），写一页纸迁移指南：字段对照表、导入步骤、常见坑。2016 年 Facebook 关闭 Parse 时给了整整一年缓冲，开源了 Parse Server，还给了迁移工具——这就是教科书级的"迁移路径"。你的体量不需要做到这个程度，但一页纸的"去哪儿+怎么搬"，能把 80% 的愤怒转化成"这团队还挺负责"。

删除是义务。用户要求删除账号或数据时，走标准的数据删除流程，该清数据库清数据库，该清备份按备份策略来。欧洲用户还涉及 GDPR 的删除权——别在这种事情上省时间，删干净、给确认邮件。

第四步：钱的事——付费用户的退款与补偿，一个公式走天下

下线最容易翻车的就是钱。记住一条铁律：用户为还没用完的服务付过钱，钱就得退。退款公式很简单：按剩余天数比例退。年付 365 美元的套餐，下线日还剩 120 天没用完，就退 120/365 × 365 = 120 美元。别搞"代金券""折成积分"这种小聪明——用户要关的是功能，不是换一家店继续消费，代金券只会让人觉得你在耍赖。

实操上有三档处理：月付用户，直接退当月剩余天数，Stripe、Paddle 这类支付平台都支持按比例退款的 API，一行调用的事；年付用户，按剩余天数比例退，这是最敏感的一群人，退款邮件里要单独说明计算方式（"您年付 365 美元，剩余 120 天，退款 120 美元"），透明是最好的灭火器；终身付费/一次性买断用户，这是最难的一档，没有"剩余天数"可算，业界常见做法是退一个固定比例（比如 30%–50%）或赠送你其他产品的等值时长，方案要在公告里一次性说清楚，不要让用户来讨价还价。

补偿和退款是两回事。退款是把没花的钱还回去，补偿是为"打乱了用户的工作流"道歉。补偿不用贵，但要具体：比如免费延长你另一个产品三个月、或者一封手写的道歉邮件（对，就是手写/亲笔，不是模板）。独立开发者的优势恰恰在这里——大公司只能发模板邮件，你可以真人出面。Mailbox 关停时，Dropbox 的 FAQ 里给每个替代品都写了迁移指引，连"你的草稿会删、请手动保存"这种细节都列出来了——细节越具体，用户越觉得被尊重。

第五步：应用内公告与告别邮件——说什么，不说什么

公告文案有三件套：站内横幅、告别邮件、changelog 条目。写法上有一条红线：不甩锅、不画饼、不玩文字游戏。

先说"三不说"。不甩锅：别写"由于第三方服务调整""受不可抗力影响"，除非真是这样。用户一眼就能看出来你在推卸责任。不画饼：别写"我们正在打造更强大的 2.0""敬请期待"，如果 2.0 根本不存在，这就是在消费最后一点信任。不玩文字游戏：别用"功能升级""服务优化"来包装下线，用户不傻，这种话术只会让他们更生气。

再说"三要说"，按这个顺序：第一句说决定："我们决定在 X 年 X 月 X 日关闭 XX 功能。"开门见山，别绕三段背景再说重点。第二句说原因，一句话、说人话："过去一年只有 3% 的用户在使用它，维护它占用了我们一半的开发时间，我们决定把精力集中在核心功能上。"第三句说安排：数据怎么导出、钱怎么退、去哪里找替代品，每一条给链接。

告别邮件和横幅的区别在于语气。横幅是通知，冷静、准确、有链接就行；邮件是告别，可以带一点人味。一封好的告别邮件结构：第一段讲决定和日期；第二段讲原因（一句话）；第三段讲"你的数据和钱怎么办"（分条列出，每条带链接）；第四段感谢——具体一点，"感谢过去三年 2,400 位用户的使用"比"感谢大家一直以来的支持"有诚意得多；最后署名，真人署名，别用"XX 团队"。

FAQ 页面要置顶三个问题："我的数据怎么办？""我付的钱怎么办？""有没有替代品？"——这三个问题覆盖了 95% 的工单。剩下的 5% 才是真的需要人工回复的，提前准备好话术模板，客服（就是你自己）就不会在下线日手忙脚乱。

第六步：SEO 与外链——301 映射表，别让流量清零

下线的功能如果有公开页面（帮助文档、功能介绍页、博客教程），直接删掉就是把 Google 排名和外链权重扔进垃圾桶。正确做法是做一张 301 映射表：每个要下线的 URL，对应一个最相关的存活页面。

映射规则很简单：功能介绍页 → 产品首页或替代功能页；帮助文档 → 迁移指南或 FAQ；博客教程 → 归档页或更新后的教程。实在找不到相关页面的，301 到首页也比 404 强——搜索引擎早已明确 301 传递不再损失权重，外链的积累不会白费。只有一种情况用 410（Gone）：这个页面代表的内容彻底不存在、且没有任何替代，比如某个已删除的 API 端点文档。410 告诉搜索引擎"别再来了"，适合真正的终点。

配置示例（Nginx，直接可用）：

# 功能下线 301 映射表 —— 逐条写，宁可多写十条，不可漏一条
server {
    listen 443 ssl;
    server_name example.com;

    # 功能介绍页 → 替代功能页
    location = /features/smart-reminders {
        return 301 https://example.com/features/automation;
    }
    # 帮助文档 → 迁移指南
    location = /docs/smart-reminders {
        return 301 https://example.com/docs/migration-guide;
    }
    # 实在无处可去的 → 首页（保底，不断链）
    location = /features/legacy-dashboard {
        return 301 https://example.com/;
    }
    # 已删除的 API 端点文档 → 410，告诉搜索引擎别再来
    location = /docs/api/v1/reminders {
        return 410;
    }
}

上线 301 之后做三件事：第一，用 Search Console 的"网址检查"抽查几条，确认返回 301 且目标页 200；第二，外链多的页面（用 Ahrefs 或 Search Console 的"链接"报告查），考虑联系对方站长更新链接，301 是保险不是借口；第三，站点地图（sitemap）里删掉下线 URL，别让搜索引擎继续抓取一堆重定向。三个月后回看 Search Console 的覆盖率报告，确认 404/软 404 没有异常 spike，才算这一节真正收尾。

第七步：代码归档与分支策略——删得干净，找得回来

代码层的下线分四步，顺序不能乱：打 tag → 归档分支 → 删部署流水线 → 关 cron 和第三方服务。

第一步，给代码办"葬礼"：打 tag。在删代码之前，先在主分支上打一个归档 tag，比如 archive/smart-reminders-final，tag 信息里写清楚：下线日期、最后服务的版本号、数据导出脚本的位置。tag 是 Git 里最便宜的时间胶囊，十年后你想看这段代码长什么样，一条命令就回来了。

第二步，归档分支。把功能相关的分支合并成一个归档分支（或直接归档整个仓库，如果是独立服务），分支名统一 archive/<功能名>-<日期>。GitHub/GitLab 都有仓库归档（Archive）功能：归档后仓库只读，不能再 push、不能再开 issue——这是一个很体面的"盖棺"动作，公开仓库归档后，别人还能看到代码和历史，但不会再有人提 issue 问你"这个 bug 修不修"。

第三步，删部署流水线。CI 里的构建任务、CD 的部署流程、Docker 镜像的自动构建，全部删掉或禁用。最容易漏的是这三处：定时构建（nightly build）、镜像仓库的自动清理策略（别让它把归档镜像也清了，先打标签锁定）、以及 IaC（Terraform/Pulumi）里的资源定义——基础设施代码不删，下次 apply 会把服务又拉起来，闹笑话。

第四步，关 cron 和第三方服务。拉一张清单逐项打勾：cron 定时任务、webhook 订阅、短信/邮件服务商的子账号或模板、对象存储的子 bucket（先确认数据已迁移或已过保留期）、域名（如果功能有独立子域名，DNS 记录删掉，但域名本身建议续费保留一年，防止被抢注做钓鱼）、错误监控（Sentry 等）里的项目、状态页（status page）上的组件。每一项关掉后，在清单上写日期和操作人——solo 开发者操作人就是你自己，写下来是为了三个月后你还能想起来"我当时关了啥"。

第八步：下线后复盘——把"关过什么"变成信任资产

下线日不是终点，复盘才是。复盘不用长，一页纸，回答四个问题：

1. 当初为什么上这个功能？把当时的决策依据写下来——是用户投票、是竞品压力、还是你半夜的灵感。很多功能死掉的原因在出生那天就写好了：为 3 个人的需求做了一个通用功能，为赶发布会做了一个没人维护的 demo。

2. 死亡信号最早什么时候出现的？回看数据，找到那个拐点：是上线三个月后增长就停了？是第一次大重构时就没人愿意碰这块代码？把信号和时间写下来，下次同样信号出现时，你的反应速度会快一倍。

3. 如果早关三个月，能省多少？算一笔账：三个月的维护工时 × 你的小时费率（按你接外包的价格算），再加上服务器和第三方服务的费用。这个数字是下次你犹豫"要不要关"时最好的清醒剂。

4. 下次怎么做得更好？只写一条，最多两条。比如"新功能上线时就写好下线条件""付费功能的公告期从 30 天改成 90 天"。复盘写十条等于没写。

最后一步是可选的，但效果出奇好：做一个公开的"功能墓地"页面。列出你关过的功能、关的原因、一句话教训。这听起来反直觉——谁会把失败挂出来？但用户看到"这个团队敢关功能、关得干净、还愿意讲清楚"，信任感反而上升。敢于公开下线史的团队，用户会相信"他们不会让我用的功能莫名其妙消失"——因为你已经证明了，即使消失，也会体面地告别。

反模式清单：这七件事，一件都别干

1. 静默下线：不发公告直接关，还指望用户"自己发现"。这是信任自杀，用户会默认你跑路了。
2. 先关入口再发公告：顺序反了。公告发出后 24 小时内还会有新用户注册，先关新入口，再发公告。
3. 导出按钮和下线开关同一天死：导出服务必须比功能多活至少 6 个月，写进公告里。
4. 用代金券代替退款：用户要的是钱回来，不是换个地方继续花。按比例退现金，别耍小聪明。
5. "功能升级"式话术：把下线包装成升级，用户不傻，话术越花，骂得越凶。
6. 删代码不打 tag：三个月后你想看一眼当初的实现，发现 Git 历史里找不到了——tag 是成本最低的后悔药。
7. 下线日当天还在改方案：公告发出后，方案就冻结了。临时改日期、改退款规则，每改一次，信任掉一格。

验收标准：全部打勾，才算下干净

下线完成不是"代码删了"，而是下面这 12 项全部打勾：

1. 公告已发布（站内横幅 + 邮件 + changelog + FAQ），公告期满足 30/90 天下限
2. 新用户入口已关闭（注册、订阅、API Key），公告期内无新增用户
3. 数据导出功能可用，抽查 3 个不同量级用户导出成功（CSV + JSON）
4. 迁移指南已发布（如有替代品），或已明确告知"无官方替代品"
5. 付费用户退款完成，退款邮件已发送，退款金额计算方式透明
6. 告别邮件已发送，FAQ 置顶"数据/退款/替代品"三个问题
7. 301 映射表已上线，抽查返回码正确，sitemap 已清理
8. 代码已打归档 tag，归档分支已建，公开仓库已设为只读归档（如适用）
9. CI/CD 流水线已删，cron/webhook/第三方服务已关，清单逐项签字
10. 计费已停止，无用户在下线日后被扣费（下个账单日复查一次）
11. 一页纸复盘已写完，归档到团队知识库
12. 下线 30 天后回看：工单量、Search Console 覆盖率、退款纠纷数，确认无异常 spike

最后说一句：下线做得体面，用户不会因为你关了一个功能就离开你；下线做得难看，用户会因为你关功能的方式离开你，甚至带走朋友。vibe 开发者的护城河从来不是功能多，而是用户信你。体面地说再见，是给下一次"上线"攒信用。