| name | Geek-skills-xuefeng-method |
| version | 1.0.0 |
| description | 雪峰式AI-Native产品开发方法论。适用于：(1) 用户行为开放、不可穷举的AI-native产品（AI日历、AI助手、AI推荐、对话式产品等），(2) 强模型依赖型场景，AI驱动核心决策而非仅辅助，(3) 多专精Agent架构设计与分工，(4) 上线后快速校准、行为审计与漂移检测，(5) 模型选择和智能路由策略，(6) 概率性输出的质量评估。触发场景包括"AI-native产品怎么做"、"用户行为不可预测怎么办"、"多agent怎么分工"、"模型漂移怎么处理"、"校准到95%太难了"、"唯快不破"、"怎么选模型"、"agent并行分工"、"AI产品上线后怎么迭代"。注意：如果产品是场景明确、边界可定义的+AI类型，请改用 keqian-method skill。即使用户没有明确说"AI-native"，但在讨论AI驱动决策、用户行为不可预测、概率性输出等话题时也应触发。 |
雪峰方法论：AI-Native 产品开发实战体系
核心理念：强模型依赖 × 多专精Agent × 快速校准 × 行为审计
来源：雪峰——AI-Native连续创业者，深耕AI日历管理等AI驱动产品。
核心洞察：穷举是死循环，唯快不破才是AI-native的生存之道。
与克谦方法论（keqian-method）互为对偶：
克谦解决"如何让AI在明确边界内可靠执行"，
雪峰解决"当边界本身不确定时怎么办"。
第零步：产品类型判断（必须先做）
在选择任何开发策略之前，先判断你的产品类型。
选错方法论比没有方法论更危险。
| 类型 | 特征 | 关键判断标准 | 推荐方法 |
|---|
| +AI（场景依赖型） | 用户行为可枚举，AI辅助执行确定性流程 | 能列出所有合法输入输出组合 | → keqian-method |
| AI-native（强模型依赖型） | AI驱动核心决策，用户行为开放式 | 用户的下一步操作你无法预测 | → 本skill |
| 混合型 | 核心流程确定，部分环节AI-native | 能拆分出哪些模块是确定的、哪些是开放的 | → 两者结合，按模块选用 |
快速判断清单
回答以下问题，如果3个以上答"是"，你大概率是AI-native：
- 用户的输入是自由文本/语音，而非选择菜单？
- 同一输入，你希望AI给出不同风格的输出？
- 用户会因为AI的回答方式而改变自己的后续行为？
- 你无法为产品写出完整的功能测试用例集？
- 产品的核心价值在于AI的"判断"而非"执行"？
第一原则：穷举是死循环
"穷举意味着：有多少人工，就有多少智能。这是死循环。"
为什么在AI-native场景下穷举不可行
在+AI场景下，克谦说"边界内可穷举，单维度选项有限"——这是对的。
但AI-native场景的数学不一样：
用户行为空间（开放） × 模型输出空间（概率性） × 上下文状态（动态）
= 组合爆炸，不可穷举
一个日历管理能有多复杂？答案是：走AI-native路线后，非常复杂。
因为用户一旦习惯AI-native交互，就永远回不到传统模式——
你必须持续适应用户不断演化的期望。
替代穷举的三个策略
策略1：行为模式簇（Behavioral Clusters）
不枚举每个case，而是聚类用户行为模式：
原始行为空间（不可穷举）
↓ 聚类
行为模式簇（5-15个典型模式）
↓ 每个模式簇
设计对应的AI响应策略
↓ 边界case
优雅降级到确定性逻辑
策略2：优雅降级（Graceful Degradation）
AI不确定时，回退到确定性逻辑：
AI置信度 > 阈值 → AI决策（快路径）
AI置信度 < 阈值 → 确定性回退（安全路径）
AI置信度极低 → 请求人工介入（慢路径）
策略3：概率性验收（Probabilistic Acceptance）
不用 assert output == expected，而用 check output ∈ acceptable_set：
assert response == "会议安排在下午3点"
assert "下午" in response
assert contains_time(response)
assert tone_is_professional(response)
assert no_hallucinated_contacts(response)
第二原则：多养专精虾
"多养两只虾，每只都比较专业，只干一种活。出了问题找bug容易。
一个全面能干的虾，出了问题找问题非常麻烦。"
专精Agent架构
┌─ 理解Agent（NLU：解析用户意图）
│
用户输入 → 路由器 ─┼─ 执行Agent（Action：调用API/修改数据）
│
├─ 校验Agent（Verify：检查执行结果）
│
└─ 表达Agent（NLG：生成用户可见回复）
每只虾只干一种活的好处：
- 出bug时，能精确定位是哪只虾的问题
- 单独升级/替换某只虾，不影响其他
- 每只虾可以用最适合它的模型（路由策略）
拆分决策矩阵
| 条件 | 拆分？ | 原因 |
|---|
| 功能正交，输出互不依赖 | ✅ | 并行执行，互不干扰 |
| 各自有独立的验证标准 | ✅ | 单独eval，精确定位 |
| 失败时只影响局部 | ✅ | 局部重试，不整体报废 |
| 有上下文依赖链 | ❌ | 合并时容易出不一致 |
| 你无法精确控制上下文注入 | ❌ | 注入什么、多少都要精确控制 |
| 合并结果需要复杂对齐 | ❌ | 合并成本可能超过收益 |
与克谦方法的差异
| 维度 | 克谦（单agent极致） | 雪峰（多专精agent） |
|---|
| 默认选择 | 顺序执行 | 并行分工 |
| 适用场景 | 有依赖链的长程任务 | 功能正交的独立模块 |
| 出错定位 | 在长链中回溯 | 直接定位出错的虾 |
| 风险 | 链越长概率乘越低 | 合并时可能不一致 |
不是对错，是产品类型不同。 同一产品内也可以混用。
第三原则：唯快不破
"无法预知上线后用户反馈和喜好，只能唯快不破。"
AI-Native快速迭代循环
Phase 1: 行为属性测试（上线前）
├── 不是断言式测试，是属性检查
├── "输出合理吗？" 而非 "输出等于X吗？"
└── 通过 = 可以上线，不通过 = 还不够稳
Phase 2: 快速上线（MVP心态）
├── 不追求完美，追求"可接受"
├── 95%校准极难，先追求80%
└── 剩下的靠用户反馈补
Phase 3: 用户反馈 + 漂移检测
├── 收集：用户满意度、异常行为、投诉
├── 检测：模型输出分布是否偏移
└── 预警：漂移超过阈值 → 触发校准
Phase 4: 快速校准
├── 提示词迭代（最快）
├── 模型切换/升级（中等）
├── 微调/RLHF（最慢但最持久）
└── 下一轮上线 → 回到Phase 3
迭代速度 > 单次质量
| 策略 | 单次质量 | 迭代速度 | AI-native适用性 |
|---|
| 一次做到95% | 极高 | 极慢 | ❌ 不现实 |
| 先80%上线再迭代 | 中等 | 快 | ✅ 推荐 |
| 60%就上 | 低 | 极快 | ⚠️ 风险大，慎用 |
第四原则：模型选择实战
"如果不是纯coding，尽量不要用xxx-codex模型，直接切通用模型就行了。"
"慢点就慢点，但牢靠，不啰嗦。"
模型路由决策树
任务类型？
├── 纯代码编写 → codex系列
├── 代码+推理混合 → 通用旗舰模型（GPT-5.x / Claude Opus）
├── 自然语言理解/生成 → 通用模型
├── 多模态 → 专用多模态模型（如GLM-5V-Turbo）
└── 简单执行 → 轻量模型（省成本）
Dumb Zone防护
模型在长上下文中会"降智"，不同模型的阈值不同：
| 模型类别 | 进入dumb zone的阈值 | 应对策略 |
|---|
| 国际Top2（GPT/Gemini） | 上下文窗口*0.7~0.8 | 0.7时compact |
| 国模（GLM-5.1等） | 上下文窗口*0.4~0.5 | 0.5时compact |
铁律： 达到阈值就/compact，不要等到降智再补救。
智能路由架构（多模型协作）
用户请求 → 复杂度评估器
↓
┌─ 简单请求 → 轻量模型（低成本）
├─ 中等请求 → 通用模型（平衡）
└─ 复杂请求 → 旗舰模型（高质量）
好处：大部分请求用轻量模型，少数复杂请求用旗舰模型，总成本可控。
第五原则：行为审计替代质量门禁
克谦用严格门禁 → 缓存命中飞轮。这在确定性输出场景有效。
AI-native输出是概率性的，需要不同的质量策略。
质量策略对比
| 维度 | 克谦门禁（确定性） | 雪峰审计（概率性） |
|---|
| 测试方式 | assert output == expected | check output ∈ acceptable_set |
| 失败处理 | 自动修复 → 升级人工 | 分析漂移原因 → 调整策略 |
| 质量指标 | 缓存命中率 | 用户满意度 + 模型一致性 |
| 迭代触发 | 门禁不通过 | 用户反馈 + 漂移检测 |
| 成本模型 | 高缓存命中 = 低成本 | 路由到合适模型 = 可控成本 |
行为审计实施
定期（每日/每周）
├── 采样模型输出（N=100+）
├── 自动检查行为属性（格式、安全、一致性）
├── 人工抽检（关键决策质量）
├── 漂移检测（输出分布与基线对比）
└── 生成审计报告 → 决定是否触发校准
漂移检测信号
以下信号出现时，说明模型可能在漂移：
- 输出分布偏移：同类输入的输出风格/长度/结构发生变化
- 用户投诉增加：满意度指标下降
- 异常行为增多：超时、拒答、幻觉增加
- 上下游不一致：Agent间的输出格式或语义不对齐
第六原则：一切以用户为中心
"AI-native的代价很大，就是一切以用户为中心。"
"用户一旦用惯了AI-native，就再也回不到传统模式了。"
用户适应性飞轮
用户使用AI-native产品
→ 用户期望提高（不接受传统交互）
→ 产品必须持续进化
→ 需要更强的模型 / 更好的校准
→ 用户体验提升
→ 用户期望进一步提高
→ …（正向循环，但也是成本螺旋）
管理用户期望
- 不要过度承诺：AI-native不是万能的，明确能力边界
- 设计优雅降级：AI不确定时给用户选择权，而非强行给答案
- 透明度：让用户知道AI在做什么，建立信任
- 反馈闭环：让用户的反馈真正影响产品迭代
实战工作流模板
启动AI-Native新项目
Phase 1: 产品定义（30%时间）
├── 判断产品类型（+AI / AI-native / 混合）
├── 定义行为模式簇（5-15个典型用户模式）
├── 设计优雅降级策略
└── 选择初始模型组合
Phase 2: 多专精Agent搭建（30%时间）
├── 拆分Agent职责（每只虾一种活）
├── 设计Agent间通信协议
├── 每只Agent独立eval
└── 集成测试（行为属性式）
Phase 3: 快速上线（10%时间）
├── MVP上线，不追求完美
├── 先覆盖80%的行为模式簇
└── 剩余20%用优雅降级兜底
Phase 4: 持续校准（30%时间，持续进行）
├── 用户反馈收集
├── 漂移检测 + 行为审计
├── 模型切换/提示词迭代
└── 下一轮上线
日常运维节奏
每日：
- 查看漂移检测报告
- 处理用户反馈中的高优问题
每周：
- 行为审计（采样+属性检查+人工抽检）
- 评估是否需要模型切换或提示词迭代
每月：
- 回顾行为模式簇是否需要更新
- 评估新模型是否值得切换
- 成本分析（路由策略优化）
与克谦.skill的互补关系
两个skill不冲突，可以在同一产品的不同模块分别使用：
| 产品模块 | 特征 | 推荐skill |
|---|
| 后端API | 确定性输入输出 | keqian-method |
| 数据处理管线 | 可穷举的转换规则 | keqian-method |
| AI对话引擎 | 用户输入开放式 | xuefeng-method |
| AI推荐系统 | 输出概率性 | xuefeng-method |
| CI/CD管线 | 确定性流程 | keqian-method |
| 模型路由/编排 | 动态决策 | xuefeng-method |
心法总结
"多养两只虾，每只只干一种活" — 专精分工，出bug好找
"穷举是死循环" — 用行为模式簇替代穷举
"唯快不破" — 先上线再校准，不追求一次完美
"慢点就慢点，但牢靠" — 模型选择，稳定优先
"AI-native的代价很大" — 一切以用户为中心，没有退路
"做过就知道了" — 理论和实操差距巨大，动手验证
参考资料
更多细节请查阅：
references/behavioral-clusters.md — 行为模式簇设计方法references/drift-detection.md — 模型漂移检测与校准协议
