封面可以不用管，博主玩鸣潮的，随便找的图片。

先交代一下写这些的原因

大四了。

其实大一就开始接触kimi和deepseek了，不过当时的原因比较荒唐，因为那个时候kimi和deepseek网页版登录是可以通过游客方式直接访问的，上课有什么问题直接问就行了，以至于大学前三年基本没留下什么记录，博客空着，GitHub 也是空的。临到要找实习，翻自己的经历，发现能写下来的东西很少，不是没做过事，是做完就忘了，也没留证据。

所以最近开始逼自己写。这篇算是第一篇杂谈，谈的不是技术细节，是踩过的坑和想了很久才想明白的几件事。写给刚开始学大数据、刚开始拿大模型写代码的人，也写给以后还在坚持学习大数据的的自己。

一、越早接触越好，但别拿它作弊

大数据和 AI 这个方向，早点上手确实有优势。一方面是工具更新太快，早接触意味着你有更多时间试错；另一方面，这东西是练出来的，不是背出来的，越早开始，积累的"手感"越多。

但有两件事最好别做。

第一件是拿它作弊。作业、课程设计、考试，一键生成很爽，代价是你跳过了唯一能训练自己的环节。等到面试官问"你这个功能为什么这么设计"，你能背出的只有别人给你的答案，稍微追问一句就断线。作弊最贵的地方不在于被抓，而在于你骗过了自己，以为自己会了。

第二件是拿它套一个"能跑就行"的系统。让模型从零生成一个带登录、带增删改查的小系统，一周能跑起来。但里面的表结构是它拍的，权限是它糊的，异常处理是它省掉的。这种项目在简历上是负资产，因为任何一个懂行的人问三个问题就能看出深浅：数据量上来之后怎么办、越权怎么拦、并发怎么处理。说不出，就露底了。

二、模型是你的四肢，脑子得是自己的

这句话我想了很久才敢写下来：大模型的发挥水平，取决于使用者的知识水平。

如果把这个关系讲得直白一点——大模型是你以后行动的四肢，你本人的逻辑思维是大脑。身体能跑多远，很多时候不是身体的问题，是大脑的问题。

同一个问题丢给两个人，同一个模型，产出质量能差出好几倍。差别不在提示词写得多花哨，在于提问的人知不知道自己想要什么、知不知道自己不知道什么。

举两个真实的例子。

例子一：异步代码里的 await。

用模型写 FastAPI 接口时，它给出的查询代码是这样的：

result = db.execute(select(Student).where(Student.sno == sno))

看着能跑，实际一调就报 MissingGreenlet。原因是 SQLAlchemy 的异步 Session 必须 await，而这行少了 await。更要命的是，报错信息完全没提 await，只说 greenlet 相关的一堆东西。

如果你不知道"异步驱动下，查询是一次协程调用"，你只能把这行代码贴回给模型，让它猜。它可能会修对，也可能再给你一段同样缺 await 的代码，来回几轮，人已经烦了。

如果你知道这件事，一眼就能看出问题：这是 await 漏了，不是 SQL 写错了。改一行就完事。

例子二：让模型做检索，效果一直不好。

一开始让模型自己决定怎么切片、怎么召回。结果问答质量忽高忽低，有时候明明文档里有答案，它答"没有找到"。

后来自己去读了 embedding 的基本原理才明白：切片太大，一段里塞了三四个主题，向量被平均掉，召回的相似度就没意义了；切片太小，上下文被切断，模型拿到半句话也答不出。最后定成按段落切、控制在几百字、保留上一段的标题，效果才稳下来。

这件事模型帮不了你，它不知道你的文档长什么样，也不知道你的问题有多具体。你得知道自己不知道什么，才能给模型提出对的问题。

补一句：这不意味着什么事都要先学原理再动手。顺序应该是——先用，用出问题，带着问题回去补原理，补完再回来改。反过来，先啃三个月理论再动手，多半会放弃。

三、学习路径：一条走得通的顺序

大数据这个词太大了，这里只谈"用大模型做应用"这条线。顺序大致是这样，每一步都别跳：

第一步，Python。 别一上来就学框架。函数、类、字典、列表推导、异常处理要熟；然后是虚拟环境（venv 或 conda）、包管理、命令行；再然后是异步，async / await 这一套必须过一遍，不然写 FastAPI 只会照抄。

第二步，Transformer。 不要求手推注意力公式，但要搞清楚几件事：token 是什么、上下文窗口为什么有限、为什么模型会"忘事"、temperature 在调什么。这些概念直接决定你后面所有的参数怎么设。

第三步，LangChain。 消息格式（system / user / assistant）、Prompt 模板、Tool 的定义方式。这一层是"怎么跟模型说话"，也是坑最多的一层，参数校验、返回值格式、多轮流式输出都在这里。

第四步，LangGraph。 状态图、节点、边、检查点。到这一步才开始处理"流程"：模型调错工具怎么办、要不要人工确认、中断之后能不能续跑。写复杂一点的 Agent，最后都会走到这里。

第五步，Agent 开发。 工具怎么设计（返回结构统一、失败要有明确信号）、权限怎么隔离（不该让模型看见的工具就别注册）、错误怎么兜底（模型抽错参数时谁来纠正）。

第六步，多 Agent 协作。 分工、交接、谁负责汇总。这一层容易做得很花哨但没用，建议等前面几步真的碰到瓶颈再上。

当然上述写的六步肯定还有遗漏，还是希望你们可以根据自身的情况去判断，我这里说的话你当成一个建议就行。

四、用 AI 写代码，最要紧的是"看得懂"

这条是重点，单独说。

现在 AI 写代码的能力确实强，一个下午甚至是一个小时就可以能产出你一周的量。但有个前提：你得看得懂它在写什么。

不是"跑起来没报错"就叫看得懂。是别人指着一段代码问你"这段在干什么""为什么这么写""换成另一种写法会怎样"，你能答上来。答不上来，这段代码对你就是黑盒，出问题的时候你连从哪查都不知道。

我见过也踩过这种坑：功能都好好的，某天报了一个奇怪的错，翻代码发现是自己没细看的一段，注释还是模型自动生成的那种空话。那一瞬间是很慌的，因为整个项目里有一半的东西你其实不熟。

几个具体的做法，讲出来不算高明但管用：

让模型写完一段，自己再复述一遍它的逻辑，能讲顺了才算过；讲不顺的地方，就是没懂的地方，让它解释，或者自己查；偶尔故意删掉一行、改一个参数，看报什么错，用报错反推这段代码的依赖关系；重要的那几十行，自己重写一遍，哪怕最后换回模型的版本。

还有一层：正因为 AI 写代码太强，它的创造性反而被浪费了。 大部分人只让它补全和修 bug，把它当高级自动补全用。其实更值钱的用法是让它一次给你三个不同方案，或者让它扮演面试官来质疑你的设计，或者让它找你的方案漏洞。这些是"用它扩脑"，不是"用它代手"。

五、选哪个模型：别在这上面纠结

如果不是参与特别前沿的模型开发，日常写代码、做应用，DeepSeek 完全够用。便宜、够快、中文理解好，工具调用也稳。

但别只用过一个。Claude、GPT、Codex 这些都可以大胆试，试完按自己的习惯用就行——有人在长上下文和代码重构上更信 Claude，有人习惯 GPT 的插件生态，也有人就喜欢 DeepSeek 的直给。没有标准答案，只有顺手不顺手。

至于 Claude，有办法的话总能用得到，这事不用展开。

真正要提醒的是：别把时间花在"哪个模型更强"的比较上。 模型三个月一换代，你今天背下来的结论，毕业时早就作废了。花在原理和项目上的时间不会作废。

六、最后

写了这么多，其实核心就三句话：

早点开始，别作弊；模型是四肢，脑子得自己长；写出来的每一行代码，都要能讲清楚它在干什么。

这篇杂谈既是给刚入门的人看的，也是写给几个月后的自己。等实习开始，回头再看这些话，希望能确认自己没走偏，而不是发现自己当年只是说说。

如果这篇能让某一个刚入门的人少踩一个坑，那它就值得写下来。