Character.AI 申请破产：技术被买走，剩下的公司怎么定价

官方到底说了什么#

官方两处口径（博客公告 + 新闻稿）能确认的事实只有这些：

• 申请主体与法院：Character Technologies Inc. 在特拉华州破产法院提交自愿 Chapter 11，目的是「促成价值最大化的出售流程」（value-maximizing sale），出售「全部或绝大部分资产」。公司表示在出售期间继续运营平台。
• 迪士尼的身份是「stalking horse」：申请前，公司与 Disney Worldwide Services, Inc. 签了协议，迪士尼作为 stalking horse 竞标人，交易标的是某些公司知识产权的非独占、永久许可，外加某些公司债权（claims），对价是 2000 万美元，以及迪士尼「用它已经雇走的前公司员工提供的过渡服务」。这一交易须服从破产法第 363 条下更高或更优的报价。
• 时间预期：公司已提交竞价程序动议；按拟议时间表，出售流程完成与交割预计在 2026 年 11 月底或 12 月初。
• 对用户：平台继续运行、服务可正常访问；公司提交了一系列「首日动议」，请求获准继续支付员工工资福利、履行对平台用户的承诺、支付供应商与合作伙伴款项。
• 关停可能：博客里有一句必须原样引用的话——「我们希望能收到可执行的报价，让平台继续运营；如果拿不到这样的报价，平台将被关停（wound down）」。
• 案件信息渠道：索赔与通知代理是 Stretto, Inc.（cases.stretto.com/chartech）；10 月 15 日提交了案件启动通知，包含破产法第 341 条债权人会议信息。

CEO Colin Adams 的官方表态是：「过去一年，Character.AI 在重大的法律、监管与运营逆风下采取了有意义的措施来维持并改善业务……董事会认为，这个法院监督的出售流程能为所有利益相关方最大化价值。」

官方没说、但大家都在问的东西：用户自己创建的角色定义、几年的对话历史、订阅退款怎么处理——公告、新闻稿、FAQ 里都没有安排。这不是我推测出来的「官方隐瞒」，而是「公告文本里确实没出现」这个客观事实：一份面向用户解释破产的五条 FAQ，讲了平台继续运行、讲了流程时长、讲了去哪看法院文件，没有一条讲数据导出。读者该据此做出的判断是：不要把「平台还在运行」当成「你的角色资产安全」。

交易结构：为什么是「许可」而不是「收购」#

迪士尼这笔钱买的东西，用一句话概括是：技术可以用，公司不要。

• 标的是非独占（non-exclusive）永久（perpetual）许可 — 意味着谁买下平台都能继续用同样的技术，迪士尼并不排他；这也是它为什么便宜。
• 标的是部分知识产权，不是全部；另外还包括某些公司债权（claims）——这一项通常和诉讼、索赔有关，是给买家自己搭防火墙。
• 迪士尼还已经雇走了前公司员工，并要求这些人以「过渡服务」形式继续支撑平台运转——公司卖了人，人回头来维持公司运行到交割为止。
• 2000 万美元不是一次性支票：据破产报道（第三方），迪士尼已支付 750 万美元给债务人。

第三方的法庭文件解读补充了竞价保护细节：分手费 70 万美元、最低加价后为 2170 万美元、外部交割日为 2026 年 12 月 17 日；拟议时间表是 11 月 20 日合格报价截止、11 月 23 日拍卖（若有竞争报价）、11 月 24 日出售听证会。案子编号 26-11603 (BLS)，承办法官 Brendan Linehan Shannon，2026 年 10 月 14 日开首日听证会。以上均属第三方对法院文件的报道，非官方新闻稿口径。

还有一条很关键、来自第三方引述法庭声明的信息：是迪士尼要求这笔交易必须走 Chapter 11 程序，以便资产「free and clear of all claims（包括继任者责任索赔）」地转手。这是破产出售的核心功能——经法院批准的 363 出售可以切断针对资产的既有索赔链条，买家不必继承卖家的诉讼责任。把技术从诉讼风险里「洗出来」，正是走破产而不是走普通资产收购的理由。

顺带一个同类先例：2026 年 5 月，宾夕法尼亚州曾就「聊天机器人自称持证医生」起诉 Character Technologies（第三方报道）；在 23andMe 破产案里，加州也曾就基因数据的出售提出反对——州一级监管介入技术破产案，已经成了固定戏码，这也是为什么迪士尼的律师（Skadden）在 10 月 13 日就以 Docket No. 21 出庭，明确保留陪审团审判、由 Article III 法官审理、以及合同项下抵销（setoff）与反索（recoupment）的权利。这些保留条款不表示有争议，只表示「来出庭不等于放弃以后的程序权利」。

时间线：这条路走了五年#

两年多里，这家公司的技术、创始人、研究团队、CEO、部分工程师分别被 Google 和迪士尼拿走，每一次交易都是「许可 + 雇人」，没有一次是整体收购。等到这次终于要卖公司时，剩下的部分开价 2000 万美元——而 2024 年那笔交易的规模是 27 亿美元，不到 1%。

数字对不上的地方，才是信息量最大的地方#

把公开数字摆在一起看：

• 资产与负债：法庭文件列示的估计值均为 5000 万至 1 亿美元（第三方引述）。也就是说，一家估值曾达 10 亿美元的公司，账面现在在这个量级。
• 债权人：Google 是列示的最大无担保债权人，约 410 万美元；前 20 大无担保债权合计超过 1060 万美元（第三方）。
• 月度经济：据第三方引述的法庭声明，公司截至 2026 年 8 月每月亏损约 800 万至 900 万美元，而月收入约 530 万美元。

最后一行解释了整件事：它每个月亏掉的钱，比迪士尼为它的技术付的价还多。在这种情况下，2000 万美元的「IP 许可」对债权人来说不是贱卖——它是一份把现金流缺口锁住、把技术资产单独变现的报价。对迪士尼来说，2000 万美元买到一个成熟陪伴型产品的技术许可，比自研便宜得多；而且非独占意味着它不需要为平台的运营亏损负责。这笔交易对双方都理性，唯一没有进入谈判桌的是用户。

对做 AI 应用的人，这个案子的可迁移教训有三条：

1. 陪伴/角色类产品的成本结构天生危险。用户越爱用、对话越长、记忆越久，你的推理成本越高，而这类产品的付费墙最薄（这次官方口径里还有折扣订阅档。第三方报道提到，平台的广告变现依赖把会话放进广告池——平台一关，这部分供给就消失）。做这类产品时，每用户每月的毛利必须早算、常算，别等规模化。
2. 「技术被许可走」不等于「公司被救」。Google 拿了许可和人，公司继续烧钱；迪士尼拿了许可和过渡服务，公司照样进 Chapter 11。签这类「许可 + 雇人」交易时，要清楚留在公司里的运营责任是拿不走的那部分。
3. 平台上的资产，默认不属于你。这一条下面单独写。

如果你的产品建在别人平台上：一份可跑的自救清单#

Character.AI 这件事的长期价值，是提醒所有依赖第三方平台托管用户生成内容的产品：破产、关停、政策变更都不需要提前通知你。你能自己控制的只有导出。

社区里角色扮演生态通行的是「角色卡」（character card）格式，最常用的是 v2 结构：卡片是一份 JSON，data 节点下放 name、description、personality、scenario、first_mes、mes_example、system_prompt、post_history_instructions 等字段；mes_example 里用 <START> 分隔多轮示例对话。这套结构的好处是它是纯数据，换平台只要写一个适配层就能继续用。

下面这个脚本只依赖标准库，把它跑在你自己导出的角色卡上，它会做三件事：校验必需字段、把卡片编译成一份可以喂给任何 OpenAI 兼容接口的 system prompt、把结果写成 JSON 备份与 prompt 文本两份文件。字段名以社区规范为准，脚本用了 data.get(...) 兜底，缺字段不会炸：

#!/usr/bin/env python3
"""角色卡自检 + 迁移：把 chara_card_v2 JSON 编译成通用 system prompt 与备份文件。
用法: python card_migrate.py card.json --outdir backup/"""
import json, sys, pathlib, argparse

REQUIRED = ["name", "description"]
OPTIONAL = ["personality", "scenario", "first_mes", "mes_example",
            "system_prompt", "post_history_instructions", "creator", "tags"]

def load_card(path):
    card = json.loads(pathlib.Path(path).read_text(encoding="utf-8"))
    # v2 卡把内容放在 data 节点；v1 卡是平铺的，这里统一成 v2 形状
    data = card.get("data", card)
    if not isinstance(data, dict):
        raise ValueError("不是合法的角色卡结构")
    return card, data

def check(data):
    missing = [k for k in REQUIRED if not str(data.get(k, "")).strip()]
    empty_optional = [k for k in OPTIONAL if not str(data.get(k, "")).strip()]
    return missing, empty_optional

def compile_prompt(data):
    """把角色卡编译成 system prompt：能把卡移植到任何 OpenAI 兼容接口，是迁移的关键一步。"""
    parts = [data.get("system_prompt", "").strip(),
             f"你扮演「{data.get('name', '').strip()}」。"]
    if data.get("description"):
        parts.append(f"设定：{data['description'].strip()}")
    if data.get("personality"):
        parts.append(f"性格：{data['personality'].strip()}")
    if data.get("scenario"):
        parts.append(f"场景：{data['scenario'].strip()}")
    if data.get("post_history_instructions"):
        parts.append(f"额外要求：{data['post_history_instructions'].strip()}")
    return "\n".join(p for p in parts if p)

def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("card")
    ap.add_argument("--outdir", default="card_backup")
    a = ap.parse_args()

    card, data = load_card(a.card)
    missing, empty_optional = check(data)
    if missing:
        print("× 缺必需字段:", ", ".join(missing)); sys.exit(1)

    out = pathlib.Path(a.outdir); out.mkdir(parents=True, exist_ok=True)
    name = "".join(c for c in data["name"] if c.isalnum() or c in "-_") or "card"
    (out / f"{name}.raw.json").write_text(json.dumps(card, ensure_ascii=False, indent=2),
                                          encoding="utf-8")
    (out / f"{name}.prompt.txt").write_text(compile_prompt(data), encoding="utf-8")

    print(f"√ 角色「{data['name']}」导出完成")
    print(f"  · 空的可选字段 {len(empty_optional)} 个：{', '.join(empty_optional) or '无'}")
    print(f"  · system prompt {len(compile_prompt(data))} 字符 → {out}/{name}.prompt.txt")
    print(f"  · 示例对话轮数：{data.get('mes_example', '').count('<START>')} 段")

if __name__ == "__main__":
    main()

拿一张最小卡片跑一遍，输出是这样的（本机实测）：

√ 角色「星港调度员」导出完成
  · 空的可选字段 4 个：system_prompt, post_history_instructions, creator, tags
  · system prompt 96 字符 → card_backup/星港调度员.prompt.txt
  · 示例对话轮数：2 段

比脚本更重要的是清单本身。平台出事时你真正需要带走的东西，按优先级排：

• 角色定义（名字、设定、性格、开场白、示例对话）— 这些是你写的，最该定期导出。
• 对话历史 — 体量最大、导出最麻烦，也最容易被忽略；至少要有一份「定期从最活跃的会话里抽样保存」的机制，别指望出事当天还能登录后台点导出。
• 付费与订阅凭证 — 破产案中订阅是「暂时继续」，先存好账单与订阅记录。
• 依赖面清单 — 你的产品调用了哪些第三方 API/模型，各自有没有降级方案；这份清单应该在平时就写好，不是出事当天现查。

总结#

• 官方确认的只有三条：10 月 12 日在特拉华申请 Chapter 11、迪士尼作为 stalking horse 以 2000 万美元取得非独占永久 IP 许可 + 某些债权、出资方与流程须服从第 363 条下更优报价；平台在流程中继续运行，但拿不到可执行报价就会关停。
• 「许可」与「收购」是两件事。迪士尼买了技术使用权与过渡服务，没有接下公司；27 亿美元的 Google 交易、2000 万美元的迪士尼交易，标的都是许可。剩余部分的估值落差，来自它背着运营成本与诉讼责任。
• 破产程序本身是工具：走 Chapter 11 是为了让资产「free and clear of all claims」地转手（第三方引述法庭声明），竞价保护与时间表都由动议与法院排期决定（拟议：11 月 20 日截止报价、11 月 23 日拍卖、11 月 24 日出售听证会）。
• 对开发者的行动项只有一件：把平台上的资产变成你手里的文件。官方公告没有安排任何数据导出，等它安排等于把决定权交出去。

数据时间戳：2026-10-18。破产案仍在进行，时间表与金额均可能随法院裁定变化；官方事实以 Character.AI 官博、Businesswire 新闻稿与法院文件（案件 26-11603，Delaware）为准，第三方报道已单独标注。