41次提交，15380行代码。三个通常各需一周的功能，被压缩到72小时完成。作者没加班，只是换了一种拆解方式。
这是Apsity开发者记录的真实交付过程：关键词搜索、模型上下文协议（MCP）服务器、月度报告——三个功能构成完整的数据工作流闭环。
三个功能，一条工作流
Apsity的核心是应用商店数据看板：收入、下载量、关键词排名、竞品动态。但用户反复问三个问题：
「新关键词去哪找？」「怎么在其他工具里用这些数据？」「这个月到底发生了什么？」
关键词搜索解决「发现」。只盯着自己注册的关键词是鱼缸思维。作者拉了18个国家的iTunes前50数据，让AI总结，用户可把潜力词存进监控列表。
MCP服务器解决「使用」。用户想直接在Claude里问自然语言问题：「昨天收入怎么样？」Claude调用Apsity接口返回答案。这个想法从EP.15的npm-subscriber-mcp就开始酝酿。
月度报告解决「回顾」。EP.03的每日提醒太碎。每月1号自动聚合数据，邮件发送，一页纸看完。
发现→使用→回顾。工作流的两端补上了，所以三个功能一起发。
拆解：把「一周」切成七片
月度报告的拆解过程被完整记录：
阶段1：语言设置（韩/英切换）
阶段2：月度聚合函数
阶段3：Claude生成报告正文
阶段4：四个卡片组件（指标/图表/评论/建议）
阶段5：报告页面渲染
阶段6：邮件发送（四卡片内嵌）
阶段7：命令行测试工具
阶段1和2独立。阶段3依赖阶段2的输出。阶段4、5基于阶段3的结果。看起来是串行，但阶段2和4可以并行——只要提前定义好数据格式，聚合查询和卡片UI就能分开做。
两个直接收益。
第一，丢给Claude的单元变小。「做月度报告」太模糊。「写一个聚合上月数据的SQL函数」足够具体。
第二，每阶段结束都有可运行的东西。不是等七天看结果，是每天多次验证方向。
正方：小单元交付是速度的来源
作者的核心论点：速度不是来自加班，来自认知负荷管理。
大功能拆成小阶段后，每个阶段的决策点变少。语言设置只管语言设置，不用想邮件模板。这种隔离让AI辅助编码更有效——上下文窗口里只放当前阶段的需求。
并行空间也被释放出来。阶段2和4的并行依赖「数据格式先行」的约定。提前定义接口，两边各自推进，最后拼接。
41次提交分布在三天，意味着平均每天13-14次代码快照。这不是为了刷数字，是阶段边界的外化。每次提交对应一个可回滚的检查点。
反方：这种方法的隐性成本
但原文也暴露了张力。
「阶段2和4可以并行」——前提是开发者能预判数据格式。如果前期设计偏差，后期拼接成本可能超过串行开发。月度报告的七个阶段看似清晰，实际依赖作者对邮件渲染、卡片布局的预先想象。
另一个问题：三个功能真的「独立」吗？作者承认它们「是一个单一工作流」。这意味着功能间的耦合被设计进去了。如果用户需求变化，这个预设的流可能变成枷锁。
还有15380行代码的质量。三天高强度输出，测试覆盖度、边界处理、技术债务——原文没提，但不等于不存在。小阶段交付加速了可见进度，是否加速了可维护性？
判断：一种特定条件下的可行策略
这个案例的价值不在「三天三功能」的数字，而在它展示了单人开发的约束优化。
作者的条件很具体：已有EP.02/03的底座（看板+AI洞察）、功能间存在预设的工作流关系、AI辅助编码降低实现成本。这些条件不满足，拆解策略的效果会打折扣。
对读者的启示可能是反直觉的：快不是目标，可验证的进度才是。七个阶段的价值不在于并行效率，而在于每个阶段结束都能回答「这步对吗」。
至于MCP服务器的长期意义——让Claude直接调用业务数据——这比关键词搜索或月度报告都更接近基础设施层。如果模型上下文协议成为行业标准，Apsity的早期实验会转化为先发优势。
当然，前提是用户真的愿意在聊天窗口里问「昨天收入怎么样」，而不是打开看板自己点。
作者最后没说的是：这三个功能上线后，用户用了吗？
热门跟贴