需求评估 Agent：一段需求文本出判定与报价方案产品系统

软件外包和技术服务接单，最常见的翻车不是做不出来，是报价前判断错类型。客户发来的往往只有三五句话：「想做个能问的」「把订单自动录进去」——前者是知识库，后者是流程自动化，成本结构完全不同：知识库的钱花在语料处理，自动化的钱花在流程边界和系统对接。判错一次，报价差一个量级，后面验收标准也跟着错位，最后变成一边做一边扯皮。

这个工具是我自己在用的：每次接到需求先跑一遍，输出类型判定、该问客户的问题、三档报价和验收单草稿，再决定要不要接、按什么口径报。

一是信号提取：从原句里抽文档量、系统名、流程动词、预算、拒单信号，每条都保留命中的原文片段，结论可以回溯到客户原话。二是类型判定：知识库、流程自动化、数据处理、建议不接四类，加权打分并给出置信度，不是黑箱输出一个标签。三是澄清清单：按缺口生成，客户已经说过的整条消失，而不是标成「可不答」。四是分轨计价：知识库按文档量、自动化按系统对接数，两套公式不混用，并给出客户预算与报价的差额提示。五是验收单生成：每条都能被第三方独立判定，自动化类写「连续 100 次成功率」，不写「准确率」。六是双轨兜底：模型只做第二意见，与规则冲突时标注出来交人复核，没有配置 API Key 也能完整跑通。

设计、实现、评测由我一个人完成。技术栈是 Python 3.13 标准库，零第三方依赖（re、json、argparse、urllib、dataclasses），客户环境不需要装任何东西。架构是单向数据流：需求文本 → 信号 → 判定 → 澄清、报价、验收四份产出，编排层只有 17 行，评测脚本和将来的机器人、表单后端都能直接调用，不必经过命令行。难点在设计判断而不是代码：模型判得可能更准，但不可复现、不可评测、挂了就不能用，所以它只做第二意见，冲突时保留能指出依据的规则结论。另一个坑是报价区间倒挂（上限被单独写死时出现），我加了构造即校验的防呆和对应测试。评测用三批样本，只报盲测 9/10，开发集和留出集的满分不算数。