我是广东工业大学计算机科学与技术专业的黄国轩，目前大三。我的目标是 AI Agent（智能体）应用开发。相比研究模型本身，我更着迷于“用大模型能力解决现实问题”——给模型接上工具、记忆和知识库，让它能真正替人完成一件事。大二下学期开始，我系统学习了 Python、LangChain、LangGraph 与 RAG（检索增强生成）相关技术。

以前我只刷别人的技术博客，轮到自己动手才发现，写博客远没有想象中容易。这周我做了三件事：注册博客园账号；研究 Markdown 的标题、列表、表格和代码块语法；试着把一段 Python 代码按规范贴进编辑器。我还立了一条规矩：凡是参考过的文章、代码，一律在文末或段后注明出处，避免将来自己都分不清哪些是原创、哪些是搬运。

这个过程非常花时间——一段两分钟能讲完的话，写成文字可能要二十分钟；一个“好像理解了”的知识点，落成文档后常常发现自己其实没理解。但我认同课程里的一句话：写博客的收益不在写的那一刻，而在坚持一段时间之后回头看，能看到自己走过的弯路。我给自己的目标是每周至少一篇，本学期累计 16 篇，学期末再回来读这篇开篇随笔，看看自己有没有“打脸”。

我的技术现状可以概括为：方向明确（Agent/大模型应用开发），能跑通不少 demo，但工程经验不足。当前积累主要有 Python 程序设计、大模型 API 与提示词工程、RAG（Embedding、向量检索、知识库）、LangChain/LangGraph 智能体工作流编排，以及软件工程基础知识。我最大的优势是目标比较明确、愿意投入大量时间做技术积累，并且已经通过持续写代码形成了自己的编程习惯；最大的短板是缺少大型项目经验，对系统架构、评测、部署和运维等工程环节的认识还停留在概念层面，而这门课正好补我的短板。

进入大学后，我先后学过HTML、Javascript、Typescript，体会到“把页面做出来”的快乐；但真正让我确定方向的，是大二下学期第一次用大模型 API 做出一个小工具：给模型一段文档、一个工具和一句指令，它就能自己拆解任务并执行。那一刻我突然意识到，软件的下一个阶段可能是“模型理解意图、工具负责执行”的智能体应用。

从那以后，我利用课余时间系统自学了 Python、LangChain、LangGraph 和 RAG：用向量数据库给模型接上自己的知识库，用 LangGraph 把“计划—调用工具—反思”画成有状态的工作流，用 LangChain 封装各类模型和工具调用。我越来越确信自己想做的是“让大模型真正落地”的 Agent 应用开发。不过，从“会调 API、会跑通 demo”到“合格的 IT 专业毕业生”，我还有四块明显短板：

1. 缺少大型项目经验：目前做的多是原型和小工具，没有经历过真实规模的代码协作与长期维护；
2. 对系统架构理解不足：知道 RAG 的链路长什么样，但说不清缓存、重试、降级、并发这些生产问题；
3. Agent 工程化经验太少：模型输出不稳定、效果如何评测、调用成本怎么控制、出错了如何兜底，这些我几乎没有真实处理过；
4. 团队协作经验不足：还没在多人共享代码库、互相 review 的环境里工作过。

对照技能调查表，我选取了对自己最重要的 7 项技能。水平分采用 0–9 制（5 分代表能通过面试，9 分代表世界一流）。

除了上表列出的手段，我给自己定了五条必须执行的学习策略：

1. 以 Agent 项目为主线：本学期完成一个“从需求到部署”的 RAG 问答/智能体个人项目和一次完整的团队项目，不做没有交付物的学习；
2. 先设计后编码：任何超过 200 行的任务，先写需求、模块划分和状态流转图，再动手写代码，不允许“上来就调 API”；
3. 把测试和评测当成作业：大模型输出不稳定，必须给核心链路建立小规模评测集和回归用例，不允许只靠肉眼点几次就说“能用”；
4. 输出倒逼输入：每周一篇技术博客，记录一个知识点、一个 bad case 或一次失败调试；
5. 主动获取反馈：代码请同学 review，疑问带着“我已尝试过什么、复现步骤是什么”去问老师和助教。

看视频、听讲解只能让人“看懂”，不能让人“会打”。我以前自学 LangChain 时就有过这样的经历——跟着官方文档把 demo 跑通，觉得全都会了，可一换成自己的业务场景，提示词稍微一变效果就崩，我根本不知道问题出在提示词、检索还是代码上。上课的意义就在于它是有反馈的练习：老师提问会逼我当场组织思路，作业 deadline 会逼我动手，同学的错误和提问会帮我发现盲区。更重要的，课堂把零散的知识串成一条线：我在教程里只学会“怎么搭一条 RAG 链路”，在课堂上才有机会理解“为什么需求要这样分析、模块要这样划分、质量要这样保障”。所以我决定认真参与，把每次提问和每次作业反馈都当成免费的“教练纠错”。

大学两年多，我体验到的师生关系大多是“老师台上讲、学生台下记”，课后交流主要靠答疑时间，比较疏远。我希望能在这门课里形成一种教练与学员的关系：老师负责给方向、立标准、及时指出问题，助教负责在训练中手把手纠动作，而学生要主动练习、主动汇报卡点。开发能力不是听会的，是改出来的——如果代码写得不对，我希望有人直接告诉我哪里不对、为什么不对，而不是期末给我一个笼统的分数。

如果老师布置的作业对我有些困难，我的选择是 C：向老师和同学请教，花更多时间，把作业全部完成，再补充一条属于 E 的做法：请教前先自己尝试至少 30 分钟，把报错信息、尝试过的方案和卡住的位置整理清楚，避免把“老师，这题怎么做”这种空问题抛给别人。我不选 A，因为交学费买的是学习机会而不是及格保证；不选 B，因为向学校告状解决不了能力问题；不选 D，因为“只做到能及格的部分”一旦成为习惯，最后往往连及格都保不住。

开发中参考别人的文章和开源代码非常常见，优秀的工程师不会重复发明轮子，Agent 开发更是站在 LangChain、LangGraph 等开源框架的肩膀上。但参考和抄袭有本质区别：

• 参考是站在前人的肩膀上继续前进：引用观点会说明出处，引用文字会加引号并标注来源，复用开源代码会遵守它的许可证（如 MIT）并保留版权声明，而且用之前会先理解它的思想和实现，能在面试或评审时讲清楚“它为什么这样设计”。
• 抄袭是把别人的成果据为己有：直接复制代码、把别人的作业改个变量名就提交、翻译外文文章不注明出处、购买代写代码，都属于抄袭或剽窃，哪怕程序能运行、成绩能拿到，也没有真正提高能力，还会带来学术诚信问题。

我已经在第一周向老师确认了本课要求：作业要独立完成；参考他人代码和文章必须注明；团队作业要写清分工；有疑问的引用要在随笔中给出链接。学校对于抄袭也有明确规定，轻则作业/课程成绩按零分处理并批评教育，重则按《学生手册》中学术不端的条款给予纪律处分并记入诚信档案。具体条款我会在开学两周内找到原文逐条确认，因为“不知道”不是理由。

除了课堂时间，我计划每周至少投入 6 小时用于软件工程课程，主要包括：完成课程作业、推进个人与团队项目、学习 RAG/Agent 工程化相关知识、精读开源框架源码、撰写每周博客。如果某周任务特别重，我会临时加时到 8–10 小时，而不是压缩质量。

几年后的路有很多条，我的初步选择是毕业后进入大模型应用公司，或互联网公司的 AI 应用部门，做 Agent/大模型应用开发工程师；工作两三年后，再根据实践情况决定是否读研深造，把某个方向做深。

相比班里其他同学，我的优势是：

1. 基础比较扎实，对大模型 API、LangChain、LangGraph、RAG 都有实际动手经验；
2. 方向明确且处于行业前沿，不会在多个方向之间反复摇摆；
3. 有长期坚持的习惯，愿意为目标持续投入。

劣势是：

1. 真实项目经验不足，简历上没有能扛住追问的完整 Agent 产品；
2. 系统架构和工程设计理解有限，容易写出“demo 能跑但经不起生产环境考验”的代码；
3. 机器学习和深度学习理论基础薄弱，遇到涉及模型原理的深问题容易答不上来；
4. 工程规范意识需要提高，文档、测试、代码 review 这些习惯还没完全建立。

本学期针对这个目标，我给自己定五条计划：

1. 认真完成软件工程课程全部作业，把每一次作业当作真实产品来对待；
2. 把 Git 从“会用”提升到“用好”：学会分支管理、冲突解决和团队协作流程；
3. 完整走一遍软件开发流程：需求→设计→编码→测试→评测→部署→复盘；
4. 在课程之外完成一个可演示的 RAG/Agent 个人项目，包含知识库问答、工具调用、评测集和错误兜底，作为简历上的第一个完整作品；
5. 每周写一篇技术博客，把输入固化成输出，并尝试参与开源社区的 issue 讨论。

我最期待这门课能以完整项目为载体：不只讲“什么是软件工程”，而是让我们真实经历一次需求分析、团队分工、迭代开发、测试和发布，让每个名词都对应一次实际操作。对 Agent 方向来说，这一点尤其重要：因为模型输出不确定，一个功能“能跑”和“可靠”之间隔着评测、回归、重试、成本控制等一整套工程方法，而这些只有亲手做一遍才能学会。我也希望评分规则尽量透明，例如作业提交时间、抄袭红线、团队分工如何评价，最好在第一节课就说清楚。

• Wish（愿望）：课程结束时，我能独立走完一个小型 Agent 项目的完整流程——从需求分析、流程设计，到 RAG 检索、工具调用、编码、评测、部署和复盘——并产出一个结构清晰、有文档、有测试的智能体应用。
• Outcome（最好结果）：我不再只是“跑通一个 demo”，而是能讲清楚知识库为什么这样分块、工作流为什么这样编排、效果用什么指标评测、模型答错时系统如何兜底；面试官问起项目时，我可以从需求讲到架构，而不是只说自己“用过 LangChain”。那会让我真正觉得自己有资格进入大模型应用行业。
• Obstacles（障碍）：内部障碍是我习惯“先把 demo 跑通再说”，容易跳过评测、文档和错误处理，遇到大项目会不知道从哪里拆分；另一个内部障碍是“demo 焦虑”——看到新的框架和功能就想学，反而没法把一个项目做完。外部障碍是课程和其他事务挤在一起时，我会本能地压缩“看不见进度”的环节（设计、评测、复盘），把时间全投给“看起来在写代码”的部分。最可能导致我失败的因素是：觉得“跑通 demo 就等于学会了”，于是把评测、测试和项目收尾一再拖延，最后用 deadline 前的赶工代替系统学习。
• Plan（if-then 计划）：
  • 如果面对一个复杂任务不知道从何下手，那么我先花 15 分钟把功能拆成 3–5 个可独立完成的小模块，并为每个模块写一句“它解决什么问题、输入输出是什么”，再开始编码；
  • 如果我又想跳过设计直接写代码，那么我先画一页最简单的流程/状态图（节点、工具、知识库入口），画完才允许自己打开 IDE；
  • 如果模型输出不稳定、效果说不清好坏，那么我先把 bad case 收集成一个小评测集，再改提示词或检索策略，而不是靠肉眼反复试；
  • 如果某周时间紧张，那么我优先保证核心功能、评测/测试和博客三项不缺席，砍掉的是娱乐而不是流程；
  • 如果连续两周没有完成计划，那么我主动找老师或助教谈一次，暴露问题而不是悄悄放弃。

问题一：工程规范会不会拖慢小型项目的开发？

书中强调软件不只是程序，还包括文档和软件工程活动，只有规范流程才能保证质量和可持续维护。我认同这一点，但现实是我过去做的 Agent 小项目几乎从不写设计文档和评测方案，demo 一样能“跑起来”，甚至速度更快。我查了一些关于敏捷开发与“无文档开发”的讨论，发现业界对文档的态度差异很大：有人主张“能工作的软件胜过面面俱到的文档”，也有人认为没有设计文档的项目三个月后就没人能维护。以我的经验，小项目省略流程确实快，但过段时间回看自己写的 RAG 链路，常常要花很长时间才看懂当时的检索、分块和提示词为什么这么设计。我的困惑是：流程的“重量”应该由什么决定——项目规模、人数、还是代码生命周期？对于几百行的个人作业和几千行的团队项目，分别应该保留哪些流程、省略哪些流程？

问题二：技术深度和工程能力，哪个更该优先？

书中讨论了一个软件工程师如何衡量和提升个人能力，提到工程师不能只埋头写代码，还要在团队中交付、沟通、成长。但我观察到另一个现象：很多公司面试大模型岗位时，既会问模型原理、检索原理这些“深度”问题，也会考系统设计、评测方案这些“工程”问题，两者都绕不开。我自己的经历是：曾经花大量时间追新框架的用法，今天看 LangChain、明天看别的编排工具，结果在项目里被问“你的检索为什么这样设计、效果如何量化”时答不上来，说明我只有广度没有深度。我的困惑是：对一个在校学生，技术深度和工程能力在时间上冲突时，应该以哪个为主线？两者之间的合理比例大概是怎样的？

问题三：课程项目需求固定、截止日期固定，敏捷会不会变成形式主义？

书中介绍了敏捷流程的价值：响应变化、迭代交付、持续反馈。但学生项目往往需求由老师定死、日期不可协商、团队成员课余时间凑不齐，我担心最后的“敏捷”只是把瀑布切成几段：照样最后一周通宵，站立会开成聊天，Sprint 回顾流于形式。我也查到业界有“ScrumBut”的说法——很多团队只保留敏捷的形式而没有敏捷的精神，说明这不是学生团队独有的困境。对 Agent 项目来说，模型效果本身带有不确定性，更需要“小步验证、快速迭代”，但课程的时间和评分框架未必支持这种试错。我的困惑是：在课程这种特殊场景下，一个团队做到哪几件事就算真正用上了敏捷？哪些仪式可以明确砍掉？

问题四：设计和数据方案，应该在什么时候定到什么程度？

书中强调从规格说明到实现要经过分析和设计，而不是拿到需求直接写代码。我认同，但实际项目里需求一直在变：我做 RAG 项目时，知识库的分块方式、向量字段、问题改写策略都反复改过，一开始把流程设计得太细，需求一变就要返工；完全不设计，后面又要为补字段、补重试付出更大代价。我在网上查到的说法也分两派：一派主张“先建模再开发”，另一派主张“先用最简单方案跑通再演进”。我的经验是，我常常把流程图和数据方案当成“作业补交”，代码写完才画图，等于没设计。我的困惑是：对一个需求不明确的 Agent 项目，工作流和数据结构应该“提前设计到可扩展”，还是“够用就行、随需而变”？课程作业中，老师是否应该在编码前检查一次设计文档，而不是只看最终代码？

问题五：初学者应该先模仿，还是先创新？

书中谈到创新的迷思，大意是创新不一定是从零到一的发明，很多好产品是把已有想法组合、改进，并且让它真正被用户使用。我同意这个定义，但它让我产生一个反向疑问：对还在打基础的本科生，老老实实仿写一个成熟项目、先把 RAG 和智能体编排的基本功练扎实，是不是比追求“原创”更有价值？我看到很多同学做课设喜欢堆“看起来很高级”的功能（比如给管理系统硬接一个大模型，但连基本的输入校验和错误处理都没有），结果核心功能反而不稳定；我自己也有过为差异化而加复杂功能的经历，最后演示时主流程出错。所以我反对“创新点越多分越高”的评价方式。我的困惑是：课程评分中的“创新性”应该如何定义和设计，才能鼓励学生把新想法真正落地、被使用，而不是诱导大家为了拿分去做“为了创新而创新”的功能？

课程反馈一题我选 D：经常提问题，平时就经常给老师和助教提反馈，并把 C 当作底线（每学期至少提三个问题、认真按时填写问卷）。我给自己定的反馈格式是“现象 + 影响 + 建议”：例如“本周实验文档第 3 步给出的示例与模板字段不一致，我多花了约半小时猜测要求；如果在示例旁边加一句字段说明，会清楚很多”。这样老师得到的不是一句“还行”，而是可以直接改进教学的信息。

链接：《IT 小小鸟》讨论：在失望中寻找希望

刘帅是计算机科班出身，成绩很好、年年拿奖学金，但他自己承认本科四年“并没有学懂计算机”——作业照老师讲过的模式做，考前靠机械记忆，几乎从不主动追问“为什么”。他后来旁听了一堂从零开始实现算法的数据结构课，才明白知识是可以连成体系的。这篇最触动我的，是他说自己用高中思维应对大学、把大量时间花在做作业和游戏上。我虽然没到“年年奖学金”的程度，但前两年也常有类似状态：作业能交、考试能过，考完就忘，因为知识从来没有经过自己的思考加工。放在今天的大模型领域，这种风险更大——框架更新极快，如果只会照着文档跑 demo、从不追问原理，很快就会被淘汰。它提醒我：检验学习成果的标准不是分数，而是“能不能从零做出来、能不能给别人讲清楚”。

链接：一直在路上——记我从初中到本科近十年的学习成长历程

周见智是一个严重偏科的学生，但凭借“多实践、多查资料”的方法在大学里补上了编程，他给学弟学妹的四条建议是：自学、英语、基础、眼界。让我印象最深的是他对实习的看法：企业要的应届生是一张白纸，关键是白纸的吸墨能力——也就是基本功和自学能力，而不是简历上堆了多少“实习经验”。我以前也觉得会的新框架越多越好，看了这篇文章后我修正了自己的路线：先补数据结构、计算机网络、数据库这些地基，再深入 RAG、Agent 这些应用技术，否则只会浮在框架表面。当然我也有不完全同意的地方：现在校招竞争比十年前激烈，完全没有实习或开源经历可能连面试机会都拿不到，所以“基础”和“可见的作品”要同步推进，只是顺序上基础永远优先。

链接：.net 程序员工作两年总结

这位作者是机械专业转行做开发的，他最初在培训机构跟着在线视频自学，结果“看得懂、做不出”，在入门阶段卡了整整一年多；后来有了老师、有了必须完成的练习，才真正学会。他总结说，编程不是背书，而是技能，需要大量练习和长时间的实践感悟，“三个月改变一生”只是宣传。他工作两年后参加面试，被问到 Session 存在哪里、索引为什么能加速、垃圾回收的原理，很多答不上来——这正好说明：视频能教会“怎么用”，但原理和工程能力需要有人追问“为什么”。放到今天也一样：看一遍 LangChain 教程很容易，但把提示词、检索、评测和错误兜底做成一个可靠的系统，需要大量练习和真实的失败经验。这篇让我更坚定地选择认真上课：课堂的价值不是“念 PPT”，而是给我反馈、追问和必须动手的压力。

写这篇随笔耗时良久，但正是在这个过程中，我把自己两年多来的学习状态完整地“体检”了一遍：方向清楚，能跑通不少智能体 demo，缺的是工程流程、团队协作和把原型做成可靠产品的规范。软件工程课程正好是我补齐这些短板的训练场。