Core philosophy: strong model dependence × multi-specialist Agents × rapid calibration × behavior auditing
Source: Xuefeng — a serial AI-Native entrepreneur deeply engaged in AI-driven products such as AI calendar management. Core insight: exhaustive enumeration is an infinite loop; only speed wins is the way for AI-native to survive.
Mutually dual with the Keqian methodology (keqian-method): Keqian solves "how to make AI execute reliably within clear boundaries," Xuefeng solves "what to do when the boundaries themselves are uncertain."
Step Zero: Product Type Determination (must be done first)
Before choosing any development strategy, first determine your product type. Choosing the wrong methodology is more dangerous than having no methodology.
| Type | Characteristics | Key judgment criteria | Recommended method |
|---|---|---|---|
| +AI (scenario-dependent) | User behavior is exhaustible; AI assists in executing deterministic processes | Can list all valid input-output combinations | → keqian-method |
| AI-native (strong model dependence) | AI drives core decisions; user behavior is open-ended | You cannot predict the user's next action | → this skill |
| Hybrid | Core processes are deterministic; some parts are AI-native | Can break down which modules are deterministic and which are open | → combine both, choose per module |
Quick judgment checklist
Answer the following questions. If you answer "yes" to 3 or more, you are most likely AI-native:
- Is the user's input free text/voice rather than a selection menu?
- For the same input, do you want AI to give outputs in different styles?
- Will users change their subsequent behavior because of how AI responds?
- Are you unable to write a complete set of functional test cases for the product?
- Does the product's core value lie in AI's "judgment" rather than "execution"?
First Principle: Exhaustive Enumeration Is an Infinite Loop
"Exhaustive enumeration means: as much manual effort as there is, that much intelligence there is. This is an infinite loop."
Why exhaustive enumeration is infeasible in AI-native scenarios
In +AI scenarios, Keqian says "within boundaries it can be exhaustively enumerated; single-dimension options are limited"—this is correct. But the mathematics of AI-native scenarios is different:
用户行为空间（开放） × 模型输出空间（概率性） × 上下文状态（动态）
= 组合爆炸，不可穷举
How complex can calendar management be? The answer is: after taking the AI-native route,very complex. Because once users get used to AI-native interaction, they can never go back to the traditional mode— you must continuously adapt to users' ever-evolving expectations.
Three strategies to replace exhaustive enumeration
Strategy 1: Behavioral Clusters
Instead of enumerating every case, cluster user behavior patterns:
原始行为空间（不可穷举）
↓ 聚类
行为模式簇（5-15个典型模式）
↓ 每个模式簇
设计对应的AI响应策略
↓ 边界case
优雅降级到确定性逻辑
Strategy 2: Graceful Degradation
When AI is uncertain, fall back to deterministic logic:
AI置信度 > 阈值 → AI决策（快路径）
AI置信度 < 阈值 → 确定性回退（安全路径）
AI置信度极低 → 请求人工介入（慢路径）
Strategy 3: Probabilistic Acceptance
Do not use assert output == expected, while using check output ∈ acceptable_set：
# 传统断言式（克谦适用）
assert response == "会议安排在下午3点"
# 行为属性式（雪峰适用）
assert "下午" in response
assert contains_time(response)
assert tone_is_professional(response)
assert no_hallucinated_contacts(response)
Second principle: raise more specialized shrimp
"Raise two more shrimp, each fairly specialized, each doing only one kind of work. When a problem arises, it's easy to find the bug. A shrimp that can do everything comprehensively is very troublesome to troubleshoot when a problem arises."
Specialized Agent architecture
┌─ 理解Agent（NLU：解析用户意图）
│
用户输入 → 路由器 ─┼─ 执行Agent（Action：调用API/修改数据）
│
├─ 校验Agent（Verify：检查执行结果）
│
└─ 表达Agent（NLG：生成用户可见回复）
Each shrimpdoes only one kind of workbenefits:
- When a bug occurs, you can precisely locate which shrimp is the problem
- Upgrade/replace a single shrimp independently without affecting the others
- Each shrimp can use the model that suits it best (routing strategy)
Split decision matrix
| Condition | Split? | Reason |
|---|---|---|
| Functions are orthogonal, outputs do not depend on each other | ✅ | Execute in parallel without interfering with each other |
| Each has independent validation criteria | ✅ | Evaluate separately, locate precisely |
| Failure affects only the local part | ✅ | Retry locally, no need to scrap the whole thing |
| There is a context dependency chain | ❌ | Merging easily produces inconsistencies |
| You cannot precisely control context injection | ❌ | What to inject and how much must be precisely controlled |
| Merging results requires complex alignment | ❌ | Merging cost may exceed the benefit |
Differences from Keqian's method
| Dimension | Keqian (single-agent extreme) | Xuefeng (multiple specialized agents) |
|---|---|---|
| Default choice | Sequential execution | Parallel division of labor |
| Applicable scenarios | Long-horizon tasks with dependency chains | Independent modules with orthogonal functions |
| Error localization | Trace back in a long chain | Directly locate the shrimp that went wrong |
| Risk | The longer the chain, the lower the multiplied probability | May be inconsistent when merging |
It's not about right or wrong, it's a different product type. They can also be mixed within the same product.
Third principle: speed is the only thing that cannot be broken
"You cannot predict user feedback and preferences after launch, so speed is the only thing that cannot be broken."
AI-Native rapid iteration loop
Phase 1: 行为属性测试（上线前）
├── 不是断言式测试，是属性检查
├── "输出合理吗？" 而非 "输出等于X吗？"
└── 通过 = 可以上线，不通过 = 还不够稳
Phase 2: 快速上线（MVP心态）
├── 不追求完美，追求"可接受"
├── 95%校准极难，先追求80%
└── 剩下的靠用户反馈补
Phase 3: 用户反馈 + 漂移检测
├── 收集：用户满意度、异常行为、投诉
├── 检测：模型输出分布是否偏移
└── 预警：漂移超过阈值 → 触发校准
Phase 4: 快速校准
├── 提示词迭代（最快）
├── 模型切换/升级（中等）
├── 微调/RLHF（最慢但最持久）
└── 下一轮上线 → 回到Phase 3
Iteration speed > single-pass quality
| Strategy | Single-pass quality | Iteration speed | AI-native applicability |
|---|---|---|---|
| Get it to 95% in one go | Extremely high | Extremely slow | ❌ Unrealistic |
| Launch at 80% first, then iterate | Medium | Fast | ✅ Recommended |
| Launch at 60% | Low | Extremely fast | ⚠️ High risk, use with caution |
Fourth principle: model selection in practice
"If it's not pure coding, try not to use the xxx-codex model; just switch to a general model." "Slower is fine, but it's reliable and not verbose."
Model routing decision tree
任务类型？
├── 纯代码编写 → codex系列
├── 代码+推理混合 → 通用旗舰模型（GPT-5.x / Claude Opus）
├── 自然语言理解/生成 → 通用模型
├── 多模态 → 专用多模态模型（如GLM-5V-Turbo）
└── 简单执行 → 轻量模型（省成本）
Dumb Zone protection
Models "get dumber" in long contexts, and the threshold differs by model:
| Model category | Threshold for entering the dumb zone | Response strategy |
|---|---|---|
| International Top 2 (GPT/Gemini) | Context window * 0.7~0.8 | compact at 0.7 |
| Domestic models (GLM-5.1, etc.) | context window * 0.4~0.5 | compact at 0.5 |
Iron rule: compact once the threshold is reached/compact, don't wait until intelligence degrades before remedying it.
Intelligent routing architecture (multi-model collaboration)
用户请求 → 复杂度评估器
↓
┌─ 简单请求 → 轻量模型（低成本）
├─ 中等请求 → 通用模型（平衡）
└─ 复杂请求 → 旗舰模型（高质量）
Benefit: most requests use lightweight models, a few complex requests use flagship models, total cost is controllable.
Fifth principle: behavior auditing replaces quality gates
Keqian uses strict gates → cache hit flywheel. This is effective in deterministic output scenarios. AI-native output is probabilistic and requires a different quality strategy.
Quality strategy comparison
| Dimension | Keqian gates (deterministic) | Xuefeng auditing (probabilistic) |
|---|---|---|
| Testing method | assert output == expected |
check output ∈ acceptable_set |
| Failure handling | Automatic repair → escalate to human | Analyze drift causes → adjust strategy |
| Quality metrics | Cache hit rate | User satisfaction + model consistency |
| Iteration trigger | Gate not passed | User feedback + drift detection |
| Cost model | High cache hit = low cost | Route to suitable model = controllable cost |
Behavior auditing implementation
定期（每日/每周）
├── 采样模型输出（N=100+）
├── 自动检查行为属性（格式、安全、一致性）
├── 人工抽检（关键决策质量）
├── 漂移检测（输出分布与基线对比）
└── 生成审计报告 → 决定是否触发校准
Drift detection signals
When the following signals appear, it indicates the model may be drifting:
- Output distribution shift: the output style/length/structure of similar inputs changes
- Increased user complaints: satisfaction metrics decline
- Increased abnormal behavior: timeouts, refusals, hallucinations increase
- Upstream/downstream inconsistency: output format or semantics between Agents are not aligned
Sixth principle: everything is user-centric
"The cost of AI-native is very high, which is everything being user-centric." "Once users get used to AI-native, they can never go back to the traditional mode."
User adaptability flywheel
用户使用AI-native产品
→ 用户期望提高（不接受传统交互）
→ 产品必须持续进化
→ 需要更强的模型 / 更好的校准
→ 用户体验提升
→ 用户期望进一步提高
→ …（正向循环，但也是成本螺旋）
Managing user expectations
- Don't overpromise: AI-native is not omnipotent, clarify capability boundaries
- Design graceful degradation: when AI is uncertain, give users the right to choose, rather than forcing an answer
- Transparency: let users know what AI is doing, build trust
- Feedback loop: let user feedback truly influence product iteration
Practical workflow templates
Starting a new AI-Native project
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%时间，持续进行）
├── 用户反馈收集
├── 漂移检测 + 行为审计
├── 模型切换/提示词迭代
└── 下一轮上线
Daily operations rhythm
每日：
- 查看漂移检测报告
- 处理用户反馈中的高优问题
每周：
- 行为审计（采样+属性检查+人工抽检）
- 评估是否需要模型切换或提示词迭代
每月：
- 回顾行为模式簇是否需要更新
- 评估新模型是否值得切换
- 成本分析（路由策略优化）
Complementary relationship with Keqian.skill
The two skills do not conflict,they can be used separately in different modules of the same product：
| Product module | Characteristics | Recommended skill |
|---|---|---|
| Backend API | Deterministic input and output | keqian-method |
| Data processing pipeline | Enumerable transformation rules | keqian-method |
| AI conversation engine | Open-ended user input | xuefeng-method |
| AI recommendation system | Probabilistic output | xuefeng-method |
| CI/CD Pipeline | Deterministic Process | keqian-method |
| Model Routing/Orchestration | Dynamic Decision-Making | xuefeng-method |
Summary of Key Principles
"多养两只虾，每只只干一种活" — 专精分工，出bug好找
"穷举是死循环" — 用行为模式簇替代穷举
"唯快不破" — 先上线再校准，不追求一次完美
"慢点就慢点，但牢靠" — 模型选择，稳定优先
"AI-native的代价很大" — 一切以用户为中心，没有退路
"做过就知道了" — 理论和实操差距巨大，动手验证
References
For more details, please refer to:
references/behavioral-clusters.md— Behavioral Pattern Cluster Design Methodreferences/drift-detection.md— Model Drift Detection and Calibration Protocol