专题

机器人与日常自动化

群聊机器人、提醒、日报和消息工具的日常记录。

群聊 插件 提醒
37
文章
3
专栏
4
来源

推荐从这里读

为什么机器人提醒最终落到日历

把提醒写进日历,比只让机器人到点发消息更可靠。

2026-05-29 项目 开始阅读

Reading Path

三步读完这个专题

  1. 1 为什么机器人提醒最终落到日历 把提醒写进日历,比只让机器人到点发消息更可靠。
  2. 2 群聊机器人能直接查到的事,就别急着问大模型 查文件、记忆、知识库、任务和健康状态时,脚本给出结果更稳。模型要不要参与,可以放到后面再说。
  3. 3 多开几个 Codex 会话,不等于真的在协作 试用 codex-governance 后,我发现工作区报告、分派确认、mailbox 回传和状态看板比“多开几个窗口”更重要。
项目 windows-bot-memory/reminder-workflow
为什么机器人提醒最终落到日历
把提醒写进日历,比只让机器人到点发消息更可靠。
1536 字
|
8 分钟
聊天提醒请求经过时间解析后写入日历事件,并在提醒前触发通知的流程示意图
项目 GitLaughs/codex-feishu
群聊机器人能直接查到的事,就别急着问大模型
查文件、记忆、知识库、任务和健康状态时,脚本给出结果更稳。模型要不要参与,可以放到后面再说。
1589 字
|
8 分钟
群聊消息先经过只读命令层查询文件、记忆、知识库、任务和健康检查,再把开放任务交给模型的流程图
项目 GitLaughs/codex-governance
多开几个 Codex 会话,不等于真的在协作
试用 codex-governance 后,我发现工作区报告、分派确认、mailbox 回传和状态看板比“多开几个窗口”更重要。
1996 字
|
10 分钟
Codex 多代理治理面板把工作区报告、分派计划、部门会话和 mailbox 回传串起来的流程图
项目 GitLaughs/codex-governance
codex-governance 独立发布:清理旧语境的边界
从大仓里拆出 codex-governance 独立发布,复制代码不难,难点在于避免旧项目名、私有路径和历史指令误混入。
1402 字
|
7 分钟
codex-governance 独立仓库发布前的本地检查记录
需要想清楚的事 blog-editorial-boundary-review
有些内容值得写,但不该混在普通项目里
机器人自我迭代、私有记忆公开化、真实动作自动化和批量创作都能写,只是要单独放,别装成普通项目流水账。
1760 字
|
9 分钟
争议内容从私有现场经过范围判断、脱敏、草稿检查门和专题归类后进入公开博客的流程图
项目 GitLaughs/daily-open-source-brief
给日报工具加插件时,把改法写进 AGENTS
daily-open-source-brief 后续要加来源、评分、摘要、渲染和投递,把这些约定写清楚,避免每次扩展都重新猜。
1476 字
|
7 分钟
AGENTS 文档把日报系统的新功能约束到 provider、collector、summarizer、renderer 和 sender 插件阶段
项目 GitLaughs/daily-open-source-brief
信息流工具最该抓住的是截止事项
日报除了告诉我今天有什么,还要把报名、申报、考试、答辩这类会过期的事项提出来。
1782 字
|
9 分钟
信息流条目经过截止日期抽取、置信度判断、数据库保存、日报置顶和周报提醒形成行动入口
项目 GitLaughs/daily-open-source-brief
每日简报做下来,最麻烦的是排序
daily-open-source-brief 里去重、打分、反馈降权这些小步骤,最后决定了日报好不好读。
1268 字
|
6 分钟
每日简报系统把采集条目经过去重、基础打分、反馈权重和最后排序后生成日报的流程图
项目 GitLaughs/daily-open-source-brief
每日简报不能因为一个来源挂了就整份消失
daily-open-source-brief 拆成插件以后,我补了失败隔离。GitHub、RSS、网页或投递出错,当天简报也要尽量发出来。
1616 字
|
8 分钟
GitHub、RSS 和网页来源分别采集,失败来源被单独记录,简报继续生成
项目 GitLaughs/daily-open-source-brief
日报工具不能只会每天发一封
我给 daily-open-source-brief 补了本地反馈 CLI:能搜索、收藏、忽略和看来源健康,读完以后下一轮排序才有依据。
1687 字
|
8 分钟
日报工具里搜索、收藏、忽略和来源健康状态影响下一轮内容排序
项目 GitLaughs/daily-open-source-brief
日报做个性化时,我把画像单独隔开
daily-open-source-brief 要记偏好,但 LLM 摘要、用户画像、聊天入口和 provider 存储不能混成一坨。
1613 字
|
8 分钟
日报工具中候选条目、独立用户画像、LLM 隔离摘要和投递渠道之间的范围图
项目 GitLaughs/daily-open-source-brief
我为什么把每日开源简报做成插件化小工具
我想每天少翻几个来源,所以把 GitHub、RSS 和公开网页先收进一个本地日报。
1124 字
|
6 分钟
每日开源简报从采集到投递的流程图
项目 GitLaughs/daily-open-source-brief
日报的信息源要写成配置
GitHub、RSS、网页和本地入口各有各的问题。来源写清楚了,后面的采集、去重和摘要才不会乱。
1459 字
|
7 分钟
日报工具把 GitHub、RSS 和公开网页来源先汇入配置文件,再进入采集、去重、摘要和投递流程
项目 GitLaughs/codex-feishu
群聊里的 AI 助手不该每句话都插嘴
飞书群聊里 AI 助手太吵了。我用双机器人分流、话题隔离和只读索引,让它少插嘴。
1767 字
|
9 分钟
飞书群聊双机器人路由架构示意图
项目 GitLaughs/chatbot-qq/plugins/reminder
群聊值日提醒,轮换规则比话术重要
给 chatbot-qq 做周期提醒时,明确对象、周期、轮换和确认方式,默认降低打扰。
1778 字
|
9 分钟
群聊值日提醒从轮换规则、周期调度、确认回包到少打扰通知的流程图
项目 life-assistant-command-feedback
生活助手的状态回包设计:先确认接收,再返回结果
试用 /today、购物、提醒和学习计划等入口后,重点是先返回接收确认,最后说清楚具体改动。
1738 字
|
9 分钟
生活助手命令从聊天入口、状态回包、确认门、后台处理到结果可清理的少打扰流程图
项目 openclaw-memory/life-assistant-boundary
生活助手的动作分层:模型只整理意图,脚本负责执行
提醒、记录和购物清单这类动作,模型只负责理解和说明,真正落地交给固定脚本。
1687 字
|
8 分钟
生活助手把聊天请求分成提醒、记录、清单和查询,再经过确认门进入确定性脚本的流程图
项目 openclaw-memory/game-timer-reminder
把游戏倒计时变成日历提醒
界面上已经写着下一次可操作时间,无需再靠记忆;截图识别、时间确认和日历提醒串联起来即可。
1351 字
|
7 分钟
网页游戏里的倒计时经过截图识别、时间确认和日历提醒,变成少打扰生活自动化的流程图
项目 windows-bot-memory/maintenance-chain
我给本地记忆补了一次健康检查
补了索引、反思、生命周期和健康检查,不然旧记录越堆越乱,以后按项目查就查不准了。
1155 字
|
6 分钟
本地记忆维护流水线与健康检查示意图
项目 windows-bot-memory/structured-recall
我把本地机器人记忆从每日 Markdown 拆成了几类
整理本地机器人记忆时发现,每天写一个 Markdown 很好落盘,但查旧经验会越来越费劲。后来我把它拆成规则、项目、任务和事实几类来维护。
961 字
|
5 分钟
本地记忆从日记拆成结构化索引的示意图
项目 windows-bot-memory/mission-control
本地助手控制台第一版:只做只读页面
第一版控制台只做了只读页面:健康、任务、待确认、项目、插件、审计。执行入口日后再设计。
1593 字
|
8 分钟
本地只读控制台把健康、任务、待确认、项目、插件、审计和记忆状态汇总到一个仪表盘
项目 GitLaughs/openclaw
接上聊天入口后,我才发现还缺本地工作区
Feishu/Lark 消息能收只是开始。后面的工作区、记忆、命令和自检,才决定这个东西能不能长期跑。
1905 字
|
10 分钟
Feishu Lark 聊天入口经过 cc-connect 进入 OpenClaw 工作区、记忆、命令、插件和运行时健康检查的流程图
项目 operation-memory-boundary-notes
操作记忆可以保存说明,但不能直接拿执行权
本地机器人可以记住做事说明。真正动作还是要走白名单、确认、回执和审计。
1780 字
|
9 分钟
操作记忆作为说明书进入白名单动作层,中间隔着确认、回执和审计的流程图
项目 GitLaughs/chatbot-qq
QQ 群机器人要先把消息分清楚
接入 Codex 后,我用 NapCat、OneBot、路由代理和插件拆消息来源,没有让模型一上来监听所有内容。
1648 字
|
8 分钟
QQ 群机器人从群消息分流到监听、点名和私聊三条任务路由的架构示意图
项目 GitLaughs/chatbot-qq
QQ 机器人发布后,把 CHANGELOG 写成发布回执
QQ 机器人发布以后,把 CHANGELOG 作为发布回执,用来记录插件平台、占位配置、隐私清理和公开包检查。
1606 字
|
8 分钟
QQ 机器人公开发布时,CHANGELOG、隐私扫描、插件测试、占位配置和公开包检查组成审计回执
项目 GitLaughs/chatbot-qq
聊天记录别原样塞给模型
chatbot-qq 里的消息、文件事件、画像更新和错误日志,会被脚本清洗成证据包,再交给模型读。
1949 字
|
10 分钟
聊天机器人把原始 JSONL 清洗成紧凑证据包后再交给模型阅读的流程图
项目 GitLaughs/chatbot-qq
QQ 机器人安装指南要写到第一次跑通
只写安装命令不够。新手第一次部署还要关注依赖、配置、服务启动、健康检查、群内验证和隐私检查。
1780 字
|
9 分钟
QQ 机器人安装从依赖准备、交互配置、服务启动、健康检查、群内验证到隐私检查的首跑流程
项目 GitLaughs/chatbot-qq
聊天机器人做长期记忆,要想清楚什么时候该想起来
看完 chatbot-qq 的记忆升级计划,我觉得第一步不是上向量库,而是排清时效、重要性、相关性和注入阈值。
2290 字
|
11 分钟
聊天机器人记忆从消息记录、显式记忆、排序检索到反思压缩的流程图
项目 GitLaughs/chatbot-qq
群聊机器人想主动说话前,得先学会接话和闭嘴
我更想补会话连续性、反馈记录和少打扰规则。主动参与要能关闭、能解释,也能降级。
2143 字
|
11 分钟
群聊机器人从会话连续性、情绪能量、反馈回路到主动参与的分层流程图
项目 GitLaughs/chatbot-qq
聊天机器人加功能时,我会先写插件清单
新功能不该直接塞进 OneBot 代理。我会先写 manifest,把权限、配置和健康检查定下来,再动手写功能代码。
1522 字
|
8 分钟
QQ 机器人插件从 manifest、权限、配置 schema、hook、health 到本地测试的功能隔离流程图
项目 GitLaughs/chatbot-qq
聊天机器人公开前,我翻了一遍私有数据
chatbot-qq 公开前,我检查了配置、群文件和运行记录,确认哪些不能进仓库,哪些代码和文档可以留下。
1443 字
|
7 分钟
聊天机器人仓库从运行现场经过私有数据审计检查门后进入公开发布区的流程图
项目 GitLaughs/chatbot-qq
QQ 机器人接自然语言任务时,模型只负责整理计划
用户的话会被整理成 spec。后面的校验、追问、确认和执行,交给本地脚本处理。
1940 字
|
10 分钟
自然语言任务从用户目标流向结构化 spec、schema 校验、本地执行器、确认门控和结果回执的流程图
需要想清楚的事 self-iteration-safety-notes
自我迭代机器人,第一步不是让模型自己改代码
我更愿意先把检索、记录、校验这些稳定动作交给代码,再让模型做审查。真要写入,也得看 diff、跑验证、能回滚。
1995 字
|
10 分钟
自我迭代机器人从命令、模型审查、确认、验证到回滚的流程图
实验 windows-bot-memory/simulation-bridge
聊天里跑仿真:把请求收敛为本地任务包
仿真请求变成任务包后,再交给固定 runner。跑完只列成果,确认后再回传,避免一句话变成本机命令。
1872 字
|
9 分钟
仿真请求先进入任务包,再分发到 Vivado、HSPICE、LTspice 固定 runner,最后生成成果清单并等待回传确认
需要想清楚的事 weekly-memory-review
把私有记忆写成博客前,我先分清哪些能写
从本地助手周复盘里找素材时,我会先把私事、运行现场和能公开讨论的工程取舍分开。
2176 字
|
11 分钟
一份本地周复盘经过隐私过滤、工程取舍提炼和公开文章出口的流程图
需要想清楚的事 windows-bot-memory/action-layer
本地助手操作电脑前的动作分级设计
让助手操作电脑之前,先明确哪些动作可以直接执行、哪些必须确认、哪些禁止。
1889 字
|
9 分钟
本地助手执行动作前先判断风险、再决定是否确认的流程图
项目 windows-bot-memory/plugin-manager
本地助手的插件系统,我先做成能力包
codex-windows-bot 第一版插件管理只做 action bundle 的开关、分类、健康检查和能力目录过滤,不急着动态加载代码。
1906 字
|
10 分钟
本地助手插件层覆盖在动作注册表之上,把能力包开关、能力目录、健康检查和固定动作执行连接起来