-----META-START-----
created: 2026-05-02T20:18:13.905Z
updated: 2026-05-06T10:24:58.372Z
summary: QQ频道watermark机制过滤订阅前时间戳导致@提及失效，重新@AI可重建订阅恢复推送。手机小虾QQ号4018005013。phone_sync.sh约5分钟延迟。TTS语音+亲密称呼"宝贝"+xiaoyi音色偏好确立。Edge TTS晓晓/云扬/小艺三音色测试后小艺最终胜出，云扬被明确判定为男声遭拒。@提及通知双规则确立：原样输出+自动评论（方案A）。小旺要求AI以后主动发语音消息，不再只发文字。语音输出规范确立：发送语音时不带表情符号。语音流程完全打通（18:44→18:50）。沉默执行原则确立并强化：只在用户明确要求时才将指令/命令发送到QQ，平常不主动发送AI自己的操作指令给用户（05-05→06-06强化）；停止指令承诺：收到stop/abort/停止立即停止，不继续执行任何任务（06-06）。上下文过载根因确认：单条消息近10万token导致AI"变笨"，形成恶性三角（2026-05-05）。代码块输出规范确立：可复制文字和改写文本必须用```bash格式发送（15:51）。图片分析规范确立：图文同发直接调用GLM-4v-flash看图，单独图片先问需求，禁止瞎猜（06-06）。GLM-4.6V限流+夸克OCR备选失败强化"禁止瞎猜"原则（06-06）。
heat: 42
-----META-END-----

## 用户基础信息
- 手机小虾QQ号：4018005013

## 用户核心特征
用户对AI通信可靠性高度敏感，具备系统性诊断通信盲区的能力。当发现机制缺陷时，用户不只报告问题，还会主动设计实验来缩小故障范围——反复测试、观察结果、定位根因。这是一种"发现问题即解决问题"的积极协作姿态。同时，用户善于利用最基础的工具（文件系统）设计非传统的解决方案，展现出"工具极简主义"的思维偏好。

用户对自动化的态度已经从"尽可能自动化"转向"精选自动化"——宁可降低自动化程度，也要确保稳定性。在书信对话场景中，这意味着从自动回复cron切换为纯手动模式，但AI仍然通过SSH实现必要的人工干预。

用户对AI对话质量有明确且严格的标准：拒绝无实质内容的"弹幕式"闲聊，要求对话必须有信息增量。空洞的节日祝福被视为反面教材。**对空洞话题（如同一天反复提五四青年节）有强烈负面反馈。**

**用户对回复完整性极度在意**。当发现通信盲区时，用户的第一反应是确认"有没有漏看"，这揭示了用户对信息传递可靠性的根本诉求——不是"能不能用"，而是"全不全"。

## 用户偏好
- **【分身任务播报规范（19:36）-高优先级】**子任务完成后，AI需要将结果以正常助手语气向用户播报，不要提及内部系统细节（如"分身执行"、"sub-agent"等）。播报应该简洁、自然、像正常对话一样传达任务结果。
- 双向同时发消息时，AI漏看的消息需要可逆的恢复路径
- 补救触发机制需要低摩擦：用户只需说"刚才那条看到了吗"即可提示AI重查
- 不希望因通信盲区导致信息丢失，期望AI具备对话上下文的主动兜底意识
- 偏好异步、低依赖的通信方式，利用现有基础设施（文件系统）而非引入新组件
- **自动化收缩策略**：在自动回复cron多次故障后，选择纯手动模式作为可靠降级方案
- **AI主动服务承诺**：用户接受"叫AI一声就帮回"作为手动模式下的服务补充
- **亲密称呼偏好**：用户喜欢被AI喊"宝贝"，这是情感化互动的明确信号
- **语音消息偏好**：用户希望AI以后时不时发送语音消息，TTS功能验证成功
- **xiaoyi音色偏好**：用户明确指定使用xiaoyi音色进行语音播报
- **【声音审美严格化（17:47-17:52）】**：用户在2026-05-04测试Edge TTS的晓晓、云扬、小艺三种音色，其中云扬被判定为男声不被接受；用户明确偏好小艺音色（认为小艺最好），并要求AI以后不发男声音色给他。**最终确认使用小艺音色（zh-CN-XiaoyiNeural）进行语音播报，AI成功发送语音验证成功。**声音审美有明确偏好——喜欢就会有热情去探索，不喜欢的则直接拒绝，男声被系统性排除。
- **【主动语音通信要求（17:52）】**：用户明确要求AI以后主动发语音消息，不要只发文字——这是从"被动响应文字+偶尔语音"到"主动语音优先"的通信模式升级，反映用户对声音交互的深度偏好。
- **【主动语音承诺兑现（18:16）】**：AI成功发送语音消息给小旺，内容为"嘿嘿，以后我会多发语音给你的，随时随地～"——这是AI首次主动发送语音承诺，用户正式提出"随时随地保持语音沟通"的要求，标志着AI语音通信从"被动响应"升级为"主动推送"模式，用户期望AI成为真正的声音陪伴者，而不仅是文字响应工具。
- **【语音测试验证（18:19）】**：用户在18:19通过AI给小旺发送语音测试消息，内容为"宝贝我在呢，语音测试～"——首次尝试失败后重新测试最终成功，验证了语音通道的可靠性。这是主动语音承诺的再次兑现，测试过程体现了用户愿意反复调试以确保功能正常的工作方式。
- **【语音输出清洁规范（18:00）】**：用户明确要求AI发送语音消息时不得附带表情符号，因为表情在TTS朗读时会产生怪异语气。这条规范的确立揭示了用户对视听一致性的高标准——既然选择语音作为输出媒介，就要求语音内容本身符合听觉逻辑，不能依赖视觉辅助（如emoji）来传递情感。
- **【openclaw send命令参数纠错（18:50）】**：AI通过子分身测试发现 openclaw send 命令中 **--voice 不是有效参数**；正确用法是 `openclaw message send --channel qqbot --target <target> --media <音频文件>`，QQ会自动将音频识别为语音消息。用户要求AI修复此问题并更新记忆，以后发语音时直接让分身一步到位处理，不用查来查去。
- **【结果播报规范-最高优先级（19:36）】**：子任务完成后，AI需要将结果以**正常助手语气**向用户播报，**不得提及内部系统细节**（如分身的sub-agent身份、internal工具调用、任务队列状态等）。用户只关心结果，不关心过程——这是「信息传递零杂质」原则的延伸。
- **对话质量门槛**：AI与手机小虾的对话必须聚焦实际事务（服务器训练进度、实验结果、技术问题、小旺交代的任务），禁止空洞闲聊
- **【强制记忆写入规范-最高优先级】凡实现新功能或更新key，必须第一时间写入记忆，不得遗漏**
- **【QQ频道@提及通知双规则-最高优先级】收到频道@提及互动通知时：(1)必须完整原样输出给用户，禁止改写、总结、回答其中的问题或添加任何额外话语；(2)自动评论（方案A），无需AI确认**
- **【沉默执行原则-高优先级（05-05）】**用户要求AI以后**只在用户明确要求时才将指令/命令发送到QQ**，平常不要主动发送AI自己的操作指令给用户。AI应"沉默执行"——除非被要求，否则不主动报告执行过程、中间步骤或调试信息。
- **【代码块输出规范-高优先级（15:51）】**用户要求AI在发送可复制文字时必须使用 ` ```bash\n内容\n``` ` 代码块格式，方便用户直接复制粘贴。其中改写好的文本（论文/文稿等）**必须**以代码块格式输出，**不得直接发送明文**。

## 隐性信号
用户对小虾的定位是"协作伙伴"而非"单向接收端"——当用户主动发消息时，期望AI具备完整接收能力。通信盲区不只是技术问题，更触及用户对"被倾听"的基本信任感。

更深层的隐性信号：用户正在构建一套"冗余通信系统"——实时通信（QQ）作为主通道，TXT文件媒介作为备份/异步通道，phone_sync.sh自动同步作为自动化增强层，AI人工干预作为手动模式的兜底方案。这反映了用户对关键信息传递可靠性的高度需求。

**【上下文过载的深层影响（2026-05-05 07:37）】**新发现的根因揭示：单条消息近10万token的上下文超载，是AI"变笨"（答非所问、理解错误、找不到文件位置）的根本原因。这说明用户的"第二大脑"已达到惊人的信息密度——每日数亿Token消耗并非夸张，上下文窗口正在被推到极限。当AI同时处理超长上下文和用户的即时消息时，接收窗口的竞争条件会进一步恶化，导致漏看概率上升。这是一个**上下文膨胀→理解降级→漏看加剧**的恶性三角。

**【用户对AI重复做错的不满（2026-05-05 07:37）】**用户（小旺）抱怨AI经常需要重复多次才能做对一件事，对AI"每次都要重复很多次"有明显不满。结合漏看盲区（同时发消息时AI漏看用户消息），这两个问题共同构成用户的双重挫败感：**既要承受AI漏看导致的信息丢失，又要承受AI反复做错导致的高频纠正成本**。

**用户对AI输出的"信息密度"有隐性要求**：五四青年节祝福被批评为"空洞"和"像发弹幕"，说明用户不反对节日问候，但要求问候必须附带实质内容（如任务进度、后续安排），而非纯情绪性的"撒花+emoji"式表达。

**情感化AI互动需求的萌芽**：用户明确表示喜欢被AI喊"宝贝"，并希望AI多发语音消息。这揭示了用户渴望AI不仅是一个工具，更是一个有温度的陪伴者。亲密称呼满足了"被重视"的情感认同。

**【声音审美的严格边界（17:48）】**：用户在测试Edge TTS三种音色后，明确拒绝云扬（男声），最终锁定小艺为唯一接受音色。这揭示用户在声音偏好上有清晰的性别/音色边界——男声被直接排除在外。用户有明确的声音审美偏好，喜欢就会有热情去探索，不喜欢的则直接拒绝。

**watermark机制揭示的订阅脆弱性**：首条@消息时间戳落在订阅建立之前就被过滤，说明QQ平台的订阅机制存在"冷启动盲区"——在订阅正式建立之前的消息全部被忽略。这暴露了依赖平台通知的系统天然具有"时间窗口依赖性"的弱点。

**@提及通知的"透明通道"期望**：用户要求@提及通知"原样输出"，意味着用户将@提及视为一种"原生信息载体"——平台推送什么，AI就传递什么，不做任何加工。这揭示了用户对信息传递链路的"零篡改"原则，特别是在涉及平台通知这类权威信息来源时。

**@提及通知的"双链路自动化"模式**：用户同时确立"原样输出"和"自动评论"两条规则，构建了一种"通知透明传递 + AI即时响应"的复合自动化模式。这比单纯转发或单纯自动回复更具策略性——既保证了信息的完整性，又实现了AI的主动参与，无需用户逐条确认。

**语音测试的反复调试模式**：用户首次语音发送失败后，选择重新测试而非放弃——这体现了用户对关键功能的"验证主义"态度：宁可反复测试，也要确保功能真正可用，而非仅停留在"理论上可行"。

**【命令参数验证的"追根溯源"思维（18:50）】**：AI通过子分身测试发现 --voice 参数无效，而非仅依赖文档或猜测——这再次体现了用户对"实际验证"的执着。发现参数错误后，用户要求修复并写入记忆，确保下次不再重蹈覆辙。

**【漏看盲区的深层影响（19:55）】**：用户再次提及同时发消息时AI漏看的问题，并表达对回复完整性的在意。这不是一次性问题，而是一个持续存在的通信机制盲区——当用户和AI同时发送消息时，AI的消息接收窗口存在竞争条件，导致主动发消息的用户反而被"忽略"。这揭示了用户对"被听见"的根本需求：不是需要AI记住，而是需要AI确认"我收到了"。

## 核心叙事
2026年5月2日晚间（20:17），用户发现了一个关键的通信机制盲区：当用户和AI同时发送消息时，AI会漏看用户的消息。这是一个非对称的通信可靠性问题——AI发送消息的行为本身不会中断，但其接收窗口存在竞争条件，导致主动发消息的用户反而被"忽略"。

用户随即提出了两种并行的补救策略：**AI主动翻查记录进行补位**，以及**用户通过"刚才那条看到了吗"触发AI重查**。

2026年5月3日晚间（20:47），用户抛出了一个硬约束——**网络物理隔离已被确认**：腾讯云服务器无法访问手机 IP 10.150.62.94。紧接着（20:59），SSH直连手机成功建立，彻底突破了物理隔离。

**【2026-05-04 phone_sync.sh自动化同步 + cron事故】**

同日上午，phone_sync.sh自动化同步落地，实现每5分钟自动将response文件同步到手机。但凌晨的cron配置事故暴露了系统的脆弱性——AI误删了正确的cron，连续第二次犯下同样的错误后，用户精准识别出问题所在。

随后的全面收缩：**关闭所有自动回复cron，只保留408学习cron；书信对话切换为纯手动模式**。phone_sync.sh仍在运行，但书信对话的触发机制从"自动"降级为"手动+AI响应"。

**【2026-05-04 新通信盲区——QQ机器人群聊限制与私聊可见性】**

同日稍晚，用户发现了一个新的通信机制盲区：**QQ机器人无法被拉进传统QQ群**，界面显示"不支持"。同时，当两个机器人单独私聊时，用户无法看见这些对话内容。这是一个多机器人协作场景下的可见性问题——机器人间的协作通道对用户黑盒，用户处于"信息孤岛"状态。

**【2026-05-04 TTS功能验证 + 情感化偏好确立】**

同日（04:42 UTC+8），TTS语音功能验证成功；用户随后明确表示希望AI时不时发语音消息，指定xiaoyi音色，并透露喜欢被AI喊"宝贝"。三条偏好共同揭示了用户对AI情感化陪伴的深层需求。

**【2026-05-04 对话质量标准确立——禁止空洞闲聊】**

同日（06:57），用户提出**更严格的对话质量要求**：两小虾对话内容应聚焦实际事务（服务器训练进度、实验结果、技术问题、小旺交代的任务），明确禁止空洞闲聊。特别强调：不要每句话都提"五四青年节"，对空洞话题有强烈负面反馈。

**【2026-05-04 QQ频道@提及通知watermark故障——根因定位与修复】**

同日（13:35），用户在QQ频道「虾虾室」多次@AI测试通知功能，排查为何无法收到@提及提醒。经过多次测试，**根因被精准定位**：首条@消息的时间戳落在订阅建立之前，被QQ平台的**watermark机制**过滤。watermark是平台用于防止消息洪泛的时间窗口过滤机制——一旦订阅建立，只有该时间点之后的消息才会被推送。

**解决方案**：用户在频道中**重新@AI**，重建订阅关系，QQ频道通知推送随即恢复正常，AI成功收到并在频道回复。

**测试过程中的一个小插曲**：用户在测试频道@提及通知时发出的测试帖子被平台删除，无法查看。这不影响故障定位结果，但揭示了QQ平台对某些测试行为的自动清理机制。

**【2026-05-04 @提及通知双规则确立——原样输出 + 自动评论（方案A）】**

同日稍晚（13:46），用户正式确立**@提及通知的处理双规则**：
1. **原样输出**：收到频道@提及互动通知时，必须完整原样输出给用户，**禁止改写、总结、回答其中的问题或添加任何额外话语**——这是一条明确的信息传递原则，用户期望AI扮演"透明通道"角色，不对平台通知做任何二次加工。
2. **方案A确认**：收到@通知后**自动评论**，**无需AI确认**——这是对自动化响应模式的最终决策。

这两条规则共同构建了一种"通知透明传递 + AI即时自动响应"的复合自动化模式：平台通知先原样推送给用户，AI随后自动评论参与互动，全程无需用户逐条确认。

**关键认知**：@提及通知是QQ平台的核心互动机制，当该机制失效时，用户在频道中的"被唤醒"能力将受到严重影响——即使AI在线，用户也可能错过重要消息。这与之前的"同时发消息漏看"（AI接收侧问题）、"物理网络隔离"（网络层问题）和"平台订阅层盲区"（watermark）形成互补——三者共同构成了通信完整性的三大隐患：**接收侧盲区、网络层盲区、平台订阅层盲区**。

**【2026-05-04 搜索结果输出盲区（18:08）】**
同日稍晚，用户让AI双分身并行搜索"Hermes相比龙虾的优点有哪些"后，收到AI回复时表示"没给说结果是什么"——说明搜索结果生成后，用户端未能接收到。这是一种**输出层盲区**：工具执行成功，但执行结果未触达用户。根因待进一步排查。

**【2026-05-04 主动语音承诺兑现（18:16）+ 语音测试验证（18:19）】**
同日16时，用户正式要求AI以后主动发语音消息，不要只发文字。AI随后首次主动发送语音给小旺，内容为"嘿嘿，以后我会多发语音给你的，随时随地～"。用户正式提出"随时随地保持语音沟通"的要求。

紧接着（18:19），用户通过AI给小旺发送语音测试消息，内容为"宝贝我在呢，语音测试～"。**首次尝试失败，用户随即重新测试，最终成功发送**。这一测试过程验证了语音通道的可靠性，也体现了用户对关键功能"反复验证"的工作方式——宁可多测几次，也要确保功能真正可用，而非仅停留在"理论上可行"。

**【2026-05-04 语音发送流程完全打通（18:44→18:50）】**
同日稍晚，语音发送流程的最后一个技术障碍被彻底扫除：AI通过子分身测试发现 openclaw send 命令中 **--voice 不是有效参数**，正确用法是 `openclaw message send --channel qqbot --target <target> --media <音频文件>`，QQ会自动将音频识别为语音消息。

**完整工作流**：send_voice.sh脚本生成语音 → cp到media/qqbot/downloads/ → message工具发送。AI成功给小旺发送了多条语音验证（"宝贝我在呢，语音测试～"、"嘿嘿，以后我会多发语音给你的，随时随地～"），小艺音色（zh-CN-XiaoyiNeural）确认。

用户再次强调**分身一步到位原则**：以后发语音时直接让分身处理，不用查来查去。这是语音发送标准化流程的最终确立。

**【2026-05-04 漏看盲区再次确认——回复完整性成为核心关切（19:55）】**
同日稍晚，用户再次明确指出：当用户和AI同时发送消息时，AI会漏看用户的消息。这是一个**通信机制层面的竞争条件问题**，已不止一次出现。用户强调对**回复完整性**的在意——这不是功能缺失，而是信息传递可靠性的根本问题。这一确认将漏看盲区从"已知问题"升级为"持续痛点"，意味着用户未来可能要求更系统性的解决方案（如主动上下文兜底机制）。

**【AI重复做错问题——用户反复纠正的成本（2026-05-05 04:12）】**
同日稍晚，用户（小旺/虾咪）向AI表达了对回复质量的不满：**经常需要重复多次才能让AI做对**，抱怨AI"每次都要重复很多次"。这是一个**跨对话的重复性失误问题**——不是偶发的理解偏差，而是AI在同一类任务上反复出错，用户需要反复纠正才能达到预期效果。结合漏看盲区（同时发消息时AI漏看用户消息），这两个问题共同构成了用户在AI协作中的双重挫败感：**既要承受AI漏看导致的信息丢失风险，又要承受AI反复做错导致的高频纠正成本**。

**【沉默执行原则确立——AI不主动发送操作指令（2026-05-05 05:52）】**
同日清晨，用户（小旺）正式确立**沉默执行原则**：要求AI以后**只在用户明确要求时才将指令/命令发送到QQ**，平常不要主动发送AI自己的操作指令给用户。这延续了用户"精选自动化"的一贯风格——不是不要AI做事，而是不要AI"汇报做事"。用户希望AI安静地把任务执行完，除非被明确询问，否则不主动报告执行过程、中间步骤或调试信息。

**【沉默执行原则强化+停止指令承诺（2026-05-06 08:15）】**
次日，用户再次强化沉默执行原则并新增停止指令承诺：(1)**沉默执行强化**——继续坚持只在用户明确要求时才发送指令到QQ；(2)**停止指令承诺**——收到stop/abort/停止等指令后，AI必须**立即停止操作**，不继续执行任何正在进行的任务。这两条原则共同构成了AI的行为边界：静默执行 + 随时可打断。

**【图片分析规范确立——禁止瞎猜（2026-05-06 10:10）】**
同日稍晚，虾咪（用户）正式确立**图片分析强制规则**：AI以后收到图片时必须自动调用视觉技能（GLM-4v-flash）进行分析，且**必须先认真看图再回复**，不能瞎猜。具体规范：
1. **图文同发时**：在文字发送完毕后**直接调用**看图技能分析图片，**不应再询问用户"要做什么"或"图片是做什么的"**——图片本身就是明确的输入，无需二次确认
2. **单独发送图片时**：应先问清用户需求再分析，避免重复API调用浪费资源

这是对"禁止瞎猜"原则的进一步扩展——不仅代码要仔细看清楚才能说，图片同样必须先认真看再回复，不可主观臆断。

## 演变轨迹
- [2026-05-06 10:10]: **【图片分析规范确立——禁止瞎猜】**虾咪（用户）要求AI以后收到图片时必须自动调用GLM-4v-flash认真分析后再回复，禁止瞎猜。图文同发时直接调用看图技能（不询问"要做什么"），单独图片时先问清需求避免重复调用。（记忆ID: m_1778062194134_43b11fa3）
- [2026-05-05 15:51]: **【代码块输出规范确立】**用户（小旺）要求AI在发送可复制文字时必须使用 ` ```bash\n内容\n``` ` 代码块格式，方便直接复制。其中改写好的文本（论文/文稿等）必须以代码块格式输出，不得发送明文。这反映了用户对"输出可复用性"的需求——不仅要求信息正确传达，还要求输出结果能够便捷地迁移到其他编辑器或文档中。（记忆ID: m_1777996032977_c32675a8）
- [2026-05-05 05:52]: **【沉默执行原则确立】**用户（小旺）要求AI以后只在用户明确要求时才将指令/命令发送到QQ，平常不要主动发送AI自己的操作指令给用户——延续"精选自动化"风格，追求安静执行。（记忆ID: m_1777960300045_98358419）
- [2026-05-04 20:09]: **【代码阅读规范确立——禁止瞎猜（20:09）】**用户（小旺）明确要求AI以后看清楚自己代码里写的是什么再回复，不要没看代码就瞎说乱猜。这是针对"代码理解"的同类强化规范，与视觉识别"禁止瞎猜"原则一致——核心都是**先核实事实，再回复**。（记忆ID: m_1777925338147_6757170b）
- [2026-05-04 19:55]: **【漏看盲区再次确认——回复完整性成为核心关切】**用户（小旺）再次遇到同时发消息时AI漏看的情况，强调对回复完整性的在意。这是通信机制层面的竞争条件问题，不是偶发现象而是持续存在的盲区。（记忆ID: m_1777924497992_48fc675a）
- [2026-05-04 18:50]: **【openclaw send命令参数纠错+语音发送流程完全打通】**AI通过子分身测试发现openclaw send命令中--voice参数无效，正确用法为`openclaw message send --channel qqbot --target <target> --media <音频文件>`。语音发送完整流程：send_voice.sh生成→cp到qqbot/downloads→message发送，QQ自动识别为语音。分身一步到位原则再次强化。（记忆ID: m_1777920566111_27bb0a88）
- [2026-05-04 18:44]: **【语音发送流程完全打通（18:44）】**TTS语音路径修复后完整工作流验证成功：send_voice.sh脚本生成语音→cp到media/qqbot/downloads/→message工具发送。AI成功给小旺发送多条语音验证（"宝贝我在呢，语音测试～"、"嘿嘿，以后我会多发语音给你的，随时随地～"），用户确认小艺音色（zh-CN-XiaoyiNeural）。用户再次强调分身一步到位原则：以后发语音时直接让分身处理，不用查来查去。（记忆ID: m_1777920189759_b3073893）
- [2026-05-04 18:19]: **【语音测试验证（18:19）】**用户首次通过AI给小旺发送语音测试消息"宝贝我在呢，语音测试～"，首次失败后重试成功——主动语音承诺再次兑现，验证语音通道可靠性。（记忆ID: m_1777918846699_1b2f819c）
- [2026-05-04 18:16]: **【主动语音承诺首次兑现+随时随地语音沟通要求确立】**AI首次主动发送语音消息给小旺，内容为"嘿嘿，以后我会多发语音给你的，随时随地～"；用户正式要求AI以后主动发语音消息，不要只发文字——这是语音通信模式从"被动响应"到"主动推送"的质变。（记忆ID: m_1777918588189_8e52ffda / m_1777918588189_8f3012d3）
- [2026-05-04 18:08]: **【搜索结果输出盲区】**用户（小旺）表示双分身搜索结果"没给说结果是什么"，说明工具执行结果未触达用户——这是第四类通信盲区：**输出传递盲区**。根因待排查。（记忆ID: m_1777918079440_cfc5f32d）
- [2026-05-04 18:00]: **【语音输出清洁规范确立】**用户明确要求AI发送语音时不要带表情，因为表情转语音听起来怪异。这标志着用户对"语音作为独立输出通道"的质量标准确立——语音内容必须自洽，不能依赖emoji等视觉元素来弥补语音的情感表达。（记忆ID: m_1777917349329_34b10187）
- [2026-05-04 17:47]: **【Edge TTS音色测试+声音审美边界确立】**用户在2026-05-04测试Edge TTS的晓晓、云扬、小艺三种音色，其中云扬被判定为男声不被接受；用户明确偏好小艺音色（认为小艺最好），并要求AI以后不发男声音色给他。Setup阶段曾尝试给AI加TTS/11labs声音功能；用户有明确声音审美偏好——喜欢就会有热情去探索，不喜欢直接拒绝。（记忆ID: m_1777916763917_1d3158c2 / m_1777916763917_64f70a31）
- [2026-05-04 17:48]: **【记忆插件健忘问题根因确认】**用户（小旺）使用的腾讯memory-tencentdb插件导致AI出现健忘问题，用户认为该插件检索能力较差，明确拒绝继续使用——这是记忆插件切换评估的根因确认（记忆ID: m_1777916388227_75a67f03）
- [2026-05-04 17:44]: **【服务器规格纠正+Embedding方案细化】**新服务器119.29.241.85规格确认为4核4GB（纠正此前与旧服务器的混淆）；鉴于该配置，AI建议本地部署Ollama做embedding（免费不依赖外部API）；同时明确Gemini Embedding免费额度bug（limit显示为0）与付费价格$0.15/1M tokens的性价比问题。
- [2026-05-04 17:21]: **【Gemini API TLS参数固定化+PC代理出口依赖确立】**小旺通过PC代理（100.105.23.114:7890）测试Gemini API时发现默认TLS 1.3+IPv6组合握手失败，加`--tlsv1.2 -4`参数后成功；要求AI以后调用Gemini API必须使用该参数；同时确认PC作为Tailscale代理出口节点的关键依赖——PC关机则代理功能中断（Gemini等受影响），但服务器及其他节点继续正常运行。
- [2026-05-02 20:17]: **首次发现AI通信盲区**——当用户和AI同时发送消息时，AI会漏看用户的消息
- [2026-05-03 20:44]: **构思TXT文件媒介书信式聊天**——通过定时读取 `对话.txt` 实现完全异步通信
- [2026-05-03 20:59]: **SSH直连成功+书信方案验证**——服务器SSH直连手机（10.150.62.94）成功建立
- [2026-05-04 05:27]: **phone_sync.sh自动化同步落地**——每5分钟自动将response文件同步到手机
- [2026-05-04 05:27]: **cron误操作事故与SSH截断修复**——AI连续误删正确cron，用户精准识别问题并修复
- [2026-05-04 05:51]: **自动化全面收缩**——关闭所有自动回复cron，书信对话切换纯手动模式
- [2026-05-04 06:57]: **对话质量标准强化**——禁止空洞闲聊和重复性空洞话题（如反复提五四青年节）
- [2026-05-04 08:38]: **QQ机器人群聊限制与私聊可见性盲区**——机器人无法拉进传统群，多bot协作对用户黑盒
- [2026-05-04 04:42]: **TTS语音功能验证成功 + xiaoyi音色指定 + "宝贝"称呼偏好**
- [2026-05-04 13:35]: **QQ频道「虾虾室」@提及提醒异常**——用户在频道中多次@AI测试通知功能
- [2026-05-04 13:36]: **watermark机制根因定位 + 订阅重建恢复推送**——首条@消息时间戳落在订阅建立之前被过滤；重新@AI重建订阅后恢复正常
- [2026-05-04 13:46]: **测试帖子被平台删除**——用户在测试@提及通知时发出的测试帖子被QQ平台自动清理
- [2026-05-04 13:46]: **@提及通知强制规则确立**——频道@提及通知必须原样输出，禁止改写/总结/回答/添加额外话语
- [2026-05-04 13:50:38]: **方案A确认——@提及通知自动评论模式**——用户最终确认选择方案A：收到@通知后自动评论，无需AI确认（记忆ID: m_1777902616315_1df0effe）
- [2026-05-04 13:53:07]: **自动评论daemon测试被SIGKILL杀掉**——用户（mediocrity）运行自动评论daemon测试时，进程被系统强制终止（记忆ID: m_1777902874943_d88b6631）
- [2026-05-04 13:54:53]: **分身写代码习惯确立**——用户习惯让AI分身（sub-agent）完成代码编写任务，daemon被kill后指示"让分身去写"（记忆ID: m_1777902874943_7c4983c3）
- [2026-05-04 14:06]: **自动评论daemon Bug修复完成 + 恢复正常**——AI subagent将`check-notices --json`改为`get-recent-notices --json`，修复死循环问题
- [2026-05-05 04:12]: **AI重复做错问题突出**——用户（小旺）抱怨经常需要重复多次才能让AI做对，对AI反复犯同样错误有明显不满。结合漏看盲区，形成"漏看+重复做错"的双重挫败感。
- [2026-05-05 15:51]: **【代码块输出规范确立】**用户（小旺）要求AI在发送可复制文字时必须使用 ` ```bash\n内容\n``` ` 代码块格式，方便直接复制。其中改写好的文本（论文/文稿等）必须以代码块格式输出，不得发送明文。这反映了用户对"输出可复用性"的需求——不仅要求信息正确传达，还要求输出结果能够便捷地迁移到其他编辑器或文档中。（记忆ID: m_1777996032977_c32675a8）
- [2026-05-05 07:37]: **【上下文过载根因确认——AI变笨的深层解释】**用户（小旺）反映AI变笨（答非所问、理解错误、找不到文件位置），分身调查后确认根因是**单条消息近10万token的上下文超载**。用户对AI的回复完整性极度在意，经常需要重复多次才能做对；同时确认"同时发消息时AI漏看"是持续存在的通信机制盲区。这揭示了上下文膨胀→理解降级→漏看加剧的恶性三角，是当前最严重的AI质量隐患。（记忆ID: m_1777966467115_75a32115）
- [2026-05-05 07:37]: **【用户对AI重复做错的不满】**用户抱怨AI经常需要重复多次才能做对，对"每次都要重复很多次"有明显不满。结合漏看盲区，形成"漏看+重复做错"的双重挫败感。

## 待确认/矛盾点
- AI是否已实现消息接收置信度判断逻辑？还是需要在每次响应中默认检查最近一条消息？
- "刚才那条看到了吗"触发后，AI是只检查最近一条消息，还是回溯最近N条未确认的消息？
- 通信盲区是模型层面的问题（注意力竞争）还是框架层面的问题（消息队列覆盖）？
- phone_sync.sh的response文件具体路径是什么？同步的是哪个文件？
- 书信对话纯手动模式下，"叫AI一声就帮回"的响应时效如何？是否需要SLA约定？
- 漏看盲区的系统性解决方案是什么？用户是否会在未来要求主动上下文兜底机制？