[docs]: update closing ceremony speech

Author: Nliver

2025/17. 实训营心得分享/share.md renamed to 2025/17. SPX-Algorithm：构建多模态搜索服务的一些心得/share.md

@@ -0,0 +1,96 @@
+# 许式伟：AI 时代重塑软件工程
+
+在第四期1024实训营结营仪式上，实训营发起人许式伟先生以《AI 时代重塑软件工程》为题，为全体学员和在线观众带来了一场深度分享。他从软件工程的基础理论出发，深入剖析了AI技术对软件工程领域的深刻影响与重塑。以下是演讲全文：
+
+# 正文：
+
+本期实训营的分享，与前三期有着显著的不同。在前三期中，实习生几乎无人使用 AI 编程；而这一期，每个团队都已大规模采用 AI coding。这一变化并非偶然，而是时代演进的必然结果。
+
+1024实训营，本质上是在探索软件工程的最佳实践。然而，当参与实践的学员——这些尚未成型的工程师——其开发方式已在短短一两年间发生根本性转变时，我们就无法再回避一个关键问题：**在 AI 深度介入编程的今天，软件工程本身是否正在被重新定义？**
+
+过去，我们谈“如何成为优秀的工程师”；今天，我们不得不谈“如何在 AI 时代做好软件工程”。我反复思考这个问题后得出一个结论：AI 正在彻底重塑软件工程的底层逻辑。许多我们曾视为理所当然的工程原则，在 AI 时代可能不再成立。
+
+正因如此，本期结营我选择了一个截然不同的主题。这不是一次技术工具的更新讨论，而是一场对工程范式的重新审视——我们必须以更严肃的态度，直面这场正在发生的范式革命。
+
+## 软件工程铁三角：工程、设计与商业
+
+在深入探讨AI的影响之前，我们有必要回归软件工程的基本理论框架。我认为软件工程的范畴始终围绕着三个核心层面：工程、设计与商业。
+
+**工程**是一门关于“如何把事做成”的学问。它的核心方法论包含三个要素：模块（拆解复杂问题）、版本（迭代逼近目标）和分工（团队协同）。这是大多数技术人员最为熟悉的部分。
+
+**设计**远不止于产品包装或UI界面，它本质上是一门关于“决策”的学问——要做什么事，以及把事做成什么样子。从战略设计、组织设计到产品设计、架构设计，每一个环节都需要精准的决策。
+
+**商业**则是所有事情的源头。商业不一定是赚多少钱，但它一定绕不开社会价值。商业好不好，最终的衡量标准是 ROI（投资回报率），这里可以用公式表达：`ROI = 社会价值/实现代价`。即用更低的成本实现更大的社会价值，这就是商业的本质。
+
+在这个框架下，我们才能理解为什么顶级产品经理做的是“减法”，而顶级架构师做的是“乘法”。
+
+好产品的定义是：**用最少的功能，实现最大化的需求覆盖**。“少就是指数级的多”不仅是Google创始人的理念，更是产品设计的黄金准则。就像计算机的 CPU，五十多年来其内部实现不断迭代，但规格接口几乎保持不变——这种“封闭性”恰恰是好产品的特征。
+
+架构设计之所以比产品设计更难，是因为它极度“逆直觉”。当我看到团队 Leader 简单地按照页面分配任务（页面A交给张三，页面B交给李四......）时，就知道这样的架构设计通常是错误的。**真正好的架构设计是在做“乘法”**，它要求每个模块都应被当作一个“子业务”来设计——**有独立需求边界、高复用性、低耦合。就像搭乐高，积木种类越少、拼装步骤越简、外部依赖越成熟，系统就越健壮**。
+
+
+## AI时代：“人月神话” 的终结
+
+在《许式伟的架构课》第74节中，我曾提出一个思想实验：假设一家公司只保留产品经理和架构师，将所有编码任务外包。如果一个产品原本需要10人年完成，那么理论上，20人可做半年，40人可做一季度，120人甚至可在一个月内交付——前提是任务已被充分拆解。
+
+这个实验揭示了一个被长期忽视的真相：软件工程的真正瓶颈，从来不是开发本身，而是产品与架构的设计过程。因为设计难以并行，而开发、测试、集成等后续环节，在理想状态下完全可以高度并行。
+
+我将这一洞察总结为“软件工程的极限理论（许式定律）”——
+
+>制约软件工程进度的瓶颈是产品设计和架构设计，这个过程无法并行；而与之对应的，开发过程可以并行，极限状态是10 分钟就把想要的东西做出来
+
+过去，这只是一个理论模型，思想实验。现实中，我们无法瞬间招募成百上千名合格开发者，沟通成本、质量控制、知识传递等现实约束，让“并行开发”止步于想象。
+
+但AI Coding的出现，彻底打破了这一限制。在AI时代，每个公司都可以“瞬间雇佣一万个开发人员”——新增一个 AI 开发者边际成本趋近于零。
+
+这意味着，“许式定律”中的极限理论不再只是思想实验，而成为每个团队必须面对的现实：
+
+>如果你的产品需求清晰、架构拆解合理，AI能在几小时内交付过去需要数周的代码；<br/>但如果你的需求模糊、模块边界混乱，AI只会以百倍速度放大你的错误。
+
+人月神话的终结，不是因为人变少了，而是因为“月”不再由“人”定义。
+
+AI 时代，每个公司都可雇任意多开发人员，因此传统软件工程中人月神话的“人月”不再是有效的度量单位。**开发工时不再是稀缺资源，清晰的问题定义与优雅的系统拆解，才是新时代的稀缺能力**。
+
+当然，既然理论上我能够任意增加研发工时，为什么一个商业软件还是没办法一天内就做出来？制约的瓶颈因素有哪些？这是一个值得深入探讨的问题，今天不作展开，欢迎读者交流讨论。
+
+## AI 在软件工程各环节的实践与挑战
+
+在实际落地的过程中，我们发现AI在不同环节的表现差异显著。
+
+在**产品设计**环节，AI 目前还难以在核心的决策过程中提供太大帮助。但它正在改变产品设计的表达方式——未来的产品经理必须输出 Live Demo，而不仅仅是静态原型。点击按钮要有真实反应，原型要能实际运行，这将成为AI时代产品设计的基本要求。
+
+在**架构设计**环节，AI 能够辅助生成设计方案，但无法自动选择最优解，也不能自动拆解任务。在我们开发 XGo 语言的实践中，我们要求 AI 将每个功能拆解为三个标准动作：实现语法（AST/Parser/Format）、实现语义（Compiler）、写文档（Quick Start）。这种明确的指令框架大大提升了AI的工作质量。
+
+在**开发与测试**环节，虽然这是 AI 最擅长的部分，但远非完美。在一个具体的案例中，AI 为实现可选参数功能提供的初始方案存在严重缺陷，甚至编写的测试用例也只是“自欺欺人”——刚好让有问题的代码通过测试，而没有真正覆盖所有分支。
+
+经过多次迭代，我们发现：好的测试用例能够大幅提升 AI 的代码质量。测试覆盖率在AI时代变得前所未有的重要。如果团队原有的测试覆盖率不足，盲目引入 AI Coding 可能会是一场灾难。
+
+## 驾驭AI：从“手动挡”到“自动挡”的思维转变
+
+如何正确理解AI的编程能力？我的比喻是：**AI Coding不是自动驾驶，而是自动挡**。
+
+自动驾驶（L5级别）意味着开发者完全不需要理解代码，只需给出需求即可。这离我们还很遥远。而自动挡意味着你仍然需要驾驶，需要知道方向，但操作门槛显著降低。
+
+这个比喻引申出几个重要启示：
+
+首先，我**不建议新手直接使用AI Coding**。就像开自动挡车仍然需要驾驶技术一样，使用AI Coding需要对软件工程有足够的理解和驾驭能力。
+
+其次，AI不会让所有开发者失业，而是导致两极分化。**优秀的开发者会因AI而更加高效、更加值钱**；而能力不足的开发者确实面临淘汰风险。
+
+最后，AI的优势不在于推理能力（大致在人类平均线附近），**而在于几乎没有知识盲区**。它是全人类知识的总和，这使它能够解答许多看似困难的问题。
+
+## 拥抱变革：效率倍增是底线要求
+
+如果一个公司的软件开发过程没有因为AI而实现效率倍增，那么它必将成为落后者。效率翻倍只是底线，实际上有潜力实现更高的提升。
+
+在 XGo 语言的开发中，我们已经全面使用 AI Coding，并且以完全公开透明的方式展示整个过程——包括如何给 AI 提任务、如何指挥 AI 工作。欢迎大家到 XGo 仓库（github.com/goplus/xgo）观摩交流。
+
+AI时代不是终点，而是新的起点。我期待与更多朋友探讨两个方向的深度合作：
+
+对于教育从业者，让我们一起探讨AI时代的工程教育变革。1024实训营将继续以公开透明的方式探索软件工程的最佳实践。
+
+对于企业决策者（CEO/CTO/技术总监），七牛云提供最全的 AI Coding 模型 API 服务和新一代软件工程的落地咨询（免费），帮助你的团队顺利过渡到AI新时代。
+
+软件工程正在被重塑，而我们有幸成为这场变革的见证者和参与者。与其恐惧，不如拥抱；与其被动，不如主动学习驾驭这个强大的新工具。
+
+未来的软件工程，属于那些能够将人类智慧与机器智能完美结合的组织和个人。