这篇回答交付双方都关心的节奏问题，立场是：PoC 的时长是范围决策的结果，不是自然流逝。
最值得拿走的是时长公式：两到六周对应「一个场景、一组硬验收标准、数据基本就绪」。超过八周的常见原因依次是场景没锁定、验收标准模糊、数据就绪度被高估。最容易误用的做法是把 PoC 当成无风险试探无限拉长，双方成本都在烧。
相比站内的验收清单，这篇回答的是更上游的问题——多久以及为什么，并给出「何时放弃 PoC 直接谈试点」的判断。再补一个预期管理：两到六周指的是从数据就绪到出结论的窗口，商务谈判与入场准备不计算在内；排期时要把这两段时间明示出来，避免双方对时长的认知错位在第一天就埋下。补充一个双方约定的技巧：把「数据就绪」写进 PoC 启动的前置条件并附明确日期，超期自动顺延，这一条能消解大部分的排期纠纷。
读完建议做一件事：检查你当前 PoC 的三要素，缺哪项就先补哪项再谈时间表。
—— FDEChina编辑部 · 实战派
PoC 要做多久才合理？
直接回答：大多数场景下，两到六周是一个合理的区间；超过八周的 PoC，问题通常不在技术，而在范围失控。行业里的普遍观察是，PoC 拖得越久，越难收场——客户的耐心、预算窗口和你的团队产能都在消耗，最后往往以不了了之告终。所以更有价值的问题是：是什么决定了一个 PoC 该多长？
三个决定因素。第一，范围是否锁定：一个 PoC 只应该验证一个场景的一个核心问题——「大模型在我们这类工单上能不能达到可用准确率」就是好问题，「大模型能在我们公司做什么」不是。第二，验收标准是否先行：上线前就写清楚用哪个数据集、达到什么指标、由谁判定通过，标准谈不拢的 PoC 做多久都不会有结论，具体的验收条款设计见 PoC 验收清单。第三，数据就绪度：客户承诺的数据两周后才到，PoC 时长就要如实顺延，并且要在启动时就说清楚，而不是默默吞下延期。
压时长的三个手段，按优先级排列。第一，砍窄：把「全量数据、完整流程」换成「有代表性的子集、贯穿一层的最小链路」，PoC 的目的是验证可行性，不是交付系统。第二，评测集先行：先花几天和客户一起把评测集建好，后面的迭代全部对着评测跑，避免「感觉不错」式的拉锯，方法见 评测基线手册。第三，周度对齐：每周向客户同步进展与风险，问题当周暴露，而不是最后一周集中爆炸，机制见 FDE 报告手册。
两个补充判断。其一，如果发现 PoC 的范围已经明显超出验证目的——客户其实想要的是生产系统——不要硬撑，诚实地把对话升级为「小试点」：更长的周期、更明确的商业条款、更完整的交付责任，见 术语库中 PoC 与试点项目的区别。其二，反向情况也一样：如果一个场景两周期满、结论是模型能力确实不够，就干脆地关闭它并留下书面结论与数据，下次技术更新时再评估——干净地失败一次，好过模糊地拖半年。范围谈判的整体方法，见 范围界定手册。