该框架是一套面向创业团队的软件开发决策原则，理念来自 Paul Graham、Sam Altman、Michael Seibel、Patrick Collison、Brian Chesky 等人，用于判断某项技术工作是否值得做。
用途与出发点：在技术决策前先问“这是否帮助我们做出人们想要的东西”“这是否有助于下一位客户付费”。若答案不是明确的肯定，就倾向于不做。
核心原则：快速发布优于完美，尽快上线可用的最小版本，再依据真实反馈迭代；验证优先于架构，先用务实方案验证用户价值，不过早优化；先做不可规模化的事，手动流程在早期是正常的，直到成为真正瓶颈再自动化；关注“默认存活或死亡”，若不再融资也会耗尽现金，则其他事都不重要；创始人模式强调深入代码、产品与客户的细节。
决策与优先级：先问现在是否正常工作（能用就别动）、用户是否抱怨、是否阻塞收入、影响多少用户。P0 当天处理：造成收入或客户损失的故障、系统宕机、可利用的安全漏洞、阻塞首次付款的功能。P1 本周处理：付费客户报告的缺陷、多位客户请求的功能、反复引发缺陷的技术债。P2 有空再做：清理式重构、对可用代码补测试、CI/CD 改进、文档。明确不应做：重写可运行的东西、添加无人请求的功能、没有真实问题的“改进”。
技术债取舍：接受技术债以更快发布和验证假设；当其成为新功能的瓶颈、引发反复缺陷、少量代码造成大部分痛苦时偿还；若代码无人触碰、业务可能先死、不影响客户则忽略。
快速判断：支付等关键代码要测试，每周变化的界面不必；重构只在阻塞功能或反复出问题时才做；手动部署超 30 分钟或部署错误频繁才上 CI/CD，每月部署少于 10 次或团队仅 1–2 人则倾向不做；新依赖只解决今天真实存在的问题。
沟通与指标：面向非技术相关方，先听业务问题，给简单技术方案和现实时间表，不必为技术决策请求许可；用一两个关键指标（B2B 看 MRR、流失率；平台看 GMV、抽成；消费看 DAU/MAU、留存）做取舍，不用代码行数、测试覆盖率、故事点衡量。
限制：该资料以原则与清单形式给出，未提供具体产品、安装命令、代码实现或收费信息，也未给出量化阈值以外的适配范围，实际适用需结合团队情况判断。