技术探索不是闭门造车，而是产品与资源的共舞
上个月从腾讯系某大厂裸辞后，我终于有时间静下来想想：这几年到底在忙什么？每天写代码、改需求、修 Bug、赶上线，像陀螺一样转个不停，却很少停下来问自己——这些技术探索，真的有价值吗？
坐在深圳南山的出租屋里，窗外是熟悉的腾讯大厦轮廓，手边是用了三年的 MacBook Pro（Windows ？哦，那台只在测试兼容性时才敢开机的“古董”）。忽然意识到，所谓“技术探索”，如果脱离了产品和资源这两个锚点，很容易变成自嗨式的炫技。
这篇文章，就是想聊聊我踩过的坑、走过的弯路，以及最近半年重新思考后的一些实践心得。不讲大道理，只说真实场景。
事情得从一个“伪需求”说起
去年双11前两周，我们组接到一个紧急需求：要在主 App 里加一个“智能推荐卡片”，用 AI 模型预测用户可能感兴趣的内容。产品经理 PPT 写得天花乱坠：“提升点击率 20%”、“打造行业标杆”、“对标抖音推荐流”。
但技术方案呢？只有一句：“你们搞个模型跑起来就行。”
当时我就懵了。模型？数据在哪？训练资源谁出？线上服务怎么部署？QPS 要多少？全没提。更离谱的是，距离上线只剩 12 天。
我第一反应是拒绝：“这根本不是技术问题，是产品没想清楚。”但 PM 回了一句让我至今难忘：“技术同学要有 owner 意识，不能只等需求喂到嘴边。”
行吧，owner 就 owner。我咬牙接了。
技术探索的第一步：别急着写代码，先摸清“产品”到底要什么
很多工程师（包括曾经的我）一听到“新功能”就兴奋，立刻打开 IDE 开始搭框架。结果呢？做了一堆没人用的功能，或者做到一半发现方向错了，返工重来。
这次我学乖了。拉了个会，直接问 PM：
- 这个卡片的目标用户是谁？
- 核心指标是点击率？停留时长？还是转化？
- 如果效果不好，有没有 fallback 方案？
- 上线后如何 AB 测试？
PM 一开始有点不耐烦，但聊着聊着，他自己也意识到很多逻辑没闭环。比如，他原以为“AI 推荐”就是万能的，但其实我们历史数据稀疏，冷启动用户占 60%，模型根本跑不起来。
最后我们达成共识：先不做复杂模型，用规则+简单协同过滤打底，重点把埋点和实验框架搭好。等数据积累够了，再迭代模型。
你看，技术探索的第一步，不是选 TensorFlow 还是 PyTorch，而是理解产品的真实目标和约束条件。否则，你写得再优雅的代码，上线后没人用，也是垃圾。
资源有限？那就用最小成本验证价值
确定方向后，问题来了：我们团队只有 3 个后端、2 个前端，还有日常维护任务。老板口头支持“创新”，但不会给额外人力或服务器预算。
这时候，就得学会“薅资源”。
- 算力：公司内部有共享的 GPU 集群，但排队要 3 天。我转而用本地 Mac 的 M1 芯片跑轻量模型（感谢 Apple Silicon），虽然慢点，但足够做原型验证。
- 数据：数据平台接口文档过时，我直接找数仓同学喝奶茶套近乎，拿到了原始日志表权限。
- 部署：不想申请新服务（流程太长），我把推荐逻辑嵌入现有微服务，用 Feature Flag 控制开关。
关键是：用最小可行方案（MVP）快速跑通端到端流程。哪怕只是返回固定推荐列表，只要能走通“触发 → 请求 → 渲染 → 埋点 → 分析”这条链路，就算成功。
我花了 3 天搭了个简陋版本，第 4 天就推给 PM 看。他惊了：“这么快？” 其实代码很糙，但能演示、能测、能迭代，这就够了。
工程师的浪漫，不是写出完美架构，而是在资源紧巴巴的情况下，让想法活下来。
代码可读性：为未来的自己和队友留条活路
说到代码，我有个执念：宁可多写两行注释，也不让别人猜我的意图。
这次推荐模块，我坚持做了几件事：
- 命名清晰：
getRecommendationsByUserBehavior比fetchData好一万倍。 - 配置外置：把推荐权重、fallback 列表等参数放到配置中心，不用改代码就能调。
- 日志结构化：每条日志带 traceId，方便追踪用户行为路径。
- 单元测试覆盖核心逻辑：比如“当用户无行为时，应返回默认热门内容”。
// 示例：带 fallback 的推荐逻辑
async function getSmartRecommendations(userId: string): Promise<ContentItem[]> {
try {
const userBehavior = await fetchUserBehavior(userId);
if (userBehavior.isEmpty()) {
// 冷启动：返回运营配置的默认列表
return getDefaultRecommendations();
}
const modelInput = transformToModelInput(userBehavior);
const predictions = await callLightweightModel(modelInput); // 本地模型 or mock
return rankAndFilter(predictions);
} catch (error) {
// 关键：记录错误但不中断主流程
logger.error('Recommendation failed', { userId, error });
return getDefaultRecommendations(); // 优雅降级
}
}
有人吐槽：“你这代码太啰嗦了，一行能搞定的事写十行。”
我说：“等你半夜被 oncall 叫醒查线上问题时，你会感谢现在啰嗦的我。”
技术选型：没有银弹，只有权衡
中间当然踩过坑。比如一开始想用 Redis 做实时特征缓存，结果发现内存不够，频繁 evict。后来换成 本地 LRU + 定期刷新，性能反而更稳。
又比如，为了“高大上”，尝试用 GraphQL 做 API，结果前端同事抱怨：“我只想拿个列表，你让我写 query？” 最后还是切回 RESTful，加了个 fields 参数控制返回字段。
技术选型的核心，不是“哪个最先进”，而是：
- 是否匹配当前产品阶段？（早期重速度，后期重稳定）
- 团队是否熟悉？（别为了用 Rust 把全组逼疯）
- 资源是否支撑？（别在 1G 内存的机器上跑 Kafka）
下表是我总结的几个常见场景的权衡参考：
| 场景 | 优先考虑 | 可接受的妥协 |
|---|---|---|
| MVP 验证 | 开发速度、易调试 | 性能、扩展性 |
| 核心交易链路 | 稳定性、可观测性 | 开发效率 |
| 数据分析类 | 准确性、可追溯 | 实时性 |
| 用户侧功能 | 体验、加载速度 | 后端复杂度 |
记住：技术是手段，不是目的。产品需要的是解决方案，不是技术展览。
资源协调：技术人的“软技能”比你想象的重要
很多人以为技术探索就是埋头 coding，其实沟通和协调才是最大瓶颈。
那次项目里，我花最多时间的不是写代码，而是：
- 和运维争论“为什么不能开新端口”（最后妥协用现有网关）
- 跟测试解释“这个功能不需要全覆盖，因为会灰度发布”
- 给老板画图说明“为什么我们需要 2 周做数据监控，而不是直接上线”
甚至有一次，为了抢一台测试机，我在茶水间堵住隔壁组的 leader，硬聊了 20 分钟。
这些事看似“不技术”，但没有资源，再好的想法都是空中楼阁。技术人得学会“向上管理”、“横向拉通”，用对方听得懂的语言讲清价值。
比如跟老板说：“如果不上监控，上线后出问题，排查时间至少 4 小时，影响 GMV。” 比说“我们需要可观测性”有用得多。
效果如何？数据不会说谎
双11当天，我们灰度放量 5%。结果：
- 点击率提升 8.2%（没达到 20%，但正向）
- 崩溃率 0（得益于 fallback 机制）
- PM 在群里发了红包 🎉
更重要的是，我们建立了一套可复用的推荐框架。后续其他业务线想加类似功能，直接 copy 模块，改配置就行。
而我，也在这个过程中明白了：真正的技术探索，不是追求酷炫，而是在产品目标和现实资源之间，找到那个最优解。
辞职后的反思：技术人该探索什么？
现在休息了半年，回头看，很多“技术探索”其实是在浪费生命。比如：
- 为了用新框架而重构，结果业务没变，bug 反而多了
- 追逐“云原生”“Service Mesh”，但团队连基本 CI/CD 都没跑顺
- 在低价值模块上过度设计，搞得后来者不敢动
真正有价值的探索，应该满足两个条件：
- 服务于明确的产品目标（哪怕只是“提升开发者体验”）
- 在现有资源下可落地、可验证
否则，就是自嗨。
最后一点建议
如果你也在大厂卷着，不妨试试：
- 下次接到需求，先问“为什么要做这个？”
- 动手前，评估下人力、算力、时间是否够
- 写代码时，多想一步“三个月后谁来维护？”
- 技术方案评审时，别只讲架构图，讲清楚“它能带来什么业务价值”
技术探索不是闭门造车，而是在产品愿景和资源现实之间跳舞。跳得好，产品起飞，技术成长；跳不好，摔得鼻青脸肿。
我现在还在思考下一步去哪。但有一点很确定：无论去创业公司还是大厂，我都会坚持——用技术解决真实问题，而不是制造更多问题。
对了，如果你在深圳，欢迎约咖啡聊聊。我请，毕竟……我现在有的是时间 😅
评论 0