有人用AI几天就搭了个完整的内容平台，听起来像技术神话。但读完他的复盘，我发现最值钱的不是"快"，而是那些他没说出口的判断。
一、项目背景：一个"够用就行"的出发点
作者Matheus Catossi（马修斯·卡托西）是个巴西开发者，主业做企业软件。他启动Kuraiq的动机很直接：现有的内容管理工具要么太复杂，要么太贵，要么两者兼具。
他没想造第二个WordPress，也不想复制Substack。目标锁定在"轻量、可嵌入、AI原生"——一个能让其他产品快速接入的内容引擎。
这个定位本身就有意思。不是"我要做最好的CMS"，而是"我要做最省事的CMS"。需求定义阶段就做了减法，后面所有技术选型都围绕这个核心。
二、技术栈：全是现成的，但组合有讲究
三天能跑起来，靠的是"不造轮子"的极端实践。他的选择清单：
前端：Next.js 14（应用路由）+ Tailwind CSS + shadcn/ui组件库。没写多少自定义CSS，组件拿来即用。
后端：Supabase（数据库+认证+实时订阅）。省了自建Auth和WebSocket的工夫。
AI层：OpenAI API做内容生成，Vercel AI SDK处理流式响应。没自研模型，没微调。
部署：Vercel一键托管，边缘函数自动扩缩。
这个组合的关键不是"用了AI"，而是"每个环节都选托管服务"。数据库托管、认证托管、AI托管、部署托管——他把"运维负担"降到了接近零。
作者的原话是：「我花时间最多的是在Prompt工程上，而不是基础设施。」
三、核心功能：AI不是装饰，是工作流
平台有三个AI驱动的功能，但设计思路不是"加AI功能"，而是"用AI重构流程"：
1. 智能草稿：输入主题，AI生成结构化大纲+初稿。作者强调这不是"一键生成文章"，而是"把空白页焦虑降到零"。
2. 动态优化：根据阅读数据（停留时间、滚动深度）自动建议内容调整。这里用了简单的规则引擎+LLM，不是复杂推荐算法。
3. 多版本管理：AI辅助生成同一内容的不同变体（摘要、推文串、邮件版），适配不同渠道。
注意一个细节：他没有做"AI自动发布"。所有生成内容都要人工确认。这是刻意的产品决策——速度要让位于可控性。
四、开发节奏：三天怎么切分
Day 1：搭骨架。Supabase表结构、Next.js项目模板、基础路由。目标是"能登录、能保存"。
Day 2：接AI。Prompt模板、流式响应UI、错误处理。这一天调试时间最长，因为"LLM的不可预测性比想象中麻烦"。
Day 3：打磨体验。加载状态、空状态、移动端适配。作者说这一天"最枯燥但最值钱"——用户不会记得你用了什么技术，但会记得卡顿和报错。
这个节奏有个反常识点：他没有留"惊喜时间"。三天是硬截止，功能必须砍到能 fit 进这个框。结果是MVP（最小可行产品）极其克制，但流程跑通了。
五、踩过的坑：快是有代价的
作者列了三个具体问题，比成功案例更有参考价值：
成本盲区。Vercel和Supabase的免费档够用，但OpenAI API调用量上来后，账单"比服务器贵一个数量级"。他没做用量限制，测试阶段就烧掉了预期一个月的额度。
Prompt债务。早期为了快速出效果，Prompt写得又长又具体。后期想调整语气或格式时，"像在一团毛线里找线头"。现在他在重构为模块化Prompt，但迁移成本已经产生。
幻觉治理。AI生成的内容有事实错误，但平台没有内置校验机制。第一个用户测试时就遇到了" confidently wrong "（自信地错误）的情况，差点砸口碑。
这三个坑有个共同模式：AI让"做出来"变简单了，但"做对"和"做省"的难度没有降低，只是转移到了新环节。
六、产品哲学：工具 vs 代理
作者提出了一个区分框架，我觉得是他复盘里最值钱的部分：
AI作为工具（Tool）：人做决策，AI执行。比如"帮我扩写这段"，"检查语法"。
AI作为代理（Agent）：AI做决策，人监督。比如"根据数据自动优化标题"，"选择最佳发布时间"。
Kuraiq目前停在工具层，但作者认为代理层才是终局。他的顾虑是：代理需要极高的容错设计，而现在的LLM"错误率还撑不起无人值守"。
这个判断和市面上很多"AI自动化"的激进宣传形成对比。作者的原话：「我们高估了12个月的AI能力，低估了3年的AI能力。但产品决策得按12个月做。」
七、商业化试探：还没答案，但有数据
平台目前处于"朋友试用"阶段，但作者分享了两个早期信号：
使用频率：测试用户平均每周创建3.2篇内容，但"智能草稿"功能的采用率是78%，"动态优化"只有23%。说明"降低启动门槛"比"持续优化"更刚需。
付费意愿：小范围问卷显示，个人创作者愿付$9-15/月，企业用户愿付$49-99/月（按团队规模）。但作者强调"样本量太小，只是方向参考"。
他没有公布具体用户数或收入，这个诚实本身就很罕见。很多AI项目的复盘会夸大早期 traction（牵引力），他选择留白。
八、对开发者的启示：快不是目的，是手段
整篇复盘读下来，"三天"其实是最不重要的数字。真正值得记的是这几个判断：
托管优先。自建基础设施的性价比在AI时代进一步下降，除非你有特殊合规需求。
Prompt即代码。需要版本管理、模块化、测试覆盖，但行业还没形成最佳实践。
人工在环（Human-in-the-loop）不是妥协，是产品特性。用户需要"可控的AI"，不是"自动的AI"。
MVP的边界由时间框定，不是功能清单。硬截止逼你做减法，而减法往往是产品力的来源。
作者最后说，Kuraiq的下一步是"慢下来"——补测试、补文档、补错误处理。快是验证假设的手段，不是持续的状态。
这个数据点收束全文：他用AI把开发周期从"预估6周"压到"实际3天"，但接下来要花"至少3周"填快带来的坑。效率提升真实存在，但分布极不均匀——前端最省，AI层最费，治理层被普遍低估。
热门跟贴