keqian-method

# 克谦方法论：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. 逐个问题点被反复修正 → 高缓存命中 ...