AI 交流论坛

如果你是开发者，想从零开始做 AI 应用，我建议不要从“训练模型”开始。 更实际的路线是： 第一步，调通模型 API。理解 token、上下文、流式输出、错误处理和费用。做一个最简单的命令行问答就行。 第二步，练 Prompt。不是背咒语，而是学会把任务、上下文、约束、输出格式说清楚。 第三步，做 RAG。拿自己的文档做一个问答工具，理解切分、embedding、检索、引用来源。 第四步，再碰 Agent。让模型调用一两个工具，观察它什么时候会乱来，怎么加限制。 第五步，补工程化：日志、评测、成本控制、权限、失败重试、人工审核。 微调放最后。大多数应用用好现成模型、RAG 和工具调用就够了，不需要一开始就训练自己的模型。 学习时最好每一步都有小项目。只看教程很容易觉得懂了，真接 API、真处理报错、真算成本，才会知道坑在哪。

给刚入门的 AI 开发者一份工具清单。我不追求全，先按用途分，能跑通一条链路就行。 写代码： GitHub Copilot：轻量补全 Cursor：编辑器里改代码很顺手 Claude Code / Codex：更适合让 AI 读项目、改多文件、跑任务 做 Prompt 和 Agent： Dify：适合先搭工作流 LangChain / LlamaIndex：适合更工程化地组织链路 MCP：适合给 AI 接工具，但要注意权限 做 RAG： pgvector：小团队、简单项目可以先用 Milvus：数据量和性能要求上来后再考虑 embedding 模型：一定要拿中文资料实测 模型 API： OpenAI、Claude、Gemini 可以做能力对比 DeepSeek、Qwen、Kimi 更适合国内可获得性和成本优先的场景 我的建议是别收藏一百个工具。先选一个编程工具、一个模型 API、一个 RAG 框架，做出一个能问自己文档的小项目。跑通之后，你自然知道下一步缺什么。

看一个开源 AI 项目，我不建议先看 star 数。star 只能说明它被关注过，不能说明你能不能用。 我会按这个顺序拆： 它解决什么问题？一句话能不能说清 最近还维护吗？看 commit、issue、release 文档能不能跑通？不要只看 README 漂亮 核心抽象是什么？比如 Agent、工具、检索、工作流怎么组织 适合二开吗？插件、配置、接口是否清楚 许可证能不能商用 如果是 RAG/Agent 类框架，我还会特别看失败处理。比如工具调用失败怎么办、检索为空怎么办、模型输出格式错了怎么办。这些地方比 demo 更能看出项目成熟度。 真正值得学习的开源项目，不只是“能跑”，而是它在复杂场景里怎么划边界、怎么处理错误、怎么组织扩展点。 大家如果看到不错的开源 AI 项目，也欢迎发到这个板块。最好不只贴链接，顺手写两句你觉得它好在哪里。

企业知识库 RAG 落地，我看到最多的坑不是技术新不新，而是基础工作没做好。 第一个坑：资料没人整理。过期制度、重复文档、不同版本混在一起，模型检索到什么都可能错。 第二个坑：权限没想清楚。不是所有员工都该看到所有文档，RAG 如果忽略权限，会很危险。 第三个坑：只看回答，不看引用。没有引用来源，用户很难信任答案，也很难纠错。 第四个坑：没有评测集。上线前不准备一批真实问题，就不知道系统到底能不能用。 第五个坑：没人维护。知识库不是一次性工程，文档更新、索引重建、错误反馈都要有人管。 我的建议是先选一个窄场景，比如客服内部知识库、HR 制度问答、产品 FAQ。场景越窄，越容易把质量做出来。 RAG 真正的难点是把知识管理、权限、评测和运营串起来。只搭一个技术 demo，离可用还差一截。

向量库怎么选，先别急着追最强。问自己三个问题就够了： 数据量多大？查询量多大？团队会不会运维？ 如果只是小项目、内部工具、数据量不大，pgvector 很香。它和 PostgreSQL 在一起，部署简单，团队也容易理解。 如果数据量更大、检索性能要求高、后面要做更复杂的向量检索，Milvus 这类专门向量库更合适，但运维成本也会上来。 如果团队人少，不想自己管服务，可以先用托管方案。贵一点，但省时间，尤其适合验证产品。 我不建议一开始就把架构做得很重。很多 RAG 项目真正卡住的不是向量库性能，而是文档质量、切分策略、embedding 选择和评测方法。 先用最简单的方案跑通，再根据瓶颈升级。不要为了一个还没验证的知识库，上来就背一套复杂运维。

文档切分没有一个永远正确的大小。chunk 太大，检索回来一堆噪声；chunk 太小，上下文又断掉。 我一般先看文档类型： FAQ：可以按问答对切 产品文档：按小节切 合同/制度：按条款切 技术文档：按标题层级切 代码说明：按模块或函数关系切 不要一上来就拍脑袋设 500 字或 1000 字。更好的办法是拿真实问题测试：用户问一个问题，检索出来的前三个片段里有没有答案？如果没有，先调切分和检索，而不是急着换模型。 还有个细节很重要：保留标题路径。比如“产品手册 > 计费 > 退款规则”。模型看到这条路径，会比只看到正文更容易理解片段位置。 我的经验是，RAG 项目里很多效果问题都不是生成问题，而是切分和检索问题。别把锅都丢给大模型。

RAG 这个词听起来复杂，其实可以先理解成一句话：让模型回答前，先从你的资料里找相关内容，再带着这些内容回答。 一个最小 RAG 流程大概是： 上传文档 → 切分成小块 → 做向量化 → 用户提问 → 检索相关片段 → 交给模型生成答案 它解决的不是“让模型变聪明”，而是让模型有机会基于你的私有资料回答。比如公司制度、产品文档、客服知识库、项目手册，都适合尝试。 但 RAG 也不是万能。文档质量差、切分乱、检索不准、权限没管好，都会让结果变差。 我建议新手先做一个很小的版本：只放 20 篇文档，只支持问答，不做复杂权限，不做多轮记忆。先看检索出来的片段对不对。检索不对，后面生成再漂亮也没用。 RAG 的第一优先级不是模型，而是资料整理和检索质量。这个顺序别反。