qinghuan
← 回到知识探索

AI 直觉 / 案例拆解

AI把参数填对了，为什么还不能执行？

从一次虚构的预约请求区分字段格式、当前业务条件和用户权限。

约 7 分钟资料核对：2026-09-26
展开本文目录
  1. 第一关：这张申请单填得合规吗？
  2. 第二关：这个人现在能办这件事吗？
  3. 通过预检查，还没有办成
  4. 给每条规则安排负责的地方
  5. 记住这三点
  6. 别把例子用过头
  7. 自己试一小步
  8. 查原始资料
  9. 找一份资料继续练
开始前，会这些就够了
  • 见过由字段和值组成的 JSON 对象
遇到不熟悉的词，先看这 3 个解释
事务
把一组数据库操作放进同一个提交范围，让它们作为一件事被确认或撤销，并按数据库规则控制其他事务看到的变化；它帮助处理做到一半时的失败。
工具调用
模型按工具说明提出要调用的功能和参数，由应用程序检查并执行，再把结果交回模型的交互方式。它把生成文字与查询、计算等实际操作连接起来。
结构约束
描述数据应该有哪些字段、字段是什么类型、允许哪些值。它帮助程序检查格式是否符合约定，但仅凭格式通常无法知道某位用户此刻能否执行某项业务。
打开完整术语小抄 ↗

假设你让助手替购物车预约两件展会周边。它生成了购物车编号和数量，看起来字段齐全，JSON也能解析。此时服务端能不能直接扣库存？还不行：购物车可能不是你的，也可能已经锁定，或者只剩一件。

工具调用让模型把一句话整理成程序能够接收的参数。参数格式正确，只说明它通过了一类检查；真正能不能做，要由掌握身份、权限和当前业务状态的后端判断。模型说“可以”，不能替代这些证据。

第一关：这张申请单填得合规吗？

模式校验，也叫 schema 校验，像检查申请单必须有哪几栏。购物车编号应是字符串，数量应是约定范围内的整数，不接受莫名多出的管理员字段。JSON Schema 可以描述许多这样的规则；仅能解析为 JSON，甚至还没有走到这一步。

要明确写出必填项和额外字段规则。JSON Schema 的 properties 说明字段怎样检查，本身不意味着这些字段都必须出现，也不默认禁止其他字段。部分业务约束可以表达在模式里，但会变化的库存和当前用户权限，仍需要服务端的数据与逻辑。

第二关：这个人现在能办这件事吗？

权限检查问的是“你能操作这个购物车吗”；业务检查再问“车是否可编辑、这次数量是否有库存”。即使数量是合法整数三，也可能超过当前可用两件。身份应来自服务端已经验证的登录上下文，不能相信模型在参数里写的 user_id。

下面用手写字典代替后端状态，依次观察格式错误、他人的购物车、库存不足和通过预检查。程序只返回原因，不写数据库，也不真的预约。这样能把每一关看清楚，而不用注册服务、调用模型或动用真实商品。

小实验 · python
carts = {'C1': {'owner': 'u1', 'editable': True},
         'C2': {'owner': 'u2', 'editable': True}}
available = 2

def precheck(args, authenticated_user):
    if not isinstance(args, dict) or set(args) != {'cart_id', 'quantity'}:
        return 'invalid_shape'
    if not isinstance(args['cart_id'], str):
        return 'invalid_shape'
    if type(args['quantity']) is not int or not 1 <= args['quantity'] <= 5:
        return 'invalid_shape'
    cart = carts.get(args['cart_id'])
    if cart is None or cart['owner'] != authenticated_user:
        return 'not_allowed'
    if not cart['editable']:
        return 'cart_locked'
    if args['quantity'] > available:
        return 'insufficient_stock'
    return 'ready_for_commit'

requests = [{'cart_id': 'C1', 'quantity': '2'},
            {'cart_id': 'C2', 'quantity': 2},
            {'cart_id': 'C1', 'quantity': 3},
            {'cart_id': 'C1', 'quantity': 2}]
for request in requests:
    print(precheck(request, authenticated_user='u1'))

怎样运行：保存为 tool_precheck.py，用 Python 3.10 或更新版本运行：python tool_precheck.py。仅用标准库，不联网。

运行后对照结果
invalid_shape
not_allowed
insufficient_stock
ready_for_commit

通过预检查，还没有办成

最后一个结果是“可以进入提交步骤”，不是“预约成功”。检查之后、真正扣库存之前，其他人可能已经拿走余量。真实后端必须在提交时保证库存条件仍成立，例如把条件检查与更新放在可靠的原子操作或事务中；本例没有实现并发控制。

业务完成应有对应的服务端结果或记录，再让助手据此告知用户。请求被拒绝时也应返回明确但不过度泄露的信息：让用户知道参数不合要求或当前不能办理，而不是把别人的购物车资料原样塞进解释。需要修改参数时，再经过相同检查。

给每条规则安排负责的地方

阅读 JSON Schema 的对象页面，分别找到 properties、required 和 additionalProperties，再给这个预约工具写一张字段表。接着读 OWASP 的语法、语义校验和服务端权限检查说明，标出哪些规则只靠字段值就能判断，哪些必须查当前状态。

不要把“模型输出稳定”和“业务允许执行”混成一个通过率。评测工具调用时，可以分别记录参数被接受多少次、权限或库存拒绝多少次、最终成功多少次。这样才看得出问题发生在模型整理参数、后端约束还是实际执行阶段。

记住这三点

  • JSON 能被程序解析、字段类型和必填项符合要求、当前业务允许执行，是不同的检查。
  • 身份与权限由可信的服务端上下文决定，不能由模型填写的字段授予。
  • 预检查通过不等于已经完成，实际提交还必须处理状态变化与并发。

别把例子用过头

  • 模式可以表达部分业务约束；本文不是说所有业务规则都必须写在模式之外。
  • 示例只演示顺序预检查，没有实现登录、数据库事务、并发扣减或真实预约。
  • 在提示词里要求模型遵守规则，不能替代服务端执行这些规则。

自己试一小步

怎样让预约工具的错误原因既有用，又不会泄露他人的资料？

  1. 增加购物车锁定、零数量和多余字段三种输入。
  2. 给每种结果设计用户提示与内部记录字段。
  3. 写出提交前库存被其他请求改变时，后端还需要保证的条件。

做到这些，就算完成

  • 是否区分格式、权限、业务状态和执行结果？
  • 是否从可信上下文获取身份？
  • 是否避免把预检查成功写成预约已经成功？

查原始资料

想确认一个细节，先看这份资料对应的部分，不必从头读完所有文档。

找一份资料继续练

先选一项，按下面的范围继续学；不必从头读完整门课程。