软工第一周作业随笔

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class78-Grade2024-CS
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class78-Grade2024-CS/homework/15710
这个作业的目标	完成课程开篇随笔撰写，梳理个人专业背景与技能现状，制定课程学习与能力提升计划；阅读《构建之法》并提出有质量的问题，思考软件工程学习方法与学术规范；借鉴前辈经验明确发展方向，同时练习Markdown排版，建立个人博客与GitHub主页，开启软件工程课程的工程化学习训练。

软件工程课程开篇随笔：从游戏启蒙到AI探索，修炼工程内功

一、介绍自己，建博客

我是一名计算机科学与技术专业的大三学生，这是我在软件工程课程中的第一篇博客随笔。

我与计算机的缘分始于从小对游戏的热爱，屏幕背后的代码逻辑、实时交互机制最早勾起了我对技术的好奇心，也带我走进了计算机专业的大门。而随着学习深入，尤其是亲眼见证AI技术的爆发式发展后，我的职业方向逐渐清晰：相比专业做游戏开发，我更希望能用好AI工具与全栈技术，打造真正能普惠大众的产品，用技术解决真实痛点、提升更多人的生产生活效率。游戏依然是我热爱的业余爱好，但我更期待用技术创造更广泛的社会价值。

在学习实践中，我也慢慢找到了自己的优势：我对用户需求和体验反馈有着天然的敏感度，擅长站在使用者视角捕捉核心痛点；同时我习惯借助AI工具快速验证方案、迭代思路，在多个实现路径中筛选最优解。技术上我不局限于单一方向，前端、后端开发均有涉猎，目前正在探索利用AI Agent实现全栈式产品开发，平时也会持续跟踪前沿AI技术动态，尝试把新技术落地为可使用的小产品。

开通这篇博客，是我这门课的第一个成长计划。有人觉得写博客耗费时间、性价比不高，但我始终认为，输出是最好的输入。写博客的过程，是倒逼自己把零散知识系统化、把模糊思考清晰化的过程；整理代码、撰写项目文档，也是在刻意培养工程规范意识。长期坚持下来，这里不仅会成为我课程学习的成长档案，也能记录我探索AI产品开发的每一步，和更多志同道合的同学交流切磋。我相信，把每一次学习、每一个项目都认真沉淀，时间自会给出答案。

二、现状、经验和计划

（1）专业选择与技能成长规划

当初选择计算机专业，最初是源于对游戏的好奇与热爱。而随着对行业的了解加深，尤其是AI技术的快速迭代让我看到了技术更广阔的价值，我越发坚定了转向AI产品开发的方向——用扎实的工程能力结合AI技术，做出能真正解决问题、普惠大众的产品。

对照课程给出的技能调查表，结合AI产品全栈开发的职业方向，我选取了6项核心技能，评估当前水平、制定课程结束后的成长目标，并明确对应提升手段：

技能项	目前水平（0-9）	课程结束目标水平（0-9）	能力说明	提升手段
架构设计、模块化设计、接口设计	3	6	目前可完成小型项目的模块划分，但复杂系统的扩展性、解耦能力不足，尤其缺少AI模块与业务系统融合的架构经验；目标是能独立完成中型AI应用的架构设计，输出满足面试标准的技术方案	1. 每个项目正式编码前，强制输出架构设计文档与接口定义，明确模块边界 2. 每周研读1个优质开源AI项目，拆解其分层设计与模型调用架构 3. 用AI工具辅助生成设计方案，对比自身方案查漏补缺
单元测试、代码覆盖率	2	5	此前开发多依赖手动调试，无主动编写单元测试的习惯，代码覆盖率低，AI相关逻辑的测试方法不熟悉；目标是掌握单元测试方法论，核心模块可输出合格测试用例，达到企业开发基本要求	1. 系统学习对应语言的单元测试框架与断言方法，补充AI接口的单元测试方案 2. 所有项目核心功能模块强制编写单元测试用例，覆盖核心与边界场景 3. 练习通过测试用例反向校验代码逻辑的完整性
模块实现、逐步细化	4	6	可按需求完成功能编码，但问题拆解颗粒度较粗，边界场景考虑不全；目标是能高效拆解复杂需求，输出严谨、可维护的实现代码	1. 需求拆解后先绘制流程图，再按功能边界拆分小模块，逐层实现 2. 遵循“自顶向下、逐步细化”原则，先搭骨架再填充细节 3. 每完成一个模块，补充边界条件与异常场景自测
效能分析与改进	2	5	此前只关注功能可用性，很少主动做性能分析，不会使用专业效能工具，对AI调用的性能优化经验少；目标是能定位常见性能瓶颈并完成优化，满足产品基本性能要求	1. 系统学习性能剖析工具的使用方法，覆盖CPU、内存、IO与API响应维度 2. 每个项目交付前做性能检测，输出效能分析报告，重点优化AI调用链路 3. 针对典型瓶颈场景，练习代码级与架构级优化方案
代码质量 / 代码评审	3	6	代码可运行但规范性不足，命名、注释、可维护性有待提升，未参与过正式代码评审；目标是写出符合工业规范的代码，能参与评审并给出有效改进意见	1. 接入代码规范检查工具，编码时实时校验格式与规范 2. 每周参与线上代码互评，提交自己代码同时评审他人代码 3. 每月复盘历史项目代码，针对冗余部分做重构练习
需求分析	4	6	擅长捕捉用户表层需求，但对深层需求、边界场景、业务逻辑的梳理不够系统，AI产品的需求边界把控经验不足；目标是能独立输出完整需求文档，覆盖核心场景与异常情况	1. 每个项目启动前输出完整需求文档，包含用户画像、核心场景与边界用例 2. 模拟用户视角，补充异常流程与边界条件，明确AI能力的适用范围 3. 通过同学互评需求文档，迭代修正需求遗漏点

（2）课程学习心得

a) 为何要来上课并且认真参与

在我看来，软件工程这门课的价值，从来不是背诵知识点应付考试，而是帮我们建立正确的工程思维，把零散的编程能力变成体系化的开发能力。软件开发的很多方法，比如需求拆解、架构设计、代码规范、质量管控，不是自己瞎写几万行代码就能自然悟透的，而是无数行业前辈踩坑总结出的经验。认真上课、完成作业，就是用最低的成本，把前人的经验转化为自己的能力。

对我个人而言，我的目标是打造能普惠大众的AI产品，这从来不是靠调用几个API就能实现的。一款真正好用、能落地的产品，背后是严谨的需求分析、稳定的架构设计、可控的质量保障，是完整工程能力的体现。这门课教授的软件工程方法，就是我实现目标的地基。认真参与每一次实践、每一份作业，都是在为未来打基础，这就是我认真对待这门课的核心理由。

b) 师生关系与作业态度

我之前体验到的大学师生关系，大多是“老师授课-学生考试”的单向模式，课后交流互动不多。我希望这门课能形成“教练-学员”式的师生关系：老师指明正确的训练方向，指出我们的问题和不足；我们主动练习、主动反馈，在一次次实践中迭代成长。

如果老师布置的作业有难度，我会选择 C：向老师和同学请教，花更多时间，把作业全部完成。因为作业里的难点，恰恰就是自己的知识盲区。如果为了省事放弃或者敷衍，看似躲过了麻烦，实则错过了成长的机会。在校期间正是试错成本最低的时候，多花时间啃下硬骨头，这些能力最终都会变成自己的职业底气。

c) 参考借鉴与抄袭的区别

在我看来，参考、引用他人成果和抄袭的核心区别，在于是否尊重原创、是否有自己的核心贡献。
合理的参考与引用，是站在巨人的肩膀上做创新：明确标注来源与原作者，遵守相关协议，在他人成果的基础上加入自己的思考、优化与落地，最终的核心价值是自己创造的。在软件开发中，我们使用开源框架、参考开源代码、调用大模型能力，只要遵守开源协议、标注出处，在此基础上开发自己的产品逻辑，这是行业常态，也是技术进步的方式。
而抄袭，是将他人的智力成果原封不动或稍加修改，隐瞒来源后当成自己的成果，本质是窃取他人的劳动。比如直接复制他人的项目代码去掉署名当作自己的作业，照搬别人的文章不标注来源，都属于抄袭。

在这门课的学习中，我会严格遵守学术规范，所有参考的资料、代码、开源项目都明确标注来源，所有作业与项目都保证是自己独立思考、亲手实现的成果。

（3）未来方向与本学期规划

我的选择

毕业之后，我希望投身AI产品与工具开发领域，以全栈开发能力为基础，结合AI Agent等前沿技术，打造能提升效率、解决真实痛点、惠及大众的产品。游戏依然会是我长期保持的业余爱好，用技术探索创意，但职业上我更希望追求技术的普惠价值。

优劣势分析

• 优势：
  1. 目标清晰，内生动力强。明确希望用AI技术打造普惠产品，愿意为长期目标持续投入，乐于探索新技术。
  2. 用户敏感度高。擅长捕捉用户需求与体验反馈，能站在使用者视角思考产品设计，这是做好效率工具类产品的核心能力。
  3. 技术视野开阔，拥抱AI趋势。不局限于单一技术方向，前后端均有涉猎，主动跟踪AI前沿技术，已经在探索AI Agent与全栈开发的结合，落地能力强。
  4. 学习能力强，快速迭代。能快速跟进技术潮流，主动学习新工具、新方法，适应AI领域快速迭代的节奏。
• 劣势：
  1. AI产品工程化落地经验不足。多是小型Demo级实践，缺少完整的、面向真实用户的AI产品全流程开发经验。
  2. 大型项目与团队协作经验欠缺。过往多为个人小型项目，多人协作的项目管理、代码协作经验不足。
  3. 底层AI原理积累不够深。更多停留在应用层，对模型原理、性能优化等底层知识掌握不足，限制了深度优化能力。

本学期规划

1. 紧跟软件工程课程节奏，把工程化基础打扎实，严格按照规范完成每一次作业与项目，不敷衍、不跳过任何基础环节。
2. 完成一款AI效率工具的完整开发，将课上学的需求分析、架构设计、单元测试、效能优化等方法全流程落地，打造一个可真实使用的小产品。
3. 每周抽出2小时补充AI工程化相关知识，学习Agent开发框架、大模型应用优化等内容，构建更完整的知识体系。
4. 坚持更新博客，记录课程学习、AI产品开发实践的过程与踩坑经验，每周至少更新一篇。
5. 业余时间继续用游戏开发保持技术乐趣，尝试用AI工具提升游戏原型开发效率，作为技术练习的补充。

（4）课程学习计划

对课程的期待

我期待这门课不是纸上谈兵的理论课，而是真正的工程实践课。希望通过一学期的学习，我能掌握工业级的软件开发流程与方法，学会写出高质量、可维护的代码，学会从需求到上线完整地做完一个项目，真正具备企业级开发的工程素养，为后续开发AI产品打下坚实基础。

代码量现状与目标

• 目前累计有效代码量约2.5万行，主要语言为C/C++、Python、JavaScript，包含课程作业、算法练习、小型全栈项目与AI应用Demo。
• 我认为要入职一流的互联网/AI公司，至少需要10万行以上的有效代码量，且需要包含中大型项目、多人协作项目的开发经验。
• 如果从事高校教学科研工作，代码量不是唯一标准，但需要有高质量的研究型代码，比如算法实现、原型系统开发，更看重代码的深度与创新性。

时间投入与代码量目标

我选择 D：比以前课要多很多，直到达到目标为止。计划每周在这门课投入12-15小时，包含上课、作业、项目开发与博客撰写。
课程结束时，计划累计新增2万行有效代码，平均每周完成约1500行。

WOOP目标规划

• 第一步 Wish：确定愿望
  扎实掌握软件工程核心方法论，养成规范的开发习惯，高质量完成所有课程项目，坚持更新博客，最终具备独立开发中型AI应用的工程能力。
• 第二步 Outcome：确定结果
  最好的结果是：课程结束后，我写出的代码结构清晰、健壮性强，做项目能从需求分析到落地交付走完完整流程，拿出手的项目能通过企业面试官的考察；同时博客积累了成体系的技术沉淀，认识了更多同好。那种靠自己的能力把想法落地成高质量产品的成就感，会让我真切地感受到，自己离“用AI造好产品”的目标又近了一步。
• 第三步 Obstacles：找出障碍
  内部障碍：最可能的失败因素：急于求成，忽视基础环节，看似完成了任务，实则知识学得不扎实，工程能力没有真正提升。
  1. 急于求成，为了快点做完功能，总想跳过单元测试、文档编写等环节，最后反而因为bug多返工。
  2. 遇到复杂技术点容易产生畏难情绪，拖延进度，越拖越不想做。
  3. 时间管理不严谨，刷技术资讯、调试AI工具容易分心，耽误核心任务进度。
     外部障碍：
  4. 其他专业课程作业、考试占用时间，导致分给这门课的时间不稳定。
  5. 做AI项目遇到冷门问题时，中文资料少，自行摸索耗费大量时间。
• 第四步 Plan：if-then 风险防范计划
  • 如果我写代码时想跳过单元测试直接写功能，那就立刻停下来，先写完核心模块的单元测试用例，再继续开发业务逻辑。
  • 如果我遇到技术难点卡壳超过1小时，那就先把问题记录下来，去请教老师或同学，或者切换到其他模块开发，换个思路再回来解决，不无效死磕。
  • 如果我刷网页/调试AI工具分心超过20分钟，那就立刻关掉无关页面，把当天任务按优先级列在纸上，从最重要的事开始做起。
  • 如果这周其他课程任务繁重，那就周日晚上提前规划下周时间，把这门课的任务拆分到每天的碎片时间，保证每天至少投入1.5小时，不堆到截止日前熬夜赶工。
  • 如果我想赶进度敷衍作业，那就翻一遍自己写的目标和“用AI做普惠产品”的初心，告诉自己现在偷的懒以后都要加倍还，高质量完成才是离目标最近的路。

三、提有质量的问题，给认真的反馈

关于“必要困难”的思考

刚看到课程要求开学就测试、就要提出问题时，我也短暂觉得压力很大。但仔细想想，舒适区里是没有真正的成长的。“预先测试、预先找问题”本质上是一种主动学习：先找到自己的盲区，再带着问题去学习，比被动听一节课效率高得多。制造“必要的困难”，就是主动跳出舒适区，让学习发生在拉伸区，这才是高效的学习方式。

《构建之法》阅读问题

快速阅读《构建之法》后，我结合自己的学习经历，提出以下5个问题：

1. 问题一（第2章 个人软件过程）
   书中提到个人软件过程（PSP）能帮助开发者精准估算工作量、提升开发效率，但我在实践中发现，对于学生的小型项目，完整执行PSP流程的记录成本很高，反而会拖慢开发节奏。我也了解到很多互联网公司并不会严格要求工程师执行完整PSP。
   我的困惑是：对于开发经验不足的学生，应该一开始就严格执行完整的PSP流程，还是先简化核心环节，随着项目复杂度提升再逐步完善？如果简化，哪些环节是必须保留的核心？
2. 问题二（第4章 两人合作）
   书中强调了代码规范的重要性，但实际开发中不同公司、不同团队的代码规范差异很大，同一种语言也可能有完全不同的风格约定。我自己写代码时，也经常纠结于遵循哪一种规范。
   我认为代码规范的核心是团队一致性，而非绝对的对错。我的问题是：对于学生来说，是先精通一套通用标准规范更重要，还是多接触不同规范、锻炼快速适应的能力更重要？当个人编码习惯和团队规范冲突时，应该如何平衡？
3. 问题三（第8章 需求分析）
   书中提到需求分析要挖掘用户的深层需求，但现实中很多时候用户自己也说不清想要什么，尤其是创新型的AI产品。我自己做小项目时，也经常遇到需求中途反复变更的情况。
   查资料了解到“快速原型法”，即先做最小可行产品再快速迭代验证。我的困惑是：在项目周期有限的情况下，需求分析应该做到多细致才算合适？如何平衡“充分调研需求”和“快速上线验证”的关系？
4. 问题四（第13章 软件测试）
   书中提出单元测试应该由开发者自己编写，是保障代码质量的重要环节。但我实际练习时发现，编写单元测试的时间经常超过功能开发时间，而且很多边界场景很难完全覆盖，尤其是涉及AI调用的非确定性逻辑。身边很多同学也觉得单元测试性价比低，不如多做几次功能测试。
   我认同单元测试的长期价值，但也疑惑：对于学生项目、小型个人项目，单元测试的投入产出比到底高不高？有没有适合小型项目、包含AI模块的单元测试最佳实践？
5. 问题五（第16章 IT行业的创新）
   书中提到创新是产品的核心竞争力，但当下AI技术发展极快，AI已经可以辅助生成代码、设计架构甚至完成简单项目。我自己也在尝试用AI Agent做全栈开发，确实能大幅提升开发效率。
   我的问题是：在AI快速普及的时代，软件工程师的核心竞争力会发生哪些变化？书中强调的工程能力、创新能力，哪些会被AI替代，哪些会变得更加重要？在校学生应该如何调整学习方向，才能适应AI时代的行业需求？

课程反馈态度

对于课程反馈，我选择 D：经常提问题，平时就经常给老师和助教提反馈。
我始终认为教学是双向的过程，就像健身教练和学员：学员及时反馈身体的感受、训练的难点，教练才能调整训练计划，达到最好的训练效果。我们及时反馈学习中的困惑、对课程的建议，老师才能优化教学内容和节奏，让所有人都学得更好。
我自己遇到问题会先独立查阅资料思考，解决不了的就及时向老师和助教请教；对于课程的作业、实践环节有想法，也会主动提出来。既是为自己解决问题，也希望能为课程优化出一份力。

四、前车之鉴

阅读了前辈们的经验分享，我收获很多，挑选三篇分享我的感想：

1. 《你是否也觉得自己是科班，但没学懂计算机？》

链接：https://book.douban.com/subject/4006425/discussion/22803961/

这篇文章的描述简直就是我大一大二的真实写照。明明学了数据结构、操作系统、计算机组成原理一堆专业课，但真上手做项目的时候，总觉得学的知识用不上，好像自己白学了，根本没“懂”计算机。
后来慢慢才明白，不是科班知识没用，是我们没有把理论和实践打通。学操作系统的时候，不会想到写代码时要考虑内存管理、线程安全；学计算机网络的时候，不会想到做应用时要处理接口超时、并发请求。科班教给我们的是底层规律，但如果只停留在背书考试，这些知识就永远是死的。这也是我格外重视这门软件工程课的原因——我希望通过真实的项目实践，把之前学的零散理论串起来，真正把科班的底子转化为解决问题的能力。不管是做AI产品还是做游戏，扎实的底层基础永远是技术人的立身之本。

2. 《速成的培训班和打基础的大学教育有区别么，你是否对大学的基础学科存在的必要性有疑问？》

链接：https://www.cnblogs.com/geniusalex/p/4928713.html

身边总有声音说“培训班学三个月就能上岗，大学四年学的都是没用的东西”，尤其是AI火了之后，很多人觉得会调用API就能做产品，我之前也有过短暂的动摇。看完这篇文章，我更加坚定了大学基础教育的价值。
培训班教的是“怎么用”，是面向岗位的技能速成，能让人快速上手干活，但技术一迭代就容易陷入瓶颈；而大学教的是“为什么”，是计算机的底层逻辑和思维方式，这些东西不会因为语言、框架、模型的更新而过时。就像我现在学AI Agent、做大模型应用，很多底层原理最终都要落到数据结构、操作系统、网络通信这些基础知识上。
当然我也承认，大学教育的短板是和产业实践脱节。所以我们不能等着老师喂知识，要主动做项目、找实践，把基础功底和实战能力结合起来，既有“内功”又有“招式”，才能在快速变化的AI时代走得稳、走得远。

3. 《技术栈和大佬的爆栈之旅》

链接：https://www.cnblogs.com/unruledboy/p/DevCareer.html

看完这位大佬的成长经历，我最大的感受是：没有谁生来就是技术大牛，所有的厉害都是靠一个个项目堆出来的。大佬也不是什么都会，而是遇到问题就去学、去啃，一点点拓宽自己的技术边界。
我自己的目标是做AI普惠产品，需要掌握的技术栈也很广：前后端、大模型应用、Agent开发、产品思维……有时候看着长长的学习清单，会忍不住焦虑，觉得要学的太多了。但这篇文章点醒了我：技术栈不是靠死记硬背攒出来的，是靠做项目攒出来的。不用急着一步到位，就从当下的每一个项目出发，遇到什么就学什么，学什么就钻透什么，每次项目都比上一次难一点，每次都突破一点舒适区，日积月累自然就有了质的飞跃。保持热爱，持续成长，就是最好的状态。

---

我的GitHub链接：
https://github.com/czhuohao1-glitch/czhuohao1.git