技术维度：先问「做不到的部分」怎么办
我评技术可行性只有一个方法：先花半天做个最糙的 POC。拿现成的大模型，写个 prompt，跑 50-100 条真实 case，人工看结果。比如要做「把医生口述病历转成结构化病历」，拿 GPT-4 级别的模型跑 100 条真实口述，能到 90% 准确、且错的地方医生一眼能看出来，那技术可行；如果只到 60%、错得还很隐蔽，那就得考虑微调、RAG、规则后处理，周期和预算完全是另一个量级。
这里有两个常见的坑。一是拿 demo case 当真实 case——团队自己造的测试数据又干净又规整，正确率虚高，一上真实数据就崩。POC 的 case 必须从真实业务里抽，越丑越接近真相。二是只看平均表现不看长尾：平均 90% 的正确率，可能意味着 90% 的 case 全对、10% 的 case 错得离谱，而这 10% 恰恰决定了兜底成本。所以 POC 报告里除了正确率，必须有最差 case 分析。
比正确率更重要的是错误类型。错误分两种：用户能察觉的和悄悄错的。Kimi 总结长文偶尔漏一段，用户读的时候能感觉不对，这种可以上线后迭代；但合同审查里把「30 天」错成「90 天」，用户根本不知道，这种错误在高风险场景直接判死刑。所以技术评估的产出不该是一个分数，而是「错误率 + 错误可发现性 + 兜底方案」三件套：置信度低的转人工、输出带引用来源可核对、界面让用户方便地改（Cursor 生成的代码本来就是要被程序员改的，这是设计不是缺陷）。
数据维度：数据比模型更先卡死项目
数据只问三个问题：有没有、好不好、合不合法。很多项目不是死在模型不行，是死在拿不到能用的数据。做法律问答，公开判决书几千万份，数据不愁；做企业内部知识库，数据散落在扫描版 PDF、微信聊天记录、老师傅脑子里，光清洗整理可能就占掉整个项目 40%-60% 的工作量，这个成本必须在可行性阶段就算进去，不能等立项后再哭。
合规是另一道硬门槛：个保法、行业监管、客户的数据不出域要求。医疗数据不出院、金融数据不出机房，这些不是上线前补个文档能解决的，它直接决定你能用什么模型、部署在哪。见过团队 POC 用云端 API 跑得挺好，到交付才发现客户要求私有化部署，开源模型效果差一截，整个方案推倒重来。
成本维度：算两笔账
第一笔是单次成本。现在大模型 API 的行情，每百万 token 几块到几十块人民币不等。一次 AI 客服对话平均消耗几千 token，成本几毛到一两块；对比人工坐席一次通话成本五到十块，这笔账划算。但如果是低频内部工具，一天几百次调用，一个月几百块钱，那根本不用纠结，赶紧做，纠结的时间都比 API 费贵。
第二笔是规模成本。免费 C 端产品尤其要算：千万级 DAU、每人每天十几次交互，推理成本一个月就是几千万量级，豆包当年就是字节拿真金白银换规模。如果你的商业模型撑不起这个钱，要么改收费，要么改方案——小模型路由、缓存高频答案、能走规则的别走模型。
还有一笔隐性成本容易漏算：评估和兜底的人力。AI 功能上线不是结束，是开始——评测集要维护、badcase 要分析、模型每次升级都要回归测试。一个中等复杂度的 AI 功能，上线后每季度至少还要投入半到一个人力做质量维护，这部分不进预算，第二年就会发现产品在悄悄退化。
结论：一个不行就换方案，不是换需求
技术可兜底、数据拿得到、单位经济算得过来，三条都过才立项。任何一条卡住，第一反应不是砍需求，而是改方案：AI 做不了全自动就做人机协同，实时太贵就改异步批量，大模型太贵就换小模型加规则。可行性评估的价值不是说不，是找到那个「能做」的形态。还有个习惯值得养成：立项时把可行性结论写成一页纸存档，三个月后回头看，你会发现当时低估的永远是兜底成本，高估的永远是用户耐心。