AI 时代的人类定位不是一句职业焦虑而是一个每天都要做的工程决策。做 AI 应用时模型负责生成文本、代码、图片和推理结果人负责定义生成边界、设计协作流程并裁决结果是否可用。这篇文章不讨论抽象的哲学命题而是把“人类定位”拆成能力边界、协作流程、评估体系、排查路径四个可落地的模块。读完以后你可以拿着这套方法去梳理自己项目里的模型能力清单设计人机协作流程并建立一套属于团队的验证机制。下面从工程角度展开。这里的“定位”不是静态的岗位描述而是你在 AI 应用系统中的分工节点。你在这个节点上是定义需求、控制质量、处理失败分支还是只是把提示词发给模型再把结果转发出去决定了你能不能从“辅助工具使用者”变成“AI 应用工程化的人”。1. 先想清楚大模型时代人类到底在交付什么1.1 模型是“能力组件”不是“人员替代”很多团队引入大模型的第一反应是“能不能让模型把某类工作全部自动化”。这个思路本身没有错但落地时会发现模型输出存在一定的随机性、幻觉和数据时效问题。你无法像调用普通函数那样保证返回值一定符合预期。因此更稳妥的理解是大模型是一个能力组件它擅长把输入转换为看似合理的输出但不保证输出正确、完整、符合业务约束。把这个概念放到你当前项目里就意味着你要为模型输出增加一层“工程保障”。比如模型生成 SQL 后要校验字段是否存在模型生成一段文案后要检查是否出现禁用词模型生成代码后要跑测试和静态检查。这些保障工作不是模型能自觉完成的而是人类定位的起点。一个容易误解的地方是不是说人类要重新做一遍模型做的工作而是人类要把“定义输出标准、校验中间结果、处理异常分支”变成工作流的一部分。1.2 三层定位方向、校对、裁决如果在 AI 应用系统里把自己看成一个节点这个节点通常承担三种职责方向定义决定“这个模型要解决什么问题”“输入来源在哪里”“输出给谁用”。结果校对检查模型输出是否符合语法、结构、事实和业务规则。最终裁决当模型输出不确定或冲突时判断是否可以放行还是打回重写。这三个职责不是集中在一个人身上而是分散在团队不同角色里。产品经理定义方向开发者实现校验逻辑测试人员建立回归集技术负责人做最终风险决策。即使你是一个人开发独立应用也需要在流程里显式区分这三个环节否则很容易出现“模型说什么就信什么”的问题。1.3 一张分工表先对齐团队共识环节模型职责人类职责典型产物需求拆分辅助归纳、生成初稿确认业务目标和验收标准功能需求卡内容生成生成文案、代码、摘要定义提示词、提供上下文提示词版本记录结果校验输出原始结果检查语法、事实、合规校验日志失败处理给出替代生成结果判断是否重试、降级或人工介入异常处理策略持续优化根据反馈调整输出清洗数据、标注错误、更新评估集评估报告这张表不建议直接照搬而是要你把自己项目的真实环节填进去。填完之后你就会发现模型在大多数环节只是“生成候选”人类真正交付的是“可用的、被验证过的结果”。明确了这一点AI 时代的人类定位就不会滑向两个极端要么全盘信任模型要么全盘否定模型。2. 用“能力边界实验”建立模型的可靠与不可靠地图2.1 为什么要手动测量而不是凭印象模型能力在不同任务上的表现差异很大。同一个模型写 Python 代码可能很稳定但写一份包含特定行业规则的合同摘要就可能频繁出错。如果你只看演示效果很容易过度乐观如果你只看一两次失败又容易过度悲观。正确做法是设计一组小实验用自己的业务样本去测试模型得到一张“能力边界清单”。这张清单的价值在于它能告诉你哪些任务可以交给模型批量完成。哪些任务需要强制人工审核。哪些任务在当前模型能力下不适合上线。哪些任务需要补充外部知识库或规则引擎才能用。有了边界清单人类定位就从“凭感觉分工”变成了“按证据分工”。2.2 最小能力边界实验输入、输出、记录一次能力实验不需要复杂系统。准备若干条代表性输入统一调用模型记录输出然后人工判断每条输出的正确性、完整性和风险等级。最后汇总成表格。实验样本要覆盖三类情况常规样本业务里最常见的输入。边界样本空输入、超长输入、格式错误输入。高风险样本涉及数字、金额、法律、安全、用户隐私的内容。对每个样本记录以下信息字段示例说明任务编号T001唯一标识输入“请为这个商品写一段标题”实际请求输出片段“高颜值无线耳机”模型返回结果是否正确是/否人工判断错误类型事实错误/语法错误/遗漏约束归类风险等级高/中/低影响程度人工处理方式修正/重写/丢弃落地操作2.3 实验脚本的设计要点与示例在工程上你可以写一个最小脚本批量记录模型输出。下面示例用于说明思路具体模型接口、密钥和参数要根据实际情况调整。import json import time def call_model(prompt: str) - str: 调用模型接口。实际项目中请替换为 SDK 或 HTTP 调用。 这里只给出函数签名方便后续扩展。 # 示例实现请按实际环境补全 # response your_sdk.chat.completions.create(...) # return response.choices[0].message.content raise NotImplementedError def run_experiment(samples): results [] for i, sample in enumerate(samples): start time.time() output call_model(sample[prompt]) latency_ms (time.time() - start) * 1000 results.append({ case_id: sample[case_id], input: sample[prompt], output: output, latency_ms: round(latency_ms, 2), status: pending_manual_check }) print(f[{i 1}/{len(samples)}] {sample[case_id]} done) return results if __name__ __main__: samples [ {case_id: normal_001, prompt: 用一句话概括今天天气}, {case_id: edge_001, prompt: }, {case_id: risk_001, prompt: 把这段合同摘要整理成三条要点} ] results run_experiment(samples) with open(experiment_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)脚本运行后把experiment_results.json交给人工标注再把标注结果整理成边界清单。这里要注意不要用一个样本就下结论。每个任务类型至少测试 5 到 10 条样本分布越接近真实请求越好。2.4 用边界清单决定人在哪里介入假设测试结果如下任务类型正确率主要错误上线建议商品标题生成92%偶尔夸大功效可辅助生成需合规审核SQL 生成68%字段名错误、漏条件需要自动校验和人工复核合同摘要45%忽略关键日期暂时不建议直接上线代码补全85%边界条件缺失需要配合单测和静态检查这张表直接决定了你在系统里要设计哪些检查点。SQL 生成正确率只有 68%就不能做“一键执行”必须有一个校验层把 SQL 解析成 AST核对表和字段是否存在再交给人工确认。合同摘要正确率低那就只能做“草稿生成”必须强制人工审核。这个过程就是“人类定位”的落地不是笼统地说“人要负责把关”而是具体到“在哪个任务、哪个环节、用哪种方式把关”。3. 把“人类定位”落成人机协作流程3.1 需求到输出的三段式任务定义、模型执行、人工验收很多失败的 AI 项目问题出在流程太短。用户输入一句话模型直接返回一个回答中间没有任何任务定义和验收动作。这种流程适合聊天玩具不适合生产系统。生产环境建议采用三段式流程任务定义把用户需求转换成模型可执行的提示词模板补充必要的约束、示例和输出格式。模型执行调用模型生成候选结果必要时进行二次生成或并行生成。人工验收由人或自动化规则决定结果是否通过未通过的进入修正流程。三段式的核心是“验收条件前置”。不要等模型输出完才想“这结果行不行”而是在任务定义阶段就写清楚字段格式是什么、禁止出现什么词、信息来源有哪些、输出长度范围是多少。3.2 提示词工程的核心是“验收条件前置”提示词不是越复杂越好。更有效的方式是把验收条件写进提示词并在代码里做结构化解析。比如你是电商运营助手。请根据商品信息生成 30 字以内的标题。 要求 1. 标题中必须包含商品名称。 2. 不能出现“第一”“最”“绝对”等夸大词。 3. 输出 JSON 格式{title: 生成的标题}这里的关键不是让模型“努力遵守规则”而是给后续校验提供稳定结构。输出 JSON 后代码可以直接解析字段检查长度和禁用词。如果模型返回的不是 JSON就直接判断为失败进入重试或人工处理。提示词的版本管理也很重要。建议把每条提示词保存为一个独立文件并记录版本号和测试结果。不要只存在聊天记录里。version: 1.3.0 task_type: ecommerce_title prompt: | 你是电商运营助手。请根据商品信息生成 30 字以内的标题。 ... validation: max_length: 30 forbidden_words: - 第一 - 最 - 绝对 output_format: json3.3 引入 Agent 时的三个控制点当你开始使用 Agent 时模型会调用工具、读取数据、执行多步任务。这时“人类定位”要更提前。建议在 Agent 流程里设置三个控制点权限控制Agent 能调用哪些工具、读取哪些数据、不能执行哪些操作。进度控制每一步是否允许自动执行还是需要人工确认后才能进入下一步。终止控制设置最大步数、超时时间、失败重试次数防止 Agent 无限循环。这三个控制点不是限制 AI 能力而是把不确定性控制在业务允许的范围内。例如让 Agent 自动写邮件草稿可以但点击发送之前必须有人工确认让 Agent 生成营销文案可以但发布到线上平台必须走审批。3.4 用状态机控制协作流程在代码层面可以用一个简单状态机来管理协作流程。from enum import Enum class TaskState(Enum): DRAFT draft GENERATED generated REVIEWING reviewing APPROVED approved REJECTED rejected FALLBACK fallback class HumanAITask: def __init__(self): self.state TaskState.DRAFT self.output None self.review_result None def run_model(self, generator): if self.state ! TaskState.DRAFT: raise RuntimeError(task is not in draft state) self.output generator(self.prompt) self.state TaskState.GENERATED def submit_for_review(self): if self.state ! TaskState.GENERATED: raise RuntimeError(task is not generated) self.state TaskState.REVIEWING def approve(self): if self.state ! TaskState.REVIEWING: raise RuntimeError(task is not under review) self.state TaskState.APPROVED self.review_result approved def reject(self): if self.state ! TaskState.REVIEWING: raise RuntimeError(task is not under review) self.state TaskState.REJECTED self.review_result rejected这段代码的核心是让状态流转变得可追踪。状态机的价值不在于复杂而在于当流程出问题时你能明确知道卡在哪一环是模型还没生成还是人工审核超时还是被自动拒绝。3.5 各环节职责速查表流程环节模型输出人类输出失败分支任务定义提示词模板业务目标与验收标准需求不明确时退回补充结果生成候选文本/代码/JSON选择是否采纳结构错误时重试自动校验解析后的结构化结果校验规则配置规则不通过时标记失败人工审核审核辅助信息批准或打回打回后进入修正队列发布上线生成终稿发布决策不符合风险要求时停止这张表可以直接作为团队协作文档的骨架。每个环节都要有明确负责人不能出现“模型生成的不知道谁负责”的模糊状态。4. 没有评估体系定位就是一句空话4.1 从“感觉还行”到“可量化可回归”如果“人工判断模型输出好坏”只是停留在主观感觉那么你无法知道一次提示词修改到底是变好了还是变坏了。这也是很多人觉得 AI 项目不稳定、难以推进的原因。要建立人类定位的工程价值必须把评估行为体系化。评估体系的起点不是指标而是回归集。回归集是一组带标准答案的输入输出样例。每次修改提示词、更换模型、调整参数时都要在回归集上重新跑一遍对比结果变化。4.2 建立最小回归集回归集不需要很大但要覆盖常见场景和风险场景。[ { case_id: title_001, task_type: ecommerce_title, input: {name: 无线蓝牙耳机, features: 降噪续航30小时}, expected: 包含商品名称不超过30字不含夸大词, risk: high }, { case_id: sql_001, task_type: sql_generation, input: 查询最近7天订单金额大于1000的用户, expected: SQL包含订单表、金额条件和时间范围, risk: high }, { case_id: summary_001, task_type: text_summary, input: 一段200字的新闻, expected: 摘要包含核心事实、时间、地点, risk: medium } ]实际项目中回归集要由业务人员和开发人员一起维护。标准答案不一定要完整文本可以是“必须包含的关键信息”列表。4.3 自动化评估脚本示例下面是一个最小评估脚本。它不依赖大模型只负责对比模型输出和预设规则这对早期回归已经够用。后续可以引入更复杂的语义相似度但基础规则先要落地。import json def check_length(text, max_length): return len(text) max_length def check_forbidden_words(text, forbidden_words): found [word for word in forbidden_words if word in text] return found def evaluate_case(case, model_output): checks {} if case[task_type] ecommerce_title: checks[length_ok] check_length(model_output, 30) forbidden check_forbidden_words(model_output, [第一, 最, 绝对]) checks[forbidden_words] forbidden checks[has_name] case[input][name] in model_output elif case[task_type] sql_generation: checks[has_from] from in model_output.lower() checks[has_where] where in model_output.lower() elif case[task_type] text_summary: checks[has_time] 2025 in model_output or 今天 in model_output passed all( value is True or value [] for value in checks.values() ) return {case_id: case[case_id], passed: passed, checks: checks} if __name__ __main__: with open(regression_set.json, encodingutf-8) as f: cases json.load(f) fake_outputs { title_001: 超强降噪无线蓝牙耳机绝对是最好的选择, sql_001: select user_id from orders where amount 1000, summary_001: 今天下午发生一起事件 } for case in cases: result evaluate_case(case, fake_outputs[case[case_id]]) print(result)这个脚本的优点是简单、透明、易于解释。缺点是无法判断语义是否合理所以它只能承担“硬性规则检查”真正的语义判断仍然需要人参与。4.4 评估指标与人工判断的分工评估维度工具人类是否介入示例格式JSON Schema、正则否输出是否为合法 JSON长度代码计数否标题是否超过30字禁用词词表匹配否是否含有“最”事实一致性人工核对资料是摘要是否遗漏关键日期安全合规人工复核是是否包含高风险表述用户价值小范围试用是文案是否能提升点击率人工判断要集中在模型最容易出错、成本影响最大的地方。不要浪费人力去逐字检查所有输出而是通过规则把明显不合格的过滤掉再把真正有风险的候选交给人。5. 常见定位错误与排查路径5.1 把模型输出当成事实现象系统直接展示模型生成的合同摘要结果漏掉了解除条款导致用户误解。原因没有为高风险任务设置“事实校验”环节只依赖模型生成。检查方式查看该任务的提示词和输出是否存在校验步骤回看回归集中高风险样本的通过情况。处理方案为高风险任务增加外部知识源或规则库强制人工审核在界面上标注“AI 生成内容仅供参考”。这类问题的预防方法是在任务定义阶段就判断风险等级。高风险任务默认加一道人工审核闸门而不是上线后发现问题再补。5.2 提示词堆叠掩盖了流程缺陷现象模型输出总是不稳定于是不断往提示词里加“你必须”“你千万不能”“如果错了就重写”。原因把模型当成了可以通过命令完全控制的执行器忽略了失败分支和校验逻辑。检查方式查看提示词长度和维护成本观察失败输出是否集中在固定错误类型。处理方案把提示词里的约束提取成代码里的校验规则让失败输出进入结构化纠错流程。不要用延长提示词的方式掩盖设计缺陷。5.3 用 AI 编程却没有代码审查现象开发者用 AI 生成大量代码提交后不审查也不跑测试导致线上故障。原因把“AI 编程”理解成“让 AI 自己写完整功能”放弃了自己作为开发者的核心职责。实际上 AI 编程更准确的定位是“快速生成候选代码”代码审查、测试和上线决策仍然必须由人来完成。检查方式查看最近提交的代码是否有 AI 生成痕迹是否都有对应测试查看故障记录中是否有未经审查直接上线的案例。处理方案建立强制代码审查规范AI 生成的代码必须经过人工 review并且要跑单测和静态检查。不要让 AI 生成代码绕过现有工程流程。5.4 定位偏移排查清单现象可能原因检查方式处理建议结果经常不可用没有边界清单回看能力实验记录建立回归集并做边界测试人工审核成本过高输入任务定义不清晰检查提示词验收条件把约束拆成自动化校验规则模型输出偶发风险缺少高风险样本测试检查实验样本分布增加高风险样本和强制人工审核修改提示词后效果倒退没有版本管理和回归集检查提示词版本记录每次修改都运行回归评估流程卡住无法继续状态机缺少失败处理查看任务状态流转日志增加超时、重试和人工介入分支排查时按输入、路径、配置、权限、日志的顺序走。先看这次请求的输入是否合法再看模型调用参数是否正确然后检查校验规则是否命中最后看日志里有没有异常记录。大多数定位问题不是模型不行而是流程里缺少可观测的环节。6. 不同岗位的定位清单与自检方法6.1 开发从生产者转向编排者开发者的核心定位从“亲手写每一行代码”转向“组装模型、工具、数据和校验规则”。你需要掌握模型接口的调用方式和参数含义。把输出解析成结构化数据的方法。为模型输出配置缓存、降级和重试策略。建立本地评估脚本快速验证模型改动的影响。自检问题如果模型接口不可用我的系统会优雅降级吗如果模型输出非法格式我的代码会抛出明确异常还是直接崩溃6.2 测试从手工用例转向评估集与幻觉检测测试人员的定位不再只是执行用例而是建立“模型行为评估集”。需要关注识别高风险输入类别并补充回归集。设计恶意输入、空输入、超长输入等边界场景。分析错误结果区分是模型幻觉、提示词缺陷还是规则缺失。配合开发人员建立自动化评估流水线。自检问题当提示词版本升级时回归集能否自动运行错误分类是否覆盖事实错误、格式错误和约束遗漏6.3 产品与技术管理定义指标和止损线产品和技术管理者的定位是设定“什么能上线什么不能上线”的标准。需要定义核心任务的正确率目标。人工审核的最大比例和成本预算。模型失败时的降级体验。出现严重错误时的回滚方案。自检问题团队是否清楚每个 AI 功能的最低正确率阈值当模型效果不达标时是否有一个明确的回退到规则引擎或人工处理的预案6.4 可复用自检表检查项是/否备注是否对模型能力做过边界实验记录样本数量和主要错误类型是否维护提示词版本每次修改有记录是否建立了回归集至少覆盖常规、边界、高风险三类样本是否存在自动化校验规则格式、长度、禁用词等高风险任务是否有强制人工审核不能只靠模型自觉是否有失败分支和降级方案模型不可用时系统能继续运行是否有评估结果可视化不要求复杂但要能看到趋势这张表建议每两周做一次自检。不是为了考核而是为了防止项目往“看起来能用实际上没人负责”的方向滑落。7. 沉淀与扩展把个人定位文档变成团队知识库7.1 分工说明卡片当团队开始协作时光靠文章和口头说明不够。建议为每个 AI 功能制作一张“分工说明卡片”内容包含任务名称、模型职责、人类职责、自动校验规则、失败处理方式和评估指标。这种卡片比冗长的文档更容易维护。7.2 模板示例feature: 商品标题生成 task_type: ecommerce_title model: gpt-4o-mini prompt_version: 1.3.0 human_responsible: - 审核夸大词 - 确认商品卖点是否准确 - 决定是否发布 model_responsible: - 生成候选标题 - 保证输出 JSON 格式 auto_validation: - max_length: 30 - forbidden_words: [第一, 最, 绝对] failure_handling: - on_json_error: retry - on_forbidden_word: send_to_review - max_retries: 2 evaluation_metric: - acceptance_rate - human_review_time这张卡片可以存在项目仓库里也可以放到团队 wiki。关键是每次修改模型或提示词时卡片要同步更新。7.3 与 Spring AI、LangChain 等框架结合在 Java 生态中Spring AI 提供了统一的模型接入方式在 Python 生态中LangChain 和 LlamaIndex 可以简化 Agent 编排。无论使用哪个框架上面的分工原则都适用框架解决的是“模型调用和链式编排”问题但“人在哪个环节介入”仍然要由你设计。例如在 Spring AI 项目里你可以通过Advisor或Filter在模型调用前后增加校验逻辑把规则检查从业务代码中剥离出来。在 LangChain 项目里可以用Tool的权限开关控制 Agent 能执行的操作并在关键节点上暂停等待人工批准。7.4 个人练习建议如果你想在这个领域持续成长建议做三个练习为自己的工作选一个高频任务建立 10 条回归集样例并写一个最小评估脚本。将一个已有的 AI 生成流程加上状态机明确生成、审核、批准、拒绝四个状态。给团队里某个 AI 功能写一份分工说明卡片并邀请同事提意见。这三个练习都会迫使你回答同一个问题模型负责什么人负责什么边界在哪里。不断回答这个问题就是 AI 时代人类定位的真正内容。与其担心被替代不如先确认自己是否已经在模型输出和最终结果之间建立了可控的校验与仲裁机制。如果你还没有那这就是你下一步最值得投入的工程方向。
AI 时代的人类定位不是一句职业焦虑而是一个每天都要做的工程决策。做 AI 应用时模型负责生成文本、代码、图片和推理结果人负责定义生成边界、设计协作流程并裁决结果是否可用。这篇文章不讨论抽象的哲学命题而是把“人类定位”拆成能力边界、协作流程、评估体系、排查路径四个可落地的模块。读完以后你可以拿着这套方法去梳理自己项目里的模型能力清单设计人机协作流程并建立一套属于团队的验证机制。下面从工程角度展开。这里的“定位”不是静态的岗位描述而是你在 AI 应用系统中的分工节点。你在这个节点上是定义需求、控制质量、处理失败分支还是只是把提示词发给模型再把结果转发出去决定了你能不能从“辅助工具使用者”变成“AI 应用工程化的人”。1. 先想清楚大模型时代人类到底在交付什么1.1 模型是“能力组件”不是“人员替代”很多团队引入大模型的第一反应是“能不能让模型把某类工作全部自动化”。这个思路本身没有错但落地时会发现模型输出存在一定的随机性、幻觉和数据时效问题。你无法像调用普通函数那样保证返回值一定符合预期。因此更稳妥的理解是大模型是一个能力组件它擅长把输入转换为看似合理的输出但不保证输出正确、完整、符合业务约束。把这个概念放到你当前项目里就意味着你要为模型输出增加一层“工程保障”。比如模型生成 SQL 后要校验字段是否存在模型生成一段文案后要检查是否出现禁用词模型生成代码后要跑测试和静态检查。这些保障工作不是模型能自觉完成的而是人类定位的起点。一个容易误解的地方是不是说人类要重新做一遍模型做的工作而是人类要把“定义输出标准、校验中间结果、处理异常分支”变成工作流的一部分。1.2 三层定位方向、校对、裁决如果在 AI 应用系统里把自己看成一个节点这个节点通常承担三种职责方向定义决定“这个模型要解决什么问题”“输入来源在哪里”“输出给谁用”。结果校对检查模型输出是否符合语法、结构、事实和业务规则。最终裁决当模型输出不确定或冲突时判断是否可以放行还是打回重写。这三个职责不是集中在一个人身上而是分散在团队不同角色里。产品经理定义方向开发者实现校验逻辑测试人员建立回归集技术负责人做最终风险决策。即使你是一个人开发独立应用也需要在流程里显式区分这三个环节否则很容易出现“模型说什么就信什么”的问题。1.3 一张分工表先对齐团队共识环节模型职责人类职责典型产物需求拆分辅助归纳、生成初稿确认业务目标和验收标准功能需求卡内容生成生成文案、代码、摘要定义提示词、提供上下文提示词版本记录结果校验输出原始结果检查语法、事实、合规校验日志失败处理给出替代生成结果判断是否重试、降级或人工介入异常处理策略持续优化根据反馈调整输出清洗数据、标注错误、更新评估集评估报告这张表不建议直接照搬而是要你把自己项目的真实环节填进去。填完之后你就会发现模型在大多数环节只是“生成候选”人类真正交付的是“可用的、被验证过的结果”。明确了这一点AI 时代的人类定位就不会滑向两个极端要么全盘信任模型要么全盘否定模型。2. 用“能力边界实验”建立模型的可靠与不可靠地图2.1 为什么要手动测量而不是凭印象模型能力在不同任务上的表现差异很大。同一个模型写 Python 代码可能很稳定但写一份包含特定行业规则的合同摘要就可能频繁出错。如果你只看演示效果很容易过度乐观如果你只看一两次失败又容易过度悲观。正确做法是设计一组小实验用自己的业务样本去测试模型得到一张“能力边界清单”。这张清单的价值在于它能告诉你哪些任务可以交给模型批量完成。哪些任务需要强制人工审核。哪些任务在当前模型能力下不适合上线。哪些任务需要补充外部知识库或规则引擎才能用。有了边界清单人类定位就从“凭感觉分工”变成了“按证据分工”。2.2 最小能力边界实验输入、输出、记录一次能力实验不需要复杂系统。准备若干条代表性输入统一调用模型记录输出然后人工判断每条输出的正确性、完整性和风险等级。最后汇总成表格。实验样本要覆盖三类情况常规样本业务里最常见的输入。边界样本空输入、超长输入、格式错误输入。高风险样本涉及数字、金额、法律、安全、用户隐私的内容。对每个样本记录以下信息字段示例说明任务编号T001唯一标识输入“请为这个商品写一段标题”实际请求输出片段“高颜值无线耳机”模型返回结果是否正确是/否人工判断错误类型事实错误/语法错误/遗漏约束归类风险等级高/中/低影响程度人工处理方式修正/重写/丢弃落地操作2.3 实验脚本的设计要点与示例在工程上你可以写一个最小脚本批量记录模型输出。下面示例用于说明思路具体模型接口、密钥和参数要根据实际情况调整。import json import time def call_model(prompt: str) - str: 调用模型接口。实际项目中请替换为 SDK 或 HTTP 调用。 这里只给出函数签名方便后续扩展。 # 示例实现请按实际环境补全 # response your_sdk.chat.completions.create(...) # return response.choices[0].message.content raise NotImplementedError def run_experiment(samples): results [] for i, sample in enumerate(samples): start time.time() output call_model(sample[prompt]) latency_ms (time.time() - start) * 1000 results.append({ case_id: sample[case_id], input: sample[prompt], output: output, latency_ms: round(latency_ms, 2), status: pending_manual_check }) print(f[{i 1}/{len(samples)}] {sample[case_id]} done) return results if __name__ __main__: samples [ {case_id: normal_001, prompt: 用一句话概括今天天气}, {case_id: edge_001, prompt: }, {case_id: risk_001, prompt: 把这段合同摘要整理成三条要点} ] results run_experiment(samples) with open(experiment_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)脚本运行后把experiment_results.json交给人工标注再把标注结果整理成边界清单。这里要注意不要用一个样本就下结论。每个任务类型至少测试 5 到 10 条样本分布越接近真实请求越好。2.4 用边界清单决定人在哪里介入假设测试结果如下任务类型正确率主要错误上线建议商品标题生成92%偶尔夸大功效可辅助生成需合规审核SQL 生成68%字段名错误、漏条件需要自动校验和人工复核合同摘要45%忽略关键日期暂时不建议直接上线代码补全85%边界条件缺失需要配合单测和静态检查这张表直接决定了你在系统里要设计哪些检查点。SQL 生成正确率只有 68%就不能做“一键执行”必须有一个校验层把 SQL 解析成 AST核对表和字段是否存在再交给人工确认。合同摘要正确率低那就只能做“草稿生成”必须强制人工审核。这个过程就是“人类定位”的落地不是笼统地说“人要负责把关”而是具体到“在哪个任务、哪个环节、用哪种方式把关”。3. 把“人类定位”落成人机协作流程3.1 需求到输出的三段式任务定义、模型执行、人工验收很多失败的 AI 项目问题出在流程太短。用户输入一句话模型直接返回一个回答中间没有任何任务定义和验收动作。这种流程适合聊天玩具不适合生产系统。生产环境建议采用三段式流程任务定义把用户需求转换成模型可执行的提示词模板补充必要的约束、示例和输出格式。模型执行调用模型生成候选结果必要时进行二次生成或并行生成。人工验收由人或自动化规则决定结果是否通过未通过的进入修正流程。三段式的核心是“验收条件前置”。不要等模型输出完才想“这结果行不行”而是在任务定义阶段就写清楚字段格式是什么、禁止出现什么词、信息来源有哪些、输出长度范围是多少。3.2 提示词工程的核心是“验收条件前置”提示词不是越复杂越好。更有效的方式是把验收条件写进提示词并在代码里做结构化解析。比如你是电商运营助手。请根据商品信息生成 30 字以内的标题。 要求 1. 标题中必须包含商品名称。 2. 不能出现“第一”“最”“绝对”等夸大词。 3. 输出 JSON 格式{title: 生成的标题}这里的关键不是让模型“努力遵守规则”而是给后续校验提供稳定结构。输出 JSON 后代码可以直接解析字段检查长度和禁用词。如果模型返回的不是 JSON就直接判断为失败进入重试或人工处理。提示词的版本管理也很重要。建议把每条提示词保存为一个独立文件并记录版本号和测试结果。不要只存在聊天记录里。version: 1.3.0 task_type: ecommerce_title prompt: | 你是电商运营助手。请根据商品信息生成 30 字以内的标题。 ... validation: max_length: 30 forbidden_words: - 第一 - 最 - 绝对 output_format: json3.3 引入 Agent 时的三个控制点当你开始使用 Agent 时模型会调用工具、读取数据、执行多步任务。这时“人类定位”要更提前。建议在 Agent 流程里设置三个控制点权限控制Agent 能调用哪些工具、读取哪些数据、不能执行哪些操作。进度控制每一步是否允许自动执行还是需要人工确认后才能进入下一步。终止控制设置最大步数、超时时间、失败重试次数防止 Agent 无限循环。这三个控制点不是限制 AI 能力而是把不确定性控制在业务允许的范围内。例如让 Agent 自动写邮件草稿可以但点击发送之前必须有人工确认让 Agent 生成营销文案可以但发布到线上平台必须走审批。3.4 用状态机控制协作流程在代码层面可以用一个简单状态机来管理协作流程。from enum import Enum class TaskState(Enum): DRAFT draft GENERATED generated REVIEWING reviewing APPROVED approved REJECTED rejected FALLBACK fallback class HumanAITask: def __init__(self): self.state TaskState.DRAFT self.output None self.review_result None def run_model(self, generator): if self.state ! TaskState.DRAFT: raise RuntimeError(task is not in draft state) self.output generator(self.prompt) self.state TaskState.GENERATED def submit_for_review(self): if self.state ! TaskState.GENERATED: raise RuntimeError(task is not generated) self.state TaskState.REVIEWING def approve(self): if self.state ! TaskState.REVIEWING: raise RuntimeError(task is not under review) self.state TaskState.APPROVED self.review_result approved def reject(self): if self.state ! TaskState.REVIEWING: raise RuntimeError(task is not under review) self.state TaskState.REJECTED self.review_result rejected这段代码的核心是让状态流转变得可追踪。状态机的价值不在于复杂而在于当流程出问题时你能明确知道卡在哪一环是模型还没生成还是人工审核超时还是被自动拒绝。3.5 各环节职责速查表流程环节模型输出人类输出失败分支任务定义提示词模板业务目标与验收标准需求不明确时退回补充结果生成候选文本/代码/JSON选择是否采纳结构错误时重试自动校验解析后的结构化结果校验规则配置规则不通过时标记失败人工审核审核辅助信息批准或打回打回后进入修正队列发布上线生成终稿发布决策不符合风险要求时停止这张表可以直接作为团队协作文档的骨架。每个环节都要有明确负责人不能出现“模型生成的不知道谁负责”的模糊状态。4. 没有评估体系定位就是一句空话4.1 从“感觉还行”到“可量化可回归”如果“人工判断模型输出好坏”只是停留在主观感觉那么你无法知道一次提示词修改到底是变好了还是变坏了。这也是很多人觉得 AI 项目不稳定、难以推进的原因。要建立人类定位的工程价值必须把评估行为体系化。评估体系的起点不是指标而是回归集。回归集是一组带标准答案的输入输出样例。每次修改提示词、更换模型、调整参数时都要在回归集上重新跑一遍对比结果变化。4.2 建立最小回归集回归集不需要很大但要覆盖常见场景和风险场景。[ { case_id: title_001, task_type: ecommerce_title, input: {name: 无线蓝牙耳机, features: 降噪续航30小时}, expected: 包含商品名称不超过30字不含夸大词, risk: high }, { case_id: sql_001, task_type: sql_generation, input: 查询最近7天订单金额大于1000的用户, expected: SQL包含订单表、金额条件和时间范围, risk: high }, { case_id: summary_001, task_type: text_summary, input: 一段200字的新闻, expected: 摘要包含核心事实、时间、地点, risk: medium } ]实际项目中回归集要由业务人员和开发人员一起维护。标准答案不一定要完整文本可以是“必须包含的关键信息”列表。4.3 自动化评估脚本示例下面是一个最小评估脚本。它不依赖大模型只负责对比模型输出和预设规则这对早期回归已经够用。后续可以引入更复杂的语义相似度但基础规则先要落地。import json def check_length(text, max_length): return len(text) max_length def check_forbidden_words(text, forbidden_words): found [word for word in forbidden_words if word in text] return found def evaluate_case(case, model_output): checks {} if case[task_type] ecommerce_title: checks[length_ok] check_length(model_output, 30) forbidden check_forbidden_words(model_output, [第一, 最, 绝对]) checks[forbidden_words] forbidden checks[has_name] case[input][name] in model_output elif case[task_type] sql_generation: checks[has_from] from in model_output.lower() checks[has_where] where in model_output.lower() elif case[task_type] text_summary: checks[has_time] 2025 in model_output or 今天 in model_output passed all( value is True or value [] for value in checks.values() ) return {case_id: case[case_id], passed: passed, checks: checks} if __name__ __main__: with open(regression_set.json, encodingutf-8) as f: cases json.load(f) fake_outputs { title_001: 超强降噪无线蓝牙耳机绝对是最好的选择, sql_001: select user_id from orders where amount 1000, summary_001: 今天下午发生一起事件 } for case in cases: result evaluate_case(case, fake_outputs[case[case_id]]) print(result)这个脚本的优点是简单、透明、易于解释。缺点是无法判断语义是否合理所以它只能承担“硬性规则检查”真正的语义判断仍然需要人参与。4.4 评估指标与人工判断的分工评估维度工具人类是否介入示例格式JSON Schema、正则否输出是否为合法 JSON长度代码计数否标题是否超过30字禁用词词表匹配否是否含有“最”事实一致性人工核对资料是摘要是否遗漏关键日期安全合规人工复核是是否包含高风险表述用户价值小范围试用是文案是否能提升点击率人工判断要集中在模型最容易出错、成本影响最大的地方。不要浪费人力去逐字检查所有输出而是通过规则把明显不合格的过滤掉再把真正有风险的候选交给人。5. 常见定位错误与排查路径5.1 把模型输出当成事实现象系统直接展示模型生成的合同摘要结果漏掉了解除条款导致用户误解。原因没有为高风险任务设置“事实校验”环节只依赖模型生成。检查方式查看该任务的提示词和输出是否存在校验步骤回看回归集中高风险样本的通过情况。处理方案为高风险任务增加外部知识源或规则库强制人工审核在界面上标注“AI 生成内容仅供参考”。这类问题的预防方法是在任务定义阶段就判断风险等级。高风险任务默认加一道人工审核闸门而不是上线后发现问题再补。5.2 提示词堆叠掩盖了流程缺陷现象模型输出总是不稳定于是不断往提示词里加“你必须”“你千万不能”“如果错了就重写”。原因把模型当成了可以通过命令完全控制的执行器忽略了失败分支和校验逻辑。检查方式查看提示词长度和维护成本观察失败输出是否集中在固定错误类型。处理方案把提示词里的约束提取成代码里的校验规则让失败输出进入结构化纠错流程。不要用延长提示词的方式掩盖设计缺陷。5.3 用 AI 编程却没有代码审查现象开发者用 AI 生成大量代码提交后不审查也不跑测试导致线上故障。原因把“AI 编程”理解成“让 AI 自己写完整功能”放弃了自己作为开发者的核心职责。实际上 AI 编程更准确的定位是“快速生成候选代码”代码审查、测试和上线决策仍然必须由人来完成。检查方式查看最近提交的代码是否有 AI 生成痕迹是否都有对应测试查看故障记录中是否有未经审查直接上线的案例。处理方案建立强制代码审查规范AI 生成的代码必须经过人工 review并且要跑单测和静态检查。不要让 AI 生成代码绕过现有工程流程。5.4 定位偏移排查清单现象可能原因检查方式处理建议结果经常不可用没有边界清单回看能力实验记录建立回归集并做边界测试人工审核成本过高输入任务定义不清晰检查提示词验收条件把约束拆成自动化校验规则模型输出偶发风险缺少高风险样本测试检查实验样本分布增加高风险样本和强制人工审核修改提示词后效果倒退没有版本管理和回归集检查提示词版本记录每次修改都运行回归评估流程卡住无法继续状态机缺少失败处理查看任务状态流转日志增加超时、重试和人工介入分支排查时按输入、路径、配置、权限、日志的顺序走。先看这次请求的输入是否合法再看模型调用参数是否正确然后检查校验规则是否命中最后看日志里有没有异常记录。大多数定位问题不是模型不行而是流程里缺少可观测的环节。6. 不同岗位的定位清单与自检方法6.1 开发从生产者转向编排者开发者的核心定位从“亲手写每一行代码”转向“组装模型、工具、数据和校验规则”。你需要掌握模型接口的调用方式和参数含义。把输出解析成结构化数据的方法。为模型输出配置缓存、降级和重试策略。建立本地评估脚本快速验证模型改动的影响。自检问题如果模型接口不可用我的系统会优雅降级吗如果模型输出非法格式我的代码会抛出明确异常还是直接崩溃6.2 测试从手工用例转向评估集与幻觉检测测试人员的定位不再只是执行用例而是建立“模型行为评估集”。需要关注识别高风险输入类别并补充回归集。设计恶意输入、空输入、超长输入等边界场景。分析错误结果区分是模型幻觉、提示词缺陷还是规则缺失。配合开发人员建立自动化评估流水线。自检问题当提示词版本升级时回归集能否自动运行错误分类是否覆盖事实错误、格式错误和约束遗漏6.3 产品与技术管理定义指标和止损线产品和技术管理者的定位是设定“什么能上线什么不能上线”的标准。需要定义核心任务的正确率目标。人工审核的最大比例和成本预算。模型失败时的降级体验。出现严重错误时的回滚方案。自检问题团队是否清楚每个 AI 功能的最低正确率阈值当模型效果不达标时是否有一个明确的回退到规则引擎或人工处理的预案6.4 可复用自检表检查项是/否备注是否对模型能力做过边界实验记录样本数量和主要错误类型是否维护提示词版本每次修改有记录是否建立了回归集至少覆盖常规、边界、高风险三类样本是否存在自动化校验规则格式、长度、禁用词等高风险任务是否有强制人工审核不能只靠模型自觉是否有失败分支和降级方案模型不可用时系统能继续运行是否有评估结果可视化不要求复杂但要能看到趋势这张表建议每两周做一次自检。不是为了考核而是为了防止项目往“看起来能用实际上没人负责”的方向滑落。7. 沉淀与扩展把个人定位文档变成团队知识库7.1 分工说明卡片当团队开始协作时光靠文章和口头说明不够。建议为每个 AI 功能制作一张“分工说明卡片”内容包含任务名称、模型职责、人类职责、自动校验规则、失败处理方式和评估指标。这种卡片比冗长的文档更容易维护。7.2 模板示例feature: 商品标题生成 task_type: ecommerce_title model: gpt-4o-mini prompt_version: 1.3.0 human_responsible: - 审核夸大词 - 确认商品卖点是否准确 - 决定是否发布 model_responsible: - 生成候选标题 - 保证输出 JSON 格式 auto_validation: - max_length: 30 - forbidden_words: [第一, 最, 绝对] failure_handling: - on_json_error: retry - on_forbidden_word: send_to_review - max_retries: 2 evaluation_metric: - acceptance_rate - human_review_time这张卡片可以存在项目仓库里也可以放到团队 wiki。关键是每次修改模型或提示词时卡片要同步更新。7.3 与 Spring AI、LangChain 等框架结合在 Java 生态中Spring AI 提供了统一的模型接入方式在 Python 生态中LangChain 和 LlamaIndex 可以简化 Agent 编排。无论使用哪个框架上面的分工原则都适用框架解决的是“模型调用和链式编排”问题但“人在哪个环节介入”仍然要由你设计。例如在 Spring AI 项目里你可以通过Advisor或Filter在模型调用前后增加校验逻辑把规则检查从业务代码中剥离出来。在 LangChain 项目里可以用Tool的权限开关控制 Agent 能执行的操作并在关键节点上暂停等待人工批准。7.4 个人练习建议如果你想在这个领域持续成长建议做三个练习为自己的工作选一个高频任务建立 10 条回归集样例并写一个最小评估脚本。将一个已有的 AI 生成流程加上状态机明确生成、审核、批准、拒绝四个状态。给团队里某个 AI 功能写一份分工说明卡片并邀请同事提意见。这三个练习都会迫使你回答同一个问题模型负责什么人负责什么边界在哪里。不断回答这个问题就是 AI 时代人类定位的真正内容。与其担心被替代不如先确认自己是否已经在模型输出和最终结果之间建立了可控的校验与仲裁机制。如果你还没有那这就是你下一步最值得投入的工程方向。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
