工信部公开《「人工智能软件」专项行动实施方案》把「智能体软件」单列成一个新形态。这个名词翻成人话是软件不再只等用户点按钮它理解目标、调工具、跨系统把事往前推。验收还停在按钮上就会漏掉后半截。名字换掉之后验收的问法也跟着换以前问按钮点了有没有反应现在问这件事从头到尾办完了没。一、按钮很顺事停在半路有一类场景是一个摘要按钮做得特别顺用户点完拿到一段摘要还得自己把这段贴回报告里。按钮并没有做到把事完成这个需求。翻一遍需求文档就能看出根在哪。开头写的是页面、交互、字段很少有一行写「这项工作是什么」。缺了这一行拆出来的就是零件。零件齐了用户还得自己拼。验收表上那一行多半是「页面正常」「按钮可点击」。这类写法在不少团队的需求模板里占着默认位置。做产品这行过去评判一个需求看页面顺不顺、按钮爽不爽。软件开始接整段路之后这条标准对不上了。功能视角下交付边界只对自研模块负责。软件开始跨系统推进之后这一段管不到接口事就断在接缝上。有一类团队的需求列表还是按页面排的这周三个页面下周两个按钮。没人按一件工作排。二、设计对象从一组功能上移到一项工作现在设计对象从「一组功能」变成「一项被完成的工作」。但是真正的问题是验收表上那一行不改后面所有排期都白做。举个例子过去画一个按钮用户点了去验证按钮亮没亮现在画一条路用户走完去验证他到没到头。设计对象为什么要跟着换因为自动化单位换了过去一次调用是一个功能点现在一次调用是一整件事。设计对象不跟着走做出来的就是一堆零件。有一类团队的改法是把「生成客服答案」改成「把用户问题变成已提交的工单」。页面反而少画了两个因为路通了不用那么多中转按钮。放到具体的一屏上导出按钮点完提示「成功」用户下载下来是个空文件。按钮亮了事没办成。在按钮的视角下永远是在数按钮。但本末倒置数着数着就忘了用户要的是结果。只有换成工作的视角才会去问这件事从头到尾到底是谁在跑。我认为判断标准只有一条验收看「事办成了没」不看「按钮亮没亮」。功能可用只是起点工作跑通才是终点。同一件事还有几个侧面需求描述从页面加字段改成先写「这项工作是」竞品分析从功能对照表改成谁替用户把事做完交付边界从只对自研模块负责改成要管上下游接口。三、开工第一问这项工作是什么比起多画两个页面我认为先把「这项工作是什么」这一句写出来更划算。第一步在需求文档第一行写一句这项工作是把什么变成什么交给谁。这个问题要求需求明确四件事。输入从哪来、输出去哪先钉首尾按钮留到收尾画。能调哪些工具列出来标出哪些要人工确认。失败怎么让人接手留统一入口不让它静默失败。成功怎么算以事办成为准不凭按钮有反应。第二步看这一句写不写得出来。一句话写不出「工作是什么」说明这一版还在做功能拼装。优先定好输入和输出这个动作最容易被忽略。输入从哪来、输出去哪不定死做到一半才发现要手动搬数据。列工具那一栏也常被漏。不写清楚能调哪些外部系统跑起来才发现中间断了一截。成功怎么算那一栏改成「用户拿到能用的结果」别写「按钮可点击」。需求描述的写法跟着换先写目标、可用工具、跨系统边界、失败兜底再往下拆页面和字段。竞品分析也是同样的思路不看有几个按钮而是看应当替用户把哪件事跑通了。最后在每个新需求评审前应当先把这一句念一遍。答不出的退回重想不进开发排期。这样才能完成「按钮实现了什么功能」到「按钮完成了那些事」的转变。四、剩下的只有第一行把「这项工作是什么」写进需求文档第一行评审时答不上就先回去想。加新功能前先写首尾再画中间。花的是一句把事说清的话不花一版架构。如果这套需求跨系统、跨步骤。一个纯展示页按老办法画就行。功能可以一件件加工作只有办成和没办成两种。验收表上那一行改了后面才跟着改。回过头看并不是按钮做得不好而是验收表上那一行从没改过。「按钮可点击」这五个字一亮后面所有排期都按零件排。令人唏嘘。