跳至内容

第九部分 · 工程化升级

到这里，你的 AI Todo 已经是一个真正能用的完整应用：Vue + Tailwind 的前端、Flask + SQLite 的后端，还接上了大模型。但你可能也隐隐感觉到——功能越加越多，代码越来越乱，改一个地方要翻好几个文件，一不小心还会碰坏别的地方。这一部分，我们就来解决这个「长大了的烦恼」。

关于这一部分怎么用

这一部分和前面几部分有个很重要的区别：工程化不是为了炫技，而是因为项目长大了、痛点真的出现了，才需要。

所以每一章我们都先讲「出现了什么痛点」，再讲「这个工程化手段怎么解决它」。这本身就是一道贯穿全章的选择题——

💡 什么时候值得投入做工程化？ 答案是：等痛点真的出现时，不要过早。项目还很小的时候上一堆规范，反而是负担。等你真的被乱代码绊倒了，再来收拾，才最划算。

前面用 Flask 是为了入门简单；这一部分我们会平滑升级到 FastAPI + Pydantic——注意是「平滑演进」，不是「推翻重做」。而且所有的搬砖活，都交给 Claude Code / Codex。

48. 项目结构是什么

这一章要解决什么问题

随着前端、后端、数据库、AI 一样样加进来，你的项目文件夹是不是开始有点乱了？HTML、Python、配置文件、数据库文件全堆在一起，想找一个东西得翻半天。这一章就来解决「东西太多、找不着」的痛点。

这是什么

项目结构，就是给你的文件分门别类、各归各位。

打个比方：一个好的项目结构，就像一间整理好的房间——衣服在衣柜、书在书架、餐具在厨房。前端的代码放前端的地方，后端的代码放后端的地方，数据放数据的地方。你想找什么，一伸手就到。

反过来，把所有东西堆在一个抽屉里，东西少的时候还行，一多就是灾难。

为什么现在需要

项目刚起步时只有一个 index.html，根本不需要什么结构。但现在你有了前端、后端、数据库、还有一堆配置——这就是那个「痛点真的出现了」的时刻。文件一多，不整理就会乱；乱了，AI 帮你改代码时也容易找错地方。

在 AI Todo 里怎么用

我们请 AI 帮我们梳理一个清清爽爽的目录：前端一个文件夹，后端一个文件夹，数据、配置各就各位。你不需要懂每个文件夹叫什么名字最专业，你要验收的是梳理完之后，项目还能不能照常跑起来。

让 AI 执行的小任务 

任务目标：
帮我把当前 AI Todo 项目的文件重新组织成清晰的目录结构。

当前状态：
现在前端、后端、数据库文件都堆在一起，越来越乱，我想让它规整一些。

限制条件：
只做文件的整理和归位，不要改任何功能逻辑；
迁移完成后，前端和后端都要能像之前一样正常运行。

期望结果：
前端代码归到一个文件夹（比如 frontend），
后端代码归到一个文件夹（比如 backend），
数据库、配置等各自放到合适的位置。
并给我一份简单的说明：每个文件夹是干嘛的。

验收标准：
1. 目录结构清晰，一眼能看出哪块是前端、哪块是后端。
2. 整理之后，前端页面照常打开、后端接口照常工作。
3. 没有报错。

运行后看到什么

AI 会把文件搬进新的文件夹，然后给你一张「目录地图」，告诉你每个文件夹装的是什么。项目看起来一下子清爽了很多。

如何验收

  • 目录结构清晰，前端 / 后端 / 数据分得清清楚楚？
  • 前端页面还能正常打开？
  • 后端接口还能正常返回数据（添加、查询任务都正常）？
  • 全程没有报错？

⚠️ 整理目录最容易出的问题是「搬完就跑不起来了」——因为文件位置变了，代码里引用的路径没跟着改。所以第 2、3 条一定要亲自跑一遍确认。

不对怎么反馈给 AI 

你把文件整理进新文件夹后，前端页面打不开了（或后端报了找不到文件的错）。
报错原文如下：
<把报错粘在这里>
请检查是不是文件路径引用没有跟着更新，修好后再告诉我正确的启动方式。

本章小结

项目大了就要整理房间：前端、后端、数据各归各位。让 AI 帮你梳理目录，验收的核心是——结构清晰，且项目照常能跑。

49. Vue 组件是什么

这一章要解决什么问题

看看你的 Todo 页面：每一条任务，长得几乎一模一样——一个勾选框、一段文字、一个删除按钮。如果这段「一条任务」的代码在页面里被复制粘贴了好多遍，那么一旦你想改任务的样子（比如加个优先级标签），就得一处一处地改，改漏一个就出 bug。这一章解决「重复代码难维护」的痛点。

这是什么

Vue 组件，就是把重复出现的页面片段，抽成一块可以反复使用的「积木」。

打两个比方：

  • 它像乐高积木——你做好一块「任务」积木，想拼几个就拼几个，每块都一样标准。
  • 它也像文档里的**「样式模板」**——定义一次，到处套用；想改的时候，只改模板，所有用到的地方一起变。

为什么现在需要

页面简单的时候，复制粘贴几段代码没什么。但现在任务条目多了、样式复杂了，重复的代码就成了负担：改一处要改十处，还容易漏。把「一条任务」抽成组件后，以后只改这一块，全站的任务就都跟着变了。

在 AI Todo 里怎么用

我们让 AI 把 Todo 页面里重复的部分（最典型的就是「一条任务」）抽成独立的 Vue 组件。抽完之后，页面看起来、用起来都和原来一模一样，但背后的代码更整洁、更好维护了。

让 AI 执行的小任务 

任务目标：
把 Todo 页面里重复的部分抽成可复用的 Vue 组件。

当前状态：
现在页面里「一条任务」的结构（勾选框、任务文字、删除按钮）是重复写的，
想改任务的样子要改很多处。

限制条件：
只做组件化重构，页面的外观和功能都不能变；
重构前后用户看到的、能操作的东西要完全一致。

期望结果：
把「一条任务」抽成一个独立组件（比如 TodoItem），
任务列表通过循环使用这个组件来渲染。

验收标准：
1. 页面外观和之前完全一样。
2. 添加、勾选完成、删除任务等功能都和之前一样正常。
3. 代码结构更清晰了，你能简单说明抽出了哪些组件。
4. 没有报错。

运行后看到什么

刷新页面——你看不出任何变化。这恰恰是对的。组件化是「内部装修」，用户端不该有感知。变的只是代码：原来一大坨，现在拆成了清爽的小块。

如何验收

  • 页面外观和之前一模一样？
  • 添加、勾选、删除，功能全都照常？
  • AI 能说清它抽出了哪几个组件？
  • 没有报错？

💡 这是一道很典型的「判断题」：重构做得好不好，标准不是「代码变漂亮了」（那个你看不懂），而是**「外观和行为一点没变」**。你完全能靠肉眼验收——功能照旧，就算成功。

不对怎么反馈给 AI 

组件化之后，页面看起来和之前不太一样了（或某个功能不好使了）：
<具体描述哪里变了>
请在保持功能和外观完全不变的前提下重新组织，不要改变用户能看到和操作的部分。

本章小结

把重复的页面片段抽成 Vue 组件，就像做一块能反复拼的乐高。验收的关键——外观和行为不变，但代码更整洁、更可复用。

50. Tailwind 如何统一页面风格

这一章要解决什么问题

页面做着做着，你可能会发现：这个按钮是蓝的，那个按钮是绿的；这里间距大，那里间距小；圆角有的圆有的方。因为不同阶段随手写的样式，风格没对齐。整个页面看起来有点「东拼西凑」。这一章解决「视觉不统一、显得业余」的痛点。

这是什么

Tailwind 是我们前面就在用的样式工具。这一章我们用它做一件事：把全站的颜色、间距、按钮风格统一成一套标准。

比方说：规定「主按钮都用同一种蓝、同一个圆角、同一个内边距」，然后所有主按钮都套这套标准。这样整个应用看起来就像同一个人、用同一套设计做出来的，专业感一下就上来了。

为什么现在需要

早期功能是一块块加上去的，每块的样式都是当时随手写的，没人管全局一致性——这在项目小的时候无所谓。但现在页面成型了，风格不统一就成了「显得业余」的痛点。趁现在收口，一次性把风格对齐。

在 AI Todo 里怎么用

我们让 AI 通篇检查页面，把散落各处、各写一套的样式，收敛成一套统一的规范：一致的配色、一致的间距、一致的按钮和卡片风格。

让 AI 执行的小任务 

任务目标：
用 Tailwind 统一 AI Todo 全站的视觉风格。

当前状态：
页面是分阶段做出来的，按钮颜色、间距、圆角等风格不太一致，
看起来有点东拼西凑。

限制条件：
只调整视觉风格，不改任何文字内容和功能；
风格要简单清晰、干净现代，保持一致。

期望结果：
全站的主色调统一；
按钮（主按钮、次按钮）风格统一；
卡片、列表项的间距和圆角统一；
整体看起来像同一套设计做出来的。

验收标准：
1. 全站视觉明显更统一、更协调了。
2. 文字内容和功能完全没变。
3. 在手机窄屏和电脑宽屏下都不错乱。
4. 没有报错。

运行后看到什么

页面整体气质变了——不再是「东一块西一块」，而是像一套完整的设计。颜色协调了，按钮长得一致了，间距也有了节奏感。

如何验收

  • 全站视觉是否明显更一致、更协调了？
  • 文字和功能有没有被动到？
  • 拉窄窗口试试，手机上会不会乱？
  • 没有报错？

不对怎么反馈给 AI 

风格统一之后，整体好看了，但还有个别地方没对齐：
比如删除按钮的颜色 / 圆角还是和其他按钮不一样。
请把它也调整成和主设计一致的风格，其余保持不变。

本章小结

用 Tailwind 把颜色、间距、按钮风格统一起来，避免每处各写一套。验收就一句话——全站视觉一致，像同一套设计。

51. 数据结构定义是什么

这一章要解决什么问题

到现在，「一条 Todo 到底该包含哪些信息」，你可能从没正式想清楚过——前端觉得有个标题就行，后端存的时候又加了个完成状态，等要做分类、优先级的时候，大家又各加各的。结果就是前后端「各说各话」，对不上。这一章解决「数据长什么样没定清楚」的痛点。

这是什么

数据结构定义，就是先把「一条 Todo 到底该有哪些字段」白纸黑字地定清楚。

就像开店进货前，先定好「一件商品」要登记哪些信息：名称、价格、库存、分类……定清楚了，前台后台仓库才不会各记各的。

对我们的一条任务，典型的字段可能是：

  • 标题：这件事是什么（比如「写周报」）
  • 完成状态：做完了没有（是 / 否）
  • 分类：属于哪一类（工作 / 生活 / 学习……）
  • 优先级：多重要（高 / 中 / 低）
  • 创建时间：什么时候加的

为什么现在需要

早期任务只有一个标题，压根不需要「定义」。但现在你要做分类、排优先级、按时间排序——字段变多了，如果不先统一定义清楚，前端传一套、后端存一套，接口就会对不上，bug 层出不穷。所以在继续加功能前，先把「数据长什么样」钉死。

在 AI Todo 里怎么用

💡 这是一道很纯粹的选择题：一条任务，到底需要哪些字段？ 这道题没有标准答案，取决于你的产品想做成什么样。字段太少，功能撑不起来；字段太多，又臃肿难维护。这个决定必须你来拍板——AI 可以给你建议，但「我的 Todo 要记录什么」，是产品负责人的活儿。

想清楚字段后，让 AI 把这份定义正式写下来，作为前后端共同遵守的「合同」。

让 AI 执行的小任务 

任务目标：
为 AI Todo 定义清楚「一条任务」的数据结构。

当前状态：
现在一条任务的字段没有统一定义，前后端处理得比较随意。

我决定一条任务包含这些字段（可按需增减）：
- 标题（文字，必填）
- 完成状态（是 / 否）
- 分类（工作 / 生活 / 学习）
- 优先级（高 / 中 / 低）
- 创建时间（自动生成）

限制条件：
这一步只做数据结构的定义和说明，先不急着改所有功能；
把定义写清楚，作为前后端统一遵守的标准。

期望结果：
给我一份清晰的「一条任务」字段定义（每个字段是什么、什么类型、是否必填、可选值有哪些）。

验收标准：
1. 每个字段的含义、类型、取值范围都写清楚了。
2. 这份定义前端和后端都能照着用。
3. 通俗易懂，我这个非技术的人也能看明白。

运行后看到什么

AI 会给你一张清清楚楚的「字段清单」：每个字段叫什么、是什么类型、必不必填、有哪些可选值。这张清单，就是接下来前后端都要遵守的「合同」。

如何验收

  • 每个字段的含义、类型、取值范围是否都清楚？
  • 是否覆盖了你想要的全部功能（分类、优先级、排序都有对应字段）？
  • 你自己看得懂吗？

不对怎么反馈给 AI 

这份字段定义基本可以，但我还想加一个「截止日期」字段，
另外「分类」我希望能自己自定义，而不是固定三种。
请更新这份定义。

本章小结

先把「一条 Todo 有哪些字段」定义清楚，前后端才不会各说各话。而「需要哪些字段」这道选择题，得你亲自来答。

52. Pydantic 是什么

这一章要解决什么问题

字段定义好了，但光有定义拦不住坏数据。用户可能提交一条没有标题的空任务，可能把优先级填成「非常非常高」这种系统不认的值。这些「不合规矩」的数据一旦混进来，后面全乱套。这一章解决「坏数据混进系统」的痛点。

这是什么

Pydantic 是后端的一个工具，作用是照着你定义的数据结构，自动检查每一条进来的数据「合不合格」，把不合格的挡在门外。

它就像门口的验票员：你规定了「标题不能为空」「优先级只能是高 / 中 / 低」，验票员就照着这份规矩，一条条检查进来的数据——票不对，直接拦下，根本不放进场。

为什么现在需要

早期数据简单、你自己一个人用，随便填也不会出事。但现在字段多了、规则复杂了（必填、可选值、类型），手工一个个检查又累又容易漏。Pydantic 能把上一章的「字段定义」直接变成「自动检查规则」，让坏数据进不来——这正是数据变复杂后最需要的一道保险。

在 AI Todo 里怎么用

我们把第 51 章定的那份字段定义，交给 AI 用 Pydantic 写成一个「校验规则」。之后后端每收到一条任务数据，都会先过一遍这个校验：合格才处理，不合格就返回一个清楚的错误提示。

让 AI 执行的小任务 

任务目标：
用 Pydantic 为 AI Todo 的任务数据加上自动校验。

当前状态：
后端目前对进来的任务数据几乎不做检查，容易混进不合规的数据。
我们已经定义好了任务的字段（标题、完成状态、分类、优先级、创建时间）。

限制条件：
这一步只加数据校验，不改动接口的整体行为；
校验规则要和我们之前定义的字段一致。

期望结果：
用 Pydantic 定义任务的数据模型，实现这些校验：
- 标题必填、不能为空；
- 优先级只能是「高 / 中 / 低」之一；
- 分类只能是约定好的几种之一；
当数据不合格时，后端返回清楚易懂的错误提示。

验收标准：
1. 提交一条正常任务，能正常保存。
2. 提交一条没有标题的任务，会被拦下并提示「标题不能为空」之类的错误。
3. 提交一个不存在的优先级（比如「超高」），会被拦下并提示。
4. 没有报错（指程序本身不崩，而是能优雅地返回校验错误）。

运行后看到什么

正常的任务照样能加进去；但当你故意提交一条空标题、或乱填优先级的任务时，后端不再默默收下，而是明确地告诉你「这条数据哪里不对」。坏数据被挡在了门外。

如何验收

  • 正常任务能正常保存？
  • 空标题的任务会被拦下，并给出清楚提示？
  • 乱填的优先级会被拦下，并给出清楚提示？
  • 程序本身不崩，只是礼貌地拒绝坏数据？

💡 验收 Pydantic 有个小窍门：专门去「使坏」。故意提交空的、错的、超范围的数据，看它拦不拦得住。拦得住，才说明这道保险真的装好了。

不对怎么反馈给 AI 

我提交了一条没有标题的任务，后端居然还是保存成功了，没有拦住。
请检查 Pydantic 的校验是不是没生效，让空标题、错误优先级这类数据能被正确拦下并返回明确的错误提示。

本章小结

Pydantic 是后端门口的验票员，照着你定义的字段规则，把不合格的数据挡在门外。验收方法——故意使坏，看它拦不拦得住。

53. FastAPI 是什么

这一章要解决什么问题

项目复杂到现在这个程度，Flask 有点力不从心了：数据校验要自己一处处写，接口有哪些、参数是什么全靠脑子记，也没有个地方能一目了然地看到「我这个后端到底提供了哪些接口」。这一章介绍一个更适合当前阶段的后端工具——FastAPI。

这是什么

FastAPI 和 Flask 一样，都是用来搭后端的工具。但它更适合「正经项目」。相比 Flask，它主要多了三样东西：

  • 自带数据校验：和上一章的 Pydantic 天生一对，数据合不合格自动检查，不用你手写。
  • 自动生成接口文档：它会自动生成一个网页，把「后端有哪些接口、每个接口要传什么、返回什么」列得清清楚楚。你打开浏览器就能看，甚至能直接在上面点着测试。
  • 更规范的工程结构：更适合功能多、要长期维护的项目。

打个比方：Flask 像一辆好上手的自行车，学骑车正合适；FastAPI 像一辆带仪表盘和安全系统的车，跑长途、拉重货更稳妥。

为什么现在需要

前期我们故意选 Flask，因为它简单、门槛低，适合入门——这在当时是对的选择。但现在项目复杂了：要严格的数据校验、要能看清所有接口、要更规范的结构。到了这个阶段，FastAPI + Pydantic 的组合就比 Flask 更合适了。 这不是说 Flask 不好，而是「不同阶段，选不同的工具」。

在 AI Todo 里怎么用

这一章我们先认识 FastAPI，理解它「多出来的好处」，尤其是那个自动接口文档——它对你这样的非技术负责人特别友好，让你第一次能「看见」自己的后端全貌。下一章我们正式把项目从 Flask 迁移过去。

让 AI 执行的小任务

先不急着迁移整个项目，我们让 AI 用 FastAPI 做一个小小的演示，让你亲眼看看那个「自动接口文档」长什么样：

任务目标：
用 FastAPI 做一个最小的示例，让我体验它自动生成的接口文档。

当前状态：
我现在的后端是 Flask，我想先直观感受一下 FastAPI 多了什么。

限制条件：
只做一个独立的小示例，先不要动我现有的 Flask 项目；
示例尽量简单。

期望结果：
用 FastAPI 写一个最简单的接口（比如返回一条示例任务），
然后告诉我怎么启动它、以及在浏览器里打开哪个地址能看到「自动生成的接口文档」页面。

验收标准：
1. 你告诉我启动命令和访问地址。
2. 我在浏览器打开那个地址，能看到一个列出接口的文档页面。
3. 我能在那个页面上直接点一下、测试这个接口。
4. 没有报错。

运行后看到什么

AI 会让你启动这个小示例，并访问一个地址（通常是 http://localhost:8000/docs）。打开后，你会看到一个自动生成的接口文档页面——上面列着接口，还能直接点「试一下」按钮实测。这是 Flask 默认不会给你的东西。

如何验收

  • 小示例能启动，不报错？
  • 浏览器里能打开那个接口文档页面？
  • 页面上能看到接口，并且能点着测试？

💡 那个自动接口文档，是 FastAPI 送给「产品负责人」的大礼。以前后端有哪些接口，你只能问 AI 或翻代码；现在你自己打开一个网页就能一目了然，还能亲手测。能看见，才好验收。

不对怎么反馈给 AI 

我按你说的启动了 FastAPI 示例，但打开 /docs 页面是打不开的（或报错）。
报错 / 现象如下：
<粘贴报错或描述现象>
请检查并修好，然后再告诉我一次正确的启动命令和文档页面地址。

本章小结

FastAPI 是更适合正经项目的后端工具：自带数据校验、自动生成接口文档、结构更规范。它最贴心的地方，是让非技术的你也能打开网页看见并测试自己的后端。

54. 为什么从 Flask 升级到 FastAPI

这一章要解决什么问题

前面几章的痛点，到这里要「收口」了：数据校验想自动化、接口想一目了然、结构想更规范——这些加在一起，就指向同一个动作：把后端从 Flask 平滑升级到 FastAPI。这一章讲清楚「什么时候该升级、升级能得到什么」，然后动手迁移。

这是什么：一次「平滑演进」，不是推翻重做

首先要打消一个顾虑：升级不等于把项目推倒重来。 我们不是删掉 Flask 从零再写一遍，而是让 AI 把现有的接口，一个个平稳地「搬」到 FastAPI 上——功能不变、行为不变，只是换了更结实的地基。这活儿又多又细，正是最该交给 Claude Code / Codex 的。

为什么现在需要：升级的「触发条件」

💡 这是一道很重要的选择题：要不要升级？答案是「看阶段」。 不是所有项目都该升级到 FastAPI——一个只有你自己用、功能很少的小玩意儿，用 Flask 一直用下去完全没问题。是我们这个项目到了这个阶段，触发条件凑齐了，才值得升级：

  • 数据变复杂了，需要自动校验（Pydantic）；
  • 接口变多了，需要能一眼看清全貌（自动文档）；
  • 项目要长期维护、继续长大，需要更规范的结构。

这三条都撞上了，升级的收益才大于成本。过早升级是折腾，恰逢其时才是升级。

在 AI Todo 里怎么用

我们让 AI 把整个后端从 Flask 迁移到 FastAPI，并把第 51、52 章定的数据结构和 Pydantic 校验一起接上。迁移完成后，你的接口行为应该和之前一模一样，但你会多得到两样东西：一个能打开的自动接口文档，和一道真正生效的数据校验。

让 AI 执行的小任务 

任务目标：
把 AI Todo 的后端从 Flask 平滑迁移到 FastAPI。

当前状态：
现在后端用的是 Flask + SQLite，已经有添加、查询、完成、删除任务等接口。
我们已经定义好任务的数据结构，也希望用 Pydantic 做数据校验。

限制条件：
这是一次平滑迁移，不是重写：
- 所有接口的功能和行为都要和之前保持一致（前端不用改就能继续用）；
- 数据（SQLite 里已有的任务）不能丢；
- 一步步来，迁移完确保能正常运行。

期望结果：
1. 后端改用 FastAPI；
2. 用 Pydantic 对任务数据做校验（标题必填、优先级只能是高/中/低等）；
3. 保留并接上原有的所有接口，行为不变；
4. 能打开 FastAPI 自动生成的接口文档页面。

验收标准：
1. 前端不做修改，依然能正常添加、查看、完成、删除任务。
2. 我能在浏览器打开自动生成的接口文档页面（告诉我地址）。
3. 提交不合格数据（空标题、错误优先级）会被校验拦下并给出提示。
4. 原有的任务数据还在，没有丢。
5. 迁移过程中的报错都已解决，最终能正常启动。

运行后看到什么

前端那边你看不出任何变化——添加、勾选、删除，一切照旧，这正说明迁移是「平滑」的。但后端悄悄升级了：打开接口文档地址（通常是 http://localhost:8000/docs），你能看到所有接口整整齐齐列在那里；故意提交坏数据，也会被稳稳拦下。

如何验收

对照三条硬指标逐一打勾：

  • 接口行为不变：前端一行没改，添加 / 查看 / 完成 / 删除任务全都照常？
  • 能打开自动接口文档：浏览器访问文档地址，看到接口列表，还能点着测试？
  • 数据校验生效：提交空标题、错误优先级，会被拦下并给出清楚提示？
  • 原有任务数据没丢？
  • 最终能正常启动，没有遗留报错？

⚠️ 迁移这种「大手术」最怕两件事：数据丢了和某个接口悄悄坏了。所以验收时别只看新功能，一定要把原来能用的每个操作都亲手点一遍，确认它们还都好使。

不对怎么反馈给 AI 

迁移到 FastAPI 后，出现了问题：
<例如：前端添加任务没反应了 / 接口文档打不开 / 原来的任务数据不见了>
具体现象和报错如下：
<粘贴报错或描述>
请在保证接口行为和之前完全一致、且不丢数据的前提下修好这个问题。

本章小结

当「数据要校验、接口要看清、结构要规范」三个触发条件凑齐，就到了从 Flask 升级到 FastAPI 的时候。升级是平滑演进而非推翻重做，交给 AI 来搬。验收三件事——接口行为不变、接口文档能打开、数据校验生效。而「要不要升级」，永远是一道看阶段的选择题。

这一部分的收尾

这一部分，你没有给产品加任何新功能，但它却变得更「结实」了。回头看你做的每一件事，其实都是被同一个逻辑推着走的——先出现痛点，再对症下药：

  • 文件乱了 → 整理项目结构，各归各位；
  • 代码重复了 → 抽成 Vue 组件，一改全改；
  • 风格花了 → 用 Tailwind 统一视觉；
  • 数据对不上了 → 先定义数据结构，钉死字段；
  • 坏数据混进来了 → 用 Pydantic 挡在门外；
  • 后端力不从心了 → 升级到 FastAPI，换个结实地基。

如果说前面的部分是让产品从不能用到能用，那么这一部分，是让它从能用走向耐用、好维护。这就是「工程化」的全部意义——它不炫技，它只是让你的产品扛得住时间、扛得住继续长大。

而这一路你也再次印证了那道选择题：工程化不是越多越早越好，而是等痛点真的出现时，才恰逢其时。

产品既好用又耐用了，那就只剩最后一件大事——让全世界都能访问到它。我们去 第十部分：Docker 与部署，把这个 AI Todo 真正送上云端。

最后更新于
第八部分 · 学会指挥 AI 开发第十部分 · Docker 与部署