在传统软件开发中，工程师们常常陷入一个困境：我们花费大量时间编写单元测试、集成测试、端到端测试，追求代码覆盖率，但最终交付的软件仍然无法满足用户的真实需求。Dima 在其文章《Build Software. Build Users》中提出了一个根本性的问题："即使我们编写了所有类型的测试，这能保证高质量的软件吗？" 实践表明答案是否定的。
问题的核心在于，工程师们往往没有真正理解用户。他们构建了一个完美的啤酒订购模块，能够处理所有可能的啤酒订购方式，但当第一个顾客喝完啤酒询问洗手间在哪里时，整个酒吧爆炸了。这个比喻生动地揭示了传统开发范式的局限性：我们关注功能实现，却忽视了用户在实际使用场景中的完整需求。
用户优先的开发范式：从代理模拟开始
现代软件开发需要一种新的范式：先理解用户，再构建软件。Dima 提出的 "用户优先" 方法建议，在编写第一行代码之前，先构建能够模拟目标用户行为的 LLM 代理。这种方法的核心思想是：
-
用户代理构建：为每个用户群体创建详细的用户档案，描述他们的日常活动、工作流程、背景知识，以及我们的软件如何融入他们的生活。
-
快乐路径定义：为每个用户群体定义典型的用户流程，这些路径可以用自然语言、伪代码或实际代码来描述，具体取决于流程需要的精确程度。
-
迭代开发循环：构建用户代理 → 构建软件 → 让用户（真实和代理）与软件交互 → 优化用户代理 → 改进软件，如此循环往复。
这种方法的优势在于，LLM 代理基于对整个互联网的训练，可能比我们更了解用户的需求和期望。通过让代理模拟用户行为，我们可以在实际开发之前就发现潜在的问题和需求。
实时用户行为分析的三层架构
要实现用户优先的开发范式，我们需要一个能够实时捕获、处理和分析用户行为的系统架构。Redpanda 提出的三层架构为此提供了技术基础：
1. 数据摄入层
数据摄入是整个系统的起点，负责从各种来源收集数据并将其传送到分析数据存储。数据源可以包括：
- 数据库的变更数据流
- 微服务和业务应用程序的事务性事件
- 前端用户交互事件
- 第三方系统集成
这些数据被摄入到流数据平台（如 Redpanda 或 Apache Kafka）中，实现数据源和分析数据存储之间的解耦。这种架构带来了几个关键优势：
- 解耦设计：数据源和分析数据存储可以独立扩展和演进
- 负载均衡：流平台可以缓冲突发的流量高峰，防止分析基础设施过载
- 发布 - 订阅语义：数据可以被实时路由到多个目的地，支持并发处理
对于不支持 Kafka API 的客户端，可以使用 Redpanda Connect 等工具进行数据集成。Redpanda Connect 是一个轻量级流处理器，包含 200 多个预构建的连接器，可以高效可靠地将数据从各种系统传输到 Redpanda。
2. 指标计算层
数据到达流平台后，需要进行清洗和转换才能发送到分析数据存储。这一层的关键任务包括：
- 数据转换：将数据转换为易于查询的格式
- 数据丰富：为数据添加额外的上下文信息
- 数据规范化：统一数值和数据类型
- 数据过滤：过滤掉不相关的数据
- 指标计算：创建更相关的派生指标
这些转换应该在数据从 Redpanda 到达时实时进行，以最小化处理延迟。为此，我们选择流处理引擎而不是批处理和微批处理技术。流处理器可以执行有状态聚合、查找连接以进行丰富化、流之间的连接以及窗口操作，将数据转换为适合运行分析的格式。
3. 服务层
服务层是整个架构的最后一步，负责将存储在分析数据库中的指标提供给用户。这一层包括：
- API 层：为面向用户的应用程序提供 API 接口，获取特定指标或聚合数据
- 数据可视化工具：为内部用户（如产品经理或数据分析师）提供详细的数据视图
- 实时流服务：对于需要实时洞察的低延迟应用程序，可以直接从 Redpanda 中的处理洞察主题流式传输
对于分析数据存储，我们选择实时在线分析处理（OLAP）数据库，如 Apache Druid、Apache Pinot 或 ClickHouse。这些数据库具有以下关键优势：
- 支持流数据摄入：原生支持从流数据源（如 Kafka 和 Redpanda）摄入数据，确保数据新鲜度
- 超低查询延迟：高效的数据存储格式和索引机制确保即使复杂查询也能快速处理
- 高查询吞吐量：分布式架构支持高并发，可以同时处理大量查询
从用户行为到产品决策的自动化闭环
将用户优先的开发范式与实时分析架构相结合，我们可以构建一个完整的反馈循环系统：
阶段一：用户行为捕获
系统实时捕获用户在应用程序中的每一个交互：
- 点击、滚动、悬停等 UI 交互事件
- 功能使用频率和时长
- 错误和异常情况
- 用户满意度指标（如 NPS 评分）
阶段二：实时分析与洞察生成
捕获的数据通过三层架构进行处理：
- 数据摄入层将原始事件发送到流平台
- 指标计算层实时计算关键指标和用户行为模式
- 服务层将处理后的数据提供给分析工具和用户代理
阶段三：用户代理模拟与反馈
LLM 用户代理基于实时分析数据模拟用户行为：
- 代理执行预定义的 "快乐路径"
- 代理识别异常行为和潜在问题
- 代理提供改进建议和功能需求
阶段四：产品决策与迭代
基于用户代理的反馈，产品团队可以：
- 优先处理高价值的功能改进
- 快速修复影响用户体验的问题
- 验证新功能假设的有效性
- 优化用户界面和工作流程
实施参数与监控要点
关键性能指标
-
数据新鲜度：数据从产生到可查询的时间延迟
- 目标：< 1 秒
- 监控点：端到端延迟、处理延迟、摄入延迟
-
查询延迟：从查询发起到结果返回的时间
- 目标：P95 < 100 毫秒
- 监控点：查询响应时间、数据库负载、缓存命中率
-
系统吞吐量：单位时间内处理的查询数量
- 目标：支持 1000 + 并发用户
- 监控点：QPS、并发连接数、资源利用率
技术选型建议
-
流数据平台：
- Redpanda：性能更高、资源消耗更低的 Kafka 替代方案
- Apache Kafka：成熟稳定，生态系统丰富
- 选择标准：吞吐量要求、运维复杂度、成本考虑
-
流处理引擎：
- Apache Flink：功能全面，状态管理强大
- Apache Spark Streaming：批流统一，易于上手
- 选择标准：处理逻辑复杂度、状态管理需求、开发团队熟悉度
-
OLAP 数据库：
- ClickHouse：单表查询性能优异
- Apache Pinot：多表关联查询优化
- Apache Druid：时间序列数据分析专长
- 选择标准：查询模式、数据规模、运维能力
监控与告警配置
-
数据质量监控：
- 数据完整性检查：确保所有必要字段都存在
- 数据准确性验证：与源系统进行定期比对
- 数据一致性监控：跨系统数据一致性检查
-
系统健康监控：
- 资源利用率：CPU、内存、磁盘、网络
- 服务可用性：各组件健康状态
- 性能指标：延迟、吞吐量、错误率
-
业务指标监控：
- 用户活跃度：DAU、MAU、用户留存率
- 功能使用情况：各功能使用频率和时长
- 用户满意度：NPS、用户反馈评分
风险与限制
技术风险
-
数据一致性挑战：在分布式实时系统中维护数据一致性是一个复杂的问题。需要权衡一致性、可用性和分区容错性。
-
系统扩展性限制：随着用户量和数据量的增长，系统可能需要重新架构。需要提前规划水平扩展策略。
-
容错与恢复：实时系统对故障的容忍度较低。需要设计完善的故障检测和恢复机制。
业务风险
-
用户代理准确性：LLM 代理对用户行为的模拟准确性直接影响反馈质量。需要持续优化代理模型和训练数据。
-
隐私与合规：用户行为数据的收集和处理需要符合相关法律法规（如 GDPR、CCPA）。需要建立完善的数据治理框架。
-
过度自动化风险：完全依赖自动化决策可能导致忽视人类直觉和创造力。需要在自动化和人工干预之间找到平衡。
结论
实时用户行为分析与产品迭代反馈循环系统代表了软件开发范式的根本转变。通过将用户优先的开发理念与现代化的实时分析技术相结合，我们可以构建更加智能、响应更快的产品开发流程。
这种方法的真正价值在于，它将软件开发从一个孤立的工程活动转变为一个持续的学习和改进过程。工程师不再仅仅是代码的编写者，而是用户需求的探索者和解决方案的设计者。产品团队不再依赖猜测和假设，而是基于真实的用户数据和智能模拟做出决策。
正如 Dima 所指出的："质量软件，在我看来，对用户来说看起来很简单。但实现这种简单性需要深刻的理解 —— 用户的工作流程、能力、背景知识，以及我们的软件如何融入他们的生活的一切。" 通过构建实时用户行为分析与反馈循环系统，我们不仅能够更好地理解用户，还能够将这种理解转化为持续的产品改进和用户满意度的提升。
未来，随着 LLM 技术的进一步发展和实时分析技术的成熟，这种用户优先的开发范式将变得更加普及和强大。软件开发的未来不在于编写更多的代码，而在于更好地理解和服务于使用这些代码的人。
资料来源：
- Dima. "Build Software. Build Users" (2025-12-27)
- Redpanda. "Bridging the data gap: an architecture for real-time user-facing analytics" (2024-07-23)