最近准备请育儿嫂，为了孩子安全，打算在家里装几路摄像头。
需求大概是：最好带 AI 人形/动作识别，甚至能做简单的意图判断，这样一旦有异常行为可以及时提醒。
但我又比较在意隐私，不太想把画面传到云端。如果有那种支持本地算力、可以在机身里直接跑 AI 模型，或者方便自己部署开源模型（比如接到 NAS/小主机上跑算法）的方案，也非常感兴趣。
想问问大家：
1 ）现在有没有比较成熟的本地 AI 家用摄像头推荐？
2 ）如果自己折腾开源模型，整体方案大概怎么搭比较靠谱？

rt
App Store 上周四晚被盗刷 5k+,支付通道走的是支付宝，刷到了一些不知名的 App 里
报警（已立案），投诉，Apple 官方和支付宝官方都已联系，互相踢皮球，有啥好办法能追回这笔资金啊，支付宝和 Apple 官方是不是有一方得赔偿才对，我觉得最大责任应该是支付宝？第二是 App Store ？

简介

目标

主要缓解个性化知识的生产和分发问题。以较低的成本实现效果凑合的类似一对一教练的效果。提升不同人体验人生的能力和效果。提升自我提升的效率。提升找到自己喜欢的东西的效率。

碎碎念

点子的核心部分叫心箱现象，包括后面的基本概念、搜索、推荐、实验和模仿。

心箱现象跟真正的教练比效果肯定不是特别好。不过我设计了一种机制，也许能让更多的人在一些关键技能上获得一对一的教练级的服务，在“技能裂变”那部分。

实现

系统主要的概念是现象和规律，规律将因现象和果现象关联起来。用户通过将现象与自己关联起来，获得适合自己的知识和信息。知识主要是通过规律来表达的。

例子

下一段提到的 LeetCode 主要提供编程题库和结果验证。

举个我瞎想的例子。假如用户关注了“解决问题能力为较强”并且将“大五外倾性为较低”与自己关联，那么可以向这个用户推荐“‘大五外倾性为较低’并且‘学习一门 LeetCode 支持的编程语言并在 LeetCode 上达到指定标准’并且‘学习一点泛化知识的技能’导致‘解决问题能力为较强’”这个规律。我假设编程可以锻炼人的通用的解决问题的能力了，然后再辅以一些泛化技能也许就能提高解决问题的能力了。不过好像开放性更高的人泛化能力天生就更强，所以这条规律也许可以再用开放性细化一下。规律中关联外倾性主要是因为我猜“外倾性为较高”的人可能通过解决社交问题来练习解决问题的能力效率更高、体验更好。

基本假设

• 具有相同天赋和思想的人（同类人）沟通效率会更高。
• 同类人中对一个人有效的方法对这类的人中的其他人也很可能有效。
• 某些方法的传播并不会影响传播者的利益。或者至少影响不大。或者存在少数人就是不在乎自己的利益。
• 个体的天赋和思想可以用一系列现象近似表达。

关于复杂性的狡辩

这个点子看起来非常复杂，不过我感觉它的复杂性对大部分用户来说很可能都是基本无感的。但是这个点子对内容生产者来说要求比较高。但是我觉得那部分对一般人比较难的任务可能科研人员比较擅长，特别是心理学方面的科研人员。

基本概念

现象

所谓现象，指能被人感觉到的一切情况。

下面举一些例子。现象可以是具有某种大五人格特质等级，具体比如“大五开放性为较高”。大五类似 MBTI ，不同的地方之一是科学家更愿意用它。现象也可以是使用某种方法，具体比如“掌握习得性乐观”。现象也可以是某种结果，具体比如“拖延程度为较低”。

上面的“大五开放性为较高”是现象描述，还可以添加一个现象详述的部分详细介绍现象。

这里要区分一下实际现象和表达现象。基本可以类比成本质与表象。实际现象指一个人或者一个对象实际具有某个现象，就像编程中某个属性取了特定的值。而表达现象是用户将现象录入到系统中的数据。实际现象跟表达现象不一定是完全一致的，可能受用户理解能力、量表质量、现象描述本身的模糊性影响。假定实际现象跟表达现象的一致程度是基本可接受的。本文中前面没有实际和表达的现象都是表达现象。

其实我感觉这里的现象用逻辑学上的谓词代替更好，但是谓词太不通俗了。

规律

所谓规律，指现象之间的联系。

下面举一个例子。“‘每周在保证一定心跳频率的情况下跑一定数量的公里数’并且‘每天吃一罐某种牌子的沙丁鱼罐头’并且‘没有完美主义’导致‘拖延程度为较低’”就是一个规律。实际的具体的相关的量我没写，实际的标准规律中的现象必须都是明确的。另外这只是个简短的例子，我总结的对我拖延有效的东西有二三十条。

规律一般可能没有类似现象的描述，除非是一些类似心理学效应的有名字的规律。

规律是可以形成类似一张网的结构的，具体说是超图。规律对应超边。举个抽象的例子，A 导致 B ，B 导致 C 。规律之间也可以构成更复杂的结构，甚至可能出现循环的结构，所谓的良性或恶性循环。

规律中的现象的主语可以不是用户，比如可以是规律处理的任务的特征。这个具体怎么实现我目前没有特别好的方法。我目前想到的就是一般的现象默认主语是用户。如果现象的主语不是用户，那么就给现象打一个“此现象的主语不是用户”的标签。然后现象是类似“处理的任务的难度为较低”。另外也许可以在规律中附加一下用户与那些非用户主语的关系。“处理的任务的难度为较低”的主语是用户好像也说得通？

类似上一节，规律也需要区分实际规律和表达规律。实际规律就是获得某些现象之后就会百分之百获得另外一个现象，没有任何余地。类似形式系统中的转化规则。我目前相信物质世界也是这样的，至少在宏观层面上，除非遇到递归和类似悖论之类的东西。某些表达规律做不到百分之百有效可能是因为某些影响规律生效的现象没有被发现。所以表现出无法百分之百有效。举个例子。假设 A 、B 、C 同时出现会导致 D 。再假设人群中只有 1% 的人不具有 C 。再假设 C 这个现象比较隐蔽，根本想不到。所以人们可能发现 A 、B 导致 D 这个表达规律可能具有超过 99% 的有效率。前一句可能有问题，我不细想了。说得再哲学一些，A 、B 、C 导致 D 这个基本上也算不上实际规律。因为规律本身可能也会变，再加上人类只能通过归纳获得表达规律。我听说我们的宇宙物理规律好像大规模变过，将来可能也会变。吟游诗人基德说的。我搜了一下，好像广泛承认的只有物理常数的变化。也许只是假说？不过如果能获取到导致规律改变的规律也许就能获得更准确的实际规律了，但还是逃不过归纳的问题。前一句是后加的，前面的懒得改了。我之前可能感觉改变规律需要我们的宇宙外的力量来干预。本文中前面没有实际和表达的规律都是表达规律。

因现象、果现象

一些因现象导致一些果现象。一个规律将一些因现象和一些果现象关联起来。一个规律的果现象可以是另外一个规律的因现象。

获得现象

将某个现象 A 与某个用户 B 关联起来叫做 B 获得 A ，获得强调从无到有的动作。

具有现象

某个现象 A 与某个用户 B 处于关联状态叫做 B 具有 A ，具有强调状态。

规律在用户身上有效作为用户的一个现象

这个只是逻辑上的概念，实际可能需要专门的机制来处理。逻辑和实际类似逻辑地址和物理地址。我放弃解释了。这段偏技术细节了。

类似地，某个规律在用户身上无效也可以作为一个现象。

难变现象、易变现象

难以改变的现象和易于改变的现象。难变现象比如具有人格，易变现象比如保持某种习惯。

虽然难易实际是连续的，但是为了方便设计就假设只有两个等级。

获得某个现象的难度可以用成功从不具有这个现象转化为具有这个现象的人数和所有尝试过的人数通过计算获得。这个计算方式有一些问题，比如自卑到自信和自负到自信的难度可能不同。如果考虑所有位置到某个位置的难度，那可能会更麻烦。也许可以通过记录所有人的起点和终点，然后再大致得出一个计算公式会更好一些。另外对于不同类的人来说，获得某个现象的难度可能是不一样的，考虑这个会更复杂。

现象箱子

现象箱子是保存表达现象的容器。

用户可能具有一些随机数量的表达现象。

实际为了效率每个用户可能需要设置多个现象箱子。

现象箱子可以有序。用于对一组相关的现象进行排序。比如“按喜欢程度排序的我喜欢的书”现象箱子。里面的现象就是“喜欢《集异璧》”、“喜欢《复杂》”这种现象。我在某本介绍推荐系统的书中看到说通过排序的对象进行推荐效果最好，就是很消耗服务器资源。我设计了一个方法好像可以缓解对服务器资源的消耗，但是精度不是特别高，在技术细节部分。另外这种有序的列表可能很多人都喜闻乐见，比如那个夯到拉的梗。

现象箱子一般描述的对象就是用户自己。但是描述其他东西也说的通，特别是如果某个现象箱子可以公共编辑。比如描述某个产品。这个就比较复杂了。

推荐箱子

推荐箱子可以包含现象、规律、以及一些指导语之类的东西。理想情况下最好是可以直接在展示推荐箱子的页面选择自己是否具有某个现象，而不用跳转到现象的展示页面进行操作。另外可以考虑放入其他类型的东西，比如用户和现象文档。推荐箱子可以整体进行评价。

规律反馈

规律反馈是当一个用户对某个规律感兴趣之后，在尝试这个规律的过程中记录相关信息的东西。

目前我计划使用时间段对规律中的现象进行反馈。当开始尝试获得一个因现象的时候点击现象对应的开始按钮，然后去实际尝试，尝试之后点击成功获得或者获得失败等按钮。当全部因现象都获得之后，如果果现象是偏被动现象，比如焦虑，那么生效之后就点击果现象生效开始，直到再次焦虑。这时可以检查自己是不是某些因现象意外丢掉了，可以做相应的反馈。如果因现象确实全部都具有着，但是果现象丢失了，那可能就是大问题了，可能是这个规律不适合自己。如果很多人都这样，那这个规律可能根本就无法长时间起效。如果果现象是偏主动现象，比如遇到困难任务不拖延，可以在任务开始的时候记录任务开始，然后任务结束的时候给自己的拖延程度打个分。不同规律可以有不同的反馈方式。

另外还可以对没希望进行反馈，比如尝试到一半突然就感觉没希望了。

另外尝试规律过程中产生的任何非结构化的信息用户也可以直接记录下来。这种信息可以关联到某个现象上，表示可能与某个现象有关。也可以只附加一个时间，表示不确定与哪些现象有关。具体比如自己产生的一些想法，还有就是规律中没有给出的副作用等。

整体大于部分之和

同时具有两个现象可能会出现与分别单独具有两个现象完全不同的现象。比如两个现象产生协同效应，产生比累加或者取最大值更好的结果。甚至可能出现单独具有两个现象都是坏的，但是同时具有这两个现象就有好处了。类似的有翻转效应。

甲之蜜糖乙之砒霜

不同人获得相同的能力的方式可能是不同的。

副作用

副作用也是现象。这个很要命。我的想法是尽量避免副作用的出现。或者尽量减少出现副作用的用户。目前我能想到的方法有参与模仿任务之前一定要告知用户风险。还有就是不要一下子让很多人测试获得某个规律的因现象的效果。这两个都是从心理学和医学试验中抄的。还有就是后面提到的让有能力消除副作用的人试。

绝对的果现象与改善果现象

我不太喜欢具有某些现象就能缓解某些问题对应的现象。比如健身改善拖延。相反我更喜欢因现象和果现象都是类似绝对的值的规律。比如一连串因现象能导致有 95% 的概率让人的拖延程度为较低，假设拖延程度为较低是用量表测出来的一个值的范围。

我不喜欢改善性质的规律主要是因为我觉得改善难以自动统计。另外我认为从极端拖延改善一点到基本不拖延改善一点是两个完全不同的东西。还有就是这种信息不全面的简单改善方法如果人用多了失败多了，可能会导致泄气。因为一个拖延程度极高的人可能需要具有大量的现象才能有实质性的改善。虽然看到大量的因现象可能也会泄气，但是我相信比那种因为失败过多导致的泄气会好一些。还有考虑到前面说的整体大于部分之和，让人独自去尝试各种现象的组合好像有点不负责任。因为其有一定风险，还有就是可能存在大量的失败和没有好结果。风险指好现象组合到一起可能会出现坏现象。比如两个精力消耗很大的好现象同时具有可能会消耗大量精力，导致出现强烈副作用。没有好结果指两个现象同时具有可能结果并不是相加，而是取最大值。前一句我是凭我解决问题的过程中积累的直觉说的，不一定是真的。最后就是我的偏见了，我就是感觉绝对的果现象比改善果现象更美。

但是我也不完全反对在心箱现象中存放那种改善性质的规律，不过我建议给这种规律加个标签或分类，标明这是个指引方向的规律。能搜索出来，但是不能直接尝试这个规律，也就是使用规律反馈。但是在试验阶段也许可以适当放宽一些。改善性质的规律应该被看成是一种元件，而不是解决方案。

搜索

通过一些现象搜索现象箱子

搜索过程类似通过多个标签搜索具有这些标签的内容。比如搜索出内向的并且想要提高问题解决能力的人。可以按必须包含全部现象进行搜索，也可以是包含一组现象中的任意现象。最好是能组合搜索。组合搜索就算不提供给所有用户也应该提供给有推荐权限的用户。

搜索与指定现象箱子类似的现象箱子

对于现象不多的现象箱子，可以直接搜索与这个现象箱子类似的其他用户的现象箱子。这种搜索方式主要目的是搜索出与某个人在某个方面的兴趣比较类似的人。比如按喜欢程度排序的科普书列表。搜索有序现象箱子好像没有特别好的方法，下面的技术细节部分提供了一个凑合的实现方式。

搜索规律和现象

搜索规律类似搜索现象箱子。搜索现象主要就是搜索现象描述。

搜索积分

一些搜索操作可能很消耗服务器资源，所以这些搜索也许不应该无限制提供，而是通过消耗搜索积分来执行。还有积分也许应该有个过期的机制，否则用户攒了很多积分一次全部花掉可能会影响系统可用性。搜索积分的来源我就不细说了，比如签到或者购买。

推荐

人工推荐

人工推荐可以类比成一个人发现某个对自己有用的方法，然后向别人安利这个方法的过程。这个操作是后面的试验和模仿的基础。

人工推荐的步骤一般是先通过一些现象搜索出一些现象箱子，然后再获取这些现象箱子对应的用户。然后将想要推荐的内容放入推荐箱子，然后将推荐箱子发送给这些用户。然后可以收集一些简单的反馈，比如对推荐的满意度。

注意这个人工推荐与后面的试验和模仿可能有点类似鸡和蛋的关系。试验和模仿获得的规律可能会用于人工推荐，而理解了人工推荐才能理解试验和模仿。不是标准的鸡和蛋的关系。

我之前打算自己做这个网站的时候是计划只给部分用户推荐的权限，而且也不是彻底的权限，范围特别大的推荐也需要其他人审核。如果读者有控制滥用的手段也可以不这么保守。

自动推荐

自动推荐就是目前最常见的那种推荐系统执行的推荐。我觉得自动推荐应该慎重使用，毕竟这东西好像比较不可控，还可能会造成很多问题。我对这个了解不多，我的感觉可能不准确。

试验

撰写试验申请书

主要包含试验包含的规律，以及看好这个规律的理由等。

审核团队审核试验申请书

主要是审核相关现象以及现象的组合有没有已知的风险。对于风险比较未知的现象，优先让有一定风险抵御能力的人试。风险比较未知比如全新的现象。风险抵御能力高的人比如有比较高的解决自己问题的能力的人，还有就是有一定经济基础可以雇人帮自己解决问题的人。

搜索小范围试验用户

如果规律依赖于某些现象，比如比较外向的人，那么就随机搜索出一些外向的人。如果不依赖某些现象，就直接随机搜索出一些用户。如果用户接受试验，那么就将用户加入试验用户集合。另外也许可以优先找一些对获得规律果现象比较感兴趣的人。

执行试验

执行试验之前告知已知的全部副作用。

如果小范围试验效果较好，扩大试验范围

如题。

更大的试验范围更好的话，推广到全体适合的用户

如题。

撰写试验报告

将一些难以通过规律反馈展示的数据写入报告，还有其他其他无法或难以用现存的机制表达的内容。

一定要双盲吗？

我的观点是不用，只要长期有效就行，同时没有严重副作用。甚至完全是安慰剂效应的短期有效的方法也可以用来构建长期有效的规律。比如一个方法需要长期坚持才能起效，为了让一些人坚持，可以在早期间隔用几个安慰剂效应比较强的方法，并且一直用那个长期坚持才能起效的方法。换句话说就是在使用正确的方法的同时使用不同的鸡血和鸡汤。当然这个需要欺骗，需要用户提前同意可以欺骗自己。不过这种先后执行的鸡血对规律的实现有点压力。因为可能不能一口气将所有因现象同时展示出来，否则所有鸡血的效果可能会同时失效。另外由于这种鸡血可能只能用几次，所以也许应该优先用在那些最重要的难以培养的能力的培养上。另外开发各种新奇风格的鸡血也许也很重要。另外据我所知双盲成本好像更高一些，也更复杂。

我也不是反对双盲，特别重要的规律可能还是需要双盲的。

模仿

招募模仿任务参与者

任务应该至少有一个被模仿者。这个被模仿者有一个很多人都希望具有，但是又不具有的能力。然后还应该有大量模仿者，我感觉很可能是模仿者越多发现的效率就会更高。

模仿者和被模仿者都可以主动参与或者受邀参与。

猜测导致具有某个能力的果现象的因现象

谁都可以猜，包括被模仿者、模仿者和根本就没直接参与的人。

询问被模仿者是否具有大家猜测的因现象

如果被模仿者有这个现象，就分配一些人或全部人具有这个现象。

模仿者试验因现象

模仿者会持续接收到推荐他尝试具有的因现象。一旦模仿者具有了能力对应的果现象，那么就报告给系统。理想状态应该是每试验一个现象之前都让审核团队审核一下，但是如果提前告知参与者风险的话，也许可以放开一些。也许可以做一个投票的机制给待模仿的现象进行排序。另外也可以不用所有模仿者都同步模仿票数更高的现象，也许可以分工，类似后面介绍的心箱合作。不过我怀疑这可能会导致一些问题。

数据挖掘

一旦出现了多个成功的模仿者，也许可以辅以数据挖掘发现具体是哪些因现象导致的能力对应的果现象。不过就像前面说的，甲之蜜糖乙之砒霜可能严重干扰数据挖掘的过程。

窄化现象

前面的过程很可能会得到大量无关的现象，需要一个过程筛选出实际起效的现象。

传播发现的规律

一旦发现对应的有效率比较高的因现象组合，就广泛传播对应的规律给其他用户。窄化现象的过程可以与这个过程结合起来。

步骤调度

本节上面的步骤并不是需要严格按写的顺序执行的。如何高效地调度这些步骤也许需要设计一下。

猜测因现象准的人也许很值钱

我们也许可以寻找导致具有这种能力的因现象。模仿者也许可以付钱请这种人。被模仿者当然可能也需要花钱请，毕竟具有某种很多人都想要的现象的人可能就能利用这种现象赚到很多钱，钱少了可能不屑于参与。但是我感觉被模仿者可能比较轻松，就是回答自己有没有对应的现象就行了。

如果网站上同时执行着多个模仿任务的话，如何调度这种人可能也比较重要。

招募具有猜测的难变因现象的人

如果某个猜测的因现象是难变现象，并且参与者中有这个难变现象的很少，那么可以通过搜索招募一些具有这些难变现象的人，并让他们补上之前猜测的那些现象。

部分问题的缓解方式

简介

这节前面是我的点子的核心部分心箱现象，心箱现象有很多问题，这节介绍一些我能想到的问题和我感觉也许有用的缓解的方法。

心箱量化：缓解标签化数据精度不高

标签化的数据只是搜索的时候效率会更高一些。效率主要指服务器执行的效率，不是使用的方便程度。相反量化的数据更利于相关分析，但是搜索效率会更低一些。向量数据库好像可以加速这种搜索，但是搜索结果是不精确的。

目前我认为使用类似维基数据的形式保存这种量化数据比较不错。如果能辅以向量数据库就更好了。

心箱信用：缓解信任问题

用户可以通过他人的行为来修改对其他用户在某一个方面的信任程度。具体比如因为对方的某个发言降低对对方的信任程度。至于这个行为的可见性，也许值得深思一下，我就不思考了。所有的信任关系构成一张网。如果 A 信任 B ，B 信任 C ，那么 A 有理由信任 C 。但可能会根据信任路径中的信任程度做一些衰减。还有就是允许用户设置衰减力度也许不错。衰减力度大更不信任间接的信任。

对于一个新人，他可以选择信任一些网站官方账号信任的用户，也可以自己信任一些自己的朋友，也可以信任一些综合评分比较高的用户。综合评分也许可以通过信任这个人的网络的质量来估计。

例子系统：缓解文字难以理解的问题

就是对符合现象描述的情况进行详细记录，可能还是文字多一些，但是也许可以辅以视频之类的形式。

这个东西看起来也许很傻，毕竟很多人就是喜欢干货。但是我这个点子的目的不是让人感觉懂了就完了，而是让人过好这一生，或者至少好那么一点。我相信理解有时候只是一种错觉，并不能有效指导行为。我还相信能直接通过抽象的现象学习的人不多，另外想要获得这种能力可能也需要通过大量的例子来练习。

这个系统可以做的比较复杂，但是每个现象都提供一个文字的列表应该是最基本的。复杂的比如给不同的例子打分。或者配合收集反馈，看哪些例子比较容易出问题。或者配合规律，看什么人比较容易忽视某类例子。或者做一个通过例子测试用户理解程度的系统等。

技能裂变：缓解部分技能需要手把手教学的问题

需要手把手教学才更容易学会的技能好像都存在大量的变数，而死板的文字难以覆盖所有的情况。这时候就需要一个系统来辅助这种技能的传播了。

我的想法是对于那些特别有价值的技能，让那些具有这些技能的人至少免费带两个徒弟。然后让所有学成的徒弟继续至少免费带两个徒弟。不断循环。

当然我这个方法有很多问题，我就不展开了。我就简单说一些问题和缓解手段。首先如何保证教学水平不会随着技能的裂变不断变差。这个可以通过优先向那些有一定技能教学能力的人传授。还有就是学成之后也许可以让更多人鉴定。有个不太好的东西，就是获得某个技能需要的时间越长，裂变得就越慢。我感觉除了人工智能有突破这个是无解的。就是教会了 AI ，AI 就可以基本无损地教给所有人了。现在的 AI 准确率很可能还不够。免费能否支撑这种模式的问题也许可以配合上面的心箱信用。另外这个模式一旦跟钱关联上，可能很容易跟传销勾搭上。如果付费，也许应该注意一下。还有因为掌握的人过多，导致某种技能贬值甚至是效用变低的问题。贬值的问题我感觉没什么好办法，除了可控核聚变可能没什么好的解决方法了。也许应该优先裂变那些贬值概率更低，更有用的技能。效用变低的技能也许只能不裂变了。

我目前感觉习得性乐观和反思是最值得用这种方式传播的技能。前者增加人尝试的次数，后者增加人从尝试从获得收获的能力。

身份系统：缓解为了提高满意度不敢大胆推荐

内容推荐者发出的所有推荐都关联到自己身上的话，他很可能会为了提高满意度只推荐那些迎合其他用户的东西。可能大部分内容消费者会很在意满意度，但是我相信可能存在一些愿意忍受更低的满意度的内容消费者。如果实在没有这种内容消费者的话，可以提供一些奖励，作为忍受某个内容推荐者的某个实验性质的身份推荐的内容的报酬。奖励比如搜索积分。

心箱合作：缓解合作问题

主要就是将一些能比较好地分割的任务分配给不同的人。比如如果一群大五人格类似的用户可以分工阅读一些书，然后找出对他们有用的信息来缓解拖延问题，假设大五人格会影响缓解拖延的方法的效果。当然前提是这些信息不需要太多的前置知识。比如一共找到十本相关的书，然后两人完整看同一本书，这样一共需要 20 人。不一人一本是考虑一个人看可能会看漏一些信息。如果人数更多的话，甚至可以两人完整看一章，这样速度会更快。类似地，一群音乐喜好类似的人也可以分工探索新的歌手、作曲家、乐团等。

你可能会问这跟协同过滤有什么区别。首先据说所知协同过滤数据量大了之后很消耗资源，好像只能通过 AI 获得近似的结果。我感觉我这个方法将运算量降下来不少。另外我这个方法目的性更强。最后我这个方法可能更有人味一点。我不知道为什么大厂基本都不给兴趣、目标等相似的人的相遇提供便利。我猜一是现在的用户普遍都很暴躁，难以维护社交关系。二是大厂不想让用户脱离平台去进行内容的过滤，因为这样更难掌控数据。三是这事可能比较难。我知道的唯一的有过这个功能就是网易云音乐，不过我感觉效果好像不是特别好。不知道是故意搞得很烂还是就是很难。第一点可以靠改善一部分用户的社交能力来缓解。第二点我不想解决。第三点也许有序列表能提升效果。还有就是不要奢求所有地方都与自己像的人，一个方面与自己像很可能就很不错了。最后就是本文后面介绍的削足适履了。

心箱数据：缓解现象重复和现象箱子容量有限

心箱数据类似维基数据。引用某个对象的现象可以通过心箱数据尽量防止重复。对象比如音乐、书籍。现象比如喜欢某首歌，喜欢某本书。另外由于用于描述用户在某一方面的兴趣的现象箱子不能太大，所以需要一个类似豆瓣图书和豆瓣影音的功能来进行打分等。心箱数据同时用来做这个好像不错。

如果某本非虚构类的书有多个版本，那么现象只关联到心箱数据中的对应的条目的第一版上，否则更新版本后可能需要更新所有相关现象。虚构类的书籍和影视作品不同版本可能就不能这么处理了。相同的音乐原则上只关联到最初发布的那首。不绝对是因为我遇到过一首歌曲最初发布的专辑的乐团只有一个专辑的情况。

文档系统：满足对各种文档的需求

网站的很多地方都需要文档。比如试验的申请书和报告。我打算自己实现的时候还打算用文档辅助实现网站的介绍系统。我觉得至少应该包含基本的格式、公式、表格和图表的功能。

去重系统：缓解重复推荐

我个人感觉重复推荐的体验相当不好。我的想法是把去重做到用户的浏览器或者客户端里。用户自己备份自己看过的内容的列表对应的文件。然后每次展示推荐之前都进行去重。我估计是维护这样一个所有用户已看过的内容的列表的成本太高了，否则目前的推荐系统不可能不做。所以才会出现重复或者只推荐新内容以减少重复。

推荐的去重也许可以用 ID 范围来表示看过的内容。但是可能需要一些辅助机制。比如对于某类人，每个与他们有关的推荐都分配一个编号。然后对于特别愿意尝试的人，如果大部分内容都看了，那也许可以通过这个编号系统进行高效的压缩。具体效果我就不知道了。

现象文档：缓解等待推荐慢

以解决某个问题为核心，将相关的现象和规律放入到一个文档中，用户勾选某些自己具有的现象之后文档可以自动提供一些个性化的规律。有点类似一个小型的专家系统。

现象警告：缓解隐私问题

某些现象和现象组合可能会被坏人利用。比如不愿意拒绝别人加上有教某种技能的能力可能很容易被人白嫖技能。直接在现象的展示页面就突出显示这种现象的危险性，以提醒用户做好准备。现象组合的提醒也许可以直接用规律凑合，然后在相关现象中链接一下。相关现象就是展示现象的页面的一个区域，或者直接就是现象详细介绍中的一个可选的小节。

本地数据：缓解隐私问题

用户具有的现象直接保存在本地的浏览器中或其他什么地方。或者以加密的方式保存在服务器上。其他用户搜索的时候不会搜到这种现象箱子。但是这种用户可以通过现象箱子搜索其他相似的现象箱子。

缓解因为给自己贴标签导致难以摘掉标签

据说人一旦给自己贴上标签之后自己就会认同相应的身份，最终导致难以摆脱这个标签。但是心箱现象刚好就是严重依赖类似标签的东西的。所以这可能是个大问题。

首先在所有现象的展示页面都提供一个弱提醒可能会比较好。然后某些特别的很容易关联到身份认同的现象可能要强提醒一下。

这个也许可以整合到一个“新手包”里。新手包里还包括比如健康饮食、规律运动等内容。“新手包”主要就是包括一些影响范围极广的现象。

还有就是也许可以推荐给新用户一个推荐箱子，就是提醒用户这个东西，提醒用户如果不知道这个东西，那么强烈推荐用户详细了解一下相关的内容。

缓解固定答案导致的行动僵化

有一段时间我比较沉迷辩证法，我发现心箱现象与辩证法也是比较拧巴的。另外我怀疑直接参考他人经验可能会导致错过获取一些关键的相关的隐性知识。所以，也许应该至少提醒一下，除非情况比较紧急，最好是自己多思考和实践一下，实在不行再参考他人的经验。至于如何培养辩证法和独立解决问题的能力，我目前还没什么好点子。

欣赏和理解某些内容可能需要较多前期投入

举个例子。某个人可能只有了解并信任一些其他的信息，才能对某个规律产生尝试的欲望。再举个例子，想要欣赏古典音乐，可能需要强迫自己听一段时间的古典音乐，并忍受那种无聊，然后才可能会喜欢上古典音乐。

我认为这是所有推荐系统的一个挑战。我没见过哪个推荐系统考虑过这个问题。在心箱现象中这个问题可以部分解决。通过直接向用户推荐一个推荐箱子，直接介绍这个问题就行了。然后在推荐某些东西的时候直接提示想要更好地利用对应的内容需要一些前提投入。或者直接只推荐给那些有相应的前期投入的用户。

摘其他推荐系统的桃子

直接让用户将他们喜欢的内容生产者和内容记录到心箱网里。包括用有序现象箱子和心箱数据。很缺德，不知道会不会遭报复。这个也许可以缓解一点冷启动的问题。

其他细节

规律的其他使用方法

除了前面提到的标准规律和改善规律。规律还可以作为诊断问题的辅助，还可以用来定义复合的现象。

诊断问题最好是用一个单独的系统来做，用专家系统可能是最合适的。但是如果没有资源实现的话，用规律也可以凑合用。比如一个人是北方人，并且肠胃不太好，并且精神和不太好，那么通过模糊搜索很可能可以搜出来通过这些东西预测一个人可能有麸质相关问题的规律。这个应该是没法跟规律反馈共用一个反馈系统。但是这个如果有预测成功的反馈很可能会很有帮助。

复合现象比如定义正常人，还有后面提到的各种极简生活的现象。这个主要是用来简化搜索的。多个现象换成单个现象会更方便一些。另外可能会具有类似特征工程的效果，就是降低资源消耗。这种规律的因现象就是复合现象的具体需要满足的条件。这种规律的果现象就是复合现象的名字。

让某种好状态变差

某些人可能会希望自己的某个好状态变差一点，比如好学、基本不拖延等。但是这可能会出现一些问题，就是改善某个状态的规律可能与让某个状态变差的规律不同。毕竟并不是简单的去掉某个导致好学的规律的一些因现象就行。另外如何精确调整某个状态的水平也是个问题，毕竟很可能没人愿意彻底抛弃好状态。考虑到让某个好状态变差可能远远简单于让某个坏状态改善，所以一般可能不需要专门的规律来指导人让某个好状态变差。当然如果这种需求确实很大的话那可能就需要考虑一些新的机制来解决这个问题了。

极简生活的可能的益处

我这里说的极简指在物质上和精神上与自己强相关的东西尽可能地少。比如吃和用含有多种添加剂的食物和日用品，或者浏览碎片化信息等。

我的想法是这些杂七杂八的东西可能会以某些无法预测的方式影响一些规律在用户身上的效果。所以过极简生活的人可能会排除更多无关的变量。

我想到这个东西主要是因为我发现香料人工麝香对我好像有很不好的影响，泛化了一下发现跟科学研究中的排除变量好像有点联系。

另外由于极简的生活对一些人来说可能很痛苦，也许可以区分不同的等级的极简生活。最极端的也许可以要求只能吃有限的几种食物，更宽松的也许类似防腐剂（我假设防腐剂合规使用也可能对某些规律的生效有一些影响。）这种东西是可以吃的。一个等级对应一个现象。某种极简生活的要求作为某个规律的因现象，具有某种极简生活的现象作为这个规律的果现象。然后这个果现象可以作为其他规律的因现象。另外在试验阶段也许过极简生活的人会更受欢迎。还有不同类型的人可能适合过不同类型的极简生活，这里说的不同不是不同等级，而是类似麸质敏感的人不接触麸质那种。还有外向的人只在吃用上面极简，内向的人在社交上极简可能会更容易一些。

削足适履

削足适履是一个很贬义的词，但这里用的时候并不是很贬义。这里说的削足适履指找一个自己向往或者适合的现象集合，然后让自己具有这个现象集合的所有现象。好处是可以获益于专门为这个现象集合对应的团体量身打造的内容。坏处就是失去了一些自由。

这里谈谈我对自由的理解。我认为某些人以为的自由存粹就是作死，这种自由就是完全不考虑后果的想干什么就干什么。这样自由久了早晚会把自己玩死。我也不是反对自由，我认为良性的自由应该是在获得了对风险的大致预知能力，及时止损的能力以及善后的能力之后对未知的探索。我比较鄙视那种简单的看别人做什么就想做什么，以及看别人没做过什么就做什么的行为。简单说就是为了爽，而且是低级的爽。当然我说的这种良性的自由对某些人来说可能更无聊一些。这里我就不展开了，这属于是“欣赏和理解某些内容可能需要较多前期投入”讨论的东西了。

一个人如果追求我说的那种那种良性的自由，那么相关的学习路径很可能是可以基本明确的。比如锻炼自己的通用的解决问题的能力，再学习自己想要探索的领域的知识。当然就算这样风险也不是没有的，就算是纯脑力活动可能也会面临大量思考白费的风险。更别说弄坏东西甚至自己的风险。学习阶段是可以利用这节说的削足适履来辅助的，但到了真正的探索阶段可能就需要基本依靠自己直面风险了。

当然我这么保守肯定只能得到一些所谓的“低垂的果实”。其实我思考这个点子很可能就相当激进，我花了很长时间思考这个点子。我目前也不太明了到底怎么平衡。也许 Paul Graham 的《 The Right Kind of Stubborn 》是要素之一。另外创业领域好像有很多看人不看点子的投资者，我想可能就是因为能力不行的创业者根本就解决不了实现点子过程中遇到的大量问题。

规律里面是什么？

我不清楚。我可以瞎写一下，但是我忍住了。但可以明确的一点是如果某个规律内部的机制明确了，并且有需要的话，可以拆分成多个规律。

关注现象

如果完全使用现象来表达某个用户对某个现象的需求和态度等的话，可能会导致两个问题：现象的数量大幅膨胀，搜索麻烦。搜索麻烦比如一个人通过将“希望好学”放入现象箱子来标记自己希望获取相关的改善规律。但是这无法确定这个人是否已经好学了。在想要推荐某个规律的时候，搜索会比较麻烦，需要搜索同时满足具有“希望好学”和不具有“好学”的用户。使用现象的关注功能就会好一些。当然如果是条件性的推荐，比如说只向开放性高且希望好学的人推荐，那么还是比较麻烦。我现在还想不到一个特别好的方案。

这段后面是目前我能想到的关注类型。特别关注：接收与这个现象相关的全部内容（规律，相关现象等），适合研究者使用。普通关注：没有具有这个现象，接收成功率较高的相关规律。比较失望屏蔽：失败次数过多，不想继续尝试，可能还会接收到一些希望特别大的规律。彻底失望屏蔽：没有具有相应的现象，但是对于能具有相应的现象彻底没有希望了。要不要加彻底失望屏蔽我是比较犹豫的。如果确实要加的话，建议对于使用了这种屏蔽的用户提供一对一的帮助。如果被滥用的话，原则上只给信用较高的用户提供。暂时屏蔽：如果用户想暂时专注于某个现象的获得，可以使用这个屏蔽其他的关注，达到时限后自动切换到普通关注。满意屏蔽：已经具有这个现象。无操作：可能收到是否想要关注这个现象的推荐。

我承认这个地方我思考得不太透彻。我感觉很可能是这个东西太复杂了，我脑子不够用。另外我也没动力用画图等方式辅助这个问题的思考。我目前感觉这个问题不是很重要。

技术细节

规则的匹配和搜索的优化

我之前了解过一点专家系统，因为我这个点子跟专家系统比较像。专家系统中有一种叫“Rete 算法”的东西，很可能可以加速规则的匹配和搜索等。但是这个算法好像是个空间换时间的算法，内存消耗很大。我问了一下 AI ，好像有一些优化和改进版的算法。我没详细了解，因为我很可能看不懂。

有序列表的模糊搜索

寻找与某个有序列表类似的有序列表我没找到现成的解决方案。我只知道好像可以用向量数据库。我设想了一种精度较低，但是我感觉效果可能凑合的方法。

首先通过原有序列表创建一个新的有序列表，其内容是原有序列表的前十。这个可以直接用一个新的现象箱子来实现。然后搜索的时候先从所有这种前十现象箱子中搜索与待搜索的前十现象箱子存在共有现象的现象箱子，并按共有现象的数量排序。然后对于每个搜索结果，分别计算并显示待搜索有序列表与搜索结果对应的原有序列表的相似度。这个相似度的计算可以放到客户端，另外也许可以显示多种相似度计算算法的结果。

只先匹配前十消耗的时间很可能很短，如果花费搜索积分可以先匹配更多的现象再显示相似度。

现象箱子容量和搜索现象数量对搜索时间的影响

我大致测试了一下，在“现象箱子-现象关系表”总数一定的前提下，如果每个现象箱子有 30000 现象的话，搜索速度反而比每个现象箱子有 123 个现象快。关系表大约都是一亿行。我认为这个测试是大致合理的，因为如果真限制每个现象箱子最多 200 个现象，那么有需求的用户还是会用很多现象箱子添加现象。不过我不敢对我的测试结果负责，因为我听说性能测试是个很复杂的活。另外测试的效果跟实际环境可能也有很多差别。我测试的时候每个现象箱子三万标签搜索时间大概 50 毫秒左右，每个现象箱子 123 标签 11 秒。前面说的时间是标签的使用率都很高，如果降低标签使用率的话速度会快很多。搜索的标签数量很多，大概一两百。

一般搜索的现象数量越多时间越长。不过这个跟现象是否被很多现象箱子添加有关。很可能是如果现象被很少的现象箱子添加的话，搜索时间会更短。

这个搜索相似现象箱子的操作很可能可以通过位图数据库加速。好像也可以通过向量数据库加速，但是用向量数据库如果要速度就只能返回不精确的结果。

通过按功能分表缓解数据量提高后性能下降

现象箱子-现象关系表的记录越多搜索时间会越长。我的一个想法是按功能创建多个心箱现象的实例，然后放到不同的服务器上。比如专门用于音乐的实例，专门用于个人成长的实例。如果某个实例还是太大的话，也许可以继续拆。另外我建议初期给现象和规律设置一个分类的功能，或者用标签。这样后期如果想要转移或复制到新实例里会更方便。

我的点子主要借鉴的对象

技术上是专家系统、推荐系统、标签系统。流程上是实验和试验。如果对这些东西了解不多的话，了解一下这些系统相关的内容也许有利于实现我的点子。

规律的数据库实现

由于规律不是简单的图，而是超图，所以用关系型数据库存储好像有点麻烦。我目前的想法是因现象一个表，果现象一个表。其中前者的表结构为（规律 ID ，因现象 ID ），后者的表结构为（规律 ID ，果现象 ID ）。因现象 ID 和果现象 ID 都是现象表中的主键。这么实现我没发现什么问题。不过我的经验很少，我的感觉很不靠谱。可能直接用一个带有因节点和果节点的关系表也行，不过这可能需要将所有现象和规律做一个转化，否则 ID 很可能会冲突，我不想了。

闲时执行耗时搜索

白天如果有用户执行特别耗时的操作，可能会拖慢其他用户的访问请求。所以将搜索请求保存下来，晚上闲时执行，然后第二天再展示给用户可能会好一些。

用另外一台服务器与主服务器进行数据库主从同步，然后对搜索请求进行排队也是个方法。不过这个可能更复杂。

通过分离出核心功能缓解开发效率低的问题

这个也许就班门弄斧了。由于我这个点子有很多问题，所以需要很多辅助手段缓解那些问题，所以我的想法是核心功能通过写单元测试等提高可靠性。边缘功能可以适当敏捷开发甚至氛围编程。特别是那些只读的功能。当然前提是做好权限控制。

心箱数据的实现

我打算自己做的时候计划用 PostgreSQL 的 jsonb 实现。

心箱量化的实现

数据的保存可以用类似心箱数据的形式。但是为了加速搜索，也许可以挑出一些属性集合用向量数据库实现。比如大五的五个属性作为一个向量。

现象箱子的历史版本功能可能很重要

因为这种信息可能有助于进行因果推断。

我能做什么

如果有人愿意替我实现这个点子，我可以不要工资兼职做远程产品经理。不过我每天可能挤不出多少时间来做这个事。所以最好别太期待。另外我很可能只能做个辅助的产品经理，我之前没做过产品经理，太复杂的事我目前没经验，再加上我只能远程。我估计我只能做用户访谈和根据需求给出一些解决方案。

AI 时代人就应该躺平吗？

我说个暴论，我觉得一部分人想躺平就是因为没有找到自己的热爱，如果通过我设想的这个东西找到了自己的热爱和对他人有用的共同点，那么可能就不会躺平了。

当然我设想的这个东西应该也没能力快速将所有人躺平的人都拉起来，但是能让一些人对生活的的满意程度变高应该就很不错了。

关于如何提升体验，详见“欣赏和理解某些内容可能需要较多前期投入”。

据说任何时代愿意自我提升的人都是少数。我设想的这个东西如何能提高这种人的比例应该也不错。

一些可能不利于这个产品的东西

我把整个点子基本都发到 Github 上了，还在一些别的网站发过。其中 Github 内容是最多的。不过之前写得都很烂，至少我感觉这个介绍文档比之前的强多了。之前的我自己都不爱看，更别提改了，所以被人关注和详细看的概率很可能不大。这个文档我看和改都比较顺畅。这个可能会有利于竞争对手。我怕我意外死掉这个点子就没了，所以就公开出去了，希望将来有人能发现并实现。发出去之后我焦虑明显降低了。如果想跟我一起做的人在意的话我可以尽量把能删的都删了，不过有一些网站的内容基本无法删除。

还有我发那些东西的账号有一些可能算黑历史的东西，也许会有点影响这个产品的名声。

我不知道因人而异的规律有多少。如果因人而异的规律很少可能根本就用不着心箱现象这么复杂的东西来发现和分发因人而异的规律。科学界普遍追求普适的规律，包括心理学，目前的确定的因人而异的规律少可能主要是因为这个。但是因任务特征而异的规律好像有一些。

对自己最喜欢的前 N 个某个领域的对象进行排序可能很消耗精力。可能 N 比较小会轻松一些。但是过小的 N 可能效果会更差一些。

平均每个人拥有更多朋友可能导致社会价值观极化加剧。相关论文：《 Why more social interactions lead to more polarization in societies 》。论文我没看，我看的是二手解读。

为什么不自己实现？

这个点子我本来是想自己实现的，但是因为一些原因我想暂停一下。但是我又怕暂停之后自己看不到这个点子变成现实了。所以就想公开这个点子。看别人能不能替我实现一下。

接受反驳

我自认为我脾气很好。另外相比夸奖，我对我没发现的缺陷和漏洞更感兴趣。如果有时间、精力和意愿等的话，请不吝赐教。

结语

首先提一下我之前发过的介绍同一个东西的文章，那篇文章发在这里效果很不理想。我感觉很可能是因为我之前写得比较烂。之前那篇有人说我写的时候只管自己输出高兴，其实我写得挺痛苦的。这篇不一样，我确实做到自己输出很高兴了。因为我感觉我悟了，悟出长文写作的诀窍了。如果有人感觉我这篇文章读起来跟之前比有进步的话，我会在附言中公开我的方法，核心就六个字。要是还不行的话我就不说了，免得把人带沟里。如果有人对只是自己写得嗨感兴趣的话可以在 Chamber 节点 @ 我。只是自己写得嗨一般来说可能好处不大，甚至可能有坏处，所以我不太想让太多人的人知道。之前的帖子： https://www.v2ex.com/t/1012289 。

第二我会置顶几次，除非有很多人反馈说这篇文章很辣眼睛，很难读之类的。先说句抱歉。

第三求一些安利我这个点子的方法。说一下我试过的。首先是在爱合伙上找人，没收获。然后是找一些跟我的点子贴边的组织和个人安利，除了知乎基本没有回的。就算是知乎看起来也没重视。然后就是发文章，知乎上我加了三次自荐自荐也才一百多个阅读，很可能将近一半都是我在本站贴的一个链接带去的阅读。知乎的阅读可能不是读完全文，可能点开就算。知乎客服说一次自荐相当于 500 曝光。下一步我计划在做自媒体的时候积累网感，感觉可以了再把文章拆成小块在知乎上发。然后我还有个相当邪修的方法，副作用很可能相当大，不出意外过几天我在这里问问，参考一下别人的看法。万一因为这帖有人替我做的话我就不发关于那个邪修的帖了，不过我感觉大概率还是没多少人搭理我。

第四我没有乔布斯的能力，但是我很可能有乔布斯的强迫症。你不想被我束手束脚的话最好别让我参与。比如我不想让网站涉及键政和涩涩。你偷我点子做我不认可的事我最多谴责你一下。另外这很可能也不算偷，我本来就没藏着掖着。不过我估计有我参与的话可能也会有一些好处，比如某些关键的地方我故意或者忘了说了。比如游说成长类和大 V 参与。不好，说走嘴了。另外我解决问题的能力可能是超过平均水平的，特别是至少在一段时间内我对这个点子的理解应该是没人能赶上的。

第五如果你特别感兴趣，想详细了解的话，推荐到 https://github.com/shendaowu/xinxiang-idea 看看。提醒一下，非常辣眼睛和不好读。有疑问推荐直接在这帖问我，给这个帖子加点人气。

第六联系方式：Nzc4MjUyODQ1QHFxLmNvbQ== 。

声明：本人仅仅负责数据工程中的数仓部分。我的主要业务包括：

• 数据建模；
• 测试以及警报系统的建构；

我的次要业务包括：

• 从各种 API 中获取数据，主要用 Python 写代码；
• 维护兄弟组的串流数据程序；
• 优化下游组的查询和程序；

我上个月开始严肃的用 Cursor 来帮助自己自动化一些开发。以下是我的经验和感触。因为我的经验并不丰富，所以估计以后会有更多的想法。

首先是判断哪些开发比较适合用 AI 自动化。一个比较简单、容易重复的开发，是给现有的 silver 表增加新的列。我们有很多 silver 表是从 s3/dynamoDB 里通过串流数据程序，以 JSON Blob 的方式导入到数据库中，然后再做一些简单的变换而生成的。这部分开发非常简单，但是频率很高，让我烦不胜烦，所以决定第一个拿它开刀。

我尝试了两种办法：

方法一，将所有变换规则都写在子目录的 cursor rules 里，再把 git flow 也写清楚。使用的时候就直接在 chat 里和 AI 对话，让它引用这两个规则，最后本人审核完毕之后，直接修改 dbt 的 models.yml ，最后提交 PR 。整体步骤大概是：

• 生成 feature branch
• 查询 bronze layer 表，确认该列在 blob 中存在，且确认其包括的数据类型；
• 已知数据类型，根据相关的变化规则在 silver layer 的数据模型中增加一列，并在 models.yml 中更新数据辞典和所需的测试规则；
• 将 feature branch 推到远端，并生成 PR ；
• 自动在 Jira 工单里增加评论；

我测试了一段时间，发现方法一还是有些问题。一个是 Cursor 的数据库插件时好时坏，还有一个是 Atlassian 的插件突然就不好用了，我也不确定是什么问题，但是最重要的是，这个方法还是没有解放我自己，我需要和 AI 进行对话。所以我后来决定自己写程序自动化这个流程。

方法二（还在制作过程中），将这部分 silver 表的元信息加入到 models.yml 中，包括列名、列类型等等。然后在 CI/CD 中增加了一个 Python 程序，一旦检测到这部分模型发生变动，那么自动将 models.yml 中的相关数据模型重新“编译”，然后用 dbt compile 和 dbt run --target dev 进行测试。这个方法的好处是，下游组想要新的列，直接修改 models.yml 提交 PR 即可，我只需要审核即可。我使用 AI 来帮我确认 yml 文件的格式，以及帮我来写 Python 程序。因为我比较喜欢写这种程序，所以大部分代码还是自己写，而不是让 AI 生成。

我同时尝试了一下让 AI 帮我从头到尾生成一个全新的数据模型。首先我写了一份详细的 Markdown 表格，里头有对业务数据的简介、下游组为什么要这个数据，每个数据流的元数据（数据流的表的名字，PK 列是哪些？怎么样避免全表扫描？等等），以及下游主所需要的每张表的特点（比如说，subscription 表是需要将数据流 A 和数据流 N 根据某几个列 JOIN 起来，最后生成的表格的每一行是一个 subscription ）。接下来我让 Cursor 直接根据这份清单，写查询从上游的 bronze 数据流的表生成我所需要的 silver 表。我觉得 AI 的表现还是可以的，不是说所有的查询都能一次性完成，但是至少能省我很多力气，总体来说就是把 boilerplate 给自动化了。对于一些比较简单的数据模型，只有 3-4 张表，又不需要非常复杂的变换的那种，基本上可以一次性生成数据模型和所有文档，就是还得自己审查一下。

这个月中，我还用 AI 帮忙生成 JIRA 工单、撰写文档、数据辞典等等。我感觉这方面它的确是个很好的助手。接下来我想要尝试把 AI 接入到 On-Call 中。我们 On-Call 经常会有一些不重要但是必须要处理的问题，而且每次处理方法完全相同。我决定让 AI 筛选一下 On-Call 的警报，如果是这类警报，那就完全交给它，最后搞完之后，重新跑一次警报查询，确认一下，就行了。如果确认不了，或者是其他警报，那么就什么也不做，还是交给我们。但是细细想来，这里其实很多细节问题，还不确定能不能比较好的自动化。

总体来说，我认为 AI 帮助很大。但是也需要接入到内部系统中，写好指示，才能真正发挥作用。我感觉 AI 对各个系统的接合可能是个难题，如果在撰写系统的时候就直接把 AI 考虑进去，那就最好了。只好有待将来继续挖掘了。AI 如果了解数据库的话，就可以回答“我想要这个数据，从哪里拿？“这个下游组经常问我们的问题，也能帮我们解除掉一点压力。

我的感觉，如果进一步整合好的话，AI 起码能够让我的效率增加 50%以上。