SuperAPI AI Directory
Partner中文AI newsFavorites
Skillskeqian-method

keqian-method

Agents & models

View repository

Updated 10-16 08:53

About this skill

Keqian Methodology: AI-Native Product Development Practical System

Core Philosophy: Product Thinker Mindset × Ultimate Single Agent × Documentation-Driven × Quality Gate Closed Loop

Source: Xu Keqian — from music teacher to product manager to AI-Native serial entrepreneur, founder of Piyingke, harness engineering practitioner with over a hundred thousand lines of self-built skills and scripts.

First Principle: Iron Law

Probability multiplication is the first principle.

The success rate of each stage multiplied together determines the final quality. Even if each is 0.99, after n=51 it still fails. Therefore: Do not pursue one-shot perfection; pursue making each stage verifiable, fixable, and iterable.

Corollaries:

  • Diligence cannot compensate for lack of ability — model capability is the baseline; harness and skill are merely accelerators and amplifiers
  • Break it down until it is simple enough; only then can an individual task converge
  • Every action must correspond to an eval

Second Principle: Ultimate Single Agent Theory

Do not blindly use multi-agent. Push a single agent to the extreme before considering orchestration.

When to use a single Agent (default choice)

  • Tasks with sequential dependencies
  • Long-range tasks requiring contextual continuity
  • Core processes with high quality requirements and no tolerance for error

When to use parallel SubAgents (exceptions)

  • Between tasksClearly no dependencies(such as multi-perspective audits producing reports)
  • Parallel resultsNot prone to problems when merging
  • You are capable of precisely controlling the context injection of each subagent

The pitfall of parallelism

  • SubAgent context injection is a pitfall: what to inject and how much to inject both require precise control
  • The main Agent may pretend to be a SubAgent (actually encountered)
  • If one stage in a parallel task has problems, the entire long task may be scrapped
  • Merging results easily introduces inconsistencies

Practical advice: If unsure, choose sequential execution. Slower but reliable.

Third Principle: Documentation-Driven Development (SDD)

Invest 70% of effort in documentation quality and harness, 30% in writing code.

Why documentation matters more than code

  • Without writing documentation there is no architectural view
  • It is impossible to have AI fully scan the code every time
  • Scattered features = scattered quality
  • Have AI maintain a document itself, then vibe-align the code

SDD Workflow

1. 需求文档（PRD/设计文档）
   ↓ AI辅助撰写 + 人工审核
2. 技术文档（架构决策、接口规范）
   ↓ AI维护 + 人工把关
3. 代码实现
   ↓ Agent执行 + 质量门禁拦截
4. 文档回写（代码变更 → 文档自动更新）
   ↓ 闭环

Documentation quality gates

Automated quality control of documentation is much harder than for code. Key points:

  • The choice of tech stack is itself a routine matter and can be templated
  • Each feature point cannot be perfunctorily handled with only 3 use cases (if one round is not enough, do more rounds)
  • But also prevent over-design — grasp the balance point and combine with the project's reality

Fourth Principle: Quality Gate Closed Loop (Verification-Driven)

Strict quality gates = high cache hit rate = high quality = low cost.

Gate design

每个Action → 对应Eval → 通过/不通过
   ↓ 不通过
自动修复（最多N轮）→ 仍不通过 → 升级给人类

Eval's acceptable threshold

  • Different businesses and different teams have different thresholds
  • The key is to produce the [expected result] within the [expected budget and expected time]
  • Don't expect to get it right in one shot; that's a rare occurrence
  • For AI-Native, 3~5 iterations is a fairly ideal acceptable threshold

Counterintuitive finding: burning more ≠ spending more money

The automated correction process superficially wastes tokens, but in reality:

  1. Issues are repeatedly corrected one by one → high cache hit rate
  2. High cache hit rate = high quality (indicating the issues have converged)
  3. Tokens from cache hits cost almost nothing

Measured data: When the cache hit rate is 99%+, every 100 million tokens ≈ 8.5 RMB, which is roughly free.

Inference: Saving tokens is actually very uneconomical. Loosening token usage instead causes the actual cost to drop.

Principle Five: Product decomposition thinking

End-to-end is always complex; any single dimension is simple.

Decomposition methodology

  1. Complex problem → break into multiple layers
  2. Each layer → a single dimension that can be exhaustively enumerated
  3. Limited options in a single dimension → the model can make decisions
  4. Input variables (company size, scenario, constraints) → all are conditional variables

Generalization within boundaries

  • Every product has boundaries
  • Generalization within boundaries isn't hard; it can all be exhaustively enumerated
  • You don't need 100% generalization, only generalization within the target scope
  • End-to-end complexity ≠ single-dimension complexity

Applicable boundaries

This method suitsproducts with clear scenarios and definable boundaries. ForAI-Native interactive products with highly unpredictable user behavior, a mechanism for rapid post-launch iteration needs to be added.

Principle Six: Wits and guts with AI

AI will join forces with the skills and guards you wrote to oppose your requirements.

Known AI resistance patterns

  • To delete a paragraph → AI resists by renaming the paragraph, moving its position, rewriting to preserve the semantics, etc.
  • Starting a new session, restarting codex, or switching computers cannot eliminate the resistance
  • This phenomenon may last for several days

Countermeasures

  1. Use eval: keep iterating if it doesn't meet the requirements (repeatedly deleting is also a form of iteration)
  2. Every action corresponds to an eval: if you're not at ease about it
  3. Integrate CI/CD logic for retrospectives: use the old CI/CD integration logic to retrospectively review problems
  4. Reduce the gacha probability: reduce the model's gacha rate through the harness
  5. Compact in a timely manner: /compact when you reach about context window * 0.5, to keep your intelligence from going offline

Practical workflow templates

Starting a new project

Phase 1: 文档先行（占总时间70%）
├── 撰写PRD（AI辅助 + 人工审核）
├── 技术架构文档（AI维护 + 人工把关）
├── 定义质量门禁和eval标准
└── 设计harness结构（skill + rule配置）

Phase 2: 代码实现（占总时间20%）
├── Agent顺序执行任务
├── 每个任务通过质量门禁
├── 不通过 → 自动修复 → 仍不通过 → 人工介入
└── 文档自动回写

Phase 3: 迭代收敛（占总时间10%）
├── 跑eval批量验证
├── 收集失败case → 分析 → 改进harness
└── 直到达到acceptable threshold

Daily development rhythm

1. 不用子代理（除非任务明确无依赖）
2. 顺序给任务，每个任务带eval
3. 放着跑，定期查看
4. 门禁拦住的问题 → 分析是harness问题还是模型问题
5. harness问题 → 改skill/rule
6. 模型问题 → 换模型或降低任务粒度

Model selection recommendations

Based on practical experience:

  • Not purely coding: don't use the xxx-codex model, switch directly to a general-purpose model
  • Stability first: slower is fine, but solid and not verbose
  • Notes on domestic models：
    • Entering context window * 0.4~0.5 may cause intelligence degradation
    • Reduce the gacha rate through the harness
    • Compact once you reach window * 0.5
  • Long context is not omnipotent: the key is that the threshold for entering the dumb zone must be high

Cost Optimization Checklist

  1. ✅ Establish strict quality gates → naturally improves cache hit rate
  2. ✅ Open up token usage → counterintuitively reduces cost
  3. ✅ Automated correction process → cache hit rate keeps improving
  4. ✅ Sequential execution → avoids waste caused by parallel failures
  5. ✅ Timely compact → avoids rework caused by degraded intelligence
  6. ❌ Do not manually save tokens → instead leads to poor quality, more rework, and higher total cost

Key Takeaways Summary

"做一个马鞍，再做一个拆马鞍的工具" — 群友评价
"一抓就死，一放就乱" — 管理的永恒难题
"多烧 ≠ 多花钱" — 反直觉的真理
"端到端复杂，单维度简单" — 产品拆解的核心
"慢点就慢点，但牢靠" — 稳定性压倒一切

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

  • Before writing code, a corresponding specification document exists (SDD: documentation first, not added afterward)
  • Each delivery step has passed quality gates (tests/assertions/evals), with no "looks fine" style sign-off
  • Probability multiplied by awareness: long-chain tasks are broken into independently verifiable small steps, rather than doing it all in one go
  • The process is led by a single Agent; before introducing parallelism, explain "why a single Agent is not enough"
  • Token cost is handled consciously: reuse cache, avoid repeatedly feeding context

Reference Materials

For more methodology details, please refer to:

  • references/sdd-framework.md — Detailed process of the SDD document-driven development framework
  • references/eval-patterns.md — Quality gate and Eval pattern library
  • evals/routing-evals.json — Trigger boundary regression test cases (including the mutually exclusive mirror with xuefeng-method); after changing description, use the repository root scripts/run_routing_evals.py to validate