企业官网建设流程全解析

写这篇的时候，我盯着“DAY70”这个标记看了很久。七十天，放在一个还要带团队、开会、评审、救火的前端Leader身上，几乎是用早到公司的半小时和晚上靠后的一小时硬凑出来的。我学的是AI Agent方向，没有空谈转行，而是把每一个学到的能力都反过来喂给日常工作。如果你也在犹豫要不要投入这条线，这篇文章应该能给你一个相对完整的参考系：我为什么学、每天怎么挤时间、做了哪些能跑起来的东西、踩过哪些坑，以及接下来打算怎么走。这篇不是课程笔记，也不是资料汇总，就是一次个人复盘，尽量把过程和判断逻辑都摊开讲。

1. 为什么一个在职前端Leader要学AI Agent

1.1 技术管理者的焦虑：PPT愿景挡不住业务追问

先说动机。我负责的前端团队大概一年前开始频繁接到两类需求：一类是业务方问“能不能做个自动汇总周报的工具”，另一类是产品经理在评审会上提“这里能不能加个智能分析”。单纯的页面开发已经很难满足这些诉求，每次我都要去跟后端同学商量、去查有没有现成的中间件，最后往往落地成一套很重的流程。这让我意识到一个事实：如果连技术团队里带队的人都不去碰AI方向，那业务侧的增量需求就只能永远停留在“再说”的阶段。

另一个压力来自团队内部。组里年轻同事私下会问“AI会不会把前端岗位干掉”，虽然我每次都给出很确定的回答，但心里清楚，这种问题的底气来自对技术边界的了解，而不是来自安抚话术。只有自己动手做过几个Agent应用，知道哪些场景它擅长、哪些场景它完全不行，才能真正回答这个问题。带着这种心态，我开始整理自己的学习目标：不是成为一个“调包侠”，而是理解Agent应用的整体结构，知道它由哪些模块组成，出了问题能从哪一层去排查。

1.2 先想清楚：转行还是赋能现有岗位

在最开始的计划里，我把方向定为“学习/转行”，但实际走了二十多天我就改了主意。一个很现实的原因：在职状态下的学习时间极其有限，如果目标是“转行”，需要在算法、模型原理、工程部署等多个维度达到能通过面试的水平，这在一百天里几乎不可能。但如果是“赋能现有岗位”，我只需要把Agent当作一种能落地到日常工作的工程手段，目标就清晰很多。

于是我把目标调整为：让AI Agent成为前端团队的工具箱。具体来说，就是我一个人先把技术路线跑通，做出几个真实场景的Demo，再决定哪些适合推广、哪些还需要观望。这样既不耽误主业，又保住了未来的可能性。如果你也是在职学新方向，我建议别把“转行”当成唯一目标。一个可行的中间态是“岗位增量”——你学习的东西能立刻反哺现有工作，哪怕最后不转，投入的时间也不亏。

1.3 前端家底盘点：哪些技能可以无缝迁移

决定了路线之后，我花了一天时间盘点自己手里已有的技术栈，结论是前端背景比我想象的更适合学Agent。

最直接的迁移是异步编程模型。JavaScript里的Promise、async/await、事件循环，跟Agent应用里的异步调用、任务编排在思路上几乎是同一个套路。写一个Agent循环的时候，我脑子里冒出来的就是“这跟处理并发请求没啥区别”。

其次是调试习惯。前端调试靠DevTools、console和断点，Python的调试靠IDE断点和日志，两者思维完全通用。拿到一个报错，第一反应从“查浏览器Network面板”变成“查API返回体和日志”，这不需要重新学。

再者是组件化思想。React组件的props、回调函数、依赖注入，跟Agent应用里的工具注册、Function Calling、回调机制有很强的相似性。理解“给模型注册一个工具”就是“把函数当作props传进去”，一下子就通了。

盘完这些家底后，我心里踏实多了：这七十天的学习，不是从零开始，而是把已有的工程能力平移到一个新场景里。

2. 70天学习路径：从读得懂到写得出

2.1 第一个10天：把Python当成“另一种方言”来学

我是TypeScript重度用户，Java和C#也写过，但Python日常几乎不碰。所以头10天做的第一件事不是报班，而是清理抵触情绪。我的办法很简单：不系统学语法，直接写一个能解决实际小问题的小工具。当时我做了个“批量图片重命名+按尺寸分类”的脚本，用到了os、pathlib、PIL这些基础库，前后花了三个晚上。写完之后，Python对我就不再是“新语言”了，它只是“另一种方言”。

第二个重点是熟悉大模型API的基本调用格式。申请了某家开放平台的API后，我照着文档把message结构、system/user/assistant三种角色、上下文窗口这些概念过了一遍。这里我踩了第一个小坑：一开始习惯用很长的system提示词，发现费用高且响应变慢，后来才知道system提示词不是越多越好，几百字以内通常就够用。

这10天里还一定要搞懂三个参数：temperature（控制随机性）、max_tokens（限制输出长度）、top_p（核采样）。我用一个最简单的“翻译中英文本”的例子把这三个参数轮番调了一遍，记录不同取值下的输出变化。说实话，这些参数不看源码的话很难直观理解，但多跑几组对比就熟了。

2.2 中间20天：用前端思维硬啃Agent核心概念

第11天到第30天，我进入最烧脑也最关键的阶段：Agent的核心概念。这阶段的信息源是官方文档、开源示例和一个离线课程的回放。我没有买什么“从入门到精通”的纸书，因为这类内容更新太快，书上内容往往过时。对于在职学习，我强烈的建议是：以官方文档和真实代码为主，书为辅。

这期间有四个概念是我用前端思维才真正想明白的。

第一个是工具调用（Function Calling/Tool Use）。模型本身不执行外部操作，它只负责“决定调用哪个工具”，然后由程序真正执行函数，再把结果回传给模型。这个模式跟前端组件里“点击事件回调”完全一致：子组件不负责业务逻辑，只负责通知父组件发生了什么事。

第二个是记忆（Memory）。短期记忆就是上下文窗口里装的消息，长期记忆需要靠向量数据库做检索。这个有点像一个组件的state和localStorage：state是当前页面内的临时数据，localStorage是持久化存储。检索就是把localStorage里跟当前问题最相关的记录取回来塞进state。

第三个是规划（Planning）。Agent拿到一个复杂任务后，需要自主拆解成多步。前端领域其实到处都是这种逻辑：webpack的loader链、路由懒加载的分包、流水线的stage划分，都是把一个任务拆成多个阶段，再按顺序或并行执行。

第四个是Agent循环（ReAct）。模型先思考（Think），再决定动作（Act），然后观察结果（Observe），再进入下一步思考。这个循环本质上就是一个异步的while循环，跟前端里轮询请求状态是一个模式。想通了这一点，很多示例代码我就读得进去了。

2.3 后40天：项目驱动，让每个模块都有落点

第31天到第70天，我基本放弃“按章节学习”的路径，改成项目驱动学习法。理由很简单：在职Leader的时间太碎片，如果学的东西没有一个能看得见的落地场景，很难坚持到第70天。

于是我给自己定了一条硬规矩：每两周必须有一个能塞进日常工作的小Agent产出。第一个项目做了代码评审助手，第二个做了会议纪要转任务卡片，第三个做了前端组件文档自动生成，第四个做了个人知识库问答。这四件事都不大，但每一个都把当时学到的核心概念用了一遍，把不懂的环节暴露得很彻底。项目驱动的好处是，遇到不会的地方你会想办法解决而不是跳过，知识留存率高很多。

3. 能看见的四个产出：把学习换成实际效率

3.1 代码评审助手：给团队当“第二双眼睛”

代码评审是我作为前端Leader每周最高频的事情之一。一开始做这个Demo，是为了验证Function Calling和结构化输出，但真做出来之后发现它比预期更实用。

实现思路分四步。第一步，通过git diff获取本次改动的代码文本。第二步，把diff按文件切成片段，逐个发送给大模型。第三步，写一个非常具体的提示词模板，包含角色设定（前端技术评审）、变更文件类型、评审维度（潜在错误、可维护性、性能风险、安全问题）。第四步，要求模型输出固定结构的JSON，包含问题等级、行号、原因和修改建议。

关键的工程决策有两个。一是“只发变更行，不发完整文件”，因为完整文件容易超上下文限额，而且评审价值最高的本来就是改动部分。二是“强制JSON输出”，我在提示词里明确要求“只输出JSON，不要解释”，并在代码层面对返回内容做清洗。后来在实际使用中发现，模型偶尔还是会返回Markdown包裹的代码块，所以代码里加了一段从文本中提取JSON的正则兜底。

这个项目跑通后，我把它接进本地的git hook，每次提交前自动跑一轮简单评审。虽然不能替代人工评审，但能在评审前筛掉明显的低级问题，节省不少时间。成本方面，一次百行改动的评审大概消耗几千tokens，费用可以忽略不计。

3.2 会议纪要转任务卡：每周省下两小时

第二个产出解决的是团队会议记录的痛点。前端Leader一天平均三到五个会，会议里产生的决策、待办和负责人都散落在聊天记录里，每周都要花时间整理。

这个Agent的工作流是这样的：先用现成的语音转文字工具把会议录音转成文字稿，然后把文字稿喂给大模型，让它抽取“决策、待办、负责人、截止时间”四个字段，输出成结构化JSON。最后一步是自动化：把JSON转换成任务卡片，能在常用的任务管理工具里直接导入。

我遇到的坑在第一版就暴露了：模型在没有明确指令的情况下会自行添加“下一步建议”“风险提示”这类内容。后来在提示词里加了一句“只抽取原文中出现的信息，禁止推测”，输出才变得干净。还有一次是语音转文字的质量差，一段半小时的录音有一半内容识别错误，模型基于错误内容生成了不存在的待办。从那之后我调整策略：只对质量好的文字稿做生成，识别率低的会议先人工过一遍。这个Agent实际用了一个月，每周大约能省下两小时的处理时间，收益很直观。

3.3 组件文档生成Agent：解决最不愿意做的维护工作

第三个项目是给团队组件库自动生成文档。组件库有几十个组件，文档更新总是滞后，组员要查一个props的含义经常要翻源码。

第一版方案我走了弯路：直接把组件源码丢给模型，让它“读懂”并生成文档。结果因为组件文件太长，输出经常截断，而且理解常常有偏差。后来我把思路改成“类型解析优先”：先用TypeScript类型分析工具直接提取组件props的类型定义和默认值，这一步是程序自动完成的，完全不需要大模型参与。然后只把类型定义和渲染示例作为上下文，交给模型生成文档描述、props表格和代码示例。

这个改动让文档准确率大幅提升。原因是类型信息是结构化的、确定的，模型不需要猜测，它只需要把已经解析出来的字段用自然语言表达成说明文字。第二版稳定之后，我又让它同时输出组件名、功能描述、props表格和示例代码，直接生成为Markdown文件，放到现有的文档站里。

3.4 个人知识库问答Agent：让沉淀被检索回来

第四个产出其实是我个人笔记系统的升级版。我多年积累的前端笔记、管理记录、项目复盘散落在本地Markdown文件里，数量一多就吃灰。

实现方式用了RAG（检索增强生成）的经典流程：先把所有Markdown文件按章节切块，每一块控制在500字左右，相邻块保留50字重叠，避免切断语义；然后把每一块用开源的嵌入模型转成向量，存入本地向量数据库；查询时把问题转成向量，在库里检索最相关的top-k（我一般取3）个块，再把这些块拼到Prompt里，让大模型基于这些材料回答问题。

这个Agent对我个人来说价值极高。比如有次我想找一个半年前做过的一个兼容性处理方案，传统搜索翻了半天都没找到，用了这个Agent之后，几秒钟就给出了答案并附上了原文索引。我后来把团队的接口规范、评审标准也串了进去，新人问问题的时候可以直接让它查，省下不少重复答疑时间。

4. 在职Leader的时间账：每天90分钟到底怎么挤

4.1 Leader的日程画像：真正可控的时间只有早晚

做技术Leader的人都清楚，白天的时间基本不是自己的。早会、需求评审、代码评审、临时救火、一对一沟通，每一件都会打断思路。我统计过自己一周的专注时间，发现真正能连续投入学习的时间段只有两个：早上提前到公司的30分钟，晚上回家处理完琐事后的60分钟。如果当天不加班，晚上能多挤出30分钟；如果遇到发版或线上事故，则完全归零。

在职学习最关键的一点是接受“不完美”。今天没完成计划，不要第二天加倍补，而是把计划顺延，以周为单位看进度。像我这种70天跨度的学习，本质上靠的是“高频低强度”的节奏，而不是“周末集中突击”。周末我当然也会投入更多，但工作日每天90分钟的连续性，远比周末五个小时的突击有效。

4.2 90分钟的结构化拆解：输入、实践、沉淀

我每天的90分钟基本按三部分分：前30分钟看官方文档或读一段开源代码，中间30分钟动手写一个小例子，最后30分钟整理笔记和复盘。早上那半小时我通常用来做“输入”，因为刚起床脑子干净，能看得进去文档；晚上那60分钟中，一半用来“实践”，另一半用来“沉淀”。

“沉淀”这个环节我觉得很多自学者会忽略。我每天会把学到的东西写成一个三行的复盘：今天解决了什么问题、用到了什么方法、哪些还需要再深入。周末再把这些复盘整理成体系化的笔记。这样做的好处是，到第70天回看时，每一天的进度都有迹可循，不会产生“学了又好像没学”的虚无感。

如果你决定参考这个节奏，给你一个建议：不要一上来就搭一个大框架，比如“我要从模型原理学到部署”。先跑通最小的闭环，再逐步加深。没有产出支撑，大部分人在第三周就会放弃。

4.3 边界感：千万别把学到的半成品丢给团队

Leader在职学习，有一个很容易踩的坑：学到一个技术觉得不错，脑海里立刻浮现“这个可以帮助团队提效”，然后兴冲冲地抛给组员让他们去尝试。这里要非常克制。组员手里有自己的迭代任务，不是你的实验志愿者。半成品工具一旦占了别人的时间，不仅没帮到团队，还会消耗信任。

我的原则是：所有工具先自己做，做到稳定之后才在团队内部小范围分享，并且明确说明“还在实验阶段，有问题随时反馈”。像会议纪要转任务卡这个工具，我自己连用了两周，确认输出稳定后，才在周会上跟组员提了一句。目前只有两个人愿意试，这个我完全接受。工具好不好用，要用结果说话，不用Leader的身份强推。

5. 踩坑实录：70天里最值得写的7个问题

先放一个速查表，再逐个展开。

5.1 上下文塞爆：模型不报错，输出先变形

第一次做代码评审助手时，我把一个完整的组件文件全量发给模型，结果一长段代码就把上下文窗口占了大半，后续输出的内容开始胡言乱语，甚至出现了重复的段落。当时我没意识到是上下文超限，因为API调用并没有报错，只是响应质量急剧下降。

排查方法是用开发工具包里的token计数函数，把输入文本和输出文本分别统计，比对上下文窗口的最大值。之后我按文件切块、每块控制在300行以内的做法解决了这个问题。经验是：上下文窗口不是给得越多越好，当内容超过模型的有效处理范围时，输出质量会断崖式下跌，这时候要学会做减法。

5.2 Agent自转不停：本地API费用像漏水

在做一个任务拆解Agent的测试时，我给了一个“总结这份文档并提出优化建议”的任务，结果它一轮一轮地调用工具，把文档读了一遍又一遍，每次都输出一点无关痛痒的分析，持续了十几轮才结束。这一轮测试消耗的API费用抵得上几十次正常调用。

排查后发现，问题在于我的循环结构缺少终止条件。模型有很强的“继续分析”倾向，如果任务拆解没有明确的完成判断，它就会一直转下去。修复方式有两个：一是在提示词里明确“当所有子任务完成后输出最终结论”；二是在代码层面设置最大迭代次数，我设置的是5轮，超过就抛出异常或强制收敛。对于任何自动化运行的Agent，这个兜底是必须的。

5.3 JSON输出不稳定：Markdown包裹让解析崩掉

这是我在做会议纪要转任务卡时遇到的高频问题。模型返回的内容看起来是JSON，但外层被包了一个```json定义的代码块，导致JSON.parse直接失败。一开始我试图在提示词里反复强调“只输出JSON”，但偶尔还是会翻车。

最终方案是在代码层做清理：拿到返回文本后，先匹配第一个{和最后一个}之间的内容，再用JSON解析器解析；如果依然失败，就把文本交给模型让它“修正为合法JSON”再解析。这两种策略组合起来，成功率达到95%以上。自动化的核心原则是：不要依赖模型的自觉，要在代码里做兜底。

5.4 并发一高就被限流：重试退避救不回来

有一版知识库问答Agent在测试时批量处理了上百个问题，结果跑到第20个左右就开始大量超时。排查发现是并发请求数超出了平台的频率限制，导致接口返回限流错误。

修复分三层：第一层是并发控制，用线程池或异步信号量，把同时进行的请求数限制在5个以内；第二层是指数退避，遇到限流错误后等待1秒、2秒、4秒再重试，最多重试3次；第三层是本地任务队列，把待处理的任务排成FIFO，逐个消费。经过这三层处理后，批量任务基本不再出问题。这个教训是：即使单个请求很快，并发场景下也需要先把流程控制好。

5.5 提示词一改全乱：没有回归集就是裸奔

有一次我优化了代码评审助手的提示词，希望它更聚焦于性能问题。结果跑了一批样例之后发现，它开始对每段代码都给出“需要重构”的建议，原本不该提的错误也提了。那之后我定了一条规矩：任何提示词的改动，必须在一组固定的测试样例上跑一遍对比，这组样例包含正常代码、有明显bug的代码、边界场景等大概十来个用例。

这组样例不需要太多，但必须能覆盖核心场景。我甚至把一些历史问题当作回归样例，防止同一个问题反复出现。提示词工程看起来是“写文字”，实际上是需要工程化管理的活。

5.6 幻觉严重：让模型“看不见”它不该看的东西

知识库问答Agent早期的回答经常出现“看起来很有道理但完全不是我笔记里的内容”的答案。虽然我给了检索片段，但模型还是会基于它自身知识做自由发挥。

我做了两件事。第一，在提示词里明确写：如果给定的材料中找不到答案，请直接回答“未找到相关信息”，不要推测。第二，在系统指令里限制它的回答只能使用给定的上下文，不能使用外部知识。这两个修改之后，幻觉率明显下降。这个教训可以通用：想让模型不编造，先让它“看不到”它不该基于的内容。

5.7 环境隔离不清：依赖互相污染耽误两天

我本地同时有Node和Python项目，有一段时间在Python环境里直接pip install装了一堆包，导致某个之前能跑的项目突然启动报错。排查了半天发现是版本冲突——我装的某个库依赖了一个高版本的传递依赖，把原本项目依赖的版本覆盖了。

从此我所有Python项目都使用虚拟环境，不同项目用不同的环境目录，并且把每个项目的依赖清单单独维护。密钥和环境变量也单独用配置文件管理，不写进代码。前端项目也有类似情况，但Node的package-lock.json锁版本相对好一些。经验就一句话：新学一个技术栈，工程规范要一开始就建立。

6. 第71天以后：接下来怎么用这条线

走到第70天，一个很重要的认知变化是：Agent的能力边界其实很清楚。它能稳定胜任的是信息提取、文本生成、代码审查、知识检索这类高重复度任务；它不能替代的是需要严格判断和多方权衡的管理决策。前端Leader学Agent，最大的收获不是多会一个工具，而是对“哪些场景可以交给自动化”有了准确的判断力。

接下来我的方向很明确，把已经跑通的四个小工具整理成一套团队内部可用的工具集，把提示词模板、代码脚本、接入文档规范化。同时我会继续关注两个方向：一是私有化部署的可行性调研，看能不能把数据敏感的场景完全跑在内部环境；二是Agent的可观测性，目前调试还比较原始，想看有没有更好的链路追踪方案。

最后说点个人体会。七十天的学习，我最大的感受是：前端背景学Agent，优势不在代码量，而在工程思维。我们习惯把一个复杂系统拆成组件、模块、状态、事件，这种思维在Agent应用的编排上天然适用。不要被“转行”两个字吓住，把它当作你现有技能的一次延展，反而更容易走远。如果你也决定开始，我的建议是今天就去跑通一个最小的API调用，哪怕只是让模型回答一句“hello world”。有了第一个跑通的程序，后面的路自然就展开了。