企业官网建设流程全解析

项目代号就叫 V1，功能当初跑通得很顺利，真正让人头疼的是“封装”这件事。软件要封装请求、封装 AI 交互逻辑、封装串口通信；硬件要封装库、封装引脚定义；发布时还要面对 Swagger 404、AI 网关 502 这种和环境强相关的幺蛾子。V1 这个阶段，功能大家都写得出来，但封装的边界画不清楚，后面每一次迭代都是灾难。这篇文章就把我 V1 项目里和“封装”打交道的完整过程拆开讲，软件层、硬件层、发布层一条线梳理清楚，给正在收尾 V1 项目的朋友一个可以直接抄的作业。

1. 先看懂“封装”：V1 项目里到底要封什么

1.1 为什么 V1 阶段必须认真做封装

很多团队做 V1 的思路是“先把功能跑起来，以后再说”。这个思路在 Demo 阶段没问题，但 V1 往往不是终点，而是第一个能对外交付的版本。这时候如果代码里的“封装”是乱的，后面接新设备、换大模型接口、加新页面，每一件事都会变成全局改动，改一处崩三处。

封装这个词在软件和硬件里的含义不同，但背后的思想完全一致：把内部的复杂性和变化隔离起来，对外只暴露稳定的接口。面向对象里讲的封装、继承、多态，封装是第一位的，因为继承和多态是建立在封装基础上的。好比一个电池盒只需要知道电池的尺寸和正负极方向，至于电池内部是镍氢、锂电还是碱性，它根本不关心。V1 项目里的封装，本质就是给团队内部划定“哪里会变、哪里不许变”的边界。

还有一点要澄清：封装不是为了“保护代码不被看”。总有人问 LabVIEW 是不是要封装成 DLL 才能保护知识产权，这种做法可以，但那只是 DLL 的副产品。封装真正解决的是变化管理问题，代码被谁看其实不重要，重要的是当底层实现替换时，上层调用方不用跟着大改。V1 阶段尤其需要这种边界，因为 V1 的底层技术选型随时可能被替换。

1.2 技术栈与封装边界：先梳理出这张分层图

我的 V1 项目是一个典型的“AI 对话 + 硬件控制”混合体：前端有 Vue 的 H5 端，也有微信小程序端；后端是 .NET WebAPI，Swagger 负责接口文档；AI 交互走本地推理网关的 OpenAI 兼容接口；硬件侧通过 Modbus RTU 串口协议控制下位机。技术栈看起来杂，但封装的层级反而好画。

我建议在动手写代码前，先绘制一张分层图，每层的职责和边界写清楚：

• 前端请求层：axios 二次封装（H5）、wx.request 二次封装（小程序），统一处理 Token、错误码、超时、取消请求。
• AI 交互层：封装 SSE 流式输出、abort 中断、重连逻辑、消息解析，调用方只需要传入 prompt 和回调函数。
• 后端接口层：WebAPI 提供稳定接口，Swagger 做契约，业务内部对接 AI 网关、Modbus 服务。
• 硬件通信层：C# 封装 Modbus 串口通信，统一打开、关闭、读写、CRC 校验、超时重试。
• 硬件 PCB 层：AD / Allegro / Cadence 封装库，统一焊盘、丝印、3D 模型标准，保证设计复用。

这张图画出来之后，团队里每个人都很清楚：换了 AI 模型，只要改 AI 交互层和网关配置；换了串口设备，只要改 Modbus 驱动层；换了数据服务，只要改请求层。V1 的项目为什么最后能稳下来，就是因为这些边界在一开始就被定死了，后面根本没机会写“面条代码”。

2. 软件层封装：请求、AI 会话、串口通信三件套

2.1 请求层二次封装：axios 与微信小程序不能各写各的

V1 项目里 H5 端和微信小程序端是并存的，如果两者各写一套请求逻辑，光错误码处理就能写三遍。我的做法是把 axios 和小程序的请求都统一成同一套接口签名，内部各自实现。

axios 二次封装的核心不是“new 一个实例”，而是把拦截器、超时、错误语义、取消请求这些边界处理好。我贴一个比较标准的封装骨架：

import axios from 'axios'; import { Message } from 'antd'; const service = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 15000, }); // 请求拦截器 service.interceptors.request.use( (config) => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = `Bearer ${token}`; } config.headers['X-Trace-Id'] = crypto.randomUUID(); return config; }, (error) => Promise.reject(error) ); // 响应拦截器 service.interceptors.response.use( (response) => { const { code, data, message } = response.data; // 统一认准 code 字段，HTTP 200 不代表业务成功 if (code !== 0) { Message.error(message || '业务错误'); return Promise.reject(new Error(message || 'Error')); } return data; }, (error) => { if (error.code === 'ECONNABORTED') { Message.warning('请求超时，请重试'); } else if (error.response?.status === 401) { // 统一跳登录 window.location.href = '/login'; } else if (error.response?.status === 502) { Message.error('网关异常，服务暂时不可用'); } else { Message.error('网络异常'); } return Promise.reject(error); } ); export default service;

响应拦截器里我故意把业务 code 和 HTTP 状态分开处理。后端返回的报文结构统一是{ code, message, data }，前端拦截器只认这个结构，任何接口都不得绕过。这个约定看起来简单，实际推进的时候后端同事偶尔会贪方便直接返回字符串或裸数组，前端一解构就挂，后来我把拦截器里的结构校验写死，不符合直接 reject，问题才根治。

微信小程序没有 axios 的拦截器机制，wx.request 也不支持 Promise。但小程序端可以封装一个 Promise 化的 request 方法，把同样的逻辑复制一份，同时保持和 axios 封装的接口签名一致。注意小程序的并发限制比较严格，多个请求最好通过队列控制，Token 过期时也要有队列做刷新重放，避免 401 后并发请求全部打向登录页。

2.2 AI 交互封装：SSE 流式输出、实时渲染与 abort 的正确姿势

V1 项目里最核心的交互是“调用大模型接口，把回答流式渲染到界面上”。这里我踩了很多坑，尤其是流式数据解析和中断请求两块。

对接 AI 推理网关最简单的方式是用 EventSource，但这个方案有个硬伤：EventSource 只能 GET 不能 POST，自定义 Header 也加不了，接入系统时 Token 根本传不进去。所以我的封装里直接用 fetch + ReadableStream，配合 AbortController 实现流式读取和主动中断。

先看关键代码：

export interface ChatStreamOptions { messages: { role: string; content: string }[]; onToken: (text: string) => void; onDone: () => void; onError: (err: Error) => void; signal?: AbortSignal; } export async function chatStream(options: ChatStreamOptions) { const resp = await fetch('/v1/responses', { method: 'POST', headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${token}`, }, body: JSON.stringify({ model: 'local-model', messages: options.messages, stream: true, }), signal: options.signal, }); if (!resp.ok) { throw new Error(`unexpected status ${resp.status}: ${resp.statusText}`); } const reader = resp.body!.getReader(); const decoder = new TextDecoder('utf-8'); let buffer = ''; while (true) { const { done, value } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); // SSE 事件块可能被拆到多个 chunk 里，必须缓冲后按空行切割 const blocks = buffer.split('\n\n'); buffer = blocks.pop() ?? ''; for (const block of blocks) { const lines = block.split('\n'); for (const line of lines) { if (!line.startsWith('data:')) continue; const payload = line.slice(5).trim(); if (payload === '[DONE]') { options.onDone(); return; } try { const json = JSON.parse(payload); const delta = json.choices?.[0]?.delta?.content ?? ''; if (delta) options.onToken(delta); } catch { // 忽略半包解析失败的噪音数据 } } } } options.onDone(); }

这段代码里最容易被忽略的是 buffer 切割。SSE 的 data 块到达浏览器时可能被切成任意大小的 chunk，如果你直接按行解析，大概率会遇到半行 JSON 解析失败。我把缓冲按\n\n切分，最后一个不完整的块留存到下一轮，这个处理是流式解析里最关键的细节。

abort 的使用要几个场景配合：用户点“停止生成”、组件卸载、超时自动取消。组件卸载时如果请求还挂着，等响应回来再 setState 会报错甚至内存泄漏，所以封装里必须支持传入 AbortSignal：

// 调用方 const controller = new AbortController(); await chatStream({ messages, onToken: (text) => appendText(text), onDone: () => setGenerating(false), signal: controller.signal, }); // 用户点击停止 / 组件卸载 controller.abort();

中断之后还要给用户一个明确的提示，而不是静默消失。曾经我在流式渲染里没处理 abort 异常，用户点停止后界面没有任何反馈，看起来像卡死了，后来在 catch 里区分AbortError和其他错误，才解决问题。

这里顺带提一下 YOLO v1 的类比。YOLO v1 之所以经典，就是因为它把目标检测封装成了一个端到端的回归问题，外部只需要输入图像、输出检测结果，内部的结构细节调用方完全不关心。我做 AI 交互封装的目标也一样：业务层只关心“发消息、收回流、能停止”，至于网关地址、模型名称、流式协议，全部收敛在封装的内部。

2.3 Modbus 串口通信封装：线程安全比功能实现更重要

V1 项目里硬件侧的下位机是走 Modbus RTU 协议的，C# 这边需要封装串口通信。串口通信的坑和 HTTP 完全不一样：没有状态码，没有超时语义，数据错了也不会报错。封装的时候我最看重三点：CRC 校验、并发读写锁、超时重试。

拿 C# 的串口封装举例，核心思路是做一个串口管理类，把底层的 SerialPort 完全藏住：

public sealed class ModbusRtuClient : IDisposable { private readonly SerialPort _port; private readonly object _lock = new object(); public ModbusRtuClient(string portName, int baudRate = 9600) { _port = new SerialPort(portName, baudRate, Parity.None, 8, StopBits.One); _port.ReadTimeout = 1000; _port.WriteTimeout = 1000; } public void Open() => _port.Open(); public byte[] ReadHoldingRegisters(byte slaveId, ushort startAddr, ushort count) { lock (_lock) { byte[] frame = BuildReadFrame(slaveId, startAddr, count); byte[] crc = Crc16(frame); byte[] sendFrame = frame.Concat(crc).ToArray(); _port.Write(sendFrame, 0, sendFrame.Length); // 读取完整响应帧…… return ParseResponse(slaveId, 0x03, count); } } public void Dispose() => _port.Dispose(); }

为什么必须加锁？因为 Modbus 是一问一答的协议，如果同时有两个线程往串口写指令，返回的应答帧根本没法区分是哪个请求的。串口不像 HTTP 有连接和请求 ID，不加锁就是灾难。有一次我遇到下位机数据偶发错乱，排查到最后就是上位机有一个定时读任务和一个手动控制任务共用了串口，加锁之后问题彻底消失。

CRC16 校验也必须做。Modbus 协议帧在 RS485 线路上传输时会因为干扰、接线不良等原因出现位错误，如果没有 CRC 校验，读到错误数据后程序还傻傻地当成正常值存库，那才是真正的隐患。调试的时候我习惯把每一帧收发数据都打十六进制日志，03 01 00 05 00 01 ...这种格式，一眼就能看出协议错误和数据错位。

超时重试也一样重要。串口通信没有连接状态，设备断电、线松了、串口被占用，程序的表现都是“没反应”。在封装里给每次读操作设置超时，超时后抛出明确异常，由上层决定重试还是告警。曾经我把超时设成无限等待，现场设备掉线后程序直接卡死，操作员根本没意识到设备离线了。

如果 V1 项目里还接了 RabbitMQ，消息队列的封装思路和串口也类似：连接池、确认机制、重试队列都要收敛到一个消息中心，业务代码里不允许直接 new 连接、直接发裸消息。封装的方式不同，目标一样：把“通信细节”和“业务语义”彻底分开。

3. 硬件封装与 PCB 设计协同：V1 板子上的坑

3.1 封装选型：尺寸、间距、焊盘编号背后的讲究

软件封装是代码层面的事，硬件封装则是 PCB 设计里的实体。V1 项目做板子的时候，结构工程师给了一堆物料，什么 0603 电阻电容、SOP20 封装的驱动芯片、0.5mm 间距的双排板对板连接器、Type-C 16Pin、PWR2.5 插座、DB9/DB15 连接器，光是查封装和核对引脚就花了两天。

封装选型要先看工艺能力。0603 是 0.6mm x 0.3mm 的贴片封装，手工焊接难度极大，回流焊倒是没问题，但如果团队想样板阶段用烙铁手调，建议改成 0805 或者 1206，给自己留点余地。SOP20 的引脚间距 1.27mm，是比较常规的密度，PCB 厂基本都能做，但要注意丝印标注和引脚 1 的方向点，贴片时方向反了整块板直接废掉。

0.5mm 间距双排板对板连接器是另一个重灾区，这种连接器的焊盘密度高，扇出困难，而且焊盘尺寸必须严格按厂家推荐封装做。不要凭感觉把焊盘做大一点“方便焊接”，板对板连接器的引脚间距太密，焊盘做大会导致相邻引脚连锡，反而增加返修率。V1 板子打样回来发现焊接不良，后来查出来就是封装焊盘比推荐值大了 0.15mm，短路虚焊一起冒出来。

DB9 和 DB15 能不能用同一个封装？如果你只是看外形，两款连接器宽度几乎一样，但引脚数量和排列完全不同，DB15 有 15 个引脚，DB9 只有 9 个，硬套会导致多余的引脚悬空或错位。这种问题典型的“看着差不多，实际上是两个物种”，V1 阶段唯一靠谱的做法是每个型号都从正规渠道拿原厂封装，不要复用。

AD23 里焊盘顺序需要重新按顺序编号的痛点，我也遇到过。板子从第三方拿来的封装，Pin 编号乱七八糟，AD 里逐个改既慢又容易漏。快捷做法是用 PCB List 面板选中所有焊盘，按 X/Y 坐标排序，然后通过脚本批量重写 Designator。焊盘编号直接影响原理图与 PCB 的对应关系，编号错了导网表时全是报错。

再补充两个冷门封装：PWR2.5 电源插座和卧贴 4.5x4.5mm 轻触开关，这类器件机械尺寸很“随意”，不同厂家给出的推荐焊盘甚至不一样。我最常遇到的问题是把 A 厂家的 3D 模型套到 B 厂家的封装库上，结果实物安装时按键帽高度不对、插座定位柱卡不进孔。硬件的封装讲究“来源锁定”：用什么品牌的哪个料号，就必须用对应厂家给的封装和 3D，混搭必翻车。

3.2 封装库的来源确认与跨平台转换

AD、Allegro、Pads、Cadence 这些工具的封装库格式互不通用，V1 项目里电路设计用 AD，但外包的 PCB 设计是用 Allegro 做的，中间还经历过从 Pads 导入 AD，再从 AD 转 Allegro 的折腾。

先说封装库的来源。最靠谱的第一优先级永远原厂推荐封装，连接器厂家官网给的封装文件和 3D 模型往往经过验证，直接用出问题的概率最小。其次是封装库网站和主流的开源封装库，但这个必须多一道核对工序。我曾经从网上下载过一个 0603 封装，焊盘尺寸看着正常，实际打样回来才发现阻焊开窗偏大，焊盘边缘露出铜皮，样板直接报废。外部下载的封装，焊盘尺寸、丝印尺寸、原点位置、阻焊层、3D 模型对齐这五项全部要手动核对一遍，缺一项就返工。

AD 封装转 Allegro 的流程看起来简单，实际坑一堆：单位换算（mil 和 mm 混用）、层映射（Top Layer、Top Paste、Top Mask、Top Silk 必须一一点对）、原点偏移。转完之后别急着布线，先导出一份光绘文件在 CAM 工具里检查丝印是否压焊盘、阻焊开窗是否正确。画原理图封装的时候也一样，AD 里放置 Part 要确认引脚编号和实际的芯片手册完全一致，EMMC 封装这种引脚多、脚距密的器件，错一个引脚编号就是一块废板。

Cadence 16.6 的标准封装库下载之后，直接导入 PCB 前要注意版本兼容。老工程用 DSP 封装、新工程用 HSMC 封装，混着用会导致 Layout 规则冲突。如果项目里用的是 Xilinx 的 FPGA，比如 xczu19eg-2ffvc1760 这种 BGA 封装的超大芯片，那就不建议手工画封装了，直接从官方网站下载引脚文件导入，BGA 的球距、球径、去耦电容位置都是设计过的，手工画极容易出错。

关于半导体先进封装技术的背景，也可以用一句带过。像 CPO 共封装光学这类先进封装方向，本质就是把多个芯片或光模块封装到同一个基板上。它和我们在 PCB 上画封装是一个道理：接口定义清楚、引脚布局合理、热和信号完整性有保障，V1 项目虽然接触不到 CPO 这么前沿的工艺，但封装库的标准意识一定是从小器件开始建立的。

3.3 AD、Pads 到 Allegro 的转换实操记录

我把我做过的一次典型的“AD 导入 Pads 封装再转 Allegro”的实操过程记在这里，给有同样需求的团队一个参考。

第一步，源文件整理。把 AD 封装库里的所有封装导出为 ASCII 格式，检查是否有命名冲突，比如两个封装名字相同但 Pad 形状不同，这类情况在转换时会静默丢失数据。

第二步，单位统一。在 AD 里把单位切成 mil，和 Allegro 的默认单位保持一致。这一步不做的话，转换后所有尺寸都会放大或缩小，开出来的板子孔位对不上。

第三步，层映射表。AD 的 Top Layer 对应 Allegro 的 TOP，Top Paste 对应 PASTEMASK_TOP，Top Mask 对应 SOLDERMASK_TOP，Top Silk 对应 SILKSCREEN_TOP。每一层都要手动确认，特别是阻焊层，漏掉的话焊盘上没有阻焊开窗，板子打样回来全铺绿油，焊接直接没法做。

第四步，DRC 校验。导入完成后，在 Allegro 里跑一遍封装 DRC，确认焊盘间距、丝印距离、原点位置有没有异常。

这套流程走一遍大概两小时，但把问题挡在了制版之前，比板子打回来再返工划算得多。

4. 发布与运行的“封装”：V1 上线前后的实战排查

4.1 WebAPI 发布后 Swagger 404 的定位与修复

V1 后端是 .NET WebAPI，开发环境 Swagger 好好的，发布到服务器之后访问/swagger/v1/swagger.json直接 404。这个问题太经典了，我用“vs2026 webapi 发布后 提示 not found /swagger/v1/swagger.json”这个关键字搜都能搜到一堆，但真正的原因往往不在代码里。

最常见的原因是Program.cs里把 UseSwagger 写进了环境判断：

if (app.Environment.IsDevelopment()) { app.UseSwagger(); app.UseSwaggerUI(); }

开发环境能跑，发布后环境变量不是 Development，Swagger 中间件压根没挂载。修复方式是把这段逻辑从环境判断里移出来，或者改成if (app.Environment.IsDevelopment() || app.Environment.IsStaging())，生产环境如果需要接口文档，直接无条件启用也行，但要注意权限控制，不能在公网裸奔一个能看全部接口定义的 Swagger 页面。

第二个坑是虚拟目录。发布到 IIS 的子应用时，SwaggerUI 默认路由是/swagger，但如果站点挂在http://host:port/appname下，SwaggerEndpoint 的相对路径就错了。解决方法是把端点地址改成相对路径./v1/swagger.json，或者直接指定完整路径。

第三个坑是托管模型。IIS 的 InProcess 模式出问题比 OutOfProcess 多，特别是 Swagger 同时依赖静态文件和路由时。排查这种问题最快的办法是看服务器上的日志和事件查看器，如果 IIS 返回 404 但应用日志里没有任何请求记录，那大概率是请求根本没进入应用，问题在 IIS 配置层；如果日志里有请求但报错，才是应用代码的问题。

发布环境这件事，还可以延伸一下 Sysprep 封装。如果 V1 要部署到很多台工控机，别一台台手动装 .NET 运行时、配 IIS、装串口驱动，用 Sysprep 做一个基础环境镜像，把运行时、驱动、防火墙白名单、IIS 配置全部固化好，再配合无人值守部署脚本。批量化部署必须走镜像封装，这是 V1 阶段最容易被忽略的效率问题。

4.2 AI 推理网关 502 的逐层定位

V1 上线之后遇到一个非常扎眼的错误：unexpected status 502 bad gateway: unknown error, url: http://127.0.0.1:15721/v1/responses。当时看到这个报错我第一反应是本地模型服务崩了，排查下来才发现问题没有这么简单。

502 Bad Gateway 说明出在网关和上游之间。我的架构是前端请求本地推理网关的/v1/responses接口，网关再把请求转发给真正的模型服务。502 的本义是网关拿不到上游的正常响应。所以排查要一层层剥开：

第一步，确认本地网关进程是否存活。直接请求一个最基础的端点，比如GET http://127.0.0.1:15721/v1/models，如果这个也失败，说明网关进程可能根本没起来，或者端口被占用。

第二步，看网关日志。我在 Windows 上执行netstat -ano | findstr 15721找出监听进程的 PID，再根据 PID 定位到具体的程序和日志目录。日志里如果显示上游连接失败，那问题就出在模型服务。

第三步，查上游模型服务的显存和内存。本地跑大模型最常见的问题就是显存溢出，模型服务进程还在，但推理时直接 OOM，网关收不到响应就返回 502。用任务管理器或者nvidia-smi一看便知。

第四步，考虑超时问题。大模型生成长文本可能超过默认网关超时时间，网关在上游还没返回前就断开了连接。这种情况下，前端 SSE 的超时设置要和后端的超时联动，不能前端等 60 秒、网关 30 秒就掐断。

还有一个隐蔽的坑：环境变量或系统代理残留。如果机器上设置了 HTTP 代理，而网关程序没有做内网地址绕过，请求可能会被代理服务器转发，代理处理不了就返回 502。排查时直接检查系统的代理设置，或者把NO_PROXY环境变量加上127.0.0.1,localhost。

这次 502 让我养成了一个习惯：所有本地服务都要有健康检查接口和启动脚本。不能靠人肉记忆“昨天明明能跑啊”来判断服务状态，写一个healthcheck.bat，开机自动检查端口和模型加载状态，有问题直接告警。

4.3 H5 封装分发、版本对比与迭代流程

V1 项目同时有 H5 端和微信小程序端，H5 需要封装成 App 分发，小程序要发布到平台。这个过程里最容易乱的是版本管理。

H5 封装分发平台上一旦发布多个版本，用户手里的版本和最新版本经常对不上。我的做法是把版本信息注入到前端代码里：用 vue-cli 或 vite 的 DefinePlugin 在构建时注入APP_VERSION和BUILD_TIME，这样页面页脚能显示当前版本号，配合后端接口返回版本号做对比。用户报问题的时候，第一步就能确认他手里的版本是不是最新的。

版本差异比对用 vue 封装 git 信息也是个好方案。构建时用child_process执行git rev-parse --short HEAD，把 commit hash、分支名、构建时间写进一个version.json，打包后塞进 H5 的静态资源目录。发版记录里把git log --oneline的变更摘要贴上去，团队之间沟通就非常明确。

小程序端同样要显示版本号，但注意小程序的发版审核周期比 H5 长，经常会遇到“H5 已经修了 Bug，App 还带旧代码”的情况。我的经验是请求接口时带一个 clientVersion 字段，后端对过旧的版本返回“请升级”的提示，而不是拿着旧逻辑硬跑。

5. 封装验收与复盘：怎么判断 V1 封装得成功

5.1 封装的三个验收标准

V1 做完了，团队开复盘会的时候我问了自己三个问题：

第一个问题：上游换了没，下游改了多少？AI 推理网关如果从本地 127.0.0.1 换成云端的服务地址，前端是不是只改一个 baseURL 就行？如果还需要在业务代码里搜v1/responses才能找到所有调用点，说明封装失败。

第二个问题：新增一个硬件设备或新增一个数据源，改动量是 1 处还是 N 处？Modbus 设备从温控器换成电表，如果只有通信层的驱动代码改，协议解析和业务语义层不用动，就算合格。

第三个问题：出了问题，团队能第一时间定位到封装边界吗？之前遇到 AI 网关 502，团队能迅速判断这是 AI 交互层的问题还是网关配置问题，就是因为封装边界清晰。如果报错的时候每个人都得看一遍全链路才能定位，那就是封装没过关。

5.2 V1 的经验要变成团队的公共资产

复盘会上我让大家把 V1 所有的坑整理成一张表，分类、现象、原因、解法、负责人、状态，一共记了三十多条。其中 Swagger 404、502 网关、Modbus 帧错乱、封装库焊盘偏大这四条是影响最大的，直接补了文档和检查清单。

封装这件事不是一次性的。V1 只是第一次把封装的边界画出来，V2 真正验证的是这些边界是否选对了。后来我们给封装库建了统一的检查规则，封装问题在画板阶段就被 DRC 挡住；给 AI 交互层加了重连和缓冲机制，流式输出卡顿的问题也明显减少。

我个人最深的体会是：V1 项目里功能代码写得好不好，决定这个项目能不能跑通；但接口和封层的边界画得好不好，决定这个项目能不能活到 V2。技术栈随时可以换，可封装的意识和边界感，才是真正值得沉淀下来的东西。如果让我重做一次 V1，我会在第一天就把封装清单列出来，而不是等到问题爆发了再靠加班弥补。