两周完成一个可运行的 AI 金融研究产品，听起来像工程速度问题。真正决定能否完成的，是能否持续拒绝那些“以后肯定需要”的功能。
MVP 不是缩小版完整产品。它应该用最少系统验证最大风险：用户是否愿意把真实研究材料交给产品，工作流能否产出可检查的结果，模型错误是否可以被发现和修正。
图 1：首版只打通一条真实、可追溯的垂直路径。平台化能力推迟到核心任务被证明以后。
第一天先写失败条件
开始前，我们没有列完整功能清单，而是写出两周后必须回答的问题：从一组指定材料出发，系统能否完成一个具体研究任务；结果是否带来源；用户能否看到并干预过程；一次任务的时间和成本是否可接受。
同时写出失败条件。若核心任务仍需大量手工补充、引用无法验证，或每次结果差异大到无法复用，那么界面再完整也不能证明方向成立。
明确失败条件能阻止团队用新增功能掩盖核心问题。登录方式、主题设置、复杂权限和完整计费都被推迟，只有直接影响验证的部分进入范围。
选择一条垂直路径
我们选取一种材料、一类任务和一种报告结构，打通从上传、解析、执行到结果查看的完整路径。没有先建设“通用 Agent 平台”，也没有支持所有文档与研究模板。
垂直路径必须是真实的，不能用静态数据伪造关键环节。文档确实经过解析，模型确实调用工具，结果确实保存并可重新打开。边缘场景可以少，主路径不能是演示脚本。
这条路径帮助团队很早发现系统级问题：长文档如何切分，引用如何对应原文，任务失败后状态如何保留。这些问题比主页设计更能决定产品方向。
架构只为当前风险服务
短周期常出现两个极端：完全不设计，所有逻辑写在接口里；或者担心未来重构，先搭建复杂平台。更合适的做法是只建立不会轻易消失的边界。
我们保留任务、节点、产物和来源四个核心模型。模型调用通过统一适配层，工作流状态持久化，前端只依赖稳定任务接口。至于节点市场、可视化编排和多租户配置，都不在 MVP 中。
数据库 Schema 优先表达事实，不追求覆盖未来所有角色。关键写操作保留版本与时间，方便排查。外部调用都有超时和错误分类，避免一个请求挂住整个服务。
这些基础并不昂贵，却让核心流程可以被观察和恢复。MVP 可以省略规模能力，不能省略理解失败所需的证据。
用现有能力换取时间
两周内不应该自建身份系统、对象存储、文档解析器和模型网关。优先使用稳定服务与成熟库，把团队时间留给领域工作流。
复用也有边界。选择第三方时，我们关注能否替换、数据是否可导出、故障时能否降级。MVP 不需要多云架构，但不能把核心数据锁在无法迁移的黑盒里。
UI 使用有限组件和明确布局，不建设完整设计系统。保持排版、间距和状态一致，比提供大量组件更重要。产品的专业感来自过程清楚和结果可信，不来自装饰数量。
每天交付可运行状态
短周期最怕最后几天才集成。我们把计划按可运行切片：第一天完成最小任务记录，随后接通单个模型节点，再加入文档来源、结果展示和失败恢复。每天结束时，主分支都有一条比昨天更完整的路径。
这样能提前暴露契约冲突，也能让产品判断建立在真实系统上。界面和服务端不各自等待“完成”，而是围绕同一个垂直路径交替推进。
每日复盘只回答三件事：今天验证了什么，发现了什么风险，明天最重要的未知是什么。任务数量不是进度，未知风险下降才是。
AI 功能必须可调试
传统接口输入确定，AI 节点可能因模型、提示词和上下文变化产生不同结果。MVP 如果只保存最终文本，出现问题时几乎无法改进。
每次执行记录工作流版本、模型、提示词版本、输入材料标识、工具调用和结构化产物。敏感原文按权限保存，不把所有内容写进普通日志。
用户看到的是简洁过程，开发视图则能比较不同执行。我们可以判断错误来自检索遗漏、上下文选择、工具失败还是模型生成，而不是统一归因于“模型不稳定”。
这种可调试性也支持快速迭代。修改提示词后，用固定样本重跑，比较引用覆盖、结构完整和人工评分，避免只凭一两个漂亮结果判断。
把人放进工作流
为了演示自动化，很容易让系统直接产出完整报告。但在高价值研究场景，用户需要控制范围、确认材料和修正中间判断。
我们在关键节点保留人工确认：解析后检查材料范围，形成提纲后允许调整，最终结论展示来源并支持回到原文。人机协作不是妥协，它是早期建立信任和收集反馈的方式。
人工步骤也帮助定义未来自动化边界。反复被用户直接通过的检查可以逐步自动化，经常被修改的节点则说明模型或任务定义尚不成熟。
延迟与成本要从第一天可见
AI 产品的单位经济性不能等规模化再考虑。一次任务调用多少模型、消耗多少 Token、等待多久，都会影响产品是否可持续。
我们为每个节点记录耗时和估算成本，界面给出过程反馈并允许取消。独立任务并行，非关键审阅可以按配置关闭。超出预算时，系统返回已完成产物并说明缺失，而不是无限继续。
早期用户可能容忍几分钟等待，但等待必须可理解。看到系统正在检索和分析，与面对一个没有状态的加载动画，是完全不同的体验。
上线标准不是功能完成
两周结束时，我们检查的不是需求列表勾选率，而是主路径能否由非开发者独立完成；失败后能否知道原因；结果能否追溯到来源；系统能否在新材料上重复工作。
还要明确哪些部分只是临时能力。MVP 的技术债如果被写下来、拥有触发条件和替换方案，就是有意识的借款；如果团队假装它不存在，就会在下一阶段变成惊喜。
首版上线后，最重要的产物不是代码，而是一组更清楚的问题：用户真正重视哪一步，哪些自动化不被信任，成本主要发生在哪里，什么能力值得继续投资。
速度来自清晰，而不是加班
短时间交付常被归因于团队更努力。努力当然重要，但持续速度主要来自范围清晰、决策链短、主路径统一，以及每天都能获得真实反馈。
当产品、设计、架构和工程由同一个小团队紧密完成时，信息传递成本很低，代价是每个决定都必须更克制。没有大团队替错误方向分摊成本。
两周 MVP 最终证明的，不是我们能多快写完一套系统，而是能多快找到值得继续建设的部分。速度的真正对象不是代码，而是认知。
执行时我会每天更新一张范围账本，只有四列：今天必须证明的假设、最小用户路径、暂时手工完成的部分、明确不做的能力。新增需求必须替换一项，而不是无条件叠加。两周结束时交付的不只是演示，还有真实输入样本、失败案例、用户反馈、成本与延迟数据，以及下一阶段是否值得投入的结论。MVP 的价值是减少不确定性，不是制造一套缩小版大系统。
短周期里“哪些决定要谨慎、哪些决定可以快”是分开的：核心数据模型和对外契约仍然要按不可逆决定对待，我在创业阶段的技术决策里用可逆性表给它们分配了不同的讨论深度。