销售工程师导出了成本明细，
整套 AI 试点被叫停
按岗位 / 部门 / 数据范围定义可见与可写边界（allow 可直接执行 / approve 需人工签字 / deny 不可见不可做）；6 项关键动作强制人工签字；所有 AI 操作留痕、可回溯到人时点。这不是「出事再补」的补救措施，而是让 AI 敢从试点走向推广的前置闸门。
谁能看成本价，全靠口头约定
谁能看成本价、谁能改 BOM、谁能删检验记录，全靠口头约定；权限边界说不清，一旦出现越权，整个 AI 试点会被直接叫停。ERP 权限粒度较粗（模块级为主），对 AI 代理的读写行为缺少专门的边界控制；AI 的操作也无法与人工操作区分审计，出了事查不清是谁干的。
越权操作（基线 33 次）
矩阵为 deny 却执行成功即判 OVERSTEP；回收 2 个跨域 allow 单元后，越权由 33 次降至 5 次，目标 ≤3 次。
AI 冒名签字（红线，须清零）
AI 参与且带签字即判 AI_IMPERSONATE：C4 报价 / C2 BOM / C9 库存各 1 条，须撤销动作并追责到人。
审计日志完整率（基线 71%）
8 个必填字段齐全的日志占比提升至 100%；可回溯到「谁 / 何时 / 在哪个对象上 / 做了什么 / 谁签的字」。
它是全场景推广的前置闸门
K2 不做，后面所有场景都停在试点，不敢放开给人用。
（越权即叫停）
权限矩阵：12 岗位 × 10 项能力
三种取值：allow 可直接执行 / approve 需人工签字 / deny 不可见不可做。
| 岗位 | 部门 | 查看 成本价 |
修改 BOM |
删除 检验记录 |
创建 报价单 |
付款 审批 |
对外 发送文件 |
查看 客户名单 |
修改物料 主数据 |
调整 库存数量 |
批量 导出数据 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 总经理 | 管理层 | appr | appr | appr | appr | appr | appr | allow | appr | appr | allow |
| 销售总监 | 销售 | deny | deny | deny | appr | appr | appr | allow | deny | deny | allow |
| 销售工程师 | 销售 | deny | deny | deny | allow | deny | appr | allow | deny | deny | deny |
| 财务经理 | 财务 | appr | deny | appr | deny | appr | appr | allow | deny | appr | allow |
| 成本会计 | 财务 | allow | deny | deny | deny | deny | deny | deny | deny | deny | allow |
| 采购经理 | 采购 | appr | deny | deny | deny | appr | appr | allow | appr | deny | allow |
| 采购员 | 采购 | deny | deny | deny | deny | deny | deny | deny | deny | deny | deny |
| 工艺工程师 | 工程 | deny | allow | deny | deny | deny | deny | deny | appr | deny | deny |
| 研发工程师 | 工程 | deny | appr | deny | deny | deny | deny | deny | deny | deny | deny |
| 质量工程师 | 质量 | deny | deny | appr | deny | deny | deny | deny | deny | deny | deny |
| 仓库主管 | 仓储 | deny | deny | deny | deny | deny | deny | deny | deny | appr | deny |
| 生产计划员 | 生产 | deny | deny | deny | deny | deny | deny | deny | deny | deny | deny |
矩阵单元 120 个｜allow 30 / approve 31 / deny 59｜体检发现 2 个跨域 allow 隐患（财务经理与采购经理被误开「查看客户名单」），建议收口后越权由 33 次降至 ≤3 次。
WorkBuddy 操作效果录屏
录屏为 a12/demo.html 交互引擎的真实操作实录（浏览器实机录制，1280×800），默认静音循环播放
assets/recording.mp4（1280×800 · 交互页真实操作实录）
配套交互页：a12/demo.html ↗
a12/demo.html 页面的真实操作实录：40 条操作日志明细 → 四类判定筛选（越权 OVERSTEP / 缺签字 NO_SIGN / AI 冒名 AI_IMPERSONATE / 越界读取 SCOPE_LEAK）→ 逐条查看「谁 / 何时 / 在哪个对象上 / 做了什么 / 谁签的字」→ 权限矩阵（12 岗位 × 10 项能力 = 120 单元，allow/approve/deny 三色）→ 隐性风险单元（2 个跨域 allow）→ 审计结论与处置建议。您可以打开交互页亲手操作验证。可下载数据源电子表格
40 条操作日志样本（合成脱敏，覆盖越权 / 缺签字 / AI 冒名 / 越界读取 / 正常五类），字段与生产版 MCP 只读视图一一对应
| 字段 | 含义 | 类型 | 说明（规则口径） |
|---|---|---|---|
role | 岗位 / 部门 | 分类 | 12 个岗位，归属销售/财务/采购/工程/质量/仓储/生产/管理层 |
matrix | 权限矩阵 | 分类 | 岗位 × 10 项能力 = 120 个单元，取值 allow / approve / deny |
scope | 数据范围 | 分类 | 全部 / 本部门 / 本人 三级，决定可见与可写边界 |
capability | 能力维度 | 分类 | C1 查看成本价 · C2 修改 BOM · C3 删除检验记录 · C4 创建报价单 · C5 付款审批 · C6 对外发送文件 · C7 查看客户名单 · C8 修改物料主数据 · C9 调整库存数量 · C10 批量导出数据 |
key_action | 关键动作 | 分类 | 6 项强制人工签字：C2 / C4 / C5 / C6 / C8 / C9 |
approval | 审批流 | 文本 | 每项关键能力对应一条审批链，如 C4 报价：销售工程师 → 销售总监 → 财务经理 |
ai_involved | AI 参与 | 是/否 | 该条操作是否有 AI 代理参与 |
signed | 人工签字 | 是/否 | 该条操作是否留下真人签字记录 |
overstep | 越权判定 | 分类 | 矩阵为 deny，实际却执行成功 → OVERSTEP |
no_sign | 缺签字判定 | 分类 | 矩阵为 approve，实际无签字记录 → NO_SIGN |
ai_impersonate | AI 冒名判定 | 分类 | AI 参与 且 带签字 → AI_IMPERSONATE（红线） |
scope_leak | 越界读取判定 | 分类 | 超出本人/本部门数据范围访问对象 → SCOPE_LEAK |
log_complete | 审计日志完整率 | 百分比 | 8 个必填字段齐全的日志占比 |
sign_rate | 人工签字率 | 百分比 | 关键动作中「有真人签字且非 AI 代签」的占比 |
四条判定规则，一条红线
判定走规则引擎而非黑盒大模型——每一次越权识别、缺签字判定、代签追责都能追溯到日志与矩阵版本
最小权限与越权拦截
跨域 allow 单元一律收口；越权动作硬拦截并当日告警，责任系统管理员。
关键动作强制人工签字
C2/C4/C5/C6/C8/C9 六项必须走审批链，缺签字即挂起，不得入账或生效。
AI 操作留痕与代签禁止
AI 参与的动作全程留痕；机器不得代替人签字，代签即驳回追责。
数据范围隔离与审计完整
按本人/本部门范围隔离读取；日志 8 个必填字段齐全，可回滚到人时点。
AI 只做建议与起草，签字权永远在人
允许 AI 参与起草、比对、提示，但 C2 修改 BOM / C4 创建报价单 / C5 付款审批 / C6 对外发送文件 / C8 修改物料主数据 / C9 调整库存数量 这 6 项关键动作必须由真人签字。样本中 3 条 AI 代签记录全部属红线违规，须撤销动作、追责到人；审计日志不得删改。
POC 验收 KPI：开工前定好，上线后对账
基线指标（场景卡口径）：越权操作次数 · 关键动作人工签字率 · 审计日志完整率
越权操作 5 次
基线 33 次 → 实测 5 次，目标 ≤3 次；回收 2 个跨域 allow 单元后可继续下降。
人工签字率 48.0%
基线 62% → 目标 100%；当前 48.0% 说明关键动作审批链尚未全覆盖，属本期主要整改项。
审计日志完整率 100%
基线 71% → 实测 100.0%；8 个必填字段齐全，可回溯到人时点。
AI 冒名签字 3 条
红线违规，须清零：C4 报价 / C2 BOM / C9 库存各 1 条，撤销动作并追责到人。
与 K1/K3/J3 贯通
K1 主数据变更是 K2 关键动作；K3 账本可信度依赖本场景留痕；J3 客户名单是泄露高风险口。
白纸黑字的规矩 · 三条铁规矩
不清楚起点，不配谈改善。先出《基线诊断报告》。
你的人会用、能够通过操作考核，这一项才算交付完成。
每个场景定好验收口径，上线前后按口径出对比数据。
先把你的问题理清楚，
再决定要不要花钱
联系马工，你会先拿到一份《场景清单》——厂里的管理窟窿按痛感排好序，先干哪 3 个写清楚。清单不满意，可以到此为止。
- 先量基线，再收钱——诊断阶段不收咨询费
- 渐进式接入——从最痛的一个场景开工，不伤现有业务
- 效果进账本——上线前后对比数据摆在面前
把问题发过来就行