从需求推演到项目落地：如何判断自研方向是否靠谱

需求推演的价值：先证伪再建设

很多开发者在启动自研项目时，容易陷入"想到什么就做什么"的状态。而需求推演——即系统性地验证方向是否成立——往往比写代码本身更重要。下面这位大三学生的经历，提供了一个很好的范例。

三轮推演：逐步收敛到可行方案

第一轮：多智能体消息总线（被否）

最初的设想是做一个高性能的多智能体消息总线，服务Claude Code、Codex、OpenClaw等工具的Agent间通信。但深入研究后发现：这些Agent的通信瓶颈在LLM推理延迟，而非消息传输本身。应用层用Python字典就能解决，高性能总线属于伪需求。

实用解读：判断一个方向是否成立，关键是找到真正的瓶颈在哪里。如果瓶颈不在你打算优化的环节，再好的技术也解决不了实际问题。

第二轮：LLM结果缓存（被否）

退而求其次，想做LLM结果缓存。但分析后发现：缓存查找相对于LLM调用耗时是零头，GPTCache等现有方案已经覆盖了基本需求，独立做缓存缺乏足够的价值增量。

实用解读：即使方向合理，也要评估"增量价值"。如果已有成熟方案且你的优化空间有限，不如换一个更有挑战性的切入点。

第三轮：C++高性能LLM网关（选定）

最终落在LLM网关方向。核心逻辑是：

• 网关不跑模型，全部工作是hold万级SSE流式长连接并转发，属于纯I/O密集型，epoll技术栈对口
• 缓存降级为网关的一个功能（省token是真实需求，但不应作为核心）
• 有明确对标对象：one-api（Go实现）、LiteLLM（Python实现，高并发下有性能争议）

这个方向的优势在于：技术栈与已有项目（epoll+Reactor RPC框架）高度匹配，同时有真实的性能优化空间。

功能边界与压测方案

计划功能：SSE流式转发、多上游路由、结果缓存、限流。

压测方案：与LiteLLM proxy跑相同的流式并发场景，对比P99延迟、内存占用、长连接上限。

实用解读：求职项目最重要的是有可量化的对比数据。没有压测数据的功能列表只是自嗨，有了P99延迟和内存占用的对比，面试官才能判断你的优化是否真实有效。

已有项目基础

该学生此前已完成两个个人项目：

1. 高性能C++ RPC框架（2025.03-2025.06）：基于epoll+Reactor模式，ET事件触发，自定义二进制协议，固定线程池+生产者-消费者队列
2. 类Redis内存KV存储（2025.09-2025.12）：手写链地址法哈希表，RESP协议解析，统一对象模型

这两个项目为LLM网关提供了扎实的网络层和协议层基础。

给开发者的三点建议

1. 先证伪再建设：在动手写代码前，花时间验证方向是否成立。一次深入的需求推演，可能省下数周的无效开发。
2. 找对标对象：有明确对标对象的项目才有说服力。"我做了个XX"不如"我做了个XX，比现有方案快30%"。
3. 功能做减法：求职项目不是产品，核心功能做到极致比堆功能数量重要。SSE流式转发做稳了，比加一堆用不上的路由规则更有价值。

难度评估

对本科生来说，这个方向的难度适中偏上。epoll+Reactor的网络编程、SSE流式处理的边界情况、万级长连接的内存管理，都需要扎实的系统编程功底。但考虑到已有RPC框架和KV存储的项目积累，整体难度在可控范围内。

关键风险点：SSE流式转发的实现复杂度容易被低估——断线重连、背压控制、上游超时处理等边界情况都需要仔细设计。建议优先把单上游的流式转发做稳，再考虑多上游路由。