2、MVP 场景怎么选：为什么选技术 / AI 自媒体写作

MVP 场景怎么选：为什么选技术 / AI 自媒体写作 ## 这一章要回答什么 知道“先做产品，不先做平台”之后，下一步最关键的问题就是： **第一个 Agent 产品应该选什么场景？** 这个问题看起来像产品选题，实际上直接影响后面的所有工程设计： - Agent 怎么拆 - 流程怎么定 - 上下文怎么组织 - 页面怎么设计 - 成果怎么展示 选对场景，很多设计会自然长出来。...

知道“先做产品，不先做平台”之后，下一步最关键的问题就是：

第一个 Agent 产品应该选什么场景？

这个问题看起来像产品选题，实际上直接影响后面的所有工程设计：

• Agent 怎么拆
• 流程怎么定
• 上下文怎么组织
• 页面怎么设计
• 成果怎么展示

选对场景，很多设计会自然长出来。
选错场景，系统会一直处在“勉强能跑，但很难做好”的状态。

一个好的 Agent MVP 场景，通常具备什么特点

从当前项目倒推，一个适合作为第一版的场景，最好满足下面这几个条件。

1. 输入清楚

用户最好能明确说出自己要什么。

比如当前项目的输入就是：

• 选题
• 角度
• 读者
• 风格
• 字数
• 必须覆盖内容
• 需要避免内容

这些输入天然适合做成表单，也方便被多个 Agent 共享。

2. 输出清楚

如果一个任务最后产出的东西很模糊，就很难判断 Agent 到底做得好不好。

当前项目的输出就很明确：

• 标题
• 提纲
• 初稿
• 审核意见
• 最终 Markdown

这让每一步都能被检查，也方便做人工确认。

3. 中间过程可拆角色

并不是所有任务都天然适合多 Agent。

如果一个任务本质上只是“一次问答”，那硬拆出多个角色，通常只是增加复杂度。
但写作不同，它天然可以拆成：

• 规划
• 研究
• 写作
• 审核

这就给了多 Agent 足够的存在价值。

4. 结果容易展示

MVP 最大的目标之一，是让你能快速向别人证明这个东西“已经有用”。

文章写作的产物非常适合展示：

• 页面里直接能看
• 用户很容易比较前后版本
• 审核意见也容易理解

这比很多“后台自动化”场景更适合当第一版。

5. 不依赖太多外部系统

第一版最好避免过强的外部依赖。

如果场景一上来就需要：

• 对接多个 SaaS
• 拿复杂权限
• 调用很多企业系统
• 写大量同步逻辑

那工程复杂度会被迅速抬高。

当前项目虽然有搜索和模型调用，但整体依赖仍然相对可控，所以很适合做入门型产品。

为什么“文章写作”是一个很好的入门场景

当我们把上述条件放在一起看，会发现文章写作几乎天然适合做多 Agent MVP。

输入和输出都足够清楚

它不是一个完全开放的问题，而是一个相对收敛的创作任务。

输入是任务信息，输出是文章产物。
这让流程非常容易围绕“任务”组织起来。

能自然拆出多个角色

写作不是单一步骤完成的，它天然有多个阶段：

• 先确定方向
• 再补资料
• 再写初稿
• 再审稿修订

这让多 Agent 协作变得自然，而不是为了多 Agent 而多 Agent。

容易加入人工确认

文章写作特别适合加入 HITL（Human in the Loop）节点。

因为用户很容易在这些阶段做判断：

• 这个标题和方向是不是对的
• 初稿是不是跑偏了
• 最终稿是不是能发

这比很多完全自动化场景更容易形成“人机协作”的产品体验。

为什么进一步收窄到“技术 / AI 自媒体写作”

“文章写作”虽然已经不错了，但还不够聚焦。
如果继续泛化成“什么文章都写”，会出现几个问题：

• 风格差异太大
• 规则不好写
• Agent 目标太散
• 质量标准不一致

所以当前项目又进一步收窄成：

技术 / AI 自媒体写作

这样做有几个非常现实的好处。

1. 读者画像更明确

当前文章的目标读者通常是：

• 技术从业者
• AI 产品观察者
• 个人开发者
• 对新工具有兴趣的内容创作者

一旦读者更清楚，内容的深浅、术语密度、写法风格就更容易控制。

2. 题材结构更稳定

这类文章常见的结构其实很稳定：

• 现象或问题切入
• 产品 / 技术对比
• 原理和使用场景拆解
• 实战建议或结论

这使得 Dispatcher、Writer、Reviewer 都更容易形成稳定规则。

3. 审核标准更容易收敛

技术 / AI 文章的基本质量要求也更清晰：

• 不要明显跑题
• 不要乱造数据
• 不要概念偷换
• 不要空泛喊口号
• 最好有结构、有判断、有案例

这正好适合后续引入“质量闸门”和人工审批。

当前项目中的场景定义是什么

如果用一句话概括当前项目的核心任务，可以写成：

给定一个技术 / AI 主题和写作要求，生成一篇适合自媒体发布的中文 Markdown 文章。

任务通常包括这些字段：

• topic
• angle
• audience
• tone
• length
• must_include
• must_avoid

最终产出通常包括：

• 标题
• 提纲
• 初稿
• 审核意见
• 修订稿

这个任务定义既足够清楚，又有足够空间让多个 Agent 协作。

为什么这个场景还能逼出很多“真实问题”

一个好的 MVP 场景，不只是“能跑”，还应该能逼出工程上的真实问题。
写作场景在这方面特别有价值。

会自然逼出上下文问题

不同 Agent 看到的输入不一样：

• Dispatcher 看题目和角度
• Research 看题目和必须覆盖点
• Writer 看研究摘要和反馈
• Reviewer 看文章正文和当前要求

这让“上下文怎么构建”变成了真实问题，而不是纸上谈兵。

会自然逼出多轮反馈问题

文章很少一次就完美。
用户会 reject，会补充要求，会产生相互冲突的意见。

这也是为什么当前项目后来补了：

• issue_board
• effective_feedback
• pending_conflict
• 冲突确认

这些都来自真实场景的推动。

会自然逼出质量控制问题

写作场景非常容易出现：

• 标题跑偏
• 初稿跑题
• 审核发现“得重写”

所以当前项目后来补了：

• Dispatcher 一致性检查
• Reviewer 结构化质量闸门
• 自动回炉 Writer

这说明场景本身能把系统往更真实的产品形态推。

这一章的结论

第一个 Agent MVP 最好选：

• 输入清楚
• 输出清楚
• 适合拆角色
• 容易展示
• 工程复杂度可控

当前项目最终选择“技术 / AI 自媒体写作”，不是因为它最宏大，而是因为它非常适合把多 Agent 产品的核心问题都跑出来。

下一章看什么

场景定下来以后，下一个问题就变成：

第一版到底该用什么技术栈，才能最快把这个产品跑起来？

下一章我们就结合当前项目，讲清楚为什么最后选的是 FastAPI + Jinja2 + SQLite，以及这套技术栈如何支撑多 Agent MVP。