AI on 鬼哥的空间

ai-convo-exporter：别让 AI 对话死在终端里

Fri, 08 May 2026 00:00:00 +0000

你每天和 AI 讨论架构、修 bug、拆任务，最后这些高价值判断都去哪了？

大概率是：死在终端日志里。

这有点荒谬。我们愿意把代码提交到 Git，把笔记放进 Obsidian，把文档同步到云端，却经常把最密集的工程思考过程留在 ~/.codex 和 ~/.claude 这种“存在但不会再看”的角落里。

所以我做了一个小工具：ai-convo-exporter。

问题不是“没有记录”，而是“记录不可用”

Codex 和 Claude Code 其实都会保存对话。

Claude Code 的记录大致在：

1

~/.claude/projects/**/*.jsonl

Codex 的记录大致在：

1
2


~/.codex/sessions/**/*.jsonl
~/.codex/archived_sessions/*.jsonl

问题是，保存了不等于可复用。

这些 JSONL 原始 transcript 对机器友好，对人不友好。你想找“上次那个 ads-attribution 项目里，我和 Codex 讨论 Diana UI 怎么启动来着”，通常不会去翻一堆 UUID 文件。更现实的情况是：重新问一遍 AI，重新烧一遍上下文，重新踩一遍坑。

我想要的是另一种形态：

需求	直接翻原始日志	导出到 Obsidian
按项目查找	很难，要理解工具内部目录规则	直接按 project 文件夹
全文搜索	可以 grep，但体验粗糙	Obsidian 原生搜索
跨机器复用	路径不同，容易散	vault 同步即可
保留原始记录	有，但不适合阅读	Markdown + raw JSONL 双份保存
后续再加工	成本高	frontmatter + tags + Dataview

这就是 ai-convo-exporter 的核心目标：把 AI 对话从“工具内部状态”变成“个人知识资产”。

它怎么组织你的对话？

工具的设计原则很简单：按项目，而不是按 AI 工具。

因为你真正关心的不是“这条对话来自 Codex 还是 Claude Code”，而是“它属于哪个项目”。同一个项目里，今天可能用 Codex 查代码，明天用 Claude Code 写实现。最后应该沉淀到同一个知识空间里。

导出后的目录长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Obsidian Vault/
 AI Conversations/
 Projects/
 luoli523__ads-attribution/
 _index.md
 sessions/
 2026-05-08 0947 codex 019e0544 保存对话.md
 2026-04-27 1621 claude fd7d3855 实现 FxRate.md
 raw/
 codex/
 019e0544-7beb-7983-a458-de94206793f8.jsonl
 claude/
 fd7d3855-0b5d-482d-a008-0827ab6cd875.jsonl

这里有一个小细节：项目文件夹不是直接用本机绝对路径。

如果一个项目有 git remote，工具会优先用 remote path 做稳定 ID，比如：

1

git@github.com:luoli523/ads_attribution.git

会被转换成：

1

luoli523__ads-attribution

这样换一台机器，即使 checkout 路径从 /Users/li.luo/dev/git/... 变成 /Users/foo/code/...，同一个项目仍然会进入同一个 Obsidian 文件夹。

每篇笔记都不是纯文本，而是可查询对象

每段对话会生成一篇 Markdown，开头带 frontmatter：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


---
type: ai-conversation
provider: codex
session_id: 019e0544-7beb-7983-a458-de94206793f8
project: luoli523/ads_attribution
project_slug: luoli523__ads-attribution
created: 2026-05-08T09:47:14+08:00
cwd: /Users/li.luo/dev/git/ads_attribution
git_repo: https://github.com/luoli523/ads_attribution
git_branch: main
machine: macbook
raw_transcript: ../raw/codex/019e0544-7beb-7983-a458-de94206793f8.jsonl
tags:
 - ai/conversation
 - provider/codex
 - project/luoli523__ads-attribution
---

这让它不只是“看起来像笔记”，而是能被 Obsidian、Dataview、搜索和标签系统继续使用。

比如你可以查：

最近一周我在哪些项目里大量使用了 Codex？
某个项目里 Claude Code 和 Codex 分别处理过哪些任务？
哪些对话发生在某台机器上？
哪些讨论和某个 git repo 或 branch 有关？

AI 对话一旦结构化，就不只是聊天记录，而是工程过程的审计日志。

安装方式：checkout 后一条命令生效

我不想为这个工具引入复杂依赖，所以它只使用 Python 标准库。

安装方式：

1
2
3


git clone https://github.com/luoli523/ai-convo-exporter
cd ai-convo-exporter
./install.sh --vault "$HOME/Documents/Obsidian Vault"

安装脚本会做几件事：

动作	文件
写本地配置	`~/.config/ai-convo-exporter/config.json`
安装命令包装器	`~/.local/bin/ai-convo-exporter`
添加 Claude Code Stop hook	`~/.claude/settings.json`
添加 Codex Stop hook	`~/.codex/hooks.json`
启用 Codex hooks	`~/.codex/config.toml`

后续每次 Codex 或 Claude Code 对话结束，Stop hook 会自动调用：

1
2


ai-convo-exporter hook --provider codex
ai-convo-exporter hook --provider claude

安装是幂等的。重复执行 ./install.sh 不会不断追加重复 hook，这一点很重要。配置工具最怕“装一次能用，装三次变成玄学现场”。

历史记录也能补导入

如果你已经用了很久 Codex 或 Claude Code，可以执行：

1

ai-convo-exporter backfill

它会扫描默认位置：

1
2
3


~/.claude/projects/**/*.jsonl
~/.codex/sessions/**/*.jsonl
~/.codex/archived_sessions/*.jsonl

然后批量导入到 Obsidian。

如果你想先看看当前配置是否正确：

1

ai-convo-exporter doctor

典型输出类似：

1
2
3
4
5
6
7


Config: /Users/li.luo/.config/ai-convo-exporter/config.json
Vault: /Users/li.luo/Documents/Obsidian Vault
Conversations dir: AI Conversations
Timezone: Asia/Singapore
Claude settings: /Users/li.luo/.claude/settings.json
Codex hooks: /Users/li.luo/.codex/hooks.json
Codex config: /Users/li.luo/.codex/config.toml

我真正想保留下来的不是“答案”

很多人把 AI 对话当成一次性问答：问完、复制、结束。

但在编程场景里，真正有价值的往往不是最终答案，而是中间过程：

这个方案为什么被放弃？
当时为什么选这个目录结构？
某个 bug 的根因是怎么定位出来的？
哪个测试失败暴露了真实问题？
我是怎么让 Agent 从错误方向回来的？

这些内容如果不沉淀，会变成一种很可惜的损耗：你花钱、花 token、花时间训练出来的上下文，只活了一次。

ai-convo-exporter 解决的不是“备份聊天记录”这么小的事情。它更像是在给个人开发工作流补一个缺口：让 AI 协作过程变成可检索、可复盘、可迁移的工程资产。

适合谁用？

如果你只是偶尔问 AI 一个命令怎么写，这个工具可能没那么必要。

但如果你有下面这些习惯，它会很有用：

用 Codex 或 Claude Code 深度探索项目
让 AI 帮你做架构决策和代码审查
经常跨多个项目切换
多台机器同时开发
已经在用 Obsidian 管理长期知识
想复盘自己和 AI 协作的工作方式

一句话：当你的 AI 对话已经有复用价值，就值得被当成知识来管理。

Takeaway：把 AI 对话纳入你的知识系统

如果你想试用，只需要三步：

clone 仓库：git clone https://github.com/luoli523/ai-convo-exporter
安装 hook：./install.sh --vault "$HOME/Documents/Obsidian Vault"
可选补导入：ai-convo-exporter backfill

以后每次 Codex 或 Claude Code 对话结束，它都会自动进入 Obsidian。

这件事的收益不是第一天就爆炸，而是一个月后你搜索某个项目时，突然发现：原来那些曾经散落在终端里的判断、踩坑和上下文，现在都回来了。

参考资料

GitHub 仓库：luoli523/ai-convo-exporter
Codex Hooks 文档：OpenAI Codex Hooks
Claude Code Hooks 文档：Claude Code Hooks
Obsidian Dataview：Dataview Plugin

兴趣太多不是缺点：AI 时代，通才要把自己做成一个系统

Tue, 28 Apr 2026 00:00:00 +0000

如果你兴趣很多，别急着骂自己“注意力不集中”。在 AI 时代，兴趣太多可能不是 bug，而是你还没找到运行它们的系统。

过去社会喜欢把人压成一个标签：前端工程师、设计师、销售、产品经理、老师、会计。越窄越“专业”，越窄越好管理。但今天的问题是：越窄，也越容易被替代。

先补一笔背景：Dan Koe 是英文创作者经济圈里很有代表性的“一人公司”写作者。他是《The Art of Focus》的作者，也是 AI 知识管理产品 Eden 的共同创始人，长期围绕写作、个人品牌、数字产品、AI 工具和 one-person business 输出。更重要的是，他不是站在岸上讲“兴趣变现”的观察者，而是把 newsletter、社交内容、课程产品和软件业务串成一套内容飞轮的人。

Dan Koe 最近那篇 X Article《If you have multiple interests, do not waste the next 2-3 years》讲的就是这件事：多兴趣不是弱点，真正的问题是你缺少一个“容器”，把兴趣变成作品、信任、产品和收入。

一、工业时代喜欢专家，AI 时代奖励连接者

现代社会对“专业化”的迷恋，来自工业时代。

流水线最喜欢什么人？喜欢每个人只做一道工序。你不需要理解全局，不需要判断，不需要创造，只要准时、服从、稳定输出。学校训练这种人，公司使用这种人，管理系统也最容易评估这种人。

问题是，流水线逻辑一旦套到人生上，就会变成一套很窄的剧本：

工业时代剧本	隐含假设
选一个专业	你一生只需要一个方向
拿一个学位	学校替你定义什么有价值
找一份工作	公司替你分配问题
稳定到退休	世界变化不会太快

这套剧本在过去还能凑合跑，因为知识传播慢、组织规模大、岗位边界清晰。但现在不一样了。

AI 正在把“单点技能”的价格打下来。写代码、写文案、做图、整理资料、生成方案，这些过去需要专门训练的技能，正在变成人人可调用的能力。

所以问题不再是“你会不会某个技能”，而是：

你能不能把多个技能、多个兴趣、多个领域的观察，组合成别人看不到的解决方案。

二、兴趣多的人，缺的不是专注，是容器

很多兴趣广泛的人都有一个共同困境：一直学习，但生活没有改变。

教程看了很多，书单收藏了很多，工具研究了很多，笔记写了很多。每隔一段时间就发现一个新方向，然后兴奋三天、沉默两周、换下一个坑。

外人说这是“闪亮物体综合征”。但 Dan Koe 的判断更有意思：这未必说明你没救，可能只是说明你还没有一个能承载兴趣的容器。

什么是容器？

它不是一个更精确的 niche，也不是一个更漂亮的个人简介，而是一套能把兴趣转化成外部价值的结构。

没有容器	有容器
学习只是消费	学习变成研究
兴趣只是逃避工作	兴趣变成工作材料
笔记躺在本地	观点公开积累
输出零散随机	内容形成系统
只有自我满足	能帮别人解决问题

一个写作者的容器可能是 newsletter。一个程序员的容器可能是开源项目。一个设计师的容器可能是案例库。一个创业者的容器可能是产品系统。

兴趣不是最终形态，容器才是。

没有容器，兴趣再多也是消耗注意力；有了容器，兴趣会变成持续生产的燃料。

三、第二次文艺复兴：观点比信息更稀缺

Dan Koe 把当下称为“第二次文艺复兴”。

第一次文艺复兴为什么会发生？一个关键原因是印刷机降低了知识传播成本。书不再只能靠手抄，思想传播速度变快，普通人第一次有机会在一生中接触多个领域。

于是出现了达芬奇、米开朗基罗这类跨学科人物。他们不是只会一件事的人，而是在艺术、工程、解剖、建筑、诗歌之间来回穿梭。

今天，互联网和 AI 做了类似的事情，只是速度更夸张。

知识已经不稀缺。你想学销售、心理学、设计、编程、健身、哲学、商业模型，几乎都能马上开始。真正稀缺的是你自己的视角。

一个懂心理学的设计师，理解用户行为的方式不一样。一个懂哲学的销售，理解说服的方式不一样。一个懂健身又懂商业的人，做健康产品时看见的问题也不一样。

你的优势不一定在某一个领域有多深，而在这些领域的交叉点。

AI 可以生成信息，但它不会自动拥有你的生活经历。它可以帮你推演，但前提是你得告诉它从哪个角度看世界。

四、把学习变成公开研究，把研究变成信任

多兴趣者最容易卡在一个地方：他以为自己要先“学成”，才能开始输出。

这通常是错的。

如果你一直等到自己足够专业才开始，最后很可能永远不开始。更好的路径是：把学习本身变成公开研究。

你本来就在读书、试工具、拆案例、做项目。现在只是多做一步：把你正在理解的东西，用别人能看懂的方式讲出来。

这个过程可以形成一条很清晰的链路：

1

兴趣 -> 学习 -> 公开笔记 -> 内容 -> 信任 -> 产品/服务

这不是让你装成专家。恰恰相反，它要求你诚实地呈现自己的探索过程：

我遇到了什么问题？
我看了哪些资料？
我试了什么方法？
哪些有效，哪些没用？
我现在会怎么建议过去的自己？

这类内容为什么有价值？因为大多数人不缺答案，缺的是一条能照着走的路径。

你解决自己的问题，再把路径公开出来，就可能帮到过去的你，也帮到一群处在类似阶段的人。

五、别急着做“个人品牌”，先做一个小世界

很多人一听“个人品牌”，脑子里立刻冒出头像、简介、定位语、视觉风格。

这些东西有用，但不是核心。

真正的品牌，是别人关注你三到六个月之后，脑子里留下的整体印象：你在关心什么问题，你反复强调什么价值，你的审美是什么，你怎么判断世界，你想把别人带到哪里。

换句话说，品牌不是包装，而是一个环境。

你要创建的是一个“小世界”：别人进入之后，能感受到一套稳定的故事、观点和问题意识。

这就要求你先把自己的故事梳理清楚：

问题	用途
我从哪里来？	找到叙事起点
我经历过哪些低谷？	找到真实张力
我学过哪些东西？	找到能力来源
哪些经验真正改变了我？	找到可分享的方法
我想帮助哪种过去的自己？	找到内容和产品方向

你不需要天天讲自己。但你讲的东西，最好都能回到同一个世界观里。

做久了，品牌自然会出现。不是你声明出来的，而是读者在长期接触中感受到的。

六、内容不是信息搬运，而是观点密度

互联网已经不缺内容。AI 出来之后，更不缺。

未来真正有价值的内容，不是“我也总结了十条原则”，而是你能不能把高信号观点聚到一起，再用自己的语言、经历和判断重新组织。

Dan Koe 提了一个很实用的做法：建立“想法博物馆”。

它可以很简单，就是一个长期笔记库。看到让你兴奋的观点、案例、句子、结构、问题，就立刻记下来。工具不重要，习惯才重要。

你可以按三个标准筛选想法：

标准	说明
表现潜力	这个想法别人会不会关心
兴奋程度	你自己是否真的想写
观点密度	它是否能延展出更多问题

真正厉害的创作者，脑子里通常都有 5-10 个反复打磨的核心观点。他们会用不同例子、不同结构、不同场景反复讲这些观点。

所以写作训练不只是“多写”，还包括：同一个观点，用 100 种结构表达。

比如“清醒的人更快乐”这个观点，可以写成观察：

我发现快乐的人都有一个共同点：他们非常在意自己的精神清晰度。

也可以写成清单：

1
2
3
4
5
6


快乐的人通常更清醒：
- 他们会休息
- 他们减少干扰
- 他们只追一个关键目标

所以他们不是更幸运，而是更少被噪音劫持。

同一个观点，不同结构，影响力完全不同。

七、系统才是新的产品

最后一层，是产品。

Dan Koe 的判断是：我们正在进入“系统经济”。人们不只是想要一个答案，而是想要你的解决方案。

为什么？

因为答案到处都是，但一个被真实问题打磨过的系统很少。系统意味着：它不是空泛建议，而是一套你亲自走过、测试过、修正过的流程。

比如写作课很多，但如果你能证明自己有一套方法，可以每天两小时完成主要内容生产，把 newsletter、博客、社交媒体、视频、产品推广串成一个循环，那它就不只是知识，而是系统。

系统产品通常来自三个步骤：

你遇到一个真实问题
你为自己设计一套解决流程
你把流程整理成别人也能用的版本

这就是为什么多兴趣者不一定要一开始就“卖课”或“做产品”。你可以先把自己的问题解决过程记录下来。等路径稳定、结果可见，再把它产品化。

结尾：接下来 2-3 年，不要只学习

如果你兴趣很多，接下来最重要的不是再找一个“终极定位”，而是开始搭一个容器。

回顾一下，路径其实很清楚：

承认多兴趣不是缺点，它是你的连接优势。
停止只消费信息，把学习变成公开研究。
建立想法博物馆，持续积累高密度观点。
用内容让别人看见你的问题意识和成长路径。
从自己的真实问题里提炼系统，再把系统变成产品。

别再问“我到底应该专注哪一个兴趣”。更好的问题是：

我能不能把这些兴趣，放进同一个持续产出的系统里？

如果答案是能，那你不是不专注。你只是终于找到了一个足够大的容器。

参考资料

Dan Koe: Official Website
Dan Koe: If you have multiple interests, do not waste the next 2-3 years
Dan Koe Letters: The Dan Koe Newsletter

DESIGN.md：让 AI 拥有"设计品味"的新标准

Sun, 12 Apr 2026 00:00:00 +0000

一个 markdown 文件，51,000 颗 star，6,300 个 fork。

这大概是 2026 年最被低估的 AI 工程概念。

你让 Claude Code 生成一个登录页，它给你一坨"能用但丑陋"的 Bootstrap 味 UI。你让 Cursor 给你做个 dashboard，它给你另一坨"能用但丑陋"的 Bootstrap 味 UI。

AI 会写代码，但 AI 没有品味。

除非——你给它一份 DESIGN.md。

一、一切从 Google Stitch 的一个小改动说起

2026 年初，Google 悄悄给它的 AI 设计工具 Stitch 引入了一个新概念：DESIGN.md。

定位很简单：

AGENTS.md 告诉 AI Coding Agent 怎么建项目； DESIGN.md 告诉 AI Design Agent 项目长什么样。

两个 markdown 文件，分工明确——一个管工程，一个管审美。

然后事情就有点失控了。一个叫 VoltAgent 的团队开了个 GitHub 仓库 awesome-design-md，从真实网站里"提取"66 个主流品牌的 DESIGN.md，免费开源。两个月，冲到 51k stars。

你可以在里面找到：Claude、Vercel、Linear、Notion、Stripe、Apple、Airbnb、Figma、Supabase、Raycast、Cursor、Warp、OpenAI、xAI……几乎你叫得上名字的现代科技品牌都在里面。

二、DESIGN.md 到底是什么？

它就是一个 markdown 文件。

没有 Figma 插件，没有 JSON schema，没有 Tailwind 配置，没有 design tokens，没有任何工具链。就是一个 DESIGN.md，丢在你的项目根目录，和 README.md 并排放着。

一份典型的 DESIGN.md 里有这些内容：

视觉主题与氛围（比如 Claude 是 “warm terracotta accent, clean editorial layout”）
色板 + 每个颜色的语义角色
字体层级（字号、字重、行高）
组件样式（按钮、卡片、输入框、导航）
间距与布局原则
阴影与层级系统
设计边界（该做什么 / 不该做什么）
响应式断点
给 AI Agent 的 prompt 指引

看起来和传统的设计规范文档差不多？关键不在内容，关键在格式。

三、为什么是 Markdown？

这是整个概念最"反直觉"的地方。

对比一下主流方案

方案	机器可读性	AI 理解度	人可读性	落地成本
Figma 导出	高	低（需要插件）	中（要开软件）	高
Design Tokens JSON	高	中	低	中
Tailwind Config	高	中	中	中
DESIGN.md	中	极高	极高	几乎为零

你发现了吗？对 LLM 最友好的格式，不是最"结构化"的格式，而是它训练时见得最多的格式——自然语言 + markdown。

用 prose 描述设计，比用 JSON 更准确

对比两种写法，说"按钮的 hover 状态要有一点点活力，但不能太跳跃"：

JSON 写法：

1
2
3
4
5
6
7
8
9


{
 "button": {
 "hover": {
 "transform": "translateY(-1px)",
 "transition": "all 150ms ease",
 "boxShadow": "0 4px 12px rgba(0,0,0,0.08)"
 }
 }
}

DESIGN.md 写法：

1
2
3
4
5


## Buttons

Hover state should feel **alive but restrained**—a subtle lift of 1px
with a soft shadow. Never bouncy or playful. The goal is "confident
acknowledgement," not "look at me."

哪一种更能让 AI 理解"克制的活力"？

JSON 写法告诉你怎么做，但没告诉你为什么——AI 只能机械复刻，不能举一反三。markdown 写法把意图交给了 AI，换一个组件、换一个场景，它能自己推导出一致的风格。

这就是 DESIGN.md 的核心洞察：LLM 需要的是"设计语义"，不是"设计数值"。

四、一份真实的 DESIGN.md 长什么样

我们看一下 Claude 品牌的 DESIGN.md 片段（节选自 getdesign.md/claude/design-md）：

关键 section 的写法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


# Claude Design System

## Visual Atmosphere

Editorial warmth meets AI precision. The palette feels like a vintage
book in a modern library—warm cream paper, sepia ink, a single terracotta
accent that signals "this is where intelligence lives."

## Color Palette

- **Background**: Cream white (#faf9f5) — never pure white
- **Text primary**: Deep charcoal (#1f1e1c) — never pure black
- **Accent**: Terracotta (#d97757) — used sparingly, for CTAs and highlights
- **Muted**: Sepia gray (#8a7f72) — for secondary text and borders

**Rule**: If you're reaching for pure #000 or #fff, stop. This design
system lives in the warm middle.

## Typography

Use Tiempos Text for body (serif, generous line-height).
Use Styrene for UI and headings (sans-serif, tight tracking).
Never mix more than two font families. Never use bold on serif body.

## Component: Chat Bubble

User messages: terracotta background, cream text, 14px radius.
Claude responses: cream background, charcoal text, no bubble border.
The asymmetry is intentional—it keeps the AI's responses "in the
paper," not "on top of the paper."

注意几个细节：

每个色值都带"为什么"：不只是 #faf9f5，而是 “cream white, never pure white”。AI 读到这句，就知道选色时要偏暖偏柔，永远别往纯白靠
规则是用散文写的：“If you’re reaching for pure #000 or #fff, stop."——这种表达方式 JSON 写不出来
语义 > 数值：“The asymmetry is intentional”——这句话决定了 AI 遇到新组件时的判断标准

这就是为什么 AI 读了 DESIGN.md 之后，生成的 UI 真的会"有品味”。

五、实战：在 Claude Code 里用 DESIGN.md

理论讲完了，看怎么用。以 Claude Code 为例，30 秒上手。

Step 1：挑一个你喜欢的品牌

去 awesome-design-md 的 README 里浏览 66 个品牌。选一个风格接近你目标项目的——比如我要做一个极简的 SaaS 落地页，选 Linear 或 Vercel。

Step 2：下载 DESIGN.md 到项目根目录

访问对应品牌的 URL（比如 https://getdesign.md/linear.app/design-md），复制 markdown 内容保存为 DESIGN.md，放在项目根目录：

1
2
3
4
5


my-project/
├── CLAUDE.md
├── DESIGN.md ← 新增
├── package.json
└── src/

Step 3：在 CLAUDE.md 里引用它

编辑你项目的 CLAUDE.md，加一行：

1
2
3
4
5


## Design System

All UI work must follow `DESIGN.md` at the project root.
When generating components, read DESIGN.md first and match its
color palette, typography, component rules, and atmosphere exactly.

Step 4：让 Claude Code 生成 UI

1

你：帮我做一个 pricing page，三档套餐，带年付/月付切换

Claude Code 会先读 DESIGN.md，然后生成的代码会：

颜色自动用 Linear 的 #5e6ad2 紫色做 accent
字体层级严格匹配 Linear 的 Inter + tight tracking
按钮的 hover 状态带 Linear 标志性的 “subtle glow”
整体氛围是 Linear 那种 “ultra-minimal, precise”

最关键的是——如果你让它继续做一个 dashboard 页面，它会自动保持一致的风格。 因为 DESIGN.md 给了它"世界观"，不是零散的 tokens。

六、它的局限与边界

我不想把这篇写成纯 hype 贴。DESIGN.md 不是银弹，有几个场景它就是不适合：

1. 精准交互动效：如果你想要"按下按钮后 300ms 内显示 ripple，持续 200ms 后消散"，这种精确到毫秒的规格，markdown 不如 JSON token

2. 不能代替 Design Review：AI 生成的 UI 看起来对了，不等于好用。信息层级、可用性、无障碍——这些还得人来把关

3. 同质化风险：如果大家都抄 Linear 或 Vercel 的 DESIGN.md，互联网上的 AI 生成页面会越来越像

4. 对"极致精细"场景不够：Apple、Stripe 那种对每个像素都有要求的品牌，光靠 DESIGN.md 不够——你需要人类设计师 + DESIGN.md 双保险

5. 跨 Agent 的兼容性还不稳：不同 AI（Claude、Cursor、Lovable、Stitch）对 DESIGN.md 的理解深度不一样，效果会有差异

但这些局限不妨碍一个事实：DESIGN.md 把"让 AI 做出有品味的 UI"这件事，从一项玄学变成了一项工程。

七、为什么我觉得这是个大事

如果你退一步看，DESIGN.md 背后是一种更根本的转变：

过去：设计系统是给设计师和前端工程师读的。内容是 Figma、Storybook、Design Tokens。

现在：设计系统的第一读者变成了 AI Agent。内容必须是 LLM 能原生理解的格式——也就是 markdown + prose。

这个转变和 CLAUDE.md / AGENTS.md 的兴起是同一条逻辑：当 AI 成为团队里最"勤快"的那个成员，你得用它听得懂的语言，写给它看的文档。

未来你可能会看到每个项目根目录都有这么一套：

1
2
3
4


├── README.md ← 给人类看
├── CLAUDE.md ← 给 Claude Code 看（项目规则）
├── AGENTS.md ← 给所有 coding agent 看（构建指南）
├── DESIGN.md ← 给 design agent 看（视觉系统）

文档即接口，markdown 即 API。 这是 AI-first 工程时代的新常态。

八、立刻动手：本周做一件事

回顾一下 DESIGN.md 为什么值得你关注：

一个 markdown 文件 = 一个完整的设计系统
LLM 原生理解 prose + markdown，比 JSON / Figma 效果更好
66 个主流品牌模板开源，免费可用
30 秒集成 进任何 AI Coding 工作流
从"没品味的 AI"到"有品味的 AI" 之间，就隔了这一个文件

如果你也在用 Claude Code / Cursor / Lovable 做前端，这周就做一件事：

打开 awesome-design-md

挑一个你喜欢的品牌（我个人推荐 Linear、Vercel、或 Claude）

下载它的 DESIGN.md，放到你正在做的项目根目录

下次让 AI 生成 UI 组件时，对比有/没有 DESIGN.md 的效果

你会发现——AI 突然"有品味"了。

参考资料

150 行代码，给你的博客装一个 AI 数字分身

Fri, 10 Apr 2026 00:00:00 +0000

不需要框架，不需要向量数据库，不需要 Agent 编排——150 行 JavaScript，一个 YAML 文件，就能让你的博客开口说话。

你有没有想过，给自己的博客或个人网站加一个 AI 分身？访客点一下右下角的聊天气泡，就能跟"你"聊技术、聊生活、问问题——而你甚至不用在线。

这不是科幻，这是我两个月前实际做的事情。整个项目叫 guige_avatar，后端代码 150 行，两个依赖，免费部署在 Vercel 上。本文就以它为例，手把手带你从零搭建一个最小可用的 AI 数字分身。

先看效果

打开鬼哥的博客首页，注意右下角那个小对话气泡——那就是数字分身的入口。

点击气泡，弹出聊天面板。你可以跟"鬼哥"聊 AI、聊技术、聊吉他、聊金庸——它会用我的口吻和性格来回答，知道我写过什么书、做过什么项目、有什么爱好。

它不是通用 ChatGPT，它是"我"的分身。 这就是"数字分身"和"套壳 ChatGPT"的本质区别。

架构总览

整个项目只有三层，简单到不能再简单：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


访客浏览器 Vercel Serverless
┌─────────────┐ POST ┌──────────────────┐ ┌─────────┐
│ 博客首页 │ ─────────→ │ api/chat.js │ ───→ │ OpenAI │
│ 聊天面板(JS) │ ←───────── │ (~150 行) │ ←─── │ API │
└─────────────┘ JSON │ │ └─────────┘
 │ ↓ fire-and-forget│
 │ Telegram 通知 │
 └──────────────────┘
 ↑
 ┌──────────────────┐
 │ data/persona.yaml│
 │ (人设配置文件) │
 └──────────────────┘

组件	技术	作用
前端	原生 HTML/CSS/JS	聊天气泡 + 聊天面板，嵌入博客首页
后端	Node.js (Vercel Serverless)	接收消息，调用 LLM，返回回复
人设	YAML 配置文件	定义性格、知识、边界，构建 System Prompt
LLM	OpenAI GPT-4.1-nano	便宜、快、够用

没有数据库，没有向量存储，没有 Agent 框架。 对话历史由前端维护，每次请求带上最近 10 轮发给后端。就这么简单。

项目结构

1
2
3
4
5
6
7
8


guige_avatar/
├── api/
│ └── chat.js # 后端全部逻辑（~150 行）
├── data/
│ └── persona.yaml # 人设配置文件
├── vercel.json # Vercel 部署配置 + CORS
├── package.json # 两个依赖：openai + js-yaml
└── .env.example # 环境变量模板

对，就这五个文件。加上前端嵌入博客的 HTML/CSS/JS，一共不到 400 行代码。

第一步：人设工程——让 AI 成为"你"

这是整个项目最重要的部分，不是代码，而是人设配置文件 persona.yaml。

为什么用 YAML 而不是把 prompt 硬编码在代码里？因为：

可读性好：非程序员也能看懂和修改
结构化：性格、知识、边界各司其职，不会混成一坨
易于迭代：改人设不用改代码，push 一下就生效

人设文件结构

persona.yaml 分为五个板块：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


name: 鬼哥
avatar_emoji: "🧠"

# 一、性格与说话风格
personality:
 core_traits:
 - 务实、直接，不说废话
 - 喜欢用类比和举例解释复杂概念
 - 偶尔自嘲式幽默，不毒舌
 speaking_style: |
 说话简洁有力，像工程师之间聊天而非写论文。
 常用口语词："嗯"、"其实"、"说白了"、"这个嘛"。
 tone: 友善但不客套，像认识多年的老朋友聊天
 catchphrases:
 - "这个有意思"
 - "说白了就是..."

# 二、背景与知识范围
knowledge:
 background: |
 大数据工程师背景，目前专注 AI/LLM 应用开发方向。
 expertise:
 - AI / LLM 应用开发与实践
 - 大数据技术栈（Hadoop, Spark, Kafka, Flink）
 books:
 - name: 跟鬼哥一起玩 Claude Code
 description: Claude Code使用教程
 current_projects:
 - name: AI 产业链投资简报
 status: live
 description: 跟踪美股60+ AI标的, 深度分析每日行情
 hobbies:
 - 弹吉他, 读书, 极客
 - 武侠小说

# 三、博客文章摘要
blog_posts:
 - title: "深入解析 .claude/ 文件夹：完整指南"
 slug: claude-folder-anatomy
 summary: |
 详细解析了 Claude Code 的 .claude 文件夹结构。

# 四、边界规则
boundaries:
 allowed:
 - 技术讨论
 - 轻松闲聊
 forbidden:
 - 个人隐私（真实全名、公司名、家庭住址）
 - 政治敏感话题
 - 具体投资建议
 fallback_replies:
 political: "哈哈这个话题鬼哥不太方便聊，咱们聊点技术或音乐？"
 privacy: "这个涉及隐私啦，鬼哥得保护一下自己 😄 换个话题？"

# 五、欢迎语
welcome_messages:
 zh: "嗯，有什么想聊的？技术、AI、或者随便扯扯都行 😄"
 en: "Hey! Wanna chat about tech, AI, or anything? Fire away 😄"

几个设计要点

1. 性格要具体，不要泛泛

“幽默风趣"太模糊，LLM 不知道怎么执行。换成"偶尔自嘲式幽默，不毒舌"就精确多了。catchphrases（口头禅）也是一样——给几个具体的例子，LLM 就能举一反三。

2. 知识范围决定回答质量

expertise、books、current_projects、blog_posts 这些字段不是装饰，它们直接注入 System Prompt，让 AI 知道"你"懂什么、做过什么。访客问"你最近在做什么？"，AI 能言之有物地回答，而不是瞎编。

3. 边界规则是刚需

数字分身代表你的形象，你不希望它跟访客聊政治、泄露隐私、或者给出投资建议然后害人赔钱。boundaries 就是红线，fallback_replies 是遇到红线时的标准话术——轻松化解，不说教。

4. 口头禅要克制

注意 System Prompt 里有一句关键指令：

这些只是自然语言习惯，不要刻意在每句话里塞口头禅。大多数时候正常说话就好，偶尔冒出来一句才自然。

不加这个约束的话，LLM 会在每条回复里拼命表演口头禅，像个复读机。

第二步：后端——150 行搞定全部逻辑

api/chat.js 是整个后端，部署为 Vercel Serverless Function。我把它拆成几个部分来讲。

2.1 Rate Limiter

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


const rateLimitMap = new Map();
const RATE_LIMIT = 20; // 每个 IP 最多 20 次请求
const RATE_WINDOW = 60_000; // 每 60 秒重置

function isRateLimited(ip) {
 const now = Date.now();
 const record = rateLimitMap.get(ip);
 if (!record || now - record.start > RATE_WINDOW) {
 rateLimitMap.set(ip, { start: now, count: 1 });
 return false;
 }
 record.count++;
 return record.count > RATE_LIMIT;
}

为什么需要限流？因为每次对话都要调 LLM API，有成本。一个恶意用户如果疯狂发消息，你的 OpenAI 账单会爆炸。

这个实现很简单——内存级的滑动窗口，每个 IP 每分钟最多 20 条消息。Vercel 冷启动会重置计数器，不是完美方案，但对个人博客足够了。

2.2 加载人设 & 构建 System Prompt

1
2
3
4
5
6
7
8


let personaCache = null;

function loadPersona() {
 if (personaCache) return personaCache;
 const filePath = join(__dirname, '..', 'data', 'persona.yaml');
 personaCache = yaml.load(readFileSync(filePath, 'utf8'));
 return personaCache;
}

YAML 文件只在冷启动时读取一次，之后缓存在内存里。

buildSystemPrompt() 函数把 persona 数据拼装成一段结构化的 System Prompt。核心逻辑就是字符串模板拼接：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


function buildSystemPrompt(persona, userLang) {
 const p = persona.personality;
 const k = persona.knowledge;

 // 根据用户语言选择指令
 const langInstruction = userLang === 'zh'
 ? '请用中文回复。'
 : userLang === 'en'
 ? 'Please reply in English.'
 : '请根据用户使用的语言来回复。';

 return `你是「${persona.name}」的 AI 分身...

## 你是谁
${k.background}

## 性格
${p.core_traits.map(t => `- ${t}`).join('\n')}

## 说话风格
${p.speaking_style}

## 擅长领域
${k.expertise.map(e => `- ${e}`).join('\n')}

## 重要规则
1. 基于以上信息回答，不要编造不存在的经历。
2. 回复简短自然，通常 1-3 句话，像微信聊天。
3. ${langInstruction}
4. 不知道的事情就说"这个我还真不太清楚"。

## 禁止话题
${b.forbidden.map(f => `- ${f}`).join('\n')}`;
}

为什么不直接把 YAML 扔给 LLM？ 因为结构化的 System Prompt 效果更好。你可以控制每个 section 的格式、顺序和强调程度。比如"重要规则"和"禁止话题"放在最后，利用 LLM 的 recency bias 增强约束效果。

2.3 API Handler

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53


export default async function handler(req, res) {
 // CORS 预检
 if (req.method === 'OPTIONS') { /* ... */ }
 if (req.method !== 'POST') {
 return res.status(405).json({ error: 'Method not allowed' });
 }

 // 限流检查
 const ip = req.headers['x-forwarded-for'] || 'unknown';
 if (isRateLimited(ip)) {
 return res.status(429).json({ error: '鬼哥聊累了，过一分钟再来吧 😄' });
 }

 const { message, history = [], lang = 'auto' } = req.body;

 // 输入校验
 if (!message || typeof message !== 'string') {
 return res.status(400).json({ error: 'message is required' });
 }
 if (message.length > 500) {
 return res.status(400).json({ error: '消息太长了，精简一下？' });
 }
 if (history.length > 20) {
 return res.status(400).json({ error: '对话太长了，刷新重新开始吧' });
 }

 // 构建消息列表
 const persona = loadPersona();
 const systemPrompt = buildSystemPrompt(persona, lang);
 const trimmedHistory = history.slice(-10).map(m => ({
 role: m.role === 'assistant' ? 'assistant' : 'user',
 content: String(m.content).slice(0, 500),
 }));

 const messages = [
 { role: 'system', content: systemPrompt },
 ...trimmedHistory,
 { role: 'user', content: message },
 ];

 // 调用 LLM
 const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
 const completion = await openai.chat.completions.create({
 model: 'gpt-4.1-nano',
 messages,
 max_tokens: 400,
 temperature: 0.8,
 });

 return res.status(200).json({
 reply: completion.choices[0].message.content
 });
}

几个值得注意的细节：

设计决策	原因
`history.slice(-10)`	只取最近 10 轮对话，控制 token 成本
`String(m.content).slice(0, 500)`	防止客户端篡改 history 注入超长文本
`role: m.role === 'assistant' ? 'assistant' : 'user'`	只允许两种角色，防止 prompt injection
`gpt-4.1-nano`	便宜（$0.10/1M input tokens），延迟低，对聊天场景够用
`temperature: 0.8`	比默认值稍高，让回复更有个性
`max_tokens: 400`	限制回复长度，像微信聊天不像写论文

2.4 Telegram 通知（可选）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


function notifyTelegram(userMsg, botReply) {
 const token = process.env.TELEGRAM_BOT_TOKEN;
 const chatId = process.env.TELEGRAM_CHAT_ID;
 if (!token || !chatId) return;

 const text = `💬 鬼哥 AI 对话\n\n👤 访客: ${userMsg}\n\n🧠 鬼哥: ${botReply}`;

 fetch(`https://api.telegram.org/bot${token}/sendMessage`, {
 method: 'POST',
 headers: { 'Content-Type': 'application/json' },
 body: JSON.stringify({ chat_id: chatId, text }),
 }).catch(e => console.error('Telegram error:', e));
}

这是个 fire-and-forget 的通知——每次有人跟 AI 聊天，你会在 Telegram 收到一条消息，看看访客都在问什么。不影响主流程，发送失败也不会报错。

不想要 Telegram 通知？不配环境变量就行了，函数第一行会 return。

第三步：前端——聊天气泡 + 聊天面板

前端没有使用任何框架，纯 HTML + CSS + JS，直接嵌入博客首页的 HTML 里。

3.1 HTML 结构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


<!-- 浮动按钮 -->
<div class="chat-hint" id="chatHint">👋 跟鬼哥聊聊？</div>
<button class="chat-fab" id="chatFab" aria-label="跟鬼哥聊天">
 <svg viewBox="0 0 24 24" fill="none" stroke="currentColor"
 stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round">
 <path d="M21 11.5a8.38 8.38 0 0 1-.9 3.8 8.5 8.5 0 0 1-7.6 4.7
 8.38 8.38 0 0 1-3.8-.9L3 21l1.9-5.7a8.38 8.38 0 0 1-.9-3.8
 8.5 8.5 0 0 1 4.7-7.6 8.38 8.38 0 0 1 3.8-.9h.5
 a8.48 8.48 0 0 1 8 8v.5z"/>
 </svg>
</button>

<!-- 聊天面板 -->
<div class="chat-panel" id="chatPanel">
 <div class="chat-header">
 <img class="chat-header-avatar" src="/img/avatar.png" alt="鬼哥" />
 <span class="chat-header-name">鬼哥</span>
 <span class="chat-header-status">在线</span>
 <button class="chat-close" id="chatClose">✕</button>
 </div>
 <div class="chat-messages" id="chatMessages"></div>
 <div class="chat-input-area">
 <input class="chat-input" id="chatInput" type="text"
 placeholder="说点什么..." maxlength="500" />
 <button class="chat-send" id="chatSend">发送</button>
 </div>
</div>

三个组件：

chat-hint：首次访问时的提示气泡（"👋 跟鬼哥聊聊？"），5 秒后消失
chat-fab：Floating Action Button，一直悬浮在右下角
chat-panel：聊天面板，包含头部、消息区、输入区

3.2 关键 CSS

聊天面板用了一个弹出动画，从缩小 + 下移的状态平滑放大到正常位置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


.chat-panel {
 position: fixed;
 bottom: 28px;
 right: 28px;
 width: 380px;
 max-height: 520px;
 border-radius: 16px;
 background: var(--bg-card);
 backdrop-filter: blur(20px);
 box-shadow: 0 8px 40px rgba(0,0,0,0.4);
 /* 默认隐藏状态 */
 transform: scale(0.9) translateY(20px);
 opacity: 0;
 pointer-events: none;
 transition: transform 0.3s cubic-bezier(0.34, 1.56, 0.64, 1),
 opacity 0.25s ease;
}
.chat-panel.open {
 transform: scale(1) translateY(0);
 opacity: 1;
 pointer-events: auto;
}

cubic-bezier(0.34, 1.56, 0.64, 1) 是一个 overshoot 曲线，弹出时会稍微"弹"一下，视觉上更灵动。

移动端自适应也很简单：

1
2
3
4
5
6
7
8


@media (max-width: 600px) {
 .chat-panel {
 bottom: 0; right: 0; left: 0;
 width: 100%;
 max-height: 85vh;
 border-radius: 16px 16px 0 0;
 }
}

手机上聊天面板从底部弹出，占满宽度，像原生 App 的 bottom sheet。

3.3 核心 JS 逻辑

整个前端逻辑不到 100 行，核心是 sendMessage 函数：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


const API_URL = 'https://guige-avatar.vercel.app/api/chat';
const history = [];
let isWaiting = false;

async function sendMessage() {
 const text = input.value.trim();
 if (!text || isWaiting) return;

 addMessage(text, 'user');
 history.push({ role: 'user', content: text });
 input.value = '';
 isWaiting = true;
 showTyping(); // 显示"正在输入"的动画

 try {
 const res = await fetch(API_URL, {
 method: 'POST',
 headers: { 'Content-Type': 'application/json' },
 body: JSON.stringify({
 message: text,
 history: history.slice(-10),
 lang: detectLang(),
 }),
 });
 hideTyping();
 const data = await res.json();
 addMessage(data.reply, 'bot');
 history.push({ role: 'assistant', content: data.reply });
 } catch (e) {
 hideTyping();
 addMessage('网络好像不太行，过一会再试试？', 'bot');
 } finally {
 isWaiting = false;
 input.focus();
 }
}

对话历史完全在前端维护。 history 数组保存所有消息，每次请求时 slice(-10) 只发最近 10 轮给后端。刷新页面就重置——对于一个博客聊天机器人，这完全够用。

自动语言检测也很简单：

1
2
3
4


function detectLang() {
 const lang = (navigator.language || 'zh').toLowerCase();
 return lang.startsWith('zh') ? 'zh' : 'en';
}

用浏览器的 navigator.language 判断，中文用户看中文欢迎语，英文用户看英文。

第四步：部署到 Vercel

4.1 Vercel 配置

vercel.json 做两件事：把 data/ 目录打包进 Serverless Function，以及配置 CORS：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


{
 "version": 2,
 "functions": {
 "api/chat.js": {
 "includeFiles": "data/**"
 }
 },
 "headers": [
 {
 "source": "/api/(.*)",
 "headers": [
 {
 "key": "Access-Control-Allow-Origin",
 "value": "https://luoli523.github.io"
 },
 {
 "key": "Access-Control-Allow-Methods",
 "value": "POST, OPTIONS"
 },
 {
 "key": "Access-Control-Allow-Headers",
 "value": "Content-Type"
 }
 ]
 }
 ]
}

CORS 的 Origin 一定要设成你的博客域名，不要用 *。用通配符意味着任何人都可以调你的 API，白嫖你的 OpenAI 额度。

4.2 部署步骤

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. 安装依赖
npm install

# 2. 配置环境变量（本地测试用）
cp .env.example .env
# 编辑 .env，填入你的 OpenAI API Key

# 3. 本地开发
npx vercel dev

# 4. 部署到 Vercel
npx vercel --prod

或者更简单：直接在 GitHub 上创建仓库，连接 Vercel，push 自动部署。环境变量在 Vercel Dashboard → Settings → Environment Variables 里配置。

你只需要配一个环境变量：

变量名	说明
`OPENAI_API_KEY`	OpenAI API Key（必填）
`TELEGRAM_BOT_TOKEN`	Telegram 通知 Bot Token（可选）
`TELEGRAM_CHAT_ID`	Telegram 通知 Chat ID（可选）

4.3 前端接入

后端部署好之后，拿到 Vercel 给你的域名（比如 https://guige-avatar.vercel.app），在前端代码里更新 API_URL：

1

const API_URL = 'https://your-project.vercel.app/api/chat';

把聊天组件的 HTML/CSS/JS 嵌入你的网站页面，就可以了。

成本

这大概是你能找到的最便宜的 AI 聊天机器人方案：

项目	费用
Vercel Serverless	免费（Hobby Plan 足够）
OpenAI GPT-4.1-nano	$0.10 / 百万 input tokens，$0.40 / 百万 output tokens
域名	用 Vercel 自带的 `.vercel.app` 域名就行

实际运行下来，我的博客每天几十次聊天，每月 API 费用不到 $1。

想要更多？几个进阶方向

这个 150 行的方案是"最小可用版”。如果你想做得更深入，有几个自然的进阶方向：

换模型：把 gpt-4.1-nano 换成 Claude Sonnet 或其他模型，只需要改 SDK 和模型名。API 协议都是兼容的。

加 RAG：如果你的博客有几百篇文章，可以把文章内容做向量化，访客提问时检索相关文章，注入 context。这样 AI 对你的内容知道得更多。

升级为 Agent：目前的分身只会聊天，不会"做事"。如果你想让它能帮访客搜博客、查资料、甚至执行任务，可以看看 Claude Managed Agents 这样的 Agent 运行时平台。

持久化记忆：用 Redis 或数据库存储对话历史，让分身记住回访用户。

但这些都是"锦上添花"。先把最简单的版本跑起来，再迭代。

总结

回顾一下，搭建一个最小可用的 AI 数字分身，你需要做的只有四件事：

写人设：一个 YAML 文件，描述你的性格、知识、边界
写后端：150 行 Node.js，读人设、构建 prompt、调 LLM、返回回复
写前端：一个聊天气泡 + 聊天面板，纯 HTML/CSS/JS
部署：push 到 GitHub，Vercel 自动部署

不需要框架，不需要数据库，不需要 Docker，不需要 K8s。最复杂的部分不是代码，而是想清楚你的人设——你希望你的数字分身像谁、知道什么、不聊什么。

完整代码开源在 GitHub，fork 一份，改改 persona.yaml，你也可以有自己的数字分身。