Excel 是团队的通用语

做项目管家的时候，我在一个设计决策上纠结了很久，最后它成了我做工具以来最值钱的一条经验。写下来。

一次教训：优雅的方案，错误的产品

给插件设计数据入口时，工程上的最优解很诱人：让用户在我的界面里重建任务结构。数据模型干净、校验完整、字段规范——每个环节都赏心悦目。

但站在用户的位置想三秒就会发现不对：项目经理手里已经有计划表了。在 Excel 里养了好几年的 WBS，字段是按自家流程长的。让他“重建一遍”，等于告诉他：换工具的先决条件是先给旧工具收尸。

结果就是他不会换。不是产品不好，是搬家成本比收益先到。

所以规则很简单

**工具适应人，不是人适应工具。**具体到落地就是一条：你的工具必须能吃能吐 Excel。

• 能吃：用户现有的表直接导进来，脏数据你洗，格式差异你兜。工程上多写一堆解析和容错代码，但用户的迁移成本是零。
• 能吐：算完的结果导出去还是 Excel——不是因为好看，而是因为它的下游（汇报、评审、转发给领导）全是 Excel 驱动的。你工具的输出，是别人工作流的输入。

为什么 Excel 值得当成“协议”来看

把 Excel 当一个协议来理解会更清楚：它是这个星球上普及度最高的结构化数据交换格式，没有之一。团队成员会用，跨公司交流用它，领导验收看它。你可以不喜欢它（单元格合并是反人类的发明，我同意），但通用语的意义就是所有人都会说。

做项目管家的 Excel 导入功能时,真正的难点从来不是读写表格——是预测用户的表会长什么样：列名千奇百怪、日期格式五种起步、合并单元格满天飞。兼容它们的过程烦到怀疑人生，但每兼容一种，就多一类“可以直接用起来”的用户。

推广到一切工具设计

这条经验早就不限于表格了：

• 做的插件全部支持纯离线，因为用户的“已有工作流”里包括“断网”；
• 博客的 RSS 做全文输出，因为订阅器是别人的阅读工作流；
• 评论不强制登录，因为“注册”就是一道搬家门槛。

**用户搬家是要付成本的。你的工具要么足够好到让他付，要么先把成本降到零。**多数产品的正确答案是后者。