真正把 Prova 做上线之后，我才发现 code 反而是容易的部分

Prova 真正开始让我觉得“这不是 demo 了”，是在它不再允许我自欺欺人的那个时刻。

Homepage 可以很长时间都维持在 aspirational 的状态。

但一个已经 live 的产品不行。

一旦用户可以 signup、confirm email、落到错误的 state、碰到 billing、submit work，并且理所当然地期待 system 记住之前发生了什么，bottleneck 就变了。

产品开始对外做出真实承诺。于是那些原本看不见的工作，突然全都变得很显眼。

如果你之前看过我在 3 月和 4 月初连续写的那三篇关于从 Claude Max 转到 Codex 的文章，你会知道那个 experiment 现在还在继续。我已经公开答应会在 May 2, 2026 发布一篇正式 follow-up，我也打算把这个承诺守住。这篇不是那篇。

但 Prova 更早地逼我意识到了一件更有用的事：

当某样东西不再只是一个有名字的 idea，而开始变成真实产品的时候，bottleneck 就会变。

至少，这就是我这次 build 的实际感受。

难的不是让 LLM generate code。

难的，是 code 周围的所有东西。

如果你现在也在用 AI 做产品，尤其是那种会碰到真实用户、真实付费、真实 product state 的东西，我觉得这大概就是最少人会提前提醒你的部分。

更有价值的 lesson 是：当一个产品不再只是 demo 的时候，真正开始重要的到底是什么。

起名字其实是最容易的部分

我得承认，给 Prova 起名字，是整个过程中比较轻松的决定之一。

因为这个名字确实和产品本身非常贴。

Prova 的意思接近 proof 或者 test。而这几乎就是这个产品的工作。它不是为了哄人感觉自己已经是 builder 了。它是为了逼你拿出证据，证明你真的做出了东西。名字好记、好用、好搜。换句话说，那才是 easy part。

真正难的部分从那之后才开始。因为当 Prova 不再只是一个名字和一个 landing page，它就开始要求所有真实产品都会要求的那些不 glamorous 的工作：

• assessment logic
• onboarding state
• authored progression
• review visibility
• billing flows
• auth hardening
• content publishing
• release gates

这也改变了我对 AI tools 和 product building 的看法。

Prova 其实必须变成什么

Prova 现在是一个面向 marketers 和 advertising professionals 的 structured AI builder program，目标是帮助他们从“使用 AI tools”走向“搭建真实 workflows、pilots 和 operating systems”。落到产品层面，这意味着 assessment 和 onboarding、一个 sprint-first 而不是 chat-first 的产品体验、review-driven progression、durable product state，以及一个更像围绕当前 sprint 的 office hours，而不是 generic AI chat box 的 mentor layer。

说清楚一点：我并不是在说 Prova 已经“做完了”。我当然也想这么说，然后直接 move on，但那样会过于方便，而且大概也不真实。今天更准确的 framing 是 soft launch：core production system 已经 live 并且能工作了，但还有一些刻意留在 launch-readiness 清单里的事情，比如 billing portal return-path cleanup，以及更完整的 MFA automation coverage。我反而觉得，这让这篇文章更有用，而不是更没说服力。现实世界里的 product building 就是这样。没有做完。也不假。只是已经真实到，下一次出错会开始有代价。

那些我没法直接 generate 出来的工作

任何 AI product 最容易做出来的版本，几乎都是 demo 版本。

你可以很快让它看起来“像活着”：

• 一个 homepage
• 一个 chat box
• 几张很 slick 的截图
• 一句很会说话的产品文案

这些东西用来做 launch teaser 很有用。

但如果你想真正理解工作在哪里，它们就没那么有用了。

对我来说，真正的工作出现在六个地方。

1. Sprint system 不能再继续“装得很像”

我不想让 Prova 变成那种 landing page 上看起来很有结构，但用户一进来里面就马上变 generic 的产品。

Fixed authored sprints 在一段时间里当然有用。

直到它们不够用了。

真正的问题出现在这里：learner 明明通过了一个 sprint，但他接下来真正的 gap，并不是 catalog 里下一个 authored sprint。

最偷懒的做法会是：

"干脆让模型自己发明下一个 sprint 吧，title、rubric、review criteria、全部一起发明。"

我不相信这种做法。

所以 system 必须更严格。

现在 reviewer 仍然可以在 authored path 正确的时候推荐 canonical next sprint。它也可以给出 adaptive detour，也就是先插入一个临时 sprint，帮 learner 修补 foundation gap，再回到主路径。而当下一个真实 gap 落在 authored catalog 之外时，它才会请求一个 composed sprint。

这在 blog post 里看起来很小。

放到产品里，一点也不小。

因为 composed sprint 不是“动态文本”这么简单。

它要先创建 placeholder sprint，要持久化 assignment，要保留回到 canonical roadmap 的 return path，要把 sprint packet 填完整，然后还要让整个 system 把它当成真实的 product state 来对待。

让这件事仍然值得信任的 constraint 很简单：

模型不能自己决定标准。

Composed sprint 只负责填 packet：title、summary、context、assignment、example。

Submission schema 和 review rubric 仍然来自 authored template sprint。

这是整个 build 里我学到的最大东西之一。

如果你希望一个动态系统还能保持可信，就要把 contract 固定住，让模型只在 contract 里面发挥。

这也是 Codex 真正帮到我的地方。不是那种 flashy 的“看，它生成了什么”。而是更有用的那种：migrations、router logic、placeholder lifecycle、request state、integration tests，以及所有那些很 boring、但会让动态产品没那么 fake 的 contract work。

我也得承认，那种更偷懒的版本其实短暂地诱惑过我。让模型更 clever 一点。让 system 更 magical 一点。后面再收拾。这个想法听起来很好，直到你开始想象：如果一个 paying user 被分到了错误的 sprint，你要怎么跟他解释。

2. Retrieval 必须变成 curricular，而不只是 semantic

当我开始让 system compose sprints 的那一刻，retrieval quality 就不再只是 backend detail。

它变成了 curriculum quality。

如果产品要去 compose 一个关于 tooling、measurement、或者 competitive intelligence 的 sprint，它就不能只是从 knowledge base 里抓几段“差不多相关”的 chunks，然后指望整个 packet 看起来 coherent。

Knowledge base 本身必须更聪明。

我们用真实 corpus 重建了它：blog posts、course modules、transcripts、companions、templates，以及深度资源。

然后，我们根据内容类型，采用了不同的 chunking 方法。

叙事型 blog posts 可以保留更大的 chunks。

Instructional modules 需要 heading-first chunks。

Templates 和 reference assets 需要更结构化的 chunking，这样 tables、checklists、slide references 和 quick-reference sections 才不会被压平为 generic paragraphs。

接下来就是 tagging。

不只是“这段内容在讲什么”，还包括：

• 这是什么类型的 chunk
• 它适合哪些 topic tags
• 它更适合哪个 audience
• 它对应什么 difficulty level

这样一来，retrieval 就不再是“nearest vector wins”，而更像 curricular matching。

产品可以问出这样的问题：

"给我这个 topic、这个 audience、这个 level 下的 grounded material。"

这比“往 demo 上贴一个 RAG”要严肃得多。

3. Evals 必须测试整个 pipeline，而不只是 model

这可能是我这次最重要的学习。

我不想因为某个 composed sprint 在 UI 上看起来还不错，就宣布胜利。

所以 eval system 必须跟着产品一起长大。

一开始，是 sprint review eval harness。

然后 composition 加上了 retrieval gate，本质上是一个 pass/fail check，用来确认 tagged retrieval 相比 untagged baseline 是否真的提升了 grounded material。

再然后，composition 加上了完整的 end-to-end harness：

• compose sprint packet
• generate schema-valid synthetic submissions
• 用真实 reviewer 跑这些 submissions
• 从 grounding、audience differentiation、difficulty gradient、curriculum coherence、review quality，以及与 authored work 的 comparability 这些维度来 judge 结果

这才是真正的 learning loop。

用更直白的话说，它的目标是防止“personalized progression”退化成 fake personalization。如果 system 要说“下一个 sprint 真的是给你的”，那它不能只靠一个看起来还行的 packet。它必须拿得出证据，说明这个 sprint 是 grounded 的、level 是合适的，而且仍然能用和 authored curriculum 一样的标准来 review。

不是“model 能不能返回 JSON？”

而是：

• packet 还 grounded 吗
• track framing 真的改变了最终的 work product 吗
• level 2 和 level 5 在体感上真的不同吗
• reviewer 还会不会做出正确的 pass/revise 判断
• composed sprint 还像是 curriculum 的一部分吗，还是像是漂在旁边的异物

这条 loop 暴露出了一堆真实问题。

那些本来该是 revise 的 submissions，明明已经刻意做弱了，却还是太强。

不同 track 之间，audience framing 会塌掉。

Measurement packet 看起来讲得很顺，但其实并没有回答不同 learner 的不同 trust questions。

对我来说，其中一个很 humbling 的 moment 是：我开始意识到，一个东西在 UI 上“看起来挺不错”的时候，依然可能一问就散。一个 packet 可能读起来很顺，但还是太 generic。一个 revise case 可能看上去合理，但还是太容易。老实说，这对我的 ego 挺有帮助。

这也是为什么我觉得这一块特别重要。

System 变好，不是因为我写出了一个很好的 prompt。

而是因为它能先在 eval harness 里对我失败，再在真实用户面前失败之前被我看见。

真正的学习，大量发生在 4 月 8 日到 10 日的那个紧密 loop 里：

• schema groundwork
• composed sprint lifecycle
• tagged knowledge rebuild
• retrieval gate
• composition calibration
• full eval pass
• integration coverage
• browser QA on the live flow

这个顺序是重要的。

这不是一次奇迹。

这是一个被控制住的 loop。

4. 那些承载信任的表面，必须是真的

这也是产品和 demo 真正分开的地方。

如果下面这些东西不成立，没有人会在乎你的 AI layer 看起来多优雅：

• email confirmation 会坏
• Google sign-in 很 flaky
• 用户会卡在 auth loop
• abuse controls 缺失
• account hardening 像是事后才想到

对 Prova 来说，这一层 credibility 最后包括：

• 能把用户送回正确产品流程的 email confirmation
• Google SSO
• optional app-based two-factor auth（TOTP MFA）
• auth 和 assessment 上的 Turnstile protection

这种工作很少有人会拿出来炫耀，因为听起来太 operational，也太 boring。

但我觉得这是个错误。

恰恰是在这些 operational、boring 的地方，产品才会赢得信任，或者悄无声息地失去信任。

5. Billing 必须是可测试的，而不只是“脑补得通”

我越来越怀疑那些把 monetization 说得像“只差一张 Stripe 截图就解决了”的 builder。

Billing 变得很真实，非常快。

问题不只是：

"技术上，有没有人能付钱？"

而是：

• trial state 期间会发生什么
• webhook state 如果晚到会发生什么
• 怎样安全地测试，而不是在自己的 revenue surface 上演戏
• 怎样验证整个 flow，而不是为了图省事发明一堆 one-off exceptions，最后把 system 弄得更不可靠

现在的 Prova 已经有了真实 subscription flow，以及一个专门用于更安全 billing verification 的 internal QA checkout path。听起来也许很小。其实一点都不小。产品越认真，你就越需要办法在不自欺的情况下测试商业逻辑。

6. Operations 必须成为产品的一部分

Prova 真正开始让我觉得像一个产品，而不是一个 feature 的时刻之一，就是我不得不把它当成一个独立的 operational system，而不是塞进原有 site 里的小功能。

Separate production system.

Separate Supabase project.

Separate Vercel project.

Separate auth configuration.

Separate billing setup.

Separate release gates.

这串话不 sexy。

但它很可能恰恰是最重要的一串话。

因为产品不会只在 UI 这一层坏掉。它们会在 systems 接触的地方坏掉，在 assumptions 外漏的地方坏掉，在 environments 漂移的地方坏掉，在有人说“这个 launch 后再补”的地方坏掉，然后所谓的 after-launch version 其实从来没真正出现。

我越做 Prova，越尊重这些 boring 的 operational sentences。

如果你想给自己的 AI product 做一个快速 pressure test，可以问：

• 当 model 变动态时，什么 standard 仍然保持 fixed
• 什么 retrieval 能让 output 保持 grounded
• 什么 eval 能在 user 之前发现 fake personalization
• 哪个 auth、billing 或 state edge 会让你明天就觉得丢脸

如果这些问题的答案还很模糊，那这个产品大概还是更像 demo，而不是 system。

真正重要的 proof

我不想只在抽象层面谈 productization，因为那样听起来会比真实情况更像哲学。

最重要的 proof 不是“我写了多少 migrations？”

而是：现在到底有什么是真的对用户可用的？

在 soft-launch 这个阶段，产品现在已经可以比较可信地说：

• email signup 和 confirmation 可以工作
• Google SSO 可以工作
• optional TOTP MFA 可以工作
• downloadable resources 和 signed downloads 可以工作
• sprint submission 和 AI review 可以在 production 里工作
• Stripe checkout handoff 可以工作

这才是 buyer-facing 的 proof。

在这之下，还有来自 repo 和 rollout 的 system proof：

• 17 个 Supabase migrations 已经进入当前 production schema bootstrap
• 4,390 条 production knowledge-base rows 已经发布并完成 composition retrieval tagging
• 38 份 downloadable resources 已发布
• tagged retrieval gate 跑赢了 untagged baseline
• 完整的 18-case composition eval suite 已经通过 gate
• 还有一个更安全的 internal QA checkout path 用于 billing verification

我列这些数字，不是为了显得自己很忙。

我现在还没有的，是来自足够数量用户的广泛 external proof，他们会说：“这个东西改变了我的结果。”现在还太早，我也不想假装已经有了。

我之所以把这些数字写出来，是因为如果你只用 launch language 去谈产品，就会非常容易低估“把一个 idea 变成产品”到底意味着什么。

重要的不是数字本身。

而是这些数字代表了什么：

• sprint system 不再只是装饰
• retrieval 不再模糊
• evaluation 不再只是表演
• product state 已经 durable 到可以依赖

看不见的工作，依然是工作。

而且通常是更难的工作。

这件事改变了我脑子里的什么

我还是觉得 AI tools 很重要。当然重要。

Codex 在这次 push 里很有用，因为它给我的感觉是 competent、careful、methodical。它很擅长帮我推进 engineering work，而不会附带太多 emotional theater。Claude 对我来说仍然更适合那些更偏 taste、更偏 creative 的工作。

但 Prova 把我推向了一个更重要的结论：

我认为 AI 可以加速 implementation，但它并不会替你省掉对于 product boundaries、sequencing、credibility、以及 operational truth 的 judgment。

那个 judgment，本身就是工作。

Landing page 不是产品。

有名字的 concept 不是产品。

Chat interface 不是产品。

Generated component 当然也不是产品。

对我来说，让一个东西真正开始像产品的，是 visible experience 背后的 invisible architecture。当真实用户可以进入、付费、推进、卡住、恢复、提交 work，并且相信自己看到的 state 时，你就不再是在玩一个 demo。你是在做出承诺。

而我觉得，产品建设真正变严肃，就是从承诺开始的。

这是对我更有用的 April lesson

我依然欠着那篇完整的 30-day Codex verdict，会在 May 2, 2026 发布。

那篇文章才是讲 cost timeline、limits story、我怀念 Claude 的地方，以及我日常 working model 发生了什么变化的正确位置。

但 Prova 已经先教会了我一件比 tool comparison 更耐用的事：

AI product building 真正有意思的部分，往往不是 demo。

而是那个 system 开始对用户做出真实承诺的时刻。也是那个时刻，你会意识到：这些承诺里有多少其实住在 generated code 之外。

我现在更尊重这一部分了。

老实说，我也觉得应该有更多 builder 谈谈这一部分。

常见问题

Prova 是什么？

Prova 是一个面向 marketers 和 advertising professionals 的 structured AI builder program，帮助他们从“使用 AI tools”过渡到“搭建真实 workflows、pilots 和 operating systems”。用产品语言来讲，它意味着 assessment、onboarding、sprint progression、review logic、resources、billing、auth 和 product state 一起运作，而不是让一个 AI chat box 假装自己就是整个 system。

Prova 里的 composed sprint 是什么？

Composed sprint 是为真实 learner gap 动态生成的 sprint packet，这个 gap 落在当前 authored catalog 之外。最重要的 constraint 是：model 不能自己发明标准。Packet 是动态的，但 submission schema 和 review rubric 仍然来自 authored template sprint。

为什么 AI product building 在 demo 之后会更难？

因为一旦真实用户可以 signup、付费、从错误里恢复、submit work，并且相信自己看到的 state，产品就开始做出承诺。到那个阶段，AI layer 周围那些看不见的 systems，比如 auth、retrieval quality、evals、billing 和 operations，会比 demo 里那个让人惊艳的第一轮 output 更重要。

如果你现在也在用 AI 做东西，我是真的很好奇：

你的项目第一次让你觉得“不舒服地真实”的瞬间是什么时候？也就是 demo 变成承诺的那一刻。

先写到这里。

Cheers, Chandler