软件工程第一周作业：随笔（何卓文）
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 计科24级6班 |
| 这个作业要求在哪里 | 作业要求 |
| 这个作业的目标 | 建立个人在博客园的技术博客和 GitHub 仓库，熟悉 Markdown、Git 的基本方法，通过阅读老师提供的资料建立自我认识，整理个人经历、能力现状与学习计划，开始积累自己的软件工程实践记录。 |
账号准备
- 博客园昵称：何卓文
- 博客园地址：https://www.cnblogs.com/howen
- GitHub ID：
reminderxxx - GitHub 主页：https://github.com/reminderxxx
- GitHub 个人介绍仓库：reminderxxx/reminderxxx
一、关于我
1. 自我介绍
大家好，我是何卓文，是24级计科6班的一名学生。
我最初选择计算机专业的原因是：
其实起点很朴实无华，有出路、能赚钱。终点也差不多，但还是想提一句，感谢老师提供这个机会让我沉下心去感受博客，写下文字记录自己的生活、技术、思考以及反思自己的过往。同时让我第一次感受到计算机人应该做的（写技术博客哈哈哈），这让我感觉第一次真正挤进程序员行列。计算机对我来说其实是认识世界的途径，从我选这个专业开始就如此，计算机推动我去了解代码，去了解各个行业与计算机的结合，也了解到各个行业的信息化，在ai时代下计算机学生更是有更多机会去感受时代前沿的浪潮。总而言之，在一众理工科中选择了计算机，我很开心，今日写下这个博客，喜悦依然。
进入大学以后，我陆续学习了算法与数据结构、计算机网络、计算机组成原理和操作系统等课程。除了课程学习，也参与了一些项目、科研、竞赛和企业实践：
| 经历 | 我参与的内容 |
|---|---|
| ISO 实验组 | 从事边缘计算中的 Model Cache 相关研究 |
| 密盾智防网络安全项目 | 曾作为负责人参与项目，推进方案、材料准备和团队协作 |
| Bibibox 数字人平台 | 参与 AI 生图与前端页面开发，以及相关小程序上线实践 |
| 浩扬电子软件组 | 参与灯具控制系统前端开发 |
| 魔宝公司 | 参与前端设计与 H5 页面设计、开发 |
大一时，我获得过优秀学生一等奖和蓝桥杯省赛三等奖，之后也获得过国创赛校赛金奖。大学期间，我参加过三下乡，担任过导员助理和助班。这些经历让我接触到不同的人和任务，也逐渐发现，自己既喜欢研究技术，也喜欢与人沟通、推动事情向前。
目前，我比较关注 Agent 全栈开发、AI 产品，以及边缘计算中的 Model Cache。平时会通过 LeetCode 练习算法，也会关注 X、GitHub 和英文技术社区中的信息，高频使用 ChatGPT 辅助学习与开发。
随着接触的项目越来越多，我逐渐发现，“能够把代码运行起来”和“能够把一个软件真正做好”其实是两件不同的事情。
我希望在接下来的学习中，不只是继续学习更多技术，而是逐渐建立完整的软件工程思维。
2. 我的闪光点：沟通与换位思考
如果要总结一个自己目前比较有优势的能力，我认为是：沟通能力。
其实我从小就是一个比较敏感的人，会主动关注别人的感受，也比较习惯站在他人的角度想事情。但大学以前，这更多是出于性格；进入大学以后，我才开始有意识地练习怎样把这种理解转化为有效的沟通和组织协调。
其中一个比较有代表性的经历，是一次国创赛的材料准备。
当时比赛快开始了，材料却还没有准备完整。大家参与不够积极，单纯在群里提醒，效果也比较有限。
为了解决这个问题，我尝试了几件事：
- 从自己做起，在群里同步工作进度，说明已经完成了什么、还缺什么材料，让大家看见事情正在推进。
- 逐个询问组员是否遇到困难，了解没有及时参与的原因，而不是直接把问题归结为不积极。
- 把任务落实到具体成员，同时讲清楚交付内容和验收标准，让每个人知道下一步应该做什么。
最终，组员都在截止时间前完成了任务。这也让我第一次具体地感受到，管理和组织协调不只是“分配工作”，还包括建立信任、了解困难、对齐信息和及时跟进。
过去两年，通过导员助理、助班、实验室和竞赛经历，我逐渐开始有意识地练习这些能力。对我来说，它并不是某一次比赛结束后就已经掌握的技能，而是一项需要终身成长的能力。
3. 为什么建立技术博客
过去，我主要通过 Obsidian、GitHub 和语雀记录自己的学习过程。这些方式虽然方便，但内容比较零散，很少系统复盘。有些问题解决以后，当时觉得自己已经懂了，过一段时间再遇到，还是需要重新查找。
因此，我希望通过博客长期记录技术学习、项目开发、Debug、阅读思考和项目复盘。
我也逐渐发现，“脑子里觉得自己懂了”和“能够把它写清楚”不是一回事。写到解释不清楚的地方，就会知道自己还需要继续学习。
相比单纯完成一次课程作业，我更希望这个博客能够成为自己的技术成长记录，同时给遇到类似问题的人提供一些帮助。
二、我的现状：距离合格的 IT 毕业生还有多远
1. 学过技术，不等于形成了工程能力
这份能力评价表，让我重新思考了一个过去一直有些模糊的问题：为什么自己学过不少技术、做过一些项目，却总觉得这些积累还没有形成体系？
以前，我很容易把“掌握一项技术”理解成学会一门语言的基础。比如学过 Python、C++，接触过 JavaScript、TypeScript，也能使用 HTML 和 CSS 完成页面，就觉得自己已经具备了相应的开发能力。
但评价表把测试、复现、代码质量和独立调试等能力单独列出来，让我意识到，语言和理论知识之外，还有很多真正决定项目能否落地的工程实践。
一个网页写出来以后，能不能真正投入使用？怎样和后端连接？接口应该如何约定？换一个环境能不能部署？如果别人接手，能不能理解并继续修改？
这些问题，并不会因为页面已经显示出来，就自然得到解决。
放到我感兴趣的 Agent 开发中，也是一样。怎样给 Agent 明确的规范和执行边界，怎样管理上下文与 Token 消耗，怎样把代码修改、测试和反馈串联起来，以及什么时候可以认为任务真正完成了，这些都需要专门学习和验证。
我过去并不是完全没有遇到这些问题，但确实没有认真整理成自己的方法。而我现在觉得，这恰恰是技术积累中很重要的部分。
2. 我目前比较有把握的能力
相比纯粹的编码，我目前更有把握的是沟通、前期需求澄清，以及从用户角度理解产品。
在项目或商务对接初期，我比较愿意先确认：对方希望解决什么问题，最终要达到什么目标，双方对结果的理解是否一致。我也比较习惯换位思考，不只考虑“这个功能能不能做”，还会想“用户为什么需要它”。
Bibibox 数字人平台中的一次设计，就让我对这一点有比较具体的感受。
基于项目当时侧重数字资产展示与交易的定位，我判断，用户关注的可能不只是数字人能否交流，也包括价格及其变化。如果页面只展示数字人的形象，却没有呈现这些信息，可能就没有抓住这个场景下用户真正想了解的内容。
因此，我设计了数字人的价格波动展示，借鉴行情图的表达方式，让用户能够更直观地查看价格走势。
这首先是我根据产品定位提出的设计判断，并不意味着已经证明所有用户都更在意价格。它是否符合实际需求，还需要继续通过反馈验证。但这段经历让我意识到，自己的一个优势，是愿意从用户的关注点出发，再决定页面应该突出什么，而不只是把功能排列上去。
我也比较愿意持续完善自己的项目。做出第一版以后，会回头看哪里不顺手、哪里没有表达清楚，以及哪些设计可以继续改进。虽然这种反思还需要更系统的方法支持，但我希望保持这种不断打磨的习惯。
3. 技能评分与提升计划
按照作业要求，使用 0～9 分自评，其中 5 分表示能够达到相应面试要求，9 分表示世界一流水平。
这些分数是我结合已有经历作出的初步判断，不代表经过专业测评。课程结束目标是挑战目标，最后还需要用实际成果检查，而不是仅凭感觉把分数提高。
| 技能 | 当前水平 | 课程结束目标 | 具体提升方式 |
|---|---|---|---|
| 产品理解与用户体验判断 | 5 | 7 | 每周研究一个与自己方向相关的 GitHub 热门项目，阅读 README、Issue、评价及有实质改动的 Fork 或 PR，分析它解决了谁的问题、用户还有哪些不满，以及不同修改回应了什么需求，留下简短分析 |
| 沟通与需求澄清 | 5 | 7 | 在实验室论文写作和与老师讨论的过程中，练习整理反馈、确认目标、拆解修改任务；如果进入投稿与审稿阶段，再学习逐条分析和回应审稿意见，而不是只完成表面修改 |
| 独立编码 | 2 | 6 | 持续推进 LeetCode Hot 100，每周至少五题，先独立尝试，再复盘题解和错误原因；同时学习后端技术，在实际项目中练习接口、数据处理和调试 |
| AI Agent 工具使用 | 4 | 7 | 从高频使用 AI 转向工作流开发，学习工具调用、上下文管理、文档分块和 RAG，推进个人知识库与 HR 问答智能体，练习检索、回答、来源检查和失败处理 |
| 软件工程实践 | 3 | 6 | 跟随课程进度，把老师讲授的方法落实到需求说明、Git 管理、阶段验收、测试、部署和项目复盘中，让每次学习都有对应实践 |
我目前最需要补足的，是独立编码和工程能力。
会使用 AI，不等于已经能够检查和修正整个系统。获得一版代码已经不是最大的困难，真正困难的是判断：它是否正确，结构是否清楚，修改会不会影响其他模块，以及出了问题以后能否定位原因。
系统在实际访问量增加、接口故障或并发请求出现时能否稳定运行，也不能只靠“我在本地试过一次”来判断。我已经开始关注这些问题，但在测试、性能分析、异常处理和重构方面，还没有形成成熟的实践能力。
我希望逐步提升工程能力，但比起分数，更希望看到具体变化：项目能够按文档部署，关键流程有测试，出现问题有日志可查，代码在需求变化后仍然方便修改。
三、关于学习、课堂与师生关系的思考
1. 为什么要来上课并认真参与
参考材料：《你为何要来上课并且认真参与》、CookieLau《停下来，回头看》。
围绕老师给出的这个问题，以及学生回应中关于专注力、课程质量和反馈的讨论，我重新想了想，课堂究竟能带给我什么。
我认为，课堂带给我的并不只是知识。
首先，认真参与课堂，本身就是对专注力的一种训练。平时通过互联网和 AI 学习，虽然方便，但也容易在不同的问题、资料和想法之间不断切换。而在课堂上，我需要跟着老师的思路，持续理解一个问题，暂时放下其他事情。这种专注对我来说也是重要的能力。
其次，课堂能够让我接触到自己原本没有意识到的知识。
我平时高频使用 ChatGPT，也会主动搜索资料，但很多时候，这些学习仍然建立在“我已经知道自己要问什么”的基础上。自己的认知是有边界的，有些东西如果从来没有接触过，我甚至不会想到去搜索它。老师的经验和知识积累，能够把我带到这些原本看不到的地方。
所以，即使 AI 已经能够帮助我们查资料、解释概念、生成代码，我仍然认为打好基础很重要。工具可以帮助我更快地解决眼前的问题，但我也需要知道它为什么能够解决、在什么条件下成立，以及出了问题应该从哪里判断。课堂学习和 AI 辅助学习，对我来说并不是互相替代的关系。
这次软件工程作业，就让我明显感受到了这一点。
从认真写自己的技术博客，到梳理技能现状、思考师生关系，再到讨论引用与抄袭、学习如何提问，我发现老师给出的任务不只是让我们完成一次提交，而是在引导我们重新认识自己，也重新认识计算机这个专业。
顺着这些材料继续了解时，我真的有一种不断发现新东西的感觉。原来学习计算机不只是写代码、刷算法、做项目，还包括怎样表达思考，怎样向别人求助，怎样说明自己的贡献，以及怎样对交付的结果负责。
对我来说，老师就像一个知识宝库。不只是因为老师知道得多，更是因为老师能够通过课程和材料，让我接触到原本不会主动想到的问题。我也希望感受不同老师的思考方式，看看他们怎样理解一个问题、怎样把知识联系起来。
因此，我愿意认真参与这门课，不只是为了学会某项技术或者取得成绩。我更希望借助课堂拓宽认识，培养专注力、判断力和职业素养，也认真想一想自己以后希望成为怎样的人。
2. 我期待怎样的师生关系
参考文章：邹欣《现代软件工程讲义：教学方法》。
文章比较了顾客与服务者、保姆与幼儿、路人与路人等关系，并更认可教练与学员的关系。我比较认同这个比喻，但也希望在这样的关系里，多一点亦师亦友的交流。
如果双方只关注最后的分数，学生顺利通过，却没有真正获得技术能力和经验，那么课堂就失去了很重要的一部分意义。反过来，如果老师包办太多，把每一步都安排好，也可能让学生失去自己探索的欲望。如果双方除了上课和考试几乎没有交流，我也觉得有些可惜。
我理解教育很重要的一部分，就是有经验的人把知识、方法和经历传递给正在学习的人。这样的传递，不应该只有单向讲授，还应该有交流、实践和反馈。
所以，我希望老师在学习要求上像教练，在交流时又能有朋友之间的坦诚。
这里的“朋友”，不是遇到作业和评分就互相迁就，而是学生不必因为担心问得不好，就不敢说出疑惑；老师也能够直接指出问题，而我们不会把批评理解成否定自己。
对于专注力、基础知识、独立思考和认真完成任务，我认为严格要求是必要的。学生未必一开始就有稳定的学习习惯，也未必会主动接触暂时看不到用途的知识。包括我自己，愿意研究新技术，并不意味着每次都能把基础补扎实、把事情坚持做完。
同时，在共同的课程目标和基础训练之外，我也希望不同兴趣的学生能够保留一些深入探索的空间。
有的同学希望研究算法，有的关注移动端，也有的像我一样，希望往 Agent 全栈开发和 AI 产品方向发展。大家都需要掌握基础，也都需要学习需求分析、测试和协作，但在项目选题、实践场景和进一步深入的方向上，可以有不同侧重点。
这不是只学眼前职业规划中“用得上”的内容，而是在完成共同要求的基础上，把一部分训练与自己的兴趣结合起来。我想，这样自己会更愿意主动投入，也更容易把课程的方法用到后面的项目里。
自主选择也意味着承担责任。我需要向老师说明目标、基础和问题，而不是一边希望自由探索，一边等待老师替我规划所有事情。
该认真练习的地方不降低要求，可以深入探索的地方保留空间。既能得到指导，也能逐渐走出自己的方向。
3. 引用、借鉴与抄袭的边界
参考文章：《最新软件工程总结，项目模板，软工作业下载》。
我认为，借鉴在软件开发中是必要的。已经有成熟方案的问题，没有必要每次都从头解决。除非是为了学习原理，否则单纯重复造轮子，未必是有效的投入。
但借鉴的尺度一定要把握好。
文章中让我印象很深的，是有人复制项目文档时，连已经过时的 Windows NT、Pentium 133 等配置都没有发现。如果运行环境是否适用于自己的项目都没有检查，这种复制就很难说是在学习经验，更像是绕过了本来应该完成的思考。
这既是对项目不负责，也是对自己的技术提升不负责。
放到 AI 辅助开发中，也是一样。AI 可以生成很多文字和代码，但生成出来的内容，不会自动变成我已经掌握的知识。它可以帮助我接触原本不知道的东西，却不能代替我判断这些东西是否适合当前项目。
比如，让 AI“帮我做一个网站”，可以是一个起点。但如果开发过程中始终没有弄清产品服务谁、解决什么问题、哪些功能必须做，以及最后怎样判断是否达到目标，即使生成了很多代码，也容易偏离真正的需求。
问题不是提示词写得短，也不是必须一开始就知道全部技术栈。我们完全可以和 AI 一步步讨论。真正需要警惕的是，把所有判断都交出去，自己只等待一个“已经完成”的结果。
借鉴也不只是学习核心思想。在符合授权和课程要求的前提下，可以复用成熟的库、框架和模块，没有必要为了证明是自己做的，就把每一行代码重写一遍。
但我需要知道自己借用了什么，为什么选择它，它适用的条件是什么，放进自己的项目后又需要哪些调整和验证。
同时，“理解了别人的代码”和“这就是我的原创”是两回事。即使已经看懂、修改过，也应该如实说明来源和自己的贡献。课程作业还需要遵守老师对合作、引用和 AI 使用的具体要求。
这也让我想到理论联系实际的道理：学习已有经验，不是把现成答案原样搬过来，而是理解它为什么成立，再结合具体条件应用和检验。
借鉴不可怕，失去自己的判断才可怕。工具可以帮助我完成更多事情，但理解、选择和对结果负责，仍然应该是我自己的工作。
4. 如何提问：不只是把问题交给别人
从大一开始，我就接触过与高效提问有关的书籍、文章和技术文档。我现在越来越觉得，它的意义不只是“怎样让别人更快回答我”。
如果我只说“程序出错了”，别人需要先了解目标、运行环境、具体现象，才能开始分析。而如果我事先整理过背景、报错和已经尝试的方法，双方就能更快进入真正需要讨论的部分。
《提问的智慧》提醒我们区分具体症状与自己的猜测；娄老师提出的“问自己、问对象、问方式”，也让我意识到，一个问题在说出口之前，就应该经历一轮整理和判断。
这个过程本身就是学习。
为了把问题讲清楚，我需要先读文档、理解概念，分清哪些已经知道、哪些只是推测，以及真正不明白的是哪一步。有时候，原本觉得完全不会的问题，整理之后可能就只剩下一个具体卡点。
当然，这不意味着必须把技术完全学会以后才有资格求助。不懂本来就是提问的原因，重要的是尽量说明自己理解到了哪里，而不是把所有思考都留给回答的人。
到了 AI 时代，这种能力又延伸到人与 AI 的交流中。目标、服务对象、限制条件和希望得到的帮助越清楚，AI 越有机会给出贴合实际的回答。
但提示词不是越长越好，也不是只要会问，AI 就一定答对。关键还是自己能否不断补充信息、修正理解，并验证结果。
我希望提升的不只是让 AI 按要求输出的能力，更是把模糊想法变成明确问题的能力。
如果作业对我来说比较困难，我选择 C，并补充自己的做法：先独立尝试、整理问题，在课程允许的范围内向 AI 提问，查阅文档和技术社区；仍然解决不了，再带着具体问题向老师、助教或同学请教。
我希望按要求完成任务，但“完成”不只是交上一份能运行的结果，还要理解过程、验证结果，并把以后可能用到的方法留下来。
四、我的未来方向与本学期准备
目前，我的长期职业目标是成为一名懂技术、理解用户、能够推动产品落地的 AI 产品经理。现阶段，我会以 Agent 全栈开发作为主要学习路径，通过真实项目补足技术和工程能力。
我比较喜欢与人交流，也愿意理解别人真正需要什么。但我不希望因此降低对自己技术能力的要求。只有真正做过开发，才更有可能理解实现成本、技术限制和协作中的困难，而不是只说“这个需求应该很好做”。
针对这个方向，我认为自己目前的优势是：愿意主动接触新技术，比较重视沟通和换位思考，也已经接触了一些真实项目和企业场景。
不足也比较清楚：独立编码和后端能力还需要补强，测试、部署和代码维护尚未形成稳定习惯；兴趣比较多，也容易同时推进太多事情，导致精力分散。
因此，本学期我希望把准备工作集中在几个方面：
- 持续完成 LeetCode Hot 100 训练，巩固算法和独立编码能力。
- 在前端基础上学习后端、接口、数据库和部署，把完整开发流程串起来。
- 推进个人知识库与 HR 问答 Agent，把工具调用、检索和回答验证落实到实际应用。
- 在 ISO 实验组继续从事 Model Cache 相关工作，并在论文写作和讨论中练习表达与反馈处理。
- 跟随软件工程课程建立 Git、测试、阶段验收和复盘习惯，把项目经历真正沉淀下来。
我希望自己不是一直增加“接触过的技术名称”，而是逐渐形成能够反复使用、也经得起实际问题检验的能力。
五、我对软件工程课程的计划
1. 我期待从这门课学到什么
参考文章：《优秀的大学怎么教程序开发和软件工程课》、《助教之路》。
前一篇保存的 UCSD 课程案例中，团队需要展示阶段成果、进行代码审查和成员互评；后一篇则讨论把大目标拆成阶段任务，持续检查并给予反馈的实践教学方式。
我比较认同这种安排。
对于需要开发、测试和迭代的项目，最终结果往往不是一下子出现的。逐步完成任务、发现问题、调整方案，这个过程才是个人积累技术和经验的重要部分。
如果只看期末大作业，当然也可能收到优秀作品，但仅凭最后的展示，很难判断其中经历过哪些尝试，也不容易知道每个人真正掌握了什么。学生还可能把注意力集中在“最后能不能交出来”，而忽略值得认真练习的过程。
这与测试很相似。从明确目标、设计方案、准备环境，到执行测试、回收结果、分析问题，再决定下一步怎样调整，本身就是一个不断验证的过程。一次成功很难直接证明整个系统已经稳定。
所以，我希望阶段任务不是把一次大提交机械地拆成几次小提交，而是真的让我们知道：完成了什么，还存在什么问题，下一步为什么而改。
记录也不只是证明“我做过”，更是在保留当时为什么这样做。哪些判断不合适，哪些方案失败过，什么问题反复出现，这些内容不留下来，过一段时间可能只剩结果，经验却忘记了。
从课程开始要求写技术博客时，我就已经有很强的期待。拥有自己的技术积累，是进入计算机专业后一直想认真做的事情。这次作业让我真正开始把经历和想法写下来，也发现自己还有很多问题值得继续思考。
这与我正在筹划的个人知识库很相似。我希望它不只是保存文件，而是让过去的知识、经历和问题能够重新被找到、联系起来，在下一次需要时发挥作用。博客可以成为其中很重要的一部分。
我期待的软件工程课，不是一门只在临近期末集中复习、完成考试就结束的课程，而是一段贯穿整个学期的实践。
课程结束时，我希望带走的不只是能够展示的作品，还有一套可以继续用到下一个项目中的方法，以及真正属于自己的经验。
2. 关于是否担任助教
我目前暂时不主动申请助教。
这不是因为我对课程没有兴趣，反而是因为这次作业和相关材料，让我开始更系统地认识软件工程。但我现在希望把更多时间留给科研、Vibe Coding、学习项目，以及个人网页和技术博客的持续打磨。
阅读《助教之路》后，我也意识到，助教不只是评分，还需要持续答疑、跟进学生情况和参与课程改进。这是一项需要认真投入的责任。
因此，现阶段我更希望先做一个认真完成训练的学生。如果未来自己有更完整的理解，也有足够的时间和能力帮助其他同学，再考虑这样的角色。
3. 当前代码量与我的理解
目前可以作为统计对象的，主要是我实际参与的 Bibibox、MEC 项目、个人课程作业和算法练习。个人知识库与 HR Agent 仍在筹划和推进中，不能把尚未实现的内容计入已有代码量。
我准备使用 cloc 统计可访问的项目，并结合实际贡献确认范围。第三方依赖、生成文件、未参与的团队模块需要排除，AI 辅助代码也应如实说明，不能把整个团队仓库的行数直接当成个人累计代码量。
| 编程语言或代码类型 | 当前代码量，按百行统计 |
|---|---|
| Python | 5000+ |
| C / C++ | 3500 |
| JavaScript / TypeScript | 1200 |
| HTML / CSS | 2000 |
| node.js | 2200 |
| 合计 | 13900 |
统计日期：2026-09-05 。
统计范围与说明：个人在项目开发、日常数据分析练习、代码练习、陌生语言练习等粗略统计。
对于“一流软件公司需要多少代码量”，我不认为存在一个对所有岗位都有效的统一数字。个人应当积累足够的编程实践，但不能把行数直接当成入职资格。
对我来说，更值得检查的是：能不能独立理解和修改代码，是否处理过异常和需求变化，能否设计测试、完成部署，以及与他人共同维护项目。
高校教学和科研同样不能只看行数。问题定义、论文阅读、算法实现、实验设计、结果分析和可复现性都很重要；如果从事教学，还需要能够把这些内容清楚地解释给别人。
代码量可以帮助我观察实践投入，但不应代替对实际能力的判断。
4. 时间与代码目标
我计划每周平均投入 14 小时，包含课堂学习，以及阅读、编程、测试、团队讨论和博客复盘。
具体安排会先计入实际课表中的上课时间，再分配其他任务。我不会把全部实习和科研时间都算成课程投入，而是按课程及其相关工程训练记录。
对于题目中的选项，我选择 D。这里的重点不是在博客里喊一句“我要努力”，而是希望保持比过去更持续的投入，不再把主要训练集中到截止时间之前。
本课程结束时，我希望新增约 10000 行自己实际参与实现、理解和验证的代码。如果按 16 周规划，平均每周参考值为 625 行，但不会机械要求每周相同，更不会为了达到数字堆积代码。
本学期还希望围绕约五个有明确结果的项目或开发场景开展练习，包括课程项目、个人知识库、HR 问答 Agent、完整前后端开发，以及已有项目的工程化改进。
这些场景可能共享代码和基础设施，不能因此重复统计成果，也不能用个人项目替代课程规定的任务。如果时间冲突，我会优先保证课程交付和核心项目，而不是为了凑数量同时开很多新项目。
六、我的 WOOP 计划
Wish：我希望实现什么
我希望借助 AI 提高学习效率，但不跳过真实的软件开发过程，在本学期把已有前端能力与后端、Agent 开发和软件工程方法连接起来。
我想利用 AI 缩短入门和查找资料的时间，把更多精力用在实际开发、调试、验证和工程判断上，而不只是让它替我生成结果。
Outcome：实现之后会怎样
理想情况下，课程结束时，我能够完成一个从需求、前后端到部署的基本流程，能够解释 Agent 怎样使用资料和工具，也能为关键功能加入测试、日志和异常处理。
我还希望留下可以回看的记录：当时遇到了什么问题，为什么选择这个方案，哪里后来发现不合理，以及怎样完成修正。
这样，再介绍自己的项目时，我说的就不只是“用了哪些技术”，而是能够讲清楚自己实际解决过什么问题。
Obstacles：什么可能让我失败
最需要警惕的，是注意力分散，以及努力一段时间后逐渐松懈。
我容易对新技术产生兴趣，看到新的 Agent、框架或产品，就想继续尝试。课程、科研、个人项目和信息输入同时增加时，时间会被切得很碎，真正把一个问题做深的时间反而减少。
短期取得一些进展后，我也可能降低要求，觉得已经完成了不少事情，接着把测试、文档和复盘往后放。AI 带来的快速反馈，又可能让我更愿意写新功能，而不愿意花时间检查已有代码。
Plan：我准备怎样应对
我准备坚持周总结和月总结，记录目标、实际成果、遇到的问题以及下一步调整，并逐渐汇总到个人知识库中。
知识库尚未完成时，先用现有笔记工具记录，不把“等系统做好”变成推迟复盘的理由。
如果周总结发现自己主要在浏览信息，却没有推进原定任务，那么下一周先暂停新增方向，优先完成一个明确的阶段目标。
如果连续两周出现学习松懈或任务拖延，那么就提前检查原因，减少低优先级事项，重新安排固定学习时间，而不是继续增加新的计划。
如果AI 生成的核心代码让我无法解释，那么先阅读、拆解和验证这部分代码，再继续开发，不能把“能够运行”直接当成已经理解。
如果项目已经能演示，但测试、文档和部署说明长期没有补齐，那么下一次开发优先处理这些问题，而不是继续增加新功能。
周总结不只回答“这周忙不忙”，而要回答：完成了什么，有什么证据，哪里判断错了，下周准备改什么。
七、《构建之法》第三版：五个需要进一步讨论的问题
版本与目录参考：《构建之法：现代软件工程》第三版。
问题一：AI 生成了更多代码，怎样证明开发者自己获得了成长？
对应章节：第3章《软件工程师的成长》，3.1“个人能力的衡量与发展”。
问题一辅助阅读：作者《第3章：软件工程师的成长——练习与讨论》
第3章将个人能力的衡量作为一个独立问题。作者的公开讨论进一步提出，代码量与工程师水平是否呈线性关系，以及程序规模增加后，代码应该怎样组织。
这让我想到自己的学习经历。过去，我会把学会语言、做出页面当成能力提升的主要证明。现在借助 AI，生成代码变得更快，但我反而觉得，单纯的行数更难说明自己究竟学到了什么。
例如，生成一个后端接口，与能够解释它的异常处理、找到超时原因、为它设计测试，是不同层次的能力。代码出现在仓库里，并不代表这些判断已经成为自己的能力。
我目前倾向于把独立调试、测试设计、重构和部署作为补充证据。但这些指标也可能被形式化：有提交记录，不一定修改有价值；有测试，不一定真正检查到了关键问题。
因此，我的问题是：
在 AI 可以快速生成大量代码的情况下，学生应当用哪些可检查的证据判断自己的工程能力确实提升了？怎样避免用项目数量、代码量或形式化记录代替真正的能力增长？
我提出这个问题，是因为自己的工具使用速度已经明显快于独立掌握所有代码的速度。我希望找到更可靠的自查方法，而不是只凭“这周又做出了一个东西”判断成长。
看到很感慨的一段文字。
问题二：产品直觉怎样转化成可以验证的需求？
对应章节：第8章《需求分析》，8.3“获取用户需求—用户调研”、8.5“功能的定位和优先级”。
问题二辅助阅读：作者《用户调研》
对应章节讨论需求获取与优先级。作者在公开讲义中提醒，用户真正需要的、表达出来的、团队理解的和最后实现的内容，可能逐步发生偏差；调研也会受到问题表述和研究者倾向的影响。
我在 Bibibox 中设计价格走势，是根据产品定位和换位思考作出的判断。这个判断让我找到了一个设计方向，但还不能直接证明它值得优先开发。
我计划通过 GitHub 的 Issue、评价和实际改动学习用户需求，但这也带来新的疑问：积极发言的用户是否代表多数用户？讨论热度高的需求，是否就更重要？我会不会更容易注意到支持自己想法的意见？
我认为直觉可以帮助提出假设，但不能直接代替验证。问题在于，学生项目的时间和用户资源有限，未必能够做大规模调研。
因此，我的问题是：
在用户数据不足的早期项目中，怎样以可承担的成本，把个人产品判断转化成可验证的需求假设？又怎样避免只收集支持自己想法的反馈？
这个问题来自我对自身优势的反思：能够感受用户可能需要什么，是一个起点；知道怎样证明或修正这个判断，才是下一步需要学习的能力。
问题三：阶段任务怎样避免变成形式化打卡？
对应章节：第6章《敏捷流程》，6.1“敏捷的流程简介”、6.2“敏捷流程的问题和解法”。
问题三辅助阅读：作者《Scrum/Sprint》
作者在公开讲义中指出，每日交流也可能流于形式：成员不断汇报自己在写代码，却没有说明任务进展。需要明确任务是什么、怎样才算完成，以及距离目标还剩多少工作。
我认同阶段任务和持续反馈，也准备做周总结。但如果每周只是写“学习了 Agent”“看了几篇文章”，这种记录未必能说明项目真正向前推进。
另一方面，探索性的工作也不一定每周都有新功能。例如，经过实验发现原方案不可行，或者排除了一个错误假设，虽然没有增加代码，也可能是有价值的进展。
如果过分要求每周都有可展示的功能，会不会让学生只挑容易完成的任务，而回避真正困难的研究和验证？
因此，我的问题是：
在 Agent 或科研这类探索性较强的项目中，阶段任务的“完成”应该怎样定义？如何既避免周报流于形式，又不让可展示的产出挤占必要的探索？
我目前想到的办法，是为探索任务也明确问题、时间范围和预期证据，例如比较两种方案、复现一个异常、确认一个限制。但怎样判断这些证据足够支持下一步决策，我还需要继续学习。
问题四：答案不固定的 Agent，应该怎样测试？
对应章节：第13章《软件测试》，13.2“各种测试方法”、13.3“实战中的测试”。
问题四辅助阅读：作者《测试的计划和执行》
相关内容让我关注测试目标、操作条件和通过标准。公开讲义也提醒，测试不能只是执行操作，还要明确预期结果，以及怎样判断测试已经达到目的。
我正在筹划个人知识库和 HR 问答 Agent，这个场景让我产生了一个具体问题。
如果 HR 两次询问我的前端经历，Agent 的回答措辞不一样，并不一定意味着错误。但如果它把团队成果全部算成我的贡献，或者把计划中的项目说成已经上线，即使回答流畅，也显然不合格。
因此，不能只用字符串是否一致判断答案，也不能只靠人工看起来“还不错”。
我认为可以分别检查个人事实、来源、检索结果、工具调用和资料不足时的处理方式。但生成答案本身具有变化，少量测试通过，可能还不足以说明系统在更多问题下可靠。
因此，我的问题是：
对于回答措辞和执行路径可能变化的 Agent，怎样定义可以重复检验的通过标准？哪些部分适合确定性测试，哪些需要多次运行或人工评价，怎样避免只凭一次演示判断质量？
这是我希望在开发前就想清楚的问题，而不是等系统已经对外使用，才发现它会自信地说出没有依据的个人经历。
问题五：产品经理会自己写 Demo，应该怎样把握职责边界？
对应章节：第9章《项目经理》，9.1“PM是啥”、9.3“PM做开发和测试之外的所有事情”。
问题五辅助阅读：作者《项目经理 Program Manager》
这一章讨论 PM 的角色。作者的公开讲义区分了 Product、Project、Program Manager，并用划船的比喻讨论：负责方向和协调的人也去划桨，可能提高局部速度，却忽略整体方向。
因此，我不能把书中的所有 PM 职责直接等同于自己想做的 AI 产品经理，但其中关于分工和整体责任的讨论很值得思考。
我希望未来能够利用 Agent 亲自做 Demo，初步验证想法和技术可行性，再与开发、算法同事共同推进。这样可能减少沟通偏差，也能让我更理解实现过程。
但如果自己过于投入原型代码，是否也可能减少与用户交流、判断优先级和推进整体工作的时间？如果把自己已经写出的方案当成唯一选择，还可能限制团队提出更好的实现。
因此，我的问题是：
当 AI 降低原型开发门槛后，产品经理亲自开发到什么程度最有价值？怎样在提高需求验证效率的同时，避免技术细节挤占产品判断，并保持清楚的交付责任？
我希望技术能力帮助自己做出更好的产品，而不是因为“我已经做出来了”，就忽略这个产品是否真的值得继续做。
八、课程反馈与提问
对于课程反馈，我选择 D：经常提问题，平时就经常给老师和助教提反馈。
但我不希望为了满足数量而刻意制造问题。我会先进行基本思考和查找，再把真正没有想明白的地方提出来。
遇到课程问题时，我会及时与老师沟通，尽量说明具体卡点、已有尝试和个人感受。这既是在练习自己的表达能力，也能帮助老师了解学生在哪些环节理解不足。
我希望反馈不是简单写“很好”或者“太难”，而是说明：哪个任务让我有收获，哪里反复卡住，问题产生了什么影响，以及怎样调整可能更有帮助。
我也会认真按时完成课程反馈，并争取至少提出三个经过思考的问题。获得回答以后，还应该继续验证和整理，而不是问完就结束。
如果把师生关系理解成教练与学员，那么学生也需要让教练知道：哪些训练真正起了作用，哪些地方还需要纠正。
九、前车之鉴：阅读前人经历后的思考
1. 科班出身，不等于已经掌握工程能力
阅读文章：刘帅《在失望中寻找希望》
作者虽然本科成绩不错，也拿过奖学金，却仍然反思自己没有真正学懂计算机。这一点让我有共鸣。
大一时，我获得过优秀学生一等奖和蓝桥杯省赛三等奖，也参与过一些项目和比赛。这些经历是对当时努力的肯定，但真正接触软件开发时，我发现，它们并不能直接说明自己具备了完整的工程能力。
准备课程和比赛，让我积累了一部分知识与解题经验；但怎样完成部署、处理接口异常、保证系统稳定，以及根据实际使用情况持续改进，我当时并没有多少经验。
后来做项目，尤其是接触 Agent 开发、借助 AI 推进应用时，我才逐渐遇到这些问题。接口不是每次都会按预期返回，功能实现后还需要测试，部署也不是把代码放到服务器上就结束。响应是否及时，用户等待时有什么感受，都需要考虑。
但我并不因此认为课堂理论没有用。
恰恰相反，大一、大二学过的课程，让我后来接触真实项目时，对很多概念并不陌生。遇到网络、数据结构和操作系统相关的问题，至少知道它们属于什么范畴，不会完全无从下手。
只是，理解概念和真正上手，确实还有距离。
知道 LRU、FIFO 的原理，并不意味着已经能够设计和实现一个操作系统。算法只是其中一部分，还要考虑模块配合、资源管理、异常处理和整体行为的验证。
作者后来旁听数据结构课，看到老师把算法实现与其他知识联系起来，才重新感受到原有积累可以怎样发挥作用。这个细节也让我觉得，问题不在于理论和实践应该选哪一个，而在于有没有真正让它们联系起来。
只停留在理论上，可能把“我能解释概念”误当成“我能解决问题”；只急着做项目、忽略基础，又可能在出错时只能不断换方案，却不知道为什么。
我更希望形成相互促进的学习方式：在项目中发现问题，再回到课程、文档和原理中补足理解，最后通过实现与测试检验判断。
2. 实习的价值，是把“我会写”放到真实需求中检验
阅读文章：周见智《一直在路上——记我从初中到本科近十年的学习成长历程》
文章中，作者通过实习接触到一线开发，却也遇到任务简单、交流不足的问题。这让我觉得，实习的意义不只是简历上多出一段经历，而是究竟参与了什么，又从中获得了什么。
在魔宝公司实习时，我第一次真正接触到实际的前端项目。此前，我已经学过一些能够支撑页面开发的基础知识，知道怎样插入图片、调整布局、适应窗口变化，也能实现一些页面效果。
但进入项目以后，需要考虑的问题明显不同了。
变量和组件怎样命名，才能让别人理解？已有规范是什么？自己的代码怎样融入原来的结构？对方提出的需求，应该怎样转化成页面和交互？
这些并不是掌握几个语法就能自然解决的问题。工程实践不是把课堂例子放大，而是在具体目标、已有系统和协作要求下，综合使用学过的知识。
这段经历让我尤其重视两种能力。
第一种是沟通和需求理解。开发之前，需要明确对方希望解决什么问题、哪些内容最重要、怎样判断完成。如果没有抓住需求，即使做出了复杂漂亮的功能，也可能不是对方需要的。自以为是的“锦上添花”，反而可能增加返工。
第二种是可靠实现需求的技术能力。理解需求只是开始，最终还是要做出来。技术越扎实，就越有机会比较不同实现方式，选择适合现有项目的办法，而不是只能使用唯一熟悉的方案。
因此，沟通与技术不能相互替代。理解需求，帮助我确定该做什么；编码和工程能力，决定能不能把它做好。
实习也让我感受到，真实工作对结果的要求更具体：不仅要完成，还要考虑时间、准确性、可靠性，以及修改对其他部分的影响。不是我自己觉得“做出来了”就结束，而是要让实际使用和维护它的人也能够接受。
文章关于英语和自主学习的提醒，我也有共鸣。大学期间，我一直在提升英语能力，也会去英文社区寻找答案，让自己接触更多文档和开发者经验。但无论看了多少资料，最终仍然要回到自己的场景中验证。
实习不是唯一的实践途径，但对我而言，它是连接学校与真实工作的一个重要入口。
一定要多看书啊哈哈哈哈！！！积累才是漫漫人生路复利的唯一准则。
3. 热情、能力与选择：我为什么想做产品
阅读文章：陈皓《对程序员职业的一些建议》
文章从毕业生对第一份工作、技术路线和未来发展的疑问展开。这些问题也让我重新整理了自己的职业想法。
对我来说，技术能力始终是计算机专业背景中很重要的一部分。无论未来具体从事什么岗位，我都不希望离开课堂和开发项目后，就慢慢失去对技术的理解。
学习代码，不只是为了写出程序，也在训练我怎样拆解问题、理解系统，以及判断一个想法需要怎样才能实现。这些能力，对我未来想做的产品工作同样重要。
不过，我也逐渐认识到，自己希望长期参与的，不只是技术实现这一部分。
我喜欢与人交流，也愿意理解别人真正需要什么。在沟通中把一个模糊想法慢慢理清，再推动它变成实际结果，会让我有成就感。开发工作本身也需要大量沟通和协作，只是相比专注某个模块，我更希望参与用户需求、产品方案和落地推进的整个过程。
这也是我逐渐明确产品经理方向的原因。
但选择产品，不意味着可以降低技术要求。我希望先通过实际开发，理解前端、后端、数据和模型怎样配合，知道一个功能背后真正涉及什么。这样与开发者沟通时，才不只是说“这个功能应该不难吧”。
与此同时，我也需要学习怎样表达需求：产品服务谁，解决什么问题，哪些目标更重要，以及怎样判断结果符合预期。
Agent 让我看到了另一种参与产品开发的方式。在 AI 辅助下，我能够更快把想法做成 Demo，初步探索可行性，再用实际可操作的东西与别人讨论，而不是只停留在文字上。
但 Demo 能运行，不代表产品已经成熟。稳定性、性能、用户体验和维护成本仍需要验证。我希望带着前期探索，与开发、算法等角色一起完善方案，而不是把一个原型交出去，就认为后面与自己无关。
我也不认为第一份工作会决定一生。即使毕业后先从开发相关工作开始，也可以随着积累逐步调整方向。重要的是，每个阶段真正学到了什么。
我不一定要做出一件“改变世界”的产品。如果未来能做出一个好用的工具，让人少一些重复操作，减少某种困扰，或者解决一个长期存在的小问题，我就会觉得很有意义。
因此，我目前的选择是，以 Agent 全栈开发和工程实践打好基础，向 AI 产品经理的方向持续积累。既保留亲手实现想法的能力，也让自己越来越懂得，什么样的东西值得被做出来。
十、GitHub 练习
我的 GitHub ID 为 reminderxxx。
按照作业要求，我创建了与 GitHub ID 同名的仓库，并在根目录的 README.md 中完成个人介绍。
目前内容包括个人简介、技术方向、项目经历、正在学习的内容、博客链接和学习目标，也加入了 GitHub Stats 等展示内容。
不过，统计卡片只是主页展示的一部分，不能代替实际代码量统计，也不能直接证明个人技术水平。对我而言，更有价值的还是后续真实的项目、提交记录和技术总结。
以前，GitHub 对我来说更多是找项目、看开源和保存代码。这次作业之后，我开始希望把它与博客一起，逐渐建设成自己的公开技术记录。
一些git提交的记录，证明有使用git经验
十一、写在第一次作业的最后
写完这篇博客，我最明确的收获，是终于知道自己接下来该补什么。
以前总觉得，再学一门语言、再做一个项目，就能继续进步。现在回头看，我更想先把做过的东西整理清楚，把后端、测试和部署这些薄弱环节补起来，而不是一直追着新的技术跑。
这学期先把每周 14 小时的投入落实下来，完成任务后也留一点时间记录问题。等期末再回来看这篇博客，看看哪些话真的做到了，哪些目标还需要调整。
浙公网安备 33010602011771号