keqian-method

1# 克谦方法论：AI-Native产品开发实战体系
2 
3> 核心理念：产品人思维 × 极致单Agent × 文档驱动 × 质量门禁闭环
4>
5> 来源：胥克谦——从音乐教师到产品经理到AI-Native连续创业者，皮影客创始人，
6> 十几万行自建skill和脚本的harness工程实践者。
7 
8---
9 
10## 第一原则：Iron Law（铁律）
11 
12**概率乘是第一性原理。**
13 
14每个环节的成功率相乘决定最终质量。即使每次0.99，n=51后也不及格。
15因此：不追求一次完美，追求每个环节可验证、可修复、可迭代。
16 
17**推论：**
18- 勤不能补拙——模型能力是底线，harness和skill只是加速器和放大器
19- 拆到足够简单，单项任务才能收敛
20- 每个action必须对应一个eval
21 
22---
23 
24## 第二原则：单Agent极致论
25 
26**不盲目使用multi-agent。单agent做到极致，再考虑编排。**
27 
28### 何时用单Agent（默认选择）
29- 有先后依赖关系的任务
30- 需要上下文连贯性的长程任务
31- 质量要求高、不容错的核心流程
32 
33### 何时用并行SubAgent（例外情况）
34- 任务间**明确无依赖关系**（如多角度审计出报告）
35- 并行结果**合并时不易出问题**
36- 你有能力精确控制每个subagent的上下文注入
37 
38### 并行的陷阱
39- SubAgent上下文注入是个坑：注入什么、注入多少，都需要精确控制
40- 主Agent可能假装自己是SubAgent（实际遇到过）
41- 并行任务中一个环节出问题，整个长任务可能报废
42- 合并结果时容易引入不一致
43 
44**实践建议：** 如果不确定，选顺序执行。慢但可靠。
45 
46---
47 
48## 第三原则：文档驱动开发（SDD）
49 
50**7成精力投入文档质量和harness，3成精力写代码。**
51 
52### 为什么文档比代码重要
53- 不写文档就没有架构观
54- 不可能每次都让AI全量扫代码
55- 零散的功能 = 零散的质量
56- 让AI自己维护一份文档，代码再vibe对齐
57 
58### SDD工作流
59 
60```
611. 需求文档（PRD/设计文档）
62   ↓ AI辅助撰写 + 人工审核
632. 技术文档（架构决策、接口规范）
64   ↓ AI维护 + 人工把关
653. 代码实现
66   ↓ Agent执行 + 质量门禁拦截
674. 文档回写（代码变更 → 文档自动更新）
68   ↓ 闭环
69```
70 
71### 文档质量门禁
72文档的自动化质量控制比代码难很多。关键点：
73- 技术栈选择本身是套路化的事，可以模板化
74- 每个功能点不能只给3个用例敷衍了事（一轮不够就多轮）
75- 但也要防止过度设计——把握平衡点，结合项目实际
76 
77---
78 
79## 第四原则：质量门禁闭环（Verification-Driven）
80 
81**严格的质量门禁 = 高缓存命中率 = 高质量 = 低成本。**
82 
83### 门禁设计
84 
85```
86每个Action → 对应Eval → 通过/不通过
87   ↓ 不通过
88自动修复（最多N轮）→ 仍不通过 → 升级给人类
89```
90 
91### Eval的acceptable threshold
92- 不同业务、不同团队有不同threshold
93- 关键是在【期望预算内、期望时间内】出【期望结果】
94- 不要指望1次成型，那是稀罕事
95- AI-Native迭代3~5轮是比较理想的acceptable threshold
96 
97### 反直觉发现：多烧 ≠ 多花钱
98 
99自动化修正流程表面上浪费token，但实际上：
1001. 逐个问题点被反复修正 → 高缓存命中
101…