拓宇 AI / 拓宇实验室

简择手记-把整本长书读薄的微信小程序

Mon, 19 Oct 2026 09:42:59 +0800

简择手记是一款把「整本长书读薄」的微信小程序。它的口号是「择其简要，记其要义」——不整段搬运原文，而是把一本书的骨架提炼出来，拆成章节、条目与可逐节精读的长文，让读者用碎片时间也能把一本厚书读透、记住、用得上。

作品初衷

很多好书内容扎实，但篇幅长、结构散，读完容易记不住、用不上；而单纯的「金句摘录」又太碎，丢了上下文。简择手记想做的是中间那一层：保留原书的章节脉络，把每一章拆成可独立阅读的条目或长文，既读得完，也记得住、查得到。

内容结构

小程序以「书单」为入口，每本书按自身特点采用两种阅读结构之一：

条目型：把全书拆成一条条可独立执行的要点，按章节分组、逐条编号，适合工具型、清单型的书。
长文型：保留章节论述的完整上下文，按节逐篇精读，支持上一节 / 下一节连续翻页，适合观点型、论述型的书。

目前已收录两本书：

《高性价比人生指南》（作者 eternity4719）——31 章 · 498 条，用「不要早死」「不要浪费钱」「别把自己搭进去」等主题，把寿命、金钱与人身自由拆成一条条可落地的要点。
《自洽的程序员》（作者辣条加辣）——8 章 · 45 节，聚焦工作中的焦虑、倦怠、迷茫与抑郁，梳理情绪、转变心境，成为一个自洽的程序员。

核心功能

书单首页与更新记录

首页即书单，一屏看清收录了哪些书、各自的章节与条目规模；下方更新记录按时间列出每次收录与上线，读到哪、更新到哪一目了然。

章节目录

每本书都有清晰的章节目录。条目型的书以卡片网格呈现每章及其条目数，长文型的书以列表逐节展开、含「本章导读」，方便按需跳读。

全文搜索

书详情页内置搜索框，可按标题或全文关键字检索，把「找一句话」变成「搜一个词」，需要时直接定位到对应条目或章节。

逐节精读与翻页

长文阅读页保留原文排版与配图，顶部显示当前进度（如 16 / 45），底部「上一节 / 下一节」连续翻页，通勤、排队等碎片时间也能连贯读完一章。

条目化清单

条目型的书里，每条要点都标注所属章节与序号（如「不要早死 · 第 24 条」），既是阅读也是清单，看完能直接照着做。

界面预览

以下为小程序端的实际截图：从书单首页、书详情与搜索，到章节目录、条目列表，再到长文逐节阅读。

书单首页：收录书目与更新记录

书详情：封面、简介与全文搜索

书详情：《自洽的程序员》8 章 45 节

章节目录：条目型卡片网格

条目列表：按章节分组、逐条编号

章节目录：长文型逐节列表

长文阅读：2.9 天天用 AI，以后不会写代码怎么办

长文阅读：4.2 接纳胜过改变

长文阅读：结语 · 成为一个自洽的程序员

适合人群

买了厚书却总读不完、读完记不住的读者
想用通勤、排队等碎片时间系统读完一本书的人
偏好清单式、可落地要点的工具型阅读者
关注个人成长、职场心态与程序员自我调节的读者

使用场景

通勤路上翻几节长文、睡前读几条人生清单、遇到问题时全文搜索定位对应章节、把要点当作行动清单逐条落实——把一本厚书拆进日常，读薄也用得上。

获取方式

微信搜索小程序「简择手记」即可打开使用，无需下载 App，即用即走。

许愿式编程 DeepSeek V4.1 Flash

Sun, 18 Oct 2026 20:10:40 +0800

先回忆下过去的 AI 编程。

之前我们叫 Vibe Coding，你给 AI 提需求，写提示词，AI 输出代码片段。但是，项目架构、依赖环境、报错排查，大多还是要你自己来。AI 只是帮你敲代码的助手，整个项目的规划、调试、修复，重担依然在开发者身上。一旦项目复杂，多轮对话来回拉扯，非常消耗精力。

而 DeepSeek 这次更新的 V4.1 Flash，带来的许愿式编程，英文叫 Wish-Driven Programming，本质是以意图驱动的全链路项目 Agent。

简单一句话：你只描述想要什么结果，AI 独立完成整套项目交付闭环。

你不用指定用 Vue 还是 Java，不用拆分模块，不用定义接口。你只需要说清楚你的愿望：我想要一个网页版彩票历史走势图，带网格、折线、色块，能加载历史开奖数据。

模型会自动做几件事：

第一，拆解需求，规划整个项目架构；

第二，选择合适技术栈，生成全套代码文件；

第三，在 Harness 环境中自动运行、自测；

第四，发现报错，自主定位问题，修改代码，反复迭代；

第五，直到交付可以直接运行的完整工程。

官方演示案例，一句需求，直接生成故宫 3D 场景、网页赛车游戏、Godot 游戏工程，全部从零构建，不需要大量提示词铺垫。

底层核心，是自反馈强化学习。模型写完代码之后，会自我验证、自我纠错，不再是一次性输出代码片段就结束。

那哪些人最受益？

第一，零基础小白，不会写代码，有产品想法，能快速验证原型；

第二，独立开发者、全栈，像我们平时做小程序、工具网站，快速搭建项目骨架，省下大量重复造轮子的时间；

第三，游戏、3D 原型快速验证，快速产出可交互 Demo。

但是，一定要理性看待，许愿式编程不是无限魔法。

第一，你的愿望描述，依然决定最终成品质量。需求越笼统，AI 理解偏差越大；需求边界越清晰，交付质量越高。

第二，复杂大型项目，依然需要人工介入做方案把关、安全审核。它适合原型、中小型项目快速落地，不适合直接交付生产级大型系统。

第三，它能帮你做工程搭建、写代码、查 bug，但业务逻辑、产品设计，依然需要人来把控。

从 Vibe Coding 到 Wish Coding，本质是人机协作范式的转变。

过去是人适配 AI，把需求翻译成 AI 能看懂的详细提示词。

未来是 AI 适配人，人只需要表达意图，AI 完成全部工程落地。

这就是 DeepSeek V4.1 Flash 带来的许愿式编程。

技术的终点，就是把门槛不断降低，让想法，直接变成产品。

MD2DOCX · Markdown 转 Word 文档

Sun, 18 Oct 2026 11:00:00 +0800

拖入 Markdown 文件或直接粘贴内容，左侧编辑、右侧实时预览，一键导出 Word 文档，免注册、免安装。

码链 · HTML 转网页链接

Sun, 18 Oct 2026 10:00:00 +0800

码链是一款轻量化、免注册的在线 HTML 转链接工具：粘贴代码或拖拽上传文件，即可生成可公开访问的网页链接，支持实时预览、全屏浏览与安全防护，适合前端页面分享、临时网页展示与代码调试。

本条目用于首页「在线演示」区块，点击卡片直接打开该工具的线上演示站点。

件杂货（钢材）盘点 AI 识别计数解决方案

Sat, 17 Oct 2026 14:00:00 +0800

钢材堆场的盘点一直是件「既慢又不能错」的事。钢卷、中厚板、螺纹钢、线材盘条、型钢、钢管、钢坯这些件杂货，同规格、重外观、高堆叠，靠人眼清点既慢又错，同规格货物还无法仅凭外观区分炉号与批次。本方案面向露天堆场场景，用旋转框检测、实例分割、端面密集计数、3D 点云与 OCR 编码比对这些手段，把以「天」计的人工盘点压缩到以「小时」计的全场快盘，人工只需复核约 10% 的差异件。

无人机航拍仓储园区：全场快盘的采集底图

人工盘点为什么必须被替代

钢材堆场的三大痛点决定了「纯人工」模式的天花板。

耗时

一个万吨级堆场人工清点往往需要数天；货车压港、船期等待，库存数据到手时已经失真。

易错

遮挡、堆叠导致漏计重计；夜晚与雨雪天视线差，数据质量完全依赖盘点员个人状态，错账率不可控。

难追溯

同规格螺纹钢、同规格钢卷外观几乎一致，肉眼无法区分炉号与批次；盘点结果没有影像证据，差异无法举证。

典型堆场场景下，这些干扰因素还会叠加出现：货物上下叠放使俯视只能看到顶层；户外粉尘、雨雪反光、逆光、夜间照明不均持续拉低成像质量；行车吊装作业中货物移动，极易重复计数或漏计。

难点	具体表现	技术对策
遮挡与层叠	货物上下叠放，俯视只见顶层；板垛只露侧面与边部	多角度采集 + 3D 点云分层还原下层数量
同类同规格	同批次螺纹钢、同规格钢卷外观几乎一致	不靠外观区分，用标签 OCR + 台账编码比对
环境干扰	户外粉尘、雨雪反光、逆光、夜间照明不均	图像增强 + 可用性阈值 + 低置信转人工兜底
标签不可靠	卷号 / 标牌锈蚀、脱落、被压住	OCR 只作辅助证据，与单证、位置、3D 联合决策
动态干扰	行车吊装作业中货物移动，重复计数或漏计	DeepSORT / ByteTrack 时序跟踪，防止重复

四层架构：从「看得见」到「回得去」

系统自上而下分为数据采集层、AI 识别引擎、盘点应用层与系统集成层。采集层解决「看得见」，识别引擎解决「认得准、数得清」，应用层解决「用得上、核得准」，集成层解决「接得通、回得去」。多路采集源按「全场快盘 / 实时出入库 / 高精度局部 / 深度测量」四类场景组合，互为兜底。

层次	解决什么	关键设计
数据采集层	看得见	多路采集源覆盖全场与死角，无人机兜底全场快盘
AI 识别引擎	认得准	分货种定制算法，2D + 3D + OCR 联合决策，输出检测框 / 掩码 / 点数 / 编码 / 层数五类结果
盘点应用层	用得上	置信度分流，人工只处理低置信与冲突件；初盘、复核、入账、报表一条链
系统集成层	回得去	识别结果沉淀为标准化事件，向既有业务系统双向同步

一个通用模型打不了天下，逐货种定制识别方法

不同钢材形态差异极大：螺纹钢、钢管这类「端面密集小目标」优先用端面视角；钢卷、板坯这类大目标优先用俯视 + 3D 分层。下表为各货种的可见特征、推荐识别方法与计数口径。

货种	可见特征	推荐识别方法	计数口径
钢卷	端面圆柱、卷号标牌	端面旋转框检测 + OCR 卷号比对	卷数 / 吨
中厚板	侧面层线、边部轮廓	实例分割做层间分离 + 3D 分层	张数 / 层数 / 吨
螺纹钢	端面截面密排小圆	端面密集计数（先捆后支）	捆数 + 支数
棒材圆钢	端面圆形截面、金属断口	端面旋转框检测 + 密集计数	支数 / 吨
线材盘条	端面螺旋纹、层叠堆放	端面检测 + 3D 点云分层	盘数 / 吨
H 型钢	端面固定截面形状	旋转框（OBB）检测	支数
无缝钢管	端面圆环阵列	端面圆环检测 + 密集计数	支数 / 根数
钢坯	矩形截面网格	网格切分 + 3D 分层	支数 / 吨

钢卷仓库

中厚板堆垛

螺纹钢成捆堆放

无缝钢管堆场

螺纹钢堆场

H 型钢堆场

钢坯库

堆场航拍全景

设计要点：螺纹钢、钢管这类端面密集小目标，优先用端面视角而非侧面视角，近距离高分辨率采集是准确率前提；钢卷、板坯这类大目标，优先用俯视 + 3D 分层还原下层数量。

七类算法组合，覆盖「定位 → 拆分 → 点数 → 测深 → 追码」

按货种与场景路由到合适的算法组合，各算法独立可替换、可灰度上线。

旋转框目标检测（OBB）

钢材堆垛往往呈任意朝向，水平框（HBB）会产生大量重叠与误检；旋转框输出带角度定位，精准锁定每个钢卷、每根型钢。

关键：训练数据需标注角度；端面小圆这类小目标需提高输入分辨率。

实例分割

相邻捆包、相邻钢卷粘连严重，仅靠检测框无法区分边界；对每个实例输出掩码，实现轮廓级拆分与板垛层间分离。

关键：遮挡部分用 3D 点云补全。

端面密集计数

螺纹钢捆、钢管捆端面是密集小目标，通用检测模型易漏检；对端面截面做点数回归，配合「先捆后支」两级计数。

关键：高分辨率端面图像（近距离采集）是准确率的前提。

3D 点云感知

俯视看不到的下层数量必须靠深度信息推断：做层数分割与体积估算，再结合单件理论重量反算件数。

关键：点云与 2D 图像需做时空对齐与融合。

标签 OCR 与编码比对

识别卷号标牌、钢印、铭牌编码，与 WMS / TOS 台账逐条比对，输出「匹配 / 疑似 / 不匹配」三档结果，支撑炉号与批次追溯。

关键：针对锈蚀、倾斜、低对比度场景专项微调；OCR 只作辅助证据。

多模态融合与时序跟踪

2D 检测 + 3D 点云分层 + OCR 标签按空间位置对齐做联合决策；吊装移动目标用时序跟踪防止重复计数。

关键：冲突时以「证据充分者优先」，仍冲突则转人工。

主动学习闭环

人工复核结果自动回流为训练样本，针对长尾场景（锈蚀标签、极端天气、异形堆垛）持续迭代，形成「识别 → 复核 → 再训练」的飞轮。

关键：复核数据打标后按周 / 月批量进入标注流水线。

按精度与成本分层组合，避免「一把抓」

能通过固定相机 + 出入库关口实现自动计数的，就不依赖无人机定时飞行；无人机用于兜底的全场盘点与复核。

无人机 + RTK 航线飞行

大面积堆场小时级完成全场粗盘；RTK 厘米级定位保证垛位可复测、可对比。

设备：多旋翼无人机 / RTK 基站 / 正射相机

龙门架 / 门禁固定相机

出入口自动计数、防漏记；事件驱动入账，无需人工发起。

设备：工业双目相机 / 补光灯 / 边缘算力盒

行车随动相机 + 手持 PDA

遮挡区、标签核对、差异件精核；行车视角贴近货物，端面图像清晰。

设备：行车 / 吊具随动相机 / 工业 PDA / 5G 图传

3D 扫描 / 激光雷达

层数、体积、重量反算；为遮挡区域提供深度证据。

设备：固态激光雷达 / 手持 3D 扫描仪

龙门架固定相机：出入口自动计数

行车随动相机与手持终端

选型原则：固定相机 + 出入库关口优先实现自动化；无人机负责兜底快盘与复核；精度要求高的局部场景再上随动相机与深度设备，按 ROI 分阶段投入。

从驾驶舱到复核台

以下为盘点系统的核心界面形态（界面数据为 MVP 演示口径，实际以现场标定结果为准）。

盘点系统 MVP 总览：上部为 Web 端「盘点总览驾驶舱」，下部为移动端 App 的盘点任务、识别补拍、差异复核与盘点看板

盘点总览驾驶舱

按货种展示盘点进度，并列出今日盘点任务：任务编号、负责区域与采集来源（无人机 / 龙门架 / 车载终端 / 手持 PDA）、进度、差异件数与执行状态，一眼看出哪片堆场还没盘完、哪些差异还没处理。

AI 识别工作台

龙门吊吊运螺纹钢捆：检测框与掩码标注示意，「遮挡区域」自动转入复核队列

在工作台上叠加检测框、掩码与计数结果，标注置信度；被判定为遮挡或冲突的区域不直接入账，而是自动进入复核队列。

差异复核队列

人工只处理系统标出的差异件，每条差异都带原因与置信度，复核时能直接看到「为什么它可疑」。

垛位 / 相机	货种	AI 识别	台账数	差异	置信度 · 原因
B3-06 · CAM-B3-02	螺纹钢	9 捆	9 捆	0	0.71 · 低置信（标牌锈蚀）
A2-11 · UAV-01	钢卷	24 卷	22 卷	+2	0.98 · 高置信（台账冲突）
C1-03 · VAN-02	中厚板	46 张	46 张	0	0.79 · 低置信（层线模糊）
D2-08 · CAM-D2-01	钢坯	132 支	121 支	+11	0.97 · 高置信（出入库未登记）
B1-01 · CAM-B1-04	钢管	57 根	57 根	0	0.66 · 低置信（夜间照明）
A4-02 · UAV-02	型钢	36 支	36 支	0	0.88 · 中置信（端面反光）

出入库自动计数

门禁相机视角下的钢坯吊装：吊装运动目标经 ByteTrack 时序跟踪，同一吊次只计一次

关口相机事件驱动计数，同一吊次只计一次，防止重复计数。

3D 点云分层

对板垛、卷堆做层数分割与体积估算，把俯视看不到的下层数量还原出来。

移动端 App · 理货员 / 库管手持端

手机 App 与 Web 端共用同一套识别服务与台账数据，现场补拍、复核结论即时回写。

与既有系统双向打通，盘点结果自动回流

识别结果沉淀为标准化事件，经 REST API / 消息队列 / 中间表与业务系统双向同步。

对接系统	对接方式	作用
WMS 仓储管理系统	REST API 双向	读取台账、回写盘点结果、库存同步
TOS 码头操作系统	REST API / 消息队列	堆场位置管理、出入库事件触发
ERP 财务系统	API / 中间表	重量对账、盘盈盘亏核销
视频监控平台	RTSP / GB28181	接入固定相机与无人机图传
数据中台	数据总线	识别结果统一存储与分析

所有识别结果保留原图 + 坐标 + 置信度 + 识别编码，保证可追溯、可举证；
出入库事件驱动：门禁相机触发即自动计数，无需人工发起；
台账回写采用「预写 + 确认」两段式，避免把未复核结果直接覆盖正式账。

可量化的验收口径，先标定、后承诺

以下为建议的验收流程与目标设定方式，P0 试点阶段需结合现场实测基线校准后再正式承诺指标。

选取独立测试垛区：覆盖至少 3 个货种、含遮挡与夜间工况的典型垛区。
人工精盘生成真值：由两名以上理货员独立清点并交叉确认，作为真值基准。
对比 AI 输出：逐垛比对件数、重量、编码匹配率三项指标，出具差异清单。
验收与留档：达到目标值即验收；未达标项进入 P0 迭代，记录基线便于后续对比。

四阶段推进：先试点、后推广、再闭环

避免一次性大投入，每阶段有明确交付与验收出口，目标 3–6 个月实现主力货种盘点 AI 化。

试点验证：选 1 个货种（建议钢卷）+ 1 个垛区，跑通「采集 → 识别 → 比对」链路。
多货种扩展：覆盖 2–3 个主力货种，接入 WMS 比对，上线差异复核工作流。
常态闭环：出入库关口自动计数上线，实现日盘 / 周盘常态化。
长尾攻坚：主动学习持续迭代，攻克锈蚀标签、恶劣天气、异形堆垛等长尾场景。

把不确定性写进方案，而不是藏起来

每类风险都有明确的兜底策略，确保低置信时「不硬出账」。

风险	应对策略
训练样本不足	先小范围标注 + 数据增强，配合主动学习持续扩展样本
遮挡导致漏计	多角度 / 多高度补拍，固定相机与无人机结果交叉验证
同类同规格难以区分	不依赖外观，靠标签 OCR + 台账编码比对定位炉号批次
恶劣天气影响成像	设置可用性阈值与人工巡检兜底，低置信时不硬出账
现场与方案假设不符	P0 试点先做实测标定，再定最终指标
数据安全与合规	图像与台账本地化存储，脱敏后上云分析

钢材盘点 AI 化的本质：多模态感知 + 业务闭环

技术上没有银弹——钢卷靠端面检测、螺纹钢靠端面密集计数、层叠靠 3D 点云、规格追溯靠 OCR 比对，每种货种都要定制策略。落地的关键不在模型多先进，而在于把 AI 嵌进真实的盘点流程：让人工只处理 10% 的差异件，让复核结果持续反哺模型。盘点不再是「拍照 → 出数量」，而是一条可追溯、可举证、能自我进化的业务闭环。

点学单词-人教版教材同步的英语单词发音小程序

Sat, 17 Oct 2026 11:20:00 +0800

点学单词是给孩子做的英语单词小程序。中小学生背单词、练发音的痛点很具体，而市面上不少学习软件广告多、要登录注册、收费项目繁杂，于是干脆自己做了一款免费、无广告的课本单词点读工具，给孩子一个干净纯粹的英语学习环境。

作品初衷

从真实的学习场景出发做减法：不弹广告、不要账号、不做付费墙，打开就是课本单词。所有内容严格对齐人教版教材单元，课本学到哪，就学到哪，与校内课堂进度完全同步。

词库覆盖

完整适配人教版小学、初中、高中全套 20 本教材
合计 6157 个课本原版单词，严格按教材单元分组
预习、复习、背单词都适配，不需要再找教辅对词表

核心功能

标准在线发音

点击单词即可播放标准读音，解决家长发音不准、没人带读的难题，孩子可以自主跟读、磨耳朵。

多维单词学习素材

每个单词配套例图、常用短语和课本原版例句，不止记拼写，还能理解词义、学会实际运用。

免登录即用

无需注册账号，打开直接使用，省去繁琐操作，点开就能学。

纯净无广告

全程没有弹窗广告、没有付费弹窗，无多余干扰，孩子专注在单词本身。

长期稳定可用

无需下载 App，小程序即用即走，不占用手机存储空间，换设备也能随时打开。

界面预览

以下为小程序端的实际使用截图：从选词书、浏览单元单词，到查看单词详解与例句跟读。

首页：按小学 / 初中 / 高中选择词书

单元单词列表：音标释义，点行播放

单词详情：配图、音标、词性与短语

课本原版例句：逐句跟读、反复听

收录统计：20 本教材 6157 个单词

适合人群

使用人教版英语教材的小学生、初中生、高中生
担心自身发音不标准、没法辅导孩子英语的家长
需要课前预习、课后巩固、跟读背单词的家庭

使用场景

课前预习单元单词、课后复习巩固、碎片时间跟读练发音、听写前过一遍词汇，随时随地练习课本单词，帮助孩子攻克单词与口语发音，告别哑巴英语。

获取方式

抖音主页直达，扫码即可进入小程序体验。

Mutiai —— AI 聚合问答工具

Sat, 17 Oct 2026 10:40:10 +0800

> 一个窗口，装下十多款主流大模型。一次提问，多模型同时作答，横向对比各家答案。

官网：http://mutiai.0315e.com/

产品简介

Mutiai 是一款个人开发的 AI 聚合问答客户端。它把国内十多款主流大模型整合进同一个窗口，你只需要输入一次问题，点击发送，所有已接入的大模型会同时开始回答，方便你对各家答案进行横向对比。

核心特性

1. 一窗多模型

单个窗口同时接入豆包、DeepSeek、Kimi、通义千问等多款主流大模型
无需在多个网页、多个标签页之间来回切换
各模型答案并排展示，一目了然

2. 一次提问，多方作答

只需输入一次问题，一键发送
多个大模型同步返回结果
省去反复复制粘贴、逐家提问的繁琐操作

3. 横向对比，甄别差异

各家 AI 的回答同屏展示，方便对比内容质量与风格差异
可快速识别 AI 幻觉（一本正经地编造错误内容）等常见问题

4. 提示词模板 + 变量填充

支持将常用提示词存入模板库，随时复用
模板支持变量占位符，例如：用费曼学习法讲解【{{topic}}】
使用时可自由填充变量，例如将 {{topic}} 替换为「木桶原理」，一键发送给所有模型

5. 灵活的界面布局

支持全屏展示单个面板
支持自由切换布局，例如双列视图
面板可单独收起、展开，按需组织工作区
支持白 / 夜主题切换

隐私与安全

不经服务器中转：所有对话请求直接发往各 AI 厂商接口，不经过作者服务器中转
不上传隐私数据：不会收集、上传你的对话与隐私信息
数据本地保存：账号信息、对话数据全部保存在本地设备

平台支持与安装

平台	支持方式
Windows	直接下载安装包，安装即用
macOS	暂无预编译包，可自行下载源码编译

开源与源码

项目源码开源，可在 Gitee 查看：支持自行下载编译，适配不同平台。

开发背景

Mutiai 采用 Vibe Coding 方式开发，是一个简洁、朴素、注重隐私的实用小工具，适合经常需要在多个 AI 之间对比答案、追求效率的用户。

智绘SQL-对话即出图，数据更鲜活

Sat, 17 Oct 2026 10:18:18 +0800

> 对话即出图，数据更鲜活

一个把「自然语言提问」直接变成「SQL 查询 + 可视化图表」的轻量级智能数据分析工具。

一、产品定位

智绘SQL 面向所有需要看数据、但不想写 SQL 的人。你只需要像聊天一样说出想问的问题，它就能：

读懂你的问题，结合数据库真实表结构自动生成 SQL；
连接你的数据库执行查询，返回真实数据；
基于查询结果自动生成 ECharts 图表，让数据直接变成可看的图。

整个过程不需要打开任何 BI 工具，也不需要等待数据团队排期。

二、它解决什么问题

传统方式的痛点	智绘SQL 的做法
提需求 → 排期 → 取数，链路动辄一两天	提问到出图，一次对话完成
非技术同事看不懂、也写不出 SQL	用中文描述需求，AI 负责写 SQL
拿到数据还要手工整理、做图	数据返回后自动生成图表配置
传统报表是固定的，临时问题追不上	每个问题都是一次即席查询

一句话概括：把「取数」这件事的门槛，从「会 SQL」降到「会提问」。

三、核心功能

1. 对话式取数（对话）

输入自然语言问题，例如「上个月订单量趋势」「各产品销售额对比」「用户增长情况」；
系统自动调用大模型生成 SQL，并展示生成的 SQL 语句，可一键复制；
执行查询后返回数据表格，做到「SQL 可见、结果可查」，不是黑盒；
内置推荐问题：连接数据库后，会自动根据你的表结构推荐几个可以问的问题，第一次使用也无从下手。

2. 智能图表生成（图表）

数据返回后自动生成图表，无需手动配置坐标轴、系列、图例；
支持在 7 种图表形态间随时切换：

auto（自动推荐）/ line 折线 / bar 柱状 / area 面积 / scatter 散点 / pie 饼图 / radar 雷达；
切换图表类型时会基于同一份数据重新生成配置，方便快速找到最合适的表达方式。

3. 表结构感知（查看表结构）

连接数据库后可读取真实的表名、表注释与字段列表；
支持多选表，批量导出表结构到 Excel，也可以一键全部导出；
这份表结构会作为上下文传给大模型，保证生成的 SQL 用对表名和字段名——这是「生成准确 SQL」的关键前提。

4. 结果导出

查询结果表格支持导出为 Excel（.xlsx），方便二次加工或直接汇报；
表结构信息同样支持导出，便于交接与文档沉淀。

5. 数据源与密钥管理（设置）

API Key 配置：填写火山方舟（Ark）API Key，作为模型调用的凭证，保存后本地留存；
数据库配置管理：新增、保存、删除多套数据库连接配置（类型 / 主机 / 端口 / 数据库名 / 用户名 / 密码），并可直接「使用」切换到某一套；
配置持久化在浏览器本地（localStorage），下次打开无需重新填写。

6. 帮助

内置使用指南，说明从配置到出图的完整流程，降低首次上手成本。

四、工作原理

智绘SQL 的核心是两次大模型调用 + 一次数据库查询：

第一次调用：把「用户问题 + 真实表结构」交给大模型，让它只输出一条标准 SQL；
数据库查询：后端连接 MySQL / PostgreSQL 执行这条 SQL，拿到真实数据（不是模型编造的数据）；
第二次调用：把查询结果交给大模型，让它输出一份 ECharts 图表配置；
前端渲染：展示 SQL、结果表格与图表，并允许切换图表类型、导出数据。

flowchart LR

A[用户自然语言提问] --> B[拼接真实表结构]

B --> C[大模型调用 1<br/>生成 SQL]

C --> D[连接数据库执行查询]

D --> E[真实结果数据]

E --> F[大模型调用 2<br/>生成图表配置]

C -.可复制.-> G[展示 SQL]

D -.-> H[结果表格 / 导出 Excel]

F --> I[ECharts 图表渲染]

设计上的两个关键取舍：

只让模型写 SQL，不让模型编数据：数据永远来自你的数据库，模型只负责「翻译」和「表达」；
SQL 对用户完全透明：生成的语句始终展示出来，既方便核对，也方便直接拿去复用。

五、技术栈

层次	技术选型
前端框架	Next.js 14（App Router）+ React 18 + TypeScript
样式	Tailwind CSS（深色主题、玻璃拟态卡片）
图表	ECharts 5（echarts-for-react）
内容渲染	react-markdown
图标	lucide-react
数据导出	xlsx
服务端	Next.js Route Handlers（Node.js 运行时）
数据库驱动	mysql2、pg（另有 better-sqlite3、oracledb 依赖）
大模型	火山方舟 Ark · `doubao-1-5-pro-32k-250115`

六、快速上手

配置 API Key：进入「设置」，填入火山方舟 API Key 并保存；
配置数据库：在「设置」中新增一套数据库连接（MySQL 或 PostgreSQL），保存后点击「使用」；
开始提问：回到「对话」，输入你的问题，或直接点击系统推荐的问题；
看图与导出：查看生成的 SQL、数据表格与图表，按需切换图表类型或导出 Excel。

七、适用场景

运营 / 市场：临时想看某个活动的转化、某段时间的订单趋势，不必走数据需求流程；
产品经理：快速验证一个假设，用真实数据支撑判断；
数据分析师：把重复的取数工作交给它，自己专注在更有价值的分析上；
开发 / 测试：连上自己的库，快速查数据、核对数据、导出结果；
教学演示：把「自然语言 → SQL → 可视化」这条链路完整地演示出来。

八、当前能力边界

为了准确，这里明确说明现状：

已完整实现：对话式取数、SQL 生成与展示、MySQL / PostgreSQL 查询执行、图表自动生成与类型切换、表结构查看与导出、结果导出 Excel、API Key 与多数据源配置管理；
已支持的数据源：MySQL、PostgreSQL（Schema 读取与查询执行均已实现）；
依赖中已引入但暂未接入路由：SQLite、Oracle（驱动已在依赖中，接口层尚未实现，选择其他类型会返回「不支持的数据库类型」）；
占位页面：查询历史目前为占位状态，尚未接入真实历史数据展示。

九、一句话总结

智绘SQL 把数据分析里最繁琐的两段——写 SQL 和 画图表——压缩成了一句话。

你只管提问，SQL 和图表交给它。

AI 海报素材站管理端 AI 生成全流程解析

Fri, 16 Oct 2026 17:19:13 +0800

从前端 Prompt 编辑到后端异步任务队列，再到双引擎出图落盘——完整拆解管理端 AI 生图模块的设计思路与实现细节。

背景：为什么管理端需要 AI 生图能力
整体架构：双引擎 + 异步任务
第一阶段：Prompt 管理与大模型文案生成
第二阶段：图片生成核心流程
双引擎详解：ComfyUI vs DashScope
异步任务机制与状态机
一键批量生图：栏目级素材自动化
前端管理界面设计
经验总结与踩坑记录

1 背景：为什么管理端需要 AI 生图能力

AI 海报素材站是一个面向用户的移动端资讯与工具平台，核心内容之一是海报素材库——各类资源的宣传海报、推荐图片需要持续更新，以保持用户新鲜感。传统做法是由设计师手工出图，周期长、成本高，且难以快速响应运营活动。

引入 AI 生图后，运营人员只需在管理端维护一批结构化 Prompt 模板，点击"生成"按钮，后台即可调用图像模型自动产出海报，全程无需设计师介入。更进一步，系统支持一键为整个栏目批量重刷封面，数十张图片几分钟内全部到位。

痛点	描述
出图效率低	设计师手工制作一张海报需 1~2 小时，远不能满足运营频次
素材库难维护	数百条资源素材，封面更新后需逐条替换，工作量巨大
解法：AI + 异步任务	Prompt 模板 + 异步队列，运营直接操作，出图全自动

2 整体架构：双引擎 + 异步任务

整个 AI 生图模块由三层组成：前端管理界面（Vue 3 + Element Plus）、后端 Spring Boot 服务（异步任务 + Service 层 + Client 层），以及两个可切换的图像引擎（本地 ComfyUI 或阿里云 DashScope）。

管理员（前端）
    │
    │ ① 选 Prompt / 提交生成
    ▼
AdminAiController  /api/admin/ai/**
    │
    ▼
AiMaterialService  业务编排层
    ├──②a 单条/批量──► AiTaskExecutor  @Async 异步线程池
    └──②b 同步出图───► AiImageClient   统一出图入口
                              │
                  ┌───────────┴────────────┐
                  │ provider=comfyui       │ provider=dashscope
                  ▼                        ▼
        ComfyUiImageClient        DashScopeImageClient
        HTTP Polling                REST API
        ComfyUI :8188              DashScope aliyuncs.com
                  │                        │
                  └───────────┬────────────┘
                              ▼
                    FileUploadUtil  UUID 落盘 uploads/ai/
                              │
                    ③ 回写 URL
                              ▼
                    MySQL: ai_generate_task / material

    ④ 前端轮询 batchTaskStatus

核心设计决策是将出图引擎与业务逻辑完全解耦——AiImageClient 作为唯一出图入口，通过 ai.image-provider 配置项在运行时动态切换 ComfyUI 或 DashScope，上层业务代码完全无感知。

3 第一阶段：Prompt 管理与大模型文案生成

3.1 Prompt 模板数据结构

每条 Prompt 模板（AiPromptTemplate）包含标题、分类、资源 ID、排序权重、提示词正文和启用状态。管理员可在前端 CRUD 维护这批模板，不同资源类型、不同类型（号码推荐 / 活动海报等）各自有对应的模板。

3.2 大模型辅助生成 Prompt 文案

很多运营人员对"文生图 Prompt 怎么写"并不熟悉。系统内置了一个大模型辅助生成 Prompt 的接口（POST /api/admin/ai/generatePrompt），运营只需填写素材标题、分类和补充要求，系统自动调用阿里云 DashScope Chat API 生成专业提示词。

// AiMaterialServiceImpl.java — generatePromptText()
public String generatePromptText(String title, String category, String hint) {
    StringBuilder sb = new StringBuilder();
    sb.append("你是资源平台宣传海报提示词专家。请直接输出一段可用于文生图模型的中文提示词，不要解释、不要编号。");
    sb.append("要求：竖版海报、红金喜庆、商业宣传风格，底部预留合规区「推荐仅供参考，请理性选购」。");
    if (StringUtils.hasText(title))    sb.append("素材标题：").append(title).append("。");
    if (StringUtils.hasText(category)) sb.append("分类：").append(category).append("。");
    if (StringUtils.hasText(hint))     sb.append("补充要求：").append(hint).append("。");
    sb.append("请生成完整提示词。");
    return dashScopeChatClient.generatePrompt(sb.toString());
}

3.3 DashScope Chat 客户端：流式 SSE 解析

Chat 模型返回的是 Server-Sent Events（SSE） 流式响应，需要逐行读取并聚合 delta.content。实现上用原生 HttpURLConnection 打开长连接，开启 "enable_thinking": true 让模型先思考再输出。

// DashScopeChatClient.java — 流式读取并聚合 content
private String readSseContent(InputStream is) throws Exception {
    StringBuilder content = new StringBuilder();
    try (BufferedReader reader = new BufferedReader(
            new InputStreamReader(is, StandardCharsets.UTF_8))) {
        String line;
        while ((line = reader.readLine()) != null) {
            line = line.trim();
            if (line.isEmpty() || !line.startsWith("data:")) continue;
            String data = line.substring(5).trim();
            if ("[DONE]".equals(data)) break;
            JsonNode delta = objectMapper.readTree(data)
                .path("choices").path(0).path("delta");
            if (delta.has("content"))
                content.append(delta.get("content").asText(""));
        }
    }
    return content.toString();
}

注意： 请求头需设置 Accept: text/event-stream，并将超时设置到 180 秒，否则大模型 thinking 阶段可能导致连接超时。

4 第二阶段：图片生成核心流程

文案 Prompt 准备好后，正式进入出图环节。根据业务场景，系统支持三种触发方式：

步骤 1 — 单条异步生成（基于 Prompt 模板）

管理员在「提示词管理」页勾选模板，点击批量生成，后台为每条模板创建一个 AiGenerateTask（状态 pending），立即丢入异步线程池。

步骤 2 — 同步出图（素材行内生成）

管理员在素材管理页直接输入 Prompt，点击「立即出图」，调用 generateImageSync，同步等待图片返回后刷新预览。适合快速验证 Prompt 效果。

步骤 3 — 一键批量生图（栏目级）

按资源类型批量为当前栏目下所有图片素材重新出图，所有任务一次性提交异步队列，前端轮询进度直至全部完成。

4.1 任务创建与状态流转

异步生成路径中，任务对象（AiGenerateTask）的状态机遵循严格的单向流转：pending → running → success / fail。失败的任务支持手动重试，会将状态重置为 pending 后重新投入队列。

[创建] ──► pending ──► running ──► success ──► [结束]
                                └──► fail ──► pending（重试）

5 双引擎详解：ComfyUI vs DashScope

系统通过 AiImageClient 提供统一的 generateImage(promptText) 方法，内部根据配置选择实际引擎。两套引擎在接入方式上差异显著：

维度	ComfyUI（本地）	DashScope（云端）
部署方式	本地/私有服务器，127.0.0.1:8188	阿里云 SaaS API
通信模式	提交 → HTTP 轮询 history API	一次请求，等待响应
工作流	JSON 工作流文件（z-image-turbo）	多模态消息体
图片返回	PNG 文件名，需再下载字节流	URL 或 Base64
随机种子	每次随机注入 seed 节点	API 自动随机
适用场景	开发/本地测试，自有 GPU	生产环境，稳定 SLA
超时配置	默认 300 秒（可配置）	readTimeout 180 秒

5.1 ComfyUI 引擎：工作流注入 + 轮询

ComfyUI 使用节点工作流（z-image-turbo-workflow.json）驱动出图。客户端在启动时通过 @PostConstruct 将工作流 JSON 加载到内存，出图时做两件事：① 把 Prompt 文本注入 57:27 节点；② 随机注入 seed 到 57:3 节点，保证每次出图不重复。

// ComfyUiImageClient.java — 工作流节点注入
ObjectNode workflow = workflowTemplate.deepCopy();
((ObjectNode) workflow.path("57:27").path("inputs")).put("text", promptText);
long seed = ThreadLocalRandom.current().nextLong(1, Long.MAX_VALUE);
((ObjectNode) workflow.path("57:3").path("inputs")).put("seed", seed);

// 提交后轮询 history/{promptId}，800ms 一次
while (System.currentTimeMillis() < deadline) {
    JsonNode history = getJson("/history/" + promptId);
    if (history.has(promptId)) {
        JsonNode images = history.path(promptId)
            .path("outputs").path("9").path("images");
        return downloadAndSave(images.get(0));
    }
    Thread.sleep(800L);
}

5.2 DashScope 引擎：多结构兼容解析

DashScope 图像 API 的响应结构在不同模型版本下字段路径可能不同（output.choices[].message.content[].image、output.results[].url、data[].url 等均有出现）。为了应对版本差异，extractImage 方法实现了多路径优先级解析，最终兜底用递归深度搜索 image/url 字段。

拿到图片数据后，无论是 HTTP URL 还是 Base64，统一调用 saveImage() 落盘到 uploads/ai/{UUID}.png，返回相对访问路径。

配置切换： 在 application.yml 中设置 ai.image-provider: comfyui 或 ai.image-provider: dashscope 即可切换，无需改代码。

6 异步任务机制与状态机

6.1 Spring @Async 线程池

AiTaskExecutor 标注了 @Component，其 execute() 和 executeMaterialBatch() 方法均标注 @Async，依赖 AsyncConfig 中配置的专用线程池执行，不阻塞 HTTP 请求线程。

Controller 层在接收到生成请求后，立即返回 taskId 给前端，前端再通过轮询 /api/admin/ai/batchTaskStatus 拿到任务的成功/失败统计。这样避免了出图时间过长（30～300 秒）导致 HTTP 请求超时。

// AiMaterialServiceImpl.java — 提交任务后立即返回
AiGenerateTask task = new AiGenerateTask();
task.setPromptId(promptId);
task.setAdminId(adminId);
task.setStatus("pending");
taskMapper.insert(task);          // ① 先入库
aiTaskExecutor.execute(task.getId()); // ② 异步执行，立即返回
return task.getId();              // ③ taskId 同步返回给调用方

6.2 异步执行器内部流程

AiTaskExecutor.execute() 是真正干活的地方，步骤如下：

标记 running — 任务开始时立即将状态更新为 running，前端可感知任务已被处理。
读取 Prompt 模板 — 从 ai_prompt_template 表查出 promptText，若不存在则直接 fail。
调用出图引擎 — 通过 AiImageClient.generateImage(promptText) 出图，获取本地文件相对路径。
写入 Material 并更新任务 — 新建一条 material（类型 poster，状态上架），回写 result_url 和 material_id，状态设为 success。
异常处理 — 任何异常（含 API 限流、超时）均 catch，将错误信息截取前 480 字符写入 error_msg，状态设为 fail。

6.3 前端轮询进度

任务管理页（task.vue）在 onMounted 时启动一个 5 秒定时器自动刷新任务列表，并在 onUnmounted 时清除，避免内存泄漏。批量任务提交后，前端拿到 taskIds 数组，通过 batchTaskStatus 接口获得 pending/running/success/fail 四个计数，当 pending + running === 0 时判定全部完成。

7 一键批量生图：栏目级素材自动化

「一键生图」是整个 AI 生图模块最有业务价值的功能。其逻辑入口是 POST /api/admin/ai/batchGenerateMaterials，参数 resourceId（资源 ID）、type（素材类型，仅 poster）、onlyEmpty（是否仅为无封面的素材生成）。

7.1 Prompt 自动构建

批量模式下没有人工 Prompt，系统在 AiTaskExecutor.buildMaterialPosterPrompt() 中根据素材的标题、分类和资源名称自动拼接一段标准化 Prompt：

// AiTaskExecutor.java — 批量模式自动构建 Prompt
static String buildMaterialPosterPrompt(Material material, String resourceName) {
    String title    = hasText(material.getTitle())    ? material.getTitle()    : "资源宣传海报";
    String category = hasText(material.getCategory()) ? material.getCategory() : "号码推荐";
    String lot      = hasText(resourceName)            ? resourceName            : "资源";
    return "竖版 9:16 手机海报，" + lot + "宣传海报，主题标题「" + title
        + "」，分类「" + category
        + "」，热情红主色搭配琥珀金点缀，喜庆现代电商活动海报质感，明亮高饱和，"
        + "干净排版，扁平化商业 UI，高清，8k。底部合规区文字：推荐仅供参考，请理性选购。";
}

这段 Prompt 具有很强的工程实践性：竖版比例、颜色风格（红+琥珀金）、质感描述（电商海报）、分辨率和合规文字全部内置，保证批量产出的图片风格统一、满足监管要求。

7.2 批量任务提交与 onlyEmpty 优化

batchGenerateMaterials 先查出当前资源类型下最多 500 条素材，若 onlyEmpty=true 则跳过已有封面的素材，仅为空封面素材创建任务，避免重复消耗 AI 算力配额。任务列表批量插入后，调用 executeMaterialBatch(taskIds) 统一异步执行。

8 前端管理界面设计

8.1 Prompt 管理页（prompt.vue）

Prompt 管理页的核心交互非常简洁：表格展示所有模板，支持多选后点击「批量异步生成」一键提交，勾选数量实时显示在按钮上。编辑对话框支持 6 行 Textarea 直接修改提示词正文。

功能模块	说明
提示词 CRUD	新增、编辑、删除，支持标题 / 分类 / 资源 ID / 状态管理
批量异步生成	勾选多条模板一键提交，后台异步处理，不卡前端页面
跳转任务监控	提交后可一键跳转到「生成任务」页查看实时进度

8.2 生成任务页（task.vue）

任务监控页展示所有任务的状态、结果缩略图、错误信息，并支持对失败任务单条重试。页面在 mounted 时自动启动 5 秒轮询，让运营实时看到出图进度，无需手动刷新。

// task.vue — 自动轮询 5 秒一次
onMounted(() => {
  loadData()
  timer = setInterval(loadData, 5000)  // 5 秒刷新
})
onUnmounted(() => clearInterval(timer))  // 组件销毁时清除

9 经验总结与踩坑记录

问题	原因	解决方案	严重度
ComfyUI 出图超时	默认超时 60s 不够	将 `comfyui.timeout-seconds` 调到 300s	高
DashScope 响应结构变化	不同版本 API 字段路径不同	多路径优先级解析 + 递归兜底	中
SSE 流式请求超时	readTimeout 默认太短	设置 `readTimeout=180000ms` + Accept: text/event-stream	高
批量任务重复生成	未过滤已有封面的素材	新增 `onlyEmpty` 参数过滤	中
error_msg 存储溢出	异常信息过长超出字段长度	截取前 480 字符	低
前端轮询内存泄漏	timer 未在组件销毁时清除	在 `onUnmounted` 中 `clearInterval`	中
随机种子固定导致重复图	工作流默认 seed 不变	每次出图随机注入新 seed	中

9.1 整体设计感悟

整个 AI 生图模块最核心的设计是关注点分离：Controller 负责鉴权和参数解析，Service 负责业务编排（任务创建、进度汇总），TaskExecutor 负责异步执行，Client 层负责与外部 AI 服务通信，每一层职责清晰，便于独立测试和替换。

双引擎设计让系统既能在开发阶段使用本地 ComfyUI 快速迭代 Prompt 效果，又能在生产环境无缝切换到云端 DashScope，无需修改任何业务代码，只需改一行配置项。这种策略模式的应用，在实际项目中非常实用。

AI聚合问答工具：多 AI 并排聚合客户端的技术实践

Fri, 16 Oct 2026 16:32:14 +0800

1. 摘要

「AI聚合问答工具」是一款桌面客户端，核心目标是把多个主流大模型网页并排装进同一个窗口：用户在底部输入框写一次问题，点一下即可同步发送给所有面板，并排对比各家回答。它不调用任何大模型 API，而是复用各站点的网页登录态，以 webview 嵌入真实对话框；强调本地优先、无遥测、数据仅存本机。本文从问题定义、技术选型、系统架构、核心模块、工程化交付与关键问题六个维度，复盘这一项目的实践过程。

2. 问题定义与项目目标

大模型能力高度分化：有的擅长推理，有的擅长长文，有的联网检索更强。用户日常需要在多个站点之间反复复制粘贴、来回切换，既低效又难以横向对比。本项目据此设定四项目标：

一窗并排，一问多答：同一窗口内并排打开 2–12 个 AI 面板。
一次输入，全部发送：一个输入框，一键广播给所有面板。
复用网页、本地优先：复用各 AI 网页版登录态，不索取 API Key；登录态与配置存于本机。
隐私友好：无统计、无追踪、无云端上报。

3. 技术选型

维度	选择	理由
壳层框架	Electron 44	原生支持 `webview` 嵌入任意站点、分区持久化（`partition`）、`nativeTheme` 系统级色彩联动，最契合"聚合网页"的场景。
打包工具	electron-builder 26	统一产出 Windows（NSIS/便携）与 macOS（dmg），支持代码签名与 CI。
图标生成	sharp 0.35	用一条命令把矢量 `icon.svg` 栅格化为 1024×1024 `icon.png`，纳入构建流程。
聚合方式	网页注入，非 API 聚合	调用 API 需各平台 Key、计费且接口频繁变动；直接嵌入官方网页可零成本、零授权地复用其完整能力。

关键判断：不重写对话 UI，而是"借用"各站点的对话 UI。这把工作量从"适配每个模型的 API"转移为"定位每个站点的输入框与发送按钮"。

4. 系统架构

4.1 进程与目录结构

src/
  main/        主进程：窗口、会话、主题联动、版本检测、本地存储
    main.js
    store.js
  preload/     安全桥接（contextIsolation）
    preload.js
  renderer/    界面、布局、站点适配、注入、提示词库
    index.html  app.js  styles.css
    providers.js  layouts.js  inject.js  prompts.js
scripts/       图标生成、应用截图、自检脚本
build/         图标与 README 截图（icon.png / screenshot.png）
assets/        矢量图标（icon.svg）
`&lt;/pre&gt;

### 4.2 进程模型与 IPC

采用 Electron 推荐的**主进程 / 预加载 / 渲染进程**三层隔离：
`</pre>

预加载（preload.js） 通过 contextBridge 只暴露最小 API 集合，绝不开启 nodeIntegration：

`contextBridge.exposeInMainWorld('api', {
  storeGet:  (k, f) => ipcRenderer.invoke('store:get', k, f),
  storeSet:  (k, v) => ipcRenderer.invoke('store:set', k, v),
  openExternal: (url) => ipcRenderer.invoke('open-external', url),
  setNativeTheme: (mode) => ipcRenderer.invoke('set-native-theme', mode),
  onUpdateAvailable: (cb) => ipcRenderer.on('update-available', (_e, i) => cb(i))
});
`

主进程（main.js） 用 ipcMain.handle 实现这些通道；其中 open-external 强制校验 ^https?://，避免任意协议跳转。

* * *
5. 核心模块实现

5.1 多面板并排与 22 种布局
每个面板是一个 webview，用 partition=&quot;persist:&lt;providerId&gt;&quot; 实现登录态隔离与重启存活：
```
`function createWebview(provider) {
  var wv = document.createElement('webview');
  wv.setAttribute('partition', 'persist:' + provider.id);
  wv.setAttribute('src', provider.url);
  wv.className = 'pane-web';
  return wv;
}
`
```
布局由 layouts.js 以 0–1 归一化坐标描述，共 22 种：2 屏（左右/上下）→ 3 屏（三栏/主从）→ … → 12 屏（3×4 / 4×3），涵盖网格、左右/上下、主从（一大带多小）等形态，渲染时映射为百分比定位。

切换布局不刷新对话是整个交互的关键。实现要点：
paneEls 缓存已创建的窗格实例；
relayout() 增删窗格后，用 syncPaneProvider() 判断——仅当某窗格的 provider 变化时才重建 webview，否则原网页原样保留；
切布局时统一复位 is-fullscreen / is-collapsed，避免与新的几何位置冲突。
5.2 一次输入、全发送的站点适配
providers.js 为每个站点维护 inputs（输入框候选选择器）与 send（发送按钮候选选择器）。真正执行在 inject.js——一段注入到目标页面隔离世界的脚本，全程只读写该标签页 DOM、不触网：

定位输入框：先按站点专属选择器匹配，未命中则回退通用发现——在 textarea / contenteditable / input[type=text] 中按可见性、位置（偏下方）、宽度、placeholder 关键词打分取最优。

框架感知填充：

`*   `textarea/input`：用原型 `value` setter + 派发 `input/change` 事件；
`

*   `contenteditable`：清空后用 `InputEvent(&amp;#39;beforeinput&amp;#39;, {inputType:&amp;#39;insertText&amp;#39;})` 兼容 **Slate**，失败回退 `execCommand(&amp;#39;insertText&amp;#39;)`；

个别站点（如智谱清言）的提交绑定在 mousedown，脚本据此改走 mousedown。

定位并触发发送：优先 aria-label/title 含"发送/Send"的按钮，兜底按按钮文本匹配；触发时派发 Pointer/Mouse/Click 序列，或回退为在输入框 pressEnter。

渲染进程对每个面板并行 executeJavaScript，用 Promise 聚合结果，逐窗标记 ok / fail 并 toast 汇总。
5.3 单窗全屏 / 收缩（不刷新）
全屏与收缩均为纯 CSS class 切换，不重建、不刷新 webview：
```
`pane.classList.toggle('is-fullscreen');  // 置顶覆盖，同一时刻仅一个
pane.classList.toggle('is-collapsed');   // 隐藏网页区，webview 仍驻留 DOM
`
```
这保证了"专注单个 AI"时既不丢失其他对话，也不产生额外的页面加载。
5.4 白 / 夜模式联动
渲染进程 applyTheme() 经 api.setNativeTheme() 通知主进程，后者设置 nativeTheme.themeSource = mode（light/dark/system）。由于 webview 内的 AI 站点普遍响应系统 prefers-color-scheme，应用切主题即联动所有内嵌站点同步深/浅色。

同时，主进程在 session-created 时清洗 User-Agent，剥离 Electron/* 与应用名令牌，让各站点按正常桌面浏览器渲染、降低被限流风险：
```
`.replace(/\s*Electron\/[0-9.]+/i, '').replace(/\s*AI聚合问答工具\/[0-9.]+/i, '')
```

5.5 提示词库

`prompts.js` 提供本地增删改查、分类与搜索；支持单 `{变量}` 与双 `{{变量}}` 占位符，使用时自动弹出变量表单（`buildVarFields` / `confirmVars`），把填好的内容回填到输入框。该模块与&quot;发送注入&quot;解耦，可独立维护。

### 5.6 版本检测与自动升级

主进程 `app ready` 后请求 `https://mutiai.0315e.com/curr_version`，用 `compareVersion()` 做语义化比较，发现远端更新即 `webContents.send(&amp;#39;update-available&amp;#39;, …)`，渲染进程弹窗并提供&quot;去升级&quot;按钮跳转官网；离线或接口不可达时静默忽略。

### 5.7 本地优先与隐私

每个 AI 独立 persist: 分区，登录态互不串扰；
应用配置（布局、provider、主题）以 store.json 落盘于 userData，由 store.js 用 fs 读写；
全程无遥测接口；requestSingleInstanceLock 保证单实例运行。
```
* * *
```
6. 工程化与交付实践

6.1 国内镜像源加速

.npmrc 将 npm、Electron 二进制、electron-builder 二进制、sharp 及其 libvips 全部指向 npmmirror，显著缩短依赖与二进制下载时间：
```
`registry=https://registry.npmmirror.com
```

electron_mirror=https://registry.npmmirror.com/-/binary/electron/

electron_builder_binaries_mirror=https://registry.npmmirror.com/-/binary/electron-builder-binaries/

sharp_binary_host=https://registry.npmmirror.com/-/binary/sharp

sharp_libvips_binary_host=https://registry.npmmirror.com/-/binary/sharp-libvips

6.2 图标与截图自动化

图标：scripts/make-icon.js 用 sharp 把 assets/icon.svg 栅格化为 build/icon.png（1024×1024），纳入 npm run icon 流程。
截图：scripts/shot.js 启动独立 Electron 实例加载真实 index.html，注册最小 IPC 桩（store:get/set、open-external、set-native-theme）后 capturePage() 输出 build/screenshot.png。实践中的关键坑：必须 disableHardwareAcceleration() 并加 --disable-gpu，否则 GPU 进程崩溃；且必须提供最小 IPC 桩，否则渲染进程启动中断、窗格不渲染。

6.3 打包与分发

electron-builder 产出：

Windows：AI聚合问答工具-&lt;版本&gt;-win-x64.exe（NSIS 安装版）+ -portable.exe（免安装便携版）；
macOS：*.dmg（x64 / arm64 通用）。

跨平台限制：Electron 不支持在单一系统交叉编译另一系统的安装包，macOS 包必须在 Mac 上执行 npm run dist:mac 或通过 CI 构建。仓库已提供 GitHub Actions 工作流，推送 v* tag 自动构建双平台。

6.4 版本管理与协作

代码托管于 Gitee（tyerp/ai-aggregated-qa-tool），HTTPS + 账号密码推送；.gitignore 排除 node_modules/、release/ 等体积较大的产物目录，仅纳入源码、配置与 build/ 资源。

7. 关键问题与解决方案

问题	现象	解决
运行态退化	环境 `ELECTRON_RUN_AS_NODE=1` 使 Electron 退化成 Node，`app is undefined`	`start` 脚本先 `delete process.env.ELECTRON_RUN_AS_NODE` 再拉起
GPU/沙箱受限	虚拟桌面/服务器上 GPU 进程 FATAL，整体闪退	`disableHardwareAcceleration()` + `--no-sandbox --disable-gpu --disable-software-rasterizer`
后台进程被回收	用 `&` 后台启动随 shell 结束被回收，误判启动失败	改用守护方式常驻拉起
跨平台打包	Windows 无法产出 macOS 包	明确在 Mac 或 CI 构建，文档标注限制
截图窗格空白	渲染进程缺 IPC 桩，中断启动	`shot.js` 补齐最小 IPC 桩后三栏正常渲染

8. 安全与合规

进程隔离：contextIsolation: true、nodeIntegration: false，预加载仅暴露必要 API；
外部跳转白名单：open-external 仅放行 http(s)；
最小权限：不索取任何 API Key、不读取用户隐私文件，所有数据存于本机 userData。

9. 总结与展望

「AI聚合问答工具」用"轻壳层 + 网页注入"的组合，以极低的维护成本实现了多 AI 并排对比这一高频诉求。其可复用经验有三：

复用网页优于调用 API——在能力快速迭代的大模型领域，嵌入官方网页比适配 API 更稳更省；
缓存与复用是流畅体验的底座——窗格实例与 webview 的复用，让"切布局/切主题不刷新对话"成为现实；
工程化前置——镜像源、图标/截图脚本、CI 打包、.gitignore 设计，决定了项目能否稳定交付。

后续可演进方向：补齐 macOS 构建与签名、提示词跨设备同步、可拖拽自定义布局、更多站点适配，以及把"变量表单"能力下沉到发送流程。