前端转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 天学到的内容有一个全局印象我把每天的学习主题整理成一张表天数主题关键产出Day 1大模型 API 初探注册、鉴权、最简调用跑通第一个“文本生成”脚本Day 2理解 Token、上下文窗口、temperature 参数完成参数调试实验记录Day 3React 搭建 AI 聊天页面静态 UI完成一个可交互的聊天界面Day 4对接后端代理解决跨域问题前后端联调通过Day 5提示词工程结构化提示词与少样本示例总结出自己的提示词模板Day 6流式输出与增量渲染实现打字机效果Day 7上下文管理消息数组与历史摘要实现多轮对话不“失忆”Day 8Function Calling 初探让模型学会“调用工具”实现天气查询工具的调用Day 9AI Agent 概念梳理从模型到 Agent 的跃迁写出一篇 Agent 入门笔记Day 10Django WebSocket 实时推送后端数据实时到前端页面Day 11前端数字孪生入门做了一个简单的 3D 数据绑定 DemoDay 12读一个开源 AI 前端组件库的源码理解流式消息组件的实现Day 13AI 应用中的错误处理与降级策略给聊天页面补充异常提示与重试Day 14规划并提交阶段复盘本篇你可能注意到第 8 天之后我接触了一个关键词AI AgentAI 智能体。这是我从第二周开始意识到的最重要的方向。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_datajson.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 输出一个结构化的请求我这边解析这个请求执行对应的真实函数把结果作为新的消息返回给模型。核心流程大致是前端发送用户输入“杭州明天适合跑步吗”模型返回function_call: get_weather(city杭州, date明天)我执行真实的天气查询函数拿到结果把结果追加到消息数组让模型组织成自然语言回复前端把整个过程的调用链展示出来这个项目让我第一次切身体会到模型只是 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复盘时我亲手画了一张“能力迁移对照表”想清楚哪些前端技能可以直接沿用哪些需要补课。这张表很直观前端已有能力迁移到 AI 领域的用途需要补强的地方React/Vue 组件化思维构建 AI 应用界面、封装流式对话组件、可视化 Agent 执行状态流式数据的增量渲染性能优化状态管理与数据流管理对话上下文、Agent 执行状态、多轮工具调用记录长会话的内存与 Token 控制前后端联调经验理解 AI 应用的 API 边界、设计后端代理层需要补充 Python 基础异步编程Promise/async处理模型调用的异步回调、流式读取、并发控制熟悉 SSE、WebSocket 等实时协议UI/UX 设计感设计 AI 交互界面流式输出、状态提示、容错界面理解 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 项目上到时候再来做一次更硬核的复盘。