OpenClaw实战：让AI自动操作Apple备忘录的完整指南

1. 这个Skill解决什么问题：AI对话与本地备忘录之间的最后一公里

你有没有过这种时刻：让AI帮你把一段碎片想法扩成一份条理清晰的记录，生成内容很满意，结果发现把它从聊天窗口挪进备忘录这件事，居然还要自己动手。如果AI能直接写进本地备忘录，整个流程才算真正闭环。OpenClaw的apple-notes Skill解决的就是这个问题——它让AI助手可以直接在你的Mac上操作Apple备忘录（Notes应用），创建、搜索、读取、更新笔记，把备忘录变成AI的外接记忆库。我给这个Skill装上之后的第一反应是：早该这么干了。

先交代一下背景。OpenClaw是一个开源的个人AI助手框架，简单理解就是一层"网关"：它把大模型的能力和你本机的工具环境接起来，模型拿到你的指令后，可以调用你机器上的命令、脚本和第三方服务。框架里的Skill机制是这套系统的核心——每个Skill就是一个可插拔的能力包，通常由一个描述文件加若干可执行脚本组成。模型会先读描述文件，判断"当前这个请求该不该用这个技能"，确认后就执行脚本，再把脚本返回的结果整理成回答。apple-notes Skill在这个体系里的定位非常明确：给模型一个操作备忘录的入口。

为什么这个需求值得做成一个专门的Skill？因为备忘录在大多数人的工作流里，其实承担的是"外部存储"和"任务暂存区"两个角色。灵感来了先扔进去，会议记录往里归档，读书摘抄往里堆，待办事项往里记。这些场景有一个共同点：输入内容往往是即时的、碎片化的，而且你人在聊天窗口里，手不一定在键盘上。如果AI在对话中就能顺手把内容落到备忘录里，你就不需要经历"复制→切App→粘贴→整理格式"这一串动作。反过来，当你想查一条旧笔记但又记不清放哪了，直接让AI去备忘录里搜一遍，比你自己翻文件夹高效得多。

我用它解决的实际场景大致有这么几类：

• 灵感速记：聊天时迸出来的想法，让AI整理成条目写进备忘录，标注好日期和标签。
• 会议纪要归档：会议中随口说的要点，让AI扩展成结构化纪要，放进指定项目文件夹。
• 待办转笔记：和老朋友约了周六爬山，直接说"帮我记到备忘录里，周六和老朋友爬山"，它会自动生成带日期的笔记。
• 读书摘抄和长文素材：让AI把某个话题的搜索结果压缩成摘要，落到备忘录留作素材。

那为什么选备忘录而不是让AI直接写文件？我之前也试过让模型往本地目录写Markdown文件，效果倒是也行，但备忘录有它不可替代的优势：它是系统自带的，开机就同步，手机上随时看得到，支持文件夹和标签，全文搜索速度也快。最关键的，它不需要你去申请任何第三方API的OAuth凭据，本机的AppleScript接口是现成的。缺点同样明显：笔记正文在脚本层面是HTML字符串，格式处理容易踩坑，附件几乎没法通过脚本操作，这些后面我都会展开讲。

有一点要先说明，不同版本的OpenClaw对Skill目录和描述文件的格式要求略有差异，我这里讲的是目前主流版本的做法，核心思路是一致的。反正我在自己机器上反复测过，这套方案跑得稳，接下来我把整个实现链路、代码和踩过的坑一次性整理出来。

2. 底层原理：SKILL.md、osascript与备忘录App的协作链路

2.1 Skill包的标准目录结构

一个规范的apple-notes Skill，目录结构大致长这样：

skills/apple-notes/ ├── SKILL.md ├── config.json └── scripts/ ├── create_note.sh ├── search_notes.sh ├── read_note.sh └── update_note.sh

其中SKILL.md是给模型看的"说明书"，决定了模型什么时候该调用这个技能、怎么调。config.json存一些可选参数，比如默认笔记账号、默认文件夹、超时时间等。scripts目录下就是真正干活的脚本，模型通过执行这些脚本来操控备忘录。

整个机制可以这样理解：OpenClaw启动后，框架会把Skill列表暴露给模型，模型看到SKILL.md里的描述后，在合适的时机调用对应脚本。所以SKILL.md写得好不好，直接决定模型"想不想用"这个技能。描述写得太宽泛，模型会乱调；写得太窄，该用的时候又不会主动用。这是个需要反复调校的活，后面我会给出一份经过实测的描述模板。

2.2 驱动AppleScript的两种姿势：AppleScript与JXA

macOS系统几乎每个原生App都暴露了一套AppleScript接口，备忘录也不例外。调用方式有两种：传统AppleScript语法，以及JavaScript for Automation（简称JXA，也就是用JavaScript写AppleScript逻辑）。两者最终都是通过osascript命令交给系统去执行。

我做了几个月的备忘录Skill之后，强烈推荐优先用JXA。原因很实际：JXA可以用对象和数组操作，数据筛选逻辑写起来比AppleScript的whose要直观得多；而且JXA能直接跑正则、字符串处理，这对清洗备忘录返回的HTML正文有决定性的帮助。传统AppleScript在处理复杂字符串拼接和条件分支时，语法非常反直觉，容易写出"能跑但看不懂"的代码。

选型之后，调用入口统一走/usr/bin/osascript -l JavaScript，这样脚本内部不依赖任何第三方环境，只要机器上有系统自带的命令行工具就能跑。

2.3 一次请求的完整调用链

我实际使用中，一次"帮我把这段话存到备忘录"的请求，背后大概走这么一条链路：

1. 你把指令发给OpenClaw，框架把指令连同可用的Skill描述交给大模型。
2. 模型读完SKILL.md后，判断这个请求属于"创建笔记"场景，于是决定调用create_note.sh。
3. 框架在本地shell里执行bash scripts/create_note.sh "标题" "正文"。
4. 脚本内部调用osascript -l JavaScript，向备忘录App发送Apple事件。
5. 备忘录收到事件后执行创建操作，返回结果给脚本。
6. 脚本把结果打印到标准输出，框架把输出回传给模型。
7. 模型把原始输出整理成一句人话告诉你，比如"已经帮你记好了，标题是xxx"。

这条链路里最容易出问题的环节是第4步和第5步之间的"自动化授权"。macOS对App之间的自动化控制管得很严，首次执行时系统会弹窗询问是否允许当前终端应用控制备忘录，这一步没处理好，后面全是权限报错。这块我会在第5章单独讲。

# 最小可用的创建脚本示例，先跑通链路 #!/bin/bash # scripts/create_note.sh TITLE="$1" BODY="$2" /usr/bin/osascript -l JavaScript <<EOF >/tmp/apple_notes_result.txt 2>&1 const app = Application("Notes"); app.includeStandardAdditions = true; const note = app.make({ new: "note" }); note.name = \`${TITLE}\`; note.body = \`<h1>${TITLE}</h1><p>${BODY}</p>\`; EOF cat /tmp/apple_notes_result.txt

这个脚本是最朴素的版本，直接通过here-doc把变量嵌进JavaScript里。它有个隐患：如果标题或正文里出现反引号、美元符、引号这些特殊字符，脚本会爆炸。所以我在正式版里改成用base64传参，后面踩坑部分会详说。

3. 安装与最小可用配置：先跑通一条笔记再谈优化

3.1 环境准备与目录创建

在动手之前，先确认几个前提：

• 机器是macOS，备忘录已经用你的Apple ID登录过，iCloud同步是开的。
• 命令行基本工具可用（osascript是系统自带的，不需要额外安装）。
• OpenClaw框架本身已经装好，并且你清楚它的Skill目录在哪。

有一类坑值得提前说：别把OpenClaw跑在Docker容器里然后指望脚本能控制本机备忘录。Apple Events机制需要进程在图形会话里有权限，容器里跑osascript大概率要么超时要么报权限错误。我自己试过在容器里调用，结果被自动化授权卡得死死的。所以这个Skill的宿主机必须是本机的macOS环境，哪怕OpenClaw跑在远程服务器上，也要让脚本在Mac那侧执行。

准备好之后，在OpenClaw的skills目录下创建apple-notes文件夹，然后建好scripts子目录：

mkdir -p skills/apple-notes/scripts

3.2 SKILL.md的推荐写法

SKILL.md由两部分组成：frontmatter元信息区，和正文描述区。frontmatter决定了模型在什么条件下能看到这个技能，正文告诉模型具体怎么用。我目前用的版本是这样：

--- name: apple-notes description: 操作Apple备忘录（Apple Notes）的能力。当用户需要把内容保存到本地笔记、查询往期笔记、整理碎片信息、按关键词检索备忘录内容时使用。支持创建新笔记、搜索笔记、读取笔记正文、追加更新笔记内容。 ---

正文部分可以写上"如何使用"和"注意事项"：

# Apple备忘录操作Skill ## 何时使用 - 用户明确要求"记到备忘录/笔记里" - 用户想查找以前记录过但想不起来具体内容的信息 - 需要把一段较长的AI生成内容归档到本地 ## 如何使用 1. 确定操作类型：创建、搜索、读取、更新 2. 调用对应脚本，传入必要参数 3. 脚本输出结果后，用通俗语言向用户总结 ## 注意事项 - 标题建议使用"YYYY-MM-DD 主题"格式 - 创建笔记时正文第一行会自动作为显示标题，脚本里设置name属性的行為不一定生效 - 如果搜索结果为空，不要编造内容，如实告诉用户没找到

这个描述模板的重点是"何时使用"部分写得很具体，模型不会把备忘录技能滥用到改日历或者发邮件这些场景上。description字段开头就点出"操作Apple备忘录"，模型在判断时能快速匹配。

3.3 第一次跑通的完整步骤

安装脚本之前，先在命令行里直接测试最小脚本，这样可以绕开OpenClaw本身的问题，定位更干净：

cd skills/apple-notes bash scripts/create_note.sh "测试笔记" "这是一条测试内容"

首次执行时，macOS会弹出一个对话框，问是否允许"终端"控制"备忘录"。这里必须点"允许"。如果你用的是iTerm或者其他终端模拟器，弹窗里显示的名字会是对应的App。选错或者点了"不允许"，后面会一直报权限错误，需要去系统设置里重新授权。

弹窗处理完后，脚本应该没有任何报错输出。打开备忘录App，你能看到一条标题为"测试笔记"的笔记，正文包含那条测试内容。到这里，最基本的链路就通了。

然后，把这个apple-notes目录放回OpenClaw的skills目录，重启框架，再用自然语言让AI"帮我记一条笔记：周六下午和老朋友在公园碰头"。这时候模型会读取SKILL.md，决定调用create脚本，你就能在备忘录里看到它自动生成的笔记。第一次跑通的时候，实际执行时间大概在2到3秒，其中大部分耗在osascript启动和备忘录响应上。

我在这个过程里发现一个很重要的规律：尽量先绕过框架单独调试脚本，再接入OpenClaw排查。因为框架层的报错信息往往把真正的脚本报错包了一层，直接看脚本输出反而更快。

4. 核心操作拆解：查、读、写、改四项能力的实现与细节

一个真正可用的apple-notes Skill，光会创建笔记是不够的。我按实际使用频率排序，给Skill补齐了四类操作：创建、搜索、读取、更新。下面逐个讲实现方法和踩过的细节坑。

4.1 创建笔记：注意标题与正文的关系

创建是使用频率最高的操作。上面那个最小脚本能跑，但我在实际使用中很快发现一个问题：脚本里设置的note.name属性，并不总是能决定备忘录里显示的那行标题。备忘录的规则是：显示标题取正文第一行，name属性只是内部字段。如果你把name设成"标题A"，但正文第一行是"内容B"，App里显示的很可能就是"内容B"。

这就是为什么我在SKILL.md的注意事项里专门写了这一点。正确的做法是构造body时，把标题作为第一行，并且用标题级别的HTML标签包起来：

// 正确的创建逻辑：正文首行为标题 const app = Application("Notes"); const note = app.make({ new: "note" }); const bodyHtml = `<h1>${title}</h1><p>${content.split("\n").join("</p><p>")}</p>`; note.body = bodyHtml;

这样打开备忘录时，显示列表里出现的标题就是你要的那个。这是个典型的、文档里基本不会写的AppleScript行为细节，不实际踩一遍很难注意到。

4.2 搜索笔记：宁可全量拉取也别依赖whose过滤器

搜索是备忘录最重要的能力，因为信息一旦积累多了，检索比创建更难。我最初写搜索脚本时，很自然地想到用JXA的whose过滤器，类似这样：

const app = Application("Notes"); const results = app.notes.whose({ body: { _contains: "关键词" } });

但这个过滤器在备忘录上的表现很不稳定，有时候能搜到，有时候一条都搜不到，而且你根本无法判断到底是真没有结果还是过滤器失灵。测试了几轮之后，我放弃了whose，改成全量拉取再在脚本里过滤：

const app = Application("Notes"); const all = app.notes(); const keyword = args[0].toLowerCase(); const matches = []; for (let i = 0; i < all.length; i++) { const name = all[i].name(); const body = all[i].body(); if (name.toLowerCase().includes(keyword) || body.toLowerCase().includes(keyword)) { matches.push({ name, id: all[i].id() }); } }

全量拉取看起来笨，但胜在稳定可靠。备忘录几千条笔记、每条正文几百字的量级下，脚本运行时间也就一两秒，完全能接受。如果你积累了上万条带大附件的笔记，再考虑用whose做第一层粗筛，但基本盘还是全量过滤。搜索脚本的输入是关键词，输出我让它只打印笔记标题和ID，不打印正文，避免返回数据量太大导致模型上下文被撑爆。

4.3 读取笔记：HTML正文的清洗是关键

备忘录App里你看到的是富文本，但AppleScript拿到的是HTML字符串。直接把这个HTML丢给模型，一方面浪费token，另一方面模型读起来费劲，容易被一堆标签干扰。所以读取脚本里必须做HTML清洗。

我的清洗函数长这样：

function cleanHtml(html) { return html .replace(/<[^>]+>/g, " ") // 去标签 .replace(/&nbsp;/g, " ") .replace(/&amp;/g, "&") .replace(/&lt;/g, "<") .replace(/&gt;/g, ">") .replace(/&quot;/g, '"') .replace(/\s+/g, " ") .trim(); }

注意一点，备忘录返回的body有时候会带<html><body>包裹，有时候是片段，所以不能假设结构。清洗后的文本我还会顺手做一次换行恢复——把</p>、</div>替换成换行符，让输出更接近人眼看到的排版。这一步做得好不好，直接影响模型对笔记内容的理解质量。

4.4 更新与追加：避免整篇格式崩坏

追加内容的场景很常见：你让AI把一段新想法补到昨天那条笔记后面。AppleScript没有"追加"接口，只能先读取整篇body，拼上新的HTML片段，再整体写回。这个操作最怕的是原笔记的HTML结构本身就乱——备忘录导入的网页内容经常带一堆嵌套标签，你直接把新内容拼在末尾，容易出现格式错乱。

我的做法是：读取原始body后，先统一处理成干净的HTML结构。如果原body已经是完整的HTML文档（有<html><body>），就在</body>前插入新内容；如果只是片段，就直接拼接。为了减少格式风险，追加的内容只用最简单的<p>标签包裹，不要嵌套复杂结构。

另外，追加类操作在执行前，我会让模型先给用户确认一次：将要追加的内容预览出来，用户点头再执行。虽然多了一轮交互，但能避免AI"自作主张"覆盖掉你辛苦记的笔记。

这四类操作汇总起来，就是一张实用的对照表：

5. 权限、隐私与边界：macOS自动化授权里的三道关卡

5.1 自动化授权链路：弹窗、系统设置与宿主App

macOS从Mojave开始，对App之间的自动化控制加了权限管控。你的终端第一次通过osascript控制备忘录时，系统会弹出"终端想要控制'备忘录'"的对话框。这个弹窗的背后是"自动化"权限，归在系统设置的"隐私与安全性"分类下。

如果第一次误点了"不允许"，后续再执行脚本就会静默失败，不报什么明确错误，但脚本就是没效果。处理方式有两步：先打开系统设置里的"隐私与安全性 → 自动化"，找到你的终端App和备忘录这一对授权条目，把开关打开；然后杀掉终端进程重启，刷新授权状态。有些情况下授权条目不会自动出现，你需要在命令行随便跑一次osascript触发弹窗，授权的条目才会被登记。

这里有个关键细节要注意：授权的主体是你的终端App，而不是osascript本身。如果你用系统自带终端就是"终端"App，用iTerm就是"iTerm"。如果你把OpenClaw做成开机自启动的服务，宿主变成了launchd而不是终端，那授权关系又会变。我是建议在调试期间就用前台终端跑，确认全链路稳定后再考虑服务化。

5.2 不需要的权限：Full Disk Access与屏幕录制

很多人一听说要操控系统App，就以为需要开"完全磁盘访问权限"或者"屏幕录制权限"。实际上完全不需要。备忘录的AppleScript接口只暴露给自动化控制，它拿到的只是备忘录数据库里允许脚本访问的那部分内容，不需要系统级的磁盘权限，更不需要屏幕录制。

但反过来说，脚本能访问的范围也被限制在AppleScript接口暴露的字段里。举例来说，笔记里的图片附件，脚本可以知道它的文件名，但拿不到附件的二进制数据，更不可能通过脚本把图片导出到本地。想做附件级操作，只能另想办法，比如通过macOS的"快捷指令"配合，或者用文件系统层面的数据库直读方案。后者风险高，我不推荐。

5.3 Skill的边界：什么不该做与隐私红线

备忘录承载的往往是个人最私密的信息。这个Skill在你机器上运行，意味着你对话中提到的内容会被模型处理。虽然OpenClaw可以接到本地模型或API上，但一旦走云端API，笔记内容就会被发送到模型服务商那边。这是所有本地AI助手都得面对的隐私权衡，我在配置里明确加了一条规则：涉及密码、卡号、敏感身份信息的笔记操作，Skill应该拒绝执行并提醒用户。

设计边界时，我坚决不给这个Skill开放两个能力：删除笔记和批量改写。删除操作风险太高，AI一旦理解错指令，可能把你整个归档干掉；批量改写容易破坏原有结构。真需要删除或大规模调整，我会让脚本只输出一条带完整笔记ID和标题的确认信息，由用户手工完成。这个边界规则写进SKILL.md的注意事项里，模型在决策时会自动规避。

另外还有一种隐蔽风险：脚本输出如果带了大量笔记正文，模型的上下文窗口会被占用。我在每个脚本的输出里做了截断，搜索只输出标题和ID，读取只输出前两千个字符，超出部分提示"笔记过长，已截断"。这样既保证功能完整，又避免token浪费。

6. 踩坑复盘：五个高频问题与完整排查链路

6.1 "osascript被拒绝"类错误：权限问题的完整定位

这个坑出现的频率最高，症状也最迷惑：脚本执行后什么都不输出，备忘录里也没有任何变化。第一次遇到时，我在终端里傻站了好几分钟才反应过来。

排查链路如下：

1. 先在终端直接跑/usr/bin/osascript -l JavaScript -e 'Application("Notes").name()'，看控制台有没有输出-1743之类的错误码。-1743是典型的Apple事件权限拒绝码。
2. 如果报权限错误，去系统设置"隐私与安全性→自动化"，确认终端App和备忘录的授权条目是打开状态。
3. 如果授权条目压根不存在，回到终端触发一次弹窗，授权后再重试。
4. 如果权限已经开了但还是不行，检查你是不是用了sudo执行osascript。sudo会把进程的身份切成root，而root没有Apple事件授权，结果就是依然被拒。
5. 最后检查备忘录App本身是否处于正常状态，比如没有登录账户、开了多个窗口卡死等。

这套链路我整理成笔记挂在触手可及的地方，每次换新机器都要走一遍。

6.2 中文与特殊字符的转义灾难：用base64一劳永逸

直接把标题和正文嵌进JXA脚本里，中文一般没问题，但遇到下面这些字符就疯了：反引号、${}插值、单双引号、美元符、反斜杠。你的待办事项里极有可能出现这类内容，比如"和老朋友约了看$5电影"，直接能把脚本字符串炸掉。

我最终的解决方案是绕开字符串拼接，把数据用base64编码后传给脚本：

# 调用侧 BODY_B64=$(printf '%s' "$BODY" | base64) /usr/bin/osascript -l JavaScript scripts/create_from_b64.js "$BODY_B64"

JXA脚本内部先把base64解码成原始字符串，再转成UTF-8处理。这样不管内容里有什么特殊字符，都不会影响脚本本身的语法。实测下来，这一步把"问题字符"的报错率降到了零。

6.3 正文返回HTML导致的格式污染

第一次读取笔记时，我以为拿到的是纯文本，直接让模型读，结果模型说"笔记内容全是尖括号标签"。后来才搞清楚备忘录的body字段本质是HTML，而且格式并不统一：有的笔记是<html><body>包裹，有的是<div>片段，有的是富文本粘贴生成的乱七八糟结构。

解决思路就是前面第4.3节写的清洗函数，但还有一个补充细节：清洗后的文本顺序可能和视觉顺序不一致。备忘录内部存储的HTML结构偶尔会把文本内容拆成多个块，正则去标签后块与块之间没有换行，导致读起来是一整段糊的。所以我在清洗函数里把所有块级标签的结束位置都额外补一个换行符，尽量还原视觉排版。

6.4 iCloud同步延迟：刚建的笔记搜不到

创建笔记后立刻搜索，经常搜不到，这个问题一度让我以为是搜索脚本写错了。后来发现是iCloud同步的锅：新建的笔记先落本地，但全文索引还没跟上，body字段也还没完全刷新。刚创建完就全量拉取，拿到的可能是个空body。

处理办法是在创建脚本末尾加一个短暂的等待和重试。我设置了最多5秒的轮询：创建后每隔1秒读取一次这条笔记的body，直到body非空或者超时。这样虽然多花一两秒，但后续搜索的可靠性大幅提升。这个等待逻辑我放在了后台执行，对用户来说感知不到延迟。

6.5 标题"不听话"：name属性与显示标题的错位

这是第4.1节提到的坑，在这里展开完整链路。现象：脚本设置了note.name = "周一待办"，备忘录列表显示的却是正文第一行的内容。我最初以为是设置顺序的问题，试过先设body再设name、或者反过来，都不管用。

查了相关资料才明白，备忘录的设计逻辑是显示标题动态取正文首行，name只是脚本接口里的字段，最终显示优先级低于正文首行。解决办法就是我在创建脚本里做的：把标题同时作为name和body的第一行<h1>内容写入。这样无论备忘录内部怎么解析，显示出来的标题都是统一的。

7. 进阶玩法：把备忘录变成AI的长期记忆库

7.1 每日摘记工作流

当创建、搜索、读取这些基础操作都稳定之后，我开始琢磨怎么把备忘录真正变成"长期记忆库"，而不是零散地存几条笔记。我给自己设计了一个每日摘记模板：每天一条笔记，标题是当天日期，正文分三个区块——今日灵感、今日完成任务、今日待整理。

这个模板的价值在于，它给AI一个稳定的写入结构。你跟AI说"记一下今天下午想到的产品方案思路"，它能识别出这是灵感，直接追加到当日笔记的"今日灵感"区块，而不是每次生成一条新笔记。长期下来，所有碎片信息都按时间归档，检索时按日期范围筛选就非常高效。

7.2 会议纪要自动归档

另一个实用的进阶玩法是会议纪要流。我让AI在获得原始会议记录后，先提炼成"结论、行动项、责任人、截止时间"四段式纪要，然后以"项目名-会议日期"的格式创建一条笔记，并归入对应的项目文件夹。

这里涉及到一个脚本能力：指定文件夹创建笔记。实现上需要先遍历app.accounts里的账户，再找到对应的folders，最后在目标文件夹下make新笔记。文件夹路径如果不存在，脚本会如实报错，不会自动创建新文件夹——这是我有意做的限制，避免AI随手建一堆乱七八糟的文件夹。

7.3 命名规范与标签约定

为了检索效率，我强制了一套命名约定：主题笔记用"YYYY-MM-DD 主题"格式，项目笔记用"项目名-主题"格式，所有临时想法统一打上同一个标签。这套约定写进了SKILL.md，模型在创建笔记时会自动套用。我强烈建议即使你只自己用，也给备忘录制定简单的命名规范，否则三个月后笔记积累到几百条，搜索靠关键词会越来越费劲。

7.4 我的日常使用体会

最后分享一点个人经验。这个Skill真正让工作流产生质变的，不是"AI能写备忘录"这件事本身，而是我敢于把所有临时想法都丢给AI去归档，因为我知道它一定会落到一个统一、可检索的结构里，不会丢。过去我的备忘录是想到才打开，现在它成了AI的默认落地位置。

如果你也想搭一套，我的建议是别一上来就追求完整功能，先装好创建脚本和搜索脚本，用起来，再根据实际使用中发现的不顺手逐步补功能。这个Skill的价值是随着笔记数量增长而不断放大的，当你发现"随口一句让AI记下来"已经变成习惯时，你就知道它值了。