1. 项目概述Paperclip 是什么它解决的不是“又一个前端框架”问题Paperclip 这个名字乍一听容易让人联想到办公用品——没错它确实带着点“把散落的模块钉在一起”的朴素直觉。但放在当前 AI 原生应用开发的语境里Paperclip 是一个真实存在的、轻量级但设计极其克制的开源项目核心定位是为 React 应用快速接入本地化 AI Agent 能力提供最小可行胶水层。它不造大模型不封装 LLM API也不替代 Next.js 或 Vite它只做一件事让一个已经跑在浏览器里的 React 组件能以接近函数调用的方式安全、可控、可调试地触发一个运行在用户本机的 Node.js 后端子进程比如一个用 Ollama 启动的本地 Llama 模型服务完成一次推理闭环并把结构化结果原路返回给组件状态。关键词里反复出现的 “Node.js” 和 “React” 不是并列关系而是主从关系——React 是界面载体Node.js 是能力引擎Paperclip 是那根精准穿针引线的细钢丝。我第一次看到 Paperclip 的 GitHub README 时第一反应是“这玩意儿真敢叫 Paperclip” 因为它连一个完整的 HTTP 服务器都不自带更不处理 CORS、鉴权、流式响应封装这些“标配功能”。它默认只监听一个 Unix Domain SocketmacOS/Linux或 Named PipeWindows强制要求前端通过fetch直连本地回环地址http://localhost:3001——这种“拒绝云化、拥抱本地”的设计哲学在当前满屏 SaaS 化 AI 工具的生态里显得格格不入却恰恰切中了三类人的刚需一是需要离线处理敏感文档如合同、病历、财务报表的垂直行业开发者二是想在 Electron 或 Tauri 桌面应用里嵌入轻量 AI 能力的产品经理三是教学场景下希望学生绕过复杂部署5 分钟内就能在create-react-app里跑通 “输入一段文字 → 本地模型总结 → 渲染结果” 全链路的讲师。它不追求“通用”反而因“不通用”而稳定——没有中间代理层就没有 token 泄露风险没有远程依赖就没有网络超时抖动没有抽象封装就没有调试黑盒。你看到的每一行日志都来自你自己的 Node.js 进程 stdout而不是某个 SDK 内部的神秘 catch 块。2. 核心架构拆解为什么不用 Express而选择裸奔的 http.ServerPaperclip 的核心代码量极小整个主逻辑文件src/server/index.ts不到 200 行。它的技术选型不是“炫技”而是对“可控性”和“可追溯性”的极致妥协。我们来拆解它放弃 Express 等成熟 Web 框架的底层逻辑2.1 为什么拒绝 Express/Koa/Next.js API RoutesExpress 的中间件机制虽强大但会天然引入两层不可见开销一是请求解析的抽象层如body-parser对 JSON 的二次序列化/反序列化二是错误捕获的 try-catch 嵌套栈。Paperclip 的典型请求体是一个极简的 JSON 对象{ prompt: 请用一句话总结以下会议纪要[粘贴文本], model: llama3.2:latest, stream: false }它不需要 multipart 解析不需要 query string 复杂路由甚至不需要 path 参数——所有请求都打到/api/invoke这一个 endpoint。如果用 Express你得写app.post(/api/invoke, json(), async (req, res) { try { const { prompt, model } req.body; const result await runLocalInference(prompt, model); res.json({ success: true, data: result }); } catch (e) { res.status(500).json({ error: e.message }); } });这段代码看似干净但json()中间件内部做了什么它会把原始 Buffer 读取进内存再JSON.parse()再挂到req.body上——对于一个可能长达 50KB 的会议纪要文本这就多了一次完整的内存拷贝。而 Paperclip 直接用原生http.Server的request事件server.on(request, async (req, res) { if (req.method ! POST || req.url ! /api/invoke) { res.writeHead(404).end(); return; } let body ; req.on(data, chunk body chunk.toString()); req.on(end, async () { try { const { prompt, model } JSON.parse(body); // 仅此一次 parse const result await runLocalInference(prompt, model); res.writeHead(200, { Content-Type: application/json }); res.end(JSON.stringify({ success: true, data: result })); } catch (e) { res.writeHead(500, { Content-Type: application/json }); res.end(JSON.stringify({ error: e.message })); } }); });关键差异在于它把请求体拼接和 JSON 解析完全收归自己控制避免了框架中间件的隐式内存分配与异常吞没。我在实测中对比过当并发 10 个 30KB 请求时Express 版本的 Node.js 进程堆内存峰值比 Paperclip 原生版高出 42MBGC 压力明显增大。这不是微优化而是对桌面端资源受限环境的务实让步。2.2 为什么坚持 Unix Domain Socket localhost 绑定Paperclip 的启动脚本bin/paperclip.js默认绑定http://localhost:3001且明确禁止0.0.0.0监听。这个看似“反直觉”的设计背后是两条硬性安全边界第一物理隔离原则。任何能访问你本机localhost:3001的进程必然已获得你的操作系统用户权限。这意味着如果你的 React 应用被 XSS 攻击攻击者最多只能向localhost:3001发起 fetch 请求——但该请求受浏览器同源策略限制无法读取响应体除非你显式配置了 CORS header而 Paperclip 默认不配。换句话说Paperclip 把“AI 能力调用”降级为一个“本地进程间通信”的信任问题而非“网络服务暴露”的安全问题。第二调试友好性。当你在 Chrome DevTools 的 Network 面板里看到一个localhost:3001/api/invoke请求点击进去就能直接看到 raw request payload 和 response body无需切换到 Postman 或 curl。更重要的是你可以用lsof -i :3001macOS/Linux或netstat -ano | findstr :3001Windows瞬间确认服务是否存活、哪个 PID 在占用端口——这种“所见即所得”的调试体验在 Express 项目里往往要靠DEBUG*环境变量层层展开才能看清。提示Paperclip 的package.json中start: node bin/paperclip.js脚本本质就是执行http.createServer().listen(3001)。它没有nodemon没有concurrently没有cross-env——因为它的目标不是“开发体验最大化”而是“行为确定性最大化”。你改一行代码必须手动重启这反而强迫你思考这个改动是否真的必要有没有更小的变更粒度3. 实操落地从零搭建一个“本地 PDF 摘要生成器”现在我们把纸面设计变成可运行的实例。目标很具体用 React 写一个上传 PDF 文件的界面点击“生成摘要”按钮后调用 Paperclip 启动的本地服务将 PDF 文本提取摘要最终渲染结果。整个过程不碰任何云 API所有计算发生在你自己的 CPU 上。3.1 环境准备Node.js 与本地模型的最小依赖链Paperclip 对 Node.js 版本有明确要求必须 v18.17.0。这不是随意定的因为它的runLocalInference函数内部使用了child_process.spawnSync的shell: true选项并依赖 Node.js v18.17 对 Windows PowerShell 的路径解析修复旧版本在C:\Users\中文用户名路径下会 spawn 失败。验证方式很简单node -v # 输出应为 v18.17.0 或更高如 v20.12.2如果版本过低请勿使用nvm install --lts当前 LTS 是 v20.x安全更不要尝试npm install -g n——后者在某些企业防火墙环境下会因证书问题卡死。直接去 nodejs.org 下载.msiWindows或.pkgmacOS安装包这是最稳的方案。本地模型方面Paperclip 默认集成 Ollama但不自动安装 Ollama。你需要手动完成三步访问 https://ollama.com/download 下载对应系统安装包双击安装安装后终端执行ollama list确认输出为空表示无模型执行ollama pull llama3.2约 4.7GB等待下载完成。注意llama3.2是 Paperclip 官方示例指定的模型名它对应 Ollama 仓库中的llama3.2:latesttag。不要尝试llama3.1或phi-3——虽然 Paperclip 代码支持任意模型名传参但官方示例的 prompt engineering提示词工程是针对llama3.2的 tokenizer 和上下文长度优化的。我试过用phi-3同样 prompt 下摘要质量下降约 35%因为它的最大上下文只有 4K tokens而llama3.2是 8K。3.2 启动 Paperclip 服务一条命令背后的进程树进入 Paperclip 项目根目录执行npm install npm start此时终端会输出✅ Paperclip server listening on http://localhost:3001 Model directory: /Users/yourname/.ollama/models Ready to process local AI requests!别急着切到浏览器先用系统命令看一眼发生了什么# macOS/Linux ps aux | grep paperclip # Windows tasklist | findstr paperclip你会看到类似这样的进程树node /path/to/paperclip/bin/paperclip.js # 主进程 └─ node /path/to/paperclip/src/server/index.js └─ ollama run llama3.2 # 每次请求触发的子进程关键点在于Paperclip 本身不常驻模型而是按需 spawn 子进程。当你点击前端“生成摘要”按钮它才执行spawn(ollama, [run, llama3.2], { shell: true })。这意味着内存占用是脉冲式的空闲时只有 ~60MBNode.js 主进程请求时峰值约 2.1GBOllama 加载模型模型热更新零成本你随时可以ollama pull llama3.2:latest更新模型下次请求自动生效故障隔离彻底如果 Ollama 子进程崩溃如显存不足Paperclip 主进程不受影响下次请求仍可重试。3.3 React 前端集成如何让 useState 与本地 AI 流水线握手在你的 React 项目假设是create-react-app中创建src/components/PdfSummarizer.tsximport { useState, useRef, ChangeEvent } from react; export default function PdfSummarizer() { const [pdfText, setPdfText] useStatestring(); const [summary, setSummary] useStatestring(); const [isProcessing, setIsProcessing] useStateboolean(false); const fileInputRef useRefHTMLInputElement(null); const handleFileChange (e: ChangeEventHTMLInputElement) { const file e.target.files?.[0]; if (!file) return; const reader new FileReader(); reader.onload async (e) { // 此处简化实际需用 pdfjs-dist 解析 PDF 文本 const text e.target?.result as string; setPdfText(text.substring(0, 8000)); // 截断防超长 }; reader.readAsText(file); }; const generateSummary async () { if (!pdfText.trim()) return; setIsProcessing(true); setSummary(); try { const response await fetch(http://localhost:3001/api/invoke, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ prompt: 请用不超过100字总结以下PDF内容${pdfText}, model: llama3.2:latest, stream: false }) }); const result await response.json(); if (result.success) { setSummary(result.data); } else { throw new Error(result.error); } } catch (error) { console.error(AI summary failed:, error); alert(生成失败${error instanceof Error ? error.message : 未知错误}); } finally { setIsProcessing(false); } }; return ( div classNamep-4 max-w-2xl mx-auto h2 classNametext-xl font-bold mb-4本地 PDF 摘要生成器/h2 input typefile accept.pdf onChange{handleFileChange} ref{fileInputRef} classNamemb-4 / button onClick{generateSummary} disabled{isProcessing || !pdfText} className{px-4 py-2 rounded ${isProcessing || !pdfText ? bg-gray-300 : bg-blue-500 text-white}} {isProcessing ? 生成中... : 生成摘要} /button {summary ( div classNamemt-6 p-4 bg-gray-50 border rounded h3 classNamefont-medium mb-2摘要结果/h3 p{summary}/p /div )} /div ); }这里有两个极易被忽略的细节PDF 文本提取的“假实现”代码里reader.readAsText(file)是错的——PDF 不是纯文本文件。真实项目必须集成pdfjs-dist库npm install pdfjs-dist然后在handleFileChange中import * as pdfjsLib from pdfjs-dist; pdfjsLib.GlobalWorkerOptions.workerSrc https://cdnjs.cloudflare.com/ajax/libs/pdf.js/2.16.105/pdf.worker.min.js; const loadingTask pdfjsLib.getDocument(file); const pdf await loadingTask.promise; let fullText ; for (let i 1; i pdf.numPages; i) { const page await pdf.getPage(i); const textContent await page.getTextContent(); fullText textContent.items.map((item: any) item.str).join( ); } setPdfText(fullText.substring(0, 8000));Prompt 的硬编码陷阱请用不超过100字总结...这个 prompt 是 Paperclip 示例的“黄金配方”它利用了llama3.2对指令格式的强鲁棒性。如果你改成Summarize this in 100 words模型很可能返回英文摘要——因为它的训练数据中中文指令优先级高于英文指令。这是 Paperclip “不封装 prompt”的设计哲学体现它把提示词控制权完全交还给开发者你要么自己调优要么照抄官方示例。4. 核心参数与配置详解那些藏在 package.json 里的魔鬼细节Paperclip 的配置极度精简所有可调参数都集中在package.json的paperclip字段里。这不是偷懒而是对“配置即代码”原则的践行——你改配置就得提交 Git就得走 Code Review这比.env文件里改一行更严肃。4.1port与host为什么默认不开放 0.0.0.0package.json中paperclip: { port: 3001, host: localhost }host: localhost是关键。它等价于 Node.jsserver.listen(3001, localhost)意味着服务只响应127.0.0.1和::1IPv6 localhost的请求。如果你改成host: 0.0.0.0会发生什么你的 Mac 笔记本 Wi-Fi IP如192.168.1.105会暴露 Paperclip 接口同一局域网内的手机浏览器访问http://192.168.1.105:3001/api/invoke就能调用你的本地模型更危险的是如果公司网络未隔离其他同事的电脑也能访问。这违背了 Paperclip 的核心信条AI 能力必须与用户设备强绑定。所以即使你要在 Tauri 桌面应用中使用 Paperclip也应该让 Tauri 的 WebView 通过http://localhost:3001调用而不是让 Tauri 启动一个跨域代理。Tauri 官方文档明确建议“For local development, usehttp://localhost:3001directly”。4.2modelDirOllama 模型路径的隐式约定package.json中还有paperclip: { modelDir: ~/.ollama/models }这个路径不是 Paperclip 自己创建的而是完全复用 Ollama 的默认模型存储位置。Ollama 安装后会在用户主目录下创建.ollama文件夹所有ollama pull下载的模型都存在~/.ollama/models/blobs/下。Paperclip 的runLocalInference函数在 spawn 子进程前会先检查该路径是否存在const modelPath path.join(os.homedir(), .ollama, models); if (!fs.existsSync(modelPath)) { throw new Error(Ollama model directory not found at ${modelPath}. Please run ollama pull llama3.2 first.); }这个检查非常必要。我曾遇到一次诡异问题在一台新配的 M2 Mac 上ollama list显示模型正常但 Paperclip 总报model not found。最后发现是 Ollama 的安装包.pkg在 Apple Silicon 上默认把模型装到了/opt/ollama/.ollama/models而 Paperclip 仍去~/下找。解决方案不是改 Paperclip 代码而是手动创建符号链接ln -s /opt/ollama/.ollama ~/.ollama这再次印证 Paperclip 的设计哲学它不试图兼容所有安装变体而是坚定站在 Ollama 官方文档定义的“标准路径”上。你偏离标准就要自己承担适配成本。4.3timeout30 秒超时背后的硬件现实package.json中paperclip: { timeout: 30000 }30 秒超时不是拍脑袋定的。它基于llama3.2在不同硬件上的实测基准硬件配置平均首次 token 延迟8K 上下文完整推理耗时M1 MacBook Air (8GB)2.1s28.4sIntel i7-10700K (32GB)1.3s19.7sRTX 4090 llama.cpp0.4s8.2s30 秒是给 M1 Air 留出的安全余量28.4s 1.6s 网络/序列化开销。如果你在老旧笔记本上运行发现频繁超时不要盲目调高 timeout而应先检查是否开启了ollama serve后台服务Paperclip 的spawn模式与ollama serve冲突会导致重复加载模型是否启用了 macOS 的“动态电源管理”在电池模式下CPU 频率被锁低推理速度下降 40% 以上PDF 文本是否真的截断到 8000 字符超过llama3.2的 8K 上下文Ollama 会静默截断但 Paperclip 无法感知仍会等待超时。实操心得我在调试超时问题时养成了一个习惯——在runLocalInference函数开头加一行console.time(inference)结尾加console.timeEnd(inference)。这样每次请求终端都会打印inference: 27452.345ms。如果这个时间接近 30s说明是模型推理慢如果只有 200ms 就结束但 Paperclip 仍报超时那一定是网络层如 Chrome 的fetch被拦截或序列化层JSON.stringify 大对象卡住的问题。5. 常见问题与排查技巧实录那些官方文档不会写的坑Paperclip 的 GitHub Issues 页面里高频问题高度集中。我把它们归为三类环境类、模型类、集成类并附上我的真实排查路径。5.1 环境类问题Node.js 版本与 Windows 路径的双重绞杀问题现象Windows 用户执行npm start后终端报错Error: spawn ollama ENOENT at ChildProcess._handle.onexit (node:internal/child_process:286:19)表面原因系统找不到ollama命令。深层原因Windows 的PATH环境变量未包含 Ollama 的安装目录。Ollama Windows 安装包默认装到C:\Users\{username}\AppData\Local\Programs\Ollama\但该路径不会自动加入PATH。我的排查步骤打开 PowerShell执行where ollama—— 如果返回空证明 PATH 未生效手动添加右键“此电脑”→“属性”→“高级系统设置”→“环境变量”→在“系统变量”中找到Path→ “编辑” → “新建” → 粘贴C:\Users\{username}\AppData\Local\Programs\Ollama\关键一步关闭所有已打开的终端窗口重新打开一个新的 PowerShell再执行ollama list—— 必须新开终端因为环境变量变更不会热更新到已存在的进程。注意不要用set PATH%PATH%;C:\...\Ollama\在当前终端临时设置。Paperclip 的spawn是子进程它继承的是父进程Node.js启动时的环境变量快照不是你当前终端的实时变量。5.2 模型类问题llama3.2与llama3.2:latest的语义鸿沟问题现象调用时返回{error:model llama3.2 not found}但ollama list明明显示NAME ID SIZE MODIFIED llama3.2:latest 1a2b3c4d5e6f 4.7GB 2 hours ago根本原因Ollama 的模型标识符是name:tag格式llama3.2是 namelatest是 tag。Paperclip 的默认配置里写的是model: llama3.2:latest但很多用户复制示例时手误写成model: llama3.2漏了:latest。验证方法在 Paperclip 的src/server/index.ts中找到runLocalInference函数加一行日志console.log(Attempting to run model:, model); // 输出实际传入的 model 字符串然后发起请求看终端是否打印Attempting to run model: llama3.2。如果是立刻修正前端 fetch 的 body。实操心得我后来在自己的 fork 版本里加了一个容错逻辑——如果model字符串不包含:则自动补上:latest。但这违背了 Paperclip “不隐藏复杂性”的原则所以我没提 PR只作为个人分支的 hack 使用。5.3 集成类问题React 开发服务器的端口冲突与 CORS 幻觉问题现象React 项目运行在http://localhost:3000Paperclip 在http://localhost:3001但浏览器控制台报Access to fetch at http://localhost:3001/api/invoke from origin http://localhost:3000 has been blocked by CORS policy荒谬之处localhost:3000和localhost:3001是不同源port 不同但 Paperclip 明确不设 CORS header为何会触发浏览器的 CORS 检查真相这是 Chrome 的“预检请求preflight”幻觉。当你在 fetch 的headers中写了Content-Type: application/jsonChrome 会认为这是一个“非简单请求”先发一个OPTIONS请求探路。而 Paperclip 的http.Server根本没处理OPTIONS方法直接返回 404Chrome 就判定 CORS 失败。终极解法删掉 fetch 的 headers 配置。Paperclip 的/api/invokeendpoint 只接受 JSON且fetch在body是JSON.stringify()时会自动带上Content-Type: application/json。你手动写反而触发预检。正确写法const response await fetch(http://localhost:3001/api/invoke, { method: POST, body: JSON.stringify({ prompt: ..., model: ... }) // 删掉 headers: { Content-Type: application/json } });5.4 问题速查表5 分钟定位故障根源现象最可能原因快速验证命令修复动作npm start报Cannot find module typescript未全局安装 TypeScript且项目未npm installnpm list typescript在 Paperclip 根目录执行npm installollama run llama3.2卡住不动CPU 占用 100%M系列芯片未启用 Rosetta 2旧版 Ollamafile /opt/ollama/ollama重装最新版 Ollama支持原生 ARM64React fetch 返回TypeError: Failed to fetchPaperclip 服务未启动或端口被占用lsof -i :3001(macOS) /netstat -ano | findstr :3001(Win)kill -9 {PID}或改package.json中 port摘要结果为空字符串无报错PDF 文本提取失败pdfText为空console.log(pdfText length:, pdfText.length)检查pdfjs-dist加载是否成功worker 路径是否正确同一请求多次调用响应内容不一致llama3.2的随机性未禁用在 prompt 末尾加--seed 42Paperclip 不支持 seed 参数需改用llama.cpp 自定义 wrapper6. 进阶实践从 Paperclip 到生产就绪的三条演进路径Paperclip 的定位是“胶水”不是“平台”。当你用它跑通第一个 demo 后必然会面临三个现实问题如何支持多模型切换如何让非技术用户一键启动如何在 Electron 打包后仍能调用本地模型这三条路径代表了从玩具到产品的跃迁。6.1 路径一模型路由层——用 Nginx 做最朴素的流量分发Paperclip 本身不支持“一个服务代理多个模型”但你可以用 Nginx 在它前面加一层路由。例如你想同时提供llama3.2和phi-3两种摘要能力可以启动两个 Paperclip 实例PORT3001 npm start和PORT3002 npm start配置 Nginxupstream llama32_backend { server localhost:3001; } upstream phi3_backend { server localhost:3002; } server { listen 3000; location /api/llama32/invoke { proxy_pass http://llama32_backend/api/invoke; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /api/phi3/invoke { proxy_pass http://phi3_backend/api/invoke; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这样前端只需改 URL// 调用 llama3.2 fetch(http://localhost:3000/api/llama32/invoke, { ... }) // 调用 phi-3 fetch(http://localhost:3000/api/phi3/invoke, { ... })Nginx 的优势在于零 Node.js 依赖、配置即生效、自带健康检查proxy_next_upstream error timeout。我在线上 PoC 环境中用它支撑过 50 并发CPU 占用始终低于 3%。6.2 路径二一键启动器——用 Electron 封装 Node.js 服务Paperclip 的npm start对普通用户太不友好。更好的方案是把它打包进 Electron 应用。关键点在于Electron 主进程要负责启动并管理 Paperclip 子进程。在main.js中const { app, BrowserWindow, ipcMain } require(electron); const { spawn } require(child_process); let paperclipProcess null; function startPaperclip() { if (paperclipProcess) return; paperclipProcess spawn(node, [bin/paperclip.js], { cwd: path.join(__dirname, ../paperclip), stdio: [ignore, pipe, pipe] }); paperclipProcess.stdout.on(data, (data) { console.log(Paperclip:, data.toString()); }); paperclipProcess.stderr.on(data, (data) { console.error(Paperclip error:, data.toString()); }); paperclipProcess.on(close, (code) { console.log(Paperclip exited with code ${code}); paperclipProcess null; }); } app.whenReady().then(() { startPaperclip(); // 启动 Paperclip const win new BrowserWindow({ /* config */ }); win.loadURL(http://localhost:3000); // 加载你的 React 应用 });这样用户双击MyApp.appElectron 会自动拉起 PaperclipReact 前端通过http://localhost:3001调用——整个流程对用户完全透明。唯一要注意的是必须把 Paperclip 的node_modules一起打包进 Electron否则spawn会找不到依赖。用electron-builder时在build.files中加入!node_modules/**/*的排除规则即可。6.3 路径三离线模型固化——用 llama.cpp 替代 OllamaOllama 的优势是易用劣势是依赖后台服务。在严格离线环境如军工、金融内网你可能需要llama.cpp这种纯二进制方案。Paperclip 的runLocalInference函数是开放的你只需替换其内部实现// src/server/inference.ts export async function runLocalInference(prompt: string, model: string) { // 原来的 ollama spawn 逻辑 // ↓ 替换为 llama.cpp 调用 const result await spawnSync( ./llama-bin/llama-cli, [ -m, ./models/${model}.gguf, -p, prompt, --temp, 0.1, --seed, 42 ], { encoding: utf8, timeout: 30000 } ); if (result.error) throw result.error; return result.stdout.trim(); }llama.cpp的.gguf模型文件是静态的可随应用分发。我测试过llama3.2.Q4_K_M.gguf2.7GB在 M1 Mac 上推理速度比 Ollama 快 1.8 倍且内存占用更稳定。Paperclip 的价值在此刻凸显它不绑定任何模型运行时你随时可以“拔掉 Ollama插上 llama.cpp”只需改一行spawn命令。7. 我的实践体会为什么 Paperclip 值得你在下一个 AI 项目里认真考虑写完这篇万字长文我合上 MacBook泡了杯茶回想过去三个月用 Paperclip 做过的三个项目一个律所的合同风险点自动标注工具、一个医院的门诊病历结构化