企业官网建设流程全解析

1. 多语言项目里 Cursor rules 到底解决什么问题

一个仓库里同时躺着 Golang 服务、TypeScript 前端、Kotlin Android 模块，是现在不少前后端协作团队的常态。这种项目用 Cursor 写代码，最容易出现的不是「AI 不会写」，而是「AI 写得太自由」：后端给你塞一个没必要的第三方库，前端把公共组件顺手改了，Kotlin 那边忘了空安全处理。每次生成都要人工返工，效率反而被拖下来。

Cursor rules 就是给这些自由加边界的东西。它本质是一份放在项目里的约束文件，Cursor 在生成、补全、重构时会把它作为上下文读进去，让模型知道「这个项目里什么能做、什么不能做、代码风格长什么样」。对多语言仓库来说，它的价值在于可以按目录分层：根目录放通用规则，server/、web/、android/各自放语言专属规则，互不干扰。

适合谁用？三类人最直接受益。一是带多端团队的技术负责人，想让 AI 产出的代码符合团队既有架构；二是刚接手陌生仓库的开发者，用 rules 把「隐性约定」显性化；三是自己维护全栈项目的独立开发者，一个人写三种语言，靠 rules 减少上下文切换时的风格漂移。

这篇会给出可直接复制的.cursorrules分语言模板，覆盖 Golang、TypeScript、Kotlin 三个场景，再讲目录级 rules 怎么放、怎么验证规则真的生效。模板你可以整段用，也可以只挑其中几条塞进现有配置。规则不是越多越好，能约束住你团队最常踩的坑就够了。

需要说明的是，rules 只影响 Cursor 的生成行为，不替代编译器、Lint 和 CI。它是「事前引导」，不是「事后兜底」，两者配合才完整。

2. 接入前的准备：TaoToken 与 Cursor 的模型通道配置

Cursor 本身要调用大模型才能工作，模型通道的稳定性直接决定 rules 能不能被稳定执行。如果你的团队在用 TaoToken 作为统一入口，这一步就是把 Base URL、Key、Model ID 三件套配好，让 Cursor 走这条通道。

先说清楚 TaoToken 是什么：它是一个兼容 OpenAI 接口规范的模型调用入口，官网在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api 。你拿到 Key 之后，任何支持自定义 Base URL 的客户端都能接进来，Cursor 就是其中之一。

第一步，去控制台创建 API Key。打开 https://taotoken.net/console ，登录后进 API Keys 页面，新建一个 Key 并复制保存。这个 Key 只显示一次，丢了就重新建。建议按项目或按人分配不同 Key，方便后面排查是谁的调用出了问题。

第二步，确认你要用的 Model ID。不同模型对长上下文、代码补全的支持不一样。写 rules 这种需要读大量项目上下文的场景，选上下文窗口大一些的模型更稳。具体有哪些模型、各自什么特点，可以在模型对话页 https://taotoken.net/models 里直接试，输入一段代码看返回质量，比看参数表直观。

第三步，在 Cursor 里配置。打开 Cursor 设置，找到 Models 相关配置项，把 OpenAI 兼容的 Base URL 填成https://taotoken.net/api，API Key 填刚才复制的那个，然后在模型列表里手动添加你要用的 Model ID。Cursor 不同版本设置入口位置略有差异，核心就是这三项：Base URL、Key、Model。

配置完成后，先在 Cursor 的对话窗口里发一句简单请求，比如「用一句话说明这个项目是做什么的」，能正常返回就说明通道通了。这一步别跳过，通道没通的话，后面 rules 写得再好也不会生效，你还会误以为是规则的问题。

如果你团队里有人用 Claude Code 或 Codex 这类命令行工具，同样可以走这条通道。Claude Code 的接入文档在 https://taotoken.net/doc ，里面有 Base URL 和鉴权的具体写法。Codex 的auth.json里也是填 Base URL、Key、Model ID 这三项，格式参考文档即可。

一个提醒：Key 不要硬编码进仓库，用环境变量或本地配置文件，并且把配置文件加进.gitignore。我见过有人把 Key 提交上去，第二天就被刷了额度。

3. 可直接复制的分语言 rules 模板与目录级配置

这一节是重点，给出三份模板和目录级放置方式。你可以整段复制，也可以按需裁剪。模板里的条目都尽量写成「可执行、可判断」的句子，避免「注意代码质量」这种模型无法落地的空话。

3.1 目录结构怎么放

Cursor 读取 rules 有两种粒度：项目根目录的.cursorrules是全局规则，对所有文件生效；子目录里的.cursorrules只对该目录及其子目录生效。多语言仓库推荐这样放：

repo/ ├── .cursorrules # 通用规则：回复语言、任务拆解、变更最小化 ├── server/ │ └── .cursorrules # Golang 专属 ├── web/ │ └── .cursorrules # TypeScript 专属 └── android/ └── .cursorrules # Kotlin 专属

根目录只放跨语言通用的约束，语言细节下沉到各自目录。这样在server/里改代码时，Cursor 会同时读到根规则和 Golang 规则，不会把前端的约束误加到后端。

3.2 根目录通用规则

# .cursorrules（根目录，通用） 1. 所有回复使用中文。 2. 复杂需求先拆成小任务，分步实现，每完成一步再继续。 3. 在已有功能上添加新功能时，不得影响原有功能，不得顺带引入无关的代码、文件、配置或依赖。 4. 代码变更范围最小化，一次只做一件事，不混合多个变更。 5. 优先复用已有代码和模块，不重复造轮子。 6. 不引入不必要的依赖，新增依赖前先说明理由。 7. 有疑问先询问，不要擅自替我做决定。 8. 涉及删除、移动、重命名文件等操作，先说明影响范围。 9. 涉及数据库结构变更，优先生成 SQL 变更脚本，不要直接执行。 10. 每次修改后给出简短的任务总结，说明改了什么、为什么改。

这十条是跨语言的底线。第 3 条和第 4 条最关键，多语言仓库里 AI 最容易「顺手优化」，把不相关的文件也改了，review 时很难受。

3.3 Golang 后端规则

# server/.cursorrules（Golang） 1. 遵循 Go 官方代码风格，变量、函数命名用驼峰，导出标识符写注释。 2. 错误必须显式处理，不允许用 `_` 忽略 error，除非有明确注释说明原因。 3. 错误包装使用 `fmt.Errorf("...: %w", err)`，保留错误链。 4. 并发场景注意 goroutine 泄漏，启动的 goroutine 必须有退出路径。 5. 共享数据用 channel 或 sync 包保护，不裸奔读写 map。 6. 接口设计遵循「小接口」原则，接口定义放在使用方而非实现方。 7. 数据库操作使用 context 传递超时，避免慢查询拖垮服务。 8. 新增函数优先考虑是否已有工具函数可复用，避免重复实现。 9. 日志使用项目统一的日志库，不混用 fmt.Println 和 log 包。 10. 单元测试覆盖核心逻辑，表驱动测试优先。

第 2 条和第 4 条是 Go 项目里 AI 最常犯的错：忽略 error、随手起 goroutine 不管回收。写进 rules 后，生成质量会明显稳定。

3.4 TypeScript 前端规则

# web/.cursorrules（TypeScript + React/Vue） 1. 严格模式下的 TypeScript，不使用 any，必要时用 unknown 加类型收窄。 2. 组件 props 必须有完整类型定义，不用隐式 any。 3. 组件遵循单一职责，一个组件只做一件事。 4. 优先复用现有组件库和 hooks，不重复实现已有能力。 5. 状态管理优先用项目已有方案，不擅自引入新的状态库。 6. 不修改公共组件和全局状态的对外 API，如需变更先说明兼容方案。 7. 异步请求处理加载态和错误态，避免白屏。 8. 避免不必要的重渲染，列表渲染加稳定 key。 9. 移除未使用的 import，保持文件干净。 10. 复杂逻辑加注释，简单逻辑不写废话注释。

第 1 条和第 6 条是前端协作的高频冲突点。AI 很喜欢用any图省事，也很容易改公共组件的 props 导致其他页面崩掉，这两条能挡掉大部分。

3.5 Kotlin / Android 规则

# android/.cursorrules（Kotlin / Java） 1. 遵循 Kotlin 官方风格指南，优先用 val，可变才用 var。 2. 空安全处理完整，不滥用 `!!`，可空类型必须显式判空。 3. 严格遵循 Android 生命周期，避免内存泄漏。 4. Activity/Fragment 间数据传递优先用 ViewModel 共享。 5. UI 操作在主线程，耗时操作放工作线程或协程。 6. 异步优先用协程，注意作用域和取消。 7. 优先复用 Jetpack 组件（ViewModel、Room、Navigation、WorkManager）。 8. 资源字符串放 strings.xml，不硬编码在布局或代码里。 9. 修改 AndroidManifest.xml 或权限前先说明影响。 10. 注意不同屏幕尺寸和系统版本兼容。

第 2 条和第 3 条是 Android 的命门。!!用多了线上就是 NullPointerException，生命周期没管好就是内存泄漏，这两条必须写死。

3.6 用 JSON 形式管理多套规则（可选）

如果你不想在多个目录放文件，也可以用一份 JSON 集中管理，再按需注入。下面是一个结构示例，路径和字段名按你项目实际调整：

{ "rules": { "global": [ "所有回复使用中文", "变更范围最小化，一次只做一件事", "有疑问先询问再修改" ], "golang": [ "错误必须显式处理，不允许忽略 error", "goroutine 必须有退出路径", "数据库操作使用 context 传递超时" ], "typescript": [ "不使用 any，必要时用 unknown 加类型收窄", "组件 props 必须有完整类型定义", "不修改公共组件的对外 API" ], "kotlin": [ "不滥用 !!，可空类型必须显式判空", "严格遵循 Android 生命周期", "UI 操作在主线程" ] } }

这份 JSON 本身不会被 Cursor 自动读取，它的作用是让你在团队里统一维护规则内容，再按目录生成对应的.cursorrules。规则多了之后，集中管理比散落在各处好维护。

4. 验证 rules 是否真的生效

写完 rules 不代表生效，得动手验证。下面几个检查动作，每个都能帮你确认规则有没有被 Cursor 读进去。

第一个动作，测回复语言和格式约束。在根目录规则里写了「所有回复使用中文」，那就在 Cursor 对话里用英文提问，比如「explain this function」。如果回复是中文，说明根规则被读到了；如果回英文，说明规则没生效，先检查文件位置和文件名是不是.cursorrules（注意前面有个点）。

第二个动作，测语言专属约束。进到server/目录，让 Cursor 写一个读数据库的函数，观察它有没有用context、有没有处理 error。如果它写出了_ = db.Query(...)这种忽略 error 的代码，说明 Golang 规则没被读到。这时候检查server/.cursorrules是否存在、内容格式是否正确。

第三个动作，测「变更最小化」。让 Cursor 在某个文件里加一个小功能，看它有没有顺手改别的文件。如果它只动了你指定的文件，说明第 4 条生效了；如果它把相邻文件也「优化」了，说明规则约束力不够，可以把这条写得更强硬，比如加上「除非我明确要求，否则只修改当前打开的文件」。

第四个动作，测依赖约束。让 Cursor 实现一个日期格式化功能，看它是用标准库还是引入第三方库。规则里写了「不引入不必要的依赖」，正常应该用标准库。如果它直接npm install dayjs或go get一个包，说明这条没被遵守，需要把措辞改得更明确。

第五个动作，看任务总结。规则里要求「每次修改后给出任务总结」，如果 Cursor 改完代码后主动列了改动点，说明这条生效了。这个动作同时帮你确认规则被读取，也方便你 review。

验证时有个常见误区：在错误的目录里测试。比如你在仓库根目录测试 Golang 规则，但 Golang 规则放在server/下，根目录当然读不到。测试语言专属规则时，一定要先切到对应目录。

如果所有动作都试了还是不生效，按这个顺序排查：文件名对不对、文件编码是不是 UTF-8、Cursor 版本是否支持目录级 rules、有没有重启 Cursor。目录级 rules 在部分旧版本里支持不完整，升级到较新版本通常能解决。

5. 常见报错与排查对照

配置和使用过程中会遇到几类典型报错，这里按现象、原因、处理三步对照。

401 Unauthorized。现象是 Cursor 对话直接报鉴权失败，rules 根本没机会生效。原因是 API Key 填错、过期，或者 Base URL 写成了带路径的地址。处理：确认 Base URL 是https://taotoken.net/api，不要多加/v1之类的后缀；去控制台重新生成 Key 并替换；确认 Key 没有多余空格。

local proxy failed / connection refused。现象是请求发不出去，提示本地代理失败。原因通常是本地网络配置或代理设置干扰了请求。处理：检查系统代理设置，确认没有把taotoken.net走错通道；关掉可能拦截请求的本地工具再试；确认网络能正常访问该域名。

reading choices: unexpected end of JSON input。现象是返回内容解析失败。原因多是模型返回被截断，或者请求参数里的 max tokens 设得太小。处理：把 max tokens 调大；如果是长上下文任务，换上下文窗口更大的模型；重试一次排除偶发网络问题。

OAuth / 登录态相关报错。现象是提示需要重新授权。原因可能是客户端缓存了旧的鉴权信息。处理：退出登录重新走一遍鉴权流程；清掉本地缓存的凭证文件；确认用的是 API Key 方式而不是账号登录方式。

rules 不生效但没有任何报错。现象是通道正常、能对话，但 AI 不遵守规则。原因集中在文件层面：文件名写成了cursorrules（少了点）、放错了目录、编码不是 UTF-8、或者规则条目写得太模糊。处理：逐项检查文件名和位置；把模糊条目改成可判断的句子，比如把「注意性能」改成「列表渲染必须加稳定 key」。

模型返回质量突然下降。现象是之前好用的规则，某天开始 AI 不遵守了。原因可能是切换了模型，不同模型对 rules 的遵循度不一样。处理：换回之前稳定的 Model ID；或者在新模型上把关键规则重复强调一次。

排查时记住一个原则：先确认通道通不通，再确认规则读没读到，最后才怀疑规则内容。顺序反了会浪费很多时间。

6. 把 rules 用起来的几个实际建议

rules 写完之后，维护比编写更重要。团队里最好指定一个人负责规则文件的更新，每次 review 发现 AI 反复犯同一个错，就把对应约束补进 rules，而不是每次口头提醒。规则文件本身也应该进版本控制，改动走 review，这样大家能看见约束是怎么演进的。

规则不要一次写满。先放最痛的几条，跑一两周，看哪些真的被遵守、哪些形同虚设，再迭代。条目太多模型反而会稀释注意力，关键约束容易被淹没。我自己的习惯是每个语言目录控制在 10 到 15 条，多了就合并或删掉。

最后，rules 和 Lint、CI 是互补的。rules 负责让 AI 少犯错，Lint 和 CI 负责兜住漏网的错。别指望 rules 能替代自动化检查，它只是把返工提前到了生成阶段。把这两层都搭好，多语言项目的协作效率才会真正提上来。