一、背景：nanobot 是什么，我为什么从它切入#
OpenClaw 是一个本地 AI 助手网关（local AI assistant gateway）——让 LLM 连接到 WhatsApp、Telegram、Discord 这类消息平台，赋予它工具调用能力，能在用户本机执行命令、读文件、跑脚本，7×24 运行，支持持久化 memory 和多用户 session 管理。代码量约 43 万行，52+ 模块，70+ 依赖。
直接读 OpenClaw 有没有必要呢？有的。但是是不是非读 OpenClaw 不可呢？未必。
我选择了 nanobot：OpenClaw 的教学级简化复刻，约 4000 行 Python，比 OpenClaw 小 99%。它保留了 agent 的核心骨架——agent loop、context 构建、持久化 memory、模块化 tool 系统，以及消息平台接入——裁掉了 100+ skills、浏览器控制、语音、复杂权限系统等生产级功能。
为什么从 nanobot 入手，而不是直接啃 OpenClaw？
核心原因是：nanobot 的设计目标是「可读性优先」。当一个功能只有一种实现方式，没有 fallback、没有兼容层、没有 feature flag，你才能看清它的本质结构。我读 nanobot 的目标是理解 agent 的架构骨架，搞清楚核心机制是怎么运转的，而不是去对照 OpenClaw 的具体实现——在 AI 成为代码能力杠杆的时代，具体实现可以先放下，架构思想才是最值得提炼的东西。
二、Prompt 设计思路 + Prompt 正文#
2.1 我是怎么设计这个 Prompt 的#
整个过程大概是这样的：
第一步：描述意图，让 Claude 先搜索背景
我先用自然语言告诉 Claude 我的场景：面试中需要介绍一个我研读过的 agent 项目，面试官可能会追问架构细节、对比分析、改进思路。然后让它搜索 OpenClaw 和 nanobot 的基本信息，建立共同背景。
第二步：让它写初稿
给一个宽松的结构要求，让 Claude 先跑一遍。为什么呢？我们对于「需要讲哪些部分」通常只有模糊概念，如果一边想一边写很低效，还容易遗漏。不如直接让 Claude 出一个完整的初稿，然后在它上面增删、纠偏、补深度——改比从零写快得多，也更全面。
第三步：逐段提出具体要求，迭代改进
这一步是最关键的。我们需要站在面试官的角度给 AI 出有针对性的指令，而不是笼统地告诉它”优化 XX 方面”。我会这么要求：
- 对比分析段：补充对 Claude code 和 OpenClaw 的对比
- 追问部分：预测面试官会根据你的回答继续追问什么——不一定和面试场景下的提问相近，但是基于面试官视角的提问能启发我们思考更多
第四步：最终收口
整合所有迭代结果，加入角色设定、语气要求、输出约束，形成最终 Prompt。
2.2 Prompt 正文#
以下是最终版本，附我的设计注释（# → 开头）：
你现在是我的面试备考教练。
请完整阅读当前项目（nanobot）的所有代码文件。
nanobot 是 OpenClaw 的极简复刻版（~4000 行 Python，比 OpenClaw 小 99%），
我通过研读 nanobot 来理解 OpenClaw 的架构思想。
面试场景：面试官问「介绍一下这个项目，以及你从中学到了什么」
请帮我生成一份口语化的面试回答稿 + 追问准备材料。# → 开头的角色设定：「面试备考教练」比「助手」更精准。它隐含了两个要求：输出要面向实战、要帮我预判面试官的思路，而不只是生成漂亮的文档。
【你需要先理解的背景】
OpenClaw 是什么：
- 一个本地 AI 助手网关（local AI assistant gateway）
- 让 LLM 连接到 WhatsApp、Telegram、Discord 等消息平台
- 赋予 LLM 工具调用能力，能在用户本机执行命令、读文件、跑脚本
- 7x24 运行，持久化 memory，多用户 session 管理
- 代码量 ~43 万行，52+ 模块，70+ 依赖
nanobot 是什么：
- OpenClaw 的教学级简化复刻
- 保留核心骨架：消息接入 → agent 循环 → tool 调用 → 结果回写
- 裁掉了大量生产级功能，换来可读性和可审计性
Claude Code 是什么（对比参照）：
- Anthropic 出品的 coding agent，terminal-native
- 定位是开发工作流：读代码库、改文件、跑命令、集成 CI/CD
- client-server 架构，本地执行但调用 Anthropic 云端 API
- 有权限系统、context 自动压缩、MCP 集成、subagent 并行
⚠️ 重要：OpenClaw 和 Claude Code 不是同类竞品，
是两种不同的 agent 产品形态，面向完全不同的使用场景。# → 背景补充：给 Claude 一个「知识基准线」，避免它从网上检索到错误信息，同时明确 OpenClaw vs Claude Code 不是竞品对比，防止它在对比段落里走偏。
【角色设定】
- 我研读过这个项目，对架构有自己的理解，正在向技术面试官介绍
- 语气：自信但不夸张，像真人在聊，不是念 PPT
- 中文回答，专有名词保留英文（tool call、MCP、session 等）
- 我对整体框架了解，部分细节不确定，
适当使用「我当时的理解是 X，背后的考量是 Y」的句式【回答正文结构】
1. 一句话定位
2. 我为什么读这个项目
3. 通过 nanobot 理解到的 OpenClaw 核心架构
- 整体分层
- 核心数据流
- 最有价值的 2-3 个设计决策（从代码里找真实存在的，说清楚背后的考量）
4. OpenClaw vs Claude Code：两种 agent 形态的对比分析【重点段】
a) 产品定位的本质差异
b) 交互模型的差异（及架构影响）
c) 执行环境与安全模型的差异
d) Memory 与持久化的差异
e) 我的技术选型思考（要体现自己的判断）
5. 如果让你改进或二开 OpenClaw，你会做什么？
格式：发现了什么问题 → 我会怎么改 → 为什么这么改 → 预期提升
6. 源码阅读方法论 + 对 agent 设计的启发# → 结构设计的逻辑：面试回答的结构不是「从头到尾讲完」，而是「先给定位，再给证据，最后给自己的判断」。第 4 段（对比分析）是核心，考察的是技术视野而不只是对某个项目的了解。第 5 段（改进思路）考察的是「你能不能把理解转化为工程决策」。
【追问准备材料】
预测面试官会根据你的介绍继续追问的 12 道题，分三组：
【A 组：架构理解类】（4题）
考察你真的读懂了 nanobot 的代码，而不只是会背概念
【B 组：对比分析类】（4题）
考察你的技术视野和独立判断能力
【C 组：延伸思考类】（4题）
考察你对 agent 这个方向的理解深度
每道题格式：
- 问题
- 考察点（面试官真正想听什么）
- 我应该怎么答（关键词 + 角度）# → 追问材料的本质：这里的核心不是「准备标准答案」，而是推演对话走向——你说了 A，面试官大概率会问 B。把这个推演做出来，延伸思考。
【输出约束】
- 代码相关内容直接从 nanobot 代码事实出发，不要编造
- 对比分析段可以结合背景知识展开，但对比观点要有自己的立场三、关于 Agent 类项目源码的阅读思路#
我读 agent 类项目，用的不是「从入口文件开始逐层追」的方式，而是先让 AI 把项目消化成一份结构化文档，再自己去看核心代码。
具体是三步：
第一步：先把项目跑起来，体验用户视角
在看任何一行代码之前，先把这个 Agent 部署起来用一用——发条消息、触发一个 tool、看看效果如何。这一步的目的是建立对一个项目感性上的认知。
- 如果做得不好，那么你祛魅了（在 Fomo 情绪严重的时期这很有意义）你可以带着”如果让我来设计，我会如何改进”的思考走进读源码环节。
- 如果这次体验让你眼前一亮，你可以思考，怎么做到这种效果？这个项目和以往读到的有什么不一样？
第二步：让 AI 生成 TELLME.md，建立整体认知
跑起来之后，我会给 Claude 一个 prompt，让它深度分析整个代码库，生成一份 TELLME.md。这份文档围绕四个方向建立结构化认知：技术栈全景（语言 / 框架 / 工具库分层）、模块职责地图（完整目录树 + 入口文件 + 各模块说明）、运行环境配置（依赖安装 / 环境变量 / 启动命令）、Agent 技术体系（LLM 调用方式 / memory 机制 / tool 注册调用链 / 数据流图）。
生成出来之后，我会对着 TELLME.md 读一遍，知道整体骨架是什么样的。
第三步：再去看核心代码
有了整体认知之后，再去看具体模块才有意义——你知道自己在看什么、它在整个系统里处于什么位置、它和哪些模块有交互。这时候看代码是在「验证和深化理解」，而不是在「盲目扫描」。
这个方法的好处是：TELLME.md 把代码库压缩成了一个可以快速遍历的指引，省去了大量「找入口、找依赖、找数据流」的时间成本，直接进入有效阅读。
四、面向面试 Vs 面向读懂源码#
面向面试的 Prompt 设计#
1. 明确场景边界
→ 面试题是什么？面试官是谁？考察什么能力层级？
2. 给定背景知识基准线
→ 把 Claude 不一定知道或可能搜到错误信息的内容直接喂给它
3. 设定「说话人」角色
→ 我是谁？我对这个项目的了解深度是什么？
在我看来我应该怎么介绍，主要介绍什么，如何才能在展示自己对架构设计的理解的同时兼顾产品 sense？
4. 结构里加入「考官视角」
→ 不只是「我要说什么」，还要设计「考官想听什么」
→ 追问材料的核心是推演对话走向，给出提示回答方向的关键词，而不是准备标准答案
5. 迭代方式：逐段提具体要求，不要整体重写
→ 初稿出来后，找思考不够全面或方向偏了的段落，给具体的补充指令面向读懂源码的 Prompt 设计#
1. 先把项目跑起来，建立用户直觉
→ 在看代码之前，先体验一遍用户视角
→ 知道输入是什么、输出是什么、系统对外表现如何
2. 用 TELLME.md prompt 生成结构化认知地图
→ 让 AI 分析整个代码库，输出技术栈、模块职责、数据流图
→ 目标是快速建立整体认知，而不是从入口文件开始逐行扫描
3. 有了认知地图之后，再去看核心代码
→ 这时候看代码是「验证和深化理解」，不是「盲目扫描」
→ 你知道自己在看什么、它在整个系统里的位置是什么
4. 对看不懂的设计，构造反例来验证理解
→ 「如果 X 不这样设计，会有什么问题？」
→ 能回答这个问题，说明你真的理解了这个设计决策
5. 最后整理「我还不确定的问题清单」
→ 读完之后，把剩余不确定的点列出来
→ 这个清单就是下一轮深读的入口核心差异在哪里？
面向面试的 Prompt，核心是「输出导向」：怎样体现我对该项目的理解。结构、角色、考官视角都服务于这个目标。
面向读懂源码的 Prompt，核心是「理解导向」：我还不知道什么、怎么一步步逼近真相、怎么验证我的理解是对的。所以先跑起来、生成认知地图、再深入核心代码，是这条路的主线。
前者是把已有的理解「结构化输出」，后者是用 AI 作为「思维伙伴」来加速理解的初步建立。