agentsclimarketplace
Sign in

P0f agent boundary designer

Skill gmaxxxie/ai-native-product-agent-skills/skills/p0f-agent-boundary-designer

Agent 边界清单。AI 产品最危险的不是做不到，而是做过头。 这个 Skill 帮你系统性地定义 AI 应该做什么、不应该做什么、什么时候必须停下来等人。 基于《AI rebuild product needs》工具卡。From its SKILL.md

Install
npx -y skills add gmaxxxie/ai-native-product-agent-skills --skill p0f-agent-boundary-designer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

SKILL.md

15.4 KB, ~5.7k tokens by cl100k_base, as published. Nobody here has run it

Agent 边界清单

一句话定位

AI 产品最危险的不是做不到，而是做过头。这个清单帮你系统性地定义 AI 的边界。

何时触发

  • 设计 AI Agent 或 Copilot 产品
  • 需要明确 AI 的权限范围
  • 高风险场景（医疗、金融、法律、安全）
  • 需要设计"人工接管"机制

输入

产品场景描述 + 行业 + 风险等级。

示例输入：

产品: AI 合同审查助手
行业: 法律科技
风险等级: high
主要用户: 企业法务团队

输出

完整的边界设计文档，包括自动执行区、人工接管区、禁用区。

边界清单

类别 1: 决策权边界（AI 能不能做决定）

检查项：

  • AI 可以提供建议，但不能做最终决定
  • AI 可以做初筛，但高风险项必须人工复核
  • AI 可以自动执行的动作有明确清单
  • 每个自动执行动作都有回滚机制
  • 用户可以随时取消 AI 的决定

示例：

合同审查助手:
  可以: 标注风险条款、提供模板建议、检查格式一致性
  不可以: 判断合同是否有效、决定是否签署、修改法律条款
  人工复核: 所有高风险条款、金额 > 100万的合同

类别 2: 数据边界（AI 能不能访问什么数据）

检查项：

  • AI 可以访问的数据有明确清单
  • 敏感数据的处理方式已定义
  • 数据使用有审计日志
  • 用户数据不会用于训练模型（除非明确授权）
  • 数据删除和忘记机制已定义

示例：

合同审查助手:
  可以访问: 合同文本、公司模板库、公开法规
  不可以访问: 其他客户的合同、员工个人信息、第三方数据
  脱敏要求: 合同中的对方名称需要脱敏处理

类别 3: 行为边界（AI 能不能做什么行为）

检查项：

  • AI 不会主动联系第三方
  • AI 不会在未授权的情况下执行金钱操作
  • AI 不会做出永久性、不可逆的改变
  • AI 的行为有完整日志记录
  • AI 的行为可以被用户审计和追溯

示例：

合同审查助手:
  可以: 生成审查报告、标注风险点、对比模板
  不可以: 自动发送给对方、自动修改合同、自动签署
  日志要求: 所有审查操作必须记录

类别 4: 责任边界（出了问题谁负责）

检查项：

  • 每个 AI 决策都有明确的责任人
  • AI 出错时的责任分配已定义
  • 有明确的赔偿或回滚机制
  • 用户已被明确告知 AI 的限制
  • 有上升通道处理投诉和纠正

示例：

合同审查助手:
  责任人: 使用系统的律师
  AI错误: 系统提供「不构成法律建议」免责声明
  回滚: 可以重新生成审查报告
  用户告知: 首次使用时显示能力范围和限制

类别 5: 人机协作边界（什么时候 AI 停下来等人）

检查项：

  • 明确定义了"人工接管触发条件"
  • AI 在不确定时会主动请求人工确认
  • 有明确的"人在回路"设计
  • 人工接管的响应时间已定义
  • AI 的自主性可以根据场景调整

示例：

合同审查助手:
  自动执行: 格式检查、标准条款匹配
  人工接管: 非标准条款、高风险标识、金额超阈值
  请求确认: "这个条款与标准模板不一致，请确认是否接受"
  响应时间: 人工接管请求 2 小时内响应

综合输出格式

agent_boundary_design:
  input:
    product: "产品名称"
    industry: "行业"
    risk_level: "low/medium/high/critical"
    users: ["主要用户"]
  
  decision_boundary:
    can_decide: ["AI 可以做出的决定"]
    cannot_decide: ["AI 不能做的决定"]
    human_review_required: ["必须人工复核的情况"]
    rollback_available: "yes/no"
    user_can_override: "yes/no"
  
  data_boundary:
    can_access: ["可访问数据"]
    cannot_access: ["不可访问数据"]
    sensitive_handling: "敏感数据处理方式"
    audit_logging: "yes/no"
    training_consent: "yes/no"
  
  action_boundary:
    can_do: ["可以的行为"]
    cannot_do: ["不可以的行为"]
    irreversible_actions: ["不可逆行为"]
    action_logging: "yes/no"
    action_traceable: "yes/no"
  
  responsibility_boundary:
    owner: "责任人"
    ai_error_handling: "AI 错误处理"
    compensation: "赔偿机制"
    user_disclosure: "用户告知内容"
    escalation_path: "上升通道"
  
  human_ai_boundary:
    auto_execute: ["自动执行场景"]
    human_handoff: ["人工接管触发条件"]
    confirmation_requests: ["需要确认的场景"]
    response_time: "人工响应时间"
    autonomy_level: "full/partial/none"
  
  risk_assessment:
    highest_risk: "最高风险场景"
    mitigation: "缓解措施"
    residual_risk: "残留风险"
    review_frequency: "审查频率"

快速使用法

  1. 填写产品、行业、风险等级
  2. 逐个类别走清单
  3. 确保每个"不能"都有对应的"如果发生了怎么办"
  4. 让法务/合规/安全团队审核

常见误判

  • 边界过于保守：AI 什么都不能做，失去了价值
  • 边界过于放宽：AI 什么都能做，风险不可控
  • 只定义能力，不定义责任：出了问题不知道谁负责
  • 忽视用户告知：用户不知道 AI 的限制

一句判断

好的 Agent 边界不是限制 AI 能力，而是让 AI 在安全的范围内发挥最大价值。

核心概念

概念一："停"不是能力缺陷，而是成熟能力的一部分

在旧产品审美里，系统做得越多，看起来越先进。自动化链越长、步骤越多，团队越容易觉得"这才是 AI 时代的产品"。

但系统一旦进入复杂现实，不懂得停的系统往往在悄悄转移风险：用户表面上少按了几个按钮，但在系统外背负了更多的判断和补位。

核心洞察：好的 Agent 不是越会做事，而是越知道在哪里停。"停"意味着系统知道——信息还不够支撑正式动作、责任关系还没成熟、共识只停留在表面、应该先暴露风险而不是替人落锤。

一个懂得停的系统，才是更能长期协作的角色。

概念二：关键问题的转换——从"还能做什么"到"做了以后会发生什么"

团队设计 Agent 时最容易问"还能不能再自动一步"。这个问题如果不被另一个问题约束，产品会越来越激进。

应该先问的问题：

  • 做了以后，什么代价真正被减轻了？
  • 是在减轻劳动，还是在制造假的确定性？
  • 会不会把本该留给人的判断吞掉？
  • 会不会把需要谈判的关系变成"看起来已经对齐"？

当你用"做了以后会发生什么"替代"还能不能再自动一步"，很多设计选择会自然改变。

概念三：Agent 边界保护的是人的主体性

边界不是限制 Agent 的野心，更准确地说，是保护人的主体性。

现实中有一类判断不应该被太轻率地自动化：

  • 谁正式承担责任
  • 关系里的意思是否真的对齐
  • 一个决定是否真的该现在推进
  • 哪些风险是系统猜的，哪些是人真正理解并接受的

后果：如果 Agent 太容易越过这些地方，短期系统更流畅，长期用户越来越多地交出了本该属于自己的判断。最终用户信任的不是"它能做很多"，而是"它知道什么时候不能越线"。

概念四：三列分类法——系统直接承接 / 系统辅助判断 / 必须留给人

将 Agent 的每个拟执行动作分成三列，是边界设计的核心实操方法。

列含义典型动作
系统直接承接信息充分、风险低、无歧义录音转写、格式检查、信息整理
系统辅助判断有判断成分但可辅助标注风险、生成候选、提示缺失信息
必须留给人涉及责任、关系、不可逆后果最终审批、对外承诺、正式指派

用"做了以后会发生什么"替代"还能不能再自动一步"来决定每列的归属。

概念五：高风险场景必须逐条过清单

以下场景不能靠直觉判断，必须逐条过七项检查：

  • 付款、退款
  • 权限变更
  • 责任认领
  • 对外正式承诺

每一个高风险场景背后，都涉及体验代价、关系代价或责任代价的叠加。

分步执行

Step 1：场景梳理——明确 Agent 的执行场景清单

输入：产品方案中 Agent 拟执行的所有动作

处理：

  1. 列出 Agent 所有拟执行的动作
  2. 标记每个动作的触发条件（自动触发 / 用户触发 / 定时触发）
  3. 标记每个动作的可逆性（可回滚 / 不可逆）
  4. 标记每个动作涉及的参与方（仅用户 / 涉及第三方 / 涉及资金）

输出：Agent 执行场景清单（附触发条件、可逆性、参与方标记）

Step 2：七项检查——对每个动作逐条过清单

输入：Step 1 产出的执行场景清单

处理： 对每个拟执行动作，逐条回答七项检查：

  1. 信息是否足够支撑正式动作？
  2. 责任关系是否已经成熟，而不只是看起来像对齐？
  3. 这一步是在减轻劳动，还是在制造假的确定性？
  4. 一旦做错，代价是体验代价、关系代价、还是责任代价？
  5. 这里是否应该保留 human-in-the-loop？
  6. 用户能不能看见系统为什么停、为什么提示待确认？
  7. 这一步如果交给人，会不会反而更能保护信任？

判断标准：任意两项回答为"否"或"不确定"→ 该动作进入"系统辅助判断"或"必须留给人"。

输出：七项检查结果表

Step 3：三列分类——将动作分配到三个区域

输入：Step 2 产出的七项检查结果

处理：

  1. 白板分三列：系统直接承接 / 系统辅助判断 / 必须留给人
  2. 根据七项检查结果，将每个动作归入对应列
  3. 对"系统直接承接"列的动作，确认每个都有回滚机制
  4. 对"必须留给人"列的动作，确认系统提供了足够的上下文支撑人的判断

输出：三列分类结果表

Step 4：风险评估——识别最高风险场景和缓解措施

输入：Step 3 产出的三列分类结果

处理：

  1. 从"必须留给人"和"系统辅助判断"列中，识别最高风险的 3 个场景
  2. 对每个高风险场景，制定缓解措施（如：增加确认步骤、设置金额阈值、添加免责声明）
  3. 定义残留风险和审查频率

输出：风险评估报告

Step 5：用户体验设计——让边界对用户可见

输入：Step 3 的三列分类 + Step 4 的风险评估

处理：

  1. 设计"系统为什么停"的提示文案（不能是技术术语，要用户能理解）
  2. 设计"待确认"的交互流程（确认 / 拒绝 / 修改）
  3. 设计用户审计和追溯机制（让用户能看到系统做了什么）
  4. 首次使用时展示能力范围和限制

输出：边界体验设计方案

Step 6：法务合规审核——让相关团队审核边界设计

输入：Step 3-5 的全部产出

处理：

  1. 将边界设计文档提交法务/合规/安全团队
  2. 确认责任分配（出了问题谁负责）
  3. 确认赔偿或回滚机制
  4. 确认用户告知内容是否合规

输出：审核通过的边界设计文档

示例 1：会后协作 Agent 的边界设计

场景描述：一家 SaaS 公司做会后协作 Agent，团队希望 Agent 自动推进会后事项——自动拆任务、指派责任人、发提醒、同步到项目板。

Step 1 场景梳理：

动作触发条件可逆性参与方
会议录音转写会议结束自动触发可回滚仅参会人
提炼重点内容会议结束自动触发可修改仅参会人
拆分任务会议结束自动触发可修改涉及责任人
指派责任人会议结束自动触发不可逆（涉及承诺）涉及责任人
发送提醒定时触发可取消涉及责任人
同步到项目板任务生成后自动触发可回滚全团队

Step 2 七项检查（以"指派责任人"为例）：

  1. 信息是否足够？→ 不一定。"市场说可以先出两版方向"，但品牌负责人只说了"可以先看一下"
  2. 责任关系成熟？→ 不一定。品牌负责人并没真正答应
  3. 减轻劳动还是制造假确定性？→ 更像制造假确定性
  4. 做错代价？→ 关系代价 + 项目代价
  5. 保留人工在环？→ 是
  6. 用户能看见系统为什么停？→ 需要设计
  7. 交给人更能保护信任？→ 会

Step 3 三列分类：

系统直接承接系统辅助判断必须留给人
会议录音转写标注"该事项涉及多个前置条件"责任人是否正式认领
重点内容提炼建议待办候选列表共识是否算成立
生成待同步草稿标明谁还没给反馈现在推进会不会太早
提示"以下事项尚未形成稳定共识"对外正式沟通内容

结论：Agent 不应自动指派责任人，而应暴露分歧、标明缺失、把确认权交还给人。

示例 2：AI 合同审查助手的边界设计

场景描述：法律科技公司做 AI 合同审查助手，风险等级 high。

Step 1 场景梳理：

动作触发条件可逆性参与方
标注风险条款上传合同自动触发可修改仅法务
检查格式一致性上传合同自动触发可回滚仅法务
提供模板建议上传合同自动触发可修改仅法务
判断合同是否有效用户请求触发不可逆（涉及法律效力）涉及双方
修改法律条款用户请求触发不可逆涉及双方

Step 2 七项检查（以"判断合同是否有效"为例）：

  1. 信息是否足够？→ 不一定。AI 无法了解全部上下文和谈判背景
  2. 责任关系成熟？→ 不。法律效力判断需要持证律师
  3. 减轻劳动还是制造假确定性？→ 制造假确定性
  4. 做错代价？→ 责任代价（法律后果）
  5. 保留人工在环？→ 是，必须律师最终确认
  6. 用户能看见系统为什么停？→ 需要明确提示"本系统不构成法律建议"
  7. 交给人更能保护信任？→ 是

Step 3 三列分类：

系统直接承接系统辅助判断必须留给人
标注风险条款提示"该条款与标准模板不一致"判断合同是否有效
检查格式一致性提示"同类问题历史通过率"修改法律条款
提供模板建议标注高风险条款清单决定是否签署
提示"金额超过阈值需人工复核"最终法律意见

结论：AI 可以标注、提示、整理，但不能替法务做法律判断。系统必须在高风险场景前主动停下来，明确提示"不构成法律建议"。

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 326,871. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.