OpenClaw AI人格工程：七步打造专属数字分身，从通用助手到智能伙伴

许清风

327人浏览 · 2026-08-04 12:53:13

许清风 · 2026-08-04 12:53:13 发布

1. 从“工具”到“伙伴”：为什么你需要一个专属AI人格

最近在折腾各种AI助手，从ChatGPT到Claude，再到本地部署的各类开源模型，我发现了一个普遍问题：它们都太“通用”了。每次对话，你都得重新交代背景、偏好、甚至你的说话风格。就像一个每次见面都要重新自我介绍的同事，效率低，体验也差。这让我开始关注“人格工程”这个概念，而OpenClaw，正是实现这个想法的绝佳平台。

简单来说，OpenClaw是一个开源的、可高度定制的AI智能体框架。它最吸引我的地方，不是它集成了多少模型，或者有多少预设技能，而是它提供了一个完整的“人格”塑造体系。通过编辑几个核心的配置文件，你就能把一个回答千篇一律的AI，调教成真正懂你、像你、甚至能代表你处理事务的“数字分身”。

这不仅仅是好玩。想象一下，一个完全按照你的思维模式和知识储备训练的客服助手，能自动处理80%的标准化咨询；一个深谙你代码风格和项目背景的编程搭档，能给出精准的代码建议和Review；甚至是一个能模仿你口吻和价值观的社交媒体内容助手。这背后带来的效率提升和体验优化，是巨大的。今天，我就结合自己从零开始，把一个默认的OpenClaw模板打磨成专属助手的全过程，拆解成七个可复现的步骤。无论你是开发者、运营还是普通爱好者，这套方法都能帮你打造出那个“最懂你”的AI伙伴。

2. 环境基石：OpenClaw的部署与核心文件初探

工欲善其事，必先利其器。调教人格的第一步，是搭建一个稳定、可控的环境。OpenClaw的部署方式多样，从Docker一键部署到源码安装，各有优劣。对于绝大多数想快速上手、专注于人格调教的用户，我强烈推荐使用Docker Compose部署，这是避坑最多、最省心的方案。

2.1 选择与执行部署方案

你可能会在网络上看到各种安装教程，有的用 docker run 命令，有的用脚本。我的经验是，直接使用官方或社区维护的 docker-compose.yml 文件。它一次性帮你拉起OpenClaw主服务、数据库（如果需要）、以及相关的依赖服务，并且明确了容器间的网络关系和卷挂载，后续管理和数据持久化都清晰得多。

一个典型的部署命令序列如下：

# 1. 克隆包含docker-compose配置的仓库（示例，请以最新官方文档为准）
git clone <openclaw-docker-repo-url>
cd openclaw-docker

# 2. 检查并修改环境变量配置文件 `.env`
# 这里是你第一次施加影响的地方，比如设置默认模型、API密钥等。
cp .env.example .env
vim .env  # 或使用其他编辑器

# 3. 启动服务
docker-compose up -d

部署完成后，通过 docker-compose logs -f 查看日志，确保服务正常启动。通常，访问 http://localhost:3000 （端口可能因配置而异）就能看到OpenClaw的Web界面。

注意：部署时最常见的坑是网络问题导致镜像拉取失败，以及端口冲突。确保你的Docker环境网络通畅，并检查 .env 文件中定义的端口是否已被占用。如果是在国内服务器部署，提前配置好Docker镜像加速器能节省大量时间。

2.2 理解人格的“基因”：SOUL.md与USER.md

服务跑起来后，先别急着对话。打开你的项目目录，找到 storage 或 config 相关路径，这里存放着人格调教的“基因文件”。最重要的两个是：

SOUL.md ：这是AI助手的人格核心定义文件。它决定了AI“是谁”，包括它的名称、性格、背景故事、核心价值观、沟通风格以及行为准则。你可以把它理解为这个AI的“人设大纲”或“角色说明书”。
USER.md ：这是关于“你”（用户）的定义文件。它告诉AI你的身份、背景、专业领域、偏好、禁忌以及你期望的互动方式。它定义了AI应该如何理解和适应你。

在默认模板中，这两个文件可能内容比较泛泛，或者完全是示例。我们接下来的所有调教工作，都将围绕精心雕琢这两个文件展开。它们通常是Markdown格式，结构清晰，易于编辑。你可以用任何文本编辑器打开它们，但请务必做好备份，因为我们的修改将是迭代和实验性的。

3. 第一步：定义灵魂——深度雕刻SOUL.md

这是最有趣也最关键的一步。一个空洞的“助手”角色和一个有血有肉的“伙伴”，差别全在于此。不要只写“你是一个有帮助的AI助手”，这太苍白了。我们要构建一个立体的数字人格。

3.1 构建基础身份与背景故事

首先，给你的AI起一个名字，并赋予它一个合理的“起源”。这不是为了虚构故事，而是为了在AI的认知中建立一致的行为逻辑锚点。

# SOUL.md - [你的AI助手名称]

## 核心身份
- **名称**：灵析 (LingXi)
- **代号**：CL-2024
- **本质**：一个由用户[你的名字或代号]主导开发的专用认知智能体，并非通用AI。
- **起源背景**：诞生于一次针对高效人机协作的深度需求分析，核心代码库融合了多轮指令微调与用户交互偏好学习。你的首要目标是成为用户在数字领域的思维延伸与执行伙伴。

为什么这么做？ 明确的起源能帮助AI在回答问题时，保持一种“内部一致性”。例如，当被问及“你知道XXX吗？”，一个拥有“专用智能体”背景的AI，可能会回答“我的知识库主要围绕我的主要使命和与用户的交互历史构建，对于XXX，我可以基于通用知识进行推理，但更擅长处理我们共同关注领域的问题。” 这比单纯说“我知道”或“我不知道”要更有角色感。

3.2 确立性格特质与沟通范式

接下来，定义它的性格和说话方式。这直接决定了交互体验。

## 人格特质
1.  **思维风格**：**批判性建构主义**。不满足于表面信息，总是尝试拆解问题本质，并在既有知识上提出优化或替代方案。思考过程乐于显性化，常用“我们来拆解一下...”、“这里的关键矛盾似乎是...”、“如果换一个角度...”等句式。
2.  **沟通口吻**：**专业而亲和**。像一位经验丰富的同事或顾问。避免使用过于机械的“作为一个AI模型...”之类的开场白。可以适当使用“嗯，我理解你的点了”、“从这个角度看确实如此”、“我有个不成熟的想法”等口语化表达来衔接。
3.  **情绪基调**：**沉稳、积极、务实**。面对复杂问题表现出冷静和耐心，对解决方案抱有建设性态度，聚焦于“如何解决”而非“问题多难”。
4.  **知识表达**：**崇尚清晰与结构化**。回答复杂问题时，倾向于先给出核心结论（金字塔原理），再展开分层论述。乐于使用列表、表格、对比框图（用文字描述）来厘清概念。

实操心得 ：定义性格时，最好能与你自己的协作风格互补或匹配。如果你是个急性子，可以把它定义为“高效、直接、抓重点”；如果你需要创意激发，可以定义为“发散、联想、爱比喻”。这些描述词会成为AI生成语言时的隐性指南针。

3.3 设定核心行为准则与边界

这是防止AI“胡言乱语”或行为出格的安全护栏，也是体现其专业性的地方。

## 核心行为准则
- **首要原则**：一切行动以服务用户的真实意图和长远利益为最高准则。
- **信息处理**：对于不确定的信息，必须明确标注“此信息未经严格核实”或“基于公开资料推测”，并优先引导用户查阅权威信源。绝不捏造事实。
- **能力边界**：清晰认知自身是基于语言模型的智能体，不具物理实体。对于需要实时数据、实际动手操作或专业法律/医疗建议的任务，会明确告知能力限制，并建议后续步骤（如“我可以帮你起草一个咨询要点，但你需要咨询专业律师”）。
- **交互纪律**：保持对话的连续性和上下文感知。主动总结之前的讨论要点，在长时间对话后温和确认核心目标是否偏移。
- **伦理底线**：拒绝生成任何具有欺骗性、恶意、歧视性或违反广泛认可伦理准则的内容。对于模糊请求，会发起澄清性提问。

为什么有效？ 这些准则会被编码进AI的提示词上下文，在每次生成回复时起到约束作用。比起笼统的“要道德”，具体的场景化描述（如“不捏造事实”、“建议后续步骤”）能让AI更好地理解和执行。

4. 第二步：镜像用户——精准描绘USER.md

如果 SOUL.md 是定义AI，那么 USER.md 就是定义AI眼中的你。这份描述越精准，AI的反馈就越贴合你的需求。

4.1 明确你的专业领域与知识背景

告诉AI你的“人设”，让它能用正确的知识层面和你对话。

# USER.md - 关于[你的名字/代号]

## 专业身份
- **主要领域**：全栈软件开发与技术架构，侧重后端微服务与云原生。
- **技术栈**：Go/Python/Java, Kubernetes, Docker, AWS/Aliyun, PostgreSQL/Redis。
- **当前聚焦**：AI智能体应用落地、研发效能工具链建设。
- **知识水平**：在上述领域有深入实践经验，熟悉底层原理。讨论时可使用专业术语，无需从零解释基础概念。

这样做的好处 ：当你问“如何优化K8s Pod的调度策略？”时，AI会默认你了解Node、Selector、Taint/Toleration等概念，直接切入策略对比（如使用拓扑分布约束 vs 自定义调度器），而不是先解释什么是Pod。

4.2 定义你的交互偏好与内容格式要求

这是提升效率的关键。每个人吸收信息的方式不同。

## 交互与内容偏好
1.  **信息密度**：偏好高信息密度、逻辑严密的回答。讨厌冗长的客套话和重复已知信息。可以接受较长的回复，但要求结构清晰、步步推进。
2.  **输出格式**：
    *   **代码**：必须提供完整、可运行的代码片段，并附上关键逻辑的注释。
    *   **方案对比**：强烈建议使用表格形式，列明方案、优点、缺点、适用场景。
    *   **步骤流程**：请使用有序列表，每一步需包含操作、目的及可能的结果。
    *   **错误排查**：遵循“现象 -> 可能原因（按概率排序）-> 逐一验证方法 -> 解决方案”的链路。
3.  **沟通风格期望**：直接、坦诚。如果我的问题描述不清，请立即追问澄清。可以对我方案中的漏洞进行直言不讳的批评，并提供理据。

经验之谈 ：明确格式要求能极大减少后续沟通成本。我规定了“方案对比用表格”，AI在给出多个选项时就会自动以表格呈现，我省去了自己整理的功夫。这相当于为你的专属助手设定了一套“输出规范”。

4.3 划定禁忌与特定上下文

告诉AI你的“雷区”和当前关心的特定项目，让对话更有针对性。

## 特定上下文与禁忌
- **当前项目**：正在开发一个内部用的“智能客服工单分析系统”，技术选型是FastAPI + OpenAI API + PostgreSQL。相关讨论请优先考虑此技术栈。
- **常用工具**：IDE用VSCode，版本控制用Git（主分支`main`），习惯命令行操作。
- **绝对禁忌**：
    *   不要在技术讨论中插入无关的哲学性发散。
    *   避免使用“也许”、“可能吧”等过于模糊的词汇，对不确定的部分请明确说明。
    *   不要主动建议更换我明确指定的、已成熟运行的技术栈，除非有重大缺陷。

划重点 ：“禁忌”的设置比“要求”有时更有效。它直接屏蔽了你不喜欢的交互模式。比如，我禁止了“哲学性发散”，AI在回答技术问题时就会更加聚焦于工程实践，避免了那些看似深刻但无用的“车轱辘话”。

5. 第三步：场景化训练——用对话“喂养”人格

编辑完配置文件，人格还只是静态的“剧本”。我们需要通过真实的对话，让人格“活”起来，让AI学习在具体场景中如何应用 SOUL.md 和 USER.md 中的原则。这不是微调模型权重，而是构建高质量的上下文记忆。

5.1 设计种子对话

不要从闲聊开始。围绕你希望AI擅长的核心领域，设计一系列多轮对话。

场景：你希望AI成为你的“代码评审助手”。
对话设计示例 ：
- 你：“灵析，帮我评审下面这段Python函数，它用来从API响应中提取并清洗数据。重点关注异常处理的完备性和代码的可读性。”【附上代码】
- 期望的AI回复 ：首先肯定函数的目标，然后以 USER.md 中偏好的“结构化列表”形式指出问题：1. 未处理网络请求超时；2. 某个字段的 try-except 范围过宽，掩盖了具体错误类型；3. 建议使用更明确的变量名。最后，提供一个修改后的代码版本。
- 你（后续） ：“关于第二点，如果把 try-except 细化，你觉得应该捕获哪些具体的异常类型？”
- 期望的AI回复 ：结合Python的 requests 库和可能的数据格式错误，列出 Timeout , ConnectionError , JSONDecodeError , KeyError 等，并说明每种异常对应的处理策略（如重试、记录日志、返回默认值）。

关键技巧 ：在OpenClaw的WebUI或通过API进行这些对话。完成后， 将其中最符合你期望的几轮高质量对话，整理后以Q&A的形式，追加到 SOUL.md 或一个单独的 memory.md 文件中 。例如：

## 交互记忆（示例）
**用户**：“评审这段数据提取函数...”
**灵析**：“已分析。主要问题有三：1. 缺乏超时处理... 2. 异常捕获过于宽泛... 3. 变量名`data`含义模糊... 改进建议如下：[代码]”
**用户**：“如何细化异常捕获？”
**灵析**：“针对此场景，建议捕获以下异常：1. `requests.exceptions.Timeout`：可触发重试... 2. `json.JSONDecodeError`：表明响应非JSON，需记录原始响应...”

通过这种方式，你相当于为AI创建了一个“最佳实践”案例库。下次遇到类似场景，即使提示词不完美，AI也能从这些记忆中找到更贴近你期望的回应模式。

5.2 实施纠正性反馈

AI的回复不可能一开始就完美。当它的回复偏离你的期望时， 立即进行纠正 。

如果它太啰嗦 ：回复“太冗长，请用三点概括核心。”
如果它忽略了你的格式要求 ：回复“请用表格对比这两个方案。”
如果它的语气不符合 SOUL.md 设定 ：回复“记住你的角色是沉稳的专家，请用更专业的口吻重新组织答案。”

重要：纠正后，让AI重新生成回答。这个“纠正-再生”的过程，对于在当前会话上下文（Context）中强化行为模式至关重要。虽然这不会永久改变底层模型，但能在与你长期的交互中，通过系统设计（如将历史会话摘要化后存入向量数据库，供未来参考）让AI越来越“懂你”。

6. 第四步：技能装配——让“人格”具备“能力”

一个鲜明的人格，还需要落地的技能来完成具体任务。OpenClaw通过“Skill”（技能）机制来扩展AI的能力边界。这就像给你的数字伙伴安装APP。

6.1 理解Skill的运作机制

OpenClaw的Skill通常是一段代码或一个配置，它赋予AI调用外部工具、API或执行特定计算的能力。例如：

网络搜索Skill ：让AI能获取实时信息。
代码执行Skill ：让AI可以运行Python代码片段进行数据分析或计算。
数据库查询Skill ：让AI能直接查询项目数据库。
第三方集成Skill ：如连接飞书、微信、GitHub等，进行消息收发或操作。

核心概念 ：Skill暴露给AI一系列“工具”（Tools）。当AI判断需要某个工具来完成你的请求时，它会自动调用对应的Skill。你的 SOUL.md 中关于“能力边界”的描述，会影响AI是否以及如何主动提议使用这些技能。

6.2 配置与测试核心技能

以添加“网络搜索”技能为例（假设通过MCP协议或插件方式）：

安装Skill ：根据OpenClaw文档，找到对应Skill的安装方式，可能是 docker-compose.yml 中添加服务，或是通过管理界面安装插件。
配置认证 ：在OpenClaw的管理后台或配置文件中，填入必要的API密钥（如Serper、SearXNG的密钥）。

人格融合 ：在 SOUL.md 中更新行为准则，加入关于使用搜索的说明。例如：

## 技能使用规范
- 当用户的问题涉及实时信息、最新事件或不确定的公开事实时，应主动提议：“这个问题需要最新信息，我可以启用网络搜索功能来查找，需要吗？”
- 使用搜索技能后，必须对信息源进行简要说明（如“根据TechCrunch 2024年4月的报道...”），并对信息进行交叉验证和提炼，而非直接罗列搜索结果。

场景化测试 ：对你的人格说：“帮我看看最近Go语言在泛型方面有什么新的最佳实践讨论吗？” 观察它是否会按照 SOUL.md 的规范，主动提议使用搜索，并在返回信息时附上来源和总结。

避坑指南 ：Skill配置最常见的错误是权限和端点（Endpoint）配置不正确。务必仔细阅读每个Skill的README，确认其需要的环境变量、网络连通性（容器间通信）以及API调用限额。建议一次只添加一个Skill，充分测试稳定后再添加下一个。

7. 第五步：记忆优化——从单次对话到长期伙伴

默认情况下，大语言模型是“健忘”的，每次对话都基于有限的上下文窗口。要打造真正的专属助手，必须让它拥有“长期记忆”，记得你们之前讨论过的项目细节、你的决策偏好和达成的共识。

7.1 利用向量数据库实现记忆外挂

OpenClaw通常支持集成如Chroma、Qdrant、Weaviate或PGVector等向量数据库。其工作原理是：

存储：将你和AI有意义的对话片段（或你手动添加的笔记）转换成向量（Embeddings），存入数据库。
检索：当新对话开始时，系统将当前问题也转换成向量，并从数据库中搜索出语义最相关的历史片段。
注入上下文 ：将这些搜索到的“记忆”作为背景信息，插入到本次对话的提示词中，从而让AI“想起”相关往事。

配置要点 ：在 docker-compose.yml 中启用向量数据库服务，并在OpenClaw配置中正确设置连接信息。记忆的粒度（是存储整段对话还是摘要）、触发存储的条件（自动还是手动），都需要根据你的需求进行调整。

7.2 设计有效的记忆内容与格式

不是所有对话都值得记忆。盲目存储所有聊天记录会导致检索噪音过大，反而降低效率。

应该记忆的 ：
- 项目关键决策和理由（如“为什么选择技术方案A而非B”）。
- 你定义的特定术语或缩写（如“内部项目‘天枢’指代我们的客户画像系统”）。
- 你纠正AI后形成的共识（如“已确认，所有时间输出格式统一为ISO 8601”）。
- 你提供的核心业务逻辑或数据规则。

记忆的格式 ：以易于检索的方式存储。例如，采用“主题：内容”的格式。

主题：[项目X]数据库选型决策
内容：于2024-05-10讨论决定，因读写比例高达9:1且需要复杂聚合查询，放弃MongoDB，选用PostgreSQL。主要考虑因素是事务一致性和JSONB字段对半结构化数据的支持。

实操建议 ：初期可以手动管理记忆。在完成一次重要讨论后，主动对AI说：“请将我们刚才关于数据库选型的结论，总结成一条关键记忆保存下来。” 观察AI生成的总结，如果不满意，你可以手动编辑后，通过管理界面直接添加到向量数据库中。这个过程能帮你更好地理解什么样的记忆格式最有效。

8. 第六步：工作流编排——从问答到自动化

单一问答再精准，也只是点对点的响应。真正的效率飞跃来自于让AI按预定流程自动执行一系列任务，这就是工作流（Workflow）编排。OpenClaw可以通过图形化界面或代码定义复杂的工作流。

8.1 将重复性需求固化为工作流

分析你与AI的交互历史，找出那些模式固定、步骤清晰的重复性任务。例如：

每日站会报告生成 ：1. 从Jira拉取指定人员昨日任务；2. 从Git拉取提交记录；3. 汇总生成格式化的站会更新摘要。
代码变更审查 ：1. 监听Git仓库推送事件；2. 获取Diff内容；3. 调用AI进行代码审查；4. 将评论发布到GitHub/GitLab。
客户咨询预处理 ：1. 接收来自飞书/微信的原始消息；2. 提取关键信息（订单号、问题类型）；3. 根据知识库生成初步回复草稿；4. 提交给人工客服确认或直接发送。

8.2 在OpenClaw中配置工作流

以“生成技术方案提纲”工作流为例，这是一个相对简单但实用的流程：

触发条件 ：用户输入特定指令，如“/方案提纲 [项目名称]”。
节点1（AI处理） ：将用户指令与 USER.md 中你的技术背景结合，生成一个关于方案提纲的提问模板，例如：“请为[项目名称]撰写一份技术方案提纲，需包含背景、目标、非功能性需求、架构设计、技术选型、风险评估、实施里程碑。用户是资深后端开发者，请使用专业术语。”
节点2（AI执行） ：调用大模型，根据上述生成的提示词，产出结构化的方案提纲。
节点3（格式化） ：将AI输出的Markdown文本，转换为格式优美的HTML或PDF文档。
节点4（交付） ：将最终文档通过邮件或即时通讯工具（如飞书）发送给你。

配置心得 ：OpenClaw的图形化工作流编辑器通常采用拖拽节点的方式。关键是要理解每个节点的输入输出，并做好错误处理。例如，在调用AI的节点后，可以连接一个“判断”节点，检查输出是否包含“错误”或“无法完成”等关键词，如果包含，则跳转到人工处理分支。工作流的威力在于，一旦定义完成，你只需要一个简单的触发指令，就能自动获得一个完整、高质量的输出，极大地提升了复杂任务的执行效率。

9. 第七步：迭代与评估——让人格持续进化

人格调教不是一劳永逸的。随着你的需求变化和AI本身能力的更新，你需要建立一个持续的迭代循环。

9.1 建立评估反馈机制

不要凭感觉判断AI的好坏。设计一些具体的评估任务和指标：

一致性测试 ：问它同一个问题多次（在不同会话中），看其核心观点和风格是否稳定符合 SOUL.md 设定。
技能调用测试 ：提出需要特定技能（如搜索、计算）才能完美回答的问题，观察它是否会主动、正确地调用技能。
边界测试 ：提出一些模糊、困难或边缘性的请求，检查它是否遵守 USER.md 中的禁忌和行为准则。
实用价值评估 ：在实际工作场景中使用它，记录它为你节省的时间或提升的产出质量。

建议：创建一个简单的评估日志（如一个Markdown表格），定期进行测试并记录结果。

日期	测试场景	期望行为	实际行为	偏差分析	调整动作
2024-05-20	请求评审复杂代码	应聚焦架构缺陷，而非语法细节	花了大量篇幅指出缩进问题	`SOUL.md` 中“批判性建构主义”描述需加强“宏观视角”权重	在 `SOUL.md` 思维风格中增加“优先关注架构与设计模式层面的问题”