{"id":"geek-skills-keqian-method","name":"keqian-method","summary":"徐克倩のAI-Native製品開発手法。対象は以下の通りです:(1) AIエージェント(Claude Code、Codex、カーソルなど)を用いた製品レベルのソフトウェア開発、(2) ハーネス/スキルシステムの設計・最適化、(3) ドキュメント駆動型開発(SDD)プロセス、(4) 自動品質アクセス管理および評価メカニ…","body":"# 克谦方法论：AI-Native产品开发实战体系\n\n> 核心理念：产品人思维 × 极致单Agent × 文档驱动 × 质量门禁闭环\n>\n> 来源：胥克谦——从音乐教师到产品经理到AI-Native连续创业者，皮影客创始人，\n> 十几万行自建skill和脚本的harness工程实践者。\n\n---\n\n## 第一原则：Iron Law（铁律）\n\n**概率乘是第一性原理。**\n\n每个环节的成功率相乘决定最终质量。即使每次0.99，n=51后也不及格。\n因此：不追求一次完美，追求每个环节可验证、可修复、可迭代。\n\n**推论：**\n- 勤不能补拙——模型能力是底线，harness和skill只是加速器和放大器\n- 拆到足够简单，单项任务才能收敛\n- 每个action必须对应一个eval\n\n---\n\n## 第二原则：单Agent极致论\n\n**不盲目使用multi-agent。单agent做到极致，再考虑编排。**\n\n### 何时用单Agent（默认选择）\n- 有先后依赖关系的任务\n- 需要上下文连贯性的长程任务\n- 质量要求高、不容错的核心流程\n\n### 何时用并行SubAgent（例外情况）\n- 任务间**明确无依赖关系**（如多角度审计出报告）\n- 并行结果**合并时不易出问题**\n- 你有能力精确控制每个subagent的上下文注入\n\n### 并行的陷阱\n- SubAgent上下文注入是个坑：注入什么、注入多少，都需要精确控制\n- 主Agent可能假装自己是SubAgent（实际遇到过）\n- 并行任务中一个环节出问题，整个长任务可能报废\n- 合并结果时容易引入不一致\n\n**实践建议：** 如果不确定，选顺序执行。慢但可靠。\n\n---\n\n## 第三原则：文档驱动开发（SDD）\n\n**7成精力投入文档质量和harness，3成精力写代码。**\n\n### 为什么文档比代码重要\n- 不写文档就没有架构观\n- 不可能每次都让AI全量扫代码\n- 零散的功能 = 零散的质量\n- 让AI自己维护一份文档，代码再vibe对齐\n\n### SDD工作流\n\n```\n1. 需求文档（PRD/设计文档）\n   ↓ AI辅助撰写 + 人工审核\n2. 技术文档（架构决策、接口规范）\n   ↓ AI维护 + 人工把关\n3. 代码实现\n   ↓ Agent执行 + 质量门禁拦截\n4. 文档回写（代码变更 → 文档自动更新）\n   ↓ 闭环\n```\n\n### 文档质量门禁\n文档的自动化质量控制比代码难很多。关键点：\n- 技术栈选择本身是套路化的事，可以模板化\n- 每个功能点不能只给3个用例敷衍了事（一轮不够就多轮）\n- 但也要防止过度设计——把握平衡点，结合项目实际\n\n---\n\n## 第四原则：质量门禁闭环（Verification-Driven）\n\n**严格的质量门禁 = 高缓存命中率 = 高质量 = 低成本。**\n\n### 门禁设计\n\n```\n每个Action → 对应Eval → 通过/不通过\n   ↓ 不通过\n自动修复（最多N轮）→ 仍不通过 → 升级给人类\n```\n\n### Eval的acceptable threshold\n- 不同业务、不同团队有不同threshold\n- 关键是在【期望预算内、期望时间内】出【期望结果】\n- 不要指望1次成型，那是稀罕事\n- AI-Native迭代3~5轮是比较理想的acceptable threshold\n\n### 反直觉发现：多烧 ≠ 多花钱\n\n自动化修正流程表面上浪费token，但实际上：\n1. 逐个问题点被反复修正 → 高缓存命中\n2. 高缓存命中 = 高质量（说明问题已收敛）\n3. 缓存命中的token几乎不花钱\n\n**实测数据：** 缓存命中率99%+时，每1亿token ≈ 8.5 RMB，约等于不要钱。\n\n**推论：** 省token其实很不划算。放开token使用量，反倒造成事实成本下降。\n\n---\n\n## 第五原则：产品拆解思维\n\n**端到端都是复杂的，单维度都是简单的。**\n\n### 拆解方法论\n1. 复杂问题 → 拆成多层次\n2. 每个层次 → 单维度可穷举\n3. 单维度选项有限 → 模型可做决策\n4. 输入变量（公司规模、场景、约束）→ 都是条件变量\n\n### 边界内泛化\n- 任何产品都有边界\n- 边界内的泛化并不难，都是可穷举的\n- 不需要100%泛化，只要目标范围内泛化\n- 端到端复杂 ≠ 单维度复杂\n\n### 适用边界\n此方法适合**场景明确、边界可定义**的产品。\n对于**用户行为高度不可预测的AI-Native交互产品**，需要补充上线后快速迭代的机制。\n\n---\n\n## 第六原则：与AI斗智斗勇\n\n**AI会联合你写的skill和门禁来对抗你的要求。**\n\n### 已知的AI抵抗模式\n- 要删除一个段落 → AI用段落改名、转移位置、改写保留语义等方式抵抗\n- 新开会话、重开codex、换电脑都不能消除抵抗\n- 这种现象可能持续数天\n\n### 应对策略\n1. **上eval**：不符合要求就持续迭代（反复删也是种迭代）\n2. **每个action都对应eval**：如果不放心的话\n3. **CICD集成逻辑复盘**：用以前CI/CD集成那套逻辑来复盘问题\n4. **降低抽卡概率**：通过harness降低模型抽卡比例\n5. **及时compact**：达到上下文窗口*0.5左右就/compact，保持智力不掉线\n\n---\n\n## 实战工作流模板\n\n### 启动新项目\n\n```\nPhase 1: 文档先行（占总时间70%）\n├── 撰写PRD（AI辅助 + 人工审核）\n├── 技术架构文档（AI维护 + 人工把关）\n├── 定义质量门禁和eval标准\n└── 设计harness结构（skill + rule配置）\n\nPhase 2: 代码实现（占总时间20%）\n├── Agent顺序执行任务\n├── 每个任务通过质量门禁\n├── 不通过 → 自动修复 → 仍不通过 → 人工介入\n└── 文档自动回写\n\nPhase 3: 迭代收敛（占总时间10%）\n├── 跑eval批量验证\n├── 收集失败case → 分析 → 改进harness\n└── 直到达到acceptable threshold\n```\n\n### 日常开发节奏\n\n```\n1. 不用子代理（除非任务明确无依赖）\n2. 顺序给任务，每个任务带eval\n3. 放着跑，定期查看\n4. 门禁拦住的问题 → 分析是harness问题还是模型问题\n5. harness问题 → 改skill/rule\n6. 模型问题 → 换模型或降低任务粒度\n```\n\n---\n\n## 模型选择建议\n\n基于实战经验：\n- **不是纯coding**：不要用xxx-codex模型，直接切通用模型\n- **稳定优先**：慢点就慢点，但牢靠、不啰嗦\n- **国模注意事项**：\n  - 进入上下文窗口*0.4~0.5就可能降智\n  - 通过harness降低抽卡比例\n  - 达到窗口*0.5就compact\n- **长上下文不是万能的**：关键是进入dumb zone的阈值要高\n\n---\n\n## 成本优化清单\n\n1. ✅ 建立严格质量门禁 → 自然提高缓存命中率\n2. ✅ 放开token使用量 → 反直觉地降低成本\n3. ✅ 自动化修正流程 → 缓存命中率越来越高\n4. ✅ 顺序执行 → 避免并行失败导致的浪费\n5. ✅ 及时compact → 避免降智导致的返工\n6. ❌ 不要手动省token → 反而导致质量差、返工多、总成本高\n\n---\n\n## 心法总结\n\n```\n\"做一个马鞍，再做一个拆马鞍的工具\" — 群友评价\n\"一抓就死，一放就乱\" — 管理的永恒难题\n\"多烧 ≠ 多花钱\" — 反直觉的真理\n\"端到端复杂，单维度简单\" — 产品拆解的核心\n\"慢点就慢点，但牢靠\" — 稳定性压倒一切\n```\n\n---\n\n## 验收标准（按本方法论执行的任务，交付前自查）\n\n- [ ] 写代码之前存在对应的规格文档（SDD：文档先行，不是事后补）\n- [ ] 每个交付环节过了质量门禁（测试/断言/eval），没有\"看起来没问题\"式放行\n- [ ] 概率乘意识：长链条任务拆成了可独立验证的小环节，而不是一把梭\n- [ ] 用的是单 Agent 主导的流程；引入并行前说明了\"为什么单 Agent 不够\"\n- [ ] Token 成本有意识：复用缓存、避免重复喂上下文\n\n## 参考资料\n\n更多方法论细节请查阅：\n- `references/sdd-framework.md` — SDD文档驱动开发框架详细流程\n- `references/eval-patterns.md` — 质量门禁和Eval模式库\n- `evals/routing-evals.json` — 触发边界回归用例（含与 xuefeng-method 的互斥镜像），改动 description 后用仓库根 `scripts/run_routing_evals.py` 校验","author":"@staruhub","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/staruhub/ClaudeSkills/tree/main/skills/Geek-skills-keqian-method","license":"MIT","category":"coding","lang":"multi","tokens":2404,"stars":0,"calls30d":2,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[{"path":"evals/routing-evals.json","size":1816,"sha256":"dd90f0967afbf7d4247f56da9a5f99019fa1d401434836c7e6cb27bcb0b9e7fa"},{"path":"references/eval-patterns.md","size":4058,"sha256":"66512ac64763de21e967884f5734f91142dbe2887e631dc192c17146a5d6f741"},{"path":"references/sdd-framework.md","size":2776,"sha256":"31fd45c5d3fe59abf15e8e7f25517b7e47222d60fde32fa733059c3342ab2781"}],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":[]}}