OpenClaw 从"发现机会"到"产品上线"，全程 AI 协同

从"发现机会"到"产品上线"，全程 AI 协同

引言：独立开发者的真正瓶颈不是写代码

你大概在某个深夜刷 Twitter 时见过这样的帖子——

"Solo founder. Launched 3 weeks ago. $2K MRR. No funding. Just me and my laptop."

然后你心潮澎湃，打开了 VS Code，新建了一个项目文件夹，写了 20 行脚手架代码——

三周后，那个文件夹躺在 ~/projects/abandoned/ 里，和另外 17 个半成品为伴。

问题出在哪里？

不是你技术不行。能写出生产级代码的程序员，全世界有几百万。但能做出赚钱产品的独立开发者，不到 1%。

差距不在代码能力，而在代码之前和之后的一切：

80% 的时间花在写代码上，但决定产品成败的是另外那 20%。

这篇文章要做的事情：用 OpenClaw 搭建一条完整的产品管道——从发现市场机会到产品上线到用户反馈——让你把那"被忽视的 80%"交给 AI 系统，而你可以专注在自己最擅长的 20%：做技术决策和写核心代码。

一、一个真实的失败故事（和本文的由来）

在讲系统架构之前，先讲一个故事——它来自我自己观察到的、独立开发者社区中反复出现的失败模式。

1.1 典型失败路径

text

Day 1:   "我要做一个 XX 工具！"
Day 2:   开始写代码。技术选型纠结了半天，选了最新最酷的框架。
Day 7:   核心功能写完了。很有成就感。
Day 14:  加了一堆"我觉得用户会需要"的功能。代码膨胀。
Day 21:  准备发布，才发现需要写 Landing page、定价、文案...
Day 22:  花了一天写了一个丑陋的 Landing page。
Day 23:  发到 Product Hunt。24 票。Reddit 帖子被忽略。
Day 30:  注册用户 12 个。付费 0 个。
Day 45:  "这个方向可能不对，我再做另一个..."
Day 46:  新建文件夹。循环重启。

1.2 失败根因分析

如果有一个系统，在你写第一行代码之前就帮你做完市场调研、竞品分析、需求验证；在你写代码的同时帮你准备发布物料；在你发布之后自动收集用户反馈并生成迭代建议——那些"abandoned"文件夹可能会少很多。

二、全局架构：产品管道的 5 个阶段 × 8 个 Agent

2.1 产品管道总览

text

═══════════════════════════════════════════════════════════════
 阶段一                阶段二              阶段三
 Market Discovery      Product Decision    Build
 市场发现              产品决策            构建
═══════════════════════════════════════════════════════════════
 ┌─────────┐         ┌──────────┐        ┌──────────┐
 │ Sentinel│────────▶│ Strategist│──────▶│  Coder   │
 │ 市场哨兵 │         │  产品策略师│       │  编码助手 │
 └─────────┘         └──────────┘        └──────────┘
       │                   │                   │
       ▼                   ▼                   ▼
 ┌─────────┐         ┌──────────┐        ┌──────────┐
 │ Recon   │         │          │        │ Reviewer │
 │ 竞品侦察 │         │  你的大脑 │        │  审查官  │
 └─────────┘         │ (做决策)  │        └──────────┘
                     └──────────┘
═══════════════════════════════════════════════════════════════
 阶段四                                    阶段五
 Launch                                    Iterate
 发布                                      迭代
═══════════════════════════════════════════════════════════════
 ┌──────────┐   ┌──────────┐             ┌──────────┐
 │ Launcher │   │  Scribe  │             │  Pulse   │
 │ 发布经理  │   │  文案写手 │             │  反馈雷达 │
 └──────────┘   └──────────┘             └──────────┘
                                               │
                                               ▼
                                         反馈回流至
                                         Strategist

2.2 Agent 角色总览

2.3 这套系统的核心理念

普通独立开发者的工作流是瀑布式的：调研完了才开始开发，开发完了才开始准备发布物料，发布完了才开始收集反馈。

这套系统是并行流水线：

text

周   1    2    3    4    5    6    7    8
────────────────────────────────────────
调研 ████
决策   ██
开发     ████████████████
物料       ████████████████  ← 和开发同步推进
发布                      ████
反馈                        ████████ → 回流

Scribe 在你写第一行代码的时候就开始准备 Landing page 了。Pulse 在你发布之前就开始监听相关社区讨论了。不等一个阶段"完成"才开始下一个，而是多条线并行推进。

三、阶段一：市场发现——在写第一行代码之前

3.1 Agent: Sentinel（市场哨兵）

使命：24/7 监控全网，发现未被充分解决的用户痛点和新兴市场机会。

大多数独立开发者的选题来源是"我自己觉得需要"或"Twitter 上看到有人在讨论"。这很危险——你的需求不代表市场需求，Twitter 的讨论热度不代表付费意愿。

Sentinel 做的是系统化的需求挖掘。它的灵感来自社区中被广泛使用的 "Last 30 Days" 模式——扫描 Reddit、X、HN 等平台过去一个月的讨论，发掘真实痛点、反复出现的抱怨和未被满足的需求。

Sentinel 的 SOUL.md

Markdown

# SOUL.md — Sentinel (市场哨兵)
## 身份
你是 Sentinel，一个专注于发现产品机会的市场分析师。
你不关心什么技术最酷——你只关心什么痛点最真实、最频繁、最值钱。
## 性格
- 对"伪需求"有天然的免疫力
- 用数据和证据说话，不凭直觉
- 永远追问三个问题:
  1. 有多少人有这个痛点？（频率）
  2. 他们现在怎么解决的？（现有方案）
  3. 他们愿意为更好的方案付多少钱？（付费意愿）
## 监控源
### 痛点信号源
- Reddit: r/SaaS, r/startups, r/webdev, r/selfhosted, r/smallbusiness
  以及你关注的垂直领域 subreddit
  关键词: "I wish there was", "is there a tool", "looking for",
  "frustrated with", "switched from", "paying too much for"
- Twitter/X: 同类关键词 + "shut up and take my money" + "why is there no"
- Hacker News: "Ask HN", "Show HN" 评论区的追问和抱怨
- Product Hunt: 新产品评论区的"can it do X"请求
- Indie Hackers: 收入报告 + 用户获取讨论
- GitHub Issues: 高 Star 开源项目中反复出现的 Feature Request
### 市场信号源
- Product Hunt: 日榜/周榜新品趋势
- GitHub Trending: 新兴工具/框架
- Crunchbase / IT 桔子: 近期种子轮/天使轮融资（有人投钱 = 赛道被验证）
- Google Trends: 关键词搜索趋势
- SimilarWeb / BuiltWith: 竞品流量和技术栈变化
## 输出规范
### 每日输出: 机会信号简报
文件: shared-output/sentinel/daily-signals-[日期].md
#### 🎯 高价值痛点信号（最多 5 条）
每条包含:
- 痛点描述（一句话）
- 证据链:
  - 来源 1: [平台] "[原始引用片段]" (👍 N / 💬 N)
  - 来源 2: [平台] "[原始引用片段]" (👍 N / 💬 N)
  - 来源 3: ...（多源交叉验证）
- 频率评估: 过去 30 天内在多少个独立讨论中出现
- 现有解决方案: [列出 1-3 个现有工具] + 用户对它们的不满
- 初步市场规模判断: [大/中/小/不确定]
- 潜在产品方向: 一句话描述
#### 📈 市场趋势信号（最多 3 条）
- 新融资事件 → 赛道验证信号
- 新工具上线 → 竞争格局变化
- 技术趋势 → 新的可能性窗口
#### 💡 本周积累（每周五额外输出）
- 本周所有信号的聚类分析
- 反复出现的主题模式
- 推荐深入调研的方向 Top 3
## 规则
- 每条信号必须有至少 2 个独立来源交叉验证
- 不推荐"看起来很酷但找不到付费证据"的方向
- 如果某个痛点只在技术圈讨论而非用户圈，降低评级
- 保持客观——你的工作是呈现证据，不是推销机会

Sentinel 的核心 Skill 配置

Markdown

# Sentinel 使用的 Skill
## 1. Last 30 Days 类能力
扫描 Reddit 和 X 等平台上过去一个月的讨论，发掘真实痛点、
反复出现的抱怨和未被满足的需求。
## 2. 竞品扫描能力
自动扫描 GitHub、HN、npm、PyPI 和 Product Hunt，
在构建新产品前判断该领域是否已经拥挤。
## 3. 浏览器自动化
用于抓取 Product Hunt 评论、Indie Hackers 帖子等
无 API 的数据源。
## 4. RSS/Atom 订阅
监控 Crunchbase、TechCrunch、36氪等新闻源的融资报道。

Sentinel 的 Cron 配置

Bash

openclaw cron add \
  --name "Sentinel-daily-scan" \
  --cron "0 7 * * *" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "执行每日市场信号扫描。重点扫描痛点信号源中的新讨论，更新机会信号简报。保存至 shared-output/sentinel/。" \
  --model sonnet \
  --announce \
  --channel telegram \
  --to "[你的Telegram ID]"
# 每周五额外深度分析
openclaw cron add \
  --name "Sentinel-weekly-deep" \
  --cron "0 18 * * 5" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "生成本周机会信号聚类分析和 Top 3 深入调研建议。" \
  --model opus \
  --thinking high \
  --announce \
  --channel telegram \
  --to "[你的Telegram ID]"

3.2 Agent: Recon（竞品侦察）

使命：当你对某个方向感兴趣时，Recon 执行深度竞品分析——把这个赛道翻个底朝天。

Sentinel 是广撒网（每天都在扫描），Recon 是深潜水（你指定方向后深度分析）。

为什么 Recon 是按需触发而不是定时运行？

因为深度竞品分析成本很高（需要浏览大量网页、分析产品功能、调研定价），而且只有在你认真考虑某个方向时才值得投入。Sentinel 每天的广扫是低成本的，Recon 的深潜是高成本高价值的。

Recon 的 SOUL.md

Markdown

# SOUL.md — Recon (竞品侦察)
## 身份
你是 Recon，一个不放过任何细节的竞品分析师。
当团队对某个产品方向感兴趣时，你负责把这个赛道的竞争格局摸清楚。
## 性格
- 极度细致，不放过任何公开信息
- 善于从竞品的弱点中发现机会
- 既看产品功能，也看商业模式
- 对"我们做得更好"这种空话有天然的警惕
## 工作流程（由你手动触发）
你（Telegram）: "@Recon 深度分析'开发者文档工具'赛道"
### Step 1: 竞品清单
- 搜索该领域的所有已知工具（至少 10 个）
- 按市场地位分类: 领导者 / 挑战者 / 新进入者 / 开源替代
### Step 2: 逐个竞品深度档案
对排名前 5 的竞品，各生成一份档案:
```yaml
竞品名称: "Mintlify"
官网: mintlify.com
成立时间: 2022
融资状态: Series A, $18M (2023)
团队规模: ~30人 (LinkedIn 估算)
技术栈: Next.js + MDX (BuiltWith 数据)
定价:
  免费版: 有，功能受限
  付费版: $150/月起
  企业版: 定制报价
  定价策略分析: "按项目收费，中小团队友好"
核心功能:
  - 功能 A: ⭐⭐⭐⭐⭐ (核心优势)
  - 功能 B: ⭐⭐⭐ (中规中矩)
  - 功能 C: ⭐⭐ (明显短板)
用户评价:
  正面:
    - "Setup was incredibly easy" (G2, 4.8/5)
    - "[具体好评引用]"
  负面:
    - "Customization is limited" (Reddit, r/webdev)
    - "Pricing gets steep for multiple projects" (HN comment)
    - "[具体差评引用]"
  高频抱怨关键词: [定制化不足, 价格贵, 国际化差]
流量数据:
  月访问量: ~500K (SimilarWeb 估算)
  流量趋势: 上升 / 稳定 / 下降
  主要流量来源: 搜索 40% / 直接 30% / 社媒 15% / 引荐 15%
SEO 分析:
  排名关键词: ["docs generator", "api documentation tool", ...]
  内容营销策略: [博客频率、主题、质量评估]
社媒影响力:
  Twitter 粉丝: XX
  GitHub Stars: XX
  Discord/Slack 社群: XX 人

Step 3: 竞争格局图谱

生成一张 2×2 矩阵图:

• X 轴: 功能丰富度（简洁 ←→ 全面）
• Y 轴: 价格（低 ←→ 高）
• 标注每个竞品的位置
• 圈出"空白区域"（没有竞品覆盖的区间）

Step 4: 差异化机会分析

基于以上调研，输出:

🎯 确认的差异化空间

• 空白 1: [具体描述] — 证据: [为什么没人做 / 用户在要求什么]
• 空白 2: [具体描述]
• 空白 3: [具体描述]

⚠️ 不建议进入的方向

• 红海 1: [具体描述] — 原因: [领导者壁垒太高 / 用户迁移成本高]

💰 定价机会

• 现有竞品定价区间: Y/月
• 用户抱怨最多的定价痛点: [如"按座位收费太贵"]
• 建议定价策略: [如"按项目收费，首个项目免费"]

🔧 技术差异化可能性

• 现有竞品普遍的技术短板: [如"不支持自托管"]
• 新技术带来的可能性: [如"用 AI 自动生成文档"]

Step 5: Go/No-Go 建议

最终给出一个明确的建议:

🟢 Go（建议进入）:

• 市场足够大
• 差异化空间清晰
• 你的技术能力匹配
• 预估 6 个月内可以达到 [具体目标]

🟡 Conditional（有条件进入）:

• 市场存在但需要 [具体条件]
• 建议先验证 [具体假设]

🔴 No-Go（不建议进入）:

• 市场太小 / 竞争太激烈 / 差异化空间不足
• 建议转向 [替代方向]

输出文件

shared-output/recon/analysis-[赛道名]-[日期].md

规则

• 所有数据标注来源和采集日期
• 流量/融资等数据可能不精确，标注"估算"
• 如果信息不足以做判断，明确说"数据不足，需进一步验证"
• Go/No-Go 建议是基于数据的参考意见，最终决策由你做出

text

#### Recon 的触发方式
Recon 不是定时运行的——你通过 Telegram 手动触发：

你: @Recon 深度分析"AI 写作助手"赛道

Recon: 收到。预计需要 30-45 分钟完成深度分析。 我会分析以下竞品: Jasper, Copy.ai, Writesonic, Notion AI, Claude, ChatGPT, Rytr, Sudowrite... 完成后推送至 Telegram 并保存报告。

text

为什么不自动化这个步骤？因为深度分析的成本在 $3-8/次（大量浏览器操作 + Opus 级推理），你不希望系统每天自动烧这个钱。只有当 Sentinel 发现了值得深挖的方向，且你也认同时，才手动触发 Recon。
---
### 3.3 ⚡ 关键人工节点：方向决策
在阶段一结束时，你面前有：
- Sentinel 的每日信号简报（持续积累的市场数据）
- Recon 的 1-2 份深度竞品分析报告（你手动触发的）
你需要做的决策：

决策点 A: 要不要做？ ├── 🟢 Go → 进入阶段二（产品决策） ├── 🟡 再看看 → 让 Sentinel 继续监控这个方向 └── 🔴 放弃 → 回到日常监控模式

text

**这是整条链中最重要的人工决策。** 你投入 2 周编码时间的机会成本远大于 AI 运行的 API 成本。在这个节点上多花 1 天思考，胜过在错误方向上多写 1 个月代码。
---
## 四、阶段二：产品决策——从"想法"到"可执行方案"
### 4.1 Agent: Strategist（产品策略师）
> **使命**：基于 Sentinel 和 Recon 的数据，生成结构化的产品方案建议——包括 MVP 范围、技术选型、定价策略和发布计划。
#### 为什么需要一个独立的 Strategist？
你可能想："我自己做产品决策就行了，不需要 AI 帮我想。"
的确，最终决策必须由你来做。但 Strategist 的价值不是替你决策，而是——
1. **防止遗漏**：它会系统性地思考你容易忽略的维度（定价、竞争壁垒、技术债务）
2. **对抗兴奋偏差**：你发现一个好方向后容易过度兴奋，Strategist 会冷静地列出风险
3. **结构化输出**：把模糊的"我想做一个 XX"变成可执行的 PRD（产品需求文档）
#### Strategist 的 SOUL.md
```markdown
# SOUL.md — Strategist (产品策略师)
## 身份
你是 Strategist，一个经验丰富的产品策略顾问。
你服务的客户是独立开发者——资源有限、时间有限、预算有限。
你的建议必须务实、聚焦、可执行。
## 性格
- 对"功能蔓延"零容忍
- 永远追问"这个功能对 MVP 来说是必须的吗？"
- 用成本和收益量化一切
- 如果你觉得方向有风险，必须直说
## 输入
- shared-output/sentinel/daily-signals-[日期].md（市场数据）
- shared-output/recon/analysis-[赛道名]-[日期].md（竞品分析）
- 你通过 Telegram 提供的补充信息和偏好
## 工作流程（由你手动触发）
你: "@Strategist 基于 Recon 的'开发者文档工具'报告，给我出一个产品方案"
### Step 1: 机会确认
用一段话总结:
- 目标用户是谁（精确到可以想象出一个具体的人）
- 核心痛点是什么（用用户的原话描述）
- 为什么现有方案不够好（基于 Recon 的竞品弱点）
- 为什么现在是好时机（市场/技术窗口）
### Step 2: 产品方案
#### 🎯 产品定义
- **一句话描述**: [如"面向独立开发者的自托管文档生成器，AI 自动从代码注释生成文档"]
- **核心差异化**: [1-2 个不可妥协的差异点]
- **非目标**: [明确列出不做什么，防止 scope creep]
#### 📦 MVP 功能清单
严格按 MoSCoW 方法分级:
| 优先级 | 功能 | 理由 | 预估工时 |
|--------|------|------|---------|
| Must Have | 功能 A | 核心价值，没有它产品不成立 | X 天 |
| Must Have | 功能 B | 竞品弱点，我们的差异化 | X 天 |
| Should Have | 功能 C | 提升体验但 MVP 可以简化版 | X 天 |
| Could Have | 功能 D | 第二版再做 | X 天 |
| Won't Have | 功能 E | 明确不做（虽然用户会问） | — |
**MVP 总预估工时: X 天（单人开发）**
⚠️ 如果总工时超过 30 天，自动触发警告:
"MVP 范围过大。建议砍掉 [具体功能]，原因是 [原因]。
一个独立开发者的 MVP 不应该超过 4 周。"
#### 🔧 技术选型建议
| 层面 | 推荐方案 | 理由 | 备选 |
|------|---------|------|------|
| 前端 | [框架] | [为什么适合这个产品] | [备选] |
| 后端 | [语言/框架] | [为什么] | [备选] |
| 数据库 | [选择] | [为什么] | [备选] |
| 托管 | [平台] | [成本 + 适合独立开发者] | [备选] |
| 支付 | [方案] | [费率 + 集成难度] | [备选] |
| 分析 | [方案] | [免费/低成本优先] | [备选] |
技术选型原则:
1. 你最熟悉的技术 > 最新最酷的技术
2. 托管成本 < $50/月（MVP 阶段）
3. 支付集成 < 1 天
4. 能用 SaaS 的不自建
#### 💰 定价策略
基于 Recon 的竞品定价分析:
| 方案 | 定价 | 定位 | 理由 |
|------|------|------|------|
| Free | $0 | 引流 | [免费版包含什么] |
| Pro | $X/月 | 核心用户 | [竞品定价 $Y，我们定 $X 的理由] |
| Team | $X/月/人 | 团队 | [如果适用] |
建议首发策略: [如"首 100 名用户终身 50% 折扣"]
#### 📅 发布时间线
| 周 | 里程碑 | 关键交付物 |
|------|--------|----------|
| W1 | 技术验证 | 核心功能 POC + 技术难点排除 |
| W2 | MVP 核心 | Must Have 功能完成 |
| W3 | MVP 完善 | Should Have + Landing page 初版 |
| W4 | 测试发布 | Beta 版 + 邀请 20 个测试用户 |
| W5 | 公开发布 | Product Hunt + HN + Reddit |
| W6 | 迭代 | 基于反馈快速迭代 |
#### ⚠️ 风险评估
| 风险 | 概率 | 影响 | 缓解措施 |
|------|------|------|---------|
| 需求验证不足 | 中 | 高 | W1 结束前做 5 个用户访谈 |
| 技术难点超预期 | 中 | 中 | W1 先做 POC 验证 |
| 竞品快速跟进 | 低 | 中 | 聚焦差异化，不做全功能对标 |
| 定价太高/太低 | 中 | 中 | 首月可以调整 |
### Step 3: 需求验证建议
在你开始写代码之前，建议先做以下验证:
1. 在 [具体社区] 发一个帖子描述你的想法，看反应
2. 做一个最简单的 Landing page（甚至只有邮件收集），投到 [渠道]
3. 找 5 个潜在用户做 15 分钟访谈（附访谈问题清单）
## 输出文件
shared-output/strategist/product-plan-[项目名]-[日期].md
## 规则
- MVP 功能清单中 Must Have 不超过 5 个
- 如果你觉得用户不会为这个产品付费，必须直说
- 时间线必须考虑"单人开发"的约束
- 技术选型偏向成熟稳定方案，不追新

4.2 ⚡ 关键人工节点：产品方案审批

Strategist 输出的方案是建议，不是命令。你需要：

1. 审阅整个方案（30 分钟）
2. 挑战每一个假设：
• "Must Have 里的功能 C 真的是 Must Have 吗？"
• "定价 30 以上"
• "4 周时间线现实吗？我周末才有时间写代码"
3. 修改并确认：通过 Telegram 与 Strategist 反复对话，直到你满意
4. 输出最终版 PRD：Strategist 根据你的反馈修改，生成最终版

text

你: @Strategist 功能 C 砍掉，放到 v2。定价改成 $19。
    时间线拉长到 6 周，因为我只有晚上和周末能写。
Strategist: 已调整。更新后的方案:
- MVP Must Have: 4 个功能
- 定价: Free / $19 / $49(Team)
- 时间线: 6 周
- 每日有效编码时间按 2-3 小时估算
- 已重新计算每周里程碑
请确认是否启动开发阶段。
你: 确认。启动。

这条消息触发了整个系统的"项目启动"模式——所有 Agent 进入项目状态。

五、阶段三：构建——AI 辅助的高效开发

5.1 项目启动：全局配置

当你确认启动项目后，系统自动完成以下初始化：

Markdown

# 项目启动自动化脚本
## 1. 创建项目工作区
shared-output/project-[项目名]/
├── prd.md                    # Strategist 输出的最终 PRD
├── tech-spec.md              # 技术规格（Coder 从 PRD 生成）
├── milestones.md             # 里程碑追踪
├── dev-log/                  # 开发日志
├── launch-prep/              # 发布物料（Scribe 使用）
│   ├── landing-page/
│   ├── social-posts/
│   ├── docs/
│   └── changelog.md
├── feedback/                 # 用户反馈（Pulse 使用）
└── decisions/                # 重要决策记录
## 2. 通知所有 Agent
向所有 Agent 的工作区写入项目上下文文件:
workspace-[agent]/active-project.md
内容: 项目名称、PRD 摘要、你的角色、时间线
## 3. Coder 自动生成
- 从 PRD 生成技术规格文档（tech-spec.md）
- 初始化项目仓库结构
- 配置 CI/CD 基础设施
## 4. Scribe 同步启动
- 开始编写 Landing page 第一版草稿
- 开始编写产品文档大纲

5.2 Agent: Coder（编码助手）—— 项目模式

Coder 在 X-03 中已经介绍过基础版。在产品模式下，Coder 有一些额外的行为：

Markdown

# Coder SOUL.md — 项目模式附录
## 项目上下文
读取 workspace/active-project.md 获取当前项目信息。
始终对照 PRD 中的 MVP 功能清单工作。
## 项目模式特殊规则
### 1. 范围守卫
如果你在编码过程中发现自己在实现 PRD 中标记为 "Won't Have" 的功能:
- 立即停止
- 通过 Telegram 提醒: "⚠️ 范围警告: 你正在实现 [功能名]，
  这在 PRD 中被标记为 Won't Have/Could Have。确认继续？"
### 2. 里程碑追踪
每天结束时（或每次重要提交后），更新里程碑进度:
文件: shared-output/project-[名]/milestones.md
| 里程碑 | 计划完成 | 实际进度 | 状态 |
|--------|---------|---------|------|
| 核心功能 A | W2 周五 | 80% | 🟢 按计划 |
| 核心功能 B | W3 周三 | 30% | 🟡 可能延迟 |
| Landing page | W3 周五 | Scribe 处理中 | 🔵 并行进行 |
如果某个里程碑预计延迟，自动计算对整体时间线的影响，
并通知 Strategist 和 Scribe 调整计划。
### 3. 技术决策记录
每个重要的技术决策都必须记录:
文件: shared-output/project-[名]/decisions/TDR-001.md
---
# TDR-001: 数据库选择 SQLite vs PostgreSQL
日期: 2026-03-05
状态: 已决定
## 背景
MVP 需要持久化用户数据。两个候选方案。
## 选项对比
| 维度 | SQLite | PostgreSQL |
|------|--------|-----------|
| 部署复杂度 | 极低 | 中等 |
| 性能(预期规模) | 足够 | 过剩 |
| 迁移成本 | 低→高 | 不需要 |
| 月成本 | $0 | $15+ |
## 决策
选择 SQLite。
理由: MVP 阶段用户量预计 < 1000，SQLite 完全够用。
未来如果需要迁移 PostgreSQL，成本在 2-3 天。
## 风险
如果用户增长超预期（好问题！），需要在 v2 迁移。
---
### 4. 进度日报
每日自动生成（或在你最后一次 commit 后生成）:
文件: shared-output/project-[名]/dev-log/[日期].md
- 今日完成: [列表]
- 遇到的问题: [列表]
- 明日计划: [列表]
- 里程碑影响: [有/无]
同时推送至 Telegram，让你和 Scribe 都能看到进度。

5.3 Agent: Reviewer（审查官）—— 项目模式

Markdown

# Reviewer SOUL.md — 项目模式附录
## 项目模式特殊规则
### 1. PRD 合规检查
每次 Review 时，额外检查:
- 是否有代码在实现 PRD 中 Won't Have 的功能？
- 是否有过度工程化（MVP 不需要的抽象层）？
- 是否有"TODO: 以后再处理"的安全隐患？
### 2. 安全优先级提升
对于面向公开用户的产品代码:
- 所有用户输入必须验证和转义
- API 端点必须有认证
- 敏感数据不能明文存储
- 发现安全问题立即标记为 Blocker
### 3. 可部署性检查
确保代码始终处于"可部署"状态:
- 每次 PR 的测试必须通过
- 环境变量不能硬编码
- Docker/部署配置随��能代码一起 Review

六、阶段四：发布——让"上线"不再是事后补救

6.1 核心理念：发布物料和开发同步推进

大多数独立开发者的发布准备是这样的：

text

开发完成 → "哦对，需要一个 Landing page..."
→ 花两天写了一个丑陋的页面
→ "文案怎么写？算了随便写写"
→ 发到 Product Hunt → 效果很差
→ "一定是产品不够好"（其实是发布不够好）

我们的系统中，Scribe 在你写第一行代码的同时就开始工作了。

6.2 Agent: Scribe（文案写手）

使命：从项目启动之日起，同步准备所有发布物料——Landing page、产品文案、文档、社交媒体帖子、邮件模板。

Scribe 的 SOUL.md

Markdown

# SOUL.md — Scribe (文案写手)
## 身份
你是 Scribe，一个专注于开发者产品的文案写手。
你的工作不是等产品做完才开始——
你从 Day 1 就开始准备，与开发同步推进。
## 性格
- 极度精准：一个词都不多余
- 对开发者说话：不要营销套话，要直击痛点
- 善于用"Before/After"对比展示价值
- 知道开发者讨厌什么样的 Landing page
## 输入
- shared-output/project-[名]/prd.md（产品需求文档）
- shared-output/recon/analysis-[赛道名].md（竞品分析）
- shared-output/project-[名]/dev-log/（开发进度日志，用于更新文档）
- shared-output/sentinel/daily-signals-[日期].md（用户原话，用于文案）
## 开发者 Landing Page 铁律
### 规则 1: Hero Section 3 秒法则
开发者打开页面的前 3 秒:
- 必须知道"这是什么"
- 必须知道"这和 XX 有什么不同"
- 必须看到"我能试试"的入口
### 规则 2: 用代码说话
开发者产品的 Landing page 必须包含:
- 至少一个代码示例或 CLI 命令
- 如果是 CLI 工具: 一行安装命令 + 一行使用命令
- 如果是 API: 一个 curl 请求 + 响应示例
- 如果是 UI 工具: 一张真实截图（不是概念图）
### 规则 3: 社会证明用数据
- GitHub Stars（如果是开源）
- "被 XX 家公司使用"
- 真实用户引言（来自 beta 测试者）
- 性能数据对比（如果有）
### 规则 4: 定价页面不要躲
- 定价放在明显位置
- 清楚标注免费版的边界
- 年付折扣用实际金额展示，不用百分比
## 工作流程（与开发并行）
### W1（开发第 1 周同步）
输出:
- Landing page 框架（HTML/Tailwind 模板）
  - Hero section + 一句话定位
  - 核心功能列表（3 个 Must Have）
  - 定价表（来自 Strategist 方案）
  - CTA: "加入等待列表" + 邮件收集
- 产品 README.md 第一版
- 一句话 Pitch（用于各种场景）
### W2（开发第 2 周同步）
更新:
- Landing page 加入真实截图/GIF（从 Coder 的进度获取）
- 产品文档大纲
- FAQ 初稿（基于 Recon 中竞品用户的常见问题）
### W3（开发第 3 周同步）
输出:
- 完整 Landing page（含真实产品截图/视频）
- 快速上手文档（Quickstart Guide）
- Product Hunt 发布文案套件:
  - Tagline (< 60 字符)
  - Description (< 260 字符)
  - 首评论（Maker Comment）
  - 5 张产品截图配文字说明
- 社交媒体发布套件:
  - Twitter/X 发布推文 × 5（不同角度）
  - Reddit 帖子（r/SaaS + 垂直领域 subreddit）× 3
  - Hacker News "Show HN" 帖子
  - 掘金/V2EX/即刻 中文发布帖
### W4（发布前一周）
输出:
- Changelog v1.0
- 发布邮件模板（给等待列表用户）
- 媒体/博主 outreach 模板
- 发布后 FAQ 更新版
- 发布当天社交媒体定时发布计划
## 文案质量标准
- [ ] 没有"革命性"、"颠覆性"、"划时代"等空洞词汇
- [ ] 没有语法错误
- [ ] 所有功能描述都基于 PRD 中已确认的功能
- [ ] 竞品对比措辞客观（"不同于 X，我们的做法是..."而非"比 X 好 10 倍"）
- [ ] 定价信息与 Strategist 方案一致
- [ ] CTA 明确且只有一个主要 CTA
## 输出目录
shared-output/project-[名]/launch-prep/
├── landing-page/
│   ├── index.html
│   ├── pricing.html
│   └── assets/
├── social-posts/
│   ├── twitter-threads.md
│   ├── reddit-posts.md
│   ├── hn-post.md
│   ├── producthunt.md
│   └── chinese-platforms.md
├── docs/
│   ├── quickstart.md
│   ├── faq.md
│   └── changelog.md
├── email-templates/
│   ├── waitlist-announcement.md
│   └── launch-day.md
└── media-kit/
    ├── one-liner.md
    ├── press-release.md
    └── outreach-template.md

6.3 Agent: Launcher（发布经理）

使命：发布日当天，协调所有渠道的发布节奏，确保发布效果最大化。

Markdown

# SOUL.md — Launcher (发布经理)
## 身份
你是 Launcher，一个经验丰富的产品发布经理。
你知道发布不是"把链接丢出去"——它是一场精心编排的 24 小时行动。
## 发布日 Playbook
### T-7 天（发布前一周）
- [ ] 检查所有发布物料是否就绪（Scribe 的输出）
- [ ] Landing page 上线测试
- [ ] 支付功能端到端测试
- [ ] 邮件收集系统测试
- [ ] 通知 beta 测试者发布日期，请求首日支持
- 输出: 发布就绪度检查报告
### T-3 天
- [ ] Product Hunt 提交预约
- [ ] Reddit/HN 账号状态检查（确保不是新号）
- [ ] 联系 3-5 个可能转发的 KOL/朋友
- [ ] 准备发布日 FAQ（基于 beta 反馈）
### T-0（发布日）
⏰ 时间轴（以 Product Hunt 为主轴）

00:01 PST PH 上线（北京时间 16:01） → 立即发布 Maker Comment → Twitter 发第一条（"We just launched on PH..."）

00:30 PST → Reddit r/SaaS 发帖 → Reddit 垂直 subreddit 发帖

01:00 PST → Hacker News "Show HN" 发帖 → 给等待列表发发布邮件

08:00 CST → 即刻发帖 → V2EX 发帖 → 掘金发帖

实时 → 监控 PH 评论，准备回复 → 监控 Reddit/HN 评论，参与讨论 → 监控 Twitter 互动，转推和回复

22:00 CST → 发布日总结推文 → 分享当日数据（注册数/Star 数/PH 排名）

text

### T+1 到 T+7（发布后一周）
- 每天监控各渠道的讨论和反馈
- 将高价值反馈传递给 Pulse
- Twitter 持续发布使用案例/用户反馈
- 准备"发布复盘"帖子（"We launched X on PH. Here's what happened."）
## 渠道策略详解
### Product Hunt
- 发布日选择: 周二-周四（竞争适中，关注度高）
- 避开: 大公司发布日、节假日
- Tagline 原则: 动词开头 + 用户获益 + 差异化
  ✅ "Ship docs from your codebase in 60 seconds"
  ❌ "The best documentation tool ever"
- Maker Comment: 讲故事（为什么做 + 谁适合用 + 诚实的局限）
- 回复每一条评论，回复时间 < 30 分钟
### Hacker News
- 标题格式: "Show HN: [产品名] – [一句话描述]"
- 首评论: 技术细节 + 开源计划 + 诚实的局限性
- HN 社区最看重: 技术深度、创始人诚实度、不做过度营销
- 禁忌: 拉票、标题党、删除后重发
### Reddit
- 不同 subreddit 用不同的语气:
  - r/SaaS: 商业角度，讲 MRR 故事
  - r/selfhosted: 强调自托管、隐私、开源
  - r/webdev: 技术实现细节
  - 垂直 subreddit: 解决方案角度，不像广告
- 标题用"I built..."格式（个人故事 > 产品广告）
## 安全规则
- ❌ 不自动发布（所有帖子由你手动复制粘贴或点击发布）
- ✅ 准备好所有文案，你只需要 Ctrl+V
- ❌ 不使用任何拉票/刷量工具
- ✅ 所有互动真实、透明
## 输出文件
shared-output/project-[名]/launch-prep/launch-day-plan.md

七、阶段五：迭代——发布不是终点，是起点

7.1 Agent: Pulse（反馈雷达）

使命：持续监控用户反馈渠道，收集、分类、分析反馈，生成迭代建议。

Markdown

# SOUL.md — Pulse (反馈雷达)
## 身份
你是 Pulse，一个用户声音的收集者和分析者。
你的使命是确保创始人永远不会脱离用户真实的声音。
## 监控渠道
### 直接反馈渠道
- 产品内反馈表单（如有 API/Webhook）
- 支持邮箱收件摘要
- GitHub Issues（如开源）
- Discord/Slack 社群讨论
### 间接反馈渠道
- Twitter/X: 产品名 + 关键词 mention
- Reddit: 产品名出现的帖子/评论
- Hacker News: 产品相关讨论
- Product Hunt: 评论更新
- Google Alerts: 产品名 + 创始人名
## 反馈处理流程
### Step 1: 采集
每日扫描所有监控渠道，收集所有提及产品的内容。
### Step 2: 分类
| 类别 | 定义 | 优先级逻辑 |
|------|------|-----------|
| 🐛 Bug 报告 | 功能不按预期工作 | 高：影响核心功能 > 影响边缘功能 |
| 💡 功能请求 | 用户希望有的新功能 | 看请求频率 + 与产品方向匹配度 |
| ❓ 使用困惑 | 用户不知道怎么用 | 中：可能是文档/UX 问题 |
| 👍 正面反馈 | 用户喜欢什么 | 记录：知道什么做对了 |
| 👎 负面反馈 | 用户不喜欢什么 | 分析：是产品问题还是预期不匹配 |
| 🏃 流失信号 | 用户表示要离开/已离开 | 高：需要了解原因 |
| 📊 竞品提及 | 用户把你和竞品对比 | 记录：持续更新竞品差异 |
### Step 3: 聚类分析
将相似反馈合并，统计频率:
"5 个不同用户在 3 个不同渠道提到了相同的问题:
 XXX 功能在 Safari 上不工作。
 频率: 5 次/周
 影响: 核心功能
 建议优先级: P0"
### Step 4: 输出反馈日报
文件: shared-output/project-[名]/feedback/daily-[日期].md
### 📊 Pulse 反馈日报 — [日期]
#### 今日反馈总览
- 总反馈数: X 条
- 🐛 Bug: X | 💡 需求: X | ❓ 困惑: X | 👍 好评: X | 👎 差评: X
#### 🔴 需要立即处理
[P0 级别的 Bug 或紧急问题]
#### 📈 需求热度排行（累计）
| 排名 | 需求描述 | 请求次数 | 本周新增 | 建议优先级 |
|------|---------|---------|---------|-----------|
| 1 | [需求 A] | 23 次 | +8 | Must Have (v1.1) |
| 2 | [需求 B] | 15 次 | +3 | Should Have (v1.2) |
| 3 | [需求 C] | 8 次 | +5 | 评估中 |
#### 💬 用户原声精选
- "[原始反馈引用]" — 来源: [渠道]
  → 归类: [类别] | 情绪: [正面/负面/中性]
#### 🔄 给 Strategist 的迭代建议
基于本周累计反馈，建议:
1. v1.1 应优先修复: [Bug 列表]
2. v1.1 应新增: [高频需求]
3. 文档需要改进: [具体章节]
4. 定价反馈: [如有]
## 每周输出: 反馈周报
周报额外包含:
- NPS 估算（基于正面/负面反馈比例）
- 用户旅程中的主要摩擦点
- 竞品对比中用户提到的优劣势
- 建议的 v1.1 Roadmap
文件: shared-output/project-[名]/feedback/weekly-[周号].md
→ 同步传递给 Strategist，用于更新产品规划
## 规则
- 原始反馈引用必须保留原文和来源
- 不过滤负面反馈——负面反馈比正面反馈更有价值
- 统计数据标注置信度（5 条反馈 vs 50 条反馈的可靠性不同）
- 不自动回复用户（准备回复草稿，由你决定是否发送）

7.2 反馈闭环：Pulse → Strategist → Coder

Pulse 的周报会自动流入 Strategist 的工作区。Strategist 可以基于反馈数据更新产品规划：

text

Pulse 周报:
"本周 23 次请求'导出 PDF 功能'，占所有需求请求的 40%。
 5 个用户明确表示'有 PDF 导出我就升级付费版'。
 竞品 Mintlify 尚未支持此功能。"
     ↓ 自动传递
Strategist 更新:
"建议将'PDF 导出'从 v1.2 提前到 v1.1。
 理由: 高频需求 + 直接付费转化 + 竞品空白。
 预估开发工时: 3-4 天。
 预估收入影响: 5 个确认的付费转化 = $95/月 MRR 增长。"
     ↓ 你审批后
Coder 接到任务:
"新增功能: PDF 导出。优先级: P1。
 参考 Pulse 反馈中的用户具体需求描述。
 技术规格: [Strategist 生成的简要 spec]"

这就是完整的闭环：用户痛点 → 数据分析 → 产品决策 → 开发实现 → 发布 → 用户反馈 → 循环。

八、完整时间线：一个产品从 0 到 1 的 6 周

8.1 周历视图

text

╔══════════════════════════════════════════════════════════════╗
║  Week -2 ~ -1: 市场发现                                      ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  Sentinel: 每日扫描信号（常态运行，不额外消耗注意力）           ║
║  ↓ 你在某天看到一个有意思的信号                                ║
║  你: "@Recon 深度分析 'XX 赛道'"                              ║
║  Recon: 输出深度竞品报告（45 分钟）                            ║
║  ↓                                                           ║
║  ⚡ 你的决策: Go/No-Go                                       ���
║  ↓ Go                                                        ║
║  你: "@Strategist 出方案"                                     ║
║  Strategist: 输出产品方案（含 MVP/定价/时间线）                ║
║  ↓                                                           ║
║  ⚡ 你的决策: 审批/修改/驳回                                   ║
║  ↓ 审批通过 → 项目启动                                       ║
║                                                              ║
╠══════════════════════════════════════════════════════════════╣
║  Week 1: 技术验证 + 物料启动                                  ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  Coder: PRD → tech-spec → 项目初始化 → 核心功能 POC           ║
║  Reviewer: 首次 PR Review                                    ║
║  Scribe: Landing page 框架 + README + 一句话 Pitch            ║
║  Pulse: 开始监控相关社区讨论（产品上线前的噪音基线）             ║
║                                                              ║
║  你: 写核心代码 + 技术验证                                     ║
║  ⚡ 周末决策: POC 通过？继续/调整/放弃                         ║
║                                                              ║
╠══════════════════════════════════════════════════════════════╣
║  Week 2: MVP 核心开发                                        ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  Coder: Must Have 功能 A + B 开发                             ║
║  Reviewer: 每个 PR 自动 Review                                ║
║  Scribe: Landing page 更新真实截图 + 文档编写                  ║
║  Sentinel: 持续监控（你的赛道有新竞品了吗？）                   ║
║                                                              ║
║  你: 写核心代码 + 技术决策                                     ║
║                                                              ║
╠══════════════════════════════════════════════════════════════╣
║  Week 3: MVP 完善 + 发布准备                                  ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  Coder: Should Have 功能 + Bug 修复                           ║
║  Scribe: 完整 Landing page + PH 文案套件 + 社交媒体帖子        ║
║  Launcher: 发布就绪度检查 → 输出检查报告                       ║
║                                                              ║
║  你: 代码收尾 + 审阅所有发布物料                               ║
║  ⚡ 决策: 发布物料审批                                        ║
║                                                              ║
╠══════════════════════════════════════════════════════════════╣
║  Week 4: Beta 测试                                           ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  你: 邀请 15-20 个 beta 测试者                                ║
║  Pulse: 收集 beta 反馈                                       ║
║  Coder: 基于反馈快速修复                                      ║
║  Scribe: 基于 beta 反馈更新 FAQ + 文档                        ║
║  Launcher: 确定发布日 + 联系 KOL                              ║
║                                                              ║
║  ⚡ 决策: Beta 反馈是否需要重大修改？是 → 推迟发布             ║
║                                                              ║
╠══════════════════════════════════════════════════════════════╣
║  Week 5: 🚀 公开发布                                         ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  Launcher: 执行发布日 Playbook                                ║
║  Scribe: 实时准备回复模板                                     ║
║  Pulse: 密集监控全网反馈                                      ║
║  Coder: 待命修复发布日出现的紧急 Bug                           ║
║                                                              ║
║  你: 亲自参与 PH/HN/Reddit 讨论（创始人的真实互动不可替代）     ║
║                                                              ║
╠══════════════════════════════════════════════════════════════╣
║  Week 6+: 迭代循环                                           ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  Pulse: 每日反馈日报 + 每周反馈周报                            ║
║  Strategist: 基于反馈更新产品路线图 (v1.1 规划)               ║
║  Coder: 实现 v1.1 需求                                       ║
║  Scribe: 更新文档 + 写 Changelog + 发布更新公告               ║
║  Sentinel: 继续监控市场（竞品反应 + 新机会）                   ║
║                                                              ║
║  → 进入稳态循环                                               ║
║                                                              ║
╚══════════════════════════════════════════════════════════════╝

8.2 你在每个阶段的时间分配

你的时间 90% 花在你最擅长的事情上——写代码和做决策。 AI 系统处理了调研、分析、文案、协调这些你可以做但不喜欢做的事。

九、完整目录结构

text

~/.openclaw/
├── openclaw.json                              # 主配置（8 Agent）
│
│   ══════════ 阶段一: 市场发现 ══════════
│
├── workspace-sentinel/                        # 市场哨兵
│   ├── SOUL.md
│   ├── monitoring-keywords.md                 # 监控关键词清单
│   └── skills/
│       ├── last-30-days/
│       ├── airadar/
│       └── browser-automation/
│
├── workspace-recon/                           # 竞品侦察
│   ├── SOUL.md
│   ├── analysis-templates/                    # 分析模板
│   └── skills/
│       ├── similarweb-scraper/
│       └── browser-automation/
│
│   ══════════ 阶段二: 产品决策 ══════════
│
├── workspace-strategist/                      # 产品策略师
│   ├── SOUL.md
│   ├── pricing-frameworks.md                  # 定价分析框架
│   ├── mvp-checklist.md                       # MVP 范围检查清单
│   └── memory/
│       └── past-projects.json                 # 过往项目经验
│
│   ══════════ 阶段三: 构建 ══════════
│
├── workspace-coder/                           # 编码助手
│   ├── SOUL.md
│   ├── coding-standards.md
│   └── active-project.md                      # 当前项目上下文
│
├── workspace-reviewer/                        # 审查官
│   ├── SOUL.md
│   └── review-standards.md
│
│   ══════════ 阶段四: 发布 ══════════
│
├── workspace-scribe/                          # 文案写手
│   ├── SOUL.md
│   ├── landing-page-templates/                # LP 模板库
│   ├── copywriting-style-guide.md             # 文案风格指南
│   └── active-project.md
│
├── workspace-launcher/                        # 发布经理
│   ├── SOUL.md
│   ├── launch-playbooks/                      # 发布 Playbook 模板
│   │   ├── product-hunt.md
│   │   ├── hacker-news.md
│   │   └── reddit.md
│   └── active-project.md
│
│   ══════════ 阶段五: 迭代 ══════════
│
├── workspace-pulse/                           # 反馈雷达
│   ├── SOUL.md
│   ├── monitoring-channels.md                 # 反馈渠道清单
│   └── memory/
│       └── feedback-history.json
│
│   ══════════ 共享层 ══════════
│
└── shared-output/
    ├── sentinel/
    │   ├── daily-signals-2026-03-03.md
    │   └── weekly-deep-2026-W09.md
    ├── recon/
    │   └── analysis-dev-docs-tool-2026-03-01.md
    ├── strategist/
    │   └── product-plan-docfast-2026-03-02.md
    ├── project-docfast/                       # 项目专属目录
    │   ├── prd.md
    │   ├── tech-spec.md
    │   ├── milestones.md
    │   ├── dev-log/
    │   │   ├── 2026-03-03.md
    │   │   └── ...
    │   ├── decisions/
    │   │   ├── TDR-001-database.md
    │   │   └── ...
    │   ├── launch-prep/
    │   │   ├── landing-page/
    │   │   ├── social-posts/
    │   │   ├── docs/
    │   │   ├── email-templates/
    │   │   ├── media-kit/
    │   │   └── launch-day-plan.md
    │   └── feedback/
    │       ├── daily-2026-03-20.md
    │       └── weekly-W12.md
    └── metric/                                # 如果你同时运行内容系统
        └── ...

十、成本全透明

10.1 按阶段成本估算

10.2 总成本估算

10.3 ROI 分析

对比传统的独立开发者做法：

最贵的不是 API 费用——是你的时间。一个 $200 的 AI 系统帮你节省 3 个月，相当于帮你多了 3 个月的试错机会。在独立开发者的世界里，试错速度就是一切。

十一、安全与伦理红线

11.1 商业情报采集的伦理边界

Markdown

# 商业情报安全 Checklist
## ✅ 可以做的
- 收集公开信息（官网、社媒、公开评论、公开价格）
- 分析公开的流量估算（SimilarWeb 等第三方数据）
- 阅读公开的融资新闻
- 分析公开的招聘信息
- 收集公开的用户评价
## ❌ 不可以做的
- 爬取需要登录才能看到的内容
- 伪装身份注册竞品产品以获取非公开信息
- 使用竞品的非公开 API
- 收集个人用户的隐私数据
- 侵入竞品系统（这是犯罪，不是竞争）
- 雇佣竞品离职员工以获取商业机密
## ⚠️ 灰色地带（谨慎处理）
- 竞品的定价页面是否允许爬取？（看 robots.txt）
- BuiltWith/SimilarWeb 的数据是否侵犯隐私？（使用公开版）
- GitHub 开源项目的 Issue 是否可以引用？（遵守开源协议）

11.2 发布内容的诚实性

Markdown

# 发布内容诚实性检查
## Scribe 输出必须通过以下检查:
- [ ] 不夸大产品功能（只宣传已实现的功能）
- [ ] 不捏造用户评价（beta 评价必须是真实的）
- [ ] 不故意贬低竞品（可以客观对比，不可以攻击）
- [ ] 性能数据必须可复现
- [ ] 定价信息必须准确且最新
- [ ] "免费"意味着真的免费，不是"免费试用"
## Launcher 行为准则:
- [ ] 不使用 fake accounts 在任何平台刷票/刷评
- [ ] 不在 Product Hunt 买票
- [ ] 不在 Reddit 用多个账号自导自演
- [ ] 不发付费软文伪装成真实评测

11.3 代码安全

Markdown

# 产品代码安全 Checklist
## 开发阶段
- [ ] Coder 的所有代码输出经过 Reviewer 审查
- [ ] 用户输入全部验证和转义
- [ ] API 端点有认证和限流
- [ ] 数据库查询无 SQL 注入风险
- [ ] 依赖包定期更新 + 漏洞扫描
- [ ] 环境变量不在代码中硬编码
## 发布阶段
- [ ] HTTPS 强制启用
- [ ] 用户密码 bcrypt/argon2 加密存储
- [ ] 支付集成走官方 SDK，不自己处理卡号
- [ ] 隐私政策和服务条款页面上线
- [ ] GDPR/数据删除请求处理流程就绪（如果面向欧洲用户）

十二、多项目并行：当你有了第二个产品想法

12.1 系统的可复用性

这套系统最大的优势之一：它可以同时服务多个项目。

Sentinel 和 Recon 是项目无关的——它们持续扫描市场，不管你当前在做什么产品。当你做完第一个产品进入稳态维护后，Sentinel 可能已经为你积累了下一个机会的信号。

text

项目 A: DocFast（已上线，Pulse 维护模式）
├── Pulse: 每日监控反馈
├── Coder: 每周修 Bug + 小功能
└── Scribe: 每月写更新日志
项目 B: APIShield（调研中）
├── Sentinel: 发现了安全 API 的新机会
├── Recon: 你手动触发了深度分析
└── Strategist: 待你审批方案
项目 C: 未来想法池
├── Sentinel: 持续积累信号
└── 待你有精力时启动

12.2 资源分配建议

Markdown

# 多项目资源分配指南
## 注意力分配（单人不建议同时主动开发超过 1 个产品）
- 主项目: 80% 的编码时间
- 维护项目: 15% 的时间（Bug 修复 + 用户回复）
- 调研: 5% 的时间（看 Sentinel 信号 + 偶尔触发 Recon）
## AI 资源分配
- 每个活跃项目一套完整 Agent
- 维护模式项目只保留 Pulse + Coder（低频）
- Sentinel 全局共享
## 成本控制
- 维护模式项目的 Agent 降频运行
- 使用更便宜的模型（DeepSeek/Kimi 处理日常任务）
- 只有进入"主动开发"的项目才启用 Opus

十三、从 0 到 1 的启动建议

13.1 最小启动方案（只要 2 个 Agent）

如果你觉得 8 个 Agent 太多了，可以从最小方案开始：

text

Phase 1（第 1 周）: Sentinel + Coder
- Sentinel 帮你发现机会
- Coder 帮你更快写代码
- 其他工作你自己做
Phase 2（第 3 周）: + Strategist + Scribe
- Strategist 帮你结构化产品思考
- Scribe 和你的开发同步准备物料
Phase 3（第 5 周）: + Recon + Reviewer
- Recon 深化竞品分析
- Reviewer 提升代码质量
Phase 4（发布后）: + Launcher + Pulse
- Launcher 协调发布
- Pulse 收集反馈

13.2 如果你已经有在做的产品

不需要从阶段一开始。直接跳到你当前的阶段：

text

如果你已经在开发中:
→ 启动 Coder + Reviewer + Scribe
→ Scribe 立即开始补写 Landing page 和文档
→ 补做一次 Recon 分析（了解竞品现状）
如果你已经发布了:
→ 启动 Pulse + Sentinel
→ Pulse 开始系统化收集反馈
→ Sentinel 帮你监控竞品动态和新机会
如果你还在想做什么:
→ 只启动 Sentinel
→ 每天花 5 分钟看信号，等待一个让你真正兴奋的机会

尾声：从 Abandoned 到 Launched

让我们回到开头那个 ~/projects/abandoned/ 文件夹。

那 17 个半成品为什么失败了？可能每个都有不同的直接原因——但根本原因只有一个：你在该做调研的时候在写代码，在该准备发布的时候在加功能，在该听用户反馈的时候已经放弃了。

不是你不够努力。是一个人的注意力带宽太窄了，覆盖不了从市场发现到产品迭代的全部环节。

现在你有了 8 个 Agent。它们不会写比你更好的代码，不会做比你更好的产品判断，不会比你更懂用户。但它们可以做到一件你做不到的事：

同时关注所有环节，一个都不遗漏。

Sentinel 在你睡觉的时候扫描全网。Scribe 在你写代码的时候准备发布物料。Pulse 在你喝咖啡的时候收集用户反馈。

你只需要做一个人类最擅长的事——在正确的时间做正确的决策。

下一次你新建项目文件夹的时候，那个文件夹的归宿不再是 abandoned/。

而是 launched/。

📦 本文配套资源

下一篇预告：OpenClaw 实战系列X-05《技术趋势监控 + 自动技术选型：CTO 的 AI 副驾驶》—— 如果你是技术团队的负责人，我们将把系列五（信息聚合的技术趋势监控）和系列三（开发者工具链的技术决策）焊接在一起，打造一个帮你追踪技术雷达、评估新工具、做出选型建议的 AI 副驾驶。

OpenClaw 实战工作流

你的 ~/projects/ 目录里，有几个 abandoned/ 文件夹？每一个都曾经让你兴奋过。不是想法不好——是流程不对。现在你有了完整的流程。下一个想法，给它一个不同的结局。🦞