Repository navigation
Product Evolution
康冠时代会话存档 / CROWN TIME WeCom Archive · 产品演化史 V1.0
记述范围：2026 年 6 月至 10 月。本文关注产品决策；AI 协作、架构重构与生产故障的工程成长史，将另文记录。
这篇文章写的不是一条从立项开始就规划好的创业路线。
最初，我只是想解决自己公司的问题。后来，我开始问：既然我能做出来，为什么不能让其他同样小的公司也用得起？再后来，我又改变了对交付方式和开源的判断。
这些决定并不总是一致。有些方案做了以后才发现不够，有些判断被后来的经验推翻。我想保留的是当时面对的问题、作出选择的理由，以及选择之后真正发生的事情，而不是把几个月的反复整理成一条没有弯路的成功故事。
**阅读说明：**文中的个人动机和「15 天」「7 天」来自我的第一手回忆；能够与仓库交叉核对的里程碑附有原始链接。「现在回看」表示回顾性解释，不代表当时已经想清楚。历史生产验收引用工单记录，不等于写作时重新验证；代码合并、上线运行、商业验收也不是同一件事。日期使用北京时间。
2026 年，我自己的公司确实需要企业微信会话存档。
业务沟通发生在企业微信里。需要查找过去的消息、确认沟通过程或处理争议时，我希望有一个能够持续保存、搜索和审阅记录的后台。这不是为了给 AI 找一个演示场景，而是原本就要花钱解决的业务需求。
按我的回忆，当时购买的 SaaS 年包即将到期，只剩 15 天。我必须决定：继续购买现成服务，还是试一次自己开发。
如果没有这个期限，我也许会把想法放进待办清单，慢慢研究。但 15 天意味着不能无限准备，也不能先设计一个理想中的完整平台。我需要尽快知道，一人加上 AI，是否真能交付一个解决实际问题的软件。
不过，我没有把公司的需求押在一个毫无退路的实验上。如果自研失败，仍然可以购买现成 SaaS。现成服务是备选方案，不是必须被证明错误的对手。
这个安排给了实验一个边界：时间有限，目标具体，失败有出口。我不需要一开始就证明自己能经营一家软件公司，只需要先回答：能不能把自己需要的那条链跑起来？
这是康冠时代会话存档的起点。不是融资计划，也不是一个关于 AI 将取代开发者的宏大判断，而是一次有真实需求、有期限、也有退出机制的尝试。
我的回忆是，7 天后，一个能够工作的 MVP 做出来了。
这个「能工作」不应该用后来产品的功能清单来解释。当时要验证的是最基本的事情：接入企业微信会话存档，取得数据，解密和保存，再在网页上查看、检索。可信试用、订阅、自动配置和平台运营后台，都是后来的工作。
仓库留下了这一阶段的轨迹。6 月 26 日出现首个提交；6 月 27 日已有消息搜索和会话审阅界面；6 月 28 日加入实际归档同步 Worker与文本消息解密、归一化。这些日期与早期快速实现相吻合，但尚不足以替「第七天」确定一个准确的验收日期。
部署也不是一步成功。6 月 27 日现存流水线记录里，先有五次失败，随后才出现成功的部署运行。它证明部署流程走通过一次，不证明当时所有真实消息和业务场景都已经验收。
对我来说，MVP 的意义不在于功能有多少，而在于实验的答案发生了变化。开始时，我问的是「一个人能不能做」；有了能工作的结果以后，我可以开始问「怎样把它做得更好」。
AI 在这一步很重要。它帮助我把需求转成实现，降低了独立开发的起步成本。但这不意味着每一行代码都是我亲手写的，也不意味着 AI 替我决定了产品。需求是否真实、哪些功能先做、失败时是否退出，以及结果是否值得继续，都需要我判断。
七天建立的是继续投入的信心，不是一张完成所有工程责任的证明。原本的十五天期限，是一次实验的时间窗口；它不是整个项目结束开发的承诺。
自己成为使用者之后，我对目标客户的理解，不是从一个抽象的市场规模数字开始的。
我的公司就是 1—5 人的小团队。在当时接触的服务方案中，有些要求至少购买五个座席，但我的实际需求可能只有一个。这里记录的是我的购买经历，不代表所有供应商都采用相同规则。
我的问题很直接：
我只有一个人，难道不配使用这种服务吗？
小团队需要的软件未必比大公司简单。沟通记录同样会丢，客户同样会改名，争议同样需要证据，权限与数据安全也不会因为只有一个人就变得不重要。但传统企业软件的销售与服务方式，往往让这样的需求很难被单独承接。
于是，我开始形成一个产品假设：如果 AI 能降低研发成本，再通过自动化降低交付和运营成本，传统服务商不愿覆盖的小客户，也许可以在明显更低的价格下得到持续服务。
这里的「也许」很重要。这是我愿意验证的商业假设，不是已经证明的盈利模型。我没有因为代码写得更快，就知道服务器、存储、支持、获客和续费的总成本一定能被覆盖。
低价也必须有清楚的边界。企业微信官方会话存档接口的开通和费用，并不会因为我写了软件就消失。后来的试用入口设计明确要求说明：软件试用免费，企业微信官方费用另计。把不同费用混成一个便宜的宣传数字，只会把困难留到客户接入时。
这使产品目标逐渐明确。我不是要做一个比所有竞品功能都多的系统，而是想降低小团队获得专业软件服务的门槛。价格只是门槛的一部分；如果用户仍然需要学会运维、等待人工配置，或者靠我逐步解释才能开始使用，门槛并没有真正消失。
现在回看，这个定位最有价值的地方，是它不断迫使我作出取舍。我不能只问某个功能是否漂亮，还要问它能否让一个没有专职 IT 人员的小团队更容易开始、更容易理解，也更容易持续使用。
自己使用一个工具时，我知道它的来历，也知道哪里还没做好。把它交给别人，这些隐含知识就不能继续成为使用条件。
一个典型例子是名字。数据库有 sender ID，并不意味着用户知道自己正在看谁。可读名称、员工备注、客户昵称和群聊名称，看上去只是界面细节，却决定系统能否表达真实工作中的关系。
RND-129 / PR #9处理显示名称的消费与 fallback；RND-130 的提交负责名称同步。后来，RND-170 / PR #16进一步分开员工备注、客户当前昵称和观察到的昵称历史。主标题继续优先使用工作中有意义的备注，而不是强行改成当前真实昵称。
这里不能说系统已经重建了每一条消息发生时的历史称呼。记录曾经观察到的昵称，和完整还原任意时刻的身份状态，是不同的能力。但这种区分本身，就让我认识到产品需要正确解释信息，而不仅是把字段显示出来。
媒体带来了类似变化。文本之外还有图片、语音、视频和文件。媒体访问与缩略图调整说明，存下来以后还要考虑访问权限、等待时间、浏览器缓存和历史回填。这个 PR 也明确保留了生产迁移与性能验证待办，不能把代码完成写成所有环境都已经切换成功。
身份和权限则让我看到另一种交付缺口。8 月 19 日，平台管理员登录问题暴露出：运营页面存在，不等于运营者已经拥有可用的身份入口。产品必须覆盖账户如何建立、如何登录、如何退出，以及操作如何留下记录，而不只是一个后台页面。
语言也需要重新设计。8 月 5 日，RND-349 / PR #26把用户可见的「监控」按语义改成「存档」「接入」和「运行状态」。这不是无脑替换：员工被纳入保存范围、企业完成配置、系统正在正常运行，本来就是三件事。
总览与用量分析的合并延续了同样的原则。Demo 的视觉可以借鉴，但正式页面的数字和状态必须来自真实租户数据。一个看起来像 SaaS 的页面，不能代替用户需要确认的「归档是否在运行」。
这些变化不是某一天统一完成的外部产品发布。从名字、媒体、身份到状态说明，系统逐步减少了对「作者就在旁边」的依赖。我开始理解，可交付不是多几个页面，而是陌生使用者能够理解系统、完成动作，并在失败时知道下一步是什么。
我并不是从第一天就坚持完全自助。
8 月 7 日的历史 ADR-0003记下了当时的选择：保持闭源、只做托管，并刻意为前十家客户手工陪跑。手工的理由也明确——先了解真实用户在哪里卡住，再决定自动化什么。
这是一种有道理的学习方式。没有看过用户配置，向导可能把简单步骤做得很精美，却漏掉最难的地方。不过，随着我重新计算服务成本，它与小客户定位之间的矛盾越来越明显。
按我的回忆，一个五座席客户的接入工作量，未必比五十座席客户少多少。授权、配置、密钥、问题排查和解释步骤，都不会按座席数等比例缩小。这不是基于计时样本得出的行业研究，而是促使我改变策略的判断。
我也因此更能理解最低座席模式。它未必只是供应商不重视小客户，也可能是传统人工交付的固定成本，需要更高的合同金额来覆盖。如果我只是把价格降下来，却照搬这种交付方式，就没有解决根本问题。
于是目标从「低价提供一套软件」转向「不让我成为每次接入的必要环节」。人工陪跑可以帮助学习，但不能未经计算就成为长期默认模式。
这个选择很快变成了架构要求。系统不能把一个填写邮箱的人当成企业 Owner；必须有可信的企业管理身份。组织不能重复创建，试用不能随便重复领取，凭据必须属于正确租户，配置不完整时不能假装激活成功。
8 月中旬，可信的 15 天试用基础、公开试用入口和多租户配置、自动激活陆续合并。授权、组织绑定、配置、连通性、订阅和运行状态开始被连接起来，而不是由我在后台手工补齐。
这不等于平台可以替客户完成一切。腾讯仍要求企业准备的会话存档 Secret 和私钥，需要管理员在受控向导中提供。「零人工」指不依赖平台人员代填凭据、改数据库和手工激活，不是消除企业自己的准备工作。
入口默认关闭也有明确意义。它防止我把实现进度误当成对陌生企业的上线承诺。代码能处理某条路径、非生产环境真实走通、生产受控开放，是三个不同阶段。
截至本文所依据的研究快照，非生产授权 E2E、生产开放和真实外部客户零人工首条消息验收仍有未完成门禁。因此，我能说自己推动了自助 SaaS 的建设，不能说已经证明每个新客户都可以零人工完成接入。
现在回看，自动化并不是让我少做一些重复劳动的附加功能。它是低价服务小团队的必要条件，却还不是商业可持续的充分条件。
99 元是一个很小的金额，但支付接入让我遇到的并不是一个小问题。
显示二维码或跳转收银台只是开始。服务器必须知道订单属于谁，是否真的付款，回调是否可信，重复通知能否幂等处理，成功后应该发放什么订阅与权益。如果回调丢失，还要有办法主动查单和恢复。
路线也需要准确记录。8 月 13 日已有微信年度套餐实现；8 月 23 日的支付宝接入 PR #67是在微信 Native 旁边增加 provider，而不是支付宝失败以后才改用微信。支付宝代码实现与真实生产支付，也需要分别证明。
能够核对的真实微信支付事件，来自GH-113 的历史取证：**2026 年 8 月 27 日 14:00:37，99.00 元回调验签通过，产生 payment_succeeded。**后续GH-106 的运行验收和GH-111 的最终核查继续确认成功支付及权益激活事实。
我在早期回忆里写过「8 月 28 日到账」。目前记录能确定的是 27 日支付成功，28 日补齐并验证支付运行链；商户结算或实际收款日期仍需另行核对，不能让回忆替代时间戳。
这笔钱的重要性，是产品开始承担真实交易的后果。订单、订阅和权益不再只是测试中的状态。但是，付款本身不能证明付款人是独立外部客户，更不能证明已经完成获客、接入、首次同步和长期续费。第一笔真实支付，和第一位经完整验收的外部付费客户，不是同一个里程碑。
支付后的记录也没有让我停在成功页面上。GH-106发现，账单生命周期与支付恢复、对账的代码存在，执行器却没有安装运行。PR #110使它们进入部署管理，之后才有实际执行和业务状态核对。
告警同样需要修正。不可信请求验签失败，首先应当被安全拒绝；不能把每一次拒绝都叫作严重支付事故。提供方确认订单不存在，也不能永远当成未知状态重试。这些问题分别在 GH-113 和 GH-111 中得到调查、分类和收敛。
所以，99 元没有替我证明商业模式。它证明了一条真实付款路径，同时暴露了收费之后必须负责的更多事情。我需要从「能收款」继续走向「交易有记录，权益正确，异常能恢复」，再去验证是否有人持续需要并愿意购买这项服务。
到了 10 月，我对项目的判断变了。按我的回忆，几个月的开发让我相信，它已不只是一个自己才能用的临时工具；我对安全性、稳定性和性能建立了信心，愿意让其他人看代码、部署和提出问题。
这是我的工程判断，不是独立安全认证，也不是一份可以证明所有规模都能稳定运行的性能报告。支撑信心的，是系统逐渐积累了可以检查的结构和记录。
7 月末的模块拆分与ADR-0002，把依赖方向和 composition root 的边界变成可执行测试。它也回应了 AI 开发的现实问题：一个功能不应该迫使 agent 理解所有无关业务，拆开的代码不能悄悄重新堆回入口文件。
对我而言，这使继续修改系统更有依据。代码的组织方式、回归测试和 CI，开始帮助我发现退化，而不只是依赖每次阅读和总结。但自动化测试的存在，仍不等于所有生产路径已经验证。
运行能力的证据也比文件清单更具体。8 月 30 日，GH-105 的恢复验收记录了从异地备份恢复的演练。这说明已有一次实际恢复能力的证明，不能把它扩大成高可用集群或自动故障转移。
10 月的数据库升级记录则提醒我，成熟不意味着不再出错。升级服务端后，备份链仍调用旧客户端，首次定时备份失败；修正以后，又等待下一次自然调度来复证。这样的遗漏不应该在公开故事里被删掉。
我愿意公开的，不是一个从未失败的系统，而是一个有决策记录、测试、恢复实践，也保留缺陷历史的系统。别人可以比我更严格地判断：哪些保证成立，哪些仍然只是主张。
公开本身也需要工程准备。PR #196补齐许可证、运行版本策略、自部署方案和社区入口；PR #204进一步处理公开文档与私有运维材料的边界。透明不等于公开客户数据、凭据和真实运行配置。
这些准备还有限制。自部署代码和指南不代表在任意干净机器上都已经验证成功，腾讯 SDK 也需要部署者自行合法获取。外部工程师的真实消息验收与生产版本核查，仍需相应证据。
对我来说，「成熟意味着敢于公开」不是宣告工程已经结束，而是愿意让它离开只有我能解释的环境，接受独立检查，并继续为发现的问题负责。
10 月的开源决定，推翻了 8 月的托管独占选择。
我不想把这种变化写成早有安排。8 月时，我优先考虑小团队的购买方式和商业交付；到了 10 月，工程信心、透明度和我对开发者身份的理解，共同改变了权衡。
会话存档处理企业敏感通信。只说「我们的系统安全」，客户很难独立判断。公开源码不能保证安全，却提供另一种信任路径：具备能力的人可以检查实现、讨论边界，也可以选择自己部署。
托管与自部署因此不必互相否定。没有运维能力的企业，可以选择托管；有条件自行管理数据的人，不必为了运行软件而购买我的云订阅。两种方式承接的是不同需要，而不是把所有用户强行放进同一种交付流程。
最终的ADR-0009明确采用单仓 AGPL-3.0：归档核心与云运营代码使用同一许可，selfhost 与 cloud 区分运行策略，不是开源和闭源的目录边界。自部署不依赖云端购买、试用或订阅到期状态。
这也意味着别人可以按许可 fork、修改、自部署，甚至提供竞争性托管服务。保留品牌与来源说明，不是禁止合法竞争；公开代码也不是只让别人看、不让别人真正使用。
Discussion #178保留了决策收敛过程，**2026 年 10 月 9 日，v1.1.0作为首个公开开源版本发布。**它标志着代码进入公共协作的环境，不代表已经形成活跃社区或获得外部贡献。
但开源对我还有一个无法只用商业计算解释的理由。
同一段时间里，我也在做其他项目，持续从开源软件和社区中得到帮助。越是自己承担开发与维护，越能理解那些可以直接使用的库、工具和文档，背后需要有人长期认真地投入。
我发现自己对于开源的世界充满尊敬，也希望不再只是使用者。把一个有实际用途的项目交出来，是我尝试参与其中的方式。它不必先成为一个庞大的产品，才值得让别人审查、使用和改进。
从这里回看那十五天，变化并不是「我终于做出了一套完整 SaaS」。一开始，我是一个希望解决自己公司问题的使用者；七天的实验让我相信自己可以创造软件；几个月后，我愿意把这份成果放到公共环境里，接受它不再只属于自己的判断和用途。
发布是一步，长期维护、回应问题和参与社区，还需要后面的行动证明。我不能在发布当天就替未来写下成绩。
最初的问题是：
我只有一个人，难道不配使用这种服务吗？
它让我开始为自己造工具，也让我尝试理解其他小团队的处境。今天，这个问题旁边多了一个愿望：
我希望自己能够成为一个有价值的 Builder。
康冠时代会话存档，是我把这句话从愿望变成实践的一个起点。
本文由 AI 协助整理写作，依据创始人确认的回忆与仓库研究；第一人称不表示全部代码均由创始人亲手编写。技术与商业状态以 2026-10-09 的研究快照为限，后续可能变化。
- **第一手回忆：**年包剩余 15 天、7 天完成 MVP、最低座席购买经历、五座席与五十座席交付成本判断，以及开源个人动机。尚缺原订阅到期记录、首个 MVP 验收日期和具体服务成本样本。
- **支付边界：**已找到 8 月 27 日 14:00:37 的 99 元支付成功记录；「8 月 28 日到账」是否指结算，付款人是否为独立外部客户，仍待确认。不据此主张已验证获客或零人工商业闭环。
- **历史纠错：**RND-130 是联系人显示名称同步，不是消息数量验收。另一张 GH-130 中的 42 与 125 是刷新任务失败与成功次数，不能用来佐证早期「消息从 42 增至 125」的回忆。
- **未完成门禁：**GH-79、GH-80、GH-82 的开放状态限制了自助生产闭环的主张；真实外部客户验收、干净机器自部署和首次真实消息仍需证据。数据库升级有执行记录，但不能据此把 GH-156 的全部观察期任务写成完成。
- **上架与日期：**未取得 9 月 15 日提交或驳回凭证，也未确认最终市场审批，正文不以正式上架为转折。
v1.0.0的 8 月 7 日是历史版本基线；其 GitHub Release 在 10 月 9 日补发布，不能混为首次公开发行日期。 - **尚未证明的结果：**可持续盈利、规模化客户使用、独立安全认证、完整零人工交付和长期社区贡献，均不作为本文结论。