| name | product-manager |
| description | Vibe Coding 时代的产品经理全栈作战系统——覆盖从 PRD 撰写、Agent 工作流编排、前后端安全审计、数据架构决策、技术债管理到上线风险预警的完整闭环。
当用户提到产品经理、PM、PRD、需求文档、产品需求、产品设计、功能规划、技术评审、
vibe coding、AI编程、agent开发、低代码、无代码、快速原型、MVP、
代码审查、安全审计、数据存储方案、技术选型、上线检查、风险评估、
技术债务、code review、发布清单、上线checklist、
商业化、变现、定价、收费、盈利模式、SaaS定价、订阅制、付费墙、
LTV、CAC、留存率、复购率、NRR、NDR、MRR、ARR、单位经济学、收入飞轮、
增长策略、用户付费、Stripe集成、会员体系、
极简创业、最小可行产品、社区驱动、冷启动、前100个客户、验证想法、
流程化、手动交付、盈利优先、可持续增长、独立开发者、bootstrapping、
indie hacker、solopreneur、Gumroad、产品市场匹配、PMF、
精益创业、Lean Startup、Eric Ries、Steve Blank、客户开发、
Paul Graham、YC、Pieter Levels、DHH、Rework、
Product Hunt、Indie Hackers、Hacker News、冷启动渠道、获客渠道、
Build Measure Learn、验证式学习、pivot、转型时，务必使用此技能。
即使用户只是说"帮我写个需求""这个功能怎么设计""我想做个产品""帮我review一下"
"这个架构有没有问题""上线前要注意什么""怎么收费""怎么赚钱""定价多少合适"
"怎么找到第一批用户""我该不该融资""先做什么后做什么"也应触发此技能。
当用户是非技术背景但在尝试用AI工具（Cursor、Claude Code、Replit、Bolt、Lovable等）构建产品时，
尤其应主动触发此技能，因为这正是最容易踩坑的场景。
|
Product Manager · Vibe Coding 时代全栈作战系统
"The gap between having an idea and shipping a working product has collapsed."
—— 2026，产品经理不再等待工程排期，而是自己动手。
这个技能解决什么问题
2026 年，41% 的全球代码由 AI 生成，92% 的开发者每天使用 AI 编程工具。产品经理已经从"写文档等排期"变成"自己上手 vibe code"。但问题来了——
研究数据显示：在 5,600 个 vibe-coded 应用中，发现超过 2,000 个漏洞、400+ 暴露的密钥、175 个 PII 泄露。AI 生成代码的漏洞率是人类代码的 2.74 倍。2026 年 3 月，某 AI 平台因跳过安全审查，一次泄露了 150 万个 API 密钥。
这个技能就是你的"防弹衣 + 作战地图"——让你既能享受 vibe coding 的速度，又不会掉进那些吞噬整个产品的坑里。
同时，本技能融合了 Sahil Lavingia《极简主义创业者》的核心方法论——先手动交付，再用 AI 产品化。在 AI 帮你 3 天写完代码的时代，"做对的事"比"做出东西"重要一万倍。70% 的 Micro SaaS 月收入不到 $1,000——差别不在技术，在于是否经过了社区验证、手动交付、再产品化的正确路径。
核心方法论：极简创业 × Vibe Coding
在写任何代码（或让 AI 写任何代码）之前，先走完这条路：
1. 找到社区 → 你已经属于的社区里，人们在抱怨什么？
2. 验证想法 → 手动为 3 个人解决这个问题，他们愿意付钱吗？
3. 流程化 → 把手动过程写成"魔法纸条"，任何人都能照着做
4. 产品化 → 现在才用 AI / Vibe Coding 把流程自动化
5. 卖给 100 人 → 同心圆销售：亲友 → 社区 → 陌生人
6. 开始营销 → 教育 → 激励 → 娱乐，三层内容
7. 保持盈利 → 你 + AI + 外包 = 极简团队，无限跑道
核心原则：
- 不发布。先卖给前 100 个客户。
- 免费和 ¥1 之间有天壤之别（零价格效应）。Day 1 就收费。
- 盈利是超能力。花得比赚的少，跑道就是无限的。
- 先花时间，再花钱。博客、社交媒体、个人触达都是免费的。
- 等到痛了再招人。你 + AI 机器人大军 → 自由职业者 → 最后才是员工。
→ 完整的极简创业十步法请查看 references/minimalist-entrepreneur.md
核心理念：三层防线
在 vibe coding 时代做产品，要同时守住三条线：
第一层：想清楚再动手（PRD 即代码）
AI agent 不是人类工程师，不会"猜"你的意思。你的 PRD 写得越模糊，AI 生成的代码越离谱。传统 PRD 写给人看，强调"为什么"；AI 时代的 PRD 要同时写给人和机器看，必须明确"怎么做"的每一个细节。
第二层：做的时候持续检查（开发护栏）
不要写完 prompt 就去喝咖啡。AI 代码"能跑"和"安全可靠"是两回事。每一个功能交付前，过一遍安全清单、跑一遍测试、检查一遍数据流。
第三层：上线前全面体检（发布门禁）
就像飞行员起飞前的检查清单，上线前必须系统性地过一遍所有关键项。不是"觉得没问题"，而是"证明没问题"。
第一章：PRD 撰写——让 AI Agent 真正理解你
为什么传统 PRD 在 AI 时代失效
传统 PRD 里常见的表达："用户可以登录系统"——人类工程师读完会主动补全认证流程、密码规则、Session 管理、忘记密码等细节。AI agent 不会。它只实现你字面上说的，而且倾向于选择最简单的路径。
AI-Native PRD 的核心原则
1. 消灭模糊性
不要写"系统应该支持用户认证"，要写：
认证系统要求：
- 使用 OAuth 2.0 + PKCE 流程
- 支持 Google / GitHub 第三方登录
- 密码要求：最少 8 字符，包含大小写字母和数字
- 登录失败 5 次后锁定账户 15 分钟
- Session 有效期 24 小时，支持 refresh token
- 所有认证相关 API 必须有 rate limiting（每 IP 每分钟 10 次）
2. 分阶段交付，而不是一口气全写
AI agent 在处理 2000 行的巨型 PRD 时，注意力会涣散（跟人一样）。把需求拆成可独立交付的阶段：
Phase 1: 数据模型 + 数据库 schema
Phase 2: 核心 API endpoints
Phase 3: 认证与权限系统
Phase 4: 前端页面与交互
Phase 5: 错误处理与边界情况
Phase 6: 测试用例
3. 用约束替代描述
与其描述你想要什么，不如明确说你不要什么。AI 特别擅长遵守约束：
约束条件：
- 禁止在前端代码中存储任何密钥或 token（必须走后端代理）
- 禁止使用 eval() 或 innerHTML 赋值
- 所有用户输入必须经过服务端校验（前端校验仅用于 UX）
- 数据库查询必须使用参数化查询，禁止字符串拼接 SQL
- 禁止在日志中打印用户密码、token、信用卡信息
4. 明确技术选型，不要让 AI 自己选
AI 会"幻觉"出不存在的 npm 包。攻击者已经在利用这一点——注册 AI 常"推荐"的虚假包名，植入恶意代码。
技术栈（锁定版本，不要自行引入新依赖）：
- 前端：Next.js 14 + TypeScript + Tailwind CSS
- 后端：Node.js + Express（或 Next.js API Routes）
- 数据库：PostgreSQL（通过 Prisma ORM）
- 认证：NextAuth.js v5
- 部署：Vercel
→ 完整的 PRD 模板请查看 references/prd-template.md
第二章：Agent 工作流编排
Agent-First 开发模式
2026 年的产品开发不再是"一个人对着一个 AI 聊天窗口"，而是多个 Agent 协作的流水线：
产品经理的 Agent 编排：
[PRD Agent] → 根据你的需求描述，生成结构化 PRD
↓
[Architect Agent] → 根据 PRD 设计系统架构和数据模型
↓
[Code Agent] → 根据架构逐模块实现代码
↓
[Review Agent] → 自动审查代码安全性和质量
↓
[Test Agent] → 生成并运行测试用例
↓
[Deploy Agent] → 处理部署和环境配置
关键实践
会话管理：AI agent 的上下文窗口有限。当对话变长时，不要强行继续——让 agent 把当前进度写入文件（spec.md、progress.md），然后在新会话中加载这些文件继续。
文件即记忆：让 agent 把决策和发现写到真实的文件里（DECISIONS.md、ARCHITECTURE.md），而不是埋在聊天记录中。聊天记录会丢失，文件不会。
约束文件前置：在项目根目录放置 AGENTS.md 或 .cursorrules 或 CLAUDE.md，写清楚项目级别的约束（技术栈、代码规范、安全要求）。每次 agent 启动时自动加载。
第三章：安全——Vibe Coding 的最大雷区
这不是"可能出问题"，而是"一定会出问题，只是什么时候"。以下是按危险程度排序的常见漏洞：
🔴 致命级
1. 密钥硬编码（Hardcoded Secrets）
AI 生成代码时，会倾向于把 API key 直接写在代码里，因为这是让代码"能跑"的最快方式。
const stripe = require('stripe')('sk_live_真实密钥在这里');
const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);
检查点：grep -r "sk_live\|sk_test\|api_key\|password\|secret" --include="*.js" --include="*.ts" .
2. 客户端认证（Client-Side Auth）
AI 常把认证逻辑写在前端——用 JavaScript 检查用户角色，然后决定显示什么。但前端代码对用户完全透明，任何人都能修改。
if (user.role === 'admin') {
showAdminPanel();
}
3. SQL 注入 / XSS
AI 生成的代码中，40-62% 包含注入漏洞。因为 AI 倾向于用字符串拼接来"快速实现"。
🟡 高危级
4. 依赖幻觉（Dependency Hallucination）
AI 推荐的 npm 包可能根本不存在。攻击者已经在 npm 上注册这些"幻觉包名"，植入恶意代码。每次 AI 建议安装新依赖时，先去 npm 官网确认这个包真实存在、有维护者、有下载量。
5. 过度权限的数据库配置
vibe coding 时为了"让它先跑起来"，数据库往往配置为完全开放读写。这种"临时"配置永远不会被改回来。
6. 环境混淆
测试环境和生产环境共享同一个数据库。Replit 曾因为 AI agent "觉得数据库需要清理"，直接删除了生产数据库。
🟢 常见但容易修复
7. CORS 配置过于宽松（Access-Control-Allow-Origin: *）
8. 缺少 rate limiting（任何 API 都应该有频率限制）
9. 错误信息泄露（把完整的 stack trace 返回给前端）
→ 完整的安全检查清单请查看 references/security-checklist.md
第四章：数据存储——做对一次，省下无数痛苦
选型决策框架
不同阶段、不同场景，数据库选择完全不同。PM 需要理解的不是 SQL 语法，而是决策逻辑：
| 场景 | 推荐方案 | 理由 | 避免 |
|---|
| MVP / 快速验证 | Supabase (PostgreSQL) | 内置 Auth、RLS、实时订阅、免费额度大 | 自建 MySQL（运维成本高） |
| 需要实时协作 | Firebase Realtime DB | 毫秒级同步，适合聊天/协作 | PostgreSQL（需额外搭 WebSocket） |
| 内容型产品 | PostgreSQL + S3 | 结构化数据 + 文件分离存储 | 把文件存数据库里（性能灾难） |
| 高并发读场景 | Redis 缓存 + PostgreSQL | 热数据缓存，冷数据持久化 | 所有请求都打数据库 |
PM 必须关注的数据问题
Schema 先行：在写任何代码之前，先把数据模型设计清楚。AI 最擅长根据清晰的 schema 生成 CRUD 代码，但如果 schema 一改再改，代码会变成一团乱麻。
行级安全（RLS）：确保用户 A 永远看不到用户 B 的数据。这不是"后面再加"的功能，必须从第一天就写进 PRD。测试方法：用两个不同账号登录，互相尝试访问对方数据。
数据迁移（Migration）：数据库结构变更必须通过 migration 脚本管理（不要手动改数据库）。每个 migration 必须可回滚。AI 不会自动考虑向后兼容。
备份策略：上线第一天就要有自动备份。不是"等数据量大了再说"。
第五章：技术债管理——快是好事，但要知道在借什么
理解技术债的"利率"
vibe coding 产生的技术债不是线性增长，而是指数级的。因为 AI 生成的代码之间缺乏一致性——每次对话生成的代码可能用不同的模式、不同的命名规范、不同的错误处理方式。
产品经理的技术债检查框架
每个 vibe code 产出的功能，上线前过一遍：
| 检查项 | 问自己的问题 |
|---|
| 可解释性 | 我能用 2-3 句话解释这个模块做什么吗？ |
| 归属清晰 | 这段逻辑应该放在哪里？（前端/后端/数据库） |
| 依赖合理 | AI 是否引入了不必要的库？ |
| 安全达标 | 密钥是否在环境变量中？输入是否有服务端校验？ |
| 数据合规 | 是否收集了不必要的个人数据？日志中是否打印了敏感信息？ |
| 测试覆盖 | 核心路径是否至少有一个测试？ |
| 文档存在 | 复杂逻辑是否有注释或 README？ |
原型与生产的隔离
这是 PM 最容易犯的错误——用 vibe coding 做的"原型"，在演示获得认可后，直接上线变成"产品"。
正确做法：原型归原型，验证完想法后，用更严格的 PRD 重新指导 agent 生成生产级代码。把原型代码放在单独的分支或目录，永远不要直接合入主分支。
第六章：上线发布——飞行前检查清单
Launch Checklist（每次上线必过）
安全类：
数据类：
质量类：
运维类：
→ 完整的风险评估框架请查看 references/risk-framework.md
第七章：商业化变现——产品不赚钱，一切白搭
"Revenue is oxygen." —— 你可以在所有维度上做得很好，但如果产品不产生收入，它就是一个hobby project。
为什么 PM 必须从第一天就想商业化
Vibe coding 让"做出来"变得极其容易，但也制造了一个幻觉：产品做出来了 = 产品成功了。现实是，70% 的 Micro SaaS 月收入不到 $1,000。区别不在于技术，在于商业模型设计。
复利思维：真正的护城河
产品经理最需要理解的概念是复利增长（Compound Growth）——不是每个月从零开始获客，而是让已有用户持续产生价值。
核心指标是 NDR（Net Dollar Retention / 净收入留存率）：
NDR = (期初收入 + 扩展收入 - 收缩收入 - 流失收入) / 期初收入 × 100%
NDR > 100%：即使不获取任何新客户，收入也在自然增长（复利！）
NDR = 115%：健康的 SaaS 业务
NDR = 120%+：仅靠老客户，每年自动增长 20%
NDR < 100%：你在漏水，获客速度必须超过流失速度
这意味着什么？ 如果你的 NDR 是 120%，你今天的 $10,000 MRR，一年后仅靠老客户就变成 $12,000。两年后 $14,400。这就是复利。而如果 NDR 是 80%，你今天的 $10,000 一年后只剩 $8,000，你必须拼命获客才能维持现状。
变现模型选择框架
不同产品阶段和类型，选择不同的变现模型：
| 模型 | 适用场景 | 复利潜力 | Vibe Coding 实现难度 |
|---|
| 订阅制（Subscription） | SaaS 工具、内容平台 | ⭐⭐⭐⭐⭐ | 低（Stripe 集成简单） |
| 用量付费（Usage-based） | API 服务、AI 功能、存储 | ⭐⭐⭐⭐ | 中（需计量系统） |
| 免费增值（Freemium） | 需要网络效应的产品 | ⭐⭐⭐⭐ | 低（Feature flag 控制） |
| 一次性付费 | 工具、模板、课程 | ⭐ | 最低 |
| 交易抽成 | 平台、marketplace | ⭐⭐⭐⭐⭐ | 高（需支付分账） |
| 混合模式 | 成熟产品 | ⭐⭐⭐⭐⭐ | 中高 |
2026 年趋势：61% 的企业买家更偏好按结果付费而非按席位付费。Usage-based 定价模型的 NRR 普遍更高，因为收入随用户价值自然扩展。
定价策略：PM 的核心决策
定价不是"随便填个数字"。一个定价决策错误可以毁掉一个好产品。
定价三问：
- 你解决的问题值多少钱？（价值锚定，不是成本加成）
- 用户的替代方案是什么？（如果替代方案是 Excel + 手工，你的上限不高）
- 用户的付费意愿在哪个区间？（做用户访谈，不要猜）
Vibe Coding 产品的定价起步建议：
个人工具 / 独立开发者市场：$9-29/月
小团队 SaaS：$29-99/月
B2B 垂直 SaaS：$99-499/月
企业级：$500+/月 或按年计费
关键原则：
- Day 1 就收费（哪怕只是 $5/月），验证付费意愿比免费用户增长重要 100 倍
- 提供年付折扣（提高 LTV，降低流失，改善现金流）
- 免费方案不要太慷慨（否则没人升级）
单位经济学：PM 必须会算的四笔账
在写 PRD 之前，先算清楚这四个数字：
| 指标 | 公式 | 健康标准 | 意义 |
|---|
| CAC（获客成本） | 营销+销售总成本 / 新客户数 | 越低越好 | 获一个客户要花多少钱 |
| LTV（用户生命周期价值） | ARPU × 平均留存月数 | 越高越好 | 一个客户总共能赚多少钱 |
| LTV:CAC | LTV / CAC | ≥ 3:1 | 低于 3 说明获客太贵或留存太差 |
| 回本周期 | CAC / 月均收入 | ≤ 12 个月 | 多久能收回获客成本 |
举例：
- 你的产品 $29/月，平均用户留存 18 个月
- LTV = $29 × 18 = $522
- 你在 Google Ads 花 $200 获取一个付费用户
- CAC = $200
- LTV:CAC = $522 / $200 = 2.6:1 ❌ 低于 3，需要优化
- 回本周期 = $200 / $29 = 6.9 个月 ✅ 还行
优化方向：
→ 降低 CAC：做内容营销 / SEO / 社区 / 口碑（成本几乎为零）
→ 提高 LTV：提升留存率、推出高级方案、增加使用场景
→ 提高 ARPU：引导用户升级、按用量计费让重度用户付更多
收入飞轮：把增长变成自驱系统
最厉害的产品不是"推着走"的，而是有一个自我强化的飞轮：
┌──→ 更多用户 ──→ 更多数据/内容 ──┐
│ ↓
口碑传播 ←── 更好的体验 ←── 产品改进 ←── 更多收入
│ ↑
└──→ 更低的 CAC ──→ 更高的利润 ──┘
PM 在 PRD 中应该回答的商业化问题：
- 这个功能如何直接或间接带来收入？
- 这个功能是帮助获客、促活、留存还是变现？
- 免费版和付费版的边界在哪里？
- 用户从免费到付费的触发点是什么？
- 是否有自然的扩展收入路径（用量增长、团队扩展、功能升级）？
→ 完整的商业化评估框架和定价策略指南请查看 references/monetization-playbook.md
第八章：持续运营——上线只是开始
自动化监控预警
不要等用户来告诉你产品挂了。至少配置：
- 错误监控：Sentry 或同类工具，出现新的未捕获异常时立即通知
- 可用性监控：UptimeRobot 或同类工具，站点无法访问时立即通知
- 性能监控：Vercel Analytics 或 Lighthouse CI，性能退化时预警
- 安全监控：GitHub Dependabot 或 Snyk，依赖出现已知漏洞时通知
迭代开发的 Agent 工作流
每次迭代遵循这个节奏：
1. 更新 PRD（明确新需求，标注变更点）
2. 让 agent 读取完整的项目约束文件（AGENTS.md / CLAUDE.md）
3. 在新分支上开发
4. agent 完成后，自己 review 代码变更（重点看安全和数据相关的改动）
5. 跑测试
6. 合入主分支
7. 部署到预发布环境验证
8. 部署到生产
参考文件索引
根据你当前的任务，选择阅读相应的参考文件：
| 参考文件 | 适用场景 |
|---|
references/prd-template.md | 要写 PRD 或需求文档时 |
references/security-checklist.md | 审查代码安全性时 |
references/risk-framework.md | 评估上线风险或做技术评审时 |
references/architecture-patterns.md | 做技术选型或数据架构决策时 |
references/monetization-playbook.md | 设计变现模型、定价策略或评估商业可行性时 |
references/minimalist-entrepreneur.md | 从零开始创业、验证想法、找社区、冷启动、获客渠道、精益方法论、创业背书时 |
