窗外是上海漕河泾软件园傍晚六点的天空，灰蒙蒙的，分不清是雾霾还是夜色提前降临。我盯着屏幕上那密密麻麻的开发者文档，感觉像在看天书。三十二岁了，还在死磕这些最底层的东西，是不是有点可笑？
但没办法。今天下午和工程师对需求，我指着原型图说“这里的数据应该实时刷新”，他头也不抬地回了一句：“Flovico，你知道这要调哪个API吗？传参格式是什么？返回的数据结构你清楚吗？”我哑口无言。那一刻的尴尬，比被客户当面否定方案还要难受一百倍。我意识到，如果我只停留在画线框图的层面，我永远只能是个“传话筒”，一个可以被任何人替代的、没有牙齿的产品经理。
所以现在，我把自己按在电脑前，面对这个第三方数据平台的文档。不是简单地看，是必须看懂。我得知道，当用户点击那个“刷新”按钮时，我的前端代码会发出一个怎样的HTTP请求。是GET还是POST？URL里要拼接哪些参数？这些参数里，哪些是必填的，哪些有默认值？比如这个“timestamp”字段，文档里写着“Unix时间戳，精确到毫秒”。什么叫Unix时间戳？为什么是毫秒？如果我只传秒级会怎样？服务器会返回一个冷冰冰的400错误，还是默默地用默认值处理，然后给我一堆错误的数据？
这还只是请求。更让人头大的是响应。文档里那个JSON结构图，层层嵌套，像一棵倒长的树。“data”对象里面套着“list”数组，“list”数组里的每个元素又是一个对象，里面有“id”、“name”、“status”……“status”的值是0、1、2，分别代表“未开始”、“进行中”、“已完成”。如果我不理解这个，我怎么设计前端的展示逻辑？难道我要告诉工程师：“哦，这里显示状态文字”？那他反过来问我：“状态码2对应什么文字？”我又得去翻文档。这种低效的、来回撕扯的沟通，正在一点点消耗我和技术团队之间本就脆弱的信任。
我点开Postman，开始手动构造请求。在URL栏里小心翼翼地输入端点地址，在Params标签页下一个一个添加参数。key，value，key，value……每填一个，我都要回头去核对文档里的描述，生怕拼错一个字母。点击“Send”的时候，心跳居然有点加速。像是等待考试结果。
返回了。一大坨未经格式化的JSON数据砸在响应框里，黑底白字，密密麻麻。我点击“Pretty”格式化，它才舒展开来，露出了清晰的结构。我一行一行地看，对照着文档里的字段说明。哦，原来“total_count”在这里，表示总记录数。“list”真的是一个数组，里面第一条数据的“status”是1……我好像，有点懂了。不是懂代码怎么写，而是懂了数据是怎么来的，又是以怎样的形态在系统里流动的。
这感觉很奇怪。就像你一直隔着毛玻璃看世界，现在突然擦亮了一小块。虽然大部分还是模糊的，但这一小块清晰的地方，让你有了踏实感。我意识到，产品经理需要的不是会写代码，而是要有一种“技术审美”。你要能欣赏一个优雅的API设计，也能嗅出一个糟糕接口的臭味。你要能判断，某个功能在技术实现上的复杂度究竟在哪里，是接口调用次数太多，还是数据处理逻辑太绕？只有这样，你在排优先级、和研发争论、向老板汇报时，手里才有实实在在的筹码，而不是空泛的“用户体验”、“商业价值”。
否则，你画的那些图，就真的只是图。很漂亮，但一碰就碎。
文档翻到下一页，是关于“错误码”的说明。又是一个长长的列表。我叹了口气，揉了揉发酸的眼睛。路还长着呢。但至少，我知道该往哪个方向走了。先把这个接口的每一个细节啃下来吧，哪怕今晚要熬到后半夜。毕竟，流量闭环的拼图，第一块就得从这里开始。没有数据，一切增长都是空中楼阁。
桌上的咖啡已经凉透了。我端起杯子喝了一口，苦涩的味道在舌尖蔓延开。但心里，却比刚才亮堂了一点。
