企业官网建设流程全解析

Cursor 2.4 的更新日志，我本来是当"又一次换皮升级"点开的，结果发现 Subagents 和 Skills 这两个词背后的改动，比我想象的大得多。我花了一周时间，把一个真实项目的迭代任务从原来的单 Agent 流程迁到新架构上，期间写废了三个 Skill 初稿，重新编排了两次任务分工，最后才跑出一套稳定的组合流程。这篇文章就是那次迁移的完整记录——Subagents 为什么要用、任务怎么拆、Skills 怎么自己写、两者怎么组合，以及被问得最多的中文显示和注册问题。如果你正准备把项目切到 2.4，这篇应该能帮你少走几天的弯路。

1. 单 Agent 模式的瓶颈：为什么 Subagents 非出不可

1.1 上下文窗口爆炸：让一个 Agent 什么都记住不现实

以前的 Agent 模式，本质上是一个 Agent 从头干到尾。给它一个需求，它自己读代码、自己改文件、自己跑命令，听起来很美好，但实际操作里有特别明显的两个问题。

第一个问题是上下文爆炸。一个中型项目少说几十个文件，Agent 要完成一次跨模块改造，就不得不把相关的代码、报错信息、历史对话全部塞进上下文窗口。窗口是有限的，塞得越多，它越容易把前面的信息"忘掉"，于是经常出现改到第三个文件时，开始违反你在第一个文件里定下的约束。这是所有用过长会话 Agent 的人都切身感受过的痛。

第二个问题是单线程。一个 Agent 同一时间只能做一件事。前后端联调的时候，你特别希望有人能同时去改接口、改页面、写测试，但单个 Agent 只能按顺序来：先改后端，再改前端，再补测试。每一步都要等上一步完成，整个流程的时间就拖得很长。而且每次切换任务上下文，都可能引入新的混乱。

1.2 编排与执行分离：一主多从的协作模型

Cursor 2.4 的 Subagents，解决的就是这两个问题。它的设计思路用一个词概括：编排与执行分离。主 Agent 不再亲自下场写每一行代码，而是扮演"项目经理"的角色，负责理解需求、拆解任务、分配资源，然后把具体的执行交给一个或者多个 Subagent 并行处理。

我理解这套模型的时候，脑子里浮现的就是一个开发小组：主 Agent 是组长，Subagent 是组员。组长不写具体代码，但知道整体目标、需要哪些人、每个人干什么；组员不用管全局，只需要把自己分到的那块活干漂亮。这样的好处非常直接：

1. 上下文隔离。每个 Subagent 只拿到和它任务相关的文件与说明，不需要把整个项目的背景全部塞给它。它的窗口里没有噪音，准确率自然更高。
2. 并行加速。多个互不依赖的任务可以同时跑，整体耗时明显下降。
3. 可复用性。你可以在一次会话里多次启动同类型的 Subagent，因为它的"角色说明"是可以沉淀的，这正好和后面要讲的 Skills 接上了。

当然，这套模型也不是没有代价，编排任务书怎么写、任务粒度怎么切、结果怎么合并，这些都是新问题。我下一节就用一次真实的项目改造来演示，顺便把翻车点一次性讲清楚。

2. Subagents 真实项目编排：拆任务、分配角色、合并结果

2.1 案例背景：给内部管理系统加一个数据看板模块

我用来验证 Subagents 的项目是一个内部管理系统的前后端单仓：后端是 Node.js + TypeScript，前端是 React，数据库用 PostgreSQL。这次迭代的需求是新增一个数据看板模块，包含三个查询接口、两个页面组件、一组数据库迁移脚本，以及对应的单元测试。

这个需求放在以前，我会直接扔给单个 Agent 让它一条龙处理。运气好能跑通，但大概率会在中段出现"前面写好的接口约定被忘了，后面又按自己的想法重新定义"之类的错位。这次我换成了 Subagents 流程，整个过程走下来，效果和效率都有明显变化，但过程中也踩了几个坑。

2.2 主 Agent 的任务书怎么下指令最稳

先说结论：任务书的关键不是字数多，而是把"边界"划清楚。一个合格的 Subagent 任务书，至少要包含四样东西：角色、输入、输出、约束。

我给这次改造下的任务书大致长这样：

• 分析组：读一遍现有路由注册和数据库迁移的目录结构，梳理出看板模块应该插入的位置，输出一份清单。
• 后端组：按清单实现三个查询接口，输入是路由规范文档，输出是代码和接口定义，约束是必须复用现有的错误处理中间件。
• 前端组：基于后端组的接口定义实现两个页面组件，约束是使用项目现有的组件库，不做重复封装。
• 测试组：给接口补单元测试，约束是测试数据用 factory，不允许直接连真实数据库。

注意这里的关键点：每个 Subagent 的输入都被主 Agent 明确指定了，尤其"前端组"依赖"后端组"的接口定义，这个依赖关系必须在任务书里说清楚，让前端组等后端组产出后再启动，而不是一上来就猜接口。我实际操作的顺序是先起分析组，拿到清单后把清单分别喂给后端组和测试组，后端组完成后再把接口定义喂给前端组。这个顺序我试了好几轮，是目前最稳的。

2.3 并行协作里最容易翻车的三个点

第一是文件冲突。两个 Subagent 同时改同一个文件，结果必然有一个的改动被覆盖。我的解决办法是在任务书里明确"互斥文件"清单，比如数据库迁移文件只有一个，只允许后端组碰；路由注册文件同理。

第二是接口约定漂移。前端组在没有拿到最终接口定义时，很容易自己假设字段名。我后来养成的习惯是：宁可多等一轮，也要先把接口定义固定下来，再放开前端组和测试组并行。

第三是验收标准不写清楚。如果你只说"实现这个接口"，Subagent 会默认写完代码就算完成，不会跑测试，不会检查类型。所以我的任务书里都会加一条强制项："完成后必须执行 pnpm typecheck 和对应测试，把失败项列出并修复，直到全绿。"

还要补一句：并行不是越多越好。我试过同时开五个 Subagent，结果编辑器和终端的负载明显上升，有些任务之间还存在隐式依赖，反而比串行还慢。目前我控制在两到三个并行，效果最好。

3. Skills 技能系统：把团队规范做成 Agent 能加载的模块

3.1 SKILL.md 的结构与加载触发机制

Skills 是 Cursor 2.4 里和 Subagents 配套的另一块拼图。如果说 Subagent 解决的是"谁来做"，Skills 解决的是"按什么规矩做"。

从文件结构上看，一个 Skill 就是一个目录，最核心的文件是 SKILL.md。目录名就是技能名，SKILL.md 的头部有 frontmatter，里面写 name 和 description，description 尤其重要，因为它是 Agent 判断"什么时候该用这个技能"的依据。正文部分就是具体的操作规范，可以是步骤、代码约定、命令清单，甚至内嵌小脚本。

我理解这套设计的时候，直接把它类比成"给 Agent 预装的操作手册"。以前你让 Agent 按团队规范写代码，得在每轮对话里重复粘贴规范；现在规范被打包成 Skill，主 Agent 在拆任务时直接把对应 Skill 指派给 Subagent，Subagent 展开目录、读 SKILL.md、按里面的流程执行，这就把个人经验转化成了可共享、可版本管理的资产。

3.2 手写一个前端组件开发 Skill 的完整步骤

我自己写的第一个 Skill，是给前端 Subagent 用的，重点解决"组件风格不统一"的老毛病。步骤很简单，把目录放在项目的 .cursor/skills 下，结构长这样：

.cursor/skills/ frontend-component/ SKILL.md scripts/ check-structure.sh

SKILL.md 的内容大概是这样：

--- name: frontend-component description: 在创建新的 React 组件、重构现有组件或调整组件样式时使用。适用于页面组件和通用组件的开发任务。 --- # 前端组件开发规范 1. 创建组件前，先检查 src/components 下是否已有相似组件，有则复用或扩展。 2. 组件采用函数式写法，使用 hooks，禁止 class 组件。 3. 样式使用项目内的 css modules，禁止全局 class 污染。 4. 所有对外暴露的 props 需要写 TypeScript 类型，并给出默认值。 5. 组件完成后运行 npm run lint 并修复全部报错。

写完后，既可以在对话里直接提到技能名触发，也可以像前面说的，在给 Subagent 的任务书里让主 Agent 把技能指派给它。实测下来，加了 Skill 之后前端组产出的代码风格，比我自己口头约束稳定得多——因为它每次都会重新读一遍规范，而不是靠"记住"。

3.3 从社区安装 Skills 之前，我建议你先做这三件事

现在社区里已经有大量现成的 Skills 可以下载使用，覆盖前端、后端、测试、文档生成等领域。但我建议在安装之前先做三件事：

第一，审查 SKILL.md 的指令内容。Skill 本质上是"带权限的指令包"，它会让 Agent 按你的账号去执行操作，所以里面如果出现可疑指令，比如让你执行来历不明的脚本，一定要警惕。我见过标注为"自动审计"的 Skill，实际内容却涉及收集环境信息，这类工具只应该用于你自己授权过的项目，别在正式环境随便装。

第二，确认 Skill 的触发描述是精确的。很多社区 Skill 的 description 写得过于宽泛，比如"用于所有代码任务"，结果它会在各种任务里被自动加载，反而污染上下文。我会把 description 收窄到具体场景。

第三，把 Skill 纳入版本管理。我习惯把 .cursor/skills 提交进仓库和团队共享，这样规范变更有迹可循，比在群里发一份新的"开发规范.docx"靠谱得多。

4. Subagents + Skills 组合工作流：我沉淀下来的模板

4.1 场景：一次涉及后端、前端、测试的全栈迭代

把前面两部分拼起来，就是我在 Cursor 2.4 里的完整工作流。拿一次典型的全栈迭代举例：给系统加一个"导出报表"功能，涉及后端生成文件的接口、前端下载按钮和进度提示，以及一条端到端测试。

我的启动方式，是在主对话里下发需求，并明确要求主 Agent 先拆任务。主 Agent 的产出是一张任务卡片，包含三个 Subagent 的配置：

表格里的 Skill 都是我事先在仓库里写好的。后端组的 api-design 技能里规定了接口路径命名、错误码规范、响应体结构；测试组的 test-case 技能里规定了测试文件的命名和断言风格。主 Agent 在指派任务时，会把技能一并带上，Subagent 启动后先读 SKILL.md 再动手。

4.2 组合使用中的约定与节奏控制

这套流程跑顺之后，我自己总结了几条约定：

一是"一次会话，一个主任务"。主 Agent 的上下文里尽量只放一个完整需求，需求之间的切换通过新会话完成，避免多个主任务的上下文互相干扰。

二是"先固定接口，再放开并行"。跨端任务里，接口定义是天然的依赖锚点，我会让主 Agent 先产出接口定义，确认无误后再放前端和测试并行。

三是"每个 Subagent 的任务书里都带验收命令"。强制要求 typecheck、lint、test 三项跑绿再回报。这样合并结果的时候，冲突率会低很多。

四是"产出即提交"。每个 Subagent 完成产出后，先让它把改动提交到本地分支，再让主 Agent 做合并审阅。这样即使合并时出了问题，也能通过分支历史回退。

这套组合流程用下来，最大的感受是：以前"让 AI 全自动改完一个项目"的那种不安全感，被拆成了"多个可审阅的小块"。每个 Subagent 的产出范围小、规范明确、有测试兜底，我只需要在合并处把把关，整体质量比单 Agent 流程稳得多。

5. 被问麻了的几个问题：中文设置、注册、免费额度、杂牌小问题

5.1 让 Cursor 稳定输出中文的方法

这个话题我必须多说两句，因为问的人实在太多。目前 Cursor 的界面本身没有完整的官方中文语言包，网上流传的"汉化"大多是第三方补丁，我不太建议随便装。想让 Cursor 说中文，最可靠的办法是控制它的回复语言：在 Rules 里加入一条"Always reply in Chinese"，或者在每次对话开头明确说"请用中文回复"。如果你希望所有项目都强制中文输出，就写在全局配置的 Rules 里，这样每个新会话都会自动生效，不用每轮重复交代。

5.2 手机号注册和免费额度的实际情况

关于注册：Cursor 支持国际手机号注册，国内手机号可以正常接收验证码，填写的时候记得选对国家区号。如果遇到输入时"自动打括号"之类的干扰，直接切到英文输入法输入，再切回中文，这通常是输入法导致的，不是注册接口的问题。

关于免费额度：免费账户每月有固定次数的 AI 请求额度，额度用完后会自动降级或提示等待，具体数值以客户端内的用量面板为准。如果你发现额度消耗得特别快，大概率是低效会话太多——在同一个超长对话里反复追问，上下文会越滚越大，每次请求消耗都更高。建议用完即开新会话，反而省额度。

5.3 响应慢、工具面板布局这类小毛病的处理思路

"响应慢"和"Taking longer than expected"几乎是高频问题。我排查的顺序是：先看是不是单个会话上下文太长，太长就先开新会话；再看是不是高峰期，换个时段或换一个模型再试；最后看是否有异常插件加载，禁用掉再对比。绝大多数情况下，前两步就能解决。

至于"搜索等工具都在顶部，怎么移回左边"这类界面布局问题，我一般是去 View 菜单或主题配置里找布局选项，如果找不到，直接重置布局看看。这些小问题不影响核心功能，折腾之前建议先看一眼更新日志，有时是版本临时调整，下一个版本就改回来了。

6. 用了一周之后的个人体会

最后说点主观的东西。这一周用下来，我对 Cursor 2.4 的 Subagents 和 Skills 的评价是：前者解决的是"AI 能不能同时干多件事"的问题，后者解决的是"AI 能不能按你的规矩干每一件事"的问题。单独用其中一个，效果提升有限，组合起来才是这次版本更新的完全体。

我个人的体会是，不要急着把旧流程一次性全换掉。最稳的上手路径是：先给项目写上两三个高频的 Skill，从组件规范、接口设计、测试要求这些你最在意的地方开始；然后找一个中等规模的需求，用主 Agent 拆一次任务，开两个 Subagent 并行跑一轮；确认顺畅之后，再逐步扩大范围。这个过程不用太久，但能帮你把踩坑成本控制住。

还有一个小技巧可以分享：我在写 SKILL.md 的时候，会刻意在 description 里加上"在 X 情况下使用"这类限定词，而不是只写"处理前端任务"。描述越精确，Agent 越不会在无关任务里误加载技能，上下文也会更干净。

下一步我计划做两件事：一是把仓库里的 Skill 整理成更适合团队共享的结构，让新成员接手项目时可以直接沿用；二是尝试把文档生成类任务也交给带独立 Skill 的 Subagent，让接口文档和代码保持同步。如果你也在用 Subagents 和 Skills，欢迎把你的协作约定告诉我，这种玩法值得互相借鉴。