PostgreSQL 的向量检索扩展——这是 pgvector 最主要的用途，也是本文讨论的前提。

下面用几组示意对比，说明同一任务里提示写法和流程不同会带来什么差别。

对比一：模糊指令 vs 明确指令

改之前：直接说「帮我检索效果对比」。结果往往泛泛而谈、格式随意。

改之后：写清材料、格式和验收标准：

用同一批测试问题分别跑关键词检索、向量检索和混合检索，记录前 5 条结果中正确段落的命中情况。

变化（示意）：输出结构稳定，可以直接按「对比用同一批问题」检查。

对比二：一次做完 vs 分步完成

改之前：把「网页内容抓取」的全部要求一次塞进去。改之后：先让它给出计划或大纲，确认后再逐步完成。变化（示意）：中途发现偏差可以及时纠正，返工更少。

把这些网页转成 Markdown，去掉导航和广告，只保留正文、发布日期和作者；发布日期缺失时标注「未知」。

对比三：不检查 vs 带检查点

改之前：拿到结果直接用。改之后：每次都对照「每个答案都能在手册中找到」检查，并让工具列出它不确定的地方。变化（示意）：问题在交付前被发现。

以上对比均为示意，用来说明方法差异，不代表具体的效率数字。

更多可以试的用法

带来源的快速调研

输入：一个需要事实支撑的问题。

请回答【问题】，每个关键结论后标注来源链接；如果不同来源说法不一，请分别列出；最后给出你认为最可靠的来源及原因。

交付前确认：关键结论都有可点击来源。

内部文档入库

适用情况：手头有一批 PDF、Word 和网页时。

把这些文档解析为干净的文本：保留标题层级和表格，去掉页眉页脚，按章节切分，每段附上原文件名和页码。

交付前确认：切分后的段落能回溯到页码。

资料卡片整理

适用情况：手头有搜索得到的十几篇资料时。

把这些资料整理成卡片：每张卡片包括一句话结论、关键数据、来源和可信度评价，最后按主题分组。

验收标准：每张卡片都有来源。

常见问题：表格内容检索不到

换用能保留表格结构的解析工具，或单独把表格转成文本描述。

常见问题：中文检索效果差

选择对中文支持好的嵌入模型，并为专有名词建立同义词。

常见问题：搜索结果过时

限定时间范围，或在提问中注明需要最新信息并核对发布日期。

概念补充：切分（Chunking）

把长文档拆成适合检索的小段，大小影响效果。

概念补充：RAG（检索增强生成）

先检索相关资料再让模型作答，降低胡编概率。

适合人群：客服人员

客服人员可以用 pgvector 处理回复草稿、工单分类等工作。需要注意：不得以 AI 名义做出政策外承诺，涉及隐私的问题按流程处理。

适合人群：软件工程师

软件工程师可以用 pgvector 处理代码阅读与重构、测试与排错等工作。需要注意：不要把密钥和未开源代码上传到未授权工具，合并前审阅每处改动。

写在最后

涉及个人信息、商业机密或受监管数据时，先确认 pgvector 的数据处理条款，再决定能否使用。

所有示例输出均为示意，不代表真实统计或效果承诺；请以自己的测试结果为准。

延伸阅读