我在安全团队做AI应用，现在有个协作的问题：大家发现问题就在群里At我改，结果群里全是细节信息，而且容易抓不住问题重点，全是讨论。很少有人能先讲清楚要达到什么结果，由谁来验收，我自己排在前面的事反而一直被打断。协作方说风控这个业务就是这样 要快速响应，不然黑产攻击都来了 啥也没解决。实际这些很多都是很小的事情和细节，事后也无法记录下产出和结果

立正反复讲的一个转变，是把注意力从“过程怎么走”挪到“最后什么算对”。他提到，给 AI 交代任务要像给一个没有上下文的实习生写要求：只凭这些信息，对方就能判断自己做完了没有、还差什么⁠1。他也把这一点说成结果导向指令：不逐步遥控，而是说清楚要什么、包含哪些维度、怎样算合格⁠2。放到你的群里，这意味着每次有人 At 你，先问一句“这件事最后要交付什么、谁签字确认”，而不是立刻进入细节。快速响应和结果清楚并不冲突：黑产攻击确实需要有人马上处理，但“马上处理”本身也可以是一个明确的结果——比如先止血、再补规则、由谁在什么时间确认已止血。

立正讲过一个团队案例：一个功能做出来偏离了最初的服务对象，回查才发现半个月前的会议改了目标，但更上层的设计目的没留下，后面的人就沿着新说法一路做下去⁠3。群里全是细节讨论、事后记不下产出，机制上很相似：只记录了“要改什么”，没记录“为什么改、改到什么程度算完”。他主张在发起任务时就把上下文和要求交代清楚，理由也随之留下来⁠3。对风控这类高频小改动，可行的做法是让发起人用一两句话带上三样东西：这次要防住的具体情形、改完怎么验证、谁来验收。做不到这三样的，就先不进入你的队列，而是回到发起人那里补。

立正讲人机分工时给过一个顺序：能用明确规则判断的，先写成程序筛掉；规则不够用的，才交给人或 AI 判断；最终拍板留给人⁠4。这个思路可以迁移到你的协作流：格式、字段、明显重复的小问题，让脚本或模板先接住；真正需要你判断的，才进你的待办。他还强调，AI 或程序的任务是减少人要看的东西，并把最值得人看的排在前面⁠4。所以你可以要求群里的小问题先进一个统一的收集处，由发起人标出影响面和紧急度，你按这个顺序处理，而不是按谁 At 得响。