

大家用 AI 用久了,有没有一种诡异的感觉。
你骂它,它改,你满意,继续。
然后下次,同样的错,重来一遍。
然后你又骂,它又改,你又满意。
这个循环就这样无限持续下去了,好像中了无限月读。
现在我已经忍不了这种事情了。
我现在主要用 Codex,主要是便宜大碗,又经常刷新额度。一方面感叹 OpenAI 才是我亲爹的同时,一边又疯狂骂,怎么这么 XX 呢。

模型是一方面的原因,三傻中就 claude 好用,又贵,折腾半天充值上了,用两天把号又封了,用的提心吊胆的。
后来我发现,还有一个很核心的点。
回忆一下,我们每天是不是会说大量的"不是这样"、"别这么写"、"我说过了",这种话。
那一次你和 AI 激情 BATTLE,大战三百回合,改了六七版,终于把它驯服成功了。AI 写出来的东西你看着顺眼了,那一刻你们俩都很满足。
但这个"成功"只存在于那一轮对话里。
我后来想了想。
这个信息是不是,才是最有价值的。
我们想想看,你主动写下来的那些要求,都是你"想到"的东西。
但你真正的标准,很多时候你自己都说不清楚——直到AI踩上去了,你才知道那里有条线。
比如:
"结尾别这么写,太正式了。"
"你没查我的资料就直接做了。"
"这个逻辑是对的,但不是我说话的方式。"
这些话,你在写什么风格指南、提示词的时候,绝对写不出来。
你的标准,很多时候你自己都说不清楚,直到 AI 违反了,你才知道。
靠,这可不行。
更何况,我们很多人其实也懒得写很详细的 skill、提示词,或者说什么狗屁 harness 工程。
所以这样想:风格指南写的是你以为你是谁,纠偏记录写的才是你真正是谁。
这些内容加上当时的背景信息,是不是高标准、高质量的执行要求?
如果能把它们收集起来,让 AI 做归因分析,最后迭代进记忆和 SKILL,是不是比手动维护提示词更有效?
实在太可惜它们就这么消失了。
大家需要了解一个名词,叫 Session。

官方解释是,一段连续工作的“上下文现场”。说白了就是聊天记录,里面包括对话记录和执行的命令等等。
如果是用现在的 agent,Claude Code、codex、cursor 等,这个都会保存在本地。
Codex 的在这里:
~/.codex/sessions/YYYY/MM/DD/
Claude Code 的在这里:
~/.claude/projects/你的项目/
聪明的你肯定想到了,那这个聊天记录是不是可以二次被 AI 利用呢。
答案肯定是可以的,而且应该被利用。
举几个例子,我们每天干了什么任务、流程(SOP)大概什么样、哪些是卡点,你平常不在意的点,是不是都能分析出来。
所以现在的很多 agent 都会拿这个做文章。比如 openclaw 的做梦,比如爱马仕的生成新技能的链路。
总而言之是我们迭代 AI 很重要的一环。
里面的内容很多,大家感兴趣可以留言催更,留下自己感兴趣的点。
我们今天讲讲怎么提取我们纠偏 AI 的信息。
每个 session 都是一个 json 文件,里面包含了很多信息。
包括你说了什么、AI 回了什么、用了哪些工具、执行了哪些命令。
但有一个问题:里面 95%都是你不需要的东西。
工具调用记录、系统注入的上下文、AI 的 thinking 过程……全是噪音。
一个 session 文件可能有几万行,你真正需要的对话部分,大概就 5%。
把整个文件塞给 AI?它撑得住,你的钱包也撑不住。
第一步:让 AI 写脚本,把 session 提炼成干净的对话
所以第一件事,是把每天的 session 文件提炼成干净的 markdown 文本,只保留你和 AI 真正说了什么。
这个脚本不用自己写,直接让 AI 帮你写,把需求告诉它:
请写一个 Python 3 脚本,把本机 AI 助手的 session / transcript JSONL 文件批量转换成干净的 Markdown 对话文件。
目标:
从原始 JSONL 会话文件中提取真正的人类用户与 AI 助手对话,过滤运行元信息、系统提示词、工具调用、事件日志和调试信息。不要总结,不要改写,只做结构化清洗和导出。
输入:
脚本需要支持通过参数传入一个或多个输入目录,例如:
--input ~/.codex/sessions
--input ~/.codex/archived_sessions
--input ~/.claude/projects
脚本递归扫描这些目录下的 .jsonl 文件。
输出:
通过参数指定输出目录:
--output ./conversations
每个 session 输出一个 Markdown 文件,文件名格式:
YYYY-MM-DD_.md
如果无法识别日期,则使用:
unknown-date_.md
提取规则:
1. 对于 Codex 风格 JSONL:
- 每行是一个 JSON 对象。
- 只处理 type == "response_item" 的记录。
- 只保留 payload.type == "message"。
- 只保留 payload.role 为 "user" 或 "assistant" 的内容。
- 从 payload.content 中提取文本字段,兼容:
- content 为字符串
- content 为数组
- 数组元素中 type 为 "input_text"、"output_text"、"text" 的 text 字段
2. 对于 Claude 风格 JSONL:
- 每行是一个 JSON 对象。
- 读取 message.role。
- 只保留 role 为 "user" 或 "assistant" 的内容。
- 从 message.content 中提取文本,兼容字符串和数组文本块。
3. 必须过滤以下内容:
- session_meta
- event_msg
- turn_context
- tool call
- tool result
- image generation call
- 系统提示词
- 开发者提示词
- 环境上下文
- AGENTS.md / INSTRUCTIONS 注入内容
- 命令输出、debug 日志、任务通知
4. 必须做基础脱敏:
- Bearer token
- sk-* API key
- OPENAI_API_KEY
- ANTHROPIC_API_KEY
- 其他明显的长 token 或密钥字符串
Markdown 输出格式:
# YYYY-MM-DD HH:MM Session
---
**User:**
用户消息内容
---
**Assistant:**
助手消息内容
要求:
1. 保留原始对话顺序。
2. 空会话不要输出文件。
3. 支持 --overwrite 参数;没有该参数时,如果目标文件已存在则跳过。
4. 输出最终统计:
- scanned
- written
- unchanged
- skipped
- empty
- errors
5. 单个 JSONL 文件解析失败时,不要终止整个任务,只记录 errors 并继续处理其他文件。
6. 只使用 Python 标准库,不要引入第三方依赖。
7. 代码要包含清晰的函数拆分,例如:
- discover_jsonl_files
- extract_codex_session
- extract_claude_session
- clean_text
- redact_secrets
- write_markdown
- main
8. 最后给出使用示例,例如:
python3 export_ai_sessions.py \
--input ~/.codex/sessions \
--input ~/.codex/archived_sessions \
--input ~/.claude/projects \
--output ./conversations \
--overwrite这会创建一个脚本,固定提取你的 session 成 MD 文件。
还可以做成定时任务,每天晚上 11 点自动跑,第二天直接有现成的材料。定时任务配置也让 AI 帮你写。

可以用下面这段提示词。
基于刚才的 session-to-markdown 导出脚本,帮我创建一个每日自动任务。 要求: 1. 每天本地时间 23:30 自动运行一次全量导出。 2. 使用项目里的导出脚本和默认输入/输出配置。 3. 如果支持内置 recurring automation,就直接创建;否则按当前系统创建等价定时任务。 4. 创建后立刻手动运行一次,确认真的生成或更新了 Markdown 文件。 5. 最后只汇报:任务名称、运行时间、脚本路径、输出目录、本次运行统计、抽查文件。
第二步:让 AI 从对话里抽出纠偏内容
有了干净的对话文本,下一步是让 AI 专门扫一遍,找出你纠正它的地方。
什么算纠偏?简单来说几类:
- 用户否定 AI 的句子
- 用户明确指出哪里不对的句子
- 用户要求以后必须怎么做。
- 用户要求以后不要怎么做。
- 用户补充了稳定偏好、工作方式、流程要求或验收标准。
- 用户指出“这次任务里真正重要的东西是什么”。
- 用户纠正 AI 对上下文、文件、路径、范围、任务边界的误解。
这些都可以归为我们纠偏了 AI 的行为,都是有价值的。
当然还有一些其他的基础要求。
一是优先级判断。
这条规则是一次性的还是永久的?永久的话,是全局都适用,还是只在某类任务里?
二是来源文件。
要能定位到原始的 session 文件,最好精确到第几轮对话。有时候你想回去看当时的完整上下文,没有来源就找不到。
三是场景。
提取的内容要包括用户的原话、当时的场景。没有这个,AI 根本不知道当时发生了什么,这条记录等于无用。
大家也可以补充其他的,然后让 AI 帮忙完善一下提示词。
基于当天导出的 session-to-markdown 对话档案,生成一份“当日全量纠偏 Markdown”。 目标: 读取当天所有 Markdown 会话文件,提取当天出现的全部纠偏信号。这里的“全量”指当天全量,不是历史全量。输出必须保留每条纠偏对应的原始会话片段和背景,方便之后人工复查和追溯。 输入: 读取 conversations/ 目录中当天的 Markdown 文件,例如: conversations/YYYY-MM-DD_*.md 输出: 写入: correction_reviews/YYYY-MM-DD_全量纠偏.md 只提取这些内容: 1. 用户明确指出 AI 哪里不对。 2. 用户否定 AI 的理解、判断、做法或输出。 3. 用户要求以后必须怎么做。 4. 用户要求以后不要怎么做。 5. 用户补充了稳定偏好、工作方式、流程要求或验收标准。 6. 用户指出“这次任务里真正重要的东西是什么”。 7. 用户纠正 AI 对上下文、文件、路径、范围、任务边界的误解。 不要提取: 1. 普通聊天。 2. 单纯任务指令,除非里面包含稳定偏好或纠偏。 3. AI 自己的解释、道歉、总结。 4. 没有用户原话支撑的推断。 5. 需要原始工具日志才能确认、但对话里没有证据的工程因果。 每条纠偏必须包含: - 纠偏标题: 用一句话命名这条纠偏。 - 优先级: 高 / 中 / 低。 高:以后马上应该改变 AI 行为。 中:可能有长期价值,但需要继续观察。 低:偏一次性、局部场景或弱信号。 - 来源文件: 写明对应 Markdown 文件路径。 - 来源位置: 如果能定位到标题、会话 ID、轮次编号或附近分隔段,就写出来。 如果没有行号,也要写“文件内第 N 条纠偏附近”。 - 原始会话背景: 引用这条纠偏前后最相关的原始对话片段。 至少包含: 1. 用户纠偏原话。 2. 如果 Markdown 中能看到 AI 前一条回复,也要包含 AI 前一条相关回复。 3. 必要时包含用户前一条任务要求,帮助理解场景。 - 用户原话: 必须逐字引用用户纠偏句,不要改写。 - 问题场景: 这句话在纠正什么场景,用 1-2 句话说明。 - 可执行规则: 把用户纠偏转成以后 AI 可以执行的规则。 规则必须具体,不要写“提高质量”“更准确”这种空话。 - 禁止动作: 明确以后不要做什么。 - 适用范围: 说明这条纠偏应该沉淀到哪里: 全局记忆 / 项目记忆 / Skill 或工作流 / 暂不沉淀。 判断标准: - 全局记忆:跨项目、跨任务都应该长期生效的行为偏好或规则。 - 项目记忆:只适用于当前项目、当前客户、当前仓库或当前工作上下文的规则。 - Skill 或工作流:适用于某个固定任务流程、工具流程、内容流程或自动化流程的规则。 - 暂不沉淀:只适用于这一次对话,或证据不足,先保留观察。 - 是否建议沉淀: 是 / 否 / 观察。 - 建议沉淀位置: 全局记忆 / 项目记忆 / Skill 或工作流 / 暂不沉淀。 Markdown 结构: # YYYY-MM-DD 全量纠偏 ## 今日结论 用 1-3 句话说明今天的纠偏主线是什么,不要总结全天任务。 ## 统计 - 读取会话文件数: - 发现纠偏总数: - 高优先级: - 中优先级: - 低优先级: - 建议沉淀: - 建议观察: - 不建议沉淀: ## 高优先级纠偏 ### 1. 纠偏标题 - 来源文件: - 来源位置: - 优先级: - 适用范围: - 是否建议沉淀: - 建议沉淀位置: #### 原始会话背景 > **User:** > 用户前一条任务或纠偏原话 > > **Assistant:** > AI 前一条相关回复 > > **User:** > 用户纠偏原话 #### 问题场景 #### 可执行规则 #### 禁止动作 --- ## 中优先级纠偏 按同样格式输出。 --- ## 低优先级纠偏 按同样格式输出。 --- ## 今日不沉淀但保留观察 列出看起来像纠偏、但暂时不应该写进长期规则的内容。 每条包含: - 来源文件 - 用户原话 - 不沉淀原因 要求: 1. 必须读取当天所有 conversations/YYYY-MM-DD_*.md 文件。 2. 必须保留原始会话背景,不能只输出总结。 3. 每条必须能追溯到具体 Markdown 文件。 4. 不要编造行号;如果没有可靠行号,就用会话 ID、标题或“第 N 条纠偏附近”。 5. 不要把 AI 的自我解释当成用户纠偏。 6. 不要为了凑数量提取普通任务指令。 7. 如果当天没有纠偏,仍然生成文件,写明“今日未发现有效纠偏信号”,并保留读取文件数。
这样就算完成了,当然也可以做成定时任务。
基于刚才的“当日全量纠偏 Markdown”提示词和当天 session-to-markdown 输出,帮我创建一个每日自动任务。 要求: 1. 每天本地时间 00:00 运行。 2. 读取当天的 conversations/YYYY-MM-DD_*.md。 3. 生成 correction_reviews/YYYY-MM-DD_全量纠偏.md。 4. 每条纠偏必须保留原始会话背景,并能溯源到具体 Markdown 文件。 5. 如果支持内置 recurring automation,就直接创建;否则按当前系统创建等价定时任务。 6. 创建后立刻手动运行一次验收,确认纠偏 Markdown 文件真实生成。 7. 最后只汇报:任务名称、运行时间、输入目录、输出文件、本次读取文件数、提取纠偏数、抽查结果。
最后我们来看看生成的效果。
生成了三十多条纠偏。然后我们就可以把其中有价值的沉淀到记忆中。


我们最后来回顾下流程,其实就三步:
- 把原始 session 清洗成干净对话 Markdown。
- 每天让 AI 从 Markdown 里提取纠偏。
- 人再决定哪些纠偏沉淀进记忆或 Skill。

还有一点要提醒大家的,就是总结这个步骤要消耗大量的额度,如果你不是 codex pro 套餐,大家完全可以选择便宜模型做总结这一步,比如GPT 5.4mini。
甚至你可以直接开一个国产模型的 code 套餐,比如 minimax 的就很便宜,完全够用。
归因和总结这个步骤,不需要最强的模型。
让你的 gpt 去调用 mini max 的接口,去做总结,岂不快哉。
上面说的是怎么把纠偏内容提取出来。
但这些数据还能做一件更有价值的事。
现在很多执行规则都写在 SKILL 里面。SKILL 多了之后,维护是个问题——哪个写错了?哪个不够用了?大多数时候全靠感觉改,改完也不知道有没有用。
人都累岔劈了。
但如果有了纠偏数据,可以多问一个问题:
AI 犯这个错的时候,它调用的是哪个 SKILL?
如果能把"这次犯的错"和"当时激活的 SKILL"对应起来,你就知道该改哪里了。不是靠猜,是有证据的修。
比如 AI 写内容风格又跑偏了,你骂了它,同时知道它当时走的是"内容生产"这个 SKILL——那问题大概率就在那个SKILL的描述里,直接去改那里。改完,下次同类任务再看有没有改善。
这条链路打通之后,SKILL 的迭代就不再是"感觉哪里不对就改哪里",而是有数据支撑的定向维护。
我们不可能像做版本管理一样手动盯几十个 SKILL,但纠偏数据可以告诉你哪个最需要动。
感兴趣的可以留言讨论下。
复制本文链接 文章为作者独立观点不代表优设网立场,未经允许不得转载。









发评论!每天赢奖品
点击 登录 后,在评论区留言,系统会随机派送奖品
2012年成立至今,是国内备受欢迎的设计师平台,提供奖品赞助 联系我们
UI设计精品必修课
已累计诞生 792 位幸运星
发表评论 为下方 3 条评论点赞,解锁好运彩蛋
↓ 下方为您推荐了一些精彩有趣的文章热评 ↓