AI 创业一年复盘：第一次 Build 的成就感，是创业最大的幻觉

从 Founder Park 出去后，Muji 去新加坡深造了一年，然后以 COO 的身份加入了 Seede AI。

All in AI 创业一年后，对于 Vibe Coding、Build 和 Demo 有了新的理解。

作为一名 Marketing 出身的哲学专业毕业生，过去一年他用 Cursor 写了 40 多万行代码。第一次从 co-founder 的视角，同时观察产品、研发和 GTM，亲身经历 AI Native 组织如何协作、哪里会卡壳，以及新的机会究竟会从哪里长出来。

最新的模型、Agent 和 Demo，每个人都能看到。但真正下场做产品、搭团队、跑业务的人，看到的是可能是远比这复杂的问题。这篇复盘文章，从 Agent Engineering、技术债、产品维护到 SaaS 的新机会，Muji 输出了许多一线踩坑后的真实思考。

文章转载自「小头 MUJI」，授权转载。

欢迎各位创业者踊跃分享你们的创业心得和经验复盘。

文章目录

1. Agent Engineering 的实践和思考

2. AI 时代，对活人感的坚持

3. 构建系统，而不是增加功能

4. build 越爽，欠下的债务越多

5. AI native 组织，谁来擦屁股？

6. 别迷信 demo，产品是长期维护出来的

7. SaaS 不会消亡，但都值得重新做一遍

8. 创业人才的标准：通才 + 能业务闭环

9. 聊创业本身，事情不会自己发生

10. 看一万遍，不如自己摔一遍

⬆️关注 Founder Park，最及时最干货的创业分享

Founder Park 正在持续寻找值得被看见的 AI 团队与项目。

我们将通过「AI 产品市集」、内容报道、社群分发等方式，帮你触达早期用户、获得真实反馈，以及建立关键连接。

如果你正在做 AI 相关的事，欢迎和我们聊聊。

去年 6 月，我从新加坡 NUS 工学院毕业，回国，开始了人生第一段全职 all in的创业。

刚好一年。世界变化真大。趁端午假期，手敲一篇 2w 字长文记录下创业第一年的收获，试着把踩过的坑和想明白的事写下来。

之前在 Founder Park，总听创业前辈们念叨，创业后的学习曲线和信息密度极陡峭。现在看，确实如此。放在几年前不敢想象，一个做 marketing 出身的哲学毕业生，用 Cursor 写了大概 40 万行代码，给主仓库贡献了 20 万行左右，代码量和研发同事差不多。当然，CEO 本尊那种最早独立开发、贡献 100 多万行代码的怪物不算。haha。

数字本身不是重点。但这是我人生第一次，从 co-founder 的视角，同时看产品、研发、GTM，看 AI native 组织到底怎么协作，卡在哪里？以及现在真正有窗口期的机会在哪里？

很多事情，我一开始也想简单了：以为 AI coding 能解决大部分问题。以为 demo 跑通就接近产品。以为 agent loop 足够强，复杂任务就能稳定搞定。以为大家都能 build 之后，组织效率会自然提升。

后来发现，都不是。

AI 确实把「做出来」变快了，但它也把更多问题提前暴露出来：维护、review、权限、数据、文档、支付、稳定性、协作边界、用户验收。这些东西过去也存在，只是以前构建慢，问题来得也慢。现在 building 被加速之后，所有债都会更快地追上来。

也让我产生了几个暴论，1-3 年的判断：

1、SaaS 不会死亡，被严重低估。现在极度缺少 AI native 的 infra SaaS 去解决 building 之后带来的持续性债务。

2、程序员不会失业，但很多人必须完成转变。要么去构建 infra；要么就必须从「记者变成编辑」：从亲手写代码，转向审阅、筛选、修改和整合 AI 写出来的代码，并对最终系统质量负责。

3、AI native 组织最深刻的变化，不是代码生成，而是协作模式：当人人都是 builder，组织结构一定会被重塑。

4、每一个 agent、每一个系统，都需要有人维护。人不会失业，只是工作方式会变。

如果你有相同的经历和痛点，那我们看到的痛点和机会，是一样的。下面内容不会只讲判断，也尽量结合这一年真实主导做过的事来写。

01Agent Engineering 的实践和思考

创业中会遇到很多卡点，这一年，我大部分的时间都是解决完一个就冲向下一个。但收获最大的还是基于 agent loop 做的工程优化尝试，也是我认为 AI 时代真正的增量所在。

创业第一天，我们就坚定让 Seede 是基于代码来构建设计的。这个方向跟最近很火的 HTML PPT、Claude Design 很像：不是文生图，而是让 AI 通过结构化代码来生成、修改、组织视觉内容。

我们大概早了一年开始相信这件事。如果设计是由代码构建的，那 agent 的形态就不应该只是一个调用 api，返回图像任务的 bot。它应该更像 Claude Code：被管理的很好的上下文注入，理解用户意图，拆解任务，规划步骤，调用工具，然后持续执行和修正。

但这件事如果不亲自做，很难真正知道 agent engineering 到底应该优化什么，卡点是什么。

很多人会脱口而出：128k context window 管理最重要。这当然很重要。每一轮输入都不是简单塞一段 prompt，而是要拆成多层拼装：系统规则、用户意图、当前画布状态、历史操作、可用工具...什么时候完整注入，什么时候摘要压缩，什么时候保留原始上下文，什么时候只保留关键状态，都会影响 agent 的判断质量。尤其是无限画布产品，对上下文的考验会非常高。

它本质上有点像 Cursor IDE 的文件树。只不过 Cursor 面对的是代码文件，而 Seede 面对的是一个个可视化画板。每一个 HTML 文件，都对应一个前端可视化展示出来的设计。所以问题变成：当用户没有清晰的项目管理习惯，而是在无限画布上不断创建设计时，agent 怎么精准判断用户到底想改哪一个文件、哪一个画板、哪一个图层？

Cursor 是 IDE 工具，用户天然有 @file、选中代码、引用上下文的习惯。但设计产品里的用户不是这样。他们更多是口喷式表达。比如：“把小米汽车改成特斯拉。” 这句话对人类来说可能很自然，指着屏幕就说了，但对 agent 来说非常难。如果画布里有 100 个设计，第 3 个设计里有一张小米汽车图片，用户没有选中它，也没有明确引用它，agent 凭什么知道要改的是那一张？这里考验的是整个系统对上下文、状态、用户行为和业务语义的理解能力。

但真正做下来，我发现一个更 tricky 的点：agent engineering 必须由懂业务、懂用户意图的人深度参与。

因为纯工程视角很容易把问题理解成模型有没有按步骤执行，工具调用有没有成功，返回格式有没有正确。这些当然重要，但它们只能证明 agent 在执行流程（tool calling）上是通的，不能证明它真的完成了用户想要的东西。在真实产品里，更关键的闭环是：用户意图 → agent 规划 → 工具执行 → 结果验收。如果不理解用户意图，就很难判断 agent 的规划执行是不是对的。有时候，问题并不是模型没执行，而是它从一开始就调用了错误的工具，走了错误的路径，最后产出的结果当然无法满足用户。

为此，我做了一个 spec 验收测试集，大概 100 多个任务，用来测试 agent 在不同设计意图下的规划和执行能力。测试集里有几类失败让我印象很深。

第一类是上下文污染：用户明明想修改当前画板，但 agent 把历史里另一个相似的画板拿来当上下文，最后改错对象。对代码产品来说，这可能只是引用错文件。但对设计产品来说，用户一眼就能看到：你改错了。

第二类是工具链路走错。比如本来应该先识别网页风格，再截图，再作为 reference image 进入 create。但 agent 有时会漏掉网页搜索后再截图的步骤。

第三类是 planner 看起来正确，但 execute 阶段偏掉。计划里写得很漂亮：改标题、换图、调整 layout。但执行时可能先改了 layout，导致原来的图层定位信息失效，后续 image tool 又找不到正确 node。

AI coding 产品里，这类错误有时还能被延后发现。代码写错了，可能要等到运行、测试、review，甚至线上场景里才暴露。但设计产品不一样。设计产品的每一次执行，都会直接反映在画布和作品上。改错了哪里，生成得好不好，风格是否符合预期，用户几乎一眼就能看到。这意味着 agent 的错误会被立刻暴露。用户不仅浪费了时间，还浪费了 token，更重要的是信任会被消耗。

这些错误从工程日志看，可能都是小问题：target id 错了、context recall 错了、tool schema 用错了。但从用户体验看，就是完全失败。

所以 agent 工程这件事，必须亲自尝试、亲自摔跤，才能积累 know-how。

4 月，我每天都熬夜到凌晨三点，就想搞清楚背后的原理。自己琢磨的过程，和写一份 PRD、然后让研发去实现，是完全不一样的。当时我拆解了 Claude Code 公开流传出来的一些 agent loop 方法和 memory 机制，然后在个人分支里的 Seede 上做了一次复现和重构。效果不错。

比如生成 100 页 PPT，如何保证内容连贯，风格连贯，生成速度还快。（说实话，我体验过世面上几乎所有 PPT 类 agent 产品，应该是没做 agent 优化，速度非常慢，产出效果还没 seede 好）。这让我更加确定一点：agent loop 是能跑通复杂任务的底线，但不是工程优化的上限。因为它有个致命问题。慢，而且贵。如果每一次工具调用都要重新触发一轮 agent loop，等待时间会非常长，token 消耗也会非常大。

从用户视角看，这是很糟糕的体验。用户不关心你背后跑了多少轮 agent，也不关心消耗了多少 token。他只关心：你是不是快速、准确地完成了我要的东西。当然，从行业环境和模型公司的叙事角度，token 消耗越多越好。但从产品角度，这一定不是好事。

所以我认为，agent engineering 的门槛从这里才开始体现。

第一层，是把 agent loop 跑起来。实现更精准的意图理解、更高的生成质量、更准确的工具调用。

第二层，是在 agent loop 的基础上做优化。把一个 skill 里的工具编组，批量执行，缩短生成时间、减少 token 消耗。

第三层，是管理好 128k context window，做好 memory 的压缩、分配和召回。

以无限画布 coding design 产品为例，我现在更倾向于把 agent 拆成两个阶段：planner 和 execute。

第一阶段是 planner。它负责理解用户意图，判断任务类型，并规划执行路径。比如用户说：“帮我把这张海报改成夏季促销风格，标题换掉，产品图换成新品，底部信息重新排版。”planner 需要判断这是 create 还是 modify，是简单任务还是多任务，是不是需要并行执行，有没有依赖关系（先改文字，还是先调整排版），要改哪些图层，要调用哪些工具。

一个简化后的 plan 可能长这样：

}

而且 tool 不再以单个的形式出现，而是规划好连续的 toolsteps。举个例子，用户输入：“帮我模仿 Seede 网站做个活动海报。” 一个合理的链路应该是：第一步，agent 做规划。它判断这是一个 create 意图，并规划出工具和使用步骤：web_search → get_official_url → read_url → screenshot → upload_as_reference_image → create。接下来一次性按顺序全部执行，不再反复通过 loop 来做。

一个高频、稳定、可复用的 agent 行为，不应该永远停留在临场推理里，而应该逐渐沉淀成工程系统里的 skill。

第二阶段是 execute 执行。最简化考虑，只需要处理两类核心任务：create 和 modify。也就是创建新设计，或者修改已有设计。有人会说，planner 阶段会导致上下文损失。拜托，可以把 planner 的结果和原始上下文一起塞进 agent loop 里，不会损失的。

而且，在 execute 阶段，不是所有任务都应该进入完整的 agent loop。更合理的方式，是根据任务复杂度拆成几种执行模式。

第一种是 fast-exec 模式。如果任务足够确定，工具链路也足够明确，就不需要进一步调用 agent，直接用 tool call 完成。比如已经明确要移除某个图片背景、替换某个文本、生成某个固定尺寸画板，这些都应该工程化处理。

第二种是 agent-loop 模式。适合单任务的循环执行，直到目标达成。

第三种是 coordinator 模式。适合多指令混合意图的执行，就如同上面 json 展示的，既要换风格，又要改文案，还要生成多个版本做选择。这时候就不应该让一个 agent loop 串行慢慢做，而是应该拆成多个子任务，让 content、image、layout 等不同能力并行执行，再由 coordinator 做整合。

第四种是 ask-user 模式。这个非常关键，用户其实能够容忍 AI 在正式干活前，先和他对齐一次。真正不能容忍的是 AI 假装理解，然后直接改错。比如用户说“把它做得更高级一点”，但当前画布里有多个设计、多个可修改对象，也没有明显的选中状态。这时候硬改，风险很高。更好的方式是先问一句：“你想调整哪一张设计？是整体风格更高级，还是重点优化标题、配色和排版？” 这不是 agent 不够聪明，而是产品应该对用户结果负责。

这也是我对 agent engineering 的一个核心理解：好的 agent 产品，不是把所有事情都丢给 agent。而是把确定性的部分工程化，把不确定性的部分交给 agent。agent 负责理解、规划和纠偏。工程系统负责稳定、快速、低成本地执行。

因此，agent engineering 有太多可做和可以优化的事情。但这些优化不是坐在会议室里想出来的，也不是写一份 PRD 就能等来的。

它必须来自实际操作。你要一行行看浏览器 console 里的日志，看每一轮 context window 里到底注入了什么，看每一次工具调用为什么成功或者失败，看 planner 为什么判断错，看 memory 为什么丢了关键信息。你会从一个旁观 AI 能力的人，变成一个真正理解 AI 产品边界的人。

02

AI 时代，对活人感的坚持

我自己有一个底线：无论团队有没有用 AI，只要最终产物不像人做的，而像机器批量生成的，就一律算废品。翻看我的飞书记录，我最常说的一个词就是「活人感」。写社群文案要有活人感，说人话；拍视频不要用 AI 配音，听得出来…

后来我发现，这个判断不只适用于内容，也适用于产品体验。

3 月，我一直在想一个问题：如果 Seede 是一个 AI 设计产品，但大多数人对 AI 设计的刻板印象还是文生图，那我们怎么体现自己的差异化体验和价值？

文生图的体验通常是：输入 prompt → loading → 等很久 → 出一张图。

这个过程其实很枯燥。用户盯着一个 loading，看不到中间发生了什么，也不知道 AI 到底有没有理解自己。最后结果出来，如果不满意，就只能重新输入 prompt，再等一轮。

那 Seede 能不能把「设计被一点一点做出来的过程」展示出来？如果用户能看到 AI 在思考、在排版、在找素材、在填文案、在调整布局，这个体验就会完全不一样。你会开始好奇：下一个布局框 AI 会放在哪里？下一段文字它会敲出什么？它会怎么处理图片和标题之间的关系？它会不会自己发现画面太空，然后补一个装饰元素？这个过程本身就会制造期待。

这种感觉就像，背后有真人（实际上是 ai designer）在协作，移动鼠标：一个负责 layout，一个负责素材，一个负责文案，一个负责细节调整。用户看到的不是一个黑盒结果，而是一个正在发生的创作过程。

这就是产品里的活人感。

所以如果 Seede 的未来，能做成一个没有 AI 味道的 AI 产品，我觉得就算大成了。虽然是 AI 产品，但用户不应该感受到冰冷的批量生成、模板化的假，以及黑盒等待的无聊。应该感受到的是：有人理解我，有人在帮我推进，有人在认真处理这个设计。

这也是我很感谢 ai coding 的地方。

在以前，这种想法很可能就停在一句话里：我们应该做一个更有过程感的生成体验。然后它会变成一个需求，进入排期，等设计，等研发，等资源。但创业公司很多时候等不起。那不如自己先做个 demo，把效果演示出来再说。最后 SF 活动现场，现场观众体验反馈很好，很有 aha moment。

当然，代价也很真实。

这直接导致我 4 月的 Cursor 账单爆炸，成为全司最大手大脚的人（笑死）。

但我更愿意把它理解成一种创业早期的研发成本：用钱和时间，快速把一个模糊想法撞成一个可被看见、可被讨论、可被验证的 demo。

03

构建系统，而不是增加功能

我对创业有一种执念：做完一个 task 还不够，总希望它能沉淀下来，变成一个系统。不能是今天解决一个问题，明天再靠人肉解决另一个问题。下一次遇到类似问题时，团队里新人也能复用这套东西，并且不至于做出破坏性的操作。

这有点像现在大家常说的 skill，但又不完全是 skill。

在我看来，skill 更像一个线性的工作流，或者 SOP。比如：写文章 → 找配图 → 做 SEO 优化 → 发布。这是一条明确路径。

但系统更像一个网状结构，是 infra 层面的。它不仅要完成任务，还要处理边界情况、权限问题、协作问题、回滚问题、质量检查问题。

我举个工作中例子，希望能讲清楚 skill 和我希望构建的系统的区别。

今年 3 月开始，我和实习生一起搭了一套 SEO 系统。不到一个月，Google Search Console 里的 impression 就开始有起色。你可能会说，不就是 websearch、写文章、多 agent 写作配图的 skill 吗？错了。skill 很难被长期维护，skill 只能作为系统中的生产环节被调用。

真正让我觉得有意思的，是怎么把 SEO 变成一个长期可维护的系统。让非技术同学也能快速上手，能够生产、管理、维护内容，并且不会轻易把页面结构、SEO meta、内容层级搞坏。

当时我和实习生一起探索了三种方案。

方案一：是直接 vibe coding 写网页。

这种方式最快，也最容易获得即时反馈。想做一个页面，打开 Cursor，写完就上线。

但它长期几乎不可维护。一个页面一个写法，图片素材到处放，meta 信息靠人记，slug 命名也不统一。短期看每个页面都能上线，长期看你根本不知道哪些页面属于同一个系列，哪些关键词已经覆盖，哪些页面互相引用。

还有各种细节问题：选题怎么归档？内容素材全部放在 public 文件里吗？页面层级和内部链接怎么设计？不同系列页面之间如何复用设计结构？当你做了 10 个系列页面以上，混乱就会开始出现。页面散落、素材散落、命名不统一、结构不统一，还容易出现某个页面 UI 被误触改掉的情况。兄弟，skill 救不了你。

方案二：是把网页设计和内容分开。经典的 headless 管理。但采用自研方案。

页面结构仍然可以 vibe coding，但内容用 markdown 文件维护。这比第一种更容易协作，因为内容不再直接散落在页面代码里。但 markdown 也有自己的问题。你需要约定一套格式：什么标记代表视频，什么标记代表图片，什么标记代表富文本，什么标记代表 CTA，什么字段代表 SEO title 和 description。只有标记足够清楚，网页才能稳定渲染。但这些规则对非技术同学，尤其是 marketing 同学来说，并不友好。

最重要的是，每次改内容还要提交 PR，还要等技术 review。久了之后，内容生产就会被工程流程卡住。

方案三：是采用 Pre-AI 时代就已经成熟的 CMS infra（虽然还不够好用，但也够用）

也就是把网页设计和内容彻底分开，但内容统一放到类似 Sanity 这样的 CMS 里维护。因为 SEO 不是一次性生成网页，而是一套持续运营内容资产的工作，后续维护的便利性和可靠性很关键！

页面结构、组件样式、交互效果，应该由工程系统来保证稳定；标题、正文、图片、meta、slug、分类、标签、发布时间、内链关系，应该作为内容数据被单独管理。这样内容就不再是散落在代码仓库里的文件，而是一套可以被查询、编辑、复用、审阅和发布的数据。

这件事对协作非常关键。

非技术同学不需要打开 Cursor，不需要改代码，不需要理解 markdown 里的特殊语法，也不需要每次改一个标题都提交 PR。他们可以在 CMS 里完成内容生产、图片上传、SEO 信息填写、草稿保存、发布管理。Marketing 要负责的，是内容质量、搜索意图、标题表达、转化路径和长期维护。

工程同学要负责的，是把页面模板、字段约束、渲染逻辑、权限和校验做好。

这其实是更健康的分工。

AI 可以继续帮忙写文章、找素材、做初稿、生成 SEO 建议，但最终内容会进入一个稳定的 CMS 系统，而不是直接散落到代码里。

但即便采用了 CMS 方案，也别觉得一劳永逸，系统的维护依然需要持续投入。CMS 解决的是内容承接和流程治理，不是自动保证内容正确。AI 可以写初稿，可以找配图，可以给 SEO 建议，但文章最终必须有人 review 一遍。

SEO title 和 meta description 是否合理？内部链接有没有断？图片 alt、canonical、结构化数据有没有问题？页面上线后，数据有没有变化？这些问题不会因为有了 CMS 和 ai agent 或者 skill 就自动消失。

你可以看看 ai 博主宣传的，他们大多只教你如何快速 build，却很少告诉你，持续维护才是更花精力的部分。

这也让我想到互联网时代的「避风港原则」：平台可以先让内容上架，出问题后再下架。

但 AI 时代做产品，难道也要变成这样吗？先让所有人随便 vibe coding，把功能和页面都堆上去，等 SEO 掉了、等用户发现 bug、等研发被迫救火，再回头修？

我觉得这不是长期主义。AI 让创建的门槛变低了，但它没有让维护成本消失。

越是人人都能 build，越需要系统来管理边界。否则最后得到的不是更高效的组织，而是一堆没人敢动、没人看得懂、没人愿意维护的页面和功能。

AI 把生产能力拉高之后，瓶颈开始后移。它堆积在治理流程、review 机制、质量标准、权限边界，以及和老系统的兼容上。这也是我非常看好的方向。当生产方式变了，承接生产结果的基础设施也一定会变。所以我越来越觉得，所有 SaaS 都值得被重新做一遍。AI 时代真正缺的，不只是更强的生成能力，而是更好的 infra、约束系统和维护流程。

04

build 越爽，欠下的债务越多

整体来说，我是负责 GTM 的。但这一年做下来，我越来越觉得，很多事情表面看是增长问题，实际都是基础设施问题。

比如最基本的归因。用户从哪里来？是小红书来的，抖音来的，Google 搜索来的，还是广告投放来的？他第一次看到我们是什么时候？中间有没有访问过别的页面？最后为什么注册？为什么付费？为什么流失？

这些问题听起来都很基础，但真正要回答清楚，并不容易。

如果只是要一个粗颗粒度的答案，接入 GA、Search Console 或者广告平台的数据，其实就能看个大概。

但真正的卡点不在这里。你要真想构建一个可持续的产品，就必须细颗粒度的记录用户漏斗情况，自己不能骗自己。但很遗憾的是，AI 时代，截至此时此刻，数据埋点和事件治理，跟不上新功能开发的节奏。大厂可以有一套自己的 SOP 和专属的埋点系统，千千万万普通的 builder 难道只能靠直觉？

当然，vibe coding 会给人一种错觉：好像什么都可以自己搭。写一个 dashboard，写几个 API，supabase 一连，轻轻松松。但真正难的是，这些东西能不能长期稳定地跑。

就拿我自己 coding 的两个事情来说：数据埋点和分销系统。早期我们自研过一套数据埋点和 dashboard，用 SQL 去查数据。

让我印象特别深的是，有一天早上八点，我想打开自研 dashboard 看看数据，结果把数据库搞崩了。

难绷。

这件事之后我意识到，你要考虑查询性能，要考虑权限隔离，要考虑数据口径，要考虑事件命名，要考虑历史数据兼容，还要考虑一个非研发同学点了某个按钮、跑了某个查询，会不会直接把生产库拖死。（说的就是我啊！！！血泪！！！）

成熟 SaaS 贵是有原因的。背后那整套稳定性、权限、容错、数据治理和最佳实践，你真的离不开。

过去 Pre-AI 时代，流程相对清晰：产品在 PRD 里写埋点方案，研发按照方案埋点，再接入 Amplitude、Mixpanel 或者自研系统。

但 AI 时代，构建产品变得太容易了。毫不夸张的说，现在的功能都不是研发同学完整做出来的，而是 PM、designer、mkt、研发都在 vibe coding。今天加一个按钮，明天改一个 onboarding，后天又新增一个支付弹窗。几十个 PR 合并之后，功能是上去了，但数据债也一起留下了。

这个新功能有没有埋点？这个点击应该是新建一个 event，还是作为老 event 的 property？字段命名是不是和历史口径一致？以后分析漏斗时，这个事件能不能和老数据对上？这些问题都很细，但每一个都会影响后面的增长判断。如果埋点乱了，最后 dashboard 看起来很漂亮，但你不知道它到底在表达什么。

更麻烦的是，AI 现在还很难直接替你判断好这些东西。亲测。就算是 Opus 4.6 的 plan mode，也很难直接给出一套可以放心上线的数据埋点方案。它可以列出很多事件名和字段，但这些事件是否符合你的业务口径，是否和老系统兼容，是否会造成重复统计，是否能支撑未来分析，最后还是必须有人（我…..）亲自消化。

分销系统也是一样。一开始看起来，分销系统很简单。有一个邀请链接，有一个 dashboard，能看到谁邀请了谁，成交了多少，应该返多少钱。

页面和字段都很好搭。真正难的是支付。你怎么合法合规地处理批量支付？怎么处理税务？支付供应商支不支持这些能力？分销系统和订阅系统不兼容怎么办？这些问题不是 demo 阶段会暴露出来的，但只要你真的跑业务，一定会遇到。

还有跟留存紧密相关的文档功能。典型的坑。每一个功能上线，理论上都应该同步更新 documentation。但现在的情况是产品里的按钮改了，文档截图还是旧的。API 参数变了，文档没有更新。某个功能逻辑调整了，用户还在按照旧说明操作。最后因为信息的 gap，客服也解释不清楚，研发也说不明白，产品也不知道谁动了代码。

是谁动了奶酪？查 PR 去吧....

这里我觉得 Mintlify (https://www.mintlify.com/) 这个方向挺有意思。它不是简单帮你搭一个漂亮文档站，而是把文档当成一套面向人和 AI 的知识基础设施。支持 docs-as-code，可以和 GitHub 连接，有 PR preview，有 AI search，有文档 analytics，也支持从 OpenAPI 生成 API reference。它开始强调用 agent 来维护文档：根据代码变化、PR 合并、Slack 讨论，自动生成文档更新建议。

这个方向很对。因为 AI 时代的文档问题，不是从 0-1 的构建，而是文档能不能持续跟上产品变化。它既要让人读懂，也要让 AI 能正确检索、引用和回答。未来用户可能不是打开文档一页页看，而是直接问 AI，如果文档本身不结构化、不准确、不更新，那 AI 只会把错误答案更快地分发出去。

文档也变成了 infra。

埋点系统、分销系统、文档持续优化、SEO 系统的维护...总总这些，构成了我这年最深切的洞察：AI 让 build 变快了，但 build 之后的每一件事，都没有消失，都是债务！等着人去维护。

怎么让这些被快速生产出来的东西，进入一个稳定、可审阅、可维护、可扩展的系统里？

这需要人，也需要新的基础设施。

所以失业是不用担心的。但肯定会转向，从亲手 build，变成维护和治理越来越多 AI build 出来的东西。

05

AI native 组织，谁来擦屁股？

这是我这一年觉得最有意思的 insight 之一。

之前我在 Founder Park 工作，经常和记者、编辑打交道。这个分工在内容产业里非常成熟。记者负责到一线采写，找到选题，采访，生产初稿。编辑负责判断选题值不值得发，稿子结构是否成立，表达是否准确，事实有没有问题，最后能不能代表这个媒体出街。一个好的编辑要有 taste，要有判断力，也要对最终质量负责。

我越来越觉得，AI 时代的研发组织里，也会出现类似的分工。

程序员不会消失。但很多程序员的角色，会从「记者」变成「编辑」。以前是自己去生产内容（代码）。以后是面对大量 AI 生成的代码（屎山）和功能，判断、筛选、修改、整合，并对最后的系统质量负责。

因为 AI native 组织最大的特点，是人人都可以成为 builder。但谁来兜底、救火和擦屁股很关键！Marketing 可以自己改网站，做 SEO，搭内容自动化工作流。PM 和 designer 可以自己做 UX 优化。

谁来测试？谁来审核这些 AI 写出来的代码？单元测试（这个 ai 能做）都跑通了，谁来保证不会因为依赖、状态、样式、数据结构的变化，影响其他模块？每天几十个 PR 提上来，谁来做那个守门员？如何保证新的改动，不会破坏原本可靠的系统？

习惯过去生产流程的程序员可能会说：那就招个测试吧。但在我看来，是甩锅和不愿意接受现实，也不够 AI native。不是说测试不重要。而是 AI 带来的是生产关系的变化：以前是少数研发在生产代码，现在是更多角色都能生产代码。当生产者变多，产出速度变快，单靠传统 QA 很难兜住所有问题。

更何况，谁都不愿意读屎山代码。尤其是 AI 写出来、提交者自己也没完全理解的屎山代码。所以这个问题到底应该怎么解决？

是通过一种新的组织分工来解决，比如让研发更像编辑，让业务同学承担更多自测和验收责任？还是通过未来某种 AI infra 来解决，比如自动 review、自动测试、自动识别影响范围、自动维护文档和埋点？

我现在还没有完全确定答案。但我很确定的是：AI coding 不可阻挡。它一定会继续进入更多团队、更多角色、更多业务流程。所以这个问题不是可选题，而是必答题。

这个体感我们非常强。我们团队差不多快 10 个人，几乎每个人都在写代码。PM、designer、marketing、研发，都在提交代码和 PR。当每个人都可以 build，每个人都可以提交 PR，组织协作很快就会变得混乱。

有几个现象非常高频。

第一，非研发同学会抱怨权限不够

不能随便新定义数据字段，不能直接修改数据库，不能随便改一些底层逻辑。但这其实是合理的。谁都担心 AI 一不小心把库删了。这是合理的。在 AI native 组织里，权限设计会变得比以前更重要。

因为能动手的人变多了，能造成破坏的人也变多了。

能不能有一套更 AI native 的沙箱机制或者 infra 层，让非研发同学也能安全地动手？比如，让他们可以在隔离环境里新建字段、改页面、跑自动化、生成数据结构，但所有改动都先进入一个可预览、可 diff、可回滚、可审计的空间。真正影响生产系统之前，必须经过权限校验、风险扫描、自动测试和人工 review。

第二，非研发同学产出的代码，对人类阅读来说可维护性经常很低。

因为很多代码都是 AI 写的，提交者自己也未必完全理解。能跑，但没有模块化。文件散落在各处。逻辑重复。边界条件没处理。最后研发不得不去 review，而且 review 起来很吃力。这背后的 insight 是：AI 让代码生产变快了，但没有让代码自动变成组织资产。能跑的代码，只是完成了功能。能被别人理解、修改、复用、回滚的代码，才是组织资产。

我很认同喵神的一个分享：在让 AI 写代码之前，应该先定义 spec。然后 ai 代码写完之后，再让 ai 用文档的形式，把最终实现和最初 spec 对齐。也就是先说清楚要做什么，再让 AI 做，最后再让 AI 解释它到底做了什么，和 spec 是否一致。减少人维护的成本（假说是未来代码都由 ai 来维护的话）。

我认为这个方式对于独立开发者来说是有效的，而且是可控的。独立开发者虽然也会让 AI 写很多代码，但自己通常对需求、上下文和最终改动心里有数。

可是到了组织协作里，这件事会变复杂很多。因为 PR 的 reviewer，不一定参与过最初的 spec。reviewer 不知道你为什么这么改，也不知道你和 AI 中间对齐过多少轮。拿到一个 10000 行代码改动，任何 reviewer 都会头皮发麻。

一个功能可能跨多个模块，影响数据、权限、埋点、样式和历史逻辑。这时候，仅仅有一份 spec 和一份实现说明还不够。组织真正需要的是更完整的变更上下文：这个需求为什么要做？它影响哪些模块？它改了哪些数据结构？它有没有新增事件和埋点？它会不会影响 SEO、文档、权限和老用户路径？如果出问题，怎么回滚？也就是说，spec 是必要的，但不是充分的。对于一个开展长期业务的组织来说，需要有更 AI native 的协作方式，把需求、实现、影响范围和验收标准都串起来。

第三，研发其实并不喜欢做纯 review 的工作，尤其是 review 别人的屎山代码。

这个不多说，懂得都懂，但在 AI 时代被放大了很多。从一个痛点，变成了一个巨大痛点。对提交者来说，这是一个功能完成了。对 reviewer 来说，这是一个债务被交到了自己手上。

第四，业务同学往往更懂用户和 UX，但容易变成拆东墙补西墙

我们经常会遇到一种情况：很容易用 vibe coding 框框几下，把一个功能做出来。结果影响了原本正常的另一个功能或者 UI。于是团队陷入往返修 bug 的循环。AI coding 确实加速了 building 的速度。但 review、治理和维护这些苦活累活，反而变成了新的门槛。

我现在听到很多关于 AI native 组织的讨论，大概有两个方向，非常赞同：

1、未来工作里会有更多内容变成审阅别人的产出。你应该预期，公司里会有越来越高比例的人，去做以前只有技术用户才能做的事。这会释放很多创造力。但它也会在另一端制造巨大压力。2、很多事情会有点像照看 agent，让它们按你的要求做事、部署，然后一路维护，确保它们持续工作。

谁来最终为系统负责？兜底，很重要。

短期 FDE 和外包，长期 infra，我的 bet。

06

别迷信 demo：产品是长期维护出来的

只要真的做过业务，应该都会认同一句话：demo 不等于生产级应用。

但 AI coding 会给人一种幻觉，包括我自己，半年前可能也会觉得 AI coding 无所不能。除了数据本身，围绕数据构建的 UI、UX、database、dashboard、workflow，好像都可以被 AI coding 快速搭出来。OPC 和独立开发者，一个人就是一个公司。但这半年真正做下来，我发现自己当时想简单了。

最初的 build 会带来极大的成就感，但真的只是幻觉，只看到了冰山一角。

AI coding 擅长做 demo，仅此而已。注意！即便这个 demo 已经有付费用户了，它也可能仍然只是 demo。我这里说的 demo，几乎等同于早期 MVP：它验证的是一个功能闭环能不能跑通，而不是一个产品能不能长期运行。

对于独立开发者和 OPC 来说，这是一个甜蜜的陷阱。用户说这里能不能多一个按钮，那里能不能多一个导出格式，AI coding 一下子就能补上。

但产品不是功能的堆叠。产品需要取舍。

尤其是在新功能和老功能相互冲突的时候，要判断什么该做，什么不该做，什么应该合并进已有路径，什么会让系统越来越乱。几十万行代码之后，真正难的是让系统在不断变复杂的情况下，依然保持清晰、稳定、可维护。

举个例子。现在人人都可以 vibe coding 做一个小游戏。你可以让 AI 写一个贪吃蛇、一个塔防、一个消除游戏。

几分钟就能跑起来，部署上线，牛逼！画面有了，操作有了，分数有了，看起来很像回事。但真正的问题是：真正承载游戏长期运行的底层环境和系统，所谓的 runtime 在哪里？

帧率稳不稳？不同设备上表现怎么样？资源怎么加载？状态怎么保存？崩溃了怎么恢复？关卡怎么设计？数值怎么平衡？用户为什么第二天还回来？作弊怎么防？版本更新后，老存档会不会坏？客服怎么处理玩家投诉？…

demo 只证明这个想法能跑，实际上还差得远，但你多用几天，就会发现它没有留存设计，没有数据反馈，没有稳定性保障，没有内容更新机制，没有客服，没有文档，也没有长期维护的人。产品要证明这个东西能长期运行，并且有人愿意持续使用。

这些能不能被解决？我的答案是，现在还不能，但需要有面向未来的 AI infra 来解决。

这件事放到 Seede 里也一样。我们付出了很多努力，去解决快速 build 带来的债务。

1、demo 里的支付，是你能接一个微信支付，跑完一个小闭环。产品里的支付，是你要考虑付费墙是否合理，订阅怎么续费，退款怎么处理，税务怎么合规，渠道分销怎么结算，异常订单怎么补偿。兄弟，是自动化还是手动搞？

2、demo 里的数据，是你能看到有多少人点击、注册、付费。产品里的数据，是你要知道每一步转化率是多少，用户为什么流失，哪个渠道来的用户质量更高，哪些行为真的和留存相关，数据口径能不能长期保持一致。最后一句很关键。

3、demo 里的客服，是创始人在群里手动回复几句。我们有 30 多个微信群，各种重复问题，我回复的头皮发麻。但产品里的客服，是用户遇到问题时，有没有文档，有没有工单，有没有错误日志，有没有内部排查路径，有没有人能接住。当然后来我们也采用了 infra，用 linear 工单的形式，对研发任务进行排期和追踪。

4、demo 里的文档，是写一篇 quickstart。产品里的文档，是每一个功能更新后，文档能不能跟上；截图是不是新的；API 参数有没有变；AI assistant 引用的答案是不是准确。不赘述了，头疼。

5、demo 里的稳定性，是今天在你电脑上跑通了。产品里的稳定性，是它在不同设备、不同浏览器、不同网络、不同历史数据、不同权限状态下，都不能轻易坏掉。

做项目，不要担心被开源项目替代。逻辑就是不要低估做成一个可持续运行的产品的难度。开源项目当然很强。AI 时代，复刻一个产品的第一版也会越来越容易。但竞争力往往不在开头那一轮复刻。真正难的是长期维护。商业产品的价值，也不只是代码本身，而是持续维护、持续迭代、持续服务用户的能力。

一个暴论，运维是脏活累活，在 ai 时代会更加值钱。运维不是 AI 企业级落地的最后一公里，而是，这场马拉松才刚开跑...事情还多着呢！

07

SaaS 不会消亡，但都值得重新做一遍

接上条，demo 很容易，但产品是长期维护出来的。这件事如果继续往下推，就会得到一个很直接的判断：SaaS 不会消亡。相反，我觉得 infra 级别的 SaaS 会重新变得非常重要，只是它们都值得被 AI native 的方式重新做一遍。

可以思考个问题，为什么 Cursor 或者 AI coding 产品商业化很成功？逻辑其实很简单：它们站在生产环节的 build 端，解决了过去产研链路里最痛的瓶颈。过去，最大的卡点是从 PRD 到研发。

但如果站在更高维度，公司业务运转角度，产研只是价值链的开端，AI coding 目前主要解决的是 one-time building 的问题。它没有真正解决 keep it running 的问题。

如果开头投入资源做了一个系统，肯定不是希望它只跑一次、火一次、上线一次，而是希望它能持续运行、持续维护、持续产生现金流。而这部分巨大的冰山下的价值，就藏在 long-term maintaining 里。而且这个是短期没办法被模型规模化的东西，同时也是全新的赛道，很适合积累 know-how，

这也是我为什么觉得 SaaS 不会消亡。相反，AI native 时代会需要一批新的 SaaS，去承接 building 之后的维护、治理、协作和交付。

所以我现在对 AI 创业也更现实了：需要离模型稍微远三条街。

判定方法很简单，如果你的产品能力完全是因为模型牛逼而牛逼，那基本上就是模型的功劳。这种我认为未来要靠供应链管理 + 分发渠道的能力，这是护城河。不是技术本身。

但模型厂商很难做的是什么？是交付。尤其是长期、稳定、深入业务现场的交付。你要理解客户的业务流程，接入他们的老系统，处理权限和数据，适配他们的组织习惯，解决一堆不标准的边界问题。这不是一个通用模型 API 能直接完成的。我也特别相信现在所谓 FDE 这个职位的出现。

短期看，很多 AI 产品都需要人力去交付。FDE 要去客户现场，把模型能力接进真实业务里，写 glue code，处理流程，改工具，做集成，解决最后一公里。

长期看，这里面一定会长出 AI native 的 SaaS infra。

这和互联网、移动互联网时代的趋势很像。一开始，很多事情都要靠人肉交付和定制。后来，重复出现的需求会被产品化。再后来，它们会变成标准化的 SaaS 和基础设施。

我相信，AI 时代也会经历这个过程。现在就很适合开始做。

旧 SaaS 会被重写。新 SaaS 会围绕 AI native 的生产关系重新诞生。

未来最有价值的软件，不一定是帮你生成更多东西的软件。而是帮你把生成出来的东西，安全、稳定、长期地变成业务资产的软件。

08

创业人才的标准：通才 + 能业务闭环

AI 时代，再单纯用岗位职能来筛选人才，我觉得已经不太合适了。因为招进来的每个人，某种程度上都应该是 builder，都需要学会用 AI 和 coding 的方式解决问题。

所以我现在更看重两点：通才，以及能业务闭环。

这个感受非常深。创业是人推着事情走，而不是被事情推着人走。没有人希望在创业公司里当一个纯 manager，天天追着其他同事问进度、催交付、补漏洞。彼此都痛苦。

最好的状态是，每个人都是 owner。在 OKR 对齐的基础上，每个人都能认领一个业务闭环，并且对它全面负责。不是只负责其中一个环节，而是要从用户问题、UX、UI、数据埋点、数据结构、测试、上架，到后续反馈和维护，都能一路盯到底。

Seede 的产品经理和设计师，我觉得就非常优秀。他们不是只停留在提需求和出设计稿，而是真的能把一个功能从用户问题拆到具体实现，再一路推进到上线和验证。

除了少数 infra 层、数据打通、权限边界这些必须由研发兜底的部分，很多功能逻辑 PM 和 designer 基本都能自己闭环验证。

所以我对那种特别习惯大公司流程分工的人，反而会更谨慎。这个归产品，那个归研发，这个归运营，那个归数据。一个只会完成自己岗位任务的人，在 AI 时代可能会变得越来越被动。

如果一个问题对业务重要，你就要想办法推进它。这是底线。

哪怕一开始你不懂，也要学到能判断、能拆解、能协作、能验收。

这才是创业里的 owner。把没人管的事情扛起来，把模糊的问题变清楚，把半成品变成能长期运行的系统。

09

聊创业本身：事情不会自己发生

这一年收获很丰富。我确实推动了很多事情发生，也对创业有些不一样的理解。

去年可能会觉得，创业最难的是把产品做出来。现在回头看，产品当然难，但更难的是持续让事情发生。

创业不是等资源到位，等别人安排，等需求排期，等某个合适的时间点。创业是你发现一个问题，然后想办法把它往前推。

没人拍短视频，那就自己拍。

没人做 demo，那就自己用 Cursor 做。

没人把 agent loop 跑明白，那就自己熬夜拆。

没人做那个想要的产品效果，那就先做一个能演示的版本。

你不去要，就永远只能等下去。

创业者是让事情发生的人，不是等事情发生的人。

这句话听起来很鸡汤，但做过之后会发现，就是这样。

这是创业者的基本素养，我觉得大部分 builder 都有这个特质：不等别人把条件准备好，而是先想办法往前拱一步。而且，这也是 AI 时代独立开发者和 OPC 最大的机会。因为工具已经足够强，单个人能推动的事情变多了。

但下一步的问题是：产品做出来之后，怎么让别人知道？怎么让第一批用户愿意试？怎么让他们持续买单？

我亲身实践出来的答案，就一句话：像做内容一样来做产品。

不要一开始就指望抢占一个多么大的市场。换个角度看，它更像粉丝经济。如果你是独立开发者，不一定需要服务所有人。你可能只需要 2000 个真正喜欢你、信任你、愿意持续付费的用户。你可以按照独立开发者最舒服的状态来开发：用户提需求，你快速理解，快速更新，快速反馈。

产品和用户之间不是冷冰冰的交易，而是长期关系。但是相反，如果没有构建起自己的圈友、社区和信任关系，只是闷头做一个产品，基本很难成。所以 build in public、build in community 会变得更重要。让用户看到你在做什么，为什么做，怎么取舍，踩了什么坑，下一步想解决什么问题。这本身就是内容。

anyway 我觉得这个时代，做一个自媒体和做一个 builder 的难度是一样的。都是在用内容在说话。你只需要让真正同频的人找到你，并且愿意和你一起往前走。

某种意义上，和开个餐馆没什么本质区别。美团上，开倒闭的餐馆，死因有很多，但绝对有一个共性，就是没有回头客。

产品也是一样。第一次让用户来，不代表生意成立。真正重要的是，他为什么回来，为什么愿意继续用，为什么愿意推荐给别人。AI 可以帮你更快开张，但不能替你留住客人。

还有一个感受很深的地方，是节奏。创业最大的体感之一，就是产品、研发、GTM 不能各打各的，必须用同一股节奏往前推。

这件事我踩过坑。比如 Claude Design 这波其实没太跟上，当时以为 Claude Design 热度会维持 1 周，结果刚发布，deepseek 来了，Claude Design 微信指数立马下滑。就是这 2 天的窗口期，抓不出就会错过。你内部还在纠结怎么产品需求排期，外部用户已经被别的产品教育完了。

更可怕的是，等到功能终于能用了，外面的大环境、叙事、关注点已经变了。这时候再发，就不是晚一天这么简单，而是整个势能都没了。

从 GTM 角度，做内容也是一样，审核团队做的物料，我不关心录制得多么精美，特效多么复杂，只关心它有没有踩在正确的节奏上。开头是不是能抓住人？信息密度是不是够？情绪推进是不是顺？用户看到第三秒、第十秒、第三十秒的时候，还有没有理由继续看？有些视频拍得很朴素，但节奏对了，就能跑出来。端午节我们才验证了个视频，发出去几小时就十万播放，几千点赞和收藏。

所以，回到创业，我的理解，不是每天都要猛冲，但一定要有节奏感。

什么时候该快，什么时候该慢，什么时候可以先做 70 分版本去验证，什么时候必须憋到 90 分再出街，这些判断非常重要。

10

看一万遍，不如自己摔一遍

感谢你看到这里。

上面种种，基本都是我这一年的阶段性思考，也是我对未来的一些下注判断。

不一定都对。很多判断可能过半年回头看，也会被我自己推翻。

但它们至少不是从二手信息里长出来的。

这一年我很深的一个体感是：AI 时代，信息差会变小，但实践差会变大。大家都能看到最新的工具、最新的 demo、最新的论文、最新的产品发布。今天出了一个新的 agent 框架，明天出了一个新的 coding tool，后天又有人做了一个很炫的 demo。

这些东西我都很感兴趣，也会第一时间去看。

但看一万遍，真的不如自己做一遍。

所以，如果你也在做 AI 产品，或者正在用 AI coding 改变自己的工作方式，我会很建议你真的下场试试。

转载原创文章请添加微信：founderparker