从RAG智能体构想到VBA原型：原始数据与衍生数据的分离

这个计划相当简单：打造一个简化版的Merge，即一个个人专用的人工智能代理。当时已经开始了针对RAG、LangChain、LangGraph、嵌入技术以及向量存储的实验，最初的设想是让该代理具备长期记忆功能并能访问内部文档。但随后出现了其他问题——自由职业项目管理变得混乱不堪，这促使他们决定先编写一个简单的VBA工具。看似容易，实际上却并非如此。在开发过程中，这个VBA原型逐渐演变成了另一种工具，用于研究未来人工智能代理可能会继承的业务逻辑。

那些无法遵循标准生命周期的项目

自由职业的工作并非一成不变。页面刚发布，客户就要求重新设计；业务方向发生变化，接着又需要支付集成功能，之后是LINE自动化功能，还有相关项目。从财务角度来看，某个任务可能已经完成并开具账单，而整个项目仍在进行中。维护合同的情况更为特殊，因为很多合同会一直持续到客户表示不再需要为止。

一个状态字段无法描述这一切，而多个独立的状态维度则可以：

billing_status = closed
task_status = active
invoice_status = pending

一起阅读后可知，金额已确定，任务仍处于进行中，且发票尚未开具。否则就需要二十种手动定义的组合状态。独立的字段使得模型更加简洁。

职责分离

经过几天的思考后，出现了一条分层规则：

Raw Data
   ↓
Small Logic
   ↓
Secondary Data
   ↓
END

原始数据包含事实信息，而衍生数据则包含为人类视觉设计的计算或转换后的信息。有一条铁律：不允许存在三级数据。衍生表格绝不能用于进一步的计算。当需要新结果时，必须回到原始数据并生成另一组衍生数据。这最终可能会产生许多衍生表格，但这是可以接受的。二十个独立的视图远胜于这样的链条结构：

Raw
 ↓
Secondary A
 ↓
Secondary B
 ↓
Secondary C
 ↓
Dashboard

因为中间的一个错误会蔓延到各个地方。其工作原理是：工作表数量越多越好，但过深的依赖关系则不可取。

严格的工作簿结构

工作表按职责划分，并采用前缀约定：

D_ = Raw Data
M_ = Master Data
S_ = System Rules
V_ = Secondary Views

原始数据表长这样：

D_Task
D_Point
D_Pharmacy

还有像这样的主表：

M_Company
M_Project
M_Contact
M_Product
M_GroupS_SystemV_TaskList
V_MonthlyBilling
V_CurrentSummary

D_ 类工作表是真实数据的来源。M_ 类工作表则是涵盖公司、产品、项目及联系人的业务词典。S_System 中存储着与 VBA 相关的配置信息：税率、各状态的含义、每小时费率以及收入目标。V_ 前缀的工作表仅为临时输出结果，可根据需求重新生成，其存在目的是供人阅读，而非供其他公式引用。

禁止直接编辑

还有另一条规则：正常操作过程中绝不应要求任何人手动编辑原始数据或主工作表。UserForms 负责记录的创建、更新以及逻辑上的删除操作，这种删除并非物理上的删除，而是通过标记来处理：

record_status = deleted

该记录会保留在系统中，这样便更便于追溯历史记录，同时也能避免数据意外丢失。

VBA作为监控工具

正是在这一点上，整个项目的方向发生了变化。VBA最初是为了自动化工作流程而设计的，但它更好的用途或许是用于监控流程。系统能够计算出预期的项目收入和药剂师的预期收入、还需要多少额外收入、每个项目还剩多少任务、哪些发票尚未发送、每个项目的当前进展以及已消耗的积分数量。

看到这些数据后就会做出相应决策，比如判定下个月无需增加药剂师的工作班次。若询问 Merge 是如何做出该决策的，如今的诚实答案大概是“经验”。这正是该决策尚未实现自动化的原因。系统应始终如一地显示相同信息，经过足够多的实际使用后，决策中的规律或许就会显现出来。这些规律随后可以被导入 Python，最终用于构建智能代理。可能的进展路径如下：

Raw Data
   ↓
Python Logic
   ↓
Secondary Information
   ↓
AI Agent
   ↕
Human adjustment through Slack

因此，VBA版本并不一定是最终的应用程序。它只是一个实验室，用于确定最终应用程序需要掌握哪些功能。

不同的工具，不同的用途

试图将所有功能都整合到一个系统中是错误的。Excel适用于处理数字、账单、状态、记录以及财务数据。Notion则用于存储详细的任务、笔记和项目信息。而实体白板则用来记录需要记住或留意的内容。

从长远来看，这种设计结合了两种呈现方式：一种是类似报告的格式，另一种则是时间线形式，而 Merge 作为主要交流平台存在于 Slack 中。未来的实体 Merge 设备可以通过文本转语音功能将重要的 Slack 消息读出声来。初期它只会输出内容，回复仍需在 Slack 中输入，因为户外环境下的语音识别效果不佳，此前的实验也导致在电脑前说话时音量过大且不自然。而要实现与实体设备的直接语音对话，就需要再次使用 Raspberry Pi。

用户界面变为黑板

经过数天的架构讨论后，团队开始开发第一个UserForm，用于管理群组、公司、项目、联系人及产品。最初的设想是仅供个人使用，外观并不重要。后来选定了一种有趣的字体，背景也进行了更改，还出现了白色分隔线，原本严肃的主数据表界面便变成了黑板风格的样式。Merge认为它带有MergeLab的痕迹，而大家真实的感受则是它还挺可爱的。

在内部管理上，所有规则都非常严格：依赖关系、原始数据的所有权、逻辑删除以及禁止使用三级数据。从视觉效果上看，它就像是在午夜时分有人正在黑板上讲解数据库规范化理论。VBA功能仍然无法使用，但至少这个黑板风格的界面保持了一致性。

经验教训

最重要的教训是，自动化不应从自动化本身开始。首先需要明确哪些信息是真实的，哪些是推导出来的，以及哪些决策仍需依靠人类判断。

表格数量减少并不一定意味着复杂性降低。许多独立的子视图往往比那些包含复杂推导数据链的紧凑结构更易于理解。

不同类型的状态应放在不同的字段中。与其使用多种组合状态，不如通过独立的字段来描述更为复杂的实际情况：

task_status
billing_status
invoice_status
record_status

业务逻辑应与用户界面分离。UserForm负责收集输入并调用可重用的逻辑，工作表则负责触发刷新并显示结果，而各种计算则存在于小型可重用模块中。这样有助于日后更轻松地迁移原型。

最重要的是，原型可以暴露隐藏的决策规则。它不必立即做出所有决策，只需让这些决策可见即可。

下一步计划

当前的首要任务是让VBA能够执行某些操作，从MasterManagementForm开始，该表单用于注册和管理组、公司、项目、联系人及产品。其基本流程如下：

Input
 ↓
Validation
 ↓
Generate ID
 ↓
Create / Update / Logical Delete
 ↓
Master Data

一旦主数据功能正常，接下来就需要为原始表格设置独立的输入表单：

D_Task
D_Point
D_Pharmacy

之后就可以生成第一个二级视图了。目前最重要的有：

V_TaskList
V_MonthlyBilling
V_CurrentSummary

当这些技术能在实际工作中得到应用时，就能清楚地知道哪些视图真的被使用了，哪些只是设想而已。只有当工作流程稳定下来后，使用 Python、Slack 集成以及 AI 智能体进行彻底重构才成为可行的选择。

目前的进展顺序是：先尝试构建基于 RAG 的智能体，接着使用 Excel，然后花几天时间界定数据范围，最后引入黑板机制。软件开发进展顺利。