传统数仓、数据库和分析系统，为业务提供了稳定的数据支持和决策依据。但当数据开始面对 LLM 时，就产生了一个全新的挑战：如何将企业数据转化为模型可感知、可检索、可执行的“上下文”。在企业 AI 系统中，这一过程通常经历三个关键环节：1. 数仓与数据库：提供干净、统一、结构化的业务数据。2. 搜索与 RAG：让模型能够快速、稳定地访问相关信息。3. 工作流与 Agent：将数据能力编排成可执行的任务，实现复杂业务的闭环。图中展示了这一链路的概览。通过这条链路，可以发现数据不再只是“给人看的”，而是成为 AI 执行的核心驱动力。一、从数仓到 LLM：数据“服务对象”的变化在之前的文章中（微信公众号...

1. 做自我介绍，并确认两个项目是个人独立开发还是学校项目？2. 从产品视角说明旅行规划助手项目的定位、能力、技术方案及需求解决办法？3. 追问1：旅行规划助手项目是否经过体验，效果如何，存在哪些问题及后续改进方向？4. 追问2：以“深圳玩三天预算3500元”为例，智能体能否满足需求，如何控制价格及响应时间？5. 知识库答疑助手项目是否为比赛，介绍技术方案（如RAG、混合检索、微调等）？6. 追问1：知识库答疑助手项目微调数据集的设计方法及测试集情况？7. 追问2：知识库答疑助手项目最终准确率及采用混合检索的原因？8. 追问3：知识库答疑助手项目向量模型和微调模型的选择依据及部署方案？9. 是否使用过多模态处理方式，图片识别的准确性及实现方法？10. 追问1：是否使用过Coze、Dify、N8N等低代码平台及使用程度？11. 确认实习时间（一周5天、持续6个月、1月初到岗的具体日期）？反问1：具体产品实习生进去负责哪个模块答：智能体 Demo 搭建、测试打标反问2：车载主要是负责端侧还是云端答：团队主要是负责云端，不涉及端侧

vivo好像也开了，字节是真开了，其他的这个月也会开始开的吧

有一次我对 AI 提了一个离谱到自己都觉得好笑的 Java 需求：“帮我写一个程序，自动找出所有内存泄漏、生成修复补丁，并直接提交到 Git。”这需求看起来像“自动化神器”，但本质是想让 AI 变成一个会理解业务、会分析代码、会操作版本库的全能工程师。更离谱的是我还加了一句：“顺便统一项目所有日志格式、处理所有异常，并回滚到上一版本。”AI 当然给了我一套很完整的方案，但我知道真正落地会非常复杂，也很可能把项目搞崩。后来我才明白，离谱的需求可以问，但别指望 AI 代替工程师做所有决定。