前两年大家讨论 AI问得最多的往往是“AI 能做什么”而到了这两年问题开始变成“不用 AI是不是一种失职”。尤其当 AI 已经能写代码、能处理文档、能辅助医疗影像、能参与法律检索时“我明明可以用 AI 却没使用出了问题要不要担责”成了一个非常现实的工程与合规话题。这篇文章会从“不作为是否构成过失”的角度切入结合 AI Agent 开发、AI 工程实践、AI 模型部署等落地场景聊聊团队和个人应该怎样使用 AI、记录使用过程、评估 AI 输出以及如何避免把“用了 AI”变成新的风险点。无论你是后端开发、算法工程师、产品经理还是刚接触 AI 应用开发的学生这篇文章都会给你一套可操作的判断框架和工程思路。1. 背景与核心概念1.1 “用 AI 也是错不用 AI 也是错”是什么意思先解释这句话。它对应的英文原题是“Damned if you do and damned if you dont”意思是你做了会挨骂不做也会挨骂。放到 AI 场景里可以这样理解你用了 AI结果 AI 生成了有缺陷的代码或错误结论你会被质疑“为什么不人工复核”。你没用 AI结果后续发现 AI 本来可以帮助你提前发现问题你会被质疑“为什么这么落后放着工具不用”。两者看起来互相矛盾但底层其实指向同一个问题AI 已经逐渐从“可选工具”变成“行业默认基础设施”时社会对“合理注意义务”的预期正在改变。这不是纯理论问题。在医疗、法律、金融、自动驾驶、软件工程等高风险领域判罚和责任认定会越来越多地考察“你当时有没有按照行业普遍认可的方式做事”。如果 AI 辅助已经成为行业普遍做法而你没有采用就需要给出充分理由。1.2 过失与注意义务的基本逻辑法律意义上的过失通常看三件事要素说明注意义务你有没有义务预见风险并采取措施注意能力以你的专业水平是否能预见风险行为偏离你是否没有达到合理标准导致损害发生AI 的介入改变的正是“合理标准”的参照系。以前写代码只要考虑逻辑、测试、评审现在很多团队已经把“是否使用 AI 辅助代码审查”“是否用 AI 生成测试用例”写进了研发规范。一旦行业标准整体上移原来的“可接受行为”就可能变成“未尽到注意义务”。需要说明的是这并不等于“不用 AI 就一定有过失”。过失认定要看行业惯例、技术成熟度、风险大小和替代措施。AI 本身也会出错所以更准确的说法是你需要建立一套证据链证明自己已经尽到了合理的注意义务至于用不用 AI、怎么用都是证据链的一部分。1.3 为什么要从软件开发视角看这个问题对软件开发团队来说这个问题的落地场景非常清晰AI 编程助手生成的代码合并到主干前谁负责审查。AI 生成的需求分析或测试数据是否有二次校验。模型部署上线后是否保留输入输出日志能否回溯。团队是否拥有“人在回路”机制而不是让 AI 独立决策。换句话说真正要讨论的并不是“用不用 AI 要不要背锅”而是“AI 使用过程中你有没有建立可追溯、可验证、可审计的工程体系”。这篇博客后面会用一个 AI Agent 的实际开发案例来演示这套体系怎么搭。2. 不用 AI 是否构成过失几个典型场景2.1 软件工程场景中的“合理预期”在软件行业判断是否构成“过失”通常没有统一法律标准更多是看“合同怎么约定”“行业规范怎么要求”“同类企业怎么操作”。场景一你负责一个交易系统历史 bug 率很高。AI 代码助手可以提前做静态扫描、补测试用例这是一个已经被验证的提效手段。如果你完全不用且没有其他质量保障机制一旦线上出事故评审者就有理由问为什么你们没有把 AI 辅助纳入质量保障体系场景二你们已经在用 AI 辅助但把 AI 生成的代码直接提交上线没有经过人工评审。这种情况下问题不在“用了 AI”而在于“过度信任 AI”。所以真正的风险不是“用”或“不用”而是“有没有一个被记录下来的决策过程”。哪怕你决定不用也要留下类似“经过评估当前场景 AI 误报率较高暂不使用采用人工规则替代”的说明。这才是有工程意义的“免责证据”。2.2 医疗、法律等高合规场景的边界医疗、法律属于更敏感的高合规场景。AI 可以作为辅助工具但通常不能替代执业人员的独立判断。这里有一个很关键的原则AI 提供建议人做决策并且人要能解释决策依据。如果你是一名医生在影像辅助系统已经普及的医院里拒绝使用任何辅助筛查工具这可能被认为没有尽到注意义务。反过来如果你完全依赖 AI 给出的诊断建议而不做复核同样可能因为“过度依赖不成熟技术”而被追问。这类场景的工程启示是必须明确 AI 的“建议权限”和“决策权限”。必须有日志记录 AI 的原始输出、人的最终判断以及差异原因。必须有回滚或人工接管机制。2.3 用“记录决策过程”代替“纠结背锅”与其纠结“不用 AI 会不会担责”不如养成一个习惯把关键决策写成记录。比如在项目文档里增加一个“AI 使⽤评估”段落包含四部分字段示例使用场景代码审查、测试数据生成、日志分析使用工具具体的 AI 助手或模型评估结论可以辅助必须人工复核或暂不使用原因……复核机制每一条 AI 输出都由谁复核、如何验证这套记录的作用不是免责而是让团队清楚知道“AI 在哪个环节被用掉了产生了什么影响”。从工程实践角度看这比单纯争论“用不用”有价值得多。3. 从“讨论责任”到“落地 AI 工程实践”3.1 把 AI 纳入开发流程的最小闭环讨论完责任我们来落地。假设你要在团队中引入 AI 辅助最稳妥的方式不是让每个人都拿一个聊天窗口随便问而是建立一个最小闭环明确任务边界AI 负责生成草稿、做初筛、给候选方案。输入标准化把上下文、约束条件、样例喂给模型。输出校验由人对 AI 输出做测试、评审、对比。过程留痕保存输入、输出、修改记录、决策人。这个闭环放在代码里就是一个带日志、带人工确认环节的 AI Agent。下面我会给出一个可运行的示例思路重点不是某个框架的固定 API而是“工程上怎么把 AI 使用过程管理起来”。3.2 搭建一个带审计日志的 AI 辅助 Agent为了便于理解我们用 Python 写一个简单的“AI 辅助代码审查 Agent”。它做的事情是接收一段代码片段调用大模型 API 做初步审查然后把 AI 输出写入本地日志最后由人工确认是否采纳建议。这是一个演示型项目核心目的是展示工程结构。实际生产环境需要根据你的模型服务、权限体系和部署方式调整。project/ ├── agent/ │ ├── __init__.py │ ├── llm_client.py │ ├── reviewer.py │ └── audit.py ├── main.py ├── requirements.txt └── README.md# requirements.txt # 本示例只依赖基础库实际使用时按模型服务商要求安装 SDK # openai # flask # python-dotenv先定义一个 LLM 客户端负责调用大模型接口。这里不写死某个厂商而是抽象成“输入消息列表输出文本”。# agent/llm_client.py import os from typing import List, Dict class LLMClient: 统一的模型调用客户端。 生产环境中可以替换为任意模型服务只要保证输入输出格式一致。 def __init__(self, api_key: str None, model: str your-model): self.api_key api_key or os.getenv(LLM_API_KEY) self.model model def chat(self, messages: List[Dict[str, str]]) - str: 调用大模型。 这里只给出结构具体请求方式取决于你使用的模型服务。 if not self.api_key: raise RuntimeError(缺少 API Key请先设置 LLM_API_KEY 环境变量) # 伪代码实际需要调用对应 SDK # response client.chat.completions.create( # modelself.model, # messagesmessages, # ) # return response.choices[0].message.content return 模拟返回建议增加空指针判断接着定义一个审查器把“提示词构造”“调用模型”“解析结果”封装起来。# agent/reviewer.py from typing import Dict from agent.llm_client import LLMClient class CodeReviewer: def __init__(self, llm_client: LLMClient): self.llm_client llm_client def review(self, code: str, language: str python) - Dict: 构造审查提示词调用模型返回审查结果。 system_prompt 你是一名资深代码审查工程师。请从正确性、安全性、可维护性三方面给出建议。 user_prompt f请审查下面的 {language} 代码\n\n{code}\n messages [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ] result self.llm_client.chat(messages) return { code: code, language: language, ai_result: result, status: pending_human_review, }然后定义审计模块负责把 AI 输出写入日志方便追溯。# agent/audit.py import json import time from typing import Dict class AuditLogger: def __init__(self, log_path: str audit.log): self.log_path log_path def log(self, record: Dict): 把审计记录追加写入文件。 生产环境建议写入数据库或日志系统。 record[timestamp] time.time() with open(self.log_path, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)最后写一个入口演示完整流程。# main.py import os from agent.llm_client import LLMClient from agent.reviewer import CodeReviewer from agent.audit import AuditLogger def main(): code def divide(a, b): return a / b client LLMClient(api_keyos.getenv(LLM_API_KEY), modelyour-model) reviewer CodeReviewer(client) audit AuditLogger() result reviewer.review(code, languagepython) print(AI 审查结果) print(result[ai_result]) print(状态, result[status]) # 人工确认后更新状态并记录日志 confirmed input(请输入人工复核结论采纳/不采纳/部分采纳) result[human_confirmed] confirmed result[status] completed audit.log(result) print(已写入审计日志。) if __name__ __main__: main()运行前需要先设置 API Key然后执行export LLM_API_KEYyour_api_key_here python main.py这里要特别说明上面的LLMClient.chat方法只是演示结构真实环境需要根据你选定的模型服务接入对应 SDK。重点不是某一行请求代码而是这个闭环设计输入代码。调用模型。输出结果。人工确认。写入审计日志。有了这样的流程团队既可以用 AI 提效又能回答“AI 这条建议是谁采纳的、为什么采纳”这个问题。3.3 为什么“人在回路”机制很重要很多 AI 事故的根源不是 AI 不够聪明而是人把决策权完全交给了 AI。代码审查、数据分析、合同审核这类任务AI 能快速给出候选答案但它无法理解项目上下文、历史决策和微妙的人际因素。“人在回路”机制的要点包括AI 输出永远被标记为“建议”而不是“结论”。关键操作必须有二次确认比如合并代码、发送邮件、修改数据库。系统要能解释“为什么 AI 给出这个建议”理想情况下保留原始输入和模型版本。这套机制既是对用户的保护也是对开发者的保护。如果你负责维护这个 Agent你会很清楚它什么时候生成过什么内容问题出现时可以回溯。4. 从 AI Agent 到一个更生动的“AI 小镇”4.1 理解 AI Agent 的“环境”与“行为”刚才的代码审查 Agent 是一个单任务应用。如果把它放大让多个 Agent 在同一个环境里并行工作就有点接近“AI 小镇”这类实验项目了。你可以在 GitHub 上找到名为my_ai_town的开源项目它构建了一个虚拟 AI 社区多个 AI 角色在“小镇”中生活、交流、执行任务。这个项目看起来像游戏但它对 AI 工程实践很有启发Agent 之间需要通信协议。每个 Agent 需要有记忆和状态。环境需要记录所有 Agent 的行为轨迹。如果你把它理解成一个“多智能体系统”的仿真沙盒就能学到很多 Agent 编排、任务规划、状态管理的思路。4.2 用“AI 小镇”理解多 Agent 协作单 Agent 解决单任务多 Agent 解决复杂协作。比如在一个自动运维场景中可以拆成三个 AgentAgent职责监控 Agent采集指标检测异常诊断 Agent分析日志定位可能原因执行 Agent在人工授权后执行恢复操作这和“AI 小镇”里的角色分工类似。关键是每个 Agent 都只能做自己权限范围内的事并且所有行为都要上报到统一事件中心。事件中心记录的不只是结果还有决策过程。4.3 从实验项目到生产系统的差距“AI 小镇”可以当成学习多智能体协作的入门项目但把它搬到生产环境前需要补齐很多工程能力并发控制多个 Agent 同时操作同一个资源需要加锁或队列。权限隔离Agent 只能调用自己有权限的 API。可观测性每个 Agent 的输入输出、耗时、异常都需要监控。安全边界不能让 Agent 拿到数据库明文密码或生产密钥。简单说实验项目负责“让 AI 跑起来”生产系统负责“让 AI 跑得可控”。如果你想深入研究 AI Agent 开发可以在本地跑通 AI 小镇项目再看它的事件循环、消息传递和记忆存储是怎么实现的。5. AI 模型部署与落地中的责任边界5.1 部署 AI 模型前要做什么回到工程实践。无论你用的是开源模型还是云端 API只要把模型部署到生产环境就要考虑“责任边界”。部署前的检查清单模型用途是否清晰这个模型解决什么问题不解决什么问题。数据合规是否确认训练和推理数据的来源、授权、敏感信息。版本是否固定记录模型版本、训练日期或发布时间。降级方案是否准备模型服务不可用时能否回退到规则或人工处理。# 伪代码模型部署前记录版本信息 model_name: your-model model_version: 2025.04.01 deploy_date: 2025-04-10 owner: your-team approval: required这些信息在出问题时是重要依据。如果模型后来被发现存在漏洞你能准确知道“当时线上跑的是哪一个版本”这是最基本的可追溯性。5.2 生产环境中的“最小权限”原则与 AI 模型对接时最容易犯的错误是给模型过大的权限。比如让 AI Agent 直接连数据库或者让它能调用删除接口。正确的做法是模型只能访问脱敏数据。写操作必须走人工审批流。API Key 不写入代码仓库使用密钥管理服务。对 AI 的调用做好限流和配额管理。这样做不是为了限制 AI 能力而是为了让 AI 失败时影响范围可控。一个拥有最小权限的 Agent即使被提示词注入攻击也无法造成大面积破坏。5.3 避免“AI 幻觉”变成线上事故AI 幻觉是指模型生成看似合理、实则错误的内容。代码场景里幻觉可能表现为推荐了不存在的函数。生成了有安全漏洞的代码片段。把两个不兼容的库混在一起。应对措施永远是“验证 兜底”用编译、测试、静态扫描验证 AI 代码。用人工 review 检查业务逻辑。用索引、约束、回滚机制兜底。在生产环境不要把 AI 输出当最终答案。把它当成候选人只有通过测试和审查的代码才能合并。6. 常见问题与排查思路6.1 “用了 AI 之后责任算谁的”这是最常见的疑问。从工程角度AI 不是法律主体不能承担“责任”。责任最终在“使用 AI 的团队和个人”身上。团队能做的是明确定义 AI 的使用边界。保留使用记录。建立人工复核机制。这样做的目的不是“甩锅给 AI”而是让责任判断变得清晰。6.2 AI 生成的内容和事实不符怎么办如果 AI 输出的内容与事实不符先不要急着修改提示词。按下面顺序排查问题现象常见原因解决思路AI 回答明显错误上下文信息不足补充准确背景和约束条件AI 编造不存在的 API模型训练数据过时对照官方文档验证不盲信AI 在不同时间回答不一致模型版本变化或随机性固定模型版本和推理参数AI 泄露敏感信息输入数据未脱敏在调用前做敏感信息过滤工程上建议对每次 AI 调用都记录模型版本和参数。这样同一问题再次出现时可以快速定位是“模型变了”还是“提示词变了”。6.3 如何判断一个 AI 工具是否适合引入可以用一个简单打分表来评估维度问题通过标准准确性输出是否正确有测试集和抽样验证可解释性能否回溯决策依据有日志和审计安全性是否泄露数据通过安全评审成本是否值得投入ROI 可计算兜底出问题怎么办有人工接管方案如果五个维度都能满足就可以小范围试点。如果有一个不满足不要强行上线。7. 最佳实践与工程建议7.1 把 AI 使用记录纳入研发流程推荐在代码仓库中增加一个“AI 使用说明”文档并在 PR 模板中加入“AI 辅助”勾选项## AI 辅助说明 - [ ] 本次变更是否使用 AI 辅助 - [ ] 如果使用AI 生成的代码是否经过人工 review - [ ] 是否评估过 AI 输出的正确性和安全性这能倒逼团队养成“用 AI 但不盲信 AI”的习惯。每次 PR 都记录 AI 参与度长期下来能形成数据帮助团队判断哪些场景适合 AI哪些场景不值得用。7.2 设计可观测的 AI Agent对于 AI Agent 项目可观测性是上线底线。至少需要监控调用量、耗时、失败率。每个 Agent 的状态变化。关键操作的审计日志。模型返回结果的置信度或异常标记。# 伪代码给 Agent 增加 trace_id import uuid trace_id uuid.uuid4().hex # 在日志中统一带上这个 trace_id方便串联一次完整调用链路当用户说“AI 刚才给了一个错误答案”时你如果能回答“这次调用发生在 14:32使用的模型版本是 xxx输入是 xxx输出是 xxx”整个排查会变得非常高效。7.3 提示词也应当做版本管理很多人写提示词是“随手写的”但提示词其实在决定 AI 输出质量。生产环境建议把提示词当作代码管理用 Git 管理提示词变更。每次修改记录原因。对关键提示词做回归测试。比如“代码审查 Agent”的系统提示词改了措辞可能会让 AI 输出变严格或变宽松。如果没有版本管理你很难知道线上效果变化是从哪一次改动开始的。7.4 安全边界不要泄露敏感数据调用外部大模型 API 时默认应该认为“发送出去的数据可能被服务商处理”。所以输入数据先脱敏。禁止发送生产库真实数据。内部敏感信息尽量使用私有化部署模型。对模型的输出也要做敏感信息检测防止它生成包含密钥或隐私的文本。尤其是 AI 编程助手可能把代码片段发给云端服务。涉及商业机密或未公开功能的代码要谨慎使用外部 AI 服务。8. AI 时代的“决策留痕”清单8.1 团队层面清单是否已经制定 AI 使用规范是否明确哪些环节必须人工复核是否具备 AI 调用日志和审计能力是否对团队成员进行 AI 使用培训如果这些问题有几个是“否”建议先补齐短板再大规模引入 AI。8.2 个人层面清单使用 AI 辅助时是否理解生成内容的原理和局限是否具备验证 AI 输出的能力是否会在关键决策中保留人工复核环节个人层面最重要的不是“会不会用 AI”而是“有没有能力判断 AI 输出是否可靠”。在 AI 领域辨别力比操作熟练度更重要。8.3 下一步可以学什么如果你把“用不用 AI 是否构成过失”这个话题当成切入点接下来可以往这几个方向深入学习AI Agent 开发学习多智能体协作、任务规划、状态管理。AI 工程实践掌握模型部署、可观测性、A/B 测试、性能调优。AI 伦理与合规了解数据隐私、算法公平、安全审计。大模型应用开发学习提示词工程、RAG、微调。工具和框架迭代很快但“保留决策过程、建立验证机制、明确责任边界”这些底层方法论很长时间内都不会过时。如果你正在团队里推动 AI 落地不妨从今天开始做一件事找一个最常用的 AI 辅助环节给它加上日志和人工复核。你会发现从“担心背锅”到“有据可查”差的只是一套工程化的留痕机制。