雪峰方法论：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：

1. 用户的输入是自由文本/语音，而非选择菜单？
2. 同一输入，你希望AI给出不同风格的输出？
3. 用户会因为AI的回答方式而改变自己的后续行为？
4. 你无法为产品写出完整的功能测试用例集？
5. 产品的核心价值在于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+）
├── 自动检查行为属性（格式、安全、一致性）
├── 人工抽检（关键决策质量）
├── 漂移检测（输出分布与基线对比）
└── 生成审计报告 → 决定是否触发校准

漂移检测信号

以下信号出现时，说明模型可能在漂移：

1. 输出分布偏移：同类输入的输出风格/长度/结构发生变化
2. 用户投诉增加：满意度指标下降
3. 异常行为增多：超时、拒答、幻觉增加
4. 上下游不一致：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 — 模型漂移检测与校准协议