--- title: "AI 时代的展示型项目与维护成本" author: "冯智勇Geo" published: "2026-11-03T10:47:00.000Z" description: "AI 时代，做一个 Demo 越来越容易。可我现在看一个项目，首先考虑的已经是维护成本，而不是功能多牛逼。" tags: ["AI","个人实践","工作流"] url: "https://fengzhiyonggeo.com/posts/ai-demo-projects-maintenance-cost/" --- # AI 时代的展示型项目与维护成本 ![《AI 时代的展示型项目与维护成本》的文章封面]() AI 时代，做一个 Demo 越来越容易。可我现在看一个项目，首先考虑的已经是维护成本，而不是功能多牛逼。 有些项目适合拿来展示一个想法，做成文章或视频；有些产品，才适合接进自己的工作流长期使用。把这两种用途分开，很多选择反而容易了。 ## 从一个手机 Agent 项目说起 前段时间，我看到一个叫 Mika 的手机端 Agent 项目，最初想问的事情很简单：它能不能自动帮我发朋友圈？ ![](https://fengzhiyonggeo.com/images/ai-demo-projects-maintenance-cost/mika-mobile-agent.webp) 看过之后，我选择先观望。比起展示出来的功能，我更在意的是：如果真的把它接进日常工作，后面需要多少时间去维护。 我当时的担心是，接入的时候看起来很方便，接下来却可能一直在适配环境、处理兼容性问题。最后省下的时间，还不够自己折腾。 这不是我已经部署后遇到的结果，而是决定要不要投入之前，对维护成本的判断。 ## 做出功能之后还要面对新问题 我在讨论里说了一句话： > AI 时代，做 Demo 很容易，维护就需要硬实力。 一个 Demo 可以在选定的设备和环境里，把想法演示出来。但如果要长期使用，就得面对不断变化的实际情况。 比如设备本身的兼容性问题。AI 可以协助分析、寻找办法，但写出一段代码，不一定就能让原本不兼容的设备配合起来。 维护常常意味着新情况、新环境、新问题。遇到这些问题，要有人继续判断和处理。不能因为第一次跑通了，就把后面这些成本当成不存在。 所以，开发变容易以后，我反而更重视维护能力。一个功能能不能做出来，和我愿不愿意长期依赖它，是两个需要分别回答的问题。 ## Demo 也可以是一种内容 顺着这个思路，我又想到：如果一个项目的目的，本来就是展示一个想法呢？ 那它可以像一篇文章、一段视频一样，成为一种内容。 过去，我可以写一篇文章，解释自己的设想。现在，我还可以做出一个能运行的原型，把这个设想直接演示给别人看。别人看完，理解了这个思路，展示的目的就已经达到了。 我把这类项目理解为“展示型项目”。它的价值可以在于表达和启发，不必一开始就承担长期产品的全部要求。 如果我自己做一个 Demo，只是准备当作内容发布，我就不需要按一个长期运营产品的标准，提前承担所有维护成本。但如果我要把它交给别人长期使用，或者让自己的业务依赖它，标准就要变了。 ## 我会把使用和展示分开判断 现在，无论自己开发产品，还是使用别人的产品，我都会先想清楚用途。 如果只是展示一个想法，我关心的是：它有没有把这个想法讲明白，能不能让人看到一种新的可能。 如果要放进日常工作，我关心的就变成了：它能不能持续使用，环境变化后谁来处理，维护它需要花多少时间。 一个展示效果很好的项目，当然值得看，也可能给我启发。但我不会仅凭一个演示，就决定把自己的工作交给它。 对那个手机 Agent 项目，我当时更倾向于把它看作一种产品 Demo 内容，所以选择观望。这个判断针对的是我自己的使用选择，也不等于断言它以后一定无法成为成熟产品。 ## 功能之外还有长期成本 以前看到一个新功能，我容易先想：这个东西能帮我做什么？ 现在我还会接着想：为了持续得到这个功能，我需要付出什么？ 开发和维护都要自己承担的时候，功能的增加就可能成为负担。少接一个暂时用不上的工具，也就少了一份需要自己照看的东西。 所以，我愿意看这些新项目，也愿意把自己的想法做成 Demo。但真正放进工作流的工具，我会更谨慎。 做 Demo 可以是表达。把它变成长期工具，就要把维护成本算进去。