📒 学霸笔记：21｜构建与交付：扩展框架能力，实现自动化构建与 CI/CD

Top Student Notes: 21 | Build & Delivery: Extend the Framework for Automated Build and CI/CD

课程 / Course: AI 原生开发工作流实战 / AI-Native Development Workflow in Practice
讲师 / Instructor: Tony Bai
章节 / Chapter: 21
主题 / Topic: Dockerfile、Makefile、CI/CD、DevOps 自动化、能力沉淀回驾驶舱、Slash Commands 扩展、从开发走向交付

一、这一讲在解决什么问题？

What Problem Does This Lecture Solve?

到第 20 讲为止，我们已经完成了：

• 需求与设计
• 计划与任务拆解
• 编码与测试
• 审查与协同
• PR 准备

但是，一个现代软件项目真正“交付完成”，并不止于：

代码写完了
PR 建好了
可以合并了

真正的软件交付，还必须解决这些问题：

• 怎么保证项目在不同环境下一致构建？
• 怎么标准化日常开发任务？
• 怎么把应用打包成可运行、可部署的镜像？
• 怎么让测试、lint、构建在每次提交时自动执行？
• 怎么把这些 DevOps 能力沉淀为团队以后都能复用的 AI 能力？

所以这一讲解决的核心问题是：

如何把 AI 原生开发工作流，从“完成代码”推进到“完成标准化构建与自动化交付”，并把新能力继续沉淀回我们的 AI 驾驶舱框架。

二、本讲核心结论

Core Conclusion of This Lecture

一句话总结

21 讲的核心，是让 AI 不仅参与“开发代码”，还参与“开发 DevOps 基础设施”，并把生成的构建、打包、CI 能力再次封装进驾驶舱，实现从项目交付到能力沉淀的闭环。

三、这一讲在整套实战中的位置

Where This Lecture Fits in the Full Practical Workflow

从 16 讲开始，整个实战路线其实是这样的：

16 讲：搭驾驶舱
17 讲：需求编译 -> spec.md
18 讲：方案编译 -> plan.md / tasks.md
19 讲：编码与测试 -> TDD 落地
20 讲：协同与审查 -> review / commit / PR
21 讲：构建与交付 -> Dockerfile / Makefile / CI/CD

所以 21 讲完成的是最后一跳：

从“代码可合并”到“项目可交付”。

四、这一讲最重要的升级：AI 从开发助手扩展到 DevOps 助手

The Most Important Upgrade in This Lecture: AI Expands from Dev Assistant to DevOps Assistant

前面几讲，AI 的主要角色是：

• 产品经理协作者
• 架构师参谋
• TDD 执行者
• Code Review 助手
• 提交与 PR 文档助手

这一讲开始，AI 的角色进一步升级为：

DevOps 基础设施生成器 + 构建流程设计者 + 交付自动化助手

这很关键，因为它说明：

AI 原生开发不只是“写业务代码”，而是覆盖从需求到交付的全链路。

五、为什么 Tony 说“不能满足于有，而要追求优”？

Why Does Tony Say “Having It Is Not Enough — It Must Be Good”?

在第 19 讲的 Foundation 阶段，AI 可能已经顺手生成过：

• Dockerfile
• Makefile

但 Tony 在这一讲强调：

不能因为“已经有了”就不再优化。

这是很有工程味道的一点。

为什么？

因为“随手生成”的文件通常只是：

• 能跑
• 能构建
• 基本可用

但未必：

• 镜像够小
• 安全性够好
• 缓存策略合理
• 目标定义清晰
• CI 友好
• 团队可长期维护

所以这里体现出一个成熟工程思维：

从 Demo 可用，升级到生产可用。

六、第一步：Dockerfile 的本质，不是“能构建”，而是“生产级容器化”

Step 1: The Essence of the Dockerfile Is Not “Buildable”, but “Production-Ready Containerization”

Tony 在这里不是简单让 AI“写个 Dockerfile”，而是通过 Prompt 指定：

• 多阶段构建
• 依赖缓存
• 非 root 用户
• 最小镜像
• 不带源码和构建工具

这些要求说明，这一步不是语法生成，而是：

让 AI 按生产级最佳实践生成容器化方案。

这一段的角色设定很重要

你把 AI 定义为：

资深 DevOps 工程师，专精于 Go 应用容器化

这会让 AI 的输出重点偏向：

• 安全
• 体积
• 层缓存
• 可维护性
• 运行时隔离

而不是只满足“能 build”。

七、Dockerfile Prompt 的设计思想特别值得学

The Prompt Design for the Dockerfile Is Especially Worth Learning

这个 Prompt 很专业，因为它包含了三类关键元素：

1. 角色设定

资深 DevOps 工程师

2. 明确目标

不是模糊地说“写 Dockerfile”，而是要求：

• 审查并重写现有 Dockerfile
• 达到生产级最佳实践

3. 显式约束

例如：

• Multi-stage Build
• 缓存优化
• 非 root 用户
• 只保留运行时依赖

学霸理解

这说明你在和 AI 协作时，越是专业场景，越要把“标准”讲清楚。
否则 AI 很容易生成“能用但普通”的版本。

八、这一讲里 Dockerfile 的工程价值是什么？

What Is the Engineering Value of the Dockerfile in This Lecture?

一个好的 Dockerfile 至少解决了四个问题：

1. 一致性

任何环境构建结果一致

2. 轻量化

多阶段构建 + 精简运行镜像，减小体积

3. 安全性

非 root 用户、不带源码、不带编译工具

4. 可集成性

后续可以直接接入 CI/CD 和部署流程

学霸理解

Dockerfile 在这里不只是“打包脚本”，而是：

交付形态的标准定义文件。

九、第二步：Makefile 的本质，是“标准化任务入口”

Step 2: The Essence of the Makefile Is a Standardized Task Entry Point

Dockerfile 解决的是：

怎么打包

而 Makefile 解决的是：

日常工程任务怎么统一执行

Tony 让 AI 写的核心 targets 包括：

• build
• test
• lint
• docker-build
• clean

这说明 Makefile 的定位不是复杂，而是：

成为项目开发与交付动作的统一入口。

为什么这很重要？

因为如果没有 Makefile，团队常常会出现：

• 有人直接 go build
• 有人用脚本
• 有人自己拼 docker 命令
• 有人忘记跑 lint
• CI 和本地不一致

Makefile 统一以后：

• 人和 AI 都有一致入口
• 本地与 CI 容易对齐
• 文档也更简单

学霸理解

Makefile 在 AI 原生工作流里特别重要，因为它把复杂命令压缩成：

稳定、短小、可组合的任务接口

这非常适合 AI 调用。

十、为什么 Makefile 这么适合 AI 驾驶舱？

Why Is the Makefile So Suitable for the AI Cockpit?

因为 AI 更擅长调用语义稳定的命令，比如：

• make build
• make test
• make docker-build

而不擅长每次都重新拼一长串 Bash。

所以有 Makefile 后：

• Prompt 更短
• 执行更稳定
• 出错点更少
• 可封装性更高

学霸理解

Makefile 相当于为 AI 提供了：

一组稳定的动作 API。

十一、这一讲最关键的“升华”不是生成 Dockerfile 或 Makefile，而是回灌驾驶舱

The Real “Elevation” in This Lecture Is Not Generating the Dockerfile or Makefile, but Feeding Capabilities Back into the Cockpit

这一讲最重要的部分，不是前两步，而是第三步：

把刚生成出来的 DevOps 能力，再封装成 Slash Commands，沉淀回驾驶舱。

这一步是 AI 原生开发最有味道的地方。

为什么这一点最重要？

因为如果只生成文件，那只是一次性交付。

但如果再进一步，把这些能力变成：

• /build
• /docker-build

那就意味着：

这次项目里的知识，变成了以后项目里的标准能力。

这就是能力沉淀

你不是每次都重新告诉 AI：

• 先怎么 build
• docker 怎么打
• 出错了怎么分析

而是直接：

/build
/docker-build v1.0.1

学霸理解

这一讲的灵魂在于：

AI 不只是帮你生成结果，还帮你生成以后能重复使用的能力入口。

十二、/build 指令意味着什么？

What Does the /build Command Mean?

/build 的作用是：

• 调用 make build
• 若失败则分析错误原因

注意这里已经不只是“执行命令”，而是：

执行 + 失败诊断

这说明 Slash Command 不是简单别名，而可以包含：

• 动作
• 检查
• 诊断逻辑
• 输出规范

学霸理解

/build 本质上就是：

把“构建项目”封装成一个可解释的 AI 运维动作。

十三、/docker-build 指令为什么更进一步？

Why Is the /docker-build Command an Even Bigger Step Forward?

因为它不仅封装了动作，还支持参数：

• /docker-build
• /docker-build v1.2.3

这说明驾驶舱里的命令已经开始具备：

• 参数化
• 默认值
• 环境变量适配
• 错误处理建议

这就不是单纯的“模板提示词”，而越来越像：

AI 原生命令接口层

学霸理解

你可以把这些 Slash Commands 看作：

• 人类可读的命令
• AI 可执行的流程定义
• 团队共享的工程动作资产

十四、这一讲真正形成了什么闭环？

What Loop Is Truly Completed in This Lecture?

Tony 特别强调：

生成能力 → 封装能力 → 复用能力

这就是本讲真正完成的闭环。

完整闭环是：

AI 帮你生成 Dockerfile / Makefile
→ 你验证它们有效
→ 再把它们对应的能力封装进 Slash Commands
→ 以后任何人都能直接调用

学霸理解

这说明 AI 原生开发最强的地方不是“这次快”，而是：

每做完一次，以后都会更快。

十五、第四步：CI/CD 的本质，是把团队流程继续自动化

Step 4: The Essence of CI/CD Is to Continue Automating the Team Workflow

前面有了：

• Makefile
• Dockerfile
• Slash Commands

接下来就很自然了：

把 test / lint / build 放进 GitHub Actions

Tony 要求的 CI 流水线很标准：

触发条件

• push 到 main
• 新建 PR

核心步骤

• checkout
• setup Go
• make test
• make lint
• make build

失败策略

任一步失败，流水线失败

学霸理解

CI 在这里不是额外的东西，而是：

把本地标准流程搬到平台自动执行。

十六、为什么有了 Makefile 后，CI 会变得非常顺滑？

Why Does CI Become Much Smoother Once You Have a Makefile?

因为 CI 最怕的是“平台脚本和本地命令不一致”。

如果没有 Makefile，CI 里就要自己写：

• go test 命令
• lint 命令
• docker build 命令

这样很容易和本地脱节。

但有了 Makefile 后，CI 只要跑：

• make test
• make lint
• make build

这样：

• 本地跑什么，CI 就跑什么
• 文档写什么，CI 就执行什么
• AI 也只需学习统一接口

学霸理解

Makefile 是本地与 CI 的桥梁。

十七、这一讲提到的“AI 原生 DevOps”非常值得展开

The “AI-Native DevOps” Mentioned in This Lecture Is Worth Exploring Further

Tony 在最后给了一个很有意思的延展：

如果 CI 失败了，可以在流水线里加一步：

• 把 build log 喂给 Claude
• 让 AI 自动分析失败原因

这就意味着 CI 不再只是：

失败了，给你一堆红字

而可能进化成：

失败了，还能自动帮你读日志、做诊断、给建议

学霸理解

这其实是在把 AI 从开发助手进一步推进为：

CI 故障分析助手

这就是 AI 原生 DevOps 的味道。

十八、这一讲的真正认知升级

The Real Cognitive Upgrade in This Lecture

这一讲最大的升级，不是学会写 Dockerfile 或 Makefile，
而是建立这样一个意识：

DevOps 相关知识，不该只是专家个人经验，而应该被 AI 帮助生成、被框架帮助复用、被团队作为能力资产积累下来。

过去的模式

• DevOps 是“会的人才会”
• 构建脚本写在某人电脑里
• CI 配置靠少数人维护
• 业务开发者觉得这些门槛高

AI 原生模式

• 通过自然语言生成高质量基础设施文件
• 通过 Slash Command 封装能力
• 让所有成员共享同一套能力入口
• 持续把新经验沉淀回驾驶舱

学霸理解

这一讲真正完成的是：

把“会 DevOps”这件事，从个人技能，升级为团队可调用能力。

十九、本讲知识结构图

Knowledge Structure of This Lecture

PR 已准备好
        ↓
还需要真正的交付能力
        ↓
生成 DevOps 基础设施
├── Dockerfile
│   ├── 多阶段构建
│   ├── 缓存优化
│   ├── 非 root 用户
│   └── 最小运行镜像
├── Makefile
│   ├── build
│   ├── test
│   ├── lint
│   ├── docker-build
│   └── clean
        ↓
能力沉淀回驾驶舱
├── /build
└── /docker-build
        ↓
平台自动化
└── GitHub Actions CI
    ├── test
    ├── lint
    └── build
        ↓
结果
从“代码可合并”
升级到“项目可自动化交付”

二十、学霸速记表

Quick Revision Table

二十一、学霸自检题

Self-Check Questions

基础题

1. 这一讲为什么说“代码被合并”还不等于真正完成交付？
2. Dockerfile 和 Makefile 分别解决什么问题？
3. 为什么在 Dockerfile 中要强调非 root 用户和多阶段构建？

进阶题

4. 为什么 Tony 说本讲的关键不是生成文件，而是把能力沉淀回驾驶舱？
5. 为什么有了 Makefile 之后，CI 的配置会更稳定？
6. /build 和 /docker-build 为什么比直接写 Prompt 更适合团队长期使用？

思辨题

7. 如果你们团队要做 CD（持续交付），你会把哪些动作进一步封装成 Slash Commands？
8. CI 失败后让 AI 自动读日志、分析原因，这会对团队效率产生什么影响？
9. 你当前项目中，哪些 DevOps 知识最值得迁移为 AI 驾驶舱中的标准能力？

二十二、学霸总结

Top-Student Summary

这一讲作为实战篇“从 0 到 1”项目交付的收官，完成了 AI 原生开发流程中的最后一块关键拼图：构建与交付自动化。

它的核心不只是让 AI 再生成几个配置文件，而是让 AI 从开发领域进一步进入 DevOps 领域，帮助我们完成：

• 应用容器化
• 构建流程标准化
• 持续集成配置
• 新能力回灌驾驶舱

在具体实践上，这一讲完成了四件事：

1. 生成生产级 Dockerfile

强调的是：

• 多阶段构建
• 依赖缓存
• 最小运行时镜像
• 非 root 用户
• 安全与体积优化

这说明 AI 在 DevOps 场景下也不应只追求“可运行”，而应追求“生产可用”。

2. 生成标准化 Makefile

通过统一的：

• build
• test
• lint
• docker-build
• clean

让项目拥有一致的本地任务入口，也为后续 AI 调用和 CI 集成提供稳定接口。

3. 将新能力沉淀回 AI 驾驶舱

这是本讲最关键的升华。
通过创建 /build 和 /docker-build 这样的 Slash Commands，我们不只是得到了构建能力本身，更把它转化为了团队以后可以持续复用的 AI 原生操作入口。

也就是说：

AI 帮你生成 DevOps 能力，而你再把这些能力变成 AI 以后会用的标准动作。

这形成了真正的能力闭环。

4. 生成 GitHub Actions CI 流水线

把本地已经标准化的 test / lint / build 流程，进一步放到平台上自动执行，从而实现项目级质量门禁。

这一讲最大的认知升级，是让我们看到：

AI 原生开发不应该只停留在“写代码更快”，而应该进一步走向“基础设施也能自然语言生成，并持续沉淀为团队共享能力”。

所以，21 讲真正完成的，是把 AI 原生开发工作流从“开发闭环”扩展为“交付闭环”。

二十三、一句话记忆

One-Sentence Memory Hook

21 讲的本质，是让 AI 参与构建、打包和 CI，并把这些 DevOps 能力再次沉淀回驾驶舱，形成从代码到交付的完整闭环。