Auto-sync: 2026-04-22 20:55

wiki/concepts/AI-Auto-Response.md

@@ -0,0 +1,56 @@
+---
+title: "AI Auto-Response"
+type: concept
+tags: []
+sources: []
+---
+
+# AI Auto-Response
+
+## Definition
+
+AI Agent 基于客户消息内容和知识库自动生成并发送回复，无需人工介入的处理模式，是多渠道客服降低人工成本的核心机制。
+
+## Workflow
+
+```
+Customer Message
+    ↓
+[Language Detection] → Detect language
+    ↓
+[Intent Classification] → FAQ / Appointment / Complaint / Review
+    ↓
+[Business Knowledge Base] → Retrieve relevant info
+    ↓
+[Response Generation] → Contextual, language-matched reply
+    ↓
+[Send to Channel] (or [Test Mode] → log only)
+```
+
+## Effectiveness Metrics
+
+| Metric | Description |
+|--------|-------------|
+| **Auto-response Rate** | 自动处理的消息占比（目标: >80%） |
+| **Response Time** | 从收到消息到发送回复的平均时长 |
+| **Escalation Rate** | 转人工的消息占比 |
+| **Customer Satisfaction** | 自动化回复的客户满意度评分 |
+
+餐厅案例：自动处理率 80%，平均响应时间 <2 分钟（对比人工 4+ 小时）。
+
+## Quality Safeguards
+
+- **Never invent**：禁止生成知识库中没有的信息
+- **Handoff guard**：不确定时主动转人工而非猜测
+- **Brand consistency**：回复语气与品牌形象一致
+
+## Related Concepts
+
+- [[Intent-Classification]]：意图分类决定触发哪种回复策略
+- [[Business-Knowledge-Base]]：知识库是自动回复的信息来源
+- [[Human-Handoff]]：AI 边界之外的场景转交人工
+- [[Language-Detection]]：回复语言跟随客户语言
+
+## Sources
+
+- [[multi-channel-customer-service]]

wiki/concepts/Active-Accountability.md

@@ -0,0 +1,46 @@
+---
+title: "Active Accountability"
+type: concept
+tags: []
+last_updated: 2026-04-17
+---
+
+## Definition
+
+AI Agent **主动发消息询问用户**是否完成了某项任务/习惯，而非等待用户主动打开 App 记录——将行为追踪从被动记录转变为主动对话。
+
+## Contrast with Passive Tracking
+
+| 维度 | 被动追踪（Passive Tracking） | 主动问责（Active Accountability） |
+|------|---------------------------|-------------------------------|
+| 触发方式 | 用户主动打开 App | AI Agent 按定时计划主动发送消息 |
+| 用户参与成本 | 需要主动记录 | 只需回复确认/否认 |
+| 通知行为 | Push 通知容易被忽略 | 主动询问，回复率更高 |
+| 典型产品 | Streaks、Habitica、Loop Habit | OpenClaw Habit Tracker |
+| 放弃率 | 高（一周后通常停止） | 低（持续参与度高） |
+
+## Why It Works
+
+行为改变研究（Klein, 2011; Gollwitzer, 1999）表明：
+- **承诺一致性**：当用户通过回复消息明确表态（"是的，我完成了"），心理承诺效应使他们更可能在未来坚持
+- **即时反馈**：AI 即时确认和鼓励比事后查看 App 数据更有激励效果
+- **社会存在感**：主动发消息的 AI 提供了"有人在监督"的真实感觉
+
+## Implementation
+
+依赖 [[OpenClaw]] 的 [[Scheduled Reminder]] 能力，配合 [[Adaptive Tone]] 调节消息语气：
+
+1. Cron Job 按设定时间发送签到消息
+2. 用户回复完成/未完成
+3. AI 解析回复并更新 [[Streak Tracking]]
+4. 根据当前连续状态调整语气（[[Adaptive Tone]]）
+5. 每周日汇总 [[Weekly Pattern Analysis]]
+
+## Related Concepts
+- [[Adaptive Tone]] — Active Accountability 的关键差异化因素
+- [[Streak Tracking]] — Active Accountability 的核心激励机制
+- [[Scheduled Reminder]] — Active Accountability 的技术实现
+- [[Morning Briefing]] — Active Accountability 的同模式应用
+
+## Source
+- [[habit-tracker-accountability-coach]]

wiki/concepts/Adaptive-Tone.md

@@ -0,0 +1,43 @@
+---
+title: "Adaptive Tone"
+type: concept
+tags: []
+last_updated: 2026-04-17
+---
+
+## Definition
+
+AI Agent 根据用户表现动态调整语气和沟通策略的机制。连续成功时给予鼓励（encouraging），连续失败时保持温和坚持（gently persistent），而非使用统一的模板化消息。
+
+## Core Mechanism
+
+| 用户状态 | AI 语气策略 |
+|---------|-----------|
+| 连续完成（高连续天数） | 简短肯定 + 引用连续记录，例："Day 12 of morning workouts. Solid." |
+| 偶发错失（1-2天） | 温和提醒 + 初心提醒，例："Just acknowledge it and remind me why I started." |
+| 连续错失（≥3天） | 更长激励消息 + 询问是否调整目标 |
+
+## Why It Matters
+
+- **静态提醒容易被忽视**：Push 通知、每日模板消息最终会被大脑过滤为"噪音"
+- **个性化消息具有真实激励效果**："Day 15, don't break it now" 这类引用具体连续记录的消息会触发心理承诺一致性效应
+- **避免羞辱感**：连续错失时不要 guilt-trip（内疚轰炸），保持支持性语气才能让用户持续参与
+
+## Implementation Example（OpenClaw）
+
+```
+When I confirm a habit, respond with a short encouraging message and
+mention my current streak. Example: "Day 12 of morning workouts. Solid."
+
+When I miss a habit, don't guilt-trip me. Just acknowledge it and remind
+me why I started. If I miss 3 days in a row, send a longer motivational
+message and ask if I want to adjust the goal.
+```
+
+## Related Concepts
+- [[Agent Personality]] — Adaptive Tone 是 Agent Personality 在习惯追踪场景的具体应用
+- [[Streak Tracking]] — Adaptive Tone 消息中的数据来源
+- [[Active Accountability]] — 需要 Adaptive Tone 才能真正实现主动问责
+
+## Source
+- [[habit-tracker-accountability-coach]]

wiki/concepts/Business-Knowledge-Base.md

@@ -0,0 +1,45 @@
+---
+title: "Business Knowledge Base"
+type: concept
+tags: []
+sources: []
+---
+
+# Business Knowledge Base
+
+## Definition
+
+AI Agent 的结构化业务知识库，包含服务详情、定价政策、营业时间、常见问题解答和人工升级触发条件等信息，是 AI 自动回复准确性的核心依赖。
+
+## Contents
+
+| Category | Examples |
+|----------|---------|
+| **Services & Pricing** | 服务列表、价格区间、套餐选项 |
+| **Business Hours** | 营业时间、节假日安排、紧急联系方式 |
+| **Location** | 地址、交通指引、停车信息 |
+| **FAQ Responses** | 预定义的高频问答对 |
+| **Escalation Triggers** | 需要人工处理的场景定义（投诉、退款、特殊情况） |
+
+## Knowledge Injection
+
+在 [[OpenClaw]] 中通过以下方式构建知识库：
+1. **Structured data**：JSON/YAML 格式的结构化业务数据
+2. **AGENTS.md 配置**：路由规则和回复模板中嵌入知识
+3. **Document ingestion**：产品手册、政策文档导入
+
+## Quality Considerations
+
+- **准确性**：知识库内容必须与实际业务一致，否则 AI 会生成错误回复
+- **覆盖度**：覆盖越全面，AI 自动处理率越高
+- **更新机制**：业务变更时同步更新知识库，避免信息滞后
+
+## Related Concepts
+
+- [[AI-Auto-Response]]：知识库是自动回复的信息来源
+- [[Intent-Classification]]：知识库结构影响意图分类的准确性
+- [[Human-Handoff]]：升级触发条件定义在知识库中
+
+## Sources
+
+- [[multi-channel-customer-service]]

wiki/concepts/Check-in-Fatigue.md

@@ -0,0 +1,42 @@
+---
+title: "Check-in Fatigue"
+type: concept
+tags: []
+last_updated: 2026-04-17
+---
+
+## Definition
+
+当追踪的习惯数量过多时，用户因签到负担过重而开始忽略或跳过签到消息，最终导致整个习惯追踪系统失效的行为现象。
+
+## Symptom
+
+- 用户停止回复每日的签到消息
+- 连续天数开始归零，但用户不再关心
+- AI Agent 的消息变成"已读不回"
+- 用户最终完全停止使用系统
+
+## Root Cause
+
+**信号淹没**（Signal-to-Noise Ratio Degradation）：当每日签到数量超过认知负荷阈值（建议 3-5 个），大脑将所有签到消息归类为低优先级噪音，选择性忽略。
+
+| 追踪习惯数量 | 认知负荷 | 预期行为 |
+|------------|---------|---------|
+| 1-3 个 | 极低 | 高参与率 |
+| 3-5 个 | 可接受 | 良好参与率 |
+| 6-10 个 | 较高 | 逐渐疲劳 |
+| 10+ 个 | 过高 | 系统性忽略 |
+
+## Mitigation Strategy
+
+1. **初始限制**：系统建立时严格限制习惯数量为 3-5 个
+2. **渐进添加**：新习惯须等现有习惯稳定（连续 ≥14 天）后才添加
+3. **季度回顾**：定期评估每个习惯的参与率，淘汰参与率持续低于 50% 的习惯
+4. **优先级排序**：不在同一时间发送多个签到请求，分散到全天不同时段
+
+## Related Concepts
+- [[Active Accountability]] — Check-in Fatigue 是 Active Accountability 系统的失效模式
+- [[Streak Tracking]] — 当用户开始忽视签到，Streak 连续天数自然归零
+
+## Source
+- [[habit-tracker-accountability-coach]]

wiki/concepts/Conversational-Interface.md

@@ -0,0 +1,40 @@
+---
+title: "Conversational Interface"
+type: concept
+tags: [interface, UX, conversation, AI]
+sources: [second-brain]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+对话即界面（Conversational Interface）是一种以自然语言对话为核心交互模式的设计理念：用户通过发送消息来操作系统，无需学习特定命令、点击特定按钮或导航特定菜单。对话本身就是使用界面，打破了"发送消息 → 另一设备构建内容"的空间壁垒。
+
+## Aliases
+
+- Conversational Interface
+- 对话即界面
+- Chat as UI
+- 自然语言交互
+
+## Key Insight
+
+> "You can text your bot from your phone and it builds things on your computer. The interface is the conversation."
+
+## Characteristics
+
+1. **跨设备**：用户从手机发消息 → AI 在电脑端执行/构建
+2. **无需 App**：手机短信/Telegram/Discord → 直接触发 AI 操作
+3. **零学习曲线**：不需要学习任何新工具或新界面
+4. **上下文感知**：AI 基于对话历史理解用户意图
+
+## In System
+
+- [[Second Brain]] 的核心交互范式
+- [[multi-channel-assistant]] 同一模式的多渠道扩展
+- [[phone-based-personal-assistant]] 语音版对话接口
+
+## Relationships
+
+- [[Zero-Friction Capture]] — 对话界面是实现零摩擦捕获的关键手段
+- [[Topic-Based Routing]] — 对话场景下的上下文隔离机制

wiki/concepts/Cumulative-Memory.md

@@ -0,0 +1,42 @@
+---
+title: "Cumulative Memory"
+type: concept
+tags: [memory, agent, persistence, accumulation]
+sources: [second-brain]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+累积记忆（Cumulative Memory）是一种 AI Agent 记忆系统特性：Agent 永久保留用户告知的所有内容，随时间推移积累越来越丰富的个人上下文，使 Agent 变得越来越个性化、越来越有价值。与传统会话式 AI 的"每次会话从零开始"形成鲜明对比。
+
+## Aliases
+
+- Cumulative Memory
+- 累积记忆
+- Persistent Memory
+- 永久记忆
+- Long-term Memory
+- 长期记忆
+
+## Mechanism
+
+- 用户通过对话/短信告知 AI 的任何信息（想法、链接、书目、餐厅推荐）都会被永久存储
+- 每次新对话都基于历史上下文展开
+- 随时间推移，Agent 对用户的了解从"陌生人"进化到"贴身助理"
+
+## Key Insight
+
+> "OpenClaw's memory system is cumulative — it remembers *everything* you've ever told it, making it more powerful over time."
+
+系统价值不是线性增长，而是**复利增长**：记忆越多 → 理解越深 → 建议越精准 → 用户越依赖 → 记忆越多。
+
+## In System
+
+- [[Second Brain]] 的核心价值主张
+- [[OpenClaw]] Workspace/MEMORY.md 文件承载累积记忆
+
+## Relationships
+
+- [[Zero-Friction Capture]] — 零摩擦捕获是积累大量记忆的前提（摩擦越低，记录越多）
+- [[Agent Memory]] — 技术层面的 Agent 记忆实现

wiki/concepts/Heartbeat-Monitoring.md

@@ -0,0 +1,45 @@
+---
+title: "Heartbeat Monitoring"
+type: concept
+tags: []
+sources: []
+---
+
+# Heartbeat Monitoring
+
+## Definition
+
+定时任务定期检查客服队列状态，在消息出现积压或响应超时前主动告警的机制，确保 AI + 人工混合体系保持高可用性。
+
+## Purpose
+
+即使 AI 自动处理率很高，仍需监控：
+- **被 AI 错误分类的消息**（应升级但未升级）
+- **新渠道接入失败**
+- **知识库缺失导致大量相同 FAQ**
+- **人工队列积压**
+
+## Implementation
+
+Heartbeat 检查通常每 15-30 分钟运行一次：
+
+```
+Every N minutes:
+  1. Check unanswered messages older than X minutes
+  2. If count > threshold → Alert (email / Slack / Telegram)
+  3. Log daily response metrics:
+     - Total messages received
+     - Auto-response rate
+     - Escalation rate
+     - Average response time
+```
+
+## Related Concepts
+
+- [[Morning Briefing]]：Heartbeat 监控数据可作为每日晨报的一部分
+- [[Self-Healing-Systems]]：异常检测后可触发自动修复（如重新分类消息）
+- [[Alerting]]：监控告警机制
+
+## Sources
+
+- [[multi-channel-customer-service]]

wiki/concepts/Human-Handoff.md

@@ -0,0 +1,38 @@
+---
+title: "Human Handoff"
+type: concept
+tags: []
+sources: []
+---
+
+# Human Handoff
+
+## Definition
+
+AI Agent 将无法自动处理或需要人工判断的客户消息转移给人工客服的机制，确保复杂问题得到专业处理，同时保留 AI 的高效处理能力用于高频简单问题。
+
+## Triggers
+
+AI 应触发人工handoff的条件通常包括：
+- **复杂投诉**：情绪激动、涉及退款、法律条款
+- **未知领域**：问题超出知识库覆盖范围
+- **特定关键词**：明确标记的升级词（如 "speak to manager"）
+- **AI 不确定**：置信度低于阈值时的模糊消息
+- **人工请求**：客户明确要求转人工
+
+## Design Principles
+
+1. **即时确认**：handoff 时 AI 先确认收到消息，告知客户人工将跟进，避免"静默感"
+2. **上下文传递**：转交时携带完整的对话历史，避免客户重复描述问题
+3. **优先级标记**：投诉类消息标记高优先级，加快处理
+4. **无缝衔接**：人工接手后系统应有完整上下文，无需客户重述
+
+## Related Concepts
+
+- [[Intent-Classification]]：投诉意图（Complaint）通常是 Handoff 的主要触发器
+- [[Unified-Inbox]]：人工处理也在统一收件箱内进行
+- [[AI-Auto-Response]]：AI 与人工互补，AI 覆盖高频简单问题
+
+## Sources
+
+- [[multi-channel-customer-service]]

wiki/concepts/Intent-Classification.md

@@ -0,0 +1,42 @@
+---
+title: "Intent Classification"
+type: concept
+tags: []
+sources: []
+---
+
+# Intent Classification
+
+## Definition
+
+AI 自动识别客户消息的意图（Purpose / Goal），将非结构化自然语言映射为预定义的分类标签，从而触发对应的处理策略和回复逻辑。
+
+## Common Intent Categories
+
+| Intent | Trigger Keywords | Handling Strategy |
+|--------|-----------------|-------------------|
+| **FAQ** | "how much", "do you offer", "what is" | 从知识库检索答案并回复 |
+| **Appointment** | "book", "schedule", "available", "reservation" | 检查可用性并确认预约 |
+| **Complaint** | "frustrated", "refund", "terrible", "problem" | 标记人工审核 + 确认收到 |
+| **Review** | "google review", "rating", "stars" | 感谢反馈 + 回应问题 |
+| **Order Status** | "where is my order", "tracking", "delivery" | 查询系统返回状态 |
+
+## Implementation
+
+Intent Classification 通常通过 LLM 的 Function Calling 或 Prompt Engineering 实现：
+
+```
+User Message → LLM Intent Classification → Match Intent to Handler → Generate Response
+```
+
+在 [[OpenClaw]] 中通过 AGENTS.md 配置 `Classify intent` 步骤实现。
+
+## Related Concepts
+
+- [[Unified-Inbox]]：意图分类应用于统一收件箱中的每条消息
+- [[Business-Knowledge-Base]]：FAQ 意图依赖知识库检索
+- [[Human-Handoff]]：投诉意图触发人工升级
+
+## Sources
+
+- [[multi-channel-customer-service]]

wiki/concepts/Language-Detection.md

@@ -0,0 +1,51 @@
+---
+title: "Language Detection"
+type: concept
+tags: []
+sources: []
+---
+
+# Language Detection
+
+## Definition
+
+AI 自动检测客户消息使用的语言，并在回复时匹配该语言的能力，是多语言客服场景的基础技术。
+
+## Why It Matters
+
+小型本地服务企业（餐厅、诊所、发廊）的客户群体通常包含：
+- 本地语言用户（ES/EN）
+- 外语用户（旅游客户、跨境客户）
+- 混合语言消息
+
+自动语言检测确保 AI 用客户的语言回复，提升客户体验和响应准确率。
+
+## Implementation
+
+Language Detection 通常在 Intent Classification 之前执行：
+
+```
+Customer Message → [Language Detection] → Identify: EN/ES/UA
+                                          ↓
+                            [Intent Classification] → ...
+                                          ↓
+                            [Generate Response in Detected Language]
+```
+
+## Response Style Guidelines
+
+| Detected Language | Response Style |
+|-------------------|----------------|
+| EN (English) | Friendly, professional, concise |
+| ES (Español) | Amigable, profesional, conciso |
+| UA (Українська) | Привітний, професійний, стислий |
+
+## Related Concepts
+
+- [[Intent-Classification]]：语言检测在意图分类之前执行
+- [[AI-Auto-Response]]：回复语言跟随检测结果
+- [[Multi-Channel-Integration]]：多渠道场景下语言检测尤为重要
+
+## Sources
+
+- [[multi-channel-customer-service]]

wiki/concepts/Streak-Tracking.md

@@ -0,0 +1,57 @@
+---
+title: "Streak Tracking"
+type: concept
+tags: []
+last_updated: 2026-04-17
+---
+
+## Definition
+
+记录用户连续完成某项任务/习惯的天数，并在每次互动中引用该数据以激励用户持续参与的行为改变机制。
+
+## Mechanism
+
+```
+用户完成习惯 → 连续天数 +1 → AI 引用并鼓励
+用户错失习惯 → 连续天数 = 0 → 重置
+```
+
+## Data Storage
+
+OpenClaw 中存储在本地 JSON 文件：
+```text
+~/habits/log.json
+```
+
+数据结构示例：
+```json
+{
+  "morning_workout": {
+    "current_streak": 12,
+    "last_check_in": "2026-04-17",
+    "longest_streak": 21,
+    "total_days": 34
+  }
+}
+```
+
+## Psychological Basis
+
+- **损失厌恶**（Kahneman & Tversky）：用户害怕失去已积累的连续天数，产生"不要断了它"的内在动机
+- **即时可见性**：连续天数是最直观、最即时的成就指标，比抽象的完成率更可感知
+- **社会比较**：连续打卡记录可与他人（或过去的自己）比较，形成竞争激励
+
+## Integration with [[Adaptive Tone]]
+
+Streak 数据驱动 AI 语气策略：
+- 高连续天数（≥7天）：简短有力，例 "Day 12. Solid."
+- 中连续天数（3-6天）：温和鼓励
+- 低连续天数或重置：支持性语气，不打击积极性
+
+## Related Concepts
+- [[Adaptive Tone]] — Streak 数据驱动语气策略
+- [[Active Accountability]] — Streak Tracking 的应用场景
+- [[Check-in Fatigue]] — Streak Tracking 失效的副作用
+
+## Source
+- [[habit-tracker-accountability-coach]]

wiki/concepts/Test-Mode.md

@@ -0,0 +1,37 @@
+---
+title: "Test Mode"
+type: concept
+tags: []
+sources: []
+---
+
+# Test Mode
+
+## Definition
+
+在不影响真实客户和现有系统的情况下，允许代理商或开发者演示、测试 AI Agent 行为的沙盒运行模式。Test Mode 下 Agent 执行完整逻辑，但所有输出仅记录到日志，不发送至真实渠道。
+
+## Core Mechanism
+
+```
+Real User Message → AI Agent → [Test Mode?]
+                               ├── YES: Log response + prefix "[TEST]", DO NOT send to channel
+                               └── NO:  Send response to real channel
+```
+
+## Use Cases
+
+- **代理商演示**：向潜在客户展示 AI 客服的工作效果，无需预先配置真实渠道
+- **配置验证**：验证 AGENTS.md 路由逻辑、知识库覆盖、意图分类准确性
+- **A/B 测试**：对比不同 Prompt 配置的实际回复效果
+- **回归测试**：升级 Agent 版本前验证新版本不破坏现有行为
+
+## Key Features
+
+- 所有响应日志记录可查，便于审计和优化
+- `[TEST]` 前缀标识测试输出，防止与真实回复混淆
+- 完整执行所有业务逻辑（Intent Classification / Knowledge Lookup / Handoff 判断），确保行为一致性
+
+## Sources
+
+- [[multi-channel-customer-service]]

wiki/concepts/Text-and-Search.md

@@ -0,0 +1,52 @@
+---
+title: "Text-and-Search"
+type: concept
+tags: [information-organization, search, retrieval, PKM]
+sources: [second-brain]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+文本与搜索（Text-and-Search）是一种极简信息组织哲学：无需文件夹层级、无需标签系统、无需复杂分类——仅靠自由文本和全文搜索就能实现有效的信息管理和检索。核心论点：所有复杂组织系统的最终目的都可以通过"写下来 + 搜得到"来实现。
+
+## Aliases
+
+- Text-and-Search
+- 文本与搜索
+- 无结构搜索
+- Plain Text + Search
+- 搜索即组织
+
+## Core Argument
+
+传统 PKM 工具（Notion、Obsidian、Roam）的困境：
+- 文件夹层级 → 需要预先规划分类
+- 标签系统 → 需要持续维护标签一致性
+- 双链 → 需要主动建立连接
+
+Text-and-Search 的解法：
+- **写入**：任何格式，随意内容，无需思考结构
+- **检索**：需要时通过搜索找到，无需提前组织
+
+## Mechanism
+
+- **捕获**：自由文本，无需格式化
+- **存储**：AI Agent 记忆系统或全文索引
+- **检索**：全局搜索（Cmd+K）或语义搜索
+
+## In System
+
+- [[Second Brain]] 的核心组织原则
+- 与 Obsidian Dataview（结构化查询）形成对比
+
+## Relationships
+
+- [[Zero-Friction Capture]] — Text-and-Search 允许真正的零摩擦捕获（无需组织）
+- [[Cumulative Memory]] — 累积记忆使搜索变得更有价值（海量历史数据中搜索）
+
+## Contrast
+
+- **[[dataview-让我从“笔记黑洞”里逃出来的-obsidian-神器-1]]**：强调 Obsidian + Dataview 的结构化查询能力，属于"组织优先"
+- **[[Second Brain]]**：强调 Text-and-Search 的极简主义，属于"搜索优先"
+- 两者并非绝对对立：Text-and-Search 适合快速捕获，结构化适合深度关联分析

wiki/concepts/Unified-Inbox.md

@@ -0,0 +1,40 @@
+---
+title: "Unified Inbox"
+type: concept
+tags: []
+sources: []
+---
+
+# Unified Inbox
+
+## Definition
+
+将多个通信渠道的客户消息整合至单一平台进行统一管理和回复的架构模式。
+
+## Core Properties
+
+- **多渠道汇聚**：WhatsApp / Instagram DMs / Email / Google Reviews 等不同渠道的消息统一进入同一个收件箱
+- **去重与合并**：同一客户跨渠道的消息能够关联识别
+- **统一状态管理**：所有消息共享同一个处理状态（待处理 / 处理中 / 已解决 / 已升级）
+- **AI 增强层**：在收件箱之上叠加 AI 自动分类、回复建议和意图识别
+
+## Architecture
+
+```
+[WhatsApp] ─┐
+[Instagram] ─┼──→ [Unified Inbox] ──→ [AI Auto-Response]
+[Gmail]    ─┤         │
+[Reviews]  ─┘         ├──→ [Human Handoff] ──→ [Agent Queue]
+                        │
+                        └──→ [Knowledge Base Lookup]
+```
+
+## Related Concepts
+
+- [[Intent-Classification]]：在统一收件箱内对每条消息进行意图识别
+- [[Human-Handoff]]：AI 无法处理时转交人工
+- [[Multi-Channel-Integration]]：统一收件箱的底层多渠道接入能力
+
+## Sources
+
+- [[multi-channel-customer-service]]

wiki/concepts/Weekly-Pattern-Analysis.md

@@ -0,0 +1,57 @@
+---
+title: "Weekly Pattern Analysis"
+type: concept
+tags: []
+last_updated: 2026-04-17
+---
+
+## Definition
+
+AI Agent 每周汇总用户的习惯完成数据，自动发现隐藏在时间序列中的行为规律，并将发现转化为可操作的下周建议。
+
+## Data Inputs
+
+一周的每日习惯完成记录：
+```json
+{
+  "morning_workout": ["✓", "✓", "✗", "✓", "✓", "✗", "✓"],
+  "read_30min":      ["✓", "✓", "✓", "✓", "✗", "✗", "✗"]
+}
+```
+
+## Analysis Outputs
+
+每周日 10 AM 自动生成结构化报告：
+
+```text
+每周总结报告：
+- 晨练：本周 5/7 天完成，最长连续 5 天
+- 阅读：本周 3/7 天完成，最差日：周五、周六
+- 整体完成率：67%
+- 最佳日：周三
+- 最差日：周五
+
+发现的行为模式：
+- "你总是在有早会的日子跳过晨练"
+- "周五和周六晚上你从不阅读"
+- "喝水习惯在周末断崖式下降"
+
+下周建议：
+- 考虑将周五晚上设为阅读替代时间（如播客）
+- 早会日提前 30 分钟闹钟
+```
+
+## Why It Works
+
+- **自我认知升级**：用户通过数据看到自己未曾注意的行为模式
+- **归因而非自责**：模式发现将"失败"转化为"可优化的行为"，减少内疚感
+- **主动预防**：下周针对性的微小调整（"早会日提前闹钟"）比泛泛的"多努力"更可执行
+
+## Relationship to Other Concepts
+
+- [[Active Accountability]] — Weekly Pattern Analysis 是 Active Accountability 的周期性总结机制
+- [[Streak Tracking]] — Streak 数据是 Pattern Analysis 的主要输入
+- [[Food Sensitivity Tracking]] — 同一模式在健康追踪场景的应用
+
+## Source
+- [[habit-tracker-accountability-coach]]

wiki/concepts/Zero-Friction-Capture.md

@@ -0,0 +1,42 @@
+---
+title: "Zero-Friction Capture"
+type: concept
+tags: [capture, productivity, memory, UX]
+sources: [second-brain]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+零摩擦捕获（Zero-Friction Capture）是一种信息获取设计原则：捕获信息的操作必须像发短信一样简单，任何额外的步骤（打开 App、选择文件夹、添加标签）都会形成阻力，导致用户放弃持续使用。核心公式：**捕获摩擦力 < 遗忘摩擦力** 时，用户才会持续使用。
+
+## Aliases
+
+- Zero-Friction Capture
+- 零摩擦捕获
+- Frictionless Capture
+- 低摩擦信息获取
+
+## Core Principles
+
+1. **即时性**：无需打开专用 App，直接在已有界面（短信/IM）捕获
+2. **无组织**：不需要选择文件夹、标签或分类
+3. **自然语言**：自由文本，无需格式化
+4. **无审查**：不需要判断"这条信息值不值得记录"
+
+## Mechanism
+
+- **Telegram/Discord/iMessage** → 零摩擦接收入口
+- **AI Agent** → 自动分类和存储（后端处理，用户无感知）
+- **对比传统 App**：Notion 需要选择 Workspace/Page/Block，Apple Notes 需要点击保存
+
+## In System
+
+- [[Second Brain]] 的核心设计原则
+- [[Inbox De-clutter]] 同一原则的 Email 场景实现
+- [[custom-morning-brief]] 通过 Telegram 实现零摩擦信息供给
+
+## Relationships
+
+- [[Cumulative Memory]] — 零摩擦捕获使信息量增加，从而增强累积记忆价值
+- [[Conversational Interface]] — 对话界面是实现零摩擦捕获的关键手段