从零构建你的Markdown知识卡片生成器MCP协议实战与全链路发布最近在内容创作圈子里有个需求越来越明显如何把那些躺在GitHub仓库里、用Markdown写的技术笔记快速变成可以直接在社交平台分享的“爆款卡片”你可能也注意到了很多技术博主开始用那种设计感很强的知识卡片来分享干货视觉效果和传播效率都比纯文本高出一大截。我自己就经常遇到这种场景——写了一段关于前端性能优化的笔记想分享出去但直接贴Markdown代码没人看手动做图又太费时间。市面上确实有一些现成的转换工具但要么收费不菲要么灵活性不够特别是当你需要批量处理或者集成到自己的工作流时总觉得差点意思。如果你也有类似的痛点那今天聊的这套方案可能会让你眼前一亮。我们不是简单地介绍一个工具而是带你从协议层理解如何用MCPModel Context Protocol构建一个完全可控的Markdown转卡片生成器并把它打包成可以分享、可以复用的NPM包。整个过程涉及AI辅助开发、GitHub Actions自动化、NPM发布策略以及在不同开发环境如Cursor、CodeBuddy中的集成技巧。更重要的是我会分享几个我在实际搭建过程中踩过的“坑”和解决方案——这些细节在官方文档里往往不会提到但恰恰决定了项目能否真正跑起来。1. 理解MCP为什么它是连接AI与工具的关键协议在开始动手之前我们得先搞清楚MCP到底是什么以及它为什么能成为我们项目的技术基石。简单来说MCP是一个让大语言模型安全、可控地调用外部工具的开放协议。你可以把它想象成AI世界的“USB标准”——只要设备支持USB接口就能互相连接同样只要工具实现了MCP Server任何兼容MCP的AI客户端比如Cursor、Claude Desktop都能直接调用它。1.1 MCP的核心架构与工作流程MCP协议定义了三个核心角色理解它们的关系对后续开发至关重要角色职责类比MCP Server提供具体的工具能力如图片生成、文件读写就像一台打印机它知道如何把电子文档变成纸质文件MCP Client嵌入在AI环境中负责向Server发送请求就像电脑上的打印对话框让你选择打印机和设置参数MCP Host提供运行环境管理Server的生命周期就像操作系统管理着打印机驱动程序的加载和运行在实际工作流中当你对AI说“帮我把这篇Markdown转成知识卡片”AI通过MCP Client会识别出这是一个“卡片生成”请求然后调用对应的MCP Server。Server执行实际的转换逻辑生成HTML或图片再把结果返回给AIAI最后呈现给你。这种架构带来了几个关键优势标准化集成你不用为每个AI工具单独写适配代码一次实现MCP Server就能在多个平台使用安全隔离AI模型本身不执行代码所有“危险操作”如文件写入、网络请求都由Server在受控环境中完成动态扩展可以随时添加新的Server来扩展AI的能力范围1.2 为什么选择MCP而不是传统API你可能会问我直接写个Web API不也能实现转换功能吗为什么要多一层MCP这里有个实际案例。我最初尝试用Flask写了个简单的转换API然后在Cursor里通过自定义指令调用。结果发现几个问题上下文管理复杂AI不知道API的具体参数格式需要我在每次对话中反复说明错误处理困难API返回错误时AI往往无法理解如何修复无法“发现”功能AI不能主动知道我这个工具能做什么需要我手动触发而MCP通过标准化的工具描述Schema让AI能“理解”每个工具的功能、参数和返回值。举个例子这是我们的卡片生成工具在MCP中的定义片段{ name: generate_card, description: 将Markdown内容转换为精美的知识卡片图片, inputSchema: { type: object, properties: { content: { type: string, description: Markdown格式的内容 }, theme: { type: string, enum: [简约高级灰, 清新自然, 赛博朋克, 复古打字机, 商务简报], description: 卡片主题样式 }, outputFormat: { type: string, enum: [png, jpeg, html], default: png } }, required: [content] } }AI看到这个定义后就能自动生成合适的调用参数甚至在用户没说清楚主题时主动询问“您希望使用哪种主题样式这里有简约高级灰、清新自然等选项”。提示MCP工具定义的description字段非常重要要写得足够清晰具体。AI主要靠这个描述来理解工具的用途和适用场景。2. 构建Markdown卡片生成器的核心逻辑有了MCP的理论基础我们现在进入实战环节。这一节我会拆解卡片生成器的核心模块并分享几个关键的设计决策。2.1 样式引擎如何实现19种主题的灵活切换市面上的卡片生成工具大多提供3-5种模板但我们希望给用户更多选择。我最终设计了19种主题样式覆盖从“商务简报”到“儿童童话”的不同场景。实现的关键在于样式与逻辑的彻底分离。我创建了一个themes目录里面每个主题都是一个独立的JSON配置文件themes/ ├── business-brief.json # 商务简报 ├── cyberpunk.json # 赛博朋克 ├── minimalist-gray.json # 简约高级灰 ├── natural-fresh.json # 清新自然 ├── retro-typewriter.json # 复古打字机 └── ... (共19个)每个主题文件定义了完整的CSS变量和布局参数{ name: 简约高级灰, variables: { --primary-bg: linear-gradient(135deg, #f5f7fa 0%, #c3cfe2 100%), --card-bg: #ffffff, --text-color: #2c3e50, --border-color: #d1d8e0, --shadow: 0 10px 30px rgba(0, 0, 0, 0.08), --radius: 12px }, typography: { font-family: Inter, SF Pro Text, -apple-system, sans-serif, h1-size: 1.8rem, h2-size: 1.4rem, body-size: 1rem }, layout: { max-width: 800px, padding: 2rem, line-height: 1.6 } }这样设计的好处很明显维护方便要新增主题只需添加一个JSON文件无需修改核心代码动态加载运行时根据用户选择加载对应主题易于定制用户甚至可以自己创建主题文件实现完全个性化注意CSS变量名要保持一致性。我最初用了不同的命名约定有的用primary-color有的用main-color导致切换主题时样式错乱。统一命名规范后问题就解决了。2.2 Markdown解析与HTML生成卡片的内容来自Markdown所以我们需要一个可靠的解析器。我对比了几个主流方案方案优点缺点最终选择marked速度快API简单扩展性一般安全性需注意✓remark生态丰富插件多配置复杂学习曲线陡markdown-it灵活功能强大体积较大考虑到我们的需求相对固定主要是标题、列表、引用、代码块我选择了marked并做了以下安全加固import { marked } from marked; import DOMPurify from dompurify; import { JSDOM } from jsdom; // 创建安全的DOM环境 const window new JSDOM().window; const purify DOMPurify(window); // 配置marked禁用危险特性 marked.setOptions({ gfm: true, // 支持GitHub风格的Markdown breaks: true, // 自动换行 sanitize: false, // 我们用DOMPurify做更彻底的清理 smartypants: true // 智能标点转换 }); // 安全的Markdown转HTML函数 function safeMarkdownToHtml(markdown) { const rawHtml marked.parse(markdown); const cleanHtml purify.sanitize(rawHtml, { ALLOWED_TAGS: [h1, h2, h3, h4, h5, h6, p, br, ul, ol, li, strong, em, blockquote, code, pre, hr, a, img], ALLOWED_ATTR: [href, src, alt, title, class] }); return cleanHtml; }这里有个实际踩过的坑最初我直接用了marked的sanitize: true选项但发现它过滤得太严格连class属性都去掉了导致无法应用CSS样式。后来改用DOMPurify并自定义白名单才在安全和功能间找到平衡。2.3 图片生成从HTML到PNG的完整流水线生成HTML只是第一步用户最终需要的是图片文件。这里我选择了puppeteer无头Chrome来渲染和截图原因如下CSS兼容性好支持所有现代CSS特性包括Flexbox、Grid、CSS变量字体渲染准确可以加载自定义字体确保设计稿和输出一致支持复杂布局特别是那些需要精确计算高度的场景但puppeteer也有自己的坑。最大的问题是性能——每次启动浏览器都要几秒钟对于高频使用的服务来说不可接受。我的解决方案是import puppeteer from puppeteer-core; import chromium from sparticuz/chromium; // 全局复用浏览器实例 let browserInstance null; async function getBrowser() { if (!browserInstance) { // 生产环境使用预编译的Chromium体积更小 const executablePath process.env.NODE_ENV production ? await chromium.executablePath() : process.env.PUPPETEER_EXECUTABLE_PATH; browserInstance await puppeteer.launch({ executablePath, args: chromium.args, defaultViewport: chromium.defaultViewport, headless: chromium.headless, ignoreHTTPSErrors: true, }); } return browserInstance; } async function generateCardImage(htmlContent, theme, outputPath) { const browser await getBrowser(); const page await browser.newPage(); try { // 设置视口大小小红书卡片常用尺寸 await page.setViewport({ width: 800, height: 1200, deviceScaleFactor: 2 }); // 注入HTML和CSS await page.setContent(htmlContent, { waitUntil: networkidle0 }); // 等待所有资源加载完成 await page.evaluate(async () { const selectors Array.from(document.querySelectorAll(img)); await Promise.all(selectors.map(img { if (img.complete) return; return new Promise((resolve, reject) { img.addEventListener(load, resolve); img.addEventListener(error, reject); }); })); }); // 截图并保存 const cardElement await page.$(.card-container); if (cardElement) { await cardElement.screenshot({ path: outputPath, type: png, quality: 90, omitBackground: true }); } } finally { await page.close(); // 注意不关闭browser保持实例复用 } }这个方案在AWS Lambda上测试时冷启动时间从6秒降到了1.5秒热请求更是只需要300毫秒左右。关键点在于浏览器实例复用避免重复启动使用puppeteer-core不自动下载Chromium减小部署包体积生产环境优化使用预编译的Chromium二进制文件3. 将工具封装为MCP Server现在我们有了一套可用的卡片生成逻辑接下来要把它“包装”成MCP Server让AI工具能够调用。3.1 创建MCP Server的基本结构MCP Server本质上是一个遵循特定协议的HTTP服务器或Stdio进程。我选择了Stdio方式因为它更简单不需要处理网络端口和认证。先安装必要的依赖npm install modelcontextprotocol/sdk然后创建server的核心文件// server.js import { Server } from modelcontextprotocol/sdk/server/index.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { CallToolRequestSchema, ListToolsRequestSchema, } from modelcontextprotocol/sdk/types.js; // 创建Server实例 const server new Server( { name: markdown-card-generator, version: 1.0.0, }, { capabilities: { tools: {}, // 声明我们提供工具能力 }, } ); // 定义我们的工具 const tools [ { name: generate_card, description: 将Markdown内容转换为精美的知识卡片图片。支持19种主题样式可输出PNG、JPEG或HTML格式。, inputSchema: { type: object, properties: { content: { type: string, description: Markdown格式的文本内容。支持标题、列表、引用、代码块等常见语法。 }, theme: { type: string, enum: [ 简约高级灰, 清新自然, 赛博朋克, 复古打字机, 商务简报, 苹果备忘录, 波普艺术, 艺术装饰, 玻璃拟态, 温暖柔和, 梦幻渐变, 紫色小红书, 笔记本, 暗黑科技, 水彩艺术, 中国传统, 儿童童话, 日本杂志, 极简黑白 ], default: 清新自然, description: 卡片主题样式共19种可选。 }, outputFormat: { type: string, enum: [png, jpeg, html], default: png, description: 输出格式。PNG适合直接分享JPEG体积更小HTML可用于进一步编辑。 }, splitLongText: { type: boolean, default: true, description: 当内容过长时是否自动拆分为多张卡片。 } }, required: [content] } }, { name: list_themes, description: 列出所有可用的卡片主题样式及其预览效果。, inputSchema: { type: object, properties: {} } } ]; // 处理工具列表请求 server.setRequestHandler(ListToolsRequestSchema, async () { return { tools: tools.map(tool ({ name: tool.name, description: tool.description, inputSchema: tool.inputSchema, })), }; }); // 处理工具调用请求 server.setRequestHandler(CallToolRequestSchema, async (request) { const { name, arguments: args } request.params; if (name generate_card) { try { // 调用我们之前实现的卡片生成逻辑 const result await generateCard({ content: args.content, theme: args.theme || 清新自然, outputFormat: args.outputFormat || png, splitLongText: args.splitLongText ! false }); return { content: [ { type: text, text: 卡片生成成功${result.isSplit ? 内容较长已自动拆分为多张卡片。 : } }, { type: image, data: result.imageData, // base64编码的图片数据 mimeType: image/${args.outputFormat || png} } ] }; } catch (error) { return { content: [ { type: text, text: 生成失败${error.message}\n建议检查Markdown格式是否正确或尝试其他主题。 } ], isError: true }; } } if (name list_themes) { const themesList themes.map(theme • ${theme.name}: ${theme.description}).join(\n); return { content: [ { type: text, text: 可用主题列表共${themes.length}种\n\n${themesList}\n\n使用示例\n\\\\n请用商务简报主题将我的笔记转为卡片\n\\\ } ] }; } return { content: [{ type: text, text: 未知工具${name} }], isError: true }; }); // 启动Server async function main() { const transport new StdioServerTransport(); await server.connect(transport); console.error(MCP Server已启动等待连接...); } main().catch((error) { console.error(Server启动失败:, error); process.exit(1); });3.2 配置AI开发工具以使用MCPServer写好了现在要让AI工具能找到并使用它。不同的工具有不同的配置方式我以最常用的Cursor和CodeBuddy为例。Cursor配置在Cursor中你需要编辑MCP配置文件通常位于~/.cursor/mcp.json或项目根目录的.cursor/mcp.json{ mcpServers: { markdown-card-generator: { command: node, args: [ /绝对路径/到/你的项目/dist/server.js ], env: { NODE_ENV: production } } } }重启Cursor后你就可以直接问它“帮我把这段Markdown转成知识卡片用赛博朋克主题。”CodeBuddy配置CodeBuddy的配置更简单直接在设置界面添加打开CodeBuddy设置找到MCP Servers部分点击Add Server填写Name:markdown-card-generatorCommand:nodeArgs:[/path/to/your/server.js]配置完成后CodeBuddy会自动发现可用的工具并在合适的时机建议你使用。注意路径问题是最常见的配置错误。在开发环境我建议使用相对路径配合process.cwd()在生产环境则要确保路径在部署环境中有效。我吃过亏——本地测试好好的部署到服务器就因为路径不对而失败。3.3 处理长文本的智能拆分用户可能会输入很长的Markdown文档直接生成一张超长卡片既不美观也不实用。我实现了自动拆分功能逻辑如下function splitMarkdownBySections(markdown, maxLength 1500) { // 如果内容本身不长直接返回 if (markdown.length maxLength) { return [markdown]; } // 按标题拆分保持章节完整性 const sections []; const lines markdown.split(\n); let currentSection []; let currentLength 0; for (let i 0; i lines.length; i) { const line lines[i]; const lineLength line.length; // 检测标题行Markdown的#语法 const isHeading line.trim().startsWith(#); if (isHeading currentLength 0) { // 遇到新标题且当前章节已有内容保存当前章节 sections.push(currentSection.join(\n)); currentSection [line]; currentLength lineLength; } else if (currentLength lineLength maxLength currentSection.length 0) { // 当前章节过长但还没遇到新标题 // 尝试在段落边界处切割 if (line.trim() currentSection.length 1) { // 空行是好的切割点 sections.push(currentSection.join(\n)); currentSection [line]; currentLength lineLength; } else { // 没有好的切割点先加入当前行 currentSection.push(line); currentLength lineLength; } } else { // 正常添加行到当前章节 currentSection.push(line); currentLength lineLength; } } // 添加最后一个章节 if (currentSection.length 0) { sections.push(currentSection.join(\n)); } return sections; }这个算法优先保持章节完整性不在标题中间切断其次在段落边界处切割。实际测试中对于一篇5000字的技术博客它能合理地拆分成3-4张卡片每张卡片都有完整的上下文。4. 从GitHub到NPM完整的项目发布流程工具开发完成接下来要让它能被更多人使用。这就涉及到版本管理、自动化测试和发布流程。4.1 GitHub仓库的最佳实践配置创建一个好的GitHub仓库不仅仅是git init那么简单。以下是我总结的几个关键配置README.md的结构# Markdown知识卡片生成器 [](https://www.npmjs.com/package/markdown-card-mcp) [](https://opensource.org/licenses/MIT) 一键将Markdown转换为19种风格的知识卡片支持小红书、Twitter、公众号等多平台。 ## ✨ 特性 - **19种精美主题**从商务简报到赛博朋克总有一款适合你 - **AI原生集成**通过MCP协议在Cursor/CodeBuddy中直接调用 - **多格式输出**PNG、JPEG、HTML满足不同场景需求 - **零配置使用**安装即用无需复杂设置 ## 快速开始 ### 作为MCP Server使用 bash npm install -g markdown-card-mcp # 然后在你的AI工具中配置MCP Server作为Node.js库使用import { generateCard } from markdown-card-mcp; const result await generateCard({ content: # 我的标题\n\n这是我的内容, theme: 清新自然 }); 详细文档主题样式预览API参考常见问题 贡献指南欢迎提交Issue和PR请先阅读贡献指南。 许可证MIT © [你的名字]**关键的GitHub Actions工作流** 我配置了两个自动化工作流一个用于测试一个用于发布 yaml # .github/workflows/test.yml name: Test on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - uses: actions/setup-nodev3 with: node-version: 18 - run: npm ci - run: npm test - run: npm run lint# .github/workflows/publish.yml name: Publish to NPM on: release: types: [published] jobs: publish: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - uses: actions/setup-nodev3 with: node-version: 18 registry-url: https://registry.npmjs.org/ - run: npm ci - run: npm test - run: npm run build - run: npm publish env: NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}4.2 NPM包的优化发布策略发布到NPM不是简单的npm publish要考虑包的大小、依赖管理和版本策略。package.json的关键配置{ name: markdown-card-mcp, version: 1.0.0, description: Markdown to knowledge card converter via MCP protocol, main: dist/index.js, types: dist/index.d.ts, bin: { markdown-card-mcp: ./dist/cli.js }, files: [ dist, themes, README.md ], scripts: { build: tsc node scripts/copy-themes.js, dev: tsc --watch, test: jest, lint: eslint src --ext .ts, prepublishOnly: npm run build npm test }, dependencies: { modelcontextprotocol/sdk: ^0.3.0, marked: ^9.0.0, dompurify: ^3.0.0, jsdom: ^22.0.0 }, devDependencies: { types/node: ^20.0.0, typescript: ^5.0.0, jest: ^29.0.0, eslint: ^8.0.0 }, engines: { node: 18.0.0 }, keywords: [ markdown, mcp, knowledge-card, ai, cursor, codebuddy ] }这里有几个设计决策值得说明files字段只包含必要的文件避免node_modules等无关内容被发布bin字段提供命令行接口方便直接调用engines字段明确Node.js版本要求避免兼容性问题prepublishOnly钩子确保发布前总是经过构建和测试处理Puppeteer的依赖问题Puppeteer是个大家伙如果直接作为依赖安装包会非常大。我的解决方案是{ dependencies: { puppeteer-core: ^21.0.0 }, optionalDependencies: { sparticuz/chromium: ^120.0.0 } }然后在代码中动态选择let chromium; try { chromium await import(sparticuz/chromium); } catch { // 如果可选依赖未安装使用系统Chromium或提示用户 console.warn(未找到优化版Chromium将尝试使用系统浏览器); }这样在大多数场景下用户安装的包体积能减少80%以上。4.3 版本管理与更新策略我采用语义化版本SemVer并配合GitHub Releases主版本Major不兼容的API变更次版本Minor向后兼容的功能新增修订版本Patch向后兼容的问题修复每次发布新版本时我会更新CHANGELOG.md创建GitHub Release触发自动发布到NPM在README中更新版本号为了让用户及时获得更新我还配置了dependabot自动更新依赖# .github/dependabot.yml version: 2 updates: - package-ecosystem: npm directory: / schedule: interval: weekly open-pull-requests-limit: 105. 实际应用中的性能优化与问题排查项目上线后真实的使用场景会暴露出很多在开发环境中没遇到的问题。这里分享几个我遇到的典型问题和解决方案。5.1 内存泄漏的发现与修复最初版本运行一段时间后内存使用会持续增长直到崩溃。通过Heap Snapshot分析发现问题出在Puppeteer页面没有正确清理// 有问题的代码 async function generateCard(html) { const browser await puppeteer.launch(); const page await browser.newPage(); await page.setContent(html); const screenshot await page.screenshot(); // 忘记关闭page和browser return screenshot; }修复后的版本async function generateCard(html) { let browser; let page; try { browser await puppeteer.launch(); page await browser.newPage(); await page.setContent(html); const screenshot await page.screenshot(); return screenshot; } finally { // 确保资源被释放 if (page) await page.close(); if (browser) await browser.close(); } }但这样每次都要启动浏览器性能太差。最终的解决方案是使用连接池class BrowserPool { constructor(maxBrowsers 2) { this.maxBrowsers maxBrowsers; this.browsers []; this.queue []; } async acquire() { // 如果有空闲浏览器直接返回 if (this.browsers.length this.maxBrowsers) { const browser await puppeteer.launch(); this.browsers.push(browser); return { browser, release: () this.release(browser) }; } // 否则等待 return new Promise(resolve { this.queue.push(resolve); }); } release(browser) { // 如果有等待的请求直接给下一个使用 if (this.queue.length 0) { const next this.queue.shift(); next({ browser, release: () this.release(browser) }); } } async destroy() { for (const browser of this.browsers) { await browser.close(); } this.browsers []; } }5.2 字体加载的跨平台兼容性在Mac上渲染正常的卡片在Linux服务器上可能字体缺失。我的解决方案是使用Web安全字体作为回退.card { font-family: Inter, -apple-system, BlinkMacSystemFont, Segoe UI, Noto Sans, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji; }自动下载缺失字体async function ensureFonts() { const fontPath path.join(__dirname, fonts); if (!fs.existsSync(fontPath)) { fs.mkdirSync(fontPath, { recursive: true }); } // 检查Inter字体是否存在 const interFont path.join(fontPath, Inter-Regular.woff2); if (!fs.existsSync(interFont)) { console.log(下载Inter字体...); const response await fetch(https://fonts.gstatic.com/s/inter/v12/...); const buffer await response.arrayBuffer(); fs.writeFileSync(interFont, Buffer.from(buffer)); } return fontPath; }在Puppeteer中注册字体await page.addStyleTag({ content: font-face { font-family: Inter; src: url(${fontUrl}) format(woff2); font-weight: normal; font-style: normal; } });5.3 错误处理与用户友好提示MCP Server的错误需要以AI能理解的方式返回。我设计了一个错误分类系统class CardGenerationError extends Error { constructor(type, message, userTip) { super(message); this.type type; this.userTip userTip; } toMCPResponse() { const tips { markdown_parse: 请检查Markdown语法是否正确特别是标题和列表的格式。, theme_not_found: 主题不存在。可用主题有${availableThemes.join(, )}, content_too_long: 内容过长请尝试启用splitLongText参数或手动拆分内容。, render_timeout: 渲染超时请简化内容或联系开发者。, network_error: 网络错误请检查网络连接后重试。 }; return { content: [{ type: text, text: 生成失败${this.type}${this.message}\n\n建议${this.userTip || tips[this.type] || 请稍后重试} }], isError: true }; } } // 使用示例 try { // ... 生成逻辑 } catch (error) { if (error instanceof CardGenerationError) { return error.toMCPResponse(); } // 未知错误 return { content: [{ type: text, text: 未知错误${error.message}\n\n已记录此问题开发者会尽快修复。 }], isError: true }; }这样的错误信息不仅人类能看懂AI也能理解并给用户提供具体的修复建议。5.4 监控与日志记录在生产环境中知道工具被如何使用、哪里容易出错很重要。我添加了简单的使用统计// 使用统计 const usageStats { totalRequests: 0, byTheme: {}, byFormat: {}, errors: [], averageResponseTime: 0 }; // 请求中间件 async function handleRequest(request, handler) { const startTime Date.now(); usageStats.totalRequests; try { const result await handler(request); const duration Date.now() - startTime; // 更新平均响应时间移动平均 usageStats.averageResponseTime (usageStats.averageResponseTime * 0.9) (duration * 0.1); // 记录主题使用情况 if (request.params.arguments?.theme) { const theme request.params.arguments.theme; usageStats.byTheme[theme] (usageStats.byTheme[theme] || 0) 1; } return result; } catch (error) { usageStats.errors.push({ time: new Date().toISOString(), error: error.message, request: request.params }); // 只保留最近100个错误 if (usageStats.errors.length 100) { usageStats.errors.shift(); } throw error; } }这些数据帮我发现了一些有趣的现象比如“简约高级灰”和“清新自然”是最受欢迎的主题占70%使用量而“赛博朋克”虽然讨论度高实际使用率只有5%。整个项目从构思到发布大约用了三周时间期间最大的收获不是技术本身而是对开发者体验的思考。一个好的工具不仅要功能强大更要容易安装、容易使用、容易调试。这也是为什么我在文档中花了大量篇幅说明各种边界情况和故障排除方法。现在这个工具已经稳定运行了几个月每周处理几千次转换请求。最让我高兴的不是技术指标而是看到用户分享的那些卡片——有人用它做技术分享有人做读书笔记还有人做每周复盘。工具的价值最终体现在它如何帮助人们更好地表达和传播知识。