Eon.

01 / 背景

问题

外展工具可以轻松发送更多内容。这往往是错误的目标。大量发送的通用消息会损害发件人的名誉，而未经检查而写入的自主代理可能会将一个小列表变成一种责任。有用的问题不是数量。它帮助一个小团队在不失去判断力的情况下进行仔细的推广，这使得它值得一读。

Eon 是作为一个解决这个问题的私人系统而建立的：首先进行研究，然后是草稿，在任何事情离开之前都有一个人在最后的位置。

02 / 受众

它是为谁而设

一个小团队需要联系合适的人，但无法花一天的时间为每条消息收集上下文。作品仍然属于一个人。 Eon 删除了围绕决策的重复收集和格式化，而不是决策。

03 / 限制

塑造构建的约束

系统必须知道索赔来自哪里。由错误的人或捏造的事实组成的个人资料比没有个人资料更糟糕。批准步骤必须足够快才能使用，预算必须在活动发生意外之前停止活动。

该构建是自托管的，因此操作员可以控制数据和发送路径。这种选择增加了运营工作：部署、存储和交付必须成为产品的一部分，而不是事后才想到的。

04 / 构建

我们建造了什么

Eon 是一系列小的、可检查的步骤：

• 一个研究队列，用于组装消息的源配置文件和上下文。
• 草稿和批准屏幕，人们可以在其中编辑、拒绝或发送。
• 在到达网络之前限制工作的活动预算。
• 记录发送内容、发送对象以及批准情况。
• 基于 Docker 和 Linux 的自托管部署。

05 / 决策

困难的部分

有趣的限制是写不出好句子。它将证据保留在判决中，并使批准状态无法跳过。可以绕过的队列不是控件。仅存在于电子表格中的预算不是预算。

该系统还必须在小清单上保持有用。如果研究步骤比手动阅读相同页面花费的时间更长，则该工具没有完成其工作。

06 / 结果

为什么没有公共链接

Eon 是私人建筑。没有公开的演示，并且此页面并不假装有。此处进行案例研究是因为设计决策非常有用：人工批准、预算和可靠记录从一开始就可以成为人工智能工作流程的一部分。