一份智能体定制需求，最常见的结尾是这样的：能对话、能查资料、能生成报告、能接企业微信、能导出 Excel。
看起来很清楚，但开发看完还是不知道第一版该做什么。
功能清单是怎么长出来的
业务部门一开始说的是问题：客服每天重复回答同样的问题；销售找资料要问三个人；运营写周报要翻五个表。
写到文档里，问题变成了功能。因为功能比问题好写，也更容易被看见。
于是需求会越写越长，优先级却越来越模糊。
需求里最该写的三件事
第一，触发条件：谁在什么情况下会用它。
第二，判断标准：它输出什么，什么样算对，什么情况必须转人工。
第三，验收人：谁签字，谁负责上线后的维护。
这三件事不写，功能再多也无法验收。
用任务卡代替功能清单
一张任务卡写：任务名称、使用角色、触发场景、输入、输出、例外、权限、验收人。
比如“查报价”不是一个功能，而是一张任务卡：销售在客户问价时触发，输入产品型号和数量，输出报价区间和依据，超过权限转经理，验收人是销售主管。
这样写，开发知道先做什么，业务知道怎么验。
任务卡还有一个好处：它能逼出例外。客户要折扣怎么办，型号停产怎么办，报价超出权限怎么办。这些问题在功能清单里通常看不到，在上线后却天天出现。
功能清单不是没用
功能清单可以做，但应该放在任务卡后面。先写清楚任务，再从任务里推导需要哪些功能。
顺序反了，功能就会自己长，最后没人说得清为什么要做。
还有一种情况：业务部门把“别人家有”写进需求。别人有的功能，不一定对应你的流程。先问这个功能解决哪一步，再决定要不要。
需求评审时，让写功能的人把每个功能对应到一张任务卡。对应不上的，先删掉；对应得上但没人验收的，也先删掉。删功能比加功能难，但第一版必须做。这一步不能省。
最容易被省略的是“不做什么”
定制项目最常见的扩大，不是功能写少了，而是边界没写。哪些问题不回答、哪些操作不做、哪些系统不接，要提前写。
比如一个客服智能体，第一版可以查规则、写回复草稿，但不承诺退款、不改订单、不判断责任。把这些写进需求，开发才知道哪些按钮不能给。
边界不是限制能力，是让第一版能上线。边界还要写清停用条件：什么情况下暂停、谁有权停、停了之后业务怎么接。这些在立项时写，比出事后补容易。写需求时多问一句：这一条如果明天不做，业务会不会停？
谁写，谁拍板
需求不能只由使用部门写。业务写场景，技术写约束，负责人拍优先级。三个人缺一个，文档就会偏。
业务容易写成一厢情愿，技术容易写成实现方案，负责人如果不拍板，最后就是谁声音大听谁的。
评审时只问三个问题：这件事为什么现在做、第一版做到哪、谁验收。答不上来，先别立项。
需求变更怎么管
定制项目一定会变。变更不可怕，怕的是没有记录。每次变更写清楚：改什么、为什么改、影响哪张任务卡、谁同意。
第一版冻结后，新需求进下一期，不要边做边塞。塞进去的功能，通常没人验收。
边界
如果只是采购标准工具，需求可以粗一点；如果是定制开发，任务卡不能省。
如果业务自己也没想清楚，先做流程盘点，不要急着写需求。需求文档不是用来代替思考的。
智能体定制需求，不是把想要的功能列全，而是把要做的那件事说清楚。功能是答案，任务才是问题。