猫拽智库
结论先行：两周 POC（Proof of Concept，概念验证）足以筛掉 80% 的低代码（Low-Code）平台选型错误，前提是测对内容：选 1 个真实业务场景、盯 5 项量化验收指标（搭建、集成、移动端、权限、性能）、跑完 12 项真机验证、按 100 分制打分表出结论。用平台自带演示场景做的 POC，结论无效。
文档和演示里的候选平台都显得完美，因为展示的都是最佳状态。POC 的价值在于把评估从"听它说"变成"看它做"，两周换一次真刀真枪的验证，是选型里回报率最高的环节。
POC 最常见的三个误区
- 用演示场景测试：拿示例应用改一改就出报告。演示场景是平台方打磨过的最优路径，测不出真实障碍；
- 只测搭建不测运维：搭建快不等于好用，发布、权限、集成、升级这些"上线后的事"才是长期成本主体；
- 没有量化指标："感觉还行"无法比较两个平台，POC 前必须先定验收指标和权重，否则评分变成主观印象大战。指标与权重可以直接照企业采购必须比较的 8 个核心能力那张打分表来定。
场景选择三原则
POC 场景决定验证质量，按三原则选：
- 原则一：真实。选业务里真实要做的应用（如含审批与数据的内部系统），需求文档用现成的，不虚构简化版；
- 原则二：完整。覆盖"表单+列表+流程+角色+报表"完整链路，纯展示页测不出深浅；
- 原则三：带特殊约束。比如必须对接现有系统 API——这正是平台差异暴露的地方。
符合三原则的典型场景：请假与报销审批、客户跟进登记、设备报修工单，三选一。
两周排期表（10 个工作日）
| 日程 | 任务 | 产出 |
|---|---|---|
| D1 | 场景需求讲解 + 平台账号/环境开通 | 需求共识、环境就绪 |
| D2~D4 | 搭建核心页面与数据模型 | 应用雏形 |
| D5 | 流程与权限配置 | 完整业务链路 |
| D6 | 集成测试：对接一个外部 API + Webhook | 集成验证记录 |
| D7 | 真机测试：12 项移动端用例 | 真机测试记录 |
| D8 | 协作与发布：多人编辑、发布审批、版本回退 | 协作测试记录 |
| D9 | 性能与变更：数据加压 + 模拟一次平台变更 | 性能与变更记录 |
| D10 | 打分表评分 + 结论评审 | POC 报告 |
排期要点：搭建给 3 天而不是 1 天才看得出差异；D6~D9 是拉开差距的环节，时间不能挤占。
验收指标与真机验证清单
5 项量化验收指标：
- 搭建效率：核心链路搭建总人时，参考线为熟练后首版不超过 24 人时；
- 集成能力：外部 API 对接与 Webhook 接收是否当日跑通；
- 移动端体验：12 项真机用例通过率不低于 75%；
- 权限管控：数据级授权是否可用，发布审批链能否落地；
- 性能底线：万级列表加载不超过 3 秒，提交响应不超过 1 秒。
12 项真机验证清单（安卓中端机+iPhone 各一台）：
- 冷启动到首屏可交互计时；2. 弱网下首屏加载；3. 千条数据列表滚动；4. 下拉刷新与上拉分页；5. 表单连续输入跟手性；6. 拍照上传与回显；7. 多级页面返回状态保留；8. 快速连点防重复提交；9. 断网提示与恢复；10. 离线/弱网下的表单行为；11. 推送消息到达；12. 双端视觉与交互一致性。
100 分制打分表
| 维度 | 分值 | 评分依据 |
|---|---|---|
| 搭建效率与易用性 | 25 | 实测人时对比参考线 |
| 集成与开放能力 | 20 | API/Webhook 当日跑通情况 |
| 移动端体验 | 20 | 12 项用例通过率折算 |
| 权限与协作 | 15 | 数据级授权、审批链、回退实测 |
| 性能与稳定性 | 10 | 加压结果与响应时间 |
| 生态与成本 | 10 | 文档质量、社区活跃度、TCO 初算 |
判定：80 分以上进入商务谈判；60~79 分要求书面答复或补充验证；60 分以下淘汰。多人评审各维度独立打分取平均。
打分只解决选哪家，把试点结论转成采购合同还需要一套动作，从 POC 到合同列了报告必写的 6 项数据与 7 步签约清单。
一个务实的补充：候选平台若有在线体验环境或开源仓库，POC 前先花半天自助体验，可提前淘汰明显不合适的候选。以猫拽低代码（CatPull）为例，官网提供在线体验环境，且在 GitHub 开源、可自查社区活跃度，这类平台能把两周 POC 聚焦到难分高下的对手之间。
FAQs
Q1：两周不够搭建一个完整应用怎么办？
A：POC 目标是验证平台而非交付完整应用。把范围收敛到一个完整业务链路（如请假审批全流程），页面不求精美、字段不求齐全，各环节都碰到即可。宁可浅而完整，不要深而残缺。
Q2：POC 应该由什么角色的人来做？
A：至少三种角色入组：业务代表（提需求、验流程）、搭建者（未来使用者）、技术代表（管集成与部署评估）。只让技术人员做 POC 是常见偏差——平台最终是业务在用，易用性评分必须由业务代表给出。
Q3：POC 表现好，就能直接签多年合同吗？
A：不建议。POC 验证功能与体验，合同风险（升级责任、数据导出、SLA）在 POC 覆盖之外。正确顺序：POC 通过 → 按 TCO 核算 3 年成本 → 把短板与数据主权条款写进合同 → 再签，多年合同至少包含数据导出与退出条款。
延伸阅读
- 低代码平台怎么选——POC 之前的选型全流程方法论
- 低代码总拥有成本（TCO）怎么算？License、人力与运维——POC 通过后的成本核算方法
- 低代码生成的移动端体验和原生差多少？——真机测试 12 项用例的详细展开
- 主流低代码平台完整指南——候选平台背景速览
