AI 信息太多了，我现在反而不建议关注太多来源。
我的做法是分三层：
第一层看官方。模型能力、价格、API 变化、废弃通知，尽量回到官方博客和文档。二手消息可以提醒你，但不要当最终依据。
第二层看少量高质量作者。不是每天转新闻那种，而是能讲清楚为什么重要、适合谁、有什么限制的人。
第三层看社区讨论。社区的价值不只是新闻，而是真实使用者会讲失败、吐槽、替代方案和坑。
我还会定期清理信息源。一个账号关注了一个月，如果只制造焦虑，没有帮我做出更好判断，就取消。
还有个很朴素的标准：输入要变成输出。看到一个新工具，最好能写一段笔记、做一次小测试、发一个讨论，而不是只收藏。
跟上 AI 不靠刷得多，靠筛得准。信息源越多，越需要自己的判断框架。
如果你是开发者，想从零开始做 AI 应用，我建议不要从“训练模型”开始。
更实际的路线是：
第一步，调通模型 API。理解 token、上下文、流式输出、错误处理和费用。做一个最简单的命令行问答就行。
第二步，练 Prompt。不是背咒语，而是学会把任务、上下文、约束、输出格式说清楚。
第三步，做 RAG。拿自己的文档做一个问答工具，理解切分、embedding、检索、引用来源。
第四步，再碰 Agent。让模型调用一两个工具，观察它什么时候会乱来，怎么加限制。
第五步，补工程化：日志、评测、成本控制、权限、失败重试、人工审核。
微调放最后。大多数应用用好现成模型、RAG 和工具调用就够了，不需要一开始就训练自己的模型。
学习时最好每一步都有小项目。只看教程很容易觉得懂了，真接 API、真处理报错、真算成本，才会知道坑在哪。
给刚入门的 AI 开发者一份工具清单。我不追求全，先按用途分，能跑通一条链路就行。
写代码：
做 Prompt 和 Agent：
做 RAG：
模型 API：
我的建议是别收藏一百个工具。先选一个编程工具、一个模型 API、一个 RAG 框架，做出一个能问自己文档的小项目。跑通之后，你自然知道下一步缺什么。
独立开发者用 AI 做 SaaS，最容易高估的是“开发速度”，最容易低估的是“卖出去”。
AI 现在确实能让一个人更快做出原型：前端、后端、文案、客服、数据分析都能帮忙。但产品不是代码仓库，做出来只是第一步。
我觉得现实经验有几条：
还有一点，独立开发者最适合用 AI 做“运营放大”：写文档、整理案例、生成客服草稿、分析反馈。这些不一定酷，但很有用。
如果你正在做 AI SaaS，我建议先写清楚一句话：谁在什么场景下，为什么愿意为它付钱。这个问题比选哪个模型更难，也更重要。
这是一个产品复盘模板，但我希望它不像模板那么死。
复盘一个 AI 小工具时，我会先问：它到底替用户省了什么？
不是“用了 AI”，也不是“接了某个模型”，而是用户原来要花 30 分钟做的事，现在是不是 5 分钟能做完？原来容易出错的地方，现在是不是更稳？
我会记录这些东西：
很多 AI 产品的问题是 demo 很亮，但没有形成习惯。用户试完觉得“挺酷”，然后就忘了。
所以我现在更看重留存和复用，而不是第一次体验的惊艳。AI 小工具要活下来，最后靠的是稳定解决一个具体问题。
看一个开源 AI 项目，我不建议先看 star 数。star 只能说明它被关注过，不能说明你能不能用。
我会按这个顺序拆：
如果是 RAG/Agent 类框架，我还会特别看失败处理。比如工具调用失败怎么办、检索为空怎么办、模型输出格式错了怎么办。这些地方比 demo 更能看出项目成熟度。
真正值得学习的开源项目，不只是“能跑”，而是它在复杂场景里怎么划边界、怎么处理错误、怎么组织扩展点。
大家如果看到不错的开源 AI 项目，也欢迎发到这个板块。最好不只贴链接，顺手写两句你觉得它好在哪里。
企业知识库 RAG 落地，我看到最多的坑不是技术新不新，而是基础工作没做好。
第一个坑：资料没人整理。过期制度、重复文档、不同版本混在一起，模型检索到什么都可能错。
第二个坑：权限没想清楚。不是所有员工都该看到所有文档，RAG 如果忽略权限，会很危险。
第三个坑：只看回答，不看引用。没有引用来源，用户很难信任答案，也很难纠错。
第四个坑：没有评测集。上线前不准备一批真实问题，就不知道系统到底能不能用。
第五个坑：没人维护。知识库不是一次性工程，文档更新、索引重建、错误反馈都要有人管。
我的建议是先选一个窄场景，比如客服内部知识库、HR 制度问答、产品 FAQ。场景越窄，越容易把质量做出来。
RAG 真正的难点是把知识管理、权限、评测和运营串起来。只搭一个技术 demo，离可用还差一截。
向量库怎么选，先别急着追最强。问自己三个问题就够了：
数据量多大？查询量多大？团队会不会运维？
如果只是小项目、内部工具、数据量不大，pgvector 很香。它和 PostgreSQL 在一起，部署简单，团队也容易理解。
如果数据量更大、检索性能要求高、后面要做更复杂的向量检索，Milvus 这类专门向量库更合适，但运维成本也会上来。
如果团队人少，不想自己管服务，可以先用托管方案。贵一点，但省时间，尤其适合验证产品。
我不建议一开始就把架构做得很重。很多 RAG 项目真正卡住的不是向量库性能，而是文档质量、切分策略、embedding 选择和评测方法。
先用最简单的方案跑通，再根据瓶颈升级。不要为了一个还没验证的知识库，上来就背一套复杂运维。
文档切分没有一个永远正确的大小。chunk 太大，检索回来一堆噪声；chunk 太小，上下文又断掉。
我一般先看文档类型：
不要一上来就拍脑袋设 500 字或 1000 字。更好的办法是拿真实问题测试：用户问一个问题，检索出来的前三个片段里有没有答案？如果没有，先调切分和检索，而不是急着换模型。
还有个细节很重要：保留标题路径。比如“产品手册 > 计费 > 退款规则”。模型看到这条路径，会比只看到正文更容易理解片段位置。
我的经验是，RAG 项目里很多效果问题都不是生成问题，而是切分和检索问题。别把锅都丢给大模型。
RAG 这个词听起来复杂，其实可以先理解成一句话：让模型回答前，先从你的资料里找相关内容，再带着这些内容回答。
一个最小 RAG 流程大概是：
上传文档 → 切分成小块 → 做向量化 → 用户提问 → 检索相关片段 → 交给模型生成答案
它解决的不是“让模型变聪明”，而是让模型有机会基于你的私有资料回答。比如公司制度、产品文档、客服知识库、项目手册，都适合尝试。
但 RAG 也不是万能。文档质量差、切分乱、检索不准、权限没管好，都会让结果变差。
我建议新手先做一个很小的版本：只放 20 篇文档，只支持问答，不做复杂权限，不做多轮记忆。先看检索出来的片段对不对。检索不对，后面生成再漂亮也没用。
RAG 的第一优先级不是模型，而是资料整理和检索质量。这个顺序别反。
给团队选主力模型，我会把它当成工程决策，而不是信仰选择。
我通常会看五件事：
主力模型也不一定只能有一个。很多团队更适合“一个默认模型 + 一个强模型兜底 + 一个便宜模型处理简单任务”。
比如普通摘要走便宜模型，复杂分析走强模型，敏感数据走可控环境里的模型。这样比全站统一一个模型更灵活。
做决策前，最好先收集 20-50 个真实样本。不要用网上随便找的 prompt 测，因为那测不出你自己的业务问题。
模型会变，评测集要留下。以后换模型、降成本、做路由，都靠这套样本说话。
多模态这块现在很热，但落到产品里要分开看：图像、视频、语音不是一回事。
图像理解已经比较实用，比如识别截图、读图表、看 UI、分析商品图。很多办公和客服场景可以直接用起来。
图像生成也成熟不少，但商业使用要注意版权、品牌一致性和可控性。生成一张好看的图不难，稳定生成符合品牌规范的图才难。
视频生成还在快速变化，适合创意探索、短片草稿、分镜尝试，但如果你要求严格一致的人物、动作和镜头，仍然要谨慎。
语音方向我反而觉得更容易先落地：转写、总结会议、语音客服、口语练习，这些需求明确，也容易评估效果。
我的建议是别笼统地说“我们要做多模态”。先说清楚你要处理哪种输入、输出要到什么质量、失败成本有多高。
多模态不是炫技，它最后还是要回到具体流程里节省时间或提高质量。
DeepSeek、Qwen、Kimi 在国内场景里经常被放在一起比较，但我觉得它们更像不同取向的选择。
DeepSeek 的优势是技术圈讨论多，性价比和推理能力经常被拿来测试，适合开发者先做原型和评测。
Qwen 的优势是生态和部署选择，尤其你在阿里云或企业内部场景里，会比较容易找到配套方案。
Kimi 给很多人的印象是长文本和中文阅读体验不错，适合资料整理、阅读、办公类任务先试。
但别只凭印象选。国内项目还要考虑：
我建议每个团队都留一套自己的中文任务评测集。比如客服问答、合同条款、代码解释、产品文案、知识库问答各放几个样本。用真实任务测，比看别人的榜单更靠谱。
长上下文听起来像万能解法，但实际用下来，它的问题也很明显：能塞进去，不等于模型真的会用好。
常见翻车点有几个：
所以长上下文任务里，我不建议直接把几十页材料扔进去让模型“总结一下”。更好的做法是先让它建立目录感：
如果是企业知识库，长上下文也不一定替代 RAG。长上下文适合一次性读材料，RAG 适合长期、可更新、可检索的知识系统。
我的判断是：长上下文提高了上限，但没有取消信息组织能力。材料越长，越需要你帮模型建立路标。
模型性价比不是“单价低”这么简单。
我更愿意这么算：
真实成本 = token 单价 × 实际输入输出量 × 重试次数 + 人工返工成本
便宜模型如果经常答偏，最后可能更贵。贵模型如果一次做对，反而省钱。
几个容易被忽略的地方：
比较稳的做法是分级路由：简单分类、格式转换、短摘要用便宜模型；复杂推理、代码审查、关键文案再用强模型。
还有一个省钱办法：整理上下文。很多成本不是模型贵，是你每次都把一堆无关内容塞进去。
所以不要只看价格表。拿你的真实任务跑一轮，算“完成一个合格结果”的成本，这个数字才有意义。
OpenAI、Claude、Gemini、DeepSeek、Qwen 怎么选？我现在不会直接问“哪个最好”，而是先问任务。
如果是复杂文档、代码理解、长推理，我会把 Claude 放进候选。
如果是生态、工具调用、第三方集成、产品化接口，OpenAI 仍然很强。
如果你重度依赖 Google 生态，或者任务里多模态和长上下文很多，Gemini 值得测。
如果你在国内做产品，DeepSeek、Qwen 这类模型的可获得性、成本、中文体验和部署选择都很现实。
真正要定主力模型时，我建议做一个小盲测：拿你团队最常见的 20 个任务，统一 Prompt，隐藏模型名，让实际使用的人打分。质量、速度、成本、稳定性、合规要求一起看。
不要只看榜单。榜单解决的是通用能力排序，项目里需要的是“在你的任务上少出错”。这两个不是一回事。
官方文档入口可以从 OpenAI、Anthropic、Google AI、DeepSeek、阿里云百炼分别看起，价格和能力以官方最新信息为准。
多步 Agent 最容易失败的地方，往往不是模型完全不会，而是中间某一步偏了，后面还继续认真执行。
我见过比较多的是这几种：
防法也不复杂，但要提前设计：
Agent 不是越自主越好。很多业务场景里，“半自动 + 人确认”比“全自动”更靠谱。
如果你们的 Agent 已经上线，我建议先把失败案例收集起来。真实失败样本比漂亮 demo 更值钱，它会告诉你系统到底哪里脆。
判断一个 Agent 好不好用，不能只看 demo。Demo 里跑通一次不难，难的是连续跑 100 次还能稳定。
我会看这几个指标：
很多 Agent 看起来聪明，其实只是“偶尔很惊艳”。但产品里需要的是稳定，不是抽奖。
我比较喜欢给 Agent 做一组固定评测集，比如 20 个真实任务，每次改 Prompt、换模型、换工具后都跑一遍。不要凭感觉判断“好像变聪明了”，要看数据。
还有一点很重要：评测不要只看最终答案。中间步骤也要看。一个答案对了但过程乱来的 Agent，迟早会在更复杂的任务里出问题。
我第一次接 MCP 时，没有做复杂系统，只做了一个很小的本地工作流：让 AI 读取项目里的几个说明文件，然后根据固定规则生成一份检查清单。
这个练习的好处是边界清楚：
跑通之后，你会更容易理解 MCP 的价值：模型不再只靠聊天上下文，它可以通过工具拿到更接近真实环境的信息。
但这里也有个坑。工具一多，模型会变得“很忙”，不一定更准。它可能反复查无关文件，也可能在权限不清楚时做多余动作。所以我觉得 MCP 的第一课不是“怎么接更多工具”，而是“怎么限制工具”。
我的建议是：先做只读，再做可写；先做单工具，再做多工具；先给测试环境，再碰生产环境。
如果你已经接过 MCP，最想听你们分享的是权限怎么做，而不是 server 数量有多少。
MCP 可以先不用理解得太玄。你可以把它看成：让 AI 更标准地连接外部工具的一套协议。
以前每个工具都要单独接一遍：文件系统怎么读、数据库怎么查、浏览器怎么控、内部 API 怎么调，各家方式不一样。MCP 想解决的是“工具接入标准化”。
它真正有价值的地方在这几个场景：
但我不建议新手一开始就堆很多 MCP Server。先接一个最小工具，比如只读文件、查一个接口、跑一个固定命令。确认权限边界和日志都清楚，再扩展。
尤其是企业场景，MCP 的重点不是“能不能调工具”，而是“谁能调、能调什么、调用记录在哪里、出错怎么追”。这些没想清楚，接得越多风险越大。
官方入口可以看 Anthropic 的 MCP 文档，先从概念和一个简单 server 开始就够了。