从想要AI到可验收的任务需求

需求不是一个技术口号

虚构的创作材料工坊有公开的纸艺说明和材料目录，成员经常要把一份说明整理成适合新手的准备清单。有人提出做一个聪明助手，这句话既没说明用户是谁，也没定义聪明如何验收。先观察一次完整任务：成员找到说明，判断适用版本，提取纸张与工具，确认数量，再整理步骤。若真正耗时在找不到最新文件，单纯生成清单可能帮不上忙；若已有结构化目录，普通筛选表也可能解决问题。产品需求应从阻碍任务完成的环节开始，而不是先决定必须使用模型。

写出任务契约和非目标

工坊把需求写成：新成员给出一份许可的纸艺说明，希望得到可核对的材料清单，以便在开始制作前准备物品。成功标准包含材料项完整、数量与说明一致、不补造未知工具，并能指出信息缺失。非目标同样重要：不自动购买材料，不判断真实机器操作安全，不处理个人身份资料，也不生成未经证实的特殊用途建议。非目标不是故意削弱产品，而是让团队知道哪些问题不能由当前系统承担。输入、输出、适用说明书和人工复核责任共同构成一个可以测试的边界。

用基线回答为什么需要改变

先让成员用现有方法完成十份虚构说明整理，记录耗时、遗漏、返工和澄清次数，这叫基线。基线可以是人工流程、模板表格或规则抽取，不必须是另一个AI模型。然后用相同难度的任务比较候选方案，计入检查模型输出的时间。假如生成只用半分钟，但审核与修正需要五分钟，而原流程只需四分钟，总体没有变快。基线还帮助发现真实瓶颈，可能是说明写得模糊而非整理能力不足。对问题原因的判断会决定是否应该优化资料、界面、规则还是模型。

把验收写成具体输入和观察

准备常规说明、工具缺失、数量冲突和新版本四类输入。常规说明应得到对应材料；工具缺失应标明未提供；数量冲突应列出冲突并请求确认；新版本应优先使用明确指定的版本而非记忆旧资料。验收不能只写用户满意，需要明确哪些错误一旦出现就暂停试点，哪些属于可修正的文案问题。对于开放生成，先定义人工审阅规则，再让不同审阅者试着评价同一输出，检查理解是否一致。若评分者对正确清单都没有共识，模型成绩就没有可靠解释，应该先修正规则。

用一页说明达成合作

需求页包含用户任务、现状证据、期望变化、范围、输入输出、评价方法与停止条件，并列出谁提供资料、谁验收、谁维护。不要把未来可能的所有功能都塞进第一次试点；先选一种频繁而风险可控的任务，获取证据后再决定扩展。如果没有足够样本或使用需求，写明待验证，而不是把希望写成事实。工坊最终要求助手只生成可核对草稿，成员确认后才使用。这样的需求能指导技术选型，也允许团队诚实得出不用AI更合适的结论。