🎯 学什么：当 AI 问你太多问题（或太少），你可以微调它的提问敏感度——而不是忍受不适的交互体验。通过 question_tuning、explain_level、proactive 三个旋钮，让 AI 学习你的偏好。核心洞察：(1) question_tuning 是学习模式——AI 观察你在哪些问题上秒回"是"，哪些问题上犹豫不决；(2) terse 模式的核心价值是在需要速度的场景减少冗余交互，但涉及不可逆操作时仍坚持提问——"快不以安全为代价"；(3) 调优是跨会话持久化的——保存在 ~/.gstack/config.yaml，AI 越用越懂你。 💡 难易度：⭐⭐ | ⏱️ 预计时间：25 分钟
[!quote]- 📖 原Skill精要 技能名称：plan-tune 核心功能：自调优提问敏感度 + 开发者心理画像。检查各 gstack Skill 中触发过的 AskUserQuestion 提示，设置每个问题的偏好（永不提问/总是提问/仅单向提问），查看双轨画像（你声明的偏好 vs 行为反映的偏好）。 所属体系：gstack 虚拟工程团队 协作关系：作用于所有 gstack Skill 的交互体验——当你说"别再问我这个了"时，它记忆并调整全局提问行为
1. 课程概览
💡 白话小课堂：plan-tune 就像调节 AI 的"主动程度旋钮"。问太多 → 用户感觉在教实习生；问太少 → 用户感觉失去控制。三个旋钮：question_tuning（学习你的偏好）、explain_level（default vs terse）、proactive（是否主动推荐 Skill）。
2. 提问的平衡艺术
The Question Balance
AI Agent 需要在两端之间找到平衡：
问太多： → 每个小决定都要确认 → 用户感觉在教一个实习生 → 打断了工作流
问太少： → 擅自做了不该做的决定 → 用户感觉失去了控制 → 产生了难以撤销的结果
plan-tune 的使命：让用户能调整这个平衡点。
3. 调节机制
Tuning Mechanisms
question_tuning 开关
false（默认）→ 正常提问频率 true → 进入调优模式
在调优模式下： → 每次 AskUserQuestion 后，Agent 会观察用户的反应 → "这个问题问得好" → 这个领域继续问 → 用户跳过或回复很快 → 这个领域少问 → 用户表现出困惑 → 这个领域多问
explain_level
default → 正常解释级别（V1 写作风格） terse → 精简模式（V0 风格，回到极简输出）
proactive
true → AI 主动推荐 Skill false → AI 只在用户明确调用时使用 Skill
🔑 核心秘诀：
question_tuning: true是学习模式——AI 会观察你在哪些问题上秒回"是"，哪些问题上犹豫不决。
4. 调优策略
Tuning Strategies
场景 1：感觉 AI 问太多了
→ 设置 explain_level: terse → 设置 question_tuning: true → 快速跳过低价值问题 → AI 会学会你的偏好
场景 2：AI 擅自做了重要决定
→ 保持 question_tuning: true → 在重要决定上明确表达"你应该问我" → AI 会在类似领域增加提问频率
场景 3：AI 推荐的 Skill 很烦人
→ 设置 proactive: false → 你仍然可以手动调用 /skillname → 只是 AI 不再主动推荐
调优是持久的
→ 设置保存在 ~/.gstack/config.yaml → 跨会话持久化 → 可以用 gstack-config 命令行手动改
5. 结构拆解：AI 交互调优 Skill 模板
AI 交互调优型 Skill 模板
核心特征
→ 管理对象 = AI Agent 的提问频率和交互风格 → 核心原则 = 学习式调优 + 安全底线不可逾越 + 跨会话持久化 → 关键设计 = 三个调节旋钮 + 四种调优场景 + 安全保护机制
通用结构
Three Tuning Knobs（三个调节旋钮）
- question_tuning：观察用户反应 → 学习提问偏好
- explain_level：default（完整解释）vs terse（精简输出）
- proactive：AI 是否主动推荐 Skill
Four Tuning Scenarios（四种调优场景）
- 问太多 → terse + question_tuning
- 擅自决定 → 表达"你应该问我" → AI 学习
- 推荐烦人 → proactive: false
- 持久化 → ~/.gstack/config.yaml 跨会话保存
Safety Floor（安全底线）
- 即使在 terse 模式，涉及不可逆操作时仍坚持提问：
- 数据库删列 / HIGH 级安全 PR / >500 行变更 / Canary 异常
- 核心原理：快不以安全为代价
6. 电商案例：调优大促期间的 AI 交互
🛒 实战案例：双11大促前3天，某电商平台CTO发现智能客服AI机器人（每天处理3万+用户会话）的回复风格出现了问题——大促期间用户咨询主要集中在"优惠券怎么叠加""什么时候发货""退换货规则"三类问题，但AI客服的语气仍然保持日常模式（友好寒暄+"亲~"开场+结尾满意度调查），一次会话平均7轮对话才能解决问题。
plan-tune对AI客服进行了三个维度的调优：
- 语气匹配（conversation_tone）：大促期间用户意图与日常不同——日常用户愿意闲聊"这个口红显白吗"，大促用户的第一句话通常是"优惠券不减钱"或"什么时候发货"——用户已经不耐烦了。基于1000条大促历史会话的情感分析数据，调优方向：检测到用户首条消息含"优惠券/物流/退款"等大促高频词→跳过寒暄直接切入正题；开场白从"亲~有什么可以帮您的？"改为"您好，我是客服助手小艾。您是想了解：1.优惠券使用 2.物流进度 3.退换货 吗？"——首轮即直接三选一。
- 响应精簡度（verbosity）：日常模式每次回复平均85字含客套话。大促模式压缩到40字以内，直接给结论。对比——日常"亲~这款精华液是我们的明星产品呢，含有5%烟酰胺可以帮助提亮肤色blabla"，大促"您的订单已发货，圆通快递YT1234567890，预计11月14日送达。查询物流请点链接。"
- 提问频率（question_tuning）：日常模式下AI确认一次信息后还要追问"还有其他需要吗？"——大促期间多这一轮对话=平均6秒延迟×3万对话=每天浪费50小时用户时间。调优后：问题解决直接结束，"还有其他需要吗？"抑制（用户主动提问时再回答）。同时在每天10:00-12:00和20:00-22:00高峰期，AI自动感知单台服务器会话并发量>500时，自动开启极简模式（每条回复不超过3句话）。
调优结果：A/B测试对比——优化前vs优化后：(1)平均会话轮次从7.2轮降到3.1轮（-57%）；(2)首轮解决率从32%提升到61%；(3)用户满意度从4.1/5提升到4.4/5（用户不喜欢AI废话，大促期间尤其如此）；(4)高峰期服务器CPU负载从78%降到54%（更短的会话=更少的Token消耗）。
🔑 启示：AI交互调优不是"让AI更聪明"，而是"让AI更匹配用户此刻的心理状态"。同一个用户日常和大促是两种心理模式——日常要温度，大促要速度。这就像实体超市——日常收银员可以聊天，但大促期间多一句废话顾客就多排一分钟队。
7. 掌握检验
Q1：plan-tune 中，question_tuning: true 的核心工作机制是什么？
- A) AI 在所有问题上一律不再提问
- B) AI 观察用户对不同问题的反应，逐渐学习只在高价值点提问
- C) AI 将提问频率硬编码为每天 3 次
- D) AI 只在用户明确说"问得好"时才继续提问
Q2：在大促案例中，设置 proactive: false 的原因是什么？
- A) 完全不使用任何 AI Skill
- B) 不让 AI 主动推荐非紧急 Skill（如设计评审），但仍可手动调用
- C) 禁止 AI 进行任何部署操作
- D) 关闭 AI 的所有安全保护
Q3：以下哪种场景最适合设置 explain_level: terse？
- A) 新手第一次学习使用 gstack，需要完整的上下文解释
- B) 代码审查中发现一个复杂的安全漏洞，需要详细分析
- C) 双 11 大促紧急修复支付 Bug，需要最快速度部署
- D) 设计新项目的完整架构，需要仔细权衡每个选择
Q4：在大促案例的调优进化过程中（default → terse → 零确认），AI 学习了 CTO 的哪些具体偏好？请列举至少 3 项。
Q5：为什么即使在 terse 模式下，涉及"数据库迁移删列""安全相关的 HIGH 级 PR""大变更（>500 行）""Canary 发现异常"时 AI 仍然坚持提问？这背后是 plan-tune 设计的什么核心原理？
Q6：大促结束后，你会切换回 default 还是继续用 terse？请从"安全 vs 效率"和"学习积累"两个角度分析利弊。
8. 答案
点击查看答案
Q1：B —— question_tuning 是学习模式，AI 观察用户在哪些问题上秒回"是"（减少提问），哪些问题上犹豫（增加提问）。
Q2：B —— proactive: false 只是静默了主动推荐，不阻止手动调用。
Q3：C —— terse 模式的核心价值是在需要速度的场景减少冗余交互。
Q4：CTO 的偏好包括：①非封网期间不询问封网检查；②小变更（< 50 行）跳过逐个 PR 展示；③不展开详细信息（需要时手动 /detail 查看）；④多次部署后减少确认次数。这些本质上告诉 AI："我的速度优先级 > 你的信息完备性，请在边界清晰的安全范围内信任我的判断。"
Q5：核心原理是"快不以安全为代价"。这些场景的共同特征是不可逆操作或高风险——删列无法 undo、安全漏洞可能已被利用、大变更的连锁影响不可预测、Canary 异常是真实线上故障的前兆。plan-tune 设计了一个安全底线——在任何一个方向都永不被关闭的强制检查点。
Q6：建议切换回 default。大促期间极端的效率需求是暂时的，大促结束后日常开发中"理解上下文 > 速度"，default 模式提供的信息密度和交互程度更适合协作和知识积累。学习积累角度：question_tuning 在 terse 期间积累的偏好是关于"紧急情况"的，回到 default 后这些学习仍有价值。
（5/6 通过）
9. 延伸阅读
- [[L6-08-多模型交叉验证|下一课：多模型交叉验证 —— 让多个AI互相挑刺，找出隐藏的bug]]
评论区
共 0 条评论