每次遇到刚接手海外项目的团队，我常听到同一句话：「英语还行，邮件能看懂， 就是这个客户太难搞。」但真正把项目翻开看，问题往往不在语言。
客户发来一整套技术资料，包几十个文件，有图纸、有规格书、有测试报告。 国内团队收到后开始报价、排期、采购。三个月后样品出来，客户说「不符合我们的要求」。
这时候双方都很委屈：客户觉得「资料都给你们了」，国内团队觉得「我们完全按图纸做的」。 问题是：图纸只写了结果，没写理由。
某个结构为什么这样设计？是功能需要、装配需要、还是供应商能力限制？ 如果不知道理由，就无法判断「这个能不能改」。翻译能把「壁厚 2.0mm」翻成中文， 但翻不出「为什么必须是 2.0」。
一份规格书里，通常 20% 是硬约束（法规、安全、客户平台要求）， 80% 是可以谈的（工艺选择、公差分配、材料替代）。 如果不区分，要么全部不敢动（成本高、周期长），要么乱动（踩到硬约束）。
「达到量产要求」是最危险的表述。是哪些指标？用什么方法测？ 在什么环境条件下测？样本量多少？判定规则是什么？ 这些问题不确认，样品阶段永远"看起来通过"。
我的做法是，在任何方案讨论之前，先完成三件事：
| 动作 | 产出 |
|---|---|
| 需求逐项确认 | 把规格书拆成条目，每条标注：来源、是否硬约束、由谁确认、确认状态 |
| 接口清单 | 列出所有交付接口：谁给谁什么、什么格式、什么时间、谁验证 |
| 验收标准书面化 | 指标、方法、条件、样本量、判定规则，双方签字确认 |
这三件事做完，项目才真正"开始"。在此之前的所有排期都是估算。
如果你无法用一句话说清楚「这个项目什么算成功」，那说明需求还没对齐， 而不是团队执行力不够。
这套做法适合有明确客户和交付要求的工业项目。 对于探索型项目（方向都还没定），过度的需求确认反而会拖慢节奏——那种情况应该先做小规模验证。
项目导入诊断会逐项检查需求、接口与验收标准的清晰度。