前两年大家讨论 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 don't”，意思是：你做了会挨骂，不做也会挨骂。放到 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( # model=self.model, # messages=messages, # ) # 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", encoding="utf-8") as f: f.write(json.dumps(record, ensure_ascii=False) + "\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_key=os.getenv("LLM_API_KEY"), model="your-model") reviewer = CodeReviewer(client) audit = AuditLogger() result = reviewer.review(code, language="python") 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_KEY=your_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 解决复杂协作。比如在一个自动运维场景中，可以拆成三个 Agent：
| Agent | 职责 |
|---|---|
| 监控 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 辅助环节，给它加上日志和人工复核。你会发现，从“担心背锅”到“有据可查”，差的只是一套工程化的留痕机制。
