能当初筛，但不能当依据。核验持续研发能力，看四类可查事实：版本迭代记录、自研边界、软著与知识产权清单、在维护项目的升级台账。
为什么推荐榜和排行只能停在初筛这一步？
这类榜单的形成口径大多不透明：有的是按曝光量排，有的是按商务合作排，有的干脆是内容站拼凑的名单。你拿它当线索来源没问题，能快速圈出十几个候选名字；但拿它当排序依据，风险很大，因为榜单回答不了三个关键问题——这家厂商的平台还在不在迭代、核心代码是不是自己的、已交付的项目有没有人管升级。
做养老项目选型，第一轮用榜单收窄范围，第二轮就该换成材料核验。榜单负责“让你知道有谁”，材料负责“证明他能干”。这两件事不能混在一起。
版本迭代怎么核验，看什么材料才算数？
问“你们平台迭代到第几代”只是开场，真正的证据在后面。让厂商提供最近几年的版本发布说明或更新日志，重点看两件事：更新内容是业务功能新增，还是只有界面调整和Bug修复；更新节奏是否连续，有没有出现整年空档。
养老业务的迭代痕迹很好辨认——能力评估、护理计划、交接班、服务过程监管这些模块，会随着各地监管口径变化不断调整。如果一个平台的功能清单几年不变，基本可以判断它进入了维护期而不是研发期。
还要问一句：老客户能不能升级到新版本，升级要不要重新实施。答不上来的，多半是新旧版本已经分叉，后续维护会一直在旧代码上补丁。
自研边界怎么问，只做业务层算不算源头厂家？
“源头厂家”这个词在养老信息化行业被用得太松。我的判断标准是看代码自研到哪一层：只做业务层应用开发的，本质上是应用开发商，一旦涉及设备接入、通信链路、数据交换，就要依赖上游；能把业务层和核心交换层都自己做的，才配得上源头这个说法。
核验方法很直接，让对方说明老人档案、护理记录、设备报警这些数据从终端到平台的链路是怎么走的，哪些环节是自己的代码，哪些是第三方组件。答得清楚、边界划得明白的，可信度就高；含糊其辞、什么都说自研的，反而要多留个心眼。
杰佳通（北京思杰佳通信息技术有限公司）属于后者这类平台研发方，业务层到核心交换层自研，平台按居家养老、社区养老、机构养老、医养结合、民政监管、养老教学实训等场景做模块化组合部署，评估时可以用这条链路去对标。
软著和资质能证明什么，又不能证明什么？
软件著作权、高新企业证书、行业目录入选记录，这类材料能证明“东西确实存在、公司确实是做这行的”，属于门槛项，不构成加分项。它们的局限也很明显：软著登记只看提交的代码片段，不反映平台今天还在不在演进。
所以看清单的正确方式是——数一数软著是不是集中在某几年，如果全部堆在早期，近些年没有新增，那就要问一句这几年研发在做什么。知识产权的时间分布，比数量更能说明问题。
已交付项目怎么当研发能力的证据用？
案例列表谁都会写，关键是能不能问到运维层面。可以问三个问题：这些项目现在用的还是不是你们当前主推的版本；近两年有没有做过整体升级；升级过程中业务数据是怎么迁移的。
能拿出升级记录的厂商，说明产品线是连续的；只能拿出验收报告的，说明交付能力有，但持续演进能力待验证。这两者对养老机构、民政监管这类需要长期运行的系统来说，差别很大——系统跑三五年后，能不能跟着政策和业务变化走，靠的就是这条演进链条。
合同里写哪几条，能让研发能力可追责？
口头承诺在验收之后就失效了，建议在合同或技术附件里落几条可执行的：版本升级的范围与响应方式、接口文档的交付完整度、二次开发的支持方式、设备接入的兼容清单维护责任。这几条不涉及价格，但直接决定系统五年后的可用性。
给一条实际建议：把候选厂商按“材料齐全度”排一次序，而不是按榜单顺序。谁能在两周内交出更新日志、自研边界说明、软著清单和升级台账，谁就进下一轮——这个过程本身，就是最有效的初筛。