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

人机协作的分工边界AI 时代的任务分类与质量门禁一、全交与全写之间人机协作的分工失焦AI 编程助手普及后协作走出了两个极端。一端是全交给 AI 生成人只做粘贴。代码跑通就算完事质量与可维护性无人把关。另一端是全自己写AI 只当搜索框用。效率没提升还觉得工具不可靠。两端都失败根子在分工失焦。没有把任务按属性拆开再决定哪部分交给 AI。创造性工作和重复性工作用同一套方式对待必然失衡。人机协作的关键不是AI 能做多少而是哪些该人做、哪些该机做、哪些该一起做。本文讨论任务分类、协作模式以及配套的质量门禁。二、任务属性与协作模式创造性/重复性/验证性的切分协作的起点是任务分类。按属性把任务分成三类每类对应不同的协作模式。创造性任务。架构设计、算法选型、接口契约、领域建模。上下文依赖深错误代价大需要人的判断。这类任务人主导AI 辅助探索。重复性任务。样板代码、格式转换、错误处理骨架、日志埋点。模式固定规则清晰错误易发现。这类任务 AI 主导人只验收。验证性任务。测试用例生成、代码审查、文档校对、依赖升级排查。需要对照规范与历史模式核对。这类任务人机协同AI 提议人裁决。三类任务对应三种协作模式。pair 模式人写主体AI 补全细节适合创造性。review 模式AI 生成草稿人逐项审适合重复性。delegate 模式AI 全做人设门禁验收适合验证性。质量门禁决定哪种模式都安全。flowchart LR A[任务输入] -- B{属性判定} B --|创造性| C[pair: 人主导 AI 补全] B --|重复性| D[review: AI 生成 人审查] B --|验证性| E[delegate: AI 全做 人验收] C -- F[门禁: 测试人审] D -- F E -- F F --|不通过| G[回退到人主导] F --|通过| H[合并] style F fill:#fff3e0 style G fill:#ffebee style H fill:#e8f5e9门禁不是可选配件是 delegate 模式能用的前提。没有自动化测试与审查的代码delegate 出去就是裸奔。三、任务分类与分配决策模型下面用 Python 实现一个任务分类器。它根据任务特征打分输出建议分配模式与所需门禁。特征包括重复度、上下文依赖、错误代价、可验证性。from dataclasses import dataclass from typing import Literal dataclass class TaskProfile: 任务画像用可量化特征描述待分配的任务。 为什么用数值特征而非关键词特征可加权可比较 便于在团队内统一判定标准减少主观摇摆。 name: str repetition: float # 重复度 0-1越高越像样板 context_dep: float # 上下文依赖 0-1越高越需领域知识 error_cost: float # 错误代价 0-1越高越致命 verifiable: float # 可验证性 0-1越高越能自动化检验 has_tests: bool # 是否已有回归测试 dataclass class Assignment: 分配决策模式、门禁、回退条件。 task: str mode: Literal[pair, review, delegate] needs_human_review: bool needs_auto_test: bool fallback_reason: str class TaskRouter: 任务分配路由把画像映射到协作模式与门禁。 为什么用阈值而非机器学习协作模式需要可解释。 团队要能讨论为什么这条是 delegate黑盒模型说不清。 # 阈值集中管理便于团队调参与复盘 REPETITION_HIGH 0.6 CONTEXT_HIGH 0.6 ERROR_HIGH 0.7 VERIFY_HIGH 0.7 def route(self, t: TaskProfile) - Assignment: 根据画像输出分配决策与门禁要求。 # 高错误代价 高上下文依赖强制人主导不可委托 if t.error_cost self.ERROR_HIGH and t.context_dep self.CONTEXT_HIGH: return Assignment( taskt.name, modepair, needs_human_reviewTrue, needs_auto_testTrue, fallback_reason错误代价与上下文依赖双高禁止委托, ) # 高重复 高可验证 有测试可委托但仍要人验收 if (t.repetition self.REPETITION_HIGH and t.verifiable self.VERIFY_HIGH and t.has_tests): return Assignment( taskt.name, modedelegate, needs_human_reviewTrue, needs_auto_testTrue, fallback_reason重复且可验证AI 全做人验收门禁, ) # 高重复但不可验证退回 review 模式人必须逐项审 if t.repetition self.REPETITION_HIGH and not t.has_tests: return Assignment( taskt.name, modereview, needs_human_reviewTrue, needs_auto_testFalse, fallback_reason缺测试基线无法自动验收人审兜底, ) # 默认走 pair保守优先 return Assignment( taskt.name, modepair, needs_human_reviewTrue, needs_auto_testTrue, 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, repetition0.9, context_dep0.2, error_cost0.3, verifiable0.8, has_testsTrue) a1 router.route(t1) print(f{a1.task}: {a1.mode} / {a1.fallback_reason}) # 创造性任务架构设计 t2 TaskProfile(支付网关架构, repetition0.1, context_dep0.9, error_cost0.9, verifiable0.3, has_testsFalse) a2 router.route(t2) print(f{a2.task}: {a2.mode} / {a2.fallback_reason}) # 门禁校验 ok, reason gate_check(a1, test_passedTrue, human_approvedTrue) 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 能代劳但门禁要焊死。