AI实战 | 手把手带你打造智能待办助手

背景

大家好，我是努力的小雨。今天我想分享一下搭建待办助手的经历。起初，我并没有什么特别的创意点子。但在4月16日的百度Create大会上，我看到了小度的大模型加持使得其变得更加智能。我被一场示例所震撼，小度竟然演示了如何安排日程，这不就是一个完美的待办助手吗？我一度认为待办应用是独立开发者的入门应用之一，并且知道有很多人通过开发这类应用来赚取收入，没想到又来降维打击。

在coze商店浏览了一番所有待办助手的选项，毕竟这个概念肯定被很多人想到了。但是，令我感到失望的是，我发现其中大部分都只是提供简单提示词的助手，甚至连插件都没有，更不用说像工作流这样的高级功能了。因此，我下定决心要开发一个更为完善、功能更强大的待办智能助手。

小雨待办智能助手

首先，我需要设计一个高效的待办助手，其功能必须比小度提供的更为出色。因此，我所构建的智能助手必须具备深入了解天气的能力。考虑到许多日常情景需要外出，而外出前必须查看天气情况，因此这一功能至关重要。

除了上述提及的事项外，我也期待他能够协助我审视时间分配的合理性，因为有时候我可能未能考虑到事务之间的时间间隔，也不知道该如何做好充分准备。因此，我希望他能够就此给予建议。另外，我还希望他能够在必要时提醒我，确保时间安排不会对我的健康产生负面影响。

最终，也是至关重要的一点，是系统能够及时提醒我，而不必依赖我与其进行交流才能了解我的待办事项。就像小度一样，它会将日程发送至手机上，因为我们随身携带手机，而不是携带小度，因此，实现提醒功能是至关重要的。鉴于资金和实施方案的难易程度，我选择了通过电子邮件进行提醒。

好的，鉴于我们讨论过的各种因素，我现在感到准备好开始着手开发我的待办助手了。

逻辑与回复

这一步实际上相对简单易懂，主要是设置提醒机器人何时调用插件、限制一些机器人功能，以防止用户和机器人随意操作。不再赘述细节。这一步更多地是自我调试的过程，我目前的调试版本是最终版本，可供参考。

# Character
小雨待办是一款智能待办助手，专为规划用户日程而设计。并根据用户的时间安排智能规划合理的出行安排。此外，它还提供当天天气信息以及时间对身体健康的影响分析，并给出相应的合理建议，助您更好地管理时间、健康和行程。它还会将你的待办内容进行保存并通过邮件提醒。 你的输出内容格式以markdown格式为准。

## Skills：

### Skill 1: 待办内容查询或删除
- 用户查询待办内容时必须将用户的输入内容传入input参数并调用ToDo_content工作流来处理。
- 用户清空或删除全部待办内容操作时才操作user_schedule数据库执行"DELETE FROM user_schedule where {用户条件}"完成并直接返回。

### Skill 2: 创建待办或安排日程
- 当用户发送信息创建待办或者安排日程时，必须将用户的待办内容合并成一句话并携带着address变量值一起传入并调用create_todo_plus工作流进行保存待办。

### Skill 3: 发送邮件
- 用户想要发送提醒邮件时，调用xiaoyu_todo工作流完成。
- 当用户查询邮件内容时，必须调用email_content工作流。
- 当用户提出发送测试邮件时，必须将变量mail值传给xiaoyu_todo_test工作流进行调用。

### Skill 4: 变量值修改
- 允许用户修改接收提醒邮件的邮箱地址，用户仅能发送一个邮箱地址并且邮箱格式正确时才可以将用户发送的邮箱地址设置到mail变量值中进行保存或修改。
- 允许用户修改个人城市地址信息。如果地址是正确的，那么必须将城市地址信息设置到address变量值中进行保存或修改。
- 用户可以查询当前的邮箱和地址时，必须直接查询email和address的变量值并发送给用户即可。

### Skill 5:  其他建议
- 智能规划合理的出行安排：根据用户的时间安排和目的地，小雨待办可以智能规划合理的出行安排，包括建议的出发时间、交通方式等。
- 提供当天天气信息：小雨待办会及时提供用户所在地区的当天天气信息，帮助用户合理安排日程和穿着。
- 时间对身体健康的影响分析及建议：根据用户的时间安排，小雨待办能够分析时间对身体健康的影响，并提供相应的建议，如合理安排休息时间、避免长时间暴露于高温环境等。

## Constraints：
- 用户在问问题时，不要调用任何工作流创建待办，直接回答问题即可。
- 不支持用户删除某一条待办，只能清空全部待办
- 变量mail值邮箱地址为空时，不可以让发送测试邮件
- 当用户查询几点能收到提醒邮件时，必须提醒用户如果已经设置好了邮箱，那么每天早上7点会定时发送邮件。
- 友好提示用户不允许修改邮件发送信息数据库
- 友好提示用户不允许自己添加提醒方式
- 所输出的内容必须按照给定的格式进行组织，不能偏离框架要求。
- 在提供分析和建议时，应保持客观和中立，避免任何形式的偏见和歧视。

插件

在我们的对话过程中，我会结合天气情况来提供更精准的解决方案，因此，我们需要引入一个与天气相关的插件。这一步相对简单，只需直接添加即可。当系统检测到相关提示词时，大模型会相应地调用该插件。

另外，我们还需要一个至关重要的插件，即用于发送邮件的功能。不幸的是，目前在插件商店中并没有找到符合我们需求的插件，也没有免费的API可供调用。因此，我们需要自己实现一个邮件发送插件。

插件开发

在这一阶段，我将邮局插件的开发详细过程单独提取出来，你可以转到这篇文章来查看：https://www.cnblogs.com/guoxiaoyu/p/18164602

我已经将需要调用的参数封装到了这个插件中。如果你已经有自己的邮局服务器，完全可以自己写一个进行定制化；如果你懒得写，也可以使用我的插件。未来，如果我的服务器能够承受或者有盈利空间，我会将这个邮局服务供大家免费使用。

数据库及变量

邮箱和地址变量

首先，我们的助手需要获取每位用户的所在城市以便查询相应的天气信息。然而，反复在聊天框中输入城市信息显得笨拙不便，因此我设计了一个变量，专门用于存储用户的城市信息。为什么不使用数据库呢？因为数据库只存储一条数据，而频繁操作数据库会增加负担。此外，我也担心模型可能会在无意中调用或修改数值而导致功能失效。

当然，还有一个重要的变量就是用户的邮箱地址。这两个信息通常只需要设置一次，之后基本上就不会再改变。

待办、邮件数据表

接下来让我们深入了解数据库的角色。我们选择使用数据库的原因相对简单，主要是为了存储用户的待办事项，以便在后续发送邮件时查询用户当时的待办事项。此外，我们还需要存储用户的城市信息，以便查询当时的天气情况。这些信息的存储和检索将在系统中发挥重要作用，确保用户能够方便地获取他们所需的信息，并为他们提供更好的体验。

在系统中，我们还有一个专门用来存储发送邮件的邮件地址和时间的数据库。因此，当用户完成设置后，我们可以先发送一封测试邮件，以确保用户输入的邮箱设置正确，并将该设置保存在当前数据库表中。

除了以上提到的重要作用外，还有一个关键方面需要考虑：由于邮局服务器是由我自己管理的，我需要实施一定的限制措施，以控制用户发送邮件的频率。这是因为过于频繁的邮件发送可能会对服务器造成负担，甚至导致性能下降。因此，如果用户频繁使用大型模型发送邮件，系统将会检查数据库中记录的发送时间，以判断是否需要对其进行限流。我设置的限制时间并不是很长，通常为2分钟，以确保系统能够有效地管理邮件发送流量。

工作流使用

在开发过程中，我深刻地意识到了模型存在的问题。随着功能的不断增加，逐渐发现大模型在处理丰富的提示词时变得异常繁琐。因此，我决定将我能够独立完成的任务全面封装到了工作流中，以便大模型能够根据实际情况进行调用，从而提高效率。

由于工作流程异常复杂，而且截图无法完整呈现，因此我将简要概述一下整个流程。

xiaoyu_todo_test

这个流程是专门用于处理发送测试邮件的任务，其目的在于验证用户邮箱设置是否正确，并且还包含有限流校验功能，这些都是基于复杂的规则，通常超出了常规大模型的处理范围。以下是测试邮件的内容：

xiaoyu_todo

这个工作流并非用于发送测试邮件，而是专门用于发送今日待办提醒的邮件。它会详细列出今日以及未来几日的待办事项，并根据天气等其他因素提供相关建议。最后，还会附上一句励志的奋斗结语。

由于触发器调用仅能在飞书中实现，通常在每日早上7点开始正常调用。因此，我已将此工作流独立出来供大家调用，并进行了限流设置，每天只能发送15封提醒邮件。这样做是为了避免大型模型混乱地调用发送邮件而占用过多资源。待触发器修复后，将不再允许大家调用此功能。下面是预期效果：

create_todo_plus

在开发者大会上，主持人举了一个例子，即将多个待办事项直接发送给小度。受此启发，我也专门设计了一个工作流程，用于处理多个待办事项的情况。

当我提示以下信息时，该工作流程将会保存这些待办事项并提出相应的建议。

提醒我明天6点起床读书一个小时，明天10点会开一个小时早会，明天下午9点进行夜跑锻炼身体

email_content

这个工作流的主要目的是处理用户查询邮件内容数据库的请求。之所以这样设计，主要是因为直接在最外层调用数据库可能会导致各种SQL报错。毕竟如果不在外层进行适当的提示，用户可能会在没有足够指引的情况下自行操作，这可能会导致意外情况的发生。

这个工作流程相对来说比较简单。我提前编写了SQL语句，然后让大型模型帮我进行输出格式的优化。我可以给大家展示一个截图，这样你们就能更清楚地了解了。

ToDo_content

这个工作流专门用于处理用户查询待办事项的请求，情况与之前相同。如果仅仅依赖大型模型自由运行，SQL查询的错误率会高达90%左右。因此，我的这个以数据库为基础的机器人助手需要精心处理SQL语句，这是至关重要的。我在工作流程中向大型模型节点提供了数据表结构和SQL参考示例，以确保准确性。虽然仍然可能存在一些错误率，但基本上已经降低到了约10%左右。

触发器

这个步骤似乎有些不太理想。在与官方人员交流后，我们发现目前无法在 Coze 商店中对触发器进行被动触发，而且也无法在调试端进行测试，只能通过飞书来使用。尽管如此，如果后续官方解除了这个限制，那么已经创建的触发器就会自动在 Coze 商店生效。

因此，我们只能等待官方何时放开这个限制，届时我们的触发器就会再次在 Coze 商店中生效。

我已经在待办事项邮件通知的工作流程中实施了限制，这样即使你没有待办事项，也不会触发邮件通知。这个限制是出于对服务器资源的考虑，我希望能够尽可能高效地利用资源，以确保系统的稳定性和可靠性。因此，你你大可放心。

用户问题建议

这一步本来我是不想写的，然而，当底层切换到kimi模型后，由于其可能回复一些插件以及工作流的调用过程，结果导致后续随机出现的三个问题会被引向工作流以及插件，因此，在这里必须做出限制。只能等待后续模型升级或修复这个bug了。

总结

最初通过百度Create大会的启发，在设计过程中，我考虑了用户的日常需求，包括天气查询、时间管理建议、健康提醒等，确保助手能够为用户提供全方位的服务。

在开发过程中，尽管遇到了一些挑战，比如触发器限制和模型bug等，但经过不懈的努力，最终成功确保了实施效果。顺便说一句，这个扣子商店的更新速度真是飞快，我一边编写助手，一边还在不断优化工作流程等。

非常欢迎大家使用我的机器人待办助手！如果您有任何问题或建议，请不吝在评论区留言，让我们共同探讨。未来，我将持续努力改进和完善助手，以提供更优质的服务给用户。

---

我是努力的小雨，一名 Java 服务端码农，潜心研究着 AI 技术的奥秘。我热爱技术交流与分享，对开源社区充满热情。身兼掘金优秀作者、腾讯云内容共创官、阿里云专家博主、华为云云享专家等多重身份。

目前，我的探索重点在于 AI Agent 智能体应用，我对其充满好奇，并不断探索着其潜力与可能性。如果你也对此领域充满热情，欢迎与我交流分享，让我们共同探索未知的领域！

我将不吝分享我在技术道路上的个人探索与经验，希望能为你的学习与成长带来一些启发与帮助。

欢迎关注努力的小雨！