构建 AI 数字分身
这段时间一直在折腾 AI 自动化。
我比较理想的状态，是以后很多事情都不用我盯着。任务扔进去以后，AI 自己分析、执行、检查、继续往下跑，最好一天 24 小时都可以工作。我只看最后的结果，或者偶尔处理真正需要我的事情。
但真做起来以后，很快会碰到一个问题。
现在的 AI 已经能处理很多执行层面的事情，但工作流跑到一些关键节点时，还是会停下来等人做决定。
比如技术方案到底选哪个，一个结果是不是已经达到可以上线的程度，两个方案各有优缺点时应该牺牲什么，某个设计放在当前业务里到底合不合适。
这些事情往往又不是单纯“模型能力不够”。
AI 可以把两个方案分析得很详细，但最后为什么选 A 不选 B，很多时候依赖的是领域知识、过去踩过的坑，以及一些很难完整写进 Prompt 里的判断习惯。
结果就是，我虽然做了一套自动化工作流，但只要中间有几个这样的决策点，人还是得一直在。
这个问题如果不解决，所谓 7×24 小时自动运行其实很难成立。
所以我后来开始想，能不能把“我”也变成工作流里的一个组件。
不是复制一个会模仿我说话的聊天机器人，而是让 AI 知道一些我过去是怎么做判断的、有哪些经验、在什么情况下会倾向于什么方案。以后自动化流程遇到原来需要叫我过来确认的地方，可以先让这个数字分身介入。
它不一定每次都能完全代替我，但如果原来十次需要我处理的事情，最后只有两三次真的需要把我叫过来，这套自动化系统就已经完全不一样了。
这就是我最近开始做 AI Twin 的原因。
我手里其实已经有不少材料。博客写了很多年，Obsidian 里有上万篇笔记，今年跟 Codex、ZCode、Claude Code 之类工具的对话更是一大堆。
问题只是以前这些东西都是给人看的，或者干脆只是随手记下来，从来没有认真想过怎么把它们变成 AI 可以长期使用的东西。
这次就先从博客开始。
先拿公开博客试
一开始没有直接碰整个 Obsidian。
里面私人资料、转载、随手摘录太多，第一次就处理它感觉事情会变得非常复杂。博客至少是公开的，而且大部分确实是我自己写的，适合先把流程跑起来。
发布清单里有 325 篇文章。经过内容哈希和隐私检查以后，这轮实际处理了 295 篇。
我在项目里把这部分叫作 Reverse Personality Compiler，反向人格编译器。
名字比较大，实际并没有训练什么模型。
大致就是让 AI 读以前的文章，从里面找出一些关于我的信息，然后整理成 Hermes 可以使用的内容。
最早做的时候我犯了一个很明显的错误。
当时只读了几篇文章，就已经开始往后做测试了。
后来发现提取出来的东西非常偏。因为那几篇正好基本都是 AI 工程相关的文章，所以最后得到的“我”自然也是围绕那几个话题打转。
这显然不是什么人格，只是采样有问题。
后面才把公开博客的覆盖范围扩大。
还有一个问题是，不能直接把一堆文章丢给模型，然后问：
“Leo 是什么样的人？”
我试下来觉得这种做法非常危险。
模型很喜欢总结。只要给它一些零散材料，它就能非常自信地归纳出一套完整的人设，但里面哪些真的是长期特征，哪些只是某篇文章当时的上下文，很难分清。
后来改成先不做人格总结，而是提取非常具体的陈述。
项目里叫 claim。
比如我在 2019 年一篇 Demo 文章里写过一句：
由于只是临时用一下，所以代码就写得比较随意了。
如果直接让模型总结，很容易变成：
Leo 对代码规范要求不高。
但这已经不是原来的意思了。
真正可以留下来的应该类似：
2019 年底，在写临时 Demo 脚本时，可以接受代码写得比较随意，不追求完整规范。
“临时 Demo”这个条件不能丢。
否则几年后 Hermes 在一个正式项目里引用这条经验，说按照我的习惯代码随便写写就可以，那就有点搞笑了。
所以现在每一条 claim 都会把原文一起留下来，包括来源、时间、适用范围和当前审核状态。
引用也会做校验，确保那句话真的在原文件里，而不是模型自己改写以后又把它当成原文。
这一批的语义提取主要还是 AI 编程工具分批读文章、生成 JSON，本地 Python 做后面的校验、记录和编译。
仓库里也有直接调用模型做抽取的接口，不过这次不能说 295 篇文章全部都是靠那个接口自动跑出来的。这个地方我专门写清楚，是因为项目做到后面我越来越发现，“已经自动化”这种说法很容易把实际上人工参与过的地方抹掉。
后面才开始归纳
单篇文章里提出来的 claim，我没有直接塞进 SOUL.md。
因为一句话只能证明“当时在这个场景下这么想过”，还不能说明这是一个稳定习惯。
后面又做了一层跨文档归纳。
比如把不同年份里关于技术选型的内容放到一起，看看有没有重复出现的做法。
最后有一条大概是：
技术方案需要放到自己的实际场景里验证。调研和 AI 建议可以用来产生候选，但最后更倾向于通过实测或者小原型决定是否采用。
这条背后不是某一篇文章，而是不同年份里关于部署、图形性能、AI 工具选型等几件事情。
这种东西我把它叫作 pattern。
目前要求至少有两篇独立文档支持，而且不能只记录支持证据。碰到反例，也要一起留下。
有一次就碰到一个挺典型的情况。
以前一篇复盘里我说 MVC 分层有必要，另一篇讲 D3 的文章又明显不赞成为组件强套 MVC。
单看结论，像是观点变了。
回头读原文以后，其实不是。
前一篇的问题是代码完全没有分层，已经变得很难维护；后一篇是在说 MVC 这种具体模式不适合当时那个 D3 组件。
所以最后没有试图总结成“我到底支持还是反对 MVC”，两条都保留，只把各自的场景限制住。
这种地方我觉得其实比生成多少条人格描述重要。
因为真正让数字分身出问题的，经常不是“什么都不知道”，而是拿一条本来只适用于 A 的经验，跑去指导 B。
提取出来以后还得审核
所有新生成的 claim 默认都是 pending。
我后来做了一个很简单的审核页面，左边看原文，右边看 AI 提取出来的结果，然后选择批准、拒绝或者跳过。
主要就是检查有没有理解歪，范围是不是放大了，现在还适不适用。
前面的一批我基本自己看。
后面量变大以后，也让 Codex 帮忙继续审了一部分，不过记录里会区分是我批的还是代理批的。
目前公开博客和个人简介这部分，一共留下了 647 条批准的 claim。
从里面归纳出了 27 条 pattern，又整理了 8 个比较像“做事方法”的 Skill。
27 条 pattern 一共用了 135 条 claim。
还有 512 条没有被继续上升成某种“人格”，就作为普通证据留在那里。
另外有 37 篇博客从头读到尾什么也没有提取出来。
这个结果我倒觉得挺正常。
之前我其实会下意识觉得，都花钱让模型读了，总得提点什么出来。
后来觉得没必要。很多文章就是单纯在记录一件事，跟人格、长期经验都没什么关系。
有些东西其实更像方法，不像人格
做到这里以后，又发现 pattern 里面有一部分东西比较特殊。
它已经不是“我通常倾向于怎么判断”，而是一套可以直接重复执行的方法。
比如我做技术验证时，很多时候会先把范围缩得很小，做一个最小 Demo，观察几个关键指标，然后再决定要不要继续投入。
这种东西如果只是写成一句：
Leo 重视小范围技术验证。
没什么用。
所以后来干脆做成 Skill，把什么时候需要触发、要验证哪些东西、Demo 做多大、看什么结果都放进去。
个人背景和一些稳定偏好放在 USER.md。
比较稳定的思考、判断习惯放在 SOUL.md。
方法单独做 Skill。
原始证据则不直接塞进上下文，需要的时候再查。
现在回头看，这种拆法比一开始想做一个巨大的人格 Prompt 要靠谱一些。
至少不同东西不会全部搅在一起。
不过目前从博客提出来的“我”仍然非常不完整。
原因也很简单：博客里大部分写的是工作和技术。
所以它知道的更多是我在这些事情上的判断方式，生活里的很多部分根本没有数据。
做完人格以后，我才发现领域知识还是空的
这里中间还闹过一个乌龙。
有一次我问，博客和 Obsidian 里的知识是不是已经接进数字分身了。
一查发现，其实没有。
前面花了很多时间提取人格、方法、pattern，但是领域知识目录虽然已经建好，内容几乎还是空的。
这个事情让我后来重新想了一下“数字分身到底需要什么”。
假设 Hermes 已经知道，我做技术选型的时候喜欢先做小原型。
这只能解决一半问题。
真的遇到图表性能问题时，它还得知道以前试过什么方案，碰过哪些坑，不同方案的限制是什么。
这些内容可能完全体现不出什么“人格”，但对替我做决策反而非常重要。
因为我平时做很多判断，实际并不是凭某种抽象的人格原则做出来的，而是单纯因为：
这个坑以前踩过。
所以后面又从已经准入的博客里选了 15 篇可视化文章，另外整理领域经验。
这次不再关心“文章说明我是一个怎样的人”，只关心里面有没有以后还能用的东西。
目前先拆成了设计与业务、组件工程、动画排障、AI 生成几个主题。
比如以前做并购动画时，有一次还没有搞清楚用户真正需要理解什么，就已经开始做设计了。
这个是踩坑。
另外一篇笔记里又记录过关系图、桑基图等几个可能的方案。
这个只是候选。
两个信息都可以留下，但不能整理着整理着，最后变成：
并购关系应该使用桑基图。
这是我现在特别警惕的一类错误。
Obsidian 现在其实只处理了一点点
Obsidian 比博客麻烦很多。
博客至少大部分都是我自己写的。
Obsidian 里面除了自己的笔记，还有很多摘录、网页内容、别人的文章、AI 整理结果。
一段话出现在我的 Vault 里，完全不能证明这是我的观点。
所以这一轮很保守，只拿了 9 篇明确标成 public 的笔记做实验。
最后整理出了 LLM Wiki 和 Agent 上下文工程两个主题。
引用别人的地方继续保留作者和来源，不会因为它进了我的 Obsidian，就自动变成“Leo 认为”。
之前系统有一次告诉我“Obsidian 已处理”。
我当时以为至少已经接了一大批进去。
后来继续追问才发现，就是这 9 篇。
一个上万篇笔记的 Vault，目前实际上只处理了九篇。
所以现在不太想继续走“先把整个 Vault 全部整理完”这条路线。
成本很高，而且很可能没有必要。
我现在更倾向于把真正高频、重要的主题提前整理，其余东西以后通过检索按需读取。
目前 Hermes 还没有直接访问整个 Vault。
团队资料也开始接进来
另外一个很有价值的来源是团队资料。
很多真正有用的技术信息，其实不会写到博客里。
技术方案、组件设计、线上问题、项目复盘，这里面有很多非常具体的经验。
这次也已经抽了一部分技术经验出来，放进领域知识。
内部资料和整理结果都还是放在本地受控目录，不会进入公开知识库。
这里有个问题之前没太注意，后面处理的时候才发现必须严格控制：
团队经验不能自动变成“我的经验”。
比如某个问题是同事解决的，我参与过讨论，最后文档又正好挂在我负责的项目下面。
数字分身以后当然可以参考这个案例，但它不能回答：
我以前遇到过这个问题，当时我是这么解决的。
比较准确的说法应该只是：
团队之前有一个类似案例，当时这样处理过。
否则数据越吃越多，过几年这个 AI Twin 的个人履历可能会比我本人精彩很多。
内容最后都放哪
项目做到一半的时候，我还折腾过一次存储结构。
最开始想的是：
AI Twin 存一套。
Hermes 运行环境再放一套。
另外建个 Git 仓库专门归档。
后来越看越觉得麻烦。
三份东西存在以后，最先出的问题不是技术问题，而是我自己会忘记哪份才是真的。
改一次以后是不是还要同步另外两份？
Hermes 自己运行时改了文件怎么办？
仓库里那份又是什么角色？
所以最后把这个方向砍掉了。
现在 AI Twin 是唯一的内容维护入口。
人格、领域知识、经验都在这里管理。
Hermes 里的那些文件只看成编译或者部署后的结果，不在那里长期维护第二份。
之前已经做出来的旧归档还没有完全迁完，不过不会继续沿着原来的方向扩。
存储方式目前也挺朴素，就是 Markdown、分层目录、索引，再加几个本地查询程序。
向量数据库之前讨论过很多次，目前还没上。
我倒不是觉得以后一定不用，而是现在最大的问题根本不是“几万篇资料检索速度够不够快”。
现在连 Hermes 会不会主动去查正确的东西都还没有完全解决。
这个阶段先上向量数据库，有点太早。
文件还有个好处，就是我随时能直接进去看。
到底存了什么，改了什么，Git diff 一眼就知道。
比较尴尬的是，文件准备好了，Hermes 不一定会用
这也是我做到后面才发现的问题。
当时已经有 647 条 claim 了。
不过真正直接进入 USER.md 和 SOUL.md 的只有 29 条具体陈述和 27 条 pattern。
8 个 Skill 也都已经放好了。
然后我拿十道题做了一次盲测。
结果十个会话，一次工具调用都没有。
也就是说 Skill 虽然在那里，Hermes 完全没有去读正文。
这个结果其实比测出来回答不准更有用。
因为之前我潜意识里已经把：
Skill 已安装
理解成了：
Hermes 已经具备这些能力。
实际上完全不是一回事。
后面才又补了一个历史证据查询入口。
需要的时候可以直接查 AI Twin，返回相关 claim、原话、时间和来源。
后来拿两个真实问题试了一下，都可以正确找到东西。其中有一次我甚至没告诉它应该使用哪个 Skill，它自己触发了检索。
所以目前至少这条链路算是能工作了。
领域知识的路由还比较一般。
问题说得特别明确，比如“看看我公开博客里以前关于可视化的经验”，基本能找对。
换成平时真正会问的自然说法，有时候它还是会跑到其他可视化 Skill。
这个还得继续测。
至于像不像我，现在还很一般
第一轮做过一次十道题的测试。
我自己先回答，然后让 Hermes 在不知道我答案的情况下回答，再让 Codex 从思路、取舍和表达几个方面比较。
最后内部评分是 35/60。
因为事前没有设一个正式的通过标准，所以这个数字看看就行。
但差异还是挺明显。
最明显的一条是它太能写。
单题回答长度比的中位数是 8.1。
同一个问题，我可能几句话结束，它能写八倍。
有些题只是说得比我啰嗦，判断本身差不多。
有几道则连方向都有区别。
不过这批测试是在证据检索功能加进去之前做的，所以现在也不能说明最新版本就是这个水平。
旧题也不准备继续反复刷。
看过答案以后再测，意义已经不大了。
后面会重新出一批没见过的问题。
下一块准备处理 AI 对话
现在我反而最期待这一部分。
博客有个问题，它基本都是事情结束以后写的。
很多真正做决定的过程不会出现在博客里。
为什么第一次方案我不同意，AI 漏掉了哪个条件，第二版为什么还是不行，最后又是因为什么改成了第三种方案。
这些东西今年大量存在于 Codex、ZCode、Claude Code 的对话里。
尤其是我纠正 AI 的消息，我感觉价值可能比最后生成的总结大很多。
因为“我同意了什么”不一定能看出多少东西，“我为什么不同意”通常信息密度高得多。
不过对话数据也挺脏。
我的消息里面会有整段粘贴进来的文档、别的 AI 的回答、系统规则，还有非常多：
“好的。”
“继续。”
“再查一下。”
这种消息显然没有多少提取价值。
另外对话会分叉、迁移、复制，同样一段内容可能重复好几遍。
所以目前打算不再按“消息”提取，而是按一次完整决策提取。
比如一次技术选型，最后整理出来的应该是：
当时具体要解决什么问题，有什么现实限制，考虑过哪些方案，我否掉了什么，为什么否掉，最后选了什么，以及后来有没有实际结果。
如果只有当时的选择，没有后来发生什么，也就停在那里，不去替过去补一个“最终证明选择正确”。
现在只完成了本地数据源盘点，还没有正式开始全量处理。
准备先拿几个边界比较清晰的真实任务做测试。
如果这部分最后能跑通，我觉得它对于前面那个目标会比单纯的人格提取更重要。
因为真正想解决的，还是最开始那个问题：
以后我的 AI 工作流运行到某个需要经验判断的节点时，它能不能不用第一时间来找我。
先去看看我以前碰到类似问题时怎么考虑，知道我有哪些习惯、哪些经验、踩过哪些坑，然后自己把大部分普通决策继续往下做。
实在没有把握，再把我叫进来。
如果最终能把人的介入从“工作流里的必要节点”变成“少数异常情况的兜底”，那这套 AI Twin 对我来说才算真的有价值。