# 从真实实验，到工程交付 (/docs)

我们从化工技术方案公司的实际工作出发：理解客户需求，攻克技术问题，开展实验，验证工艺，完成安全环保分析，最后交付一套说得清依据的解决方案。

**人把真实实验做出来，Agent 帮助组织研究、更新模型和推进工作，软件把每个结论与它的依据连起来。**

<Callout title="这套文档现在是什么状态？">
这是产品定义 v0.1。产品方向来自当前讨论；子系统边界、页面组织和实施顺序是供继续讨论的架构草案。当前已实现的是这个文档站，文中平台能力均为规划内容。已确认方向和待定问题见[决策记录](/docs/planning/decisions)。
</Callout>

## 从这里开始 [#从这里开始]

<Cards>
  <Card title="产品边界" href="/docs/product/boundaries" description="服务谁、解决什么问题，哪些事情由人和现有工具承担。" />
  <Card title="一个项目怎么走完" href="/docs/product/workflow" description="用同一个例子串起需求、实验、仿真、评审与交付。" />
  <Card title="三个工作台" href="/docs/workspaces" description="研究人员、项目负责人和客户分别看什么、做什么。" />
  <Card title="系统架构" href="/docs/architecture" description="共享底座怎样支撑各模块，模块之间怎么传递数据。" />
  <Card title="十个子系统" href="/docs/subsystems" description="逐个说明职责、数据归属、接口、失败处理与拆分方式。" />
  <Card title="首个验证闭环" href="/docs/planning/first-loop" description="第一阶段用什么实际结果证明这套产品值得继续做。" />
</Cards>

## 三个需要始终保持清楚的概念 [#三个需要始终保持清楚的概念]

| 概念 | 用人话说 |
| --- | --- |
| 产品 | 客户买来能独立完成一件工作的能力组合，例如 AI 研发工作台 |
| 工作台 | 不同角色的操作入口，例如研究侧和客户侧 |
| 子系统 | 负责一类业务及其数据的模块，例如实验记录或计算仿真 |

一个产品可以组合多个子系统；同一个子系统也可以出现在三个工作台里。具体组合见[产品化路径](/docs/product/productization)。

## 文档怎么读、怎么改 [#文档怎么读怎么改]

- 讨论业务：先读产品边界、项目流程和工作台。
- 讨论架构：先读总览、数据与版本，再进入具体子系统。
- 安排第一阶段：读首个验证闭环和决策记录。
- 遇到术语：查看[术语表](/docs/reference/glossary)。

文档中的示例项目、对象编号和目录结构都用于解释设计。涉及候选技术方案的地方会明确标注；没有写成已上线能力或已经承诺的交付时间。