如何把实际业务场景里需求梳理成对应的AI工具，同时也伴随着清晰的上下文、组件和判断标准，防止任务跑偏。同时如何定义对应做出来的工具或者产品是否有效，能说清好坏或者有效程度的标准和范围？

把业务需求交给 AI 前，先写清三件事：Context（这个任务在什么环境、什么背景下发生）、Component（任务由哪些部分组成、涉及哪些字段或环节）、Criteria（什么算好、什么算不好）。一个常见反例是让人清理重复图像，却没说明是内容重复还是文件名重复，AI 只能自己假设，结果自然不对。这三样都用自然语言写就行，不需要术语。如果最后产出和预期不符，通常就是这三项里某一项没说清，可以顺着往下拆⁠1,2。

需求梳理时先做任务光谱：能用明确规则判断的（格式错误、字段缺失、数值超范围、重复）用程序处理，把大部分明显没问题的筛掉；剩下真正需要看上下文、看多字段关系、理解“为什么怪”的部分才交给 AI。AI 不假装做最终裁判，它对能验证的部分给高置信判断，把不确定的部分标出来交给人。人的每次审核结果再回流到 skill 和评估里，形成可迭代闭环⁠3。

判断工具是否有效，先看 AI 在你承诺的核心任务上能不能过“可用”及格线：拿足够多的真实 case 人工判断质量，大部分结果不错就继续，大部分不能用就降低任务难度或换路径。量化层面，把判断标准写成 skill，构建 evals 测 precision/recall——该抓没抓是 false negative，不该报警却报警是 false positive，换模型或改 prompt 后看指标是升还是降。这套标准也适用于判断项目处于哪一层：看用户使用时 AI 在 runtime 里承担了什么职责，而不是看有没有用最新模型⁠3,4,5。