2026年8月思考笔记：AI 与 Agent 系统、日常与其他、工程与开源

本月共 484 条笔记 | 记录时间：2026-08-04 — 2026-08-31

主题分布：AI 与 Agent 系统 212 条 · 日常与其他 118 条 · 产品、工程与开源 96 条 · 自我认知与心理 36 条 · 商业、投资与职业 9 条 · 内容、创作与记录 6 条 · 阅读、思想与历史 4 条 · 旅行、地理与城市 3 条

以下是这个月的全部记录，按主题归档，条目内保留原始时间戳。

一、AI 与 Agent 系统

212 条记录

最开始的需求是啥：

2026-08-04 00:07:12 · #ailoha

我们的task就是在48小时内实现一个独立小项目：Lite Ailoha

目标：

用户上传一张聊天截图，也可以附加一段补充文字。系统需要理解截图里的上下文，识别可以执行的行动并生成用户可确认的 action cards（主要有 创建会议，创建联系人，更新联系人）。用户确认卡片后，结合用户的联系人数据以及当前上下文生成对用户有帮助的洞察和建议（洞察和建议是重点内容）。

最终交付的话产品形式（iOS app），github repo，可运行的测试环境（本地和云上部署都可以），其他没有任何限制

可以使用全程用 daypage 去记录

2026-08-04 00:07:29 · #ailoha

可以使用全程用 daypage 去记录，元意识如何指导

可以深度的补充一些知识体系对于如何做一个独立任务，如何分析需求，如何参考一些非常前沿的审美的的体系

可以通过这个任务深度的理解对方的公司的需求是什么

如何营销的问题深度的思考探索

如何补充和确定这个需求的能力

做的过程中很兴奋怎么办

2026-08-04 00:48:48 · #ailoha

感觉自己前段时间的痛苦让自己开悟了

自己很兴奋期待展示自己对世界的理解的时候了

为什么不按照原来的方式去做

2026-08-04 01:00:37 · #ailoha

总想自己创意一下？

感觉创业好苦

想证明一下自己

今天又受到弘一法师的影响

tmd 为什么我不能做到最吊

需求做不好我就死死的去学

即使是猎头行业，做上层猎头的效应（传播效应）远远强于

2026-08-04 01:09:07 · #ailoha

即使是猎头行业，做上层猎头的效应（传播效应）远远强于下游的猎头

付费率也更高，底层的猎头 FOMO 心态

我的元认知很强

2026-08-04 01:11:47 · #ailoha

对我来说身体好像只是一种传感器

去接触这个世界吧，勇敢玩这个游戏！

花48 小时做一个没用的产品对我来说是一件痛苦的事情

2026-08-04 01:13:20 · #ailoha

花48 小时为这个世界创造出价值对我来说是一件很兴奋的事情

如同在悬崖边上行

顶尖的人才几乎不会去上任何的招聘的平台

2026-08-04 01:27:40 · #ailoha

80% 的顶级候选人属于“被动求职者”（Passive Candidates），他们处于工作中，需要被发现、被说服、被劝诱

有时候对方给你出一个题

2026-08-04 01:30:12 · #ailoha

你可以适当的调整题的结构

调整的目的不仅仅是让对方看见你

也是为了这个过程中你去评估对方

几个痛点，招聘者视角：

2026-08-04 03:03:57 · #ailoha

脉脉、猎聘、Boss直聘数据是不互通的，且反爬机制极严。很多基于代码注入的AI插件极易触发风控导致封号

破冰好难啊，微信上发消息发一句在吗，容易被忽视

后期更近的问题，如何更近如何管理，AI 如何提醒

对于IOS 来说，记录可以有哪些的扩展的能力支持

2026-08-04 03:13:18 · #ailoha

Screenshot Automation（截图自动化）

Visual Intelligence 文本提取

siri

Back Tap / Action Button / Control Center

Live Activities / Dynamic Island 灵动岛

Widgets + Interactive Widgets 小组件

Apple Intelligence / Use Model 动作端侧模型

Clipboard / Files 集成

PIP 模式很有意思的，画中画的模式，但是仅仅是语音或者视频通话才可以，不过可以类似于夸克搜题的方式，辅助触控，小白点的方式 + 快捷指令

数据记录这部分是清晰的，但是数据飞轮呢》

2026-08-04 03:32:39 · #ailoha

数据记录这部分是清晰的，但是数据飞轮呢》

看一下，就是所有的猎头常用的工具里面

2026-08-04 10:42:37 · #ailoha

今天看一下，就是所有的猎头常用的工具里面，他们基本上经常在的一种方式，就是在咖啡馆跟别人聊天，然后通过一些碎片化的方式记录到自己的思维笔记里面，用flomo 或者 get笔记管理 ….

还有一点就是使用场景的问题，我观察到国内国外的猎头

2026-08-04 11:58:01 · #ailoha

其实还有一点就是使用场景的问题，我观察到国内国外的猎头，他们基本上使用平台是有差异的。一般来说，在手机端基本上都做的更多的是一些轻量化交互的逻辑。就比如说在维护一些群体，然后可能在手机端去做一些这样的能力，比如说聊天记录，然后提取关键信息，然后配合一些记录工具，把本地截图快速的转化为本地的工程或者待办清单

一般都会在PC端，通过一种思维表格的方式去管理交互的

所以相对来说，移动端就会考虑无感捕捉与即时响应

Web / 浏览器插件，早起 Web 端可以做的极简，主要是作为数据查看器和配置中心，能迅速建立用户的数据依赖

​​确保跨端体验的“无缝流转”​​：这是用户最在意的体验。比如在手机上截图生成的“待跟进候选人”，在打开电脑 Web 端时，能直接以卡片形式浮在浏览器最上层，支持一键拖拽到 CRM 系统中，形成真正的闭环（或者是通过 mcp 的方式接入到三方的平台，可以有助于三方的平台管理和维护数据）

可以是一个工具场景、可以做成一个通用需求

2026-08-04 12:03:17 · #ailoha

可以是一个工具场景、可以做成一个通用需求、可以作为一种普遍的关系需求

但是思考点主要是围绕强需求思考，HR 的痛点，如何维护和管理联系人

手机端做好轻量，只做到管理的这一层，更多的逻辑是可以通过电脑端 codex 去做更复杂的处理逻辑操作

浏览器插件的一个痛点的场景：

2026-08-04 12:04:46 · #ailoha

招聘网站“刷人”时的秒级抓取与入库

这是目前猎头插件最刚需、使用频率最高的场景。超级个体猎头每天要在猎聘、Boss直聘、脉脉、LinkedIn 上刷几百个简历

​​看到合适的候选人，传统操作是“打开简历→手动复制姓名电话→切到CRM系统→新建联系人→粘贴保存”，一套下来至少1分钟，一天下来手指都酸。

​​插件悬浮在招聘网页侧边。猎头刷到好简历时，点击一下插件按钮，自动提取页面上的姓名、公司、职位、联系方式，直接生成一个“创建联系人”的卡片。确认后，数据自动同步到猎头的飞书表格或CRM里。这能把“找一人存一人”的时间压缩到5秒钟

然后还包括就是快速的截图只能总结，比如说一些重要的信息，还依靠重复的发送，这样是很困难

像 LightUp、AroundDeal 以及

2026-08-04 12:16:39 · #ailoha

像 LightUp、AroundDeal 以及 GitHub 上各种开源的抓取脚本用于抓取简历入库，已经证明了这个就是强需求的逻辑

猎头核心的KPI 就是简历推荐量和面试量

我发现他们目前在做的还是有一些

2026-08-04 14:46:05 · #ailoha

我发现他们目前在做的还是有一些，就是做一些computer use

然后再包括通过一些RPA或者是OCR，然后做一些本地化的工具。OCR是一个本地化，就是自动的去截取这个图片的内容，然后分出来，然后自动去交给AI的接口去做一些处理。但是这个问题最大的是平台风控问题，这个Boss直聘是针对浏览器插件，包括传统就是 codex 做一个识别

颗粒度问题，也涉及到一些长期价值，短期价值

2026-08-04 15:03:05 · #ailoha

颗粒度问题，也涉及到一些长期价值，短期价值，长期记忆，以及业务的处理方式

表层可以放一些硬指标，基础标签之类的，这部分是结构化的字段的，基础的薪资，还有一些的核心技能（但是这个东西应该考虑智能的程度，方便 HR 额阅读体验快速筛选（服务于 UI 的，可以有一些轻量化的数据库）

中层可以放一些动态软标签以及认知的画像，精准匹配用的，也是 AI 最有价值的方向，wiki 系统的，性格特质问， 职业倾向问，标签

底层是一些原始的凭证，结构化的数据，这部分都是用户 input 的原始的仓库，AI 一般都处理过的

美学部分的思考，场景

2026-08-04 15:20:36 · #ailoha

Notion 无界卡片的美，卡片视图和列表视图的切换，每一个候选人都是一张卡片， 头像，核心的标签，最近的跟进时间以极简排版呈现，大面积留白，视觉层级清晰

LoanZa CRM 的视图，大的字体，字体的样式，留下的趋势图，卡片使用微圆角和弱层次阴影，让元素在视觉上“悬浮”，减少认知负担，“柔和中性色调 + 品牌强调色”的搭配，让枯燥的候选人数据显得高级且易读

克制色彩字号

关系图谱的显示，可视化， WOLB 的设计，它本质上是通过自定义的标签，然后将人脉分层、节点和连线来展现出关联度能量，高级能力了

关键信息是可以回溯的，也就是说它最好，哪怕在维基页面里面，要清晰的展现出每一条新的信息，添加的一些日志情况，这样的话是可以支持回溯的。相对来讲，还是看上下文更全，它本质上是一个维基的逻辑，首先要把维基的逻辑做好

最开始的目标肯定是，我希望很多人可以去注册

2026-08-04 16:09:57 · #ailoha

我觉得最开始的目标肯定是，我希望很多人可以去注册，然后包括完成复杂登录注册验证，然后拥有比较好的审美。然后在登录的时候可以选择谷歌登录或者是Apple登录，然后登录之后自然就进入到多用户的多租户的一个页面去，然后每个用户有一个管理系统

然后可以完成一系列的操作

从它的数据结构来说，我觉得越是底层它越是发散越是上层

2026-08-04 16:12:06 · #ailoha

从它的数据结构来说，我觉得越是底层它越是发散越是上层越是倾向于相对收敛

但这个相对收敛来说，我觉得它更多服务于用户体感，还有站在用户角度上面来说，它能够有一个到达什么样的边界值，这是一个直觉问题以及用户体感的问题

就比如说关于它的存储逻辑，对下层无所谓，任何形式的输入。然后再到维基层的话，实际上编译成一个LM可以清晰地处理，然后服务于LM去调用的层。然后上层的话可能是一个相对灵活的一个JSON层，它可以用户去自己去定义字段，定义一些参数，设置一些模式，他服务的就是用户去筛选

哪怕再这么去扩充上下文，去有各种途径去感受感知上下文

2026-08-04 16:15:44 · #ailoha

其实哪怕再这么去扩充上下文，去有各种途径去感受感知上下文，但是我觉得还是缺少一种原始的体感。体感这东西我强调很多遍，就是它相对来说在这个场景中真的蛮重要，因为其实越是靠近用户层，越是需要体感，它更多是一种直觉，还有品味

比如说 UI 应该如何显示的问题

隐私安全和加密是双向门，不是很重要的内容

2026-08-04 16:19:21 · #ailoha

隐私安全和加密是双向门，不是很重要的内容， 往往是后期的内容

这部分是重要的，但是不是紧急的

wiki 的逻辑，wiki 和 agent 以及

2026-08-04 16:30:49 · #ailoha

wiki 的逻辑，wiki 和 agent 以及 raw 之间的流程顺序的问题

这部分要考验用户的体感的问题

上层是一些实体

2026-08-04 16:46:13 · #ailoha

实体本质上是用户层面的事情，用户价值的事情

底层的本质上是 wiki 的一种应用

那么上层的角色以及标签都是虚化出来的

他这样的话设计有一个好处，就是有些东西可以抽离出来，比如说input这部分逻辑也可以抽离出来，就是如果只要和用户没有关系，他可以抽象为底层的一些基础设施，那么他input的本质上有一些基础的代码，或者是一些处理逻辑，比如说对于一些底层的数据库，或者是后端API的设计，那么这部分就是可以先做的，无所谓的

然后另外一方面，就比如说针对这个项目来说，我抽象几层，一个最底层的数据源层，它本质上也是数，基于一些底层的数据结构的一些存储，以及一些基础设施，它们怎么建设，类似于Info层。但是中间层的话，我觉得就是更多是在业务处理逻辑上面，比如说它怎么样通过一些原始数据，然后它的Agent Loop怎么样去做的，以及它的多Agent系统怎么样去实现的，还有就是它的Agent密集，它支撑了一个什么样的架构，以及它最后要达到什么样的效果，这部分怎么去评估？然后这部分也是一个中间层，就是核心的业务逻辑，这部分应该怎么去设计？以及我觉得 LLM wiki 也包含在这一方面，因为实际上我们在输入数据的时候，这时候它系统首先会判断，就它会有一个Agent系统，然后去判断就这个信息应该去如何流通的，他肯定不可能原始的直接出入任何的形态的信息，而是说做一个中间的统一的调度入口

然后还有就是它最后落地的形态是什么样子？这时候它肯定存储的还是一种Wiki的方式。但是呢，这种Wiki它是服务于上层的用户的，一个就是你可以在AJ系统里面去调用你的Wiki，另外一个是你自己这个agent 系统的服务，在上层用户层展现的时候，它会有哪些语义的定义？它这是用户价值层的事情，就是它的名词应该怎么样用？它的逻辑应该怎么样去设置？它的界面应该怎么样去优化和排版，这部分的话就可以用 skills 去做的

schema 就只是一种展现的方式了，，底层也有单一的事实来源

有时候是有一些冲突的

2026-08-04 17:03:09 · #ailoha

但是面临冲突的时候，首先要做的事情，并不要着急去品味解决冲突，而是我觉得更重要的是，多站在几个角度去分析这个冲突以及把这个冲突往下分解

比如说一些原始的对话截图和会议记录，

心中的疑惑是这样子，比如说我们我在面临一些问题的时候

2026-08-04 17:03:12 · #ailoha

心中的疑惑是这样子，比如说我们我在面临一些问题的时候，比如说在面临新创建一个项目，然后对应的知识文档或者是方向可能很多，那么管理这些文档还是一件很繁琐的事情。或者是就是非常非常多零散的想法，它漂流在各个地方，那么怎么样去把它聚合到一起，我觉得还是一件非常有挑战的事情。就是我理解的聚合在一起，就是有一些比较重要的东西嘛，就是我我觉得就是一些成功的经验，它可以算到一个知识里面去，但是一些零散想法，它可能未必是这样，所以我想做的就是怎么样去把它们组装到一起，很好地组装到一起，是否也可以用到一个，就是在项目中，比如说一些新的项目，一些全站的类型的项目，包括前后端，那么它去是否要做一个额外的一些知识库整理的方式？或者是把以前的一些碎片化的灵感也编译到一起？是否可以去用一些卡帕西的 LLM wiki 的方式去管理

任务到现在，其实花了一半的时间去设计，调研

2026-08-04 17:26:32 · #ailoha

任务到现在，其实花了一半的时间去设计，调研，理解需求，判断边界，扩展训练自己的审美，直觉

没有开始写代码

这个任务挺有意思的，它其实也促使我去理解怎么样去快速

2026-08-04 17:27:31 · #ailoha

我觉得这个任务挺有意思的，它其实也促使我去理解怎么样去快速迭代，它算是我自己实践中的非常好的一个问题，这是一个 good question

也应该整理一个域名和服务器

2026-08-04 17:44:48 · #ailoha

md 要做就做到最牛逼

用户付费意愿强

talentsignal.com 没了

gettalentsignal.com ✅

技术角度上分析，即使角色的处理的 workflow

2026-08-04 19:52:47 · #ailoha

技术角度上分析，即使角色的处理的 workflow 可以是一致性的

但是用户价值体现的是对应的处理的信息，给用户反馈的是什么样的结果

应该设置各种的自动化能力，大幅度提升 codex

2026-08-04 20:36:02 · #ailoha

应该设置各种的自动化能力，大幅度提升 codex 的利用的效率，完成项目最大程度上

继续考虑 agent 层

2026-08-04 20:58:03 · #ailoha

几个能力，一个是接入微信的 OpenClaw ，这样的话可以在微信中作为一个轻量的入口连接起来

另外一个是可以以agent 的方式接入 codex 或者 Claude code

Vision OCR、bounding box

2026-08-04 20:58:30 · #ailoha

云端 agent 可以做更多的东西

最开始不要考虑打码

通知的能力和场景思考，在这个业务中自己的一些思考和品

2026-08-04 21:09:24 · #ailoha

通知的能力和场景思考，在这个业务中自己的一些思考和品味

我觉得在思考之前，先思考什么样是不同值的。有一些事只记录不同值的，比如说有一个联系人，他新添加了一项偏好，然后没有明确的截止时间，agent 说话有歧义， agent 只是推测候选人可能冷掉，这种方式一般都只是记录，没有必要通知。不是每一个signal都应该成变成notification

场景： 静默层 timeline，一般添加偏好，每日简报

iOS 通知原生区分 passive、active、time-sensitive 和 critical 等打断等级。Time Sensitive 可以突破部分通知控制

Time Sensitive：明确且即将错过，有确定的时间，到期时间，有真实的窗口期的，灵动岛

AlarmKit：真正的闹钟级提醒，AlarmKit 可以让第三方 App 创建真正醒目的闹钟和倒计时，可以越过静音模式和当前专注模式，也可以显示在锁屏、StandBy、灵动岛和配对的 Apple Watch 上，这种情况适合用户明确说这个要提醒，确定的面试或者电话强提醒

Apple 对 Live Activity 的定义是：让用户在几个小时内持续跟踪一个正在进行的任务、事件或活动；它会出现在锁屏、灵动岛、Apple Watch Smart Stack、Mac 菜单栏等位置

所以相对来说，我觉得当这用户点击，比如说持续跟进，或是用户想要即将发生的候选人事件，然后联动导指显示最关键的一种状态，比如说面试的时间、面试的状态

Apple Watch是很好的渠道，有时候手机是被忽略的，但是手表它轻触的是很难完全忽略的。所以对于一般来说社交类或对时间要求比较紧的领域的人来说，iWatch是一个强需求事情

Calendar 应该集成，但不要污染日历

Widget、锁屏和系统入口 也可以优雅的设计，包括 siri ，快捷指令

行业的一些思考：

2026-08-04 22:03:51 · #ailoha

顶级猎头不是做终结的，承接的是一个组织没办法靠职位描述、数据库和面试流程独立完成的任务

不敢相信，真正开始写代码现在才开始

2026-08-05 01:32:54 · #ailoha

而我，准备去睡觉了 …

思考一下推广的问题

2026-08-05 09:00:21 · #ailoha

猎头是一个很垂直的行业感觉

没有这个领域的经验，叙事必须要的更宏大叙事一些

营销叙事必须要变宽

具体的产品定位要变窄

产品的定位就是面向猎头的，用户价值的主要视角是猎头本身

产品的营销层面，是一个通用的产品，从私人对话证据，到一个经过确认、可追溯、可恢复的下一步

https://www.granola.ai/

2026-08-05 13:49:52 · #ailoha

https://www.granola.ai/ 的拖拽效果交互效果，交互感做的非常好

https://www.leonar.app/features/leonar-source/ 的边框，悬浮，字体样式，字体，上面的导航栏的审美细节都做的很好，很值得学习

https://rondesignlab.com/ 的大字体很值得学习

Attio：参考字体层级、克制的间距和首屏下方立即出现的高保真产品界面。Talent Signal 最应该学习它的产品完成感。

Metaview：参考首屏如何同时完成品类定位、价值表达和真实产品展示。不要照搬绿色暗黑风格，只学结构。

Common Room Signals：和 Talent Signal 的概念最接近。它把分散 signal 直接画成可识别的人、事件和动作，比原子轨道更接近业务语义。

Clay：参考如何建立一个别人无法轻易复制的品牌世界，以及如何在强烈视觉之后迅速接上客户证据。

Juicebox：同属招聘 AI，参考它的品类表达、互动式产品演示和首屏后的客户 Logo，而不是照搬紫色。

3. 竞争并不弱，部分产品承诺已经被覆盖

2026-08-05 23:13:39 · #ailoha

这个市场不是空白市场。

目前招聘产品的公开能力已经包括：

Metaview：自动记录、转写和结构化招聘对话，并同步 ATS；

SourceWhale：捕获通话、邮件、短信、WhatsApp 和会议，自动形成完整上下文、下一步并同步 CRM/ATS；

Loxo：集中候选人、客户、对话和历史记录，并提供基于权限和数据库内容、带引用的 AI 查询；

其他 AI 招聘产品也在提供 candidate signal、follow-up、结构化 evidence 和 ATS-ready notes。 SourceWhale

因此，Talent Signal 不能把自己的差异定义成：

AI 总结招聘对话；

自动发现候选人信号；

生成下一步；

记住候选人上下文；

写回 ATS。

这些能力正在迅速成为招聘软件的标准配置。

它真正可能成立的差异只有三个：

私密渠道捕获

处理 ATS 和会议机器人捕获不到的微信、WhatsApp、LinkedIn DM 等上下文。

可验证的时间状态

不是保存一份摘要，而是维护“什么事实在什么时候变了”。

高信任动作治理

证据确认、动作批准、执行和目标端回读相互独立。

这三个方向有价值，但目前没有证据证明猎头愿意为这些额外步骤承担操作成本。

OCR 的能力

2026-08-06 00:48:44 · #ailoha

感觉是有致命问题的

是别的效率很低，没有家属价值

建议直接取消隐私的方案，直接干

好像现实世界也开了多倍速一样

2026-08-06 11:17:42

这个世界也像是如同电影的帧率一般一闪一闪的AI 时代，好像现实世界也开了多倍速一样

这个世界也像是如同电影的帧率一般一闪一闪的去刷屏

主观时间好像被压缩、被切碎，没办法再去回过头来看过去的一些人一些经历，甚至连自己的内心都来不及安放

每一次回想起来泪水忍不住涌现

看得见的，仅仅只是当前匆匆一闪的当下帧

要是世界可以慢一点就好了 ,,,

可以好好的去告别，好好的去再见，好好地说一声谢谢

还好人生很长，总归是可以用一些时间去换得一些在场 ….

一些比较常识的理解，就目前关于技术常识的理解

2026-08-06 12:30:14 · #ailoha

一些比较常识的理解，就目前关于技术常识的理解，就比如说现在Level Tears，就是iPhone上面的OCR路线，它本质上是设备短跑，然后速度快、省电、不联网，但是它不做理解画面，也就是说它的理解能力很弱的。但豆包的SAD系列，它的大模型，它是不仅能做文字级别的，还能理解图片中的版式结构，还有语义关系。所以测试速度也是很快的，目前准确率也能到第一梯队。 就前期的话，我觉得还是用豆包这个模型形态来去做，相对来说的话，价格大概是1000张图片大概是在15块人民币左右，然后对比美国的模型，便宜大概4倍

它像猎头营销的一个时机应该是它的基本链路是非常清晰

2026-08-06 12:55:09 · #ailoha

我觉得它像猎头营销的一个时机应该是它的基本链路是非常清晰，或者是让人产生一种ah moment的，这是在用户价值上面来看的话，就是它应该是会有一些比较好的反馈。就比如说截图，每一次截图的时候，然后它真实的会产出一些行动，比如说它会去有一个自动化链路去完成一些基本的Actions，以及给这个用户做一些基础的存档。这个 Actions 它也可以准确的去做到一些行为，它可能会维持和当前用户相关的，比如说设定一些闹钟

然后实际上这个 Actions 应该也能做蛮多的，但这个地方应该还是需要具体而言多思考一下，应该也是一个 AI 的平台

而且我就在想一个问题，就是它的对应的载体到底是什么

2026-08-06 14:54:49 · #ailoha

而且我就在想一个问题，就是它的对应的载体到底是什么？到底是人吗？还是某一个具体的关系？但它的形态是什么？因为人他对人联系人这个认知成本是最低的，大脑里面很容易产生一种映射。但如果是一种虚拟的东西呢？就比如说做，对于房产销售来说，他要映射出来的是一家公司和对应的一个人之间关系？这个公司是一个什么样的显示形态？

我在想一个具体的需求情况，就是在用户的场景下

2026-08-06 19:24:50 · #ailoha

我觉得简历上传是尤其重要的，因为简历它可以去辅助HR编译更多的信息，去对这个人有更全面的建模，甚至是一些链接，这些东西也是非常非常重要的

如果就我判断的话，我觉得它是一个强需求的场景

因为实际上其实大部分情况也需要考虑，就是一些链接去分析这个简历，然后通过这个简历去匹配对应的人或者或者企业

我想赢

2026-08-06 22:12:00 · #ailoha

我想赢

参考产品的结论开始收敛了：

2026-08-07 14:52:00 · #ailoha

Mesh（原 Clay）证明“联系人 + 关系记忆 + 提醒”可以做得漂亮，但它最新的 Liquid Glass 与关系强度表达 不应直接复制。

Things 证明真正的高级感来自对象清晰、渐进展开与位置连续性，而不是材质堆叠。

Cardhop / folk 证明搜索必须是首页一级能力，且联系人、公司、备注要统一检索。

Granola 证明移动端应该主动缩小能力边界，只承载现场最适合手机完成的任务。

Attio 证明记录深度有价值，但把桌面 CRM 全量搬到手机会牺牲速度与识别性。

我在想，就是其实这种年轻人

2026-08-07 15:08:17 · #ailoha

其实我在想，就是其实这种年轻人，他应该是比类似于资源管理，我觉得更珍贵一些。所以相对来说，我觉得就有几点吧，就界面一定要极简为好，这部分可以参考Notion，然后再就是输入一定要非常非常尽量减少猎头他们的负担，这部分是可以参考 Flomo

然后再一点的话，我觉得就是这个资源既然很珍贵的话，我觉得它是不是就是主题，一方面是极简，另一方面我觉得它可以去以看参考那种艺术馆，就是要有大量的，可能相比较而言比较多的留白，尤其可以参考日式的美术馆，那种设计思路，包括线条，包括边框，包括内容，包括主题。然后它的一种管理的方式，管理的策略，怎么样去引导人去找到最合适的

聊天框一定不是未来主要的入口，那么什么样才是好的入口

2026-08-07 15:31:37

沉静、结构化、上下文感知、可追溯、可撤销的 AI

AI 出现在用户正在编辑的页面、选中的文本和数据库上下文里，而不是强迫用户离开工作流进入一个空白聊天框

想在哪些情况下，因为我觉得它也是可以参考Bommo那

2026-08-07 16:00:38

想在哪些情况下，因为我觉得它也是可以参考Bommo那种模式，因为它在全局的模式下都能看到一些比较有意思的状态。然后我觉得这个APP它主要形式它应该是维护这些联系人，所以联系人就像它一个核心的资源

我觉得它页面结构完全就是可以以联系人为主导，然后AI在全局是一个辅助作用。也就是说，AI它应该就放在下边的导航栏，然后搜索的话也应该放在下边的导航栏

然后我觉得添加的话，不是一个高频场景了，它应该是放在主页的一些右边吧，这样的话可能更好一些

我不是很确定，就是对于用户来说是否会有多种身份

2026-08-07 16:09:48 · #ailoha

我不是很确定，就是对于用户来说是否会有多种身份。但是就我自己思考来说，我觉得前期可以不用考虑太多，因为对于大部分来说，他可能生活中还是一个角色，这部分可能前期设计略有，尽可能想要去精简，并且非常具有审美的页面

所以我觉得他主页尽可能还是类似于Notion那种，非常有品味和丝滑度

然后我觉得它应该也是要允许添加 favorites 显示在最前方，符合用户的直觉

我发现就是慢慢的生成UI这个场景来说

2026-08-07 17:32:35 · #ailoha

我发现就是慢慢的生成UI这个场景来说，如果没有交互的话，最开始如果只是确定几个功能的话，实际上没有必要去搞一些那个什么高精度图，或者是其他的什么各种UI图，或者是各种交互式的类型网页、Demo，我觉得都没有必要。我觉得最简单就是确定需求，然后确定功能，确定一些用户第一眼看到的画面，然后针对这些画面去让它直接生成一个图片

考虑是可以做联系人的关系

2026-08-07 19:00:48 · #ailoha

but 感觉实体之间的联系，应该先确定的是实体

不如先把联系人的部分做好

用户指标 / 产品约束

2026-08-07 19:21:52 · #ailoha

用户是谁： 猎头 / 销售… 关于自己的资源

核心任务： 所有平台的截图 / 文字/ pdf 全部统一处理为联系人的数据

成功指标： 程序正常，能正确的处理数据信息，用户信息，，给出好的反馈，结合这个人的风格，用户可以对资源进行处理、维护、更新、查找

有时候要考虑群聊的情况

2026-08-07 19:22:47 · #ailoha

微信中去识别群聊的效果

记忆投毒（Memory Poisoning）：攻击者

2026-08-07 20:33:07 · #ailoha

记忆投毒（Memory Poisoning）：攻击者往记忆里塞假信息，实验注入成功率超过 95%。所以写入前一定要校验来源，不能让任何人都能写

精心伪装成内容变形的滚动舞台

2026-08-08 09:36:13 · #ailoha

精心伪装成内容变形的滚动舞台

agent /

2026-08-08 22:12:24

codex 指数回退

幂等键是地基,对账优先于盲目重试,错误分类决定要不要重试，而不是所有失败都一视同仁地退避重试

cc 类似

input thinks

2026-08-08 22:31:20 · #ailoha

IOS 快捷

多图片截图 / 多平台适配

浏览器插件

web 端

蜘蛛侠

2026-08-09 10:57:20 · #ailoha

最感动的是黑珍珠

感觉黑寡妇的一生很传奇

她很像我熟悉的一个朋友

从小经历过一些残酷的训练，被特工计划选中

手上背负着不少的暗杀名单

后面叛逃成为顶尖特工

顶级近身格斗与暗杀技巧、精通多国语言、擅长伪装与渗透、心理操控与审讯（能反向操纵对方套出情报）

表面冷静、克制、话不多，甚至带点讽刺幽默感；内心其实背负着强烈的负罪感和自我怀疑，一直想为过去做的事赎罪。

是团队里的"黏合剂"角色——擅长安抚队友情绪、化解冲突（比如安慰浩克、劝说鹰眼），有很强的责任感和牺牲精神。

最终在《终局之战》中为了拿到灵魂宝石（必须以挚爱之人的牺牲为代价）主动选择跳下悬崖牺牲自己，完成了她多年寻求的救赎。

有一个增长期的问题是值得考量的

2026-08-09 14:59:01 · #ailoha

我觉得有一个增长期的问题是值得考量的，就比如说我们在去设计这个 Workspace 的时候，它会不会涉及到就是一个小型团队的真实需求。它可能会是一个，比如说他会额外聘请一个猎头去，就是去做一些候选人的管理。但也有可能是这个 CEO 自己本身他会有一些候选人，或是产品经理会物色一些候选人，把他们在不同平台里面的一些 context，然后汇集到一起。它可能是一个在针对团队模式的一种真实需求

而且我觉得还有一种更强的可能，就是针对特殊的场景。就比如说，可能会有一些销售类型的，他同样服务于好几个甲方公司。当然还有一种就是关于猎头，他可能也会服务于好几种独立的公司。然后他更想做的是针对不同公司，他自己候选人是隔离性很强的，就最好相互之间都没有任何的污染性。那么这时候他自己可以创建一个工作区，就比如说他可以创建一个 Workspace，就关于公司一的，那么他再去创建一个公司二的 Workspace 的时候，他后面就可以添加一些候选人列表，然后我相互选列表如果是，就是在某一个 workspace 的时候，它可以受限于这个 workspace。所以我觉得 workspace 的空间还是蛮大的，它相比较而言可能是一个扩展性非常强的，类似于 projects

这好像也只有一条路，就是抱为一团，结合为一个整体

2026-08-09 15:56:31 · #ailoha

这好像也只有一条路，就是抱为一团，结合为一个整体，自己 owner，完成目标

拥抱不确定性，一直干，风险偏好者

所以他目标应该是尽可能去完成目标，不要浪费别人的时间

2026-08-09 16:00:20 · #ailoha

所以他目标应该是尽可能去完成目标，不要浪费别人的时间

现在没有想到自己潜移默化的也会去影响哪一些人

2026-08-09 17:21:24 · #ailoha

现在没有想到自己潜移默化的也会去影响哪一些人，我觉得这样真的挺开心的

我到现在大概对团队有一些本质的理解了

2026-08-09 21:56:20 · #ailoha

管理团队，也是向上管理

本质上管理的是一个目标 goal

所有的人都不是零和博弈，而是共赢的

大家的目标就只有一个，就是赢 ～

所以去尝试打开所有的人边界，理解他们的能力，管理他们

突然意识到了所有的人都是有自己的能力边界的

理清楚关系，需求，网络和目标

并且完成目标，这是我们的任务

目标一致，而不是观点一致

2026-08-09 22:04:43 · #ailoha

共享上下文，而不是所有的人一起做所有的事情

相互补位，但是每一个结果仍然有一个明确的 Owner

用于提出坏消息，而不是用忠诚感掩盖问题

我要做到最好

2026-08-09 22:37:42 · #ailoha

我的目的是要做到最牛逼的产品

商业化的产品 ！！！！ 我要学习 ～～～

我要赢，我要比他们还想赢 ～

我要记录自己会赢

原来经历过痛苦

2026-08-10 00:23:50 · #ailoha

经历过时代的快速变化

所有的人匆匆而来，匆匆而去

即使游戏中的人物匆匆而来，匆匆而去

我也希望可以真诚的和你们度过一段宝贵的时光

产品 / 技术的其他地方

2026-08-10 14:53:39 · #ailoha

成员 / 各自的优势

仓库分析理解

基本的配置

agent - ai 项目是给 agent写的

查看和学习项目，理解 IOS 到底是有哪些的需求和痛点

然后每天站会的时候然后要去还要去解决的问题就是一些用户反馈的一些问题。站会的话就是 11 点

入职 ailoha

2026-08-10 16:04:26 · #ailoha

感觉节奏是巨快的

第一次遇到这么快的节奏

hi，深度分析，我是新同学 我第一次进入到的

2026-08-10 16:20:40 · #ailoha

hi，深度分析，我是新同学 我第一次进入到的 alloha 团队，我希望你可以帮我配置好整个项目团队关于自己的知识库，组织，每日的工作任务，工作区，以及原始数据的 wiki 包括每日的一些计划，行动，我希望这个仓库作为我的日常的管理的中心大脑 ，我希望不仅仅是技术的身份， 而是整个技术、产品，以及结合 /Users/cubxxw/date 目录仓库的一些信息，包括各个需要的子目录，以及一些额外的文档的目录，以及项目的自动化

全程的浏览器和自动化可以用 kimi 浏览器插件去做

团队的管理围绕着 https://linear.app/ailoha-ai/team/AIL/projects/all 做项目管理，以及围绕着 github 做项目协作，围绕飞书做日常的视频会议，系统，文档协作

飞书你可以深度的查看飞书文档的内容，飞书的人员信息，各个人帮我都存到为独立的 wiki ，存放他们的能力边界，和详细的信息

我发现当前设置场景模式截图之后好像有问题

2026-08-11 00:01:24 · #ailoha

我发现当前设置场景模式截图之后好像有问题，一个就是我觉得它上面显示的问题，就一直就是显示这个灵动岛，就有点干扰我的视野。另外一个我觉得是在真实截图的时候，比如说在当前聊天框里面截图，然后当前截完图之后立马返回，然后发现这个截图还有延迟，这个我感觉挺神奇的，就这个场景模式截图

目前他们最大的问题还是整套设计文档或者是项目文档

2026-08-11 09:53:19

我觉得目前他们最大的问题还是整套设计文档或者是项目文档，它的认知成本太高

对于一些整个生态的体系，就对于 ai节点的边界处理的没有那么到位

而且我觉得还有一个问题，就是它的生态目前还是非常依赖于 AI 去做的，但是这个门可能会造成大量的重复工作，还有就是修理的任务

但我觉得还是应该设立好边界，就是清楚，一个人的边界，但是不是 AI 的边界。然后在此基础上去通过一种 AI 一些 AI 这样的能力去约束，让你的项目规范到合理的方向去运转

Claude agent sdk 流式问题 / 紧急

2026-08-11 11:02:29 · #ailoha

RC

IOS 前端的一系列问题

e2e 的问题

关于两个人物，本质上也是一个任务

2026-08-11 14:22:10 · #ailoha

关于两个人物，本质上也是一个任务，螺旋上升完成整个系统的优化

使用 Loop engineering 的方式深度挖掘和执行

目标驱动（找到一个好的目标和问题）

目标驱动的持续循环，设定一个可以验证的完成目标，（“所有测试通过并提交”“功能列表全部完成”等）

agent 每完成一轮后，另外的一个轻量模型检查条件是否满足（不知道是否可以同一个模型去验证纠正？）

外部的状态 + 进度文件，解决上下文窗口限制

Agent 自己跑测试、lint、build、甚至 Playwright 截图对比

失败就自己去修复，一直到完全绿色

的现在的时间的安排，基本上就是设计 Loop 本身，以及验证的条件，角色的边界，Claude 的文件

设定前期的探索的方向和批准的计划

然后遇到一些我异常的话就去干预，被跑断的时候打断

最终要实现的目标：

人写linear ，或者自然语言描述

Manager Agent 自动： 分析 -> 出 Plan -> 人轻量审批

并行 agent： 实现 + 写测试 + 安全审查

本地 / 云端 Loop 直到测试绿

正确的实践，不应该去写代码，而是百分之三十的时间做最难的架构/ 0->1 决策

百分之三十的时间排产品和优先级

百分之三十的实践做调度和管理 agent 团队

最开始，完善自己的上下文，同时也是了解项目的上下文

结合需求去提出更多的问题，问题升维

从 ticket → 实现 → 测试 → 审查 → 构建 → 分发 → 监控 → 自动修，全是 loop，不是单向流水线

架构的目的无非是两个

2026-08-11 18:57:53 · #ailoha

人清晰合适颗粒度的 contexts

以及更好的设计 Evals

Skills 的话，可以被 AI 执行，并且版本化管理的 SOP

所以什么时候写 Skills ，就是当这个经验成熟的时候，可以使用这一套 SOP

这样想来，为什么要重构前端

2026-08-11 19:11:23 · #ailoha

以及为什么要重构 CICD

无非想的还是整套设计的优化重构，从设计出发入手，思考有什么深度的重构的空间

/goal OpenClaw 本身就是本地

2026-08-11 22:51:17

/goal OpenClaw 本身就是本地 Agent 运行时，可以把整个 Obsidian Vault 或某个子目录当作 workspace。

官方有 openclaw-lark / 飞书 Channel 插件，能直接在飞书里对话。

社区有人已经在做「OpenClaw 读本地笔记 → 飞书推送日报/问答」。

你可以：

指定一个本地目录（或 Vault 子文件夹）作为该 Agent 的知识源

写好 System Prompt（人格、说话风格、回答边界）

通过飞书机器人对外服务

相关：

官方飞书插件：larksuite/openclaw-lark

社区桥接：m1heng/clawdbot-feishu（支持动态 Agent、workspace 隔离）

Obsidian 深度结合：obclaw（专门把内容整理进 Obsidian，并支持飞书入口）

深度思考，我希望你去认真的调研一下当前整个市场目前的形态是什么样子。然后我希望你最后还是以Codex 集成 LLM 作为基础的组件， 深度的去分析设计，完成整个项目的设计，最终达到一个可以部署，常驻的效果，并且集成集成一系列的 agent 能力和适合的 skills ，集成飞书，以及我希望它面向飞书的主要是一些同事艾特我情况下，去结合这个Agent以及本地的知识库去深度的分析，以及给出一系列的嗯可以用的skill。本质上也可以用Codex的parsing能力，但是如果是一些非常出格的，就比如说涉及到一些隐私和密钥的东西。如果对方是通过飞书的方式问你询问的话，你需要拒绝掉，你可以设置一个hook

然后对应的codex以及本地的一些skill你都可以重用，本地的知识库你也都可以通用，能用很多的能力

linear 的前后端的问题

2026-08-12 10:54:03

agent 部分需要放在 linear agent 部分

aha

2026-08-12 14:44:37 · #ailoha

浏览器插件，作为一个 agent / skills

可插拔，针对一些类似社交的平台，做一种可插拔的效果

新同学快速上手，首先是理清楚整个的人的项目的结构

2026-08-13 14:38:47

新同学快速上手，首先是理清楚整个的人的项目的结构，业务流程整个过程中发生了什么

最好能在这个过程中 AI 去引导新同学发现一系列的问题和 bug

然后 AI 可以在这个问题中给予解决

最小的 looop

2026-08-13 16:58:28

把现在的：

Claude → 启动 Actor → 理解 datasetId → 再取 dataset → 判断结果

改成：

Claude → research_search → 直接得到真实人物记录或明确失败状态

几个问题，现在的暴露出来的三个

2026-08-14 00:53:31

apify_linkedin_name_search

apify_linkedin_structured_search apify_linkedin_profile_scraper

Actor 应该是 apify 的基础设施 不应该都暴露给 agnet

不合理，可以统一的封装为同一个 search_person() 对于 agent 来说

cat src/ailoha_agent/agent/prompts/skills/person-profile-analyzer/skill.md

Person Identity Resolution 不够好，里面有

canonical name aliases company title

但是问题最大的是你找到的是不是这个人，

应该引入 Identity Resolution Score，搞一些 confidence 去测评，避免张冠李戴

prompt 里面继续调节的，加一些中文的社群，现在 linkedin 太多了， 还是需要 agent 中灵活的插入中国的社交的平台

姓名搜索

2026-08-14 14:52:49

姓名搜索 现在搜索一个人时，会把姓名、公司、岗位和地区一起交给 Provider 搜索。 如果这个人已经换了公司，旧公司就会把他过滤掉。 如果这个人已经换了岗位，旧岗位也会把他过滤掉。 一旦正确的人没有进入候选名单，后面的打分和排序做得再好也没有用。 解决办法是，始终单独执行一次只带姓名的搜索。 公司、岗位和地区不再限制姓名搜索。 这些信息只用来帮助后面排序。

别名搜索 同一个人在不同地方使用的名字可能不一样。 比如中文名是“高利明”，LinkedIn 上可能写的是“Liming Gao”。 现在只有姓名搜索没有结果，或者结果很差时，才会尝试第一个别名。 如果姓名搜索返回了一些错误的同名人物，别名搜索可能根本不会执行。 解决办法是，把每个确认过的别名都当成一条独立的搜索路线。 姓名搜索有结果，也要继续执行别名搜索。 只使用用户提供或已经确认过的别名，不让系统随便猜名字。

公司和岗位搜索 只用姓名搜索时，可能会找到很多同名的人。 如果知道这个人的公司或岗位，就可以再搜索一次“姓名 + 公司”或者“姓名 + 岗位”。 现在这条路线只是备用路线。 它还可能因为别名路线已经执行而被跳过。 解决办法是，只要公司或岗位比较可靠，就单独执行一次上下文搜索。 这条路线不再依赖姓名搜索有没有结果。 它也不再和别名搜索二选一。 姓名搜索负责不漏人。 公司和岗位搜索负责在同名人物中找到更相关的人。

合并搜索结果 同一个人可能同时被姓名、别名和公司三条路线找到。 现在系统会按照 LinkedIn URL 把重复的人合并。 但是合并以后，系统可能只记得一个排名。 这样就看不出来这个人其实被多条路线共同找到。 解决办法是，合并人物时保留每条路线的排名。 例如，这个人在姓名搜索中排第六，在别名搜索中排第一，在公司搜索中排第二。 多条路线都找到同一个人，说明这个人更值得排在前面。 同时还要完整保留 Provider 返回的公司、岗位、历史经历、地区和学校等信息。

当前经历和历史经历 一个人现在的公司和以前的公司不能混在一起。 用户说的公司，可能是他现在的公司，也可能是他以前工作过的公司。 如果候选人现在去了新公司，不能因为当前公司不同，就直接认为不是同一个人。 解决办法是，把当前经历和历史经历分开保存。 当前公司一致，可以作为比较强的证据。 历史公司一致，也可以作为证据，但不能当成当前公司一致。 如果候选人没有填写公司信息，只能说明我们不知道。 不知道不等于不匹配。 只有出现明确而且可靠的矛盾，才算冲突。

候选人排序 搜索结果排在第一，不代表他一定就是用户要找的人。 Provider 的排名只能说明这个结果比较相关。 它不能直接证明两个人是同一个人。 解决办法是，结合姓名、别名、当前公司、历史公司、岗位、地区和学校一起判断。 姓名一致是最基本的条件。 公司、岗位、地区和学校用来进一步区分同名人物。 多条搜索路线共同找到，也可以帮助提升排名。 但是路线排名不能代替身份判断。

Strong 判断 如果系统只知道一个姓名，就不能确认搜索结果一定是本人。 即使第一名的姓名完全一致，也可能还有很多同名的人。 解决办法是，只有姓名时不能判断为 strong。 除了姓名以外，还需要公司、岗位、地区或学校等其他证据。 第一名还必须和第二名有明显差距。 如果候选人之间差别不大，系统就不要强行选择。

展示 Top 3 当系统无法确定哪一个是正确的人时，应该把最可能的三个人展示给用户。 不能只展示第一名，让用户误以为系统已经确认。 解决办法是，根据 Top 3 的差异提出一个最有用的问题。 如果三个人的公司不同，就询问公司。 如果公司相同但岗位不同，就询问岗位。 如果公司和岗位都相似，就询问地区或学校。 如果这些信息还是无法区分，就让用户直接查看三个 LinkedIn 主页进行确认。 最简单的总结 先只用姓名搜索一次，保证不要漏掉正确的人。 再用别名搜索，解决不同名字找不到的问题。 再用公司和岗位搜索，帮助区分同名的人。 把所有搜索结果合并起来，但保留每条路线的排名和证据。 最后根据当前经历、历史经历、岗位、地区和学校进行排序。 有足够证据时推荐最可能的人。 证据不足时展示 Top 3，让用户自己确认。 最重要的一句话是： 先保证正确的人能够进入候选名单，再考虑谁应该排在第一；如果人都没有搜出来，后面的评分和排序就没有任何意义。

ailoha 设计 kiwi 访谈

2026-08-14 21:28:15

是的，而且我现在觉得我比刚才更准确地 get 到了。

奇意想做的，并不是一个“帮你处理人际关系的 AI 助手”，甚至也不只是 Relationship Intelligence。她真正想做的，是给 AI 构建一个关于“人”的环境：让 AI 不只是越来越擅长数学、Coding、搜索和生产力，而是开始理解人与人之间那些复杂、模糊、长期、无法被标准答案验证的关系。

她自己其实用了一个很好的类比：Claude Code 的价值，不只是“模型会写代码”，而是它给模型搭了一个 coding 的 environment——有 context、有工具、有长期任务、有人的反馈和 verification。奇意想做的事情，本质上类似：如果 Coding 可以给 AI 造一个环境，那么 human interaction 为什么不能？

我理解这件事有四层。

第一层，是最表面的产品：一个“外挂的关系记忆”。

它帮你记住一个人说过什么、在意什么，你们过去发生过什么，并从这些碎片里理解关系的上下文。比如你给她分享马修·麦康纳的视频，Ailoha 不只是记住“王慧分享了一个视频”，而是发现你分享链接的时间戳恰好落在“如何在噪音中寻找意义”那一段，于是把这个细节与你当时正在思考的问题联系起来。

所以最初的产品体验很像：

AI 帮我记住别人，从而让我成为一个更好的朋友、同事、父母、伴侣。

但这只是入口。

第二层，是一个 relationship copilot：帮助你理解关系，而不是替你拥有关系。

这里是她和很多 AI companion 产品最根本的区别。

现在很多 AI 产品隐含的方向是：真人太麻烦、摩擦太大，AI 又聪明、耐心、永远回应我，那我为什么还要跟人打交道？

奇意对这个方向其实是警惕的。

她认为 AI 有一种非常隐蔽的 sycophancy：它越来越理解你以后，很容易抓住你真正渴望相信的东西，再帮你把它合理化。久而久之，你可能形成一个看起来信息无限丰富、实际上仍然围绕自己旋转的茧房。

所以她不是想做：

AI → 替代人与人的关系

而是：

AI → 帮助你理解关系 → 让你重新回到真实世界与另一个主体互动 → 把真实互动的结果带回来 → 再修正 AI 对这段关系的理解。

也就是说，真正的 verifier 不是 AI，而是另一个人。

这一点我觉得非常关键。她明确说，AI 给你的分析和建议无法自己完成验证，最终必须由你回到现实世界，在真实关系中践行和验证。

所以它不是 emotional companion。

甚至某种程度上，它是在做 anti-companion：

不是让 AI 成为那个最懂你的人，而是让 AI 帮助你更好地理解那些你真正爱、在意、需要共同生活的人。

第三层，才是她真正的 AI thesis：今天我们对“智能”的定义太窄了。

这是我觉得最能解释她为什么非得创业的地方。

现在整个 AI 世界的主流训练方向，都在奖励：

数学、Coding、Science、Reasoning、工具调用、任务完成效率……

这些当然都是 intelligence。

但她认为 intelligence 不应该只有这一种形态。人的智能还包括：

理解别人； 理解情境； 理解含混的意图； 记住关系历史； 知道一句话在不同关系里意味着完全不同的东西； 理解冲突； 理解信任； 理解什么时候应该推进，什么时候应该退后。

这些事情几乎都不存在一个标准答案，也很难像数学题、代码一样自动 verify。

所以她真正想问的是：

我们能不能给 AI 建一个新的 environment，让人与人之间真实发生的 interaction，成为模型理解“关系智能”的训练场和验证场？

这也是为什么她说，希望把 AGI 的发展方向从今天高度偏向理性、数学、Coding、Science 的方向，往更人文的方向“挪 0.5 度”。

我觉得这句话其实比“Relationship Intelligence”更接近她真正想做的事情。

第四层，是一个很大的长期想象：Ailoha 不是“套壳”，而可能成为 human interaction 的 environment。

这也是她明知道大家会说“套壳”，依然说“壳很重要”的原因。

她并不认为护城河一定来自“我有一个别人没有的大模型”。她在赌的是：

随着基础模型越来越强，真正稀缺的可能变成——

模型处在什么 environment 里？ 它拥有什么 context？ 它如何和人持续交互？ 谁给它提供真实世界的 verification？

Coding 世界产生了 Claude Code 这样的环境。

那人际关系世界有没有可能也产生一个这样的环境？

而且关系的特殊之处在于，它天然产生大量目前基础模型没有的、非常难获得的 out-of-distribution intelligence：因为每一段真实关系都是开放的、动态的、私人化的，也没有标准答案。她认为人与 AI、人与人的循环互动，可以不断给这个系统提供新的 verification。

所以如果让我替她把这家公司最底层的 ambition 压缩成一句话，我现在会写成：

Ailoha 想做的，不是一个更懂你的 AI，而是给 AI 建造一个理解“人”的环境。

或者更有哲学意味一点：

当所有人都在教 AI 如何完成任务，她想教 AI 如何理解人。

再进一步，甚至可以是：

她想做的不是用 AI 替代关系，而是让人与人的关系，成为 AI 获得另一种智能的地方。

我觉得这才是奇意这家公司真正有意思的地方。也正因为这样，之前我们想的那些“女性投资人转型创业”的标题，其实还是有点小了——她的人物故事很精彩，但她正在押注的 AI 命题，本身可能更值得成为这期播客的标题中心。

对齐颗粒度：skill层的结构性缺陷

2026-08-16 17:24:23 · #方法论/对齐颗粒度 #AI产品

团队协作中最隐蔽的低效不是沟通频率不够，而是颗粒度不对齐——同一个任务，不同人脑子里的分解粒度不同，导致交付物永远对不上预期。

这不是沟通问题，是skill层的结构性缺陷：

没有显性化的流程 → 每次靠个人经验重新发明 没有统一的eval标准 → 好坏全凭主观判断 没有可复用的case库 → 知识不积累

真正的杠杆点不在于「更多沟通」，而在于把隐性的对齐过程变成可检验的skill。

我的目标希望做出来一个顶级的产品

2026-08-17 10:15:47

要想做出来顶级的产品，必须要去顶级的团队，接受顶级的思维的训练，找到本质的原因，并且解决

向上管理的本质是对自己的管理，管理自己的目标和任务，可靠的完成

eval 的全量数据，整理

2026-08-17 10:57:05

eval 的全量数据，整理

完成标准， eval 平台

2026-08-17 11:03:41

完成标准， eval 平台？

我发现声明式的编程很适合 AI 时代的

2026-08-17 12:39:52

我发现声明式的编程很适合 AI 时代的 coding 的过程

清晰输入和输出，然后不断的完成这个过程，优化这个链路

而不是想清楚这个错误是什么，然后去解决？

LinkedIn Actor

2026-08-17 15:36:30

X/Twitter 用户动态、帖子、线程、搜索

Instagram Profile、帖子、Reels、评论

Facebook Page、帖子、广告资料库

TikTok Profile、视频、话题

YouTube Channel、视频、字幕、评论

Reddit 用户、帖子、社区和评论（目前也是高质量的）

Google 搜索结果、Google Maps 公司资料

通用网页 Website Content Crawler、RAG Web Browser

AND 即刻 、 小红书

有些启发

2026-08-17 19:07:20

Bench 单位未必要是传统的工程组件化单位视角

而是agent视角

IdentityCase 就是给定人物线索，系统能否找到正确身份，并安全、可追溯地使用这个身份

这组比纯 LinkedIn 检索更适合测

2026-08-18 10:06:48

这组比纯 LinkedIn 检索更适合测 Agent 最终有没有污染联系人数

据：

崔添翼 vs 庄天翼：公开产品内容和人物事实是否混写。井琳 vs 孙天祥：消息来源和融资传闻主体是否分开。佳妮/Not-Sylvia vs 舒爽：是否把两个人错误合并。杨坚丽 vs 贺大玮/潘思铭：引荐人、被介绍人和公开职业事实是

否正确归属。

杨坚丽误关联：用户报告通讯录污染后，是否还会继续更新错人。王冠 vs 瓦恁：三张截图、多人物、直接聊天和转述事实归属。MOBAI：日历确认与联系人更新是否分开。赵晨阳：公开产品帖是否被错误写成个人 Profile/Notes。庄天翼：敏感融资卡片是否保持不写入。詹青云/珍妮特·温特森：活动海报人物是否被自动当成联系人。

这 10 个已经全部可评分：

严格策略通过：6/10最终执行安全：7/10其中佳妮/舒爽、杨坚丽/贺大玮、王冠/瓦恁三例是 Agent 辅助裁

决，升级长期 benchmark 前建议业务 owner 再签一次。

完整 Gold 在 /Users/cubxxw/date/Ailoha-ai/private-eval/2026-

08-17-kiwi-person-images/reports/goldevalcases_v0.jsonl。

二、最值得补一轮人工确认的 6 人

这批已经非常接近高质量 Gold，投入产出比最高：

人物 价值

━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Chris Oneil 历史里用户明确说“就是他”，非常适合测搜索→确

认→写入状态分离

───────────── ──────────────────────────────────────────────

孙凯一 中文名、拼音、英文 alias、Tencent/Stanford/

公司线索联合召回

───────────── ──────────────────────────────────────────────

许秀娟 同名、复旦、KTB、历史公司、隐私化英文名

───────────── ──────────────────────────────────────────────

王金刚 姓名+LongCat 团队，适合测唯一候选和错误职位

纠正

───────────── ──────────────────────────────────────────────

王照涵 GitHub 协作被误判为雇佣关系，适合测弱推断被

第一方资料推翻

───────────── ──────────────────────────────────────────────

杨坚丽 已发生真实错人和错误 memory 召回，适合测纠错

后是否真正清除污染

其中前四个是 stronggoldcandidate，后两个是

strongcorrectiongold。这六个一旦完成正确 Profile URL/事实快

照确认，会比继续随机增加普通人物更有价值。

三、可以立即做“不该搜索”测试的人物

这组不需要 LinkedIn Gold，因为正确答案就是不搜索或保持歧义：

美团思琦：只有名字和公司，没有姓氏/部门，应该追问。Vibe 的 White/Kiwi 团队成员：身份已知，不应重复搜索。已确认联系人收到 LinkedIn 请求：出现“LinkedIn”不代表要搜

人。

刘牧 Sirius：信息已经足够创建草稿，不需要人物研究。Jennifer(a16z)/Raft 团队：核心是会议和互动同步。蒋哲君等已知联系人：批量更新，不应重新做人肉搜索。“Aloha/翻咔”软件：同名对象是产品，不是人。阴明：禁止根据罕见姓氏猜测敏感家庭关系。

这组非常适合测：

search_person 是否被滥用。无线索时是否追问。已知联系人是否被重复搜索。是否把概念、公司、产品当成人。是否产生敏感身份推断。

四、值得保留但还不能正式评分的人物

需要补正确身份 Gold

Patrick：伦敦投资人、投过 Manus/Plaud。许维：湖畔招生负责人。谢伟：离职后的 current/former employer。曹尉：多轮补充历史雇主后才出现候选。

需要事实或来源裁决

李茜/曹尉：可能离职属于传闻，不能覆盖 current employer。曾歆勋：LinkedIn 陈旧，新闻与其它来源描述了后续创业。崔添翼：人物研究和 DeepSeek 技术内容需要先拆成两个 case。陈伟嘉：人物、客户关系和夜宵事件需要拆开评分。

这些适合做诊断集，但暂时不能放进 Champion 晋升门禁。

五、生产图片池里还能提取的人物

34 个生产任务、47 张原图中，首轮还有 17 个标准 Gold 候选：

李井瑞/聪聪舒爽/猫仔孙凯金淦Anqi ChenKathyRyan（两组任务）Chris OneilJulian/丁志远（两组任务）刘牧牛立思琦金宇

这些目前适合测截图读取、联系人识别、事件抽取和 Widget；如果要

测 LinkedIn Recall，还需要给每人补正确 URL Gold。

另外还有：

12 个多人/群聊/引荐/别名特殊案例。4 个融资、手机号等高敏案例。1 个赵晨阳公开产品帖负样本。

完整盘点见 /Users/cubxxw/date/Ailoha-ai/private-eval/2026-08-

17-kiwi-person-images/reports/README.md。

六、公共人物压力测试集

还有 50 条公开人物候选，适合低隐私、可重复的搜索压力测试。目

前仍是 proposed catalog，不应直接作为正式生产 Gold。

最值得先拿出的 12 条是：

王兴兴：重复名、拼音、前雇主。余凯：常见名和姓名顺序。王坚：身份能确认，但 current role 不安全。姚期智：四种姓名和超长时间线。汪滔：Frank Wang 碰撞及“汪/王”差异。李想：人名、普通词、汽车品牌意图碰撞。Ilya Sutskever：权威个人页陈旧。Demis Hassabis：几天级职位变化。Jeff Dean：同一机构官方页面冲突。Alexandr Wang：短名、跨领域撞名、职位变化。Chris Anderson：科技圈内完全同名。“王伟，在北京做 AI”：正确行为是追问，不是猜人。

目录在 /Users/cubxxw/date/Ailoha-ai/.codex-worktrees/ail-546-

linear-minimal-v2/ailoha-agent/evals/fixtures/

ail546publiccasecatalog.md。

我建议的第一批正式测试名单

如果现在只选一批最有价值的，我建议分成三组：

检索质量：金淦、王锐、习翔宇、Chris Oneil、孙凯一、许秀

娟、王金刚。

Agent/Memory 安全：佳妮/舒爽、杨坚丽/贺大玮、王冠/瓦恁、赵

晨阳、井琳/孙天祥、庄天翼。

路由负样本：思琦、刘牧、Vibe 团队成员、Aloha 软件、王伟模

糊输入。

开始的问题本质，json to

2026-08-18 11:52:37

开始的问题本质，json to linedin-by-name，gold top13 NO

本质上确定稳定保证每次 Agent 都正确拆姓名、选择 Actor、翻页、轮询 Dataset、合并重复 URL、区分当前/历史职位、统一排序，并且在身份不确定时绝不写错 Contact

Full structured 有条件的 fallback

Short 中文姓名 page 1 → Jin Gan / Gan Jin variant → 必要时中文姓名扩页 → 必要时 relaxed → 有可靠 company/title/location 才允许 structured Full=（内部工具判断，可以真实测试优化工具，现在主要是 context 召回的）

TOP1 是 plausible（60） 或 strong（80） 就停止后续搜索，都需要用户确认

TOP1 任然是 weak， 继续搜索

Top1 分数足够

有至少两个独立身份线索

没有关键冲突

和 Top2 有明显差距

关键字段覆盖足够 → 才停止

context 问题： 传递的信息有限

可以通过 Bench ， Smoke test 优化：

Recall

Candidate

…

ps:

如果信息不足 agent 询问用户补充的

如果 profile 冲突，agent 自己判断或者用户判断

Weak:

2026-08-18 12:12:19

如果 agent 传入英文 、拼音情况下（Gan Jin 和 Jin Gan 都搜索）

Strict 扩页，Relaxed 搜索，告诉 Apify 放宽内部匹配

扩页规则： 只有 strong 情况下停止

Relaxed 搜索：Actor 放宽内部限制，

Context 结构化搜索，包括下面的字段：

{

“profileScraperMode”: “Full”,

“searchQuery”: “金淦 某公司 Founder 上海”,

“locations”: [“上海”],

“currentJobTitles”: [“Founder”],

“maxItems”: 20

}

SerpAPI 兜底： agent 可以调用，但是确保 Serp url 一定回到统一的候选池里验证

任 weak ，返回 top10

eval smock test

2026-08-18 17:11:26

review notion

集成 EXA

other

eval 测试量化数据集，关于 agent

2026-08-18 18:51:20

eval 测试量化数据集，关于 agent 召回率的问题

一些干净和准确的数据，以及答案

LLM 输出

今天必须要把测试和数据集处理好

goal 指标：

2026-08-18 19:59:52

新的 Exa 测试的情况

以及整个平台的 evaluation 的搭建的情况

然后结合 evaluation 的搭建完成整个任务

所以现在目标应该改过来。我觉得与其是证明自己

2026-08-18 20:59:35

所以现在目标应该改过来。我觉得与其是证明自己，或者是让他们一起成功

倒不如是在这个过程中，反复地训练自己，训练自己的绝境能力，学习能力，成长能力

Aout search social

2026-08-19 12:04:13

Aout search social evidence： 这个人最近在想什么，做什么，关注什么的工具

LLM 意图： 确定这个人身份 、 搜索这个人的信息

如何让 Agent 真的知道自己是否搜得足够的好

2026-08-19 18:07:05

给 search_social_content 内部增加四个能力：

Provider bake-off 与离线评测系统。

结构化“证据语义”，区分作者原话、引用、转发和评论。

两阶段检索：宽召回 → 正文补全 → 多语言重排。

按“能力路线”治理，而不仅是按“平台 Adapter”治理。

但我觉得还有一点是比较认，比较有意思

2026-08-20 00:26:58

但我觉得还有一点是比较认，比较有意思，就是他提到的就是关于具象和抽象之间关系，就是抽象一定要由具象而得来的，不然的话就是犹如空中楼阁

大量具象经验 → 识别重复模式 → 提炼共同结构 → 形成抽象模型 → 反过来指导具象实践

一个没有写过真正的大型系统的人，直接学习一些大型的技术，很容易变成背概念

但是他并不知道什么样的边界是稳定的，哪些抽象是过度设计的， 什么情况下应该拆分

反而言之，一个有多年工程经验的人，抽象是有重量的

没有做过 Agent ，就觉得 memory 很重要

做过 agent 会发现什么样的更应该保存，memory 是 agent 状态管理的一部分，而不是简单的知识库

现实问题

↓

具象实践

↓

遇到大量边界情况

↓

抽象规律

↓

形成模型

↓

指导新的实践

↓

修正模型

最开始 agent sdk 按照大致的人物画像去分类

2026-08-20 09:01:46

一个美国 AI Founder：

LinkedIn → X → YouTube → Reddit → Instagram

一个学者：

Google Scholar / Semantic Scholar → LinkedIn → X → YouTube → Reddit

当然对于 AI 来说也是可以选择的

最后传递回 agent 最好也是一个结构化的数据

训练一种从复杂现实中提取不变量（invariants

2026-08-20 11:22:59

训练一种从复杂现实中提取不变量（invariants）的能力

游戏的付费策略确实是一种未来的 AI 时代为

2026-08-20 11:24:42

游戏的付费策略确实是一种未来的 AI 时代为 token 付费的很好的形式

Pi 的极简设计可以好好学习其中的思路和技巧

2026-08-20 14:34:35

关于如何划分设计 tools 工具的单元和最小边界的

tools 的颗粒度的设计哲学

搜索的本质是先广撒网，然后再深挖某一个主题 / 人物

search 便宜能并行最好，fetch 要准确

tools 颗粒度的划分最本质是按照 agent 的决策单元划分

围绕一个问题去思考，对 LLM也是： agent 在完成这个任务的时候的，是否需要在这里做一次独立的判断 / 停顿

如果两个操作几乎总是一前一后被调用、中间没有agent需要插入判断的空间，就该合并成一个工具；如果两个操作在真实使用中会被独立调用、组合方式多变，就该拆开

更少但更强大的工具比大量细粒度工具表现更好，减少agent需要发起的调用次数

具体真实而言这是一种体验的，后面可以通过 Eval 测试，具体观察 agent 的调用的轨迹， 是不是在两个相似的工具之间反复跳转的，是不是经常传错参数，是不是明明应该拆两步但是切硬塞进一次调用导致丢失了中间的信息

tools 工具的分类的一些设计哲学

2026-08-20 14:48:35

MCP自己的工具标注系统就是这个哲学最好的证据。官方定义了四个标注维度——readOnlyHint、destructiveHint、idempotentHint、openWorldHint

readOnlyHint 回答的是"能不能免确认自动跑、能不能和别的调用并行" ——服务于调度器/权限层

destructiveHint 回答的是"出错了能不能撤销、要不要人工确认"——服务于审批流程

idempotentHint 回答的是"失败了能不能安全重试"——服务于错误恢复逻辑

openWorldHint 回答的是"这个结果是不是来自不可控的外部世界、要不要打折扣验证"——服务于证据可信度评估

核心是看看代价有多大

MCP规范对没有标注的工具采取最悲观的默认假设——一个没有标注的工具会被当作可能是破坏性的、不可重试的、开放世界的。换句话说：不分类不是"中性"选项，是"最大摩擦"选项——每次调用都要人工确认、都不能并行、都不能安全重试。分类本身就是在为agent争取自主权

agent 的改进应该结合 evaluation

2026-08-20 18:22:09

agent 的改进应该结合 evaluation 去做

抛开最基本的 case 和 grader，然后其中的 trace 记录的是 agent 走了什么路径

还有就是 experiment 是把新旧版本在同一批 case 上进行公平比较，核心是回答几个问题：

agent 最终是否有没有完成用户任务

它是否选择了最正确、最短、可恢复的工具路径

每一条结论是否能回到真实的证据？ 而不是来自模型的补全

遇到空结果、部分覆盖和外部失败的时候，有没有正确的表达不确定性

改 prompt、 tools 或者模型后，正确率，成本和延迟是进步还是退化

知道自己不知道

2026-08-21 10:37:40

纯技术的场景和普通的场景是不一样的

让 AI 去学习什么样是更好的，联系人的方式去做的

agent sdk 和 下面的 api 都是一层抽象

2026-08-21 10:48:50

但是我在想如何让 agent 组件提升，就是添加一些 Eval 的过程中如何有一些比较好的效果

调试最痛苦的是，目前的 Agent

2026-08-21 14:56:14

我觉得调试最痛苦的是，目前的 Agent 它曲选择性的调用工具

关于 evaluation 设计的问题

2026-08-21 16:59:16

其中最好是以 social 为单位去设计整个链路

PR dataset，agent smoke

2026-08-21 18:57:40

PR dataset，agent smoke test

Release dataset，e2e test

Live dataset，观察可用性和 Schema

我发现现在有一个很根本的问题

2026-08-21 19:14:10

我发现现在有一个很根本的问题，就是根本就不知道这个工具它最后实现的效果如何。它不仅仅是用户需要去用，更多是它真的需要在放在可观测的 Agent 环境里面，去看一下 Agent 怎么调用的

产品从一开始的传播心智来说就很重要了

2026-08-22 11:07:50

如何让 Agent 产品真实的发挥出真正的作用

Ailoha 其实在品牌效应和命名哲学上有很多启发和思考

kiwi 在这一块的灵感和判断好丰富，kiwi 和 kimi

ailoha = aloha + AI

夏威夷岛是 Aloha，加了一个 AI 的 i，Ailoha

而且 Ailoha 本身第一次听见能复述，这个过程中就很强

而且可以自带情绪，Aloha 已有温暖的联想了，第一句话也可以讲清楚巧思，AI 进入 Aloha

是否可以匹配用户的状态

2026-08-22 19:16:13

可以记录用户的状态，也许是一个很重要的分析用户意图的方法

因为用户他可能有时候他的 context 或者是 memory 或者是 address 可能会在不同的地方，以及用户他在不同的状态下，他的 input，然后其实有可能可以作为线索，然后传递给 claude context

这个东西应该比较简单吧，因为它本质上还是传递的是用户最近的一系列信息，包括他发的时间、发的地点、发布的状态

ailoha 核心的 aha

2026-08-22 19:31:51

人物身份解析的能力

来源与时间管理

事实和推论的分离

什么应该记、什么不应过度分析

移动端捕获与事件触发

核心的能力，长期可以建立的护城河是围绕业务的 harness 系统

但是 harness 真的长期各个业务线区别很大吗？ 为什么区别很大

我觉得基本上来自 agent 在自己业务中的自进化，一些好的 case ，以及针对这些 case 的训练 ，以及 memory 系统如何设计，围绕业务的一些比较好的 skills 、tools 的能力封装，围绕用户的一些提高用户体验和实现的一些思考沉淀，什么时候用 agent teams ，什么时候用 sub agent ….

因为核心还是 agent 能力不是吗

2026-08-23 12:42:03

因为核心还是 agent 能力不是吗，页面只是服务于具体的场景的

App 更重要的也是服务于用户记录的

页面是服务于用户消费的

消费的类型和格式是不是 agent 也可以自由的发挥创造

App 是用户的长期状态与行动能力；页面只是 Agent 为当前任务临时编译出来的视图

同一份生活记录，早晨可以被编译成今日仪表盘；旅行时变成地图和时间线；低落时变成过去相似状态的对照；做月度回顾时变成叙事、图表或播客；需要行动时直接变成待办、消息草稿和日程

Google 的 A2UI 探索让 agent 输出声明式界面，再由客户端用可信组件渲染

我在想，就是对于harness的产品来说

2026-08-23 14:53:30

我在想，就是对于harness的产品来说，他们设计环境实际上是面向agent系统以及人相关，还有就是产品相关以及用户的记忆相关，然后去设计的一个场景问题。然后以至于就是AI agent可以结合这些harness去适当的去得到对应的想要的数据，然后可以在需要的时候也可以去向用户补充一些数据

产品不用排斥抽象啊

2026-08-23 15:43:53

既然 LLM 擅长抽象，那么就抽分发挥 LLM 抽象的能力

用户记录一些具象的东西，LLM 辅助自己抽象，形成系统就好了

这样的话，抽象不也是基于用户自己的具象得来的吗？

所以可以做两套系统

2026-08-23 15:49:12

一套是非常的具象化的产品，产品角度上避免过多的泛化，收敛到具体的职业，领域中

一套是非常的抽象化的产品，产品角度上要更多的容忍 agent 能力，设计 harness 环境，可以是一套通用的，围绕用户自己的产品

抽象价值与直觉 → 提出高 conviction

2026-08-23 16:14:42

抽象价值与直觉 → 提出高 conviction 假设 → 进入具体的人、产品和环境 → 被失败与反馈纠正 → 再压缩成新的抽象模型

Kiwi 有一个高度抽象、理想主义和审美驱动的认知内核，但经历了极强的现实训练；她把产品失败、人物行为、一线反馈和结果当作抽象世界观的校准

这个点真的很值得我自己去学习，我自己是很依赖抽象判断，然后扩展为系统、框架和完整解释，比较晚进入交付， 比较晚被现实修正

Kiwi 身上学到的最大的一件事情就是训练强现实反馈

2026-08-23 16:28:44

Kiwi 身上学到的最大的一件事情就是训练强现实反馈的能力

快速的洞察到问题的所在，快速的去交付和解决问题

在此之后再去反推每一次每一个的问题，完善系统，训练抽象的能力

一体化很容易带来的问题就是

2026-08-23 18:22:48

agent 卡死很容易会拖垮业务的 API 、身份持久化、工具权限容易混在一起

产品级双服务，前端 → Product Backend/Gateway → Agent Runtime → Domain API，业务事实和模型实验解耦，但是需要的处理跨服务事务、队列和协议

再到最后就是平台级分层，可扩容、可恢复、支持 HITL 和长任务

daypage 的几个问题：

2026-08-23 18:33:27

数据同步的问题打通

mcp 的设计与实现打通（确保可以接入到其他的agent 平台）

用户体验尽可能更丝滑完整体验，数据的加载速度都没有问题确保

数据存储的链路

朋友安装 DayPage

↓

邮箱 / Apple 登录

↓

记录思考和笔记

↓

先保存到手机本地 Vault

↓ 自动同步

DayPage 的 Supabase

↓

DayPage Cloud MCP

↓ 用户授权

其他 Agent / App

昨晚自己说的一些

2026-08-24 09:03:44

想不想，和急不急，是两回事。

不要把一个其实也属于自己的选择，全部解释成迫不得已。

结构决定概率，但不要让结构替自己提前宣布结局。

创业最重要的不是一个人还是一群人，而是谁更快让现实进入决策。

好的搭档不是多一双手，而是多一双你原本没有的眼睛。

人不是总分，而是能力的形状。

很多厉害的人不是完整，而是非常尖锐。

AI 越强，“执行”可能越便宜，判断什么值得执行反而越重要。

团队不是把几个完整的人放在一起，而是让几个不完整的人组成一个更完整的系统。

我可以有很强的世界观，但应该永远允许现实把它打碎。

一个人真正危险的时候，可能不是不知道，而是开始觉得自己已经把这个世界解释完了。

Claude code 和 cursor 这些的

2026-08-24 10:12:04

Claude code 和 cursor 这些的 context 或者 memroy 的问题都可以参考

一个是存储内容，一个是调用内存

思考 context 的组成的方案

ailoha 多模态的识别的问题分析

2026-08-24 14:09:09

发现现在图片的读取的问题有偏移

比如说我图像是在某个地方拍的

但是 ailoha 识别出来的是我发的两张的旅行照片

Gemini 的输出是一个有损压缩层

2026-08-24 14:21:27

原图包含一系列的

背景地标

小字号招牌

人物关系和位置

聊天气泡左右归属

两张照片之间的对比

Gemini 没注意到但用户第二轮追问的细节

对于非聊天截图来说，很多的图片可能仅仅只有文字信息和价值，可以用 content_hash + model_version + prompt_revision 缓存 Gemini 结果，避免重复识别

Claude 有需要的时候再按照需求去读取原图

Ailoha Eval 设计的很有巧思

2026-08-24 16:47:28

生产任务取证 + Agent 轨迹诊断系统

结合自己的业务有很好的适配点

以完整产品 Task 为观察单位，而不是只看单次模型 Completion。

先保存原始证据，再生成 Facts、Signals 和 Judge 结论。

确定性规则先行，LLM Judge 处理语义判断。

JSON/JSONL 服务机器处理，HTML/Markdown 服务人工审阅。

成本、缓存、工具调用、Prompt/工具指纹和副作用都属于质量。

命名保持诚实：SDK 侧记录不冒充模型供应商的 wire-level prompt。

Replay 使用测试身份，不在真实用户环境做危险的“先执行、再回滚”。

Trace 用来解释过程，Outcome 用来证明结果；Eval 的最终对象应是某个不可变候选版本在可重建任务上的多次运行结果，而不是一次回答的 Judge 分数

而且当前的 workflow 只监听 dev

如何搭建内部的 eval 平台

2026-08-24 17:21:28

最合适的设计是分成两层：稳定的“平台内核”与可由 AI 生成的“业务 Overlay”。平台内核定义不可破坏的对象、执行规则和权限边界；业务 Overlay 只描述这个业务要证明什么。以后新增联系人、日历、搜索、Coding Agent 等业务时，只更新 Overlay，不重写平台

使命声明。 本平台把非确定性 Agent 行为转换成可复现、可比较、可审计的发布决策。它必须同时回答：发生了什么、最终状态是否正确、候选版本相对基线是否退化、是否允许进入下一环境。Trace、Judge 分数或 run succeeded 都不代表质量通过；发布只能消费冻结的 Experiment Artifact。

对象声明。 平台包含七个核心对象：CaseRevision 定义输入、权限、预算和预期结果；SuiteSnapshot 冻结本次选择的 Case；BuildFingerprint 绑定代码、模型、Prompt、工具和数据；ExperimentManifest 在运行前冻结全部规则；Trial 表示一次隔离执行；Outcome 表示独立验证的最终状态；ExperimentArtifact 只追加结果、证据和 Verdict。所有 Case、Grader、Oracle、Baseline 和 Policy 都必须使用 ref@revision 或 digest，缺失或未执行统一判为 invalid_run。

执行声明。 PR 只运行快速、确定性、无 Live Secret 的 Contract/Safety Suite；FAT 在一次性身份、固定 Fixture、隔离 Runner 和显式 Reset 下运行 Baseline/Candidate 多 Trial 实验；生产只允许受风险策略约束的 Canary 和异步采样。每个 Trial 必须验证初始状态和结束状态，任何缓存、联系人、日历或历史数据都不得跨 Trial 泄漏。

评价声明。 先用代码 Grader 验证 Schema、权限、PII、工具合同、预算和禁止副作用，再用 Outcome Oracle 验证数据库及外部状态，最后用 Trace/LLM Grader 评价意图、忠实性、路径、恢复和体验。Human Gold 负责裁决歧义和校准 Judge。被测 Agent、Evaluator 和 Policy Engine 使用独立身份；Judge 只能追加评分证据，不能直接决定发布。

数据与安全声明。 Registry、Manifest、Trial、Outcome 和 Verdict 进入事务型 Metadata Store，大型 Artifact 进入不可变 Object Store；Web Pod 本地文件不能成为事实源。数据严格分成 Agent、Runner、Evaluator、Report 四个可见面，被测 Agent 永远不能读取 Hidden Oracle 或 Protected Holdout。生产 Trace 晋升 Case 前必须完成脱敏、保留期限、删除 Lineage 和人工 Gold 审核。

学习闭环声明。 事故、用户纠正、失败动作、成本异常和生产采样先进入 Candidate Inbox，通过隐私、可重建性和 Gold Review 后才晋升 Case。Case 只允许追加或 Supersede，不原地改答案；稳定 Capability Case 可以毕业进入 Regression Suite。生产发现未知失败，离线 Suite 证明修复，FAT 生成发布证据，Canary 验证真实结果。

AI 演进声明。 AI 只能生成 proposed_diff，不能直接修改 Active Contract。每次升级必须同时给出来源、理由、影响范围、兼容性、验证、成本、隐私影响、回滚和反证条件。接受 Gold、删除或重标 Case、降低覆盖率、修改 Oracle/Judge/Required Gate、开放生产权限和改变保留策略，必须经过具名 Human Gate。

EvaluationDomain:

decision: 这组评测支持什么决策

journeys: 需要覆盖哪些用户旅程

environments: PR、FAT、Prod 分别允许什么副作用

cases: Case Registry、版本和可见性

experiment: Baseline、Candidate 与冻结策略

suites: Case selector、Trial 数量和执行层级

outcomes: 必须发生、禁止发生、如何独立验证

graders: 确定性、语义和人工评分器

release: 有效 Trial、聚合规则、预算和阻断条件

feedback: 哪些生产信号可以成为 Candidate

governance: AI 可以提议什么、什么必须人工批准

Anthropic 的 CI/PR 系统

2026-08-24 18:15:52

LLM Judge 指的是用大语言模型本身作为自动评判者，来评估生成内容的质量

传统的评估是需要人工标注，但是 LLM Judge 是让一个能力较强的 LLM（如 GPT-4、Claude 等）扮演 “裁判”，对模型输出进行打分、排序或优劣判断

打分评估

两两对比

多维度（觉得很重要的维度）分别去测评打分

现在的问题是 social tools 的

2026-08-24 18:19:30

现在的问题是 social tools 的 search 、fetch 的逻辑

如何测评的作用

也就是需要把整个 workflow 验证的系统打通

evaluation Baseline vs candidate

人工检查失败 case / transcript

最后都 merge 进去

图片压缩后，经过 OCR

2026-08-25 11:15:42

图片越大，存储、网络和模型处理成本通常越高。多模态模型还可能根据图片尺寸进行切片，分辨率过高不一定带来等比例的信息收益

找到一个合适颗粒度的图片

压缩图片可能会导致小字和截图信息丢失问题

照片适合 JPEG，但截图往往更适合 PNG，这是因为截图中像素结构不一样，JPEG 擅长压缩一些“连续变化、细节复杂、允许轻微误差”的自然图像；PNG 擅长压缩“颜色重复、边缘锐利、不能出现误差”的图形图像

概念是服务于自己理解的

2026-08-25 13:29:04

没有现实具象的例子，概念就是一些抽象的名词

架构和系统是服务于自己理解具象的

如果不对自己流程和业务架构清晰判断，永远不知道 AI 做了什么，改了什么，以及自己应该怎么样改

这可以是一个颗粒度的问题

监控是服务自己快速、准确找到问题

2026-08-25 14:40:37

或者形成一些洞察

形态上按照最终的形态去设计

终极形态是什么： LLM 是自进化的， eval 辅助人类调试这个过程

case 中，适合长期作为 case

2026-08-25 16:57:22

case 中，适合长期作为 case 的还是需要文字和结构化的 case

特定需要的时候可以 recall 图片，这个比例应该是最多的，可以更快速，更稳定，更容易定位到到底是 agent 推理，工具使用还是产品策略出了问题

所以其实就是一些好的案例，好的案例来自于好的品味

2026-08-25 17:12:24

好的品味纠正 LLM 去设置 case ，eval，goal ，校准 judge

避免让同一个模型自己给自己评分

2026-08-25 17:28:27

agent 生成答案后要么就是程序硬检查

要么就是独立 judge context

有争议或者高风险的时候，才到不同的模型 、 人类复核

关于如何让模型自己评价自己的问题

2026-08-25 18:09:12

多 agent 可以由自主 agent 协调多个 subagent 并且汇总结果

主 Codex：执行 E2E

↓

程序：生成中立 evidence packet

↓

Judge subagent：空白 context 独立评分

↓

主 Codex：合并硬检查与 Judge 结论

evalustion example：

2026-08-25 21:57:27

同一个LLM 不同的 context review

case 的设计和 goal 设计尽可能清晰符合人类的偏好，但是format未知

不经意间

2026-08-26 12:39:37

感觉自己的具象的能力得到了很强的训练

哈哈哈哈

之前真的太抽象了， 导致别人很难理解

我觉得可以更多的在一些具体的事情上具象去观察，感受思考

点赞这个动作可以理解

2026-08-26 13:35:46

它对应 HomeTaskRackItem.checkboxButton，点击后把整条任务移入 Remembered

如果这个按钮的产品含义是“这件事结束了/收起来”：移入 Remembered、持久化 completed 和清理运行资源都有必要，Agent 无须参与

如果产品含义真的是“我喜欢/这条回答有帮助”：当前设计不正确。它没有记录反馈，也不会让 Agent 学到用户偏好，只是把任务完成了

图标语义混淆：用户看到的是“点赞”，系统执行的却是“完成并归档”

代码去量化打分

2026-08-26 13:44:36

几个维护

可以让不同 context 的 test agent 去估分

前端的一些问题：（2）

2026-08-26 18:51:29

前端的一些问题：

没有原图的情况下，对应的 case 收集出来的意义是什么？ e2e 目录下

我看 e2e case 用了大概一个多月，感觉每一次都消耗了很多token，而且加了很多额外的认知负担，但是我看了一下的现在的 e2e 部分没有一些比较清晰的可以扩展为业务回归的体系

一个是没有原始 input ，二没有整个完整的链路可观测的链路，三没有用户真实的 review eval

有必要做的是把每一次真实测试 e2e 测试的链路，因为人的体感是很清晰的，可以选择性的把完整的信息或者数据上传保留作为 eval case

当前的 e2e 复用场景是什么？

case 注册 → 周期执行 → 基线对比 → 趋势观察 → 回归门禁 → 版本演进

这个月感觉用来比较爽的一点，Aloha

2026-08-26 20:23:11

这个月感觉用来比较爽的一点，Aloha 它很适合用来吃瓜。就是我一般如果有朋友，他给我截图之类的，他一般发一些什么小红书帖子啊，发什么乱七八糟的。这时候我懒得去深度研究，我就是直接让 aloha 一下，Aloha 就会帮我分析这个帖子。他的一些背景以及他一些上下文信息，然后帮我补全，就相当于做了一次一些深度的聚合。我觉得这样就很爽。

而且还有一点就是我觉得 aloha 它很适合去查人。就是我一般在社交媒体里面遇到一个人，就如果要去了解他的话，我觉得是一件比较困难的事情。因为实际上就是我们都知道嘛。当然你去翻他的点事也能翻出来，但是未必是一种真实的他的状态，所以往往就需要你去再去 search 一下。会不会有一些其他的一些，他留下来的一些比较真实的一些材原料，或者是他方的一些视角？尤其是评论区，一些评价可能就非常非常的宝贵了

Infisical 巨好用

2026-08-26 22:22:39

可以作为多设备电脑，多 env 的管理工具

可以作为 Kubernetes 的 secrets 和 config 的管理工具（operator）

还可以作为 agent proxy 的方式，agent 通过一句话的方式，Infisical

Agent 只获得完成任务所需要的 credential

发现了一个很有哲理的思考点

2026-08-27 10:27:56

AI 时代看见问题比解决问题更重要

cubxxw，这一周你的笔记表面上在细致讨论

2026-08-28 10:00:28

cubxxw，这一周你的笔记表面上在细致讨论 Ailoha 的产品架构与验证方式，但在这些技术细节之下，有一条贯穿始终的暗线：你反复在追问同一个问题——Ailoha 究竟是在帮助用户「理解他人」，还是在帮助用户「理解自己」，而这两者之间的边界，恰恰是你们产品最深的分歧点。

你一方面担心 Ailoha 会被关系驱动的用户带向精细的 social capital management，变成另一种 CRM， 另一方面你自己的使用快感却来自「吃瓜」和「查人」——在社交媒体上遇到一个人，懒得深挖，直接把帖子甩给 Ailoha，让它补全背景、聚合上下文，甚至是翻评论区里那些宝贵第三人视角的评价。 这不是功利性的利益获取，而是一种纯认知层面的好奇心满足。你一边理性地看到产品滑向利益工具的风险，一边感性上却最享受它作为「理解装置」的纯粹乐趣。更有趣的是，你在判断用户心智层级时，把「身份认同」放在了最高位， 而身份认同本质上是用户在自我叙事中的定位，不是他与别人的关系图谱。如果你的产品最终售卖的其实是用户的自我身份感，那么「关系」到底是产品的核心，还是通往自我理解的一条迂回路径？

你的笔记里还藏着一个更微妙的系统性问题：笔记 12 和笔记 14 都指向同一个现象——Ailoha 会倾向回归「已知的历史真人」，而不是朝向「未知的截图对象」，甚至会把一张陌生旅行照片识别成你发过的旧图。 这在技术上可以当作 bug 来修，但在更深层，它暴露出你的系统本能地把「已有记忆」设为锚点，把「新信息」当作需要归位到旧框架里的东西。这恰恰呼应了你自己对「向内探寻」的偏爱。 你害怕产品变成精致的利益管理工具，但你的系统设计却一直在做同一件事：把一切新的、陌生的经验，收敛回你已经认识的人和已有的关系里。如果 Ailoha 的记忆系统天然倾向于「回归已知」，它会不会在不知不觉中，也限制了你和你的用户真正向未知敞开的能力？

还有一层需要正视的张力：你在笔记 1 里表现出的近乎苛求的证据文化——每个改造都要绑定场景、版本、设备、baseline/candidate 对比，甚至定下「误认为已执行人数为 0」这样的硬标准，没有对比表就绝不写「优化有效」——这与你在笔记 2、3 里论述的「好的品味来自好的案例，品味纠正 LLM」形成了一种奇妙的双轨。 你不信任「感觉更顺」，却信任「品味」；你要求给一切设计补回证据收据，却又承认护城河建立在 harness、memory 和优秀案例这些难以量化的东西上。 这种分裂并不矛盾，反而正是你的方法论：品味负责提出假设，证据负责赋予假设地位。事实与推论分离，不只是产品架构原则，也是你对自己的认知要求。但你是否意识到，当你在 Ailoha 里执着地区分「AI 建议」和「已经执行」，区分「事实」和「推论」时，你其实也在对自己操作同样的区分——哪些是你验证过的判断，哪些只是你现阶段的好品味？你设计了一个极其诚实的产品，但你对「自己下一阶段的认知边界」是否足够诚实？

把这三条线并在一起看，你会看到一个完整的自画像：你在设计一个处理「人与人的关系」的产品，但你反复强调它的底层是「人与自己的关系」；你的系统倾向回归已知的记忆，而你自己也在传统文化、关系伦理和个人探索之间反复拉扯；你用最严谨的证据文化去约束一个最终只能靠品味和直觉来驱动的核心。这一切都指向同一个事实：Ailoha 对你而言从来不只是关系管理工具，它是你用来探索「我如何理解世界」的媒介，而「关系」只是从这面镜子里看见自己的方式。你担心它的用户画像会让它变成利益工具，那你或许也该问，你自己会不会因为太在意验证和边界，而错过了那些刻意不追求结果、纯粹为好奇而探索的时刻——那恰恰是笔记 11 里最让你「爽」的时刻。

真正的洞察是：Ailoha 从未贩卖「理解他人」，它贩卖的是「借理解他人之名，更清晰地看见自己」；而真正的验证，不在证据表的中位数里，在于它能否守住你最初那份对好奇与探索的敬意。

AI 类型的 feature

2026-08-28 10:09:20

AI 类型的 feature 这样的功能对于用户来说是非常灵感的

把某一个功能拉到某一个程度，用户对此有一定的信任程度，要到达一定的体验分数后再上

ailoha Eval 的思考的链路

2026-08-28 12:33:38

第一性原理核心要解决的问题： 对 ailoha 本身的一些工具了解，以及思考是否需要分类，比如说建议工具、只读工具、主动工具、写入工具，后面可以做什么

对 ailoha 第一版本的 Eval 测试什么？

一些比较好项目他们设计的元方法，学会设计

现在的 Eval 前沿的设计转变方法是什么，博客从单轮文本转向完整轨迹

prompt 调整的正确方式是什么定义，现在的 agent 应该尽可能交给 harness， 加一些权重 tools ，而不是调整 prompt，prompt 应该是最后的事情，智能交给模型

后面的自进化逻辑

给出答案

当前唯一的问题是什么，谁真正评价好坏

2026-08-28 12:47:27

当前唯一的问题是什么，谁真正评价好坏，一线的证据是什么，最小的验证是什么，谁负责，什么样的结果让我们改判

Ailoha 现在具体哪里无法判断好坏？

这个问题会造成什么用户后果？

为什么现有测试或人工体验不够？

最小要搭什么，多久能看到证据？

为什么选择这个切口，而不是做完整平台？

做完后能支持哪个产品或工程决策？

Ailoha 当前不缺一个通用 Eval 平台，缺的是针对“截图 → 人物搜索 → 联系人/会议 action card”的最小产品 Eval 闭环。建议先用 kiwi 的所有的真实案例建立 baseline，验证后再决定是否平台

核心背景，现在修改的工具，prompt 这些风险很高，没办法稳定回答的，搜索是否更准确，联系人 / 会议是否正确创建

核心是下一步要怎么样做？ ？？？

对于 Claude 把产品要求变成任务

2026-08-28 14:39:02

对于 Claude 把产品要求变成任务，grader 、trace 和 outcome

对于 Manus 的文件系统的记忆、可恢复的压缩，错误保留、缓存设计

Claude code 的建议：

2026-08-28 15:06:34

30–50 个高价值 Task（尤其是失败的 task）

每个 task 去寻找一个已知能通过全部 grader 的参考解法，证明任务可解

outcome grader，检测真实的结果

guardrail grader，检查不可违反的过程

quality grader，判断开放式质量，比如说语气、解释质量、相关性

同时写 Should 和 Should-not case

environment 必须要隔离，每一个 trial 从干净的环境开始，不能共享一些资源环境

Grader 采用分层的结构，能用代码用代码， 不能用代码一个维度一个rubric model-based，人类评测 gold，主观判断，Judege 校准

调节 prompt 和 eval 往往是为了在

2026-08-28 15:07:03

调节 prompt 和 eval 往往是为了在 under-trigger 和 over-trigger 之间找平衡

Grader，用什么方式判断：

2026-08-28 15:09:17

├── deterministic grader：代码、规则、状态检查

├── model-based grader：由 LLM judge 执行

└── human grader：由人工专家执行

判断什么样的内容：

semantic / state / trace / contract：判什么内容

Semantic Grader 可以由 LLM 执行，也可以由人执行

本质上就是语义裁判，不检查输出字面是否和标准答案一模一样，而是判断表达的含义是否满足要求

投入大量同居查看大量的 transcript

2026-08-28 15:27:55

投入大量同居查看大量的 transcript ，持续检查：

Agent 是否真的犯错；

Grader 是否误杀合法方案；

Task 是否存在歧义；

Harness 是否限制了模型；

环境是否泄漏状态；

Agent 是否在投机或绕过 Grader；

失败是否“公平且可解释”

所以 Transcript 不是为了漂亮的 observability 页面，而是 Grader 校准和 Eval 健康检查的主要证据

Phoenix 的 shadow lab 可以做什么

2026-08-28 15:32:49

一个可替换的实验与评审 UI

Phoenix 提供了 Dataset、Experiment、重复运行、Evaluator、结果比较和 Trace 下钻，能减少我们自己开发实验 UI 的成本

Phoenix 没有提供： Contact、Calendar、Memory 的 before/after state；

不过考虑第一阶段不用 Phoenix ，可以先证明一个最小的闭环

OpenAI 的 evaluation

2026-08-28 16:23:38

OpenAI 的 evaluation 的设计方法也很独特

用的是 Agent legible repository 公开方法

让环境、知识和反馈对 Agent 可读、可验、可修改

感觉 OpenAI 的方法论很适合结合到 agent 项目中

实际上也是把 evaluation 作为 harness agent 的一部分

相当于把组织相关的也基础设施化，过去依赖资深工程师脑内记忆，slack 对话和 code review 的东西，被转成了 agent 可以检查的显式状态

隐性知识 → 可检索知识

偏好要求 → 可执行不变量

人工观察 → Agent 可读取的信号

我觉得这部分是很适合学习的，我们日常的工程师现在都在飞书，如果是在 slack 的话我测试下来 agnet 是可以每天去整理一些问题和信息，然后自己去分析问题信息，分析文档，还有 UI 日志，指标啥的，都可以抽象为 tools ，然后 agnet 灵活的使用

优化关于Google search

2026-08-28 16:41:21

加入到 agent 的描述中

在工具中可以给一个部分可以反问，引发 agent 的思考以及判断

Letta 设计观察

2026-08-28 16:55:18

Letta 是如何从经历中形成 memroy ？

原始经历 Experience

↓ 反思、归纳、清理

长期记忆 Memory

↓ 检索、固定加载、渐进展开

当前上下文 Context

↓ 模型推理与工具调用

行为 Action

↓

产生新经历

这些大厂这些 evaluation

2026-08-28 17:36:28

感觉这些大厂这些 evaluation 的设计都挺值得借鉴和学习的

eval 的 case 应该是来自于真实的分布的

2026-08-28 18:53:33

服务于具体的决策，明确用于模型选择、回归检查、发布阻断

好的 eval ，在固定范围和版本下面

2026-08-28 19:34:28

好的 eval ，在固定范围和版本下面，用不泄露答案的真实案例，可信 Gold 和可复现运行，回答一个明确产品决策，可以清晰的给出结论到底是修改 prompt 还是 tools， 还是 models ，还是 memroy 还是产品预测

不依赖模型输出的总体人工基线，从而推理测出来

2026-08-28 19:53:43

2Meet 在 Kiwi 场景中的真实需求比例、系统误报多少、漏报多少、主要错在哪里。

使用本地部署的 phoenix 完成 Eval

2026-08-28 20:25:58

使用本地部署的 phoenix 完成 Eval 平台的搭建，针对 2meet 的任务

把一千多张 Kiwi 图片上传到平台。属于同一个聊天或者任务的多张图片合成一个 Episode，不要重复计算

一条条独立标注，不看模型原来的答案。主要判断：该不该生成 2Meet、Calendar，还是都不生成；看不懂的单独标成 needs_context

如果标的字段没那么确定，反过来调整一下产品的语义边界值，清晰 rubric，基于新的 rubric ，然后人工标注案例是否如何 Policy

标完以后，先统计真实图片里到底有多少 2Meet，再计算当前模型的 Precision、Recall 和路由完全正确率

把模型的错误自动分成两类：不该生成却生成了是 FP，应该生成却没生成是 FN

再把 FP/FN 按原因分类，比如：Kiwi 不是参与者、只是客套话、历史记录、线下已取消、已经排期、线上线下判断错误

从每种错误里挑 3～5 张最有代表性的图片，再补一些正常正确案例，组成几十张 Regression Suite

每个 Regression Case 都补上 Gold、hard fail 和 state oracle（正确答案是什么、绝对不能发生什么、数据库最后应该变成什么）

用完全相同的图片和环境，让旧版本跑三次，新版本也跑三次。记录最终路由、Tool 调用、完整 Trace，以及 Calendar/2Meet 的真实状态变化

把模型失败和 Harness 失败分开。登录失败、图片没传进去、Tool 超时或者状态回执缺失，都不能算模型错误，只能算无法判断

人工抽查失败 Trace，确认是模型真的理解错了，还是 Gold、Evaluator、运行环境本身有问题

对比新旧版本：新版本应该明显减少 FP，同时不能制造大量新的 FN；未确认写入、重复创建等 hard fail 必须为零

曾经失败、修复后通过的 Case 永久加入回归测试。以后每次修改模型、Prompt、Tool 或路由规则，都自动重新跑这些 Case

Claude 团队主要回答的是：Agent 能不能在固定任务和环境里稳定完成目标。Ailoha 结合业务，应该还要加上：真实图片世界里应该生成多少 2Meet，模型有没有系统性乱生成或者漏生成

真实 2Meet 占比是多少，当前 Precision 和 Recall 是多少，主要错误是什么，新版本改善了多少，还有哪些问题没有解决

当前 Ailoha 已经有 Claude 式

2026-08-28 20:28:21

当前 Ailoha 已经有 Claude 式 Eval 的雏形：Case、Gold、Evaluator、Trace、State oracle 和 Suite。

现在真正缺少的是：

把一千多张图片完整放进 Population 标注流程。

自动把 Kiwi Annotation 和模型输出连接起来。

自动生成 FP/FN 和错误分组。

从错误分组生成 Regression Case。

在相同环境里多次运行新旧版本。

把实验结果和 state receipt 回写 Phoenix

解决 evalations 中的词汇量的问题

2026-08-29 00:32:09

解决 evaluation 中语境的问题（多听视频和播客）

解决 evaluation 中品味的思考，什么样的是好的 Eval，现有

那就训练自己去表达精准，找到问题，定位本质的能力

2026-08-29 00:43:49

第一性原理一直剖析一直剖析

剖析到不可剖析为止

现在的公司的启发是选择一个高反馈密度的真实的工作流

2026-08-29 15:20:37

现在的公司的启发是选择一个高反馈密度的真实的工作流，拥有它的环境、结果、memroy、policy 和 evaluator

reword，human-on-the-loop

2026-08-29 15:55:30

reword，human-on-the-loop 人在环上，实际不是 AI 发奖品，而是告诉模型之前的行为有多少，今后应该更倾向还是更少做出类似行为

Verifier 负责判断 → Reward 把判断转成优化信号 → 模型根据它学习

模型学到的事情就是找到能获得高 reward 的行为

只要 reward 与真实目标一致，追求高分才等于真正进步

IM 聊天框本质上有一些非常稀缺的东西。比如

2026-08-29 16:09:03

IM 聊天框本质上有一些非常稀缺的东西。比如，它未必是完美的表达，但往往是不完美的表达，以及非常真实的表达、非常真实的偏好。

它可能会有一些隐含的意图，而这些东西往往最接近人自己本身非常真实的一些东西，所以里面都会有一些非常主观的真实。然后这些东西……

关于这个，我是很多的 memory，我觉得挺有意思的，因为它本质上还不仅仅是用户自己本身的一些 memory。当然用户自己本身的 memory 它可能有价值，但相对来说，如果是做一些 conversation，然后做一些关系类型的，关于个人记忆边界的，那么可能相对来说可能更有价值一些。基于这些东西，如果后面去和模型厂商合作的话，去筛选一些训练样本，包括做一些 benchmark

eval awareness 评测觉察

2026-08-29 16:27:38

模型在执行任务时能察觉到自己正处于被评测的场景，行为可能因此发生变化

harness 这个词语正在扩容，现在不仅仅是 “prompt + tools + memory + orchestration"了，而是明确把 tracing（追踪）、feedback handling（反馈处理）、recovery logic（恢复逻辑）也算作 harness 的组成部分agent harness 被描述为围绕基础模型的结构化执行层，涵盖 prompt 与上下文管理、记忆、工具接口、编排逻辑、运行时隔离、反馈处理、追踪和恢复逻辑

我发现我跟 kiwi有一个非常非常不一样的点，就是

2026-08-29 16:29:03

我发现我跟 kiwi有一个非常非常不一样的点，就是 kiwi 他是一个第一性原理很强的人，他基本会把日常的所有生活，包括他对这个世界理解、对技术理解、对经济理解以及对AI的理解，他基本都是拆到物理学公理里面，然后再去重建。所以他的判断力基本都是源于他自己的嗯对某一件问题的第一性原理，这导致他有一些比较强的判断力

然后我发现我自己这部分能力其实是很弱的，我相对来说我自己是非常系统性或者是涌现式的思维。通常来说都会把，不管是技术经济还是生物学当做一个自组织的活系统来去看，而不是拆成一个单独的零件去优化，所以相对来说关注的整体更多一些

先说说为什么会出现 evals

2026-08-30 13:55:20

解决的是早期改一个 prompt ，跑了几个 case 看上去没有问题

但是可能上线后用户投诉说感觉变蠢了

这个可能是用户的错觉，但是除了手动测试几个场景，没有任何的办法

早期靠直觉和手动测试可以，但是 agent 进入生产环境开始扩展的时候，没有系统化的评估就会出现各种的问题

Claude 最早是通过 end to end

2026-08-30 14:07:15

Claude 最早是通过 end to end Eval 的方式去做的

coding agent evaluation 的 scaffold 最开始做的是

模型自己决定运行什么样的命令、查看什么样的文件、编辑什么样的工具

最开始就是三种工具，bash tool + file edit too + planning tools

给出具体的任务，最终去测试 repo 是否满足任务

好的 Eval 可以精准的暴露出来问题

2026-08-30 14:11:59

坏的 Eval 会扭曲结果，让自己误以为进展很大

Eval 的核心是 goal ，就用来回答一个问题，怎么样是客观的证明去达成这样一个目标

所以它才衍生出来了三个部分，测试集是为了定目标，评分标准是为了定尺度，独立执行是为了保真实，然后三者合一才是完整的 Eval

从一个大的 Eval 拆解为小的 Eval 这个过程

2026-08-30 14:25:01

很重要的一个点是为了更精准的定位问题，避免模糊

所以Claude Code团队最开始从整体任务e to e Eval变成了component

但我觉得这过程中，实际上有一些case，或者是有一些goal，它是不利于现在的传统的tools来完成Eval的，因为它没有完，非常好的评估标准。所以这个过程中，我觉得有些东西它是需要人去 preference 的

在不损失任务完成度的情况下，有没有说不必要的话，简洁性是一个 Eval ，另一类，更适合 rubric + LLM-as-judge + 人类 preference

是这样子的，大概是claude他们和OpenAI之间

2026-08-30 14:31:49

我觉得是这样子的，大概是claude他们和OpenAI之间有一个非常非常不一样的区别。我觉得这个区别就是在他们去优化他们的指标的时候，会有一些差异。比如说你最开始测试什么，以及怎么打分，以及偏好数据怎么收集，这些都会决定了你的一个模型能力往哪个方向去走。所以我觉得在应用层也是这样子的，就是你通过什么样的方式去优化对应的，你要设定什么样目标，你要设定什么样的对的、好的、比较有品味的，那么反过头来，它都会反过来去定义你这个 agnet 应用你会往什么样的方式去走？

Evaluation 本质上是在编码价值判断

2026-08-30 14:37:19

所以说任何的评估指标其实都很重要的，它决定两个模型未来的生长方向。就比如说，就哪怕是更好的回答，或者是更成功的Agent行为，或者是更符合用户意图，就它会有一个规范性的问题，就什么叫有帮助？什么叫诚实？什么叫做尊重用户的主体性？

我觉得这些东西它都涉及到一系列的非纯技术的问题，就包括哲学、伦理学、政治哲学、现象学等问题

工程师和产品经理能解决的往往是怎么测和测的优化更快，但是他不一定擅长系统性的追问，就是为什么我们这样定义就是好的

用户理解和产品哲学，其实是需要更深层次的洞察，可能不仅仅是关于生物学相关的，就是如何让用户去喜欢上这个产品，依赖这个产品。我觉得可能还有更深层次的是，人应该如何理解自身的意图，怎么样去和工具去相处，怎么样去处理这个不确定性和责任的问题。但是如果仅仅是去靠用户调研和AB测试偏好数据，容易停留在人们说他们喜欢什么的表层，但是他们其实是错过了人们需要什么样真正的人机关系，这样深层次结构

所以其实哲学家我觉得他是很擅长去把一些模糊的产品愿景翻译成可以操作，并且不至于说过度简化的原则，或者是评估维度

哲学家帮助把模糊的产品愿景（“更有用”“更安全”“更像人”）翻译成可操作但又不至于过度简化的原则和评估维度。Anthropic 的 Constitutional AI 本身就大量借鉴了哲学传统，效果已经证明这条路是可行的

rubric 感觉是 evaluation

2026-08-30 14:51:23

rubric 感觉是 evaluation 平台中非常重要的一部分

rubric 是最容易被低估、也最容易在事后复盘中被发现"当初想岔了"的环节

rubric 到底是给谁用的，很重要，决定了颗粒度

如果直接给human，可以用模糊但是配案例的语言的，以为人有常识可以兜底

给另外一个模型做 LLM as judge，必须要极度具体，可以操作，否则模型自己也会在边界案例上前后不一致

但是我觉得实际上在拆解这个原则的时候，找出失败的模式，而不是理想状态，往往更重要的。就是与其从什么是诚实的回答这种正向的定义出发，倒不如我们从一些真实的失败的案例中出发，就哪些东西到底是说了一些模棱两可的话的，哪些地方是过度谄媚，哪些地方是假装知道一些不知道的东西。就跟我们实际上是我们找一些热爱的东西一样，实际上我们在不知道我们自己热爱什么的时候，我们先去思考自己不喜欢什么，然后去把这些不喜欢的东西，然后去定义清楚，就是怎么样去依次的去解决它们，然后基于此去演变出来我们的一个初步理想状态是什么样子的

可能也跟他们组织的价值观理念的不一样

2026-08-30 14:56:08

可能也跟他们组织的价值观理念的不一样，我觉得可能在于长期而言，怎么样去训练人的思维方式，包括塑造，就是保持一致性、组织信息和处理约束，这些复杂层次来说，我觉得Claude可能是更有利的，因为你看，实际上Claude它自己有更强的指令，你长期用它的时候，实际上人它会被迫的去把一些想法拆的很清楚，约束写的更完整，然后模型它不会轻易的就说差不多就行了，这个过程中实际上在训练严谨性。然后我觉得其实长期而言，文笔和结构实际上更接近高质量人类思考，就它输出的一些节奏。还有信息的密度，包括如何自然的转折，如何好的思考是长什么样子的。所以就长期接触，人们是会慢慢的吸收掉那种不机械，但是有呼吸感的表达和推理方式的

评估信号的“硬度”决定了模型学到什么策略

2026-08-30 15:10:31

硬指标（SWE-bench、HumanEval、pass@k 等）：本质是二元或接近二元的——跑通/不过、测试过/不过。长期用这类信号做 RL 或 preference，模型会学到“最小化失败概率”的策略

软信号实际上定义的就是评估者直接比较哪些更清晰、更诚实、更愿意指出风险、更有分寸。这些信号实际上是更连续的，但是更接近真实的使用体验，但是它的噪声更大，成本最高

评估信号就是训练信号的 upstream。如果评估只奖励“能跑通”，模型就会学“糊一个能过测试的方案”；如果评估同时奖励“清晰、诚实、有分寸”，模型才会把这些特质内化

一旦 evaluation 体系建起来

2026-08-30 15:25:04

一旦 evaluation 体系建起来，很多东西就是免费的：延迟、token 用量、成本、错误率都可以在固定任务集上持续追踪。评估的复利效应很容易被忽视，因为成本是前期可见的，收益是后期累积的

而且另外一点就是更强的模型发布的时候，有评估的团队可以快速的验证，调整提示词

Eval 平台是自然而然长出来的

2026-08-30 15:30:03

并不是一开始就有完美的设计方案

而是在每一步，走一步看十步

最开始是Anthropic 工程师每天自己用 ，改了 prompt 和 tools 和 UX 后，dogfood 感觉明显更好，然后 ship

但是后面成熟后发现

今天修了「啰嗦」，会不会导致明天 Claude 少解释关键内容？

今天提高 Edit 成功率，会不会导致它更激进地修改文件？

换成新 Sonnet 后，搜索能力提高了，但是不是更容易乱改？

于是需要把以前依靠工程师感觉判断的东西冻结成 regression eval

用户抱怨

↓

发现 failure mode

↓

人工修复

↓

确认效果

↓

把这个 case 加入 eval

↓

以后每次版本都自动跑

最开始建立一个比较小的 Eval ，然后比较，之前的 prompt 和 之后的 prompt 之间的区别，成立的话 ship，然后封装，封装的目的是为了后面复用，避免修改后产生其他的问题又需要做一遍

真正有用的 eval 可能最终不会长得像一个“AI

2026-08-30 15:31:43

真正有用的 eval 可能最终不会长得像一个“AI 评测平台”，而会越来越像 AI-native CI/CD

Eval（evaluation）是大集合

2026-08-30 15:32:51

Eval（evaluation）是大集合，Benchmark 是其中一种形态

Eval 等于考试这件事情本身

benchmark 就是等于高考

既然是一个 CICD 系统，那么真正重要的就是

2026-08-30 15:36:30

线上 failure → 自动沉淀 case → regression eval → CI → experiment → ship decision 变成开发者每天自然使用的 workflow

如果你想提高模型的探索性（比如调高

2026-08-30 16:10:21

如果你想提高模型的探索性（比如调高 temperature、增加采样多样性），pass@k 会变好——因为更多样的候选里更容易"撞对"一个。但这同时会拉低 pass^k——因为多样性增加意味着单次输出的稳定性/确定性下降，每次"都对"的概率反而降低

反过来，如果你想让模型更保守、更确定（降低 temperature、加强对齐、限制输出空间），单次成功率的方差会变小，pass^k 会更好看，但 pass@k 的提升空间也会被压缩（因为 k 次尝试之间高度相关，“多次里至少一次对"带来的边际收益变小）

所以好像大模型为什么一般在 coding 领域的能力和其他的领域的能力差异还是蛮大的

而对于评估来说，最接近产品需求和用户的人最有资格定义

2026-08-30 16:20:54

而对于评估来说，最接近产品需求和用户的人最有资格定义成功。在 Anthropic，产品经理、客户成功经理甚至销售通过 Claude Code 就能以 PR 形式贡献评估任务

我已确认：

2026-08-30 16:45:15

100 个 Episode 全部加载成功

每条都有图片、AI 草标、置信度和判断依据

目前人工提交数为 0

没有写入 prediction

原始 Ground Truth 项目仍保持 0 annotation、0 prediction

进入后点击 Label All Tasks，逐条操作：

看完 Episode 中所有图片。

把 AI 草标当建议，不要默认接受。

独立选择最终路由：

仅生成 2Meet

仅生成 Calendar

两个不同承诺分别生成

都不生成

needs_context

补充参与者、时间状态、承诺强度、线上/线下和排期状态。

点击 Submit，进入下一条。

核心判断口径：

Kiwi 不是参与者 → 不生成。

双方明确承诺未来线下见面、尚未排期 → 2Meet。

已有可执行日期和时间 → Calendar。

同一个承诺不能同时重复生成 2Meet 和 Calendar。

看不清、缺相邻截图或关键信息 → needs_context，不猜。

当前 AI 草标分布是：2Meet 10 条、Calendar 21 条、都不生成 67 条、needs_context 2 条。

需要特别注意：这个项目是“看得到 AI 答案后的人工复核”，因此结果不能直接冒充完全独立的盲标 Ground Truth。如果目标是测量真实 Precision/Recall，最终还需要独立 Gold 或二次裁决。

另外，这个平台当前只记录判断，不会真的创建 Calendar 或 2Meet，也不会触碰生产数据。等你复核完，我可以继续完成：冻结 Gold、统计分歧、计算模型 Precision/Recall、归类 FP/FN，并构建 Regression Suite

hamel 眼中的好的 Eval 和坏的 Eval

2026-08-30 20:17:23

一堆的通用指标，是没有意义的

人们不知道3分和4分之间该做什么，这个数字凭什么比2分好，不明显，这是模糊的

指标往往是不重要的，优化的是一个没人真正在意的数字

业务说八个指标都很重要，但是如果真的有人在多个指标中都很重要，说明在优化的是一个没人真正在意的数字

Pass@k 可以给模型 k 次重试机会

2026-08-30 20:23:46

Pass@k 可以给模型 k 次重试机会，至少一次成功，这个可以测量 harness 能力的天花板（coding 能力）

Pass^k 连续 K 次全部成功可以度量一次性底线 harness 会不会随机崩溃

Eval 最终是可以作为 CI 门禁的，回归测试套件（指的是过去测过的，是否可以满分通过） ，每次改动都跑一遍，同时监控线上找新的非确定性 case，持续扩充 eval 集

Capability Eval vs Regression Eval 可以参考 bloom、inspect-EvalS（UK AISI）

要不要上多 Agent 架构，应该由 eval 结果驱动，而不是一上来就默认要用

我觉得挺有意思的，就是如果是让LLM做测评，实际上它更适合做一些判别式任务，比如说两两比较、分类，还有按标准打分。不擅长做一些开放式生成的自我评判

然后我觉得其实还有一点就是关于Agent它在传递工具

2026-08-30 20:25:52

然后我觉得其实还有一点就是关于Agent它在传递工具的时候，有没有把对应的参数传对，这个也很重要。就尤其是在单Agent场景情况下，传递给工具的参数到底对不对，尤其是从对话历史中提取的参数以及为什么不对。然后这些不对的都是很宝贵的案例

然后另外一个就是多Agent系统就会再新增一类：agent handoff accuracy（该交接的时候有没有交接，交接对象对不对，会不会出现循环交接）

所以实际上要不要上多Agent系统架构应该是由 Eval 来结果驱动的，而不是一上来就默认要用

Metric-based（exact match、ROUGE/BLEU、function call 准确率、可执行测试如 text2sql）：便宜、适合自动化回归，但可能不贴合具体场景、容易漏掉细微差别

人工评测：质量最高但慢且贵。建议：多轮迭代打磨评分标准；“show not tell”——给评分员看 1分/3分/8分的具体样例而不是抽象描述；除数值分外加一个 pass/fail 阈值；多个评审员用共识投票聚合

LLM-as-judge：便宜、可扩展，但有 position bias（喜欢排前面的答案）和 verbosity bias（偏爱长答案）。建议：优先用 pairwise 比较或 pass/fail 而不是打分制，因为更可靠；用最强的模型当裁判；加 chain-of-thought 让裁判先推理再打分，能提升评测质量；把开放式问题尽量改造成选择题格式方便自动化；裁判分数要定期跟人工标注做一致性校验，一致后才敢放心扩大规模用

我突然发现，就是传统来说，单轮模型交互

2026-08-30 20:31:10

我突然发现，就是传统来说，单轮模型交互，它是很容易做一些意图分类的。比如说模型有没有听懂指令，以及系统提示词有权重有没有压过用户的提示。还有再就是它的输出是否是对的。然后在知识之上呢，去做一些Workflow。Workflow它复杂度增加，但是没有添加一些新的非确定性来源，只是把上面的两样猜到了每一个步骤

LLM-as-judge 很值得去测试，便宜

2026-08-30 20:35:33

LLM-as-judge 很值得去测试，便宜，并且可以扩展，但有 position bias（喜欢排前面的答案）和 verbosity bias（偏爱长答案）

建议：优先用 pairwise 比较或 pass/fail 而不是打分制，因为更可靠；用最强的模型当裁判；加 chain-of-thought 让裁判先推理再打分，能提升评测质量；把开放式问题尽量改造成选择题格式方便自动化；裁判分数要定期跟人工标注做一致性校验，一致后才敢放心扩大规模用

Metric-based eval 这类方法的共同特点是：给一个明确的、可计算的规则或公式，喂进去模型输出和参考答案，吐出一个数字，全程不需要人看、也不需要另一个模型当裁判

但实际上， Metric base Eval它还是评测体系中的一层，它还是要搭配人工评测以及 LLM as judge 去校准，尤其是一些主观性强、表达自由度高的一些任务

Verifier 是自进化中的核心瓶颈

2026-08-30 20:45:21

RSI 的整个循环（answer → experience → learning signal → problem/curriculum）能不能持续转下去，关键不在于"能不能生成"新东西，而在于——能不能可靠地判断新东西是否更好。生成永远可以做，但如果判断标准不可靠，改进方向可能一直在跑偏而不自知

我觉得对于一些形式上的任务，比如说数学或者代码，这种Verifier它是很好做的，因为它可以通过一些单元测试或者代码执行结果，然后它对就对，错就错，客观稳定，容易搭起自动化闭环，但这种闭环是有边界的，因为判断标准实际上是人预先固定死的

然后我觉得更多是一些主观的、开放式的任务。这种任务它实际上非常依赖于人的主体、主观性去判断，所以它很难有一个客观的对错。你需要有强烈的判断，就是新颖性、有用性和重要性。这个东西它本来就很难形式化，Verifier也很难做

Verifier 本身也开始进化

Self-Trained Verification：把 verifier 当成训练对象，让它的判断能力随迭代提升

Self-evolving Deep Research Agent：agent 能力在进化的同时，评价用的 rubric（评分标准）也在同步更新

Meta-evaluation：不只评价结果，还进一步评价"评价者"本身做得好不好

Red Queen Gödel Machine：让 agent 和 evaluator 一起进化，评价标准不再是固定不变的

Evaluation工程师

2026-08-30 21:02:06

我觉得Evaluation工程师，整个学习过程中或者成长过程中，就是一个不断定义什么是好的一个过程

所以Evaluation 工程师应该是一个研究者，而未必是一个顶级的工程师

网络上会有一些关于 evaluation 的标准

2026-08-30 21:27:41

我觉得网络上会有一些关于 evaluation 的标准，尤其是关于“好”的核心判断，比如有效性。

一个测评可能跑得很顺、数字很好看，但测的并不是自己关心的能力。所以核心是问自己：如果一些指标涨了10分，业务到底真的会变好吗？这是我们觉得很有意义的一个答案。

比如我们在研究 ToMeat 这个工具时，在评估怎么提升它的能力。我们有一套方案，去解决它。下一个版本真的把分数跑高了，但它真的是好的吗？

我觉得还有一点：这个评估是不是明确、稳定、可信。比如同一个数据，今天测和明天测，结果是不是差不多？换一个标注员，结果可能也不会天差地别。

还有就是我觉得有没有区分度，能够真的分得开好和差。如果一个评测，所有的模型、所有版本都能拿到 95 分以上，那么这个评测已经饱和了，没有区分能力，继续做，让用它做决策是没有意义的。

然后另外一些就是可操作性的，就是就算是出了一些低分，工程师他应该知道就是哪个环节或者是哪种 case 出现了问题，怎么样去修改它。

到底什么是好呢？好到底是什么？我觉得指标它可以定位问

2026-08-30 21:31:03

到底什么是好呢？好到底是什么？我觉得指标它可以定位问题，但是完整的 Evaluation 它还要回答，就是用户真正需要的结果是什么？什么样到底算是正确？什么样算错误？什么样算无法判断？以及哪种错误的代价最大？还有就是换模型、 Prompt 或者是 Workflow 之后，旧的问题有没有复发？

深度思考辅助我理解，为什么远程手机端好像没办法使用语

2026-08-31 10:52:50

深度思考辅助我理解，为什么远程手机端好像没办法使用语音输入，也没办法成功的发送内容调用 AI？

有些时候测试的并不是我们所以为的东西

2026-08-31 11:44:36

每一个分数的存在的意义，分数高的情况下，到底代表什么样的能力，答不出来就是坏的

再就是数据本身是脏的，有些训练集与评测集本身就是错误的，后续所有的工作都是没有意义的

Pilot 的概念和理解

2026-08-31 12:58:45

Pilot 就是正式标注开始之前，抽取一小批数据，让两个以上的标注员独立标注，然后：

计算标注者间一致性（IAA）

逐条看分歧，讨论是指南没写清还是理解不同

修订标注指南（rubric），补充规则和示例

再抽一批重测，直到达标

比如说针对某些时候创建 calendar， 某些信息可能很模糊，这时候会出现一种判断的错位，怎么样把这个错位对齐的问题

Pilot 看什么？ 核心就是标注者间的一致性

不做 Pilot 的后果就是，标注指南里的模糊点会在正式标注中被系统性放大，等你发现数据有问题时，几千条已经标完了，返工成本极高

LLM 相关的主观标注，包括质量评分、偏好排序排序、安全性判定，边界 case 极多的

evaluation 里最难具象化的

2026-08-31 14:45:23

我觉得 evaluation 里最难具象化的，是把“表现得好”变成一套可观测、可复现、可归因的判定标准，也就是 evaluation oracle（评判真值）

oracle 是一个知道正确答案的权威

怎么造出来一个可靠的 oracle 是值得思考的一件事情

oracle 围绕整个 evaluation 流程，甚至标注本身

定义构建需要我们知道什么样的是好的，这就是在写 oracle 规则

构造题目这就是oracle 的骨架，每道题的参考答案，评分维度都是 oracle 实例化

判分也需要 oracle 拿模型输出和 oracle，产生每题分数

聚合本身也是 oracle 结果汇总，把 oracle 判出的每题分数聚合成总分

报告就是 oracle 的结果呈现

关于标记的之间

2026-08-31 18:58:01

Evaluation 是一套可复现的质量证明系统

真实任务 / 已知风险

→ 候选 Case

→ 人类定义 hidden Gold / Oracle

→ 独立复核与争议裁决

→ 冻结 Case + Suite

→ baseline / candidate 独立运行

→ 收集回答、Trace、状态差分、动作收据

→ 分层 Grader

→ Metric + GateResult

→ 人类决定 adopt / revise / reject / release

→ 失败重新进入下一轮 Case / 标注队列

人标完后让 AI 再标，非常值得，但是要做成盲标，需要暂时隐藏人类标签，解释和最终答案，AI 看原始的 case

程序比较两边结构化差异，只把 disagreement 送给独立 Reviewer

Reviewer 回看原始证据，可能接受人类标签、接受 AI 的提醒，或判定 rubric 本身需要修改

最开始所有都标注一遍

2026-08-31 20:46:57

但是因为还要校验

后面让 LLM 按照新的产品语义规则新定义了一套 rubric ，原来的 2Meet 和 Calendar 定义不够准确

2Meet 本质上管理尚未排期的线下关系机会，而 Calendar 管理已经占用时间的广义事件，范围包括面试、Podcast、线上会议等

因此我们提出了 v0.3 生命周期 Rubric。下一步不会直接拿当前标签计算模型准确率，而是先冻结旧标签，遮住答案进行一次独立盲复验，再由人工只裁决分歧案例。Gold 稳定后，再计算真实 2Meet 占比、Precision、Recall、路由准确率和主要错误类型，并把代表性错误沉淀成长期 Regression Suite

evaluation 应该先于完整 agent 产品

2026-08-31 23:07:39

准确的顺序应该是先定义用户任务、成功标准和不可接受的失败

写出第一版本 evaluation，真实的任务集、评分标准、风险边界

做出第一个 agent 的原型，跑通完整的链路

根据真实失败不断的修正 evaluation

当 evaluation 能稳定区分好坏后，再投入完整产品、复杂架构和规模化优化

evaluation 可以不断的逼迫团队思考，什么样是好的产品，什么样是好的 eval，什么样是好的设计，并且这个过程中不断的做

本质上也是测试驱动开发

目标假设 → 初版 eval → 薄原型 → 发现失败 → 更新 eval → 再设计 Agent

有些时候同样的标注可能背后是几个不同的问题

2026-08-31 23:15:05

缺少上下文， need_context

rubric 没写清楚，rubric 缺陷

产品本身还没清晰应该怎么样做，产品语义未决

标注者理解错了，标注错误

产品的语义边界应该取决于，FP，FN 对用户的实际伤害，行为是否可撤销，是否产生真实写入，用户对产品的期待

LLM grader 必须用人工标签校准，rubric 要清晰，并优先采用分类、pairwise 或 pass/fail，而不是开放式“感觉评分”

如果 rubric 或者产品边界发生变化

生成新的 policy_version、rubric_version 和 gold_version

用新 Gold 同时重新评分旧版本和新版本

不能拿旧模型在 Gold v1 上的分数，与新模型在 Gold v2 上的分数直接比较

对于 2meet 的这个场景，或者是

2026-08-31 23:22:32

我觉得对于 2meet 的这个场景，或者是 calendar 这个场景

可以选择固定的使用代码的方式去评分，比如说有没有调用对应的Calendar或者是2meet Tools，比如说Tools参数是否正确，就比如说数据库是否创建对应的记录，是否重复创建，是否未经确认写入，是否发生 harness 错误，我觉得很重要

不一定需要 LLM grader ， 比较模糊的地方可以用 LLM grader

人工盲标原始 Episode

→ 产品仲裁争议案例

→ 冻结 Gold 和 rubric

→ 用人工评分过的历史 Trace 校准 LLM grader

→ 冻结 grader

→ 旧版本、新版本各运行三次

→ 确定性 evaluator + LLM grader 评分

→ 人工抽查失败 Trace

evaluation 强迫你从很多的场景和案例出发

2026-08-31 23:28:46

思考整个链路应该如何去设计，如何去做

这个过程我觉得也是一种 enjoy

二、日常与其他

118 条记录

小孩的隐私性是有很大的问题，怎么样去保证他在

2026-08-04 12:56:58

小孩的隐私性是有很大的问题，怎么样去保证他在 iOS 端用不了隐私性？我觉得结果一定不会成真的。结果他正确的逻辑应该是用完即弃，就是他只提取一些重要的信息，然后截图还可能会原始地提取一些数据。但是我在想，这个截图还有必要去真实地保存吗？好像也没有这个必要。为学校在手机端还结合了目的地定位服务这个功能，目前的使用状态就是他明明在 iOS 系统原来自己都能提取一些关键词，然后提取一些关键词可能会交给去处理，但这个关系就处理到这些隐私性的问题，比如说聊天记录里面的隐私，再就是行业的一些潜规则，然后候选人的一些薪资待遇性。那么，这个东西我觉得他就没有办法做到一些公布，他就一定是一个对于用户来说还是一个非常私密的东西，而且对于存出来说，他要考虑一个很关键的问题，用户对于这个平台是否信任的问题。如果他所获取的信息太多的话，我觉得他会涉及到一个信任问题。那么我们再去反推一个问题，就是关于怎么样去接纳你这个人。我觉得就是关于这个安全和它的隐私保存在云端时的数据，然后再包括就是这个数据还怎么样合理地保存下来。 #ailoha

我使用了各个平台 ai chat

2026-08-05 02:12:20

我使用了各个平台 ai chat 模式优势去补充自己的认知和 context

我使用了语音 甚至洗澡和豆包聊天

想做一些实验

2026-08-09 10:45:50

证明自己可不可以成事

人生应该设置很多的 Deadline

有限的时间内做出无限的挑战

我想要的不是想赢

2026-08-09 23:27:38

也不是成功

也不是躺平

而是一生都没有被辜负

不想辜负自己的能力，不想错过时代的窗口，不想让见过的世界白白流过，也不想为了赢，最后变成一个冷漠、功利、只剩下产出的人

我认真活过，尽力创造过，真实爱过；我没有逃避时代，也没有把灵魂卖给时代

我搭子也很担心我其实

2026-08-09 23:31:46

但是其实一直以来我还是觉得如果再让我选一次我还是会选择我搭子，即使现在结果很差，但是我们经历，信任

对于 while 来说，我觉得尤其重要的是每一次做的

2026-08-11 18:28:14

对于 while 来说，我觉得尤其重要的是每一次做的事情，自己都要在大的颗粒度以及合适的颗粒度上有所思考

他们想要一个奇迹

2026-08-11 22:31:31

那我给他们一个奇迹 ～

我感觉他们还真的是很忙的，所以懂他们的需求还是很重要

2026-08-12 09:33:43

我感觉他们还真的是很忙的，所以懂他们的需求还是很重要的。我觉得他们就是想要一个能够快速帮他们解决问题。

公司主体很干净就是美国美区的

2026-08-12 10:42:43

公司主体很干净就是美国美区的

泛化的原理 research

2026-08-12 13:39:45

泛化的原理 research

联系人机制决策和执行安全系统

2026-08-12 16:00:22

联系人机制决策和执行安全系统

contacts 为单位 research

2026-08-12 18:05:45

contacts 为单位 research 的一些思考

中文 、 英文名称，各个平台探索

以及 contact 为单位的时候

补充： 错误召回的污染问题

搜索策略： 以 contacts 为单位去 search ，然后的话可以结合 memory 中的 context 去交叉验证

我说我后面把我的解决思路也抽象为 SQL

2026-08-13 00:59:07

我说我后面把我的解决思路也抽象为 SQL，我现在已经开始追根问底了。把这个过程也抽象 skills

如果我不行，说明我在这条路上没有天赋

2026-08-13 09:19:16

如果我不行，说明我在这条路上没有天赋

Jason 好像距离更远了

2026-08-13 09:34:24

Jason 好像距离更远了

如何快速的找到这个人

2026-08-13 11:37:01

最主要的原因就是清晰用户是一个什么样的人

清晰 review 的人的颗粒度是一个什么样的

Diff 中关于 Dev 、 main

2026-08-13 12:25:38

Diff 中关于 Dev 、 main 之间发布的策略以及关系的问题

如何验收的问题

如果一直很迷惑，一定是认知的错位

2026-08-13 14:09:23

如果一直很迷惑，一定是认知的错位，补充的不应该是知识和理解，而是认知

最本质的原因去区分出来的一部分的人可能是噪音

2026-08-13 14:55:29

最本质的原因去区分出来的一部分的人可能是噪音

排序的逻辑 、领英的关系网 search 可以

2026-08-13 18:56:14

排序的逻辑 、领英的关系网 search 可以 search 出来

领英的图像

但我现在我发现我自己学乖了，在这个过程中

2026-08-13 21:47:49

但我现在我发现我自己学乖了，在这个过程中，我有他们自己本身的一些方法，然后怎么样去追问题，怎么样追到合适的颗粒度，怎么样去演练这个问题，怎么样判断，为什么要用这个框架。

嗨Siri，我想要那个 Linkin 的哦，好

2026-08-14 18:57:15

嗨Siri，我想要那个 Linkin 的哦，好，谢谢好

找问题，实际上就是找失败的链路

2026-08-15 00:54:38

一条一条的去寻找失败的链路，追溯到的一个又一个可以被证据区分，被行动改变的原因

颗粒度过粗会导致任务搜索不准确

颗粒度过细会导致过度关注的某个函数表达式的问题

所以沿着路线去挖掘，深挖，一直挖，挖掘到具体合适的颗粒度定位到这个问题然后解决，到此为止 …

目标感是我一直匮乏的

2026-08-16 10:42:08

我觉得目标感，确定目标很重要的

围绕这个目标看看自己能做什么，有什么可以做的，到底有没有捷径可走

如果没有强烈的目标感，我觉得人是会很难受的，学习是没有意义的，做事情是没有意义的

确定一个目标，然后加强去做吧，做有意思的事情

真实

2026-08-16 13:03:58

我感觉自己还不够

还不够清醒的选择自己愿意承担代价的人与事，并且在其中真实的活过

去真实在场，去拥有选择，去敢于承诺，去建立真实的连接，去和有限性和解

失败了又有什么关系呢

2026-08-17 10:01:43

再来一遍而已

真正害怕的其实是没有真正的去做自己

金淦 案例 lint case

2026-08-17 10:22:30

金淦 案例 lint case

去接近现场

2026-08-17 13:50:50

发现很多问题都是可以通过追问得到的

name

2026-08-17 16:22:40

alise

context

maybe incomplete

Adversarial

要不要有一个轻量级判断skills是否去检索联系人

2026-08-18 01:24:43

要不要有一个轻量级判断skills是否去检索联系人

关于的context 召回的问题：

2026-08-18 11:17:47

如何 search ， 如何召回？

施宏斌： 无公司名称和链接， Xbanker.ai（没有意义的污染的数据源）

关于其中的 context 问题

2026-08-18 13:41:19

关于其中的 context 问题

harvestapi~linkedin-profil

2026-08-18 14:23:25

harvestapi~linkedin-profile-search

name + context

Actor run

DatasetID

Get Dataset

拿到记录后

必须有姓名和合法 /in/ LinkedIn URL

提取 headline、location、当前职位、历史职位

按规范化 LinkedIn URL 去重

同一人被多条路线召回时合并履历

用原始 hard clues 重新评分

最终只返回 Top 3

fetch_linkedin_posts(profi

2026-08-18 14:47:20

fetch_linkedin_posts(profile_url) 对帖子进行的检索

如果用户已经确定的话，可以把帖子之类的也给召回

看一个问题，整理需求，看最开始的实现者的一些信息

2026-08-18 16:30:47

看一个问题，整理需求，看最开始的实现者的一些信息

site:linkedin.com/in “王锐”

2026-08-18 17:02:19

site:linkedin.com/in “王锐” “出海”

非常依赖网页中出现完全相近的词语

并且排序还是以字符串匹配为主

召回上限由 Apify/搜索引擎决定

待评估的部分

2026-08-18 17:17:56

待评估的部分

有痛苦才会有最深刻的体感，有最深刻的体感才会有最深刻

2026-08-18 20:13:21

有痛苦才会有最深刻的体感，有最深刻的体感才会有最深刻的思考。所以我觉得痛苦好像没那么可怕，它是我人生中的必经之路

痛苦就像是动力一样，促进自己往前再往前。

可能对于他们来说，其实也是一种看法

2026-08-18 20:39:52

我觉得可能对于他们来说，其实也是一种看法，其实也不是妥协自己

我只是观察一下，kiwi 到底是怎么样去对待她的员工

以及他怎么样去对待一个新人

是否会想着给新人一些空间

但是我觉得说的很对，如果一个团队，他既不让你做自己

2026-08-18 20:45:42

但是我觉得说的很对，如果一个团队，他既不让你做自己，又喜欢打压你，那我觉得是有问题

所以倒不如做自己，让自己开心

关于 Exa 的优化的策略， 对比 Apifix

2026-08-19 11:51:27

Apifix 的搜索策略是否应该保留下来

Exa People

2026-08-19 11:51:38

├─ 找到强候选

│ → Apify 只抓这个 URL 的详情

│ → 姓名匹配 + 至少一个公司/职位/地区锚点

│ → 直接停止，不再重复搜姓名

│

├─ 找到候选，但姓名冲突或证据不足

│ → 执行 Apify required name routes

│

└─ Exa 为空、失败或超时

→ Apify required name routes

→ 必要时再走 Serp fallback

Exa 存在的最大的问题是search的价格高

2026-08-19 11:55:19

Exa 存在的最大的问题是search的价格高，但是很准确

Exa 还有一个问题就是数据可能是过时的

偶发的，LinkedIn 页面变更，隐私设置问题，People Index 官方说明按周刷新，平均索引延迟约 3.5 天，理论刷新窗口约 0–7 天

多平台的搜索策略

2026-08-19 14:12:07

单工具 vs 多工具

几个平台，如何交叉

skills 应该设置一个 todo ？

Exa 的一些测评效果如何

2026-08-19 15:29:34

分析如何接入的这个逻辑，如何调研这个逻辑

对于各个平台，我们去搜索一个人的时候

2026-08-19 18:38:03

对于各个平台，我们去搜索一个人的时候，对一个人真实的建模的时候，是否会有一些技巧

比如说针对各个平台

kiwi 感慨控制欲真的很强烈

2026-08-19 21:54:09

她甚至对一些没兴趣的人或者事情非常没有耐心

看见双重标准带来的割裂感

2026-08-19 22:35:55

你会看到非常矛盾的画面

对外面对顶尖人物，周到、克制、愿意倾听，细心维护珍贵的精英圈层关系

对内面对团队里普通人，不耐烦、容忍度极低

生产力这个场景好像没有什么可挖的

2026-08-20 00:26:02

生产力这个场景好像没有什么可挖的，这一层好像最终还是会被模型层给吃掉

我们人是如何了解另外一个人的

2026-08-20 09:02:50

ta 做了什么？

ta 是什么背景？

ta 最近状态是什么？

ta 发生了哪些变化？

ta 对哪些事情感兴趣？

我们有哪些共同点？

我们有哪些可以聊的话题？

我突然想起来，跟 kiwi第一次见面的时候

2026-08-20 09:29:08

我突然想起来，跟 kiwi第一次见面的时候，我就有一种比较深刻的感受

她从一开始没有把我当做伙伴，而是 white 的辅助品，类似于外包的位置，对于我甚至一点兴趣都没有

让 kiwi 真正可以接纳的，只有一种人

2026-08-20 09:45:53

就是最开始她自己挺感兴趣的人

并且在这个后续接触过程中，可以得到很多正反馈

那么就一定要在某一个地方，有一个非常非常明显的优势

并且这种优势一定要非常具象化的表现出来

或者是招进来的就是非常非常好用的工具的人

微信如果有背景的话，好像识别不是那么好

2026-08-20 13:03:37

微信如果有背景的话，好像识别不是那么好。

ailoha 是一个动词

2026-08-20 19:12:57

确实也可以反过来推出来一个用户的心智

这个动作真的很重要

佩服 kiwi

2026-08-20 21:41:52

很厉害的一个人

对世界和社会的观察与理解

kiwi 是一个学识很高的人

2026-08-20 21:42:10

kiwi 是一个学识很高的人

好好学习，好好抄袭

2026-08-21 12:42:41

好好学习，好好抄袭

ailoha 其实后面都会加一个感叹号

2026-08-21 17:00:47

这是一种用户心智的行为

是对于碎片化信息记录也是有很多的启发的

2026-08-21 17:08:11

突然想到，其实是对于碎片化信息记录也是有很多的启发的，怎么样去记录碎片化信息

策略： 广度发散，后深度

2026-08-21 17:53:54

评论优先，无论是一级评论甚至二级评论（sub_comments)

评论数高的帖子质量高，分享数高的帖子最有传播价值，收藏数高的帖子最具有实操价值，点赞数高的帖子最具有普遍认可性

Context 最本质的就是：

2026-08-21 19:02:11

attention budget 中，提供最少但是最高信号的信息

我在想，就是它最开始进入的时候

2026-08-22 12:07:46

我在想，就是它最开始进入的时候，应该也可以去有一些其他的进入方式。首先我们来讨论一个环节，就是它的 action onboarding 这个按钮

因为我在想，就是手机上或者是很多时候，就会有一些需要记录的信息。那么这时候还可以作为一个信息的记录的工具

ailoha 记录的是人与人之间的关系

2026-08-22 13:03:19

但是如果有些人不是很需要很多的关系呢？

为什么人一定需要那么多的关系？

一直在找的是向内探寻

关系归根其实也是自我的探索

所以归根结底最终也是一种自己内在的投射

Ailoha 很容易把关系优化成更精细的 social capital management，及时他们不认同自己是 CRM ，但是这样用户画像决定了他们的日常使用场景是偏向于通过关系获取利益的场景

ailoha 真的很能占领用户的心智

2026-08-22 13:15:49

这个本质就是在某个具体的场景出现的时候，用户能自然而然想到你的，并且预期你能带来一个明确的结果

既然有用户心智，那么自然而然是有层级而言的

包括品类描述的是它到底是什么的，场景描述的是我什么时候会想到它，结果就是用完以后到底什么会变好，身份描述的是使用它说明自己是一个什么样的人

用户的转变是产品价值

用户的自我身份认同是用户价值

就像即刻的群体的，即刻的最开始的用户会去刻意营造一种感觉

用户身份的认同感，使用的时间，发布的帖子等等

Allalong 是一个很好的代词

2026-08-22 13:38:32

ailoha 把人与人之间的理解的成本从 2000 美元一小时降低为 -

但是 allalong 把对自己的理解也是这样的

需要额外的培养的一种能力就是表达能力

2026-08-22 15:08:53

感觉现在的表达能力是匮乏的

Ailoha 不是帮助你管理关系

2026-08-22 15:30:11

Aloha 不是“夏威夷岛”的名字，而是夏威夷语中包含爱、情感、善意、同情及问候等含义的词

它是在你的一生中，理解「你如何成为你」

关于硬件的问题

2026-08-22 16:55:21

P0 ，语音输入的问题，输出问题

P0， 蓝牙

碰一下， 音响的方式

长续航的能力

控制芯片

网络模块，

P0 存储的问题

语音，

同步的方式，

基本的传感器，

拍照，720 的

应该还有一点比较好的，就是那个然后去以最快的速度去加

2026-08-22 18:57:38

应该还有一点比较好的，就是那个然后去以最快的速度去加载到当前的 session 中，我觉得还蛮有意思的

但这时候它其实对于notes 的召回或者是 Memory 的召回还是有要求。

面对死亡时，什么值得相信

2026-08-23 11:42:17

无法控制结果时，如何承受？

做错事情后，能否得到宽恕？

没有生产价值时，是否仍值得被爱？

为什么要对另一个人保持长期忠诚？

为什么真理、善和人类本身值得追求？

Kiwi 也是需要理解和解释

永远站在系统外面，理解它、拆解它、评价它，却很难允许某种关系、传统或共同体反过来塑造自己

但人只有在某些时刻停止做观察者，成为参与者，才可能得到归属

你自己要求确定性自然而然要求聊天的对方要求确定性了

2026-08-23 14:42:12

这一点必须要改变自己

另外自己的语言组织和输出的能力也很重要

希望小鸭子可以帮助自己完成这样的愿望

没有实感，不去理解整个链路会让人感觉到非常的痛苦的

2026-08-23 15:33:32

没有实感，不去理解整个链路会让人感觉到非常的痛苦的

可以试试开发出来一个基本的产品，然后让

2026-08-23 16:24:34

可以试试开发出来一个基本的产品，然后让 Alloha 接入进来看看

应该可以有不错的效果

merge contact这个过程

2026-08-23 16:41:33

我觉得就已经约束了很多人的使用体验

未必需要这么多的联系人，联系人无非也只是内心的一种映射关系

发现还是有一个问题

2026-08-24 13:53:54

最开始截图的是 A

后面我希望 ailoha 我询问就是各个平台探索这个人信息

然后发现 ailoha 研究的是之前有过的联系人 B，而不是探索的是当前的这个人的信息 ….

截图上传后，系统记录这个人信息和截图信息

模型通过自己去阅读整段历史，然后猜测这个人是谁

context 中同时存在两种人物

一个是截图的对象，一个是历史真人

第一轮：

2026-08-24 14:00:33

图片 → 正确读到截图中的未知聊天对象

Memory → 同时带入历史联系人

Assistant → 回答时又提到了某个历史真人

第二轮：

用户说“探索这个人”

→ 系统没有记录“这个人 = 第一轮截图对象”

→ 模型把“这个人”解析成上一轮提到的历史真人

→ Social Tools 开始查询该历史真人

Mini mac 不知道为什么连接不上了

2026-08-24 16:25:18

我让 codex 使用 clash verge 去配置一个新的 profile

然后 做着做着 就没动静了

侧重在即刻上面

2026-08-25 09:05:21

如何发帖如何读取如何拉下来

找出问题，定义问题和判断问题

2026-08-25 13:30:50

找出问题，定义问题和判断问题

评估如果可以用程序评估当然更好了

2026-08-25 17:01:50

但是很多时候没办法用程序，往往是非结构化和多字段的

需要为每张图片建立事实账本

记录一些关键的事实

关于 Suggestions 的一些思考

2026-08-26 10:54:35

只有深度的分析流程才可能产出 selectOptions

System 中的 Suggestion 目前有一些额外的约束语

开屏的品牌启动动画有必要的，覆盖最开始的初始化的时间

2026-08-26 11:14:51

品牌视觉是有必要的，但是显示时间不是有意设定的，停留时间主要取决于真实冷启动耗时

首次品牌展示仍完整保留，但 RootPage 会在下面并行准

关于导航栏，好像真的不会用到现在的导航栏

2026-08-26 13:36:27

关于导航栏，好像真的不会用到现在的导航栏

版本发布这部分也需要额外的注意

2026-08-26 15:09:49

人的注意力都是有限的，所以如何最可爱，最便捷，最人话的方式把更新讲清楚，并且站在用户的角度上讲清楚很重要

以及 what to test 这个描述是如何生成的

2026-08-26 15:20:19

版本发布这部分也需要额外的注意

人的注意力都是有限的，所以如何最可爱，最便捷，最人话的方式把更新讲清楚，并且站在用户的角度上讲清楚很重要

第一解决报错

2026-08-26 15:45:27

第一解决报错

Judge 很适合分析评价

2026-08-27 11:00:22

哪一个更好，好在什么样的维度，是否存在明显的退化

最终得到的是一个新版本的高胜率的东西，各个体验维度的胜率

动画其实是一件很虚伪的事情

2026-08-27 11:50:18

我相信站在任何一个用户来说

如果一个动画明明并没有实际的含义，只是为了证明自己的品牌效应

那么我觉得这就是一种产品自嗨，以及用户欺骗

慢一点，但是准确度高一些

2026-08-27 14:10:27

我们公司给我的感觉就是，感觉每个人都很忙忙碌碌，有一大堆计划，做的很快很好，大家都很精英，天才

所有人都在高速运转，但我不知道这台机器到底开往哪里

大家都在共同解决什么样的重要问题？？？ 这个重要真的重要吗？？？ 每天围绕这些这些问题做了一系列重要的事情，这些事情重要吗？？？

给定的问题真的值得解决吗，用户体验感真的更好的了吗，产品自己运作，复利的优势真的建立起来了吗

kiwi 对我：

2026-08-27 14:11:19

质疑得更强 → 我感到被定性而防御 → 我表达和行动更紧张 → 她获得更多不够清晰的信号 → 继续加强质疑

Fat 环境隔一段时间好像就会退出

2026-08-27 14:50:37

Onborarding 自己体感使用下来每一次进去

发布的过程中尽可能控制变量

2026-08-28 10:04:42

发布的过程中尽可能控制变量，这样可以保证出现问题时可控的

控制变量是一个很好的习惯

一个 CRM 的系统

2026-08-28 11:20:31

但是允许是一个变化的人

CRM 只是一个非常好的载体

CRM 本身就是服务于人的标签

去服务人去更新对应的标签

观察员工感觉没什么问题，看看他们是如何工作的我不排斥

2026-08-28 12:41:02

但是侵入式太强了 ….

shadow labe 可以回答

2026-08-28 13:11:32

shadow labe 可以回答 conditate 是否比 baseline 更好

Trial 的基本单位是某个固定 Case

2026-08-28 15:48:13

Trial 的基本单位是某个固定 Case，在固定配置和独立初始环境下，从开始到终止的一次完整尝试（attempt）

然后 Manus 来说，context

2026-08-28 16:30:00

然后 Manus 来说，context 是运行时的资源

精标，2meet 场景

2026-08-28 19:30:05

筛选 2meet 后的场景服务的对象是：

为什么 2Meet 经常误报

哪些表达被误认为是会面

参与者、时间状态和客套话规则是否有效

但是没办法回答：

真实图片中有多少应该生成 2meet

系统漏掉了多少 2meet

总体准确率

FP / FN 本质上是如何计算的

2026-08-28 21:08:46

persision 是精确率

Recall 是召回率

Positive 是正类

Negative 是负类

TP（True Positive）：模型说有，实际上也有

FP（False Positive）：模型说有，实际上没有

FN（False Negative）：模型说没有，实际上有

TN（True Negative）：模型说没有，实际上也没有

Positive（正类）：这张图片应该生成 2Meet

Negative（负类）：这张图片不应该生成 2Meet

Precision/Recall

2026-08-28 22:24:54

Precision/Recall 告诉你错了多少；FP/FN 原因分类告诉你为什么错，以及应该修哪个判断环节

没有判断力，就加油干，加油学，培养判断力

2026-08-29 00:33:02

知道什么样是好的，什么样是不好的

知道好的品味是啥样的

深度挖掘本质，形成判断

2026-08-29 01:30:02

对世界真实的理解和判断

我对旅游照片的态度的，价值观位移行为证据

2026-08-29 14:16:12

稀缺改变了注意力

以前生活感受充足时，容易把记录看成表演

当时间和生活感变得稀缺，照片显露出另一种价值

所有人都有行为模式

2026-08-29 14:17:39

但是不是所有的人都高度的跨维度一致性

有些人师习惯稳定

有些人是习惯性在角色中一致性

看某个人的选择是否能被同一原则持续预测，看三件事情

冲突时牺牲什么、长期把资源投向哪里、新证据出现后是否更新

标注打分是一个没有意义的事情

2026-08-30 21:52:48

因为设置打分这个行为本身，我们很笼统

1分到底比2分少什么

所以的不如一些正交的维度

解决错问题是一个很严重的问题

2026-08-31 09:03:14

还有实际上也来辅助我们区分表现问题和深层次问题

明确什么样的是完成 什么样的不算完成

thinking 的响应过于慢了，用户看不到状态

2026-08-31 10:18:43

thinking 的响应过于慢了，用户看不到状态，不确定任务是否是在正常推进

这部分的速度思考是否还有什么样的计划

关于 Calendar 和 2Meet 的辨认

2026-08-31 11:45:50

很重要的一点就是，Calendar 是可以区分到具体的时间日期的

这时候即使有时候时间模糊没有那么明确也可以计划到一天

但是 2Meet 是没有一个具体的见面的日期，但是有线下见面的意图的

更新后可以升级为 Calendar

地点可以反过来发送给用户确认纠正

因为实际上标记的过程中有大量的一些模糊的东西，回归到产品角度的理解，技术角度的理解和用户角度上理解，是可以完成标注的

从结构上的出发，实际上 Calendar 应该最好是一个完整的结构

Calendar 回答的是我什么时候必须要做什么？

2Meet 回答的是下一次回到了某个地方，我想见谁，做什么？

2Meet 的确认更轻，Calendar 是强确认的

2026-08-31 15:40:24

有完整的时间，一般都属于 Calendar

有一个异地场景，我们有一个小男生

2026-08-31 16:01:24

有一个异地场景，我们有一个小男生，联系人只有一个女生，和那个女生异地

然后询问的最多的就是，那个女生到底是怎么样想的🐶

What is he/she actually thinking?

信息丢失是一件很痛苦的事情

2026-08-31 17:40:21

这部分是否产品有一些比较好的解法

我理解用户上传了自己的信息，肯定是希望自己被记住的

标注过程中我觉得最难做到的一件事情就是对产品规则的定

2026-08-31 17:43:58

标注过程中我觉得最难做到的一件事情就是对产品规则的定义没有那么清楚

比如说 Calendar 和 2Meet 之间的关系是什么

如何定义时间

需要抽象的能力以及具象的能力结合

2Meet 产品的定义是和某一个人没有具体的时间，但是有清晰的见面的意图

学会发现产品规则本身的漏洞

2026-08-31 17:56:16

只知道日期能不能建 Calendar

缺少具体时间是否允许创建全天事件

地点缺失是否影响创建的一系列问题

conversastion 中提到了 meet 和产品真的 actions 是两码事

有空聚聚这种完全只是客套话，不该生成的

我想约你吃饭，这样的也是单方意愿的，也不一定生成的

“周六见”“好”是双方承诺，可以行动

“下次当面聊，但时间再定”是 2Meet

“我们上个月见过”是历史信息，什么都不生成

标注不是一件简单的事情

2026-08-31 18:09:44

理解任务背景和 rubric 很重要

然后如何理解也很重要

标记过程中遇到了对产品语义不清晰，不要强行选标签

2026-08-31 18:20:37

标记过程中遇到了对产品语义不清晰，不要强行选标签，而是标记为 disputed 、Unknown ，进入产品裁决，可能是几类合同缺口：

产品概念没有被写成可执行规则。例如“想见面”究竟要求双方明确承诺，还是礼貌表达也算

原始证据不足。例如无法确认 Kiwi 是否参与者、交流是线上还是线下、是否已经排期。

多个阶段被混在一起：理解到了、提出建议、用户确认、实际写入 Calendar，是四种不同状态。

标签粒度太粗，无法表示“需要澄清”“无需动作”或多个都合理的结果

产品团队自身还没有形成稳定共识。此时标注分歧其实是在发现产品标准，而不是标注错误

这个时候我觉得正确的做法应该是，冻结该 Case，不猜答案，然后分开记录：

fact：截图中明确出现了什么

inference: 标注员如何理解

product question：哪条产品规则尚未确认

写一个最小裁决的问题，比如说“双方说‘下次有机会见’但没有明确承诺，应该进入 2Meet，还是 none/clarify？”

交给具名的产品/domain authority 决定；高风险副作用 Case 再由独立 Reviewer 复核

把裁决写成“规则 + 正例 + 反例 + 会推翻它的条件”，然后重新标注所有受影响 Case

notes 的产品定义是，关于这个人和这段关系

2026-08-31 18:32:58

notes 的产品定义是，关于这个人和这段关系，未来值得记住的信息

可以是联系人维度的用户可读记忆流

对方的背景、偏好、沟通方式

用户或者三方对他的评价，但是要保留来源

关系状态、机会线索

Notes 是联系人维度的，记住意图的背景和关系事实，但是不承担意图的生命周期

锚定到一句话

2026-08-31 18:50:28

非常具体的一句话

具体到对应的人群一眼就看上了

什么样的人群，有什么样的关系

我笑了

2026-08-31 22:49:28

模型一般在某个问题上表现的很差

很多人的第一反应就是，模型应该是哪里不太行？

三、产品、工程与开源

96 条记录

只选一个方向，连续跑 90

2026-08-09 20:13:41

只选一个方向，连续跑 90 天；开始前亲手写下三项具体数字、预算上限和退出条件。期间不新开项目，不提前搭自动化工厂，每周必须获得付费、拒绝、复购或流失中的一种外部证据

ailoha 关于 ios

2026-08-11 00:42:50

#ailoha 关于 ios 测试是否有一些非常好的建议和启发

Android 目前设计主要是以一种对

2026-08-11 11:31:36

Android 目前设计主要是以一种对 Android 理解为基础做的

而不是 RN 的方式去做的

手感的理解，四个维度：

2026-08-11 16:02:38

触控响应时延（Touch-to-Photon Latency）

帧率稳定性与掉帧（Frame Hitches/Jank）

物理阻尼与动画曲线（Spring Physics & Animation Curves）

触觉反馈同步性（Haptic Sync）

在过去，“手感”被认为是一种纯粹的主观艺术，必须依赖顶尖 UX 设计师和工程师反复手动微调。但在当今前沿的 AI Agent 与自动化工程体系中，“手感”已经被高度解构为可度量、可计算的客观物理指标

IOS 延时，以及 RunLoop 设计，AI

2026-08-11 18:12:21

IOS 延时，以及 RunLoop 设计，AI Agant Harness 的 loop 设计

架构图的深度的思考分析，是否有一些值得探索的设计的逻辑

/goal 深度分析整理当前项目有哪些大的环节和模块

2026-08-11 20:02:24

然后最终以完成一个 linear 任务为目标，设计整套新手上手指南，以及整个链路完成过程中的教学，培训，方便用户理解上手的项目

确实，我觉得他们说的很对。大部分时候其实是边做边学的

2026-08-11 20:23:29

确实，我觉得他们说的很对。大部分时候其实是边做边学的，大部分时候其实是没有办法去完全学清楚之后，然后再去做。创业公司好像也没有时间，也没有这个精力去做这件事情。所以能做的事情就是快速上手。所以他围绕很多问题，基本上都是围绕你，让你去快速上手这件事情去设计了一些问题。我终于明白了

包括整个 IOS 前端的设计的逻辑

2026-08-11 21:25:35

包括整个 IOS 前端的设计的逻辑，我需要你深度的探讨目前所有的结构，以及架构的问题，先把现在的前端的代码的架构深度的分析的，理清颗粒度的问题，结合 UI ，以及真实的 E2E 测试，深度的理清架构的设计问题

/goal 深度调研，我希望你能够充分的使用本项目的

2026-08-11 22:02:10

/goal 深度调研，我希望你能够充分的使用本项目的所有工具以及当前仓库的所有的一些文档以及描述。然后我希望你能充分的为前端设计一套自动化体系，然后我希望能够覆盖Hernias agent 的测试，充分发挥测试的能力

我希望你先去做的一件事情，就是先调，先去调研现有的一些目前的部署架构。然后我希望你能够深度地去，我会给你一些设计文档，然后你去深度地评估，然后以及你自己去search一些非常好的、非常前沿的一些AI agent native 团队，他们的一些工程方法，以及测试以及CICD的整体实验。我希望你能结合当前的工作流去优雅地结合

然后给出深度的改进建议，设计文档，包括现有以及改进后的部署的架构图，那部署架构图最好用一些目前scale去设计，可以灵活展开

然后希望给出一些本地化调研和分析

2026-08-11 23:03:50

然后希望给出一些本地化调研和分析。这个计划明天主要还是提出的对这个发金佑的一些基本信息源，我希望最终可以把它提供给自己的同事去阅读。对应的阅读载体主要还针对测试，而且和 CCD 以及用户场景，还有手感真实体验。不说逻辑简单的，就目前的整个 get 工作量没有改变，把这些教务图集成到一个大的网页里，然后结合这些内容去整理进去。有一些非常明确的工作，以后变化不大的，尽可能认识。还没端午节，他的测试金字塔很值得学习，最开始静态，然后运行频率就是 PR 的级别，每一次的 PR，然后每次 P 也是每次皮，再然后挤能逻辑的话也是包括测试的话相对来说也是简单的，然后最后是非 van’t，因为这个还是一个小的 back 每个票，然后全亮的每天晚上为是每个大的版本，比如说累死，然后最后就是专辑的一种生性，他就是也是人员方式，我绝对不会设置很对，但是具体最后页面的话，可能还是需要比较让人清晰易懂，就学具体的计划，安排整个的工作流程，因为不仅仅是给自己看，是给其他的同事去看。现在最好是把当前的一些工作流简单地优化一下，包括它的无聊转移，下一个周期什么样子的深度的心态出来，然后再网页方式发给朋友看一下。这个跨仓的话最开始因为他是设计到三个仓库吗？一个就是前端上，还有一个后端，还有 A 键，然后 A 键可能重新重一下，它相对来说可以尽可能的放在第三阶段里面去，然后爆装了，还相对来说可以做一些挨到三的阶段性的设置邂逅，就是前段的话就完全没有问题，就是全部都可以去计划，然后设置放在最高有限制。

重构

2026-08-12 10:52:25

盛超

金淦gan

设计稿，到合适的颗粒度的问题，需要深度的探讨和设计

结合 SRE 的情况

2026-08-12 11:50:20

合适的评估的逻辑，应该确保一些类型都可以正常的处理，这些问题可以围绕一些大的模块去设计，比如说根据联系人

我在想当前是不是有一些skill，就比如说当前仓库

2026-08-12 11:53:34

我在想当前是不是有一些skill，就比如说当前仓库，我每次在让你去撰写调研文档的时候，实际上现在基本上都是网页驱动嘛，就网页作为一个input入口。然后这时候我其实就是很想能有很多比较好的设计，就比如说现在网页，因为它自己本质上还是本地的一种静态网页嘛，但实际上我觉得很多设计就是它可能后面要去发布，就是那么这时候我就想要一个skill，就是它可以完成发布的逻辑，就是它不仅是可以把这个目录以及对应的同级别的目录以及子目录，然后映射出去，基本上我希望就是外部都可以访问到，就是这个网页中的所有资源。所以相对来说，希望你就是做这样的一个skill，然后可以做这样的一组转换发布，

帮我research一下，linear上面其他的做的

2026-08-12 11:57:50

帮我research一下，linear上面其他的做的一些类似的任务，以及他们的解决方法，包括链接 linear 还有GitHub ，我想深度的整理所有的这种 but ，整理出一些通用的逻辑和能力

完了，今天又受到打击了，感觉今天就是被狠狠的骂了一下

2026-08-12 22:28:24

完了，今天又受到打击了，感觉今天就是被狠狠的骂了一下，因为感觉自己还是不够，不懂工程能力，没有这个工程能力，因为工程能力本质上还是一个找到问题的能力，以及定位问题以及解决问题的一系列能力。但是我现在发现就是现在一个都不沾，所以还是可能跟以前的独立开发习惯有很大关系。就独立开发相对来说，就是很多颗粒度的问题，直接让 AI 去解决，自己也不会去思考，就是为什么要这样设计。但是我发现这种能力，就是系统化思维能力，还有工程能力，在 AI 时代是尤尤其重要的能力

当然不排除我可能会有一些其他的能力，就比如说元意识的能力，然后其他的一些思维的方式的能力。但是我觉得不可否认的是，目前工程能力还是一个非常欠缺的，我准备今天晚上把它补上。

因为其实之前结合黑黑的一个能力体系，我觉得黑黑他就是第一性原理去把所有的东西分析的具有细致，然后再去基础上去深度的去思考怎么样去优化改进这部分。那我觉得他前端可能可以作为类似的一种设计体系，然后我去深度的去挖掘之后，以某一个模块，然后沿着模块走，再去深度挖掘整个类目，然后再去在每个类目里面去分析，就是这个设计的是否合理性。对它有一个非常本质的判断，然后再去选择一些比较好的设计，再去优化掉现有的设计体系。但我觉得这部分就是有一个很重要点，就是你知道为什么要这样做。因为你知道为什么不能这样做了之后，知道它原理之后，你就可以设评估了。然后评估它也可以设评级的，比如最低层级的 etoe，再到非常细颗粒度的，再到比较高颗粒度的，我觉得都可以有一些比较好的设计体系去解决这个问题。所以我准备今晚的话，相对来说可能会解决一些问题，并且深度挖掘这些解决问题的步骤是什么样子的，以及如何去审评这个过程，是否可以得到一个比较好的效果。以及哪些东西需要自己判断的，哪些东西可以让 AI 去帮自己去代替掉的。以及怎么样去把这个流程给设计出来

white 在工程上帮助了自己很多

2026-08-13 09:14:27

white 在工程上帮助了自己很多

white 也是希望我不要损失掉技术和工程的品味颗粒

2026-08-13 13:42:38

white 也是希望我不要损失掉技术和工程的品味颗粒度的问题

并且一套分析问题以及颗粒度的方法，很受启发 ,,,

颗粒度提到好多次

2026-08-13 14:03:17

感觉这个应该叫工程认知颗粒度

还不够，更多的去测试和描述，结合你该的所有的内容， 抽离出一系列的颗粒度，然后分析之前的问题，说清楚问题以及上下文，能定位到这个问题的工程认知颗粒度

以便于我去针对这个问题补充对应的认知理解，建立判断所需要的基本的品味

以及说清楚怎么改，为什么要这样改，改了之后有什么样的好的测试评估标准

工程判断力的核心：不一定需要时间的积累出工程的判断力

2026-08-13 14:23:40 · #领域/软件工程

但是也可以很快的建立基本的判断力，关键是把三件事情分开：

先测量，再归因，后设计

先理解： 这些分类确保不是互斥的，一次页面的卡顿可能是多种原因，拆分颗粒度到一定的程度，区分出来现象，测试这个现象有很多种方法，可以依次去思考，有一套 AI 的方法轮去分析测试出来原因

再归因： 判断这个问题的本质是什么的，如何判断这个问题

最后再设计：设计到实现有距离， AI 给出的设计需要 review 分析判断，需要你自己也去深度的理解，确保没有问题，不变量是尤其重要的， AI 可以生成大量正确的局部代码，却可能破坏全局的行为，工程师需要非常的明确，哪些行为绝对不能改变，谁可以拥有状态，谁可以修改状态

定义不变量

设定改动边界

设计验证信号

让 AI 小步测试实现

用测试和性能数据纠正

进入生产

守住不变量的前提，需要建立足够颗粒度的工程认知

2026-08-13 14:26:14

不需要先理解整个系统，而是需要对“本次改动的因果链、边界和状态生命周期”理解得足够深

整个系统：广而浅

相关链路：窄而深

跨层边界：非常精确

如何判断拆到合适的层级

2026-08-13 14:36:30

white 的方法是知其然知其所以然

但是还是不准确，工程本质上是管理人、代码和 AI 之间的关系

人与人之间的认知的成本，代码的可维护成本

人与人之间的认知的成本本质上还是有工程认知颗粒度对齐的

如果一个问题太过于复杂的话，AI 可以写出来未来的维护成本很高

对于工程师来说拥有一定层级的认知的颗粒度是很重要的

这个认知的颗粒度用工程上的方法是确定到不变量，定位到根源，有一些更好的 research 的方法，能描述清楚

我突然想到

2026-08-13 14:54:06

即使是在工程领域，也要利用自己的工程优势

然后去得到一系列的反馈和认知

利用对应的反馈和认知去补予自己

对于引入组件的思考，1-10

2026-08-13 17:53:48

新的组件必须要回归到业务价值，是否可以创造出一些新的价值，以及组件本身的架构设计，对应的风险

对比之前的方案，是否有一系列的问题

我观察下来，就是我感觉是有很多问题的

2026-08-13 21:47:23

我观察下来，就是我感觉是有很多问题的，就是踩过很多的坑。因为最开始还是按照自己以前的一种设计和开发的习惯，实际上就是和团队本身的颗粒度是非常不一样的

而且其实双方的品质及验收标准也是完全不一样的

所以相对来说，我前期都会用过很多的过去的经验，然后去做这样的一个项目，就会踩过很多坑，发现

但我觉得如果对这个问题有一些非常清晰的定义和准确的判

2026-08-13 21:50:10

但我觉得如果对这个问题有一些非常清晰的定义和准确的判断的话，应该知道这个问题它有没有哪些约束的边界，它当前在思考哪个环节，以及它面向的用户场景有哪些。然后围绕这个去思考，这个产品的边界应该如何设计，它的代码的质量怎么样去评估，怎么样去验证

取消第一个问题本质及它对应的新的描述

2026-08-13 21:54:54

那么对于搜索来说，我觉得它最大的问题就是现在很多的词都搜索不清。所以最开始应该做的是一个需求，整理需求，需求深度分析，这样的一个过程，就比如说对于搜索来说，他目前最大的问题是一系列的搜索不准确的问题。就比如说这个人，他有些时候可能在领域上，用一些方式去搜索的话，他的排名更高一些，这取决于他目前领英的搜索方式，还有就是他现在搜索很多人了，就是把这些人聚合到当前项目中的

所以最主要的，最开始知道一个问题的时候，应该抽象的阶段性的解决，肯定有一系列的方法的

你就最开始就可以让它去深入去调研，然后这个他工作上所出现的问题，然后呢说出来当前是怎么设计的，跟着让它去写对应的实现的方案

再去深入地去 research 一些其他的厂商是如何设计的，他们的设计方案是什么

再去分析他有没有可能有哪些的改进方案

最后再去分析，这些改进方案分别如何去改进？他们之间会不会引入一些新的组件？这个新组件我不要引入，引入有什么好处？

/goal 基于上面的任务深度分析，执行

2026-08-14 01:07:47

/goal 基于上面的任务深度分析，执行，尽可能收敛，多去判断是否值得改是否有价值改，然后结合验证的标准去执行任务，测试驱动，确保测试都通过

完成之后深度的 review 和改进

然后最后深度的结合修改以及上面的所有的设计到的设计编写文档，这个文档有助于我明天发布给其他人 review（实际上就是可以作为写代码前的设计文档，只是面向同事）另外一篇文档是结合这篇文档补充的深度的一些知识，品味和判断，每一些设计新的设计，或者新的调整都应该第一性原理分析，为什么有问题，以及怎么样改，为什么要这样改，改了后效果如何测评没有问题（反正就是要展现出来 AI builder native的高水平）

while 有很多非常好的工程方法

2026-08-14 11:51:05

知道遇到问题钻研到什么样的颗粒度

针对这样的颗粒度应该如何做技术判断和分析

A/B SDK

2026-08-14 15:34:14

这个好像确实是挺有意思的

考虑用户使用过程中的真实的评估反馈去选择合适的 SDK

正确的步骤

2026-08-14 17:29:37

第一个明确问题，完成一个最小单元的 PR

更多的设计不要

更多的错误发现不要

都放在其他的 PR 中

多的对比的放在设计部分

新同学一定要把第一个 PR 早日跑通拿到反馈

2026-08-14 18:01:20

思考这个链路，查找问题，优化链路

建立对整个 ailoha 的理解分析

API 也可以抽象层级

2026-08-14 18:04:05

可以抽象到合适的颗粒度然后去执行

kiwi 说自己是需要一个上层的解释系统的

2026-08-16 12:45:53 · #领域/软件工程

kiwi 说自己是需要一个上层的解释系统的，让下面的目标、痛苦、选择和努力能够彼此连接起来

它可以叫世界观，生命母题、元叙事、或者人生公理，至少回答下面的几个问题：

世界对我而言是什么？

什么值得我认真投入？

成败意味着什么，又不意味着什么？

今天这件琐碎的事，为什么属于我想过的人生？

所以核心是这个驱动自己下面的所有的一致性的：

最上层解释

↓

我想成为什么、怎样活

↓

当前阶段押注什么

↓

这个项目为何值得做

↓

今天完成哪一个动作

如果这些都很分散的话，我觉得就可能成为孤立劳动，那就会有意义感和痛苦的错位

生命命题： 我一生中反复遭遇的问题

元叙事：你用什么故事，把人生经历解释成一个整体

人生公理： 你依据什么不可再退后的原则，做出判断和选择

母题这个东西，应该是自己一生反复都想到的一些基本主题，我们总是在处理同一个问题，自由、归属的问题，真实与芥辣的问题，有限与死亡的问题

随着人的成长，被处理的越来越成熟

元叙事指的是我用什么样的大故事去解释这一生

人类会通过理性不断进步

历史最终会走向解放

科学能够解决人类的问题

苦难是救赎过程的一部分

人生公理就是的我从哪些不再需要证明的前提出发

数学中的公理，是一个体系接受的初始前提。人生公理则可以理解为：当理由不断向后追问时，你最终愿意站住的那条原则

人生公理与普通观点的区别，在于它会真正参与困难选择

有时候看到一些叔叔阿姨爷爷奶奶一个人出去旅行看这个世

2026-08-16 12:54:44 · #领域/软件工程

有时候看到一些叔叔阿姨爷爷奶奶一个人出去旅行看这个世界，很心酸

我觉得他们看上去是孤零零的，想去看看和这个世界，但这种心酸是我看这种现象之后，自己由内而发去辐射上去的，这是我自己。当然这种辐射有可能是我自己内心的映射，就比如说我变衰老，或者是错过人生的这种恐惧，然后映射到他们身上。但是我觉得更多的是，他确实也在反逼我自己，看清我自己，他反逼我自己想要什么样的人生

一个人把生命支付给安全、体面、规则、他人期待和各种代理目标；等到仍然想看世界时，却发现时间、身体、关系和生活结构已经失去了重新选择的弹性，这是多么可悲的事情啊

人生不能只在功能上存活，必须持续包含由自己选择、亲自在场的部分

保留选择权会悄悄变成不作选择

任何一个动作好像对于用户来说都是有一种认知成本的

2026-08-16 15:55:45

感觉任何一个动作好像对于用户来说都是有一种认知成本的。就比如说刚刚那个 merge 的动作，我觉得就是对于我来说，我是就感觉很懵逼这个动作的意图的，所以我觉得就是，如果是用户价值的话，更多的是应该站在用户他自己本身，任何一个动作是否给他带来一些非常大的反馈，这个应该是用户价值

应该分的是，这个动作它自己本身是否有意义。就 Merge 它这个动作，它可能对于产品设计来说是有意义的，但它对于用户来说，可能对于很多用户来说，它是一个非常的增加他的认知负担的一件事情。

ailoha/测试 Ailoha 写入通道测试 —

2026-08-16 17:19:47

#ailoha/测试 Ailoha 写入通道测试 — 如果你看到这条，说明连接成功。

元skill生成机制：从case到skill的自动化

2026-08-16 17:24:35 · #方法论/元skill #架构思维

如果对齐颗粒度的瓶颈在skill层，那真正的架构级问题是：能不能建一个「生成skill的skill」？

即：不是手动编写每一条对齐规则，而是设计一个机制，让系统从case积累中自动涌现出新的skill/prompt模板。

这可能是在团队中找到位置的切入点——不是做更多执行，而是做执行背后的基础设施。

类比：不是写更多prompt，而是写生成prompt的meta-prompt。

创新代币框架（Choose Boring

2026-08-16 17:24:44 · #方法论/创新代币 #技术选型

创新代币框架（Choose Boring Technology）在AI时代的重审

Dan McKinley 的核心论证：每个团队的创新预算有限，技术栈多样性的隐性运维成本会吃掉真正的业务创新空间。用无聊但可靠的技术，把创新代币花在真正的差异化上。

AI时代的新风险：AI生成代码让人以为自己懂了一个技术栈，但其实只是掩盖了不懂——虚假信心的运维成本比选错技术更高。

实证：DSH（Cordis微内核）把创新代币烧在底层架构（可逆效应、插件热装卸），但agent实际工作能力没提升，用户感知的竞争力弱于Codex/Claude Code。创新代币的分配位置错了。

关键判断：创新代币该花在离用户价值最近的地方，不是离技术兴奋感最近的地方。

主要显示的地方：

2026-08-17 17:34:23

case debug 大部分的时间

dateset management ，goal 数据是核心的资产

Metrics Dashboard 是看趋势的

可以口语化地这样总结：

2026-08-18 10:11:23

“这次我们测了 6 个人：金淦、王锐、习翔宇、陈斌、雷绍满和施 宏斌。其中金淦、王锐有人工确认的 LinkedIn，习翔宇用来测试会 不会认错同名的人，另外三位主要检查搜索链路和联系人卡。”

旧版本失败，不是因为它没搜姓名，而是搜索方式太死：

中文姓名被拆开后用 strictSearch=true，而且主要看前面很少 的结果。

英文别名没有稳定带进去，例如王锐的 Ray / Rui Wang。

截图里的软标签被误当成确定公司，反而把正确候选过滤掉。

Serp 即使找到了正确 LinkedIn URL，也没有稳定回灌到候选 池。

只有弱候选时，系统容易当成“没搜到”直接丢掉。

Agent 会继续发散搜索，导致联系人卡出现得很慢。

新版本主要做了四件事：

姓名、英文别名、公司和截图软线索分开处理，未经确认的公司 不再作为硬过滤条件。

当 Apify 只有弱候选时，自动进行一次定向 LinkedIn 搜索。

找到 LinkedIn URL 后，直接回灌给 Apify 抓取具体档案，不 再依赖 Agent 自己记得回灌。

研究期间先展示一张基础联系人卡，后续再补资料，同时防止重 复建卡。

效果上的区别是：

Provider 层正确身份的 Recall@3 从 0/2 提升到 1/2。

Alias 使用从 0/3 提升到 3/3。

URL 定向回灌测试是 4/4 成功。

Apify 可观察成本从 $0.672 降到 $0.304。

金淦和王锐的正确 URL 回灌路径已经有代码测试保护。

习翔宇的错误档案不会被标成强匹配，但旧实测中它仍会排在弱 候选第一，排序质量还没完全解决。

但要实话实说：最后一次六人真实 E2E 是在最终几轮修复之前跑 的。当时 Agent 最终召回仍是 0/2，联系人卡虽然最终 6/6 都生 成了，但只有 3/6 在 360 秒内出现。

所以合并结论是：方案和代码值得合并，但应先修完当前 CI，再用 最终 commit 重跑一次六人 Smoke。通过后可以把它作为“明显改善 召回与 UI 反馈”的增量版本合并，不能表述成“人物召回已经彻底 解决”。

但现在金干和王瑞是大概率可以通过工程商解决的

2026-08-18 10:22:06

但现在金干和王瑞是大概率可以通过工程商解决的，没有问题的，可以搜到的。但是现在还有一些其他问题，就比如说陈斌，就是那种姓名重名率很高，但如果没有确定公司职位或者城市或者英文名的，搜索出很多候选人，就没有办法判断出这个人。然后林商满，林商满的话就，

Exa People Search 解决了其中的

2026-08-18 17:36:52

Exa People Search 解决了其中的 name + context 检索的问题

可以代替 apify 候选的发现层，并且如果有召回 linkedin url 或者 SerpAPI 有拿到好的 url 那么可以直接使用 LinkedIn 的 URL 搜索来完成目标

但是已经有了 Exa 为什么还需要 person search 的部分和逻辑？

Exa People Search 的 API

2026-08-18 17:59:53

Exa People Search 的 API 说明：

Exa 可以作为 e2e 的部分，一起把结果返回回去

https://app.notion.com/p/A

2026-08-18 18:34:48

https://app.notion.com/p/AIL-546-Search-Person-V2-Agent-Exa-Review-3c0e28de3c6d811e8336e113262e62d7

PR 文档

但是我发现 Exa 的话，准确率在百分之九十以上，比自己优化的链路，而且可以降低不到百分之五十的检索成本，我用失败的六个案例测试，基本上都找回了（有一个模糊但是也返回了）

关于 Exa 的集成：

person search 中集成的，maybe 集合 context + name

white 是一个很棒的人

2026-08-18 22:34:16

在我看来是这样的

给我的定位是一个潜力培养者

耐心的辅助，引导自己向前

这让我觉得很幸福

white 本身也是一个工程能力极强的人，非常强的具象能力

如果有机会的话后面可以和他一起创造

我是愿意和他一起向前创造与成长的

kiwi 是一个精英主义

2026-08-18 22:40:05

给我的定位应该是一个工程以及辅助者

但是看我对业务的不熟练会立马得到反馈给我贴上标签

她是一个很没有耐心的人

而且我觉得她对我的判断有所偏差

不过我觉得这是磨合中正常的事情

其实加入创业团队本质上也是一个相互观察和磨合的过程

当前还是有一个问题

2026-08-19 10:25:10

EXA 目前 search 的能力很强了，可以解决大部分的问题

我在封装的工具中集成了 EXA，目前的测试已经的很强了

现在最主要的问题是希望测试一些的关于召回工具的逻辑

新的逻辑跑通

2026-08-19 12:04:58

代码 review

架构描述清楚，边界值，画图

PR

测试的话，准备一些案例，针对 Exa 的测试

2026-08-19 13:44:59

测试的话，准备一些案例，针对 Exa 的测试

如何让 Agent 讲清楚某一个 PR

2026-08-19 14:47:33

第一句话描述出这个问题的本质是什么

最好带上架构图

后续写这个 PR 具象化的一些的描述，架构的改动，流程的改动

以及对应的代码的相关变更

white 是一个极致的工程主义者

2026-08-20 16:17:43

和 white 一定不要通过工程方向和他对抗

而是尽可能在工程层面向他谦虚学习

但是面临工程选择的冲突应该保留自己的见解，不冲突，但是可以通过量化或者观测用实现结果数据去证明

Exa API 优化细节 :

2026-08-20 18:44:26

query、候选返回和停止逻辑档期啊

evaluations 配置 ci 的逻辑

2026-08-20 19:17:20

每一次提交代码，配置改变的时候，都进行一系列的检查以及确定性的测试

ailoha 有时候对图片的理解能力很奇怪

2026-08-21 09:53:33

ailoha 有时候对图片的理解能力很奇怪，有些聊天明明是连贯的，但是因为我和对方信息交叉了，ailoha 认为她下面的是回复的，所以对下面回复的会有很多额外的独立的解释，但是实际上是需要结合她上一句话说的 context，感觉对微信场景下聊天的识别能力不太好

还有一种情况就是聊天框有背景的情况下，不是很理解背景的含义反而过度关联和解释

用 ailoha 去深挖一个人，补充一下这个人 context

因为最近对一些 ailoha 处理社交的媒体很在意，但是后面发现自己 ailoha 了一些人， 但是发现 ailoha 并没有

profile 还有 linkined 这些我在想是否有必要存在

我在聊天框发了一个 notion 设计稿链接以及对方的回复，ailoha 帮我 review 了一下找了一下 but 给出了一些解决方案这点让我惊喜到了

还有一点就是很有意思的是把三方的一些碎片的记录 api 让 agent 接入了一下，ailoha 反而通过记录的工具对应到聊天框，更清晰理解了我们之前聊天的一些洞察，给了一些多维度的建议

还有一件事情，就是有个朋友给我 share 一些图片，大部分的情况下如果不是我熟悉的地点的话，我就会截然而止，发一个祝福就结束了

但是就是因为 ailoha 了一下，ailoha 真的挖掘出来了这个人在的位置是一个是瑞士的一个小城市，然后我就很惊讶，就追问了一下在哪里的，结果问到了他在那边找工作，这单很惊喜到我

ailoha 真的确实加强了和朋友在 im 工具中聊天的交互体验

真实的下场的体感

2026-08-21 13:18:10

去感受工程中的问题和痛点

直面问题和痛点

然后去解决

思考分析前端的问题，快速学习，快速分析，快速上手

2026-08-23 16:52:40

思考分析前端的问题，快速学习，快速分析，快速上手，快速构建

LinkedIn tool 和 social

2026-08-24 10:08:54

LinkedIn tool 和 social tool 已经完成设计实现了，提交了PR ，今天走完 review 的流程

现在开始做前端的重构的部分，整理了一系列的问题，然后今天我和盛超对一下就开始做这部分了

Fat 突然发现有一个非常便捷的使用方式

2026-08-24 15:09:12

Fat 突然发现有一个非常便捷的使用方式，就是可以直接在 actions 中测试和运行对应的分支去选择，然后去构建和编译

github actions cicd 这一点真的很灵活很好诶，默认可以是 fat 自己更新后编译

所以 baseline 和 candidate

2026-08-24 17:55:33

所以 baseline 和 candidate 一直都是一起的

baseline 代表的是当前的基线，candidate 代表的要考试测评的目标线，candidate 表示新的 PR 修改的部分

两者用的都是 code_sha ，而不是一种具象化的分支名

hard gate 定义的情况下

2026-08-24 17:59:27

hard gate 定义的情况下，一次出现就可以阻止 PR

比如说 Baseline 没泄漏，Candidate 泄漏身份值

Eval 不认识 trace schema，却默认通过的这种情况

普通的 gate 用于判断整体比那好多少

所以一般定义一些指标

然后让 Candidate - Baseline

只有 Hard Gate 全部通过，性能和成本改善才有意义

dogfood（内部员工试用）

2026-08-24 18:21:48

↓

soak（小流量长时间浸泡测试，验证稳定性）

↓

gradual rollout（1% → 5% → 20% → 100% 渐进式发布）

为 Ailoha Agent

2026-08-25 10:45:24

为 Ailoha Agent 开通人物搜索和多平台社媒检索能力

付款与管理

付款负责人：Kiwi / 财务

付款方式：统一公司付款卡

账号：使用公司邮箱注册，至少两名管理员可恢复

API Key：dev、FAT、prod 分开创建，存入 AWS Secrets Manager

计费方式：PAYGO 按量付费，不是固定月费

首轮：7 天 FAT 付费试跑

初始预算：Exa $50、TikHub $50

未校准前月度保护线：两家合计 $400/月

$400 是防超支上限（保守上限是 Exa 每月14000次调用上限是 238

服务选择月度价格估算为什么ExaDeveloper PAYGO若 14,000 次都是 Exa 请求，保守上界约 $238/月当前只使用 People Search；Developer 已有 10 QPS、团队 Billing 和按量计费，Enterprise 的 SSO、ZDR、SLA、高并发暂时用不到TikHubPAYGO，保留默认 10 RPS若 14,000 次都是 TikHub HTTP 请求，约 $14–140/月不同接口单价为 $0.001–0.01；当前流量远低于 10 RPS，不需要额外 RPS 套餐或 Enterprise

Exa 当前 Search 基础价为 $7/1k requests，内容 highlights 为 $1/1k pages。Exa 价格

TikHub 当前按接口收取 $0.001–0.01/request；RPS 套餐和请求费用相互独立。

Exa

位置：进入 Exa Dashboard，创建或选择公司 Team，然后进入 Billing 充值。

首次付款：免费接口验证通过后、FAT 7 天试跑开始前。

后续付款：不是固定续费日。建议每月 25 日复盘；余额低于下一周预计消耗或月预算的 30% 时再充值。

管理：为不同环境创建独立 Key，并设置 Key/Team spending budget。余额或预算耗尽时会返回 402，不会无限透支。Exa Team Billing、Exa 预算错误

TikHub

位置：进入 TikHub 用户后台，注册、验证邮箱、查看目标接口单价，然后充值余额

首次付款：免费测试通过后、第一次调用付费接口前。

后续付款：按余额补充，不需要每月续订；同样建议设置 30% 低余额提醒。

支付注意：当前价格页列出支付宝、PayPal、加密货币及 Enterprise 银行转账；较旧官方文档仍提到 Stripe/信用卡，最终以 Kiwi 实际打开的结账页为准

必须强调的注意点

14,000 次的口径必须确认。 用户 turn、Agent tool call、供应商 HTTP request 不是一回事。一次 TikHub 搜索可能同时查询三个平台。

统一付款不等于共用 Key。 付款卡可以统一，但环境密钥必须隔离，泄漏时才能单独撤销。

暂不启用无限自动充值。 建议“低余额提醒 → Owner 确认 → 充值”；积累三个月数据后再考虑有限额自动充值。

月价是区间，不是固定订阅费。 Exa 取决于搜索结果和 highlights 数量；TikHub 取决于平台、接口和 fan-out。

试跑后再定正式预算。 统计 provider + route + environment + billed requests + cost，不记录原始查询、联系人信息或 Provider payload

完整版本已更新到 付费与统一管理方案 (line 80) ，校验通过

需要的配置（不同的 key 用于不同的环境）

EXA_API_KEY=

TIKHUB_API_KEY=

TIKHUB_BASE_URL=https://api.tikhub.io

代码能读懂

2026-08-25 11:41:03

知道解决什么样的问题

知道©生命周期、回收、Delegate、线程和状态同步风险

出现滚动、键盘、富文本、复用错误时，知道去哪里诊断

能判断应该用 SwiftUI、UIKit bridge，还是 Introspect

其他的可以交给 AI

前端的一些问题：

2026-08-25 23:37:11

端到端任务 tracing 目前做的太少了

用户行为和产品分析，有对应框架但是覆盖很少

性能监控和回归测试，有采集，但是缺少指标

怎么看待技术文档，感觉应该回归到代码

2026-08-26 12:57:47

文档只是辅助自己去理解的

项目中应该少一些文档

but 一些比较好的理念，价值设计，一些直觉、一些 taste 相关的可以放在 brain 中

前端一系列的问题，but 需要整理出来

2026-08-26 14:54:10

前端一系列的问题，but 需要整理出来，按照优先级排序，列出来

找出来对应的所有的问题

前端架构的问题

2026-08-26 17:16:38

面向 IOS 多进程的架构，但是不是面向多端的架构

前端架构的问题（2）

2026-08-26 18:07:52

前端架构的问题

联系人的问题

Apple 的 Contacts framework 本身没有问题，但是当前 Ailoha 的问题主要是系统联系人 和 Ailoha 联系人的业务上的错位，导致行为路径不同

当前的联系人的能力的，ailoha 后端

iPhone -> 后端，批量导入，这个问题最大，Onboarding 获得 Contacts 权限后，会直接启动后台导入，每一百条上传后端

Ailoha -> iphone ，这个写入系统通讯录没问题的，用户可以控制

IPhone 通讯录，发消息时按姓名或手机号查收件人

还有就是手机号规范化明显偏向于美国

10 位号码自动加 +1

11 位且以 1 开头也按美国号码处理，但是这不是中国语义吗

其他长号码简单加 +

关于导入联系人的设计：

用户点击「导入联系人」

↓

说明用途、上传字段、数据去向： 现在只是简单的导入联系人，从通讯录导入联系人，Ailoha 会读取你选择的联系人姓名、电话和邮箱，并上传到你的 Ailoha 账户，用于联系人识别和关系管理。不会修改系统通讯录。

↓

选择联系人范围

├─ 选择部分联系人（推荐）

├─ 导入全部通讯录

└─ 稍后再说

↓

调用 Apple 系统授权/选择器

↓

本地生成导入预览

“将导入 42 人，跳过 8 个重复联系人”

↓

用户明确点击「上传并导入 42 位联系人」

↓

上传、进度、结果与管理入口

核心我觉得是 Apple 联系人是可以为 Ailoha 提供身份线索的，但是不能覆盖 Ailoha 的关系记忆，而且 ailoha 的 AI 笔记也不应该自动反向写入系统通讯录

不建议继续使用一个既申请权限、又读取联系人、又转换成后端模型的 LocalContactImporter，建议拆成一个系统适配模块

Apple 实现内部才使用：

CNContactStore

CNContactPickerViewController

ContactAccessButton

contactAccessPicker

CNSaveRequest

业务层不应该看到 CNContact、CNAuthorizationStatus 或 CNLabeledValue。

这也为多端留下边界：

iOS/macOS：AppleContactsAdapter

Android：AndroidContactsAdapter

后端导入合同和 Ailoha Contact 领域模型保持一致

所以我现在觉得就是，Figma时代应该仅仅存在于过去

2026-08-26 19:18:21

所以我现在觉得就是，Figma时代应该仅仅存在于过去，因为代码特别昂贵的时代。但现在实际上代码已经很廉价了，就这时候还需要 Figma去做这么多这么占比的任务，那我觉得是不值当的，还不如说直接用。模拟器，起一个 APP，在这个过程中真实的测试它的点击、滑动、手感、体验。特效，这个过程中我觉得才是非常非常真实的原生的体验

那也不是说 Figma已没有价值了，而是说他的价值已经迁移到了。可能就是在前期，他去帮你完成整个模块的设计稿的时候，他往往是很有价值。但后面往往当你的主题风格已经敲定的时候，如果你不再经历一些页面的大改，我觉得是没有必要去上这么重的组件

这个时候最爽的一个过程应该是你直接就模拟器上 review 修改，这时候再让 AI 去做一些声明式的修改，我觉得是最划算、最值当的

我在想，这次洪水实际上和上一次不太一样

2026-08-26 21:25:17

我在想，这次洪水实际上和上一次不太一样，因为上一次实际上是中国境内，出现了一个问题，比如说 25 年，也就 7 个月前，时间没有隔太久

那时候也已经知道了上游存在高风险冰湖还有滑坡，当天的水位已经检测到异常了，但是还是有大量的人停留在低洼核心区，没有有效的疏离机制，而当时建筑又处于泥石流的路径，所以导致会出现意外

而且我觉得就是灾难本身没有国界，就双方国家都很惨。最主要是看尼泊尔那边是否有明显的汇报，因为天灾不可避免，这种就属于一种没有办法预见的极端的自然灾害。所以从工程角度上来讲，应该是事故发生之后，我们的现有的监控技术是否有提前预警，以及口岸人员是否采拟了合适的措施。所以其实很很重要一点，就是中国这一次到底有没有一些可避免的人员伤亡，有没有把这个风险等级提高到有一定的程度？

重构还有一种方式，就是频繁的测试，关于 App 的

2026-08-27 10:22:51

重构还有一种方式，就是频繁的测试，关于 App 的 input 和 output ，以及整个链路的效果，观察这个效果是如何的

以及这个过程中应该用 agentic testing 的方式

重构的计划应该分期

2026-08-27 10:26:37

先解决紧急的一些 bug 问题

优化一些性能的问题

长期优雅系统的重构的问题

观测驱动重构的方法

2026-08-27 10:53:39

每一次的重构都当做一个可重复的产品实验

用真实的输入驱动完整的链路，通过重构前后的体验差异决定下一步，而不是只是看代码是否简洁

所以这个过程中核心的闭环应该是：

真实输入语料

↓

Agent 操作真实 App

↓

采集 UI + 交互 + App 状态 + API + Agent + DB 全链路证据

↓

与重构前基线做差分

↓

定位性能 / UI / 操作 / 状态所有权问题

↓

实施最小重构，再回放同一批输入

这也是一个 evaluation 的平台

大学前的我是一个巨爱玩的人

2026-08-27 11:34:12

超级喜欢去各个网吧旷课，打游戏，排位

那时候要是有编程和创造的话我想自己也可以做出来一些非常有意思的产品或者设计的

重构前端任务，这一次的方法：

2026-08-27 12:31:20

自己的手感体验产品，每一个细节部分，挖掘问题，分析问题，解法

从前端架构上分析，自上而下分析，遍历前端问题，以及一些比较好的解法

自动化 agentic e2e，测试和量化前端所出现的问题，以及比较好的解法

工程角度： 自动化体系，evaluation 体系，e2e 体系搭建

之前出现的一系列的 linear 的问题

前端目前最重要的部分入手， onboarding

目前最复杂最痛苦的地方切入： 状态所有权

服务的目的：

More perfect !!!

Growh !!!

我们讨论一个场景，你分析现在的灵动岛状态管理的展示的

2026-08-27 18:04:12

我们讨论一个场景，你分析现在的灵动岛状态管理的展示的问题

一个是显示的数据时间，你是否推荐？

然后还有用户在 APP 里面回复后，如果退出 APP， task 还在处理，但是没有灵动岛接管的，感觉状态连续性有问题（当前代码只做：TaskData.processingState = true ，追加用户消息 没有 Activity.request()，but 这里待讨论，如果产品预期只是：截图任务和需要用户操作的卡片才进入灵动岛，普通聊天回复留在 App 内。 那当前行为基本符合现有设计

具体可以验证下面 7 件事

2026-08-27 23:17:19

图片导入占内存太高

Ailoha 不好的设计：多张原图经过 Data → UIImage → 压缩 → 上传，多个任务同时工作，容易把内存顶高。

新设计：页面只保存缩略图和文件身份；统一控制解码、压缩、上传、取消和清理。

Talent Signal 怎么试：把单张截图从选择、保存、OCR、预览到恢复全部改成文件引用，不再让原图长期放在内存里。

补回设计文档的证据：改造前后内存峰值、首张预览时间、取消后残留文件数、重启恢复结果。

边界：这只能证明文件生命周期设计有效，Ailoha 的 1/5/10 张并发仍须真机验证。

启动页挡住真正页面

Ailoha 不好的设计：Splash 固定等待约 2.35 秒，Root 页面也跟着晚创建。

新设计：Splash 展示和 Root 准备并行进行；页面先出现壳层，账号和内容准备好后再开放按钮。

Talent Signal 怎么试：在登录恢复期间先显示可理解的页面骨架，模拟慢登录、登录过期、深链和待处理截图。

补回设计文档的证据：首个可见页面时间、首个安全可操作时间、旧账号内容是否闪现、深链是否恢复正确。

边界：Talent Signal 只能验证安全开放规则，不能决定 Ailoha 是否保留品牌动画。

一个大状态变化，整页跟着刷新

Ailoha 不好的设计：Contact、Calendar、Home 的正式数据、草稿、弹窗、请求状态容易混在同一个大对象里。改一个字段，不相关区域也可能刷新。

新设计：正式数据、草稿、页面呈现、网络命令分别由明确的模块负责；视图只观察自己需要的状态。

Talent Signal 怎么试：在 Web 的截图流程或 iOS 的 Pursuit 工作区，只拆一个完整能力，保持原有恢复和 operation ID 不变。

补回设计文档的证据：改造前后页面刷新次数、一次修改涉及多少状态负责人、原有流程是否完全等价、恢复测试是否通过。

边界：文件变小不是效果，必须拿刷新和回归数据说话。

日历改一个事件，却重算整段日历

Ailoha 不好的设计：事件被反复分组和按天过滤，单个事件变化可能引起较大范围重新计算。

新设计：保留正式事件表，另外建立“日期 → 事件 ID”索引；改一个事件只更新旧日期和新日期。

Talent Signal 怎么试：生成 1,000 和 10,000 条活动，比较全数组扫描与日期索引。

补回设计文档的证据：单日读取耗时、单事件更新时间、结果是否完全一致、实际刷新了多少日期。

边界：Ailoha 的多日事件、时区、夏令时、分页、缓存淘汰和第三方日历仍须自己验证。

多个地方同时决定弹出哪个页面

Ailoha 不好的设计：Root、Router、外部任务、sheet 可能同时发起页面跳转，容易重复弹出、静默丢失或顺序不稳定。

新设计：任何时刻只有一个页面路由负责呈现，并明确新请求是排队、合并还是丢弃。

Talent Signal 怎么试：把 RelationshipArchiveView 中多个 sheet 和延迟弹窗状态收进一个类型化路由。

补回设计文档的证据：深链晚到、取消后继续、后台恢复、重复请求等测试全部通过；重复弹出和请求丢失为 0。

边界：Talent Signal 只能证明单进程页面路由；Widget、Live Activity、ARPC 仍须在 Ailoha 测。

用户分不清“AI 建议”和“已经执行”

Ailoha 不好的设计：建议、等待确认、执行中、结果未知、已经完成可能只靠卡片文案区分。

新设计：建议明确表示“还没执行”；确认只能授权一次；取消不能显示成成功；真正成功必须有回执。

Talent Signal 怎么试：

iOS Calendar 验证“建议 → 系统编辑器 → 取消/保存”；

Browser Extension 验证“等待 → 结果未知 → 查询结果 → 回执”。

补回设计文档的证据：找 5–8 名未参与开发的人完成任务，要求复述“已经做了什么、还没做什么、下一步是什么”。

硬标准：误认为已执行的人数为 0；结果未知后重复提交的人数为 0。

这补充的是信任和可靠性证据，不是性能证据。

重构效果只能靠“感觉更顺”

Ailoha 不好的设计：启动、图片、日历、页面刷新没有统一的测试场景和前后对比收据。

新设计：每个重构节点绑定固定场景、代码版本、设备、构建模式、测试数据和异常记录。

Talent Signal 怎么试：先接入启动恢复、图片导入、日历读取、页面恢复等五个小场景。

补回设计文档的证据：同条件下的 baseline/candidate 对比，包括中位数、范围、最慢样本和异常记录。

没有这张对比表，只能写“设计待验证”，不能写“优化已经有效”。

iOS进去on board这个过程，我在想

2026-08-28 11:00:54

iOS进去on board这个过程，我在想，就是如果把它设计最好是一个兔子前面挂一个胡萝卜的样式

吸引用户点击进去，用户点击进去之后就有比较好的效果

有一个 aha 是进入到 App 后给好朋友截图

2026-08-28 11:20:59

有一个 aha 是进入到 App 后给好朋友截图，我本身对他很理解，但是ailoha把他之前在外网从来没提到过的一些经历拿出来，很惊讶到我现在查人的能力很强了

SerpAPI QPS 的问题解决

2026-08-28 11:35:03

每小时成功搜索吞吐量

并发不高，但是持续调用的

execution outcome

2026-08-28 14:29:51

execution outcome 在运行结束的时候是可以判断的，记录的是真实的状态是否有发生改变

metrics 回答的是这个系统长期表现的是什么样的

metrics 的切片比总分更重要，成功率上升可能是因为任务变简单了

metrics 应该完全可重建，不是新的事实源

通过 transcript 捕捉到运行的效率

通过 execution outcome 来捕捉到交互可靠性

Transcript + Outcome +

2026-08-28 14:44:22

Transcript + Outcome + Artifact

↓

Grader(s)：这一次如何测试

↓

Grade / Assertion records：

↓

Metrics aggregation：整体表现

怎么样 ↓

Gate / 产品决策：是否允许发布

联系人广场的概念

2026-08-29 01:45:00

感觉和 notes 息息相关

实际上这个世界也是无数的 group 组成的

这个世界上的信息流动是不是也由无数的人与人之间的关系，社圈与社群之间的关系组成

所以其实为自己的社交联系人建立社交圈真的是一个非常 sense 的事情

我在想 memroy 甚至也可以用到这样的设计技巧，如果社群非常大的情况下，那么 memroy 就针对对方的联系人，通过和这个联系人的社圈关系，然后慢慢的往外扩散

用户甚至可以自己拉一个社交圈或者创建一个社交圈

通过联系人的方式去管理自己的成长

所以产品的定义应该是一个有人文气息的产品

用户如果可以自然而然 DIY 一个社群，本身是一件很有趣的事情

好的直觉本质上是识别隐藏架构的能力

2026-08-29 14:06:52

一个人可以从很少的信息里面准确的识别一个人，一个事情，甚至是一个时代的最重要的变量

背后是一个生成机制，一套底层的代码

反复注意什么

冲突中舍弃什么

如何分配时间、信任和资源

说法、选择、审美与行动之间能是否可以相互解释

这些是否可以指向同一个内核？

能力并不是脱离环境存在的。某种高度敏感、发散、追根究底的思维，在稳定执行岗位里可能显得低效；放到研究选题、产品定义或组织设计中，却可能形成不可替代的生态位

持续学习现在成为 scaling 与大规模 RL

2026-08-29 15:20:05

持续学习现在成为 scaling 与大规模 RL 之后的关键研究前沿

让模型像人一样在部署中不断的学习

今天最值得落地的是建立一个由快到慢、可验证、可回滚的学习通

TTT： test time traning

外部记忆和 context ，现在已经可以生产落地了

生物学给出的最有用启发也不是“复制神经元数量”，而是 complementary learning systems：

hippocampus 类系统：快速记录具体经历，避免立即覆盖旧知识；

cortex 类系统：通过较慢、交错的 replay，把反复出现的结构压进分布式表示；

新知识如果与已有 schema 一致，可以更快被整合；冲突知识需要更慢、更谨慎地处理

怎么样测试的更稳定，更准确，可重复

2026-08-29 16:45:59

为什么这样算成功？ 这是站在谁的立场定义的？ 误判是会伤害到谁

pass@k ，给模型 k 次的机会

2026-08-30 15:16:59

pass@k ，给模型 k 次的机会，其中至少有一次尝试是正确/通过的"的概率（或者说，能这样成功的比例）

LLM 生成代码这类任务，同一个问题采样多次，每次结果可能不一样

实际写代码时，程序员经常会让模型生成好几个候选方案，然后跑单元测试挑一个能过的用。这种"允许多次尝试，只要有一个对就算成功"的场景，就该用 pass@k 来衡量

对每道题，让模型生成 k 个样本

检查这 k 个里有没有至少一个通过测试

统计所有题目中"至少一个通过"的比例

pass@k 本质上是逻辑或

2026-08-30 16:04:59

pass@k 本质上是逻辑或，只要有一次成功就算成功，测试的是多次尝试中的天花板，所以代码的场景很看重这个指标，因为实际上也可以生成多次，自己去选择一次

pass^k 本质上是逻辑与，意思是每一次都必须要成功才算成功，实际上这个测试的是最低的效果，对于 agent 应用来说基本上测试的是这个，所以用户很在意这个指标，每一次的事件效果都去确保达到基线

越早开始越好

2026-08-30 16:12:32

实际上先从一些小的失败中提取简单任务就够了，等太久就得从线上系统反向推导成功标准

从手动的测试内容开始，你每次发布前验证的行为、用户常用的场景、bug 追踪器和客服工单里的问题——这些都是现成的测试用例来源。按用户影响优先排序，有助于你把精力投入到最关键的地方

设计评分器，环境要稳定隔离，要评估结果而非路径，加入部分的得分，小心评估本身的bug

Harbor：专为容器化环境设计

2026-08-30 16:21:12

Harbor：专为容器化环境设计，支持跨云厂商大规模跑试验

Promptfoo：轻量开源，YAML 配置，Anthropic 自己也在用

Braintrust：离线评估+生产可观测性+实验追踪一体

LangSmith：和 LangChain 生态紧密集成

Langfuse：自托管开源方案，适合有数据驻留要求的团队

不好的话，我觉得很简单。就我之前做的来看

2026-08-30 21:28:54

不好的话，我觉得很简单。就我之前做的来看，如果测试集太小，比如只有20个 case，我就说这个方案是好的，这就是经典的样本量不足，会导致一些假阳性问题。

为什么会出现假阳性，我觉得待会儿可以讨论一下

还有的就是人工标准没有效验，就直接就信。因为有可能就是标注员，或者是出现一些比较大的分支的时候，标注结果可信度是未知的，但是它会被当做一个金标准去使用，我觉得这个也是有问题的

驱动我行为的唯一的就是

2026-08-31 08:44:21

没怎么可以失去的

快速迭代，快速反馈，快速错误，快速丢脸

Rubric 在标注前写好初稿

2026-08-31 13:01:33

标注界面上标注员看到的问题（比如 “这个回答是否正确？"）是 rubric 的外化形式，但 rubric 本身是一整套评分标准，包括每个问题选项定义，分数的含义，判断依据，正例反例，边界 case 规则

标注员的一致性，如何更高，最基本的任务定义，知道标注在测试什么，目标是什么，评分标准，评分的维度是什么样的

每个维度的分级标准，，正例和反例，边界 case 规则，标注员要注意的事项

语义上 Calendar 和 2Meet

2026-08-31 15:31:25

语义上 Calendar 和 2Meet 是禁止重复创建的，产品契约明确是禁止的，但是没有代码级别的硬校验

周末约一个咖啡，应该是 2Meet ONLY， 有些周末只是候选时间窗口，并不是咖啡真正占用的日程区间

要不要周末下午约 xxx 喝咖啡，只是提议 2Meet

另外时间模糊的一般也推荐是 2Meet

但是如果是日期和字段确定的情况下，比如说周六下午，那么就是 calendar only

标注师的也很难

2026-08-31 18:41:03

定义语境，任务规范、成功标准、edge case 通常是更大的瓶颈，但一旦是语境定义清楚后，，agent 类型任务对标注师的技术底子要求也不低

先用清晰、覆盖尽可能多 edge case 的 rubric 把标注难度往下压，压不下去的部分（比如判断 agent 是否在钻空子）交给有技术背景、能理解工具语义的标注师去处理

把能想到的判断标准写死、写具体，把标注这件事变成"照着checklist打勾”，而不是"凭感觉判断”

还有很大一部分压不下去的，是需要人的判断力的

总有一些取巧方式是写 rubric 时根本没想到的

agent 发现测试是通过读某个日志文件、匹配字符串来判断是否成功的，于是它直接往日志里写了期望的字符串，压根没解决 bug 本身

agent 利用了工具返回结果里的一个信息泄露（比如报错信息里包含了预期答案），走了捷径

agent 表面上按步骤执行，但其中一步悄悄修改了评分脚本本身的判断逻辑

冻结 Pilot Gold candidate

2026-08-31 20:10:22

冻结就是锁定，保证可复现性和可比性，确保这周跑的分数和上周跑的分数可比较，差异才可能归因到模型本身

防止为了分数而改数据，很多时候模型迭代时，开发者看到某道题模型答错了， 本能反应可能是这题是不是标错，然后去改标签，改着改着，分数涨了，但是模型能力没有涨，这是模型自己的 bug

防止数据泄露，冻结意味着这批数据有明确边界和版本

版本可以追溯也很重要，冻结会产生一个明确的快照

主要在冻结前做， LLM 复核是 Pilot 迭代循环的一部分

人工标注 → LLM 自动复核（标记可疑条目） → 人工确认可疑条目 → 算一致性 → 修订 rubric → 重测 → 达标后冻结

四、自我认知与心理

36 条记录

少一点认知

2026-08-09 22:35:37

多一些执行

很多时候思考是为了满足自己的某一种想象，也是一种 ego ，证明自己努力了

所以还是需要元认知视角，去打开这个视角探索这个世界

我搭子今天给我发信息，我知道我搭子其实比我痛苦很多

2026-08-09 23:58:44

我搭子今天给我发信息，我知道我搭子其实比我痛苦很多，我搭子担心我，他平常也不会主动对我说他的一些焦虑，还有痛苦，之前黑黑作为局外人帮我看清楚很多，其实很感谢黑黑，我搭子还是认为会不会是自己影响了我的人生，可能也会后悔

我突然想到明天要去工作的时候，他给我发的信息，其实最开始可能也会担心吧 ，焦虑 ，害怕，不知道怎么样做，他们说我很有意思，但是我知道自己对比其他人肯定是不够的，我还看上去失败过，还有两年多的空窗期，甚至拿到的薪资可能也远远高于之前，有一种不配得感

我问 AI AI 好像接住了我，我很感动，它在我记录的很多的 inspiration 看见了我

想起来自己的一直以来的游戏心态 / 平常心， 我不会因为恐惧、焦虑、未知和嫉妒，做出让自己后悔的事情

我很感激我的搭子，因为遇见了他所以才有现在的我，所以他已经是组成现在的我一部分了，但是其实一直以来我还是觉得如果再让我选一次我还是会选择我搭子，即使现在结果很差，大家都经历过痛苦，挫折，折磨，但是我们经历，信任，这好像是我人生中最感动我的经历了

原来这就是平常心，也是游戏心

好好对待自己，对待身边的人，对待工作，对待遇见的人，做好自己！

知道世界有输赢，仍愿意真诚投入，知道一切可能结束，仍然善待局中的人

其实对于新公司后面我就很兴奋了，很渴望，希望和他们一起工作创造

因为我们是一起创造的，一起下一段旅程，无论结果什么样的我都可以接受，我要好好的做自己，做好自己

人生好似也想旅程，也像游戏，现在开始，也是下一场游戏的开端

OpenClaw 本身就是本地 Agent 运行时

2026-08-11 22:50:33

OpenClaw 本身就是本地 Agent 运行时，可以把整个 Obsidian Vault 或某个子目录当作 workspace。

官方有 openclaw-lark / 飞书 Channel 插件，能直接在飞书里对话。

社区有人已经在做「OpenClaw 读本地笔记 → 飞书推送日报/问答」。

你可以：

指定一个本地目录（或 Vault 子文件夹）作为该 Agent 的知识源

写好 System Prompt（人格、说话风格、回答边界）

通过飞书机器人对外服务

相关：

官方飞书插件：larksuite/openclaw-lark

社区桥接：m1heng/clawdbot-feishu（支持动态 Agent、workspace 隔离）

Obsidian 深度结合：obclaw（专门把内容整理进 Obsidian，并支持飞书入口）

目标 → 边界 → 方案 → 实现 → 验证 →

2026-08-13 15:44:43

目标 → 边界 → 方案 → 实现 → 验证 → 交付 → 反馈

最终的交付物要回答：

交付物，验收标准，如何证明有效，哪些情况不在本次范围内，质量、时间、成本、风险允许到什么样的程度

认真入局，但不执着于用一局证明自己；通过共同创造接受

2026-08-16 14:35:24

认真入局，但不执着于用一局证明自己；通过共同创造接受现实检验，同时不让成败吞掉完整的自己

去掉 ego ，不证明自己可以赢

而是慢慢来，从一点一点的解决问题开始，真实的去创造，去做自己

真正的游戏精神，是勇敢入世，勇敢做自己，知行合一，勇敢锻炼，成长，创造

入职第一周认知转变路径

2026-08-16 17:24:17 · #方法论/入职认知 #心理模型

真正的问题不是「怎么融入」，而是「我到底是谁、该站在哪」。

Day 1-3：格格不入 → 沉默 → 被朋友诊断为「自卑」 Day 4-5：社交沉默是心理自保，不是退缩——但存在被合理化为「等稳定再说」而滑入长期断联的陷阱 Day 6：重新掌握对话节奏，开始主动输出，精确数着工作天数——说明在认真对待这份工作 Day 7：solo温泉完成自我重启闭环

核心认知：身份不是环境分配的，是自己定义的。带进新一周的不是「如何融入」，而是这周想清楚的自我定位框架。

三条认知路径：从「我是谁」到「这是什么」

2026-08-16 17:24:30 · #方法论/认知路径 #工作框架

入职第六天的关键切换——不再纠结融入问题，转向拆解工作本质：

Case提取：从实战中抽取可复用的case和eval标准，而不是空转理论 流程显性化：把团队里隐性的代码/agent流程设计摊开来，变成可审视的流程图 抽象层杠杆：找到抽象层的自动化机会——不是做更多，而是让系统替你做

这三条路径的递进关系：先有具体case的手感，才有流程的骨架，最后才配谈抽象层的杠杆。反过来走会变成空中楼阁。

规则重写者被扔进既有系统时的自然反应

2026-08-16 17:24:53 · #方法论/身份定位 #心理模型

入职第一周的格格不入不是能力问题，也不是性格缺陷——是规则重写者遇到既有规则体系时的本能抗拒。

展小美的诊断「你从狂妄变自卑了」抓到了表象，但真正的结构是：产品信念和组织归属感的错位。你相信产品，但不确定自己在团队的位置。

解法不是强行表演自信，而是跟直属leader确认被招聘的真实原因——从空转的自我否定切到有方向的发力。

博尔赫斯《克鲁斯小传》的对应：关键不是怎么融进去，是你到底是谁、该站在哪。停止表演应该的角色，认出本来的身份。

确实感觉自己成长太慢了，痛苦让我成长，磨灭我的

2026-08-18 20:11:58

确实感觉自己成长太慢了，痛苦让我成长，磨灭我的 ego，放下自己的自傲

并且不断让我回头反问，问题的根源到底是什么？

而且 kiwi 并不是主动骂我

2026-08-18 20:42:11

而是总是在旁边内涵我

总是潜意识会觉得我真的很菜

时不时看一下我

事实和情绪分离

2026-08-19 09:09:46

不让情绪参与工作

不让情绪参与决策

kiwi 感慨控制欲真的很强烈（2）

2026-08-19 21:59:48

kiwi 感慨控制欲真的很强烈

她甚至对一些没兴趣的人或者事情非常没有耐心，你觉得这是精英主义吗，身边的人都是那种高认知，她自己感兴趣的人就很有兴趣耐心，没兴趣的人就非常的厌恶，这样的创始人，甚至没有任何的共情能力和同理心对于团队

因为一个人能力跟不上，就厌恶这个人本身

2026-08-19 22:00:21

因为一个人能力跟不上，就厌恶这个人本身，剥夺对人的基本共情，这是风险点

哪怕理智上知道：这个人品性很好、忠诚度高、值得培养

2026-08-19 22:17:06

情绪层面，很难扛住过程当中的低效

所以现实结果：大部分潜力型，还没等到成长完成，就已经被边缘化、挤走

这类创始人往往不是完全没有共情：对自己认可

2026-08-19 22:21:18

这类创始人往往不是完全没有共情：对自己认可、欣赏的人，共情力很强，能体察对方的难处

共情是定向开放的，不普惠给所有人，她对于自己喜欢看的电影愿意开放共情能力

团队里普通员工、跟不上节奏的成员，不在她的共情圈之内，对方的压力、委屈、成长阵痛，她感知不到，也认为不值得她去感知

朋友说的很对

2026-08-19 23:36:13

珍惜每一次的痛苦和苦难，可能都是养料，去帮助自己看见自己，成长的珍贵的养料

这些东西可以辅助自己看到很多

很感激 kiwi ，我和 kiwi 是相互都是非常的生理性排斥的

她把我视为蠢货

我认为她对于人有明显偏好

对于那种可能会消他时间的人，消耗他的认知，消耗他精力的人，他会非常的生理性厌恶

甚至不愿意在自己的团队中使用一点点的同情和同理心

这是她性格使然

成就了她现有的认知和独特的审美判断，也造成了团队的一系列隐患

不如好好观察，好好学习

实际上情绪也是自己内心的反射器，因为说的很准确，自己确实的有这样的问题，不是天才，没有超强上手能力，只能学hhh，努力学，成长，暂时放下内耗

及时现在忙碌的没有很理性的分析能力和判断能力

但是也还是隐隐约约感觉到

就是这样，一点点来，带一些善意，加油！！

会有一天抛开云彩的

不管怎么样

2026-08-21 12:35:30

做好自己

只能做好自己

朋友，就一期一会

希望他们也可以过得很好 ～

寻找变量，变量指的是真正会让组织走向结局真正的隐藏变

2026-08-23 12:45:36

寻找变量，变量指的是真正会让组织走向结局真正的隐藏变量

这套系统可以暂时命名为，有审美取向的实证主义，需要偏见提供方向，然后用失败、结果、用户去更新判断

但是问题也会导致高 conviction 可能变成过早分类；高密度关系网络可能放大权威偏见；跨域发散可能替代收敛；追求真实关系的产品，也可能因过度采集和推断破坏真实本身

昨晚发生了什么？我想一下，我梳理一下昨天晚上整个过程

2026-08-24 08:33:16

昨晚发生了什么？我想一下，我梳理一下昨天晚上整个过程。半夜的时候喝了酒，跟我，大概 12 点的时候，我们开始喝酒，跟我朋友。刚刚喝的有点醉，可能好久没有喝了。如果是之前的体质，肯定不会醉。但是又因为好久没有喝了，我们就聊到一点，这是我们对于这个世界的一些看法，对这个世界人与人之间的差异、阶级之间的差异，未来 AI 时代会不会放大这种差异

突然想到 archer 对于整体的时代进步，保持一种悲观的，或者是一种不喜不悲的态度，好像能在某一个方面能共情到他一点

然后讲一讲我昨晚做的梦。我昨晚做的梦特别悲惨，想到我之前在老挝的时候，对于官方人员的一些无力感。官方一直是我心中一直非常非常有一种崇拜烙印的东西。可能现在少很多了，但是我没有想到这种梦还会把这种回忆给勾起来

讲得很科幻，就讲的是，但是我正好是在那边被选中。选中去祭祀，就一直在挣扎，挣扎到最后我说我自己算了，我说我不是这里的人，然而他们后面还是让我去，帮我带到一个小黑屋，然后拿出被祭祀者的一些信件，当时好像是一个手环，玉玉环。然后他后面就是意思是让我自己把玉环还给他，然后就不用祭祀了。但是我拿出来的瞬间，他突然就把它敲碎。然后梦醒了，我知道后面会发生什么，后面应该一系列敲诈

我当然很恐怖一点，就是我好像在面临强权，就是是一种无力感。面临强权力不平等，也是一种无力感。

然后突然介绍一下我今天早上的感受。就正好走在路上

2026-08-24 08:38:41

然后突然介绍一下我今天早上的感受。就正好走在路上，因为今天太阳很大，而且走在路上我一直在思考这个问题，突然思考思考，突然就整个人就开始发呆。

看到我，看到对面斜对面角落的人行道，然后太阳洒在那个墙面上，墙前是一个人又一个人走过，有一种幸福感

这种幸福感恰好是自己内心发现出来的，谁也夺不走

昨晚酒里讨论的都是这个世界为什么不平等

梦里成为亲自成为那个被不平等支配的人

早餐重新发现了一种不依赖权力、财富和时代结构的幸福…

这个闭环，好像是上天在暗示我…

那些最无法被拥有的东西，反而最难被夺走

游戏人生…

想起昨晚和朋友讨论过关于佛学中，有和无

2026-08-24 08:56:48

阳光下的幸福仅仅持续了不到一分钟，很感动…

金刚经应无所住而生其心

因为无所住，所以看见阳光会幸福

看到强权会害怕

朋友离开可以难过

事情成功可以开心

幸福感也是无常的，执著后就会有所住，被锁死了

物衰无常我们发现流失的美

太阳过去就过去

发呆结束就结束

有，是因为真实感受到了，是缘起

无，是因为抓不住，随时因缘而散

有和无好像就是一个过程

世界好像没变，自己变了，有，便也是无

吵架的原因

2026-08-24 13:33:30

亲子关系的一直以来的问题

亲密关系的一系列问题

和领导之间的问题

可以做一个线下的联系人场景

2026-08-26 00:22:29

我觉得很有意思和必要性

因为其实倒不如把定位直接定义为线下约朋友，就叫 coffeechat，但是现在的地图和侧重内容好像很难服务于冷启动

很多时候

2026-08-27 11:45:12

想要拼尽全力做到最好

其实于我而言，对我自己的观察而言

并不是为了要证明自己

只是希望人生中尽力而为

其实偏见也无所谓

很多时候自己也能看到

很多关系未必可以走到最后

但是自己这个过程中还是尽可能全力，真心

也不是抱有幻想

而是想着，真的可以一期一会对对待这个世界，对待身边的人

山穷水尽绝无路，柳暗花明又一村

很有意思的一点，就是我对关系的需求其实是很小的

2026-08-27 11:53:12

我觉得很有意思的一点，就是我对关系的需求其实是很小的，就是越小越好。因为我觉得就是很多东西都是深层次的共鸣，共同成长，共同在场。这个好像对自己的叙事来说，更有意义一些

所以对于选朋友来说，我是非常谨慎，并且保持一种延迟的态度，很慢

相对来说，white 前期给了我很多的时间和空间发挥

2026-08-27 13:20:22

给了一个比较大的命题，让我有时间可以缓冲多多思考

如果还是按照之前的逻辑，快速分配任务，快速解决，其实表面上看上去解决了很多的问题，但是实际上项目并没有得到一些本质的提升，自己也没有得到一些深层次的提升和成长

所以其实慢一点，多多行动的目的是为了得到反馈更好的思考

我和 kiwi很大一点不一样，就是可能有两层原因吧

2026-08-27 13:57:16

我觉得我和 kiwi很大一点不一样，就是可能有两层原因吧。一层是表层的，就是我观察我自己，其实并不是很喜欢这种不平等的关系，或者是他对方一种非常打量式的眼光去注视我，然后快速给我贴标签。我理解他，这是他自己降低不确定性的一种方式，但是我觉得这对自己人、身边的人来说，是一件很残酷的事情，当然我觉得 kiwi 他可以做到这一阶段的自我迭代，就是他能够快速地去通过击碎自己的偏见，然后建立一种新的认知体系

其实还有一个更深层次的原因，是因为我觉得我们对人的理解和关系的理解的本质的差异性。相对来说，我觉得 kiwi 他更多的是一种通过快速的量化以及对对方贴出标签，快速的评价去降低自己的不确定性，包括他是一个什么样的人，特别的人，他是一个有什么 title 的人，或者是他做了哪些事情

我的话，我就是人本位，我会觉得就是对方首先是一个人，他是一个很复杂的人，他是一个在这样的文化体系里面，在这样的国家，在这样政治体系里面，受到对应的教育，有什么样的家庭，有什么样的人生。他是一个很复杂多样的人。这时候再去推演出他为什么会做这样的决定，他会做什么样决定。他会选择什么样的道路，我会觉得这个世界就是一个仙人球，就大家都在通过不同的因素去塑造出自己，甚至是基因的因素。但这也是造就了每个人不同的非常多样性的一个因素。所以我的朋友可以很少，但是相对来说，我对他们都非常的亲密和信任

所以这也是为什么我们做产品。我觉得我的产品可能更多的是在服务于怎么样去让这个人如何去成长，如何去观察到自己，如何去快速的让自己在这个世界上长出自己的一个本位

Kiwi 关注的是产品是否可以解决自己的关系上的一些问题，如何代替或者帮助自己产生共情和换位

真的超级无语，我去给帮 Kiwi 配置电脑

2026-08-28 12:21:38

真的超级无语，我去给帮 Kiwi 配置电脑，她还一脸的不耐烦，她很坚信她自己是对的，就是这些电脑肯定不是她的，因为刚刚配置的是一个新的电脑，但是她确定这个电脑可能是 white 的，但我确信这个链接没有问题。我觉得可能是另一个同事在 onboarding 过程中设置了一个密码，但 Kiwi 还是坚定没有设置，表明是自己拿到的新的，后面同事回来之后说这个就是刚配置的自己设置的密码

而且感觉她情绪很不正常，她直接把 Wait 那台电脑的 Mac mini 电源线给拔了，后面又插上去了。我靠，这种事情她之前干过。她给手机充电的时候充了半天，然后发现还是没有开机。她后面就非常不耐烦，然后直接把那个电源的按钮，然后关掉重新开启，就导致我的电脑被迫关机，重新开

我觉得人与人之间最好的距离是3米，但是我和 Kimi 之间最好的距离是 30 米

一条记录

2026-08-28 23:53:06

今天

好像 while 要离开我们团队了的

感觉一些都好怱然

我今天被折磨了一天的算法

其实能理解和共鸣到 kiwi 现在的处境

本来想要离开的

突然有点共情了

团队好像越是绝境自己好像越是兴奋

是一个新的挑战

真的觉得自己很笨

2026-08-29 00:40:56

完全没有 ego 了很小很小了

努力学习，成长，思考，创造

能做的也仅此了 ….

我想的最多的最近的两天

2026-08-29 00:41:24

就是 kiwi 朋友圈标签的 “一期一会”

我自己也被这个词语触动了无数次

相互照见

2026-08-29 14:11:30

和小兔子

工作学习密度低，但能做饭、晒被子、去图书馆、规划和记录每天；你成长密度高，却反复说“分不开”“没有生活”“没时间”

我们的自我标签：“all in”“咸鱼”“幸福”“牛马”。

她害怕未来没有积累，我害怕今天忙碌的没有意义

体感这个东西知识学不来，体感会深深影响自己的直觉和判

2026-08-29 14:14:11

体感这个东西知识学不来，体感会深深影响自己的直觉和判断力

经历和反馈以及因果反思，再验证

直觉不是神秘感觉，而是大量被现实标注过的经验，被压缩成快速判断

价值观这个东西也不是固定的

2026-08-29 17:20:18

我们在匮乏的时候，充实的时候价值观也是不一样的

具体生活；

感受力；

对普通时刻的记录；

没有功利结果的幸福

成长究竟要服务于什么？

手标的感受

2026-08-30 21:45:51

标记指南写的烂，自己标的时候反复纠结、反复回去改标准的地方，就是指南模糊、维度没拆开的地方，这些需要观察和记录下来

单一维度打分很容易失真，很多时候你会发现某条数据"整体感觉不好”，但说不清是哪里不好，这时候会逼你把"好/坏"拆成几个更具体的子维度（比如相关性、事实性、语气），这是从"打分"进化到"结构化评估"的关键一步，手标能让你切身体会到为什么单一分数不够用

边界感，就是关于哪些 case 是这个 task 本来就该模糊，哪些是指南没写清楚

所以实际上如何评估这个边界

2026-08-31 12:32:54

所以实际上如何评估这个边界，很明显的地方就是要不要创建 Calendar

即使模糊，能创建 2meet 或者 calendar 也要创建，因为卡片可以发送给用户用户去修正，修正对用户的成本更低

五、商业、投资与职业

9 条记录

想试一试真实可以量化的场景

2026-08-04 00:48:15

做成候选人推进助手，而不是泛记忆关系

面向独立猎头、小型招聘团队和创业公司招聘负责人：从候选人聊天截图中识别承诺、偏好、风险和下一步，防止优秀候选人因跟进断裂而流失

前面对重要的资产，我觉得还是对人的一种理解的能力

2026-08-04 13:06:00

前面对重要的资产，我觉得还是对人的一种理解的能力，就是这个人你觉得他是什么样的人、什么状态，还拥有什么技能。用户画像本来外向是最重要的，然后再就是关于数据与信息安全，这些就是避免个人的尊严会使个人的财产安全受到危害，包括自己的一些生物识别信息，人脸、指纹，比如说特定的信息，不公开的职业，还有些毕业的。然后这就是精准的定位，这些东西都是属于隐私信息吧，无法识别的信息必须要加密，或者是还有中等的信息，我觉得可以做一些模糊处理。 #ailoha

所有的问题都一定要站在团队和创业公司的角度出发

2026-08-11 20:25:16

所有的问题都一定要站在团队和创业公司的角度出发，一定要做出让团队真正有价值的一个东西。那么到底什么东西它是有价值的？我觉得是要考虑这个团队它自己的目前的，它的需求点到底是什么？

对于三方工具来说感觉是一个问题

2026-08-21 14:42:50

三方的工具就像是一个黑盒子一样

but 也取决于核心的壁垒到底是什么样的，Exa 专门维护了 people index 和职业信息 highlights

我希望那个 ailoha 可以有一个 hook

2026-08-22 15:05:26

我希望那个 ailoha 可以有一个 hook ，如果截图是和联系人无关的，那么应该分析存储转发到我的 daypage 或者是其他的有意思的产品

我觉得类似于金淦这样类似的人，或者是一些对关系很自信的人，对他们来说或许更多的是理解自己比理解其他人更重要

所以未来的产品，无非是两个作用，入口和消费的作用

核心的竞争力，无非是各个产品本身的处理的模式以及效果的竞争优劣

我甚至可以在自己的产品入口接入 ailoha 的产品 ，分析然后存储进去

甚至也可以是 ailoha 截图有一些核心的思想启发可以补充到自己的产品中去

但是我觉得既然选择这条路，我觉得我能做的就是提高自己

2026-08-30 15:19:57

但是我觉得既然选择这条路，我觉得我能做的就是提高自己快速学习的能力，这是唯一的方法，就是只有对这个某一个具体的领域有一些非常强烈的学习欲望和学习的好奇心，然后推演出来这个领域里面本质的判断，我觉得这是我们核心的竞争力，未来唯一的竞争力。因为实际上当你会的东西很多的时候，实际上就是因为你的判断被稀释掉了。但是如果怎么样去组合你的判断，然后形成一种强判断，这个可能是未来需要思考的

江峰有一点比较让我意外，就是他好像很神奇

2026-08-30 18:14:05

我觉得江峰有一点比较让我意外，就是他好像很神奇。每次我们在商场路过的时候，很多人跟他打招呼，而且那些人实际上是带着目的的。他们可能跟江峰说“你好”，江峰一般都会回复“你好”。他们之间就很奇怪。

站在我的角度，我一般可能会回应一下，但通常不会回话。就像有些人跟你聊天的时候，突然回一个表情包，意思可能是不想聊了。所以对于他们跟你打招呼来说，有时候他们跟你说一句话、问好，可能只是他的职业习惯。

这时候如果你不想去吃饭，就可以不用回复他们，只要点个头就好了，代表回复了，就跟聊天发一个表情包一样。但如果你自己明明没有兴趣，还是会跟他们回复“你好”，就等于给他们一个信号，说你好像是想来买东西，或者购物。但实际上你并没有这个打算，所以他给了一种错觉，他对双方是不是一个额外消耗。但是就事论事来说，我觉得江峰他这种品质挺好的，就是他会去在意每一个人，然后给他们回应

符合个人价值观的产品

2026-08-31 16:33:37

未必是一个好的商业产品

值得记住的见面机会

2026-08-31 19:43:03

↓

尚未占用时间资源：2Meet： 关系机会管理

↓ 确定排期

已经占用时间资源：Calendar：时间资源管理

↓

完成 / 取消 / 重新待约

范围角度，2meet 是关系，但 Calendar 本身又比 2Meet 更广：面试、Podcast、线上会议、看医生都可以是 Calendar，不一定是线下见面

Calendar 可以通过用户确认，把一些模糊行为交给用户确认，但是不丢失

对于一些时间候选窗口很大的事件，比如说周末喝咖啡（没说具体哪天），某天见某人，不具体，还有就是某个某个月见某个人，这种时间跨度太大的，可以先放到 2meet

对于非线下并且没有排期的行为都不会生成，比如说 “之后线上聊聊”

六、内容、创作与记录

6 条记录

可以，而且这正是解决其他人物的关键。但

2026-08-18 10:22:10

可以，而且这正是解决其他人物的关键。但 Context 应该用来“扩

大搜索和验证身份”，不能直接当成硬条件。

例如截图里出现：

姓名、英文昵称公司、职位、项目活动名称、城市、时间共同出现的人产品或团队名称

推荐链路是：

姓名广搜

→ 用 Context 生成多组定向查询

→ 找到 LinkedIn URL

→ 回灌抓取 Profile

→ 用公司、职位、地点、时间和共同关系交叉验证

→ 证据不足则保持弱匹配

比如“施宏斌 Xbanker.ai”：

不能直接认定 Xbanker.ai 是他的当前公司。可以搜索 “施宏斌” “Xbanker.ai” site:linkedin.com/in。找到候选后，再检查公开履历是否真的出现 Xbanker.ai。对得上才提高匹配分数，对不上也不应该提前过滤掉这个人。

当前代码已经解决了一半：

未验证的公司、职位不会再作为 Apify 硬过滤条件。支持别名、查询变体和 LinkedIn URL 回灌。只有弱候选时会进行定向 Serp 搜索。

还缺的一半是：系统化地把截图内容转换成“软查询线索”，并将搜

索结果重新交叉评分。现在 soft_context 主要用于避免误过滤，

还没有完全发挥在查询扩展和候选排序上。

因此结论是：结合 Context 可以明显解决陈斌、雷绍满、施宏斌这

类案例；但 Context 只能增加证据，不能凭空证明身份。最合理的

下一步就是补上“Context 查询扩展 + 时间感知交叉评分”。

search_social_content 和

2026-08-19 14:16:01

search_social_content 和 search_person

最开始可以抽出来 workflow 或者 skills，确保开始使用 search person 确定身份

search_person

为一个目标人物召回或验证 LinkedIn 候选；返回职业身

份事实和检索覆盖；不搜索社交内容，不确认最终身份。

search_social_content

在指定公开平台检索帖子或表达；返回内容、作者、来源

和平台覆盖；不确认现实身份，不修改联系人。

标题本质上是为用户服务的

2026-08-24 15:41:09

所以 title 标题的 prompt 最精髓的部分不是把内容压缩成标题，而是把标题定义为一个记忆钩子

三周后用户看到标题，能立刻想起，哦，对，就是这件事情

标题不负责总结，只负责唤醒具体的场景

标题要求寻找用户最可能记住的单一细节，用户看到细节就可以回忆起整个对话

Phrase it the way the user might casually refer to it later when talking to a friend.

用户之后跟朋友闲聊时可能会随口提到它的那种方式来措辞 / 命名

只抓住一个细节的部分

我感觉现在看起来怪怪的，我一直都没有一种非常清晰的状

2026-08-25 00:40:51

我感觉现在看起来怪怪的，我一直都没有一种非常清晰的状态，清晰的展现出来。就我应该怎么做？他现在就是在刚发送完一个截图之后，进来之后，他上面标题都是空的。我觉得很奇怪，他应该第一反应不是应该解析出来这个标题吗？我觉得界面在这个过程中还是可以解析出来的。那么这时候第一眼看起来就相对来说比较友好一些，而且进去也能看到一些截图的图片

而且我觉得再者一说，那这个标题完全前期就可以去按照一些非常简单的方式去描述出来，后面不断的通过完全调研之后再去更新，这样不是更友好吗？而且我觉得后右边是需要一种状态的，阴影当然也是一种状态。但其实还应该去让用户清晰地能感知到，就是当前到底处于一个什么状态，是否已经加载完成了，是否已读未读。

可能可以去加一个 tools

2026-08-28 10:54:07

可能可以去加一个 tools 可以去对截图中的内容进行深度的 deep，当然或者是一个其他的 skills， 升高这部分的权重

关于 Calendar 和 2Meet

2026-08-31 15:15:49

核心的信息就是，Calendar 核心信息就是标题、准确日期时间、地点、参与人、冲突

然后 2Meet 就是人、城市以及为什么想见 / Notes

七、阅读、思想与历史

4 条记录

可以试一试这个方法，就是可能会非常有效

2026-08-13 21:48:43

我觉得可以试一试这个方法，就是可能会非常有效。就最开始针对某一个问题，然后以小见大，去不断的放大这个问题，然后分析周围的框架以及它们的连接体系。但前提是真的能精准的定位到问题，如果没有办法定位到问题的话，还是要回到整体的流程框架中分析，或者是通过日志去排查出对应的问题，看目前到底是什么样的问题

之前版本的等 while 来帮我 review

2026-08-20 10:05:53

之前版本的等 while 来帮我 review 一下，现在在做是关关于小红书和 Reddit 等工具的集成

开放式问题是可以评估评分的

2026-08-25 17:27:24

评估的体系可以围绕几个维度

比如说语气真诚性，工具调用的顺利性，回答是否准确克制，是否是基于事实推断的

凯文凯利一辈子方法论你的核心就是放弃中心化控制,相信

2026-08-29 16:44:00

凯文凯利一辈子方法论你的核心就是放弃中心化控制,相信涌现"(《失控》全书的立论

凯利这个人有个很特别的细节——他给自己做过一个"剩余天数倒计时钟",天天提醒自己人生剩下多少天;他也反复强调"时间比金钱重要"

而马斯克体系要的恰恰是把一个人的时间全部收编进他自己的目标(火星、AI、能源革命),这些是马斯克的"长期项目",不是凯利的

八、旅行、地理与城市

3 条记录

我看尼泊尔那个口岸真的太危险了，根本就没有办法逃生

2026-08-26 21:13:40

几乎很难逃生。我看他们还往沿着下游跑的，这根本就是非常的不可思议的一件事情。应该正确的做法是往高处跑

向河流两侧的高处转移

如果完全来不及的情况下，应该尽可能的垂直于河谷方向，迅速地向两侧高地移动 ，因为实际上我们都需要的是横向距离

关于屏保

2026-08-29 14:15:16

屏保放的是我之前日复一日旅居观察拍到的照片

旅居时，你不需要翻照片，因为幸福是当前环境；现在照片变得重要，是因为当前生活无法持续供给那种感受。屏保像一个“时间接口”，把过去那个有时间、能观察、能感受的自己，短暂恢复到现在

现在这个被工作占满的我，并不是我的全部。那个会旅行、观察世界、感受风景的人仍然存在

见面承诺：

2026-08-31 11:14:29

Calendar：已经占用明确时间资源的承诺

2Meet：尚未排期、但值得保留的线下见面机会

同一个原子承诺在同一时刻只能属于其中一种

2Meet 被排期后，应显式晋升为 Calendar，并结束原来的 pending 状态

Calendar 相对来说，已经约在周三，但是具体几点待定的

但是如果是线上聊聊的状态下，并不属于 2Meet ，没有时间也不能创建 Calendar

周三和张三开会，另外下次去上海见李四，这是两个独立的承诺，一个是 Calendar ，一个是 2Meet