当我们谈论最小可行程序（Minimal Viable Program, MVP）时，2014 年 Joe Armstrong 提出的定义正在被 AI 时代的开发实践重新诠释。传统软件工程中，MVP 是一种收缩策略 —— 从最小功能集出发，逐步迭代扩展；而 LLM 驱动开发则带来了一种全新的膨胀模式 —— 从模糊意图出发，通过模型生成逐步收敛到可执行代码。这两种范式的背后是截然不同的设计哲学，前者追求确定性的可控收缩，后者拥抱概率性的渐进澄清。
传统 MVP 的收缩逻辑：Erlang 遗产
Joe Armstrong 对 MVP 的理解深深根植于 Erlang 语言的并发模型与容错哲学。在他的观念中，最小可行程序不是功能的简单裁剪，而是系统边界的精确界定。一个 MVP 应当包含足够独立的进程结构，这些进程通过消息传递进行通信，并在 supervisor 树的监控下实现故障自愈。Armstrong 强调 "让程序崩溃"（Let It Crash）的设计原则 —— 与其编写防御性代码试图捕获所有错误，不如允许进程在遇到不可恢复故障时直接崩溃，由上层监督者负责重启恢复。这种设计思路要求从一开始就将程序分解为相互隔离的最小单元，每个单元只承担单一职责，进程间不存在共享可变状态。
这种收缩逻辑的关键特征是可预测性与确定性。传统 MVP 的代码量是明确可控的，开发者能够精确理解程序的执行路径，测试可以穷举所有可能的输入组合，系统的行为可以用形式化方法验证。在 Erlang/OTP 生态中，一个最小可行的程序通常包含一个 supervisor 进程和若干 worker 进程，配置文件定义了重启策略与最大重启频率，整个系统的状态转移是确定性的。这种确定性使得传统 MVP 可以在投入生产前通过充分的静态分析与集成测试达到高可信度。
AI 时代 MVP 的膨胀逻辑：从意图到代码
当 LLM 介入程序生成过程后，最小可行程序的构建逻辑发生了根本性转变。传统模式下，开发者从需求出发，手写代码，逐步添加功能；而在 LLM 驱动开发中，开发者首先给出模糊的高层意图，模型基于海量训练数据中的模式匹配生成候选代码，随后通过多轮对话迭代澄清与修正。这种模式的本质是将程序规格的确定过程从开发阶段转移到了运行时，代码不再是对需求的直接翻译，而是模型对模糊意图的概率性解释。
这种膨胀逻辑带来了新的设计挑战。首先是边界模糊问题：传统 MVP 的功能边界由开发者手动界定，而 LLM 生成的程序边界可能随对话上下文漂移，一个简单的需求可能引发模型生成远超预期的功能代码。其次是确定性丧失：相同提示词在不同调用中可能产生语义不同的代码，版本的精确复现成为难题。再者是故障模式的转变 —— 传统软件故障来自代码错误或运行时异常，而 LLM 驱动程序的故障可能源于提示词歧义、上下文遗忘或模型推理偏差，这类故障难以通过传统测试方法覆盖。
融合范式：AI 原生设计的可行路径
面对这两种逻辑的冲突与融合，2024 年至 2025 年的行业实践催生了几种可行的设计模式。最小可行智能产品（Minimum AI Product, MAP）概念建议将 AI 功能限制在单一可验证的用例上，从一开始就建立明确的信任边界与监控系统，这与 Armstrong 的单一职责进程理念形成呼应。最小可行上下文（Minimal Viable Context）则强调在提示词工程中精确控制输入 token 的范围，只向模型提供解决问题的最小必要信息，避免上下文膨胀导致的行为漂移。
从工程实现角度看，AI 时代的 MVP 应当借鉴传统 MVP 的收缩智慧。具体而言，可以设定以下设计参数：在功能维度，单次迭代只引入一个 AI 能力，使用独立的 API 调用或模型实例，避免功能交织导致的故障传播；在验证维度，对 LLM 生成的每段代码建立自动化测试套件，包括单元测试、模糊测试与基于属性的测试，确保输出的确定性满足最低要求；在监控维度，由于 LLM 输出具有概率性，需要部署额外的输出质量检测层，对生成内容进行采样审查与指标追踪。这些措施的本质是在膨胀式生成过程中引入收缩式约束，在拥抱 LLM 灵活性的同时维护系统的可控性。
从架构演进角度看，最小可行程序的长期目标从 "最小功能集" 转向 "最小可信度阈值"。传统 MVP 的成功标准是功能是否实现，而 AI 原生 MVP 的成功标准还需要包括模型输出的准确率、延迟、Token 消耗成本以及用户对 AI 辅助的信任度。当这些指标达到预设阈值时，才考虑扩展 AI 能力的覆盖范围。这种设计哲学将传统的功能驱动迭代转变为质量驱动迭代，使得 AI 组件的演进更加可持续。
工程实践参数参考
在具体实施 AI 时代的最小可行程序时，以下参数可作为初始参考：单次提示词 token 数控制在 2000 以内以降低上下文遗忘风险；模型 temperature 参数设置在 0.1 至 0.3 之间以平衡创造力与确定性；每次代码生成后运行自动化测试套件，测试覆盖率目标不低于 80%；建立提示词版本库，每次迭代的提示词变更需记录变更日志；部署输出采样机制，对前 100 次调用的输出进行人工审核，建立质量基线后再切换到全自动模式。这些参数并非一成不变，而应在实际项目中根据模型能力、任务复杂度与可靠性要求持续调优。
理解传统 MVP 与 AI 时代 MVP 的深层差异，有助于开发者在引入 LLM 能力时保持工程纪律。Armstrong 的 "让程序崩溃" 哲学在 AI 语境下可以转化为 "让模型输出可审计" 的新原则 —— 与其依赖模型产生完美答案，不如设计系统使其输出总是可追溯、可验证、可回滚。在这种设计哲学下，最小可行程序不再是功能的起点，而是可控性的起点。
资料来源：
- Harbinger Group: "From Minimal Viable Product (MVP) to Minimum AI Product (MAP)"
- Joe Armstrong 关于 Erlang 并发模型与容错设计的公开演讲资料