第一周随笔

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/homework/15692
这个作业的目标	建立个人技术博客，介绍自己，明确学习现状与计划，提出课程问题，从前人经验中学习

准备工作

账号

• 博客园地址：https://home.cnblogs.com/u/forest132
• GitHub 主页：https://github.com/Lin-huaj
• GitHub 个人介绍仓库：https://github.com/Lin-huaj/Lin-huaj

1、自我介绍

我是林华杰，一名计算机科学与技术的学生，目前就读大三。
现在的我对AI方向比较感兴趣的，一方面是AI的飞速发展以及其展现出来的前景让人心动，更多是对于AI的潜力，其能到达的高度让我好奇，想参与其中。
我更感兴趣的是ai的底层原理，就是小黑盒里面的东西，但是我深知自己在技术方面缺乏之多，所以我会一边进行ai应用实战，一边学习数学知识，钻研ai原理。
对于软件工程，我也略感兴趣，现在的ai太强大了，甚至还在飞速发展，目前“一人公司”的概念已不是虚幻，借助ai实现软件的建造是必然趋势。
但是我认为能用好ai在软件工程上的前提是，我需要对于软件工程的原理和代码本身足够了解，纯粹的交给ai无异于将命运交给运气，这样不仅对于学习还是工作都是毫无益处的。
我是个更注重原理的人，所以我希望我能在接下来的学习中，借助博客等工具，更加了解软件工程的原理和代码。
我认为，只有自身先学会，再辅以ai工具，才有可能创造出实用、能造福于人的软件，而不是将成败与否交与ai，做出一个漏洞百出，空中楼阁的软件。

2. 现状、经验和计划

（1）专业选择与技能评估

如何选择了这个专业？

我选择计算机科学与技术这个专业，源于对“创造”这件事本身的着迷。高中时我第一次接触到编程，看到一行行代码能让计算机按照自己的想法运行，那种掌控感和创造感让我意识到——这是一门可以“无中生有”的学科。后来随着对AI技术的了解加深，我发现软件工程正在经历一场深刻的变革。正如《现代软件工程讲义》中所说，在Vibe Coding（自然语言编程）时代，生成一个“看起来能跑”的App变得前所未有的容易。但真正吸引我的，不是AI能替我写代码，而是AI能让我一个人完成一个团队的工作——这个“一人公司”的可能性，让我下定决心选择了这个专业。

进入大学后，我逐渐把兴趣聚焦在AI应用方向，做过一些AI生成图片、AI辅助编程的实战项目，也在C、C++、Java、Python等语言上有了一定的积累。但我清醒地认识到，自己目前还处于“能用”但“不精”的阶段——代码能跑，但离“高质量、可维护、可复现”还有很大距离。

技能自我评估与提升计划

我对照软件工程师能力自我评价表，选取了以下7项对我特别重要的技能进行评估：

技能项	当前水平 (0-9)	目标水平 (0-9)	提升手段
需求对齐与代码质量（模块化拆分、消除冗余逻辑）	4	7	① 每周完成一个小型模块化编程练习，强制进行功能拆分；② 使用ESLint/Pylint等静态检查工具并确保零报错；③ 每次提交前进行代码自审，清理死代码和无用导入；④ 学习设计模式并在项目中实践；⑤ 参与开源项目PR，接受Code Review
测试驱动开发与自动化测试	3	7	① 为每个个人项目编写单元测试，确保覆盖率>70%；② 学习Jest/Pytest等测试框架；③ 在课程项目中实践TDD流程；④ 分析优秀开源项目的测试用例设计；⑤ 建立个人测试代码库，积累常用测试模板
架构设计与系统思考	3	7	① 学习《构建之法》中的架构设计章节；② 分析3个以上开源全栈项目的架构；③ 在课程作业中强制进行架构设计文档撰写；④ 参与团队项目时主动承担架构设计任务；⑤ 每周阅读一篇系统设计相关的技术博客
AI辅助编程与代码审查能力	4	8	① 练习使用AI工具生成代码后手动重构优化；② 培养鉴别AI生成代码正误的能力；③ 对AI生成的每段代码追问“为什么这么写”；④ 建立个人代码片段库，对比AI方案与手动方案的差异；⑤ 在团队中推行AI代码的二次审查机制
版本控制与协作规范	4	7	① 规范Commit消息格式；② 每周至少进行一次有意义的PR并附审查评论；③ 学习Git高级操作（rebase、cherry-pick等）；④ 在团队项目中实践分支管理策略；⑤ 维护个人GitHub仓库，保持活跃的数字足迹
全栈开发与MVP构建能力	3	7	① 独立完成一个前后端分离的完整项目；② 学习使用PaaS/BaaS/Serverless等快速开发工具；③ 实践从想法到可交互产品的完整流程；④ 每周至少投入3小时进行全栈项目开发；⑤ 在课程项目中承担全栈角色
软件工程文档与知识沉淀	3	7	① 每个项目撰写完整的README和技术文档；② 坚持用博客记录开发过程中的心得与踩坑；③ 学习技术写作，提升文档表达能力；④ 在团队项目中负责文档规范的制定；⑤ 建立个人知识库，系统整理学到的工程经验

评分标准说明：5分表示能通过面试，9分表示世界一流。我给自己打3-4分，是因为目前能完成基本功能，但离“能通过一流公司面试”还有明显差距。

（2）阅读心得

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

阅读了Scalers的《不上课，你真的亏大了》以及相关同学的思考后，我有以下几点心得：

第一，认真听讲是一种能力。 Scalers指出，学会认真听讲本身就是对人的一种能力培养，大学中如果没能养成认真听讲的习惯，可能导致散漫的习惯养成，关键时刻也不能绷紧自己的弦。我深以为然。聚精会神在这个时代已经是稀缺能力，大学应该打好这个基础。

第二，课程有用无用不是一个大学生的格局能判定的。 Scalers认为，很多学生评论课程落伍是由于自己短浅的目光所导致。如果能在大学里训练自己不带情绪地学好任何课，毕业后会成为非常有竞争力的人。这让我反思自己——我曾经也抱怨过一些课程“没用”，但现在想想，也许是我还没到能理解这些课程价值的阶段。

第三，跟上老师的节奏、梳理思路是最快的进步。 Scalers提出了一种“原生态”思考模式的概念——没有经过系统训练、任由随机事件冲击产生随机结果的状态。这种状态的人在社会上很容易被当成“韭菜”收割，而大学听课可以在大脑里留下专业领域带来的精神、信念、理论和体系。

但同时，我也认同那位北航同学的观点：一堂好课、一个好老师，不需要强制大家“认真听讲”。好的课堂自有其吸引力。但无论如何，作为学生，我的责任不是等“好课”降临，而是在任何课程中都尽量汲取有价值的东西。我来上课并且认真参与，是因为我认同Scalers的核心观点——大学是专治“青春期各种不服”的地方，我要抓住这个宝贵的系统学习机会。

b) 师生关系与作业态度

在大学中，我体验到的师生关系比较复杂。大部分课程是传统的“讲授-接收”模式，老师站在讲台上讲，学生在下面听。少数课程有更多的互动和项目实践。参考邹欣老师在《现代软件工程讲义》中对师生关系的讨论，我认为最理想的师生关系既不是“餐馆/食客”，也不是“老板/雇员”，更不是“保姆/幼儿”——而是“教练/学员”关系：教练设计训练方案、提供指导和反馈，学员主动训练、在实践中成长。

对于这门课，我希望的师生关系是：老师是项目导师和行业引路人，学生是主动的学习者和实践者。老师在关键节点给予方向性指导和质量把关，学生通过大量实践（Learning By Doing）来掌握技能。

如果老师布置的作业对我来说有些困难，我会选择：C——向老师和同学请教，花更多时间，把作业全部完成。

我的理由是：作业困难恰恰说明它在我的“最近发展区”内，是最能促进成长的部分。逃避困难等于放弃了成长的机会。我会先自己尝试解决，实在不行再向老师和同学请教，确保理解每一处难点，而不是简单地“抄答案”。

c) 引用、参考与抄袭、剽窃的区别

在工作中引用文献、参考别人的资料、在别人工作的基础上继续开发，与抄袭、剽窃的本质区别在于：是否注明出处、是否将别人的成果据为己有、是否进行了实质性的创造性工作。

引用和参考是学术和工业界的正常实践——我们站在巨人的肩膀上，但必须清晰标注哪些是别人的贡献、哪些是自己的创新。而抄袭和剽窃是故意（或放任）将他人的思想、文字、代码作为自己的原创成果提交。

在代码层面，参考开源项目的实现思路并自己重写、注明来源，是合法且鼓励的做法；但直接复制粘贴别人的代码而不加标注、不理解其原理，就构成了学术不端。我会严格遵守学校关于抄袭的处理规定，在每次作业中明确标注参考来源，并且确保自己真正理解了提交的每一行代码。

（3）未来选择与准备

对照前人的经历，我的选择是：以软件工程能力为基础，结合AI技术，走“技术驱动型创业者/一人公司”的路线。

我的目标不是单纯成为某个大厂的程序员，而是具备从0到1独立构建成熟软件产品的能力——在充分理解软件工程的前提下，借助AI的力量，实现“一人即公司”的武装。

优势

• AI实战经验：我在AI生成图片、AI辅助编程等方面有一定积累，对AI工具的能力边界有直观认识，这让我在“AI-Native”时代有先发优势。
• 多语言基础：C、C++、Java、Python都有涉猎，虽然不是精通，但具备快速切换技术栈的灵活性。
• 产品思维：我不满足于“写代码”，更关注“做什么”和“为什么做”，这让我在做项目时更贴近真实需求。

劣势

• 深度不足：各语言都停留在“能用”层面，缺乏对某一技术栈的深入理解和工业级经验。
• 工程规范意识薄弱：代码习惯不够规范，缺乏系统的测试、文档、CI/CD等工程实践训练。
• 缺乏完整项目经验：没有独立完成过一个从需求分析到部署上线的完整软件项目。
• 理论基础不够扎实：数据结构和算法、操作系统、网络等核心课程的知识还没有内化为解决实际问题的能力。

本学期规划

1. 课程学习：全身心投入软件工程课程，将其作为“一人公司”能力建设的核心训练场。
2. 项目实践：至少独立完成一个有完整前后端、有用户价值的软件项目，从需求分析、架构设计到编码测试、部署运维全流程走一遍。
3. 技能提升：针对上述7项技能逐项突破，每周至少投入10小时在编程实践上。
4. 知识沉淀：坚持用博客记录学习过程，形成可对外展示的作品集和知识体系。
5. 开源参与：开始在GitHub上维护个人项目，建立“数字足迹”。

（4）课程计划

对课程的期待

参考了美国本科软件工程课程、中国软件工程本科教学方案后，我对这门课的期待是：

• 不是“纸上谈兵” ：不希望课程停留在讲概念、背定义，而是通过真实项目来实践软件工程的全流程。
• 有明确的产出：希望课程结束时，每个人都有一个可以展示的作品，而不是一份试卷分数。
• 培养工程思维：不仅仅是写代码，更是学会如何做需求分析、架构设计、项目管理、质量保障。
• 与现代技术接轨：希望课程能涉及AI辅助编程、云原生、DevOps等当前工业界实际使用的技术栈。

我打算怎样度过这门课程

• 课前：预习相关材料，带着问题来上课。
• 课中：认真听讲、积极参与讨论、主动提问。
• 课后：立即实践课堂内容，不把作业拖到截止前。
• 项目：把课程项目当作真实产品来做，追求高质量而非“交差”。
• 反思：每周写一篇学习笔记，记录做了什么、学到了什么、遇到了什么困难。

代码量计划

目前代码量（估算）：

语言	代码量（行）
Python	~3,000
C	~2,000
C++	~1,500
Java	~1,500
HTML/CSS/JavaScript	~1,000
合计	~9,000

目标代码量：为了有资格入职一流的软件公司/互联网/AI公司，我认为需要至少 20,000 - 50,000行 的工业级代码积累（含测试代码、配置文件等）。从事高校教学科研工作则更注重理论深度和论文产出，代码量要求相对较低，但需要有高质量的开源贡献或科研项目代码。

本课程结束时，我希望新增代码量达到 5,000行以上，平均每周完成 300-400行。

时间投入

我打算平均每周拿出 15-18小时 用在这门课上（包含上课时间）。

选择：D. 比以前课要多很多，直到达到目标为止。

前两年我在一些课程上确实浪费了不少时间，现在到了专业核心课程阶段，必须发奋赶上。这门课是实现我“一人公司”目标的关键一步，值得投入更多时间。

WOOP计划

第一步，Wish / 确定愿望

在这门课程结束时，我希望具备独立完成一款成熟软件的能力——能够独立进行需求分析、系统设计、编码实现、测试部署的全流程，并且在充分理解软件工程原理的前提下，熟练借助AI工具提升效率，实现“一人即公司”的武装状态。

第二步，Outcome / 确定结果

如果这个愿望实现了：

• 我可以在简历上写下一个完整的、可展示的软件项目，有真实的用户和价值；
• 我具备了独立接项目、做产品的能力，不再是只会“写代码”的程序员；
• 我建立了自己的工程规范和开发流程，未来无论是就业还是创业都有了扎实的底子；
• 最重要的是，我证明了自己可以完成一件有复杂度的事情——这种信心将伴随我很长时间。

第三步，Obstacles / 找出障碍

内部障碍：

• 静不下心：具体来说，是手机通知太多，总想刷社交媒体；遇到难题容易焦虑，想逃避去做其他轻松的事。
• 完美主义拖延：总想等到“准备充分”再开始，结果迟迟不动手。
• 缺乏长期自律：往往前两周很有干劲，第三周开始松懈。

外部障碍：

• 其他课程的作业压力，时间冲突。
• 项目遇到技术难题时缺乏及时指导。

最可能的失败因素：遇到困难时产生畏难情绪，开始拖延，最终导致项目质量不达标或半途而废。

第四步，Plan / 风险防范计划

• 如果我在写代码时忍不住刷手机，那么我就把手机放到另一个房间，设置45分钟的番茄钟，专注写完一个功能模块再休息。

• 如果我因为项目太难而产生拖延的念头，那么我就把大任务拆解成最小可执行单元（比如“今天只写一个API接口”），先完成再完美，用“小胜利”积累信心。

• 如果我连续两天没有推进项目进度，那么我就强制自己坐在电脑前，哪怕只写10行代码也要动起来——启动是最难的，一旦开始就容易继续。

• 如果其他课程作业挤占了软件工程课的时间，那么我就提前一周做计划，在每周日晚上把下周的时间分配好，优先保证软件工程项目的固定时间段（比如每周二、四、六晚上8-10点）。

• 如果我遇到技术难题卡住超过1小时，那么我就立即记录下来问题是什么、尝试过什么方案，然后向同学或老师请教，不让自己陷入“死磕”的无效循环。

---

“每个人都想学好一门课，也有人立了各种愿望和flag，但是学期结束，很多人却不能取得预期的成功。” 我不要成为那些人中的一员。这门课是我走向“一人公司”的第一步，我会用行动证明——这一次，不一样。

3. 提有质量的问题，给认真的反馈

阅读《构建之法》的五个问题

问题一：关于第1章“软件=程序+软件工程”的定义

引用原文：

书中第1章提出了一个核心公式：“软件=程序+软件工程”[reference:0]。作者进一步指出，正是因为对软件开发活动（构建管理、源代码管理、软件设计、软件测试、项目管理）相关内容的完成，才能完成把整个程序转化成为一个可用的软件的过程[reference:1]。书中还扩展了一个推论：软件企业=软件+商业模式[reference:2]。

我的问题：

在AI辅助编程（如Vibe Coding/自然语言编程）日益普及的今天，这个公式是否需要重新定义？当AI可以自动完成大量的“软件工程”活动（如生成单元测试、代码重构、甚至部分架构设计）时，“程序”和“软件工程”之间的边界是否正在模糊？

查到的资料：

根据《构建之法》第四版的介绍，这本书“系统化体现了AI时代的软件工程知识体系”，并指出“当AI能替代90%的常规编码时，本书聚焦放大工程师其余10%的价值”[reference:3]。这暗示作者已经意识到AI对软件工程的冲击，但书中是否仍然坚持“软件=程序+软件工程”这个经典定义？

我的经验和困惑：

我之前做过一些AI生成图片和AI辅助编程的项目，切身体会到AI正在改变软件开发的范式。以前需要写几百行代码实现的功能，现在可能用一段自然语言描述就能让AI生成基础版本。这时，开发者的核心工作从“写程序”变成了“定义问题、审查代码、整合系统”。如果程序本身可以由AI生成，那么“软件=程序+软件工程”中的“程序”部分是否被大幅压缩了？还是说，AI生成的内容依然算作“程序”，但“软件工程”的内涵扩展到了“如何与AI协作”？

我的困惑是： 在AI时代，软件工程的定义是否需要从“程序+软件工程”演进为“（程序+AI辅助）+软件工程+人机协作”？或者说，这个经典公式依然成立，只是“软件工程”的外延被大大拓宽了？

问题二：关于第2章“单元测试必须由最熟悉代码的人来写”

引用原文：

书中第2章在讨论单元测试时提出：“单元测试必须由最熟悉代码的人（程序的作者）来写”[reference:4][reference:5]。好的单元测试还应该满足以下标准：在最基本的功能/参数上验证程序的正确性、测试要快、应产生可重复一致的结果、应覆盖所有代码路径、应集成到自动测试的框架中[reference:6]。

我的问题：

在AI可以自动生成单元测试代码的今天，“必须由程序的作者来写”这一要求是否还成立？如果AI生成的单元测试覆盖率高、质量好，是否可以被接受？

查到的资料：

书中其他地方提到，单元测试的基础上可以建立回归测试，目的是“验证新的代码的确改正了缺陷”和“验证新的代码有没有破坏模块的现有功能”[reference:7]。这些目标是客观的、可量化的——测试通过了就是通过了，没通过就是没通过。从逻辑上讲，测试代码的“作者”是谁并不影响测试结果的有效性。

我的经验和困惑：

我在自己的小项目中也写过一些单元测试，深知写测试是一件枯燥但重要的事情。AI辅助生成测试代码可以大幅提高效率。但另一方面，我担心如果让AI生成测试，开发者可能对测试逻辑缺乏深入理解，导致测试用例虽然“看起来覆盖了”但实际上没有测试到真正的边界条件。书中强调“单元测试必须由最熟悉代码的人来写”，背后的逻辑可能是：只有真正理解代码的人才能设计出有意义的测试用例。但如果AI也能“理解”代码（通过分析上下文和语义），这个前提是否被削弱了？

我的困惑是： “由作者来写”是单元测试质量的一个充分条件，还是一个必要条件？如果AI生成的测试能达到同样的质量标准，我们是否应该坚持“必须由人来写”的原则？

问题三：关于第4章“结对编程”

引用原文：

书中第4章介绍了结对编程（Pair Programming）：“结对编程是指一对程序员平等的并发进行开发工作，即用同一个显示器，同一个键盘，同一个鼠标工作，一起分析，一起编码，一起测试”[reference:8]。在结对编程中，“因为有着随时的复审和交流，程序的各方面的质量取决于一对程序员的各方面水平较高的那一位”[reference:9]。结对编程中有两个角色——驾驶员（driver）控制键盘输入，领航员（navigator）负责领航提醒，在过程中不断重复地互相复审[reference:10]。

我的问题：

在远程办公和分布式协作日益普遍的今天，传统的“同一台电脑、同一个键盘”的结对编程模式是否还适用？AI能否充当“领航员”的角色？

查到的资料：

豆瓣上有读者提出了类似的问题：“第四、五章大谈双人合作，团队合作的好处，但作者忽略了一个重要的前提，也就是所谓的团队准入机制”[reference:11]。这位读者认为，“任何没有团队准入机制就堂而皇之的跟你大谈团队合作重要的机构、组织或者个人，都是流氓行为”[reference:12]。在大学里，“很多时候自己单干和团队协作是不能够自己选择的”，“若不能选择队友，遇到猪队友，那只会给自己徒增'游戏'难度”[reference:13]。

我的经验和困惑：

我理解结对编程的理论好处——实时代码审查、知识传递、减少bug。但在实践中，尤其是远程协作场景下，两个人坐在同一台电脑前 coding 并不总是可行。而且，正如豆瓣读者所言，如果搭档水平差距过大或配合不默契，结对编程可能反而降低效率。此外，我注意到现在有一些AI编程助手（如GitHub Copilot、Cursor）可以在编码过程中实时提供建议和审查——某种程度上，它们正在扮演“领航员”的角色。

我的困惑是： 结对编程的核心价值在于“实时协作与复审”，还是在于“两个人比一个人想得更周全”？如果是后者，那么AI助手是否可以在一定程度上替代人类领航员？如果是前者，那么在分布式团队中，如何有效地实现结对编程的价值？

问题四：关于第6章“敏捷流程”

引用原文：

书中第6章讨论了敏捷流程。敏捷开发的原则包括：“尽早并持续地交付有价值的软件以满足顾客需求”、“敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势”、“经常发布可用的软件，发布间隔可以从几周到几个月，能短则短”[reference:14]。书中还指出，敏捷流程“是一系列价值观和方法论的集合”[reference:15]。

我的问题：

敏捷开发强调“欢迎需求变化”，但在实际项目中，频繁变化的需求往往导致项目范围失控、技术债务积累和团队 burnout。这个矛盾如何解决？“欢迎变化”和“控制范围”之间的平衡点在哪里？

查到的资料：

有读者在阅读笔记中提到：“没有坚实编程实力的基础，是不可能想到敏捷的开发流程的”[reference:16]。这说明敏捷流程的有效实施依赖于团队的技术成熟度。书中也提到，敏捷的团队应该“自主管理”、“自我组织”、“多功能型”[reference:17]。但这些要求在实际的中小型团队中往往难以完全实现。

我的经验和困惑：

我参与过一些课程项目，经历过需求在开发过程中不断变化的情况。有时变化确实是合理的（用户反馈、市场变化），但更多时候变化源于需求分析阶段的不足——“先做了再说，反正可以改”。这导致项目不断返工，最终质量下降。敏捷强调“拥抱变化”，但我困惑的是：如何在“拥抱变化”的同时，确保项目不会因为变化而失控？

我的困惑是： 敏捷流程中的“欢迎需求变化”是否有一个隐含前提——变化必须是高质量的、经过深思熟虑的？如果需求变化本身是低质量的（比如用户没想清楚就提出来），团队应该如何应对？书中是否有关于“如何筛选和管理需求变化”的具体方法论？

问题五：关于第16章“创新”

引用原文：

书中第16章讨论了IT行业的创新。其中提到一个观点：“要成为领域的专家，才能创新”[reference:18]。书中举了索尼公司的例子：索尼在大型收录机领域取得成功后，创始人盛田昭夫有“随身听”的想法，但公司专家们做了多次市场调查证明随身听没有市场。盛田坚持己见，最终创造了随身听这一划时代的产品[reference:19]。

我的问题：

这个例子恰恰说明，有时候“非专家”的直觉反而能带来突破性创新——盛田昭夫的创新恰恰是在“专家们都说不行”的情况下成功的。那么，“要成为领域的专家才能创新”这个观点是否与这个例子自相矛盾？或者说，什么样的“专家”才是真正有利于创新的？

查到的资料：

书中还讨论了“创新的迷思”[reference:20]，指出大众对创新有很多误解——比如“创新一定是灵感大发突然想到的”[reference:21]。实际上，创新往往需要长期的积累和思考。但索尼的例子似乎又在说明：即使专家们基于数据和经验做出了“正确”的判断，真正的创新仍然可能来自于“不听话”的直觉。

我的经验和困惑：

我对“创新”这个话题特别感兴趣，因为我的目标是成为“一人公司”——一个人独立完成软件产品。在AI时代，个人可以调用大量工具和资源，创新的门槛在降低。但我困惑的是：一个人如何在“不是领域专家”的情况下实现有意义的创新？书中说“要成为领域的专家才能创新”，但索尼的例子又说明专家的判断可能成为创新的阻碍。

我的困惑是： 书中所谓的“专家”是指“掌握了领域内所有现有知识的人”，还是指“具备独立思考和判断能力的人”？如果是前者，专家可能因为“知道太多”而被现有框架束缚；如果是后者，那么“专家”和“创新者”之间并不矛盾。书中对这个区别是否有更深入的讨论？

关于课程反馈的态度

我的选择：D. 经常提问题，平时就经常给老师和助教提反馈。

理由如下：

第一，反馈是双向的，是“教练/学员”关系的基础。 正如我在第二部分所期望的，理想的师生关系是“教练/学员”关系。教练需要了解学员的训练状况才能调整训练方案，学员需要及时反馈自己的困惑和进展才能获得针对性指导。如果学员不反馈，教练就只能凭猜测来教学，效果必然大打折扣。

第二，“必要困难”理论告诉我们，主动制造认知冲突是有效学习的关键。 加州大学洛杉矶分校的罗伯特·比约克和伊丽莎白·比约克教授提出的“必要困难”理论指出：在学习时故意制造轻微的挫败感，可以使大脑对学习材料的处理更深入，记忆更持久[reference:22]。提问和反馈正是制造这种“认知摩擦”的有效方式——当你试图把一个模糊的困惑凝练成一个清晰的问题时，你已经在进行深度的思考了[reference:23]。

第三，提问本身是一种能力，需要刻意练习。 有文章指出，“在答案唾手可得的时代，真正稀缺的不是知识，而是提出好问题的能力”[reference:24]。搜索引擎和AI可以回答几乎所有的事实性问题，但“提出正确的问题”仍然需要人的判断力和思考力。通过经常提问和反馈，我不仅是在帮助老师改进教学，更是在训练自己“提出好问题”的能力。

第四，认真反馈是对自己和他人负责。 如果只是“不提问、不理会、不填写”，我浪费的是自己的学习机会；如果“等到老师催促多次才随便填写反馈”，我提供的低质量信息反而可能误导教学决策。只有“经常提问题，平时就经常给老师和助教提反馈”，才能形成良性的教学循环。

因此，我承诺在本学期做到：

1. 每节课后至少提出一个与课堂内容相关的问题（可以是课上的疑惑，也可以是课后的延伸思考）；
2. 认真填写每一次课程反馈，不敷衍、不拖延；
3. 在团队项目中，主动向助教和老师反馈项目进展和遇到的困难；
4. 在博客和讨论区中积极参与讨论，分享自己的思考和困惑。

4. 前车之鉴

阅读心得

前人走过的路，往往刻着最真实的教训。在阅读这些博客的过程中，我不断在别人的故事里看到自己的影子——那些迷茫、挣扎、觉醒与坚持，仿佛一面面镜子照出了我当下的处境。以下是我对其中三篇的详细感想。

一、读《辜新星：时刻调整方向 找到人生的蓝海》——关于“忙”与“盲”的反思

文章链接：https://book.douban.com/subject/4006425/discussion/22803733/

这篇文章触动我最深的地方，是作者大一时期的经历——他进了北大计算机系，加入了校团委社团文体部，忙着认识朋友、办文艺晚会、参加团校活动，每周光各种例会就有三个半[reference:0]。结果呢？“高等数学期中考试只考了不到80分”，一纸成绩单把他从“瞎忙”的状态中惊醒[reference:1]。

读到这一段时，我几乎以为在照镜子。进入大学后，我也一度陷入了类似的“忙碌陷阱”——参加各种活动、加入多个社团、认识很多人，每天日程排得满满当当，仿佛越忙就越充实。但学期结束时回头看，发现自己并没有在真正重要的事情上有实质性的进步。正如作者所说：“大学的确提供了非常丰富的能力培养机会和广阔的个人发展空间，但归根结底，学习和进步才是大学的主题，荒废其中任何一个都不能让大学生活过得充实而完整。”[reference:2]

关于ABCD四类时间管理法

作者从学长那里学到了一个时间管理方法：把每天要做的事情分成A（紧迫且重要）、B（重要不紧迫）、C（紧迫不重要）、D（不重要不紧迫）四类，然后按顺序为每件事安排专属处理时间，关键是在专属时间内专心致志做好当前事情[reference:3]。

这个方法让我深受启发。反思自己过去的时间分配，我发现大部分时间其实花在了C类和D类事情上——刷手机、回消息、参加一些意义不大的活动，而真正重要的事情（B类，如深入学习一门技术、系统阅读专业书籍）反而被一再推迟。作者说这是他“从学长那儿获得的第一笔真正意义上的财富”[reference:4]，我也决定从本学期开始践行这套方法：每天早晨花10分钟列出当天的任务清单，按ABCD分类，优先保证A类和B类任务的完成。

关于“时刻调整方向”

文章开头讲了一个骑单车的故事：爸爸告诉儿子，别人骑车时车头看起来很直，也是因为他在时刻调整方向，才能顺利前进[reference:5]。这个比喻击中了我的要害。我过去有一种错误的完美主义倾向——总觉得要先规划好一条“完美的直线路径”，才能开始行动。但现实是，没有人能一开始就看清全部道路，所谓“直线”不过是无数微调累积的结果。与其在起点纠结方向是否正确，不如先骑上车，一边走一边调整。

二、读《刘帅：在失望中寻找希望》——科班出身不等于学懂了计算机

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

这篇文章让我感到一种强烈的警醒。作者是典型的计算机科班出身——学过数据结构、编译原理、操作系统、汇编语言、计算机原理、离散数学、计算机网络、数据库……从DOS的Turbo Pascal时代一直学到VC6[reference:6]。然而他自己说：“我却没有学懂计算机。”[reference:7]

问题出在哪里？

作者反思道，他本科时成绩一直排在前面，但“几乎所有的时间和精力都花在了犯迷糊、做作业和游戏上”[reference:8]。他像高中一样，只学上课讲的那点知识，“几乎不看教材、不怎么看课外资料”，作业基本独立完成，但“从来不是主动地思考、从各个可能的角度出发寻找到解决问题的方法，而是沿着老师讲过的固定的模式，或者寻找类似的解答方法，然后稍微变换”[reference:9]。

这段话让我冷汗直冒——这不就是我现在正在做的事情吗？上课听讲、完成作业、考试拿高分，然后呢？真正内化到脑子里的东西有多少？如果换一个从未见过的问题摆在我面前，我能独立设计出解决方案吗？我仔细想了想，答案是：大概率不能。我所谓的“学习”，很大程度上只是在重复已知的解题模式，而不是在培养真正的解决问题的能力。

“科班”不是护身符

作者的经历打破了我一个潜在的侥幸心理——“我是科班出身，好歹比非科班有优势”。但事实是，科班只是给了你一个系统的课程框架和一张入场券，如果你只是被动地完成课程要求而没有主动思考和深入探索，四年下来可能只是“混了个文凭”，并没有真正掌握这个学科的精髓。

作者说：“本科阶段是我们精力最最充沛、时间最最富裕、最最容易跟其他人拉开距离的阶段，如何处理这段生活，将会造成最后的千差万别。”[reference:10]我现在正处于这个阶段，每一天都在拉开或缩小与别人的差距。这篇文章提醒我：不要满足于“完成了作业”，要追问“我真的理解了吗”；不要满足于“考试通过了”，要追问“换一个场景我还能用上吗”。

关于“机械记忆”的警示

作者在考研和读研后进一步反思了自己的思维局限——“以机械记忆为主的学习方式”[reference:11]。他发现，每看到一个题目总是先看答案，让答案指引思路，而不是用自己的脑子想问题[reference:12]。他警告说，这种学习方式“会使人的思考方式沦为简单地重复和机械地回忆，胆子变小，创新力几乎丧失”[reference:13]。

读到此处我深感震撼。在AI时代，机械记忆的价值正在被加速贬值——任何事实性知识都可以在几秒内被检索到。真正稀缺的能力是提出好问题、设计好方案、做出好判断的能力。而这些东西，靠“看答案—记答案—考答案”的模式是永远学不会的。

三、读《徐宥：掉进读书的兔子洞》——关于笔记、自省与“建索引”式的学习

文章链接：https://book.douban.com/subject/4006425/discussion/22802960/

这篇文章让我最受触动的是作者的两个习惯：记思维快照和不求甚解但建索引。

关于思维快照笔记本

作者说，他从高中开始就有一个习惯：“把每天胡思乱想的东西记在一个笔记本上，算是思维快照。我还常常翻回去自省，看看过去和现在的变化。”[reference:14]大一大二时，笔记本上记的是“和生活和感情有关的琐碎小事，或者宏大空泛的目标和叙事”；而到大三时，记录的内容明显具体起来——“这周看完了什么书、下周去图书馆借什么书等”[reference:15]。

这个习惯让我很有共鸣。我一直有随手记录想法的习惯，但从来没有系统地翻回去看过。作者的提醒是：记只是第一步，翻回去自省才是关键。通过对比过去和现在的想法，你能看到自己的成长轨迹，也能发现自己是否在重复同样的错误。我决定从这个月开始，每周日晚花15分钟翻看过去一周的记录，做一次简单的回顾和反思。

关于“建索引”式的学习

作者大三时疯狂读书，但大部分是“囫囵吞枣地看，做一些总结性的笔记”[reference:16]。他形容自己像“饥饿的狗熊在掰玉米棒子，看上去很勤奋地在掰，掰下来，啃两口，扔掉”[reference:17]。但他做对了一件事——“很注意整理自己的既得知识”[reference:18]。

他打了个比方：大三疯狂读书就像是在“建索引”，等到大四要“搜索结果”的时候，不需要每本书全文检索，直接按照笔记本上的索引找到当时看过的书就可以了[reference:19]。这个比喻太精妙了。在知识爆炸的时代，你不可能记住所有读过的内容，但你可以记住“哪里有什么”——建立一个可检索的个人知识体系。

这让我重新思考自己读书和学习的方式。以前我总有一种“必须全部记住”的焦虑，读不完一本书就不敢开始下一本，结果反而什么都没读完。作者的做法给了我一个启发：可以快速浏览建立索引，再根据需要深入。不需要每一本书都精读到底，但每一本读过的书都应该在笔记中留下“索引条目”——它讲了什么、核心观点是什么、以后什么场景下可能会用到。

关于“踏实”与“勤奋”

作者提到他从叔叔和获鼎身上借来了“踏实和勤奋这两个优秀品质”[reference:20]。这两个词看起来朴素，但真正做到却极难。在信息过载的时代，“踏实”意味着不浮躁、不追求速成；“勤奋”意味着持续投入、日拱一卒。我反思自己，最大的问题恰恰是不够踏实——总想找“捷径”、总想“快速掌握”，结果往往是浮于表面、根基不稳。这篇文章让我意识到，真正的成长没有捷径，只有日复一日的积累。

综合感悟：三条共同的教训

读完这三篇文章，我发现它们指向了三个共同的教训：

第一，主动思考 vs 被动接受。 刘帅的教训是“沿着老师讲过的固定模式解题”[reference:21]，徐宥的教训是“像无头苍蝇一样到处尝试”[reference:22]——两种看似相反的状态，本质都是缺乏主动的、有方向的思考。真正的学习不是被动接收信息，而是主动构建自己的理解框架。

第二，记录与自省。 辜新星通过成绩单惊醒[reference:23]，刘帅通过考研反思[reference:24]，徐宥通过笔记本自省[reference:25]——三人都经历了“被现实提醒”或“主动回头看”的过程。没有记录和自省，人就容易在忙碌中迷失方向，日复一日地重复同样的错误而不自知。

第三，长期积累 vs 短期冲刺。 三位作者最终能走出迷茫，靠的都是持续的努力和积累——辜新星“每年都能获得奖学金”[reference:26]，刘帅“风风雨雨地跑着，简简单单地过着”[reference:27]，徐宥“踏实和勤奋”地积累[reference:28]。没有什么一夜逆袭的神话，所有的“顿悟”背后都是漫长的“渐悟”。

给我的启示

回到我自己的处境——我的目标是成为“一人公司”，在AI辅助下独立完成成熟的软件产品。这三篇文章给我的启示是：

1. 不要满足于“完成作业” ，要追问自己是否真正理解了背后的原理。AI可以替我写代码，但不能替我思考架构、不能替我判断什么是对的、不能替我做 trade-off 的决策。这些能力只能靠我自己的主动思考来培养。

2. 建立自己的知识管理系统 ——像徐宥那样记笔记、建索引，让自己读过的每一本书、写过的每一段代码都留下可检索的痕迹。

3. 定期自省，调整方向 ——像辜新星那样“时刻调整方向”，不要一条路走到黑才发现走错了。每周、每月、每学期都问问自己：我离目标更近了还是更远了？我是在“忙”还是在“盲”？

前人的教训是最好的老师。我希望自己在学期结束的时候，能够说：我没有重蹈他们的覆辙，我在他们的经验上走得更稳、更远。

结语

从作业到行动

写完这份作业，我的感受可以概括为三个词：清晰、压力、期待。

清晰的是方向。 写下“一人公司”这个目标之前，它只是一个模糊的憧憬。但在梳理技能评估、WOOP计划、课程期待、时间管理方法的过程中，这个目标被一层层拆解成了可执行的步骤——每周15-18小时的投入、7项技能的逐项突破、5,000行代码的积累、从需求分析到部署上线的完整项目。模糊变清晰了，口号变路径了。

压力来自看到了差距。 技能评估表中那一个个“3分”和“4分”，刘帅学长那句“科班出身却没有学懂计算机”的警醒，以及那些大佬们动辄数万行的代码量——都让我清楚地意识到，自己离“合格”还有很长的路要走。但压力本身就是动力的另一面。

期待源于找到了方法。 记思维快照、建知识索引、用ABCD四象限规划每天、用WOOP防范风险、带着问题去读书、主动给老师和助教反馈……这些具体的方法论是前人用时间和教训换来的，我现在接过了它们，剩下的就是——执行。

写给学期末的自己

当你读到这段话的时候，这门课应该已经接近尾声了。我想对那时的你说几件事：

• 那些每周15-18小时的投入，你做到了吗？如果做到了，请给自己一个肯定；如果没做到，请不要找借口。
• 那个“一人公司”的目标，你推进了多少？你的GitHub上是否多了一个可以展示的项目？
• WOOP计划里写到的那些“如果……那么……”的应对策略，你遇到困难时用上了吗？还是又在刷手机逃避？

不要因为一次懈怠就否定全部努力，也不要因为一点进步就放慢脚步。真正拉开差距的，不是爆发力，而是持久力——是那些没有鲜花和掌声、只有键盘敲击声的普通日子。

前人的路已经照亮，剩下的，靠自己一步一步走出来。

这一次，说到做到。