内容来源：https://blog.n8n.io/building-with-ai-the-day-2-problem/

内容总结：

AI“一日奇迹”变“运维噩梦”：非技术创业者的“第二天难题”如何破局？

随着AI开发工具普及，越来越多非技术背景的人能快速搭建应用，但随之而来的长期运维问题正成为新痛点。业内人士指出，许多人在产品上线初期体验“高光时刻”后，会迅速陷入“第二天难题”——即系统在运行、扩展和维护中出现的各类突发故障。近期，一位财务人员戴夫的“灾难一周”引发广泛共鸣，生动展现了这一困境。

戴夫在一家百人公司财务部工作，他用AI工具搭建了一个自动处理发票的系统，周一时备受赞誉，但此后麻烦不断。周二，系统金额录入错误且无法追溯；周三，系统需要更新，同事因凭证和权限绑死在个人账户而无法协助；周四，公司要求将该系统推广至其他办公室，却发现所有配置均为“硬编码”，几乎要推倒重来；周五，系统又悄然漏掉了12张发票，且无任何错误提示。短短一周，戴夫从“明星员工”变成“救火队员”。

这一案例在开发者社区引发讨论。有经验的工程师指出，“第二天难题”并非新问题，而是软件工程领域的经典挑战，涵盖可维护性、可扩展性、安全性、可观测性等多个维度。问题的根源在于“缺乏预判”——许多非技术开发者在“第一天”搭建时，根本不知道后续可能面临什么。

对此，资深技术专家给出的核心建议是：在“第零天”就问对问题，而非等到故障发生后再补救。 包括：如何追踪系统每一步的输入输出？如何对版本进行保存和回滚？团队成员如何获得权限与文档支持？系统未来如何扩展？以及若系统静默失败，如何通过监控和告警及时感知？

此外，安全问题、AI模型更新带来的行为变化、运行成本随规模增长等问题也需要提前规划。专家强调，AI工具虽能加速开发，但其本质是“有求必应”，若用户未提出运维与扩展需求，它默认不会主动考虑。建议非专业开发者在使用AI时，明确要求其按软件工程最佳实践设计，并主动接受“访谈式”提问，以识别潜在风险。

“软件开发不是一次性项目，而是一个持续过程。”专家总结道，“产品能活到‘第二天’，恰好说明它有价值。只有从第一天就为长期运维做好准备，才能让产品走得更远。”

中文翻译：

"你做出来的那个东西挂了——我们怎么修？"

尽管用AI把东西做出来并发布的感觉无比美妙，但如果你真的独立发布过几样东西，你大概知道当某个东西出故障时胃里那种翻江倒海的感觉。或者，当你创造的东西开始扩张、而你并不确定该如何应对时，那种挥之不去的恐惧感。

哎呀。

如果你是非技术背景出身，这可能会对你的势头造成致命打击。大语言模型能帮我们创造的东西有无限可能，但大多数AI工具并不设计用来教你底层基础设施是如何运作的。所以当事情分崩离析时，你并不总是清楚发生了什么，或者为什么发生。

先说清楚：你不需要为此感到难过！撸起袖子直接开干往往是最好的学习方式。你可能正在解决一些你之前根本不知道其存在的问题，而且你甚至可能连自己正在尝试做的事情叫什么名字都不知道。

这就是我想帮忙的地方。我目前是一名市场营销人员，但我出身于软件工程领域，拿到了计算机科学学位，在转行之前做了多年开发。所以对于这类事情为什么会出问题，我有一个独特的视角。而这个特定的挑战——你构建了某个东西，但它在运行过程中出故障了——就是一个完美的例子。

因为这对软件构建者来说并不是一个新问题。事实上，这是一个经典问题。我们甚至给它起了个名字：朋友们，这就是“第二天问题”（Day 2 Problem）。

那到底是什么？

第二天问题是指在规划（第0天）和初始构建工作（第1天）完成之后，在产品成长和维护过程中出现的长期问题和挑战。

如果你难以想象我的意思，这里有一个例子：

戴夫极其糟糕一周的故事。

认识一下戴夫。他在一家100多人的公司财务团队工作，态度积极肯干。大家都喜欢戴夫。他不是工程师，但他总在尝试新软件，而且已经在教团队里的其他人如何用AI构建东西了。

这周，事情出了岔子。出了大岔子。

周一

戴夫的团队被发票淹没了。供应商通过电子邮件发来PDF，但之后必须有人手动把信息敲进系统里。这非常耗时，所以每个人都积压了好几周的活儿。

所以，经过周末的思考，戴夫周一早上干劲十足地开始了。在一个AI工具的帮助下，他构建了一个自动化流程：发票进来，AI扫描PDF，提取关键信息并上传。它甚至能在某些信息看起来有问题时发出标记。

好样的，戴夫！所有人都印象深刻，他的老板告诉他：“这种事就是我们可以用来帮你拿到我们一直想帮你争取的晋升机会的东西。”戴夫下班开车回家时几乎要在车里跳起舞来。

周二

第二天一早，应付账款团队就联系戴夫：有3张发票的金额录入错误。而且错得不是一点点。戴夫手忙脚乱地想弄清楚发生了什么：是AI误读了PDF？还是没有正确上传到系统里？

他打开他的自动化……无从得知。没有任何AI在每个步骤做了什么操作的记录——上面只显示“自动化已完成”。

于是戴夫开始四处排查。他调整了几个地方，找到了问题所在。幸运的是，问题不大，所以他修复了它并更新了自动化。

上线之后，他跑了一次测试……结果不行。糟糕。这更麻烦了。该用Control-Alt-Delete大法了！他回到系统试图回到之前的版本，但根本没有那个功能。他编辑的是唯一的版本，没有其他任何东西在那里。

戴夫花了接下来几个小时重新搭建他的原始版本，然后再加入新的修复。然后整个下午剩下时间都在反复检查确保一切正常，赶在回家前进行了更新。

希望现在一切都已经修好了？

周三

戴夫整个下午都被接二连三的会议缠住了。下午2点，自动化程序需要更新。错误信息显示，只需要重置一下就行。他的队友马可主动提出帮忙。

但是……从哪里入手？戴夫才是那个总是做这件事的人。你怎么才能进到编辑器里？没有任何文档。而当马可终于找到一个懂的人时，登录凭据绑定的是戴夫的邮箱，而且密码也不是Password123。

马可给戴夫发短信。戴夫正在季度规划会议上假装认真听讲，试图在桌子底下回短信指导。效果不太好。发票一直积压到4点半戴夫有空了才处理。

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

周四

戴夫的老板仍然相信他！她看到了前景，知道这个自动化已经在为团队节省大量时间。于是她问出了一个自然而然的下一个问题：“我们能把它也推广到奥斯汀办公室吗？”

戴夫打开自动化，心一下子沉了下去。一切都是硬编码的：一个收件箱、一套供应商格式、一个会计系统的连接。要在奥斯汀使用，他需要做的不仅仅是调整一些设置。他几乎得从头重新构建一遍。又一次。

他告诉老板：“没问题，交给我！”然后取消了下班后的计划来搞定这件事。

周五

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

直到下午3点，一个供应商打来电话：他们的发票这周没有被付款。戴夫检查了一下：自动化从未处理过这些发票。它无法解析那种格式，所以就……直接跳过了。没有报错。没有标记。什么都没有。

更糟的是：这还不是唯一一份。戴夫开始往下查，发现了一周里还有11张发票被以同样的方式悄悄跳过了。这周每一天，当他在排查那些他能看到的问题时，还有更多他看不见的问题在发生。

他的老板过来了。戴夫回家路上完全没有想跳舞的感觉。

戴夫遇到了很多“第二天问题”

现在，大多数“第二天”问题并不是字面意义上发生在第二天。但事情以意想不到的方式出错，或者在初始上线后需要更新，这种体验是不可避免的。

坏消息是：原本可能出问题的方面还有很多很多。安全性呢？或者AI模型更新了，突然给出截然不同的输出怎么办？系统运行的时间越长，它就越容易瓦解崩溃。

但幸运的是，我也有非常好的消息告诉你：这不是一个新问题！处理第二天问题这件事，软件工程师们已经处理了几十年了。你可以从他们的经验中学习，免去自己很多心碎的时刻。

那么怎么做呢？

我要给所有朋友、同事和网上陌生人的第一条建议是这样的：

解决第二天问题的方法是，在第0天问自己正确的问题。

怎么解决？通过提问。

第二天问题真正根本的症结在于缺乏意识。

戴夫的大部分问题其实并不难修。他只是没想到这些问题竟然会成为问题，直到它们发生了他才手忙脚乱地去补救。就像我在开头说的：我不怪戴夫，我也不会怪你。你不知道你所不知道的事。

戴夫本该在周一问的问题

戴夫和他的团队实际上做对了一件事：他们知道谁是负责人。在考虑其他事情之前，先确保这一点是明确的。

早在2006年，亚马逊的维尔纳·沃格尔斯就提出了这条著名原则：

“你构建它，你运行它。”

如果你不是实际维护和持续运营你所构建之物的合适人选，你需要非常清楚谁会来做这件事？所以，无论是你自己，还是你加上将来会共同负责的其他人，在经历戴夫那样的一周之前，问问自己这些问题：

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

戴夫无法判断是AI误读了PDF还是上传失败了，因为过程中没有记录任何投入和产出。任何持续运行的项目都应该有一定程度的可追踪性，这样你就有了一个关于所发生事情的记录。

（厚着脸皮打个广告：这是人们喜欢使用n8n的主要原因之一。可视化工作流让定位问题所在变得容易得多，而且n8n会记录每次执行的每个步骤的所有输入和输出。）

• 变更将如何进行，以及我如何撤销它们？

戴夫编辑了他唯一的副本，然后无法回退。在你发布之前，决定好：版本保存在哪里？你能快速回滚更新吗？你能在非正式环境的地方测试变更吗？

• 还有谁需要访问权限，他们应该能做什么？

马可帮不上忙，因为凭据是戴夫的，而且所有系统逻辑都在戴夫的脑子里。如果其他人会使用或依赖它，就要设置共享凭据、权限级别，以及足够的文档，让别人不需要给你发短信也能操作它。

• 这个系统可能需要如何扩展？

戴夫的老板要求扩展项目，结果整个东西需要重新构建。在开始构建之前，问问自己：这需要扩展吗？扩展到什么程度？从一开始就考虑到这一点，远比日后改造要便宜得多。

• 我如何知道某个东西正常运转（或没有正常运转）？

戴夫的自动化整个星期看起来都好好的，但实际上在悄悄跳过发票。如果你的系统需要在后台运行，确保有一种方式来监控它是否在运行，理想情况下，如果它失败了，能通知到真人。

超越戴夫的一周

戴夫运气不好，但他也很幸运。即使在他那个灾难性的一周里，还有更多事情可能出错。这里还有一些你应该考虑的问题：

• 这需要多高的安全性？

如果有人入侵了戴夫的系统，他们就能获取供应商付款数据。问问自己：如果有人进来，最坏情况下他们能看到什么或做什么？如果答案涉及财务数据、客户信息，或者任何受联邦法律保护的内容，安全性就不能是事后的想法。

• 当AI变化时会发生什么？

传统软件在有人修改代码之前，每次都给出相同的输出。AI不是这样。模型更新会调整提示词的处理方式，这意味着同样的输入会产生不同的结果。如果你的产品依赖于一致性，你需要一种方法来测试它是否仍然表现得和上周一样。（这个的行业术语叫“评估”（evals）——可以把它想成是针对AI的QA。）

• 运行这个要花多少钱？

也许戴夫的系统每次运行只花2美分，第一周根本看不出来。但如果它成为公司的默认工具并扩展到其他地点，就可能需要一笔重大的预算审批。

如你所想，经验丰富的软件工程师有一套更全面的审查领域清单。

一个流行的描述方式是“ilities（各种‘性’）”，因为很多这类主题都以这个后缀结尾：可维护性、可移植性、可扩展性等等。当我在学校学这些东西的时候，老师告诉我们一共有61个！

知道要深入到什么程度，真的取决于你在尝试构建什么：

如果你在建一座——嗯——建筑，这会是什么：一个棚子、一栋两层楼房、还是一栋20层的大厦？如果你在做一个快速简单的应用，你不需要那么面面俱到。但如果你在构建需要可靠运行并处理复杂需求的东西，就要相应地做好准备。

也许你需要请一位专业人士？就像有些人会自己搭后院的棚子，但不会自己建核反应堆或工业桥梁一样，有些时候请一位工程师进来才是正确的做法。

等等，AI不能替我做这个吗？

你可能会问自己：等等，为什么AI不直接把这个问题解决了？既然它是在海量软件工程数据上训练出来的，为什么不直接回答（甚至主动提出）这些问题，开箱即用呢？

问题在于，大语言模型被优化为给你想要的那个输出，而如果你不知道你想要什么，它也不知道！

所以，当你说“给我做一个能做X的应用”时，它不会假定你实际的意思是“给我做一个能做X的应用，还要有提供第三方访问的能力，并且能扩展到相邻用例，同时确保我们在它失败或出错时能知道。”

你只需要稍微推它一把。如果你问“我应该如何处理版本控制？”，凭我的经验，它通常会回答类似“好点子！我们确实应该加上这个，像这样做。”

但你必须引导它朝那个方向走。而且你必须知道你真正想要什么！

不知道从哪里开始？就用这样的提示词给AI正确的上下文，让它来问出你真正需要的东西：

“我不是专业软件开发人员。我想确保这个项目遵循软件工程的最佳实践：比如可维护性、安全性、可观测性和可扩展性。请围绕我的项目对我进行访谈，帮助我确定在发布之前我应该思考哪些问题。”

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

戴夫学到了教训。构建软件不是一次性做完然后就能忘掉的事情。一旦东西上线了，维持它运行的工作量和当初一样大。原来，第二天才是最漫长的一天！

但这并非坏事：这其实是一种荣誉的象征。一个产品能活到第二天，是因为人们喜欢用它们，或者觉得它们有足够的价值愿意回来继续用。

所以，如果你打算开始构建，请给你的产品一个长久幸福生活的机会。

通过在第0天问正确的问题，为第二天做好准备吧！

英文来源：

“That thing you built is down - how do we fix it?”
Despite the pure bliss of shipping something you’ve built with AI, if you’ve actually launched a few things on your own, you probably know the feeling in the pit in your stomach when something breaks. Or just the looming sense of dread when something you’ve created starts to expand and you’re not really sure how to handle it.
Yikes.
If you come from a non-technical background, this can be fatal for your momentum. There’s so much possibility for what LLMs can help us create, but most AI tools are not designed to teach you how the underlying infrastructure works. So when things fall apart, it’s not always clear what happened or why.
Just to be clear: You don’t need to feel bad about this! Jumping in to start building is often the best way to learn. You’re probably trying to solve problems that you didn’t previously know existed, and you likely don’t even have a name for what you’re trying to do.
That’s where I’d like to help. I’m currently a marketer, but I came up through the world of software engineering, getting my degree in CS and working as a dev for years before making the switch. So I have a unique perspective on where this stuff is going wrong. And this particular challenge - where you build something, but it breaks down the road - is a perfect example.
Because this isn’t a new problem for software builders. In fact, it’s a classic. We even have a name for it: This, my friends, is a Day 2 Problem.
What’s that, exactly?
Day 2 Problems are the long-term issues and challenges that show up when growing and maintaining a product, after the planning (Day 0) and initial building work (Day 1) are done.
If you’re having trouble imagining what I mean, here’s an example:
The story of Dave’s really bad week.
Meet Dave. He's on the finance team at a 100+ person company and has a can-do attitude. Everyone loves Dave. He’s not an engineer, but he’s always trying out new software and he’s already showing other people on the team how to build things with AI.
This week, things went wrong. Very wrong.
Monday
Dave’s team is drowning in invoices. Vendors send in PDFs by email, but then someone has to manually type the information into the system by hand. It takes forever, so everyone is several weeks behind.
So after thinking about it over the weekend, Dave hits the ground running on Monday morning. With the help of an AI tool, he’s built an automation: Invoice comes in, AI scans the PDF, key information is extracted and uploaded. It even flags if something looks off.
Hurray, Dave! Everyone is so impressed and his boss tells him, “This is the kind of thing we can use to help you land that promotion we’ve been trying to get for you.” Dave is practically dancing in his car on the commute home.
Tuesday
First thing in the morning, the accounts payable team pings Dave: 3 invoices posted with the wrong amounts. And not by a small amount. Dave scrambles to figure out what happened: Did the AI misread the PDFs? Did it not properly upload it to the system?
He opens his automation and… there’s no way to know. There’s no record of what the AI did for each step - it just says “Automation complete.”
So Dave starts poking around. He tweaks a few things and finds the issue. Fortunately, it’s minor, so he fixes it and updates the automation.
Once it’s live, he does a test run. … and it doesn’t work. Uh oh. This is worse. Time for Control-Alt-Delete! He goes back to the system to try to go back to the previous version, but that’s not a thing. He edited the only version and there’s nothing else there.
Dave spends the next few hours rebuilding his original version, and then adding in the new fix. Then the rest of the afternoon triple-checking to make sure it all works before updating right before going home.
Hopefully everything is fixed now?
Wednesday
Dave is stuck in back-to-back meetings all afternoon. At 2pm, the automation program requires an update. It just needs to be reset, the error message says. His teammate Marco offers to jump in.
But… where? Dave is the one who always does it. How do you even get to the editor? There’s no documentation. And when Marco finally finds someone who knows, the login credentials are tied to Dave’s email and there’s a password that is not Password123.
Marco texts Dave. Dave, who is currently pretending to pay attention in a quarterly planning meeting, tries to text back instructions under the table. It doesn’t go well. The invoices sit until Dave is free at 4:30.
At least the problem is resolved by 4:31!
Thursday
Dave’s boss still believes! She sees the vision and knows that it’s already saving their team significant time. So she asks the natural next question: “Can we roll this out to the Austin office, too?”
Dave pulls up the automation and his stomach sinks. Everything is hardwired: one email inbox, one set of vendor formats, one connection to one accounting system. To make it work for Austin, he’ll have to do more than just tweak some settings. He’ll pretty much have to rebuild it from scratch. Again.
He tells his boss, “Sure, no problem!” And cancels his after-work plans to get it done.
Friday
Smooth sailing! After all the bumps, everything seems to be running correctly.
Until 3pm, when a vendor calls: Their invoice hadn’t been paid this week. Dave checks: the automation never processed them. It couldn't parse the format, so it just… skipped them. No error. No flag. Nothing.
Even worse: That’s not the only one. Dave starts digging and finds 11 more invoices from the week that were silently skipped the same way. Every day this week, while he was troubleshooting the problems he could see, there were more problems that he couldn't.
His boss stops by. Dave does not feel like dancing on the drive home.
Dave had a lot of Day 2 Problems
Now, most “Day 2” problems don’t literally happen on the second day. But the experience of things breaking in unexpected ways, or requiring an update after the initial launch is unavoidable.
Here’s the bad news: There are way more things that could have gone wrong. What about security? Or the AI model getting updated and suddenly giving very different outputs? The longer the system runs, the more vulnerable it is to falling apart.
But fortunately, I also have very good news for you: This is not a new problem! Dealing with Day 2 issues is something software engineers have been dealing with for decades. You can learn from their experience and save yourself a lot of heartache.
So how do you do that?
My #1 piece of advice for all my friends, coworkers, and internet strangers is this:
You solve Day 2 problems by asking yourself the right questions on Day 0.
How do we solve this? By asking questions.
The real underlying issue with Day 2 problems is lack of awareness.
Most of Dave’s problems weren’t even that hard to fix. He just didn’t realize they even could be problems until after they happened and he was scrambling to fix them. Like I said at the top: I don’t blame Dave, and I wouldn’t blame you, either. You don’t know what you don’t know.
What Dave should have asked on Monday
Dave and his team actually got one thing right: They knew who owned it. Before everything else, make sure that’s clear.
Back in 2006, Amazon's Werner Vogels famously introduced this principle:
"You build it, you run it."
If you’re not the right person to actually maintain and sustain something you’re building, you need to be very clear about who will? So whether it’s you, or you plus some other person who will be owning in the future, ask yourself these questions, before you have a week like Dave’s:

• How will I track what the system does at each step?
  Dave couldn't tell whether the AI misread a PDF or the upload failed, because nothing recorded the inputs and outputs along the way. Any ongoing project should have some degree of traceability, so you have a record of what has happened.
  (Shameless plug: This is one of the main reasons people love using n8n. A visual workflow makes it dramatically easier to see where things went wrong, and n8n records all of the inputs and outputs for every step of every execution.) - How will changes be made, and how will I undo them?
  Dave edited his only copy and wasn’t able to go back. Before you launch, decide: Where are versions saved? Can you quickly roll back updates? Can you test a change somewhere that isn't live? - Who else needs access, and what should they be able to do?
  Marco couldn't help because the credentials were Dave's and all the system logic was in Dave’s head. If other people will use or depend on it, figure out shared credentials, permission levels, and enough documentation that someone else can operate it without texting you. - How might this need to grow?
  Dave's boss asked to expand the project and the whole thing needed to be rebuilt. Before you build, ask: Will this expand? How much? Building with that in mind from the start is far cheaper than retrofitting later. - How will I know if something is working (or not working)?
  Dave's automation looked fine all week, but was secretly skipping invoices. If your system needs to run in the background, make sure there’s a way to monitor that it’s running, and ideally, will notify a human if it fails.
  Beyond Dave's week
  Dave got unlucky, but he also got lucky. Even in his disaster of a week, more could have gone wrong. Here are a few more questions you should consider:
• How secure does this need to be?
  If someone broke into Dave's system, they'd have access to vendor payment data. Ask yourself: what's the worst thing someone could see or do if they got in? If the answer involves financial data, customer information, or anything federally protected, security can't be an afterthought. - What happens when the AI changes?
  Traditional software gives the same output every time until someone changes the code. AI doesn't. Model updates can adjust how a prompt is handled, meaning that the same input gives a different result. If your product depends on consistency, you need a way to test that it still behaves the way it did last week. (The industry term for this is "evals" - Think of it as QA for AI.) - How much does this cost to run?
  Maybe Dave’s system only costs 2 cents for each run, which is invisible in the first week. But if it becomes a default part of the company and scales to other locations, it may require a major budget approval.
  As you’d imagine, experienced software engineers have a much more comprehensive set of areas to review.
  One popular way to describe them is the “ilities,” since so many of these topics end with that suffix: maintainability, portability, scalability, etc. As I was learning all of this stuff in school, we were taught that there are 61 of them!
  Knowing how deep to go really depends on what you’re trying to build:
  If you were building a, well, building, what would this be: a shed, a 2-story house, or a 20-story building? If you’re building a quick, simple app, you don’t need to be so exhaustive. But if you’re trying to build something that needs to run reliably and deal with complex needs, prepare accordingly.
  Maybe you need to bring in a professional? Just like some people build their own outdoor sheds, but not their own nuclear reactors or industrial bridges, there are times when bringing in an engineer is the right move.
  Wait, can’t AI do this for me?
  You may be asking yourself: Wait, why doesn’t AI solve this, already? Given that it’s been trained on massive sets of software engineering data, why doesn’t it answer (or even ask) these questions, out of the box?
  The problem is that LLMs are optimized to give you the output you’re looking for, and if you don’t know what you want, then it doesn’t either!
  So, when you say “Build me an app that does X,” it won’t assume that what you actually mean is “Build me an app that does X, with the ability to provide third-party access, and the ability to expand to adjacent use-cases, and make sure we know when it fails or does something wrong.”
  You just need a bit of nudging. If you ask, “How should I handle version control?” in my experience, it will often respond with something like, “Good point! We should actually add that, like this.”
  But you have to guide it in that direction. And you have to know what you actually want!
  Not sure where to start? Just use a prompt like this to give the AI the correct context and get it to ask you what you really need:
  “I'm not a professional software developer. I want to make sure this project follows best practices for software engineering: things like maintainability, security, observability, and scalability. Interview me about my project and help me identify what I should be thinking about before I launch.”
  Building is a process, not a project.
  So Dave learned his lesson. Building software is not something you do one time and then forget about it. Once the thing is live, there’s just as much work keeping it going. It turns out, Day 2 is the longest day!
  But that’s not a bad thing: It’s actually kind of a mark of honor. Products only make it to Day 2 if people enjoy using them or find enough value to keep coming back.
  So if you’re going to start building, give your product a chance at a long and happy life.
  Prepare for Day 2 by asking the right questions on Day 0!