人机协作的分工边界：AI 时代的任务分类与质量门禁

人机协作的分工边界：AI 时代的任务分类与质量门禁的重点在于把前置条件、操作顺序和容易误判的地方分清楚。

人机协作的分工边界：AI 时代的任务分类与质量门禁

一、全交与全写之间：人机协作的分工失焦

AI 编程助手普及后，协作走出了两个极端。一端是全交给 AI 生成，人只做粘贴。代码跑通就算完事，质量与可维护性无人把关。另一端是全自己写，AI 只当搜索框用。

效率没提升，还觉得工具不可靠。两端都失败，根子在分工失焦。没有把任务按属性拆开，再决定哪部分交给 AI。创造性工作和重复性工作用同一套方式对待，必然失衡。

人机协作的关键，不是"AI 能做多少"，而是"哪些该人做、哪些该机做、哪些该一起做"。本文讨论任务分类、协作模式，以及配套的质量门禁。

二、任务属性与协作模式：创造性/重复性/验证性的切分

协作的起点是任务分类。按属性把任务分成三类，每类对应不同的协作模式。创造性任务。架构设计、算法选型、接口契约、领域建模。

上下文依赖深，错误代价大，需要人的判断。这类任务人主导，AI 辅助探索。重复性任务。样板代码、格式转换、错误处理骨架、日志埋点。

模式固定，规则清晰，错误易发现。这类任务 AI 主导，人只验收。验证性任务。测试用例生成、代码审查、文档校对、依赖升级排查。

需要对照规范与历史模式核对。这类任务人机协同，AI 提议，人裁决。三类任务对应三种协作模式。pair 模式：人写主体，AI 补全细节，适合创造性。

review 模式：AI 生成草稿，人逐项审，适合重复性。delegate 模式：AI 全做，人设门禁验收，适合验证性。质量门禁决定哪种模式都安全。

flowchart LRA[任务输入] --> B{属性判定}B -->|创造性| C[pair: 人主导 AI 补全]B -->|重复性| D[review: AI 生成 人审查]B -->|验证性| E[delegate: AI 全做 人验收]C --> F[门禁: 测试+人审]D --> FE --> FF -->|不通过| G[回退到人主导]F -->|通过| H[合并]style F fill:#fff3e0style G fill:#ffebeestyle H fill:#e8f5e9

门禁不是可选配件，是 delegate 模式能用的前提。没有自动化测试与审查的代码，delegate 出去就是裸奔。

三、任务分类与分配决策模型

下面用 Python 实现一个任务分类器。它根据任务特征打分，输出建议分配模式与所需门禁。特征包括重复度、上下文依赖、错误代价、可验证性。

from dataclasses import dataclassfrom typing import Literal@dataclassclass TaskProfile:"""任务画像：用可量化特征描述待分配的任务。为什么用数值特征而非关键词：特征可加权可比较，便于在团队内统一判定标准，减少主观摇摆。"""name: strrepetition: float # 重复度 0-1，越高越像样板context_dep: float# 上下文依赖 0-1，越高越需领域知识error_cost: float # 错误代价 0-1，越高越致命verifiable: float # 可验证性 0-1，越高越能自动化检验has_tests: bool # 是否已有回归测试@dataclassclass Assignment:"""分配决策：模式、门禁、回退条件。"""task: strmode: Literal["pair", "review", "delegate"]needs_human_review: boolneeds_auto_test: boolfallback_reason: str = ""class TaskRouter:"""任务分配路由：把画像映射到协作模式与门禁。为什么用阈值而非机器学习：协作模式需要可解释。团队要能讨论"为什么这条是 delegate"，黑盒模型说不清。"""# 阈值集中管理，便于团队调参与复盘REPETITION_HIGH = 0.6CONTEXT_HIGH = 0.6ERROR_HIGH = 0.7VERIFY_HIGH = 0.7def route(self, t: TaskProfile) -> Assignment:"""根据画像输出分配决策与门禁要求。"""# 高错误代价 + 高上下文依赖，强制人主导，不可委托if t.error_cost >= self.ERROR_HIGH and t.context_dep >= self.CONTEXT_HIGH:return Assignment(task=t.name, mode="pair",needs_human_review=True, needs_auto_test=True,fallback_reason="错误代价与上下文依赖双高，禁止委托",)# 高重复 + 高可验证 + 有测试，可委托但仍要人验收if (t.repetition >= self.REPETITION_HIGHand t.verifiable >= self.VERIFY_HIGHand t.has_tests):return Assignment(task=t.name, mode="delegate",needs_human_review=True, needs_auto_test=True,fallback_reason="重复且可验证，AI 全做，人验收门禁",)# 高重复但不可验证，退回 review 模式，人必须逐项审if t.repetition >= self.REPETITION_HIGH and not t.has_tests:return Assignment(task=t.name, mode="review",needs_human_review=True, needs_auto_test=False,fallback_reason="缺测试基线，无法自动验收，人审兜底",)# 默认走 pair，保守优先return Assignment(task=t.name, mode="pair",needs_human_review=True, needs_auto_test=True,fallback_reason="特征不明确，人主导 AI 辅助",)def gate_check(assignment: Assignment, test_passed: bool, human_approved: bool) -> tuple[bool, str]:"""质量门禁：按分配决策校验放行条件。返回 (是否通过, 原因)。任何门禁缺失都阻断合并。为什么把门禁独立成函数：决策与校验分离，便于在不同环节（本地/CI/评审）复用同一套规则。"""if assignment.needs_auto_test and not test_passed:return False, "要求自动测试通过，但未通过或未运行"if assignment.needs_human_review and not human_approved:return False, "要求人工审查，但未获批准"return True, "门禁通过"if __name__ == "__main__":router = TaskRouter()# 重复性任务：格式转换，有测试t1 = TaskProfile("CSV 转 JSON", repetition=0.9, context_dep=0.2, error_cost=0.3, verifiable=0.8, has_tests=True)a1 = router.route(t1)print(f"{a1.task}: {a1.mode} / {a1.fallback_reason}")# 创造性任务：架构设计t2 = TaskProfile("支付网关架构", repetition=0.1, context_dep=0.9, error_cost=0.9, verifiable=0.3, has_tests=False)a2 = router.route(t2)print(f"{a2.task}: {a2.mode} / {a2.fallback_reason}")# 门禁校验ok, reason = gate_check(a1, test_passed=True, human_approved=True)print(f"门禁: {ok} / {reason}")

生产系统会把画像特征从历史任务中自动提取。重复度从相似 diff 比例算，错误代价从故障复盘标注算。让阈值随团队成熟度演进，而非一成不变。

四、分工的灰区：信任校准与质量回退风险

分工模型给出建议，但灰区始终存在。

分类主观。同一个任务，资深者看作重复性，新人看作创造性。画像特征依赖标注，标注本身有偏差。阈值要按团队实际校准，不能照搬。

AI 能力边界在移动。今天属创造性的任务，半年后可能变重复性。模型升级、上下文窗口扩大，会让 delegate 边界扩张。分类器要定期重训，否则建议会滞后。

delegate 模式风险最高。AI 全做，人只验收。一旦门禁松动，低质代码长驱直入。验收必须随机抽样深审，不能只看测试绿。

技能退化。长期 delegate 重复性任务，工程师失去底层手感。遇到创造性任务时，连判断标准都模糊了。要保留"手动练习"配额，刻意维持手感。

适用边界。这套分工适合有测试基线、有 review 文化的团队。没有测试、没人审的团队，delegate 就是放任。一个常被忽视的点是"AI 决策链的审计"。

delegate 模式下，AI 为什么这么改、改了哪些文件、依据什么规则，都要留可追溯的日志，出问题时才能复盘是规则错还是执行错。另一个实践要点是"建立 AI 产出的回归基线"：对 AI 高频生成的模块，维护一套黄金用例与性能基线，每次生成自动比对，发现偏离立即告警，而非等到线上故障。最后，团队要定期做"信任校准"复盘，回顾最近 N 次 delegate 任务的实际返工率，若返工率上升，说明边界划得过宽，应回退到 review 模式，用数据驱动边界调整而非凭感觉。

五、总结

人机协作不是全交或全写，而是按任务属性分工。机制上分创造性、重复性、验证性三类，对应 pair、review、delegate 三种模式。工程上用质量门禁兜底，让每种模式都有可验证的放行条件。落地路线：先做任务画像与分类阈值；再为重复性任务接 review 模式；测试基线成熟后开放 delegate；最后用返工率数据持续校准边界。AI 能代劳，但门禁要焊死。