如何构建内部工具：管理后台、审批与电子表格替代方案

构建内部工具，先选定一个目前让人头疼的工作流程——通常是某份共享电子表格、某个邮件往来或某个聊天频道正在承担数据库的职能——然后把它变成一个小型应用，包含规范的表单、带状态的列表、每个角色正确的权限，以及谁在何时修改了什么的历史记录。AI 应用构建器可以在一个下午内做出可用的第一版。让它成功的关键，是把范围限定在一个工作流程上，并与每天都要使用它的人一起构建。

什么算是内部工具

内部工具是支撑业务运转、并不光鲜的软件。常见类型包括：

更多起步思路，请参见团队内部工具创意。

到底要不要自己构建？

如果一个人维护这份表格、数据量不大、出错的代价也很小，那就保留电子表格。当你注意到以下迹象时，就该构建工具了：

• 人们相互覆盖彼此的修改，或者没人知道哪一份才是最新版本
• 你需要让部分人只能看到或编辑部分数据
• 你已经写了一整页关于如何使用这张表的说明
• 状态变化需要通知某个人，而这些通知却总是被遗漏
• 你需要审计记录——谁批准了这件事，以及什么时候批准的

还有一个中间选项。低代码内部工具平台（如 Retool、Airtable 界面、Softr 等）会在你的数据之上提供现成的构建模块。如果你的数据已经保存在受支持的数据库或电子表格中，并且你想要拖拽式的界面，它们就很适合。而当工作流程很有特点、你希望它的外观和行为完全符合团队需要，或者你希望自己拥有代码时，由 AI 构建的应用会更适合你。关于这个更一般的问题，参见小企业应该自建还是购买软件。

先设计工作流程，再设计界面

在写提示词之前，先把工作流程写成一个简短的故事。以费用审批工具为例：

1. 员工提交一笔费用：金额、分类、日期、说明、收据照片。
2. 其经理收到通知，并批准或带评论拒绝。
3. 超过某一限额的费用还需要财务审批。
4. 财务每周批量把已批准的费用标记为已付款。
5. 每个人都能看到自己费用的状态；财务可以看到全部费用。

从这个故事中可以得出：

• **数据：**费用、用户、角色、审批记录（谁、决定、评论、日期）、附件。
• **状态：**已提交 → 经理已批准 → 财务已批准 → 已付款，或已拒绝。
• **角色：**员工、经理、财务、管理员。
• **规则：**金额阈值，以及谁可以把事项推进到每一种状态。
• **界面：**提交表单、“我的费用”、“等待我审批”、财务的全部费用表格，以及带历史记录的详情页。

用这些术语描述工作流程，AI 就能一次就做对。

权限与历史记录

内部工具通常保存着敏感数据——薪资、客户信息、资金。有两条规则：

1. 每次操作都要在服务器端检查角色。 经理不应该能够直接调用批准接口来批准自己的费用。
2. 记录历史。 保存每一次状态变更和编辑，并注明操作人和时间。这能解决大部分“这是谁改的？”的争论，并且在出问题时极其宝贵。

决定人们如何登录。对于已经在使用公司 Google 或 Microsoft 账户的团队，用这些账户登录很方便；邮箱加密码则在任何地方都适用。无论采用哪种方式，都应限制注册，只允许你的团队成员进入。

一条有效的首条提示词

为一家 25 人的公司构建内部费用审批工具。员工提交费用，包括金额、货币、分类（差旅、餐饮、软件、设备、其他）、日期、说明，并上传收据照片。其经理可以看到“等待我审批”列表，并可以带评论批准或拒绝。超过 500 美元的费用还需要拥有财务角色的人批准。财务可以看到所有费用的表格，支持按状态、人员和月份筛选，并可以把已批准的费用标记为已付款。每一次状态变更都会记录操作人和时间，并在费用详情页以时间线形式展示。角色：员工、经理、财务、管理员——每次操作都在服务器端检查。所有数据保存在数据库中，并预置真实的示例数据。界面简洁、信息密集、速度快——这是一个工作工具，而不是营销网站。

构建步骤

1. 主表和表单，用于核心记录，并预置真实的示例数据，以便搜索和筛选的效果一目了然。
2. 状态与流转，包括谁可以把事项推进到每一种状态。
3. 角色与登录，仅限你的团队使用。
4. 每条记录上的历史日志。
5. 通知——当某件事需要某人处理时，发送邮件或聊天消息。
6. 从现有电子表格导入数据。如何把电子表格变成应用介绍了清洗和导入的方法。
7. 先让两三位真实用户试用一周，再推广给所有人。
8. 在约定日期停用旧流程。 两套系统并行运行，意味着两套都不可信。

让人们真正用起来

很多内部工具本身运行完美，却依然失败，因为人们还在沿用旧的方式。

• 与用户一起构建。 在设计新版本之前，先观察某人今天是如何完成这项工作的。
• 比旧方式更快。 如果提交比发消息花的时间还长，人们就会继续发消息。
• 信息密度胜过美观。 运营人员更喜欢带有良好筛选功能的表格和便于键盘操作的表单，而不是大卡片和大量留白。
• 把下一步操作放在最前面。 “等待我处理”应该是人们第一眼看到的内容。

常见错误

• 把整张电子表格都重建一遍。 只迁移那一个最让人头疼的工作流程；其余部分暂时留在表格里。
• 没有负责人。 上线之后，必须有人负责变更和修复。
• 把权限当作事后补充。 在一个已经完成的工具上再添加角色，比一开始就规划好更难。
• 跳过审计记录，结果第一次出现资金缺失时才发现需要它。
• 在没有登录的情况下发布到公开网址。 任何内部使用的东西都必须要求登录。

上线后如何持续运行

流程每隔几个月就会变化——新增一个审批步骤、一个新分类、一个新团队。从一开始就要为此做好准备：

• 把设置保存在数据表中，而不是代码里。 保存在数据库中的分类、阈值和审批人分配，管理员无需重新构建就能修改。
• 把请求集中收集。 工具中一个简单的“建议修改”链接，胜过分散在各种聊天里的请求。
• 定期导出。 对主要数据表进行 CSV 导出，可以确保数据不会被锁死，也让月末报表变得轻松。
• 每次变更后都要测试。 任何工作流程的修改之后，都要重新走一遍提交、批准和拒绝的流程，因为权限相关的错误往往就出在这些地方。

运行成本

用 AI 构建的内部工具会产生托管费用、数据库费用、文件存储费用（如果人们需要上传文档），以及可能的邮件或消息服务费用（用于通知）。对于你自己拥有的工具，通常没有按席位收取的许可费——当许多偶尔使用的人都需要访问时，这一点很重要。持续的成本是有人花时间去维护它。

用 Mythex 构建

内部工具很适合在 Mythex 上构建。你描述工作流程，代理会在实时预览中把它构建出来，并为记录添加 Postgres 数据库，为收据等上传内容添加文件存储。文档中的内部工具用例和管理后台用例提供了入门提示词。同事可以在你的工作区中一起协作构建，且无需按席位付费。

有两件事需要注意。团队使用该工具时的登录，是你所构建应用的一部分，采用的方式由你选择——它们与 Mythex 账户是分开的。另外，Mythex 不为应用本身内置 Salesforce、HubSpot 或 Slack 集成；这些需要通过各自的 API 并使用你自己的密钥进行连接。如需起始提示词，可以试试审批跟踪或内部管理工具模板；如果你需要的主要是图表，可以参见如何构建仪表盘。

常见问题