aigcbar - null

深度解读AI创业复盘：警惕Build幻觉，拥抱AI变现新机遇

type
status
date
slug
summary
tags
category
icon
password
网址
从 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 输出了许多一线踩坑后的真实思考。
文章目录
去年 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、每一个系统，都需要有人维护。人不会失业，只是工作方式会变。
如果你有相同的经历和痛点，那我们看到的痛点和机会，是一样的。下面内容不会只讲判断，也尽量结合这一年真实主导做过的事来写。
01
Agent 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 可能长这样：
{
"actionMode": "modify-layout",
"confidence": "high",
"sceneName": "poster-design",
"continueDesignStyle": true,
"strategy": "coordinator",
"brief": "修改标题、替换产品图、调整底部布局",
"subtasks": [
{
"id": "s1",
"agent": "content",
"brief": "把标题改成「夏季限时特惠」",
"deps": [],
"targetNodeIds": ["txt001"]
},
{
"id": "s2",
"agent": "image",
"brief": "把产品图替换为夏季新品",
"deps": [],
"targetNodeIds": ["img002"]
},
{
"id": "s3",
"agent": "layout",
"brief": "底部联系方式区域改为两列布局",
"deps": ["s1", "s2"],
"targetFrameId": "abc123",
"layoutMutation": "patch-in-frame"
}
],
"toolSteps": [
{
"tool": "createframewith_image",
"args": {
"assetId": "img-uuid",
"w": 1080,
"h": 1080
},
"description": "创建帧并放入图片"
},
{
"tool": "remove_bg",
"args": {
"nodeId": "$prev.imageNodeId"
},
"description": "去除图片背景"
}
]
}
而且 tool 不再以单个的形式出现，而是规划好连续的 toolsteps。举个例子，用户输入：“帮我模仿 Seede 网站做个活动海报。” 一个合理的链路应该是：第一步，agent 做规划。它判断这是一个 create 意图，并规划出工具和使用步骤：websearch → getofficialurl → readurl → screenshot → uploadasreference_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、内容层级...
Loading...

没有找到文章