个人博客作业 3

个人博客作业 3

1. 经过大半学期的实践，你在学期初提的问题都能自己回答了么？请回答你自己的问题。在博客中要加上当初博客的链接。

当初博客的链接：阅读《构建之法》提出的5个问题 - Surreal_Blog - 博客园

在学期初阅读《构建之法》时，我提出了5个关于创新、团队和技术的疑问。经过大半个学期的软件工程实践（特别是我们的笔记阅读插件开发项目）以及在项目组的科研探索，我对这些问题有了新的理解。以下是我的解答与反思。

(1) 关于“颠覆式创新”的应对

回顾：当时我困惑于大公司如何在“短期绩效”与“长期颠覆”中平衡。

现在的回答：“双模态组织（Ambidextrous Organization）”可能是解法，对于成熟公司，大部分资源确实需要用于改良式创新（如修 Bug、优化现有 UI），以维持生存和用户满意度。但应对颠覆，不能靠全员转型，而是需要“隔离”。就像实验室里的前沿探索一样，颠覆式创新需要一个小规模、容错率高、甚至初期不看重 KPI 的独立团队去“试错”。平衡不在于让同一个人既做维稳又做颠覆，而在于组织架构上的资产配置。

(2) 关于“好的想法为什么不一定赢”

回顾：该“顺势而为”还是“逆势而行”去改变用户习惯。

现在的回答：在开发笔记插件的 Beta 阶段，我深刻体会到了“转换成本（Switching Cost）”的威力。即便我们的功能在逻辑上更优，但如果用户需要改变哪怕一点点原有的高频操作习惯（比如快捷键差异），他们都会产生抵触。因此，我的答案是：创新初期必须“顺势”，核心价值必须“逆势”。在交互和入门门槛上，必须最大程度兼容现有习惯（顺势），降低用户的认知负荷；但在核心价值主张（Value Proposition）上，必须提供现有产品无法提供的体验（逆势），只有当（新体验收益 - 转换成本 > 0）时，好的想法才会赢。

(3) 关于“专家 vs. 跨界新手”

回顾：作为学生是该深耕还是跨界。

现在的回答：这学期的经历告诉我，“专家”负责实现的深度，“跨界者”负责定义的广度。在学院的项目组中，我发现，如果没有神经科学的专家知识，模型难以处理异构的高噪声脑信号；但如果没有AI背景的“外行”引入大模型思维，传统解码方式也很难进一步取得突破。作为学生，目前的策略应该是 T 型发展：先在 AI/软件工程某一领域成为“专家”（深耕），建立核心竞争力，然后保持对其他领域（如产品设计、心理学）的“跨界好奇心”。创新往往发生在“将 A 领域的成熟方法应用到 B 领域”的瞬间。

(4) 关于“技术创新 vs. 非技术创新”的权衡

回顾：资源该如何分配给商业模式或用户体验。

现在的回答：在软工项目的实际推进中，我发现技术往往是“下限”，而非技术因素决定“上限”。我们组的插件技术实现并不算最顶尖的黑科技，但我们花了很多时间优化“用户如何借助插件阅读和编辑笔记”这一流程（非技术体验创新），结果用户反馈极好。反之，如果技术很强但流程繁琐，用户根本不会用到核心功能。我的结论是：在产品从 0 到 1 阶段，非技术创新（验证需求、优化体验）更关键，它决定了方向是否正确；在从 1 到 100 阶段，技术创新（性能、并发、稳定性）更关键，它决定了产品能跑多远。

(5) 关于“技术成熟度曲线”的判断

回顾：何时该跳入新技术的浪潮。

现在的回答：与其盯着虚无缥缈的“曲线位置”，不如看“落地案例的ROI（投资回报率）”。通过观察现在的大模型应用，我发现当一个技术开始从“媒体头条”转移到“开发者文档”和“垂直领域案例”时，就是进入“启蒙上升期”的信号。作为开发者，最好的切入时机不是在期望膨胀的最高点（那时全是泡沫），而是在泡沫破裂后，看到有具体、小型的成功落地场景出现时。这时候投入，既规避了最大风险，又能享受到技术逐渐成熟的红利。

2. 如果一些问题没有得到回答，或者困惑越来越大了，请说明

(1) “伪需求”的量化识别难题：

在阅读《构建之法》时，我可以事后诸葛亮地分析 Iridium 是失败案例。但在我们自己的项目中，当且仅当代码写完、产品上线后，我们才能确切知道某个功能是否多余。在开发前期的需求分析阶段，除了依靠直觉和简单的访谈，有没有更工程化、更低成本的方法来极其精准地证伪一个需求？ 尤其是在 AI 应用中，很多需求是“看起来很酷”但“由于概率性不可控”而无法成为刚需的。

(2) 技术债务的边界：

为了赶 Beta 版本的 Deadline，我们不得不写了一些“临时代码”。我知道这是技术债务，书上也说要还。但在快速迭代的互联网模式下，有些代码可能永远没机会重构产品就下线了。到底什么样的技术债必须马上还，什么样的债可以赖掉？ 这种决策在现实中似乎更多靠 Tech Lead 的直觉，而非具体的工程指标。

3. 对于 AI 时代的软件开发，又有了新的问题？请说明

(1) 既然AI能生成代码，初级程序员的“练手”路径在哪里？

《构建之法》强调了“做中学（Learning by doing）”和代码量的积累。但现在，作为学生，我们大量的 Curd（增删改查）代码和基础算法都可以由 AI 秒级生成。

• 如果跳过这些基础训练，我们是否会失去对底层逻辑的深刻理解？
• 未来的软件工程师培养体系，是否应该从“写代码”转向“审查代码”和“设计系统”？我们该如何重新定义“基本功”？

(2) 如何测试“概率性”的软件系统？

传统软件工程基于“确定性”逻辑——输入 A 必然输出 B。我们编写的单元测试也是基于此断言。

但现在的软件越来越多地集成 LLM（大语言模型），其输出具有概率性和不确定性。

• 我们该如何构建针对 AI 应用的测试体系？
• 当软件的核心逻辑是一个黑盒模型时，传统的 CI/CD（持续集成/持续部署）流程和质量保证（QA）标准该如何适配？

(3) “提示词工程（Prompt Engineering）”会成为软件工程文档的一部分吗？

以前我们写需求文档、API 文档。现在，一段复杂的 System Prompt 实际上定义了软件的功能和边界。

• Prompt 应该被视为“代码”进行版本管理，还是被视为“文档”？
• 在多人协作的项目中，如何管理 Prompt 的变更和回归测试？这似乎是当前软件工程方法论中的一个空白地带。

4. 学期当初，老师传递了 NCL 的理想教学环境， 当学期趋近结束时，请你点评这个学期的各种教学方法对你的价值，以及和你理想中的学习环境的差距

在课程结束之际，回顾整个学期，这门课确实构建了一个极度接近真实职场市场的模拟环境（NCL）。相比于传统的“老师讲、学生听、期末一张卷”，这种高强度的互动与反馈机制让我印象深刻。

(1) 以公开博客来交作业，千帆竞发图的跟踪

这是我第一次体验这种“开源社区”式的作业提交。它的最大价值在于打破了信息孤岛。以往作业只有老师看，写得好坏无所谓；现在全网公开，不仅有同伴压力（Peer Pressure），更有一种“作品感”。“千帆竞发图”带来了一些分数焦虑，但它客观反映了在课程不同阶段的投入与进度的变化，让学生能够及时查缺补漏，追赶进度。

(2) 结对编程的 API 驱动的编程

这是对“代码洁癖”和“沟通能力”的双重磨练。在开发初期，我们被迫先定义 API 接口，这直接治好了我以前“想哪写哪”的毛病。结对过程中，领航员（Navigator）和驾驶员（Driver）的角色切换，让我意识到：写代码最难的不是语法，而是向另一个人解释清楚你的逻辑。

与理想环境的差距： 理想：两个人能力互补，能够产生 1+1>2 的心流体验。 现实：有时候双方进度或技术栈差异过大，会导致变成了“一个人写，一个人看”的尴尬局面。

(3) pq-问答 的当堂测试，对软件 UX 的现场测试等

通过 pq-问答 可以即时了解自身是否理解了课程所授的内容，也便于在课后需要时进行回顾。

(4) 学生自行组队并选择项目

给予了我们极大的自主权。正因为是我们自己选择了做“笔记阅读插件”，且这个项目确实是为了解决我们自己作为学生的痛点，所以整个学期团队的内驱力非常强。我们不是在“做作业”，而是在“做产品”。

与理想环境的差距： 理想：跨学科组队，比如商学同学做 PM，设计学同学做 UI，计科同学做 Dev。 现实：同学大多是 AI/CS 背景，思维模式趋同，导致在商业模式设计和 UI 审美上容易出现短板，缺乏多元视角的碰撞。

(5) 请业界的专家、相关的老师、工程师来讲课 + demo

打破了象牙塔的围墙。特别是看到业界工程师讲解真实的 DevOps 流程或架构演进，让我看到了我现在写的代码和企业级代码之间的鸿沟。

(6) 用 ‘天使投资’ 的方法来评选成功的团队项目

这是一个神来之笔。它把评分标准从“代码写得难不难”变成了“产品是否有市场价值”。这迫使我们从技术思维（Feature）转向产品思维（Benefit）。我们必须学会 Pitch，学会讲故事，学会证明我们的插件能留住用户，这对于我这种理工科思维重的学生是极大的补充。

5. 根据这个自我评价表，快速评价一下自己在 课前/课后 提高最大的几个部分 （自己选择）。 评价表： 现代软件工程 课件 软件工程师能力自我评价表 - SoftwareTeacher - 博客园

(1) 维度一：AI模型全栈与权衡能力

考察点1：需求导向的算法设计与分析

• 课前状态 (Level 1 - 理论认知者)
  • 自我评价：受科研思维影响，我以前极度看重模型的“准确率”或算法的“复杂度”，总想用最先进（SOTA）的模型，而忽略了实际应用场景。
• 课后状态 (Level 2.5 - 基础实践者/场景适配者)
  • 自我评价：在做笔记插件时，我意识到“用户体验”比“绝对技术指标”更重要。
  • 提升实证：例如，在实现笔记分析功能时，虽然用超大模型效果最好，但推理延迟太高，用户等不了。我们最终权衡选择了“轻量级模型 + 规则引擎”的方案，牺牲了一点点准确度，但换来了秒级的响应速度。这个过程让我学会了在“业务需求（快）”与“技术指标（准）”之间做工程权衡（Trade-off），而不仅仅是追求分数的刷榜。

(2) 维度二：AI原生架构与沟通设计

考察点4：模块化架构设计与隐性知识的处理

• 课前状态 (Level 1 - 功能收集者)
  • 自我评价：以前写代码主要为了跑通实验或交作业，代码结构随意，几乎没有文档。我认为“代码即文档”，觉得只要自己能看懂就行。隐性知识（如环境配置、特殊逻辑）全在脑子里，没有显性化。
• 课后状态 (Level 2.5 - 接口契约制定者)
  • 自我评价：在在完成各自任务后同步代码的过程中，我深刻体会到了“无文档代码”带来的灾难。其他的同学难以看懂我的更新内容，导致交接极其痛苦。
  • 提升实证：在 Beta 阶段，我被迫开始尝试“文档先行”。在开发新功能前，先定义好 API 接口文档（Markdown 格式），并注明了模块间的依赖关系。虽然还没达到“架构师”级别，但我已经从“为了自己写代码”转变为“为了团队写代码”，学会了通过文档来降低沟通成本。

(3) 维度五：智能开发与人机协同

考察点13：高效的人机结对编程实践

• 课前状态 (Level 1 - AI 辅助编程探索者)
  • 自我评价：虽然我是AI专业的，但此前用 ChatGPT 写代码主要是“生成-复制-粘贴”。遇到Bug就把报错丢给AI，如果AI修不好就卡住了。我把 AI 当作一个搜索引擎或代码生成器，缺乏主动的引导。
• 课后状态 (Level 3 - AI 对话工程师)
  • 自我评价：在结对编程和高强度的插件开发中，我逐渐摸索出了“Prompt Engineering for Code”的方法。
  • 提升实证：现在我不再让 AI “直接写一个插件”，而是学会了提供上下文（Context）。例如，我会先把现有的项目文件结构、相关的接口定义发给 AI，然后描述：“基于这个类结构，帮我实现XXX功能，注意异常处理”。我也开始能识别 AI 生成的“幻觉代码”（比如不存在的库函数），并能反向引导AI修正逻辑。我从单纯的“使用者”变成了 AI 的“驾驶员”。