第一次作业：自我介绍、现状与计划、《构建之法》提问、前车之鉴

项目 内容
这个作业属于哪个课程 https://edu.cnblogs.com/campus/gdgy/Class78-Grade2024-CS/
这个作业要求在哪里 https://edu.cnblogs.com/campus/gdgy/Class78-Grade2024-CS/homework/15710
这个作业的目标 ①练习用 Markdown 写博客、传代码、遵守排版与引用规范；②盘清自己当前的技能水平和差距，给出可执行的本学期计划；③通过快速通读《构建之法》并提出有观点、有证据的问题，进入"预先测试"式的学习状态；④读前人经历，避免重复踩坑。

说明：本文使用博客园 Markdown 编辑器撰写，仓库地址与截图见文末。文中引用的数字（代码量、自评水平）均为我自己统计/自评，未经他人核实。

一、介绍自己，建博客

1.1 我是谁

我是一名计算机专业的大三学生。名字、学校这些就不细写了，博客园账号和 GitHub ID 都在文末，感兴趣的同学可以直接去看我的提交记录——那比我在这篇随笔里怎么形容自己都要准确。

先说我对"写博客"这件事的看法。我同意作业要求里的判断：写博客花时间，但很值得。理由有三个。第一，写不出来说明没想清楚，博客是一种强制自己把模糊理解变成明确表述的工具。第二，公开的提交记录和随笔，是求职时少数几个别人无法注水的证据。第三，半年之后回头看自己的博客，能直观看到自己走了多远，这种反馈比分数管用。

我也留一句给持反对意见的同学：如果反对的理由是"写博客是形式主义、浪费时间"，我认可其中一半——只写不做的博客确实是形式主义。所以我给自己的约束是：每篇随笔至少对应一段能跑起来的代码或一个能验证的结论，不写空心的心情日记。

二、现状、经验和计划

2.1 我怎么选了这个专业，差距在哪

高考填志愿时，我对"计算机科学与技术"的理解基本就是"写程序、做网站、工资稍高一点"，然后我个人对计算机也比较的感兴趣，对于硬件的东西，我自认为我的动手能力不强，所以我并没有考虑其他的工科，很快就选择了计算机这个专业。

离一个合格的 IT 专业毕业生，我的差距主要是三块：

  1. 动手量严重不足。学过的课不少，但真正从需求到部署完整做完的项目几乎为零。课设大多是"交上去就再也不会打开"的一次性代码。
  2. 基础课的"知其所以然"缺失。数据结构会写，但为什么用这个不用那个、复杂度和内存布局怎么互相影响，说不清楚。操作系统的进程/线程只是背过概念，没在真实并发 bug 里吃过亏。
  3. 工程素养是空白。不会写单元测试，不会做代码复审，Git 只会 add / commit / push 三板斧，没碰过分支协作、CI、code review。这些恰恰是团队作业和实习最需要的。

2.2 技能自评表

评分口径：0 = 完全没接触，5 = 能通过一线公司面试，9 = 世界一流。

我从技能调查表中抽出对我最重要的 6 项：

# 技能 ①目前水平 ②课程结束时期望水平
1 Python 程序设计与工程化 4 6
2 数据结构与算法 3 5
3 代码阅读与调试能力 3 6
4 软件设计（模块划分与 API 设计） 2 5
5 工具的使用（Git / CI / 调试器 / 效能分析） 2 6
6 需求分析与用户沟通 1 4

③提高手段（每项 5 条）

技能 1 · Python 程序设计与工程化（4 → 6）

  1. 本学期尽量提交多次代码到 GitHub，保证提交历史。
  2. 把课程个人项目全部用 Python 实现，并强制要求：类型注解 + docstring + ruff 静态检查通过。
  3. 通读一个中等规模开源项目的源码（候选：LangChain 的 core 模块），每周写 1 篇源码阅读笔记。
  4. 给自己的项目补上单元测试，覆盖率目标 70% 以上，用 pytest + coverage.py 度量。
  5. 每次写完一个功能就做一次重构：拆函数、去重复、命名规范化，前后各提交一次以形成对比。

技能 2 · 数据结构与算法（3 → 5）

  1. 每周固定2道题，在 LeetCode 上完成并保留提交记录。
  2. 每题做完写"三行总结"：用了什么结构、时间/空间复杂度、为什么不用别的做法。
  3. 手写实现一遍基础结构（链表、栈、队列、二叉树、堆、哈希表、并查集），不看标准库。
  4. 每两周做一次 45 分钟限时模拟面试，全程不查资料，记录卡壳点。
  5. 把《编程之美》和课程作业里出现的算法题对照刷一遍，重点弄懂"从原始算法到优化算法"的推导过程。

技能 3 · 代码阅读与调试能力（3 → 6）

  1. 停止"printf 一把梭"，本学期强制用 IDE 断点调试完成至少 10 次真实排错，并记录排错过程。
  2. 每次遇到 bug，先在纸上写出"我假设它是什么原因"，再验证——养成假设驱动调试的习惯。
  3. 学会用效能分析工具（cProfile / line_profiler）给自己的项目做一次性能剖析并写出报告。
  4. 每周读一份他人的代码（课程结对项目 / GitHub issue），尝试在不运行前先说出可能的 bug 在哪。
  5. 建立个人 bug 记录表：现象、根因、修复方式、如何避免再犯，期末复盘一次。

技能 4 · 软件设计（2 → 5）

  1. 课程项目开工前必须先写设计文档（模块图 + 接口定义），老师/同学评审通过后再动键盘。
  2. 学习并实践至少 3 个常用设计模式的真实使用场景（不是背定义），在自己项目里各用一次并说明为什么用它。
  3. 每完成一个模块，做一次"如果需求变了怎么办"的思想实验，把耦合点写下来。
  4. 精读《构建之法》第 11 章并做一份 API 设计规范清单，团队项目里强制执行。

技能 5 · 工具的使用（2 → 6）

  1. Git：本学期掌握 branch / merge / rebase / cherry-pick / 冲突解决，所有作业通过分支 + Pull Request 提交，不再直接推 main。
  2. 为仓库配置 GitHub Actions，做到每次 push 自动跑测试，红了就不许合并。
  3. 熟练使用 Markdown（含表格、代码块、Mermaid 流程图），所有文档不再用 Word。
  4. 学会写规范 commit message（约定式提交：feat/fix/docs/refactor/test）。
  5. 掌握一个包管理与虚拟环境方案（uv 或 conda），保证别人 clone 我的仓库后能一键跑起来（提供 README + 依赖锁定文件）。

技能 6 · 需求分析与用户沟通（1 → 4）

  1. 团队项目立项前，实际访谈至少 5 个目标用户，记录原话而不是自己的想象。
  2. 学会写用户故事（As a ... I want ... so that ...）和场景描述。
  3. 项目发布后主动收集反馈，至少拿到 20 个真实用户的使用记录或意见，并在博客里公开。
  4. 每次结对项目做一次正式的代码复审，学会"批评代码而不是批评人"的表达方式。

2.3 阅读心得

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

坦白说，我以前的默认状态是"人到场，心不在"。看完那篇学生的思考以及底下的评论之后，我意识到问题不在课，在于我一直把上课当成信息的单向接收，而没有当成一次可以消耗老师资源的机会。

老师是这个环境里唯一一个"提问不用付钱、问错不会被嘲笑"的资源。同样的问题我去问搜索引擎，要花两小时辨别答案真假；我问老师一句话，可能三分钟后就知道该往哪个方向走。放弃这个资源去自学，不是自主，是浪费。

所以我的答案很具体：我来上课，是为了把"我以为我懂了"的东西，在一个能被当场戳穿的环境里验证一遍。

b) 师生关系与作业困难时的选择

我过去两年体验到的主要是"授—受"型关系：老师讲，我记，考试考，我背。双方都完成任务，但没有真正的智力交锋。我在这门课上希望的是"健身教练与学员"的关系——老师负责设计有强度的训练和纠正动作，我负责真正练到位并如实反馈哪里练不动。这种关系的前提是学员不能装，教练也不必哄。

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

为什么不选其他：A（交钱了就该直接给及格）本质上是把自己当成消费者而不是学习者，四年之后市场不会认这张收据；B（觉得难就不做并去告状）放弃了成长机会还破坏了关系；D（只做保及格的部分）看起来理性，实际上是把"及格"当成了目标，而及格从来不是这门课的目标。

C 的成本确实最高。但软件工程这种技能型课程，难度本身就是训练量。我做过的事：作业卡住时先自己扛 30 分钟（避免变成伸手党），扛不过就带着"我已经试过 A、B，卡在 C"这样的具体问题去问，而不是问"这题怎么做"。

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

三者的区别不在"用了别人的东西"，而在是否透明、是否标注、是否经过自己的加工。

行为 是否声明来源 是否经过自己的理解与改写 性质
引用文献 是，明确标注 — 正当学术行为
参考开源代码继续开发 是，遵循其开源许可证并在 README/注释中注明 是，理解后集成或改造 正当工程行为
抄袭 / 剽窃 否，把他人成果表述为自己的 否 学术不端

具体到这门课，我给自己定的三条底线：

  1. 凡是复制的代码，必须在文件头注释里写清来源 URL、作者、许可证，并写一句"我改了什么"。
  2. 凡是引用观点、数据、图，在博客里贴出链接。本文的"前车之鉴"部分就是这么做的。
  3. 开源协议要读。MIT / Apache-2.0 / GPL 的义务不一样，GPL 的传染性在课程项目里也可能出问题——这一点我打算在课上向老师确认：课程项目引用第三方 GPL 代码是否允许，作业的原创性边界具体划在哪里。

学校对抄袭的处理规定我也查了并记住了：一经认定，通常是该课程成绩作废、记入档案、给予纪律处分，严重的会影响学位授予和保研资格。这笔账不划算到根本不需要犹豫。

2.4 未来选择与本学期规划

几年后的选项里，我的选择是：做软件项目，具体方向是 后端或AI应用开发。目标是这个学期能做出一个项目。

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

  • 方向明确且早。很多同学到大四才开始想"我要干什么"，我大三上学期就锁定了方向，这意味着我有整整一年多可以针对性积累。
  • 已经动手了。不是"打算学 AI"，而是已经在按路线学 LangChain 等框架，并且定下了主项目（一个求职/实习情报 Agent），这学期的课程作业可以直接为这个项目服务，不用两头分心。
  • 信息检索与自学能力经过验证（见 1.2）。

我的劣势（这部分我不想含糊过去）：

  • 代码量太少，工程经验近乎空白。没有做过多人协作项目，不知道真实团队里的沟通成本和代码腐化是什么感觉。
  • 数学与基础课偏弱。Agent 方向看着是"调 API"，但要往深走，概率、线性代数、模型原理绕不开，我目前只能停在"会用"层面，说不清"为什么"。
  • 英语阅读速度不够快。这个领域 90% 的一手资料是英文的（论文、官方文档、GitHub issue），我现在的阅读效率明显拖了后腿。
  • 没有拿得出手的公开产出。GitHub 上几乎是空的，这在实习筛选里是硬伤。

本学期规划：

  1. 主线项目：把"求职/实习情报 Agent"做到能公开演示的程度——有仓库、有 README、有部署地址、有至少 20 个真实用户的使用反馈。课程团队项目尽量与它技术栈对齐，实现一份时间两份产出。
  2. 基础补课：每周 8 道算法题 + 1 篇源码阅读笔记，不间断。
  3. 工程习惯：所有代码走 Git 分支 + PR + CI，杜绝"直接在 main 上乱推"。
  4. 公开输出：每两周至少 1 篇技术博客，学期末不少于 8 篇。
  5. 英语：每天 30 分钟读英文技术文档原文，不查词典先通读一遍再精读。

2.5 这门课的计划与 WOOP

对课程的期待。 参考美国本科和中国软件工程本科的教学方式，我最期待的不是"讲全知识点"——知识点我自己能看视频学会——而是三件我自学得不到的东西：

  1. 真实的团队协作压力。和一个不熟的人一起写代码，还要面对代码被别人评审，这种体验只能在这门课里获得。
  2. 有反馈的迭代。我想知道我写的东西在专业眼光下"差在哪"，而不是只有一个分数。
  3. 公开的用户检验。作业要求里提到"用户数量和反馈是项目重要的评价标准"，这一点我特别认同——它逼着我们面对"做出来没人用"这种最真实的失败。

我打算怎么度过这门课：不逃课、不拖作业、把每次个人/结对/团队项目当成简历上的一行来写。我想当助教——理由不是想加分，而是教别人是检验自己是否真懂的最快方式；如果我讲不清楚，说明我自己没懂。

当前代码量（精确到 100 行）：

语言 代码量
Python 约 【2000】 行
C / C++ 约 【1000】 行
Java 约 【1000】 行
JavaScript / HTML / CSS 约 【100】 行
合计 约 【4100】 行

入职一流软件/互联网/AI 公司需要多少代码量？ 网上流传的说法差异很大，从"1 万行能入门"到"10 万行才算熟练"都有。我自己的判断是：代码量是个必要非充分条件，更该看的是"独立写完并维护过的、别人真的在用的代码"有多少行。 一个写了 5 万行课设垃圾代码的人，不如一个写了 1 万行但有测试、有文档、有用户的人。我给自己定的目标是累计 1 万行以上。

从事高校教学科研呢？我了解到的情况是，高校岗位对代码量的要求远低于对论文、项目和教学能力的要求，但动手能力是门槛而非加分项——不会写代码的人没法带学生做系统类课题。所以对这条路径，代码量目标我会下调，但会把重心移到复现论文、开源科研工具上。

每周投入时间： 我打算平均每周在这门课上投入 12—15 小时（含上课时间）。其中上课约 3 小时，课后编码与阅读约 9—12 小时。

关于"以前浪费时间现在要发奋"，我选 D：比以前课要多很多，直到达到目标为止。

但我要给这个 D 加一个约束，因为光喊口号没用：这个"多"必须是有上限的、可执行的。我的做法是把它拆成"每天 2 小时雷打不动 + 周末 4 小时机动"，而不是"这周有空就多写点"。前者能坚持，后者一定失败。

代码量目标： 本课程结束时累计新增 15,000 行（个人项目 + 结对 + 团队），即约 每周 1,000 行。按 15 周计算。这个数字对我来说是有挑战性的——我过去两年加起来也没写过这么多。

WOOP

W — Wish（愿望）

在本课程结束时，我有一个能公开访问、有真实用户、代码质量和文档都拿得出手的 Agent 项目，并且我能在团队项目里承担核心开发角色，而不是打杂。

O — Outcome（结果）

想象学期末的那一天：我打开自己的 GitHub，提交记录是一整片绿，不是突击刷出来的，而是 15 周每天两三次的自然结果。我的项目有陌生人给我提了 issue，我认真回复并修好了它。团队答辩的时候，我能不看稿子把系统架构讲清楚，因为每一块都是我亲手写的。我把仓库链接放进简历，寒假投实习时，面试官顺着链接点进去，看到的不是一个空壳，而是一个真在跑的东西。那一刻我会觉得，大三这一年我没有白过——不是因为拿了高分，而是因为我第一次拿出了"证据"。

Ob — Obstacles（障碍）

内部障碍：

  • 静不下心，且我知道自己是怎么静不下来的。具体是：写代码遇到一个卡点（比如一个报错查不出来），焦虑上来，我会"顺手"打开 B 站或者刷手机，本意是"歇五分钟"，实际是四十五分钟。回来之后因为进度落后更焦虑，于是继续逃避，形成闭环。这是我最主要的失败模式。
  • 完美主义导致的拖延。总觉得"设计还没想清楚，先不写"，结果一周过去一行代码没有。
  • 基础差带来的挫败感。看别人几分钟解决的 bug 我要两小时，容易自我否定然后干脆不做。
  • 作息不规律。晚上精神好，早上起不来，导致上午的课和上午的自习时间被浪费。

外部障碍：

  • 团队成员进度不齐，我要么等别人（浪费时间），要么自己全干了（累死且学不到协作）。
  • 课程作业与考研/实习准备的时间冲突，大三下学期这个矛盾会很尖锐。
  • 宿舍环境不适合长时间专注，室友打游戏时我很难不受影响。

最可能的一项失败因素，以及怎么克服：

最可能让我失败的，是"遇到卡点就逃避到手机上"这个循环。

它危险在于：它不表现为"我不想学"，而表现为"我在休息"，所以我很难自我察觉，也很难被别人指出。一学期下来，它偷走的时间可能超过 200 小时——这足以让我从 D 掉回 B。

克服办法（不是靠意志力，是靠环境设计）：

  1. 学习时手机放到另一个房间，物理隔离，而不是"放桌上但不看"——后者我试过，无效。
  2. 卡住超过 25 分钟就必须站起来离开电脑，到楼下走一圈再回来，打断"焦虑—刷手机"的条件反射。
  3. 把"我卡住了"这句话写进 bug 记录表，而不是憋着——写下来这个动作本身就能降低焦虑。
  4. 每周日晚上花 10 分钟回看本周的实际投入时长（用时间记录工具，不靠回忆），如果连续两周低于 10 小时，立刻在下周一削减目标而不是硬撑。

P — Plan（if-then 风险防范计划）

如果出现的问题 那么我就采取的行动
程序没写完时我想开小差上网冲浪 立刻站起来，离开电脑和手机，到楼下走一圈（约 10 分钟），回来只做一件事：把当前卡住的那一行代码写进 bug 记录表
一个 bug 查了超过 25 分钟没头绪 停止自己死磕，带着"我已经试过 X 和 Y"去问同学或老师，或者去搜索并明确写下关键词；不再无限延长独处时间
我又想"等设计完美了再动手" 强制自己在 15 分钟内写出最丑但能跑的版本（先跑通再优化），用一次提交把它钉死，之后在这个基础上改
团队成员进度拖延，我准备把活全接过来 先把任务边界和 deadline 在群里写清楚并 @ 到人；如果对方仍不动，我只接管阻塞我自己的那部分，其余按原分工保留并如实向老师反映，不代做
早上起不来，上午的自习被浪费 前一晚 23:30 前把手机放到床边够不到的地方；把最重要的一件事安排到下午/晚上，不指望上午
期中之后我开始觉得"这门课投入太多不划算" 回去看一次自己第 1 周写下的这份 WOOP 和 Outcome 段落，并统计一次已完成的提交数——用事实而不是情绪来判断要不要放弃
我因为"别人比我强"而想放弃 只跟上周的自己比：看本周提交数和 bug 记录表条数，不看别人的项目

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

我按"一周 6 章、三周读完"的节奏快速通读了《构建之法——现代软件工程》（第三版，邹欣著，全书 17 章）。下面 5 个问题，是我读完之后真正没想通、或者不认同的地方。

问题 1｜第 2 章《个人技术和流程》2.3 单元测试

我看到的文字： 书中强调单元测试必须由程序员自己编写，要覆盖足够多的情况，并给出了"单元测试必须达到足够的覆盖率，否则就是耍流氓"一类的主张，同时反复强调测试要先想清楚边界条件、要写成能自动运行的形式。

我的问题： 在 2026 年，AI 已经可以在几秒内为一个函数生成一整套覆盖各种边界的单元测试。那么"程序员亲手写单元测试"这件事的价值，究竟在于"产出测试代码"，还是在于"被迫思考边界条件"这个思维过程？

我查了资料： 社区里有两种明显对立的说法。一种认为 AI 生成的测试"覆盖率数字很好看，但断言常常是错的或者无意义的"（典型问题是 AI 会把当前有 bug 的行为当成正确行为固化进断言）；另一种认为手写测试的成本太高，导致现实中大部分项目干脆没有测试，AI 生成再人工审查是更务实的路径。

我的经验： 我自己试过一次让 AI 给我的一个数据抓取函数写 pytest。它生成的用例在语法和结构上都很漂亮，但有一个致命问题：它假设了我代码里一个错误的行为是正确的，并把它写成了断言。如果我不逐行审查，我就会得到一个 100% 通过、但完全保护不了我的测试套件。

我的困惑： 如果测试的价值主要在"被迫思考边界"，那么在 AI 时代，是否应该改成"人负责列边界条件清单，AI 负责生成代码，人再审查断言"？书里的方法论写于 AI 辅助编程普及之前，它需不需要一条新的补丁？如果需要，这条补丁的具体形式是什么——是降低手写要求，还是提高审查要求？我没有想清楚。

问题 2｜第 3 章《软件工程师的成长》3.1 软件工程师的职业发展

我看到的文字： 这一节给出了软件工程师从"菜鸟"到"专家"的能力阶段划分，强调程序员的核心竞争力在于扎实的编程基本功、对问题的分析能力和持续的成长，并把成长路径描述为一个能力逐级跃迁的过程。

我反对（或部分不同意）的地方： 我认为书中这套能力模型的权重分配，在今天的 AI 应用开发岗位上已经不完全成立了。

作者的观点（我的理解）： 编码基本功是最底层、最重要的能力，越往上走越依赖它。

我的观点： 在 Agent 应用开发这个具体岗位上，我观察到的能力权重更像是：问题定义能力 > 系统设计与工具编排能力 > 编码基本功。理由是，这类岗位大量的工作是"把一个模糊的业务需求，拆解成 prompt、工具调用、状态管理和错误兜底的组合"，而单点代码的难度往往不高，甚至大部分可以由 AI 辅助生成。

支持我的事例： 我自己在做求职情报 Agent 时，卡我最久的从来不是"这个函数怎么写"，而是"用户到底要的是岗位聚合还是岗位筛选"、"抓取失败时应该重试、降级还是直接告诉用户"。这些是设计问题，不是编码问题。

但我也不否认作者： 一旦系统复杂度上去（并发、状态一致性、成本控制），基本功不足就会立刻暴露。

所以我的真正问题是： 书里的成长阶段模型，是否需要针对不同岗位类型给出不同的能力权重曲线？对一个明确要走"AI 应用工程师"而不是"底层系统工程师"的学生，大三这一年应该把有限的时间优先投给哪一项？我希望老师能就这个具体的取舍给一个判断，而不是"都重要"。

问题 3｜第 6 章《敏捷流程》6.3 敏捷的流程 / 每日例会（Daily Standup）

我看到的文字： 书中介绍了敏捷开发中的每日例会制度，强调它应当简短（站着开、控制在很短时间内）、每人回答三个问题（昨天做了什么、今天打算做什么、遇到什么障碍），目的是同步信息、暴露风险，而不是汇报工作。

我的问题： 在"课程团队项目"这个特定场景下，每日站会几乎注定会退化成形式主义，书里有没有给出针对这种情况的替代方案？

支持我提问的具体事实：

  1. 课程团队成员不住在一起、课表不同、有各自的其他课程和考研/实习安排，每天找到一个所有人都在线的 15 分钟窗口的成本极高。
  2. 学生团队的开发不是全职的，很可能一个人两三天没有代码进展——这时站会上的回答必然是"昨天没什么进展"，连续几天如此，会议的信息量趋近于零。
  3. 书里描述的敏捷团队是全职、共处一地、目标单一的专业团队，这三个前提在课程项目里一个都不成立。

我的困惑（不是反对，是真的不会做）： 如果照搬每日站会，我们大概率会开成"每天打卡"；如果不开，又缺少同步机制，很可能到集成时才发现彼此的接口对不上。在学生团队的约束下，什么样的同步频率和形式才是有效率的？ 是改成每周两次？还是用异步的文字站会（每天在群里发三行）？异步文字站会算不算违背了敏捷"面对面沟通优先"的原则？这个问题我希望在团队项目开始前就得到答案，因为选错了会浪费掉好几周。

问题 4｜第 8 章《需求分析》8.1 需求分析的方法 / NABCD 框架

我看到的文字： 书中给出了 NABCD 框架：Need（需求）、Approach（做法）、Benefit（好处）、Competitors（竞争）、Delivery（推广/交付），并强调要从用户的真实场景出发，通过访谈、观察等方式挖掘需求，而不是凭想象设计产品。

我的问题： 当产品本身是"用户从未见过的新交互形态"时，NABCD 里的 N（Need）还能通过用户访谈得到吗？

为什么我会问这个： 我做的是 Agent 类产品。我实际访谈过几个同学，问他们"你需要一个什么样的求职助手"。得到的回答是"能帮我投简历就行"、"能提醒我 deadline"。但没有任何一个人主动提出"我需要一个能自动监控岗位变化并告诉我该改哪部分简历"的东西——因为我没做出来之前，他们想象不到这个东西存在。

我查到的说法： 亨利·福特那句被反复引用的"如果我问用户想要什么，他们会说想要一匹更快的马"（这句话的真实性本身有争议，但现象是真实的）；以及《启示录》一类产品书里提到的"用户能说出痛点，但说不出解法"。

我的困惑： NABCD 的 Need 如果只来自用户访谈，那么在创新型产品上就会系统性地低估需求、做出"更快的马"。但如果允许开发者凭直觉定义 Need，又回到了书中批评的"闭门造车"。这两者之间的边界在哪里？ 具体来说：在学生团队项目里，当我访谈得到的需求和我的技术直觉冲突时，我应该听哪个？有没有一个可操作的判断标准，而不是"具体情况具体分析"？

问题 5｜第 16 章《IT 行业的创新》

我看到的文字： 这一章讨论了创新的来源和形式，指出创新并不总是灵光一闪的突破，更多时候是渐进式的改良、组合与迭代；同时讨论了创新的时机、团队环境以及大公司创新为何常常失灵等问题。

我的问题： 书中"渐进式创新为主"的判断，在生成式 AI 出现的这一轮技术变化中是否被证伪了？

我提这个问题的原因，是书中的描述和我的间接经验矛盾：

  • 书里的框架建立在对过去几十年 IT 行业的观察上：技术演进大体是连续的，颠覆性变化之间存在较长的稳定期，所以"持续改良 + 抓住时机"是最优策略。
  • 但 2022 年底以来我看到的现实是：能力出现了非连续的跳变。一个在 2021 年需要一整个团队做几个月的项目，在 2023 年之后可能一个人两周就能做出来；而一些当时看起来很有价值的技术路线（例如某些手工设计的对话流程系统），在新一代模型面前直接失去了存在意义。

我的困惑： 如果技术演进存在阶段性断层，那么"渐进式改良"在断层附近可能是在优化一个即将过时的东西。作为一个大三学生，我的时间只有一份：我应该按书中的建议踏实做渐进式积累（打基本功、写好代码），还是应该更激进地去追新范式（哪怕基础不牢）？ 这两者在时间上是直接冲突的。书里没有给出判断"什么时候该追新、什么时候该守基础"的标准，而我觉得这恰恰是学生最需要的那个标准。

关于课程反馈，我选 D：经常提问，平时就给老师和助教提反馈。

理由很实际：作业里说这是"健身/教练"的关系。教练调整训练计划的前提，是学员如实说"这个动作我做不动"、"这里练完疼得不正常"。如果我作为学员什么都不说，教练只能按标准计划走，那么浪费的是我自己的一个学期。

我给自己的具体承诺：

  1. 本学期至少提 3 个有内容的问题（本篇的 5 个问题算第一批），并且不只提问题，还会跟进后续——如果老师给了答案而我还是不懂，我会继续问。
  2. 每次收到反馈问卷都按时、认真填写，写具体现象而不是情绪。例如不写"作业太多"，而写"结对项目第二周我实际花了 11 小时，其中 6 小时在等队友提交接口，建议把接口定义的 deadline 提前"。
  3. 平时就反馈，不等到期末。发现课程节奏、作业说明、评测标准上有歧义，当天就在博客评论或课堂上提出来——因为这类问题拖到期末就失去改进价值了。

四、前车之鉴

我从作业给出的博客列表里选了三篇细读，因此我改选了同为"半路出家/基础与速成"主题的另一篇。

感想一｜辜新星《时刻调整方向 找到人生的蓝海》

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

这篇里最戳我的不是北大光环，而是两件小事。

第一件是他大一当"社团狂"，每周光例会就有三个半，然后高等数学期中考试不到 80 分。他写的"一纸惊醒梦中人"，我在自己身上看到过同样的东西：忙不等于有产出，忙甚至是一种很舒适的自我欺骗——因为忙的时候你不用面对"我到底学会了什么"这个问题。

第二件是那位师兄给他的方法：把每天要做的事分成 A（紧迫且重要）、B（重要不紧迫）、C（紧迫不重要）、D（不重要不紧迫） 四类，然后给每件事安排一段专属时间，在这段时间里只做这一件事。

我有类似的习惯吗？老实说，没有稳定的。 我用过 ToDo 类 App，但只记 A 类和 C 类（有 deadline 的事），从来不记 B 类。而这篇博客恰好点出了我的要害：B 类才是真正拉开人和人差距的东西——刷算法题、读源码、写博客、补数学，这些都不紧迫，所以永远排在最后，所以永远不做。我的 2.5 节 WOOP 里那个"每天 2 小时雷打不动"，本质上就是把 B 类强行伪装成 A 类（给它一个每天固定的时间约束）。这是我读完这篇之后对计划做的一处实质修改。

另外，他求职只投了十家公司，因为在求职季开始之前就定了目标并针对性准备。这一点对我很重要：我目标定得早（2027 寒假实习），但如果我不像他那样"针对目标做各种准备"，早定目标就只是个心理安慰。

感想二｜刘帅《在失望中寻找希望》

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

"我是科班——却没学懂计算机"，这句话我读了好几遍。他列出的课程清单——数据结构、编译原理、操作系统、汇编、计算机原理、系统结构、离散数学、概率论、计算机网络、数据库——我修过的和即将修的，几乎是同一份清单。而他每学期都拿奖学金，毕业三年后回头说"我并没有学懂计算机"。

他对自己本科状态的描述，我几乎可以逐句对上号：

"我总是认真听老师讲课，每次上课从来不预习，从来不会计划这学期我要干什么、这堂课我要干什么，我机械地听着每一节课，机械地在迷糊中重复着作业、考试。"

这段话之所以让人不舒服，是因为它描述的是一个"好学生"。成绩不错，拿了奖学金，没逃课，作业独立完成。但独立完成的作业是"沿着老师讲过的固定模式稍微变换"，不是主动从多个角度找解法。我以前一直以为"独立完成作业"就是努力的证明，读完才知道，独立完成 ≠ 独立思考。这是我在这篇里最大的一个认知修正。

他后来旁听清华朱仲涛老师的数据结构课，那堂课现场从零实现凸包算法、写完一次编译通过、全班鼓掌两分钟。让他震撼的不是算法本身，而是他意识到："凡是自己不理解的东西，其实有很多人是理解的"，只是"我的老师没有给我必要的关键性指导"。

我的收获是一条很具体的行动：不懂的时候，任何时候都可以去问，从而节省大量时间。他在结语里写"你不会的知识，你懒于想通的东西，总是会在一个必要的时候提醒你、惩罚你"——那个"必要的时候"，通常就是面试现场。他面"完美时空"那一段几乎是一场公开的解剖：被问 Java 如何实现 const、被问 Lucene 索引怎么实现，答"没看过"。他总结自己一贯的问题是"知其然不知其所以然"。

这正是我在 2.1 节里承认的第 2 条差距。所以我把"每周 1 篇源码阅读笔记"写进了提高手段——不是为了写笔记，是为了强迫自己从"会调用"走到"知道它内部怎么实现"。

感想三｜荆棘人《.net 程序员工作两年总结》

链接：http://www.cnblogs.com/Tpf386/p/4798437.html

这一篇对应作业列表里"速成的培训班和打基础的大学教育有区别么"这个问题。作者是机械制造专业大专毕业，在工厂干过大半年，2011 年转行学编程。

这篇最珍贵的地方是它写的不是成功，是失败。他在第一个培训班耗了整整一年多：70 多个同学报名，最后坚持下来的不到 15 个。他自己描述的状态是"只看视频，不怎么做练习"、"过完年又忘记一部分"、"常常在家打魔兽，一边受了良心煎熬"。

他事后总结的那句话，我认为是全篇最有价值的一句：

"人在学习时常常高估自己的能力。编程不是高中背书，不是做数学化学题，它是技能，是需要大量练习和长时间实验感悟的。"

还有一个细节让我印象很深：他为"为什么一行语句后面要加分号"纠结很久，等老师 30 多分钟过来看一眼，老师说"这不是很明显吗？少了个分号"。他写道："老师不知道完全无基础的人的无知程度。"

这直接回答了我对师生关系的疑问：老师不是不愿意教，是他无法预知你卡在哪里。所以问的时候必须把自己卡住的具体位置说出来，而不是笼统地说"我不会"。这也印证了我在 2.3 b) 里写的做法——带着"我已经试过 A、B，卡在 C"去问。

最后是他列出的那 40 多道面试题。看完我最大的感受是：这些题几乎没有一道是"背了就能答"的。聚集索引和非聚集索引的区别、Session 存在哪里、垃圾回收的过程、Lucene 索引为什么能提速——全是"知其所以然"类的问题。他自评"两年经验没有特长"，而原因在他自己文中已经写明：前期靠看视频速成，跳过了动手练习。

对照作业列表里 E 项原本想问的"速成培训和大学基础教育有没有区别"，我读完这篇的答案是：区别不在课程内容的深浅，而在于是否有人在你卡住时纠正你、以及是否强制你动手练习。培训班失败的原因不是内容差，而是（在他这个案例里）缺少老师、缺少练习、缺少反馈——这三样恰好是大学课堂本来应该提供的。所以"我看视频也能学会，为什么来听课"这个念头，在这篇里被证伪了：他看了一年多视频，没学会。

附录：GitHub 仓库与截图

GitHub 仓库地址： https://github.com/doki475/doki

截图：

[
屏幕截图 2026-09-06 142539
]

屏幕截图 2026-09-06 142715

参考与引用

本文所有引用均已在正文对应位置注明来源。文中未标注来源的判断（如对代码量门槛的看法、对能力权重的判断）属于我个人的定性推测，不是事实陈述，欢迎反驳。