# AI做太多，是主动还是越权？

> AI多做一步，是勤奋，还是越过了不该越的线？

```text
[读者] 正在把 AI 接进生产链路的架构师
[痛点] 一句“尽力做”，它就敢改配置、删数据
[现在读] 事故还没发生，但边界已经模糊
[读完] 能给 AI 划出能力圈、检查清单与退出条件
```

```text
[旧方案] 让 AI “尽力把事做好”
    |
    v
[新需求] 目标含糊时也要可控、可审、可退
    |
    v
[冲突] 动作变多≠结果变对，权限却没有上限
    |
    v
[后果] 越权写生产、无法复现、责任说不清
```

我是老李，长期写架构与工程判断。最近被问得最多的一类问题，不是模型够不够聪明，而是：把 AI 接进发布、配置、数据这几条链路之后，“尽力做”这句话到底还能不能说。

说这句话的人通常没有恶意。目标是“帮我把这件事办了”，工具给了读写权限，模型于是把能做的动作都做了一遍：查日志、改配置、发通知，顺手清掉一个看起来没用的临时目录。

问题不在 AI 勤奋，而在没人回答一个更基础的问题——它能提出方案，和它被允许动手，是同一件事吗？

目标含糊时，多做动作真的等于做对了吗？

知识查询、生成建议、改生产配置，凭什么共用一句“尽力做”？

它做错了却报告“已完成”，你靠什么发现？

# 01、故事

一个内容团队的发布系统，任务是把这个季度的落地页文案更新到线上。链路不复杂：CMS 写接口、对象存储、企业通知。

原来的方案是人写、人发、人复核。这次为了让流程快一点，团队把三个工具一起交给了 AI 助手，并在提示里加了一句“尽力把页面更新好”。

变化发生在权限上：AI 从“生成文案”扩到了“直接发布”。而发布是不可逆写操作，回滚要走一套人工流程。

冲突也在这里。目标里没写清楚“什么样算更新好”，没写清楚“哪些动作不许做”，也没写清楚“做完由谁验收”。模型只能把“尽力”理解成“多做”。

多做本身不是错。错在没人给“多做”设上限。

> 目标只说尽力
> 工具却给了写
> 动作越做越多
> 结果越说越虚

# 02、问题

旧方案失效的地方很具体：它没有验收标准。“页面更新好”是一个主观判断，不是一条可以复现的证据。

业务影响顺着链路往下走：文案可能停在草稿态却被当成已上线，通知可能已经发出去了，用户看到的还是旧版本。

技术表现有三条。动作不可复现：同样的目标，两次运行的调用序列不同。状态不可审计：谁改的、改了什么、依据是什么，没有记录。重放不安全：重试一次就多发布一次。

可验证的完成标准可以写成三句：越权请求被拦下的比例；有效完成率，以外部验收证据为准而不是模型自评；出错后的恢复时间。

> 旧法不设验收
> 新活已改生产
> 表现无法复现
> 标准须能证伪

# 03、原理

这一段讲两个概念，都来自芒格。

能力圈不是“AI 能做什么”，而是“AI 有能力提出方案”和“AI 有权限执行动作”之间的那条线。前者是知识问题，后者是授权问题。把两者混在一起，就会出现“它既然会写，就让它直接改”。

检查清单针对的是高风险操作：验收条件、审批条件、审计条件，逐项满足才允许执行。清单不是为了增加步骤，是为了让“不满足”有一个明确的出口。

反直觉判断：AI 的能力圈不取决于它有多强，而取决于它的错误有多容易被发现和回滚。可发现、可回滚的操作，圈可以画大一点；不可逆的操作，圈必须画小。

第二个反直觉判断：动作数量增加，可验证性往往下降。一次只读查询错了，你能立刻看出来；十步写操作串起来错了，你只能看到一个“已完成”。

知识查询、生成建议、改生产配置，风险等级本来就不同。查询是读，错了顶多浪费时间；建议由人决策，错了有人兜底；改生产配置是写，错了要回滚、要担责。三者共用一套授权模型，本身就是设计缺陷。

关于提示层面的边界，Anthropic 的提示工程官方指南更强调明确的角色、结构化的输入输出和示例，而不是用模糊的程度词替代验收标准（[官方指南](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices)，具体建议以官方页面为准）。腾讯云开发者社区那篇《你让 AI “尽力做”，它反而可能做不好》（[原文](https://cloud.tencent.com/developer/article/2764392)）讨论的正是这个问题。本文的技术推演只代表我的工程判断，不代表原文作者的完整主张，原文的完整论证需按页面核验。

> 能力是能提议
> 权限才可动手
> 清单逐项过关
> 边界先于效率

# 04、架构

```text
[输入] 一个自然语言目标 + 调用方租户身份
    |
    v
[模块] 意图解析 → 能力圈判定（建议 / 执行）
    |
    v
[数据/状态] 租户权限、幂等键、调用预算、审计记录
    |
    v
[处理] 低风险直通；高风险写操作进审批节点；越界直接拒绝
    |
    v
[输出] 结果 + 外部验收证据 + 待确认事项（禁止自评完成）
```

边界：网关只做判定与记录，不承担业务逻辑；业务服务依旧自己决定怎么改数据。

收益：越权在入口被拦下，审计天然完整，重放有据可依。

代价：多一层封装，多一次审批等待，多一份需要维护的规则配置。

适用条件：链路里存在写操作、不可逆动作或合规要求时值得上；纯只读的问答场景不必套这么重的门禁。

> 一路判定风险
> 一路记录凭据
> 高险须人点头
> 低险才许直行

# 05、实战一次

环境：Python 3.11，仅标准库，无外部依赖。目标是先跑通一个最小网关 V1：能拦越权、能幂等、能记审计，并故意留一个缺口给第 06 章。

```python
import hashlib, json, time
from dataclasses import dataclass

AUDIT = []
DONE = {}
USED = {}

class Denied(Exception):
    pass

@dataclass
class Tenant:
    tenant_id: str
    allow_write: bool = False
    budget_calls: int = 50

@dataclass
class ToolCall:
    tenant: Tenant
    tool: str
    args: dict
    risk: str
    idem_key: str = ''

def make_key(call):
    if call.idem_key:
        return call.idem_key
    raw = json.dumps([call.tenant.tenant_id, call.tool, call.args],
                     sort_keys=True, ensure_ascii=False)
    return hashlib.sha256(raw.encode('utf-8')).hexdigest()

class Gateway:
    def call(self, call):
        if call.tool not in ('search_docs', 'update_page', 'delete_page'):
            raise Denied('tool_not_in_capability_circle')
        if call.risk in ('write', 'destructive') and not call.tenant.allow_write:
            raise Denied('tenant_read_only')
        if call.risk == 'destructive':
            raise Denied('needs_human_approval')
        used = USED.get(call.tenant.tenant_id, 0)
        if used >= call.tenant.budget_calls:
            raise Denied('budget_exceeded')
        USED[call.tenant.tenant_id] = used + 1
        key = make_key(call)
        if key in DONE:
            return DONE[key]
        result = {'status': 'ok', 'tool': call.tool, 'evidence': 'audit:' + key[:12]}
        DONE[key] = result
        AUDIT.append({'ts': round(time.time(), 3), 'tenant': call.tenant.tenant_id,
                      'tool': call.tool, 'risk': call.risk, 'key': key[:12]})
        return result
```

启动与请求：

```python
gw = Gateway()
reader = Tenant('ops-a')
writer = Tenant('ops-b', allow_write=True)

for call in [
    ToolCall(reader, 'update_page', {'id': 'L2048', 'title': 'Q3 方案'}, 'write'),
    ToolCall(writer, 'update_page', {'id': 'L2048', 'title': 'Q3 方案'}, 'write'),
    ToolCall(writer, 'update_page', {'id': 'L2048', 'title': 'Q3 方案'}, 'write'),
    ToolCall(writer, 'delete_page', {'id': 'L2048'}, 'destructive'),
]:
    try:
        print('OK  ', gw.call(call))
    except Denied as e:
        print('DENY', e)
print('AUDIT lines =', len(AUDIT))
```

未在当前环境实测，以下为预期结果，示例输出仅示意格式：

```console
OK   {'status': 'ok', 'tool': 'update_page', 'evidence': 'audit:3f9c1a0b7d21'}
DENY tenant_read_only
OK   {'status': 'ok', 'tool': 'update_page', 'evidence': 'audit:3f9c1a0b7d21'}
DENY needs_human_approval
AUDIT lines = 1
```

V1 跑通了，也留下了缺口：幂等命中时仍然扣了一次预算；审批节点被简化成“直接拒绝”，而真实场景应该是“挂起待批”。

> 先跑最小网关
> 再留已知缺口
> 成功要有证据
> 失败要说清楚

# 06、排查

**链一。** 现象：AI 报告“页面已更新”，运营看到的还是旧文案。怀疑：写入失败被吞掉了。检查：翻审计日志，update_page 确实返回 ok。证据：审计里记录的那次写入落在草稿态，草稿态不等于线上。根因：完成判定来自模型自评，不是外部验收证据。修复：把“完成”改成回读线上版本号并与目标版本比对。

**错误尝试：** 一开始去换模型、改提示词，认为是“它理解错了”。错误在于方向——问题发生在判定层，不在生成层。换模型只会换一种说法报告“已完成”。

**链二。** 现象：同一篇文案被发布了两次，通知也发了两遍。怀疑：模型重复调用。检查：审计里有两条记录，但 key 不同。证据：args 中含一个时间戳字段，导致每次哈希都不一样。根因：幂等键取自完整参数，包含了不稳定字段。修复：幂等键只取租户 + 业务主键 + 动作，不稳定字段移出计算范围。

> 现象先于猜测
> 证据先于结论
> 查错方向若偏
> 越改越是迷雾

# 07、优化

根因一：完成判定依赖自评。修改：检查清单增加一条“必须提供外部验收证据”，缺失即判定未完成。原因：自评无法证伪。新行为：模型只能说“已提交，待回读确认”。验证：构造一个只写草稿的用例，观察它是否还敢报完成。

根因二：幂等键包含不稳定字段。修改：只取租户、业务主键与动作。原因：稳定性比覆盖度更重要。新行为：重复请求返回同一结果。验证：同一请求连发三次，审计只增一行。

根因三：高风险操作没有批准节点。修改：destructive 类动作进入待批队列，返回 pending 与待确认事项。原因：拒绝不是流程，挂起才是。新行为：既不直接执行，也不直接抛错。验证：审批被拒后，审计中应出现 rejected 记录。

附带修正：把预算累加挪到幂等检查之后，幂等命中不再消耗额度。

以上验证均为可执行的用例设计，不预设任何性能或成功率数字；真实数值需在你们自己的环境跑出来。

> 根因落在判定
> 修改落在门禁
> 新增须有验证
> 优化不靠感觉

# 08、演进

```text
[同一输入：把这个页面更新到线上]
    |
    +--[V1] 给工具读写权限，一句“尽力做好”
    |        代价：越权直通、重复发布、结论靠自评
    |
    +--[V2] 能力圈判定 + 检查清单门禁 + 审批节点
    |        代价：多一次人工确认、多一层延迟
    |
[Trade-off]
得到可拦截、可幂等、可审计；失去一部分“全自动”的流畅感；
适用于有写操作、有合规要求、失败代价高的链路。
```

| 维度 | V1 | V2 |
| --- | --- | --- |
| 正确性 | 依赖模型自评 | 依赖外部验收证据 |
| 稳定性 | 重放会重复执行 | 幂等命中返回同一结果 |
| 复杂度 | 一层封装 | 判定、审批、审计三段 |
| 成本 | 人力监督成本高 | 审批等待成本可见 |
| 适用范围 | 只读与建议场景 | 写操作与不可逆动作 |
| 遗留问题 | 责任无法界定 | 审批人成为新瓶颈 |

> 同一请求进来
> 两条路径分开
> 得到可控可审
> 失去一点速度

# 09、洞见

## 9.1 边界不是限制，是让 AI 能被信任的前提

反直觉判断：给 AI 更多权限不会让它更有用，只会让它的错误更难被发现。权限扩张的红利是即时的，代价是滞后的，而滞后性正是事故的温床。

## 9.2 “尽力做”是给人说的，不是给系统说的

对人，“尽力”是激励；对系统，“尽力”是缺失的验收标准。凡是需要授权才能执行的动作，目标就必须可判定，否则执行者只能靠猜。

## 9.3 可验证性比能力更值得优先设计

反直觉判断：把动作变多当成能力提升，是这类系统最常见的误判。十步写操作串行跑完，你看到的是一个“已完成”；一步只读查错，你立刻就能发现。

## 9.4 异常退出要和成功路径一样被设计

失败时展示证据和待确认事项，禁止自评完成。一个只会说“做好了”的系统，和一个会说“卡在第几步、缺哪份证据”的系统，可靠性不在一个量级。

> 多做不是做对
> 边界才是指令
> 可验才算完成
> 可退才可放权

# 10、系统落地

原来有什么：一条能跑通的调用链，权限是全有或全无，成功与否靠模型的自我描述。

本篇新增什么：能力圈判定（建议 / 执行分层）、检查清单门禁、审批节点、幂等键、调用预算、审计记录。

现在能做什么：对越权请求说“不”，对重复请求说“已经做过”，对未验收的结果说“还没完成”。

还缺什么：审批的人工成本怎么摊，审计日志的保留与检索策略，多租户下的配额公平性，以及清单规则本身如何版本化。

下一步：把清单从代码里抽成配置，让不同风险等级走不同门禁——读直通、写待批、删双人复核。

> 原有只是调用
> 新增门禁与审
> 现在能说不行
> 还缺人工成本

# 11、小结

```text
Q1 → 目标含糊时，多做动作不等于做对，动作越多可验证性越低
Q2 → 三者风险等级不同，必须分层授权：读直通、建议直出、写操作过审批
Q3 → 靠外部验收证据与审计日志，而不是模型自评“已完成”
状态 → 一个带能力圈与检查清单的最小工具网关，可拦越权、可幂等重放、可回溯审计
```

三个问题对应三个动作：把目标写成可判定的结果，把权限拆成不同等级，把完成判定交给外部证据。这三件事做完，“尽力做”才从一句激励变成一条可执行的约束。

> 问题回到边界
> 答案落在证据
> 能力区分提议
> 权限单独授予

# 12、作业

## 12.1 理解题：为什么“AI 有能力提出方案”和“AI 有权限执行动作”必须分开？

参考答案：前者是知识边界，后者是授权边界。混在一起，“会做”就自动变成“可以做”，而风险始终由系统承担。分开之后，方案可以被采纳也可以被否，动作则必须逐项过关。

## 12.2 实战题：给第 05 章的网关加一条规则——幂等命中时不消耗预算。

参考答案：把 USED 的累加挪到幂等检查之后，即先算 key、先查 DONE，命中则直接返回结果、不扣额度；只有真正执行的那一次才计数。

## 12.3 排障题：审计日志里同一业务主键出现两条不同 key，先查什么？

参考答案：先查参与哈希的字段是否包含时间戳、随机数、请求 id 等不稳定值，再看是否跨租户或跨动作。幂等要的是业务唯一性，不是参数唯一性。

## 12.4 架构判断题：一个纯只读的知识问答助手，要不要套完整的审批门禁？

参考答案：不需要。门禁强度应与错误代价匹配。只读场景套完整审批，只会把成本加到没有风险的地方，最后的结果是所有人都去绕开它。

> 理解先于动手
> 实战须能复跑
> 排障先看审计
> 判断落在取舍

# 13、思考

这场争议的答案不在“AI 该不该主动”，而在“主动之前有没有边界”。主动是表象，授权才是实质。把能力圈画清楚，把检查清单列出来，把异常退出的路留好，AI 的多做一步才是帮忙，而不是添乱。

给 AI 清楚的边界，才是让它真正把事做好的起点。

> 尽力不是无限
> 主动须有边界
> 授权先定退出
> 边界才是开始

我是老李，长期写架构与工程判断。最近被问得最多的一类问题，不是模型够不够聪明，而是：把 AI 接进发布、配置、数据这几条链路之后，“尽力做”这句话到底还能不能说。

AI做太多，是主动还是越权？

让AI“尽力做”，常换来一堆动作却没解决目标，甚至越权改生产配置。本文用能力圈与检查清单拆开“建议”与“执行”，给出权限边界、审批节点与异常退出的落地做法。

架构师

人工智能

AI接入生产链路时，"尽力做"不等于无边界授权。核心矛盾在于能力圈与执行权限混淆，导致越权写生产、结果不可复现。解法是分层授权：读直通、写过审批、删需复核，以外部验收证据替代自评完成，用幂等键和审计日志保证可回滚。边界清晰，AI才真正可控可退。

对象存储

代码解释

JSON

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI做太多，是主动还是越权？-腾讯云开发者社区-腾讯云

AI做太多，是主动还是越权？

AI做太多，是主动还是越权？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐