我把大二的一年，留在了「心元」里

有些人用大学四年寻找答案，而我在大二这一年，只顾着把一个问题做成现实。那一年，我把所有的昼夜留给了代码，也把自己留在了「心元」里。

开门见山：关于项目现状

在展开回忆前先作说明：目前我已经完全退出，不再参与「心元」项目的任何后续研发与运维。

这篇文章记录了我作为核心开发者，从零搭建起这套全端架构、AI 链路并推动商业交付的完整历程。主站的前端交互、流体毛玻璃视觉与多端AI角色对话能力同样由我一手敲定与开发，包括后面宣传运维图设计、产品逻辑与架构设计等等。如果好奇它最终落地的形态，可以由此窥见当时的心血：

心元(Xodn.com)官方网站

由我主导架构设计研发的角色AI交互平台

荒原上的宏大命题

2025 年初秋，故事始于一个看似宏大但早已在技术圈暗流涌动的题目。

学院领导引荐我们参与项目，带队的是 赵盛烨老师 （全网拥有 400 多万粉丝的知名科技博主与学者）。他刚好比我大整整 20 岁，既是师长，也是一位纯粹搞技术的人。从始至终，我与赵老师之间没有任何私人恩怨，全是纯粹的技术探讨、方案推演与工程共鸣。彼时黑板上落下的方向，带着极具野心的探索意味：

“做数字人，探索某种意义上的‘数字永生’。”

但在我看来，这谈不上什么虚妄的狂想。当时市面上海外的 Character.ai（c.ai）、国内的猫箱，以及开源极客圈里火热的“酒馆”（SillyTavern），早已验证了角色 AI 与人设交互的可行性。

我有十足的底气与信心能把它做出来。内心深处反倒没有盲目的狂妄，更多的是一种在狂奔中“追赶前人”的急迫与焦虑——甚至在某些深夜，我也会隐隐自问：市面上已有先例，我们这样拼命追赶，到底有没有用？

但无论如何，既然机会落到了手里，我只想用代码把答案敲出来。

2025 年秋（大二上） · 校园业余开荒

学院领导引荐立项，组建三人学生初创班底。前期全在学校利用课余时间边上课边摸索，纯属业余自发探索，无工资亦无考勤，摸索 C.ai 模式与数字分身可行性。

2026 寒假 · 千元民房与自费奠基

期末同伴渐次离场，一人退掉车票留宿。在月租一千的出租屋闭关狂啃 Flutter 跨端开发与流式大模型编排，自费奠定最初全端架构骨架。

2026 年春（大二下初） · 独挑大梁与班级引援

新学期开学，依然在校内利用业余时间推进。独立攻克 Blendshapes 面部对口型方案，因人手断层甚至回班级拉同学共同开发。

2026 年 5 月 · 天使轮进场、每日业务打卡与全面旷课

天使轮资本与资方进场，从校园业余骤变商业高压。开始推行严格的每日业务打卡与工作汇报。为保住三端交付死线，我大二下学期所有课全都没去上，天天整日整夜拼命干，每月补贴仅 1000 元。

2026 年 6 月 · 旷课的代价：期末考场与公测死线

一边是旷课数月、空白一片的期末试卷，一边是赵老师微博宣发的上线死线。白天进考场硬着头皮答卷，夜晚在屏幕前通宵改 Bug 跑打包，如期上线雪峰智能体。

2026 盛夏（7-8月） · 小区工位、借钱度日与股权剥离

暑期进驻居民楼工位。遭遇工资拖发、报销无门、借钱度日与会议诛心评语；在底层大厦浇筑完成后，最终被彻底踢出公司，所有股权被迫全部转让清退。

团队最初是校内临时拼凑起来的，设立了专门的组长。技术班底起初共有三人，两位学长均比我高一届（大三），而彼时的我才刚踏入大二。

在赵老师找到我们时，了解完他的公众声量与深厚背景，我心里其实有着超越同龄人的清醒：找我们这群涉世未深的大学生开公司，在某种意义上，我们也许只是一颗被推到前台的棋子。

但我并不甘于只做一颗被动的棋子。我想互相借助这个难得的平台——借赵老师的影响力与时代机遇为跳板，为我们搭建真正能让学生团队落地成长、孵化技术的舞台。因此在成立公司之初，我甚至主动申请担任了公司的法定代表人（法人）。

我抱着最大的纯粹与赤诚，想借着平台做出一番成就。在暑期之前——无论是大二上的初探、寒假闭关，还是大二下前半学期，我自始至终都是在学校里干，完全属于课余与业余时间的自发摸索。没有资方监控，没有考勤打卡，更无人论及报酬。

然而，当蓝图落地为枯燥的代码，其余两位技术并未真正放在心上。有人退守日常，有人动力缺缺，三人班底很快减员至两人，技术大梁不可逆地全面压向了我一人。

纯凭胸膛里翻滚的一腔少年热血与对新技术的执迷，我咬牙扛了下来。可那时的我未曾料到，在冷酷的商业法则里，一个人干得太多、太纯粹、不遗余力地交付了所有成果，换来的往往不是同等的尊重，而是棋子在物尽其用后的弃置。在无数次深夜改 Bug 陷入迷茫时，我曾向赵老师倾诉过内心的动摇：

2025 年冬 · 深夜的对话

我

老师，同组的人好像都退回各自的生活节奏了……现在只剩下我一个人写底层架构和三端适配，我有点不知道还能扛多久。

赵老师

长征万里，总有人掉队，你继续走就好。

我

……我明白了。您放心，我继续往前走。

那一刻我只是听到了这句话。而真正嚼碎并咽下它的苦涩，是在很久之后。

做事情的人终究会明白：你永远无法等待所有人都准备好才启程。既然选择了远方，总得有人先踩碎脚下的荆棘。

一千块出租屋里的寒冬与火

真正让我斩断退路的，是那个寒假。

彼时我正疯狂吸收 Flutter 的一切。我渴望写出一个真正意义上的现代化 App——不是课程设计里单薄的 Demo，而是一个有血有肉、能在真实设备上稳定运行的完整产品。

我决定把 Flutter 与「心元」彻底绑定。

那个寒假我退掉了回家的车票，在学校外租了一间月租一千块的民房。

没有窗明几净的孵化器，没有写满排期的白板，没有所谓的创业光环。陪伴我的，只有一张简陋的书桌、一台性能吃紧发烫的电脑、一台中继信号时好时坏的移动 Wi-Fi，以及永远温吞的外卖。

一间逼仄的房间
一台发烫的电脑
闪烁的移动 Wi-Fi 信号
屏幕上无尽滚动的编译日志
和一个前途未卜的项目

除夕前夕，窗外是万家团圆的鞭炮声，我握着手机给父母打电话，声音平静却笃定：

除夕前夕 · 民房里的报喜电话

母亲

孩子，除夕了怎么还没买票回家？学校那边那么冷，食堂都关门了，你一个人在外面吃得饱穿得暖吗？

我

妈，你们别担心！我在学校抓到了一个很难得的项目机会，正在做一款属于自己的跨端 AI 产品，外卖天天都能送到，我挺好的！

母亲

别太拼了，缺钱了随时跟家里讲，身体最重要啊。

我

好嘞，等我做出成绩来，一定带给你们看！

那时的我相信，只要我不停下敲击键盘的手，代码就一定会给出答案。

拆解神话：AI 狂飙、C.ai 与数字人形象对口型

大二下开学，AI 领域的浪潮呼啸而至，技术的演进快得令人窒息。

「心元」的内核，本质就是实现与特定角色的 AI 拟人交互，业务形态非常像海外爆火的 Character.ai（C.ai）——面向真实用户，提供对逝去亲人、历史伟人、网络名人等语料与性格的蒸馏与数字分身克隆。

寒假期间我便开始猛啃 AI 体系。我从底层最基础的 messages[] 数组开始，一层层向下剥离概念的伪装。从 System、User、Assistant 的角色划分，到 Context 上下文构建、Function Calling、Tool Calling，再到让大模型展现深度思考推理链路的 Reasoning Content 与 Prompt Engineering。

起初，项目要求使用提示词工程复刻还原“雷锋同志”。另一位技术在 2025 年上半年主要负责这个角色的对话落地，而整套方案中最残酷的技术瓶颈正是：形象渲染与高保真“对口型”（Lip-sync）。当时对方在形象对口型方案上陷入停滞，这套关键的数字人技术选型与开源部署路线，最终还是由我一手调研、验证并提供项目工程，供其部署并成功上线的。

我越来越清晰地看透：「心元」的灵魂从来不是一张静态生成的数字面孔，而是它能否在时间的流逝中，与人类建立起长久的温度与羁绊。

它开始蜕变为一套有机的整体：AI 角色人格 + 上下文机制 + 长期记忆体系 + 数字人多模态表达。

让大模型给出单次回答轻而易举，但让它在成百上千轮对话后依然“记得你”，却是一道残酷的工程险峰。

最开始，历史记录可以野蛮地塞进请求。但 Token 窗口与计费成本的天花板很快压了下来。我重构了一套滑动窗口 + 语义摘要 + 向量检索（RAG）的分级上下文策略：

               ┌───────────────────────────────┐
               │         用户最新输入          │
               └───────────────┬───────────────┘
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
┌───────────────────────┐             ┌───────────────────────┐
│     短期工作记忆      │             │     长期向量记忆      │
│  Sliding Window (K轮) │             │ Embedding + Cosine    │
└───────────┬───────────┘             └───────────┬───────────┘
            │                                     │
            └──────────────────┬──────────────────┘
                               ▼
               ┌───────────────────────────────┐
               │    动态组装 Context Prompt     │
               │   (Token Budget 剪裁与压缩)   │
               └───────────────┬───────────────┘
                               ▼
               ┌───────────────────────────────┐
               │       LLM 推理与异步沉淀      │
               └───────────────────────────────┘

为了让记忆拥有生命力，我引入了基于时间维度的衰减权重设计，让高频交互的情感锚点持久留存，而琐碎细节自然淡化：

$S = \Big( (1 - \text{CosineDist}(q, d)) \cdot \alpha + \text{Importance} \cdot (1 - \alpha) \Big) \cdot e^{-\lambda \Delta t}$

在工程实现上，很多团队在做 RAG 长期记忆时，动辄引入独立的外部向量数据库（如 Pinecone 或 Milvus）。但对于单兵作战的独立开发而言，维护两套异构数据库不仅会带来巨大的运维黑洞，还会引入灾难性的分布式事务与一致性同步问题。

我的选型直接锚定了 PostgreSQL + pgvector 原生向量扩展（依托于自部署 Supabase 的底层数据库体系）。

这样做带来了压倒性的工程红利：用户资料、会话关系数据与高维 Embedding 向量共存于同一引擎，利用 HNSW 索引实现毫秒级向量召回，并直接在数据库层通过 PL/pgSQL 存储过程完成时间衰减与混合算分，将大量原本需要应用层处理的复杂算力直接下沉到数据库核心：

-- 在自部署 PostgreSQL 中启用 pgvector 扩展并创建混合衰减记忆检索函数
create extension if not exists vector;

create table if not exists public.character_memories (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references auth.users(id) on delete cascade,
  fact text not null,
  category varchar(32) default 'preference',
  importance float default 0.5,
  embedding vector(1536), -- 适配 OpenAI / 开源 Embedding 维度
  last_accessed_at timestamptz default timezone('utc'::text, now())
);

-- 创建 HNSW 向量索引加速余弦相似度检索
create index on public.character_memories 
using hnsw (embedding vector_cosine_ops);

-- 定义带时间衰减因子的 RPC 记忆召回函数
create or replace function match_character_memories(
  p_user_id uuid,
  p_query_embedding vector(1536),
  p_match_threshold float default 0.65,
  p_match_count int default 5
)
returns table (
  id uuid,
  fact text,
  category varchar,
  combined_score float
)
language plpgsql security definer
as $$
begin
  return query
  select
    m.id,
    m.fact,
    m.category,
    -- 结合向量余弦距离 (<=>) 与时间半衰期模型进行综合打分
    (
      ((1 - (m.embedding <=> p_query_embedding)) * 0.6 + m.importance * 0.4)
      * exp(-0.05 * extract(epoch from (now() - m.last_accessed_at)) / 86400)
    )::float as combined_score
  from public.character_memories m
  where m.user_id = p_user_id
  order by combined_score desc
  limit p_match_count;
end;
$$;

有了这套原生底层，客户端与编排服务只需要一行轻巧的 RPC 远程调用，即可在毫秒级内抽离出语义最相关的情感记忆切片：

// Flutter 客户端 / 编排层：通过 Supabase RPC 极速召回多层记忆
final List<dynamic> recalledMemories = await supabase.rpc(
  'match_character_memories',
  params: {
    'p_user_id': currentUserId,
    'p_query_embedding': queryEmbedding,
    'p_match_threshold': 0.65,
    'p_match_count': 5,
  },
);

// 动态装配 Context Prompt，结合滑动窗口历史完成 Prompt Budget 剪裁
final assembledPrompt = buildContextPrompt(
  persona: characterPersona,
  memories: recalledMemories.map((m) => m['fact']).join('\n'),
  recentHistory: slidingWindowHistory,
);

AI 应用的护城河，从来不是调用 API 那一行代码，而是围绕模型构建的那套精密、自洽且能持续吞吐上下文的工程架构。

智能体与流式管道的工程隐喻

市面上开始热炒 Agent 与 Skills 的神话，但当我亲手将模块切开，它的内核依然是坚固的工程底座：提示词编排 + 动态上下文注入 + 工具调用状态机。

为了消除客户端感知延迟，后端必须全面拥抱 SSE（Server-Sent Events）流式管道。更复杂的是，数字人需要依赖 TTS 驱动口型，而语音合成无法在一个完整的 Token 流全部生成后才启动。

我设计了一套流式分块断句缓冲引擎（Chunked Sentence Tokenizer），在 LLM 持续吐出 Token 的过程中，依据标点符号动态切分语义单元，并发丢入 TTS 队列与音素特征提取管线：

LLM (SSE Stream)
       ↓
[ "今天", "衡阳的", "天气", "非常晴朗，", "我们", "出去", "散步吧！" ]
       ↓
分句缓冲区检测到标点断句 ("今天衡阳的天气非常晴朗，")
       ↓ 并发调度
 ┌─────────────────────────┬─────────────────────────┐
 ▼                         ▼                         ▼
TTS 语音合成流          Viseme / 口型权重提取      客户端预加载音频
 (MP3 / PCM Stream)      (Blendshapes 帧序列)       (流式 AudioSource)
 └─────────────────────────┬─────────────────────────┘
                           ▼
              数字人音画精准同步驱动渲染 (A/V Sync)

当 TTS 吐出的音频流与面部网格的 Blendshapes 随着音素起伏精准闭合时，整个链路终于合拢：

人类意图 → 角色人格驱动 → 模型流式生成 → 标点断句缓冲 → 语音合成与 Blendshapes 提取 → WebGL / Native 数字人渲染

在概念泛滥的年代，我们终于用一行行代码，把虚无的“智能体”熬成了真实可见的毫秒级交互。

架构突围：五月天使轮、旷课狂奔与一腔极致的纯粹

在五月之前，哪怕寒假退票在出租屋里自费啃框架，整个项目的推进依然属于在大学校园里利用课余时间的业余自发摸索。上课、去自习室、在宿舍熬夜敲代码，节奏虽苦，但性质是学生在象牙塔里的自由钻研。

但到了大二下学期的五月，资本的风吹了进来。

资方作为赵老师的旧友参与了项目，引入了天使轮投资，对外宣称融资约 50 万元。随着媒体宣传与资金入场，团队开始推行每日业务打卡：每天汇报一下工作进展与落地情况即可。说实话这个制度本身并不严苛，哪怕只是简单打个卡、说说今天做了什么，也完全够了。其他人基本上也就这样对待它。

但我不是。

我比所有人都更着急，但却也比所有人都更纯粹。

眼看着 6 月中旬的上线死线一天天逼近，满脑子全是跑不通的接口、还没打通的三端适配、没有做完的支付业务与邀请裂变……不是外部逼我，而是我自己根本停不下来：用户鉴权系统、Skills 提示词动态注入、角色蒸馏、上下文记忆管理与向量召回——每一个模块都卡在我的脑子里嗡嗡作响。

不是被人压着干，而是我自己比谁都更急、更拼，主动把自己焊死在了键盘上。每天一睁眼脑子里全在飞速运转如何推进架构，整天整夜地死磕。

而事实是，面对同一套打卡制度，那位跟我一起的技术同学只是老实打卡应付、不多做一步；而我是把每天的打卡当成了最低门槛，然后拼命往远超门槛的方向狂奔

而更为讽刺的是，如此全力以赴，当时发给我的研发补贴仅仅只有可怜的每月 1000 元。每天吃着寒酸的外卖，但我当时根本顾不上计较这些——想到我们是一个团队，想到学校这边马上要搞重要的路演答辩，如果核心功能拿不出手大家在台上不好展示，想到赵老师定下的上线目标，我就只想拼尽全力快速把底层核心管道全部打通。

Demo 与商业产品之间相隔的，从来不是几百行代码，而是一整套严密防御、容灾与高并发的现代化工程体系。

在传统工程思维里，支撑这样一套复杂系统通常需要一套臃肿的后端矩阵：Spring Boot / Go 微服务、手写数百个 CRUD 路由、冗长的 DTO/VO 转换、中间件鉴权拦截器、Redis 会话同步……如果一个人把精力耗尽在这些重复的样板代码上，三端产品绝无按时上线的可能。

我做出了项目中最关键的一次架构决策：全面拥抱 Supabase 自部署方案，以数据库为核心驱动全栈交互。

很多人误以为 Supabase 只是类似 Firebase 的“低代码玩具”，或只能依赖海外云端托管。但在实际工程中，它是一套完全基于开源工业级标准构建的现代化 BaaS 底座。我们之所以坚持在自己的 Linux 云服务器上基于 Docker Compose 私有化自部署，原因非常现实：

1. 数据自主权与合规：国内 AIGC 业务对于用户身份、生成内容和私域知识库有极其严苛的合规与留存要求，数据必须物理落盘在自主可控的服务器上；
2. 免除席位与超额成本：云端托管在并发量激增时计费高昂，而自部署集群能在固定规格的物理节点上压榨出极限算力；
3. Flutter 首选全栈基石：supabase_flutter SDK 提供了极高成熟度的客户端抽象，让前端得以安全、直接、响应式地操纵数据库，抹平了传统业务网关的繁琐层次。

整套落地架构的工程拓扑如下：

┌─────────────────────────────────────────────────────────────────────────┐
│              Flutter Multi-Platform (iOS / Android / Web)               │
│        (Bloc/Provider 状态管理 + supabase_flutter 响应式数据流绑定)      │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ HTTPS / WSS (携带 GoTrue 签发的 JWT)
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│               Nginx Ingress (SSL Offloading / 频控 / Fail2ban)          │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│               Self-Hosted Supabase 集群 (Docker Compose 编排)            │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │       Kong API Gateway (统一反代、路由分发与 API Key 凭证校验)    │  │
│  └───────┬──────────────────┬──────────────────┬─────────────────┬───┘  │
│          │                  │                  │                 │      │
│   ┌──────▼──────┐    ┌──────▼──────┐    ┌──────▼──────┐   ┌──────▼────┐ │
│   │   GoTrue    │    │  PostgREST  │    │  Realtime   │   │  Storage  │ │
│   │ (Auth/JWT)  │    │(自动 CRUD)  │    │(WS广播推送) │   │ (音视频)  │ │
│   └──────┬──────┘    └──────┬──────┘    └──────┬──────┘   └──────┬────┘ │
│          │                  │                  │                 │      │
│          └──────────────────┴─────────┬────────┴─────────────────┘      │
│                                       ▼                                 │
│                 ┌───────────────────────────────────────────┐           │
│                 │   PgBouncer (Transaction 连接池管理优化)   │           │
│                 └─────────────────────┬─────────────────────┘           │
│                                       ▼                                 │
│                 ┌───────────────────────────────────────────┐           │
│                 │  PostgreSQL 15+ (pgvector + RLS 行级防御) │           │
│                 └─────────────────────┬─────────────────────┘           │
└───────────────────────────────────────┼─────────────────────────────────┘
                                        │ Database Webhooks / SSE Pipeline
                                        ▼
┌─────────────────────────────────────────────────────────────────────────┐
│               AI Streaming & Orchestration Service (微服务)             │
│   (LLM 编排 ↔ 流式分块断句缓冲 ↔ TTS 语音合成 ↔ Blendshapes 面部权重)     │
└─────────────────────────────────────────────────────────────────────────┘

1. 核心安全护城河：PostgreSQL RLS（Row Level Security 行级安全）

很多初级开发者对“前端直连数据库”充满恐惧，质疑其越权风险。但 Supabase 的颠覆性正在于此：它将数据访问控制彻底下沉至数据库物理内核，利用 PostgreSQL 原生 RLS 构筑零信任体系。

前端发起的每一次请求，都会携带 GoTrue 生成的 JWT。Kong 网关将验证后的身份上下文注入 PostgREST 会话，PostgreSQL 则通过内置的 auth.uid() 函数动态阻断任何非本人的非法读取或越权写入：

-- 启用用户会话表的行级安全策略
alter table public.chat_conversations enable row level security;

-- 策略 1：用户仅能查询自身所属的会话记录
create policy "Users can only select their own conversations"
  on public.chat_conversations
  for select
  using (auth.uid() = user_id);

-- 策略 2：用户插入记录时，强制校验 user_id 与当前 Auth 身份一致
create policy "Users can only insert their own conversations"
  on public.chat_conversations
  for insert
  with check (auth.uid() = user_id);

-- 策略 3：公开角色模板所有人可读，但仅管理员具备修改权限
create policy "Public personas are viewable by everyone"
  on public.character_personas
  for select
  using (is_public = true or auth.uid() = creator_id);

有了 RLS，原本需要在业务后端编写数十个鉴权校验拦截器的逻辑，被浓缩为几行坚固的底层 SQL。即使客户端请求被恶意抓包篡改，数据库层面也会在执行计划阶段物理截断越权查询，从根本上绝收了水平越权漏洞。

2. Flutter 端的响应式交互与状态管道

在客户端，Flutter 通过 supabase_flutter 直接接入响应式生态。配合本地状态管理与乐观更新机制，用户发送消息时可以在 0 毫秒内于屏幕渲染气泡，底层则通过 WebSocket 长连接自动同步：

// Flutter 端：基于 Supabase SDK 的响应式聊天会话流监听
class ChatRepository {
  final SupabaseClient _supabase = Supabase.instance.client;

  // 1. 获取当前用户认证状态与 ID
  String get currentUserId => _supabase.auth.currentUser!.id;

  // 2. 响应式监听当前会话下的消息流变动（基于 Realtime Postgres Changes）
  Stream<List<ChatMessage>> watchMessages(String conversationId) {
    return _supabase
        .from('chat_messages')
        .stream(primaryKey: ['id'])
        .eq('conversation_id', conversationId)
        .order('created_at', ascending: true)
        .map((maps) => maps.map((item) => ChatMessage.fromJson(item)).toList());
  }

  // 3. 发送消息（RLS 会在底层静默校验当前 user_id 权限）
  Future<void> sendMessage({
    required String conversationId,
    required String content,
  }) async {
    await _supabase.from('chat_messages').insert({
      'conversation_id': conversationId,
      'user_id': currentUserId,
      'content': content,
      'role': 'user',
      'created_at': DateTime.now().toUtc().toIso8601String(),
    });
  }
}

3. 连接池陷阱与高并发压测调优

在自部署 Supabase 的生产实战中，最大的暗礁莫过于 PostgreSQL 连接枯竭（Connection Exhaustion）。

PostgreSQL 采用经典的“每个客户端分配一个专属后台进程”模型。当公测开启、数百上千个 Flutter 客户端建立长连接并高频触发 RESTful 查改时，PostgreSQL 进程数迅速逼近操作系统的上限，内存被大量私有缓存耗尽。

为了化解高并发冲击，我在 Docker 编排中深度接入了 PgBouncer，并严格配置为事务连接池模式（Transaction Pooling Mode）：

• 客户端完成单次 HTTP 请求事务后立刻释放数据库物理连接，交由连接池复用；
• 将数百并发连接复用到 PostgreSQL 底层的 20-30 个高性能物理连接上，将数据库内存占用下降了 70%，查询吞吐量（QPS）提升了数倍；
• 对于需要保持状态的 Realtime WebSocket 长连接，则单独划分子网直连或采用专用 Session 通道分流，确保实时推送与高频 CRUD 互不干扰。

自部署 Supabase 并不是偷懒，它是一次大胆且经过深思熟虑的工程降维打击：它让我以一人之力，筑牢了一套原本需要五人团队才能维系的商业级全栈防线。

像素级执念与全端覆盖

多端覆盖是不可推卸的死命令： Web 、 Android 、 iOS ，必须同步交付。

在资源极度匮乏的团队里， Flutter 成了我最决绝也最正确的武器。然而“一套代码，跨端运行”的背后，是几何倍数增加的调试代价与平台差异：

• iOS：严格的后台保活机制、AudioSession 抢占冲突、App Store 审核中针对 AI 生成内容（AIGC）的合规协议；
• Android：混乱的机型碎片化、异形屏适配、底层 Native 渲染管线兼容；
• Web：CanvasKit 引擎加载白屏优化、流式 SSE 在不同浏览器中的跨域拦截。

我对 UI 产生了近乎苛刻的洁癖。我不允许「心元」身上残留半点“学生大作业”的廉价感。

为了实现原生质感的流体毛玻璃效果，我手写了分层渲染组件，利用 BackdropFilter、动态着色器（Shader）与曲率计算，确保在 120Hz 高刷屏上依然丝滑稳定在 60fps 以上，彻底规避过度绘制导致的掉帧：

// 高性能流体毛玻璃卡片组件封装
class LiquidGlassCard extends StatelessWidget {
  final Widget child;
  final double blur;
  final double opacity;
  final BorderRadius borderRadius;

  const LiquidGlassCard({
    super.key,
    required this.child,
    this.blur = 16.0,
    this.opacity = 0.08,
    this.borderRadius = const BorderRadius.all(Radius.circular(24.0)),
  });

  @override
  Widget build(BuildContext context) {
    return ClipRRect(
      borderRadius: borderRadius,
      child: BackdropFilter(
        filter: ImageFilter.blur(sigmaX: blur, sigmaY: blur),
        child: Container(
          decoration: BoxDecoration(
            color: Colors.white.withOpacity(opacity),
            borderRadius: borderRadius,
            border: Border.all(
              color: Colors.white.withOpacity(0.18),
              width: 1.0,
            ),
            gradient: LinearGradient(
              begin: Alignment.topLeft,
              end: Alignment.bottomRight,
              colors: [
                Colors.white.withOpacity(opacity + 0.06),
                Colors.white.withOpacity(opacity * 0.3),
              ],
            ),
          ),
          child: child,
        ),
      ),
    );
  }
}

不是因为逻辑有多复杂，而是骨子里有一股近乎顽固的偏执：既然我已经带它走到了这里，它就必须足够体面。

运维深渊：代码之外的真实世界

技术越往深处走，越是一场与不确定性的肉搏。

自部署 Supabase 绝非简单敲一行 docker compose up -d 就能高枕无忧。在生产环境里，Kong、GoTrue、PostgREST、Realtime、Storage、PgBouncer 以及集成了 pgvector 的 PostgreSQL 等十多个容器紧密咬合在一起，任何一个环节的配置失衡都会引发整机雪崩：

1. 双层网关的 CORS 与流式穿透：Flutter Web 端在不同浏览器中发起跨域请求时，常常因为 Kong 与前端 Nginx 的 CORS 响应头冲突导致预检拦截；而 AI 的 SSE 响应和 Realtime 的 WebSocket 长连接，极易被 Nginx 默认的代理缓冲区截断，导致客户端无法逐字流式打印，而是卡顿数十秒后“憋”出一整段文本。我必须细致调优 Nginx 的 proxy_buffering off、Chunked 编码与 Kong 路由插件，让字节流零时延穿透；
2. 磁盘 IOPS 与 WAL 膨胀危机：在早期批量向量化导入角色记忆与用户资料时，pgvector 的 HNSW 索引构建产生了海量的 WAL（Write-Ahead Logging）预写式日志。在毫无征兆的深夜，云盘容量瞬间被吃尽，Docker 卷触发保护机制将 PostgreSQL 锁为 Read-Only，整套自部署集群瞬间全线瘫痪。

最惊心动魄的一次，是在排查线上配置时不小心误操作重启了生产服务器。

由于底层容器套接字绑定冲突与守护脚本未自愈，整个集群在毫无征兆的情况下全线停摆。冷汗瞬间打湿了我的后背。情急之下联系服务器厂商客服，那边的技术售后草草看了几眼，居然轻描淡写地给出了一个近乎判死刑的方案：

“系统级状态异常，这种情况只能恢复出厂设置重装系统镜像。”

如果恢复出厂，线上跑的真实用户、Supabase 数据卷、辛苦调优的环境配置将全部灰飞烟灭！那一刻我咬碎了牙，硬生生按捺住慌乱回绝了格式化。我一个人通宵坐在屏幕前，通过 journalctl、systemd 与系统进程链逐个抓取异常，一层层顺藤摸瓜摸出断掉的底层进程并重新拉起套接字，最终在绝境里硬生生把服务器抢救了回来，生产数据毫发无损！

后来随着产品曝光，线上接口遭遇了外部恶意的网络挂马与 CC 攻击。

面对从未系统接触过的网络安全深水区，当时大二的我完全是一窍不通。但命运奇妙的是，我在技术交流群里结识了一位网上大神——对方居然才念高中。但他也是那种骨子里痴迷技术、不信邪、喜欢自己瞎搞闯过来的纯粹极客。我们两个隔着屏幕通宵协作，他带着我在终端抓包分析恶意 TCP 连接特征，我顺势编写 Nginx 频控拦截与 Fail2ban 过滤脚本，把黑客攻击硬生生打死在防火墙外：

# 生产环境 Nginx 入口代理：兼容 Supabase 接口、Realtime WebSocket 与 AI 流式输出
location /rest/v1/ {
    proxy_pass http://supabase_kong_gateway:8000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location /realtime/v1/ {
    proxy_pass http://supabase_kong_gateway:8000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_read_timeout 86400s; # 保障长连接不被异常踢出
}

location /api/v1/chat/stream {
    proxy_pass http://ai_streaming_upstream;
    proxy_http_version 1.1;
    
    # 核心：彻底关闭缓冲，保障 SSE Token 与断句音频流毫秒级直达 Flutter
    proxy_set_header Connection '';
    proxy_buffering off;
    proxy_cache off;
    chunked_transfer_encoding on;
    proxy_read_timeout 300s;
}

整个五月，因为资方进场后推行的每日业务打卡与严苛的三端上线死线，我彻底放弃了大学本学期的所有课程，整整一个多月连教室门都没迈进过一次。

直到六月初大学期末考试周猝然降临，现实的撕裂感达到了顶点：一边是完全空白的考勤与从来没听过的专业课试卷，我只能硬着头皮坐在考场里强撑精神答题；而另一边，则是团队定死的绝对死命令：6 月中旬网页须正式上线，并通过赵老师的个人微博向全网公众宣发！

交卷铃声一响，我便立刻狂奔回工位与出租屋屏幕前，通宵达旦地排查 Bug、做 iOS/Android/Web 三端真机联调、优化 SSE 长连接并跑全端打包发布。白天是考场，夜晚是战场。这一路走来的艰辛、荒诞与极限拉扯，真的只有我自己明白。

真正的技术成长，从不是你在温室里背熟了所有理论才被允许上场；而是现实的重锤突然砸下，你必须在废墟里逼自己以最快速度学会生存。

晨光熹微：雪峰报考契机、技术去魅与业务泥潭

六月中旬，心元正式切入线上公测。

这一趟上线刚好踩中了全国高考填报志愿的**“张雪峰报考”契机**。借着这股东风，我们顺势推出了高考志愿填报专属智能体。赵老师在微博宣传引爆后，后台注册用户很快激增至大几百人。

看着后台疯狂跳动的实时请求日志，外行人和媒体惊叹于 AI 的拟人、灵动与对答如流；但作为底座的搭建者，我深知光环之下的技术真相：

本质上，AI 依然是基于概率分布的预测模拟，根本不可能有所谓真实的“张雪峰意识”。那套让外界惊艳的拟人对话，背后全靠极其严苛的提示词工程（Prompt Engineering）与按需动态注入的 Skills 工具状态机在支撑。

任何专属音色定制、ASR 语音识别、短信验证网关，全是我在阿里云等云服务商管道上一寸寸焊死打通的。配合最新 iOS Liquid Glass 流体毛玻璃视觉，我用提供的 Mac 与 iPhone 在 iOS、Android、Web 三个平台上来回真机联调与测试。每一个像素的曲率、每一个音频包的缓冲，全是咬着牙一个人死扛下来的。

看着后台跳动的活跃日志与涌入的数百位真实用户，坦白讲，我内心并没有太多的波澜与自我感动。

因为过往独立开发并上线过多款产品的经历，让代码跑在陌生人的手机屏幕与浏览器里，对我而言早已平常稀松、微不足道。在心元这里，我关心的从来不是表象的热闹，而是高并发下服务端的承载底线、流式长连接的抖动率，以及业务审核对产品生命周期的致命损耗。

更让我体会深刻的是：在真实的商业世界里，写代码从来不是最难的。

作为开发者，只要给出明确的任务要求，我都能按时保质把技术管道铺平。真正折磨人、拖垮进度的，是业务部门那套极其繁冗复杂的各大应用市场上架资质、AIGC 合规备案、网信审查与行政手续。这些外部业务流程迟迟没有审核下来，如同一道无形的泥潭，消耗了我大量原本可以专注技术迭代的心血与时间。

我曾以为，走过了最硬核的技术开荒期，一切都会顺理成章地好起来。

然而，当商业的齿轮开始加速，真正的深渊才在盛夏悄然张开巨口。

裂痕：居民小区工位、人情冷暖与利益法则

七月，盛夏与暑期正式来临。

结束了五六月份在学校全面旷课、每日高压业务打卡、争分夺秒抢上线的窒息搏命后，资方要求团队在暑期集中全职办公。

当时资方许诺：进入暑期全职阶段后，研发补贴可以上升到每月 2500 至 3000 元的正常工资。虽然以我当时的跨端全栈架构与独立交付能力，这个薪资远不如去外部市场上找一份体面的大厂实习，但我依然毫不犹豫地选择留下——因为我太相信这个项目了，我早已把「心元」当成自己的孩子，抱着倾尽全力的心态去开发这一切。

在我的设想中，正规商业融资后的集中办公，理应是一个像模像样的写字楼办公室，大家像正规科技公司一样正式立项协同。可真正拎着行李到了现场才发现，所谓的工位其实只是在某个小区居民楼里。

现实的齿轮很快开始无情地咬合：

之前从班里拉来的同学，因为工程强度过大且难以跟上我这种边干边硬啃的实战节奏，很快选择退出；而另一位技术虽然因有工资发放介入负责聊天业务，但他仅仅抱着打卡上班、严守边界的心态在应付，不久后又被安排派往北方学习具身智能机器人相关，其实说白了最后连硬件都没对接上，这以他的技术力不业于造火箭，而他只是在重复走我的技术路线，才开始学习基础的llm调用。兜兜转转，三端的全栈交付与底层维护，再次全盘压回了我一人头上。

现在回想起来，我当时真的太年轻、太单纯了。一旦触碰到金钱与利益，我完全没有考虑人际与职场，这也确实是我最大的短板所在。

从一开始我就明白，自己跟投资人交流极少。我过于沉浸在代码与开发的世界里，甚至平时对亲人也疏于联络。直到后来现实的撞击迎面而来，我才真正痛彻心扉地意识到：无论未来走得多远，父母才是人生唯一的真正贵人；除此之外，皆为利益之友。师生也好、职场也罢，本质都不可能像血脉至亲那样，拥有毫无保留的包容。

然而，生活很快露出了更残酷的底色。

投资人以“暑期没有提前发放工资的先例”为由，规定工资必须次月 20 多号才结算。当时我从学校赶到长沙待了一个月，实际到手的收入仅有约 900 元。我天天在那个逼仄的房间里点廉价外卖，吃得寒酸局促。

当我因为生活拮据提出申请提前预支一点工资维持生计，结果“鸟都不鸟我”。

其实我知道这位投资人对我是有成见的，她极其看重一个人的外在举止与社会交际；而我太沉浸于自我的技术世界，没有时间去逢迎与交际。但我当时执着地相信：赵老师至少同为技术出身，应该明白对于一家技术驱动的项目而言，在同一条件下何者才是最核心的基石。我选择把所有的委屈暂时咽下，默默承受。

价值错位与终局

真正气愤与引爆一切的导火索，发生在那次全员打卡汇报会议上。

在当着所有人的面进行任务复盘时，一句诛心的评语如重锤般当面砸落：

“你没有真正把心元当成自己的项目，说白了就是个没有感情的机器。”

那一瞬间，巨大的荒谬、冰冷与愤怒彻底将我吞没。

我只想当面问一句：这一路走来，从底层架构、自部署 Supabase 容器集群、三端性能调优到服务器全天候运维，全是我一个人用命在出租屋里敲出来的！当初我苦苦恳求团队共同挑起重任时，另外的技术你在何方？

如今，仅仅因为对方表面上与投资人走得近、交流多、懂得讨巧，便被夸赞为“与公司一条心”——其实这只是一种精致的职场伪装。 我当时无法理解，如今才终于明白：人不能太纯粹、太老实，得学会说冠冕堂皇的职场话，这正是我初入社会摔得头破血流的短板。

当我为此发生激烈争执、并正式提出提高工资待遇时，其实我压根没想过自己会被一脚踢出局。

但投资方与管理层当时的真实心理，却是残酷而清醒的：“这孩子觉醒得太早了。”

在他们的算盘里，底座地基已经被我一个人全部浇筑完毕，系统已经完成了全功能闭环，剩下的只差应用市场上架与日常维护了。既然大厦已成，他们便不再需要承担一个核心技术开发者提出的身价与话语权要求。

我把自己的技术价值与不可替代性想得太重了。

钱于我而言其实无所谓。作为投资方，他们极度纠结公司的产权归属，这对我当下的实际经济价值其实十分有限，但我所苦苦渴求的，是一份最基础的安全感与尊重：

心元是我的全部心血，如果我身体透支、无法继续高强度工作，难道仅凭投资人一句话就能随意完成交接，让我过去一整年的所有付出彻底化为乌有吗？

双方本应是平等的双向选择，但我感受到的却是彻头彻尾的工具化冷酷：现阶段有价值时拼命榨取；一旦地基浇筑完成，过往所有的倾尽所有都可能被无视抹杀。

这种毫无归属感的憋屈长期积压，最终在生计与尊严的悬崖边全面爆发。项目攻坚阶段我全力投入、不计代价，可实际待遇却让人凉透了心：

• 之前口口声声承诺“哪怕没钱也会优先保障发放薪资”；
• 7 月下旬我沟通结算上月工资，得到的答复却是拖到次月 10 号；
• 7 月底垫付的报销款迟迟不予落实，我只能狼狈地向外借钱维持温饱；
• 到了 8 月中旬，我已经面临连每天吃饭都困难的绝境，在多次催促下，才勉强在 15 号拿到了维系生命的报酬。

项目的所有成果多被归于资方一人，而真正用命敲代码的人却被视作随时可弃的螺丝钉。我承认自己在沟通上有着年轻人的棱角与幼稚，但我绝不接受自己实打实的心血被全盘抹杀。

而需要说明的是，即使在后来团队矛盾激化、面临撕裂的时刻，赵老师其实也是极力想要留住我继续走下去的。自始至终，我与赵老师之间全是纯粹的技术探讨与工程共鸣，我也始终全力落实他给出的规划；真正将我推向对立面的，从来不是技术探讨，更不是赵老师，而是资方那套冷酷的资本算盘与产权收拢。

关于公司产权归属与自身权益边界的探讨，终究触碰了商业资本最不可撼动的底线。

当初成立公司时，我主动申请担任法人，本想借助平台不遗余力地把技术做成，甚至天真地以为大家是风雨同舟的合伙人；然而到了这一刻，现实才彻底露出了冰冷的底色——在资本的算盘里，我自始至终只是一颗不计报酬、交付了全盘技术与产品的棋子。

我一个人干得太多、太纯粹，毫无保留地把三端全栈与整套底层架构搭建完毕。可当大厦已成、系统的边际开发成本骤降，这颗倾尽所有的棋子便失去了利用价值。迎接我的，是一场毫无回旋余地的彻底清洗：

我被彻底踢出了公司，卸任法人，并将名下的所有股权签署协议全部转让，干干净净地被扫地出门。

没有体面的告别，没有温情的交接。

这一年，我把所有的热血与心血留在了代码里；而现实，给我上了生动且残酷的第一课。

淬炼之后：技术人的成人礼

离开的那天，我坐在空旷的长椅上，慢慢解开了心里的死结。

曾经的我以为，团队就是一群心怀信仰的人奔赴同一片星海；后来我才懂得，商业语境下的组织，本质是目标、责任、利益与权力规则的严密契约。

当资本入场、产权确立、利益分配摆上台面，温情脉脉的叙事便会迅速褪去。

我承认自己在那场博弈中的笨拙与幼稚——我沉溺于代码非黑即白的确定性，却对复杂的利益博弈与人际沟通一无所知。我以为把产品做到极致就是最大筹码，却不知没有契约保障的热爱，脆弱得不堪一击。

但我不曾后悔。

远方依然在脚下

赵老师当年那句“长征万里，总有人掉队”，在今天有了全新的回响。

过去我以为掉队的是同行的旅伴；现在我明白，在人生的长途跋涉中，有些人注定只能陪你走完特定的一程。

老师、同窗、合伙人、投资人，皆是过客。真正重要的，是在潮起潮落之后，你是否依然保有出发时的火种。

如今，我依然在敲击着 Flutter，依然在深耕移动端与 AI 的深度融合，依然在构建属于自己的新产品。

我不再执念于某个具体的标签，因为我知道：

代码可以被交接，项目可以被剥离，但那些在深夜出租屋里与 Bug 厮杀出的肌肉记忆、那套完整的产品感知力，早已刻进了骨髓，谁也夺不走。

承蒙关照，心元这一站，我已全力以赴。

📄🦌🙌🐟🏖️

Cталин博客

未觉池塘春草梦，阶前梧叶已秋声