我在安全团队做AI应用， 现在有个协作的问题：大家发现问题就在群里At我改，结果群里全是细节信息，而且容易抓不住问题重点，全是讨论。 很少有人能先讲清楚要达到什么结果，由谁来验收，我自己排在前面的事反而一直被打断。

立正反复讲的一个区分：不要一上来就关注零件和做法，要先说清楚要达到什么结果。他举过一个团队例子，领导层听到新名词就要求所有东西都改成那个形式，结果执行的人很无语，因为大家盯的是概念，不是结果⁠1。放到你的群里，同事@你说“这里有问题”，信息量其实很低：他不知道这算不算达标、由谁判断达标。如果发起时就写明期望的产出、判断标准和验收人，讨论就会围绕“是否达标”收敛，而不是无限展开细节。他在讲AI协作时也把这一点说得很直接：把结果和验收标准讲清楚，执行方自己处理过程中的问题⁠2。

群聊同时承担了发现、讨论、决策和追踪，信息就会糊在一起，重点被稀释。有一篇讲团队上下文的文章指出，经验和上下文散落在聊天、文档、复盘里，彼此没有结构和索引，每次都要重新拼凑⁠3。另一篇访谈整理里有个具体教训：一个功能做着做着偏离了最初的服务对象，因为半个月前的会议改了说法，但“为什么这样定”没有留下来，后面的人只能沿着新说法高效地做错⁠4。对你的处境，一个可试的做法是：群里只留“问题是什么、期望结果、验收人、当前状态”，具体排查过程放到一个可追踪的地方，比如一条任务记录或一个文档。这样你被打断时，先看到的是要不要接、接到什么程度，而不是一堆细节。

你排在前面的事一直被打断，一部分原因可能是别人不知道你在做什么、什么算紧急。立正讲过一个分工思路：确定性的、规则清楚的部分交给程序或流程，模糊的、需要判断的留给人，人只处理最值得看的部分⁠5。这可以迁移到你的协作上：把“什么情况必须找你、什么情况先走流程或找别人”写成一条简单规则，让大部分@在到达你之前就被分流。这不是推卸，而是让你的判断力用在真正需要的地方。