一个月试点说不清有没有用，多数情况不是能力本身不行，而是三件事被混在一起记录了：任务选得对不对、权限够不够、验收标准定没定。把这三件事拆成能查的记录，通常一周内就能判断该继续还是收手。先不要扩大范围，也不要急着否定这个能力，先把已有的运行痕迹翻出来。

判断方向：先按结果把跑过的任务归类，再从被拒日志里挑出因权限中断的任务，最后确认当初写没写可观测的验收条件。三项都有记录，问题多半在任务选择或权限范围；三项都没有记录，说明试点缺验收设计，继续投入前要先补一条判定标准。适用边界：只对能在配置、日志和任务记录里查到痕迹的试点有效，主观感受不能替代记录。

把跑过的任务列成表并标出结果

这一步回答的是“任务是不是选错了”。不要凭记忆填，每一行都要能在运行记录或工单里找到对应事件。表至少四列：任务名、触发方式、结果、人工介入次数。

结果建议只分四类：完全自动完成、部分完成、失败、无法判定。填完后按结果归类看分布，通常会出现两种明显不同的形态。

• 完全自动完成的任务很少，而且都是低价值的重复性任务：任务选错了，换任务比加投入更划算。
• 大量任务落在“部分完成”，但人工介入集中在同一个环节：更像是流程或权限卡住，不是任务本身不适合。

“无法判定”这一类要单独拎出来，它通常说明任务没有明确产出物，连判断对不对都没依据，这类任务不适合放进试点。

核对权限是否让任务卡在半路

这一步是为了排除权限原因。需要两份材料对齐：被拒记录和转人工记录。被拒记录来自运行日志，关键词常见的有 permission denied、forbidden、unauthorized、insufficient scope、403，具体字段名和关键词要结合自己的日志格式替换。转人工记录来自工单、群里的求助消息或手动补跑记录。

# 1) 从运行日志抽出被拒事件，关键词按自己环境替换
grep -Ei 'permission|forbidden|unauthori[sz]ed|insufficient|scope|403' presence.log > denied.log

# 2) 按任务名聚合，看哪些任务反复被拒
# 假设任务名在第 3 列，列号按实际日志格式改
awk -F'\t' '{print $3}' denied.log | sort | uniq -c | sort -rn

只有同一个任务既出现在被拒记录里、又出现在转人工记录里，才算“因缺权限中断”。只在日志里报错但任务最终跑完的，不算中断。算占比时用任务数做分母，不要用被拒条数做分母，否则一个任务的重试很容易把比例放大得失真。

判读方式比较直接：被拒集中在少数任务，先缩小这些任务的权限或直接换任务；被拒分散在很多任务上，说明工作区、组织或服务账号的权限模型整体没配好，这时候加任务只会让中断清单更长。如果日志里根本没有任务名字段，说明可观测性不足，这本身就该记成一条待补项。

风险边界：不要为了绕开卡点给服务账号开全局管理员权限。那会把一个试点范围问题变成权限治理问题，后面很难收回。

回看验收标准是不是一开始就没定

这一步排除指标原因。先去翻当初的邮件、会议纪要、需求单，搜“完成”“成功”“达标”这类词，看有没有写过判定条件。多数试点失败在这里：大家心里都有一个“看着还行”的标准，但没写下来，一个月后谁也说不清到底算不算过。

找不到就现场补一条，补的时候只要求可观测。一个够用的写法包含四段：产出物是什么、判定窗口多长、通过条件是什么、不通过时怎么兜底。

# 验收判定示例，占位值，按实际任务替换
task: weekly_digest
observable: 输出文件生成，且标题、摘要、来源链接三个字段完整
window: 连续 3 次运行
pass: 3 次中至少 2 次无需人工修改即可被使用方直接采用
fallback: 不达标时由人工按模板撰写，记录耗时用于对比

窗口次数和通过条件是占位，要按团队节奏定。关键是这条标准能被第三个人在产出物和日志上核对，而不是靠发起人主观说“感觉可以”。补完这条，再拿它去回测过去一个月的记录，能直接看出达标与否。

开一次短会只回答继续还是收手

前面三张表齐了，会议就有材料可看。参会人控制在四人以内：任务发起人、实际使用方、管权限的人、能看日志的人。三十分钟够用，议程按下面走。

1. 过任务表，只看“部分完成”和“失败”两类，逐条问是任务问题还是权限问题。
2. 过权限中断清单，按“本周内能否开通”排序，开不出来的单独列。
3. 确认验收判定条件，没有就当场定一条，写进纪要。
4. 给出结论，只有继续、调整、停止三种，不允许“再看看”。

会议结论必须落到“谁、在哪天之前、做什么”，否则一个月后会再开一次同样的会，问题还是同一个。