# 下一代产品定义初稿

**状态：** Draft v0.1  
**日期：** 2026-03-27  
**适用范围：** 下一代自有产品线，不用于约束 `Hive CN` 维护线

---

## 1. 一句话定位

`Build for Future` 是一个面向中文开发者的 AI-native Feature Delivery Workspace，帮助开发者围绕“正在推进的功能交付”而不是围绕 `Project`、`Session` 或文件本身来工作。

---

## 2. 短版定位

它不是另一个聊天壳，也不是另一个 AI 编辑器。  
它是一个围绕功能推进、上下文组织、agent 执行、验证证据和交付状态来设计的开发工作台。

---

## 3. 长版定位

今天大多数 AI coding 产品，仍然主要围绕三种中心来组织工作：

- 以 `Editor` 为中心
- 以 `Terminal` 为中心
- 以 `Chat / Session` 为中心

这些产品已经能大幅提升编码效率，但它们仍然保留了传统开发工具的核心结构：用户自己维护任务边界、上下文切换、验证链路和交付节奏。

`Build for Future` 的目标不是继续优化“如何和 AI 聊天写代码”，而是重新定义“开发者如何持续推进一个结果直到可交付”。

它的核心不是代码编辑，而是：

- 我正在推进什么
- 这个功能现在卡在哪
- 哪个 agent 在做什么
- 是否已经具备测试、review、PR、merge 的条件
- 接下来最该做的动作是什么

所以，它应该被定义为：

**一个面向中文开发者的、本地优先的、以功能交付为中心的智能开发工作台。**

---

## 4. 它是什么

### 4.1 产品本质

它是一个 `Feature-first` 的开发工作台。

核心对象不是文件，不是单次聊天，也不是单个命令，而是“一个需要被推进到完成的功能/改动目标”。

### 4.2 工作方式

用户进入产品后，看到的主舞台不是项目列表，也不是会话历史，而是：

- 当前正在推进的 Feature
- 每个 Feature 的当前状态
- 每个 Feature 关联的 worktree / branch / session / agent run
- 每个 Feature 当前缺失的验证证据
- 哪些 Feature 可以继续推进、review、合并或交付

### 4.3 产品形态

它是：

- 本地优先的桌面开发工作台
- AI-native 的多线程开发环境
- 面向个人开发者和小团队的交付推进工具

---

## 5. 它不是什么

为了避免方向漂移，先明确非定义。

它不是：

- 另一个以聊天记录为核心的 AI coding app
- 另一个通用代码编辑器替代品
- 一个更漂亮的终端壳
- 一个通用项目管理软件
- 一个先做 SaaS 再考虑本地体验的云产品
- 一个以“跟上上游 Hive”为目标的长期 fork

它可以包含编辑、终端、diff、review、模型切换这些能力，但这些都不是产品真正的中心。

---

## 6. 用户真正要解决的问题

### 6.1 当前 AI coding 工作流的问题

当前主流 AI coding 产品虽然已经能帮用户写代码、跑命令、分析项目，但在真实开发推进里仍然存在几个结构性问题：

- 用户关心的是“功能推进状态”，产品却主要展示“聊天线程”
- 用户关心的是“这个功能离交付还差什么”，产品却主要展示“agent 刚才做了什么”
- 用户需要长期、多轮、多分支推进一个目标，但大部分产品仍然鼓励单会话线性推进
- 用户要自己维护 worktree、session、branch、diff、review、test 之间的关系
- 中文开发者在网络、模型、术语和协作习惯上仍然存在额外摩擦

### 6.2 真正的用户目标

用户不是为了“多开一个 session”而使用产品。  
用户也不是为了“调用一个 agent”而使用产品。  
用户真正的目标是：

- 把一个功能做出来
- 在过程中不丢上下文
- 能清楚判断当前进度
- 能自然切换 agent 和执行路径
- 最后带着足够证据完成交付

---

## 7. 核心世界观

### 7.1 Build for Future

`Build for Future` 是品牌哲学，不是单个功能点。

它表达的是：

- 这不是给旧工作流补一个 AI 面板
- 这是按下一代开发方式重新设计的产品
- 默认接受 AI、并行 agent、长任务、多上下文、持续验证这些已经成为现实

### 7.2 Feature-first

产品内部的对象模型应当围绕 `Feature` 而不是 `Session` 组织。

这意味着：

- `Session` 不是主角，只是执行线程
- `Project` 不是主角，只是代码和配置容器
- `Feature` 才是一等公民
- 交付状态是产品主舞台的一部分，而不是事后附属信息

### 7.3 Delivery-centered

系统不只帮助“写出代码”，而是帮助“推进到可交付状态”。

所以产品必须内建：

- 上下文收拢
- agent 执行
- 验证链路
- 风险感知
- 交付状态表达

### 7.4 Human-steered

这不是“完全自动的软件工厂”叙事。  
它更像“开发者主导、agent 并行执行、系统负责组织和显化状态”的工作台。

开发者始终保留：

- 目标定义权
- 上下文裁剪权
- 路径选择权
- 审阅和合并权

---

## 8. 顶层对象模型

下一代产品的顶层对象建议改为：

### 8.1 Workspace / Project

代码仓库、基础配置、团队上下文的容器。

### 8.2 Feature

产品中的一等公民。  
它代表一个待推进的交付目标，例如：

- 修复中文输入法下的发送问题
- 补全整套界面的汉化
- 重构某个页面布局
- 增加某个 review 检查能力

### 8.3 Run / Thread / Session

Feature 下的执行线程。  
它们可以由人发起，也可以由不同 agent 并行推进。

### 8.4 Evidence

所有支撑交付判断的证据集合，包括：

- diff
- test
- lint
- screenshot
- review notes
- risk summary
- PR 状态

### 8.5 Delivery State

每个 Feature 都应该具备清晰可视的状态，例如：

- Draft
- In Progress
- Blocked
- Ready for Review
- Ready to Merge
- Shipped

---

## 9. 与现有产品的差异化

### 9.1 相对于 Hive CN

`Hive CN` 仍然主要以 `Project -> Session` 组织工作。  
下一代产品要转向 `Project -> Feature -> Run / Evidence / Delivery State`。

这不是皮肤升级，而是对象模型重构。

### 9.2 相对于聊天型 coding app

许多产品的中心仍然是会话流。  
我们要把聊天退居为执行轨迹，而不是工作入口。

### 9.3 相对于编辑器型 AI 产品

很多产品强化的是“在编辑器里调用 agent”。  
我们要强化的是“围绕功能交付组织整个开发过程”。

### 9.4 相对于企业流程平台

有些产品已经开始把 issue、PR、Slack、Jira 接进来，但往往更偏企业流程平台。  
我们的优先级不是流程覆盖，而是先把个人和小团队的高频开发推进体验做顺。

---

## 10. 目标用户

第一阶段不追求大而全，先服务最典型、最高频的一类人。

### 10.1 核心目标用户

- 高频使用 Claude Code / Codex / OpenCode / Cline 一类 agent 的开发者
- 同时维护多个项目、多个 worktree、多个改动线程的个人开发者
- 想把 AI 真正纳入日常开发主流程，而不是偶尔问问题的工程师
- 对中文 UI、中文说明、本地优先、网络环境适配有明确需求的开发者

### 10.2 次级用户

- 小团队技术负责人
- 需要并行推进多项改动的全栈开发者
- 愿意将 agent 纳入 feature 开发主流程的产品型工程师

---

## 11. 第一阶段产品承诺

第一阶段不承诺“替代所有 IDE”。  
第一阶段只承诺一件事：

**让一个开发者更自然地推进功能，而不是管理工具碎片。**

具体来说，第一阶段应做到：

- 打开产品就能看见当前在推进什么
- 任意一个 Feature 的上下文和执行线程都能被快速恢复
- 用户能知道一个 Feature 现在离“可 review / 可合并 / 可交付”还差什么
- 多 agent 和多 session 不再造成结构混乱

---

## 12. 语气与品牌表达方向

### 12.1 我们希望传达的感觉

- 不是实验玩具
- 不是“加了 AI 的旧工具”
- 不是只给极客玩的复杂编排器
- 而是一个真正为未来开发方式构建的、清晰、克制、强有主张的产品

### 12.2 推荐的品牌表达关键词

- Build for Future
- AI-native
- Feature Delivery
- Workspace
- Local-first
- Human-steered
- Built for Chinese developers

---

## 13. 首页文案草案

下面是几种可以继续演进的首页定位文案。

### 版本 A：最稳

面向中文开发者的 AI-native Feature Delivery Workspace

### 版本 B：更有产品感

围绕功能交付，而不是围绕文件和会话工作的下一代开发工作台

### 版本 C：更品牌化

Build for Future  
为下一代开发方式构建的智能工作台

### 版本 D：更偏结果导向

从想法到 PR，再到交付，用一个工作台持续推进每个 Feature

---

## 14. 当前阶段的非目标

为了保持聚焦，先明确不做什么：

- 不定义自己为“替代 VS Code 的完整 IDE”
- 不优先做插件生态
- 不优先做大型团队协作平台
- 不优先做企业流程审批系统
- 不一开始就为 Tauri 重写服务
- 不为了“看起来先进”而堆砌过多 agent 编排概念

---

## 15. 第一版结论

下一代产品不应再被定义为“汉化后的 Hive”或“另一个 AI IDE”。  
它应该被定义为：

**一个面向中文开发者的 AI-native Feature Delivery Workspace。**

它的价值不在于让用户开更多 session、调用更多模型，  
而在于让用户更清楚、更连续、更低摩擦地推进一个功能，直到它真的可以被 review、merge 和交付。

---

## 16. 后续文档衔接

在这份产品定义之后，下一步应继续补两份文档：

1. `docs/plans/2026-03-27-next-product-ux-principles.md`
2. `docs/plans/2026-03-27-next-product-ia.md`

这两份分别负责定义：

- 交互原则、体验原则、反模式
- 首页 / Feature 列表 / Feature 详情 / Run 详情 / 交付状态的整体信息架构
