最近 Hacker News 上有个实验很有意思标题是 “Show HN: I asked LLMs to choose between popular developer tools”。做法不复杂给大模型列出一组流行开发者工具让模型从中选一个并说明理由。这类实验常被当成娱乐帖但仔细想一下它其实是一种可量化的评测方法。如果提示词设计得当LLM 可以快速生成横向对比、决策理由和风险提示帮助技术团队完成选型初筛。这篇博客不打算简单复述那个帖子而是把它拆成一个可以落地的技术流程怎么设计评测维度、怎么写提示词、怎么批量跑多个模型、怎么判断结果是否可信以及最后如何接进自己的 Web 服务或自动化任务。适合正在做技术选型、想用 LLM 辅助决策、或者想搭一个工具评测知识库的开发者。先说前提这个项目公开信息有限所以文中代码和参数是通用模板真实场景里需要替换成你自己的模型接口、工具列表和评估标准。下面是完整拆解。1. 核心能力速览能力项说明项目类型LLM 评测实验 / 开发者工具选型辅助脚本输入一组流行开发者工具 评估维度 使用场景输出工具选择结果、推荐理由、对比矩阵、风险提示核心方法通过明确提示词约束 LLM 输出结构化 JSON再用多轮投票提升稳定性硬件门槛调用云端 API 几乎无门槛本地模型需按模型版本测试显存占用启动方式Python 脚本 / Notebook / Web API 包装是否支持批量任务支持需要设计任务队列、并发控制和失败重试是否支持接口 API支持可以封装成 HTTP 服务供内部调用适合场景技术选型初筛、工具对比、生成评测报告、构建内部工具知识库从标题看这个实验的核心价值不在于“LLM 选得准不准”而在于它提供了一套可以复用的评测流程。把流程固化成脚本和接口以后团队可以随时拿新工具、新场景去问同一组模型得到可比较的结果。2. 这个实验想回答什么问题“让 LLM 在流行开发者工具之间做选择”看起来像一次简单的问答实际上包含了三层能力测试。第一层是工具理解。模型需要知道 Express、FastAPI、Spring Boot 这些工具是什么、生态如何、适合解决什么问题。判断标准不是模型能不能背出定义而是它给出的推荐理由是否贴合你的具体场景。第二层是比较能力。只给工具列表没有意义必须给评估维度学习曲线、社区活跃度、性能、部署复杂度、长期维护风险。这些维度决定了模型是在“查资料”还是在“做工程决策”。提示词里维度写得越清楚输出越接近团队真实关心的问题。第三层是稳定性。同一个问题问 10 次如果模型每次推荐结果都不一样那这个实验就只能当娱乐不能作为决策依据。所以更可靠的玩法是让多个模型分别回答最后做投票和理由合并。这就是把 LLM 评测当成一个工程问题来解决而不是单纯玩 Prompt。从实际用途来看这类实验适合回答以下四类问题新项目启动时在几个主流框架里选型。团队已有的技术栈是否需要替换降低维护成本。第三方 SDK 或开发者工具接入前识别潜在绑定风险。给客户或团队内部写技术选型报告生成初稿和对比表。边界也很明显LLM 不能代替真实性能压测也不能代替安全审计。它给出的理由可能来自训练数据无法感知工具最新版本的变化。因此这个流程定位是“初筛”不是“结论”。3. 适用场景与使用边界3.1 适用场景技术选型初筛是最典型的场景。假设团队要在 Django 和 FastAPI 之间选一个你可以让 LLM 从“开发效率、异步支持、生态成熟度、团队学习成本”四个维度给出推荐。如果模型给出的理由基本正确你只需要验证其中最关键的 2 到 3 条就能快速缩小候选范围。其次是工具对比报告生成。把 5 个工具和 8 个评估维度交给模型让它输出一张 Markdown 表格再补充每个维度的解释。这个功能对写技术方案很有价值相当于让 LLM 先帮忙整理竞品分析初稿。第三是内部知识库构建。你可以把工具官方文档、PDF 手册、API Reference 解析后存入向量库再让 LLM 基于这些资料做选择。这样模型就不只是依赖训练记忆而是能引用实际文档内容回答会可靠很多这也是 “building LLMs for production” 里常见的 PDF 解析场景。3.2 使用边界与合规提醒不要用 LLM 的推荐替代硬性指标。比如数据库选型要看 TPCC、主从延迟、数据一致性保证消息队列要看吞吐和投递语义前端框架要看包体积和运行时性能。这些数据必须来自真实压测不能靠模型估算。如果涉及人脸识别、语音合成、图像生成、代码生成等内容必须确保数据来源合法测试素材有授权不侵犯版权和隐私。把内部代码片段发给外部模型前先做脱敏和信息安全评估。对 LLM 推荐的拉踩言论也要谨慎。模型可能在某些工具上产生偏差输出一篇看起来合理但已经过时的对比。最终选型需要人工复核尤其是那些会长期影响团队维护成本的技术决策。4. 环境准备与前置条件这是一套通用检查清单具体版本按你的操作系统和项目要求调整。操作系统Windows 10/11、macOS、Ubuntu 20.04 或更高版本均可。Python 版本建议 Python 3.9 或以上。Python 依赖requests、openai、pydantic、pandas、tenacity。LLM 接口OpenAI 兼容接口、云端模型 API或本地 Ollama 服务。本地模型运行按模型大小准备 NVIDIA 显卡和对应显存实际占用以运行时监控为准。文档或 PDF 解析可选安装 pdfplumber、pypdf、Playwright用于抓取官方文档。磁盘空间脚本本身很小但本地模型文件可能是几个 GB 到几十 GB需预留空间。端口占用如果封装成 Web 服务建议使用 8000 以后的自定义端口避免与常见服务冲突。安装 Python 依赖pip install openai requests pandas pydantic tenacity pypdf如果使用 OpenAI 兼容接口可以通过环境变量设置 API Key 和接口地址export LLM_API_KEYyour-api-key export LLM_BASE_URLhttp://127.0.0.1:8000/v1这里我建议把模型配置单独放到.env或者config.json里避免在代码中写死密钥。5. 一个最小可运行脚本这段代码只是演示思路实际使用需要替换模型名、接口地址和工具列表。5.1 定义工具和评估维度先把要比较的工具和评估维度放到一个 JSON 文件里方便后面批量扩展。{ scene: 构建一个高并发 REST API 服务, dimensions: [ 开发效率, 异步支持, 生态成熟度, 部署复杂度, 团队学习成本 ], tools: [ FastAPI, Django, Express.js, Spring Boot ] }5.2 调用 LLM 生成选择这里用 OpenAI 兼容接口的通用请求格式。如果本地模型不支持某些参数可以打开extra_body或关闭parallel_tool_calls。import json import os import requests def ask_llm_to_choose(config: dict, model: str) - dict: 调用 LLM 接口让模型在给定工具之间做选择。 实际接口地址、模型名和请求参数需要按你使用的服务调整。 url os.getenv(LLM_BASE_URL, http://127.0.0.1:8000/v1) /chat/completions headers { Authorization: fBearer {os.getenv(LLM_API_KEY, )}, Content-Type: application/json, } prompt f 你是资深技术负责人。场景{config[scene]} 评估维度{json.dumps(config[dimensions], ensure_asciiFalse)} 候选工具{json.dumps(config[tools], ensure_asciiFalse)} 请从候选工具里选出一个最合适的并返回 JSON格式如下 {{ choice: 工具名, score: 0-100, reasons: [理由1, 理由2], risks: [风险1, 风险2] }} 不要输出额外内容。 payload { model: model, messages: [ {role: system, content: 你是一个严谨的技术评测助手。}, {role: user, content: prompt}, ], temperature: 0.2, response_format: {type: json_object}, } resp requests.post(url, jsonpayload, headersheaders, timeout120) resp.raise_for_status() data resp.json() content data[choices][0][message][content] return json.loads(content) if __name__ __main__: config { scene: 构建一个高并发 REST API 服务, dimensions: [开发效率, 异步支持, 生态成熟度, 部署复杂度, 团队学习成本], tools: [FastAPI, Django, Express.js, Spring Boot], } result ask_llm_to_choose(config, modelgpt-4o-mini) print(json.dumps(result, ensure_asciiFalse, indent2))如果接口不支持response_format可以去掉这个参数然后在提示词里要求模型只输出 JSON同时用正则把输出内容修剪到合法的 JSON 范围。6. 功能测试与效果验证写完了最小脚本接下来要验证它是否真的可用。建议按下面的测试用例跑一遍。6.1 Web 后端框架选型输入场景构建一个高并发 REST API 服务。候选工具FastAPI、Django、Express.js、Spring Boot。预期输出包括一个明确的 choice 字段、一个分数 score、至少 3 条 reasons、2 条 risks。判断成功的关键是理由是否贴合“高并发 REST API”这个目标比如异步支持、性能表现、数据库迁移能力、部署成本。如果模型返回“Django 是最适合高并发的框架”但没有解释数据来源就要人工复查一遍。模型可能把“生态丰富”误解成“性能最好”。6.2 数据库选型输入场景业务需要强一致性事务读写比约为 5:1部署在云上。候选工具PostgreSQL、MySQL、MongoDB、SQLite。这里重点观察模型是否能区分“关系型数据库”和“文档数据库”的使用边界是否提及事务、ACID、扩展方式。如果模型推荐 MongoDB 却声称它支持强跨文档事务需要确认版本和配置。6.3 前端构建工具选型输入场景中后台管理系统团队以 React 为主。候选工具Webpack、Vite、esbuild、Rollup。预期输出会涉及开发服务器启动速度、HMR 体验、插件生态、生产构建配置成本。这里最容易出现的幻觉是“Vite 比 Webpack 所有方面都好”忽略了老项目迁移成本。6.4 CI/CD 工具选型输入场景项目规模 50 人仓库在 GitHub 上需要容器化部署。候选工具GitHub Actions、GitLab CI、Jenkins、Buildkite。合格回答应该提到 GitHub 生态集成、YAML 维护成本、自建运维成本、并发并发限制。如果模型只给了工具名而没有提到约束条件说明提示词里的场景表达得还不够具体。6.5 批量一致性测试同一个问题用同一模型问 5 次统计 choice 是否一致。如果 5 次里出现 3 种不同选择说明提示词太开放或者模型本身不稳定。这时需要降低 temperature并增加“请严格根据评估维度打分”的约束。测试项预期结果判断标准Web 框架选型得到 JSON 输出key 完整理由可读数据库选型能区分 SQL/NoSQL 边界正确指出事务和一致性风险前端构建选型结合场景推荐不忽略迁移成本CI/CD 选型结合团队规模推荐不夸大单一功能5 次重复实验至少 4 次一致若不一致则调整 temperature7. 把结果变成批量评测任务单次调用没有意义真实场景需要批量评测。比如一次跑 10 个场景、5 个模型一共 50 次调用。为了避免接口限流和网络超时任务队列和失败重试是必要的。7.1 使用线程池并发调用import concurrent.futures import json import time def run_single(task: dict) - dict: 执行单次 LLM 选型任务失败时抛出异常由上层重试。 config task[config] model task[model] task_id task[task_id] # 实际调用 ask_llm_to_choose 函数 result ask_llm_to_choose(config, model) return {task_id: task_id, model: model, result: result} def run_batch(tasks: list, max_workers: int 3) - list: results [] with concurrent.futures.ThreadPoolExecutor(max_workersmax_workers) as executor: future_map {executor.submit(run_single, task): task for task in tasks} for future in concurrent.futures.as_completed(future_map): task future_map[future] try: result future.result() results.append(result) except Exception as e: results.append({task_id: task[task_id], error: str(e)}) return results if __name__ __main__: tasks [] for i, scene in enumerate([REST API, 数据处理管道, 微服务网关]): tasks.append({ task_id: i, model: gpt-4o-mini, config: {scene: scene, dimensions: [...], tools: [...]} }) all_results run_batch(tasks, max_workers3) print(json.dumps(all_results, ensure_asciiFalse, indent2))并发数不要开太高。云端 API 通常有 RPM 和 TPM 限制本地模型也可能因为显存不足排队。建议每次只并发 2 到 3 个请求观察延迟和错误率。7.2 失败重试与缓存对于超时、限流、返回 JSON 解析失败等问题可以写重试。最简单的方法是使用 tenacityfrom tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type import requests import json class LLMResponseError(Exception): pass retry( stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max10), retryretry_if_exception_type((requests.Timeout, LLMResponseError)) ) def ask_llm_with_retry(config: dict, model: str) - dict: text json.dumps(config, ensure_asciiFalse) if not text: raise LLMResponseError(empty config) # 这里换成你的真实调用逻辑 return ask_llm_to_choose(config, model)每次调用前建议先检查本地缓存。同一个场景、同一个模型、相同温度参数直接复用结果避免重复消耗接口配额。缓存可以存到 SQLite 或 JSON 文件里以scene model prompt_hash作为 key。7.3 结果持久化批量任务跑完以后把结果统一写入 CSV 或 Parquet 文件方便后续做统计分析和人工复核。import csv def save_results(results: list, output_path: str) - None: with open(output_path, w, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerow([task_id, model, choice, score, reasons, risks]) for item in results: result item.get(result, {}) writer.writerow([ item.get(task_id), item.get(model), result.get(choice), result.get(score), ; .join(result.get(reasons, [])), ; .join(result.get(risks, [])), ])用 CSV 保存的好处是可以直接导入 Excel 或 BI 工具也可以后面用 pandas 做聚合分析。8. 接口 API 与批量任务调用示例如果你不只想跑本地脚本而是想把这个评测能力接到现有系统里可以封装一个 HTTP 接口。这样团队内部的选型系统、日报生成、周报自动化都能直接调用。8.1 用 FastAPI 封装评测接口from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field from typing import List app FastAPI() class EvalRequest(BaseModel): scene: str tools: List[str] dimensions: List[str] model: str Field(defaultgpt-4o-mini) class EvalResponse(BaseModel): choice: str score: int reasons: List[str] risks: List[str] app.post(/api/evaluate, response_modelEvalResponse) def evaluate(req: EvalRequest): config { scene: req.scene, dimensions: req.dimensions, tools: req.tools, } try: result ask_llm_to_choose(config, req.model) except Exception as e: raise HTTPException(status_code500, detailstr(e)) return result if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)启动接口服务uvicorn main:app --host 0.0.0.0 --port 8000这样本地语言模型还是云端模型都可以统一暴露成一个内部服务。别人只需要知道接口协议不需要关注模型细节。8.2 使用 curl 测试接口curl -X POST http://127.0.0.1:8000/api/evaluate \ -H Content-Type: application/json \ -d { scene: 构建一个高并发 REST API 服务, tools: [FastAPI, Django, Express.js, Spring Boot], dimensions: [开发效率, 异步支持, 生态成熟度, 部署复杂度, 团队学习成本], model: gpt-4o-mini }如果接口能正常返回 JSON就说明整套链路可以跑通。后续在里面加鉴权、限流、成本统计都比较容易。8.3 批量任务的接口设计批量任务建议单独设计一个异步任务入口避免客户端长时间等待。POST /api/batch/evaluate { tasks: [ { task_id: task-001, scene: REST API, tools: [FastAPI, Django], dimensions: [性能, 生态], model: gpt-4o-mini }, { task_id: task-002, scene: 消息队列, tools: [RabbitMQ, Kafka], dimensions: [吞吐, 运维复杂度], model: gpt-4o-mini } ] }服务端可以先把任务放入队列返回一个batch_id然后通过另一个接口查询每个 task 的状态和结果。这个模式适合内部工具避免调用方一直阻塞等待。9. 资源占用与性能观察这套流程的资源占用取决于你使用云端 API 还是本地模型。如果用云端 API主要看接口延迟和费用。单个选择任务的完整链路包括构造 prompt、调用模型、解析 JSON。一次简单的选型调用通常不会太长但如果工具数量很多、评估维度很多prompt 变长延迟会明显增加。批量任务的核心成本是 token 消耗因为每个维度都要在 prompt 里重复出现。如果用本地模型重点看显存占用和推理速度。显存占用取决于模型大小和输入长度。以 7B 到 8B 量级的模型为例常见情况是量化后占用在 4GB 到 8GB 左右但这并不是固定结论必须按实际模型版本、上下文长度、量化精度来测试。更稳妥的做法是启动后观察nvidia-sminvidia-smi --query-gpuname,memory.total,memory.used --formatcsv观察时要注意显存占用会随上下文长度变大。如果你把大量工具文档或 PDF 内容拼接到 prompt 里显存占用会上升。建议先跑短 prompt 验证流程再逐步加长文本。如果是解析 PDF 文档、官方文档构建知识库资源瓶颈会在 CPU 和内存。PDF 解析阶段通常不依赖 GPU但大文件解析会占满单核 CPU。把解析后的文本写入向量库时内存占用会随文档规模增加。降低资源占用的几个方法批量任务并发数控制在 2 到 3。提高temperature会降低一部分重复性但不是主要方式。对输入文档做分块只把和候选工具相关的段落送入 prompt。使用本地向量库做检索减少长上下文输入。10. 常见问题与排查方法问题现象可能原因排查方式解决方案返回内容不是合法 JSON模型不遵守格式约束打印原始 resp.content去掉 response_format在提示词里加强“只输出 JSON”用正则提取 JSON 块多次结果不一致temperature 过高或维度不清晰固定 temperature0重复 5 次统计降低 temperature增加“按维度逐一打分”的指令API 调用超时输入过长或接口限流查看服务端日志和响应时间缩短工具列表和维度增加重试降低并发本地模型启动后很卡显存不足或模型未量化执行 nvidia-smi 查看显存换更小模型或降低上下文长度批量任务中途失败单次请求超时导致线程崩溃查看日志中 task_id给每个任务增加独立重试和异常捕获推荐理由出现幻觉模型记忆过时或上下文不完整检查理由是否引用具体文档内容把官方文档片段加入上下文或用 RAG 检索后拼接PDF 解析乱码扫描件或复杂排版预览 PDF 是否为图片型使用 OCR 组件或选择带 OCR 的解析库端口被占用已有服务占用 8000 端口执行 netstat -anofindstr :8000遇到问题时第一步永远是打印错误信息。把 API 返回的完整报文保存下来再决定是调整提示词、减少输入文本还是换模型。11. 最佳实践与使用建议想让这套评测方法真正可用可以遵守下面几条工程化建议。第一次先跑小规模实验。不要一上来就批量跑 50 个场景。先用 3 个熟悉的工具、2 个评估维度验证流程确认输出格式稳定再逐步扩展。把 prompt 模板和工具配置分开管理。prompt 模板放在单独文件里工具列表和评估维度放在 JSON 或数据库里。后续更新只需要改一份配置不需要动代码。保存每一次原始输出。不只保存解析后的 JSON还要保存模型返回的原始字符串。很多坑都在“解析失败”和“模型输出格式不标准”上原始内容丢了会很难定位问题。多模型投票比单一模型可靠。如果条件允许用不同厂商的模型跑同一组任务统计选择结果的重叠度。重叠度高的部分可信度更高重叠度低的部分需要人工重点复核。输入输出目录分开。批量任务运行后原始请求、原始响应、解析结果、人工复核记录分别放在不同目录避免污染。接口服务要限制访问范围和权限。内部评测接口最好只监听内网地址不要直接暴露到公网。如果必须公网访问需要加认证和限流。涉及代码片段拼接、内部架构信息输入时先脱敏。不要直接把公司内部敏感信息发送到外部模型接口。涉及文档、PDF、图像、声音、人脸等素材确认来源合法获得授权后再进行解析和处理。最后人工复核不能省。LLM 适合做初筛和对比报告草稿但最终选型必须由熟悉业务的工程师确认。12. 总结与下一步“Show HN: I asked LLMs to choose between popular developer tools” 这类项目最值得尝试的点不是让模型替你拍板而是把选型过程变成了一个可编程、可重复的实验。只要你把工具列表、评估维度、场景描述结构化就能让 LLM 快速生成对比报告和决策理由减少信息搜集时间。先做哪一步建议如下先把第 5 节的最小脚本跑通换成一个你真正关心的选型场景比如你熟悉的两个框架。跑通之后观察输出格式和稳定性再考虑封装成 FastAPI 服务。如果过程顺利再扩展批量任务多模型投票、文档知识库和 PDF 解析都可以逐步加进来。最容易踩的坑不是模型回答得不对而是输出格式不稳定、批量任务没重试、结果没有留档。这些问题在早期小规模测试时很容易规避等到批量跑起来再处理就麻烦了。后续可以继续扩展的方向包括把评测结果可视化做成工具对比图把工具官方文档和 Release Notes 自动同步进向量库把新版本发布事件接入评测流程定期刷新选型报告。这样整个评测系统就不只是一个“问答脚本”而会变成一个持续运转的工具情报站。
用LLM辅助开发者工具选型：从提示词到API封装
最近 Hacker News 上有个实验很有意思标题是 “Show HN: I asked LLMs to choose between popular developer tools”。做法不复杂给大模型列出一组流行开发者工具让模型从中选一个并说明理由。这类实验常被当成娱乐帖但仔细想一下它其实是一种可量化的评测方法。如果提示词设计得当LLM 可以快速生成横向对比、决策理由和风险提示帮助技术团队完成选型初筛。这篇博客不打算简单复述那个帖子而是把它拆成一个可以落地的技术流程怎么设计评测维度、怎么写提示词、怎么批量跑多个模型、怎么判断结果是否可信以及最后如何接进自己的 Web 服务或自动化任务。适合正在做技术选型、想用 LLM 辅助决策、或者想搭一个工具评测知识库的开发者。先说前提这个项目公开信息有限所以文中代码和参数是通用模板真实场景里需要替换成你自己的模型接口、工具列表和评估标准。下面是完整拆解。1. 核心能力速览能力项说明项目类型LLM 评测实验 / 开发者工具选型辅助脚本输入一组流行开发者工具 评估维度 使用场景输出工具选择结果、推荐理由、对比矩阵、风险提示核心方法通过明确提示词约束 LLM 输出结构化 JSON再用多轮投票提升稳定性硬件门槛调用云端 API 几乎无门槛本地模型需按模型版本测试显存占用启动方式Python 脚本 / Notebook / Web API 包装是否支持批量任务支持需要设计任务队列、并发控制和失败重试是否支持接口 API支持可以封装成 HTTP 服务供内部调用适合场景技术选型初筛、工具对比、生成评测报告、构建内部工具知识库从标题看这个实验的核心价值不在于“LLM 选得准不准”而在于它提供了一套可以复用的评测流程。把流程固化成脚本和接口以后团队可以随时拿新工具、新场景去问同一组模型得到可比较的结果。2. 这个实验想回答什么问题“让 LLM 在流行开发者工具之间做选择”看起来像一次简单的问答实际上包含了三层能力测试。第一层是工具理解。模型需要知道 Express、FastAPI、Spring Boot 这些工具是什么、生态如何、适合解决什么问题。判断标准不是模型能不能背出定义而是它给出的推荐理由是否贴合你的具体场景。第二层是比较能力。只给工具列表没有意义必须给评估维度学习曲线、社区活跃度、性能、部署复杂度、长期维护风险。这些维度决定了模型是在“查资料”还是在“做工程决策”。提示词里维度写得越清楚输出越接近团队真实关心的问题。第三层是稳定性。同一个问题问 10 次如果模型每次推荐结果都不一样那这个实验就只能当娱乐不能作为决策依据。所以更可靠的玩法是让多个模型分别回答最后做投票和理由合并。这就是把 LLM 评测当成一个工程问题来解决而不是单纯玩 Prompt。从实际用途来看这类实验适合回答以下四类问题新项目启动时在几个主流框架里选型。团队已有的技术栈是否需要替换降低维护成本。第三方 SDK 或开发者工具接入前识别潜在绑定风险。给客户或团队内部写技术选型报告生成初稿和对比表。边界也很明显LLM 不能代替真实性能压测也不能代替安全审计。它给出的理由可能来自训练数据无法感知工具最新版本的变化。因此这个流程定位是“初筛”不是“结论”。3. 适用场景与使用边界3.1 适用场景技术选型初筛是最典型的场景。假设团队要在 Django 和 FastAPI 之间选一个你可以让 LLM 从“开发效率、异步支持、生态成熟度、团队学习成本”四个维度给出推荐。如果模型给出的理由基本正确你只需要验证其中最关键的 2 到 3 条就能快速缩小候选范围。其次是工具对比报告生成。把 5 个工具和 8 个评估维度交给模型让它输出一张 Markdown 表格再补充每个维度的解释。这个功能对写技术方案很有价值相当于让 LLM 先帮忙整理竞品分析初稿。第三是内部知识库构建。你可以把工具官方文档、PDF 手册、API Reference 解析后存入向量库再让 LLM 基于这些资料做选择。这样模型就不只是依赖训练记忆而是能引用实际文档内容回答会可靠很多这也是 “building LLMs for production” 里常见的 PDF 解析场景。3.2 使用边界与合规提醒不要用 LLM 的推荐替代硬性指标。比如数据库选型要看 TPCC、主从延迟、数据一致性保证消息队列要看吞吐和投递语义前端框架要看包体积和运行时性能。这些数据必须来自真实压测不能靠模型估算。如果涉及人脸识别、语音合成、图像生成、代码生成等内容必须确保数据来源合法测试素材有授权不侵犯版权和隐私。把内部代码片段发给外部模型前先做脱敏和信息安全评估。对 LLM 推荐的拉踩言论也要谨慎。模型可能在某些工具上产生偏差输出一篇看起来合理但已经过时的对比。最终选型需要人工复核尤其是那些会长期影响团队维护成本的技术决策。4. 环境准备与前置条件这是一套通用检查清单具体版本按你的操作系统和项目要求调整。操作系统Windows 10/11、macOS、Ubuntu 20.04 或更高版本均可。Python 版本建议 Python 3.9 或以上。Python 依赖requests、openai、pydantic、pandas、tenacity。LLM 接口OpenAI 兼容接口、云端模型 API或本地 Ollama 服务。本地模型运行按模型大小准备 NVIDIA 显卡和对应显存实际占用以运行时监控为准。文档或 PDF 解析可选安装 pdfplumber、pypdf、Playwright用于抓取官方文档。磁盘空间脚本本身很小但本地模型文件可能是几个 GB 到几十 GB需预留空间。端口占用如果封装成 Web 服务建议使用 8000 以后的自定义端口避免与常见服务冲突。安装 Python 依赖pip install openai requests pandas pydantic tenacity pypdf如果使用 OpenAI 兼容接口可以通过环境变量设置 API Key 和接口地址export LLM_API_KEYyour-api-key export LLM_BASE_URLhttp://127.0.0.1:8000/v1这里我建议把模型配置单独放到.env或者config.json里避免在代码中写死密钥。5. 一个最小可运行脚本这段代码只是演示思路实际使用需要替换模型名、接口地址和工具列表。5.1 定义工具和评估维度先把要比较的工具和评估维度放到一个 JSON 文件里方便后面批量扩展。{ scene: 构建一个高并发 REST API 服务, dimensions: [ 开发效率, 异步支持, 生态成熟度, 部署复杂度, 团队学习成本 ], tools: [ FastAPI, Django, Express.js, Spring Boot ] }5.2 调用 LLM 生成选择这里用 OpenAI 兼容接口的通用请求格式。如果本地模型不支持某些参数可以打开extra_body或关闭parallel_tool_calls。import json import os import requests def ask_llm_to_choose(config: dict, model: str) - dict: 调用 LLM 接口让模型在给定工具之间做选择。 实际接口地址、模型名和请求参数需要按你使用的服务调整。 url os.getenv(LLM_BASE_URL, http://127.0.0.1:8000/v1) /chat/completions headers { Authorization: fBearer {os.getenv(LLM_API_KEY, )}, Content-Type: application/json, } prompt f 你是资深技术负责人。场景{config[scene]} 评估维度{json.dumps(config[dimensions], ensure_asciiFalse)} 候选工具{json.dumps(config[tools], ensure_asciiFalse)} 请从候选工具里选出一个最合适的并返回 JSON格式如下 {{ choice: 工具名, score: 0-100, reasons: [理由1, 理由2], risks: [风险1, 风险2] }} 不要输出额外内容。 payload { model: model, messages: [ {role: system, content: 你是一个严谨的技术评测助手。}, {role: user, content: prompt}, ], temperature: 0.2, response_format: {type: json_object}, } resp requests.post(url, jsonpayload, headersheaders, timeout120) resp.raise_for_status() data resp.json() content data[choices][0][message][content] return json.loads(content) if __name__ __main__: config { scene: 构建一个高并发 REST API 服务, dimensions: [开发效率, 异步支持, 生态成熟度, 部署复杂度, 团队学习成本], tools: [FastAPI, Django, Express.js, Spring Boot], } result ask_llm_to_choose(config, modelgpt-4o-mini) print(json.dumps(result, ensure_asciiFalse, indent2))如果接口不支持response_format可以去掉这个参数然后在提示词里要求模型只输出 JSON同时用正则把输出内容修剪到合法的 JSON 范围。6. 功能测试与效果验证写完了最小脚本接下来要验证它是否真的可用。建议按下面的测试用例跑一遍。6.1 Web 后端框架选型输入场景构建一个高并发 REST API 服务。候选工具FastAPI、Django、Express.js、Spring Boot。预期输出包括一个明确的 choice 字段、一个分数 score、至少 3 条 reasons、2 条 risks。判断成功的关键是理由是否贴合“高并发 REST API”这个目标比如异步支持、性能表现、数据库迁移能力、部署成本。如果模型返回“Django 是最适合高并发的框架”但没有解释数据来源就要人工复查一遍。模型可能把“生态丰富”误解成“性能最好”。6.2 数据库选型输入场景业务需要强一致性事务读写比约为 5:1部署在云上。候选工具PostgreSQL、MySQL、MongoDB、SQLite。这里重点观察模型是否能区分“关系型数据库”和“文档数据库”的使用边界是否提及事务、ACID、扩展方式。如果模型推荐 MongoDB 却声称它支持强跨文档事务需要确认版本和配置。6.3 前端构建工具选型输入场景中后台管理系统团队以 React 为主。候选工具Webpack、Vite、esbuild、Rollup。预期输出会涉及开发服务器启动速度、HMR 体验、插件生态、生产构建配置成本。这里最容易出现的幻觉是“Vite 比 Webpack 所有方面都好”忽略了老项目迁移成本。6.4 CI/CD 工具选型输入场景项目规模 50 人仓库在 GitHub 上需要容器化部署。候选工具GitHub Actions、GitLab CI、Jenkins、Buildkite。合格回答应该提到 GitHub 生态集成、YAML 维护成本、自建运维成本、并发并发限制。如果模型只给了工具名而没有提到约束条件说明提示词里的场景表达得还不够具体。6.5 批量一致性测试同一个问题用同一模型问 5 次统计 choice 是否一致。如果 5 次里出现 3 种不同选择说明提示词太开放或者模型本身不稳定。这时需要降低 temperature并增加“请严格根据评估维度打分”的约束。测试项预期结果判断标准Web 框架选型得到 JSON 输出key 完整理由可读数据库选型能区分 SQL/NoSQL 边界正确指出事务和一致性风险前端构建选型结合场景推荐不忽略迁移成本CI/CD 选型结合团队规模推荐不夸大单一功能5 次重复实验至少 4 次一致若不一致则调整 temperature7. 把结果变成批量评测任务单次调用没有意义真实场景需要批量评测。比如一次跑 10 个场景、5 个模型一共 50 次调用。为了避免接口限流和网络超时任务队列和失败重试是必要的。7.1 使用线程池并发调用import concurrent.futures import json import time def run_single(task: dict) - dict: 执行单次 LLM 选型任务失败时抛出异常由上层重试。 config task[config] model task[model] task_id task[task_id] # 实际调用 ask_llm_to_choose 函数 result ask_llm_to_choose(config, model) return {task_id: task_id, model: model, result: result} def run_batch(tasks: list, max_workers: int 3) - list: results [] with concurrent.futures.ThreadPoolExecutor(max_workersmax_workers) as executor: future_map {executor.submit(run_single, task): task for task in tasks} for future in concurrent.futures.as_completed(future_map): task future_map[future] try: result future.result() results.append(result) except Exception as e: results.append({task_id: task[task_id], error: str(e)}) return results if __name__ __main__: tasks [] for i, scene in enumerate([REST API, 数据处理管道, 微服务网关]): tasks.append({ task_id: i, model: gpt-4o-mini, config: {scene: scene, dimensions: [...], tools: [...]} }) all_results run_batch(tasks, max_workers3) print(json.dumps(all_results, ensure_asciiFalse, indent2))并发数不要开太高。云端 API 通常有 RPM 和 TPM 限制本地模型也可能因为显存不足排队。建议每次只并发 2 到 3 个请求观察延迟和错误率。7.2 失败重试与缓存对于超时、限流、返回 JSON 解析失败等问题可以写重试。最简单的方法是使用 tenacityfrom tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type import requests import json class LLMResponseError(Exception): pass retry( stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max10), retryretry_if_exception_type((requests.Timeout, LLMResponseError)) ) def ask_llm_with_retry(config: dict, model: str) - dict: text json.dumps(config, ensure_asciiFalse) if not text: raise LLMResponseError(empty config) # 这里换成你的真实调用逻辑 return ask_llm_to_choose(config, model)每次调用前建议先检查本地缓存。同一个场景、同一个模型、相同温度参数直接复用结果避免重复消耗接口配额。缓存可以存到 SQLite 或 JSON 文件里以scene model prompt_hash作为 key。7.3 结果持久化批量任务跑完以后把结果统一写入 CSV 或 Parquet 文件方便后续做统计分析和人工复核。import csv def save_results(results: list, output_path: str) - None: with open(output_path, w, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerow([task_id, model, choice, score, reasons, risks]) for item in results: result item.get(result, {}) writer.writerow([ item.get(task_id), item.get(model), result.get(choice), result.get(score), ; .join(result.get(reasons, [])), ; .join(result.get(risks, [])), ])用 CSV 保存的好处是可以直接导入 Excel 或 BI 工具也可以后面用 pandas 做聚合分析。8. 接口 API 与批量任务调用示例如果你不只想跑本地脚本而是想把这个评测能力接到现有系统里可以封装一个 HTTP 接口。这样团队内部的选型系统、日报生成、周报自动化都能直接调用。8.1 用 FastAPI 封装评测接口from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field from typing import List app FastAPI() class EvalRequest(BaseModel): scene: str tools: List[str] dimensions: List[str] model: str Field(defaultgpt-4o-mini) class EvalResponse(BaseModel): choice: str score: int reasons: List[str] risks: List[str] app.post(/api/evaluate, response_modelEvalResponse) def evaluate(req: EvalRequest): config { scene: req.scene, dimensions: req.dimensions, tools: req.tools, } try: result ask_llm_to_choose(config, req.model) except Exception as e: raise HTTPException(status_code500, detailstr(e)) return result if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)启动接口服务uvicorn main:app --host 0.0.0.0 --port 8000这样本地语言模型还是云端模型都可以统一暴露成一个内部服务。别人只需要知道接口协议不需要关注模型细节。8.2 使用 curl 测试接口curl -X POST http://127.0.0.1:8000/api/evaluate \ -H Content-Type: application/json \ -d { scene: 构建一个高并发 REST API 服务, tools: [FastAPI, Django, Express.js, Spring Boot], dimensions: [开发效率, 异步支持, 生态成熟度, 部署复杂度, 团队学习成本], model: gpt-4o-mini }如果接口能正常返回 JSON就说明整套链路可以跑通。后续在里面加鉴权、限流、成本统计都比较容易。8.3 批量任务的接口设计批量任务建议单独设计一个异步任务入口避免客户端长时间等待。POST /api/batch/evaluate { tasks: [ { task_id: task-001, scene: REST API, tools: [FastAPI, Django], dimensions: [性能, 生态], model: gpt-4o-mini }, { task_id: task-002, scene: 消息队列, tools: [RabbitMQ, Kafka], dimensions: [吞吐, 运维复杂度], model: gpt-4o-mini } ] }服务端可以先把任务放入队列返回一个batch_id然后通过另一个接口查询每个 task 的状态和结果。这个模式适合内部工具避免调用方一直阻塞等待。9. 资源占用与性能观察这套流程的资源占用取决于你使用云端 API 还是本地模型。如果用云端 API主要看接口延迟和费用。单个选择任务的完整链路包括构造 prompt、调用模型、解析 JSON。一次简单的选型调用通常不会太长但如果工具数量很多、评估维度很多prompt 变长延迟会明显增加。批量任务的核心成本是 token 消耗因为每个维度都要在 prompt 里重复出现。如果用本地模型重点看显存占用和推理速度。显存占用取决于模型大小和输入长度。以 7B 到 8B 量级的模型为例常见情况是量化后占用在 4GB 到 8GB 左右但这并不是固定结论必须按实际模型版本、上下文长度、量化精度来测试。更稳妥的做法是启动后观察nvidia-sminvidia-smi --query-gpuname,memory.total,memory.used --formatcsv观察时要注意显存占用会随上下文长度变大。如果你把大量工具文档或 PDF 内容拼接到 prompt 里显存占用会上升。建议先跑短 prompt 验证流程再逐步加长文本。如果是解析 PDF 文档、官方文档构建知识库资源瓶颈会在 CPU 和内存。PDF 解析阶段通常不依赖 GPU但大文件解析会占满单核 CPU。把解析后的文本写入向量库时内存占用会随文档规模增加。降低资源占用的几个方法批量任务并发数控制在 2 到 3。提高temperature会降低一部分重复性但不是主要方式。对输入文档做分块只把和候选工具相关的段落送入 prompt。使用本地向量库做检索减少长上下文输入。10. 常见问题与排查方法问题现象可能原因排查方式解决方案返回内容不是合法 JSON模型不遵守格式约束打印原始 resp.content去掉 response_format在提示词里加强“只输出 JSON”用正则提取 JSON 块多次结果不一致temperature 过高或维度不清晰固定 temperature0重复 5 次统计降低 temperature增加“按维度逐一打分”的指令API 调用超时输入过长或接口限流查看服务端日志和响应时间缩短工具列表和维度增加重试降低并发本地模型启动后很卡显存不足或模型未量化执行 nvidia-smi 查看显存换更小模型或降低上下文长度批量任务中途失败单次请求超时导致线程崩溃查看日志中 task_id给每个任务增加独立重试和异常捕获推荐理由出现幻觉模型记忆过时或上下文不完整检查理由是否引用具体文档内容把官方文档片段加入上下文或用 RAG 检索后拼接PDF 解析乱码扫描件或复杂排版预览 PDF 是否为图片型使用 OCR 组件或选择带 OCR 的解析库端口被占用已有服务占用 8000 端口执行 netstat -anofindstr :8000遇到问题时第一步永远是打印错误信息。把 API 返回的完整报文保存下来再决定是调整提示词、减少输入文本还是换模型。11. 最佳实践与使用建议想让这套评测方法真正可用可以遵守下面几条工程化建议。第一次先跑小规模实验。不要一上来就批量跑 50 个场景。先用 3 个熟悉的工具、2 个评估维度验证流程确认输出格式稳定再逐步扩展。把 prompt 模板和工具配置分开管理。prompt 模板放在单独文件里工具列表和评估维度放在 JSON 或数据库里。后续更新只需要改一份配置不需要动代码。保存每一次原始输出。不只保存解析后的 JSON还要保存模型返回的原始字符串。很多坑都在“解析失败”和“模型输出格式不标准”上原始内容丢了会很难定位问题。多模型投票比单一模型可靠。如果条件允许用不同厂商的模型跑同一组任务统计选择结果的重叠度。重叠度高的部分可信度更高重叠度低的部分需要人工重点复核。输入输出目录分开。批量任务运行后原始请求、原始响应、解析结果、人工复核记录分别放在不同目录避免污染。接口服务要限制访问范围和权限。内部评测接口最好只监听内网地址不要直接暴露到公网。如果必须公网访问需要加认证和限流。涉及代码片段拼接、内部架构信息输入时先脱敏。不要直接把公司内部敏感信息发送到外部模型接口。涉及文档、PDF、图像、声音、人脸等素材确认来源合法获得授权后再进行解析和处理。最后人工复核不能省。LLM 适合做初筛和对比报告草稿但最终选型必须由熟悉业务的工程师确认。12. 总结与下一步“Show HN: I asked LLMs to choose between popular developer tools” 这类项目最值得尝试的点不是让模型替你拍板而是把选型过程变成了一个可编程、可重复的实验。只要你把工具列表、评估维度、场景描述结构化就能让 LLM 快速生成对比报告和决策理由减少信息搜集时间。先做哪一步建议如下先把第 5 节的最小脚本跑通换成一个你真正关心的选型场景比如你熟悉的两个框架。跑通之后观察输出格式和稳定性再考虑封装成 FastAPI 服务。如果过程顺利再扩展批量任务多模型投票、文档知识库和 PDF 解析都可以逐步加进来。最容易踩的坑不是模型回答得不对而是输出格式不稳定、批量任务没重试、结果没有留档。这些问题在早期小规模测试时很容易规避等到批量跑起来再处理就麻烦了。后续可以继续扩展的方向包括把评测结果可视化做成工具对比图把工具官方文档和 Release Notes 自动同步进向量库把新版本发布事件接入评测流程定期刷新选型报告。这样整个评测系统就不只是一个“问答脚本”而会变成一个持续运转的工具情报站。
