从外卖比价App的三份AI评估报告说起：别再把「技术可行」当成项目可行

前言

最近在构思一款跨平台外卖比价App，先后用三个主流大模型做了完整的项目可行性分析。本以为只要技术上能实现，项目就有落地空间，结果三份输出结论差异极大——有的给出了从MVP到规模化的完整落地方案，有的经过多轮推演后不断退而求其次，最后给出的方案已经完全背离了产品初衷。

复盘下来发现一个非常典型的误区：很多人向AI咨询项目可行性时，默认只问「技术上能不能做出来」，却忽略了法律合规、平台对抗、用户体验、分发门槛、商业回报这些更核心的维度。更关键的是，大模型本身就有一个天然缺陷：它只关心方案「合不合理、能不能做」，却很少判断「值不值得做、用户会不会用」。技术可行，从来只是项目的最低门槛，而非可行性的全部。

本文就以这次外卖比价App的三份评估输出为样本，逐一拆解各模型的分析质量，总结做项目可行性评估必须覆盖的核心维度，给所有想靠AI做项目论证的开发者、创业者一个参考。

一、三份AI评估输出质量对比与拆解

三份输出分别从不同视角出发，覆盖维度、风险尺度、结论偏向差异极大。其中Gemini与豆包为一次性完整报告，DeepSeek为多轮对话动态推演，先通过总览表格快速建立认知：

评估模型	核心结论	覆盖维度	合规风险判定	方案落地性	整体偏向
Gemini	推荐端侧浅层Agent方案，作为MVP完全可行	技术方案、产品路线、云端架构、商业化	仅提及隐私与反爬风险，未深入法律层面	给出完整MVP路线与AWS部署方案	产品落地导向，偏乐观
豆包	推荐后端服务聚合方案为核心，端侧仅作补充	业务方案、前端选型、AWS部署、风险评估、路线规划	判定为法律灰色地带，存在不正当竞争风险	分三阶段落地，从单EC2到分布式集群	工程实现导向，偏中性
DeepSeek	判定「选品阶段全自动比价」无法合规商业化，先后推出的手动输入、截图OCR等替代方案均无核心产品价值	技术、合规、分发、体验全维度动态校验	明确指出爬虫、自动化方案存在刑事犯罪风险	无符合原始需求的落地方案，替代方案价值极低	风险合规导向，极度保守，重技术合理轻用户价值

1.1 Gemini：产品视角完整，但合规与系统边界严重缺失

Gemini的报告核心思路是「在现有约束下找最优落地方案」，整体是典型的产品经理+技术架构视角，给出了从方案选型、云端架构、产品演进路线到商业化ROI的完整链路。

亮点：

1. 方案分层清晰，明确区分了纯云端API、深度端侧自动化、浅层端侧抓取三种路径的优劣，给出了MVP阶段的折中方案；
2. 配套了完整的AWS架构设计与分阶段产品演进Roadmap，CPS返佣的商业化逻辑自洽；
3. 给出了可执行的PoC验证步骤，符合「低成本快速验证需求」的产品思路。

明显缺陷：

1. 合规风险评估严重不足：仅将云端API抓取的风险归为「隐私安全问题」，对端侧自动化方案的法律风险、违反平台协议的后果几乎没有提及，完全未触碰到《反不正当竞争法》、刑法相关的红线；
2. 系统与分发边界认知模糊：没有提到iOS系统沙盒机制导致端侧Agent方案完全无法实现核心功能，也未提及应用商店对无障碍服务类应用的上架限制、国产安卓系统的后台管控问题，默认「能写脚本就能做产品」；
3. 对端侧方案的长期维护成本预估不足，严重低估了平台UI迭代对脚本稳定性的冲击。

整体来看，Gemini的报告适合做「产品功能设计参考」，但绝不能作为可行性决策的依据——它跳过了太多致命的非技术约束。

1.2 豆包：工程维度全面，合规风险偏温和化处理

豆包的报告是三份里维度最完整的单份报告，从核心业务方案、前端技术选型、AWS云端部署架构到风险边界、实施路线全覆盖，工程落地性最强。

亮点：

1. 对端侧Agent方案的缺陷分析最到位，明确指出了iOS系统级不可行、用户体验差、维护成本高、无法支持高并发等核心问题，直接否定了其作为核心方案的可能性；
2. 前端选型、AWS分阶段部署的内容非常扎实，从单EC2到分布式集群的演进路径清晰，成本、并发指标都有具体参考值；
3. 风险部分覆盖了反爬、匹配准确率、合规、个性化优惠券四大类，维度相对全面。

明显缺陷：

1. 后端爬虫方案的法律风险评估偏温和：仅将其定义为「法律灰色地带」，没有明确点明破解接口、批量爬取可能触及的刑事法律风险，弱化了合规问题的致命性；
2. 默认后端聚合方案「完全可行」，但实际上持续的反爬对抗成本、账号/IP池成本、法务风险，对小团队而言依然是极高的门槛，报告对长期维护成本的预估偏乐观；
3. 没有提及规模化运营后被平台起诉的实际案例与判赔风险，风险提示的警示性不足。

整体而言，豆包的报告是优秀的「工程实现指南」，技术架构和落地路径的参考价值很高，但在合规风险的权重上给得不够，容易让读者低估法律风险的严重性。

1.3 DeepSeek：合规最严谨，但方案价值持续走低，暴露大模型共性缺陷

与前两份一次性给出完整落地方案的报告不同，DeepSeek的输出是一场多轮往复的方案推演。它的合规尺度最严、风险判断最准，但也最典型地暴露了当前大模型做产品评估的通病：只关注方案的技术合理性与合规性，却不判断方案本身是否具备用户价值——只要能做出来、不违法，哪怕完全背离用户原始需求，也会被当作可行方案推荐。

整个推演过程中，模型先后给出了四套替代方案，每一套都在技术上「说得通」，但离用户想要的「一键比价、提升效率」的核心价值越来越远：

第一轮方案：手动输入比价工具

模型最早的合规折中方案，是让用户自己在三个平台查完价格，手动输入到App里，由App计算最终结果。
这套方案完全合规、开发成本极低，但完全背离了产品初衷。用户的核心痛点就是「切换平台比价太麻烦」，结果工具反而要求用户手动填数据，本质上是把用户的操作成本从「切换App看价格」变成了「切换App再输一遍价格」，没有节省任何精力，甚至更麻烦。用户直接指出「第一步根本没意义」，这套方案也就随之作废。

第二轮方案：WebView注入式比价App

被否定手动方案后，模型提出了「内嵌WebView加载平台网页版，注入JS自动提取结算页价格」的方案，声称这是移动端唯一可行路径。
但这套方案建立在一个完全错误的前提之上：它默认美团、饿了么、京东外卖都有功能完备的移动网页版。现实是三大平台均无可用的H5下单入口，现有网页仅做引流展示，无法完成加购、结算全流程。前提不成立，整套方案直接作废。这也暴露了大模型的另一个问题：很容易基于想当然的常识假设给出方案，缺乏对现实业务环境的核实。

第三轮方案：截图+OCR识别

网页版路径走不通后，模型又主推「截图OCR自动识别」作为MVP方案，认为这是当前最合规、最易落地的路径。
这套方案的逻辑是：用户手动打开每个平台的App、选品、进入结算页，然后截图，App自动识别价格并汇总。但它依然没有解决核心价值问题：用户都已经走到结算页了，肉眼直接就能看到价格，为什么还要多一步截图操作？所谓的「自动识别」，只是省去了用户心算加减法的步骤，却增加了截图的操作成本，对于追求效率的用户来说完全是多此一举。用户再次指出「OCR也没意义，我都到结算页面了，还需要截图给你看吗」，直接戳破了这套方案的价值泡沫。

最终收敛方案：结算页智能算价工具

在连续被否定后，模型最终承认「选品阶段自动比价」无法合规实现，给出了最后的替代定位：「结算页一键算价工具」，主打帮用户计算复杂优惠组合、挖掘隐藏优惠券。
这套方案依然停留在决策末端，用户必须手动进入每个平台的结算页才能使用，本质上只是一个带OCR的计算器，和用户最初设想的「一键比价、辅助选品」的产品形态已经相去甚远，价值增量非常有限。

整体评价：风险合格，产品价值维度严重缺位

亮点：

1. 合规风险判断最严格，明确点明了爬虫、自动化方案的刑事法律风险，能有效帮创业者避开法律红线；
2. 能够跟随用户质疑推翻自身结论，不会硬撑错误前提，推演过程相对诚实。

核心缺陷：

1. 产品价值判断严重缺失：多次推出看似合规、技术可行，但毫无用户价值的方案。大模型只会在「合规、技术可实现」的框架里找解，却不会站在用户角度反问：「这个东西真的比手动操作更好用吗？用户为什么要为它下载一个App？」
2. 前提假设容易脱离现实，默认外卖平台有网页版这类不符合实际业务现状的判断，会误导没有行业经验的开发者；
3. 工程落地指导薄弱，相比豆包完整的架构与部署方案，DeepSeek的技术落地内容零散且参考性低。

这份推演最大的警示意义在于：大模型给出的「可行方案」，很多时候只是「技术上能做出来、不违法」，并不等于「用户会用、有商业价值」。如果不加判断地照单全收，很容易做出一个技术正确但没人用的产品。

二、核心误区：「技术可行」从来不等于「项目可行」

这次评估最直观的感受，就是很多人（包括我一开始）对「可行性」的理解太窄了——默认只要代码能写出来、功能能跑通，就是可行。但实际上，技术可行性只是所有可行性维度里，门槛最低的那一个。

就像DeepSeek多轮推演里反复出现的情况：方案技术上都能跑通Demo，但要么违法、要么上不了架、要么用户用一次就卸载、要么维护成本高到赚不回来。一个真正能落地的商业项目，至少要过五重关卡，缺一不可：

2.1 法律合规关：商业项目的绝对底线

很多技术人做项目时，只会想「技术上能不能实现」，不会想「法律上允不允许」。就像外卖比价这个场景：

• 服务端逆向API、破解签名，不是简单的「违反平台协议」，而是可能触犯非法获取计算机信息系统数据罪，面临刑事责任；
• 端侧自动化脚本操控其他App，属于妨碍、破坏其他经营者合法提供的网络产品或者服务正常运行，违反《反不正当竞争法》，面临巨额民事赔偿；
• 哪怕是看似安全的「浅层抓取」，只要规模化运营、影响到平台利益，就有被起诉的风险。

永远记住：合规不是「会不会被抓到」的概率问题，而是「能不能承受最坏结果」的底线问题。对于正规创业项目，触碰刑法红线的方案，技术再完美也直接排除。

2.2 平台对抗关：不是一次性技术问题，是持续的成本黑洞

很多可行性评估只会算「一次性开发成本」，不会算「长期维护成本」。

• 爬虫方案要持续对抗平台的反爬策略：IP封禁、签名升级、设备指纹、人机验证，每一次平台升级，都要投入人力破解，每月代理IP、账号池、打码服务的成本就是几万起步；
• 端侧Agent方案要跟着平台App的每次UI改版改脚本，还要适配不同品牌、不同系统版本的手机，维护成本是无底洞。

这种「军备竞赛」式的维护，对小团队来说是致命的——你花一个月做出来的功能，平台一次版本更新就可能全失效。

2.3 用户价值关：背离核心需求的方案，做出来也没人用

这也是AI做可行性评估最容易翻车的地方：它总能在约束条件下找到一个「能做出来」的方案，却不会判断这个方案有没有解决用户的真实痛点。很多AI推荐的折中方案，本质上都是为了技术自洽而牺牲产品价值，做出来只是一个「正确的废品」。

产品的核心价值是「给用户提供便利」，但很多技术方案为了实现功能，反而给用户添了更多麻烦：

• 深度端侧Agent：比价一次要等几十秒，手机全程被占用，用户体验还不如手动切App；
• OCR截图比价：用户要手动切三个App、截三张图，最后App只帮你算个加减法，完全是多此一举。

这些方案技术上都能做，但用户用一次就会卸载，因为它没有解决「比价麻烦」的痛点，反而把麻烦换了一种形式。判断方案行不行，先问自己：和用户手动操作比，这个方案真的更省事吗？

2.4 分发落地关：做出来≠用户能拿到

很多方案在测试机上跑得好好的，真要上线就处处碰壁：

• 依赖无障碍服务的应用，主流应用商店基本不让上架，只能走侧载，用户下载成本极高；
• 国产安卓系统的后台管控，会直接杀死无障碍服务，功能时灵时不灵；
• iOS端干脆从系统层面就不支持跨应用自动化，一半用户直接覆盖不到。

技术实现只是第一步，能不能正常分发、能不能稳定运行、能不能覆盖目标用户，都是实打实的落地门槛。

2.5 商业回报关：成本能不能覆盖收益

最后回到商业本质：这个项目赚的钱，能不能覆盖成本？

• 看似成本很低的端侧方案，长期维护成本会吃掉所有利润；
• 看似体验好的后端方案，代理IP、反爬对抗、法务风险的成本，远高于CPS返佣的收益。

很多项目技术上完美，体验上优秀，但就是算不过账来，最终只能死掉。

三、向AI咨询项目可行性时，正确的提问方式

很多人得到的评估报告质量差，本质是提问方式错了。你只问「这个技术能不能实现」，AI自然只会给你讲技术可行性，甚至为了给出一个「答案」，强行推荐毫无价值的折中方案。

如果想得到真正有决策价值的评估，一定要主动引导AI覆盖全维度，推荐按这个框架提问：

1. 法律合规维度：这个方案是否违反现行法律法规？是否违反目标平台的用户协议？风险等级如何，是否存在刑事风险？
2. 全周期成本维度：除了初始开发成本，持续维护成本有哪些？是否存在持续的平台对抗成本？年维护成本大概是什么量级？
3. 用户价值维度：这个方案的完整操作流程是什么？和用户手动完成相比，效率提升了多少？是否存在为了实现功能反而增加用户操作负担的情况？
4. 分发落地维度：这个方案能否正常上架主流应用商店？是否存在系统层面的限制？不同平台（iOS/安卓）的兼容性如何？
5. 商业化维度：主流的盈利模式有哪些？对应成本结构下，回本周期大概多久？是否存在盈利模型跑不通的风险？

只有让AI把这五个维度都讲透，得到的可行性结论才有参考价值，而不是一个片面的「技术上可以实现」，更不是一个看似合规却没人会用的「正确废品」。

写在最后

这次三份AI输出的对比，尤其是DeepSeek的多轮推演，其实也折射出了当下用AI做项目论证的通病：大家很容易沉迷于「技术能不能实现」的兴奋里，却忽略了真实世界里的种种约束，更忘了产品最本质的问题——用户到底需不需要。

技术从来都只是工具，不是项目的全部。一个真正能落地的项目，从来不是「技术上最酷的那个」，而是在合规、体验、成本、商业之间找到平衡的那个。

希望这篇文章能帮大家避开「技术可行=项目可行」的坑，下次再用AI做项目评估时，记得多问几句法律、成本、体验和用户价值，别等代码写了一半，才发现做出来的东西根本没人用。