Status Deck：用Tauri+Vue3+Go打造桌面工作状态聚合仪表盘

1. 项目概述

1.1 为什么要自造一个Status Deck

先说我自己的处境。我手头长期维护着三个业务线的小程序、两个公司内部中台、一个开源组件库，以及一堆散落的个人实验项目。每天早上一坐到工位，第一件事就是打开一堆标签页：GitLab看两个仓库的MR和Pipeline状态，Jira看今天的迭代任务，Grafana看生产环境的报错趋势，再顺手翻一翻微信里测试同学给我留的bug反馈。等到把这些全部看一遍，半小时已经没了，而且信息还是割裂的——没有一个地方告诉我"今天最该处理的是什么"。

这就是我做Status Deck的动机，简单说就一句话：把散落在各个平台的关键信息，聚合到一个常驻桌面的仪表盘上。它不是一个办公OA看板，也不是一个数据中台的可视化项目，更不是去重新造一个Jira轮子，而是面向开发者个人视角的"工作状态总览"。它能告诉我：

• 哪些CI流水线还挂着、是因为什么挂的；
• 今天真正需要我出手的代码评审有几条；
• 线上日志里有没有新出现的ERROR级别关键报错；
• 我负责的模块在最近一轮测试里暴露了什么问题；
• 今天还有哪些节点的缺陷单没动过。

如果说项目是产品的话，那Status Deck就是我的驾驶舱。对读者来说，这个项目的最大价值在于：它不是传统意义上的教学demo，而是一个可以真正塞进日常开发流程里的全栈作品，既有前端界面打磨，又有后端采集调度，还牵扯到桌面端容器选型、本地存储、WebSocket长连接、甚至后面接入AI总结。无论你是在前端转全栈的路上想找项目练手，还是已经带团队想做个内部效率工具，它都非常有参考意义。

1.2 这个项目解决的核心痛点

先聊痛点，不然一切都是自嗨。

开发者日常的信息来源是高度碎片化的。公司用Jira，代码托管在GitLab，发布看Jenkins，日志找Kibana，用户反馈在钉钉群，需求文档在语雀或者Confluence……每一个平台都有自己的"待办状态"，但这些状态之间没有联动。我经常在一种体验中来回拉扯：Jira上把任务置为"进行中"，但对应的代码分支还没提交；CI挂了半天没人管，因为大家默认"应该有别的同学在看"；一个P0线上报障从钉群里刷过去了，看一眼就忘。

另一个痛点更隐蔽：这些平台的推送机制并不适合开发者。Jira的一天十封邮件提醒，我看都不看；IM群里刷屏式的告警机器人，重要信息早被冲走了。开发者需要的是"当我有空看一眼时，一眼就能看到重点"，而不是"不断的被打断"。这个逻辑决定了Status Deck的核心形态：它是拉取+聚合+重排，不是推送+打扰。

还有一层原因和团队协作没关系，纯粹从个人技术成长角度。我想做一个"全栈自造"的项目，不是为了秀技术，而是为了把所有环节都亲手摸一遍：

• 前端是Vue 3 + TypeScript，主要为了把桌面端交互细节做透；
• 桌面容器我在Tauri和Electron之间做了对比；
• 后端采集用Go，出于性能、交叉编译和部署体积的考虑；
• 通信层用WebSocket做实时刷新；
• 本地文件存储和SQLite结合，保证断网时也能看到历史快照。

做完一期的体会是：这种"自造工具"的方式，比看任何教程都更能逼你把全链条跑通。接下来我把具体的思路、选型、踩坑过程完整拆出来，希望给正在规划全栈项目或者想做个效率工具的同学一个可参考的样本。

2. 设计拆解与技术选型逻辑

2.1 为什么是Tauri而不是Electron

先说桌面容器的选择。很多人一看到"桌面仪表盘"，第一反应就是Electron，毕竟生态成熟、资料多。但我在这个项目里最终用的是Tauri，理由不只是"新一代更酷"，而是几个实际诉求叠加在一起的结果。

第一是内存占用。Status Deck的定位是常驻桌面，要开机自启、挂在系统托盘里、平时以很小的窗口悬浮在屏幕角落。Electron动不动几百MB内存，对一台还要同时跑IDE、浏览器、本地服务、容器环境的开发机来说，太奢侈了。Tauri用的是系统WebView，内核不打包浏览器，安装包只有几MB，运行时内存占用可以控制在几十MB级别。实测下来体感非常明显，开一整天也不会有"风扇猛转"的负担。

第二是后端进程的归属问题。Status Deck的核心是数据采集，而采集逻辑我放在Go服务里。Tauri的优势在于它可以很干净地和本地的Go进程做进程通信，主进程用Rust写，轻量、可靠，适合做窗口管理和系统托盘。而Electron的Node.js事件循环本身就很繁忙，再塞采集逻辑，代码层级容易乱。

第三是跨平台编译体验。我主力开发机是Windows，但偶尔需要在macOS上看效果。Tauri配合GitHub Actions做三平台构建很顺，Rust的交叉编译虽然要提前准备target，但整体链路清晰。Electron做多平台打包也不是不行，但产物体积和CI耗时始终是个绕不开的短板。

当然，Tauri也不是没有代价。它的WebView内核在各操作系统上表现有细微差异，比如Windows上WebView2对CSS backdrop-filter的渲染就和macOS的WKWebView不完全一致；Rust部分的学习曲线也摆在那里，好在我只需要做窗口、托盘、自定义协议转发这些基础能力，没有一个星期就上手了。

我最终敲定的架构是这样的：

• 桌面壳：Tauri 2.x，负责窗口、系统托盘、开机自启、自定义协议；
• 前端：Vue 3 + TypeScript + Pinia + Vite，负责仪表盘界面渲染和交互；
• 后端采集服务：Go，监听本地端口，轮询各个数据源接口，解析、整合、推送；同时服务一个SQLite数据库做本地存储；
• 通信：前端通过HTTP获取一次全量快照，然后通过WebSocket订阅增量更新；
• 数据源：第一版接入了GitLab、Jira、Jenkins、本地的日志文件扫描器。

2.2 Go采集端的作用边界

一开始我纠结过一个问题：采集逻辑能不能直接放在前端或者Tauri的Rust进程里？后来实践下来发现，还是得有一个独立的Go进程。原因主要有三个。

首先是隔离性。数据源的Token、密钥如果存在前端的localStorage或者Tauri的配置里，风险比较大；独立Go服务可以把密钥放在系统级配置目录中，并做权限收窄，前端完全接触不到。其次是调度稳定性。Go的goroutine和定时常驻非常适合做轮询采集器，比如每30秒拉一次GitLab流水线状态、每1分钟拉一次Jira活跃迭代、每5分钟扫一次日志目录，这些定时任务放在前端里会被标签页休眠机制打断，放在Rust进程里开发成本又偏高。第三是数据格式处理效率。从JSON API取回来的原始数据非常杂乱，Jira的字段结构、GitLab事件结构都带着大量无关信息，Go里做字段清洗、归一化、去重、落库，性能好，代码也更直观。

那Go服务具体做什么？我给它定的范围是：采集、归一化、存储、推流。采集负责按照配置的时间间隔主动请求外部API；归一化把不同来源的数据变成统一的卡片结构；存储负责写SQLite以及按时间窗口做历史归档；推流则是把更新后的卡片状态通过WebSocket发给前端。它还负责启动时扫描本地日志目录，把错误日志抽成事件流——这个能力最实用，因为有些本地启动的服务日志非常长，靠肉眼盯根本看不过来。

我不想把Go进程做得太复杂。它不负责做事后统计，不做鉴权，不暴露多余端口，只监听127.0.0.1上的一个随机端口，并通过Tauri启动时注入的密钥做简单握手。前端UI和后端服务之间是纯粹的"订阅/推送"关系，保证每一层职责单一。

2.3 数据模型与卡片结构设计

写Status Deck最核心的一个设计决策，是定义一套统一的"状态卡片"模型。数据源千差万别，但落到仪表盘上，其实都可以抽象成一张卡片，包含以下字段：

有了这层抽象，前端渲染就变得相当统一：所有卡片都走同一个卡片组件，只是根据source和type来决定辅助展示。比如GitLab的水管卡显示流水线阶段和耗时，Jira的卡显示经办人和优先级标识，Jenkins卡显示构建按钮的状态。后续如果想新增一个数据源，只需要在Go里写一个adapter，把数据源API返回的原始结构映射成上面的卡片结构，前端一行都不用改。

这里有一个容易被忽略的坑：同一个事物在不同数据源里可能被当成不同的卡片。比如一个MR关联的CI流水线，在GitLab那边是一条流水线事件，在Jenkins那边是一条构建任务，在Jira里还有一个对应的代码审查任务。如果不做关联归并，仪表盘上就会出现三张割裂的卡。我一开始也踩了这个坑，后来在卡片模型里增加了一个attributetrace_id，用于把"同一件事"的多个状态源绑定到一起。归并逻辑用的还是最朴素的时间窗口+标题关键词匹配，先以规则为主，二期再考虑引入AI语义归并。

2.4 前端视图层为什么要做"抽屉式"布局

Status Deck的使用场景是常驻桌面、随时扫一眼，所以界面布局我做成三栏抽屉式：左侧是数据源导航，中间是"待处理队列"视图，右侧是详情抽屉，点击卡片后滑出。这样的布局最贴近开发者的工作流：常态下只看中间待处理队列，有卡片需要展开时右侧抽屉同步展示上下文信息。

前端状态管理用Pinia，因为卡片的状态流转非常频繁，从running到failed、从pending到resolved，状态机是明确的，Pinia的store结构很方便做这种约束。为此我定义了状态机转换表：

• 待处理状态可以进入运行中、已解决、失败；
• 运行中状态可以进入失败、成功、已取消；
• 失败状态可以进入重新运行，进而回到运行中；
• 已解决状态不可逆，除非新建卡片。

这些约束直接放在store的action里，不允许组件直接改state，避免界面逻辑失控。后端推送来的每条增量事件都带上卡片完整状态，前端按id合并，保证一致性。

3. 实操走查：从零开始搭建

3.1 初始化整体工程结构

这个项目我用了pnpm workspace管理，因为同时涉及Tauri主工程、Vue前端和Go服务，前端部分拆成多个包会更清晰。目录结构长这样：

status-deck/ ├─ desktop/ # Tauri壳工程 │ ├─ src/ # Rust侧代码 │ └─ tauri.conf.json ├─ frontend/ # Vue 3前端 │ ├─ src/ │ └─ package.json ├─ collector/ # Go采集服务 │ ├─ cmd/ │ ├─ internal/ │ ├─ go.mod │ └─ main.go └─ scripts/ # 一键启动脚本

这里有个工程上的建议：虽然叫monorepo，但前端和Go服务不要强行共用一个包管理。Go有自己独立的模块体系，最合理的做法是让pnpm workspace只管desktop和frontend，collector作为独立Go module，通过根目录的Makefile或者npm scripts做统一调度。强行混合只会让CI和本地开发都不舒服。

3.2 Go采集服务关键实现

Go服务端的核心是调度器和数据源适配器。调度器我用了一个很轻量的方式，不引入cron库，直接用time.Ticker。

package collector import "time" type SourceAdapter interface { Name() string Fetch() ([]RawItem, error) Normalize(raw RawItem) (*Card, error) } type Scheduler struct { adapters map[string]SourceAdapter freq map[string]time.Duration incoming chan RawEvent } func (s *Scheduler) Run() { for name, ad := range s.adapters { go func(n string, a SourceAdapter) { ticker := time.NewTicker(s.freq[n]) for range ticker.C { items, err := a.Fetch() if err != nil { s.incoming <- RawEvent{Source: n, Err: err} continue } for _, it := range items { s.incoming <- RawEvent{Source: n, Item: it} } } }(name, ad) } }

Ticker的好处是简单粗暴，缺点是如果某个数据源请求耗时很长，下一次Tick可能堆积。我实际用的时候给每个adapter加了超过阈值自动截断的context.WithTimeout，保证采集器整体节奏稳定。

数据源适配器里最有代表性的是GitLab的MR巡检。GitLab API返回的Merge Request列表，过滤条件比较多：需要排除Draft、排除自己主动关闭的、只保留和我相关的、按更新时间排序。这些过滤规则我放在Normalize阶段，因为如果直接在API请求阶段用Query参数过滤，每个项目的自定义字段又会导致规则复杂化，不如全量拉回来后统一清洗。

归一化后的卡片写入SQLite时，用upsert保证幂等。SQLite在本地频率下完全够用，不需要单独的数据库引擎。注意启动时创建表索引，尤其是trace_id和updated_at这两个字段，否则数据量上来后查询会明显变慢。

3.3 WebSocket推送与心跳策略

数据推流我用了gorilla/websocket，因为实现简单、文档多。设计上不是每条采集到的数据都立刻推给前端，这样会产生大量小消息、触发前端无意义的频繁渲染。我更倾向于状态快照+增量事件混合推送：

• 首次连接：后端将当前SQLite中的全量卡片按视图维度打包成一次snapshot，发给前端；
• 后续连接：以增量事件为主，每次推送包含本轮归并后发生变化的卡片列表；
• 如果某轮采集没有变化，后端不推送任何消息，但会发送一个轻量的ping事件，用于前端确认链路存活。

WebSocket最麻烦的不是握手，而是异常断开。开发者电脑睡眠、网络切换、Tauri窗口被系统挂起，都会导致连接断开。断开后前端如果无脑重连，会搞出重连风暴。我用的策略是指数退避+最大重试间隔封顶。

let retry = 1 const maxRetry = 20 const baseDelay = 1000 const capDelay = 30000 function connect() { const ws = new WebSocket(`ws://127.0.0.1:${port}/ws?token=${token}`) ws.onclose = () => { if (retry > maxRetry) return const delay = Math.min(baseDelay * 2 ** (retry - 1), capDelay) setTimeout(() => { retry += 1 connect() }, delay) } }

同时前端的Vue组件只在收到snapshot和卡片变更event时才做渲染，所有连接状态都收敛到一个Pinia store里，避免多个组件各自维护ws实例导致消息重复处理。

3.4 前端界面渲染细节

前端界面最花时间的地方不是数据绑定的逻辑，而是"状态可视化"。同样一张卡片，从"pending"变成"running"再变成"failed"，在视觉上要能被用户下意识感知。我的做法是给每个状态定义一组语义色和动效：失败用深红色脉冲光晕，成功用绿色打勾跳动，运行中用青色扫光动画。这些动效看起来不难，但真做起来要考虑浏览器性能，尤其不能每秒钟都触发整个列表的动画，否则CPU占用会翻好几倍。

仪表盘的网格布局，我用了CSS Grid，让卡片在固定列数下自动换行。每个卡片高度不固定，但依据内容大致分为"紧凑型"和"展开型"，紧凑型只显示标题、状态和priority标识；展开型则在右侧抽屉展示详情。这个是纯前端的交互优化，对数据模型没有影响。

还有一个细节：Tauri环境下Vue前端访问本地Go服务的WebSocket，会存在跨域的cherry，需要在Tauri的tauri.conf.json里配置允许的URL，或者后端在HTTP头里放行http://tauri.localhost。这个坑第一次跑通时很容易卡住，后面单独拉一节说。

3.5 一键启动与调试体验

开发调试阶段最痛苦的环节，是每次改动前端或者Go服务都要手动三步操作：编译Go、启动Go、再启动Vite。我在根目录写了个npm script，用concurrently并行跑两个进程，再让Tauri的开发模式监听前端端口。

npm run dev

这个命令会：

1. 启动Go采集服务，监听随机端口并写入run/collector.port文件；
2. 启动Vite dev server；
3. 等待Vite ready后，再启动Tauri dev窗口；
4. Tauri的main进程从端口文件读出Go服务地址，注入到前端环境变量中。

Debug时我习惯单独开一个终端跑Go进程，因为Go日志和前端日志混在一起很容易乱。Go的采集日志和推送日志分开打：采集日志用INFO级别、推送日志用DEBUG级别，平时只开INFO，排查问题时再切DEBUG。

4. 踩坑记录与常见问题排查

4.1 本地服务端口管理与权限

这个项目里，Go服务监听的是127.0.0.1随机端口，理论上不存在端口冲突问题。但我在一期开发时图省事，把端口硬编码成了5170，然后就撞上了崽剧：某天电脑上不知哪个进程占用了5170，导致Go服务启动失败，前端WebSocket连不上，面板一片空白。排查了十分钟才发现是端口被占。

后来我学乖了，Go服务启动时先向系统申请一个空闲端口，而不是自己猜一个端口。方法是直接监听端口0，内核会自动分配空闲端口，然后把实际端口号和随机生成的握手密钥写入一个临时文件里，供Tauri主进程和前端读取。Tauri窗口加载完成后，通过自定义协议读取这个文件，完成初始连接信息的注入。

这个方案的连带收益是：每次启动都用不同端口，降低了被恶意探测的可能性，因为只监听本地回环，外部根本发现不了这个服务的存在。

4.2 跨域、令牌注入与安全边界

Tauri前后端通信和平时浏览器前后端联调有一个明显的不同：前端的Origin是http://tauri.localhost，而后端Go服务跑在127.0.0.1上，两者之间天然跨域。WebSocket尽管是ws协议，同样受到Origin检查限制。我的解决办法是：Go服务启动时给所有请求响应标上Access-Control-Allow-Origin: http://tauri.localhost，并且只接受来自这个Origin的WebSocket握手请求，其余的拒绝。

令牌方面，我用的是最简单的Bearer token方案，但这个token不是写死在前端代码里的。启动时Go服务生成一个随机token，写入临时文件并由Tauri主进程读取，再通过Tauri的window.__STATUS_DECK_TOKEN__注入给前端。这样一来，前端代码仓库里没有敏感数据，token只在内存和本地临时文件中流转，泄露面大幅缩小。

顺带一提：Tauri 2.x里可以通过withGlobalTauri把后端能力暴露成全局对象，但我没有启用，因为前端只需要读token和调用系统托盘相关能力，没必要把整个Tauri API都裸露在全局。

4.3 WebSocket重连与前端状态一致性

这个问题是典型的前后端协作深水区。当电脑休眠恢复后，TCP连接其实已经断了，但前端WebSocket对象的状态可能还停留在OPEN，要等底层超时才能触发onclose。这期间如果有数据变动，前端就会漏更新，而且界面还显示"已连接"，非常误导人。

我的解决方式分两层。第一层是WebSocket应用层心跳：后端每30秒发一个ping的应用消息，前端收到后更新本地心跳时间戳；前端如果超过75秒没收到任何消息（包括ping），就主动断开并走指数退避重连。这个时间窗口比操作系统级的TCP超时要快得多，把"断线无感知"的时间压缩到一分钟以内。第二层是重连成功后的快照对齐：前端每次重连拿到snapshot后，用整个快照覆盖本地store，保证即使断线期间漏了几条增量事件，也不会出现状态不一致。

4.4 常见问题速查表

这个表是我开发过程中真实踩过的问题，不是网上抄来的。

4.5 从"能跑"到"稳定跑"的两个关键细节

第一，本地SQLite文件的写入频率很容易失控。Go采集端如果每30秒拉一次GitLab，每次拉完都更新SQLite，磁盘写入也不算频繁。但一旦接入日志文件扫描器这种高频数据源，每秒可能产生几十条日志事件，直接全量写入SQLite会导致磁盘IO飙升。我的做法是引入一个简单的内存缓冲池，每收集到100条日志事件，或者每3秒强制flush一次，再批量写入SQLite。日志类数据允许一定的延迟，但绝不能拖垮主进程的采集调度。

第二，前端渲染时用v-memo或者分片渲染来避免大列表卡顿。仪表盘卡片数量如果超过200张，一次性渲染所有DOM节点会有明显卡顿。我采用分页渲染：默认只渲染前100张卡片，滚动时动态加载后续卡片。这不是一个炫技方案，但对于桌面应用、尤其是开机自启的常驻应用来说，任何一点不必要的性能损耗都会累积成糟糕的体感。

5. 一期复盘与下一步规划

5.1 一期验收的四个标准

与其说这是一期总结，不如说我在开发前就给自己定了四个验收标准，做完后逐项对照：

• 信息聚合效率：以前每天早晨开工前要花30分钟翻转各个平台，现在打开Status Deck两分钟能看完全部可处理事项。这个达到了。
• 常驻稳定性：连续开一周不崩、不占大内存、不出现白屏死状态。这个经过两周实测达到了。最稳的一次是连续跑了6天，Windows休眠唤醒没出问题。
• 新增数据源成本：接一个全新数据源是否在2小时内能完成。GitLab和Jenkins都达标，Jira的适配器因为字段太庞杂，花了将近半天。
• 代码可维护性：后端Go代码和前端Vue代码是否做到了一两周不看还能快速上手。前端因为状态机约束比较强，还行；后端有一些adapter的重复代码，二期需要重构。

按这四个标准来评判，Status Deck的第一期算是"及格但有明显不足"。最大的不足不是功能不够丰富，而是整个项目的业务闭环还不够完整——仪表盘告诉了我"有什么要处理"，但还没有做到"处理完以后状态的联动反馈"。比如我在GitLab上把一个MR合入后，Status Deck是通过下一轮轮询被动感知到的，并不是主动从GitLab webhook接回来的。被动轮询的延迟对于MR这种低频事件无所谓，但对于CI失败、线上告警这类时效性强的场景，最好依赖Webhook推送而不是主动拉取。目前是混合方案：CI状态30秒短轮询，日志文件靠本地监听。

5.2 二期想做的扩展方向

接下来有几个方向，按优先级排：

第一，AI摘要层。不是简单调用大模型把所有卡片描述再抄一遍，而是做跨卡片的语义归并。比如"商户登录接口"这个模块，可能同时出现了Jira缺陷、CI失败、日志报错三张卡，AI需要识别出它们是同一件事，并在仪表盘顶部生成一段"事件摘要"，告诉用户这件事涉及范围、可能影响、建议下一步。这个方向需要先积累足够多的卡片历史数据，做成离线分析模块，再接入大模型能力，避免每次界面刷新都要调用一次接口，成本控制不住。

第二，手机端远程查看。目前Tauri桌面的价值在于开发时随处可看，但它毕竟不能跟出差场景友好配合。二期考虑做一个简单的手机H5版，只读不写，通过安全通道连接回家里或公司的服务端，在手机上看到同样的关键卡片。要在后端补充按用户维度的权限控制，不能像现在这样只绑定本机使用。

第三，多项目配置管理。目前的配置是写死在Go服务里的，要改数据源、改Token都得改配置文件重启服务。二期打算把数据源配置做成可视化维护，直接在仪表盘右上角打开设置抽屉，通过前端提交新的配置内容，写入配置中心再触发采集器热加载。

第四，小程序的联动也考虑过，但是小程序平台够完整、审核成本高，我这个工具主要给自己用，手机端H5已经够用，小程序可能不会优先做。

5.3 给也想自造工具的开发者几条建议

这个项目做下来，让我对"自造工具"这件事有几个很实在的体会，想分享给同样打算做个全栈项目的同学。

第一，自造工具的第一用户是自己，不要一开始就想太多通用性。我一开始写了特别多配置文件，想着未来要支持不同团队用、支持多种数据源、支持自定义展示规则，结果做完发现全是过度设计，真正用到的配置只有GitLab的Token、Jira的查询语句、日志目录的路径。先满足自己的80%需求，跑起来再去考虑别的使用场景，这个节奏才舒服。

第二，后端和前端的学习曲线是不同的。我是前端出身，写Vue很顺手，但Go服务的并发模型和错误处理方式一开始坑了我不少时间。尤其是goroutine里的错误如果不被捕获，整个采集器会静默挂掉，没有Panic信息，前端看到的只是卡片不更新。后面我养成了一个习惯：每个采集goroutine都用recover包一层，把panic信息打到日志文件里。对于前端转全栈的同学来说，这种"生产事故教育"比任何语法教程都更有用。

第三，桌面端小细节对体验的影响被严重低估。窗口拖拽、开机自启、托盘菜单、右下角通知、窗口失焦自动隐藏，这些功能单个拿出来都很简单，但拼在一起才让Status Deck有了"桌面应用"的感觉，而不是一个"穿在浏览器外套里的网页"。如果只做Web版，你永远不会去考虑"系统休眠后唤起时UI没刷新"这种问题。

第四，命名很重要，Status Deck这个名字本身就是产品定位。我见过很多开发者工具类项目，技术上很好，但产品定义上模糊不清。一个工具需要一句话说清它是干嘛的，否则自己写着写着就跑偏了。Status、Deck两个词合起来，既描述了形态（状态面板），又暗示了使用方式（一览无余的卡片阵列），整个项目的边界感一下子就出来了。

我可以坦白说，Status Deck到现在也只算完成了第一期的"可用"状态，离"好用"还差着一段距离。但它已经切切实实地改善了我每天开工后前30分钟的信息焦虑，也让我在Vue、Tauri、Go、SQLite、WebSocket这一整条技术链上有了更深的掌控感。对正在寻找全栈练手项目的朋友，我建议直接照抄这个思路：挑一个你最痛的实际场景，用最顺手的技术栈做出来，把它用起来，而不是做完截图就丢到仓库吃灰。这个项目后面我还打算持续迭代下去，下一期应该会写AI摘要层的具体实践。