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