AI创业一年复盘：真实参与、经验摔打、知行合一

AI创业一年复盘：真实参与、经验摔打、知行合一

去年6月，我顺利从新加坡NUS工学院毕业，回国开启了人生第一段全职投入的创业旅程。转眼，已经过去了整整一年。世界变化飞快，趁着端午假期，我写下一篇约2万字的长文，试图总结这一年创业的收获，并把踩过的坑和思考的结论写下来。

这一年里，我作为团队的联合创始人，亲历并参与了产品从设计到工程、从原型到落地的全过程。面对AI native产品开发的复杂性，我深刻体会到，创业后的学习曲线陡峭，信息密度极高，让原本以为简单的事变得异常艰难。

我在创业初期，曾天真地认为只要把AI能力应用到设计领域，就能解决大部分问题。但实践告诉我，这远远不够。AI确实让『做出来』的效率提升了，但它也把更多系统性问题提前暴露出来：维护、审查、权限、数据、文档、支付、稳定性、协作边界和用户验收等等。这些过去虽存在，但因为_BUILD过程缓慢，问题也来得慢一些。如今加速了，每个问题都变得更加紧迫。

这一年，我发现了一个重要理念：AI native组织最深刻的变化，不是代码的生成，而是协作模式的重构。当人人成为builder，工作的边界和效率都会被重新定义。而这背后，我以为真正的问题，是『谁维护AI系统』？

在创业初期，我对AI的潜力充满期待，但很快便意识到，仅仅依靠技术输出是不够的。很多错误之所以发生，是因为缺乏对业务和用户意图的深刻理解。我曾尝试自己复现并重构Claude Code中的一些AI loop和memory机制，这个过程让我受益良多。

在产品开发过程中，我制作了100多个Spec验收测试用例，检验AI在不同设计场景下的规划与执行能力。这些测试反映了一个深刻的现实：即便是看似合理的规划，执行阶段也可能偏离预期，导致用户体验严重受损。比如，用户希望修改某个设计，但Agent却误操作了另一个；用户口述意图时，Agent却完全误解，把任务走错了链路。

尤其是在无限画布的设计产品中，理解用户的意图比简单调用API要复杂得多。用户可能只是说一句『把小米汽车改成特斯拉』，对人类来说可能很自然，但对AI来说则非常模糊。它需要知道：到底在哪个画板上？哪个图层？哪一个设计对象？如果系统里有100个设计，没有明确的选择，Agent很容易『盲目』执行。

我意识到，agent engineering的真正价值，不在于AI是否能执行任务，而在于它是否能『准确理解用户意图』，并『合理规划执行路径』』。因此，我在Seede的开发中，逐步拆分了整个Agent流程，分为两个阶段：planner和execute。

第一阶段是planner，负责意图理解、任务分割与路径选择。比如用户说『帮我模仿Seede网站做个活动海报』，Agent需要判断这是『创建』还是『修改』，任务是否多步骤、是否有依赖关系，并规划出明确的工具链路：web_search → get_official_url → read_url → screenshot → create。

第二阶段是execute，用不同模式对任务进行处理：fast-exec（直接调用工具）、agent-loop（单任务循环）、coordinator（多任务并行处理）、ask-user（避免误操作，提前对齐用户意图）。这些模式让Agent既有灵活性，又能提升执行效率。

在这个过程中，我不断提醒团队：一切交互不应该由AI独自完成。如果最终产物不像人做的，而是机械式生成的，那就失去了产品的人性温度。因此，我坚持一个底线——任何AI生成的设计，要有『活人感』。

这不仅适用于文案写作，更适用于产品体验。设计的灵魂不在于技术的堆叠，而在于最终展示的『情感温度』。比如，用户希望将海报做得『更高级』，但Agent单方面执行，反而让设计失去原始特色。这时候，产品应该先和用户对齐，而不是直接『揣测』。

AI engineering的优化与实践，必须来自真实的场景。只有深入了解设计过程中的每一步，才能让AI真正成为“人”的延伸，而不是替代者。