P1 原型验证
先给结论：1–2 周，做出一个能跑通核心链路的最小原型，让你在上生产之前先看到效果。
P1 不证明"我们能做出来"——那是必然的。P1 证明的是"这件事做出来，你的人会不会用"。
一、什么时候该做 MVP
三种情况，中一种就该做：
| 情况 | 具体表现 | 为什么先做原型 |
|---|---|---|
| 需求还不确定 | 三个部门说的痛点不一样，或者你自己也说不清"到底要它干什么" | 用两周把最可能的那条链路做出来，比开三次会更容易达成一致 |
| 想先看效果 | 知道要做什么，但不确定大模型在这个场景里准不准、够不够用 | 样本数据跑一遍，准确率是多少、错在哪，两周内能看到 |
| 内部还没共识 | 老板想做，业务部门觉得添麻烦；或者反过来 | 原型是唯一能终止争论的东西——让业务人员自己点一下 |
判断标准很简单：如果你能一句话说清"上线后谁每天用它做什么动作"，可以直接进 P2；说不清，先做 P1。
二、什么时候不该做
| ❌ 不该做 | 原因 | 该做什么 |
|---|---|---|
| 需求已明确，只差开发 | 原型会重复一遍生产开发的工作，多花两周 | 直接进 P2 |
| 只是想要个 demo 汇报 | 演示系统不需要权限、异常、并发，做了也不能用 | 用现成工具搭，别花钱 |
| 决策人还没定，做出来是给人看的 | 没人拍板就没有验收标准，原型会变成无底洞 | 先做 P0 诊断，把决策人拉齐 |
| 数据一条都拿不到 | 没有真实样本，原型只能编数据，验证不了任何东西 | 先解决数据，再来 |
三、交付物三样
- 能跑通核心链路的最小原型 —— 一个业务动作从输入到输出完整走通，可点击、可演示、可交给业务人员试用。部署在你方沙箱或我方环境，源码同步给你。
- 验收标准文档 —— 写清这个原型"算不算跑通"：输入什么、输出什么、什么算对、什么算错。这份文档会直接变成 P2 的验收清单初稿。
- 上线路径建议 —— 如果继续做，还差什么：要对接哪些系统、要补哪些权限、数据要清洗到什么程度、大概几周、大概多少钱。这一节会明确写出"不建议继续"的情况。
四、1–2 周时间表
十天，按天排。第 2 天结束时会有一个"要不要继续"的判断点，做不下去我们会在这里停，按合同约定结算。
| 时间 | 做什么 | 产出 |
|---|---|---|
| 第 1–2 天 | 现场跟岗半天，看业务人员真实怎么操作；确认核心链路、输入输出格式、样本数据 | 一页链路定义 + 数据样本清单。第 2 天下班前双方确认，确认后范围不再变 |
| 第 3–5 天 | 搭骨架：数据读取、模型调用、结果输出三段打通；先用最笨的方法跑通，不优化 | 端到端能跑，输出还很粗糙，但链路是通的 |
| 第 6–8 天 | 调效果：改提示词、加规则兜底、处理边界情况；每天给业务骨干看一次结果 | 准确率达到可试用水平；业务骨干开始提具体意见 |
| 第 9–10 天 | 交给业务骨干自己操作，我们在旁边记录卡点；补验收文档和上线路径建议 | 可试用原型 + 验收标准 + 上线路径建议 + 一次 60 分钟演示 |
每天一个 15 分钟同步，微信语音即可。不写周报，不开评审会。
五、MVP 验收三条标准
三条全过才算交付。缺一条，我们继续做，不加钱。
标准一：一个具体业务动作能在原型上完成
不是"能对话"，不是"能生成内容"，是一个能叫出名字的业务动作从头走到尾。例如：“把这张询价单变成一份建议报价单，业务员能直接发给客户。”
验收方式：业务骨干现场操作 3 遍，3 遍都完成，且结果可用。
标准二：至少 1 名真实业务人员试用过
不是我们演示给他看，是他自己上手用过，并且给出"愿意继续用"或"不愿意"的明确回答。
验收方式：试用记录，含试用人的姓名、岗位、试用次数、原话反馈（包括难听的话）。
标准三：明确"上线还差什么"
验收文档里必须有这一节，逐条列出差距：权限、异常处理、系统对接、数据清洗、性能、监控。每条标注预估工作量。
验收方式：这份清单你能看懂，并且认可它没有被刻意缩小。
六、价格与付款
| 项 | 内容 |
|---|---|
| 价格 | 按项目报价，诊断后书面给出。P1 单独计价，可与 P2 合并 |
| 付款 | 100% 预付，签约后 3 个工作日内 |
| 验收 | 按动手前约定的标准逐条核对，不达标调整至达标 |
| 工期 | 1–2 周（10 个工作日），从数据到位那天起算 |
| 超期 | 因我方原因超期，按合同约定承担违约责任（具体条款签约时确认） |
为什么 100% 预付：金额小、周期短，分期的手续成本比资金成本还高。而且预付让我们不用在第二周停下来谈钱——那两周的节奏经不起打断。
为什么原型阶段要先把验收标准写死：范围足够小，小到"做成什么样"可以提前讲清楚。标准写清楚了，双方都不用赌。
七、这个阶段不含什么
说清楚，免得后面扯皮。
| 不含 | 说明 |
|---|---|
| 生产环境部署 | 原型跑在沙箱，上生产属于 P2 |
| 真实系统对接 | 用样本数据或手工导入代替，真实接口对接属于 P2 |
| 权限与账号体系 | 原型通常只有单一角色 |
| 异常处理与兜底 | 只覆盖主链路，不覆盖所有失败情况 |
| 性能与并发 | 单用户、低数据量，不做压测 |
| 模型 API 费用 | 按实际用量另计，通常几十到几百元 |
| 硬件与软件授权 | 你自行采购，我们不加价 |
| 培训与文档（除验收文档外） | 完整的操作手册和培训在 P2 |
超出以上范围的，属于新需求，另签补充协议。
八、下一步
想清楚要不要做 P1，最快的办法是先做 P0 诊断——免费，90 分钟，我们会直接告诉你该走 P1 还是直接上 P2，或者不用做。
打 18920966306（微信同号）。天津同城可到场，外地远程。报价方式见 服务与交付，权限边界见 驻场与权限。
常见问题
P1 原型和 P2 交付的区别是什么？
P1 交付的是「能证明核心链路可行的最小原型」，用脱敏样本数据、跑在你方沙箱或我方环境，不做权限体系、不做异常处理、不做性能优化。P2 交付的是「能上生产、能被真实业务连续使用的系统」，包含完整的权限、异常处理、监控、文档和培训。P1 的代码可以复用进 P2，但通常需要重写一部分——因为原型阶段刻意省略的正是生产必需的部分。
一个小原型能做出什么程度的东西？
一个核心业务动作能从输入跑到输出。举例：把一份非结构化的客户询价单读进来，匹配历史报价和库存，生成一份建议报价单。这条链路能跑通、能看到效果、能让业务人员点着用。但只有一个角色、一条链路、没有登录权限区分、没有异常兜底、没有和你的 ERP 真实对接（用样本数据代替）。
如果原型做出来不满意怎么办？
原型交付后按事先约定的验收标准逐条核对。不达标的，我们调整到达标为止；如果调整后仍无法达标，按合同约定处理。原型阶段的验收标准在动手前就会写清楚，避免事后扯皮。
原型做完发现方向错了，钱是不是白花了？
不是。这正是 P1 存在的意义：用两周和一笔小投入，换掉一个可能持续两个月的方向性错误。我们在 P1 阶段遇到过不少客户改变方向，其中大部分是「发现真正的痛点不是最初以为的那个」。这个结论本身就值回票。如果结论是「不该做」，我们会在验收文档里直接写出来，并且不推荐进 P2。
原型能直接上线用吗？
不建议。原型刻意省略了权限控制、异常处理、并发、审计日志、数据备份这些生产必需项，直接上线会在第一次出错时暴露问题。原型上线要走的改造清单，会在验收文档的「上线还差什么」一节里逐条列出，通常需要 3–6 周，也就是 P2。
1–2 周时间够吗？会不会是糊弄？
够，但前提是范围足够小：一个核心动作、一个角色、一条链路、样本数据不超过 200 条。范围一大就做不完，所以立项时我们会把范围写死，超出范围的部分放进「上线还差什么」清单而不是硬塞进原型。如果评估后发现两周做不完，我们会在立项前告诉你，而不是做到一半再延期。
P1 阶段需要我们提供什么？
三样：1 名业务骨干（每周 2 次、每次 1 小时，两周共约 8 小时）、测试环境只读账号或 10–100 条脱敏样本数据、一个能部署原型的沙箱环境（我方提供也可以）。不需要生产环境任何权限，不需要 IT 部门配合，不需要采购。
先聊清楚问题，
再谈要不要做
90 分钟诊断会，免费。我们会告诉你这件事值不值得做、大概多少钱、以及——如果结论是"不该做"，也会直接说。
