企业官网建设流程全解析

做 AI 助手这件事，我入坑的时间不算早，但踩的坑足够多。Grok Bot 从一行代码都没有，到每天有稳定用户来用，中间大概经历了七轮比较大的重构。而我在整个过程里用得最顺手的开发工具是 Cursor，很多次产品思路的成形，其实是在编辑器的补全提示里被"点醒"的。

所以这篇东西不打算写成产品宣传，也不是工具说明书，而是把 AI 助手从想法到落地这条路上，我觉得值得说清楚的东西摊开来聊。包括 Grok Bot 的定位是怎么一次次收敛的、Cursor 怎么配置才能顺手、提示词体系怎么分层、代理循环怎么防止失控，以及那些官方文档里压根不会写的报错处理。不管你是刚接触 AI 助手开发，还是已经在用 Cursor 写代码，应该都能从里面挑到能直接抄的东西。

1. 项目缘起：一个做增长的人为什么会扎进 AI 助手

1.1 从"看别人做产品"到"自己下场做产品"

在开发者工具行业待久了，会养成一个很不好的习惯：看任何产品都先看它的增长曲线，而不是先看它好不好用。我也一样，很长一段时间里我关注的是激活率、留存漏斗、付费转化这些指标，产品本身的内核反而被我当成了背景板。做增长的人有个通病，就是容易把"让更多人用"当成目标，而忽略了"用了之后到底得到什么"这个更根本的问题。

真正让我改变想法的是 AI 助手这一类产品的出现。它和传统的效率工具不一样，传统工具的价值是确定的——你打开剪贴板管理软件，它就是把剪贴板管好；但 AI 助手的价值是弹性的，同一个入口，有人拿它写周报，有人拿它查代码，有人拿它整理会议记录。这意味着它的增长逻辑根本不能套用旧工具那一套：你没法靠一个明确的功能点去打广告，因为用户自己都说不清要用它做什么。

这个认知让我产生了一个很强烈的冲动：与其在外面分析别人的数据，不如自己做一遍，亲手把"从零到有用户"这件事走通。Grok Bot 就是在这个节点上开始动手的。名字里带 Bot，但我从一开始就没打算把它做成一个只会聊天的玩具，而是想做那种"能接进工作流"的助手——能读文件、能调工具、能记住上下文，而不是每次对话都从零开始。

1.2 产品定位的三次关键收敛

做 AI 助手最容易犯的错，就是贪。第一版的时候我想做的功能列表能拉出一整屏：代码解释、文档问答、日程管理、邮件草稿、翻译、数据分析……结果做出来一个四不像，每个功能都只是"能跑"，但没一个能让人愿意天天用。这个阶段我大概浪费了两个月。

第二次收敛是在用户反馈里找到的。我拉了一批早期用户的对话记录，发现一个特别有意思的现象：使用频率最高的场景，并不是我预设的那些"高级功能"，而是最朴素的三个动作——问一个问题、让它帮我改写一段文字、让它帮我看看这段代码哪儿错了。换句话说，用户要的不是"功能多"，而是"在具体的一件小事上比我自己做得好"。

第三次收敛是砍功能。我把那些使用率低于 3% 的模块全删了，只留下"问答、改写、代码解释"三条主线，然后把全部精力放在响应速度和回答质量上。这一步做得很痛苦，因为删掉的都是自己熬夜写的代码，但事后看这是 Grok Bot 能跑起来的转折点。

1.3 技术选型背后的取舍逻辑

做 AI 助手绕不开几个基础决策：模型用云端还是本地、界面是网页还是客户端、记忆放在本地还是服务端。这三个问题没有标准答案，但每个选择都会在后面反复找你要账。

我最终的选择是：主对话走云端模型，敏感和离线场景接本地模型；界面先做 Web，后期再补桌面端；记忆以本地为主、云端兜底。这么定的理由很实在——云端模型的能力上限更高，适合承担主力对话；本地模型在断网或者处理私密内容时是刚需，哪怕效果差一截也得有；记忆放本地能降低合规和成本压力，同时让用户感觉"这是我的助手"而不是"某个平台上的账号"。

这里要提醒一句，本地模型的硬件门槛别被宣传视频骗了。一个能流畅跑起来的量化模型，对内存和显存的要求比想象中高，如果你只是想在笔记本上试水，先挑小参数量的版本，跑通了再往上加，不然后面调性能会调到你怀疑人生。

2. 开发环境搭建：Cursor 的中文设置与顺手配置

2.1 安装、注册与界面汉化的一次性搞定

Cursor 是当前做 AI 助手项目时用得比较多的编辑器，它本质上是基于 VS Code 深度改造的，所以很多操作习惯可以无缝迁移。安装过程没什么坑，官网下载对应系统的安装包，一路下一步就行。值得注意的是首次启动会让你登录账号，这一步建议用一个稳定使用的邮箱，因为后面涉及订阅和额度，换账号会麻烦。

界面汉化是新手问得最多的问题。很多人搜"cursor 设置中文""cursor 怎么设置中文"，其实方法就一条路径，我给你按顺序列出来：

1. 打开 Cursor，按下Ctrl + Shift + P（Mac 上是Cmd + Shift + P）调出命令面板。
2. 输入Configure Display Language，回车。
3. 在弹出的列表里如果没有zh-cn，选择Install Additional Languages，会跳转到扩展市场。
4. 在扩展市场搜索Chinese (Simplified)，找到官方语言包点击安装。
5. 安装完成后回到命令面板，再次执行Configure Display Language，选择zh-cn，重启编辑器。

重启之后整个界面就是中文了。如果你不小心切到了别的语言想切回来，重复上面第 2 步和第 5 步即可，语言数据是保存在本地的，不用重装。顺便说一句，汉化只影响界面文字，不影响代码补全和 AI 对话质量，所以放心装。

提示：网上流传的"复制一大段提示词进去保存就能永久汉化"的说法，本质上只是装了个语言包或者改了个用户设置文件，跟真正的提示词没有关系。语言设置是编辑器行为，跟模型能力是两码事，别被误导。

2.2 额度、订阅与团队协作的现实取舍

Cursor 的订阅体系是很多人纠结的地方。免费版本能用，但代理调用次数、Tab 补全的强度和高级模型的使用都有明显限制；订阅版本放开之后，最大的差别其实不是"能不能用"，而是"敢不敢高频用"。做 AI 助手项目有个特点，就是你需要反复让工具帮你读代码、改代码、生成脚手架，这种高频操作在免费额度下很容易被卡住，体验会断断续续。

我的建议是这样：如果你只是偶尔写写小脚本，免费额度基本够用，先用一段时间再决定要不要付费；如果你已经在做完整项目，每天要改几十个文件，那订阅带来的收益会很明显，因为省下的时间本身就是成本。至于团队协作，Cursor 支持多人共享规则文件和项目配置，这一点对做产品很关键——你们可以把项目规范写成配置文件提交到仓库，所有人都遵循同一套约定，AI 生成的代码风格才不会五花八门。

关于续费时间，这里有个小细节值得注意。订阅的计费周期通常是跟着你首次订阅的日期走的，不是你某次手动操作的时间点。所以如果你发现续费生效日期跟你预期的不一致，先去账单页面确认周期，不要着急重复下单，避免出现两笔重叠的费用。账单地址、发票这些信息也都在同一个页面里更新，改完记得核对一遍国家地区和邮编，信息错了有时候会导致支付失败。

2.3 界面布局与操作习惯的迁移

从别的编辑器转过来的人，第一反应往往是"侧边栏怎么在右边"或者"顶部栏太占地方"。Cursor 的布局其实是可以调的：在设置里搜索sidebar，找到侧边栏位置选项，就能把它挪到左边或右边。想把顶部栏收起来也可以，界面外观设置里有对应的开关。这类调整看着是小事，但每天用十几个小时的工具，布局不顺手会持续消耗你的耐心。

另外一个值得花时间的地方是快捷键迁移。如果你以前用别的编辑器已经形成了肌肉记忆，别硬扛，去键盘快捷方式设置里把常用操作的键位改成你熟悉的，或者导入现成的键位映射文件。我见过有人为了"适应新工具"硬改自己习惯，结果效率反而下降了半个月，这完全不值得。

2.4 把项目规则沉淀成文件

这是 Cursor 里我觉得最有价值的功能之一：项目规则文件。你可以在项目根目录放一个规则文件，把项目的技术栈、目录约定、命名规范、代码风格写进去，之后 AI 生成的代码就会自动参考这些内容。

举个例子，做 AI 助手的项目通常会约定：所有网络请求必须走统一的封装层、错误必须带上下文、异步操作必须有超时处理。把这些写进规则文件，比每次对话都手动提醒一遍要省心得多。规则文件的内容可以写得具体一点，比如：

# 项目规则 ## 技术栈 - 前端：TypeScript + 组件化框架 - 后端：Node.js，接口统一走 /api 前缀 - 所有网络请求必须经过 request 封装层，禁止直接调用底层请求方法 ## 代码风格 - 函数必须带类型标注 - 异步函数必须有超时和错误处理 - 禁止在组件里写业务逻辑，逻辑抽到独立模块 ## 目录约定 - src/components 放展示组件 - src/services 放业务逻辑 - src/utils 放通用工具

这份文件你看似是在约束 AI，实际上是在约束团队所有人。新人接手项目的时候，光读这份文件就能把约定搞清楚，比翻文档快得多。

3. AI 助手的核心能力：提示词、记忆与代理循环

3.1 系统提示词的分层设计

做助手最核心的东西不是界面，是提示词体系。很多人把提示词当成一段写死的文本，想到什么往里加什么，结果越写越长，模型反而抓不住重点。我更推荐分层写，把不同职责的内容拆开。

第一层是身份层，只写"你是谁、你服务谁"，越短越好，比如"你是一个帮助用户处理日常工作的助手，回答问题要直接"。第二层是能力层，说明它有哪些工具可以用、什么时候用，比如"当用户提到文件时，先调用读取工具确认内容"。第三层是约束层，写清楚不能做什么，比如"不确定的信息不要编造，直接说明不知道"。第四层是格式层，规定输出的结构，比如"代码必须用代码块标注语言"。

这么拆的好处是，你以后想改哪一层就改哪一层，不会牵一发动全身。而且每层的职责清晰，排查问题时也好定位——回答跑偏了，大概率是约束层没写清楚；工具调用不积极，多半是能力层的描述不够明确。

注意：网上那种"复制一大段提示词就能让助手变强"的模板，很多是拼凑出来的，里面夹杂着互相矛盾的指令。提示词不是越长越好，指令冲突比指令缺失更致命。

3.2 上下文与记忆的组织方式

助手和普通问答工具最大的区别，是它需要"记得住"。但记忆不能无脑堆，堆多了会拖慢响应、增加成本，还容易让模型被旧信息带偏。我的做法是把记忆分成三类，用不同策略处理。

第一类是会话内记忆，就是当前这轮对话里的内容，完整保留，这是基础。第二类是长期事实记忆，比如用户的偏好、经常提到的项目名称，这类信息我提取成简短条目存下来，每次对话带上几条，不占太多空间。第三类是可检索记忆，比如用户上传的文档和历史对话，这类内容量大，我不会全塞进上下文，而是做成可以按需检索的索引，需要的时候再取。

这里有个实操经验：记忆条目要定期清理和合并。早期的 Grok Bot 里，同一个偏好被记了好几遍，每次对话带上一堆重复内容，模型反而分不清哪个是最新的。后来我加了个简单的去重和更新时间标记，效果立刻好了很多。

3.3 工具调用与代理循环的防失控设计

代理能力是把助手从"聊天"变成"干活"的关键。简单说，就是让模型能决定去调用某个工具，拿到结果之后再继续思考下一步。听起来很美好，但真做起来最大的风险是"循环停不下来"——模型调一个工具，看到结果不满意，再调一次，来回几次就烧掉一堆调用额度。

我的处理办法设了三道闸。第一道是步数上限，硬性规定一个任务最多循环多少步，到点就强制给结果，哪怕结果不完美。第二道是重复检测，如果模型连续两步调用了同一个工具、参数也差不多，就中断并提示它换个思路。第三道是工具分级，把工具分成"只读"和"有副作用"两类，只读的可以随便调，有副作用的（比如写文件、发请求）必须谨慎，我在提示词里明确要求这类操作前要说明意图。

这三道闸加上之后，代理的稳定性提升非常明显。之前跑长任务经常卡死，现在最坏的情况也就是提前结束，不会无限循环。刚开始做代理功能的朋友，一定要先把上限设好，别等出了问题再去补，那时候成本已经花出去了。

3.4 本地模型与云端模型的混合调度

前面提到过混合调度，这里展开说说怎么落地。核心思路是做一个路由层，根据任务类型决定用哪个模型。判断依据可以很简单：涉及隐私内容、或者用户明确要求离线的，走本地；需要高质量推理、或者任务复杂的，走云端。

路由层不用写得太复杂，一个简单的规则表就够了。但要注意两个坑。第一个坑是本地模型的响应不稳定，同样的输入有时候快有时候慢，所以超时时间要留足，别用云端的那套标准去卡它。第二个坑是格式差异，本地模型对某些指令的理解可能和云端不一样，比如对输出格式的遵循程度。我的做法是给本地模型单独准备一套更简短、更直白的提示词，不跟云端共用。

本地模型的加载也有讲究。为了减少每次启动的等待，可以做成常驻服务，首次加载完之后保持运行，请求来了直接处理。这样用户第一次用会稍等，后面就快了。如果你的机器内存有限，那就得在"常驻"和"按需加载"之间做取舍，这个只能根据自己的硬件实测决定。

4. 从 Demo 到可用产品：实操流程拆解

4.1 最小可运行版本的拆分方式

做 AI 助手最容易拖延的地方，是想一步到位。我第一版就吃了这个亏，界面、记忆、代理、多模型全想一起做，结果每个都半成品。后来我改成拆解最小可运行版本，只做一条最核心的链路：用户输入 → 请求模型 → 流式返回 → 显示在界面。

这条链路跑通之后，你会发现后面加什么功能都只是在这条主线上挂模块。记忆是在请求前加一层处理，工具调用是在返回后加一层判断，多模型是在请求时加一个路由。主线稳了，扩展才不会互相打架。我强烈建议刚开始做的人先忍一忍，别急着做花哨的界面，把这条最朴素的链路打磨顺畅，收益远比想象中大。

4.2 流式输出的体验优化

AI 助手的体验，有很大一部分取决于"等不等得住"。模型生成一句话可能要好几秒，如果界面一直转圈，用户会以为卡死了。流式输出就是解决这个问题的——模型生成一点就显示一点。

实现流式输出要注意几个细节。第一，要处理中途出错的情况，网络断了或者模型异常，得把已经显示的内容保留下来，给个明确的提示，而不是整段消失。第二，滚动位置要跟着输出走，但不能强行把用户拽回底部，如果用户主动往上翻看历史，就别打断他。第三，代码块要处理闭合问题，流式输出的时候代码块可能只出来一半，渲染逻辑得能容忍这种中间状态。

这些细节单看都很小，但用户对助手的耐心就是这么一点点攒出来的。我做过一轮对比测试，同样的回答质量，加了流式输出和滚动优化的版本，用户连续对话的轮次明显更多。

4.3 评测与回归：怎么判断改好了还是改坏了

助手类产品有个麻烦，就是"效果好不好"很难量化。你改了一版提示词，感觉好像变好了，但可能是心理作用。所以我给自己定了一套简单的评测办法。

第一步，准备一批固定测试题，覆盖问答、改写、代码解释三类，每类十几道。第二步，每次改动后重跑一遍，记录回答是否合格。第三步，关注两个指标：合格率和平均响应时间。合格率掉了，说明改动有问题；时间涨太多，说明性能退化了。这套办法很土，但比"凭感觉"靠谱得多。

需要提醒的是，评测题别设得太刁钻。有些人为了证明模型强，专门挑边缘问题测，结果每次都在修边界情况，主干功能反而没打磨好。测试题应该贴近真实用户的高频场景，把常见问题做扎实，比解决罕见问题有意义。

5. 常见问题与排查实录

5.1 开发工具类问题速查表

用 Cursor 做开发，常见的问题其实就那么几类，我整理成表，方便直接对照。

关于"人机验证失败"这个问题，多啰嗦两句。它通常不是账号问题，而是本地环境的问题，缓存异常、浏览器版本过旧、页面状态过期都可能触发。我的处理顺序是：先刷新页面重试，不行就换一个浏览器，再不行清掉站点缓存后重新登录。一般情况下前两步就能解决，不用紧张。

5.2 助手运行类问题排查

产品跑起来之后，问题会从"工具问题"转向"效果问题"。这里列几个我遇到过的高频情况。

回答开始胡说八道，通常是上下文里混进了错误信息，或者长期记忆里存了过期的偏好，检查一下最近写入的记忆条目。工具调用不积极，多半是能力层提示写得太含蓄，模型没理解"什么时候该调工具"，可以把触发条件写得更明确。回答风格突然变了，检查是不是不小心切换了模型，或者提示词里的格式层被改动过。响应变慢，先看是不是上下文暴涨，长对话到后面很吃性能，该截断就截断。

排查这类问题的思路是"从外到内"：先看输入（用户问了什么、上下文带了什么），再看配置（模型、提示词、参数），最后才怀疑模型本身。很多新手一出问题就怪模型不行，实际上十有八九是自己前面的某一环出了偏差。

5.3 几个踩过才知道的坑

第一个坑是过度依赖自动生成。刚开始用 AI 写代码，觉得它什么都能写，结果积累了一堆自己看不懂的代码，后面出问题根本改不动。后来我定了个规矩：AI 生成的代码，我必须能讲清楚它在干什么才合并。这条规矩救了我好几次。

第二个坑是把提示词写得太满。前面提过指令冲突的问题，这里再强调一次，提示词里的规则如果互相矛盾，模型会随机挑一个执行，表现就是"时好时坏"。写完提示词之后，建议自己通读一遍，专门找有没有前后冲突的地方。

第三个坑是忽视成本监控。代理调用一多，费用涨得比你想象快。我从第二个月开始养成了看用量报表的习惯，发现有些调用完全可以用本地模型替代，调整之后成本降了一截。做这类产品，成本不是上线之后才考虑的事，从架构设计阶段就得把账算清楚。

第四个坑是过早追求"全能"。我见过不少项目，功能列表长得吓人，但没有一个能让人记住。助手这东西，用户愿意留下，往往是因为某一件小事做得特别顺手。与其做十个半吊子功能，不如把一个高频场景做到极致。

回过头看，Grok Bot 能走到有稳定用户这一步，靠的不是某个惊艳的技术点，而是一遍遍砍功能、一遍遍调提示词、一遍遍修那些看起来不起眼的小问题。做 AI 助手这件事没有捷径，但确实有方法——把主线做扎实，把边界设清楚，把成本盯紧一点，剩下的就是耐心迭代。我现在每次改动前还是会跑一遍那套土办法的评测题，这套习惯大概会一直跟着我，因为它是唯一能让我在"感觉变好了"和"真的变好了"之间做判断的东西。