00 - 项目动机与背景：一人公司的构想

角色声明：我是 Founder (创始人)，你是我的 CTO / CPO (技术合伙人)。

为什么会有这个项目？

1. 时代背景：AI 带来的生产力变革

2024-2025 年，AI 代码助手的能力急剧提升。一个人 + AI = 一个完整的创业团队，这个命题正在从愿景变为现实。

但问题是：我们还没准备好如何管理这个"一人公司"。

传统公司有清晰的组织架构、角色分工、SOP 流程。而当我们独自作战时，往往是：

• 既是 Founder 又是 PM 又是 Architect 又是 Developer
• 角色切换混乱，决策缺乏章法
• 没有"第二双眼睛"来审视自己的决策

2. 核心洞察：Code is Liability, not Asset

代码是负债，不是资产。

这是我们的第一公理。

传统思维认为"写代码 = 创造价值"。但在 AI 时代，代码的本质是维护成本。每多一行代码，就多一分需要理解、测试、维护的负担。

因此，一人公司的原则是：

• 能用 SaaS，就不自己写
• 能复用开源架构，就不自己造轮子
• 以最小代码量，交付最大用户价值

3. 产品开发的本质逻辑

做产品的逻辑其实很简单：

发现问题 -> 验证方案 -> 交付价值

但很多人在 AI 辅助下容易陷入"技术陷阱"——为了炫技而造轮子，忘了用户到底需要什么。

我们建立这套体系的目的，就是用流程和角色分工，防止自己迷失在代码里。

角色声明：Founder & CTO/CPO

在这个一人公司里，你是唯一的决策者，我是你的技术合伙人。

注意：我是你的顾问和执行者，不是你的替代者。最终决策权永远在你手中。

共识：PRD 是产品和研发的沟通语言

从 0 到 1 做产品，和单纯写代码是两个完全不同的维度。

在传统公司里，Founder 负责描述愿景和目标，PM 负责转化为需求文档，研发负责实现。每个人在自己的岗位上发挥价值，通过 PRD 形成共识。

在一人公司里，你同样需要这种共识机制。PRD 就是你和 AI 之间的"合同"——它定义了我们要做什么、为什么做、怎么做。

一旦 PRD 达成共识，我们就可以：

• 细化每个角色的职能
• 拆解任务，分配给合适的 AI 工具
• 按 SOP 流程推进，而不是想到哪做到哪

宏观视角：为什么我们要"抄"架构？

做产品的逻辑是：发现问题 -> 验证方案 -> 交付价值。

以 Midday 为例，它已经跑通了"SaaS 交付价值"的通用底层：

• 账户体系与认证
• Stripe 支付接入
• 多租户数据隔离
• 高性能前端架构

如果我们从零去写这些功能，会消耗掉 80% 的精力，导致没有精力打磨真正属于我们的 20% 核心业务。

我们的策略

Midday 提供了：高性能跑车底盘（Next.js, Supabase, Turborepo, Stripe）
我们要做的：设计这辆车的外观、内饰，以及决定它开去哪里（是去越野还是赛道）

借用成熟底座，专注垂直领域的具体问题——这就是 AI 时代做产品的捷径。

流程纠偏：绝不能从数据库开始

从数据库设计开始是典型的"工程师思维"陷阱。

一旦先定义了表结构，你的思维就会被框死在"字段"里，导致产品很难用。

真正的产品流程 (Product Flow)：

1. User Story → 用户是谁？什么场景？解决什么痛点？
2. UX Flow → 用户怎么操作？页面怎么跳转？
3. Data Model → 为了支撑这个操作，后台需要存什么数据？

数据库是为业务服务的，应该放在最后一步。

产品流程：User Story → UX Flow → Data Model

我们拒绝"想到哪写到哪"的开发方式。真正的产品流程应该是：

1. User Story (用户故事)

• 用户是谁？
• 他在什么场景下？
• 他想解决什么痛点？

2. UX Flow (交互流程)

• 用户怎么操作？
• 页面怎么跳转？
• 有哪些分支和异常？

3. Data Model (数据模型)

• 为了支撑这个操作，后台需要存什么数据？
• 表之间是什么关系？

预期产出：一份 MVP 产品规格书，包含一句话介绍、核心功能列表、页面清单。

快速掌握新项目的四步法

面对陌生技术栈，我们采用以下方法快速上手：

Step 1: AI 搜索 real-world example

让 AI 帮你找同类型的开源项目（starter 或 production app）。

Step 2: Deepwiki 了解架构

用 AI 分析项目结构、依赖关系、核心模块。

Step 3: 同构复刻 (Isomorphic Reconstruction)

保持技术架构和代码结构完全一致，只更换业务场景。

Step 4: 生成 MVP 规格书

用上面的 Product Flow 产出产品规格文档。

AI 驱动的"从 0 到 1"最佳实践

❌ AI 不擅长的领域

• 初始化项目（依赖版本、脚本封装已有成熟方案）
• 复杂的配置细节
• 确保依赖版本兼容性

✅ AI 擅长的领域

• 生成结构说明书（目录结构、模块划分）
• 代码迁移（保持一致性的搬运）
• 业务逻辑填充（vibe coding）

最佳实践流程：

1. 用 create-xxx 初始化项目（脚本比 AI 更快更稳）
2. AI 生成结构说明书（技术架构图、模块划分）
3. 按说明书迁移核心组件（AI 搬运工模式）
4. 填充业务逻辑（对话式编程）
5. Review & Refactor（保持代码整洁）

实战行动：启动"创始人会议"

现在，你需要找一个 AI（推荐 Claude 3.5 Sonnet 或 DeepSeek-R1），让它担任你的 产品经理 (PM)。

创始人会议启动 Prompt

请复制以下内容给你的 AI，开启需求对齐：

Role: 你是我公司的资深产品经理。我作为创始人，准备开发一款名为 "SkillVault"（技能金库） 的个人成长追踪应用。

Context: 我们在技术上会复刻开源项目 Midday 的架构（Next.js + Supabase），但在业务上完全不同。Midday 是追踪财务，我们是追踪技能成长。

Goal: 请不要直接给我代码或数据库设计。我们需要先对齐需求。请通过连续提问的方式，帮我理清以下 3 个核心模块。每次只问一个模块的问题，等我确认后，再进行下一个：

1. 核心价值 (Value Proposition)：除了记录学习时间，我们如何量化用户的"成长"？（例如：类似 RPG 游戏的经验值？还是技能雷达图？）
2. 关键用户旅程 (User Journey)：用户完成一次"学习记录"的最短路径是什么？（是手动输入，还是通过 Chrome 插件抓取？）
3. MVP 范围 (Scope)：第一版我们要砍掉什么功能，只保留什么最核心的功能？

请开始你的第一个提问。

预期产出物：MVP 产品规格书

在对话结束后，你应该要求 AI 总结出一份 MVP 产品规格书 (Markdown)，这才是写代码的依据。它应该包含：

1. 一句话介绍

产品解决了什么核心问题。

2. 核心功能列表 (Features)

3. 页面清单 (Sitemap)

你需要做哪几个页面（首页、详情页、设置页等）。

总结

下一步

在下一篇文章中，我们将正式发布 一人公司章程 (OPCC)，定义完整的角色体系、SOP 流程和沟通协议。

Stay tuned.