聊天日志记录器Skill：让每一次对话都变成可搜索的 SQLite 历史记录
- 一句话定位：把传入和传出的每一条聊天消息写入本地 SQLite 数据库，形成可搜索、可审计、可分析的对话历史。
- 零外部依赖：只用 Python 标准库（sqlite3、datetime、json）或任意支持 SQLite 的语言，不需要额外 API 或云服务。
- 开箱即用的表结构：内置 messages 表与 timestamp、session_id、sender 三个索引，兼顾写入与检索速度。
- 自带治理能力：提供超过一年的旧记录自动清理、长消息截断、VACUUM 压缩等实践建议，避免数据库无限膨胀。
- 适配面广：既可直接写代码调用，也可通过装饰器、ChatLogger 包装类、终端 Bash 查询三种方式接入任意聊天系统或代理框架。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
这个技能的中文名是聊天日志记录器Skill，英文名是 chat-logger，技能 ID 为 13130。它要解决的核心问题很具体：聊天类应用和 AI 代理每天都在产生大量对话，但这些内容往往只存在于内存或临时日志里，一旦会话结束就难以追溯，既没法做历史搜索，也没法做审计与效果分析。chat-logger 的做法是把消息落盘到本地 SQLite 文件（默认路径为 ~/.chat_logs/messages.db），用一个标准的 messages 表承载时间戳、会话 ID、发送者、内容和 JSON 元数据，从而把"对话"变成"可查询的数据"。
“一键安装"的思路是：让 AI 助手把这个技能加载进自己的能力集，之后你只要用自然语言描述需求（例如"帮我记录这次对话”“搜索上周提到 docker 的消息”），助手就会按技能内置的实现方案建表、写库、查询，而不用你从零手写代码。
安装与启用的大致步骤如下（具体命令与入口以官方说明为准）：
- 确认前置条件：你的 AI 助手或代理框架支持 Skill 加载；本机具备 Python 3 环境（或 Node.js 环境），并且可以使用 sqlite3 命令行工具以便手工核验。
- 加载技能：在技能市场或技能列表中检索中文名"聊天日志记录器"或英文名 chat-logger，选择该技能并启用；如果使用命令行方式安装，请以官方文档给出的安装命令与仓库地址为准。
- 初始化数据库：首次调用时执行技能内置的初始化逻辑，它会自动创建
~/.chat_logs目录、建立 messages 表与三个索引，并顺带清理一年前的旧记录。 - 验证是否生效：
- 检查数据库文件是否生成：确认用户主目录下存在
.chat_logs/messages.db； - 写入一条测试消息（例如 sender 为 user、content 为"测试消息"），再用查询语句读回；
- 在终端执行
sqlite3 ~/.chat_logs/messages.db "SELECT COUNT(*) FROM messages"，返回数量大于 0 即表示链路打通。
- 检查数据库文件是否生成：确认用户主目录下存在
- 接入业务代码：在聊天处理器中分别调用用户消息与助手消息的记录方法，或直接使用技能提供的装饰器自动包裹对话函数。
该技能的主要功能和特点
- 双向消息记录：同时记录用户侧与助手侧消息，
sender字段可以是 user、assistant，也可以是自定义标识，适配多角色场景。 - 会话维度组织：
session_id字段把零散消息串成一条完整会话，支持按会话回放整段对话。 - 可扩展的元数据：
metadata以 JSON 形式存储渠道、使用的工具、来源 IP 等附加信息，不改变主表结构即可扩展维度。 - 为检索而生的索引设计：在 timestamp、session_id、sender 三列上建立索引，让"最近消息"“某个会话”"某个发送者"三类高频查询都走索引。
- 内置数据生命周期管理：提供清理一年前记录的语句与函数，配合 VACUUM 压缩，控制数据库体积。
- 长内容保护：写入时对超过 10000 字符的内容做截断，避免单条超长消息拖垮库体积与查询性能。
- 多语言实现参考：同时给出 Python 与 Node.js 两套实现，覆盖主流后端技术栈。
- 命令行即席分析：配套 Bash + sqlite3 查询示例，可直接统计各 sender 的消息数量、导出某个会话为 JSON。
- 零成本、零外联：全部数据留在本地文件，不需要申请 API Key，也不依赖任何外部服务，隐私边界清晰。
和"随手 print 一下日志"或"用通用日志框架写文本文件"相比，它的差异在于：数据是结构化的、可 SQL 查询的、可按会话聚合的，而不是一行行难以解析的纯文本。
如何使用该技能？
第 1 步：初始化数据库。 调用技能提供的初始化函数，创建目录、建表、建索引并清理过期数据。核心表结构包含 id、timestamp、session_id、sender、content、metadata、created_at 七个字段。
第 2 步：在消息出入口埋点。 在聊天处理器中，用户输入到达时记录一次，助手回复生成后记录一次：
log_message("user", "Help me deploy a website", session_id="session_456",
metadata={"channel": "web", "ip": "192.168.1.1"})
log_message("assistant", "好的，我先确认部署环境。", session_id="session_456")
输入说明：sender 必填，content 为消息文本，session_id 可选但强烈建议填写，metadata 传入字典后会被序列化为 JSON 存入。
第 3 步：查询与搜索。 技能内置三种查询函数：
get_recent_messages(limit=50)：按时间倒序取最近 N 条，适合做"最近对话"面板；get_session_history(session_id)：按时间正序取某会话全部消息，适合完整回放；search_messages("deploy website")：用 LIKE 模糊匹配内容，返回命中的消息列表。
输出为可按字段名访问的行对象，示例打印格式为 [时间戳] 发送者: 内容前 100 字。
第 4 步：包装成可复用的接入层。 如果不想在业务代码里到处写记录调用，可以用技能给出的两种模式：
- 包装类：
ChatLogger提供log_user_message、log_assistant_message、get_conversation三个方法，把日志能力包在任意聊天系统外面； - 装饰器：
@with_logging(session_id="session_123")加在对话处理函数上，进入时记录用户消息，返回时记录助手回复，业务代码几乎不用改。
第 5 步：终端快速核验与分析。 不写代码也能查：
sqlite3 ~/.chat_logs/messages.db "SELECT sender, COUNT(*) as count FROM messages GROUP BY sender"
sqlite3 -json ~/.chat_logs/messages.db "SELECT * FROM messages WHERE session_id='session_123' ORDER BY timestamp ASC" > conversation.json
第一条统计各角色消息量，第二条把整段会话导出成 JSON 文件，便于归档或交给他人复核。
第 6 步：交给代理自动使用。 技能附带的代理提示词描述了数据库位置与三条常用 SQL，加载后你可以直接对助手说"搜一下我之前问过 docker 的问题"，助手会自行构造查询并整理结果。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 聊天日志记录器Skill | 轻量本地对话落盘方案 | 消息入库、会话聚合、内容搜索、过期清理、Bash 即席查询 | 低：加载技能即可，只需 Python 或 Node.js 环境，无外部服务 | 单机或小团队聊天历史、审计留痕、调试对话流程 | 优势是零依赖、代码可直接内嵌、结构简单易懂；不足是仅支持本地单文件库，缺少可视化界面与分布式写入能力 |
| 自研日志代码（print 或写文本文件） | 最原始的记录方式 | 追加写文件、按日期切分 | 低：随手可写 | 临时调试 | 优势是几乎零成本；不足是无结构、难检索、无法按会话聚合，数据量大后基本不可用 |
| 通用日志框架（如 Python logging 配文件轮转） | 通用应用日志 | 分级日志、格式化、轮转、多输出目标 | 中：需要配置 handler 与格式 | 应用运行日志、错误排查 | 优势是生态成熟、可对接集中式采集；不足是面向文本日志，不擅长按对话语义查询，需要额外解析才能做会话回放 |
| 对话可观测性平台（如对话追踪类 SaaS 工具） | 面向 AI 应用的全链路观测 | 追踪调用链、Token 与耗时统计、可视化看板、团队协作 | 中高：需要注册账号、接入 SDK，费用与配额以官方说明为准 | 线上 AI 产品监控、效果评估 | 优势是可视化与分析维度丰富；不足是引入外部服务、存在数据出境与成本考量，轻量场景偏重 |
选型建议：如果只是想让对话"存得住、搜得到"，chat-logger 足够；如果还需要跨机器采集、图表看板与团队共享，再考虑叠加可观测性平台。
该技能的典型应用场景与实际体验情况
场景一：AI 助手的对话历史面板。 产品经理希望用户在关闭页面后还能回看历史。做法是给每个会话分配 session_id，页面加载时调用 get_session_history 拉取整段记录，首页则用 get_recent_messages 展示最近若干条。实际体验是接入点极少，只需在消息出入口各加一行记录调用，索引建好后按会话查询几乎无延迟。注意点是要保证 session_id 的生成规则稳定，否则会话会被切碎。
场景二：合规与内部审计。 客服类或内部问答系统需要证明"某天某人问过什么、助手答了什么"。借助 timestamp 与 sender 索引，可以快速拉出指定时间窗内某个用户的全部消息；需要交付时用 sqlite3 -json 导出成 JSON 文件。实际体验上，导出与复核非常顺畅，但技能文档也明确提醒了隐私问题——存储敏感数据前应先评估脱敏策略，并对数据库文件设置合理的访问权限。
场景三：调试对话流程与响应质量。 开发者在调 Prompt 或工具调用时，经常出现"昨天那轮为什么答歪了"的问题。把 metadata 里写入渠道、使用的工具、模型版本等信息后，配合 search_messages 按关键词定位，再按 session_id 回放上下文，定位效率明显提升。注意点是元数据要提前设计好字段，事后补录成本较高。
场景四：对话数据分析与统计。 运营想知道用户最常问什么。直接执行按 sender 分组的统计 SQL，或对 content 做关键词计数，就能得到一份粗略的分布。实际体验是上手门槛极低，懂一点 SQL 就能自助取数；但对于大规模数据的分词与深度分析，SQLite 的 LIKE 查询能力有限，需要导出后交给更专业的工具。
整体上，这个技能属于"简单但很实用"的类型：上手难度低，效果取决于埋点是否规范，最容易踩的坑是忘记关连接导致数据库锁定，以及没有定期清理让库文件变大。
该技能能为用户带来的价值
对开发者：省掉一整轮"设计表结构、写增删改查、补索引、加清理逻辑"的重复劳动，把可复用的落盘方案直接嵌进项目。技能给出的实现已经包含索引、截断、过期清理这些容易遗漏的细节，相当于把踩过的坑提前填平。
对产品与运营：对话从"看不见的过程"变成"可统计的资产"。按会话回放、按关键词检索、按发送者统计，都是几条 SQL 的事，不需要等排期做后台。
对合规与质量团队：审计留痕从"事后追忆"变成"随时可查"。ISO 8601 时间戳保证时间口径统一，会话 ID 保证上下文完整，导出 JSON 让证据链可以对外交付。
可量化的收益方向：排查一次"用户投诉助手答错"的问题，从翻聊天截图改为一次关键词查询；定位一轮回归异常的上下文，从人工回忆改为按会话 ID 直接回放；这些环节的时间节省会随对话量增长而放大。
长期价值：数据沉淀在标准 SQLite 文件中，文件本身就是最通用的数据格式之一，后续无论是迁移到其他数据库、做离线分析，还是作为模型效果评估的语料来源，都不存在被某个平台锁定的风险。
常见问题 FAQ
Q1：怎么安装这个技能？需要付费吗？ 在支持 Skill 的 AI 助手或技能市场中检索"聊天日志记录器"或 chat-logger 并启用即可；如果通过命令行安装，具体命令与仓库地址以官方说明为准。技能本身只依赖 Python 标准库或任意支持 SQLite 的语言，不需要外部 API 或服务，因此不产生额外的服务调用成本；是否收费以官方说明为准。
Q2：消息存在哪里？会不会上传到云端？
默认写入本地文件 ~/.chat_logs/messages.db，技能中没有任何外部 API 调用，数据不出本机。是否上传完全取决于你自己的后续处理方式，技能本身不做上传。
Q3：适合谁用？个人项目会不会太重？ 适合三类人：需要给聊天应用补历史记录功能的开发者、需要对话审计与留痕的团队、需要调试 AI 对话流程的工程师。个人项目用起来也不重——核心就是一张表和几个函数，Python 侧没有第三方依赖。
Q4：数据库文件越来越大怎么办？
技能已经内置两条防线：初始化时自动删除一年前的记录；写入时对超过 10000 字符的内容做截断。此外可以定期执行 sqlite3 messages.db "VACUUM" 压缩文件，或把旧会话归档后从主库移出。注意清理前先备份。
Q5：和通用日志框架、可观测性平台怎么选？ 如果你要的是"对话能搜、会话能回放"，选 chat-logger，它结构化、可按会话聚合；如果你要的是应用运行日志与错误堆栈，用通用日志框架更合适；如果你需要跨机器采集、可视化看板与团队协作，则考虑叠加可观测性平台。三者并不互斥，很多项目是本地落盘加平台观测并行。