me：
上一个回答我很不满意，所以那个分支作废，我新开了一个分支，在这个分支的基础上继续。我希望的是你能够找到最优秀的产品，然后依照那个架构来进行开发，但结果不尽人意。我觉得这种开发模式不正确。

1. 你现在是一名产品经理，开发架构师，业务分析师。给我规范一下开发的流程，写到全局的文件里，我希望每一次对话，都能够慢慢的优化迭代我开发的工作流，可以适应我的习惯，也可以直接指出我需要调整的工作流程，避免再次出现上一个这么弱智的提问。
2. 理性向量一会，我的工作流大致为：先询问关键词，在市面上寻找同类的实现方案，整理进一个文件夹，然后在根据这些同类的方案以及自己的想法整理出自己的大致的方案，再然后与ai、与同事讨论，得出一个综合的方案。最后在让ai划分阶段，各阶段的计划。逐步实现。这样的工作流如何，市面上是否有更好的工作流。
   
codex：
已经把新流程写入项目根级 [AGENTS.md](D:/hua_project/muban-cp/AGENTS.md)。以后在这个仓库中的新对话都会遵循，不会再从模糊方向直接跳到大规模开发。

当前分支：`稍微满意的基础模板`  
提交：`b3a3a83 docs(workflow): gate product discovery before implementation`  
工作区干净，没有修改业务代码。

## 对你原工作流的评价

方向大约有 70% 是正确的：

```
关键词 → 同类方案 → 自己的方案 → AI/同事讨论 → 分阶段实现
```

主要缺少四个环节：

1. 关键词之前缺少“问题定义”

关键词会受到最初表达限制。应该先明确用户、现场任务、成功指标、约束、事实、推测和未知问题，再由 AI 提出中英文关键词供你调整。

2. 不应该寻找唯一“最优秀产品”

产品没有脱离使用条件的绝对排名。应建立参考集合：

- 直接同类产品
- 某项体验特别优秀的相邻产品
- 行业标准
- 成熟开源实现
- 当前项目和旧客户端
- 不适合本项目的反例

最后提取各自优秀的产品模式，而不是完整照抄某一个产品。

3. 讨论与开发之间缺少原型验证

正式编码前应先做：

- 业务流程图
- 信息架构
- 线框图或可评审 HTML
- 关键异常状态
- 高风险技术 PoC
- 多方案加权比较

4. 开发后缺少学习回流

日志、现场反馈和实际演示结果，应回流修改方案和工作流，而不是一条直线走到底。

## 最终采用的工作流

```
问题框定
→ AI 提出关键词，用户修正
→ 用户/现场 + 市场产品 + 标准开源 + 现有代码调研
→ 至少三个候选方向
→ 原型或限时 PoC
→ AI、用户、同事综合讨论
→ ADR 保存重大决定
→ 用户明确批准执行
→ 纵向阶段开发
→ 每阶段演示并决定继续、调整或停止
→ 日志与反馈进入下一轮发现
```

该流程组合了：

- [Design Council Double Diamond](https://www.designcouncil.org.uk/resources/framework-for-innovation/)：发现、定义、发展、交付，并允许根据新证据返回前面阶段。
- [Shape Up](https://basecamp.com/shapeup/1.1-chapter-02)：先明确边界、投入上限、风险和非目标，再批准开发。
- [AWS ADR](https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html)：记录重大决定的背景、候选方案和后果。
- [Scrum Guide](https://scrumguides.org/scrum-guide.html)：透明、检查、适应。
- [Atlassian Product Discovery](https://www.atlassian.com/agile/product-management/discovery)：同时验证价值、可用性、可行性和战略适配，并让发现与交付持续互相反馈。

## 建立的文件

- [完整产品研发工作流](D:/hua_project/muban-cp/docs/workflow/product-development-workflow.md)
- [用户与 AI 协作偏好](D:/hua_project/muban-cp/docs/workflow/collaboration-profile.md)
- [工作流学习日志](D:/hua_project/muban-cp/docs/workflow/workflow-learning-log.md)
- [战略调研目录规范](D:/hua_project/muban-cp/docs/discovery/README.md)
- [架构决策 ADR 模板](D:/hua_project/muban-cp/docs/templates/architecture-decision-record.md)
- [升级后的需求提案模板](D:/hua_project/muban-cp/docs/templates/business-requirement-and-module-proposal.md)
- [本次流程治理提案](D:/hua_project/muban-cp/docs/proposals/UC-003-product-development-workflow-governance.md)

以后面对“统一客户端最终产品形态”这类问题，我会先声明为战略通道，建立调研包、参考产品集合和多个产品方向，停在原型及方案评审阶段。只有你明确选择方向并说“执行”，才进入生产代码开发。

me：
我希望把这个写到全局的提示词上下文里面，让往后每次开发都自动参照这个工作流来进行，每一个对话都有机会有可能可以迭代更新工作流。

codex：
已经把新流程写入项目根级 [AGENTS.md](D:/hua_project/muban-cp/AGENTS.md)。以后在这个仓库中的新对话都会遵循，不会再从模糊方向直接跳到大规模开发。

当前分支：`稍微满意的基础模板`  
提交：`b3a3a83 docs(workflow): gate product discovery before implementation`  
工作区干净，没有修改业务代码。

## 对你原工作流的评价

方向大约有 70% 是正确的：

```
关键词 → 同类方案 → 自己的方案 → AI/同事讨论 → 分阶段实现
```

主要缺少四个环节：

1. 关键词之前缺少“问题定义”

关键词会受到最初表达限制。应该先明确用户、现场任务、成功指标、约束、事实、推测和未知问题，再由 AI 提出中英文关键词供你调整。

2. 不应该寻找唯一“最优秀产品”

产品没有脱离使用条件的绝对排名。应建立参考集合：

- 直接同类产品
- 某项体验特别优秀的相邻产品
- 行业标准
- 成熟开源实现
- 当前项目和旧客户端
- 不适合本项目的反例

最后提取各自优秀的产品模式，而不是完整照抄某一个产品。

3. 讨论与开发之间缺少原型验证

正式编码前应先做：

- 业务流程图
- 信息架构
- 线框图或可评审 HTML
- 关键异常状态
- 高风险技术 PoC
- 多方案加权比较

4. 开发后缺少学习回流

日志、现场反馈和实际演示结果，应回流修改方案和工作流，而不是一条直线走到底。

## 最终采用的工作流

```
问题框定
→ AI 提出关键词，用户修正
→ 用户/现场 + 市场产品 + 标准开源 + 现有代码调研
→ 至少三个候选方向
→ 原型或限时 PoC
→ AI、用户、同事综合讨论
→ ADR 保存重大决定
→ 用户明确批准执行
→ 纵向阶段开发
→ 每阶段演示并决定继续、调整或停止
→ 日志与反馈进入下一轮发现
```

该流程组合了：

- [Design Council Double Diamond](https://www.designcouncil.org.uk/resources/framework-for-innovation/)：发现、定义、发展、交付，并允许根据新证据返回前面阶段。
- [Shape Up](https://basecamp.com/shapeup/1.1-chapter-02)：先明确边界、投入上限、风险和非目标，再批准开发。
- [AWS ADR](https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html)：记录重大决定的背景、候选方案和后果。
- [Scrum Guide](https://scrumguides.org/scrum-guide.html)：透明、检查、适应。
- [Atlassian Product Discovery](https://www.atlassian.com/agile/product-management/discovery)：同时验证价值、可用性、可行性和战略适配，并让发现与交付持续互相反馈。

## 建立的文件

- [完整产品研发工作流](D:/hua_project/muban-cp/docs/workflow/product-development-workflow.md)
- [用户与 AI 协作偏好](D:/hua_project/muban-cp/docs/workflow/collaboration-profile.md)
- [工作流学习日志](D:/hua_project/muban-cp/docs/workflow/workflow-learning-log.md)
- [战略调研目录规范](D:/hua_project/muban-cp/docs/discovery/README.md)
- [架构决策 ADR 模板](D:/hua_project/muban-cp/docs/templates/architecture-decision-record.md)
- [升级后的需求提案模板](D:/hua_project/muban-cp/docs/templates/business-requirement-and-module-proposal.md)
- [本次流程治理提案](D:/hua_project/muban-cp/docs/proposals/UC-003-product-development-workflow-governance.md)

以后面对“统一客户端最终产品形态”这类问题，我会先声明为战略通道，建立调研包、参考产品集合和多个产品方向，停在原型及方案评审阶段。只有你明确选择方向并说“执行”，才进入生产代码开发。

me：
我需要清理一下文档（很多文档没啥用，），我需要新开一个对话，按照新工作流重新讨论。
1. 保留：docs/analysis/mainstream-solutions-and-plc-reuse-assessment.md、docs/architecture/capability-catalog.md、docs/architecture/unified-client-architecture.md、docs/guides/new-business-module-guide.md，其他的文档都归档。
   
codex：
文档清理完成，可以新开对话重新讨论。

当前 `docs` 活动区只保留：

- [主流方案与 PLC 复用评估](D:/hua_project/muban-cp/docs/analysis/mainstream-solutions-and-plc-reuse-assessment.md)
- [公共能力目录](D:/hua_project/muban-cp/docs/architecture/capability-catalog.md)
- [统一客户端架构](D:/hua_project/muban-cp/docs/architecture/unified-client-architecture.md)
- [新业务模块指南](D:/hua_project/muban-cp/docs/guides/new-business-module-guide.md)

其他处理：

- 18份历史文档已移动到 [归档目录](D:/hua_project/muban-cp/docs/archive/2026-08-18-before-workflow-restart)。
- Profile Schema 属于功能文件，不是普通文档，已迁移到 [profiles/schemas](D:/hua_project/muban-cp/profiles/schemas/desktop-profile.schema.json) 并修复引用。
- 根目录 [AGENTS.md](D:/hua_project/muban-cp/AGENTS.md) 已精简：新对话采用全局工作流，项目层只保留工业客户端特有规则，不再自动读取旧方案。
- README 和相关链接已修复。
- 工作区干净，归档可以通过 Git 恢复。

提交：

`9eba40f docs: archive superseded planning materials`

me：
给我同类方案的关键词，以及网址。

codex：
当前建议先研究“统一工业应用平台”，不要只搜索“MES”。MES 太宽泛，容易把方案带向大型服务端系统，而你的核心是“一台工业客户端承载多个可配置业务”。

## 第一组：最接近目标产品

|优先级|关键词|参考方案|为什么值得看|
|---|---|---|---|
|1|`Ignition modular industrial application platform`、`Ignition modules architecture`、`Ignition Vision client`|[Ignition Modules](https://inductiveautomation.com/ignition/modules)、[模块架构文档](https://www.docs.inductiveautomation.com/docs/8.3/getting-started/modules-overview)|和你的目标最相似：统一平台、业务模块、PLC/数据库连接、报警、报表，可按需增加或停用模块。|
|2|`Tulip composable MES`、`frontline operations platform`、`manufacturing app suite`|[Tulip Composable MES](https://support.tulip.co/docs/composable-mes)|值得参考“多个小型工业应用组合成完整系统”、公共数据模型、质量、追溯、工艺执行等业务组织方式。|
|3|`Siemens Industrial Edge apps`、`industrial edge application management`、`edge app deployment manufacturing`|[Siemens Industrial Edge 开发者概览](https://developer.siemens.com/industrial-edge/overview.html)|值得参考客户端应用的安装、启停、版本、设备管理、集中部署和应用市场模式。|
|4|`FactoryTalk Optix HMI platform`、`configurable industrial workstation UI`、`industrial application library`|[FactoryTalk Optix](https://www.rockwellautomation.com/en-us/products/software/factorytalk/optix.html)、[技术文档](https://www.rockwellautomation.com/en-us/support/documentation/technical/capabilities/optix-portfolio.html)|值得参考标准化工业 UI、组件库、报警、日志、报表、OPC UA、不同工业电脑部署。|

建议优先深入看：

1. **Ignition**：产品和模块架构参考。
2. **Tulip**：业务应用组合与用户体验参考。
3. **Siemens Industrial Edge**：模块部署、版本和运维参考。
4. **FactoryTalk Optix**：工业 UI 与设备连接参考。

## 第二组：设备与边缘架构

|关键词|官方资料|重点研究|
|---|---|---|
|`EdgeX Foundry device service architecture`、`pluggable device adapter`|[EdgeX Foundry 文档](https://docs.edgexfoundry.org/4.0/getting-started/)|业务与 PLC、串口、相机等设备驱动如何解耦。|
|`Eclipse Kura modular IoT edge framework`、`OSGi industrial edge application`|[Eclipse Kura](https://eclipse.dev/kura/)|模块生命周期、设备配置、远程管理、断网运行。|
|`OPC UA industrial interoperability`、`OPC UA information model`|[OPC UA 官方概览](https://opcfoundation.org/about/opc-technologies/opc-ua/)、[OPC UA 规范概览](https://reference.opcfoundation.org/specs/OPC-10000-1/4)|不同 PLC、设备和上层业务之间的标准化接口与信息模型。|

这些项目不一定适合直接塞进 Electron 客户端，但其“设备适配器”“公共设备服务”“业务不直接操作驱动”的思想值得采用。

## 第三组：插件化软件架构

|关键词|官方资料|重点研究|
|---|---|---|
|`VS Code extension architecture`、`extension manifest contribution points`、`activation events`|[VS Code Extension API](https://code.visualstudio.com/api/)、[Extension Anatomy](https://code.visualstudio.com/api/get-started/extension-anatomy)|模块清单、按需激活、菜单贡献、配置贡献、统一 UI 规范。|
|`Eclipse Theia plugin architecture`、`plugin host process isolation`|[Theia Plugin API](https://eclipse-theia.github.io/theia/docs/next/documents/Plugin-API.html)|插件隔离、插件 API、运行时安装与停用。|

这里借鉴的是软件架构，不是把客户端开发成代码编辑器。

## 第四组：业务边界与数据模型

|关键词|官方资料|用途|
|---|---|---|
|`ISA-95 manufacturing operations management`|[ISA-95 官方介绍](https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard)|判断客户端、MES、ERP、PLC 各自应该负责什么。|
|`ISA-95 equipment hierarchy`|同上|统一工厂、车间、产线、工位、设备的层级模型。|
|`ISA-95 production operations quality operations`|同上|整理生产、质量、维护、库存等业务模块边界。|

## 可以直接复制搜索的关键词包

```
"modular industrial application platform"
"composable MES architecture"
"frontline operations platform manufacturing"
"industrial workstation unified client"
"configurable shop floor operator terminal"
"industrial edge application management"
"HMI SCADA modular architecture"
"pluggable device adapter architecture"
"manufacturing application module lifecycle"
"feature flags module enable disable desktop application"
"offline-first industrial application"
"industrial application diagnostics logging"
"ISA-95 manufacturing operations management"
"OPC UA industrial interoperability"
"recipe changeover management software"
"SPC manufacturing software module"
"manufacturing traceability workstation"
```

中文辅助关键词：

```
统一工业客户端
可组合 MES
模块化工业应用平台
产线操作员工作站
工业边缘应用管理
可配置制造执行终端
多业务工业客户端
工业客户端模块启停
PLC 设备适配器架构
离线优先工业软件
生产换型管理软件
SPC 质量管理模块
制造追溯工作站
```

第一轮讨论建议围绕 **Ignition + Tulip + Siemens Industrial Edge** 展开：分别代表“统一平台”“业务组合”“部署运维”三个关键方向。它们应作为参考集合，不应直接选一个照搬。

me：
看了一会ignition的官网和b站视频，很难搜寻到我需要的信息。得问gpt。

目标：从具体业务客户端逐步演进为统一工业客户端平台  
背景：目前公司为每一个具体的产线上的业务都会开发一个客户端，然后一年下来，开发了很多个客户端，这些客户端有着部分相同的功能，但却分为了几个客户端，我认为最终应该是合为一个客户端的。  
目前有着大概的思路，但具体方案还需要探索讨论一下。  
现在我需要看一下同类的产品的方案是怎么样实现的，学习一下。  
目前我想要了解`Ignition modular industrial application platform`、`Ignition modules` 。我想要了解架构方案，我想要了解方案，你先给我列一下目录及对应的各个子目录的简介。我根据需要了解。

账号被封，笔记丢失。