团队协作场景的工作流是怎样的？

[nmgwddj]

这个项目使我眼前一亮，从部署到试用整个流程非常顺利。我遇到了一些工作流程上的问题，希望能帮忙解惑。

我们的团队针对一个产品可能有多种语言实现，如一个需求可能在 iOS、Android、HarmonyOS、Windows、macOS、Linux、Web 分别用不同的语言如 Objective-C、Java、C++、TS、ArkTS 等。同一个需求可能产出不同平台不同语言多份 proposal，但对于 PRD 全端都是一样的。

在现有工作流中，我可以实现某个项目中单个仓库的流程。但像上面这种情况，推荐的 workflow 是怎样的呢？

[ChenNima]

Hi @nmgwddj 感谢你的反馈！目前这个 case 确实比较特殊，我可以提供下我的几个想法：

• 目前一个 idea 是支持创建多个 proposal 的，理论上可以从一个idea出发分散到多个不同 proposal 的 tech design 中，但这样不能解决你的一个问题：PRD 是共享的
• 在此基础上，如果使用 OpenSpec 的话，可以做到在一份 PRD 上反复 Patch 不同平台的实现，来做到一个中央化管理 Spec 的效果，但不符合你多仓库协作的需求

有用户向我们反馈希望增加 Proposal，以及 Idea 之间的派生关系，比如从一个基础的 Idea 和 Proposal（也就是你的共享 PRD）然后派生出多个实际需要被实现实现的 sub idea / proposal，也想听听你的看法？

[nmgwddj]

@ChenNima 感谢百忙之中回复。

我们团队内部已经在实践一些文档管理的方案，但基本上各个相关的平台是割裂的。所以我可能更多的是给您提供一些现状和期望，对于如何实现，我也希望您或者大家有一些批判性思维，不要被特殊团队里面的历史流程局限思路。因为历史的迭代方式都是相对比较传统的，在 AI 加持下，可能很多步骤和流程是没有必要的。

在我们现有的团队工作流程下，产品给出的 PRD（类似这个项目的 Idea）是没有端侧属性的，我们会按产品需求或技术团队内部衍生的技术需求由 Feature owner 去编写一份公共的技术方案，在该公共的技术方案中会单独描述一些端侧差异（如 Web 端不需要考虑数据库持久化的场景），但不会细节到内部实现、设计模式等内容。最后由各端的开发人员再根据公共技术方案去生成类似 OpenSpec 的文档与仓库绑定，这些文档涉及到与代码仓库相关的 Proposal、Design、Tasks 等。

结合这个项目来看，按既定流程是需要端侧去根据各端不同的情况由各端开发人员去生成对应平台或语言的 Proposal，然后再开始实施，当人的差异越来越少时，更多的可能就是由 AI 驱动去生成各端各语言的细节实施计划。

我比较赞同 Proposal 的派生想法，这种情况你可以类比一下 AWS 端侧 SDK 的场景，当 AWS 服务有一个新的接口或功能实现后，需要对不同的端侧 AWS SDK 去实现，如 Rust、Java、C++ 各类语言的版本，他们的需求都是相同的，但具体实现时的语言、针对的平台等可能是不同的。在没有 AWS 强大的 Codegen 基础设施下如何驱动。