AI协作工作区排行榜：多角色软件工程Context Engineering方案

传统软件工程如何完成跨角色协作？本质上围绕“人”进行信息传导。

一个项目中，产品经理、设计师、前端工程师、后端工程师、测试工程师、运维人员各自拥有独立工具链和工作流。产品经理负责PRD与业务规则，设计师产出原型与交互说明，前端开发编写组件并衔接API，后端开发构建服务与数据库，测试人员专注用例及自动化脚本。角色分工明确，但沟通完全依赖会议、文档和即时消息。

在纯人工协作时代，这种模式尽管效率低，尚可运转。但AI编码代理介入后，缺陷立刻显现：AI只能读取代码仓库中的文本符号，却无法理解背后的业务上下文。它容易误判过时文档，混淆需求、测试与代码之间的映射关系。更棘手的是，各角色不得不反复向AI解释背景信息，沟通成本急剧攀升。而产品、测试、设计等非开发人员，若被迫为了适配AI而改用工程化格式，团队阻力可想而知。

因此，一个关键问题摆在面前：随着AI深度融入研发流程，项目的仓库是否应从一个纯粹的“代码仓库”，进化为一个“面向AI协作的项目工作空间”？

核心思路

该工作空间并非简单地将所有资料（需求文档、设计稿、测试用例）一并塞入同一个仓库。其核心模式如下：

人类团队继续使用自己最熟悉的方式维护资料（如Markdown、Word文档、Figma截图），而AI不直接消费这些“杂乱”的原始信息。中间需增加一个“编译层”——暂称 Context Compiler。它将产品、设计、测试、代码等各类资料，编译成AI可解析的结构化上下文。随后，不同角色的AI代理（如开发Agent、测试Agent）基于编译好的“角色视图”进行协同。

需求文档 / 设计稿 / 测试用例 / 源码...
    ↓
Context Compiler
    ↓
/AI/领域上下文  /  /AI/角色视图
    ↓
产品Agent / 设计Agent / 前端Agent / 后端Agent / 测试Agent / 审查Agent

这一模式的意图并非用AI取代人类，而是消除低效、重复的上下文转述，使AI在多角色协作中更加可靠。

一句话概括

简言之，面向AI协作的项目工作空间是一种以项目目标为边界、以角色视图为入口、以Context Compiler为转换层的协作架构。它保留了各角色的原始工作方式，同时将所有资料编译为对应Agent可用的AI上下文。

核心并非“让其他角色服务开发”

这一提案常被误读为：“产品、设计、测试将资料整理好，是为了让开发Agent更顺畅地写代码。” 这仅是一个极小的应用场景。更完整的视角如下：

每个角色保留自己的原始资料，同时也借助AI理解其他角色产出的成果。 Context Compiler负责将其他角色的信息，编译成当前角色可理解、可操作的AI上下文视图。

举个例子：

开发角色使用AI时

前端的AI代理需要理解需求、页面流程、交互规则与API契约。后端的AI代理则需要掌握业务规则、领域模型和幂等性要求。这些信息从产品、设计、测试资料中提取，并编译为专用的 for-frontend.generated.md 和 for-backend.generated.md 文件。

产品角色使用AI时

产品经理无需亲自阅读代码。他的AI代理能够基于前端、后端、测试的上下文，回答诸如“当前哪些需求已实现？哪个接口对应哪个需求？测试是否覆盖了关键验收标准？”等问题。

设计角色使用AI时

设计师的AI代理可基于前端代码与页面图谱，回答“当前页面实现状态如何？哪些组件已存在？设计稿与代码实现是否存在差异？”

测试角色使用AI时

测试人员的AI代理能够基于全部上下文，生成风险矩阵、判定回归范围，甚至提供测试数据建议。

因此，AI上下文是双向流动的，而非单向传递。所有角色的信息经编译后流转，为每个角色提供支持。

设计原则

要让该模式落地，必须遵循以下关键原则。

1. 人类资料保持原始形态

产品、设计、测试人员，继续用Word、流程图等工具保持习惯。绝不能为了适配AI而迫使整个团队改变工作方式。这是底线。目标是降低协作成本，而非增加非开发成员的负担。

2. AI默认读取编译后上下文

普通AI代理默认禁止直接读取“../产品”、“../设计”等原始资料目录。应优先读取“/工作区/AI”目录。仅在用户明确要求，或上下文缺失、冲突等特殊情况下，才允许回溯原始资料。此举可有效防止AI被混乱草稿或过期方案误导。

3. AI上下文为编译产物，非人工维护资料

/工作区/AI下的所有文件均由Context Compiler自动生成，通常不应手动修改。若生成内容有问题，应追溯至原始资料修正，再重新编译。这建立了“源码→编译→产物”的清晰链路。

4. 领域上下文与角色视图分离

/AI目录需包含两类内容：

• 领域上下文：回答“某个领域当前状态如何？”例如“产品当前的需求列表”、“后端当前的API契约”。
• 角色视图：回答“某个角色为完成工作，需要从其他领域理解什么？”例如“for-product.generated.md”即为产品角色的视图，融合了代码实现状态与测试覆盖情况。

5. 优先利用官方支持的AI工具机制

该工作空间并非要创建一个全新的孤立系统。对于Claude Code的CLAUDE.md、Skills、Agents，或Codex的AGENTS.md、MCP等机制，应尽量遵循官方使用方式。/AI仅存放生成给AI使用的上下文数据，不替代这些官方机制。

6. Skill是方法，MCP是工具，AI上下文是数据

三者需清晰区分。Skill指导Agent如何执行任务（例如“如何实现一个后端API”），MCP为Agent提供可调用的工具（如“查询最新文档”），AI上下文则描述项目当前状态（如“有哪些需求、接口和测试”）。明确各自职责，系统才能避免混乱。

当前推荐目录结构

这是一个供社区探讨的起点，并非最终答案。

项目根/
    /产品           # 人工维护的产品资料（.docx, .pdf, .xmind）
    /设计           # 人工维护的设计资料
    /测试           # 人工维护的测试资料

    /工作区         # AI代理的工作目录
        /AI          # 编译后的AI上下文
        /前端        # 前端源码
        /后端        # 后端源码
        ...

为何将“/工作区”单独提取？主要原因：防止AI代理默认扫描外层混乱的人工资料；为AI运行环境划定清晰边界；便于配置各类AI工具的项目级规则、Skills和MCP。

为何这一提案值得关注？

它致力于解决以下核心痛点：

• 减少无效沟通：大量跨角色会议实质上是在“同步上下文”。当上下文能被结构化沉淀、生成和追踪，许多沟通便不再必要。
• 降低AI幻觉：Agent不再直接读取混乱的原始资料，而是读取经过编译和校验的结构化上下文，从而从根本上减少误读与错误输出。
• 保留传统习惯：产品、设计、测试无需改变工作方式，只需定期将资料放置到正确位置，并审核Compiler生成的报告。这是该方案能够实际落地的前提。
• 实现全链路追踪：一个需求从文档到代码到测试，均能建立清晰的追踪关系。无论对AI审查、回归分析，还是人工Review，都具有极高价值。
• 赋能所有角色：这是最关键的一点。产品经理无需懂代码即可查看实现状态，测试人员无需逐一询问开发即可评估变更影响。每个角色都能借助AI理解他人的工作成果。

当前尚待解决的问题

该提案尚不成熟，留下若干开放问题供社区探讨：

• 命名问题：“/工作区”是否全球通用？或改用 /workspace 或 /dev 更合适？
• 权限与存储：人工资料（可能包含敏感信息）应完全存放于Git仓库，还是兼容Git LFS、外部链接或私有对象存储？
• 版本控制：“/AI”目录的编译产物是否应提交至Git？是团队共享统一版本，还是每人本地生成？
• 访问规则：普通Agent应被“完全禁止”读取人工资料，还是需要更细粒度的权限模型？
• Compiler能力：Context Compiler需达到何种强度？最低可用版可能仅支持Markdown和PDF，生产级版本则需支持Figma、Jira、Confluence等。
• 跨工具标准：Claude Code、Codex、Cursor等工具的Skill、MCP机制各异，是否需要制定跨工具通用标准？
• 质量评估：如何评估AI上下文质量？可能需要一个 context-health.generated.md 来记录覆盖率、冲突数量、过期信息等。
• 角色视图粒度：为不同角色生成的视图，信息粒度如何控制？产品视图是否需包含代码细节？测试视图是否需要完整的code graph？

欢迎参与讨论

此仓库并非为了宣告某个标准，而是为了提出一个开放性问题：在AI编码代理时代，软件项目的目录结构与协作方式应如何演变？我期待与社区一同，通过实际讨论与迭代，给出一个经得起验证的答案。

来源：互联网