企业官网建设流程全解析

1. 从“云端对话盒子”到“本地数字员工”：OpenClaw想解决的问题

159K Star的开源AI助手，放在整个开源托管平台上都是相当罕见的量级。我最初看到这个数字时，第一反应是：又一个把大模型API包一层壳的聊天项目。直到我把OpenClaw拉下来，从架构设计到技能插件全部过了一遍，才意识到这个判断错得离谱。它做的事情，一句话概括：把AI从一个只能对话的云端盒子，变成一台跑在自己机器上的本地数字员工——能访问私有数据、能执行授权任务、能把记忆留在你的设备里。这篇文章不打算复述README，而是从架构、部署、技能开发、实测和踩坑五个侧面，聊聊它凭什么重新定义“个人AI”的边界。适合想自己动手搭私人AI助手的开发者，也适合被云端AI的隐私和记忆问题困扰的深度用户。

1.1 云端AI的三堵墙：记忆、数据与行动

先说你正在用的那些云端AI助手。体验乍一看很流畅，但仔细拆开，会撞上三堵墙。

第一堵是记忆墙。每次打开对话框，它很可能并不记得你上周让它整理过什么。表面上有“历史会话”，但那只是把聊天记录堆在服务端，真正做判断时，上下文窗口里的东西依然有限。你昨天说过的偏好，今天可能要重新描述一遍。更麻烦的是，这种记忆不在你手里，导出、清理、迁移都受对方平台规则限制。

第二堵是数据墙。个人AI真正值钱的地方，是能结合“你的”文件、邮件、日程、笔记来做判断。但这些数据一旦要传到云端，就有成本和风险：有些是隐私敏感，有些是体量太大，还有些场景压根不允许数据离开本机。我自己手头一个模拟项目里的合同级文档，就从来没有上传过任何在线对话工具——不是不信任，是规则不允许。

第三堵是行动墙。聊天框能给你建议，但没法替你执行。它不会帮你把散落在桌面上的文件按规则归档，不会在你出差时自动汇总报销凭证，更不会在每天早晨跑一遍例行检查再给你一份结论。普通AI是“脑子”，但缺手缺脚；而个人AI的“边界”，恰恰卡在行动力这里。

1.2 159K Star背后：社区到底在为什么买单

一个开源项目能积累到159K Star，不可能是刷出来的。我习惯点开源托管平台上项目的提交记录和讨论区，看它是不是有持续迭代的迹象。OpenClaw的版本节奏很稳，几乎每个版本都带Breaking Change说明和迁移脚本，讨论区里大部分人在聊具体用法而非单纯吹捧。

社区里到底是谁在用它？我观察下来大致三类人。第一类是隐私敏感用户，他们不想把所有对话记录交给云端，但要享受AI带来的效率，于是本地运行是唯一解。第二类是自动化爱好者，他们手里已经攒了一堆脚本和定时任务，想要一个能自然语言指挥这些脚本的统一调度口。第三类则是做知识管理的知识工作者，每天要处理大量文档、会议记录和网页资料，需要AI在本地完成切分、向量化、检索和摘要。

这三类人有一个共同点：他们不是想要一个更聪明的“聊天对象”，而是想要一个更听话的“办事员”。Star数在我眼里不是荣誉，而是这种需求真实存在的佐证。

1.3 OpenClaw的定位：AI运行时，而不是模型壳

市面上一堆“开源AI助手”，本质都是套壳：前端一个对话页面，后端调云端模型API，再追加一点Prompt模板。这类项目过两周就凉半截，因为没解决什么底层问题。OpenClaw的定位完全不同——它更像一个“AI操作系统运行时”，或者叫“数字员工的执行环境”。

模型能力只是它的一部分，而且是可以随时替换的零件。真正核心的是那套围绕个人数据和个人权限运转的框架：它知道你有哪些本地资源，知道什么动作被允许，知道如何把一个模糊的意图拆成可执行的任务步骤，还知道把每一次执行的结果沉淀到记忆里。这个思路和我之前尝试过的一些Agent编排框架不一样，那些框架要自己搭积木，OpenClaw则是把整座房子和管道都铺好了，我只需要决定往哪个房间放什么东西。

2. 拆开看OpenClaw的内部：五层架构与数据流

定位说清楚了，接下来看它内部到底长什么样。我把OpenClaw的源码和配置翻完之后，脑子里留下的是一张五层架构图：感知层、认知层、记忆层、行动层、编排层。这里我用文字把它拆开讲，不用图表，但保证逻辑是连贯的。

2.1 感知层：不只有文字对话框

如果OpenClaw只有输入框，那它和聊天工具没区别。它真正的设计是“一切皆事件”：文本消息只是其中一种输入源，除此之外还有语音片段、图片文件、目录变更、定时触发器、收到HTTP请求的Webhook，甚至其他程序通过消息队列塞进来的事件。

每种输入源都由一个适配器负责，把原生格式统一转换成内部事件结构。比如我往某个被监视的目录里扔进一份PDF，文件系统适配器会捕获到新增事件，随后OpenClaw会判断该不该触发知识入库流程。事件结构统一有个很大的好处：写技能的人不用关心输入到底来自哪里，只要处理统一事件就行。这套做法和操作系统里“一切皆文件”的思路很像，用一层的抽象把多样的外部世界收敛成标准接口。

2.2 认知层：模型即插即用

认知层是负责“想”的部分，但它刻意做得很薄。OpenClaw没有绑定任何一家模型服务，也没有把某个具体大模型焊死在核心流程里。它把以下三件事全部塞给可插拔的推理内核：意图解析、任务规划、工具调用决策。

配置里一个provider块就能切换本地推理或远程API。远程API的好处是效果通常更好，本地模型的好处是隐私和成本可控。我个人的做法是“推理用本地，模板化任务用本地，太难的任务才临时切远程”。这里有个容易被忽略的点：OpenClaw对模型的输出做了结构化约束，它要求模型在工具调用场景下返回固定格式的JSON，而不是自由发挥的长文本。因为有了这层约束，模型才从“聊天生成器”变成“能被程序安全调用的执行器”。

2.3 记忆层：短期、长期、语义记忆

OpenClaw把记忆拆成三个层次。第一层是工作记忆，对应当前任务的上下文窗口，模型处理当前任务时临时使用；第二层是长期记忆，以条目形式保存在本地数据库，记录用户的偏好、历史结论和重要事件；第三层是语义记忆，把文本切片做向量化后存进本地向量库，检索时按语义相似度召回。

三层配合起来的效果很直观。今天上午我让它归纳过一份项目周报，下午问它“我们上午看的报告里有哪些风险点”，它能直接从语义记忆里找回相关片段，而不是重新要求我再传一遍文件。这种能力就是所谓“个人AI”区别于普通聊天机器人的关键。同时，记忆数据默认落在本机存储目录，并且支持加密键，至少不会一装完就裸奔在磁盘上。

2.4 行动层：技能与权限

如果说记忆层是“大脑”，行动层就是“手”。OpenClaw把一切可执行的能力都抽象成技能，包括本地脚本、系统命令、HTTP请求、浏览器自动化，甚至通过命令行调用某个老旧的内部工具。每个技能都必须声明自己的描述、触发方式、执行方式，以及权限范围。

权限设计是行动层里面最让我惊讶的部分。很多Agent项目在早期就是一股脑给Shell权限，出了事再说。OpenClaw则要求技能开发者显式声明允许访问的路径、允许调用的命令、是否需要在执行前请求人工确认。它为了让用户放心，还提供了沙箱执行模式。在实际使用中，权限系统不仅是安全兜底，也反过来逼着你思考：这个技能到底该不该被AI自动执行？想清楚再写技能，比出了事再去补救有效得多。

2.5 编排层：单Agent与多Agent协同

编排层管理的是“谁来干、按什么顺序干、干完怎么收尾”。简单任务可以走单Agent，完成意图解析、调用技能、返回结果就结束。复杂任务则可以拆分给多个Agent协作，比如一个Agent负责读资讯，一个Agent负责提炼摘要，另一个Agent负责汇总成日报，它们之间通过事件队列传递中间结果。

我实际跑过多Agent流程之后，最大的感受是任务边界必须划清楚。两个Agent假如都要操作同一批文件，非常容易产生竞态条件。我的做法是给不同Agent分配不同的工作目录，各管一段，最后再合并。编排层里还有一个关键配置：最大执行轮次。AI思考能力再强，也不能让它无限循环下去，超过轮次就强制停手，等人工接手。

3. 从零部署一台“私有AI员工”：环境准备与模型选型

光看架构容易让人觉得“又是PPT级项目”，真正动手部署一遍，才会有体感。我前后在两台机器上部署过OpenClaw，一台是普通办公桌面机，一台是专门跑本地模型的机器。这里把部署流程和选型经验完整写出来。

3.1 部署前先算三笔账

不是所有机器都适合跑OpenClaw，动手之前先想清楚三件事。

第一是算力账。如果你只用远程模型API，OpenClaw本身对硬件要求不高，一台8G内存的机器就能跑，因为重活都在服务端。如果你想全本地推理，那就要看模型参数量：7B级别的开源权重模型，配16G内存加一张中等显存的消费级显卡就能跑，但最好只做单任务；14B及以上，建议内存加到32G，显存往24G走，否则推理速度会让人失去耐心；更大参数模型，老实说已经超过“个人部署”的范畴了。

第二是数据账。OpenClaw的数据目录会逐渐膨胀：会话记录、向量库、技能日志、备份文件，几个月下来可能轻松突破几十GB。我建议一开始就把数据目录放在一个独立硬盘或加密容器里，不要跟系统盘混在一起，后续备份迁移会省很多事。

第三是场景账。你打算把它当后台服务常驻，还是只在需要时临时启动？常驻意味着要写服务管理、开机自启、日志轮转；临时用则可以忽略这些。我个人建议先用临时模式跑一周，确认稳定后再转常驻，避免一上来就给自己铺太多运维活。

3.2 安装、初始化与配置

安装流程不算复杂，但有几处细节容易卡住。大致步骤如下：

# 克隆仓库到本地 git clone <openclaw仓库地址> cd openclaw # 创建虚拟环境并安装依赖 python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt # 初始化默认配置 openclaw init --profile personal

依赖安装阶段最常出问题的是本地向量库相关的编译包，部分环境下需要系统级依赖，报错信息往往很长但结尾会提示缺哪个native库。遇到这种情况，优先看官方文档对应操作系统的安装小节，不要硬着头皮编。

初始化之后生成的主配置文件长这样，我把关键字段注释在下面：

[core] name = "my-openclaw" data_dir = "~/.openclaw/data" # 所有数据落在这里 log_level = "info" [model.provider] type = "local" # local 或 remote model_path = "/opt/models/my-llm" # 本地模型路径 embedding_path = "/opt/models/embedding" # 向量化模型路径 [service] host = "127.0.0.1" # 只监听本机，防止外部访问 port = 18080

注意host默认是127.0.0.1，这在绝大多数场景下是对的。如果想让局域网内其他设备访问，再改成0.0.0.0，但必须同时配好防火墙和访问令牌，否则你的AI助手等于裸奔在局域网上。

3.3 模型的两种接法：本地推理与远程模型API

模型接入方式直接决定部署形态。我把两种方式的感受对比一下：

我的建议是“生成模型与嵌入模型分离”。生成模型负责规划和对话，可以根据任务难度灵活切换；嵌入模型负责向量化记忆数据，一旦选定了就不要频繁更换，因为它直接影响记忆库的一致性，换模型后旧向量的检索质量可能大幅下降。这个问题在后文避坑部分还会展开。

如果你选择远程API模式，配置里只要把provider切到remote，填上端点地址和密钥就行。我最初图省事直接用了远程模式，跑了两天发现历史记录越来越少被召回，主要原因是我的某些文档确实不适合离开本机，才下决心把链路改成本地，虽然推理速度慢了一截，但数据安全感提升了一大截。

3.4 首次启动与连通性自检

启动命令很简单：

openclaw serve

但如果只是确认服务起来了，还不够。我习惯做三个自检动作。第一，看健康检查接口是否返回正常：

curl http://127.0.0.1:18080/health

第二，看日志里是否出现“provider ready”和“skill registry loaded”两类关键字。前者表示模型连接成功，后者表示技能库注册完成。第三，发一条最普通的测试消息，比如“请返回当前时间”，观察能否走完“感知→认知→行动”链路。如果这一步卡住，问题多半出在模型输出格式不符合结构化约束，可以临时把日志级别调到debug，看模型到底返回了什么。

首次启动最常见的三类失败是：依赖没装全、模型路径写错、端口被占用。依赖问题上文提过；模型路径写错时日志会直接报“model not found”；端口占用则换一个端口或停掉老进程就行。这些都不是大问题，真正的坑往往在后期的运行阶段，我放到实测和避坑部分细说。

4. Agent技能栈：让OpenClaw不只聊天还能动手干活

部署只是开始，OpenClaw真正的灵魂是技能栈。没有技能，它只是一个能对话的本地模型壳；有了技能，它才开始变成“员工”。

4.1 技能到底是长什么样的

在OpenClaw里，一个技能就是一组带清单描述的自动化能力。它不像传统程序那样由用户手动点击触发，而是可以被AI根据意图自动调用。每个技能对应一个描述文件加一个执行器。描述文件里写清楚这个技能是干什么的、何时触发、需要什么权限；执行器则是一段可运行的脚本，可以是Python、Shell，或者调用某个外部命令行工具。

我看到一个比较形象的比喻：技能相当于给AI提供了一份“工具说明书”。模型本身只知道“要解决问题”，但不知道“怎么调用本地工具”，是技能描述告诉它可以做什么、参数怎么写。所以写技能描述时最重要的是“写清楚意图边界”，让模型能判断什么情况下该调用它。描述写得太含糊，AI就会在边缘场景里乱用技能，甚至在不该用的时候用了。

4.2 从零写一个“整理下载目录”技能

我拿一个真实用过的技能举例，功能是“扫描下载目录，按文件类型移动到归档目录”。这个场景很简单，但能完整展示技能文件的要素：

id: sort-downloads version: 1 name: 整理下载目录 description: 扫描下载目录，按扩展名移动到对应归档子目录 trigger: type: scheduled cron: "0 22 * * *" run: script: scripts/sort_downloads.py params: source_dir: ~/Downloads target_dir: ~/Archive permissions: paths: allow: - ~/Downloads - ~/Archive deny: []

执行脚本本身不复杂，核心逻辑就是在source_dir下遍历文件，依据扩展名映射表决定目标子目录，再用移动操作完成归档。把脚本放到指定路径，在OpenClaw控制台执行技能注册命令，它会校验权限声明和脚本存在性。然后我手动触发一次，观察日志里技能是否被正确调用，确认无误后，再打开定时触发。

这个技能看起来平淡无奇，但它解决了我的真实痛点：下载目录常年堆满PDF、图片、安装包，手动整理又懒得做。交给AI定时触达之后，每天晚上自动归档，早上起来目录清清爽爽。关键是，这类技能不需要模型多聪明，只要意图识别准确，执行过程完全可以靠普通脚本完成。

4.3 给技能画一条安全红线

技能能干活是一件好事，但如果不加约束，AI也真的会干坏活。我在玩Agent类项目时见过太多“模型乱调用工具导致灾难”的案例，所以对OpenClaw的权限设计尤其敏感。

我的安全红线可以总结成三条。第一，非必要不给全局执行权限。凡是涉及文件迁移、删除、网络请求的技能，一律在permissions里写明白允许路径和禁止路径，宁可把路径写多一点，也不要留白。第二，危险动作加人工确认。删除操作、批量改名、发送对外消息，这类不可逆或影响范围大的操作，在技能描述里明确标注“需要人工确认”，OpenClaw会在执行前暂停并询问用户。第三，启用沙箱执行模式。社区里很多技能在跑Python脚本，沙箱模式可以把脚本限制在隔离空间内，禁止它访问无关路径。我后来会详细复盘一次误删目录事件，那次就是因为我嫌配置麻烦，把某个技能放出了沙箱，结果AI在理解意图时多走了一步，把不该动的一个兄弟目录一并处理了。安全机制平时看着碍事，真出事时它就是最后一道闸。

5. 我的实测记录：三类高频任务的稳定性对比

光说不练没有说服力。我把OpenClaw挂在一台32G内存、24G显存的机器上，模型用开源权重模型，连续跑了两周，重点观察三类高频任务。下面的数据是我个人环境的实测，不代表所有配置下的表现，但能反映这类本地AI助手的典型水平。

5.1 任务一：多轮信息整理与摘要

我准备了一个包含二十份文档的文件夹，要求OpenClaw完成“逐份阅读→提取要点→合并成一份综述，并且在后续对话里能基于综述回答细节问题”的流程。这是一个非常典型的个人知识管理需求。

实测结果是：二十份文档全部读取成功，生成的综述结构完整，没有出现缺漏章节。追问细节时，它能从向量库里找到对应片段并给出有依据的回答，而不是凭模型记忆编造。这个任务的成功率在我测试中接近九成，剩下的失败场景基本都出在文档格式太怪、扫描版PDF缺文字层这类边缘情况。感想是，只要输入数据是干净文本，OpenClaw的摘要和检索链路相当可靠。

5.2 任务二：定时拉取资讯并生成日报

第二个任务是每天早晚各一次，从几个RSS源拉取更新，经过模型过滤和分类后生成一份简报。我把它写成定时触发的技能，跑了整整一周。

这一周里，定时触发从来没漏过，但生成质量波动比较明显。早上首次运行时，模型刚启动，速度偏慢，偶尔会出现超时；中午再跑时速度恢复正常。另一个问题是，有些RSS源会有重复条目，模型对重复内容的去重能力不稳定，需要我在技能脚本里额外加一层基于链接的硬去重。最终日报的可用性大概在八成以上。如果你要跑类似任务，一定要给网络请求加重试和超时机制，否则一次网络抖动就会让整个任务断在那。

5.3 任务三：本地点对点文件归档

第三个任务听起来跟AI关系不大，但我故意让它做：根据页面上的完成状态，把对应文件从“待处理”目录移到“已完成”目录，并更新索引记录。这个任务的关键点在于“需要先理解页面状态，再决定是否移动文件”。

实测下来，AI的意图理解和工具调用的衔接很稳，没有出现“看错状态就乱移动文件”的情况。这个任务之所以值得记录，是因为它代表了一类“认知+操作”混合型任务——AI既要判断语义，又要执行实际动作。这种场景在纯聊天AI里根本不会发生，而在OpenClaw这类能行动的项目里，它变成了常规操作。只要我在权限配置里把两个目录写清楚，执行过程就是可靠的。

5.4 稳定边界总结

我把三类任务的实测结果整理成一张表：

这个数据给到我的启发是：OpenClaw在“认知+执行”链路稳定之后，真正的瓶颈往往是外围工程，比如数据质量、网络稳定性和权限边界，而不是模型够不够聪明。项目本身的容错机制已经很完善，但外围环境该加固的还得自己加固。

6. 避坑地图：记忆、权限与长上下文中的现场问题

两周实测下来，稳定完成任务是常态，但踩坑也踩出不少经验。以下问题是真实出现过的，不提前规避，迟早会遇到。

6.1 记忆越长，检索噪声越大

刚开始用OpenClaw时，我把所有文档一股脑交给它入库。一开始效果很好，但随着数据量涨到几千条片段，追问类任务的回答质量开始下滑，会偶尔引用不相干的片段。

排查后发现，问题出在向量检索的召回逻辑：向量库会根据相似度返回Top K片段，数据量大了之后，边界相似的片段会被错误召回。解决办法是两招。第一，在技能里给检索任务设置“时间衰减”，近期写入的记忆权重更高；第二，把大文档库拆成几个独立命名空间，比如“工作项目A”“生活笔记”“技术资料”，检索时限定命名空间，把噪声范围大幅缩小。经过这样调整，回答质量基本恢复了。

6.2 Agent“死循环”与任务轮次失控

有一类问题在Agent项目里非常经典：AI发现命令执行结果不符合预期后，不选择停手，而是反复尝试不同参数，直到把资源耗光。

我遇到一次，AI在处理一批图片时，尝试用一种底层工具来批量缩放，结果该工具在特定格式上报错，它就在“改参数→运行→再次报错”的循环里转了几十轮。OpenClaw的默认最大执行轮次是20，那次它转满之后才被强制中断。解决思路一是把默认轮次调低，重要任务配置为10；二是写技能描述时明确写上“如果出现某种错误，直接返回失败并通知用户”，给模型一个明确的失败出口。打那以后，我所有文件处理类技能都会附带“失败即报告”的约定。

6.3 权限爆炸事故：一次误删目录的复盘

这是最有代表性的一次事故。某开发者A同学在试用OpenClaw时，写了一个“清理临时文件”技能，只给了一张模糊的意图描述，权限范围则图省事设置了整个用户目录。AI在执行时把“临时文件”的范围理解成了“一段时间未访问的缓存类文件”，结果扫过了一个包含其他非临时内容的目录，大量文件被移入回收站。

复盘下来，根因有两个。第一，技能描述没有限定“临时文件”的精确标准，导致意图漂移；第二，权限范围太大，使得AI有足够能力破坏不该碰的目录。这事的教训不是“AI不可靠”，而是“权限和描述缺一不可”。之后A同学重新写了技能，明确只扫描指定子目录，权限范围缩到那一个目录，并且把“执行前需确认”打开，再也没出现同类事故。如果你也要写类似清理类技能，记住：权限范围宁小勿大，描述里把什么该删、什么不该删都写死。

6.4 换模型之后embedding错乱

模型选型那节提过，生成模型和嵌入模型最好分离。实际踩坑正是在这里。我有一次为了追求更好的摘要效果，把生成模型升级到了更大的版本，顺手把嵌入模型也换了。结果第二天发现，历史记忆的召回质量骤降，甚至出现了问了A问题、返回B文件片段的情况。

原因在于，向量库里的旧向量由旧嵌入模型生成，新嵌入模型生成的向量分布跟它不一致，相似度计算自然失真。办法是嵌入模型一旦选定就固定，只在凌晨维护窗口做全量重新向量化。升级生成模型完全没有问题，但嵌入模型变更必须当作一次数据迁移来对待，而不是简单换配置。

6.5 版本升级配置不兼容

OpenClaw迭代速度很快，我经历过一次升级后，部分技能无法加载，日志提示配置字段名不匹配。这类问题的处理思路很简单：升级前先备份配置和数据目录，再查看官方文档里的迁移指南，那里会列出版本间字段变化。遇到不兼容的字段，逐个改完再启动。

这里有一个经验：不要把技能配置写得过于复杂，复杂的配置在升级时就是复杂的迁移负担。我后来尽量把可变参数收敛到环境变量，技能文件只保留最小静态配置，升级时改动量小很多。

7. 关于“个人AI边界”的冷思考

最后一节不谈操作，聊点对“个人AI边界”这件事本身的理解。OpenClaw能拿到159K Star不是偶然，它映射的是很多人对AI产品的真实期待：我需要一个能接触我数据的助手，但数据的主权必须留在我这边。

7.1 边界不是模型能力决定的，而是数据授权决定的

很多人谈论AI边界时，首先想到模型能力边界——它能答什么、不能答什么。但OpenClaw这类项目给我的感受是，模型能力只是下限，上限是由数据授权和权限边界拉高的。同一个模型，接入你的知识库之后，回答质量能瞬间提升一个档次；拿到执行权限之后，价值又从“建议”变成“交付”。

反过来，数据授权也要讲边界。AI能访问多少数据、能调动多少权限，决定了它对你生活的介入程度。OpenClaw把这些边界做成显式的配置项，而不是靠糊里糊涂的Prompt隐式控制，这一点比很多封闭产品都诚实。

7.2 本地部署不是免费的午餐

OpenClaw不是没有代价。硬件投入只是第一笔账，后面还有维护、升级、排查故障的时间成本。本地模型效果弱于云端顶级模型也是现实，尤其是在复杂推理和创意写作类任务上，差距依然明显。适合使用它的人群，至少要有能力看懂日志，或者愿意花时间看文档。

我的建议是：不要因为有159K Star就期待它零成本完美。把它当成一个需要经营的工具，而不是一个装完就一劳永逸的服务。愿意投入，它回馈你的价值远超一个普通聊天窗口；不想投入，那它对你来说可能还不如网页版方便。

7.3 我的使用原则：能干活，但知道停手

最后说点个人体会。开源AI助手的边界，从来都不是模型能力决定的，而是你愿意交给它多少数据、允许它动用多少权限。OpenClaw真正打动我的地方，是它把边界的选择权还给了用户：你可以只让它做一个安静的摘要工具，也可以把它训练成一条龙处理日常事务的本地员工。

我现在的原则是：能干活，但知道停手。每次新技能上线，先给最小权限，先跑一周再说。这条原则，比任何架构设计都更重要。AI助手越顺手，越要保持对这种“顺手”的警惕。是你定义了它的边界，而不是让它替你做所有选择。