1.2 我怎样用五天看懂一家陌生公司
进入云枢科技的第二天，我已经能复述公司官网上的产品介绍，也知道它有销售、研发、项目和客户成功团队。但如果 CEO 此时问我这家公司为什么赚钱、为什么又会越增长越缺现金，我仍然答不完整。
我给五天调查设定的目标不是“成为行业专家”，而是形成一张可以被企业人员纠正的底图。五天后，我必须能把已经确认的事实、仍有分歧的说法和自己的猜测分开。
开始计时前，我先确认自己是否真的获得了进入公司的条件
CEO 已经公开表示支持 AI 转型，但“支持”还不等于我能完成调查。我把四项条件写进邮件，请他和对应负责人确认：
- 可以查看经过批准的收入、成本、应收和客户流失数据；
- 可以访谈关键岗位，也可以观察一线员工处理真实工作；
- 可以抽查顺利、延期、亏损和流失样本，而不只看优秀案例；
- 出现跨部门分歧时，可以请有权确认事实的人共同走查。
数据负责人同时划出边界：客户名称和个人信息先脱敏，合同原文只能在批准环境查看，未经允许不得把资料放进外部 AI 服务。
如果我只能听技术部门介绍，却要判断全公司的经营问题，这五天不会产生可信结论。
五天里，我每天都让一个判断失去理所当然
| 天数 | 我查看的材料 | 我原来的理解 | 当天出现的反证 | 留下的工件 |
|---|---|---|---|---|
| 第 1 天 | 收入、毛利、应收、客户结构 | 公司主要靠 SaaS 规模增长 | 实施和顾问收入超过一半，实施失败又影响订阅续约 | 三类业务收入与成本表 |
| 第 2 天 | 赢单、输单、续约和流失访谈 | 购买决定主要由运营负责人作出 | 使用者、预算、IT、采购和法务分别能推动或叫停 | 客户角色与替代方案表 |
| 第 3 天 | 一笔顺利订单与 YS-24-017 | 延期主要发生在项目执行阶段 | 风险在对客方案和合同以前已经出现 | 两笔订单五线时间轴 |
| 第 4 天 | CRM、方案、合同、项目、财务记录 | 公司系统很多，事实应该容易核对 | 同一客户、范围和“正常”状态有多个版本 | 关键事实来源表 |
| 第 5 天 | 跨部门共同走查 | 把资料放在一起就能自然形成共识 | 同一词语在不同岗位有不同业务含义 | 商业系统图 0.5 与疑问清单 |
表格看起来像一份安排，真正有价值的是每天的判断变化。没有反证，五天很容易变成五场公司介绍。
第一天，收入表推翻了“这是一家纯软件公司”
官网最显眼的是 SaaS 产品，我原以为订阅收入决定公司大部分经营逻辑。财务负责人把最近一个完整年度拆开以后，我看到订阅收入 3,600 万元，只占总收入约 44%；实施与定制、顾问与运营服务合计超过一半。
更重要的是三类收入相互影响。销售为了拿到订阅合同，可能压低实施报价；实施延期会推迟验收和回款，也会让客户迟迟不能真正使用；客户使用不足又会影响第二年的续约。
第一天结束时，我没有只抄三张财务表，而是写下一个新问题：“同一位客户在三类业务之间怎样移动，哪一类业务的决定会把成本推给另一类？”
第二天，客户访谈推翻了“找到需求人就等于找到客户”
销售最先带我见的是一位运营负责人。他能讲清门店管理问题，也愿意推动试点。但继续追问后，我发现总部运营人员是使用者，COO 关心经营结果，财务掌握预算，CIO 控制数据接入，采购和法务可以暂停合同。
我又问客户如果不购买云枢科技会怎么办。答案包括继续使用表格、增加分析人员、请外部顾问或暂时不改。这些替代办法不够先进，却保留了控制权和较低的改变风险。
到这里，价值不再是“AI 分析更智能”，而是客户能否更早发现门店问题，同时不增加另一套无法解释的工作。
第三天，两笔订单把问题第一次出现的位置向前移动
我把 YS-24-017 和一笔按期完成的非标准订单放在一起。两笔订单都包含接口工作，区别不在项目经理是否更努力。
顺利订单在方案发出前开过技术确认会，客户准备事项进入合同附件；延期订单只留下了售前个人判断，方案和合同没有指定第三方授权条件。
如果只看失败订单，我可能增加项目启动检查；有了顺利订单，改造方向变成复制“承诺前确认条件”，而不是在签约后更早发现坏消息。
第四天，我不再问系统先进不先进
CRM 说客户“正常”，项目系统也说“正常”，客户成功记录里却有两次投诉，财务则显示尾款逾期。
四个系统并不一定有一个是错的：销售的正常表示仍有商业机会，项目的正常表示计划尚未正式改期，客户成功看到的是关系风险，财务依据的是合同付款日期。
问题在于经营会上大家用了同一个词，却没有说明它代表哪种事实。我开始为客户主体、合同范围、项目状态和应收金额分别记录权威来源、确认人和更新时间。
第五天，我把“事实、分歧、假设”分成三栏
跨部门走查前，我没有先展示诊断结论，而是提交一张登记表：
| 类型 | 当时的例子 | 会议需要做什么 |
|---|---|---|
| 已确认事实 | 41% 的项目发生未充分计价的范围变化 | 确认口径和来源，进入经营基线 |
| 尚有分歧 | “接口已确认”究竟确认了技术可能、客户意愿还是第三方授权 | 指定能够确认的人，并找到原始记录 |
| 待验证假设 | 非标准承诺是验收和回款推迟的重要原因 | 增加顺利与失败订单对照，不能直接立项 |
销售纠正了我对客户决策的理解，项目团队补上了启动条件，财务把“合同额”和“已经收回的钱”分开。会议没有消灭所有问号，但每个问号都有了下一份证据和确认人。
AI 在五天内只承担可逆的整理工作
AI 可以帮助我整理公开资料、把访谈按主题归类、对齐订单时间、找出不同版本和列出缺失项。所有摘要保留来源，敏感资料遵守公司边界。
它不能把四个人的不同说法合成一个顺畅故事，也不能给“谁应该负责”下结论。存在冲突时，最有价值的输出往往是一张清楚的冲突表。
五天结束时，我交出的不是一张漂亮海报
我交给经营团队的是商业系统图 0.5、三笔代表性订单、关键事实来源表和十个待验证问题。每个已确认结论都能指回财务记录、客户访谈或订单材料；每个未确认判断都明确写着“还不知道”。
这份底稿会在本卷后续持续修订。你可以先查看它最终长成的样子：云枢科技已填写商业系统图，但阅读后面的章节时要留意每一部分是怎样被证据补上的。
下一节，我们先从最容易被功能要求掩盖的问题开始：客户为什么愿意付钱。