HeyGen 创始人 Joshua Xu 今天在推特宣布，HeyGen 在本月达到了 1 亿美元的 ARR。从首次达到 100 万美元 ARR，到 1 亿美元，HeyGen 花了 29 个月的时间。
怎么做到的？
HeyGen 的回答是：速度就是一切。想清楚什么在变，什么不变，围绕不变的东西来构建产品和系统，享受模型改进带来的红利。
Joshua Xu 在推特上分享了了一份 AI 创业 Playbook——「无数次团队讨论、实验和一路走来吸取的教训的结晶」。公司内部是如何思考、 如何协作、如何决策、如何保持发布速度比对手快 5 倍的核心方法论，几乎完整地公开了出来，很坦诚。
以下是完整内容，Founder Park 进行了编译和适当调整。要点很多，推荐全文阅读。
原文链接：
https://x.com/joshua_xu_/article/1978837502787219578
超 15000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。
进群后，你有机会得到：
最新、最值得关注的 AI 新品资讯；
不定期赠送热门新品的邀请码、会员码；
最精准的AI产品曝光渠道
HeyGen 的使命很简单：让每个人都能用视觉化的方式讲故事。
我们把视频分成两种：
沟通型视频：比如，同步业务进展、做个教程、录个访谈、播客或者产品讲解。这类视频的目的就是为了说清楚一件事。 （用脚本来编辑最合适。)
电影感视频：比如，制作精良的广告、电影、MV、预告片，还有那些高端的品牌内容。这类视频是为了打动人、启发人或者纯粹为了娱乐。（用时间线来编辑更方便。)
我们的全部精力都放在第一种视频上，想让它变得人人可用。
我们说的「人人」，是指任何水平的人，不管你是零基础的新手到经验丰富的专业人士。我们的产品足够简单，任何人花几分钟就能做出来一个质量不错的视频。
为什么会有这本小册子？
传统的软件开发模式已经死了。过去的开发常识，现在正在变动。AI 时代，每隔几个月就有一次技术突破，昨天还觉得不可能的事，明天就成了基本操作。
在 HeyGen，我们不跟这种不确定性对抗，我们选择跟着趋势走。我们的整个开发哲学，就是围绕如何 AI 的发展来建立的，而不是去寻找根本就不存在的、所谓的「稳定技术基础」。
这本小册子，就是想讲清楚我们是怎么思考、怎么做产品、怎么赢的。它写给 HeyGen 的每一位同事，工程师、设计师、产品经理，也写给那些想加入我们的人。它告诉你，当「地基」不断变化时，我们是如何工作的，以及我们是如何把这种不确定性变成我们的竞争优势的。
01
其实就一句话：「快速行动，做到极致。驾驭 AI 浪潮，接受研究本身的不确定性，提前六个月布局，并做出能随着模型升级而能力提升的灵活产品，但绝不以牺牲质量为代价。」
1.1 一个根本性的变化：从找「地基」到驾驭「浪潮」
在 AI 时代，我们工作的前提就是不再依赖一个稳定的技术「地基」。每隔几个月，AI 技术就会发生翻天覆地的变化。模型能做什么，不能做什么，没人说得准，而且一直在变。
我们正处在一个百年一遇的技术窗口期。未来 12 个月，AI 就是我们这代人的「战争」。我们有机会做出下一个 Google 或 Facebook。机会就在眼前，我们必须把强度拉满。这才是大家来 HeyGen 的原因，也是我们聚在这里的理由。
一个关键的区别：不过，说「拥抱不确定性」，我们指的只是底层的 AI 技术基础：模型、能力、研究突破。但在服务稳定性、产品质量和用户体验上，我们绝不接受任何不确定性。就算脚下的「地基」不断变化，我们给用户的东西也必须绝对可靠。
这不是一个 Bug，而是我们的机会。我们选择顺着趋势走。
| 传统时代 | AI 时代（我们的方式） |
| 在稳固的地基上盖楼 | 在技术浪潮上冲浪 |
| 追求用得久 | 做出来就能自动升级 |
| 做 12-18 个月的计划 | 实际点，计划未来的 2 个月 （正好跟上模型升级的节奏） |
| 打磨到完美再发布 | 为了学习而发布 |
| 一步一步来 | 同时做各种实验 |
1.2 这和敏捷开发有什么不一样？
传统的敏捷开发，默认了技术本身是相对稳定的，能力也是可预测的。但我们面对的环境是，基础技术每几个月就「变天」了。所以，我们的方法虽然借鉴了敏捷的原则，但我们优化的核心是应对技术的剧变，而不是在一个稳定的环境里小步快跑。
1.3 冲浪者的优势
竞争对手总想找块坚实的土地，结果被下一波技术飞跃打得措手不及。我们从一开始就想着让产品能随着模型变强而自动升级。我们选择冲浪，而不是跟浪对抗。
想清楚什么在变，什么不变：对我们来说，想清楚哪些东西短期内会变（比如模型、能力），哪些东西大概率不会变（比如用户的工作流程、核心痛点）非常重要。我们要围绕不变的东西来构建产品和系统，同时享受模型改进带来的红利。
一些冲浪的机会：
In-context learning、fine-tuning 与 RAG 方法的权衡
语音模型后处理能力的提升
如何优化一个集成了多家供应商的系统
1.4 关于质量的悖论
我们既要行动快，又要做到最好。这听起来是不是很矛盾？但只要你明白这一点就不矛盾了：行动快，才能让我们长期做出更好的东西，也才能更快地给用户创造价值。当别人一个月发布一个功能时，我们已经试了五次。我们的学习速度是他们的五倍。这种学习带来的复利，最终会变成产品的巨大优势。
记住，快不是指功能上得快，而是指用户价值交付得快（以及快速学习）。速度，是为了「做到最好」这个终极目标服务的。
特别是视频内容，质量是绝不能妥协的。用户喜欢一个产品，不是因为你界面好看，而是因为它能用极高的质量解决他们的问题。我们衡量成功的标准很简单：任何用户在我们平台上做出的视频，能达到的平均质量是多少。
02
2.1 我们的节奏：为期两个月的浪潮周期
为什么是两个月？因为这刚好和 AI 模型的升级节奏差不多，能让我们在保持专注的同时，又能灵活地调整方向。
我们的节奏是这样的：
每两个月规划一次路线图：跟 AI 的发展周期是同步的。领导层、技术负责人和产品经理（我们也鼓励设计师参加）会坐下来，深入复盘产品和策略。为了聊得透彻，最好在线下进行。我们会非常坦诚地评估自己的表现，该调整策略就调整。
6-12 个月的战略布局：预测并为下一个大机会做准备。
每两周出一份承诺清单：产品和工程团队一起定下来，接下来两周各自要交付什么。
每天都发布：每天都有新的改进、功能或者实验上线。
背后的想法是：短周期让我们能跟上 AI 的发展节奏。这个周期足够长，能让我们做点有意义的事；也足够短，能在技术风向变的时候及时调整。
2.2 如何做「冲浪」实验
注意：这个框架更适合已有的产品和增长方向，对于那些需要更长探索时间的新功能和研究，可能不太适用。
第 1 天：想清楚假设和成功的标准。
第 2 天：做出一个 MVP（真正意义上最简可行的那种）。
第 3-5 天：发给一小部分用户试试。
第 2 周：分析数据，总结学到的东西，决定下一步怎么走。
一个好的实验 | 失败的实验 |
|---|---|
快的（几天搞定，别拖几周）。 | 大部分实验都会失败，这很正常。 |
科学的，有数据支撑。 | 从失败中学到了东西 = 胜利。 |
能给出明确信号的：继续、换个方向，还是停掉。 | 失败了但什么都没学到 = 真正的失败。 |
赌个大的，而不是小修小补。 （我们还没到那个阶段） | 别让一个实验拖到最后什么结论都得不出来。 |
2.3 如何做出「浪潮般」的快速决策
决策框架：很简单，就问一个问题：这是个「单向门」，还是「双向门」？
单向门：出去了就回不来的那种决策，要非常谨慎（很少见）。
双向门：随时可以反悔的决策，产品经理快速决定，马上测试（很常见）。 当有争论时，问问自己：这事能测试吗？如果能，那就别吵了，直接动手做实验。
如何沟通决策：
有了决定，马上在 Slack 里说清楚，指定一个人负责，明确完成时间。
团队之间要完全透明。
不仅要说计划，还要说为什么这么定。
清楚地告诉大家，这个决定需要同步给谁。
2.4 押注 6 个月后的未来
虽然我们只做两个月的具体计划，但得盯着 6 到 12 个月外的地方做战略布局。这要求我们：
时刻关注 AI 研究的最新进展。
理解算力的发展趋势。
预测模型接下来会具备什么能力。
搭建能从未来的技术进步中受益的灵活架构。
2.5 如何在快速行动中管理技术债
核心原则：你做的东西，要默认它以后会被替换掉。
搭建的抽象层，要假设它未来会变（但提醒一句：时机不成熟时别过度设计）。
写文档，要记录你的假设，而不是具体的实现方法。
所有东西都严格做好版本控制。
设计的系统要能随着模型升级而自动变好。
怎么看待技术债：我们的原则是，把还技术债看成是对未来速度的投资。如果一项工作能明显提升团队效率和系统可靠性，我们就应该鼓励和庆祝。还技术债的工作，必须和业务结果、效率提升挂钩。
03
3.1 速度就是一切，没得商量
新的现实：在 AI 时代，谁学得快，谁就赢。就这么简单。
以天为单位发布，不是周。
拿不准的时候，就发个实验。
保持前进的势头比追求完美更重要。
慢，是唯一不可原谅的罪。
具体怎么做：
MVP 是用来验证想法的，不是最终产品。
一个「足够好」且及时的东西，远胜于一个「完美」但迟到的。
先发布不完美的，再跟进：如果不行就果断砍掉，如果用户在乎就持续迭代到最好。
Bug 比不完美的功能更糟糕，因为 Bug 会让你学不到东西。
速度是一种态度
速度不只是执行快。它是一种心态。我们从不会说「为了安全，咱们等到周一再发吧」。这种想法暴露了紧迫感的缺失，不想更快学习（白白浪费 2-3 天宝贵的数据），主人翁意识不强，以及对执行能力的不自信。这种心态会让我们输掉。赢家会主动负责，快速发布，快速学习，快速适应。
先行动，别总想着完美
如果你总想着确保自己是对的，那你行动就太慢了。别怕犯错，要怕的是学得太慢。
3.2 拥抱技术浪潮
别再指望技术稳定了，这不存在。AI 的「地基」每两个月就会变一次。你应该这样设计产品：当模型升级时，它能自动变好。让你的产品体验驾驭在 AI 进步的浪潮之上，而不是被它甩在身后。
3.3 充分讨论，坚决执行
现在是「战时」，不是和平时期。每个人都可以提意见，但决策必须快。一旦决定了，就算你之前不同意，也要百分之百投入去执行。因为执行不到位导致的战略失败，比一个可以快速纠正的错误决策要可怕得多。
3.4 通过创新实现用户价值
用户喜欢的是能解决他们问题的产品，而不是漂亮的界面。创新和用户的喜爱是绑在一起的。我们致力于用 AI 颠覆人们创作视频的方式，创造过去不可能实现的奇妙体验。但是，如果创新不能解决真实的问题，那就毫无价值。
新手入门的挑战：
用户水平不同，用 AI 产品做出来的东西差别巨大。
我们的责任是：教会用户怎么用，而不只是介绍功能。
成功的标准 = 任何一个用户，平均能做出多高质量的视频。
我们要衡量的是视频的质量，而不仅仅是创建了多少视频。
3.5 自研还是外购：一个简单的原则
哪个能给用户带来最好的体验，我们就选哪个。
我们自己做：Avatar 视频模型（因为没有外部供应商能达到我们的质量要求）。
用别人的：语音（外面的供应商质量足够好，我们也能省下资源）。我们不纠结面子，只要结果。
04
4.1 通用的团队结构
所有团队都一样：产品经理（PM） + 工程师 + 设计师 + 数据科学家。
4.2 每个角色是干什么的
产品经理：总指挥
| 他们主要干什么 | 他们需要会什么 |
| 推动决策和定优先级。 | 能上手做出可用的 MVP 和体验原型。 |
| 直接跟老板们沟通策略。 | 能把复杂的技术概念，用简单的语言讲给用户听。 |
| 为每个功能背后的「为什么」负责。 | 主导「先做原型」的工作方式。 |
| 协调工程师、数据科学家和设计师。 | - |
在 AI 时代的新要求：
直接做能用的原型，别再写又长又臭的文档了。
用 Figma 设计稿或者体验原型本身当文档。
规划那些眼下还不存在的能力。
非常熟悉市面上所有的 AI 工具，并且每天都在用。
工程师：快速构建者
他们主要干什么：
用最快的速度把决定好的东西做出来。
提供产品经理可能会忽略的技术视角。
设计的架构要灵活，方便快速迭代。
深入理解做这件事背后的「为什么」。
在 AI 时代的侧重点：
用 AI 编程助手（比如 Cursor、ChatGPT）来提速。以前我们总说 10 倍工程师，现在我不确定有没有 10 倍，但有了 AI 工具，每个人的效率至少是两年前的 3 倍。
做的原型，要有能进化成正式产品的潜力。
少写文档，多写代码。
直接跟 PM 一起快速做原型。
设计师：化繁为简的大师
他们的主要角色：定义出简单又出色的体验。
设计的使命：作为一个视频创意工具，我们的设计必须是世界级的。不然，我们就无法让这个工具被所有人使用。所以，我们设计的第一原则就是：简洁。
在 AI 领域，让一个东西能用不难，难的是在保持高质量的同时，让它用起来极其简单。这是我们设计团队的核心任务。
他们主要干什么：
能上手做出可用的 MVP 和体验原型。
把原型打磨成消费级的、让人用着开心的体验。
确保所有功能都和谐地统一在 HeyGen 的产品框架里，并建立和维护设计规范。
坚守我们的原则：简单到连我奶奶都会用。
主导简化的工作——如果我奶奶用着都费劲，设计师就得站出来解决它。
维护好设计系统，让未来的开发能保持一致和快速。
帮助把产品营销做得更简单易懂。
在功能被验证后，专注于视觉打磨和体验的一致性。
在 AI 时代的侧重点：
一个关键原则：为了保证速度，设计师的重点是在想法被验证之后，把体验做到极致，而不是在早期探索阶段就过度投入。他们是「简单到奶奶都会用」原则的守护者，这是一个在想法验证后，需要真正专业知识才能解决的巨大挑战。
数据科学家 & PM：分析搭档
数据科学家干什么：
解释和验证指标：确保大家对数据的理解是一致的。
做统计分析：相关性、因果关系推断等。
建立 PostHog 里搞不定的高级实验指标。
为成熟的功能搭建公司级的数据看板。
做需要高级 SQL/Python 的复杂分析。
做一些轻量级的数据工程和建模。
普及数据科学的知识和术语。
PM 干什么：
熟悉自己领域的核心数据，能发现异常并着手调查。
用 PostHog 看数据趋势和用户行为。
能从 Hex 的主表里拉一些简单数据。
主动管理实验的全过程，包括事前的测试和事后的清理。
设计实验方案——给谁看，怎么分组，成功的标准是什么。
想清楚需要埋哪些点来衡量效果。
初步判断实验哪个版本胜出。
理解自己领域的数据和公司战略的关系，能在发布决策时做出高质量的判断。
应该能自己在 PostHog 里做分析，在 Hex 里写简单的查询。
俩人一起干什么：
分析实验的影响——一起解读结果。
定义关键指标（比如 AER、留存、转化）。
当需要深入分析时，一起复盘实验。
调查数据异常。
4.3 平等的伙伴，但分工明确
PM 帮助定义「做什么」：
工程师 确定「怎么做」：
设计师 确保「简单易用」：
让复杂的 AI 人人可用
守住「奶奶测试」的底线
创造愉悦的体验
数据科学家 提供「事实」：
所有人都要对「为什么做」有共识：
这事为什么值得做？
我们在为谁解决什么问题？
为什么是现在？为什么用这个方法？
这事怎么能帮公司往前走？
4.4 做原型的流程
理念：在传统的软件开发里，PM、设计师、工程师是「铁三角」。但在快节奏的 AI 时代，我们更关心速度和学习，而不是完美的流程。
灵活的搭档模式：PM 和设计师的合作可以很灵活。有些 PM 更懂体验，那就他来主导原型；有些设计师深谙 AI，可以主导原型开发。
两人原则：原则上，一个 PM/设计师，加一个工程师，两个人就能开干一个原型。我们不为了照顾每个人的情绪而去追求所有人都同意。我们来这是为了加速验证想法，好让我们能做出更好的产品。
每个人都有机会为新想法做原型。在 AI 时代，可以做的东西简直是无限的（就像我们在黑客松里做出的那些东西一样，太棒了）。关键是要有一个小而精的团队来快速做决定。
通用的方法：
原型先行：PM/设计师和工程师直接搭档，快速把想法做出来测试。
证明它行：在投入大量设计之前，先用真实用户验证这个想法。
设计打磨：一旦被证明可行，设计师再介入，把体验打磨好，确保它和整个产品风格统一且简单。
达到上线标准：任何一个从原型毕业要上线的功，都必须是经过精心设计的。
为什么这么做：AI 功能有巨大的不确定性，大部分原型可能都行不通。在没被验证的想法上过度投入设计，纯属浪费时间。但是，最终交到用户手里的东西，必须达到我们的质量标准。
05
5.1 他们干什么：构建和打磨产品的核心功能
核心产品团队，专注的是最基础的产品体验，那些定义了 HeyGen 是什么、能做什么的功能。他们追求的是极致的用户体验、完整的功能和长期的产品愿景。
核心产品团队的特点：
做复杂功能时，开发周期更长。
非常关注产品体验和用户走过的每一步。
强调设计系统和体验的一致性。
需要和整个产品生态系统打通。
我们虽然做的是个商业工具，但对于一个创意工具来说，让人用得爽太重要了，这也是 HeyGen 能不能做到一亿用户的关键。
5.2 核心产品的标准
标准很简单：每一个体验，都要做到绝对的最好。任何差一点的，都算不及格。怎么做到？比你的对手快 5 倍，迭代次数是他们的 5 倍。
5.3 追求零 Bug
我们的目标应该是零 Bug。我们还没做到，但这是我们的方向。你去用那些顶级的创意工具，比如 Canva、Figma 或者 CapCut，你几乎碰不到 Bug，因为创意工作对精确性要求极高。作为一个创意工具，可靠不是加分项，而是必需品，它关乎用户的信任和工作能否继续。
06
6.1 增长团队是公司的实验引擎
增长团队和核心产品团队的玩法不一样。我们是实验引擎，为速度、学习和影响力而生。我们所有的原则，都只为了一个目的：提升我们的迭代速度。
6.2 增长团队的核心原则
工程只是工具，产生影响才是目的。
我们不只是交付代码，我们交付的是结果。在 AI 时代，代码不值钱，影响力才值钱。别为了追求代码优雅，去过度设计一个没人要的东西。你要优化的，是「多快能产生影响」：做那些最重要的事（20% 的投入，带来 80% 的结果），一旦被证明有效，就迭代，当价值真正体现出来后，再把它打磨好。
做实验是为了学习，不是为了赢
那些稳赚不赔的实验，根本算不上实验。做实验的目的，是通过冒聪明的风险、赌大胆的假设来学得更快。要愿意快速犯错，这样你才能更快地找到正确的路。
6.3 增长团队的重心
增长 PM：实验的指挥官
和团队一起做决定。
对数据和学习循环负责。
深入理解用户痛点和业务影响。
清晰地定义问题和目标。
定义「做什么」——框定问题、定义目标、理清背景。
和工程师一起明确「为什么做」——为什么这事值得干？为什么是现在？
有强烈的行动偏好，快速发起实验。
对结果负责，不只是对产出负责。
增长工程师：速度机器
和 PM、设计师一起设计方案。
负责搞定可行性、权衡和执行，目标是做得更好、更快、更聪明。
在明确「为什么做」的同时，塑造「怎么做」。
以最快的速度把实验做出来。
痴迷于学习循环和数据。
深入理解问题，而不只是等着别人告诉他「要做什么」。
理解了「为什么」，就能成为一个更主动的参与者，用更少的迭代交付更多的价值。
关注多快能产生影响，而不是完美的架构。
打造能改变公司发展轨迹的实验引擎。
6.4 增长团队有什么不同
增长团队和核心产品团队玩的是两种完全不同的游戏。核心产品团队专注于构建和打磨功能，而增长团队专注于快速实验和学习。在这场游戏里，速度就是一切，我们所有的原则都为此服务。
07
核心原则：
异步优先：我们办公室在不同地方，所以尽可能用异步的方式沟通。
会议警报：如果团队里有谁一周开超过 3 个、5 人以上的会，就得亮红灯了。
时间花在哪：我们的时间应该花在做东西上，不是开会上。
线下见面：利用线下见面的时间，实现最高效的沟通和团队建设。
决策怎么沟通：
有了决定，马上在 Slack 里说清楚，指定一个人负责，明确完成时间。团队之间要完全透明。不仅要说计划，还要说为什么这么定。清楚地告诉大家，这个决定需要同步给谁。
反馈怎么给：
直接说。做得好就是好，不好就是不好。对事不对人。当你收到反馈时，记住：这是在说事，不是在说你。每个人都有进步的空间。
08
8.1 AI 开发七宗罪
追求完美的架构
花好几周去设计一个能「扩展」的架构。
扩展想解决的问题是：你只有 100 个用户。
你真正的问题是：还没人爱你的产品。
研究到瘫痪
「我们需要做更多用户研究。」
聊了好几个月，一行代码没写。
更好的办法是：先做错，快速学习，再做对。
对稳定「地基」的幻想
总等着 AI 技术「成熟」。
还用 2019 年的思路做东西。
现实是：它永远不会稳定，去驾驭浪潮吧。
共识的陷阱
所有人都同意 = 没人在乎。
要有强烈的观点，但也要乐于被说服。
有争论，说明你可能碰到了真正重要的事。
以质量为借口
「这个还没准备好。」
「我再打磨一下。」
自信地发布，然后快速改进。
「憋大招」式发布
偷偷摸摸开发 6 个月。
然后搞个盛大发布。
结果发现，你的对手早就发布、早就学到了。
沉没成本谬误
「我们已经投了这么多了。」
快速砍掉失败的项目。
庆祝你学到的东西，然后删掉代码。
8.2 什么时候才应该真正慢下来
质量红线（没得商量）：
那些让你无法从实验中学到东西的 Bug。
安全漏洞。
明显伤害用户体验的功能。
影响到现有客户的破坏性改动。
战略性停顿（很少，但很重要）：
影响公司未来的「单向门」决策。
会影响未来 6 个月开发的技术架构决策。
当用户反馈告诉你，大方向错了。
法律或合规要求。
8.3 危险信号
如果你听到这些话，赶紧拉响警报：
「我们再多想想」 → 潜台词：我们已经落后了。
「我们得让所有相关方都同意」 → 潜台词：决策瘫痪要来了。
「万一技术变了怎么办？」 → 潜台词：它肯定会变，但我们还是得发。
「我们等下一个模型出来再说」 → 潜台词：我们的对手可不等。
「我们需要一个更稳健的方案」 → 潜台词：我们首先需要的是用户。
「这个还可以再打磨一下」 → 潜台词：先发出去，如果用户在乎再说。
09
9.1 我们为什么能赢
我们的发布速度比对手快 5 倍：更多的实验 = 更多的学习。
学习会产生复利，变成更好的产品：别人躲着走的东西，我们迎头赶上。
不确定性就是我们的优势：「老派」的竞争对手适应不了。
我们专注于真正重要的事：用户的质量，学习的速度，创新的差异化。
9.2 我们的七条「驾浪」原则（我们的追求）
快速行动，不妥协。
打造绝对最好的产品体验。
质量第一（尤其是视频的视觉质量）。
充分讨论，坚决执行。
拿不准？发个实验。
拥抱不稳定的 AI 开发——去驾驭浪潮。
通过整合来激发创新。
10
三年前，我们根本想象不到 AI 今天能做什么，那时连 ChatGPT 都没有。三年后，我们今天觉得最牛的东西，可能也会显得很古老。唯一不变的，就是变化本身。唯一的策略，就是驾驭浪潮。唯一的目标，就是用户价值。
我们没有所有问题的答案，但我们有一样更好的东西：业内最快的学习闭环。
每一天，我们都面临一个选择：是去寻找虚假的稳定，还是去驾驭浪潮。我们选择后者。我们选择去打造那种能随着 AI 进步而奇迹般变得更好的产品。我们选择快速发布，更快地学习，并最终取胜。
欢迎来到软件开发的未来。让我们一起做点了不起的事。
记住，快但要稳；创意要能整合；速度得有方向。
赶紧上，别纠结，顺势而为。
转载原创文章请添加微信：founderparker
更新时间：2025-10-19
本站资料均由网友自行发布提供，仅用于学习交流。如有版权问题，请与我联系，QQ：4156828
© CopyRight 2020- All Rights Reserved. Powered By bs178.com 闽ICP备11008920号
闽公网安备35020302034844号
