AI 项目生产维护：如何应对「第二天」问题

“你做的那个东西宕了——我们该怎么修？”

尽管发布一个用 AI 打造的作品会让人无比兴奋，但如果你真的独立上线过几个项目，应该很熟悉那种感觉：东西一出故障，心里顿时一沉。又或者，当自己做出来的东西开始扩张，而你却不太确定该如何应对时，那种挥之不去的不安。

如果你没有技术背景，这种情况可能会彻底打断你的节奏。LLM 能帮助我们创造的东西充满无限可能，但大多数 AI 工具并不是为了教你理解底层基础设施如何运作而设计的。因此，当系统分崩离析时，你往往很难弄清楚究竟发生了什么，又为什么会发生。

先说清楚：你完全不必因此感到难为情！直接上手开始构建，通常就是最好的学习方式。你可能正在尝试解决一些过去甚至不知道其存在的问题，也很可能连自己想做的事情叫什么都不知道。

这正是我想提供帮助的地方。我目前是一名营销人员，但我的职业生涯始于软件工程领域：我取得了计算机科学学位，做了多年开发，之后才转行。因此，我能从一个独特的视角看出这些事情究竟错在了哪里。而这种“东西做出来了，却在后续运行中崩掉”的挑战，就是一个绝佳的例子。

因为对软件构建者来说，这并不是什么新问题。事实上，这是个经典问题。我们甚至专门为它起了一个名字：朋友们，这就是 Day 2 Problem。

具体是什么意思？

Day 2 Problem，指的是产品在完成规划（Day 0）和初始构建（Day 1）之后，在持续发展和维护过程中出现的长期问题与挑战。

如果你还不太能想象我说的是什么，下面来看一个例子。

Dave 糟糕透顶的一周

来认识一下 Dave。他在一家拥有 100 多名员工的公司里负责财务，做事积极主动。所有人都喜欢 Dave。他不是工程师，却总爱尝试新软件，而且已经开始教团队里的其他人如何使用 AI 构建东西。

这一周，事情出了岔子。非常严重的岔子。

Dave 的团队被发票淹没了。供应商通过电子邮件发送 PDF，但之后仍然需要有人把里面的信息手动录入系统。这件事耗时极长，导致所有人的工作都积压了好几个星期。

于是，经过周末的一番思考，Dave 在周一早上一上班就立刻行动起来。借助一款 AI 工具，他构建了一套自动化流程：发票到达后，AI 扫描 PDF，提取关键信息并上传。如果发现内容看起来不对，它甚至还会进行标记。

Dave，好样的！所有人都对他刮目相看，他的老板还对他说：“这正是我们可以拿来帮你争取那次晋升的成果——我们一直都在努力帮你推动这件事。”下班开车回家的路上，Dave 高兴得简直要在车里跳起舞来。

第二天一早，应付账款团队就给 Dave 发来消息：有 3 张发票录入了错误的金额，而且差得可不是一点点。Dave 手忙脚乱地开始调查：是 AI 误读了 PDF？还是没有把信息正确上传到系统？

他打开自己的自动化流程，却发现……根本无从得知。系统没有留下 AI 在每一步做了什么的记录，只显示了一句“Automation complete.”

于是 Dave 开始四处排查。他调整了几个地方，终于找到了问题。幸运的是，问题不大，他很快修好并更新了自动化流程。

新版本上线后，他跑了一次测试。……结果无法运行。糟了，这次更严重。该使出 Control-Alt-Delete 了！他回到系统中，想恢复到之前的版本，却发现根本没有这个功能。他修改的是唯一的版本，除此之外什么都没有。

接下来的几个小时里，Dave 重新构建了原始版本，然后再加入新的修复。整个下午剩余的时间，他都在反复检查，确保一切正常，直到临下班前才完成更新。

现在应该都修好了吧？

Dave 整个下午都被一场接一场的会议占满。下午 2 点，自动化程序提示需要更新。错误信息说，只需要重置一下即可。他的同事 Marco 主动提出可以帮忙处理。

但是……该去哪里操作？这件事一直都是 Dave 在做。到底要怎样才能进入编辑器？没有任何文档。等 Marco 好不容易找到一个知道操作方法的人时，又发现登录凭据绑定的是 Dave 的邮箱，而且密码还不是 Password123。

Marco 给 Dave 发了短信。此时的 Dave 正在一场季度规划会议上假装认真听讲，只能偷偷在桌子下面回复操作说明。整个过程并不顺利。那些发票就这样一直搁置，直到 4 点半 Dave 才终于有空。

至少问题在 4 点 31 分解决了！

Dave 的老板依然相信这个项目！她看到了它的前景，也知道它已经为团队节省了大量时间。于是，她顺理成章地问出了下一个问题：“我们能不能也把它推广到 Austin 办公室？”

Dave 打开自动化流程，心里顿时一沉。所有东西都是硬编码的：一个电子邮件收件箱、一套供应商格式、一条连接到某个会计系统的通道。要让它适用于 Austin，他需要做的远不只是调整几个设置，基本上得从头重建。又一次。

他对老板说：“当然，没问题！”然后取消了下班后的安排，留下来完成这项工作。

一帆风顺！经历了这么多波折之后，一切似乎终于正常运行了。

直到下午 3 点，一家供应商打来电话：他们的发票这周还没有付款。Dave 检查后发现，自动化流程根本没有处理这张发票。因为无法解析它的格式，系统就直接……跳过了。没有报错，没有标记，什么都没有。

更糟糕的是：这还不是唯一一张。Dave 继续深挖，发现这一周还有 11 张发票以同样的方式被悄无声息地跳过了。这一周的每一天，当他忙着排查那些看得见的问题时，还有更多他看不见的问题正在发生。

他的老板走了过来。开车回家时，Dave 已经完全没有跳舞的心情了。

Dave 遇到了一大堆 Day 2 Problem

大多数“Day 2”问题并不会真的发生在第二天。但东西以意想不到的方式出故障，或者在首次发布后需要更新，这些情况都无法避免。

坏消息是：原本可能出问题的地方远不止这些。安全问题怎么办？如果 AI model 更新后突然开始给出截然不同的输出，又该怎么办？系统运行得越久，分崩离析的风险就越高。

不过幸运的是，我也有一个非常好的消息：这并不是一个新问题！软件工程师已经和 Day 2 问题打了几十年的交道。你可以借鉴他们的经验，避免让自己遭受许多不必要的折磨。

那么，具体应该怎么做？

对于我的所有朋友、同事以及互联网上的陌生人，我最重要的一条建议是：

我们该如何解决这个问题？靠提问

Day 2 问题真正的根源，是缺乏认知。

Dave 遇到的大多数问题其实并没有那么难修复。只是直到问题真正发生、自己不得不手忙脚乱地补救时，他才意识到这些事情原来可能成为问题。就像我在开头说的：我不会责怪 Dave，也不会责怪你。你无法知道自己不知道什么。

Dave 在周一时本该问的问题

其实，Dave 和他的团队有一件事做对了：他们知道这套系统归谁负责。在考虑其他事情之前，先确保这一点足够明确。

早在 2006 年，Amazon 的 Werner Vogels 就提出过一句著名的原则：“You build it, you run it.”

如果你并不适合亲自维护并长期支撑自己正在构建的东西，就必须非常明确地确定：那谁才是合适的人？因此，无论负责人是你，还是你和另一个未来会接手的人，都应该在经历 Dave 那样的一周之前，先问问自己下面这些问题：

我该如何追踪系统在每一步做了什么？

Dave 无法判断究竟是 AI 误读了 PDF，还是上传失败，因为整个过程中没有记录任何输入和输出。任何需要持续运行的项目，都应该具备一定程度的可追溯性，让你能够查到过去发生了什么。（厚着脸皮插播一句：这正是人们喜欢使用 n8n 的主要原因之一。可视化 workflow 能让你更轻松地看出问题出在哪里，而且 n8n 会记录每次执行中每一个步骤的所有输入和输出。）

变更应该如何进行？我又该如何撤销变更？

Dave 修改了自己唯一的一份副本，之后便再也无法恢复。在发布之前，你需要确定：不同版本保存在哪里？能否快速回滚更新？能否在非生产环境中测试变更？

还有谁需要访问？他们应该能够执行哪些操作？

Marco 无法提供帮助，因为登录凭据属于 Dave，而所有系统逻辑也都只存在于 Dave 的脑子里。如果其他人将来需要使用或依赖这套系统，就要准备共享凭据、设置权限级别，并提供足够的文档，让别人无须给你发短信也能操作它。

未来可能需要怎样扩展？

Dave 的老板要求扩大项目的应用范围，结果整套系统都得重新构建。在动手之前，先问问自己：它将来是否会扩展？会扩展到什么程度？从一开始就考虑这些问题，远比日后再改造便宜得多。

我怎样才能知道系统是否正常运行？

Dave 的自动化流程整个星期看起来都没问题，实际上却在暗中跳过发票。如果你的系统需要在后台运行，就必须确保存在一种监控其运行状态的方式。理想情况下，一旦失败，它还应该通知相关人员。

Dave 的运气很差，但某种程度上也很幸运。即使这一周已经如此灾难重重，原本仍然可能发生更多问题。下面还有几个值得考虑的问题：

这套系统需要做到多安全？

如果有人入侵了 Dave 的系统，就能访问供应商的付款数据。问问自己：一旦有人闯入，最糟糕的情况下，他们能看到什么，或者做什么？如果答案涉及财务数据、客户信息，或任何受联邦法律保护的内容，那么安全就绝不能留到最后才考虑。

AI 发生变化时怎么办？

传统软件在有人修改代码之前，每次都会给出相同的输出，AI 则不然。Model 更新可能会改变 prompt 的处理方式，导致相同的输入得到不同的结果。如果你的产品依赖一致性，就需要一种方法来测试它是否仍然保持着上周的行为。（这个概念的行业术语是“evals”——你可以把它理解成 AI 的 QA。）

运行这套系统需要多少钱？

也许 Dave 的系统每次运行只需要 2 美分，第一周里几乎让人感觉不到成本。但如果它成为公司的默认流程，并扩展到其他办公地点，就可能需要申请一笔数额可观的预算。

不难想象，经验丰富的软件工程师会检查一套全面得多的领域。

一种常见的概括方式是把它们称为“ilities”，因为许多相关主题都以这个后缀结尾，例如 maintainability、portability、scalability，等等。我在学校学习这些知识时，老师告诉我们，这样的属性总共有 61 个！

究竟需要深入到什么程度，取决于你想构建什么：

假设你正在建造一栋真正的建筑，那么它究竟是什么：一间棚屋、一栋两层住宅，还是一栋 20 层的大楼？如果你只是在构建一个快速、简单的 app，就不必面面俱到。但如果你想打造的是一个需要可靠运行、能够应对复杂需求的东西，就要做好相应的准备。

也许你需要请专业人士参与？有些人会自己搭建户外棚屋，但不会自己建造核反应堆或工业桥梁。同样，在某些情况下，请工程师加入才是正确的选择。

等一下，AI 不能替我做这些吗？

你可能会问自己：等一下，AI 为什么还没有解决这个问题？既然它接受过海量软件工程数据的训练，为什么不能开箱即用地回答这些问题，甚至主动提出这些问题？

问题在于，LLM 的优化目标是给出你想要的输出；如果你自己都不知道想要什么，那它同样不会知道！

因此，当你说“帮我构建一个可以做 X 的 app”时，它不会自行假设你真正的意思是：“帮我构建一个可以做 X 的 app，同时支持向第三方提供访问权限，能够扩展到相邻的 use-case，并且确保我们能在它失败或做错事情时及时发现。”

你只需要稍微推动它一下。以我的经验，如果你问：“我应该如何处理 version control？”它通常会给出类似这样的回答：“说得好！我们确实应该把这个加进去，可以这样做。”

但你必须把它引导到这个方向。你也必须知道自己真正想要什么！

不知道该从哪里开始？只要使用类似下面这样的 prompt，为 AI 提供正确的上下文，让它主动询问你真正需要什么：

构建是一个过程，而不是一个项目

于是，Dave 吸取了教训。构建软件并不是做完一次就可以抛在脑后的事情。东西一旦上线，维持其持续运行所需的工作并不会比构建阶段少。事实证明，Day 2 才是最长的一天！

但这并不是坏事：它其实有点像一种荣誉的象征。只有当人们喜欢使用一款产品，或者认为它足够有价值、愿意不断回来使用时，产品才有机会进入 Day 2。

所以，如果你准备开始构建，就给你的产品一个长久而幸福地生存下去的机会。

在 Day 0 提出正确的问题，为 Day 2 做好准备！

n8n 用户有着各式各样的背景、经验水平和兴趣。我们一直希望在博客文章中介绍不同的用户及其项目。如果你正在使用 n8n，并愿意为社区带来启发，请联系我们 💌