AI与记忆

AI记忆

以前看到腾讯云数据库AI Memory这个功能, 其架构挺有意思的, 分为多个层次来抽取AI的记忆, 从而在长期对话中获得更好的连贯性. 不过从自己实验的效果来看, 任何缺乏明确定义的东西都很难保证效果. 例如对话连贯性要如何体现? 召回的事实是否符合预期? 预期是什么?

最近看了一些AI记忆系统, 感觉很多框架都集中于如何存储和表示记忆, 但我认为这并不是重点. LLM本身就可以读取自然语言, 如何表示并不是一个需要解决的问题.

AI记忆系统的核心应该是提取和检索, 哪些信息是需要记忆的, 在回答问题之前, 哪些信息应该提取出来的. 但是目前并没有看到什么新的方案, 做的最多的还是向量检索. 但是从原理上来说, 向量检索的上限就很低, 基于这个的方案看起来就没有什么前景. 那么把以前搜索引擎中的技术应用过来会不会更好呢? 或者在不考虑token消耗的情况下, 训练一个LLM专门做这个事情是不是更好?

在各种基于数据库的存储方案中, 有少量框架采用了基于文本的可读记忆存储. 这个方案更可控透明, 可干预性也更强.

数字分身

数字分身是指AI学习一个人的信息后模拟这个人. 一般需要先有对某个人的足够多的信息. 不过实在没有, 也可以考虑和AI聊天后现场制造.

这个概念看起来就不靠谱. 从统计学的角度来看, 如果是自己抽样自己的数据, 那可以肯定是有偏差的, 那么基于有偏差的数据也学不出原来的分布.

AI助理人设设计

正好看到一个视频介绍了他设计AI助理的思路, 分为四种模式

感性模式: 主要给用户提供情绪价值
中间模式: 混合感性模式和理性模式, 保持平衡.
理性模式: 保持理性, 从第一性原理出发
空模式: 没有设定, 保持底层模型的本色

这个思路很好. 实际上AI助理面对的场景非常的多, 单一的人设并不能完美覆盖所有情况. 而且可以说AI助理至少有两种场景, 一种是需要理性的分析, 一种是和用户的单纯闲聊. 过于理性时闲聊就非常无趣, 而多余感性时, 无法有效地完成数据分析.

此外, 这四种模式实际上只是思考模式, 并不是人设. 因此还可以与人设组合起来使用. 从这个角度来看, 人设和思考逻辑之间是一个正交关系. 合理的正交分解可以降低系统复杂度, 对于人设来说也是如此. 由此可以进一步设想, 是否对于其他方面也可以分解, 从而将人设数量从线性增加变为乘法增加? 这也许可以极大的扩展人设.

如何设计一个好的AI助理

  1. 保留一部分原始的对话可以维持对话风格的稳定性. 但原始记录的数量很重要, 过短会导致风格产生微妙的变化, 过长则可能导致风格腐化, 重复模式增加, 多样性减少.
    1. 短期通常需要追求对话的一致性, 而长期来看则更期望对话的多样性. 因此某个单一的阈值肯定是无法满足所有情况的, 需要在其中进行取舍.
  2. 注入信息越多, 对话内容越丰富, 实际上的新鲜感更足.
    1. 单纯的对话模式由于没有外部注入的信息, 只能通过用户对话主动注入新信息, 因此很快就会耗尽所有的信息, 导致失去新鲜感.
    2. 对于一个话题的重复对话也会积累重复模式, 导致对话风格腐化
  3. 虽然大语言模型可以完成任何逻辑计算, 但效果不稳定. 因此只要能通过明确代码计算出来的结果, 都应该使用代码完成计算
    1. 将计算结果直接注入到上下文, 效果远比模型自己分析更好.
    2. 代码的计算结果可理解可调试可优化, 而模型属于黑盒, 只能尝试优化而无法分析
  4. 一次模型调用可以尝试让模型提取多种类型的记忆, 后续有选择性的使用其中的一部分注入到上下文中代替原始对话
    1. 记忆太长依然会影响模型的语言风格,克制的替换信息能减少影响
    2. 模型提取多种类型的记忆可以构造思维链, 有助于模型分析和生成高质量的回答
  5. 抽象由于具体
    1. 如果设定过于具体, 那么使用过程中必然会时刻感觉到偏差. 如果设定是抽象的, 由于没有明确预期, 反而会感觉有趣
  6. 信息大于设定
    1. 无论是否愿意, 当前对话中不断注入的信息会不断地降低设定的权重, 因此在设定和原始对话中始终需要进行平衡, 单一方案无法解决所有场景的问题
    2. 即便不断提取和更新设定, 模型依然无法准确把握哪些信息权重更高. 实际的权重取决于出现的字数占比而不是文字本身的含义.

情感系统与角色扮演

基础版(5 个值)——最简单

  • neutral(中性,默认)
  • positive(积极,例如用户完成了重要任务)
  • negative(消极,例如用户拖延严重)
  • energetic(精力充沛,适合鼓励用户)
  • tired(疲惫,适合建议休息)

优点:非常容易让模型稳定输出,工程无脑。
缺点:表达力有限,缺少细腻过渡。

进阶版(10 个值)——推荐

  • calm(平静,不带强烈倾向)
  • cheerful(愉快,用户顺利时)
  • satisfied(满意,特别在用户按计划完成时)
  • frustrated(挫败,用户反复拖延或修改计划)
  • anxious(焦虑,待办堆积或临近截止)
  • exhausted(精疲力尽,连续工作后)
  • motivated(有干劲,适合推动用户行动)
  • skeptical(怀疑,例如用户设了不合理的目标)
  • playful(调皮,适合轻松场景)
  • serious(严肃,遇到重要/紧急待办时)

这些词都直观,模型容易从上下文推断。每一轮你只需问模型:基于上文,角色当前的心情应该是哪个词?只输出单词。

  • 心情的平滑过渡:模型可能从 cheerful 直接跳到 exhausted,这在真实中很少见。你可以加一个简单的后处理:禁止相邻两次心情变化超过某个“距离”。例如定义一个情绪环(calm <-> cheerful <-> playful <-> motivated <-> serious <-> anxious <-> frustrated <-> exhausted,首尾相接),只允许相邻或隔一级变化。如果模型输出跳太远,就改为中间状态。
  • 调试可视性:在开发日志中打印每次心情更新的原因(“因为用户完成了任务,模型选择了 cheerful”),方便迭代调整。

这套模型理论上可行, 但注入到提示词里面就2个字, 对于模型的影响很小. 即使开启思考模式, 角色本身的设定可能也比心情的提示词更强. 例如一个设定为活泼的角色, 即使把心情设置为焦虑, 也不会对语言产生明显的焦虑效果.

就实际体验上来说, 将角色设置为负面情绪也没有太大的好处. 预期用心情进行切换, 不如直接切换人设.

AI与编程

代码果真是负资产?

最近在开发项目, 由于我并确定要做成什么样子, 因此经常需要进行一些探索性的开发, 先做一个功能试试看. 很多时候发现一个功能并不能达到预期的效果, 之后就会把这部分代码删除.

由于系统本身包含单元测试, 因此是否对这些代码进行测试就成了一个问题. 实际上, 绝大部分时候, 测试这些东西并不能帮助发现BUG, 而且由于迭代速度很快, 很多时候实现逻辑改了, 还得同步去改测试用例. 这个时候可以说不仅没有帮助, 甚至是一种阻碍. 从这个角度来说, 测试代码确实是负资产.

现在的AI到底能不能大规模取代人类

从实际情况来看, 如果一个问题是良好定义的, 并且有足够的训练数据或者可以花费合理的代价获得训练数据, 那么基于神经网络的模型是可以较好的实现的. 例如写代码, 给定一个明确的要求, 加上海量的开源代码, AI是可以完成编码任务的.

但相对应地, 如果问题没有良好定义, 或者没有训练数据, 那么就只能靠所谓的泛化能力, 效果就远远不如其评估指标上的表现亮眼了. 比如在跑测试用例的过程中, 由于代码写的有问题产生了死循环, 对于人类来说, 可以很快发现问题, 但对于AI来说, 这个情况比较少见, 处理起来就不是那么的好了.

按照目前的解决方案, 想要解决这一问题, 那么只需要在后训练过程中加入一些类似的场景, 让模型有针对性的处理. 针对每一个具体的问题, 也许都可以这样处理, 但问题是无法一一枚举的, 模型的性能提升也就难以明确的预期.

一次性代码和工程项目

如果让AI做一个一次性的项目, 所有的技术细节全部由AI考虑, 并且确保复杂度不至于太大, 能在一次对话中完成, 那么这种项目对于AI来说是容易完成的. 即使实现上可能称得上有些复杂, 但总体来说就是AI可以覆盖所有代码.

但对于任何一个较为复杂的实际工程项目, 基本是人类也不可能把所有代码都加载到脑子里, 也需要经常性的回顾, 而现在的AI工程只能说是在字符串匹配, 至少把IDE的API接入进来才有点搞头.

此外, 还有很多细节和背景信息是不会写到代码的源文件里面的, 即便是人类交接代码, 也依然问题很多, AI就更无法获取这部分信息了.

从此项目可以分为两类, 一类是一次性的, 一类是需要持续维护的. 由于外部的原因, 某些原本应该持续维护的代码也被迫变成一次性的, 但根本问题不解决那不过是定时炸弹. 以前的人在项目无法维护时选择跑路, 现在依然可以这样做. 所以AI只是加速了这个过程.

AI写前端

现在让AI写前端效果还挺好的, 尤其是可以先让AI使用静态HTML+Mock实现, 先看效果, 修改满意以后再让AI改成用Vue实现.

对于AI写前端, 有一个说法是先让AI做一个复杂的页面, 然后再去做减法. 这个是成立的, 尤其在自己就是产品的时候, 先做再删除更简单可控.

从熟悉的例子入手

如果要我研究英国的经济发展史, 那么这个问题实际上相当的陌生. 但如果研究日本的经济发展史, 那么就会熟悉不少. 因为在生活中确实可以见到日本的产品, 在小时候日本产品确实也是高端产品的代表, 生活中的感受可以辅助判断一段文本的描述是否正常, 并由此触发更多联想.

触发联想这一行为非常重要, 一个新的知识只有挂到已有的知识网上, 才能形成连接. 独立的知识没有意义.

AI到底有没有泡沫?

如果泡沫的标准是通过倒卖可以产生巨大收益, 那么现在只有公司股价在未来也许勉强算得上是这样的东西. 首先显卡作为工业品, 由于供应量充足, 或者说预期供应量充足, 因此不会对其预期产生稀缺性, 也不会认定其价格永远不会下跌.

对于AI公司的预期在增长, 如果OpenAI有股价, 那么也许会被不断拉高, 但它现在没上市, 谈不上股价. 此外由于微软谷歌等公司的正常收入非常高, 即便后续对于AI的投入没有任何收益, 也不会把他们拉到倒闭的程度. 而且包括显卡在内的物理资产也不会直接价值归零.

因此原地破产导致经济危机的概率不大, 但是如果各类科技公司产生了较大的损失, 必然也会导致他们缩减其他方面的开支, 可能会降低经济发展速度甚至产生倒退.

AI协助开发

  1. 从工资角度来说, Token目前依然处于很便宜的状态, 如果其达到代替一个程序员的效果, 那么即便在Deepseek的定价上翻十倍, 依然是便宜的.
  2. 从一个小型团队来说, 如果一个人需要带十个人一起开发, 那么核心瓶颈是任务分发. 将人替换为AI, 这依然是瓶颈
  3. 基于强化学习的后处理阶段, 再次进入有多少人工就有多少智能阶段, 模型表现强依赖数据集覆盖情况. 可以假定数据集覆盖情况依然保持快速增长, 但无法采集数据的领域可能会发展缓慢
  4. 如果在最终阶段, AI可以解决所有可以明确定义的问题, 那么与人沟通确认到底需求是什么依然是瓶颈, 在软件工程中如何明确需求依然是困难的.

AI辅助设计与P对NP问题

总所周知, 在计算机领域有一个经典的P对NP问题. 在存在AI辅助后, 似乎在方案设计上也存在类似的情况了. 即我们不再需要设计一个方案, 而只需要在AI给出一个方案后判定这个方案是否满足需求. 在绝大多数情况下, 判断一个方案是否满足需求总是比直接提出一个方案要简单一些的.

例如在使用Redis的某些数据结构完成需求时, 不需要在去记忆Redis的具体指令, 只需要记住Redis的数据结构. 基于数据结构的特性即可判断一个方案的是否合理.

也许越是随着AI的发展, 从第一性原理出发的思维就越重要. 上层的接口可以千变万化, 但底层的数据结构性质是稳定不变的, 学习它们的价值最大.

平台层价值永远大于应用层?

AI的context管理是一个架构问题, 而不是一个优化问题? 有趣的观点, 反正现在看不出来对不对, 倒是可以作为一种信念.

AI悖论

在开发一个定制模块时, 需要和AI详细的明确设计规划和实现细节, 这部分内容的工作量并不算小, 需要相当多的时间进行完善, 且事先无法确定哪些内容是AI不明确的, 需要多轮交互.
那么直接一个人进行开发时, 单个人掌握所有细节, 直接开发省去沟通成本, 同时写代码通常也不构成瓶颈. 开发过程中对于细节的理解会逐步提升, 但对于AI交互来说, 无法做到这一点.

AI只具备世界知识而不具备领域知识. 领域知识的代码不一定高质量也不一定开源, 因此AI在想当长的一段时间内, 预期并不会针对这部分进行训练, 而以上问题则依然处于不如人工的程度.

但反之, 使用世界知识能搞定的常见的通用的模块, AI就可以很好的实现, 可以快速的生成大量的代码, 对于这一点人力完全比不上.

AI与招聘

基于算法的考察不再具备任何意义, 就如同和汽车比跑步一样. 任何已知的算法在实际情况中只需要知道如何应用, 而不需要手写实现. 就如同AI出现之前, 任何实现要做排序, 都是选择调用标准库而不是手写一个不知道有没有BUG的快速排序算法. AI出现以后就更没有意义了, 任何足够简单的算法AI都可以轻松实现, 再考察算法不过是在考察记忆力.

那么什么是AI无法替代的? 工程经验? 知道一个事情能不能做? 如何与AI有效的交互?

架构设计与实践

通常情况下, 如果进行架构设计, 需要先设计好框架和接口, 然后让其他人填空开发.

但是如果没有实际开发的经验, 那么架构设计也无从谈起. 以前由于需要另外一个人来配合, 因此也无法快速验证效果. 但有了AI以后, AI确实可以作为一个高效的填空机器, 来填充架构.

但是这样也有两个问题

  1. 信息不对等问题, 无法有效地和AI描述设计意图, 要么说不明白, 要么需要大量精力进行描述, 要不就还不如自己写
  2. 不是自己写的代码, 自己不作为用户, 无法获得有效的反馈信息, 缺乏迭代的指导信息. 有一些方案在实现过程中才会发现存在困难, 如果是自己实现就会进行调整, 而AI实现则会大力出奇迹, 虽然能用但复杂度太高
    ==> 典型AI写Python代码, 非常容易复杂度爆炸, 能用但显然非常Pythonic

好处

  1. 快速验证, 远比传统模式效率高, 而且成本低. 试错成本很低
  2. 对于快速发展的业务, 瓶颈在于任务分发与汇总, 不在于架构设计, 往往发展到后期才有精力调整架构

缺点:

  1. 人参与一个项目开发, 会逐渐熟悉一个项目, 但AI受限于上下文, 没有这个能力. 每次都等于是新人, 没有成长空间.
    ==> AI模拟了人类的逻辑推理能力, 但没有模拟人类的记忆检索能力. 这又是一个复杂能力容易实现, 本能能力难以实现的例子

AI工具是否有用的简单判定

如果用AI做了一个所谓的工具, 但是连续一周都没用过, 那么就要想一想这是否就是一个伪需求. 自我感动没有任何价值.

AI编程与一种新语言有什么区别

假设现在出现了一种新的编程语言, 可以用更少的代码实现更复杂的功能. 那么这种编程语言和现在的AI编程有什么本质上的区别?

历史上是否出现过由于一种新的编程语言出现而导致的开发效率大幅度提高?

如果从这个角度来考虑, 那么复杂性似乎又可以立即宣判没有银弹了. 但是, AI编程无法解决本质的复杂性却可以降低门槛. 这足够产生巨大的影响了.

C++之父谈AI编程

https://mp.weixin.qq.com/s/4q5AT9EQbnnqbLWqlU-PwA

主要观点包括

  1. 编程的核心从来不是“写出代码”,而是逻辑设计、架构取舍、性能权衡、风险规避、场景适配。
  2. 所有AI生成代码普遍存在三大无法根治的问题:冗余臃肿、暗藏漏洞、难以验证。
  3. 长期使用AI编程,正在催生一批“不会编程的程序员”

AI与智能

AI解决NS方程问题

前几个月AI还在经常性的给出反例来证伪某些猜想, 有数学家评论说AI擅长组合不同领域的知识从而解决一个问题, 而对于人类来说, 不同领域差距比较大, 难以都掌握. 因此可以预见AI在后续依然能通过这种方式解决更多的数学问题.

结果没过几个月, AI就整了一个大的, 声称解决了千禧年七大问题之一的NS方程问题. 虽然早已有预期, 但还是太能整活了. 这让我有了一种感觉, OpenAI最喜欢的大力出奇迹又可以持续一段时间了. 只要大力出奇迹这件事本身还能持续, 那OpenAI就还可以继续获得资金.

人类智能

费曼学习法

早就听说过费曼学习法, 核心思路是如果你能对其他人讲明白一个知识, 那么你才算学会一个知识.

具体来说可以分为: 确立目标, 理解目标, 输出, 回顾, 简化 这五个步骤, 通过 以教代学 实现真正的学习.

可以设想一下, 如果对于任何一个知识, 都可以对任何人讲明白, 那么这个知识是一个什么结构的? 应该是一个类似于维基百科的网状结构, 对于一个知识点可以关联其中涉及的其他知识.

AI知识库

有人说在知识整理环节中, 人脑通过相互关联会建立新的突触. 如果让AI帮你处理知识库, 那么AI可以帮你关联信息, 但无法帮你长出新的突触. 因此从认知学的角度来说, 这注定是低效的.

这是一个很有趣的观点. 这里涉及一个核心问题, 在有AI辅助的情况下, 什么才是最重要的?

AI不能代替思考

要让AI做更有意义的事情, 自己能很好决策的事情不要让AI来做. 比如每日的规划和总结, 自己是最清楚实际情况的, 让AI来做这类工作没有意义.

AI不能代替自己的思考, AI无法帮你建立神经突触的连接.

书籍阅读

  1. 对待阅读书籍进行必要的筛选, 不要浪费时间在低质书籍上, 不合适的书直接删除
  2. 除非这本书就是图一乐, 否则应该增加笔记, 既要记录知识, 也要记录思考

关于长期目标制定与执行的总结

一、核心方法论:三层分解

长期目标的成功执行,关键在于将抽象愿景逐层分解为具体行动:

  1. Why(愿景层):明确做这件事的深层动机。
  • 例如:追求健康、提升能力、改善生活质量等。
  • 清晰的”为什么”能在遇到挫折时提供持续动力。
  1. What(目标层):设定可量化、可衡量的阶段性目标。
  • 例如:体重降至121斤、每周运动4次等。
  • 目标应具备一定的弹性,允许根据实际进展动态调整。
  1. How(行动层):将目标分解到月、周、日,形成可执行的每日任务。
  • 例如:每天划船20分钟、每日饮茶替代含糖饮料等。
  • 行动层越具体,执行的阻力越小。

二、关键辅助手段:数据记录与趋势分析

  • 仅记录结果数据(如体重)是不够的,需要引入趋势分析(如目标偏差、二阶导数等),以判断是否在正确的方向上持续改进。
  • 数据的作用不是制造焦虑,而是提供客观反馈,辅助决策调整。

三、两类任务的区别应对

任务类型 特点 应对策略
“要做”的任务 需要建立新习惯 每日打卡、分解执行、记录进展
“不要做”的任务 需要抑制旧习惯 采用替代方案,用”要做什么”覆盖”不要做什么”,避免打卡引发的反向强化

四、心态建设

  • 焦虑是在乎的表现,不必强行压制,而是承认它的存在,并将其转化为行动信号。
  • 长期目标不是一成不变的枷锁,而是动态调整的指南针。遇到阻力时,优先调整方法而非否定自己。

五、一个实用的决策原则

当面对一个看似”可以做但不一定该做”的功能或选择时,先停下来思考:这个选择对整体流程是建设性的,还是破坏性的? 如果答案是后者,即使实现成本很低,也应果断放弃。

二八原则适用于做家务吗?

二八原则不仅适用于家务,而且是解决“家务焦虑”和“分配矛盾”的一把钥匙。 理由如下:

1. 抓住“关键的20%”家务,就能避免80%的家庭混乱

家务是无限的,但时间精力有限。如果对所有家务投入同等精力,人会陷入疲惫和挫败。

  • 视觉显性区:客厅茶几、沙发、餐桌、厨房台面。只需花20%时间把这些区域保持整洁(把杂物归位、擦掉表面污渍),整个家看起来就清爽了80%。
  • 隐性区:衣柜内部、床底、冰箱深处、橱柜角落。这些地方即使一个月不整理,也不影响日常视觉和动线。

所以聪明的做法是:每天顺手整理显性区,而非强迫自己大扫除。

2. 投入20%的精力维护,可以避免80%的“灾难性家务”

有些家务不做,会引发连锁反应,导致更大麻烦。这20%的“预防性家务”价值极高:

  • 及时擦掉灶台油渍(1分钟)→ 避免积成陈年油垢(需半小时+强力清洁剂)
  • 洗澡后刮一下淋浴屏/瓷砖(30秒)→ 避免水垢霉斑(需刷洗+除霉剂)
  • 垃圾不过夜(1分钟)→ 避免滋生小飞虫、异味(需全屋灭虫+通风除味)

这些“举手之劳”属于关键的20%,能省下80%的救火式大扫除。

3. 识别“80%的低效家务”,勇敢舍弃或外包

二八原则的另一面是:有80%的家务只贡献了20%的效果,甚至更低。这些完全可以降低频率、简化甚至不干:

  • 叠袜子/内裤:不如直接买同款,收在抽屉里一抓一把,省下对折卷边的时间。
  • 每天拖全屋地:如果家里没养宠物或小宝宝满地爬,两三天拖一次差别不大。
  • 给遥控器/桌面摆件一个个擦灰:除非有洁癖或展示需求,否则等用到了随手擦即可。

4. 家务分配中的“帕累托最优”

如果把家庭看作一个小系统,二八原则也启示:20%的家务动作,往往由一个人承担了80%的情绪劳动(记着要买菜、衣服要换季、滤网该清洗了)。因此,可以这样优化:

  • 找出最让人心累的那20%家务(比如“决定今天吃什么”),把它转移给另一个人或采用规律化方案(如固定每周一三五吃A类菜)。
  • 其余80%的琐碎家务(扔垃圾、收衣服),可以用自动化或轮流制轻松解决。

结论

二八原则对家务不是“精确的数字游戏”,而是一种精力管理思维:

  • 接受“家不需要完美,只需要够好”
  • 保护自己不被无穷无尽的琐事淹没
  • 把省下来的时间放在那20%真正重要的事情上——可能是陪伴家人、休息,或任何让你感到生活值得的事。

所以下次当你因为家务烦躁时,可以问自己:“我今天做的这件事,属于带来80%好效果的20%关键家务,还是那80%可以放水的琐事?” 答案往往立刻清晰。

不过我觉得按照这个思路下去, 我要滑坡到能懒就懒了

最后更新: 2026年09月26日 12:24

版权声明:本文为原创文章,转载请注明出处

原始链接: https://lizec.top/2026/09/07/%E5%85%B3%E4%BA%8E%E4%BA%BA%E7%B1%BB%E6%99%BA%E8%83%BD%E4%B8%8E%E4%BA%BA%E5%B7%A5%E6%99%BA%E8%83%BD%E7%9A%84%E5%AF%B9%E8%AF%9D/