TARE-Learn/前言_.md

# 前言


```Plain Text
AI 编程已经从“尝鲜工具”进入“研发基础设施”阶段。
AI 不只是提高个人写代码速度，而是在重构研发组织的能效模型。
今天学习 TRAE，不是为了替代工程师，而是让工程师掌握被 AI 放大的工作方式。
```

---

# 第 0 部分：AI 编程行业趋势与能效变革破冰

# 一、开场定位

## 讲师开场话术

各位领导、各位同事，今天这门课表面上是 TRAE 工具培训，但我更希望大家把它理解成一次研发工作方式升级的起点。

过去我们讲研发效率，更多讲的是：

```Plain Text
流程优化
组件复用
低代码平台
DevOps 自动化
测试自动化
```

但从 2023 年之后，AI 编程工具开始进入研发现场，研发效率的提升方式发生了变化。

它不再只是“工具帮人少点几下”，而是开始进入：

```Plain Text
需求理解
代码阅读
代码生成
测试生成
重构建议
代码评审
文档生成
故障排查
```

这些环节。

也就是说，AI 编程的影响，不只是让某个工程师写代码快一点，而是开始改变研发组织的能效结构。

---

# 二、行业趋势：AI 编程已经进入主流阶段

## 讲师讲法

第一点，我们先看行业趋势。

AI 编程已经不是少数极客在尝鲜，而是正在变成开发者的日常工具。

Stack Overflow 2025 开发者调查显示，**84% 的受访者已经在使用或计划在开发流程中使用 AI 工具**，其中 **51% 的职业开发者每天使用 AI 工具**。这说明 AI 编程已经从“可选项”变成很多研发团队的“默认工作方式”之一。\([Stack Overflow Insights](https://survey.stackoverflow.co/2025/ai)\)

GitHub 2025 Octoverse 也显示，生成式 AI 已经成为开发中的标准能力之一：超过 **110 万个公开仓库使用 LLM SDK**，其中近 **69\.4 万个项目是在过去 12 个月创建的**；GitHub 还观察到，新加入 GitHub 的开发者中，接近 **80% 会在第一周使用 Copilot**。\([The GitHub Blog](https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/)\)

## 屏幕展示

```Plain Text
AI 编程已经进入主流阶段

过去：
少数人尝鲜 AI 补全

现在：
大量开发者日常使用 AI 工具

趋势：
AI 编程从“工具能力”变成“研发基础设施”
```

## 讲师补充

这里我们不需要把 AI 神化。

AI 不是今天用上，明天整个研发效率就翻倍。

但它的普及速度很快，而且正在改变研发人员的基本工作方式。

以前一个工程师的能力更多体现在：

```Plain Text
自己写代码
自己查资料
自己读项目
自己定位问题
```

现在逐渐变成：

```Plain Text
会不会描述问题
会不会给 AI 足够上下文
会不会判断 AI 输出是否可信
会不会把 AI 产出转化成可交付成果
```

---

# 三、技术发展：从代码补全到 Agent 工作流

## 讲师讲法

第二点，AI 编程工具本身也在升级。

早期的 AI 编程主要是代码补全。

你写一半，它帮你补几行。

后来变成聊天式助手。

你可以问它：

```Plain Text
这个函数是什么意思？
这个报错怎么解决？
帮我写一个测试用例。
```

现在进入第三个阶段：**Agent 化**。

Agent 不是简单回答问题，而是可以围绕一个任务执行多步操作：

```Plain Text
理解需求
检索代码
制定修改计划
改代码
运行检查
解释变更
辅助提交
```

GitHub Copilot 当前已经强调“agent mode”，可以在编辑器中解释概念、补全代码、提出修改并验证文件；Gartner 对 AI code assistants 的定义也已经覆盖生成、分析、调试、测试、修复、重构、文档、依赖搜索、代码评审等研发环节。\(GitHub\)

## 屏幕展示

```Plain Text
AI 编程工具演进

阶段 1：代码补全
帮你补几行代码

阶段 2：对话助手
帮你解释、生成、改写

阶段 3：研发 Agent
围绕任务完成多步研发动作
```

## 讲师补充

所以今天我们学习 TRAE，不能只学“怎么让它写一段代码”。

更重要的是学：

```Plain Text
怎么让 AI 读懂一个项目
怎么让 AI 找到正确上下文
怎么让 AI 追踪调用链路
怎么判断 AI 的回答是否可信
```

这才是企业研发里真正有价值的能力。

---

# 四、能效理念：AI 不是单点提效，而是组织能效重构

## 讲师讲法

第三点，我们讲“能效”。

过去讲研发效率，通常是看个人效率：

```Plain Text
一个人一天写多少代码
一个需求几天完成
一个 bug 多久修复
```

但 AI 进入研发之后，能效的核心不只是“写代码更快”，而是：

```Plain Text
新人理解项目更快
老项目维护成本下降
重复性编码减少
测试和文档生成成本降低
跨模块知识获取更快
代码评审和风险识别前置
```

也就是说，AI 影响的是整个研发链条。

Microsoft Research 和 GitHub 曾做过一个受控实验，使用 Copilot 的开发者完成指定编程任务的速度比对照组快 **55\.8%**。这个数字不应该被简单理解成“所有研发工作都快 55%”，但它说明在特定编码任务中，AI 对效率提升是真实存在的。\([微软](https://www.microsoft.com/en-us/research/publication/the-impact-of-ai-on-developer-productivity-evidence-from-github-copilot/)\)

Gartner 也预测，到 2028 年，**75% 的企业软件工程师将使用 AI code assistants**，而 2023 年初这一比例还不到 10%；同时 Gartner 特别提醒，企业不应只从“降本”角度看 AI 编程工具，还要看价值创造、开发者能力提升和研发体验改善。\([gartner\.com](https://www.gartner.com/en/newsroom/press-releases/2024-04-11-gartner-says-75-percent-of-enterprise-software-engineers-will-use-ai-code-assistants-by-2028)\)

## 屏幕展示

```Plain Text
AI 能效不是单点提效

不是只看：
代码写得更快

更要看：
理解更快
交接更快
测试更快
文档更快
风险发现更早
知识传递成本更低
```

---

# 五、关于“AI 替代人”：点到为止，积极但不盲目

## 讲师讲法

当然，今天有董事和管理层在场，我们也需要正视一个问题：AI 会不会替代人？

我的建议是不要回避，但也不要把它讲得过度悲观。

更准确的说法是：

```Plain Text
AI 会替代一部分重复性、低上下文、低判断含量的研发工作。
AI 会改变岗位结构和团队用人方式。
但 AI 不会在短期内替代所有工程判断、业务理解和系统责任。
```

目前行业里已经出现一些信号：企业在评估 AI 对招聘、团队规模和岗位结构的影响，一些公司也公开谈到 AI 工具带来的生产率提升和招聘节奏变化。比如近期关于 Uber 的报道中提到，公司内部使用 Claude Code 和 ChatGPT 带来约 25% 的生产率提升，但管理层也强调，这种效率提升和最终用户价值之间并不是简单线性关系。\(The Times of India\)

同时，Stack Overflow 2025 调查也显示，虽然 AI 工具使用率很高，但开发者对 AI 输出准确性的信任并没有同步上升；面向领导者的解读中还提到，工具数量增加可能让工作流变复杂，而不是自动变简单。\(Stack Overflow Insights\)

## 推荐措辞

这一段建议你在课堂上这样说：

```Plain Text
我们不用把 AI 看成一个马上替代所有工程师的东西，
也不能把它看成一个可有可无的插件。

更现实的判断是：
会使用 AI 的工程师，会逐渐替代不会使用 AI 的工作方式；
会组织 AI 工作流的团队，会逐渐替代低效率的传统研发流程。
```

这句话比较稳，既能让高管听到能效趋势，也不会让工程师产生强烈抵触。

---

# 六、为什么今天从“陌生代码库理解”开始讲？

## 讲师讲法

既然 AI 编程有这么多方向，为什么第一天不是讲“让 AI 写代码”，而是讲“陌生代码库理解”？

原因很简单。

企业研发里，真正消耗大量时间的，往往不是从零写一个 demo，而是：

```Plain Text
接手旧项目
理解陌生模块
定位调用链路
判断改动影响面
识别风险点
补测试
写交接文档
```

这些工作恰恰是 AI 最适合辅助，但也最需要人工判断的地方。

所以今天我们从“理解陌生代码库”开始，是因为它同时覆盖了三个能力：

```Plain Text
AI 提效能力
工程理解能力
风险判断能力
```

这也是高管和工程师都关心的交叉点。

对管理层来说，它关系到组织能效。

对工程师来说，它关系到个人能力升级。

对公司来说，它关系到研发质量和交付速度。

---

# 七、15 分钟开场完整结构

## 0 \- 2 分钟：开场破冰

```Plain Text
今天不是一场单纯的工具培训，而是一场研发工作方式升级课。
我们要讨论的是：AI 进入研发后，工程师、团队和组织能效会发生什么变化。
```

---

## 2 \- 5 分钟：行业趋势

```Plain Text
AI 编程已经进入主流阶段。
Stack Overflow 2025 调查显示，84% 的受访者已经使用或计划使用 AI 工具，51% 的职业开发者每天使用。
GitHub 2025 Octoverse 也显示，AI 已经成为开发活动中的标准能力之一。
```

配套引用：\(Stack Overflow Insights\)

---

## 5 \- 8 分钟：技术发展

```Plain Text
AI 编程工具正在从代码补全，发展到对话助手，再到 Agent 工作流。
今天的工具已经不只是帮你补几行代码，而是可以帮助理解项目、制定修改计划、生成测试、辅助评审。
```

配套引用：\(GitHub\)

---

## 8 \- 12 分钟：能效理念

```Plain Text
AI 的价值不只是让个人写代码更快，而是降低整个研发链条中的理解成本、交接成本、测试成本和文档成本。
但企业不能只从降本角度看 AI，而要看价值创造、质量提升和研发体验。
```

配套引用：\(微软\)

---

## 12 \- 15 分钟：替代与拥抱

```Plain Text
AI 会替代一部分重复性、低上下文、低判断含量的工作。
但企业真正需要的，不是简单减少人，而是提升每个人和每个团队的产出质量。

今天我们学习 TRAE，就是为了让大家掌握 AI 时代新的研发基本功：
会提问、会给上下文、会追链路、会验证结果。
```

---

# 八、PPT 页面建议：开场 6 页

## Slide 0：标题页

**标题：**
AI 编程时代的研发能效升级

**副标题：**
从工具使用到研发工作方式变化

**讲师备注：**
今天不是单纯学习 TRAE，而是以 TRAE 为入口，学习 AI 时代研发团队的新工作方式。

---

## Slide 1：AI 编程已经进入主流阶段

**页面内容：**

```Plain Text
AI 编程不再是尝鲜工具

趋势：
- 开发者日常使用率快速上升
- AI 从个人插件进入研发流程
- 新人默认接触 AI 编程
```

**讲师备注：**
Stack Overflow 2025 显示，84% 的受访者使用或计划使用 AI 工具，51% 的职业开发者每天使用；GitHub 也观察到新开发者快速采用 Copilot。\([Stack Overflow Insights](https://survey.stackoverflow.co/2025/ai)\)

---

## Slide 2：AI 编程工具的三阶段演进

**页面内容：**

```Plain Text
1. 代码补全
   补几行代码

2. 对话助手
   解释、生成、改写

3. 研发 Agent
   计划、修改、测试、验证、提交
```

**讲师备注：**
今天的 AI 编程工具已经从“补代码”走向“协同完成研发任务”。GitHub Copilot 等工具已经强调 agent mode，Gartner 对 AI code assistants 的功能定义也覆盖调试、测试、重构、文档和代码评审等环节。\([GitHub](https://github.com/features/copilot)\)

---

## Slide 3：AI 带来的不是单点提效，而是能效重构

**页面内容：**

```Plain Text
过去关注：
一个人写代码有多快

现在更要关注：
理解项目有多快
交接成本有多低
测试文档能否自动生成
风险能否更早暴露
团队知识能否复用
```

**讲师备注：**
不要把 AI 提效理解成单纯“多写代码”。真正的组织价值在于降低理解成本、沟通成本、质量成本和维护成本。

---

## Slide 4：积极拥抱，但不盲目乐观

**页面内容：**

```Plain Text
AI 会替代：
重复性编码
低上下文任务
模板化文档
简单测试生成
初步代码解释

AI 仍需要人负责：
业务判断
架构取舍
安全边界
质量责任
上线决策
```

**讲师备注：**
这一页要稳。不要制造恐慌，也不要说 AI 没影响。核心表达是：被替代的不是工程师这个人，而是低效、重复、缺乏判断的工作方式。

---

## Slide 5：工程师角色正在变化

**页面内容：**

```Plain Text
过去：
主要靠自己写、查、改、测

现在：
会描述任务
会提供上下文
会拆解问题
会验证 AI 输出
会把 AI 结果工程化
```

**讲师备注：**
这是从“编码执行者”向“AI 协同工程师”的变化。

---

## Slide 6：为什么第一天先讲陌生代码库理解？

**页面内容：**

```Plain Text
企业研发最常见的成本：

接手旧项目
理解陌生模块
追踪调用链路
判断影响范围
识别风险点
沉淀文档
```

**讲师备注：**
这正是 TRAE 这类 AI IDE 最适合切入的地方，也是工程师最需要掌握的新基本功。

---

# 九、高管在场时的推荐表达



```Plain Text
AI 编程不是单个工具采购问题，而是研发能效体系升级问题。
```

```Plain Text
AI 不只是提升个人编码速度，更重要的是降低组织的知识传递成本和项目理解成本。
```

```Plain Text
未来的差距，不一定是用不用 AI，而是能不能把 AI 嵌入标准研发流程。
```

```Plain Text
我们不是盲目追求 AI 替代人，而是让 AI 替代低价值重复劳动，让人聚焦业务判断、架构质量和交付责任。
```

---

# 十、和后续课程的衔接话术

开场最后可以这样收：

```Plain Text
所以今天我们不从“让 AI 写代码”开始，而是从“让 AI 帮我们理解代码”开始。

因为在企业真实研发里，理解陌生项目、识别调用链路、判断风险影响，是比写几行代码更底层的能力。

接下来，我们会进入今天的正式主题：

如何用 TRAE 快速理解一个陌生代码库，并且判断 AI 给出的结论是否可信。
```