SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsxuefeng-method

xuefeng-method

Agents & models

View repository

Updated 10-16 08:45

About this skill

Xuefeng Methodology: AI-Native Product Development Practical System

Core philosophy: strong model dependence × multi-specialist Agents × rapid calibration × behavior auditing

Source: Xuefeng — AI-Native serial entrepreneur, deeply engaged in AI-driven products such as AI calendar management. Core insight: Exhaustion is an infinite loop; only speed is unbreakable — that is the way of survival for AI-native.

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 Judgment (Must Be Done First)

Before choosing any development strategy, first judge 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 enumerable; AI assists in executing deterministic processes Can list all legal input-output combinations → keqian-method
AI-native (strongly model-dependent) AI drives core decisions; user behavior is open-ended You cannot predict the user's next action → This skill
Hybrid Core process is deterministic; some stages are AI-native Can break down which modules are deterministic and which are open-ended → Combine both, select according to module

Quick Judgment Checklist

Answer the following questions; if you answer "yes" to 3 or more, you are most likely AI-native:

  1. Is the user's input free text/voice rather than a selection menu?
  2. For the same input, do you want AI to give outputs in different styles?
  3. Will users change their subsequent behavior because of the way AI responds?
  4. Are you unable to write a complete set of functional test cases for the product?
  5. Is the product's core value in AI's "judgment" rather than "execution"?

First Principle: Exhaustion Is an Infinite Loop

"Exhaustion means: as much manual labor as there is, that much intelligence there is. This is an infinite loop."

Why exhaustion is infeasible in AI-native scenarios

In +AI scenarios, Keqian says "within boundaries it can be exhausted, 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' constantly evolving expectations.

Three Strategies to Replace Exhaustion

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

Instead of using assert output == expected, but use 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 relatively specialized, each doing only one kind of work. When problems arise, finding the bug is easy. With one all-around capable shrimp, finding the problem when issues arise is very troublesome."

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 pinpoint exactly 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)

Splitting 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 verification criteria ✅ Individual eval, precise localization
Failure only affects a local part ✅ Local retry, no scrapping of the whole
There is a context dependency chain ❌ Merging easily produces inconsistencies
You cannot precisely control context injection ❌ What and how much to inject must be precisely controlled
Merged results require complex alignment ❌ Merge cost may exceed the benefit

Differences from Keqian's method

Dimension Keqian (single-agent extreme) Xuefeng (multi-specialized agent)
Default choice Sequential execution Parallel division of labor
Applicable scenarios Long-horizon tasks with dependency chains Independent modules with orthogonal functions
Error localization Backtrack within a long chain Directly pinpoint the shrimp that erred
Risk The longer the chain, the lower the multiplied probability May be inconsistent when merging

It is not a matter of right or wrong, but of different product types. Within the same product, they can also be mixed.

Third Principle: Only Speed Cannot Be Broken

"You cannot predict user feedback and preferences after launch, so only speed 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% then iterate Medium Fast ✅ Recommended
Launch at 60% Low Extremely fast ⚠️ High risk, use with caution

Fourth Principle: Model Selection in Practice

"If it is not pure coding, try not to use the xxx-codex model; just switch directly to a general model." "Slower is fine, but it is reliable and not verbose."

For the model routing decision tree, dumb zone protection, and multi-model collaboration details, see references/model-routing.md。

Fifth Principle: Behavior Auditing Replaces Quality Gates

Keqian uses strict gates → cache hit flywheel. This works in deterministic output scenarios. AI-native outputs are probabilistic and require a different quality strategy.

Quality Strategy Comparison

Dimension Keqian Access Control (Deterministic) Xuefeng Audit (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 Access Control Not Passed User Feedback + Drift Detection
Cost Model High Cache Hit Rate = Low Cost Route to the Right Model = Controllable Cost

Behavior Audit Implementation

定期（每日/每周）
├── 采样模型输出（N=100+）
├── 自动检查行为属性（格式、安全、一致性）
├── 人工抽检（关键决策质量）
├── 漂移检测（输出分布与基线对比）
└── 生成审计报告 → 决定是否触发校准

Drift Detection Signals

When the following signals appear, it indicates the model may be drifting:

  1. Output Distribution Shift: The output style/length/structure for similar inputs changes
  2. Increased User Complaints: Satisfaction metrics decline
  3. Increased Anomalous Behavior: Timeouts, refusals, and hallucinations increase
  4. Upstream/Downstream Inconsistency: Output formats or semantics between Agents are misaligned

Principle Six: Everything Is User-Centric

"The cost of being AI-native is high, and that cost is being entirely user-centric." "Once users get used to AI-native, they can never go back to the traditional mode."

User Adaptability Flywheel

用户使用AI-native产品
  → 用户期望提高（不接受传统交互）
  → 产品必须持续进化
  → 需要更强的模型 / 更好的校准
  → 用户体验提升
  → 用户期望进一步提高
  → …（正向循环，但也是成本螺旋）

Manage User Expectations

  • Don't Overpromise: AI-native is not omnipotent; clearly define capability boundaries
  • Design Graceful Degradation: When AI is uncertain, give users the choice rather than forcing an answer
  • Transparency: Let users know what the AI is doing to build trust
  • Feedback Loop: Let user feedback truly influence product iteration

Acceptance Criteria (self-check before delivery for tasks executed according to this methodology)

  • Step Zero completed: product type determination (+AI / AI-native / hybrid) has a clear conclusion and the method was chosen accordingly
  • Agent division of labor follows "each shrimp does only one kind of work"; each Agent's responsibility can be stated clearly in one sentence
  • Launch/delivery includes a behavior audit plan: know how to detect model behavior drift instead of waiting for user complaints
  • No indefinite delay in pursuit of "calibrating to 95%"—the rhythm of fast launch + fast calibration is reflected
  • Model selection has routing rationale (cost/capability/latency), rather than using the most expensive one for everything

Practical and Collaboration Templates

Practical workflows, daily operations rhythm, complementarity with keqian-method , and the summary of core principles have been consolidated into references/operating-playbook.md. The entry file only retains judgment, principles, and navigation to avoid continued expansion of the main document.

Reference Materials

For more details, please refer to:

  • references/behavioral-clusters.md — Behavior pattern cluster design method
  • references/drift-detection.md — Model drift detection and calibration protocol
  • references/model-routing.md — Model selection, context thresholds, and intelligent routing
  • references/operating-playbook.md — Practical workflows, operations rhythm, and methodology complementarity
  • evals/routing-evals.json — Trigger boundary regression test cases (including the mutually exclusive mirror with keqian-method); after changing description, use the repository root scripts/run_routing_evals.py for validation