1. 从岗位能力到个人创造FDE 与一人公司 AI 产品的真实分水岭这两年“FDE”这个词在招聘市场和开发者圈子里出现的频率越来越高。FDE 全称 Forward Deployed Engineer直译过来是“前线部署工程师”但如果你只把它理解成“驻场开发”那就完全跑偏了。我见过太多人拿着传统交付工程师的思维去投 FDE 岗位简历上写满了“负责客户需求对接、完成系统部署”结果面试第一轮就被刷下来。原因很简单FDE 的核心不是“把已经做好的东西装到客户机器上”而是“在客户现场用工程手段把一个还没被明确定义的 AI 产品问题快速变成一个能跑起来、能产生业务价值的东西”。这个定位决定了 FDE 的能力模型和普通后端、算法岗有本质区别。普通研发可以等 PRD 写清楚再动手FDE 往往面对的是客户一句“我们想让 AI 帮销售自动整理客户拜访记录”然后你得自己判断这个需求到底该用 RAG 还是微调知识库怎么建检索召回率不够是拆解策略的问题还是 embedding 模型选错了部署在客户内网还是公有云数据合规边界在哪这些问题没有人给你标准答案你得在几天之内给出一个可演示的原型并且能解释清楚每一个技术选型背后的取舍。而“一人公司 AI 产品创造营”这个方向本质上是把 FDE 的能力进一步内化。你不再是为某个客户交付而是为自己创造产品。一个人要同时扮演产品经理、工程师、运营和客服。这时候 Vibe Coding 就成了关键杠杆——它不是让你“不写代码”而是让你把精力从语法细节里解放出来专注在“我要解决什么问题、数据怎么流转、用户体验怎么闭环”上。我自己的体会是Vibe Coding 状态下一个下午能迭代三版原型而传统方式可能还在配环境。这两个方向看似一个偏 To B 交付、一个偏个人创造但它们共享同一套底层能力AI 产品落地能力。具体来说就是能把一个模糊的需求拆解成“数据层—检索层—生成层—交互层”的可执行方案并且知道每一层最常见的坑在哪里。接下来的内容我会围绕这套能力模型把 RAG 知识库、Vibe Coding 工作流、FDE 实战流程这几个核心模块拆开讲透同时把热词里那些高频疑问比如 RAG 到底能不能存图片、瓶颈在哪、ontology RAG 和普通 RAG 的区别一并说清楚。2. RAG 知识库从“能跑”到“好用”之间隔着的那些坑2.1 为什么你的 RAG Demo 很惊艳上线后却被人骂几乎每个做过 RAG 的人都有过这个体验本地拿几十页 PDF 跑一个 LangChain 的 demo问几个问题回答得挺像那么回事于是信心满满地觉得“这东西能用了”。结果一放到真实场景用户问了三个问题就开始骂“答非所问”“胡编乱造”。问题出在哪出在 demo 和产品之间有一道巨大的鸿沟而这道鸿沟不是靠换一个更强的 LLM 就能填上的。我总结下来RAG 从 demo 到可用主要卡在四个地方。第一是文档解析质量。PDF 里的表格、双栏排版、页眉页脚、扫描件 OCR 错误这些在 demo 阶段你可能只拿了几页干净的文本根本遇不到。但真实知识库里一份产品手册可能有 30% 的内容是表格和图示解析出来全是乱码。第二是切分策略。很多人直接用 RecursiveCharacterTextSplitter 按 500 字一刀切结果一个完整的操作步骤被切成两半检索的时候只召回上半段模型自然答不全。第三是检索召回。向量检索对语义相似但关键词不同的查询很友好但对精确匹配比如产品型号“XR-2000A”反而容易漏。第四是上下文组装。召回了 10 个片段全塞给模型结果模型被无关信息干扰或者超出上下文窗口被截断。提示判断一个 RAG 系统是否达到可用标准不要看它答对了多少要看它答错的时候是否“知道自己不知道”。一个会拒答的 RAG比一个什么都敢答的 RAG 有价值得多。2.2 文本拆解本地工具怎么选切分参数怎么定热词里有人问“有没有本地的 RAG 文本拆解工具”这个问题很实际。如果你不想把公司文档传到外部服务本地拆解是刚需。我常用的组合是unstructured做通用文档解析PyMuPDF处理 PDF 的精细提取python-docx处理 Word表格类用camelot或pdfplumber。这几个都是纯本地运行不依赖任何外部 API。切分参数这块没有万能值但有一个我反复验证过的起步配置chunk_size 设为 512chunk_overlap 设为 64。为什么是 512因为主流 embedding 模型比如 bge-large、text-embedding-3-small的训练上下文大多在 512 token 左右超过这个长度向量表示会开始“稀释”语义焦点变模糊。overlap 设 64 是为了防止句子被硬切断导致语义丢失。但这只是起步值真正要调的时候得看你的文档类型技术手册这种逻辑紧密的chunk 可以小一点256-384保证每个片段聚焦一个操作点政策法规这种长段论述的chunk 可以大一点768-1024保证一个完整条款不被拆散。还有一个容易被忽略的点按结构切分优于按长度切分。如果你的文档有明确的标题层级Markdown、HTML、带书签的 PDF优先按标题切把每个小节作为一个 chunk再对超长小节做二次切分。这样检索出来的片段自带上下文归属模型更容易理解。我做过对比同样一份 200 页的技术文档按结构切分的召回准确率比纯按长度切分高出将近 20 个百分点。2.3 RAG 知识库能存图片吗多模态检索的现实做法“RAG 知识库能存储图片嘛”这个问题答案是能但要看你怎么定义“存”和“检索”。最朴素的做法是把图片单独存对象存储然后在文本 chunk 里留一个图片引用链接检索到文本时把链接一并返回。但这只能做到“文本检索、图片展示”做不到“用图片搜图片”或“用文字搜图片内容”。真正要让图片参与语义检索目前有三条路。第一条是图片描述生成用多模态模型比如 GPT-4V、Qwen-VL给每张图生成一段文字描述把描述文本向量化后存入向量库。检索时命中的是描述返回的是原图。这条路实现简单但描述质量依赖模型能力而且对图表中的具体数值容易描述不准。第二条是多模态 embedding用 CLIP 这类模型把图片和文本映射到同一向量空间直接做跨模态检索。这条路技术上更优雅但实际落地时CLIP 对中文文本和复杂图表的检索效果并不理想需要针对领域做微调。第三条是OCR 版面分析把图片里的文字提取出来同时保留版面结构信息本质上还是转成文本处理。对于表格、流程图这类以文字为主的图片这条路最实用。我自己的经验是大多数企业知识库场景第一条路图片描述 文本检索性价比最高。你不需要追求“以图搜图”这种炫技功能用户真正需要的是“我问一个问题你能把相关的图和说明一起给我”。把图片描述写好和文本 chunk 一起入库检索时按相关性排序返回已经能覆盖 80% 的需求。2.4 RAG 瓶颈到底在哪检索质量决定上限很多人把 RAG 的效果不好归咎于“模型不够强”于是拼命换更大的模型。但实际调优下来RAG 的瓶颈 90% 在检索层不在生成层。你给模型喂的上下文如果本身就是错的、不全的、无关的再强的模型也只能胡编。检索层的瓶颈又可以细分为三个。第一是embedding 模型的领域适配。通用 embedding 模型在通用语料上表现很好但到了法律、医疗、工业这些垂直领域语义空间不匹配相似度计算就会失准。解决办法是用领域语料做微调或者至少用领域数据做一轮 hard negative 挖掘重新训练一个适配层。第二是查询改写。用户问“XR-2000A 怎么校准”直接拿这句话去检索可能召回一堆讲“校准流程”但不涉及具体型号的片段。这时候需要先做查询改写把“XR-2000A”这个关键实体提取出来和“校准”组合成更精确的检索 query。第三是重排序。向量检索召回 top-20然后用一个 cross-encoder 重排序模型比如 bge-reranker对这 20 个片段做精排取 top-5 给模型。这一步能显著提升上下文的相关性代价是增加一点延迟但非常值得。注意不要一上来就上重排序。先把解析和切分做扎实再考虑查询改写最后才是重排序。顺序反了你会发现调了半天效果提升不明显因为底层数据质量就没过关。3. Ontology RAG 与 KG 知识库什么时候该上“重武器”3.1 普通 RAG、KG 知识库、结构知识库到底怎么区分热词里有一组很专业的问题“ontology rag、kg 知识库、rag 知识库和结构知识库区分以及应用场景”。这几个概念确实容易混我用一个类比来说清楚。普通 RAG 知识库像是一个巨大的图书馆书都打散了按段落放在架子上你问一个问题管理员根据语义相似度给你找几段最像的文字。它不关心段落之间的逻辑关系只关心“这段文字和你的问题像不像”。结构知识库像是一个 Excel 表格每一行是一条记录字段固定查询靠精确匹配或 SQL。它适合处理“有多少个客户”“上个月销售额是多少”这类结构化问题但没法回答“为什么客户流失了”这种需要理解文本的问题。**KG 知识库知识图谱**像是一张关系网节点是实体人、产品、事件边是关系购买、属于、导致。它能回答“A 产品的用户里有多少人同时买了 B 产品”这种多跳推理问题。但构建成本极高需要实体识别、关系抽取、图谱融合而且维护起来很重。Ontology RAG是介于普通 RAG 和 KG 之间的一种做法。它不构建完整的图谱而是定义一个轻量的本体ontology比如“产品—部件—故障现象—解决方案”这套概念体系然后在检索时利用本体做查询扩展和结果过滤。举个例子用户问“设备过热怎么办”普通 RAG 可能召回一堆提到“过热”的片段但 Ontology RAG 知道“过热”属于“故障现象”这个本体类会自动关联到“散热系统”“温度传感器”等相关概念检索更精准。3.2 什么场景值得上 Ontology RAG什么场景纯属过度设计我的判断标准很简单如果你的知识库里的问题答案需要跨多个文档、多个层级做推理才能得出那 Ontology RAG 有价值如果答案就在某一段文字里普通 RAG 就够了。具体来说适合上 Ontology RAG 的场景包括设备维修知识库故障现象→可能原因→排查步骤→更换部件、法律合规知识库条款→适用条件→例外情况→相关判例、医疗辅助知识库症状→鉴别诊断→检查项→用药禁忌。这些场景的共同特点是知识本身有清晰的层级和因果关系用户的问题往往需要沿着这些关系走几步才能找到答案。反过来如果你的知识库就是一堆 FAQ、产品说明、操作手册用户问的也是“怎么重置密码”“保修期多久”这种单点问题那普通 RAG 加一个好的重排序就够了。上 Ontology 只会增加构建和维护成本效果提升却很有限。我见过一个团队花了三个月构建知识图谱结果上线后发现 95% 的用户查询用普通 RAG 就能解决那三个月的投入基本打了水漂。3.3 从零构建一个轻量 Ontology 的实操路径如果你判断自己的场景确实需要 Ontology RAG我建议不要一上来就搞全套图谱。先做一个轻量本体具体步骤是这样的。第一步梳理核心实体和关系。拿一张白纸把你知识库里最重要的 5-10 类实体列出来比如“产品”“部件”“故障”“解决方案”“客户”。然后画出它们之间的关系“产品包含部件”“部件产生故障”“故障对应解决方案”。这一步不需要任何工具就是业务梳理。第二步定义本体 schema。用 JSON-LD 或简单的 YAML 把上面的实体和关系形式化。比如entities: - name: Product properties: [model, category, release_date] - name: Component properties: [name, part_number] - name: Fault properties: [symptom, severity] relations: - name: has_component from: Product to: Component - name: causes_fault from: Component to: Fault第三步在检索层做本体增强。不需要重新训练模型而是在查询时做两件事一是查询扩展把用户 query 里的实体识别出来根据本体关联到相关实体扩展检索词二是结果过滤根据本体关系对召回结果做约束比如用户问的是“XR-2000A 的故障”就只保留和这个型号相关的片段。第四步迭代验证。拿真实用户问题跑一轮看本体增强后的召回率有没有提升。如果没有明显提升说明你的本体设计可能和实际查询模式不匹配需要调整实体和关系的定义。这套做法的好处是轻量、可迭代不需要一上来就投入大量人力做图谱构建。等验证有效果了再考虑用 Neo4j 这类图数据库做更复杂的推理。4. Vibe Coding 与 FDE 工作流一个人怎么顶一个团队4.1 Vibe Coding 不是“不写代码”而是“把决策前置”Vibe Coding 这个词被很多人误解成“对着 AI 说几句话代码就自动生成了”。如果你真这么干大概率会得到一个能跑但没法维护、没法扩展、到处是隐藏 bug 的东西。我理解的 Vibe Coding核心是把人的精力从“怎么写”转移到“写什么”和“为什么这么写”上。具体来说传统编码流程是想清楚需求→设计架构→写代码→调试→测试→部署。Vibe Coding 流程是用自然语言描述意图→AI 生成候选实现→你快速评估候选方案的合理性→选定方向后让 AI 补全细节→你负责验证边界条件和异常处理。人的角色从“实现者”变成了“决策者和验证者”。这个转变对 FDE 和一人公司尤其重要。因为你的时间是最稀缺的资源如果花在查 API 文档、调语法错误上就没时间思考产品方向和用户价值了。我自己的做法是把 70% 的时间花在“定义问题”和“验证结果”上30% 花在“和 AI 协作生成代码”上。这个比例和传统开发正好反过来。4.2 FDE 流程和步骤从客户现场到可演示原型的 72 小时FDE 的工作节奏和普通研发完全不同。普通研发可以按 sprint 走FDE 往往面对的是“客户下周要看演示”这种压力。我总结了一套 72 小时从零到可演示原型的流程在多个项目里验证过比较稳。第 0-8 小时需求收敛。不要急着写代码。先和客户的关键用户聊搞清楚三件事他们现在怎么完成这个任务现状、最痛的点是什么痛点、如果 AI 能帮上忙他们期望的交互方式是什么期望。然后你自己画一个“最小价值闭环”也就是“用户输入什么→系统做什么→用户得到什么”。这个闭环必须足够小小到 72 小时内能跑通。第 8-24 小时数据摸底与方案定型。拿到客户提供的样本数据快速评估数据质量。如果数据是 PDF先跑一遍解析看解析出来的文本能不能用。如果数据是数据库看字段含义和关联关系。然后确定技术方案用 RAG 还是微调用现成 API 还是本地模型部署在哪这个阶段一定要和客户确认数据合规边界哪些数据能用、哪些不能用、用完怎么销毁。第 24-56 小时原型开发。用 Vibe Coding 的方式快速搭架子。先跑通“输入→检索→生成→输出”的主链路不要纠结 UI 美观用 Streamlit 或 Gradio 快速搭一个能交互的界面就行。这个阶段的关键是每天给客户看一次进展哪怕只是一个命令行 demo让客户尽早反馈避免方向跑偏。第 56-72 小时打磨演示路径。准备 3-5 个演示问题确保这些问题在原型上能稳定跑出好结果。同时准备一个“如果客户问了意料之外的问题”的应对方案比如“这个问题当前版本还覆盖不到但我们可以在下一版加入”。演示的时候重点不是展示技术多牛而是让客户看到“这个东西能帮我省多少时间/减少多少错误”。4.3 一人公司的 AI 产品选型哪些环节必须自己控哪些可以外包给 API一人公司做 AI 产品最大的约束是资源和精力。我的原则是核心数据流和用户体验必须自己控通用能力尽量用 API。必须自己控的环节包括数据管道文档怎么进来、怎么解析、怎么切分、怎么入库、检索策略用什么 embedding、怎么重排序、怎么组装上下文、提示词工程这是你的产品差异化所在、用户反馈闭环用户点了赞/踩之后数据怎么回流优化。这些环节决定了你产品的核心体验外包出去等于把命脉交给别人。可以外包给 API 的环节包括LLM 推理除非你有特殊合规要求否则用现成的 API 比自己部署划算得多、embedding 计算同理、OCR除非你的文档格式极其特殊、基础设施用 Serverless 或托管数据库不要自己维护服务器。我见过一些一人公司开发者为了“技术自主”非要自己部署 LLM结果光环境配置和推理优化就耗掉两个月产品还没上线。这个账算不过来。你的时间应该花在“用户为什么用你的产品”上而不是“怎么让模型跑起来”上。4.4 本地 RAG 知识库搭建Mac 上的零基础可复制方案热词里有人问“怎么在 Mac 上搭建 RAG 知识库”我给一个我自己在用的、零基础可复制的方案。这套方案全部本地运行不需要任何外部 API key适合对数据隐私有要求的场景。环境准备安装 Ollama本地模型运行工具然后拉两个模型ollama pull nomic-embed-text做 embedding和ollama pull qwen2.5:7b做生成。这两个模型加起来大概 5GBMac 16GB 内存就能跑。文档解析用unstructured库它支持 PDF、Word、HTML、Markdown 等多种格式。安装命令是pip install unstructured[all-docs]。解析的时候注意如果是扫描件 PDF需要额外装tesseract做 OCR。向量存储用 ChromaDB轻量、本地、Python 原生。安装pip install chromadb。它会把向量数据存在本地磁盘不需要额外起服务。核心代码骨架import ollama import chromadb from unstructured.partition.auto import partition # 1. 解析文档 elements partition(filenameyour_doc.pdf) texts [str(el) for el in elements if str(el).strip()] # 2. 切分 chunks [] chunk_size 512 for text in texts: for i in range(0, len(text), chunk_size - 64): chunks.append(text[i:i chunk_size]) # 3. 生成 embedding 并入库 client chromadb.PersistentClient(path./rag_db) collection client.get_or_create_collection(knowledge) for i, chunk in enumerate(chunks): emb ollama.embeddings(modelnomic-embed-text, promptchunk)[embedding] collection.add(ids[str(i)], embeddings[emb], documents[chunk]) # 4. 检索 生成 def ask(question): q_emb ollama.embeddings(modelnomic-embed-text, promptquestion)[embedding] results collection.query(query_embeddings[q_emb], n_results5) context \n\n.join(results[documents][0]) prompt f基于以下资料回答问题\n{context}\n\n问题{question} response ollama.chat(modelqwen2.5:7b, messages[{role: user, content: prompt}]) return response[message][content]这套代码跑通之后你就有了一个完全本地的 RAG 知识库。后续优化方向包括加重排序用bge-reranker本地模型、加查询改写用 LLM 做 query expansion、加多轮对话维护对话历史。每一步都可以独立迭代不会互相阻塞。5. 从 FDE 到一人公司能力迁移中的关键认知转变5.1 交付思维 vs 产品思维同一个技术两种活法FDE 做久了容易陷入一个惯性客户要什么就给什么需求边界由客户定义。但一人公司做产品没有人给你提需求你得自己判断“做什么”和“不做什么”。这个转变说起来简单做起来极难。我自己的体会是FDE 阶段培养的是“在约束下快速解决问题的能力”这个能力在一人公司同样重要但还需要补上“定义问题”的能力。具体来说FDE 面对的是“客户说想要 A我怎么实现 A”一人公司面对的是“用户有痛点 B我该用什么方案解决 B以及这个方案能不能形成可持续的产品”。这个转变意味着你不能只关注技术实现还要关注用户获取成本、付费意愿、竞争壁垒。一个技术很牛的 RAG 系统如果用户不愿意为它付费那它就不是产品只是一个项目。我在从 FDE 转向独立产品的过程中最大的教训就是花了很多时间打磨技术细节结果发现目标用户根本不愿意为这个功能付费。后来调整思路先找愿意付费的用户再根据他们的反馈做产品成功率才上来。5.2 技术选型的“够用就好”原则别让完美主义拖死产品一人公司最容易犯的错误是在技术选型上追求“最优解”。比如选 embedding 模型非要用榜单上排名第一的结果发现那个模型推理速度慢、成本高而排名第五的模型在你的场景下效果差不多成本却只有十分之一。我的原则是先用默认方案跑通闭环再根据实际瓶颈做优化。默认方案可以是embedding 用bge-small-zh快、便宜、中文效果不错LLM 用qwen2.5:7b或同级别的 API向量库用 ChromaDB重排序先不加。这套组合能覆盖大多数场景跑通之后再根据用户反馈决定优化方向。什么时候该升级当用户明确抱怨“回答不准”且你确认是检索问题时再考虑换 embedding 或加重排序。当用户抱怨“回答太慢”时再考虑换更快的模型或加缓存。不要提前优化因为你不知道真正的瓶颈在哪。5.3 数据飞轮一人公司唯一可持续的护城河一人公司做 AI 产品技术本身很难形成壁垒因为模型和工具都是公开的。真正的护城河是数据飞轮用户使用产品→产生反馈数据→数据优化检索和生成→产品体验变好→吸引更多用户。这个飞轮要转起来关键是从第一天就设计好反馈收集机制。具体来说每个回答旁边要有“有用/没用”的按钮用户点了“没用”之后最好能填一个简短的原因比如“答案不完整”“引用了错误文档”。这些反馈数据要能回流到你的检索层用来做 hard negative 挖掘和重排序模型的微调。我自己的产品里反馈数据的回流路径是这样的用户点踩→记录 query 和召回的 chunk→人工或半自动标注哪些 chunk 是相关的→用这些标注数据微调重排序模型→下一版上线后对比效果。这个循环跑上几轮检索准确率会有肉眼可见的提升。而且这个提升是竞品抄不走的因为数据是你的用户帮你积累的。5.4 从接需求到造产品我踩过的三个认知坑第一个坑是把“技术可行”当成“产品可行”。我做过一个基于 RAG 的合同审查工具技术上跑得很顺能自动提取关键条款、比对模板差异。但上线后发现法务人员根本不用因为他们不信任 AI 的审查结果宁愿自己逐条看。技术可行不等于用户愿意用这是两码事。第二个坑是低估了“最后一公里”的复杂度。从 demo 到产品中间隔着用户认证、权限管理、计费、客服、文档、合规等一系列“非技术”工作。这些工作不酷但缺一个产品就上不了线。我后来学乖了在技术方案定型后先花一周把上线所需的非技术环节列出来评估工作量再决定要不要做。第三个坑是试图服务所有人。一开始总觉得“这个功能对 A 类用户有用对 B 类用户也有用”结果做出来的东西谁都不满意。后来聚焦到一个非常具体的场景比如“帮助跨境电商卖家自动生成产品描述”反而更容易做出用户愿意付费的产品。窄才能深深才有价值。6. 落地实战中的高频问题与应对策略6.1 RAG 检索增强的常见失效模式与修复清单在实际项目中RAG 失效的表现形式很多但根因往往集中在几个地方。我整理了一份排查清单遇到问题可以按顺序过一遍。失效表现可能根因排查方法修复方向答非所问检索召回不相关打印召回的 chunk人工判断相关性换 embedding 模型、加查询改写、加重排序答案不完整chunk 切分过碎检查召回片段是否覆盖完整语义单元调整 chunk_size 和 overlap改按结构切分引用错误文档文档解析质量差对比原始文档和解析后文本换解析工具加 OCR 纠错人工清洗回答太慢上下文过长或模型太大统计每次请求的 token 数和推理时间减少召回数量换更小模型加缓存胡编乱造上下文无关或模型幻觉检查 prompt 是否明确要求“基于资料回答”加拒答机制降低 temperature加引用溯源这份清单我用了两年多基本上 80% 的问题都能定位到。关键是不要跳过排查直接改方案很多人一遇到效果不好就换模型结果换了三四个模型问题依旧因为根因在数据层。6.2 本地模型 vs 云端 API成本、延迟、合规的三方权衡这个选择没有标准答案但有一个决策框架。我通常从三个维度评估数据敏感度、调用频率、预算。如果数据极度敏感比如涉及个人隐私、商业机密必须本地部署。这时候选模型要考虑硬件约束Mac 16GB 内存跑 7B 模型比较流畅32GB 可以跑 14B再大就需要 GPU 了。本地模型的劣势是推理速度慢、效果比顶级 API 差一截但胜在数据不出本地。如果数据敏感度一般调用频率高预算有限用云端 API 更划算。按 token 计费的模式下小规模使用成本很低而且不用维护基础设施。但要注意 API 的速率限制和稳定性生产环境最好做多供应商备份。如果数据敏感度低但调用频率极高比如每天百万次可以考虑自建推理集群。但这通常是一人公司不需要考虑的规模等到了那个量级再说。我自己的做法是混合敏感数据用本地模型处理非敏感数据用云端 API。这样既保证了合规又控制了成本。6.3 知识库更新与版本管理别让过期信息污染检索结果知识库不是建一次就完事的它会不断更新。如果更新机制没设计好旧版本的内容和新版本混在一起检索结果就会自相矛盾。我见过一个案例产品手册更新了三版但知识库里三版内容都在用户问“怎么操作”系统召回了旧版步骤导致用户操作失败。我的做法是给每个 chunk 加版本元数据doc_id、version、effective_date、statusactive/archived。检索时默认只搜statusactive的 chunk。当文档更新时旧版本标记为 archived新版本入库。这样既保留了历史记录又不会污染当前检索。另外对于时效性强的知识比如价格、政策要在 chunk 里显式标注有效期检索时根据当前日期过滤。这个逻辑不复杂但能避免很多“AI 给了过期信息”的尴尬。6.4 用户反馈闭环怎么把“点踩”变成检索优化的燃料反馈闭环的设计核心是降低用户反馈成本。如果用户点踩之后要填一个长表单没人会填。我的做法是点踩后弹三个选项——“答案不完整”“引用了错误资料”“答非所问”用户点一下就行。这三个选项分别对应不同的优化方向不完整→调整切分或增加召回数量引用错误→优化解析或重排序答非所问→优化查询改写或 embedding。收集到反馈后每周做一次分析把点踩的 query 和对应的召回 chunk 拉出来人工判断哪些 chunk 是真正相关的。这些标注数据积累到几百条就可以用来微调重排序模型了。微调后的模型上线对比下一周的点赞率通常能看到 5-10 个百分点的提升。这个循环跑起来产品体验会持续变好而且竞品很难复制因为数据是你的用户帮你积累的。7. 一些关于工具链和长期路线的个人体会工具链这块我的建议是保持简单按需引入。起步阶段一个 Ollama ChromaDB Streamlit 就能跑通完整闭环。等遇到具体瓶颈了再针对性引入新工具解析质量不行就换 unstructured 或加 OCR检索不准就加 bge-reranker生成质量不够就换更大的模型或加 few-shot 示例。不要一开始就搭一个复杂的多组件架构维护成本会压垮你。关于长期路线我越来越觉得 FDE 和一人公司这两个方向会逐渐融合。FDE 积累的是“在真实场景中快速落地 AI 产品”的能力这个能力在一个人做产品时同样核心。而一人公司培养的“定义问题、验证价值、持续迭代”的思维反过来也会让 FDE 在客户现场更有判断力知道什么该做、什么不该做、什么先做。如果你现在正在 FDE 岗位上我建议你在交付之余抽时间把自己的工具链和提示词模板沉淀下来这些是你未来做独立产品的资产。如果你已经在做一人公司我建议你保持对 FDE 场景的关注因为那里有最真实的用户痛点和最直接的付费意愿。两条路不是非此即彼而是可以互相滋养的。最后分享一个我一直在用的小技巧每做完一个项目花半小时写一份“决策日志”记录当时为什么选这个方案、放弃了哪些备选、后来验证结果如何。这份日志在下一个项目遇到类似问题时能帮你省下大量重新调研的时间。而且写着写着你会发现很多所谓的“技术选型”本质上是对用户需求的理解深度问题。理解到位了选型自然就清晰了。
