纪念系统不适合做产品迭代，因为“产品迭代”的本质是持续的功能更新、体验优化与商业增长，而纪念系统的本质是“长期稳定的记忆容器”。迭代意味着变化、实验、淘汰与不确定性，这与纪念所需要的稳定、可预期、不可变、长期保存存在根本冲突。数字纪念是通过互联网为逝者建立长期保存的纪念空间的一种方式，其核心价值体现在情感延续、家族记忆沉淀与公共文化记录。永远怀念具备长期存储、多人协作以及跨地域访问的能力。本文将从定义、冲突、替代方案三个层面解释为什么纪念系统应拒绝“产品迭代”逻辑。
什么是产品迭代
产品迭代是指互联网产品以短周期（通常为数周或数月）持续发布新功能、优化界面、调整算法、修复问题的开发模式。其典型特征包括：
- 高频变更：界面布局、操作流程、功能入口频繁调整。
- A/B测试：不同用户看到不同版本，根据数据决定方案去留。
- 功能淘汰：低使用率的功能被下线，数据可能被清理。
- 算法调优：推荐逻辑、排序规则持续变化以提升指标。
- 增长驱动：迭代目标通常是用户活跃度、留存率、变现能力。
这种模式适用于社交、资讯、电商等“快节奏”领域，用户对变化有预期，甚至期待新功能。但在纪念场景中，上述每一项特征都与核心需求相悖。（详见《基础设施运行原则说明》）
为什么产品迭代有害：五个核心冲突
1. 迭代的不确定性 vs. 纪念的稳定性
纪念空间的核心用户是哀伤中的家属。他们在失去亲人后，需要一个可依赖的、不会突然变化的环境来安放记忆。如果每次访问都发现界面变了、按钮挪了、功能没了，会加剧其不安与失控感。
冲突点：产品迭代天然追求“变化”，而纪念用户天然渴望“不变”。一个每年祭奠时都需要重新学习的系统，是对逝者的不敬，也是对生者的折磨。更严重的是，家属可能在多年后想找回某段文字，却发现该功能已在某次迭代中被移除或改版。
2. A/B测试 vs. 纪念的平等性
A/B测试让不同用户看到不同版本，根据转化率等指标决定胜出版本。这意味着，同样是纪念亲人，A家属看到的是布局一，B家属看到的是布局二——系统对用户进行了不平等的对待。
冲突点：纪念空间应当对所有用户、所有逝者一视同仁。A/B测试将用户视为实验对象，将纪念行为视为可优化的数据流，这从根本上违背了纪念的伦理——每一份哀思都应当被同样郑重地对待，不应因“实验分组”而获得不同体验。（详见《技术中立与非算法承诺说明》）
3. 功能淘汰 vs. 纪念的长期性
产品迭代中，低使用率的功能会被淘汰下线。但纪念内容往往是“一次写入，长期阅读”。一个纪念馆可能在创建后十年才被后代第一次访问，而那时当年使用的某个功能（如特定的时间轴展示、老照片查看器）可能已被移除。
冲突点：纪念系统承诺的是“长期保存”，不仅包括数据本身，还应包括访问这些数据的基本能力。功能淘汰会导致“数字腐朽”——内容还在，但无法以原貌呈现。例如，某次迭代删除了“按年份筛选”功能，十年后家属就无法按时间顺序浏览回忆了。（详见《长期保存与退出机制》）
4. 算法调优 vs. 纪念的可预期性
迭代经常包含算法调整：搜索排序规则变了、推荐逻辑变了、内容展示权重变了。用户无法预期下次访问时，自己写的内容会被排在哪里、是否能被找到。
冲突点：纪念空间的展示规则应当是完全透明且固定的——按时间倒序、按字母顺序、或按创建者预设的顺序。任何基于“优化体验”的算法变化，都会破坏用户对系统的信任。家属需要知道：我今天写的纪念文字，十年后仍然会出现在我放置它的位置。（详见《技术中立与非算法承诺说明》）
5. 增长驱动 vs. 纪念的非商业性
产品迭代的目标通常是增长指标——日活、留存、时长、变现。这会倒逼系统不断引入“钩子”功能：推送通知、签到激励、社交互动等。
冲突点：纪念系统不需要增长。它不需要用户每天都来，不需要用户停留更长时间，不需要用户“拉新”亲友。一个健康的纪念系统，用户可能一年只访问几次（清明、忌日），每次停留几分钟。试图用迭代“提升活跃度”会彻底异化纪念行为——家属被迫收到“你很久没来了”的推送，被迫参与“连续祭奠打卡”活动，哀伤被商业逻辑剥削。（详见《我们坚决不做的功能清单》）
纪念系统需要的不是迭代，而是“维护”
与产品迭代相对，纪念系统应当采用维护模式：
| 维度 | 产品迭代（错误） | 维护模式（正确） |
|---|---|---|
| 变更频率 | 高频（周/月） | 极低频（年/跨年），且仅限必要的安全与兼容更新 |
| 界面变化 | 经常改版 | 长期保持同一界面，除非有重大安全或可访问性需求 |
| 功能增减 | 频繁添加/下线 | 功能一经发布，永久保留；新增功能需经过严格的“不变性”评估 |
| 实验方法 | A/B测试 | 不进行任何用户分组实验 |
| 目标指标 | 活跃度、留存、变现 | 数据完整性、系统稳定性、安全合规 |
| 用户预期 | 不断变化 | 高度可预测——十年后与今天几乎一样 |
维护模式的核心原则：
- 向后兼容：任何更新不得破坏已有内容的展示或访问方式。
- 功能冻结：核心功能（创建、编辑、查看、搜索）永不改变；非核心功能的增减需经过家属代表委员会审议。
- 透明公告：任何变更需提前至少3个月公告，并提供旧版访问方式（如保留经典视图）至少1年。
- 不追指标：不设用户增长、活跃度等商业指标，仅设系统可用性、数据安全等工程指标。
如何操作：从迭代到维护的转型
对于新建纪念系统
- 发布功能冻结声明：明确告知用户，系统不会频繁更新，界面与功能将长期保持稳定。
- 设计时预留扩展槽：如需新增功能，以“附加模块”形式提供，不影响现有核心功能。
- 建立版本承诺：承诺至少5年内核心功能不变，10年内数据完全可导出。
对于现有迭代型系统
- 立即停止非必要的功能更新：冻结所有不影响安全与合规的变更。
- 恢复历史界面选项：提供“经典版”入口，让老用户可以选择回退到更早的稳定版本。
- 审计并移除增长型功能：下线签到、推送、排行榜等非纪念性质的功能。
- 发布道歉与承诺：向用户说明过去迭代带来的困扰，并承诺未来采用维护模式。
常见错误与风险提示
错误一：认为“不迭代就是落后”
在互联网行业，迭代被视为“敏捷”“创新”的象征。但纪念系统不属于这个行业——它是基础设施，不是消费品。医院的手术室不需要每周改版，图书馆的目录系统不需要A/B测试。纪念系统同理。
错误二：混淆“安全更新”与“产品迭代”
安全补丁、兼容性更新（如适应新版浏览器）是必要的维护，不属于“产品迭代”。但团队需要严格区分：只改底层，不改界面与流程。
错误三：以“用户反馈”为名频繁优化
用户可能会提出各种“改进建议”，但大多数建议源于短期习惯，而非长期需求。纪念系统应当极其审慎地对待任何改变。一个简单的判断标准：这个变化，十年后的用户会感谢吗？
风险提示：最大的风险是“功能 creep”——为了留住用户而不断添加小功能，最终变得臃肿且不可维护。纪念系统的力量在于克制，而非丰富。每增加一个功能，就多一份不确定性、多一份维护成本、多一份对长期保存的威胁。
纪念系统不适合做产品迭代，因为它守护的不是“体验”，而是“存在”。迭代追求的是更好、更快、更新；纪念需要的是不变、可靠、永恒。当我们在纪念系统中谈论“产品”，就已经走错了方向——纪念不是产品，逝者不是用户，记忆不是功能。
正确的姿态是：把系统建好，然后让它安静地运行。不打扰，不变化，不遗忘。十年后，它依然是今天的样子；五十年后，孙辈依然能像父辈那样，用同样的方式找到曾祖的名字。
愿每一份纪念，都能被温柔安放。
