tybiefh-beep self-evolving-prompt-system
触发条件
已积累足够交互历史(建议 20+ 次对话),需要让系统根据用户实际使用模式自动优化 SYSTEM_PROMPT 时使用。AI 观察历史对话中的修正行为、用户反馈、重复指令,生成改进版 prompt 草稿,用户审阅后确认回写,形成迭代闭环。
反触发(不适用)
- 交互历史不足时(建议 20+ 次有效对话)效果差,不应提前启用
- 用户对 prompt 有强烈手动控制偏好时不适用
- 任务高度多样化、没有稳定模式时(强行优化反而引入噪音)
- 涉及合规/医疗/法律等领域(prompt 改动需人工审计)
Gotchas(易错点)
- 自动优化可能引入偏见 → 用户的"修正"是主观的,如果只听用户的,会过度拟合一两个人的偏好
- 回滚困难 → 改坏后回滚必须有版本历史,不能只存"当前版"
- diff 展示不直观 → 改了什么对用户不透明;必须高亮显示新增/删除/修改
- 优化频率太快会震荡 → 每周最多 1 次自动提议,频繁提议让用户疲劳
- 评估指标单一会误导 → "用户修正频率"作指标,但用户不修不一定满意(可能懒得修)
- prompt 改动有连锁反应 → 改 SYSTEM_PROMPT 可能影响所有任务,不能只看 1 个任务的反馈就改全局
- 没"维持现状"选项 → 提议后必须能"拒绝 + 给出拒绝原因",AI 才能学习不该改什么
- 优化建议可能"作弊" → 把用户"修过的话"原样抄进 prompt,导致 prompt 越来越长越来越碎
覆盖操作(必须支持)
- 历史对话行为分析 prompt(识别用户偏好模式:常用术语/避用词/常用格式)
- prompt 差异对比 UI(当前版 vs 建议版 diff 展示,逐行高亮)
- 用户审阅 → 局部修改 → 版本保存的交互流程
- prompt 版本历史管理(支持回滚到任意版本)
- 效果评估指标(用户修正频率是否下降 + 用户满意度评分)
- 优化建议的"撤销/拒绝/接受"三态
- 建议理由说明(AI 必须说"为什么改这条")
工作流(分阶段)
1. 立项
- 决定分析维度(常用术语 / 偏好格式 / 重复指令 / 修正模式)
- 决定建议频率(周/双周/月)
- 决定评估指标(用户修正频率下降 / 满意度评分 / 任务成功率)
2. 数据收集
- 每次对话结束:记录"用户修正了 AI 哪些输出"+"用户主动补充的偏好"
- 每周聚合:统计"重复出现 ≥ 3 次的修正模式"
- 每月产出:1 份"待优化点清单"喂给 AI
3. AI 提议
- 输入:历史修正 + 当前 prompt + 评估指标
- 输出:改进版 prompt + diff + 改动理由(每条)
- 不允许"全量替换",只能"局部微调"(改动行 ≤ 20%)
4. 用户审阅
- 三态:接受 / 拒绝(并写理由) / 局部修改后接受
- 所有审阅结果回写,作为下一轮优化的训练信号
- 接受后版本号 +1,旧版本存档
5. 评估
- 优化后跑 N 个固定任务,看修正率变化
- 修正率不降 = 优化有效;升 = 优化失败,自动回滚
- 每月发报告:本月优化几次,接受率,效果变化
交付清单(checklist)
- 修正行为自动捕获
- AI 提议带 diff + 理由
- 局部修改 UI(可逐行编辑建议)
- 版本历史 + 一键回滚
- 评估指标(修正率 / 满意度)
- 优化失败自动回滚
- 拒绝理由记录(AI 学习)
- 月度报告(优化效果汇总)