1 经过大半学期的实践，你在学期初提的问题都能自己回答了么
在第一篇博客中，我提出了以下 5 个问题：
“最好在设计的时候就写好单元测试”，难道不会让我们陷入过度设计的陷阱吗
这个问题其实在我发布第一篇博客之后，就在评论区得到了解决。我们可能没有必要追求在设计之初就编写单元测试，但是编写测试还是必不可少的。某种程度上，测试也算是另一种文档，它回答了关于我们的项目一个重要的问题：满足什么条件，我们的代码才算是 work 的？所以，追求写出完美的单元测试确实是会走入过度设计的误区，但是这并不意味着我们可以省去测试。
结对编程是一个很理想的做法。如果两个人水平接近，那容易出现俩人都看不出来的问题；如果有一个人水平明显高出来很多，那这个时候另一个人的存在就没什么意义
这个问题我不太好回答，毕竟我其实并没有经历结对编程。不过我倒确实在一开始以为要开始结对编程的时候，考虑过很多怎么和搭档配合的具体情况，结果是越想越觉得我可能没法很好地参与到这个过程中，因为我实在受不了我自己在旁边光说不练或者是有一个人在我干活的时候在一边叨叨个不停。所以，结对编程到底是不是一个理想的做法 in general，我持保留态度，但是我确信它并不适合我。
开源社区的团队模式该怎样去做权衡
现在看来这是一个很没有营养的问题，因为这就是个个人的价值观的问题，没有任何一种百分百好的团队模式，否则现在的开源社区也不至于有这么多异彩纷呈的团队结构。不过至少对于我自己而言，我慢慢确信了我更希望成为一名独裁者类型的维护者，因为我愈发发现我对自己的项目有一种奇怪的洁癖，我真的是会很嫌弃那些不太符合我的审美偏好的新功能（虽然我嘴上不会这么说）。
什么样的用户才可以算是“典型用户”
具体来说，我一开始是在担心设计“典型用户”的时候过于钻牛角尖，比如过度防御潜在的恶意用户，但事实是我发现这有些多虑了。我们的团队项目真的是会把 API key 甚至是 database 直接 git track（虽然后续抹掉了 db），但 so what？我们的几十上百个用户完全没有对我们的 API key 表现出什么兴趣。所以还真没必要设计一个典中典的典型用户，小步前进快速迭代才是更好的策略。
如何写好 spec
当初我不太确定到底该写详细的 tutorial 还是一个相对简单的 API reference，毕竟任何一种工作量都不算太小。不过，反正现在 LLM 也可以帮忙了，所以显然我可以直接二者兼顾，Q.E.D
2 对于 AI 时代的软件开发，又有了新的问题
虽然这可能也是一个老生常谈的问题了，但是我还是很想问，对于 vibe coding 这种在完成项目之余可能产生 a ton of 我并不需要的代码的编程方式，该怎么看待？
我自己特别排斥 AI 编程，我甚至是在今年下半年才开始用 AI 写代码，而且我几乎只会让 AI 帮我生成一个小功能，代码量不能太大；即使这样，我还要一行一行把 AI 生成的代码过一遍，重新设计一下结构，这样我往往能删掉一半左右的我不需要的代码。我本来以为这样可能是一个通用的范式，但是我发现好像真的会有项目纯 vibe coding，没有人工参与，然后项目里就多了很多冗余的代码，我在参与进这种项目之后如果要添加一些新的功能会非常难受。本质上可能还是 AI 的能力没有那么好或者是 prompt 写得一般造成了项目质量问题，但是在可预期的时间内、AI 似乎没有办法在编码能力上得到质的飞跃的情况下，过分信赖 AI 和 vibe coding 不是会造成更大的技术债务吗？
我认可 AI 编程在很多情境下带来的效率提升，但是现在真的把 vibe coding 当作一种 serious 的开发流程，是不是仍旧为时尚早？
3 这个学期的各种教学方法对你的价值，以及和你理想中的学习环境的差距
- 以公开博客来交作业的方法，千帆竞发图的跟踪：公开博客让我得到了很多的互动，包括一些问题让我得到了一些我自己可能想不到的回答，很好地拓展了我的思维；千帆竞发图于我而言倒是谈不上什么很大的价值，但这作为一种反馈机制确实是很棒的设计
- 结对编程的 API 驱动的编程：不太喜欢；前文我说过我不太喜欢结对编程，至于 API 驱动的编程，这个 API 文档内容有些不够清楚，我花了相当多的时间去读源码
- pq-问答的当堂测试，对软件 UX 的现场测试等：是很棒的策略，和用户的直接交流可以帮助开发者走出“当局者迷”的困境
- 学生自行组队并选择项目：我其实并没有参与这个环节，因为我在学期初就已经加入了项目，不过我想这个过程也是给予了大家很大的自由度
- alpha 阶段后强制团队有人员变动：我不太理解这个过程的作用是什么——不过我其实并没有意识到这件事情的发生，因为似乎没有人告诉我谁被踢出去了
- 请业界的专家、相关的老师、工程师来讲课 + demo：这是一个非常非常珍贵的机会，虽然专家们讲的内容我可能并不懂，但是了解他们思考问题的角度、聆听他们在产品开发过程中的一些经历，可以让我学到很多东西
- 用 ‘天使投资’ 的方法来评选成功的团队项目：我其实是不太认可投票的方式的，因为这种方式的前提是大家真的能够客观做出评价，而排序这种方式其实是投票中尤为困难的一种形式，也许对于排名很靠前和很靠后的团队来说这种方法行之有效，但是对于中间的团队，这种方式难免会促成一种“中庸”的选择，排名未必真的反映这些团队项目的好坏
4 在课前/课后提高最大的几个部分
- 第一维：AI模型全栈与权衡能力
- 第二维：AI原生架构与沟通设计
- 第三维：云原生与约束工程化
- 第四维：开源协作与需求转化
- 第五维：智能开发与人机协同
- 第六维：工程领导与系统权衡
对于我来说，提升最大的可能是“智能开发与人机协同”和“工程领导与系统权衡”，因为课程期间我不可避免地接触到了一些我不是很熟悉的技术，所以我需要大量向 AI 进行提问，这个过程中我编写 prompt 的能力也是有了较大的进步；而且这也是我第一次真正意义上参与到团队开发中，算是一个从无到有的过程。