16 行业应用需求:企业员工 AI 助理
你好,我是李锟。
在这门课程的进阶篇,我们的一个主要任务是带着前面学习到的知识,设计开发一个中等复杂度的企业级 Autonomous Agent 应用。这个应用应该有足够的代表性,具有 Autonomous Agent 的主要特点。但是这个应用也不能太过复杂,不能包含太多复杂的 AI 算法,导致我们陷入大量的算法细节,也不能包含太多属于传统业务应用的功能,导致我们偏离学习的重点 LLM + AI。
OpenAI 的创始人 Sam Altman 在最近一次访谈中给了开发者一个忠告:要边做边学,别先去学!
我百分百赞同 Sam 的这个观点。因为你认为会有用的知识和技术,很可能对于近期的目标来说完全用不上,甚至永远也用不上。只有带着明确的目标,以这个目标作为衡量标准来有针对地学习,才能学到最实用的知识,并且深度掌握这些知识。举个例子:美国黑人篮球打得非常好,不是因为他们的篮球理论学得好,笔试分数考得高,而是因为他们从小就热爱打篮球,每天反复练习很多个小时。
其实这个观点就是我一向坚持的学以致用的“剑宗模式”。我们这门课程,也是坚持边学边做,以可运行的例子驱动。这是这门课相当与众不同之处,夸夸其谈的教程实在太多,确实不缺我们这一套。
经过仔细考虑,我决定设计开发一个面向企业员工的 AI 助理。这个 AI 助理的设计思想来自于著名的时间管理方法——GTD(Getting Things Done),因此我们需要对 GTD 先有一些了解。
最有效的时间管理方法——GTD
流行的时间管理方法有很多,除了 GTD 之外还有番茄工作法、单核工作法等等。但是在全面性和有效性方面最强的还是 GTD。
GTD 简介
GTD 这套时间管理方法,来自于美国时间管理大师 David Allen 的著作《搞定》(英文名为 Getting Things Done)。关于 GTD 的科普文章网上有很多,我推荐两篇写得不错的:
然而大多数人严格按照《搞定》书中的方法来做时间管理,很难长期坚持下来,因为这本书写得确实太复杂了。不仅如此,关于 GTD,David Allen 其实一共写了三本书,包括:
- 《搞定1:无压工作的艺术》
- 《搞定2:提升工作与生活效率的52项原则》
- 《搞定3:平衡工作与生活的艺术》
如果一定要把这三本书都仔细读完才能开始做 GTD,那么 GTD 其实也没有那么重要了,而且这种做法严重违背了 Sam Altman 强调“边做边学”的忠告。幸运的是 GTD 其实上手不是很复杂。
按照挑战全网最清晰 GTD 教程这篇文章说的,我们要做的事情可以划分为“梦想”和“琐事”两大类。
如图所示,在 GTD 中,把琐事和梦想分得更为细致。琐事可以分为行动(action)和项目(project)。行动指一个动作(步骤)就能完成的事;项目是多个动作(步骤)才能完成的事,包括了多个行动。梦想又可以分为:宗旨和原则、愿景、目标、关注和责任范围。
应用 GTD 一共有 5 个步骤:
- 收集:将大脑清空,把所有要做的事情放入收集篮。这一步不要太在意条目的格式和严谨。可能只是临时想到的一个好点子,用口语化方式先记下来。要做的事包括梦想和琐事两大类。属于梦想的事情可能只是一个愿景或目标,而不是具体的行动。
- 整理:对要做的事情进行加工,找到下一步行动(next action)。每个行动的粒度尽量小一些,通常不要超过 1 天时间。某件事情如果需要多个动作才能完成,可以把这些行动组织到项目中。给行动和项目加上适当的标签(label)。
- 组织:将加工好的行动和项目放入你自己的检查清单(check list)系统内,做到各就各位。检查清单划分为以下两大类:
-
可操作类
-
等待列表:你委派给其他人执行的所有任务。
- 下一步行动清单:需要完成但没有截止日期的行动。
- 日历:要在特定日期或时间完成的操作。
-
不可操作类
-
垃圾箱:不值得你花时间且不需要任何关注的条目将移至垃圾箱列表中。
- 参考资料:此列表包含不需要任何操作但在不久的将来某个时候可能需要的所有有用的信息。
- 某天/也许列表:你不确定是否应该立即完成的所有任务的类别。把它们收集起来,但要定期检查它们,看看是否需要采取任何行动。
- 回顾:有规律性地回顾你的检查清单,时刻保持大脑空白状态。这时候主要做三件事:一是查看所有条目的进度。二是确定下一步需要做什么。三是确定待办事项是不是需要调整。
- 执行:利用你的检查清单以及标签,在合适的时间、环境做适合的事情。
传统 GTD 应用存在的问题
尽管 GTD 是一套非常完善的时间管理方法,其有效性得到了广泛认可,然而能长期坚持 GTD 的人却不多。我来分析一下具体原因。
应用 GTD 有两种方式:一是基于纸条-卡片-收集篮等办公用品:不使用应用软件,而是使用纸条-卡片-收集篮等办公用品。其优点是无使用门槛,容易上手。缺点是只能放在固定位置 (例如办公室内的办公桌上),不利于随时随地记录想到的事情,也不便于回顾。
二是基于应用软件,优点是可以支持手机等移动设备,便于随时随地记录想到的事情,也便于回顾。缺点是会有一些使用门槛。
上面应用 GTD 的第一种方式,缺点很明显,这些缺点足以让大多数用户无法坚持。我们可以完全忽略第一种方式,我分析一下第二种方式为何用户也很难坚持。
不考虑所有人都有的惰性问题,用户难以长期坚持使用传统 GTD 应用的原因有很多:
- 录入过程比较繁琐,而且只支持文本录入,不支持多模态如语音、图片方式的录入。
- 支持的输出和通知类别太少。
- 不具有多端支持,无法全面覆盖到电脑(台式机 + 笔记本)、智能手机等设备,导致包围度不够。
- 无法连接数据库,从数据库中查询到任务相关内容,自动生成报表和图表。
- 无法与外部工具相连接,通过调用外部工具方便地完成一些任务。
- 无法自动完成回顾,例如周期性生成回顾报告。
- 只能被动地执行,无法主动提出改进时间管理的建议。
上述的这些问题,有一些是属于单纯的用户体验的问题,基于传统技术也不难解决。还有一些是与自动化、自主性相关的问题,这就需要借助于一些现代 AI 技术了。如果只采用传统技术,这些问题解决起来会很复杂,而且很笨拙。
除了传统的 GTD 应用外,还有一类更加简单的传统行事历应用。其实我们可以把行事历中的条目看作是 GTD 中与时间相关的条目,需要在特定时间完成,或者在特定时间之前、之后完成。也就是上面介绍 GTD 时提到过的日历相关条目。这样看来,行事历应用的相关功能完全可以被包含在 GTD 应用的范围内。
有了 LLM 和现代 AI 技术的支持,我们有可能开发一个高度智能的新型 GTD 应用。在 David Allen 的书里面,他是希望 GTD 事无巨细把要做的事情全部收集起来,并且进行统一规划。不过我们开发的这个企业员工 AI 助理,可以看作是 GTD 的一个子集,只包括工作时间内要做的事情。
我与 David Allen 有一个不同观点:把工作内容与生活、家庭内容分开,其实更有利于完成工作和生活目标。假如完全混在一起,往往会互相影响。我们未来也许可以开发另一个私人生活的 AI 助理,不过现在先聚焦于工作内容。
以下我们把这个应用简称为“AI 助理”。AI 助理的需求可以划分为功能性需求和非功能性需求两大部分,我们先讨论功能性需求。
AI 助理的功能性需求
AI 助理首先需要实现传统 GTD 应用的那些基本功能。包括支持前面介绍的“收集-整理-组织-回顾-执行”的 GTD 五大步骤。这些基本功能都与 AI 无关,因此我就不赘述了。只介绍一下在基本功能之外,对传统 GTD 应用的增强部分。
AI 助理需要实现以下与 AI 相关的功能:
对于企业级 GTD 应用来说,与面向个人用户的 GTD 应用相比,有一个主要差异是要支持团队协作。最基础的功能是支持把多个员工的行动组织在一个项目中,多个员工共同完成一个项目。
为了改善应用的用户体验,并且提高包围度,AI 助理还需要实现以下功能:
AI 助理的非功能性需求
除了功能性需求外,还需要考虑一些非功能性需求。对于一个需要支持高并发、高可用性的在线服务来说,非功能性需求的工作量甚至会占有系统开发工作量的三分之一以上,因此需要事先详细讨论并形成文档。打个比喻,非功能性需求就像是冰山在水面之下的部分,平时是看不到的。如果一个产品负责人只看到水面之上的部分,他就会盲目乐观,急功近利,最后往往会导致产品的失败。
对于一个运行于企业私有云或局域网环境的 AI 助理来说,非功能性需求不是很多,主要包括三个方面:
- 安全相关:需要确保系统的安全,免遭黑客的入侵和攻击,而且数据不会泄漏。
- 运维相关:对系统运行状态做监控,确保系统的高可用性。
- 配置管理相关:应用软件的版本管理,维护配置管理数据库(CMDB)。
AI 助理 UseCase 图
前面讨论的功能性需求和非功能性需求只是一个粗略的规划,并非正式的软件需求文档。需要强调的是,需求规划不能替代正式的软件需求文档。编写软件需求文档的标准做法是编写用例(Use Case)。我推荐你课后读一下 Alistair Cockburn 的经典著作《编写有效用例》(Writing Effective Use Cases)。
这里我只把主要用例的 UseCase 图画出来。UseCase 图相当于是用例的清单,它无法取代用例本身。画完了 UseCase 图,仍然需要下功夫写好用例的文字描述。这个工作虽然繁琐,但是不要偷懒忽略这个工作。因为应用软件需求的质量,会直接影响实现的质量。如果进入了实现阶段才发现需求存在严重问题,那个时候纠错的成本是很高的。
画 UseCase 图的第一步是确定系统相关的 Actor 有哪些。这里的 Actor 就是将会与这个应用发生交互的那些用户角色,除了人类用户外,也可以是其他应用或系统。AI 助理相关的 Actor 比较少,初期可以只设置企业员工、系统管理员两个。以后随着系统的完善再适当划分更多的 Actor。
企业员工相关的 UseCase 图如下:
系统管理员相关的UseCase图如下:
总结时刻
在这一课中,我带你扮演了一位 AI 产品经理的角色。首先我介绍了流行的时间管理方法——GTD 的基本概念和步骤,然后分析了传统 GTD 应用难以坚持使用的原因。接下来利用我们学习到的 LLM 与 AI 相关技术,设计了一个新型的 GTD 应用——企业员工 AI 助理。我们一起对这个应用的功能性需求、非功能性需求做了规划,并且画出了相关 UseCase 图。
在下节课,我们将扮演应用架构师的角色,基于这节课提出的需求,完成企业员工 AI 助理的技术选型和技术架构设计。
思考题
LLM 和 AI 技术为何能够解决传统 GTD 应用存在的问题?请你聊一聊你的看法并分享到留言区,我们一起交流,如果你觉得这节课的内容对你有帮助的话,也欢迎你分享给其他朋友,我们下节课再见!