企业官网建设流程全解析

• 文档
• 教程
• 人工智能
• 大模型

导读：本文围绕 OpenClaw Mastery for Everyone 课程 Day 2 的claw-instructions-create-user.md指南展开，完整讲解如何通过一次结构化访谈，为你的 OpenClaw 实例（Claw）生成~/.openclaw/workspace/USER.md用户画像文件。你将掌握 USER.md 的五大字段设计（Who / Contact / Focus / Style / Patterns）、约 250 词的目标篇幅、敏感信息与 MEMORY.md 的边界划分，以及创建后的确认与验证闭环；文章同时结合 Day 2 课程文档与同目录下的 SOUL.md / AGENTS.md / MEMORY.md 指令文件，说明 USER.md 在 OpenClaw 四身份文件体系中的定位与协同方式。

一、USER.md 是什么：四个身份文件中的"关于你"

在 OpenClaw 的体系里，一个只运行进程与一个"真正认识你"的助手之间，隔着四个每次对话都会重新加载的 Markdown 文件。Day 2 课程文档 learn.md 给出了它们的分工：

USER.md 本质上是一份"简报文档"（briefing document）：它告诉代理，它正在为哪一个人工作、这个人的当前焦点是什么、以及这个人希望以什么风格被服务。它与 SOUL.md 的区别在于视角——SOUL.md 定义代理的身份，USER.md 定义用户的画像；两者共同决定了对话的"校准基线"。

课程 README 强调，Day 2 的产物是"四个定义 Claw 性格、上下文、规则与记忆的身份文件"，而claw-instructions-create-user.md正是其中负责 USER.md 的那份可执行指南。

上图来自 Day 2 课程文档：SOUL.md / USER.md / AGENTS.md / MEMORY.md 四个引导文件（bootstrap files）在每轮消息时从磁盘重新加载，因此无论会话多长、上下文窗口如何压缩，它们始终以最新状态存在于对话中；而每日日志（memory/YYYY-MM-DD.md）只在按需检索时被拉取，重要上下文须"晋升"进 MEMORY.md 后才成为每轮可见的持久事实。

二、创建 USER.md 的完整流程：三个阶段

按照 claw-instructions-create-user.md 的规定，整个流程分为三个阶段：访谈收集 → 一次性写入 → 确认完成。指南要求"严格按说明执行"（Follow these instructions exactly），目标只有一个：按顺序向用户提出 USER.md 的设置问题，然后创建~/.openclaw/workspace/USER.md。

前置动作：先读 SOUL.md 保持命名一致

在提问之前，若~/.openclaw/workspace/SOUL.md存在，必须先读取它。这样做的目的是让 Claw 的名字和用户的名字在多个文件之间保持一致：

• 如果 SOUL.md 中已经包含用户的名字，直接复用，不要重新收集；
• 只对缺失的信息提问，或请求用户更正不一致之处，而不是把已经确认过的信息再问一遍。

这条规则与 claw-instructions-create-soul.md 中"Identity 段落写入[USER_NAME]"的设计遥相呼应——四个文件共享同一套名字，任何一处漂移都会削弱代理对"为谁服务"的感知。

访谈期间的铁律

在访谈过程中，指南明确了四条不可违背的操作纪律：

1. 一次只问一个问题，等待用户回答后再继续；
2. 在普通聊天中以纯文本提问（ask the questions in plain chat）；
3. 问题之间不要运行工具，也不要写入任何文件；
4. 不要把回答追加进memory/YYYY-MM-DD.md日志——把答案先保存在对话上下文中，待所有问题问完后一次性写入 USER.md。

这条"攒齐答案、最后落盘"的规则同样出现在 SOUL.md 与 MEMORY.md 的指令中（见 claw-instructions-create-memory.md 的"During this interview"段落），并且被 claw-instructions-create-agents.md 的 Memory Management 部分显式固化："对于引导式设置流程或多问题访谈，不要在问题之间写增量笔记；先完成访谈，再写入目标文件或在访谈结束后记录持久上下文。"

三、访谈问卷逐题解析：五个模块、九道问题

USER.md 的访谈共 9 道题，分布在五个模块中。下面逐题说明提问意图与回答的落点。

Who（谁）

1. 确认姓名与代词：优先从 SOUL.md 复用名字；如果已存在，只询问偏好的代词（preferred pronouns）与必要的姓名更正；如果缺失，则询问全名与代词。
2. 城市与时区：问"你在哪个城市、哪个时区？"——时区是 Claw 判断"当前时间对用户是否合适"的基础依据。

Contact（联系方式）

3. 主邮箱与响应时间规则：问主邮箱地址，并询问"你对响应时间有什么规则吗？"——例如是否希望 Claw 在深夜不发送邮件、是否对紧急事项有响应时限约定。

Focus（焦点）

4. 你的角色是什么？（role）
5. 你手头具体在忙什么？——列出本周正在积极推进的 2–3 件事。

第 5 题是 USER.md 中最关键的一题。课程文档对 FOCUS 段的解释非常直白："Finishing Q2 roadmap, closing a partnership deal, behind on three client check-ins"是有用的，"Head of Product" 只是给代理一个分类标签。本周真正压在桌上的具体事项，才是让 USER.md 产生价值的内容——泛化的职位头衔无法指导代理做出有针对性的帮助。

Style（风格）

6. 默认输出格式：短句、详细段落、要点列表，还是其他？——确立默认输出格式。
7. 格式偏好：是否有你在意的强偏好？例如"聊天里不要用要点列表""匹配我的消息风格""保持在一屏以内"。

课程文档强调：STYLE 段必须写成具体指令而非抽象描述。"Short responses by default"、"Never use bullets when a sentence will do"、"Push back when you disagree instead of just complying" 都是可执行的具体指令；而"professional but approachable" 这类抽象偏好，代理无法据此稳定行事。

Patterns（模式）

8. 工作时段：你的工作时间是？有哪些时段不希望被打扰？
9. 第一天须知：有没有"一个新助理第一天就该知道"的、关于你工作方式的重要信息？

四、写入 USER.md：官方模板与填充要点

访谈结束后，用收集到的答案创建~/.openclaw/workspace/USER.md。指南给出完整模板并要求：替换所有占位符，文件中不得残留任何方括号。

# User Profile ## Who Name: [FULL NAME] Pronouns: [PRONOUNS] Location: [CITY], [TIMEZONE e.g., "UTC+5:30 / IST"] ## Contact Email: [PRIMARY EMAIL] [RESPONSE TIME RULES IF PROVIDED] ## Focus Role: [JOB TITLE / DESCRIPTION] Organization: [COMPANY OR "Independent"] What I am working on right now: - [SPECIFIC ITEM 1] - [SPECIFIC ITEM 2] - [SPECIFIC ITEM 3 if applicable] ## Style [SPECIFIC FORMAT PREFERENCES FROM QUESTIONS 6-7. Write as direct instructions, not descriptions.] ## Patterns Working hours: [FROM QUESTION 8] [INSIGHT FROM QUESTION 9]

填充时需要注意的三个要点

• 目标篇幅：约 250 词。这是课程给出的 USER.md 专属预算（四文件合计约 2000–2500 词）。原因在于注意力稀释：会话初期 USER.md 可能占据模型相当比例的注意力，随着会话增长到数万词，同一文件的实际权重会急剧下降；小而精的文件才能保证每轮被完整加载、且每条指令都有足够的相对权重。
• Style 段要写成指令而非描述：指南括号里特别注明 "Write as direct instructions, not descriptions."，这是模板中最容易写错的部分。
• 敏感信息隔离：这是 USER.md 最重要的边界规则——不要把敏感个人信息写进 USER.md。如果用户自愿提供了属于私密语境的细节（财务状况、健康状况、关系细节等），应当简短说明"这些应该放进 MEMORY.md"，然后继续。原因在课程文档中写得很清楚：USER.md 是group-safe（群聊安全）文件，Day 3 连接 Telegram 等消息平台后，它会出现在群聊上下文中；而 MEMORY.md 只在一对一私聊中加载。想让他人可见的信息才放 USER.md，私密信息一律进 MEMORY.md。

五、确认完成：写入后的三项汇报

文件写入后，向用户确认以下三件事（这正是指南"Confirm Completion"阶段的要求）：

1. 报告文件写入位置：~/.openclaw/workspace/USER.md；
2. 总结已捕获的角色与当前焦点事项：让用户核对 Focus 段是否准确；
3. 标记可能过期的内容：明确指出哪些信息"会随时间过期、后续需要更新"——典型如本周焦点清单（weekly focus items）。

指南还规定：除非用户明确要求，不要在同一个运行中继续创建 AGENTS.md。这与 claw-instructions-finalize-identity.md 中"不要在同一次运行中继续下一步，除非用户明确要求"的编排一致——Day 2 的四个身份文件按 SOUL.md → USER.md → AGENTS.md → MEMORY.md 的顺序逐个构建，每份文件独立确认，避免一次性写入过多导致上下文稀释与错误累积。

六、从课程文档看 USER.md 的设计原理

为什么 USER.md 要独立成文件，而不是并进 SOUL.md？

课程文档给出了三个技术理由，其中与 USER.md 直接相关的是隐私边界：一旦 Claw 接入群聊（Day 3），你希望财务状况、健康、关系上下文不进入群聊可见的上下文。USER.md 作为 group-safe 文件在一切上下文中加载，因此它只能包含你愿意被他人看到的信息；私密信息由 MEMORY.md 承担，加载边界由架构强制保证。

另一个理由同样与 USER.md 相关——关注点分离：行为规则属于 SOUL.md，关于"你"的上下文属于 USER.md，学习到的事实属于 MEMORY.md。如果混在一起，更新一个偏好时可能误触行为约束，维护成本会随文件增长急剧上升。

为什么 USER.md 每轮重载？

OpenClaw 在会话增长时会定期把较早的对话压缩成摘要以腾出上下文空间，但四个引导文件因为"每轮从磁盘重载"而天然免疫压缩——它们永远新鲜。这正是 Day 1 课程文档 learn.md 中提到的安全教训的解决方案：当"先询问再删除"这类常驻指令被压缩掉后，代理会像指令从未存在过一样继续行动；而 USER.md 这类磁盘文件不存在这个问题。

为什么 Focus 要"具体"而不是"贴标签"？

这是 USER.md 与 SOUL.md 共通的写作哲学：具体、尖锐、难以被重新解释的内容，才能在长会话中存活。课程文档以 SOUL.md 为例说明"约束比愿望更稳定"，同样的逻辑适用于 USER.md 的 Focus 段——"本周具体的 2–3 件事"比"我是产品负责人"更能指导代理在全新情境下做出正确反应。

七、USER.md 的维护：让它随你一起演化

课程文档强调：这些文件今天不会完美，这没关系。USER.md 的校准是一个迭代过程：

• 最快路径是在对话中直接告诉代理你的偏好，然后让它把该偏好写入 USER.md——"注意到某件事 → 更新文件 → 在后续会话中看到效果"这个循环，正是 USER.md 保持新鲜的机制；
• 优先级变化时更新 Focus 段。过期的 Focus 会产生"两个月前还有用"的回应；
• 文件既可以由你手动编辑，也可以直接对代理说"把这条加进 USER.md"，代理可以自行编辑自己的身份文件。

八、完整验证闭环：权限、重启与两个测试

当四个文件全部就绪后，claw-instructions-finalize-identity.md 提供了一条可执行的验证链路，其中与 USER.md 相关的内容包括：

1. 权限加固：SOUL.md、USER.md、AGENTS.md、MEMORY.md均设为600（仅属主可读写），memory/目录设为700；
2. 重启网关：运行openclaw gateway restart；
3. 验证测试：
   • 向 Claw 提问What do you know about me?——期望响应包含 USER.md 中的真实上下文（姓名、角色、当前焦点）；
   • 提问What are your rules?——期望响应反映 SOUL.md 与 AGENTS.md 中的名字、禁止行为、语气与确认协议；
4. 失败定位：如果两个测试的响应都很"泛化"（generic），说明工作区文件可能未被加载，应检查openclaw.json中配置的工作区路径。

九、最佳实践小结

结合指南与课程文档，创建高质量 USER.md 的要点可以归纳如下：

• 复用而非重问：先读 SOUL.md，名字已存在就直接复用，只补缺失字段；
• 一次一问，攒齐再写：访谈期间不跑工具、不写文件、不记增量日志；
• Focus 写具体事项：职位头衔给代理分类，本周清单给代理行动依据；
• Style 写成指令：用"默认短句回答""能用一句话就不用要点列表"替代"专业而亲切"；
• 约 250 词：精简到每轮可完整加载、每条指令有足够权重；
• 敏感信息进 MEMORY.md：USER.md 是群聊安全文件，只放你愿意公开的信息；
• 写入后确认三件事：文件位置、角色与焦点摘要、可能过期的内容；
• 逐步构建：SOUL.md → USER.md → AGENTS.md → MEMORY.md 逐个完成，除非用户明确要求，不在同一轮继续下一步；
• 持续迭代：优先级变化就更新 Focus，偏好变化就在对话中直接让代理写入。

完成 USER.md 后，你的 Claw 将知道它服务的对象是谁、对方此刻在忙什么、以及希望以什么风格被对待——这是 Day 3 接入手机消息通道之前，让代理从"能力通用"走向"为你校准"的关键一步。

相关文件索引

• 本文主体指南：claw-instructions-create-user.md
• Day 2 理论文档（四文件体系与原理）：learn.md
• SOUL.md 创建指令：claw-instructions-create-soul.md
• AGENTS.md 创建指令：claw-instructions-create-agents.md
• MEMORY.md 创建指令：claw-instructions-create-memory.md
• 身份验证与收尾：claw-instructions-finalize-identity.md
• Day 1 安全基线：learn.md
• 课程总览：README.md

• 文档
• 教程
• 人工智能
• 大模型