Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file not shown.
Binary file not shown.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

Large diffs are not rendered by default.

Original file line number Diff line number Diff line change
@@ -0,0 +1,96 @@
# 许式伟:AI 时代重塑软件工程

在第四期1024实训营结营仪式上,实训营发起人许式伟先生以《AI 时代重塑软件工程》为题,为全体学员和在线观众带来了一场深度分享。他从软件工程的基础理论出发,深入剖析了AI技术对软件工程领域的深刻影响与重塑。以下是演讲全文:

# 正文:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

It's recommended to adjust the heading level for better document structure. The main title of the article is already a level 1 heading (#). This line, 正文: (which means "Body text:"), should probably be a level 2 heading (##) to maintain a proper hierarchy. Alternatively, since it acts as an introduction, you could remove it entirely for a more compact presentation.

Suggested change
# 正文:
## 正文:

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Critical: Double H1 heading violates markdown structure. Either remove "# 正文:" or change to ## 正文:. Recommend removing entirely as it adds no semantic value.


本期实训营的分享,与前三期有着显著的不同。在前三期中,实习生几乎无人使用 AI 编程;而这一期,每个团队都已大规模采用 AI coding。这一变化并非偶然,而是时代演进的必然结果。

1024实训营,本质上是在探索软件工程的最佳实践。然而,当参与实践的学员——这些尚未成型的工程师——其开发方式已在短短一两年间发生根本性转变时,我们就无法再回避一个关键问题:**在 AI 深度介入编程的今天,软件工程本身是否正在被重新定义?**

过去,我们谈“如何成为优秀的工程师”;今天,我们不得不谈“如何在 AI 时代做好软件工程”。我反复思考这个问题后得出一个结论:AI 正在彻底重塑软件工程的底层逻辑。许多我们曾视为理所当然的工程原则,在 AI 时代可能不再成立。

正因如此,本期结营我选择了一个截然不同的主题。这不是一次技术工具的更新讨论,而是一场对工程范式的重新审视——我们必须以更严肃的态度,直面这场正在发生的范式革命。

## 软件工程铁三角:工程、设计与商业

在深入探讨AI的影响之前,我们有必要回归软件工程的基本理论框架。我认为软件工程的范畴始终围绕着三个核心层面:工程、设计与商业。

**工程**是一门关于“如何把事做成”的学问。它的核心方法论包含三个要素:模块(拆解复杂问题)、版本(迭代逼近目标)和分工(团队协同)。这是大多数技术人员最为熟悉的部分。

**设计**远不止于产品包装或UI界面,它本质上是一门关于“决策”的学问——要做什么事,以及把事做成什么样子。从战略设计、组织设计到产品设计、架构设计,每一个环节都需要精准的决策。

**商业**则是所有事情的源头。商业不一定是赚多少钱,但它一定绕不开社会价值。商业好不好,最终的衡量标准是 ROI(投资回报率),这里可以用公式表达:`ROI = 社会价值/实现代价`。即用更低的成本实现更大的社会价值,这就是商业的本质。

在这个框架下,我们才能理解为什么顶级产品经理做的是“减法”,而顶级架构师做的是“乘法”。

好产品的定义是:**用最少的功能,实现最大化的需求覆盖**。“少就是指数级的多”不仅是Google创始人的理念,更是产品设计的黄金准则。就像计算机的 CPU,五十多年来其内部实现不断迭代,但规格接口几乎保持不变——这种“封闭性”恰恰是好产品的特征。

架构设计之所以比产品设计更难,是因为它极度“逆直觉”。当我看到团队 Leader 简单地按照页面分配任务(页面A交给张三,页面B交给李四......)时,就知道这样的架构设计通常是错误的。**真正好的架构设计是在做“乘法”**,它要求每个模块都应被当作一个“子业务”来设计——**有独立需求边界、高复用性、低耦合。就像搭乐高,积木种类越少、拼装步骤越简、外部依赖越成熟,系统就越健壮**


## AI时代:“人月神话” 的终结
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inconsistent spacing: two blank lines before heading. Use single blank line for consistency.


在《许式伟的架构课》第74节中,我曾提出一个思想实验:假设一家公司只保留产品经理和架构师,将所有编码任务外包。如果一个产品原本需要10人年完成,那么理论上,20人可做半年,40人可做一季度,120人甚至可在一个月内交付——前提是任务已被充分拆解。

这个实验揭示了一个被长期忽视的真相:软件工程的真正瓶颈,从来不是开发本身,而是产品与架构的设计过程。因为设计难以并行,而开发、测试、集成等后续环节,在理想状态下完全可以高度并行。

我将这一洞察总结为“软件工程的极限理论(许式定律)”——

>制约软件工程进度的瓶颈是产品设计和架构设计,这个过程无法并行;而与之对应的,开发过程可以并行,极限状态是10 分钟就把想要的东西做出来
过去,这只是一个理论模型,思想实验。现实中,我们无法瞬间招募成百上千名合格开发者,沟通成本、质量控制、知识传递等现实约束,让“并行开发”止步于想象。

但AI Coding的出现,彻底打破了这一限制。在AI时代,每个公司都可以“瞬间雇佣一万个开发人员”——新增一个 AI 开发者边际成本趋近于零。

这意味着,“许式定律”中的极限理论不再只是思想实验,而成为每个团队必须面对的现实:

>如果你的产品需求清晰、架构拆解合理,AI能在几小时内交付过去需要数周的代码;<br/>但如果你的需求模糊、模块边界混乱,AI只会以百倍速度放大你的错误。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

It's better to use standard Markdown for paragraph breaks within a blockquote. Using <br/> might not render consistently across all platforms. I suggest splitting the content into two separate blockquotes for better clarity and standard compliance.

Suggested change
>如果你的产品需求清晰、架构拆解合理,AI能在几小时内交付过去需要数周的代码;<br/>但如果你的需求模糊、模块边界混乱,AI只会以百倍速度放大你的错误。
>如果你的产品需求清晰、架构拆解合理,AI能在几小时内交付过去需要数周的代码;
>但如果你的需求模糊、模块边界混乱,AI只会以百倍速度放大你的错误。

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider using markdown line breaks instead of HTML <br/> for better portability:

> 如果你的产品需求清晰、架构拆解合理,AI能在几小时内交付过去需要数周的代码;
> 
> 但如果你的需求模糊、模块边界混乱,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)观摩交流。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

For better readability and accessibility, it's recommended to format this plain URL as a clickable Markdown link.

Suggested change
在 XGo 语言的开发中,我们已经全面使用 AI Coding,并且以完全公开透明的方式展示整个过程——包括如何给 AI 提任务、如何指挥 AI 工作。欢迎大家到 XGo 仓库(github.com/goplus/xgo)观摩交流。
在 XGo 语言的开发中,我们已经全面使用 AI Coding,并且以完全公开透明的方式展示整个过程——包括如何给 AI 提任务、如何指挥 AI 工作。欢迎大家到 XGo 仓库([github.com/goplus/xgo](https://github.com/goplus/xgo))观摩交流。

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider converting to proper markdown link for better UX:

欢迎大家到 [XGo 仓库](https://github.com/goplus/xgo) 观摩交流。


AI时代不是终点,而是新的起点。我期待与更多朋友探讨两个方向的深度合作:

对于教育从业者,让我们一起探讨AI时代的工程教育变革。1024实训营将继续以公开透明的方式探索软件工程的最佳实践。

对于企业决策者(CEO/CTO/技术总监),七牛云提供最全的 AI Coding 模型 API 服务和新一代软件工程的落地咨询(免费),帮助你的团队顺利过渡到AI新时代。

软件工程正在被重塑,而我们有幸成为这场变革的见证者和参与者。与其恐惧,不如拥抱;与其被动,不如主动学习驾驭这个强大的新工具。

未来的软件工程,属于那些能够将人类智慧与机器智能完美结合的组织和个人。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

It's a common convention to have a single newline at the end of a file. This prevents issues with some command-line tools like cat and can avoid noisy diffs in version control.

Suggested change
未来的软件工程,属于那些能够将人类智慧与机器智能完美结合的组织和个人。
未来的软件工程,属于那些能够将人类智慧与机器智能完美结合的组织和个人。

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Critical: Missing newline at end of file (violates POSIX and repository's own article #6 standard "一行之差:为什么你的文件末尾应该留一个空行?"). Please add trailing newline.

8 changes: 4 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -49,16 +49,16 @@
### 🎓 第 4 期训练营
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Critical: Missing entries for articles #16-22 in table of contents. The new article (#22) and 6 other existing articles are not discoverable via README. Please add:

| 16   | 关于架构设计的几点认知体会 | [📖 阅读](2025/16.%20关于架构设计的几点认知体会/content.md) |
| 17   | SPX-Algorithm:构建多模态搜索服务的一些心得 | [📖 阅读](2025/17.%20SPX-Algorithm:构建多模态搜索服务的一些心得/share.md) |
| 18   | 代码不是核心:从 XLink 项目看产品开发的决策层次 | [📖 阅读](2025/18.%20代码不是核心:从%20XLink%20项目看产品开发的决策层次/content.md) |
| 19   | llpyg: LLGo 快速集成 Python 生态的桥梁 | [📖 阅读](2025/19.%20llpyg:%20LLGo%20快速集成%20Python%20生态的桥梁/content.md) |
| 20   | X绘图-我们是如何让AI更好的融入我们的产品的 | [📖 阅读](2025/20.X绘图-我们是如何让AI更好的融入我们的产品的/实训感悟.md) |
| 21   | 实训营分享:LLGo 中 Python 编译与运行时集成 | [📖 阅读](2025/21.%20实训营分享:LLGo%20中%20Python%20编译与运行时集成/content.md) |
| 22   | 许式伟:AI时代重塑软件工程 | [📖 阅读](2025/22.许式伟:AI时代重塑软件工程/reinventing_software_engineering_in_the_AI_Era.md) |


#### 实训课题
| 模块 | 主题 | 内容 |
| ------- | --------------------------------------- | --------------------------------------------- |
| 模块 | 主题 | 内容 |
| ---- | -------------------------------------------- | ------------------------------------------------------------------------------------------- |
| 第 1 组 | XBuilder 项目分享与传播 | [📖 阅读](4th/1st_xbuilder_share/topic.md) |
| 第 2 组 | XBuilder 基于大模型的代码生成与素材生成 | [📖 阅读](4th/2nd_copilot_classfile/topic.md) |
| 第 3 组 | LLGo 对 Python 库开箱即用 | [📖 阅读](4th/3rd_llgo_python/topic.md) |
| 第 4 组 | AI Powered Ops | [📖 阅读](4th/4th_ai_powered_ops/topic.md) |

#### 实训公开课
| 期数 | 主题 | 内容 |
| ------- | --------------------------------------- | ---------------------------------- |
| 期数 | 主题 | 内容 |
| ---- | -------------------------------------------- | ------------------------------------------------------------------------------------------- |
| 第 1 期 | 《人人都是产品经理》作者苏杰:AI 教我的产品哲学 | [📖 观看](https://mp.weixin.qq.com/s/qGQBKs3bjDZzk-SKdNumBw) |
| 第 2 期 | 汪源 × 许式伟:AI时代如何打造真正解决用户痛点的产品? | [📖 观看](https://mp.weixin.qq.com/s/eppy6z7XNN-mVZIjk44yvg) |
| 第 3 期 | 《构建之法》作者邹欣:实战中的软件工程——从微软到 AI 时代的构建之道 | [📖 观看](https://mp.weixin.qq.com/s/CkKXGLzycyE7inMFp6jKlw) |
Expand Down