阅读AI回复很累，连续协作消耗精力很快，我用i-have-adhd改善体验的实践

AI 回答了很多，我却读得很累

我一直受到 AI 回复冗余、逻辑不够连贯的困扰。

今天偶然刷 GitHub Trending，我看到了 i-have-adhd。它是一个约束 Coding Agent 回复方式的 Skill，要求 AI 把行动放在前面、减少岔题、把多步任务说清楚，去掉没有必要的开场白和客套话。

这些要求正好对应了我的一部分困扰。我安装之后，确实感觉回复简洁了一些。

原版还有哪些不足，我怎样补充规则

虽然用了原版 i-have-adhd 后回复少了铺垫，但在让 AI 分析 TeamAI 仓库时，我仍然觉得读起来很累：小节和列表把信息分好了，功能之间的关系却需要自己串起来；主流程还没理解，目录、命令、边界情况就已经全部展开。

我的优化方法是：拿这段读起来费力的回复，让 grill-me 逐个追问，把“很累”拆成具体问题，再将回答整理成 rules，补进技能。

于是我在改版中补充了这些约束：

用一个具体场景串起因果关系，从事情发生讲到结果，避免先列完整功能清单。
默认先用 5–8 句话讲清主流程。实现细节、命令和边界情况等追问再展开，只有影响结论的内容才提前说明。
多个相关问题放进同一条流程里回答，最后用一句话确认各个问题的结论。
新概念先用日常语言解释，再补术语；提问的前提有误时，先直接纠正。

这些规则希望让 AI 先帮我建立理解，再按需要增加细节，明确要求完整展开时再展开。

同一个问题，改造前后的回复有什么不同

改完之后，我用同一个问题做了一次对比：两次都使用 GPT-6 Astra，一次没有使用 i-have-adhd，一次使用了改造后的版本。提问是：

https://github.com/Tencent/teamai-cli 阅读这个repo，告诉我这个repo的价值主张是什么，核心功能是什么。我粗略看了一下但是没能完全理解，像是基于git，让团队可以主动通过一些指令如teamai push去管理特殊的一些文件比如skills之类的？还有hooks可以收集对话数据上传到git？这些对话数据怎么处理什么时候处理的？

下面两版都从开头连续展示，保留到数据处理部分，后续内容以省略号截断。仅整理换行、标题和表格格式，并去掉原回复中的来源标记。

没有使用 i-have-adhd

你的理解基本正确，但需要把“配置分发”“使用统计”“经验沉淀”分开。TeamAI 的价值主张是：让一个人调教 AI、解决问题的成果，能被整个团队的 AI 复用。Git 是它的共享存储和审核机制；CLI 负责把共享资源安装到不同 AI 工具里，hooks 负责自动同步、采集使用信号和提示分享经验。当前 README 将知识检索和持续改进两部分标为 beta。

下面以“你用 AI 排查了一次部署故障，同事以后遇到同类问题”为例，串起整个流程。以下依据我读取的 main 代码快照，主要解释 Git 模式。

1. 开始工作前：团队把 AI 的工作方式统一起来。

团队准备一个共享 Git 仓库，保存 skills、rules、文档、agents、hooks、MCP 配置等。成员运行 teamai init <仓库地址> 接入后，TeamAI 会把这些资源转换、安装到各自工具的对应位置，例如 Claude Code、Codex、Cursor 的配置目录。

你改进了一个部署 skill，运行 teamai push，通常会推送分支并创建 PR/MR；审核合并后，同事通过 teamai pull 获取更新。支持相应 hooks 的工具会在会话开始时自动触发 pull。

所以它相对“直接用 Git 管 skills”的主要增量，是跨工具安装适配、自动同步，以及按角色、标签等选择分发资源。

2. 排查过程中：hooks 在本地采集事件，也会读取聊天日志。

这里的 hooks 主要是 AI 工具的事件回调，例如用户提交消息、工具调用完成、AI 停止回复，而不是 Git 的 commit hooks。

实际采集包括：

触发时机本地处理

会话开始记录会话，后台拉取团队资源

用户发送消息记录消息事件，保留 prompt 前 200 个字符

工具执行后记录工具名称；另外统计 skill 使用

AI 停止回复（Stop）如果工具提供 transcript 路径，读取日志统计轮数、token、中断、拒绝工具调用、工具错误等，并提取末次 AI 输出片段

这些事件主要写在本机 ~/.teamai/dashboard/events.jsonl，用于本地 dashboard 和后续汇总。所以不能简单说它“只收集数字”：本地事件中确实有部分文本；但这不等于这些文本都会上传到 Git。Stop 也可能在每次回复结束时触发，不必等到你关闭整个聊天窗口。

3. 数据采集后，有三条不同的处理路线。

路线什么时候处理、由谁处理什么会进入 Git

团队使用统计 teamai pull 时，由 CLI 本地汇总、计算相对上次上报的增量 stats/<user>.yaml：skill 使用次数、会话干预、轮数、token、按日指标等；不是聊天正文

单次会话存档主动执行 teamai session save，由 CLI 将事件折叠成 Markdown，不调用 LLM 默认只存本地；加 –push 才提交到 sessions/<user>/<年-月>.md。默认不含 prompt，另加 –include-prompt 才带脱敏后的首条提问摘要

可复用的经验文档运行 /teamai-share-learnings，由当前 AI 工具中的模型回顾会话、撰写经验 AI 再调用 teamai contribute –file …，提交到 learnings/

特别容易忽略的是：teamai pull 除了下载资源，还会自动上报汇总统计。因为会话开始会自动 pull，所以常见情况是下一次会话开始时，上报此前积累的数据。

你运行 teamai digest 时，CLI 再读取团队仓库中的统计和会话摘要，生成周报；这条流程并不是“服务端定时用 LLM 阅读所有聊天”。

……

触发时机	本地处理
会话开始	记录会话，后台拉取团队资源
用户发送消息	记录消息事件，保留 prompt 前 200 个字符
工具执行后	记录工具名称；另外统计 skill 使用
AI 停止回复（Stop）	如果工具提供 transcript 路径，读取日志统计轮数、token、中断、拒绝工具调用、工具错误等，并提取末次 AI 输出片段

路线	什么时候处理、由谁处理	什么会进入 Git
团队使用统计	teamai pull 时，由 CLI 本地汇总、计算相对上次上报的增量	stats/<user>.yaml：skill 使用次数、会话干预、轮数、token、按日指标等；不是聊天正文
单次会话存档	主动执行 teamai session save，由 CLI 将事件折叠成 Markdown，不调用 LLM	默认只存本地；加 –push 才提交到 sessions/<user>/<年-月>.md。默认不含 prompt，另加 –include-prompt 才带脱敏后的首条提问摘要
可复用的经验文档	运行 /teamai-share-learnings，由当前 AI 工具中的模型回顾会话、撰写经验	AI 再调用 teamai contribute –file …，提交到 learnings/

使用改造后的 i-have-adhd

你的理解基本正确：TeamAI 的基础确实是“用 Git 管理、评审和分发团队的 AI 配置”。它进一步想实现的是：一个人调好的 AI 工作方式、解决问题得到的经验，能被整个团队的 AI 工具复用。但“hooks 把整段聊天上传到 Git，然后后台自动提炼知识”并不是它默认的工作流程。

我读了 README 和关键实现，以下按当前 main 分支（4068f6f）说明。

它的价值主张是什么？

假设你把 Claude Code 调教好了：知道团队的代码规范、会使用某个排障 skill、配置好了内部 MCP。同事用 Codex，仍然要自己配置，也可能重复踩你踩过的坑。

TeamAI 希望把这些个人积累变成团队资产：统一存进共享仓库，再适配、安装到不同成员的 AI 工具里。Git 提供版本历史和评审机制，TeamAI 提供资源识别、工具适配、自动同步与知识复用。

所以我的判断是：它最直接的价值是降低团队维护 AI 工作环境的成本；更进一步的价值是形成“实践 → 经验 → 团队复用”的循环。后面的知识和改进能力，项目自己也标为 beta。

teamai push 到底在做什么？

你说的“管理 skills 等特殊文件”是对的，但它不只是给 git push 换个名字。

成员先用 teamai init 关联一个共享经验仓库。teamai pull 把仓库里的 skills、rules、docs、agents、hooks、MCP 等资源转换、安装到本地 AI 工具对应的位置；支持的工具还会通过会话开始时的 hook 自动执行 pull。

当你改进了本地资源，teamai push 会识别并提交选中的资源，推到共享仓库的分支，并尝试创建 PR/MR。评审合并后，其他成员通过 pull 得到更新。通常这个共享仓库与业务代码仓库分开，也支持放在同一个仓库中的模式。

对话数据怎么处理、什么时候处理？

这里要分清三条流程。

第一条：自动采集与统计。

在你提交提示词、AI 调用工具、AI 停止响应等事件发生时，hooks 会记录本地事件。Stop 触发时，如果工具提供了会话记录路径，还会在本机扫描记录，提取 token 用量、对话轮数、工具错误、用户打断等信息。Stop 是工具的事件，不应理解为只有关闭整个聊天窗口才处理。

这些数据供本地 dashboard 使用。之后执行 teamai pull 时，会把增量统计聚合并上传到团队仓库的 stats/<user>.yaml。因此，pull 除了下载资源，还可能上报统计；会话开始自动 pull，也就可能顺带上报此前积累的数据。这里靠程序解析和聚合，不需要 LLM。

一个需要准确区分的细节：自动上传 Git 的这条统计链路传的是聚合指标，不是完整聊天。但本地采集器确实会保留提示词的前 200 个字符，以及从会话记录读取的最后一条 AI 回复片段。因此，“不上传完整聊天”不能等同于“本地完全不存文本”。

第二条：手动保存会话摘要。

运行 teamai session save 时，它把已有的本地事件折叠成 Markdown 摘要，记录工具使用、轮数、干预次数等；这也不调用 LLM。

默认只存本地。加 –push 才上传到团队仓库的 sessions/<user>/<年-月>.md；上传内容默认是计数和工具名，额外加 –include-prompt 才带上经过脱敏的首个提示词片段。之后运行 teamai digest，程序读取统计、会话摘要等数据生成周报。因此这里的“摘要”主要是结构化活动记录，不是 AI 写的技术复盘。

……

有技能的版本则更多用连续的段落解释“为什么需要它、怎样共享、数据之后去了哪里”，读起来更容易跟住。

相比openai的旧模型，GPT-6 Astra 的表达已经更贴近我的语言理解习惯，但我仍然会觉得信息陈列太多。这次加上技能后，我感觉更省力了。