# 一个项目怎么走完 (/docs/product/workflow)

以下使用一个示意项目：客户希望从一股成分波动的含溶剂废液中回收有价组分。它用于说明软件流程，不代表已经确定了具体工艺路线。

## 1. 把需求变成设计基础 [#1-把需求变成设计基础]

客户提交现有分析报告、处理规模、目标纯度、现场公用工程条件和成本目标。项目人员把资料拆成可引用的数据项。

系统分别记录：客户提供、实验实测、文献参考、工程假设和计算结果。缺少的信息保持为待补充，不能被一个看起来合理的默认值悄悄代替。

**产物：** 需求记录、设计基础初版、技术问题清单。

## 2. 比较路线，找出最值得验证的问题 [#2-比较路线找出最值得验证的问题]

研究人员和 Agent 提出候选路线，并记录选择它们的条件。仿真可能发现某项分离性能对运行成本影响很大，而目前只有文献数据。

系统把它登记成一个研究问题：需要验证什么、如何判定、会影响哪个方案选择。

**产物：** 候选方案、关键假设、实验建议及依据。

## 3. 真人做实验，软件记录事实 [#3-真人做实验软件记录事实]

实验人员确认计划后执行。每次实验有自己的编号，关联样品批次、设备、实际操作条件、原始仪器文件和偏差。

如果计划与现场不同，两个值都保留。没有按计划完成的实验同样需要记录，后续再判断哪些数据可用于分析。

**产物：** 实验 Run、原始文件、现场记录、有效性说明。

## 4. 分析数据，更新模型 [#4-分析数据更新模型]

分析任务引用指定实验和数据版本，保留处理步骤、脚本或计算方法。新参数先作为候选模型版本，与实测数据比较。

模型更新可以来自参数拟合，也可以来自改变某项假设；两者要能区分。求解器收敛说明数值任务完成，模型是否足够贴近实验还需要另行判断。

**产物：** 分析结果、候选模型、误差与适用范围。

## 5. 推导下一轮工作 [#5-推导下一轮工作]

Agent 根据目标、已有证据和剩余不确定性提出下一步：补测原料、做重复实验、验证其他工况，或者进入方案细化。

建议需要说明为什么值得做、需要哪些资源、做完后能决定什么。研究人员可以接受、修改或否定，并记录原因。

**这一步回到实验或设计，形成 Human-in-the-loop 的持续改进闭环。**

## 6. 工程化与安全环保分析 [#6-工程化与安全环保分析]

方案逐步明确后，工艺对象、物流数据、设备负荷与计算结果被引用到工程设计和专业分析中。

同一条排出物流可以关联到污染源条目；同一台设备可以关联到偏差分析和保护措施。新增数据后，相关结论进入待复核状态，专业人员决定如何更新。

**产物：** 工程方案、关联清单、分析条目及待解决事项。

## 7. 发布阶段成果，与客户共同决定 [#7-发布阶段成果与客户共同决定]

项目负责人选定设计基础、实验依据、模型结果和报告版本，形成一个发布包。客户评论锚定具体曲线、图纸对象或报告段落。

客户提出的新要求进入需求变更；系统展示对实验计划、预算和交付物的影响，再由项目团队处理。

**产物：** 可追溯的交付版本、客户反馈、后续任务。

## 一次变更怎样传下去 [#一次变更怎样传下去]

以客户补充了进料组成分析为例：

| 环节 | 应发生什么 |
| --- | --- |
| 项目与设计基础 | 新数据形成修订，保留此前依据 |
| 研究规划 | 检查原有假设和实验是否仍覆盖新范围 |
| 计算与仿真 | 标记引用旧输入的结果；按规则提交新的运行任务 |
| 工艺模型 | 检查相关物流、设备负荷和方案比较 |
| 安全环保 | 提示依赖这些数据的分析条目需要复核 |
| 交付 | 旧发布包保持原样；新成果进入下一个版本 |

自动影响追踪以已登记的依赖为基础。缺少关联时要允许人工补充，不能声称已经发现所有影响。