# 前言 ```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 给出的结论是否可信。 ```