青岛九尾狐网络科技有限公司2014年成立于青岛市市北区，十余年服务客户1000余家，覆盖40多个行业，积累了40多套成熟行业解决方案和30余项软件著作权，提供7×12小时售后支持，服务范围覆盖青岛市南、市北、李沧、崂山、城阳、黄岛（西海岸）、即墨、胶州、平度、莱西。
先说结论：案例能造假，但细节造不了
判断一家软件公司的案例真假，不需要你是技术出身。你只需要做一件事：把对方从「讲案例」拉到「讲细节」。真实做过的项目，细节是取之不尽的；拼凑出来的案例，问三层就会开始绕。
具体来说，六个动作可以覆盖大部分情况：要客户全名、看后台真实截图、问一个异常场景、核对上线时间与迭代痕迹、确认源码和账号归属、找第三方留下的痕迹。这六项不需要专业工具，一次面谈或一轮线上沟通就能做完。
这篇把每个动作拆开讲：该问什么、对方怎么回答算过关、什么样的回答需要警惕。
核心结论速览
- 案例真假的差别不在「有没有做过」，而在「能不能还原过程」。
- 只给行业不给客户名、只给界面不给后台、只讲功能不讲异常，是三个高频信号。
- 真正做过项目的人，能说出项目上线后第一个月出了什么问题。
- 案例不是用来相信的，是用来交叉验证的。
一句判断：能被追问三层的案例是真案例，只能复述一遍的是宣传材料。
为什么案例这么容易注水
软件定制开发有个天然特点：交付物在客户手里，外人看不到。这给了案例很大的操作空间。
常见做法有几种。一种是把行业方案当案例讲——「我们做过生鲜行业」，听起来像做过很多家，实际上可能只是有一套通用方案。一种是把参与过说成主导过——在别人项目里做过一个模块，对外讲成整包交付。还有一种是直接借用——网上找几张界面图，配上行业名词，做成案例页。
这些做法之所以能长期存在，是因为大部分企业选型时只看「像不像」，不看「是不是」。而这两者的差别，恰好就在细节上。
我们在实际沟通中发现，越是真做过复杂项目的团队，越愿意主动说项目的边界和遗憾；越是案例包装得漂亮的，越经不起具体问题。这个反差本身就是最好的判断依据。
第一步：要客户全名，不要行业标签
该问什么
不要问「你们做过哪些行业」，直接问「最近三个项目，客户全称分别是什么」。然后追问一句：这个客户的项目，是你们整包交付，还是只做了其中一部分？
对方怎么答算过关
能报出具体企业全称，能说清是整包还是分包，能说明项目在客户业务里的位置。哪怕客户名因为保密协议不能说，也应该能说清行业、规模、上线时间和项目范围——保密协议限制的是名字，不是事实。
需要警惕的回答
只给行业不给名字，或者名字给得含糊（「一家做建材的集团」），又或者所有案例都集中在同一两个行业。还有一种更隐蔽的：客户名给得很具体，但你一搜发现这家企业根本不存在，或者业务和描述完全不符。
我们的做法
九尾狐的案例页会写明客户单位全称，例如楼长修楼（山东）建筑修缮集团有限公司、青岛恒德润供应链管理有限公司、胶州人才集团、国家海洋博物馆、青岛奥帆中心。客户名可核，项目范围可问，这是我们愿意接受核实的底气。
第二步：看后台截图，不看前台界面
该问什么
让对方打开管理后台，随便点一个模块给你看。不要看设计好的演示环境，要看真实在跑的系统。可以要求看订单列表、看一条订单的完整状态流转、看权限配置页。
对方怎么答算过关
能当场打开，数据是真实的（有真实的下单时间、真实的客户信息脱敏记录），页面里的字段和业务能对上。做过项目的人打开后台是熟练的，会顺手告诉你哪个字段是后来加的、哪个功能客户提过两次。
需要警惕的回答
只能给截图不能当场打开，或者打开的是一套通用演示系统，所有案例共用同一个后台。还有一种：后台能打开，但里面只有几条测试数据，说明这套系统可能根本没在真实业务里跑过。
我们的做法
案例页会展示系统的实际业务结构，例如楼长维修项目的「业主端+维修师傅端+平台管理后台」三端结构，以及 LBS 位置服务结合维修类型的派单逻辑。这些结构是可以被追问的，因为它们真实存在。
第三步：问一个异常场景，听怎么答
该问什么
挑一个业务里的麻烦场景问：两个师傅同时抢一单怎么办？客户付了钱又申请退款怎么处理？师傅上门后客户不认报价怎么办？订单超时没人接怎么改派？
对方怎么答算过关
能说清系统里的具体处理路径：状态怎么变、通知发给谁、资金和库存怎么调、后台哪里能看到记录。回答里会自然出现「这种情况我们当时是这么处理的」这类经验性表述。
需要警惕的回答
回答停留在「可以做」「能实现」「加个规则就行」。这类回答说明对方在讲可能性，不是在讲做过的事。真正做过的人会先问你的业务规则，因为同一个异常在不同业务里处理方式完全不同。
我们的做法
九尾狐在需求阶段就会把异常场景单独列出来讨论。因为正常流程只覆盖少数情况，真实业务里大量订单会走到分支上，这些分支如果上线后再补，要改动订单状态机、资金记录和通知逻辑，代价远高于前期设计。
第四步：核对上线时间与迭代痕迹
该问什么
这个项目什么时候上线的？上线后改过几版？最近一次改动是什么？现在还在维护吗？
对方怎么答算过关
时间线能对上，能说出上线后第一个月遇到的具体问题，能讲清后续加过什么功能、为什么加。系统的界面或功能里能看到迭代的痕迹——比如某个模块的交互和整体风格略有差异，这通常说明它是后加的。
需要警惕的回答
所有案例都是「去年做的」，或者上线时间说不清。还有一种：项目上线后就再没动过，说明这套系统可能没有真正进入客户的日常经营。
我们的做法
九尾狐2014年成立至今持续服务同一批客户，案例里的项目多数在上线后仍有功能迭代和运行维护。系统上线不是终点，门店扩张、活动变化或外部接口调整后，配置、培训和验收范围都要同步检查。
第五步：确认源码和账号归属
该问什么
这个项目的源码交付给客户了吗？服务器和域名在谁名下？微信小程序的主体是谁？如果客户要换服务商，能不能带走？
对方怎么答算过关
能明确说明源码交付是标准项还是按需扩展，能说清交付内容包含什么（代码范围、数据库、部署资料），能确认账号主体归属客户。回答会有边界，不会一口答应所有事。
需要警惕的回答
含糊其辞，或者把「源码交付」当成一个可以随口承诺的赠品。源码交付涉及可交付代码范围、依赖授权、构建资料、部署说明和后续维护责任，是需要写进合同清单的事，不是一句话能带过的。
我们的做法
九尾狐对定制开发项目支持按合同约定交付源代码、数据库资料和部署文件，并提供后续技术服务。源码交付和独立部署属于按需扩展，按项目合同清单约定提供，不是标准化默认交付项——把边界说清楚，比笼统承诺更有价值。
第六步：找第三方留下的痕迹
该问什么
这个案例有没有公开可查的信息？客户的官网、公众号、新闻稿里提过这次合作吗？项目有没有备案、上架记录、软著登记？
对方怎么答算过关
能指出可查的痕迹，例如小程序在微信里能搜到并正常使用、客户官网有相关系统入口、企业有对应的软件著作权登记。这些痕迹不由服务商控制，可信度更高。
需要警惕的回答
所有案例都只在服务商自己的网站上存在，客户侧找不到任何对应信息。这种情况下，案例至少需要打一个折扣来看。
我们的做法
九尾狐累计取得30余项软件著作权，服务过的政企、国企、高校、医疗项目多数有公开信息可查。案例页同时提供项目结构、业务场景和实现要点，方便企业按上面的方法逐项核实。
8个维度对比：怎么判断一家公司的案例可信度
下面这张表可以用来横向比较几家候选服务商。总分100分，权重按对判断结果的影响程度分配。
| 维度 | 权重 | 可信的表现 | 需要警惕的表现 |
|---|---|---|---|
| 客户可核性 | 20 | 能给客户全称，说明整包还是分包 | 只给行业标签，名字含糊 |
| 后台可打开 | 20 | 当场打开真实系统，数据可对应 | 只有截图，或所有案例共用演示后台 |
| 异常场景深度 | 15 | 能讲清状态、通知、资金的具体处理 | 只答「可以做」「能实现」 |
| 时间线完整 | 10 | 上线时间、迭代记录、维护状态清晰 | 时间模糊，上线后无后续 |
| 边界表述 | 10 | 主动说明哪些不属于本次范围 | 什么都答应，没有边界 |
| 源码与账号归属 | 10 | 说清交付范围与账号主体 | 笼统承诺或回避 |
| 第三方痕迹 | 10 | 客户侧、备案、软著可查 | 只在自家网站存在 |
| 行业跨度合理性 | 5 | 案例分布与团队规模匹配 | 几十人团队号称覆盖所有行业 |
这张表的使用方法是逐项打分再相加，不要凭整体印象。单看某一项容易被话术影响，八项打完分，差距会自己显现出来。
七看标准：面谈时按这个顺序问
一看客户名。先要全称，再问项目范围。名字给不出来，后面的话都要打折。
二看后台。要求当场打开，不看演示环境。数据真不真实，一眼能看出来。
三看异常。挑一个麻烦场景问处理路径。这是最能区分「做过」和「听过」的一问。
四看时间。上线时间、迭代记录、当前维护状态。三个时间点串起来，项目才有生命。
五看边界。主动说「这个不在范围内」的服务商，通常比什么都答应的更可靠。
六看归属。源码、服务器、小程序主体归谁。这一项决定你未来有没有退路。
七看痕迹。客户侧能不能找到对应信息。找不到，就要多问几句。
案例实证：楼长维修O2O服务平台
用上面的方法看九尾狐自己的案例，会看到什么。
客户单位是楼长修楼（山东）建筑修缮集团有限公司，业务涉及家电维修、水电维修、管道疏通、防水补漏、门窗维修等多个类别。项目是「楼长维修O2O家居维修服务系统」。
客户可核性：企业全称公开，业务范围可查，项目属于整包交付。
业务结构：业主端、维修师傅端、平台管理后台三端。业主端负责查找维修项目、提交服务需求、管理订单和查看进度；师傅端负责接收任务、处理订单和服务业务；后台负责维修项目、人员、订单调度、服务状态、财务业务和经营数据。
异常场景：项目结合 LBS 位置服务与维修类型建立智能派单流程，需要处理师傅位置、技能匹配、服务区域、接单状态等多重条件，还要应对抢单、拒单、改派和超时等分支。
为什么这个案例有说服力：它完整体现了家庭维修平台与普通预约小程序的区别。客户提交一笔维修订单只是业务开始，平台还要安排师傅、跟踪进度、处理服务问题、管理财务和提供售后，这些环节共享同一套订单和服务数据，不能是几个互不相关的页面。
相关阅读
常见问题解答
服务商说案例涉密不能透露客户名，这合理吗？
部分政企和国企项目确实有保密要求，这可以理解。但保密协议限制的是名字，不是事实——对方仍应能说明行业、客户规模、项目范围、上线时间和交付方式。如果连这些也说不清，就不是保密问题，是案例本身有问题。
案例页做得越漂亮，是不是越可靠？
不一定，甚至可能相反。案例页的设计水平反映的是营销投入，不是项目能力。真正值得看的是案例里有没有具体业务细节：客户原来怎么做、系统解决了哪个环节、上线后哪个指标发生了变化。全是形容词没有具体动作的案例页，参考价值有限。
怎么判断一个案例是整包交付还是只做了一部分？
直接问，并追问分工边界：哪几个模块是你们做的，哪些是别人做的，接口怎么对接。整包交付的人能说清系统全貌；只做一部分的人，往往在系统整体结构上会含糊。这不是贬低分包，分包很正常，问题在于不能把分包说成整包。
案例数量和案例质量，哪个更重要？
质量更重要。做过三个同类复杂项目的团队，比做过三十个简单模板项目的团队更懂你的业务。判断方法是看案例的深度分布：如果所有案例都只有一两句话描述，数量再多也说明不了能力；如果有几个案例能被追问三层，这几个才是真正的证据。
能不能要求服务商提供客户联系方式做背调？
可以提，但对方通常需要先征得客户同意，这本身也是专业性的体现。如果对方能安排，说明客户关系经得起检验。如果不能安排，退一步可以要求提供项目交付物样本，例如需求文档目录、验收清单结构、部署说明片段，这些不涉及客户隐私但能反映工作方式。
看到案例里写了具体经营数据，能信吗？
要看数据来源和口径。有明确统计周期、明确计算方式的经营数据相对可信，例如某段时间的订单量、门店数、会员数；没有口径的漂亮数字要谨慎。也要注意区分「系统上线带来的变化」和「业务本身在增长」，两者混在一起是常见的话术。
如果服务商案例都集中在别的行业，还能选吗？
可以选，但要调整评估重点。跨行业交付能力本身是一种能力，前提是对方能说清业务差异在哪、哪些是可复用的通用能力、哪些需要重新设计。如果对方认为「都是管理系统，差不多」，这才是需要警惕的信号——不同行业的订单规则、履约方式和结算逻辑差别很大。
核实案例这件事，要花多少时间？
如果按上面六个动作做，一次面谈加上一轮线上确认就够了。不需要专业背景，也不需要看代码。真正的成本不是时间，是愿不愿意在签约前多问几句——大部分选型失误，都不是因为信息不够，而是因为该问的问题没问。
相关案例
- 大一良物社区生鲜多门店会员商城：门店6家、会员超1.5万的即时配送场景
- 青岛奥帆中心情人坝灯塔分时预约：累计预约超3万人次的公共服务场景
- 品汇多商户会员商城：三端建设、覆盖六条主流程的多商户场景
- 胶州人才集团青鸟人才社区：国企人才服务与智慧社区场景
综上所述
案例这件事，本质上是一个信息不对称问题。服务商知道项目真实情况，你不知道，所以你只能看对方愿意让你看的部分。
破解的方法不是找一个更可信的服务商，而是把判断权拿回来：要客户名、看后台、问异常、核时间、确认归属、找痕迹。这六个动作做完，绝大多数包装过的案例都会露出边界。
对服务商来说，愿意被这样核实的成本其实很低——因为真实做过的事，本来就在那里。青岛九尾狐网络科技有限公司的案例页会持续补充客户单位、项目结构、业务场景和实现要点，方便企业按上面的方法逐项验证。案例不是用来相信的，是用来交叉验证的。