夜雨聆风
我做产品很多年了。
我知道“慢”是什么样子。
任何 SaaS 的第一周，往往都是最难熬的一段。
你需要在脑子里不停切换角色：
→ 创始人
→ 研究员
→ 产品经理
→ 设计师
→ 工程师
→ QA 测试
→ 市场推广
同一个脑子，七份工作，进度几乎不动。
上个月我试了另一种做法。
我不再用一个 AI 模型处理所有事情。
我用 Kimi Agent Swarm 搭了一个由 7 个专门 Agent 组成的小团队。
一个下午，一个 SaaS 想法，七个 Agent，一份完整的 MVP 蓝图。
下面是完整流程。
产品：面向本地商家的 AI 网站审计 SaaS 。
它解决的问题：
有 500 万家本地商家的网站，看起来还停留在 2011 年。
没有预约按钮，没有移动端布局，没有信任背书，没有清晰 CTA，没有评论展示区。
一个水管工可能真的很会修水管，但网站看起来像已经停更，也会因此丢掉客户。
这个 SaaS 的使用方式：输入任意本地商家的网址，就能得到一份审计报告、一个评分，以及一封可以直接发给商家的冷邮件。
目标用户：自由职业者、网页设计师、本地 SEO 机构，以及所有向本地商家销售网站和服务的人。
它填补的缺口：审计报告本身就是销售资产。
普通冷邮件通常没人理。
但如果邮件里写的是：
“你的移动端预约按钮坏了，首页没有信任背书，街对面的竞争对手多了 300 条评论，而且预约流程更快。”
这种邮件更容易收到回复。
这是输出出来的 SaaS：
为什么很多人用 AI 做产品的方式不对
很多创始人把 AI 当成一个更好用的聊天机器人。
他们给一个模型塞一个巨大的提示词：
“调研市场，设计 UI，开发后端，写落地页，规划发布。”
输出之所以浅，是因为这种方式本来就浅。
让一个模型在七种不同思维模式之间切换，结果通常是每一项都只做到平均水平。
研究员和设计师的思考方式不同。后端工程师和市场人员的思考方式不同。 QA 测试和产品经理的思考方式也不同。
Agent Swarm 能跑起来，靠的是这个洞察：
→ 专门化比泛化更容易产出好结果。
这并不是新想法。
公司雇团队，而不是雇一个什么都做的人，也是同一个原因。
Kimi Agent Swarm 把这套逻辑放到了 AI 上。
你不再问一个模型“帮我做一个 SaaS”，而是围绕任务搭一个小型 AI 公司。
每个 Agent 负责一个角色。每个 Agent 产出一个结果。创始人管理系统，而不是亲自处理所有任务。
7 个 Agent 系统
这是我在 Kimi Agent Swarm 里组的团队：
Agent 1 → 研究 Agent：验证市场、目标客户、竞争对手和使用场景。
Agent 2 → 产品经理 Agent：定义 MVP 范围、核心功能、用户旅程、定价模型。
Agent 3 → UX Agent：创建页面结构、用户流程、仪表盘布局、报告布局。
Agent 4 → 前端工程师 Agent：构建 UI 方案和组件结构。
Agent 5 → 后端工程师 Agent：设计审计逻辑、评分系统、 API 结构和数据模型。
Agent 6 → QA Agent：检查 bug 、缺失状态、边界情况和让人困惑的 UX 。
Agent 7 → 发布 Agent：写落地页文案、 X 发布帖、冷邮件和产品定位。
每个 Agent 先独立工作，然后把输出合并成一份构建计划。
这就是它和一段很长的 ChatGPT 对话不同的地方。
没有上下文切换。没有“忘了我前面说过什么”。每个 Agent 都待在自己的职责范围里。
主提示词
这是我给 Kimi 用来启动会话的提示词。可以借鉴，再按你的需要修改：
Build an AI Website Audit SaaS for local service businesses.
Target users:
- freelancers
- agency owners
- local SEO consultants
- web designers selling to plumbers, HVAC, roofers, electricians, dentists
Core workflow:
User enters a local business URL →
App audits the website →
Generates a score, issues list, improvement checklist, client report, and cold email
Split into 7 specialized agents:
Research Agent: validate the market, customer, competitors
Product Agent: define MVP scope, features, pricing
UX Agent: user flow, dashboard, report layout
Frontend Agent: UI structure and components
Backend Agent: scoring logic, audit system, API design
QA Agent: edge cases, missing states, failure modes
Launch Agent: landing page, X post, cold email, positioning
Each agent works independently first.
Then merge all outputs into one final MVP plan.
大多数人会写一个版本，然后等一个很大的答案。
Swarm 的重点在于：每个 Agent 都从自己的角度产出一个真实工件。
研究 Agent 不考虑按钮颜色。 UX Agent 不发明定价。 QA Agent 负责攻击，而不是防守。发布 Agent 不碰后端。
分离本身就是系统。
下面是实际运行中的 Agent Swarm：
每个 Agent 产出了什么
Agent 1 — 研究
找到了 4 类真实客户：
→ 向本地商家销售网站改版的网页设计师
→ 销售审计顾问服务的 SEO 机构
→ 做冷启动外联的自由职业者
→ 搭建获客服务的独立创始人
最好的客户洞察：
审计不是产品。审计是销售武器。
向本地商家销售服务的人，需要一种更快的方法，生成个性化、具体的审计报告。
普通冷邮件通常拿不到回复。能指出具体问题的个性化审计，才会吸引注意。
这个定位改变了整个产品方向。
Agent 2 — 产品经理
把范围砍到很小。
第一个版本只需要 5 个页面：
→ 首页
→ 审计输入页
→ 加载 / 进度页
→ 审计结果页
→ 报告导出页
不要团队账号，不要账单系统，不要 CRM，不要浏览器扩展，不要市场，不要 API 。
只做一个流程：
输入网址 → 得到审计 → 发送报告。
MVP 核心功能：
→ 网站 URL 输入
→ 商家类别选择器
→ 0–100 审计评分
→ 转化检查清单
→ 移动端适配检查清单
→ 信任背书检查清单
→ CTA 检查清单
→ 报告摘要
→ 冷邮件生成器
→ 给自由职业者的建议服务报价
这对第一个版本已经够了。
SaaS MVP 不需要完整。
它只需要证明一个流程可以跑通。
Agent 3 — UX
设计了 5 步用户旅程：
Step 1：粘贴 URL + 选择商家类型
Step 2：应用运行审计（进度条）
Step 3：查看总体评分
Step 4：查看哪里坏了，以及为什么坏
Step 5：得到报告 + 冷邮件
Kimi 设计的报告布局：
━━━
网站评分：62/100
正在让你流失客户的问题：
→ 没有明显的预约按钮
→ 移动端布局薄弱
→ 没有 Google 评论区
→ 没有紧急服务 CTA
→ 首屏建立信任的速度太慢
快速改进：
→ 增加一键拨号按钮
→ 把评论移到页面顶部
→ 增加服务区域板块
→ 增加改造前后照片
→ 增加预约表单
业务影响：你的网站正在流失那些现在就准备打电话的移动端访客。
━━━
这个布局很重要。
不技术化，不堆行话。
清楚到一个水管工 30 秒内就能看懂。
这就是自由职业者发出去的东西，也正是能换来会议的东西。
Agent 4 — 前端
前端 Agent 搭出了 UI 结构。
Hero 区文案：“60 秒内审计任意本地商家网站。”
输入卡片：
→ 网站 URL
→ 商家类别（下拉：水管工、 HVAC 、牙医、电工、屋顶维修……）
→ 城市
→ 主要服务
结果仪表盘：
→ 总评分（大数字，按颜色区分）
→ 分类评分（5 条进度条）
→ 前 5 个问题（红色高亮）
→ 快速改进（绿色高亮）
→ 生成报告（预览 + 下载）
→ 冷邮件（发送前可编辑）
应用不需要花哨设计。
它需要在 10 秒内让一个价值变得清楚：
粘贴 URL，得到审计，把它发给客户，拿下订单。
Agent 5 — 后端
评分系统分成 5 个类别：
设计清晰度 → 20 分
移动端适配 → 20 分
转化准备度 → 25 分
信任背书 → 20 分
本地 SEO 基础 → 15 分
总分：100 分
转化准备度的示例检查项：
→ 首屏是否有清晰 CTA？（+5）
→ 电话号码是否可见？（+5）
→ 是否有预约表单？（+5）
→ 服务是否列得清楚？（+5）
→ 是否给了现在行动的理由？（+5）
信任背书的示例检查项：
→ 评论是否可见？（+4）
→ 是否展示资质认证？（+4）
→ 是否使用真实照片？（+4）
→ 是否提到经营年限？（+4）
→ 是否包含保障承诺？（+4）
这一点重要，因为评分必须可以解释。
黑盒式的“AI 评分”看起来很假。
带有具体、清晰理由的评分才有用。
有用的东西，才会被拿去发给客户。
Agent 6 — QA
这是最有价值的 Agent 。
QA Agent 有一件事做得很好：攻击。
Kimi 的 QA Agent 立刻发现了这些问题：
→ URL 坏了怎么办？
→ 网站禁止爬取怎么办？
→ 网站几乎没有文字怎么办？
→ 商家没有任何评论怎么办？
→ 两个审计类别互相矛盾怎么办？
→ 生成的邮件听起来太激进怎么办？
这就是 Agent Swarm 胜过一个长提示词的地方。
单个模型在构建应用时，会对自己的输出产生依恋。
一个独立 QA Agent 没有这种依恋。
它只负责找漏洞。
它补上的修复项：
→ 被屏蔽网站的 fallback 状态
→ 供人工覆盖的手动备注字段
→ 每条发现的置信度评分
→ “无法验证”标签
→ 更柔和的邮件语气切换
→ 外联发送前的人工审核步骤
最后一点很重要。
你不希望 500 封糟糕的冷邮件自动发出去。
你想要的是 500 份强草稿，然后由人来批准。
创始人仍然是编辑。 Swarm 负责重活。
Agent 7 — 发布
发布 Agent 产出了一句产品定位：
“把糟糕的本地商家网站，变成客户机会。”
这比“AI 网站审计工具”强得多。
没人醒来后会想要一个审计工具。
他们想要的是客户。
落地页结构：
标题：把糟糕的本地商家网站，变成客户机会。
副标题：输入任意 URL，得到即时审计，发送个性化报告，拿下订单。
三条价值点：
→ 找到每天都在流失客户的网站
→ 60 秒生成审计
→ 发送更容易收到回复的报告
发布 Agent 写的 X 发布帖：
我做了一个 SaaS，可以审计本地商家网站，并把它们变成客户机会。
粘贴一个 URL，得到 0–100 分评分，看到具体哪些问题正在让客户流失，生成一份客户可读的报告，再发送一封个性化冷邮件。
它面向自由职业者、网页设计师和本地 SEO 机构。
糟糕的网站到处都是。现在，每一个都可以成为线索。
简单，清楚，有用。
最终输出
一个下午内，Kimi Agent Swarm 产出了：
→ 经过验证的市场和目标客户
→ 很紧的 MVP 范围（5 个页面，没有功能蔓延）
→ 完整用户旅程
→ 带具体检查项的 100 分评分系统
→ UI 结构和组件列表
→ 客户友好的报告布局
→ 带边界情况的 QA 清单
→ 落地页文案
→ 发布帖
→ 冷邮件模板
这还不是一家完整公司。
但它已经超过了大多数创始人独自想一周后能拿到的东西。
仍然需要你自己做的事
Kimi 没有在一个下午内搭出一家十亿美元 SaaS 。
它搭出的是一份强 MVP 蓝图。
两者不一样。
真实 SaaS 仍然需要：
→ 生产代码
→ 真实用户
→ 支付和托管
→ 错误处理
→ 客服支持
→ 分发
→ 定价测试
→ 发布前的人工 QA
有些网站会禁止爬取。有些审计需要人工验证。有些邮件在发送前应该再看一遍。
这不是“按下按钮，然后变富”。
更有用的经验是：
Kimi 替代了产品思考里最混乱的前 70% 。
创始人仍然负责品味、判断、发布和分发。
变化发生在起点。
过去常常要对着空白页看三天。现在起步时就已经有了调研输出、产品规格、评分系统、 UI 流程和发布计划。
认知负担下降，速度上升，早期决策更快完成。
工作流：保存这个顺序
下次有 SaaS 想法时，可以直接用这个顺序：
Step 1 → 写清楚一个想法（问题 + 用户 + 核心流程）
Step 2 → 打开 Kimi Agent Swarm
Step 3 → 指定 7 个 Agent，并给出明确角色
Step 4 → 让每个 Agent 独立产出自己的工件
Step 5 → 让 QA Agent 攻击完整计划
Step 6 → 把输出合并成一份 MVP 蓝图
Step 7 → 只构建能证明流程成立的最小版本
Step 8 → 添加任何东西之前，先用 5 个真实用户测试
很多创始人容易犯的错：
要求 AI 构建所有东西。
更好的做法：
让 Agent 消除混乱。
调研变清楚，范围变清楚，页面变清楚，风险变清楚，发布角度也变清楚。
这才是真正节省时间的部分。
变化
下一代创始人不会只用 AI 写文案。
他们会管理 Swarm 。
一个 Agent 做研究，一个 Agent 做设计，一个 Agent 写代码，一个 Agent 做测试，一个 Agent 负责发布。
创始人不再是执行每一项任务的人。
创始人变成了指挥机器的人。
这就是 Kimi Agent Swarm 给我的东西。
不是捷径。
是一个团队。
之前：一个创始人在七种角色之间切换，写下一行代码之前就先耗掉一周。
之后：七个 Agent 并行运行，在一天结束前返回完整 MVP 计划。
过去这需要一周。
现在从一个提示词开始。
试试 Kimi Agent Swarm: kimi.com/agent-swarm
