你接了一个 AI 项目，客户说“想让客服更高效”，但还没定具体任务、能不能用现有资料、怎样算做好。先花 15 分钟把这三件事问清，再决定要不要做试点。下面用三份虚构项目需求演示一张开工核对表，附一个不联网的本地小脚本。
开工前先准备什么
找一位真正了解业务的人，带上需求描述、可用于测试的样例说明和预算边界。暂时没有获准使用的样本时，不要拿真实客户资料去试模型，可以先用虚构数据验证流程。
| 准备项 | 会上要确认的内容 |
|---|---|
| 需求负责人 | 谁能解释流程、确认结果并拍板是否继续 |
| 一项具体任务 | 谁在什么环节输入什么，AI 要返回什么；这次明确不做什么 |
| 可用测试资料 | 样本从哪里来、是否获准用于该测试、是否覆盖常见情况 |
| 验收办法 | 固定一组样本和人工参考结果，写下通过条件与失败处理 |
| 人工回退和预算 | 哪些情况交给人处理，试点最多花多少时间或费用 |
这是一份项目沟通表，不是成功率预测。NIST 的 AI 风险管理框架建议先了解系统使用场景，再用测量结果支持后续管理；它是自愿使用的参考框架，不能替代你自己的业务和合规审查。NIST 当前页面也标注 AI RMF 1.0 正在修订，具体请以官网更新为准。查看 NIST AI RMF Core
三个容易在开工后才暴露的缺口
需求只写了目标口号。 “提高效率”“用上大模型”还不能指导开发。把它改成一个具体动作，例如“把售后工单先分成 4 类，客服确认后再入队列”。再写清输入、输出、适用对象和排除项。若连谁负责确认都不清楚，先做需求访谈，不要直接报固定交付日期。
数据还没准备好。 资料可能没有标签、字段不一致、缺少关键场景，或者尚未确认是否允许用于测试。先用合成样例走通流程；拿到真实样本前，明确来源、授权、脱敏和保留方式。样本能打开，不代表已经获准使用。
“效果好”没有验收口径。 先选一组固定样本，和业务负责人一起写出可检查的期望结果。比如分类任务可以逐条核对类别和必须转人工的情形；知识问答可以标出答案必须引用的资料，以及资料没写时应怎样回答。样本数、阈值和试点范围由双方按风险与成本商定，没有通用的行业门槛。
如果你还承诺“节省多少时间”或“减少多少成本”，要额外留一份上线前基线，约好测量窗口、排除项和业务变化的影响。NIST 的 Measure 指引也建议记录测试集、指标和评估细节；小样本只能帮助发现问题，不能单独证明正式上线后的效果。查看 NIST Measure 指引
用一张核对表决定下一步
对每个项目回答五个“是/否”：负责人已确定、任务边界已写清、测试资料已获准使用、验收办法可逐项核对、人工回退和预算边界已约定。不要把它们加成一个分数；任意一项未完成，都应先补齐对应工作。
练习包有三份虚构需求：一个目标仍模糊的客服助手、一份缺少验收办法的设备手册问答，以及一份核对项都齐全的工单摘要试点。脚本只整理缺口：前两项分别提示“先需求澄清”和“补齐试点准备”；第三项只标成“可进入人工评审的候选”，不替你批准项目。
下载AI 项目开工核对练习包，解压后在包目录运行：
python3 project_check.py --input kickoff_cases.json --output kickoff_preview.json --self-check脚本只读取你填好的 JSON，并写入新的结果文件，不访问网络、不调用 AI，也不会覆盖输入文件。打开 kickoff_expected.json 可对照样例输出。Python 是 Python Software Foundation 维护的通用编程语言，可从Python 官网免费下载安装；如果还没用过命令行，可先看Python 与 uv 入门。
评审结果仍由项目双方决定
即使五项都填“是”，也只表示可以进入人工评审：业务负责人还要确认收益是否值得投入，技术人员要验证样本是否代表真实流程，相关负责人还要核对数据、合同和部署要求。若结果影响客户权益或业务决策，也要设计复核、申诉和暂停机制。
这三份案例和脚本只验证一张核对表能否找出预先写下的缺口。它们不是行业失败原因统计，也没有真实客户访谈、模型效果或成本收益数据。若只想比较收费结构，可继续看AI 项目报价；工单分类的低把握回退示例见工单自动分类实测。