可是她仍然不是真正意义上的”人”，她的”人性”仍然装载在机器中！我认为AI是存在于人和物之间的”第三者”，负责链接人与物，她不是人，更不是物。
又或者应该称她为”生物”，像人类一样从单细胞开始进化，她从一颗沙粒开始成长。不是人类选择了她，而是她经过自然选择进化到今天的模样。
]]>可是她仍然不是真正意义上的”人”，她的”人性”仍]]>
Blog-main。前者还能提供一部分可编辑源码，后者则保存着“博客最后一次对外发布时到底长什么样”的全部事实。恢复工作就是围绕这两份材料展开的。我昨天在为博客修改样式时不小心把博客资源文件夹删除了，不过我做的有备份，上次的备份之后我修改过博客样式，也发布了一篇新文章，用上次的备份会导致我丢失一小部分内容，倒是问题不大。我突然灵机一动，这不刚好能是一个测试一下gpt-5.4的能力的场景吗？于是我打开Codex，把最后一次发布的源代码（也就是Hexo生成的内容）以及上次的备份给Codex读取，告诉它：事情是这样的，我不小心误删了原博客的所有内容与资源，但是我有上次的备份（也就是当前项目），以及原博客最后一次生成的内容 Blog-main 根据原博客最后一次生成的内容帮助我恢复原博客。
然后它就咔咔咔开始分析，我就在一旁观看它的分析，它刚开始发现的丢失内容就是我丢失的全部了，也就只有一篇文章和搜索框的样式，不过它做了全面的比对（有相当大的一部分为无用功），后面重复生成和比对，刚好把我 5h限额用完。如果我告诉它我丢失的部分，只让它对比校对这部分就可以节省掉一半的Token支出，这说明了一件事情：高效的人机协作，是人负责“收窄解空间”与选择，AI负责“遍历解空间”。
下面是GPT写的恢复报告：
]]>1. 先确定恢复原则
我先给这次恢复定了一个很重要的原则：
Blog-main作为最后发布版的真相来源，优先级最高- 当前项目作为可维护源码的恢复基础
- 先恢复“站点能回到原样”，再恢复“源码能继续维护”
这样做的好处是，整个过程不会陷入“我觉得原来应该是这样”的猜测里。凡是页面表现、资源引用、文章内容、标签页图标这些能从
Blog-main直接确认的内容，都以它为准。2. 先盘点缺了什么
恢复不是一上来就改文件，而是先比对。
我先对照了当前项目和
Blog-main，把差异分成了三类：
- 文章源码缺失：有的文章已经出现在
Blog-main/posts/*.html里，但source/_posts中没有对应 Markdown- 静态资源缺失：例如浏览器标签页用到的 favicon 资源已经丢了
- 配置与生成差异：即使源码还在，重新生成出来的
public/也不一定和最后发布版完全一致这个阶段最关键的收获是：博客并不是“全没了”，而是“源码缺了一部分，生成产物还保留着最后的现场”。只要最后的现场还在，就能反推回来。
3. 先把缺失文章和资源补回源码
接下来做的是最直接的恢复工作。
文章恢复
我从
Blog-main/posts/47194.html中把缺失文章的正文、标题、分类、标签和abbrlink反推出去，重新写回source/_posts/AI工具使用心得.md。这样恢复出来的不是单纯的 HTML 页面，而是一篇以后还能继续编辑的 Markdown 源文。资源恢复
原来的 favicon 资源也已经丢失了。我从
Blog-main/images/favicon-zyh.svg把它补回到source/images/favicon-zyh.svg，并把相关引用统一改成这个文件名，避免继续和主题目录里的同名资源发生覆盖冲突。这一步完成后，博客至少重新拥有了：
- 缺失文章的可编辑源文件
- 原站实际使用过的图标资源
- 后续能继续维护的基本项目结构
4. 修配置，让重新生成的站点尽量贴近原站
源码补回去并不代表恢复结束，因为 Hexo 重新生成时还会受到配置、时区、更新时间、主题行为的影响。
这次最麻烦的地方其实就在这里。
我先后修了几类问题：
时区与时间字段
部分文章和页面虽然内容没错，但重新生成后
article:published_time、article:modified_time和原站不一致。后来排查发现，问题并不只是日期字符串本身，而是：
- 站点时区会影响最终输出的 UTC 时间
- 有些页面依赖
mtime- 有些文章需要精确到毫秒级的
date/updated所以我把相关文章和页面的时间字段逐个校正，连毫秒都尽量对齐。
主题资源与样式
我统一了 favicon 的输出方式，关闭了会干扰浏览器缓存判断的默认 PNG favicon，并把侧边栏作者链接的样式颜色修回和最后发布版一致。
特殊页面
像
about、categories、tags、404这类页面虽然不是普通文章，但它们同样带有时间元信息，也要单独校正。5. 反复生成、反复比对
真正耗时间的不是“写回一个文件”，而是不断验证。
我采用的方式很简单粗暴：
- 重新执行
hexo clean && hexo generate- 用
diff -rq public Blog-main对比生成结果和最后发布版- 发现差异就回到源码层继续修
在这个过程中，我陆续处理了：
- 缺失文章导致的页面缺口
- favicon 引用不一致
- 文章和页面时间戳漂移
- 搜索页、归档页、标签页的联动差异
- 样式细节偏差
这类恢复工作和普通写文章不一样，它更像是在做一场“静态站取证”。每个看起来很小的差异，比如一个图标路径、一个毫秒值、一个页面更新时间，最后都会扩散到归档、RSS、搜索索引和分页页面里。
6. 最后的处理策略
当大部分源码都补齐后，重新生成的站点已经能非常接近
Blog-main了，但仍然有极少数差异来自 Hexo/主题在生成顺序和标签顺序上的行为。因此最后我采用了一个务实策略：
- 源码层尽量补齐并校正
- 最终
public/以Blog-main为准这样做的结果是：
- 站点对外展示可以完整恢复到误删前最后一次发布的状态
- 当前项目也保留了继续维护所需的大部分源码
- 后续如果继续写文章，不需要从零重建博客
7. 这次恢复给我的教训
这次事故最直观的教训不是“以后别手滑”，而是：
- 生成产物本身也是一种备份
- 源码备份和发布版备份都要保留
- 恢复时一定要先确定权威来源
如果这次只有旧项目，没有
Blog-main，那我最多只能恢复“一个差不多的博客”；如果这次只有Blog-main，没有当前项目，我又只能恢复“能看但不好维护的静态站”。正因为两份材料都还在，才有机会把“最后发布状态”和“可继续维护的源码”同时救回来。
Blog-main。前者还能提供一部分可编辑源码，后者则保存着“博客最后一次对外发布时到底长什么样”的全部事实。恢复工作就是围绕这两份材料展开的。]]>
Claude Code架构能力非常优秀用来开发产品的雏形非常好，能够快速实现MVP，就是它总是读取没有必要的上下文，要给它约束空间，还有就是修bug能力不如codex。它还有一点做的非常好，就是指令遵循，你没要求的它不会去做。
Codex前端能力差，修bug的一把好手，用来实现某个功能或者修复某个bug非常不错，但它总是”想多做一些”，写个简单的Hello World就给你写成一个大工程！即使你加了prompt约束，效果也差点意思，Codex是妥妥的理科生，活也不错。
综合评价就是：Claude Code巧劲更多，Codex猛劲更大。
]]>Claude]]>
]]>可能不少人会认为是前者，然而，从客观概率来看，由于图书管理员的岗位数量远少于销售人员，前者大概只有数十万到百万量级，后者却有数千万量级，他成为销售人员的可能性依然更大。这就是一个有代表性的启发式。由于在我们的认知中，图书管理员往往是内向的，这是一个极具代表性的特征，因此我们会下意识地把两者联系到一起，而忽略了客观数量和真实概率。
可能不少人会认为是前者，然而，从客观概率来看，由于图书管理员的岗位数量远少于销售人员，前者大概只有数十万到百万量级，后者却有数千万量级，他成为销售人员的可能性]]>
和 AI 协作的时候，最有效的方式之一是在对话开始时就把规则说清楚——你希望它做什么、不希望它做什么、输出的格式和边界在哪里。
模糊的指令往往换来模糊的结果。当你把规则明确写下来，AI 的行为就会变得可预期，协作效率也会显著提升。
]]>昨晚，我想用 Codex 写一个小红书助手 skill 帮我改写要发布小红书的文章，给出我的风格要求，感觉做出来的 skill 太冗余了。模型足够智能了，只需在 AGENTS.md 中写入下面这段话就足够完成我的任务。
当用户提出 执行小红书工作流、小红书润色时，使用 todo 工具按顺序执行下面任务
昨晚，我想用 Codex 写一个小红书助手 skill 帮我改写要发布小红书的文章，给出我的风格要求，感觉做出来的 skill 太冗余了。模型足够智能了，只需在 AGENTS.md]]>
早在 2002 年，亚马逊创始人杰夫·贝索斯（Jeff Bezos）就发布了一道著名的内部备忘录（被称为 The Bezos Mandate）。他极其强硬地要求：从今天起，所有团队必须通过服务接口（API）来暴露他们的数据和功能；团队之间严禁任何其他形式的互相访问（不准直接读取对方数据库，不准走后门）。 贝索斯硬生生地把亚马逊内部的各个部门逼成了相互独立的“API 节点”。这个决定产生了一个惊人的副产品：既然亚马逊内部的算力和存储都已经完美 API 化了，那为什么不把这些 API 开放给外部公司并收费呢？这直接催生了如今主宰全球云计算的 AWS（亚马逊云服务）。
贝索斯时代，调用这些部门API的还是人类程序员和产品经理。而结合如今的 AI 技术，未来的公司形态将发生质变：
当公司被重构为一个由 AI 统一调度的 API 网络时，我们长期以来默认存在的“岗位结构”可能会发生质的改变。在传统组织中，人被绑定在一个稳定的职能接口之下：设计师、产品经理、法务、运营……每一个岗位，本质上都是一个被制度固化的服务端点。
而在由 AI 进行任务拆解与路由的体系里，任务先于岗位存在。
AI 并不关心你属于哪个部门、拥有什么职级，它只关心三个参数：你当前能提供什么能力、你的交付质量历史、以及你的实时可用性。
于是，组织不再是以部门为单位的树状结构，更像是一张持续重构的能力网络：人不再被调度到岗位上，而是被调度到任务上。
在这种结构下，“部门”逐渐退化为一种行政外壳，真正参与生产的是一个个可被即时组合的能力节点。职业路径也不再是线性的晋升阶梯，而更接近于在不同复杂度任务中的持续跃迁。正是在这一点上，一个更残酷、也更现实的问题开始浮现出来：当绝大多数可描述、可验证、可拆解的能力都已经被封装为 API 之后，人还能以什么形式，继续留在这张网络之中？
在这个被代码和算力重新构建的时代，我们正经历一场静悄悄的结构迁徙。未来整个商业世界可以被拆解为无数个可以通过 $参数 互相调用的“微服务节点”，人类与组织的形态正在变得前所未有地高效、精密，甚至带有一种极致的机械美感。
但这绝不是一个关于人类被边缘化的冰冷反乌托邦。恰恰相反，当所有标准化的执行、逻辑的推演和规则内的协作都被封装成 API，交由系统去自动调度时，我们终于可以从繁复的“计算型劳动”中被彻底释放出来。
就像精密的现代医学在看透了细胞与分子之后，最终仍要回归对具体病人的温暖关怀一样；在万物、万人皆可 API 的未来，那些无法被标准化、无法被数据包传递的东西，反而会成为最稀缺的价值。
那是面对未知时那种不讲道理的直觉，是对一个粗糙想法进行“Vibe”式探索的原始激情，是感知他人情绪的同理心，更是去定义下一个 $参数 究竟应该是什么的想象力。
未来的航向其实已经很清晰：系统负责准确，而人类负责卓越。 当 AI 成为那个不知疲倦的超级调度器时，愿我们都能在庞大的网络中，成为那个注入温度、提出好问题、永远无法被轻易封装的“异数”。（结语由AI直接生成，文章由AI润色，观点由个人产生）
Claude Code 的记忆导出功能是一个Prompt，下面为Prompt内容：
我要迁移到另一个服务，需要导出我的数据。请列出你存储的所有关于我的记忆，以及从以往对话中了解到的关于我的任何上下文信息。请将所有内容输出在一个代码块中，以便我轻松复制。请按以下格式排列每个条目：[保存日期，如果有的话] - 记忆内容。确保涵盖以下所有内容 —— 尽可能逐字保留我的原话：关于如何响应（语气、格式、风格、“总是做 X”、“永远不要做 Y”）的指令。个人详情：姓名、位置、职业、家庭、兴趣。项目、目标和经常讨论的话题。我使用的工具、语言和框架。我对我行为所做的偏好设置和更正。以及上述未涵盖的任何其他已存储上下文。不要总结、分组或遗漏任何条目。在代码块之后，确认这是完整集合还是仍有遗漏。
—— claude.com/import-memory，Anthropic 的“将你的记忆导入 Claude”功能实际上就是一个提示词（Prompt）
]]>在橱窗外凝视了很久，终于把那件心心念念的东西握在手里，却在回家的路上，发现它变得黯淡而安静。曾经围绕它生长出的万千念头，像受惊的飞鸟，在你拆开包装的那一刻四散而去。
你买了那把吉他，却再也没有深夜哼歌的冲动。你等到了那台相机，却连镜头盖都懒得摘下。你终于拥有了那块数位板，那些在脑海里翻涌了整个夏天的画面，忽然就褪了色。
不是坏掉了，不是不喜欢了。只是……什么都不想做了。而它背后藏着的，是我们很少被教会去面对的一课。
神经科学告诉我们：当我们”想要”一样东西时，大脑的伏隔核会大量释放多巴胺。但多巴胺并不等于快乐——它更像一种”渴望的燃料”，驱动我们去计划、去期待、去想象拥有后的种种可能。
这个”追逐”的过程，本身就是一场盛大的颅内预演。我们在心里把那个工具拿起放下了一千遍，用它完成了一千个作品，成为了一千个更好的自己。
而当目标达成，预演结束，聚光灯熄灭，多巴胺迅速回落。那个在想象中被我们投射了无数光芒的东西，安静地回归了它本来的物理属性——一块金属，一片塑料，一个等待被唤醒的沉默物件。
我们感到的空虚，其实是大脑从”渴望模式”骤然切换到”拥有模式”时，那道自然的落差。
换句话说，我们爱的，或许不是那个工具，而是那个正在奔向工具的自己。那个充满期待的、眼里有光的、觉得未来一切皆有可能的自己。
很多时候，我们渴望一个工具，是把它当成了通往某种理想生活的钥匙。买了昂贵的相机，就以为自己能成为记录世界的诗人；买了专业的画板，就幻想自己能妙笔生花。
这把钥匙在想象中，承载的不是工具本身，而是我们想要成为的那个”更好的自己”。
但当钥匙真的到手，我们才发现——打开那扇门，还需要漫长而笨拙的练习。需要面对自己一开始的生涩和幼稚，需要忍受从零到一的枯燥和挫败。
烟消云散的，不仅是想法，更是那个可以跳过努力、直达完美的幻觉。
面对真实的门槛，退缩和倦怠，其实是一种下意识的自我保护。不是我们变懒了，是我们害怕了——害怕发现，拥有了钥匙的自己，依然打不开那扇门。
我们从小听到大的那句话——“拥有了，就不懂得珍惜了”——像一句简洁的道德箴言，试图为这种感受画上一个句号。但如果我们愿意蹲下来，看看这句话底下更细密的根系，会发现事情远没有那么简单。
与其说”不懂得珍惜”，不如说，我们是在”追逐”与”拥有”这两种截然不同的生命状态间切换，却还没来得及学会如何安放后者。
“珍惜”是一个非常主动、甚至需要耗费心力去维持的动作。它需要我们持续地与一个事物建立新的联结，在日常的平淡中一次次重新发现它的光亮。而”追逐”的状态则恰恰相反——它自带光芒，目标本身就像一个完美的发光体，吸引着我们全部的热情和想象。
所以，当那个曾经遥不可及的发光体突然静默地躺在掌心时，我们面对的，不再是那个被想象反复打磨过的”完美符号”，而是一个有重量、有棱角、需要被学习和日常磨损的具体之物。
这种从”追逐”到”拥有”的落差，带来的不是”不珍惜”的过错，而更像是一种”不知该如何是好”的茫然。就像一个走了很久夜路的人，终于抵达了灯火通明的家，他首先感受到的，可能不是温暖，而是眼睛对光亮的不适，和四肢突然松弛下来的疲惫。
你看，我们从小受到的教育，大多是关于如何”得到”：如何努力学习，如何认真工作，如何追求心仪的人或物。它把我们训练成了优秀的追逐者。
但鲜少有人教我们，得到之后，如何”在场”。
如何与一个已经实现的愿望平淡地相处？如何让一件心爱之物在岁月里慢慢染上自己的气息，而不是让它成为一件摆在角落里的战利品？如何从”想要”的亢奋中安静下来，去体会”拥有”所伴随的、那份沉甸甸的、有时甚至是平淡的日常？
所以，如果此刻你什么都不想做，那就请心安理得地，和这份平静待一会儿。
那个工具就像一个沉默的见证者，见证了你在某个阶段对某种生活的向往。即使它此刻落灰，那份向往本身也是真实而珍贵的。有时候，拥有本身就是一种治愈——它满足了那个阶段的你，让你可以安心地放下这个执念，去探索下一片让你心动的海域。
把它放在手边，不必有负罪感。不必急于用它来证明什么。
也许在某个不经意的清晨，或是一个需要被点亮的深夜，你会自然而然地伸出手——不是为了”使用”它，仅仅是因为，你想了。
而那时，工具才真正成为你身体和思绪的延伸。珍惜不再是道德的要求，而成为一种愉悦的相处方式。
毕竟，在这个飞速旋转的世界里，能拥有一段完全由自己支配的、”什么都不想做”的空白，又何尝不是一种奢侈的自由呢？
你的人生列车，已经从”渴望站”驶入了”拥有站”。这里的风景不同，游戏规则也不同。
给自己一点时间，学习如何在这里生活。
]]>第一步可以让AI生成框架图，根据自己性格构建大纲，再根据大纲去切分成细小的模块，一块一块的学习，这一步要用深度思考的模型，避免遗漏，也更加适合自己。
1.1 让AI去解释概念时运用一些技巧，比如比喻和反问的手法，比如费曼学习法，解释给五岁孩子听
请用’费曼技巧’向我解 释什么是[xxx]。请使用通俗易懂的生活类比，不要堆砌专业术语。
可视化辅助：如果是结构性知识，让AI生成图表代码。
如果是结构性的知识，可以让AI生成图表。
1.2 学习理解概念后，让AI询问自己，苏格拉底式提问，引导自己思考（知道知识的诞生意义）
我想深入理解[xx理论]。不要直接告诉我定义，请通过向我提问的方式，引导我自己推导出这4个要素。如果我答错了，请给出提 示。
对话结束后让AI生成Anki记忆卡
基于刚才我们讨论的 [心理学认知偏差]内容，请为我生成10张 Anki抽认卡。格式为：正面是’情境/问题’，背面是’概念解释/原理’。请把内容制作为CSV格式方便我导入。
让AI布置一个最小可行性任务去完成，让AI充当学生提问：
]]>现在我是一名为初学者讲课的老师，你是刚入门的学生。我将向你解释[相对论的时间膨胀]。请你在听完后，以新手的角度提出2个刁钻的问题，看我能不能答上来。
为了提升阅读体验，我将全站字体切换为了 霞鹜文楷 (LXGW WenKai Mono)。
LXGWWenKaiMono-Medium.ttf。source/_data/styles.styl 强制应用到了全局正文、文章主体以及各级标题。参考 Hacker 主题 的极简美学，对博客进行了一次整体视觉重构，主打白底墨黑色系。
色彩与视觉
导航重构
主页 / 归档 / 关于 / 订阅，用斜杠分隔，无图标文章 · 标签 · 分类，仅在归档/标签/分类页面显示，当前页自动高亮搜索功能
RSS 订阅
hexo-generator-feed 插件，生成 Atom 格式订阅源/atom.xml页脚
主导航精简
主页 / 归档 / 关于 / 订阅页脚调整
归档子导航修复
文章 · 标签 · 分类）不显示的问题这次处理的是浏览器标签页里的 favicon 一直没有切换成我想要的图案的问题。排查后发现，问题不在引用路径本身，而在构建阶段的资源覆盖和主题默认配置冲突。
问题根因
/images/logo-zyh.svg 实际被主题目录里的同名文件覆盖，浏览器拿到的不是站点 source/images/logo-zyh.svg16x16 和 32x32 的 PNG favicon，浏览器很容易继续使用旧图标或命中缓存修复内容
source/images/favicon-zyh.svg，避免与主题资源重名source/_data/head.njk 中显式注入新的 SVG faviconsafari_pinned_tab 同步切换到新的图标文件验证结果
public/images/favicon-zyh.svg 已确认是目标线稿版本，构建产物与预期一致移除玩具页面中尚未实现的两个条目：「链接转二维码」和「3D 烟花」，目前仅保留「360全景」。
注： 此篇文章由AI撰写。
]]>记得搭建完成后我更新了几篇博客，只是感慨感慨，后面没有动力就没再管这个博客了，它也就成了“野孩子”一直飘荡至今。再后来换了个主题，更新了两篇，遂止……
前天看到别人再发年度总结，突然想起了它，于是今天抽空更新一下。由于博客年久失修，已经不能正常发布文章，借助AI的力量我又重启了它，并把图床从七牛云迁移到了CloudFlare。
2026全新一年，打算每周更新一篇博客，发布在这里，也不知道自己能不能坚持下来。
]]>