返回首页

对比阅读

对比阅读:AI Does the Triage, Humans Make the Final Call — How AI Should Land 与 AI 干分诊脏活,人做最后拍板 — 这才是 AI 落地该有的姿势

AEN
GitHubDeepSeekLanyun·

AI Does the Triage, Humans Make the Final Call — How AI Should Land

What this is

This week, a developer tested an AI triage assistant against a real VS Code Issue (#339955) — the AI independently produced accurate classifications, but the project's design principles deliberately left a safeguard: AI doesn't make the final call for maintainers.The triage assistant does four things: reads Issue content, classifies the issue type (Bug, Feature Request, Inquiry, etc.), suggests priority and labels, and drafts a reply. The model runs DeepSeek-V3.2 on the Lanyun YuanShengDai MaaS platform, accessed via an OpenAI-compatible API.The MCP referenced in the test is a protocol that lets AI models invoke local tools. The Issue describes an MCP service disappearing from the workspace after a user upgrade — the AI independently pinpointed the root cause.

Industry view

We've noticed that this 'AI first-pass triage + human final decision' division of labor is becoming a de facto standard across multiple domains. Support tickets, bug reports, internal approvals — all isomorphic scenarios: high information volume but each item is easy, requiring classification before handling. AI eats 80% of the repetitive work; humans focus on the 20% that requires judgment.But there are dissenting views. Members of the developer community point out: for ambiguous or contested Issues, AI tends to produce 'plausible-sounding but off-target' recommendations, which actually increases review overhead; when Issue descriptions are incomplete, AI's priority judgment may misalign with project strategy — priority is about resource trade-offs, not technical analysis.The more pragmatic view: the value of these tools isn't how smart the AI is, but compressing 'read 100 Issues' into 'read 20 AI summaries'. What gets saved is time, not judgment.

Impact on regular people

For traditional enterprise IT: this is a template for AI adoption — not replacing any role, but consuming the most time-consuming triage step in the workflow, lightening the load for downstream human work.For individual careers: your future workflow will very likely include a step where 'the AI assistant goes through it first'. It won't make the call for you, but it'll pull you out of the manual grind of 'read 100 then decide'.For the consumer market: similar 'AI triage' will permeate customer service, food delivery complaints, e-commerce after-sales. Consumers will encounter AI first, then humans — this is already happening.
来源: juejin.cn
BZH
GitHubDeepSeek蓝耘·

AI 干分诊脏活,人做最后拍板 — 这才是 AI 落地该有的姿势

这是什么

本周一位开发者用真实 VS Code Issue(编号 339955)测试了一个 AI 分诊助手 — AI 独立给出了准确归类,但项目设计原则刻意留了一道防线:AI 不替维护者做最终决定。 这个分诊助手做四件事:读取 Issue 内容、判断问题类型(Bug、功能请求、咨询等)、给出优先级和标签建议、起草回复。模型用的是蓝耘元生代 MaaS 平台上的 DeepSeek-V3.2,通过 OpenAI 兼容接口接入。 测试中涉及的 MCP 是一类让 AI 模型调用本地工具的协议。Issue 描述的是用户升级后 MCP 服务从工作区消失 — AI 独立定位到了根因。

行业怎么看

我们注意到,这种「AI 第一轮分诊 + 人最终决策」的分工,正在多个领域成为事实标准。客服工单、Bug 报告、内部审批 — 都是同构场景:信息量大但单条不难,需要先归类再处理。AI 吃掉 80% 的重复劳动,人聚焦 20% 的判断。 但也有反对意见。开发者社区里有人指出:对于信息模糊或带争议的 Issue,AI 容易给出「看起来合理但答非所问」的建议,反而增加审核成本;当 Issue 描述不完整时,AI 的优先级判断可能与项目战略错位 — 优先级背后是资源取舍,不是技术分析。 更务实的看法是:这类工具的价值不在于 AI 有多聪明,而在于把「读 100 条 Issue」压缩成「读 20 条 AI 摘要」。省的是时间,不是判断。

对普通人的影响

对传统企业 IT:这是 AI 落地的一个范本 — 不是替代某个岗位,而是吃掉流程里最耗时的分诊环节,为后续人工作业减负。 对个人职场:未来你的工作流大概率会出现「AI 助手先过一遍」这步。它不替你拍板,但会把你从「先看 100 条再决定」的体力活里拉出来。 对消费市场:类似的「AI 分诊」会渗透到客服、外卖投诉、电商售后。消费者会先遇到 AI,再遇到人 — 这件事已经在发生。
来源: juejin.cn