AI 产品开发方法论（非确定性产品怎么做）
回答：AI 产品和传统软件的开发流程差在哪？
生命周期总纲：†cc-cd-framework（newsletter 精编版，六步双环）+ cccd-framework（播客口述版，含起源翻车故事）——同一框架两个来源，配 agency-based-versioning（按自主权而非功能切版本）、double-ended-non-determinism（为什么 demo 惊艳上线即崩）、ai-products-two-differences。
质量与护栏：†minimum-viable-quality-mvq、ai-guardrail-four-patterns、weekly-failure-mode-rituals、ai-product-sense-three-step-process（Marily Nika 系）。交互设计：†nlx-natural-language-as-new-ux（Aparna：对话界面的隐形构件）、chat-universal-interface（Kevin Weil 反共识：chat 不是过渡形态）、reason-about-llms-as-humans、process-visualization-as-delight、precompute-for-ai-speed、ai-activation-good-friction。
指标与留存：ai-product-metrics-beyond-engagement（Mike Krieger：参与度指标是陷阱）、chatgpt-retention-thirds（Nick Turley：留存三分之一来自哪）、ship-first-to-learn-what-to-polish、run-toward-high-stakes-use-cases。
切入点选择：ai-wedge-workflow-selection、ai-attitude-based-segmentation（按用户对 AI 的态度而非需求分群）、ai-native-rethink-not-bolt-on、small-invisible-ai-features-win。
AI 产品 CC-CD 框架Cc Cd Framework
AI 产品 demo 惊艳、上线即崩、故障链纠缠难追因、用户信任悄悄流失——传统软件的开发生命周期假设（确定性行为、按功能切版本、上线即终点）在 AI 产品上失效。
最小可行质量 MVQMinimum Viable Quality Mvq
AI 功能在受控开发环境里表现良好，几乎必然在真实世界里性能下降，但下降多少、降到什么程度就不能上线，没有一个明确的、能在开发过程中反复对照的质量门槛。同时容易在漂亮的 demo 里迷失，忘了检查这个功能是否财务上站得住脚。
自然语言即新 UXNlx Natural Language As New UX
很多产品人把"用 AI 做产品"简化理解成"反正就是聊天框"，认为对话界面不需要被设计，模型输出什么就是什么。这个框架反驳了这个误解，给出"自然语言作为界面"这件事本身需要被刻意设计的具体构成元素。
AI 产品 CCCD 框架Cccd Framework
AI 产品的开发生命周期（CCCD, Continuous Calibration / Continuous Development，致敬 CI/CD）：如何在不毁掉用户信任的前提下，从低自主版本逐级放权到高自主 agent，同时把生产中的意外行为持续回灌成改进飞轮。起源：作者曾因一步到位做端到端客服 agent、hotfix 追不上涌现错误而被迫下线产品（同类翻车如 Air Canada 客服 agent 幻觉出不存在的退款政策并被判有效）。
基于自主权的版本规划Agency Based Versioning
AI 产品如何切 v1/v2/v3。传统"按功能深度/用户需求"规划版本的方式，无法控制 AI 系统的失败风险，也无法产出可评估的中间状态。
双端非确定性Double Ended Non Determinism
解释为什么"demo 惊艳 → 生产崩溃 → 问题纠缠难追因 → 产品方向动摇"的剧本在 AI 产品上反复上演——这不是执行不力，而是忽视了 AI 系统对传统软件假设的根本性破坏。
AI 产品两大差异AI Products Two Differences
为什么不能照搬传统软件的产品开发方式来做 AI 产品——先在头脑里立起两个根本差异，再谈流程与方法。
AI护栏四模式AI Guardrail Four Patterns
发现了模型的失败模式之后，具体该往系统提示词/产品里加什么样的规则，才能让 AI 产品"优雅地失败"而不是"灾难性地失败"，且不需要换一个更强的底层模型。
每周失败模式仪式Weekly Failure Mode Rituals
具体怎么"主动"把模型推向失败模式，而不是坐等用户上线后来教你。作者每周三早上第一个会议前花不到 15 分钟做这套仪式，持续对自己正在做的 AI 工作流有效。
AI 产品直觉三步法AI Product Sense Three Step Process
AI 功能在受控演示环境里表现完美，一上线遇到真实用户的模糊输入、混乱意图和零耐心就崩了——PM 需要一套可重复的实操习惯，在用户教你之前自己先发现模型的失败模式，而不是"AI product sense"这种听起来很虚的说法。
通用对话界面定位Chat Universal Interface
"聊天框只是过渡形态，将来会有更好的 AI 交互"是流行论断。产品团队据此纠结：要不要用结构化 UI 取代 chat？Kevin 给出反共识判断，并划清 chat 与专用 UI 各自的位置。
类人推理LLMReason About LLMs As Humans
设计 AI 产品的交互、架构或 prompt 策略时没有先例可循（如"模型思考 20 秒时 UI 该显示什么"）。Kevin 称这是他在 OpenAI 学到的最反直觉的东西：把模型当人来推理，往往直接得到可用答案。
过程可视化即愉悦Process Visualization As Delight
生成式 AI 产品的核心能力往往是一个"黑箱"（用户看不懂模型内部在做什么），如何在不改变底层模型能力的前提下，让用户对这个过程产生信任感和愉悦感。
AI速度预计算Precompute For AI Speed
AI 生成内容通常意味着让用户等待生成过程完成,这个等待本身就会拉低体验——有没有办法让 AI 功能感觉是"即时"的?
AI 激活的有效摩擦AI Activation Good Friction
AI 产品的激活（day0/day1 体验）为什么特别难、特别重要；onboarding 流程到底该砍步骤还是加步骤。
AI 产品非参与度指标AI Product Metrics Beyond Engagement
Web 2.0/社交产品时代的"参与度"指标(时长、DAU、互动频率)被自然而然地搬到 AI 对话产品上,但一次好的对话可能是两条消息,也可能是两百条——用传统engagement 指标衡量,反而会误导团队去做错误的优化。这个模型帮你判断:AI 产品该往哪个方向找北极星指标。
ChatGPT 留存三分法Chatgpt Retention Thirds
AI 产品的留存到底是"模型天生强"还是"产品做出来的"？这个框架拆解 ChatGPT 留存改进的三个来源及大致占比，给 AI 产品团队一个投入配比参考。
先发布后打磨Ship First To Learn What To Polish
AI 产品要不要等打磨好再发？传统"质量门槛"直觉在 AI 上为什么失效，以及横向通用产品怎么跳过"空盒子"冷启动。
拥抱高风险用例Run Toward High Stakes Use Cases
用户拿 AI 问医疗、感情、重大人生决定——高风险用例。公司是禁用这些场景规避责任，还是投入做好？这个模型给出 OpenAI 的立场和配套做法。
AI 楔形工作流选择AI Wedge Workflow Selection
AI 能做的事情太多,团队常常不知道该先切入哪个工作流才能让用户第一次尝试就留下来,还愿意重复使用。
基于 AI 态度的用户细分AI Attitude Based Segmentation
传统用户细分按"功能性需求"分组(不同的人需要产品解决不同问题),但 AI 产品发现:决定用户体验差异的往往不是需求本身,而是用户对 AI 技术本身的态度——用老办法做用户测试和细分,会得出误导性的结论。
AI 原生重构而非附加AI Native Rethink Not Bolt On
团队做 AI 功能的"第一版"往往是简单粗暴地把聊天框粘贴到产品上(bolt-on),没有真正带来价值——为什么高价值的 AI 体验总是要等到"第二次尝试"才出现?传统的产品开发流程(先做用户研究、再设计方案、再实现)在 AI 场景下还适用吗?
隐形AI小功能制胜法则Small Invisible AI Features Win
团队默认把资源投向"大 AI 功能"(聊天机器人、复杂 agent),但这类高调功能未必是用户真正买单的部分——该怎么判断哪些 AI 投入性价比最高?