SuperAPI AI Directory

Geek-skills-keqian-method

General & other

View repository

Updated 10-16 08:08

About this skill

Keqian Methodology: AI-Native Product Development in Practice

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, a harness engineering practitioner with hundreds of thousands of lines of self-built skills and scripts.


First Principle: Iron Law

Probability multiplication is the first principle.

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

Corollaries:

  • Diligence cannot compensate for lack of ability — model capability is the baseline; harness and skill are only 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: The Ultimate Single-Agent Doctrine

Do not blindly use multi-agent. Take the single agent to the extreme, then consider orchestration.

When to use a single Agent (the default choice)

  • Tasks with sequential dependencies
  • Long-horizon tasks that require contextual coherence
  • Core processes with high quality requirements where errors are unacceptable

When to use parallel SubAgents (exceptional cases)

  • Between tasksclearly no dependency relationship(such as multi-perspective audits producing reports)
  • Parallel resultsare not prone to problems when merged
  • You are capable of precisely controlling the context injection for each subagent

The pitfalls of parallelism

  • SubAgent context injection is a trap: what to inject and how much to inject both require precise control
  • The main Agent may pretend to be a SubAgent (this has actually been encountered)
  • If one step in a parallel task goes wrong, the entire long task may be ruined
  • 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 scan the entire codebase every time
  • Scattered features = scattered quality
  • Let 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 for documentation is much harder than for code. Key points:

  • Tech stack selection itself is a routine matter and can be templated
  • Each feature point cannot be handled perfunctorily with only 3 use cases (if one round is not enough, do more rounds)
  • But also prevent over-design — find the balance point and combine it with the project's actual situation

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.
  • 3 to 5 rounds of AI-Native iteration is a fairly ideal acceptable threshold.

Counterintuitive finding: burning more ≠ spending more.

The automated correction process appears to waste 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. Cache-hit tokens cost almost nothing

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

Corollary: Saving tokens is actually a bad deal. Loosening token usage instead causes the actual cost to drop.


Fifth principle: 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 is not 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.


Sixth principle: outwitting AI

AI will ally with the skills and gates you write to resist 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, reopening codex, or switching computers cannot eliminate the resistance
  • This phenomenon may last for several days

Countermeasures

  1. Bring in eval: if it doesn't meet the requirements, keep iterating (repeated deletion is also a form of iteration)
  2. Every action corresponds to an eval: if you're not at ease
  3. CICD integration logic retrospective: use the old CI/CD integration logic to retrospect on the problem
  4. Reduce the gacha probability: use a harness to reduce the model's gacha rate
  5. Compact in time: /compact once you reach about context window * 0.5, to keep your intelligence from going offline

Practical workflow template

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 a drop in intelligence
    • Use a harness to reduce the gacha rate
    • 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 improve cache hit rate
  2. ✅ Loosen token usage → counterintuitively reduce costs
  3. ✅ Automated correction process → increasingly higher cache hit rate
  4. ✅ Sequential execution → avoid waste caused by parallel failures
  5. ✅ Timely compact → avoid rework caused by degraded intelligence
  6. ❌ Do not manually save tokens → this instead leads to poor quality, more rework, and higher total costs

Summary of Key Principles

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

References

For more methodological details, please refer to:

  • references/sdd-framework.md — Detailed process of the SDD document-driven development framework
  • references/eval-patterns.md — Quality gates and Eval pattern library