第一原则：不要马上报价¶
客户一句话进来，新人的本能是马上估算价格。顺序错了：**先弄清楚要做什么，再谈多少钱。**问清楚之前给出的任何数字都是猜，猜的报价要么亏要么丢单。
这一步的结构是：动作 → 输入 → 判断 → 输出。输入是客户的原话，动作是按固定顺序提问，判断标准是「范围确认完成」，输出是需求确认单。
陌生需求先开需求评审会¶
判断规则：陌生客户，或需求明显超出现有单元、拿不准怎么做的，先开会再提问；老客户加同类需求、一眼是现成单元的，直接走需求八问。
接到陌生的客户和陌生的需求时，先发起一个需求评审和分析的会议——商务、技术等各种角色凑在一起，先看清楚这件事该怎么办，而不是各自回工位开始想。它的性质类似小组作业要做 pre：大家凑在一起，先把事情本身弄明白。
参会：商务 + 技术，需要时拉其他角色。会议产出四样：
客户的业务意图：拿数据去干什么、给谁看、看了做什么决定
初步拆解方向：哪些像现成单元，哪些要新增
接不接的倾向：明显不可行的，到此为止
对接人：后续需求八问由谁去问客户
**会上同样不报价。**评审会解决「这件事该怎么看」，需求八问解决「这件事具体是什么」，报价在两者之后。
需求八问¶
客户说：
「我们希望长期跟踪一些科技网站，有新文章就帮我们整理出来。」
评审会开完、对接人定了之后（或无需开会的场景），同样不报价，按固定顺序问：
哪些网站？（能拿到清单吗）
多少个？
什么内容算「新文章」？
多久更新一次？
历史数据要不要？要多久的？
需要哪些字段？（标题、作者、时间、URL、正文……）
怎么交付？（格式、投递方式）
预算大概多少？什么结果算完成？
「什么叫整理」「什么叫新文章」这类词必须追问到可以执行为止。模糊词是后续纠纷的来源——每留下一个模糊词，验收时就多一笔糊涂账。
需求确认单¶
八问的落点是一张需求确认单。案例填完长这样：
需求确认单（案例）
抓取对象： 300 个海外科技网站的新文章（客户提供清单）
频率： 每天一次
字段： 标题、作者、发布时间、URL、正文
历史数据： 过去一年
输出： CSV + 数据库写入
验收定义： 300 个站点全部覆盖；每天 08:00 前完成更新
预算区间： 客户已确认接受
不做清单： 热点汇总（本期不含，见范围）范围确认完成的判断标准，四条同时满足：
数据来源明确（清单、接口或可枚举的对象）
输出形式明确（格式、频率、位置）
验收标准可以定义（什么结果算完成，能写出数字或清单）
价格区间被客户接受
判断规则：什么需求能接¶
客户提出需求
↓
数据来源明确吗？
否 → 继续确认（回到需求八问）
是 → 能否使用现有标准单元？
否 → 技术评估（数据工程师介入，评估新技术成本）
是 → 估算工作量
↓
能否满足预算？
否 → 调整范围（砍范围、分期、或不接）
是 → 报价，进入签单三类需求不能直接做：
数据来源完全未知，或客户自己也说不清楚要什么
验收标准无法定义——「做好一点」这类标准变不成数字，就没法验收
需要开发全新的核心技术，或成本明显超过预算
**不能接也是结论。**把理由写进需求确认单交回商务，不要带着问号进执行。
报价与范围¶
范围确认后才报价。估算的机械公式：
需求规模
× 标准单元数量
× 执行复杂度
× 维护周期
=
成本估算报价谈的是范围，不是态度：**商务不是把客户说的所有东西都答应下来，而是在预算和交付能力之间确定一个双方都能接受的范围。**客户要的超出预算，就砍范围或分期，而不是先答应下来再想办法。
这一步的输出物：已双方确认的需求确认单（含不做清单）+ 报价。两者齐备，才算可以签单。