3天3个功能：1.5万行代码怎么切出来的

一个功能通常吃掉一周。设计、实现、界面、国际化、营销页、文档，逐个来。这是作者学到的规则。4月28日到30日，他发了三个：关键词搜索、模型上下文协议服务器、月刊。41次提交，15380行代码。

不是并行，是切片

先澄清：不是三管齐下。一天一个，三天发完。能成的原因很简单——每个功能被切成阶段，丢给克劳德（Claude，AI编程助手）的单元很小。

这三个功能建在Apsity仪表盘之上。EP.02搭了仪表盘，EP.03加了AI洞察。本周的三件事叠在上面：关键词发现、直接从克劳德调用数据、自动化月刊。

它们不是孤立的。是一个流程。Apsity本来就能显示已注册应用的数据——收入、下载量、关键词排名、竞品变动。缺的是三件事："新关键词从哪找？""怎么在其他工具里用这些数据？""这个月发生了什么，我要一页看完。"

关键词搜索解决发现。应用商店优化（ASO）归根结底是选词。只看已注册关键词是鱼缸视野，得看别人怎么出现。于是拉取18个国家的iTunes前50，让AI总结，用户把有潜力的词存进观察清单。

模型上下文协议（MCP）服务器是出口。有时候你想用自然语言问克劳德，而不是打开Apsity。"昨天收入怎么样？"——克劳德问Apsity，然后回答。这个想法从EP.15做npm-subscriber-mcp时就有了。

月刊是回顾。EP.03做了每日提醒，但每日太吵。过了一个月，你想回头看发生了什么，而数据散在各处。每月1号聚合，邮件发送，完事。

连起来：发现→使用→回顾。 workflow两端原本缺失的部分。所以一起发。

正方：切片是唯一的杠杆

三个周级功能三天完成，原因确实简单。作者从不把功能看成一大块。切成小阶段，每阶段以可运行的产物和一次提交结束。

月刊的切片长这样：

阶段1——语言设置（设置里加ko/en）
阶段2——月度聚合函数
阶段3——克劳德生成月刊正文
阶段4——4个卡片组件（指标/图表/评论/建议）
阶段5——月刊页面渲染
阶段6——邮件发送（4卡片内联）
阶段7——命令行测试工具

阶段1和2独立。阶段3依赖阶段2的输出。阶段4和5建在阶段3的结果上。依赖图看起来是串行，但阶段2和4可以并行。早点定义数据结构，然后分别做聚合查询和卡片界面。

两个好处。第一，丢给克劳德的单元变小。"做个月刊"太模糊，"做个月度聚合函数，输入是这个结构，输出是那个结构"就清晰。克劳德的输出质量取决于输入的精确度。

第二，每阶段结束都有东西能跑。不是"做了80%但跑不起来"，是"阶段2跑完，聚合函数能返回正确数据"。心理账户不同，回滚点也不同。

作者提到一个细节：阶段3让克劳德生成正文，但正文结构是固定的。不是"随便写个月度总结"，是"按这四个板块写，每个板块有字数限制和必含数据点"。约束给足，AI输出才稳。

卡片组件的设计也体现切片思维。四个卡片独立开发，最后拼成页面。如果某个卡片有问题，不影响其他三个上线。阶段6的邮件内联是常见坑点——网页渲染和邮件客户端渲染是两回事，单独成一个阶段，专门测试各邮件客户端的兼容性。

反方：切片不是万能药

但切片有代价。阶段切得越细，上下文切换越频繁。作者三天41次提交，平均每天近14次。这意味着每天至少14次进入"这是什么阶段、当前状态、下一步做什么"的认知加载。

对于复杂功能，阶段间的依赖可能隐藏。月刊的依赖图被描述为"看起来串行，但2和4可以并行"——这个判断需要全局视图。新手容易切错，导致后期返工。阶段3依赖阶段2的输出，如果阶段2的数据结构定义有问题，阶段3、4、5、6全要改。

另一个风险：切片让人产生"进度很快"的幻觉。七个阶段做完六个，感觉"只剩一个"，但阶段6（邮件发送）可能卡住三天。邮件客户端的兼容性、退信处理、图片内联、垃圾邮件过滤，每个都是深坑。作者提到"专门测试各邮件客户端"，说明踩过或预见到了。

克劳德的单元变小，但协调成本上升。41次提交背后是41次提示工程（prompt engineering）。每次都要交代背景、当前代码状态、期望输出。对于大型代码库，"当前代码状态"本身的描述就很长。作者没有提上下文窗口（context window）的限制，但15380行代码的改动，不可能每次全量塞进提示。

还有一个未言明的前提：Apsity的底子已经打好。EP.02和EP.03的基础设施——仪表盘框架、AI洞察管道、数据模型——是这三个功能的地基。如果从头建一个新产品，三天三个功能是不可能的。切片的前提是已有可复用的模块和稳定的数据流。

国际化（i18n）被轻描淡写地放在"通常吃掉一周"的清单里，但实际很耗。阶段1的语言设置只是开关，真正的翻译工作——月刊正文的多语言生成、邮件模板的多语言版本——被分散在各阶段。作者没有提翻译是谁做的：克劳德生成？人工校对？还是只做英语和韩语？如果是AI生成，质量是否经过审核？这些细节被切片的光滑表面盖住了。

判断：切片是工具，不是方法论

这件事的真正价值，在于展示了AI辅助开发的一种可行节奏。不是"用AI写代码更快"这种笼统说法，而是具体的操作参数：阶段粒度控制在几小时到一天，每个阶段有明确的输入输出定义，AI负责实现而人负责验收。

作者没有说"这是最佳实践"，只是记录。但记录本身有信息量：15380行代码，41次提交，7个阶段——这些数字暗示了工作量的分布。平均每次提交375行，对于AI辅助开发来说偏保守，说明作者在看AI的输出，而不是全盘接受。

三个功能的选择也有讲究。关键词搜索是数据输入，MCP服务器是数据输出，月刊是数据消费。形成一个闭环，而不是三个孤立功能。这种产品思维——用功能组合解决完整用户旅程——比切片技术更值得学。

切片能成功的隐性条件：产品方向已经验证，技术债务可控，AI工具链熟悉。少了任何一条，三天变三周。作者的经历是"在特定约束下的可行解"，不是"普遍适用的加速公式"。

对于读者，可带走的是检查清单：你的功能能不能拆成"几小时能跑通"的阶段？每个阶段的输入输出是否提前定义？AI生成后你有没有人工验证？这些比"我也用克劳德"更重要。

最后，那个命令行测试工具（阶段7）容易被忽略。它不是用户可见的功能，是开发者的安全网。发邮件前能本地跑一遍，不用真的等每月1号。这种"为开发体验投资"的意识，往往是三天和三周的分水岭。

三天发完，代码在仓库里。但真正的产品验证——用户用不用关键词搜索、MCP服务器的调用频率、月刊的打开率——才刚刚开始。切片加速了开发，没加速验证。这部分时间，省不了。