如何在Azure DevOps中实现子卡片讨论备注自动汇总到父卡片

Azure DevOps 没有开箱即用的原生功能可以实现子工作项 Discussion 评论的自动汇总（rollup）到父工作项。
ADO 原生提供的 Rollup 聚合能力仅支持数值类字段（比如故事点、剩余工时、关联任务计数等）的自动计算，Discussion 属于非结构化富文本评论数据，不在原生聚合支持范围内。原生界面仅能在父工作项的关联链接列表里跳转到子项查看评论，无法直接在父项讨论区聚合展示子项评论内容。

按实现成本从低到高排序，推荐以下三种可落地路径：

方案一：Power Automate 低代码流实现（最优通用方案） #

不需要写大量代码，普通项目管理员就能配置完成，适合绝大多数团队：

• 新建自动化云流，触发条件选择 Azure DevOps 连接器的「当工作项被添加评论时」，配置作用范围为目标项目的 Task 工作项类型
• 流触发后，第一步查询当前触发评论的 Task 的所有父级关联，过滤链接类型为Parent，定位到所属的 User Story
• 拉取本次新增的评论原文，给内容加上统一来源标记，例如：> 🔄 自动同步自子任务 #【Task ID】【Task标题】，和父项原生评论做明确区分
• 调用连接器的「添加评论到工作项」动作，把标记好的评论追加到对应 User Story 的 Discussion 区
• 可选增强配置：
  • 新增评论更新、删除的触发流，通过评论ID映射关系，同步更新/删除父项里对应的同步评论
  • 给父项新增评论触发校验：如果检测到用户编辑/删除的是带同步标记的评论，自动回滚操作，提示「该评论为子任务同步内容，请前往对应子任务页面修改」，实现同步评论只读效果
  • 配置月度定时全量校验流，补全因为触发失败漏同步的评论

方案二：Web Hook + Azure Function 代码实现（高定制化方案） #

如果团队有开发能力，需要更高的可控性、支持多层级工作项汇总，可以选这个方案：

• 在 ADO 项目的 Web Hook 配置页，订阅三个事件：工作项评论已添加、工作项评论已更新、工作项评论已删除，事件触发时把 payload 推送到自行部署的 Azure Function 接口
• 在 Function 中编写处理逻辑：
  1. 校验触发事件的工作项类型，仅处理 Task 类型的评论事件
  2. 递归查询当前 Task 的所有上级工作项（支持 Epic -> Feature -> User Story -> Task 多层级结构）
  3. 维护一张评论ID映射表（存在Azure Table Storage或者其他轻量存储里），绑定子项原评论和父项同步评论的对应关系
  4. 调用 ADO REST API 完成父项评论的增删改操作，同步时可以给评论写入自定义扩展标记，比文本前缀的识别准确率更高
• 这个方案的稳定性、可扩展性比低代码流更好，还可以自定义评论排序、过滤规则，比如仅同步特定状态下Task的评论、@特定用户等。

方案三：自定义表单控件实时拉取展示（无冗余数据方案） #

如果不想在父项里写入重复的评论数据，可以选择做自定义控件嵌入工作项表单：

• 基于 ADO 扩展框架开发一个轻量工作项控件，部署到组织级后添加到 User Story 的表单布局里
• 控件加载时自动调用 ADO API，拉取当前 User Story 下所有子 Task 的全部评论，按时间线和父项本身的原生评论混排展示，支持点击直接跳转到子项的原评论位置
• 这个方案完全不需要做数据同步，没有冗余数据，也不需要处理评论增删改的同步逻辑，缺点是聚合的评论不会出现在原生Discussion区域，是在单独的自定义控件模块展示。

• 不建议直接修改父项原生Discussion区的已有评论内容插入同步内容，容易破坏原有评论结构，所有同步内容都以独立评论的形式追加即可
• 如果要做编辑、删除的双向同步，必须维护评论ID的映射关系，不要靠文本匹配找对应评论，避免匹配出错导致内容混乱
• 如果团队不需要严格区分父项原生评论和子项同步评论，也可以配置同步规则时自动@对应父项的负责人，确保消息触达

内容的提问来源于stack exchange，提问作者HerrimanCoder