Files
skill-template/development/CHECKLIST.md
chendelian 20e89774ca
All checks were successful
技能自动化发布 / release (push) Successful in 8s
docs: add third-party acceptance CHECKLIST and acceptance-reports
2026-07-22 17:54:18 +08:00

7.9 KiB
Raw Blame History

技能交活验收 Checklist第三方视角

checklist_version: 1.0

本清单用于旁人 / 测试 / AI 编程工具对任意业务技能做交活验收。
它描述的是「验什么、怎样算过」,不是开发规范摘要。写法与实现约束见同目录其他文档。


验收输出强制规则(凡执行本清单必须遵守)

面向 AI 与人工验收员:只要开始按本 Checklist 验收,下列规则全部强制,无需用户在提示词里再重复。

  1. 必须落盘报告,禁止只在对话里给出口头结论。
  2. 报告目录(唯一合法位置):技能仓库根目录下的 acceptance-reports/
    (与 development/scripts/ 平级;禁止写到 development/tests/、临时目录或其他路径。)
  3. 报告文件名(唯一合法格式)YYYYMMDD-HHMMSS-acceptance.md
    示例:20260722-175000-acceptance.md
    时间取验收执行时的本地时间;禁止使用 report.md验收.md、无时间戳的文件名。
  4. acceptance-reports/ 不存在,先创建该目录再写入
  5. 报告开头必须写明:
    • 完整相对路径:acceptance-reports/YYYYMMDD-HHMMSS-acceptance.md
    • 技能 slug、当前 git 提交短哈希(若可得)、checklist_version
  6. 报告正文必须逐条对应下方条目,每条给出:PASS / FAIL / N/A / NEED_MANUAL,并附简短证据(文件路径、命令、观察结果)。
  7. 报告末尾必须有「给技术人员的修改清单」:只列出未通过项(FAIL 与未通过的 NEED_MANUAL),按 P0 → P1 → P2 排序。
  8. 禁止修改业务代码来“凑”验收通过;本清单的执行结果是报告,不是改代码。
  9. 若用户只说「按 Checklist 验收」而未指定路径:仍必须遵守本节省略规则,不得省略落盘。

结果取值

含义
PASS 已满足
FAIL 不满足
N/A 本技能不适用(须说明原因)
NEED_MANUAL 须人工点选/真机;报告中写清已做或未做

级别

级别 含义
P0 不通过不可交活
P1 限期整改
P2 体验建议

0. 技能画像(验收前先填,用于裁剪)

先根据技能实际情况勾选;后续章节不适用则整项标 N/A 并注明原因。

  • S0-1 交互形态:纯本地 / API / 网页RPA / 桌面RPA / 手机RPA / 编排(调兄弟技能)
  • S0-2 目标站登录策略required / optional / not_needed / 不适用
  • S0-3 是否依赖账号会话account-manager 或等价 Profile是 / 否
  • S0-4 持久化:无 / 仅任务日志 / 另有业务表
  • S0-5 Skill Action无 / 仅同步短任务 / 含异步长任务
  • S0-6 是否需要在任务中心查看进度或结果:是 / 否

1. 安装与可运行(所有技能)

  • A1-1 P0 按平台方式加载/安装后,技能可被识别(有名称,能打开详情或执行入口)
  • A1-2 P0 健康检查(如 health)能跑完且结果可读;缺关键条件时有明确失败提示,而非空白崩溃
  • A1-3 P0 版本查询(如 version)返回的版本与对外宣称一致
  • A1-4 P1 若有用户可见配置:说明可读;按说明改关键项后行为符合说明

2. 对外说明是否自洽(所有技能)

  • A2-1 P0 市场「说明」能让非开发者理解:做什么、给谁用、开始前准备什么
  • A2-2 P0 「说明/教程」不以开发目录、内部实现细节作为用户主路径
  • A2-3 P1 「教程」可按真实顺序跟做(准备 → 步骤 → 失败怎么办)
  • A2-4 P1 「演示」结构完整(有演示信息位;无视频则标明暂无,不假装有)
  • A2-5 P0 「更新日志」能对应到当前交付版本
  • A2-6 P0 平台/Agent 侧说明中,常见用户意图的触发方式与真实能力一致(短操作 vs 长任务不混淆)

3. 主能力行为(所有技能)

  • A3-1 P0 主成功路径能按宣称完成核心动作(至少 1 次完整闭环)
  • A3-2 P0 缺参或非法输入时稳定失败(可读错误,不假成功)
  • A3-3 P1 失败可诊断:能从任务记录/提示判断失败阶段,而非只有“失败了”
  • A3-4 P0 同一能力从已声明的不同入口触发时,业务结果一致(不出现入口分叉成两套逻辑)

4. 调度与长任务(有 Action 或长任务时适用)

  • A4-1 P0 秒级只读/短操作:不进入任务中心也能完成(若技能提供此类能力)
  • A4-2 P0 长耗时/浏览器/需进度或取消的能力:经 Agent 或技能动作触发后进入任务中心(或平台等价异步队列)
  • A4-3 P0 异步任务在任务中心能看到进行中与结束状态;结束有成功或失败结论
  • A4-4 P1 进行中的进度/步骤信息对用户可理解
  • A4-5 P1 已对外暴露的动作参数覆盖主路径关键输入(无“命令行能做、动作入口不能做”的关键缺口)

5. 账号与浏览器会话(网页 RPA 适用;其他形态标 N/A 或改测等价项)

  • A5-1 P0 未准备好账号/浏览器档案时,主路径失败并提示,不会默默用本机默认浏览器身份跑起来
  • A5-2 P0 登录策略为 required 时:未登录不能把做不成的事当成成功
  • A5-3 P0 交付联调默认能看见浏览器窗口(有头);不能把无头当作唯一可验收形态
  • A5-4 P1 浏览器窗口启动形态满足交付约定(如最大化或可视区域足够操作与人工介入)
  • A5-5 P1 验证码或人工确认:有等待与超时;超时后任务失败可理解,不无限挂死或假成功
  • A5-6 P0 NEED_MANUAL 真实站或约定仿真站主路径至少完整跑通 1 次;仅模拟数据通过不算交活

6. 结果落点(按画像裁剪)

  • A6-1 P0 宣称可追溯时:跑完后任务记录中有对应条目(成功/失败均有)
  • A6-2 P0 宣称写入业务数据或可在数据管理查看时:成功跑完后能看到新业务数据;仅有任务摘要、业务侧仍空 → FAIL
  • A6-3 P1 重复执行同一业务键时,结果符合宣称(更新/去重/追加),无莫名脏数据或静默丢数据
  • A6-4 P1 「零结果成功」与「失败」可区分
  • A6-5 P1 若产出文件:落在约定数据位置且可找到,不丢在不明临时路径

7. 可观测与安全观感(所有技能)

  • A7-1 P0 失败提示或任务结论不泄露密码、完整 Cookie、明文 token 等敏感信息
  • A7-2 P1 关键步骤有据可查(能对应到开始/关键节点/结束)
  • A7-3 P1 若宣称支持录屏或截图存证:打开开关后关键步骤或失败能留下可查看产物;宣称支持却完全无产物 → FAIL
  • A7-4 P2 用户可见文案偏业务语言,而非大段开发黑话

8. 质量门禁与交活底线(所有技能)

  • A8-1 P0 仓库默认测试套件通过(执行技能约定的一键测试命令,如 python tests/run_tests.py -v
  • A8-2 P0 不以「仅模拟档通过」作为交活依据(有真实档要求时必须真实跑通或书面阶段性豁免)
  • A8-3 P0 NEED_MANUAL 已声明的宿主入口(详情/Agent/工具栏/定时等)按声明抽测可通过
  • A8-4 P1 对外版本一致详情、version、更新日志、发布标签能对上
  • A8-5 P1 开发者按平台规则能安装并测到该技能(若平台有开发者可见性要求)

9. 报告结尾必填

报告末尾固定三块:

  1. 结论:通过 / 不通过(任意 P0 为 FAIL 或不通过的 NEED_MANUAL → 不通过)
  2. 统计PASS / FAIL / N/A / NEED_MANUAL 数量P0 FAIL 列表
  3. 给技术人员的修改清单:仅未通过项,带条目 ID 与期望现象