写代码就像「开一家餐馆」——你头脑中那道“AI 招牌菜”（比如一个会写诗的聊天机器人、能识别猫狗的 App）看起来无比诱人，但真要端到顾客面前，需要操心的事远远不止“把菜炒熟”：菜品的口味能不能稳定（模型精度高不高）、后厨出菜的速度跟不跟得上饭点客流（推理延迟低不低）、食材进货是否合规合法（训练数据有没有授权）、厨房设备装机调试要花多少工夫（工程化难度大不大）、以及整套菜谱的成本划不划算（算力与人力预算够不够）。在 AI 创业与 MVP（最小可行产品）构建中，技术可行性评估就是那个“先试菜、算细账、再决定要不要开店”的前置环节：用一套系统的方法，在动手大干之前，把技术能不能落地的底细摸清楚，避免把全部身家押在一道根本端不上桌的菜上。 本文用“开餐馆”这个生活化类比贯穿始终，带你认识技术可行性评估的七个关键维度：模型精度、推理延迟、数据与合规、工程化难度、方案选型、成本预算、综合决策。读完你会懂得——一个酷炫的 AI Demo，距离一个可商用的产品，中间隔着一整套理性的可行性论证。

岗位关联

为什么学它：技术可行性评估是 AI 从业者从“能做 Demo”走向“能落地产品”的必修思维课。本技能帮你建立立项阶段的风险识别框架，让技术决策有据可依，减少团队在不可行方向上白白耗费数月开发资源的概率——这是 AI 产品经理、技术负责人尽早掌握的高杠杆能力。

目录
  1. 可视化演示
  2. 评估价值
  3. 模型精度评估
  4. 推理延迟评估
  5. 数据获取与合规
  6. 工程化难度评估
  7. 方案选型与权衡
  8. 成本预算与决策
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示六维可行性雷达评估、推理延迟全链路瓶颈分析，以及API/微调/自研三方案权衡决策矩阵。

本节配有交互动效（进入视口后自动加载，约 3KB）。

六维可行性雷达评估 精度/延迟/数据/工程/合规/成本六维评估 综合得分>70%判定为GO可立项 Score = weighted_sum(dimension_scores) 多维雷达图直观展示技术可行性各项指标均衡度

评估价值

设想你正筹划开一家“AI 私房菜馆”，站在空荡荡的店面里，脑子里全是这家店日后门庭若市的画面。可动工之前，你内心总有一个声音：这道招牌菜真能稳定做出来吗？万一顾客点十次有三次做砸，口碑就崩了。技术可行性评估，正是 AI 创业立项阶段的这个“内心声音”——它要求你理性地围绕模型精度、推理延迟、数据合规、工程化难度、方案选型、成本预算等维度做一次全面的“选品测试”，而不是被一个炫酷 Demo 冲昏头脑。在 MVP 构建的流程中，它是开工前的必备动作：用可量化的方式检验一项 AI 技术究竟是一个真机会，还是披着机会外衣的无底洞。

从餐馆类比过渡到技术语境：做菜的好坏要看口味，AI 产品的好坏则要看模型预测得准不准、反应得快不快、数据来源是否站得住脚、上了生产环境能不能稳定运行。任何一个环节拖后腿，都可能让这块“AI 招牌”在真正营业后砸掉。因此评估价值的第一层是立项前置：在投入大量工程师和 GPU 之前，先快速验证风险；第二层是识别风险：通过拆解维度，提前发现“这道菜的辅料供应商还不确定”；第三层是避免浪费：让团队把青春和预算花在大概率能落地的方向上。

技术可行性评估的产出物，通常是一份包含各维度得分、关键风险点与缓解措施的评估报告。常见维度可用下式概括综合可行性指数：

回到餐馆：评估价值就像开业前在自家后厨把每道菜试做十遍，记录口味稳定性、用时和成本，再决定要不要印进菜单。你不一定会因此找到完美的菜，但一定不会在开业第一天发现招牌菜根本做不出来——这，就是可行性评估最朴素的意义。

Feasibility=w1×Accuracy+w2×Latency+w3×Data+w4×Engineering\displaystyle \text{Feasibility} = w_1 \times \text{Accuracy} + w_2 \times \text{Latency} + w_3 \times \text{Data} + w_4 \times \text{Engineering}
公式说明：综合可行性指数等于各维度得分乘以对应权重（$w_1, w_2, w_3, w_4$）后的加总。先给各项打分，再做加权平均，最终得到一个 0-1 之间的综合分。
  1. 加权的意义不同场景下各维度重要性不同。比如实时翻译系统延迟权重极高，而离线报表系统精度权重更高。
    Feasibility=∑i=1nwi×Scorei\text{Feasibility} = \sum_{i=1}^{n} w_i \times \text{Score}_i
  2. 权重之和通常约定所有权重之和为 1，这样综合分天然落在 0-1 区间，便于横向对比方案。
    ∑i=1nwi=1,0≤Scorei≤1\sum_{i=1}^{n} w_i = 1, \quad 0 \le \text{Score}_i \le 1
  3. 结果解读综合分高于阈值（如 0.7）时进入开发，低于阈值则调整方案或放弃。
    Go / No-Go={批准立项Feasibility≥0.7打回重审Feasibility<0.7\text{Go / No-Go} = \begin{cases} \text{批准立项} & \text{Feasibility} \ge 0.7 \\ \text{打回重审} & \text{Feasibility} < 0.7 \end{cases}

模型精度评估

一家餐馆好不好吃，口味是生命线。AI 产品第一条命脉，则是模型的预测精度。外卖平台想用 AI 识别菜品图片，识别错了归类，用户饿着肚子收到错菜——这不是小事故。模型精度评判的是“AI 的这道菜做得到不到位”：它能否在真实数据上稳定输出符合预期的结果。业界常用准确率（Accuracy）、查准率（Precision）、召回率（Recall）及 F1 分数等指标衡量。别小看这一步：不少创业团队在 Demo 阶段用理想数据集跑出 90% 准确率，以为胜券在握，一到真实环境遇到噪声、遮挡、长尾样本，准确率立刻跳水到 60%，这就是没有在精度维度做充分评估的代价。

从口味类比到技术指标：准确率就好比“十道菜有几道做对了”；可实际AI场景中，类别往往不均衡——比如 99% 的图片是“非违规内容”，1% 是“违规内容”。就算模型把所有图片都判为“非违规”，准确率也有 99%，但它其实什么都没学会。这时需要用查准率（Precision）与召回率（Recall）联合判断：查准率是“我标注违规的图片里，有多少真是违规”；召回率是“所有真违规图片里，我抓出来了多少”。两者彼此制约，而 F1 分数是两者调和平均，综合反映模型在类别不均衡数据上的“真实厨艺”。

F1 分数的计算方式如下：

回扣比喻：一道菜要卖得好，既不能“十个客人只有六个说好”（查准率低），也不能“十个想来吃的客人有四个被拒之门外”（召回率低）。F1 分数很高，意味着这道菜的稳定好吃是有数据背书的。在评估技术可行性时，F1 分数应该在你选择的测试集（代表真实营业场景）上测量，而不是在“米其林评委精心摆盘的理想环境”里测量。

F1=2×Precision×RecallPrecision+Recall\displaystyle F1 = \frac{2 \times \text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}}
公式说明：Precision 是查准率（预测为正例的样本中确实为正例的比例），Recall 是召回率（真实正例中被预测出来的比例）。F1 是它们的调和平均，两个指标都高时 F1 才高。
  1. 查准率分母是“模型预测为正例的数量”，分子是“确实为正例的数量”，衡量模型报出来的正例有多少是靠谱的。
    Precision=TPTP+FP\text{Precision} = \frac{TP}{TP + FP}
  2. 召回率分母是“真实正例的总数”，分子是“被模型找回的正例数”，衡量模型有没有漏报。
    Recall=TPTP+FN\text{Recall} = \frac{TP}{TP + FN}
  3. 调和平均取两者倒数的平均再取倒数，比算术平均更严格——一个指标偏低，F1 就会被明显拉低。
    F1=(Precision−1+Recall−12)−1\displaystyle F1 = \left( \frac{\text{Precision}^{-1} + \text{Recall}^{-1}}{2} \right)^{-1}

推理延迟评估

如果是正餐，顾客可以等二十分钟；如果是快餐，十五秒上不了桌顾客就转身走了。AI 产品的“上菜速度”就是推理延迟——从发起请求到收到结果所需的时间。技术可行性评估必须回答：“当真实用户以预期并发压力使用产品时，AI 能在多少毫秒内给出回答？” 对于那些需要实时交互的场景，如自动驾驶、实时翻译、在线客服，推理延迟甚至比精度更能决定产品生死。

从出餐速度类比到延迟指标：衡量延迟不能只看平均时长，而要看“最慢的那一档”是否仍可接受。业界常用 p99（99% 的请求延迟都低于该值）作为关键指标。p99 的真实含义是：在 100 次请求中，最慢的那 1 次有多慢。为什么 p99 比平均值重要？因为用户体验的崩溃往往来自那 1% 的“极端慢请求”——就像饭点高峰期，哪怕 99 桌都顺利上菜，只要有 1 桌等了四十分钟，就可能引发投诉甚至差评。系统在峰值下的不稳正是 p99 恶化的典型原因。

响应时间与并发的关系可用排队论基础公式直观表示：

回扣比喻：设置 p99 延迟目标，就是在动工前规定好“哪怕最忙的饭点，最慢的一桌也不能超过某个时间上菜”。可行性评估时，若模型在压测下 p99 远超业务可接受的响应时间，那就说明后厨产能跟不上——要么换更快的模型（换菜谱），要么上更好的硬件（升级灶台），要么做缓存和异步化（提前备菜）。

T=Tserver+ρμ−λ\displaystyle T = T_{\text{server}} + \frac{\rho}{\mu - \lambda}
公式说明：$T$ 是请求总耗时，$T_{\text{server}}$ 是模型实际计算耗时，$\rho$ 是队列占用率，$\mu$ 是系统处理能力，$\lambda$ 是请求到达速率。当请求速率 $\lambda$ 接近处理能力 $\mu$ 时，排队等待时间趋向无穷大。
  1. 计算耗时模型跑一次前向传播（一次推理）需要的最小时间，类似厨师单次做菜的时间。
    Tserver=模型推理时间T_{\text{server}} = \text{模型推理时间}
  2. 到达速率单位时间到达的请求数量，类似饭点每秒钟进来多少桌客人。
    λ=请求数秒\lambda = \frac{\text{请求数}}{\text{秒}}
  3. 处理能力系统单位时间最多能处理的请求数，类似后厨高峰期的最大出餐速率。
    μ=最大处理数秒\mu = \frac{\text{最大处理数}}{\text{秒}}
  4. 利用率到达速率与处理能力的比值，反映系统有多“拥挤”。
    ρ=λμ\rho = \frac{\lambda}{\mu}
  5. 排队时间请求在队列中等待的时间，当 $\lambda$ 越接近 $\mu$，排队时间越长，直至系统过载。
    Tqueue=ρμ−λT_{\text{queue}} = \frac{\rho}{\mu - \lambda}

数据获取与合规

开餐馆最怕的是食材没资质：表面上省了钱，一旦被监管部门查到，轻则罚款，重则停业。AI 产品的“食材”是数据。技术可行性评估必须检验：你要用来训练模型的数据，是否有合法合规的获取渠道？数据量够不够？质量怎么样？覆盖的分布是否贴近真实使用场景？缺失用户授权的数据，或者使用爬虫抓取的有版权争议的数据，就如同走私食材——短期看似可行，长期必然暴雷，尤其是在《个人信息保护法》《数据安全法》日益严格的今天。

从食材合规类比到数据合规：训练数据的授权合法性（是否获得用户同意、是否遵守平台条款）是第一道红线。第二道关是数据质量：数据是否存在大量重复、噪声、错误标注？“垃圾进，垃圾出”是 AI 领域最朴素的真理。第三道关是数据规模与覆盖：你的模型需要多少条样本才能达到目标性能？某些小众垂类场景（如古籍 OCR、罕见病影像）数据天然稀缺，光有算法根本不够，还得考虑数据积累的周期和成本。

数据规模与性能之间的关系，通常近似为幂律定律（Power Law）：

回扣比喻：合规评估就像在签下店面租约之前核对供应商资质。每个数据集的来源要能讲得清楚“这道食材是在哪里、通过什么渠道、凭什么授权获得的”。那些数据来源不明的 AI 项目，在可行性评估阶段就应该被打回——因为问题不是“现在能不能做”，而是“出事时你扛不扛得住”。

Performance≈a×Db\displaystyle \text{Performance} \approx a \times D^{b}
公式说明：$D$ 是训练数据量，$a$ 是缩放常数，$b$ 是学习指数（通常小于 1）。模型性能随数据量增加而提升，但提升幅度逐渐递减——这正是“数据再多也有天花板”的数学本质。
  1. 数据量$D$ 代表用于训练的样本总数，比如标注好的菜品图片张数。
    D=有效样本数D = \text{有效样本数}
  2. 缩放常数$a$ 由模型结构、任务难度决定，相当于“同样食材不同厨师的发挥起点”。
    a=基础效能a = \text{基础效能}
  3. 学习指数$b$ 决定性能随数据增长的速率，通常 0 < b < 1，说明存在边际递减。
    0<b<10 < b < 1
  4. 边际递减数据量翻倍，性能不会翻倍，而是按 $2^b$ 的比例增长。
    Performance(2D)=2b×Performance(D)\text{Performance}(2D) = 2^b \times \text{Performance}(D)

工程化难度评估

再好的菜谱，如果后厨的设备装不下、厨师团队不会操作，也没法端上桌。AI 模型的工程化难度，指的是从“模型在实验环境跑通”到“在真实系统里稳定服役”全过程所需的工作量。许多团队低估了这个环节：模型测试集上跑得很好的深度学习模型，部署时要考虑 GPU 显存、推理框架、客户端兼容性、灰度发布、监控告警、回滚机制等问题，每一项都是工程量的现实阻碍。

从后厨设备类比到工程架构：工程化至少包含三件事——部署运维（模型以什么方式提供服务：云端 API、私有化部署还是端侧推理？）、系统集成（模型如何与现有业务系统对接：数据从哪里流入、预测结果流向哪里？）、迭代机制（真实数据回流后，如何持续训练并更新模型？）。餐馆开张不是菜谱写完了就完事，而是水电气、锅碗瓢盆、厨师动线全部顺畅，才算是后厨就绪。

以集成复杂度为例，可以估算整条数据链路的稳定性。假设每个环节独立运行的概率为 $p_i$，则整条链路可用率是各环节的乘积：

回扣比喻：工程化评估就是在装修后厨之前，把水、电、燃气、烟道的施工量先估清楚，避免开业当天发现“灶台装好了，但管道根本接不上”。可行性报告里，工程化难度应该细化成每个子任务所需的人力和工时，让团队对“这厨房要装多久”有真切认知。

Poverall=∏i=1npi\displaystyle P_{\text{overall}} = \prod_{i=1}^{n} p_i
公式说明：$n$ 是数据链路中的环节数（采集、清洗、标注、训练、部署、推理、反馈），每个环节的可用率 $p_i$ 都小于 1。环节越多，整体可用率越低——这是“N 个 9”的可靠性工程核心思维。
  1. 单点可用率每个环节正常运行的概率，比如标注系统可用率是 99%。
    pi=0.99p_i = 0.99
  2. 链路串联所有环节都要正常工作，整体才能正常工作，所以概率相乘。
    Poverall=p1×p2×⋯×pnP_{\text{overall}} = p_1 \times p_2 \times \cdots \times p_n
  3. 环节数量影响5 个 99% 的环节串联，整体可用率约为 95%；10 个环节则降到约 90%。
    0.995≈0.951,0.9910≈0.9040.99^5 \approx 0.951, \quad 0.99^{10} \approx 0.904

方案选型与权衡

开餐馆的菜谱不是唯一的：可以做川菜、粤菜、融合菜，也可以自建中央厨房或采购半成品。AI 技术路线同样常有多种方案：用大参数模型还是小参数模型？自研模型还是调用成熟 API？开源模型微调还是从零训练？不同路线在精度、延迟、成本、数据需求、可维护性上各有优劣，不存在“全都要”的免费午餐。

从菜系选择类比到选型权衡：大模型的优势是“厨艺上限高”，但响应慢、成本贵（如同聘请名厨坐镇，月薪不菲）；小模型的优势是“出菜快、成本低”，但某些复杂任务可能精度不足（如同家常小炒，快但难做精细功夫菜）。自研路线掌控力强，但周期长、维护成本高；采购成熟 API 上手快，但长期依赖第三方，且敏感数据出域面临合规风险。关键不是“哪条路线绝对好”，而是哪条路线与你的资源、市场窗口、数据现状最匹配。

选型决策常以多目标加权的形式量化对比：

回扣比喻：选型不是选“最好吃的菜”，而是选“最适合这家店定位的菜”。路边摊做不了国宴，米其林也不会卖炒粉。可行性评估的价值，就是在系统梳理各方案的性价比后，帮助团队做出一致且可辩护的决策，避免因人设事、凭感觉定路线。

Sk=∑j=1mwj×ukj\displaystyle S_k = \sum_{j=1}^{m} w_j \times u_{kj}
公式说明：$S_k$ 是第 $k$ 个方案的综合得分，$w_j$ 是第 $j$ 个评估目标的权重（如精度、延迟、成本），$u_{kj}$ 是第 $k$ 个方案在第 $j$ 个目标上的效用值（0-1 分）。逐一打分后选综合分最高的方案。
  1. 候选方案列出可选技术路线，例如方案 A 用 GPT-4 API、方案 B 用开源 7B 模型微调、方案 C 自研小模型。
    k∈{A,B,C}k \in \{A, B, C\}
  2. 评估目标确定决策关心的维度，如精度、延迟、成本、数据合规风险。
    j∈{1,2,3,4}j \in \{1, 2, 3, 4\}
  3. 效用打分每个方案在每个维度上给 0-1 分。比如方案 A 精度 0.9、延迟 0.6、成本 0.3。
    ukj∈[0,1]u_{kj} \in [0, 1]
  4. 加权汇总将权重与效用相乘后求和，得到每个方案的总分，取最高者并做敏感性分析。
    Sk=w1×uk1+w2×uk2+⋯S_k = w_1 \times u_{k1} + w_2 \times u_{k2} + \cdots

成本预算与决策

餐馆能不能开下去，最终看的是“算不算得过账来”。技术可行性评估的最后一个维度是成本：GPU/API 调用费、数据采购与标注费、工程师人力、运维成本、迭代预留——把这些加起来，再对比产品预期的商业收益，判断 ROI 是否为正。很多 AI 项目在技术上完全可行，但在商业账面上却不可行：单次推理成本 5 元，而付费用户每个月的消费才 3 元，这样的生意注定亏损。

从算账类比到成本评估：成本构成包括固定成本（如 GPU 服务器、模型训练一次性投入）和可变成本（如每次推理消耗的算力、每份数据的标注费用）。全生命周期成本（TCO）才是决策依据。为了把多维度信息收敛成一个可执行的判断，团队常做一个"Go/No-Go"决策表：先对每个维度打分，乘以权重得总分，再设立一票否决项（如数据合规不达标、单次推理成本超过付费阈值，则直接否决）。

综合决策公式：

回扣比喻：最后的决策，就像开业前夜店主对着一整本账本沉思。一道菜再美味、后厨再熟练，如果综合算下来定价 100 元成本 120 元，也不会写进菜单。技术可行性评估的终点不是一份漂亮报告，而是一个能让团队带着信心或者及时止损的决策——先开个最小规模的样板店（MVP）试营业，再决定要不要全面铺开，永远是最稳妥的路。

Decision={Go(∑i=1nwi×Si)≥θ  且无否决项No-Go否则\displaystyle \text{Decision} = \begin{cases} \text{Go} & \left( \sum_{i=1}^{n} w_i \times S_i \right) \ge \theta \; \text{且无否决项} \\ \text{No-Go} & \text{否则} \end{cases}
公式说明：$\theta$ 是可行阈值，如 0.7。即加权平均分足够高，且没有数据合规、成本超限等一票否决项，才批准立项，否则打回调整或终止。
  1. 各维打分将精度、延迟、数据、工程、成本各维度打分为 $S_i$（0-1 分）。
    S1=0.8,S2=0.7,S3=0.5,S4=0.9,S5=0.6S_1 = 0.8, S_2 = 0.7, S_3 = 0.5, S_4 = 0.9, S_5 = 0.6
  2. 加权求和乘以各维度权重 $w_i$，合计得到综合分。
    ∑i=1nwi×Si=综合分\sum_{i=1}^{n} w_i \times S_i = \text{综合分}
  3. 阈值比较综合分与预设阈值 $\theta$（如 0.7）比较，决定是否放行。
    综合分≥θ⇒Go\text{综合分} \ge \theta \Rightarrow \text{Go}
  4. 否决检查即使综合分达标，如果存在一票否决项（如数据无授权），仍然不能通过。
    存在否决项⇒No-Go\text{存在否决项} \Rightarrow \text{No-Go}

AI 应用场景

场景一：银行信贷审批系统立项评估

阶段：MVP构建 / 技术可行性评估

解决的问题：传统银行风控依赖人工审批，效率低且标准不一。直接引入大模型做自动化审批听起来吸引力巨大，但银行对推理延迟、数据隐私、合规性要求极为苛刻。技术可行性评估将“AI 审批”这个宏大想法拆解为：模型在历史信贷数据上的 AUC 能达到多少（精度）、每笔审批能否在 200ms 内完成（延迟）、客户数据是否经过充分脱敏授权（合规）、能否接入现有信贷核心系统（工程化）、单笔推理成本是否低于人工审批成本（成本）。评估发现纯端侧大模型延迟不达标，转向“小模型规则兜底 + 大模型辅助”的混合方案。

具体案例：某股份制银行在立项前组织 2 周技术预研，采集 10 万条脱敏样本，分别测试 7B 开源模型与规则引擎的组合。结果显示混合方案在 AUC 达到 0.91、p99 延迟 180ms、单笔成本 0.02 元的前提下，通过了可行性评审，获批进入 MVP 开发。若未做此项评估，团队很可能直接投入大模型方案，最终因延迟与成本双重不达标而返工。

场景二：电商智能客服方案选型

阶段：技术方案选型 / 成本预算

解决的问题：电商平台想用 AI 客服替代 80% 的人工重复咨询。技术团队在“调用通用大模型 API”与“微调开源模型私有化部署”之间产生分歧。可行性评估通过两个维度对比拉齐认知：通用大模型 API 效果好在精度上得分高，但存在数据出域风险且按调用量计费，月成本随订单量线性膨胀；开源模型私有化部署前期成本高，但边际成本低、数据安全可控。通过加权评分，结合该平台日均 50 万咨询量的实际规模，私有化部署的综合成本在第 6 个月即低于 API 方案，最终被选定。

具体案例：某头部电商平台在评估中发现，通用 API 每万次调用约 12 元，按日均 50 万次计算，月成本约 180 万元；而私有化 7B 模型加 4 张 A10 显卡的方案，月均摊成本约 40 万元，且可复用已有客服语料训练领域模型，意图识别准确率从 78% 提升到 87%。正是可行性评估让“看似省事”的方案让位于“长期更优”的方案。

场景三：法律文书 AI 工具的数据合规体检

阶段：数据获取与合规评估

解决的问题：创业团队计划做一款“合同风险自动审查”AI 工具。Demo 阶段效果惊艳，但在技术可行性评估的数据合规维度暴露了隐患：训练数据中大量合同来自公开网络，未获得作者授权，且包含当事人姓名、身份证号等个人信息，未做有效脱敏。依据《个人信息保护法》与《数据安全法》，这类数据一旦用于商业模型训练，将面临高额处罚。评估团队在立项阶段将其标记为“一票否决项”，迫使团队改用合规数据源（购买授权语料库 + 邀请律所脱敏投稿），虽然数据量从 200 万份缩水到 20 万份，但规避了致命合规风险。

具体案例：某 AI 法律科技创业公司在 A 轮融资前的技术尽调中，因可行性评估报告里清晰标注了数据合规整改路径，投资人才敢于推进。如果跳过该项评估，等到产品上线后遭遇数据来源诉讼，公司将面临灭顶之灾。

Python 演示

python95 行
# -*- coding: utf-8 -*-"""AI product technical feasibility evaluator."""import json DIMENSIONS = [    "model_accuracy",    "infer_latency",    "data_compliance",    "engineering",    "solution_choice",    "cost_budget"] WEIGHTS = {    "model_accuracy": 0.25,    "infer_latency": 0.15,    "data_compliance": 0.25,    "engineering": 0.15,    "solution_choice": 0.10,    "cost_budget": 0.10} VETO_ITEMS = [    "data_compliance",    "cost_budget"]  def evaluate_feasibility(scores: dict) -> dict:    """Compute weighted score and decide go / no-go."""    if not scores:        return {"error": "empty scores", "decision": "No-Go"}     total = 0.0    detail = {}    for name in DIMENSIONS:        sc = scores.get(name, 0.0)        w = WEIGHTS.get(name, 0.0)        detail[name] = {"score": sc, "weight": w, "weighted": sc * w}        total += sc * w     veto_hits = [name for name in VETO_ITEMS if scores.get(name, 0.0) < 0.5]    passed = total >= 0.7 and not veto_hits     return {        "total_score": round(total, 3),        "detail": detail,        "veto_hits": veto_hits,        "decision": "Go" if passed else "No-Go"    }  def pretty_report(result: dict) -> str:    """Format the evaluation result into readable text."""    lines = []    lines.append("==== Feasibility Evaluation Report ====")    for name, item in result["detail"].items():        lines.append(            "{:<18} score={:<5.2f} weight={:<5.2f} weighted={:<5.3f}".format(                name, item["score"], item["weight"], item["weighted"]            )        )    lines.append("----------------------------------------")    lines.append("Total weighted score: {:.3f}".format(result["total_score"]))    if result["veto_hits"]:        lines.append("VETO items: " + ", ".join(result["veto_hits"]))    lines.append("Final decision: " + result["decision"])    if result["decision"] == "No-Go":        lines.append("Suggestion: adjust plan and re-evaluate before building MVP.")    return "\n".join(lines)  def main():    """Run a sample evaluation."""    sample_scores = {        "model_accuracy": 0.82,        "infer_latency": 0.74,        "data_compliance": 0.95,        "engineering": 0.60,        "solution_choice": 0.78,        "cost_budget": 0.66    }    result = evaluate_feasibility(sample_scores)    print(pretty_report(result))     json_out = {        "total_score": result["total_score"],        "decision": result["decision"],        "veto_hits": result["veto_hits"]    }    print("\nJSON summary: " + json.dumps(json_out, ensure_ascii=False))  if __name__ == "__main__":    main()
目的：该评估器将正文所述的可行性评估流程代码化，输入各维度 0-1 分，输出加权总分、一票否决命中项和最终立项建议，可直接用于团队内部的 MVP 立项预审。
  1. DIMENSIONS = [...]定义了六个评估维度，与思维导图的一级分支一一对应，方便后续逐个打分。
  2. WEIGHTS = {...}每个维度的权重，所有权重相加为 1，对应加权公式中的 $w_i$。
  3. VETO_ITEMS = [...]一票否决项列表，数据合规和成本一旦低于 0.5 分，即使总分达标也会被否。
  4. for name in DIMENSIONS:遍历所有维度，逐项计算 score * weight 得到加权分，最后累加到 total。
  5. veto_hits = [...]找出所有得分低于 0.5 的否决项，这就是“红线检查”。
  6. decision综合判断：总分 ≥ 0.7 且无否决项才返回 "Go"，否则返回 "No-Go"。
  7. sample_scores模拟一个数据合规良好但工程化偏弱（0.6）的项目，观察总分在 0.7 线附近时的决策结果。

常见误区

误区“我在笔记本上跑通了一个模型，准确率 90%，说明技术是可行的，直接开发上线吧。”刚接触 AI 的产品经理和技术新人常常这样想，把实验室里的一次成功当作生产环境长期稳定的保证。

正解Demo 相当于在理想厨房里做了一道菜给朋友试吃，而技术可行性评估要求你在真实的后厨环境、真实的客流高峰期、真实的食材条件下，连续做一百道一模一样的菜。生产环境中的数据噪声、系统并发、网络抖动、模型漂移都会让性能显著下滑。可行性评估必须用接近真实场景的测试集和压测来验证，而非单点 Demo。

为何常见：人脑天然容易被“亲眼所见”说服。一个能跑的 Demo 提供了强烈的正反馈，让人系统性低估从“跑通”到“稳定服务”之间的巨大工程量。

误区“我们的模型准确率 98%，没什么可担心的。”初学者往往把准确率当作模型优劣的万能指标，忽略了在类别极不均衡的场景下，准确率会严重失真。

正解这就像店里统计“顾客没有闹事比例 98%”——但如果 99% 的顾客根本没点你招牌菜，这个数字毫无意义。对于欺诈检测、罕见病筛查、违规内容识别这类正样本极少场景，必须用查准率、召回率和 F1 分数综合衡量。一个把所有样本都判为负类的模型，准确率可能高得离谱，但对业务毫无价值。

为何常见：准确率是最直观、最容易在 PPT 上展示的指标，而查准率/召回率需要结合业务背景理解，因此容易被忽视。

误区“网上一抓一大把数据，直接爬下来塞给模型训练不就行了？”许多创业团队在数据匮乏时，第一反应是“先爬了再说”，完全跳过来源合法性与用户授权审查。

正解数据是 AI 的食材，但走私食材做的菜再好吃，一旦被查就是停业整顿。合规风险在可行性评估中是“一票否决项”：数据来源不合法、用户未授权、敏感信息未脱敏，都可能让项目在融资尽调、产品上线或监管抽查时崩塌。正确的做法是优先盘点已有业务数据、使用开源合规数据集、与数据持有方签署授权协议，评估时限用合法数据能做到的性能上限。

为何常见：互联网提供了巨大的“数据错觉”——看起来触手可及，让人误以为资源免费且无主。而法律合规意识薄弱是技术人员转型商业项目时的普遍短板。

误区“既然大模型效果更好，为什么不直接用最大的模型？”工程师对模型效果有天然执念，倾向于选择榜单 SOTA 的模型，却忽略它需要多少 GPU 显存、推理延迟多高、单次调用成本多少钱。

正解如同开社区小餐馆不必请米其林三星主厨——你的客单价支撑不起这个成本。技术可行性评估要求把精度、延迟、成本放在同一张损益表上看：一个精度低 3 个百分点但速度快 10 倍、成本低 20 倍的模型，可能才是商业上最优的选择。用加权评分公式综合比较方案，才能避免“性能最优而商业不可行”的陷阱。

为何常见：算法竞赛文化和论文 benchmark 文化培养了“越高越好”的思维惯性；而产品思维要求的是“够用就好，且整体平衡”。

误区“立项时做了一次评估，后面按计划执行就行，不用再看了。”团队把可行性评估当作一次性关卡，忽略了技术迭代、数据变化和市场环境变动。

正解可行性评估是一个持续迭代的过程。MVP 阶段的评估结论可能因数据积累、模型进步、成本下降而改变；之前不可行的方案，半年后可能因开源生态成熟而变得可行。建议每季度或每个关键里程碑重跑一次评估，像餐馆定期更新菜单和核算成本一样，保持决策的时效性。

为何常见：评估报告是一次性产出的“文档思维”，而非“流程思维”。新手容易把做事动作等同于交付物，而忽略了评估背后是持续校准的决策机制。

面试题

Q1. 以下哪项是技术可行性评估的主要目标？

单选题 · easy

  • A.编写漂亮的算法论文
  • B.在立项前识别技术风险← 正确答案
  • C.提升模型准确率到 99%
  • D.收集尽可能多的数据

答案：B。技术可行性评估的核心是识别风险，避免资源浪费，类似“先试菜再开店”的调研动作。写论文是学术目标、提升准确率和收集数据都是研发过程，不是评估本身的直接目标。

Q2. F1 分数的正确计算公式是？

单选题 · easy

  • A.查准率与召回率的算术平均
  • B.查准率与召回率的调和平均← 正确答案
  • C.准确率与召回率的乘积
  • D.查准率与准确率的加权和

答案：B。F1 是查准率（Precision）与召回率（Recall）的调和平均，公式为 2×P×R/(P+R)，比算术平均更严格地惩罚一个指标偏低的模型。

Q3. “p99 延迟为 200ms”的含义是？

单选题 · mid

  • A.所有请求都低于 200ms 返回
  • B.平均每个请求耗时 200ms
  • C.99% 的请求延迟低于 200ms← 正确答案
  • D.最快的一个请求耗时 200ms

答案：C。p99 表示 99% 的请求延迟低于某个值，衡量的是最慢那 1% 请求的上界体验，类似“高峰期最慢的一桌等位时间”。

Q4. 某模型把所有图片都识别为“非违规”，其识别准确率是 98%（违规图片占 2%）。该模型的查准率和召回率分别是？

单选题 · mid

  • A.查准率 98%，召回率 98%
  • B.查准率 0%，召回率 98%
  • C.查准率 0%，召回率 0%← 正确答案
  • D.查准率 98%，召回率 0%

答案：C。模型没有预测出任何正例，所以查准率（预测正例中真实正例比例）无法计算记为 0，召回率（真实正例中被找出比例）为 0。准确率 98% 完全由大量负类样本贡献，掩盖了模型的无效。

Q5. 数据合规在技术可行性评估中通常属于？

单选题 · mid

  • A.可协商的加分项
  • B.一票否决项← 正确答案
  • C.仅在融资时关注
  • D.与模型精度同等权重

答案：B。数据来源非法、用户未授权、敏感信息未脱敏可能导致产品下架、高额罚款，因此在评估中是一票否决项，不属于可协商的加分项。

Q6. 在评估一个 AI 智能客服方案时，以下哪些指标属于推理延迟评估的典型关注点？

多选题 · mid

  • A.单次调用 API 响应时间← 正确答案
  • B.系统在高并发下的 p99 延迟← 正确答案
  • C.模型在测试集上的 F1 分数
  • D.用户可接受的最长等待时间← 正确答案

答案：ABD。推理延迟评估关注的是响应时间、峰值下的尾部延迟（p99）以及业务对响应速度的容忍度。F1 分数是模型精度的度量，不归入延迟评估维度。

Q7. 关于技术路线选型，下列说法正确的是？

多选题 · mid

  • A.大模型效果一定优于小模型，应无条件选择
  • B.自研方案灵活但周期长，采购方案快但成本结构不同← 正确答案
  • C.选型应综合精度、延迟、成本等多维度加权比较← 正确答案
  • D.开源模型微调三方兼具可控与成本优势，永远最优

答案：BC。选型不存在“无条件最优”或“永远最优”的路线。大模型虽效果强但延迟和成本高；开源微调有隐含的运维和数据准备成本。正确的做法是加权比较各方案，并结合团队资源做取舍。

Q8. 某 AI 产品的综合加权得分为 0.75（阈值 0.7），但数据合规项只有 0.2，评估结论应该是？

单选题 · hard

  • A.通过，因为总分超标
  • B.不通过，因为触发一票否决← 正确答案
  • C.通过，只需补充说明
  • D.不通过，因为总分不足

答案：B。根据决策规则，总分达标但存在一票否决项时仍为 No-Go。数据合规 0.2 低于 0.5 的否决线，必须整改数据来源后重新评估，否则法律风险不可承受。

Q9. 训练数据规模与模型性能之间关系描述正确的是？

多选题 · hard

  • A.数据量翻倍，性能必翻倍
  • B.性能随数据量提升且存在边际递减← 正确答案
  • C.数据质量对性能的影响可能大于数量← 正确答案
  • D.数据量足够大时即可完全消除过拟合

答案：BC。幂律定律表明性能随数据量提升但增幅递减，选项 A 错误。数据质量（噪声、标注错误）往往比单纯数量对性能影响更大，选项 C 正确并是数据工程的核心经验。D 过于绝对，数据量增大可缓解但无法完全消除过拟合。

Q10. 项目立项评审中表示“打回重审”的条件是？

单选题 · hard

  • A.综合加权分小于 0.5
  • B.任一维度得分未达 0.6
  • C.综合分达阈值但成本项低于 0.4← 正确答案
  • D.模型精度未达 95%

答案：C。A 不完整，打回条件既包含综合分低于阈值也包含触发一票否决；B 不是所有维度都有硬性 0.6 门槛；C 正确表达了“总分达标但否决项命中仍打回”的决策逻辑；D 中精度 95% 并非所有场景的硬性要求。