前端转AI第15天阶段复盘：从API调优到Agent雏形的实战经验

第 15 天，进度条走到 14%。说实话，这个节点卡得有点微妙——刚熬过最初的新鲜感，又还没看到真正的成果，恰恰是最容易放弃的时候。所以我不打算急着往下灌新知识，而是把这 14 天翻出来彻底复盘一遍。这个“前端转 AI 100 天”计划，本意是记录一个前端开发者如何系统性地转向 AI 方向，每天输出一篇学习笔记。如果你也在关注前端开发的新出路，或者正在犹豫要不要碰 AI 大模型相关内容，这篇 Day 15 的阶段复盘，应该能给你一份足够真实的参考。我会把学到的东西、踩过的坑、以及后续路线的调整，全部摊开来讲。

1. 先回答自己一个问题：为什么要做“阶段复盘”

1.1 学习最怕的不是慢，而是“假装在学”

我见过太多人（包括以前的我）学东西是这样的：收藏夹里存了一堆教程，每天打开几个视频，跟着敲两行代码，感觉“今天也在努力”。但两周后回头一看，问自己“你到底学会了什么”，答案往往是支离破碎的——这个会一点，那个会一点，但哪个都不能独立做出一个完整的东西。

复盘本质上是强制自己从“输入模式”切换到“整理模式”。前 14 天我输入了大量信息：大模型 API 文档、提示词工程技巧、前端 AI 组件库的源码、Agent 相关的概念文章。如果没有一个阶段性的梳理，这些信息就是散落在脑子里的碎片。只有当我坐下来，试着把它们写成结构化的总结时，才发现哪些是真懂了，哪些只是“我看过”而已。

1.2 复盘模型：知识、技能、作品三个维度

我做复盘用的框架很简单，就三个维度：

• 知识：头脑中新增的概念和原理，比如什么是 Token、什么是上下文窗口、什么是 Function Calling、RAG 的基本流程。
• 技能：能动手操作的能力，比如用 React 封装一个流式对话组件、用 Python 写一个调用大模型 API 的脚本、配置 Django WebSocket 服务端。
• 作品：能拿得出手的产出，比如一个可以运行的聊天 Demo、一个实时推送数据的页面、一篇记录踩坑过程的笔记。

这三个维度是递进关系。知识是最容易获取的，看一篇文章就有了；技能需要动手练，至少踩几次坑才能算掌握；作品才是真正稀缺的，因为它意味着你把知识内化成了自己的东西。我复盘时发现，前 14 天我在“知识”维度的收获最多，大约占 70%；“技能”维度大概 25%；“作品”维度只有可怜的几个 Demo。这个比例不算健康，所以后文能看出我调整了策略。

1.3 复盘的产出：一份能指导下一个 14 天的行动清单

复盘不能只是“回顾过去”，它的真正价值在于“指导未来”。我会在最后部分给出 Day 16 到 Day 30 的行动清单，但现在先把结论放在这里：下一个阶段，我会把重心从“学知识”转向“做作品”。理由很简单，AI 领域的信息更新太快了，你永远不可能“学完再开始”。更合理的做法是带着一个具体目标去学，遇到什么问题解决什么问题，用作品倒逼输入。

这也是我写这篇复盘最想传达的经验：阶段复盘不是给自己打分，而是帮自己校正方向。分数低了没关系，方向偏了才是问题。

2. 前端转 AI，起点比很多人想的好

2.1 技术栈迁移没有想象中那么痛苦

最开始那两天，我内心是有焦虑的。AI 领域铺天盖地的都是 Python、PyTorch、模型训练、数学公式，我一度觉得自己是不是选错了方向。但真正开始动手之后，我发现一个被反复验证的事实：对于大多数“前端转 AI”的人而言，你做的不应该是“研究大模型原理”，而是“让大模型成为你的能力来源”。

这个定位差异很重要。研究大模型原理，需要对机器学习、深度神经网络、数学优化有系统理解，那是算法工程师的路径；而作为一名前端转 AI 的工程师，你的优势在于知道如何构建用户界面、如何与后端协作、如何处理数据流。AI 在你这里不是研究对象，而是工具。就好比你是厨房里掌勺的厨师，不需要懂怎么炼铁铸锅，但你需要知道哪口锅好用、火候怎么控制、什么时候该开大火什么时候该转小火。这个大模型就是那口锅，而提示词工程、API 参数调优、流式处理就是你的控火技术。

前端工程师的技术栈完全没有被浪费：JavaScript/TypeScript 依然是 AI 应用领域最重要的编程语言之一——无论是浏览器端集成，还是 Node.js 中间层，甚至不少 AI 应用的前端 SDK 都以 TS 作为首选语言。我第 3 天写的“AI 聊天室”Demo，整个交互层全部用 React 完成，一点 Python 都没碰。所以别怕转型等于从零开始。

2.2 前端能力在 AI 应用中的位置

我画过一条很朴素的价值链：数据 → 模型 → 应用 → 用户。模型解决“理解与生成”的问题，但用户不直接面向模型，用户面向的是应用。应用是什么？对一个前端工程师来说，应用就是你写的页面、组件、交互逻辑、状态管理、API 对接层。

AI 应用相比传统应用，最大的不同在于交互方式——从“用户操作，系统响应”变成了更自然的对话式交互，而且数据是流式的。模型生成内容不是一次性吐出来的，而是一块一块地传回来的，像聊天框里一个字一个字往外蹦的效果。这个体验细节，决定了一个 AI 聊天页面是“能用”还是“好用”。前端在这里的价值非常具体：如何渲染流式文本、如何管理对话历史、如何处理中断和重试、如何用数字孪生或可视化技术展示 AI 的分析结果——这些都是前端技能在 AI 场景中的直接延伸。

我身边有些前端朋友很焦虑，觉得 AI 会替代初级前端的工作。但我的观察恰恰相反：需要懂 AI 的应用型前端岗位正在增加，而不是减少。普通的表单页面、管理系统需求确实在萎缩，但具备“能和大模型配合干活”能力的前端，正在进入一个新的上升通道。这也是我把 100 天押注在这个方向的原因。

2.3 AI 前端生态正在快速成熟

一个让我印象很深的信号是：AI 的前端基础设施已经形成了一个相对完整的生态，从底层 API 封装到上层 UI 组件，都能找到成熟方案。比如阿里开源过 AI 会话前端控件，帮你省掉聊天界面里大量的重复工作——消息列表、输入框、流式文本渲染、状态管理，开箱即用。这和当年 jQuery 出来时简化 DOM 操作、React 出来时统一组件化思维是类似的性质。

组件库成熟的另一面意味着：早期的红利来自“比别人更早掌握”，而现在红利更多来自“组合能力”——把现成的 AI 组件库、大模型 API、前端框架组合成一个完整应用。作为前端工程师，我们恰恰是最擅长做“组合”的人。14 天里我至少接触了 5 个开源的 AI 前端项目，读它们的源码让我意识到：这条路越来越清晰，也越来越拥挤。清晰的好的方向，拥挤是正常的，说明需求真实存在。

3. 14 天具体学了什么：一条从“调 API”到“Agent 雏形”的路线

3.1 第一周：把大模型当成一个“会生成文本的函数”

Day 1 到 Day 7，我做的事情可以用一句话概括：学会稳定地调用大模型 API，并理解它的脾气。如果你从来没碰过大模型 API，我建议先建立一个核心认知：无论底层模型多复杂，对你来说它就是一个输入文本、输出文本的函数。你传入一串字符（提示词），它给你返回另一串字符（回答）。所有复杂的机制——Token 化、注意力机制、概率采样——最终都体现在“同样的输入，给你不同的输出”这个现象上。

在这个阶段我做的事包括：

• 注册并申请大模型 API 的访问凭证（选了一个兼容 OpenAI 接口格式的平台，这样以后切换模型不用改代码）。
• 用 Python 写一个最简调用脚本，设置model、messages、temperature三个最核心的参数。
• 弄懂了messages数组的结构：system设定模型角色，user是用户输入，assistant是模型回复。多轮对话其实就是不断往这个数组里追加消息。
• 把temperature当成“胆量旋钮”来做实验：设成 0 时回答稳定但略显刻板，设成 0.8 时想象力丰富但偶尔跑偏。这个参数是调试模型行为时最先要调的旋钮。

第一周最大的认知刷新在于：大模型不需要“教”，它需要“引导”。你不需要告诉它“你是 AI”“请不要说错误信息”——这些都是废话；你需要给它清晰的上下文、角色定位、输出格式约束和示例。大多数人觉得 Prompt 玄学，是因为没有把提示词当成代码来写——好的提示词应该是有结构的、可测试的、可版本化的。

到这里我还做了一个小实验：不用任何封装库，用原生fetch从浏览器直接调大模型接口。结果自然是被跨域拦了个正着。这反而成了我最值钱的教训之一——直接暴露了 API 密钥会被任何人看到，跨域策略会拦掉纯前端调用。结论是：前端不能直接对接模型 API，必须有一个后端中间层做代理。这个认知在第 3 周帮我避免了很多幼稚的架构设计。

3.2 第二周：从前端调用到完整交互链路

Day 8 到 Day 14，我开始做一个真正的前端页面：AI 聊天助手。这跟第一周的脚本调用完全不同，因为它涉及的不只是“调一个接口”，而是完整的应用交互链路。

技术栈是 React + Vite，后端临时用 Node.js 的 Express 搭了一个代理服务。前端页面的核心功能有三个：输入提问、接收流式回复、展示多轮对话历史。最开始我以为最难的是前端渲染部分，后来发现真正的难点是流式处理。大模型接口返回内容是按块的（SSE 协议，Server-Sent Events），你需要不断读取数据流、解析分块内容、增量更新界面。我第一次实现时，界面上的文字迟迟不出来，后来发现是解析的事件格式不对，快照里多了一个data:前缀没处理掉。这类问题文档里不会写，只能靠调试经验。

然后是对话上下文管理。一开始我只把用户最新的问题发给模型，模型回答得特别“失忆”——你刚说完“我今年 28 岁，住在杭州”，下一轮问“我家门口下雨吗”，它完全不记得你之前说过什么。后来才意识到要维护一个消息数组，每次请求把整个历史都带上。但历史带多了又会出现新问题：Token 数量上涨，响应变慢，调用成本变高。这时候才真正理解“上下文窗口”这个概念意味着什么——它不只是技术参数，而是产品体验和成本的核心制约因素。我做一个简单的 token 估算函数，大致算出历史消息的占用，超过阈值就自动裁掉最早的几条。

第二周的另外两块内容是数据可视化方向的延伸。一是了解了前端数字孪生的基础概念，尝试把一个简单的 3D 场景和实时数据绑定在一起——数据一变，页面上对应区域的形态就动。二是花了一天学了 Django WebSocket 的核心用法，用 Python 后端往前端页面实时推送数据。这两个东西在传统前端项目中属于“高阶玩法”，在 AI 场景里却是常态：AI 分析的结果需要实时可视化，AI Agent 的执行过程需要实时推送给用户看。

3.3 14 天学习清单速览

为了让你对前 14 天学到的内容有一个全局印象，我把每天的学习主题整理成一张表：

你可能注意到，第 8 天之后我接触了一个关键词：AI Agent（AI 智能体）。这是我从第二周开始意识到的最重要的方向。Agent 不是我一开始以为的“更聪明的聊天机器人”，而是一个更主动的系统——它能理解目标、拆解步骤、调用外部工具、根据结果调整策略。前端在这个领域的切入点在于 Agent 执行过程的可视化呈现：让用户看到 Agent 正在做什么、下一步要做什么。这会让“AI 在执行任务”这件事从黑盒变得透明可信。

4. 实操复盘：三个小项目把我按在地上摩擦

4.1 项目一：AI 聊天助手的前端落地

这个项目是前 14 天的核心作品，虽然只有几百行代码，但它逼迫我完整走过一遍“前端 + 大模型”的链路。我在这里把关键实现细节拆开讲，这样你可以直接参考。

首先是后端代理。我用 Express 写了一个最简单但完整可用的中转服务：

const express = require('express'); const app = express(); // 重要：中间层必须处理跨域，并且不要把密钥暴露给前端 const cors = require('cors'); app.use(cors()); app.post('/api/chat', async (req, res) => { const { messages, temperature = 0.7 } = req.body; const response = await fetch(process.env.MODEL_API_URL, { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${process.env.MODEL_API_KEY}` }, body: JSON.stringify({ model: process.env.MODEL_NAME, messages, temperature, stream: true }) }); // 直接以流的方式回传前端，不做缓冲 response.body.pipe(res); });

前端调用时，关键是要用fetch结合ReadableStream来逐步读取：

const res = await fetch('http://localhost:3000/api/chat', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ messages }) }); const reader = res.body.getReader(); const decoder = new TextDecoder(); while (true) { const { done, value } = await reader.read(); if (done) break; const chunk = decoder.decode(value, { stream: true }); // 这里解析 SSE 数据行，增量追加到界面 handleChunk(chunk); }

这个项目里最容易出问题的不是代码逻辑，而是工程细节。比如：用户在流式输出还没结束时直接关闭页面，应该中断调用而不是让它继续在后台烧 Token；网络不稳定时，流式响应会中途断掉，需要提供“重新生成”的能力；useEffect里请求异步状态更新时，要注意组件已经卸载的情况，否则 React 会报内存泄漏警告。

4.2 项目二：Django WebSocket 实时推送

第二个项目起因很明确：AI 执行任务的过程往往比较长，如果用户盯着一个静止页面，体验会非常煎熬。我想到的方案是用 WebSocket 往前端推送进度事件——模型每完成一步，后端就推一个状态，前端实时更新界面。

Django 侧我用的是 Channels 库，核心代码大致是：

import json from channels.generic.websocket import AsyncWebsocketConsumer class TaskProgressConsumer(AsyncWebsocketConsumer): async def connect(self): self.group_name = 'task_progress' await self.channel_layer.group_add(self.group_name, self.channel_name) await self.accept() async def disconnect(self, close_code): await self.channel_layer.group_discard(self.group_name, self.channel_name) async def send_progress(self, event): await self.send(text_data=json.dumps({ 'stage': event['stage'], 'percent': event['percent'], 'message': event['message'] }))

前端这边则是WebSocket+ 事件分发：收到stage字段，就切换页面上的步骤高亮；收到percent，就更新进度条。跨域配置、心跳保活、断线自动重连是我在这个项目里补的三门“小学问”。心跳保活是最容易忽略的——不少 WebSocket 连接会被中间的代理闲置超时断开，前端需要每隔一段时间发一个 ping 消息维持连接，否则长任务跑到一半就断流了。

这里想多插一句：很多人学 WebSocket 只关注“怎么连”，很少关注“断线了怎么办”。我的经验是，断线重连才是实际生产环境中最关键的逻辑——连接一定会断，你的代码必须假定断线是常态，而不是异常。这个思维方式放在 AI 应用里同样适用：大模型调用的失败率远高于传统接口，你的前端必须把“重试”“降级”“暂停”“继续”这些状态都考虑进去。

4.3 项目三：做一个会“调用工具”的 Agent 雏形

第三个项目原本不在前 14 天的计划里，但第 8 天学习 Function Calling 时我忍不住动手了。这个项目的价值在于让我真正理解了AI Agent 的工作闭环。

Agent 的本质是这样一个循环：用户给目标 → 模型拆解步骤 → 决定调用哪个工具 → 调用工具拿到结果 → 把结果反馈给模型 → 模型决定下一步 → 直到任务完成。前端在这个项目里的角色很有趣：我要给用户展示 Agent 的“思考过程”——它正在调用什么工具、拿到了什么结果、下一步准备做什么。这个可视化界面做得好不好，直接决定了用户对 Agent 的信任度。

为了让演示效果直观，我实现了两个简单的工具函数：一个是计算器，一个是模拟的天气查询接口。模型通过 Function Calling 输出一个结构化的请求，我这边解析这个请求，执行对应的真实函数，把结果作为新的消息返回给模型。核心流程大致是：

1. 前端发送用户输入“杭州明天适合跑步吗？”
2. 模型返回function_call: get_weather(city=杭州, date=明天)
3. 我执行真实的天气查询函数，拿到结果
4. 把结果追加到消息数组，让模型组织成自然语言回复
5. 前端把整个过程的调用链展示出来

这个项目让我第一次切身体会到：模型只是 Agent 的“大脑”，真正的能力来自你给它接的“手脚”——工具库的设计、工具的输入输出约定、工具调用的安全控制，这些工程问题才是落地时要花大力气的地方。

5. 踩坑实录与排查方法

5.1 环境与工程问题

我总结一下前两周遇到的最有代表性的几个坑，按照“现象 → 排查 → 解决”的结构写，方便你以后直接对照。

坑一：API 密钥写在前端代码里

现象：我把密钥写在页面的.env文件里，然后用VITE_APP_KEY方式引入。后来发现，所有以VITE_开头的变量都会被打包进浏览器可访问的静态文件里。这意味着任何人打开 DevTools，就能看到我的密钥。教训一句话：前端代码里没有秘密，绝对不要把任何密钥、口令、敏感配置放进前端工程。正确做法是让后端代理去持有密钥，前端只和后端通信。

坑二：跨域配置不全导致“能跑但经常报错”

现象：接口一开始是通的，但某些请求偶尔报 CORS 错误。排查下来发现，错误发生在自定义请求头（如Authorization）和预检请求（OPTIONS）没被正确处理。解决方法是把允许的方法、允许的请求头、预检请求的响应全部配置完整。这里建议直接看浏览器 Network 面板里的失败请求预览，里面会明确告诉你哪个响应头缺失。

坑三：SSE 流式解析脆弱

现象：流式内容在某些情况下会乱码或丢弃。原因是我解析 SSE 时简单按行处理，但中文内容可能被拆到不同 chunk 里，导致解码乱码。解决方法是使用TextDecoder的stream: true参数，它会在内部处理多字节字符的拆分问题。另外，SSE 消息之间的分隔符是空行，不要用换行来切割。

5.2 模型行为问题

工程问题靠调试解决，模型行为问题则需要“驯服”。有几个现象值得记录：

现象一：模型“一本正经地胡说八道”

有次我问它“React 19 的某个新 API 怎么用”，它给出了一个看起来很完整的示例代码，但那个 API 其实并不存在。这是大模型的经典问题——模型根据概率“生成”而非“检索”，所以它会生造内容。我的解决方案是：凡是涉及具体文档、API 版本的信息，必须标注来源，并且让模型说明不确定的地方。在提示词里加一句“如果不确定或信息可能过期，请明确说‘我不确定’，不要猜测”，能把幻觉比例降低不少。

现象二：温度参数不是越高越好

我发现同一个问题在temperature = 1.2时会产出完全跑题的答案，降到0.3后明显收敛。但温度过低也有副作用：答案变得机械、缺少变化，甚至出现重复句式。经过反复试验，我的建议是：需要创意（文案、头脑风暴）时用0.7~0.9；需要准确性（代码、总结、提取信息）时用0.2~0.4。这个参数值得你做一组对照测试，找到最适合你的模型和场景的值。

现象三：上下文太长，费用和时间暴涨

对话进行到第 15 轮时，单次请求的消息数组已经非常庞大，每次请求的响应时间肉眼可见地变慢。我做了两个补救措施：一是把超过一定轮数的早期历史消息做摘要——调用模型把前面的内容压缩成一段摘要，替换掉完整历史；二是设置单轮回复的最大 Token 数，避免模型生成过长的内容。

5.3 今天我会直接绕开的坑

有些坑我踩过之后才发现完全可以提前避免。比如：

• 不要在项目一开始就追求“完整架构”——先写一个 50 行的原型，把链路跑通，再逐层加代码。很多新手把时间花在搭目录结构上，结果连核心接口都没调通过。
• 不要同时学太多框架——AI 领域每天都有新工具出来，一会儿 LangChain，一会儿 LlamaIndex，一会儿新的 Agent 框架。第 6 天时我一度陷入“框架选择焦虑”，后来强行给自己定了一条规矩：先学不依赖框架也能跑通的原理，再回头看框架会觉得豁然开朗。原理是根，框架是枝叶。
• 不要一个人埋头苦干——我第 9 天写 Agent 笔记时卡了一下午，后来去社区搜了半天，发现别人踩过的坑和我的一模一样，照着别人的排查步骤十分钟就解决了。遇到问题先去搜索，搜索不到再自己折腾，这是效率最高的路径。

6. 成果自评与能力迁移地图

6.1 用一张表看清前端能力如何迁移到 AI

复盘时我亲手画了一张“能力迁移对照表”，想清楚哪些前端技能可以直接沿用，哪些需要补课。这张表很直观：

这张表对我最大的作用，是帮我扔掉“转型等于清零”的包袱。实际上带得走的前端能力至少有一半以上，剩下的核心补课项就是 Python 基础、模型 API 的机制、以及 Agent 相关的工程模式。

6.2 目前的能力边界：清楚自己“还不会什么”

复盘不能只看收获，也要看清边界。我现在的能力是：能独立完成一个中等复杂度的 AI 前端应用（聊天、流式渲染、Agent 状态展示），能写简单的 Python 后端（Express 或 Django 的代理服务），能读懂大模型 API 文档并做参数调优。但我还不会：模型微调、RAG 的实现细节、向量数据库的使用、复杂的 Agent 多工具编排、模型评估与安全测试。

这个边界认知很重要。因为市场上对“AI 工程师”的岗位要求差异很大，有的偏模型训练，有的偏应用工程。我现阶段的方向很明确：做偏应用方向的 AI 前端工程师，主打“AI 应用化”能力，而不是“AI 理论化”能力。这不是逃避技术的深度，而是基于自身背景做出的差异化定位。前端工程师做 AI 应用的天然优势在于产品和用户体验的敏感度，这是纯算法背景的人相对欠缺的。

与此相关的一个观察是：我最近翻了翻 2026 年的前端面试题趋势，发现很多公司已经开始在常规前端面试中加入 AI 相关内容——不是问“你怎么用 AI”，而是问“你怎么把 AI 集成到前端产品里”。从某种角度看，这已经不是“转行”的问题，而是“前端这个职位本身的技能集合在扩容”。如果你现在还在做传统前端，提前接触 AI 集成的技能，对面试和晋升都会是明确的加分项。这也是我敢把 100 天押在这个方向的原因之一——我并不是在逃离前端，而是在拓展前端的边界。

7. 下一个 14 天怎么走

7.1 学习路线的三个调整

复盘之后，我给 Day 16 到 Day 30 阶段定了一个新的路线，核心思路是“少学多做”。具体有三个调整：

调整一：从“知识输入”转向“作品输出”。下一个 14 天我会把一个真实场景的项目做完——做一个“AI 知识库问答工具”的完整 Demo。用户能上传文档，系统自动做切分和向量化，用户提问时能基于文档内容回答，而不是凭空发挥。这个项目涉及 RAG 的核心流程，也是目前 AI 应用落地最广泛的能力之一。

调整二：补 Python 和数据处理的基础。在前两个项目里，Python 只是被我当脚本语言用，一遇到数据处理就捉襟见肘。所以我会用零碎时间过一遍 Python 的语法、文件读写、Requests 库、以及最基础的 pandas 操作。目标不是成为 Python 专家，而是能看懂 AI 后端项目的代码，能自己写数据处理脚本。

调整三：建立“多 AI 协作”的实践视角。最近我一直在思考一个有意思的工程方向：不同的大模型有各自擅长的领域，有的擅长代码，有的擅长创意写作，有的擅长逻辑推理。一个应用能不能在中间层做路由，根据用户请求的类型动态选择最合适的模型，实现“多 AI 协作”的效果？这个方向对前端工程师的架构能力是一个很好的锻炼，也具备很高的实践价值。我会在接下来的项目里做一些最小验证。

7.2 给同样在转型路上的人几句实在话

复盘做到最后，我想说几句可能不太中听但非常实在的话。

第一，转型不是百米冲刺，而是一场马拉松。100 天听着很长，实际上每天能投入的有效学习时间也就 2 到 4 小时。不要把目标定得太宏大——不要指望 100 天能从零变成 AI 专家，但要指望 100 天后，你能做出让之前自己惊叹的作品。

第二，把学习成果可视化。我要求自己每天输出一篇笔记，哪怕只有几百字，关键是让“今天学到了什么”变得可见。人的记忆是不可靠的，但笔记和 Demo 不会骗人。复盘的这一天我翻看前 14 天的记录，发现很多当时觉得很难的东西现在一眼就能看懂，这种进步的实感，是坚持下去的最大动力。

第三，接受自己的笨拙。前两周我一度很沮丧，觉得 AI 领域的东西太多太杂，自己永远追不上。后来想通了一件事：那些看起来举重若轻的大神，也是一步步踩过来的，只不过你只看到了他们的高光时刻，没看到他们在调试时抓耳挠腮的样子。笨拙不可怕，重要的是你在往前走。

最后分享一个小技巧：我在手机桌面上放了一个小组件，显示“Day 15 / 100”这样的进度。每次点亮屏幕看到数字在增加，心里就会有一种“已经走了这么远，再走一段吧”的念头。保持记录、保持输出、保持一点点好胜心，这 100 天会比你想象的更快。下一个 14 天，我打算把重点放在 RAG 项目上，到时候再来做一次更硬核的复盘。