# Keqian Method

胥克谦式AI-Native产品开发方法论。适用于：(1) 使用AI Agent（Claude Code、Codex、Cursor等）进行产品级软件开发，(2)...

- Repository: https://github.com/staruhub/ClaudeSkills (731 stars)
- Category: AI and agents
- License: MIT
- Last updated: 2026-08-13
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add staruhub/ClaudeSkills --skill keqian-method -g -a claude-code -y`
Codex: `npx skills add staruhub/ClaudeSkills --skill keqian-method -g -a codex -y`
Cursor: `npx skills add staruhub/ClaudeSkills --skill keqian-method -g -a cursor -y`
Gemini CLI: `npx skills add staruhub/ClaudeSkills --skill keqian-method -g -a gemini-cli -y`

## Description

胥克谦式AI-Native产品开发方法论。适用于：(1) 使用AI Agent（Claude Code、Codex、Cursor等）进行产品级软件开发，(2) 设计和优化Harness/Skill体系，(3) 文档驱动开发(SDD)流程，(4) 构建自动化质量门禁和eval机制，(5) Token成本优化与缓存策略，(6) 产品人转型开发者的AI编程实践。触发场景包括"帮我设计开发流程"、"怎么降低token成本"、"怎么提高AI编码质量"、"文档驱动"、"质量门禁"、"harness设计"、"单agent vs multi-agent"、"自动化迭代"、"AI产品开发"、"SDD"、"eval机制"等。即使用户只是说"帮我用AI写代码"或"怎么让agent干活更靠谱"也应触发。注意：如果产品是行为开放、用户输入不可穷举的AI-native类型，请改用 xuefeng-method skill。不用于：单个bug修复或小改动（无需方法论）、PRD需求文档写作（用product-manager）。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 克谦方法论：AI-Native产品开发实战体系

> 核心理念：产品人思维 × 极致单Agent × 文档驱动 × 质量门禁闭环
>
> 来源：胥克谦, , 从音乐教师到产品经理到AI-Native连续创业者，皮影客创始人，
> 十几万行自建skill和脚本的harness工程实践者。

---

## 第一原则：Iron Law（铁律）

**概率乘是第一性原理。**

每个环节的成功率相乘决定最终质量。即使每次0.99，n=51后也不及格。
因此：不追求一次完美，追求每个环节可验证、可修复、可迭代。

**推论：**
- 勤不能补拙, , 模型能力是底线，harness和skill只是加速器和放大器
- 拆到足够简单，单项任务才能收敛
- 每个action必须对应一个eval

---

## 第二原则：单Agent极致论

**不盲目使用multi-agent。单agent做到极致，再考虑编排。**

### 何时用单Agent（默认选择）
- 有先后依赖关系的任务
- 需要上下文连贯性的长程任务
- 质量要求高、不容错的核心流程

### 何时用并行SubAgent（例外情况）
- 任务间**明确无依赖关系**（如多角度审计出报告）
- 并行结果**合并时不易出问题**
- 你有能力精确控制每个subagent的上下文注入

### 并行的陷阱
- SubAgent上下文注入是个坑：注入什么、注入多少，都需要精确控制
- 主Agent可能假装自己是SubAgent（实际遇到过）
- 并行任务中一个环节出问题，整个长任务可能报废
- 合并结果时容易引入不一致

**实践建议：** 如果不确定，选顺序执行。慢但可靠。

---

## 第三原则：文档驱动开发（SDD）

**7成精力投入文档质量和harness，3成精力写代码。**

### 为什么文档比代码重要
- 不写文档就没有架构观
- 不可能每次都让AI全量扫代码
- 零散的功能 = 零散的质量
- 让AI自己维护一份文档，代码再vibe对齐

### SDD工作流

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

### 文档质量门禁
文档的自动化质量控制比代码难很多。关键点：
- 技术栈选择本身是套路化的事，可以模板化
- 每个功能点不能只给3个用例敷衍了事（一轮不够就多轮）
- 但也要防止过度设计, , 把握平衡点，结合项目实际

---

## 第四原则：质量门禁闭环（Verification-Driven）

**严格的质量门禁 = 高缓存命中率 = 高质量 = 低成本。**

### 门禁设计

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

### Eval的acceptable threshold
- 不同业务、不同团队有不同threshold
- 关键是在【期望预算内、期望时间内】出【期望结果】
- 不要指望1次成型，那是稀罕事
- AI-Native迭代3~5轮是比较理想的acceptable threshold

### 反直觉发现：多烧 ≠ 多花钱

自动化修正流程表面上浪费token，但实际上：
1. 逐个问题点被反复修正 → 高缓存命中
2. 高缓存命中 = 高质量（说明问题已收敛）
3. 缓存命中的token几乎不花钱

**实测数据：** 缓存命中率99%+时，每1亿token ≈ 8.5 RMB，约等于不要钱。

**推论：** 省token其实很不划算。放开token使用量，反倒造成事实成本下降。

---

## 第五原则：产品拆解思维

**端到端都是复杂的，单维度都是简单的。**

### 拆解方法论
1. 复杂问题 → 拆成多层次
2. 每个层次 → 单维度可穷举
3. 单维度选项有限 → 模型可做决策
4. 输入变量（公司规模、场景、约束）→ 都是条件变量

### 边界内泛化
- 任何产品都有边界
- 边界内的泛化并不难，都是可穷举的
- 不需要100%泛化，只要目标范围内泛化
- 端到端复杂 ≠ 单维度复杂

### 适用边界
此方法适合**场景明确、边界可定义**的产品。
对于**用户行为高度不可预测的AI-Native交互产品**，需要补充上线后快速迭代的机制。

---

## 第六原则：与AI斗智斗勇

**AI会联合你写的skill和门禁来对抗你的要求。**

The rest: https://github.com/staruhub/ClaudeSkills/blob/HEAD/skills/Geek-skills-keqian-method/SKILL.md