AI Coding 或者 Coding Agent，或许是当下最火热的 AI 赛道。这是模型能力的主线，更强的代码能力，意味着模型能够解锁更多应用场景。
在全行业都在体验 AI Coding 的时候，氛围编程 Vibe Coding 成为了最热门的关键词。
Vibe Coding 引入了大量非专业代码人群，因此饱受关注。但陈志杰意识到，严肃场景的软件生产比想象中复杂的多。
软件开发是一个数十年的产业，软件开发构建了今天我们熟悉的整个「数字世界」。
而写代码，仅仅是软件工程的一个子环节。这意味着，刚刚能够做到基础 Coding 的大模型，也许之后有机会解决更大更难的问题。
一个有机会被 AI 颠覆的价值极高的存量市场。
2025 年初，前 TikTok 算法负责人陈志杰选择创业，与老搭档刘晓春一起，创办言创万物，聚焦 AI Coding 方向，更准确地说，AI SWE（软件工程）。
我们找到陈志杰和刘晓春，聊了聊他们眼中的 AI Coding 和 AI SWE。AI 将会如何改变软件生产的全链路？未来工程师与 AI 之间的关系会是怎样？作为创业公司，他们打算怎么做？
采访 ｜ Nico、李一豪
编辑 ｜ Nico、万户
超 6000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。
-
最新、最值得关注的 AI 新品资讯；
-
不定期赠送热门新品的邀请码、会员码；
-
最精准的AI产品曝光渠道
公司 & 团队介绍
言创万物是一家致力于以 Agent 技术重构软件研发的 AI 初创公司，成立于 2025 年初，已完成近千万美元天使轮融资。我们正在构建一支 AI 驱动的团队，从产品、技术到组织全面拥抱 AI，以推动软件开发进入下一个时代。
陈志杰，2010 年毕业后加入百度凤巢从事算法研发工作。2019 年之后在欢聚时代内部创业，2020 年底加入字节，开始做推荐算法。当前为言创万物 cofounder & CEO。
刘晓春，2011 年起在百度凤巢从事算法研发，2019 ～2020 年在欢聚时代内部创业。2020 年底返回百度，先后在凤巢、搜索、电商等负责技术、产品。当前为言创万物 cofounder & COO。
01
写代码只占软件工程师工作的 30%
Founder Park：从 TikTok 出来创业，为什么不选择原本非常熟悉的泛娱乐赛道？
陈志杰：我个人感觉这一波最本质的其实是生产力的提升。我之前也看过很多 ToC 的娱乐向产品，不仅 DAU 体量非常小，最可怕的是 DAU 不怎么涨，这是一个很大的问题。
但真正提升用户效率的方向，像 Cursor、Replit 等编程工具，ElevenLabs 、Harvey.ai 、Glean、Abridge、Sierra、manus、Genspark 等法律、医疗领域应用，还有智能客服等场景都涌现出很多不错的公司。所以我们创业一开始的大方向，也是锁定在提升生产力与效率的领域。
刘晓春：我们确实也考虑过 C 端，但最后还是觉得——AI 在 C 端目前缺少一个真正有吸引力、能打动用户的产品形态。它虽然很强，但离「让人非用不可」的阶段还有点距离。
而反过来看，生产端就不一样了，效率提升这件事本来就和 AI 是天然契合的。它解决的是实际的问题，能带来非常明确的价值，效果看得见，摸得着。所以我们觉得，还是应该把精力聚焦在这个方向上。
李一豪：过去几个周期里面，很多 C 端娱乐产品还是借助媒体载体形态的变化，从广播、电视到 PC、移动设备，每一次硬件迭代都催生出适配新形态的产品，具有强烈的媒介依赖性。但是我们现在看到的这波 AI 进展，还是初步的、文本 based 的智能，刚刚到推理的阶段。对于娱乐的颠覆，它现在还没办法跟现有的、高质量内容生产的上一代工具去 PK。
陈志杰：是的，你看上一波那些很成功的产品，比如 Facebook、YouTube、Instagram、Twitter、TikTok/抖音、快手，它们背后的本质是某种智能吗？不是。是某种生产力的提升吗？也不是。它其实本质还是人与人之间的连接，或者是内容本身。
Founder Park：提到 Coding，现在最火的词是 Vibe Coding，你怎么理解这个概念？
陈志杰：vibe coding，跟着感觉走编程。可能对于一些 demo 或自娱自乐开发很有趣。但严肃的开发场景没那么简单。不要小看严肃场景的复杂度，也不要小看专业工程师的才智，那些严肃场景的开发不是那么容易被 vibe coding 替代的。
很多人只看到 AI Coding 本身，却忽略了它只是软件研发生命周期的一环。实际上，工程师日常工作中，coding 环节的时间占比通常不超过 30%。国内外公司普遍都这样，像红杉对 Codex 团队的采访也说到，工程师编码时间不超 35%。真正的机会在于 AI SWE（AI 软件工程，Software Engineering）。
Founder Park：写代码只是整个软件工程（SWE）中的一环，怎么理解 Coding 在 SWE 中的定位？
陈志杰：SWE 是一个很复杂的事情。无论是从软件生命周期还是软件架构分层视角看，coding 都只是其中一个环节。
从软件研发生命周期视角看，SWE 是指软件（传统软件/互联网产品/新一代 AI 产品等）生产的全流程，包括需求沟通、技术设计、writing code、code review、testing、代码合并、程序构建、部署发布、监控运维的整个过程。 写代码仅仅是整个 SWE 全流程中的一部分。从统计数据看，中外公司工程师日常工作写代码的时间，平均下来都不会超过 35%。
从软件分层架构的视角看，任何一个真正有实际应用价值的 online service，靠一个单一模块（代码库）是无法 work 的。比如一个严肃的在线服务，除了你直接写代码的那个模块，还需要考虑负载均衡、缓存机制、数据存储、前后端架构、服务监控、数据落盘、报表分析等等很多依赖的模块。
当前 AI 主要还是单个模块下的代码生成，这还远远未到达终态。写某个模块的代码仅仅是第一步，SWE 中还需要众多工作要完成。现实中的这些服务模块、配置项、环境依赖需要严丝合缝的「咬合」在一起，否则是 run 不起来了的。
整个数字世界都是建立在软件基础之上，产值不言而喻。传统 SWE 领域发展至今，涌现出了众多优秀的开源或闭源工具了，也出现了非常多以「提供软件技术服务为核心业务」的高市值公司，比如云厂商，Oracle，databricks、mongoDB 等等。
「软件工程/软件生产」不是一个 fancy 的词汇，也不是新概念。但任何所谓 fancy 的概念的落地，都是在软件基础之上的。而作为 foundational infrastructure，SWE 领域的发展依然欣欣向荣，在每个技术大突破浪潮下，都会创立非常优秀的公司。
Founder Park：这样一件复杂、长链路的事情，为什么不是大厂做？创业公司有什么机会？
陈志杰：正是因为 AI SWE 覆盖的场景足够广泛而且很复杂，目前还没有一家公司能解决所有环节的问题，这正是行业的巨大机会所在。我们可以看下云厂商，aws 上的 CI/CD 服务，多数云客户倾向于使用第三方工具，而非完全依赖云厂商自家的 CI/CD 服务。所以我相信，AI-SWE 的发展也会如此，未来可能会有十几家很有价值的 AI-SWE 公司，而非一两家垄断。
大公司在这方面的推进速度也未必快。例如，GitHub Copilot 作为最早做 AI Coding 的产品之一，如今它的使用体验好像不如后起之秀 Cursor。谷歌前段时间推出的编码工具 Jules，实际体验也较为一般。
相比之下，创业公司虽资源有限，但在聚焦的细分领域投入往往不小。以 coding 产品化项目为例，大公司投入的人力可能也就几十人，这样去对比的话，考虑到大厂还存在组织效率等其他客观条件的限制，我觉得这里一定有创业公司的机会。
刘晓春：我补充几点看法。
首先，AI Coding 是一个问题特别多、用户又特别挑剔的领域。很多用户会因为某个功能特别好用就留下来，也会因为一个点不顺手就立马流失。这种情况下，其实是有利于新玩家进入的。因为一旦现有产品解决不了用户的问题，用户就会自然转向更好的新产品。
第二点，这个领域技术更新特别快，可能前几个月还领先的模型，没过多久就被别的模型超越了。这种技术的快速演进，会不断打破已有的优势，也就给了新公司更多机会。不像一些壁垒已经建立好的行业，新人很难撼动老大地位。AI Coding 这个方向，恰好是那种「你能解决问题、就能获得用户」的地方。
第三，其实所谓的资源优势，在这个方向里作用挺有限的。你说资金、人力，大公司当然有，但他们投入到这个业务上的资源并没有我们想象中那么多。像一些大公司，相关项目也就几十上百号人。再多了，协作成本反而上来了。而反过来，像 Cursor 这种公司，早期也就三十人，市值却已经很可观了。所以在这个领域，人多钱多，不一定真的是优势。
整体看下来，这里问题多、变化快、用户要求高，又没有资源碾压，我们自己其实也没什么可怕的，反而觉得这是一场很有机会的比赛。
02
Coding 之于 SWE，
就像垒砖之于建筑设计
Founder Park：AI 对 SWE 的影响，长期来看会分成几个阶段？Cursor 也服务专业程序员，它在其中扮演怎样的角色？
陈志杰：现在大家常拿 Cursor 做对比，Cursor 目前还是在「以人为中心」的 IDE 下的产品形态，也主要是在 coding 环节。
从未来视角看，AI 或 Agent 有可能成为整个研发流程的 Controller 和 Planner，统筹写代码、查 bug、code review、测试、持续集成部署等各个环节。因此 AI SWE 的一阶影响在于，它能以控制器和规划器的角色渗透到软件研发生命周期的每个阶段 —— 目前已有一些迹象，比如让 Agent 修复 bug 或合并代码请求，未来必然会在更多环节实现提效。当然不会有一个大招一次性到达那个状态，一方面是模型能力还不够，另一方面传统 workflow 还需要时间改造，可能会逐渐渗透到各个环节，终态会是 Agent 作为 planner+controller，更自主的完成任务。
二阶影响则体现在 AI-native 的软硬件基础设施的变革上。为适配 AI Agent 的运行，整个 Agent 依赖的 Infra 都会变化。目前已出现面向 Agent 生成后端服务的 Superbase、解决多 Agent 通信的 MCP 协议，以及提供运行沙盒隔离的 E2B 等工具。这意味着我们与 Cursor 等产品并不是直接竞争关系，而是在 SWE 领域中解决不同维度、不同场景的问题，整个行业仍处于非常早期的探索阶段。
另外值得注意的是，Cursor、Copilot 等产品目前仍依托 VS Code 这种传统 IDE 形态发展，但当 Agent 具备持续自主运行数小时的能力时，这种产品形态未必是最优解。未来更可能出现的工作模式是：通过统一的工作控制台调度多个 Agent—— 它们可能分别负责编写代码、执行工作流或修复漏洞，而开发者只需完成任务委托和结果校验。这种基于多 Agent 协同的工作范式，显然会突破现有 IDE 的产品框架。
Founder Park：AI IDE 形态只是暂时的解决方案。OpenAI Codex 的负责人也提到，他们很在意 Agent 的运行时间，还提到正确用法是同时跑 20 个任务再去验收结果。长远看，用户与代码的交互会有更多变化，产品形态也会逐步演进。
陈志杰：对，所以总而言之，我觉得当前态势是这样：
第一，软件工程（SWE）是一个更大的市场，coding 只是其中一环，大家可以在里面解决不同的问题。
第二，Cursor、windsurf 现在的产品形态，也不是一个黄金标杆，因为现在的 IDE 是为人设计的，不是为 agent 设计的。
李一豪：SWE 的未来是在不同的抽象层级解决问题。Cursor 现在也很重要，但它就是在 coding 这个 level 不断提高智能水平。但是一个工程的完成是高度复杂的，涉及到调度、沟通、安排，是更复杂的问题。未来的产品可能是在一个更 high level 的层面，去统筹、调度所有现有的工具，是一个更整体的系统性工程。
陈志杰：对，刚才咱们讨论的其实是一个更长远的愿景。具体演化到那个阶段也是一步一步来的。总之我觉得，我们的方向会更聚焦在：怎么样让更大粒度的任务，尽可能自动化地完成，并且结果是可信赖，agent 运行过程是安全。
Founder Park：和过去的 SWE 相比，AI 进来以后，它能够在哪些方面提效或解决问题？
陈志杰：从一些论文中能看到 Google 和 Facebook 都有相关研究。像 Google 曾进行系统升级，涉及 Protocol Buffer 的某个字段升级，而相关代码可能达百万行以上，以前靠人工逐个确认、测试，要花费很长时间，甚至好几年，大部分工程师都觉得这是脏活累活，后来他们结合自身工作流程，让模型进行修改，晚上运行一整晚，白天人再去检查、验收、合并，通过这种方式大大提高了效率。
再如 Facebook 也有类似的工作，用 AI 来提高单元测试的覆盖率，使整个系统的可测性大幅提升。此外，美国红杉前两天采访 Codex 的案例中提到，他们在发布会前要修复一个 bug，查了很久，最后是 Agent 把 bug 修复了。这里有个很有意思的点，就是工程师真正写代码的时间其实不多，大量时间都花在这些脏活累活、事务性工作上，而这些都是 AI 可以逐步帮助提升的。
刘晓春：如果从一个普通人的角度来看，我觉得 AI Coding 和 AI SWE 的关系，其实有点像盖房子时「垒砖」和「盖大楼」的区别。
很多人觉得开发软件就是写代码，就像觉得盖楼就是一块块把砖垒上去。但你想想，像东方明珠、SOHO 大厦这样的建筑，它的核心难道只是砖垒得整齐吗？肯定不是啊。这里面包括结构设计、材料选型、力学计算、施工流程，每一步都需要很强的专业能力和系统配合。
软件开发也是一样。写代码只是最基础的一步，像是在「垒砖」。但如果真的要把一个完整的系统建出来，还要考虑技术选型跟业务匹配不匹配，不同的技术栈怎么协同，工具平台能不能支持不断迭代，还要做各种取舍和规划，这些才是整个工程里最复杂的部分。
AI SWE 想解决的，其实就是这些系统性的问题 —— 就像盖楼不能只盯着砖块，软件开发也不能只盯着代码行数。它关心的是整个生命周期里的各种环节，从架构设计到持续交付，每一块都要想清楚、打通，这才是真正的难点，也是最有价值的地方。
李一豪：那你们怎么规划未来的产品，去设计这套盖大楼的流程，包括工程图纸、验收细节、debug 等等？这个先后顺序和重要程度是怎么规划的？
刘晓春：首先，我们其实是跳出 AI coding 的范畴去思考的。我们更关注的是，做 AI SWE 的最终目标到底是什么？我们的方向，是希望真正对齐软件工程师和产品经理的任务目标，站在软件工业的视角去看这个问题。不是为了写代码而写，而是希望 AI 能参与到整个任务的达成过程中，帮大家一起把事情真正做成。
第二个角度是，光有目标还不够，要达成这个目标，其实需要非常多的工具、平台和服务配合。那 AI 就不能只会写代码，它要能理解工具、调动工具，甚至知道什么时候该用哪个工具。我们现在做的事，跟传统意义上的 AI coding 最大的区别就在这儿：我们是从「目标出发」，而不是从「代码出发」。
所以简单说就是两点：一方面目标导向，另一方面是具备调动工具和平台的能力。这两者加在一起，才有可能让 AI 真正参与到盖楼的每一个环节里，而不是只会搬砖。
Founder Park：之前跟志杰沟通，提到过《人月神话》（软件工程领域的「圣经」），其中的观点认为，在软件工程流程中，人力增加反而造成了效率的折损。AI SWE 会如何解决这个问题？你们有怎样的思考？
陈志杰：软件开发有两类困难。第一类叫作「固有困难」，它是指软件开发本身固有的复杂性，比如 Complexity，Conformity，Changeability，Invisibility，《人月神话》认为这一类复杂性是软件生产的本质属性，是没法消除的。
另一类困难就是「人为困难」，也就是说这些问题不是软件本质导致的，而是由于当前工具、方法或组织方式不完善造成的。包括：沟通和协作能力的问题，看看大公司有多少会议就知道了；进度估计的困难， 软件开发进度难以准确估算，容易低估所需时间，尤其是后期集成和调试工作量。另外就是特别著名的「人月神话」，布鲁克斯最著名的观点之一：「将一个项目分配给更多的人并不能总是加快进度」，有时还会适得其反，因为增加人手会带来更高的沟通和协调成本。
过去几十年，大量的软件工程进展正是致力于降低这类偶发复杂性。现代 IDE、版本控制系统（如 Git）、测试框架、持续集成工具、容器化部署、甚至 AI 编程助手（如 GitHub Copilot、ChatGPT）等，都是在不断消除偶发困难，使得开发者可以更多地聚焦于本质部分。
我们举一个现实中很常见的例子：100 个工程师持续迭代某一个模块，每周可能都会有几十次代码合入。因为是人类在开发，现实的排期压力（想想业务方 40 米的大刀）等因素下，他们未必会很好的遵循开发规范，长期以往，整个模块的封装被完全破坏掉了，这就是所谓代码屎山的来源，整个系统变得原来越难维护，整个模块开发效率反而下降。
因为现实世界本质就是复杂的，数字世界是现实世界的映射，所以梳理清楚需求，这一步是必不可少的。但如果未来的工作主力由「人」变成 Agent 后，上面讲的「人为困难」应该能大幅缓解了。只要你设定清楚规则，agent 的规范遵循能力未来还是会比人强很多的。另外，agent 之间的「沟通」可能比人之间的沟通要容易点（笑）。
03
Cursor 很成功，
但也有掣肘
李一豪：其实 Cursor 也在做类似的事情，它在写代码维度上，提供快速的 reward 机制，扩充 context，从插件到自己的 IDE，再到理解已有代码库。它也在做自己的 MCP，希望拓展可调度的工具空间。这个思路会不会跟你们类似？
刘晓春：现有产品像 Cursor/Windsurf 其实挺成功的，从终极目标来说我们是一致的 —— 都是希望 AI 能够完成更大粒度的任务，能够自主规划、选对工具，最后把事情完整地做出来。
但现在看，这些产品的成功同时成为了他们的包袱：
第一个问题是，他们当前用户里有不少是传统或半传统的工程师，这类用户习惯了强手动控制，所以 他们 至今还需要花很多精力在编辑器、补全这些底层功能的完善上。
第二是月费制的商业模式其实有点掣肘。现在是月费 20 美元的订阅，但很多用户其实是奔着大模型来的，如果要搭 Claude 4 用，算力一上来，成本就有点顶不住了。
第三是坚守专业工程师的定位很有挑战。它的用户结构里其实也有不少小白用户，希望能像 Lovable 或 Bolt 那样，开箱即用、直接解决问题。所以你看 Cursor 最近上线的 Background Agent，虽然本意是做大任务的自动执行，但放在云端托管后，反而更像是给小白用户用的，对专业工程师未必有吸引力。
所以我觉得既有产品的成功有两面性，一方面有先发优势、有品牌、有用户；但另一方面，这些「已有的包袱」也确实会限制它在大方向上的推进速度。尤其是在追求「大任务自主完成」这个目标上，可能很多产品选择会被牵着走，不那么纯粹了。
陈志杰：我觉得，Cursor 是从 VScode 这种 IDE 模式下演变过来的，它一开始在抢占用户心智方面非常好。但在 agent 化的趋势下可能会受到制约。而我们更多是朝着 「大粒度任务由 agent 自主完成」 的目标迈进，整个产品和技术体系都围绕这一核心展开。
刘晓春：刚才听志杰说完，我也想抛一个可能稍微「激进」一点的观点：我其实觉得，在大粒度任务的自主执行这个方向上，未来的赢家很有可能不是 Cursor/Windsurf。就算不是我们，也很可能不会是它们。
原因其实也挺简单的。他们现在已经有了不少存量用户，而且也积累了相当程度的品牌认知，这些反而成了它往前走的束缚。它很难完全跳出来，去专注攻克这个方向。而恰恰这个方向，本身挑战就很大，需要的专注度也很高，不是说你顺带做一下就能做好的。
所以我们现在是完全围绕这个目标在做事情，从架构到底层机制，都是奔着这个去的。这点我觉得可能是我们相对更有机会的地方。
Founder Park：解决这个问题的企业或产品应该具备怎样的素质或能力？当你们去解决这个事情的时候，优势是什么？
刘晓春：首先我们没有 Cursor 那种存量包袱，这反而是创业公司的一个天然优势。没有那么多历史负担，不需要去迁就原来的产品形态或者用户预期，所以从一开始我们就可以围绕「大任务的自主运行」这个目标去设计产品、打磨算法。
比如刚才志杰提到的几个点：我们希望任务起步阶段能和用户对齐得更清楚；我们希望 agent 能在沙盒环境里更安全地自主执行任务，不需要用户总是点确认。这些都是从目标出发去设计的。我们所有的产品思路和技术路径，其实都是围绕这个方向来展开的，也因此能更聚焦、更彻底。
陈志杰：大公司里即便有经验丰富的高阶人才负责，推进起来也较为困难。事务性工作往往会占据他们一半的时间，加上同时负责多个项目，真正能投入到一个项目上精力实则有限。在创业公司，比如说我，基本上 100% 的时间都是在 focus 在这一件事情上面，而且没有那么多事务性的工作需要处理，我天天琢磨的就是这个事。我觉得这个也是很不一样的。
刘晓春：另外，从团队角度来看也有挺明显的差异。我们之前问过公司里的同学，大家普遍感觉，自己现在的产出效率大概是大厂时期的两到五倍。
这种变化来自两个方面：一是像志杰说的，杂事少，注意力更集中；二是我们自己就是一家 AI 产品研发公司，会非常主动地用 AI 来提效。只要有提升空间，我们就会去调整基础设施，让大家用得更顺手。
现在公司里每个人其实都在同时使用多款 AI coding 工具，还对接了多个账号，哪个工具体验好、效率高，就随时切换。整个组织的运行模式，本身就是围绕「AI 驱动」来构建的。
Founder Park：用 AI 更高效率地组织和运转，能够去做到原来想象不到的一些事情。
刘晓春：现在很多大厂也在说自己用 AI 提效了，比如提升了 10%、20%。但说实话，我觉得可能很少有人敢说自己提效超过 30%。因为它有各种现实的掣肘——流程复杂、权限繁琐、组织层级多，AI 再强也很难发挥到极致。
但我们这边就不太一样了。我们更像是从零开始去构建一个 AI 原生的组织，这样 AI 的效率空间能被充分释放出来。它不是锦上添花，而是变成了整个运转方式的核心，很多过去觉得「只能靠人做」的事，现在真的可以靠 AI 来解决。
陈志杰：补充一点思考。过去所有的软件设计原则，其实都是为「人」作为开发者来设计的，为了解决人为的复杂性。比如说，为什么要有函数？为什么要有面向对象？为什么编程语言从汇编一直发展到现在的高级语言？其实都是为了人作为工程师更好的理解和维护代码而设计的，是为了减少人的认知负担。
那你想，以 agent 为中心的开发模式下面，会变成什么样子呢？软件工程的的原则会变成什么？现在这些软件工程原则是不是还会不会存在？当这些第一性原则都发生改变的时候，整个领域一定会发生天翻地覆的变化。
04
优秀的工程师，
未来能带 100 个 Agent 干活
Founder Park：有观点认为，针对软件工程，AI 其实并不擅长精确计算的问题，反而非常擅长「模糊」计算的问题，所以理论上它在做架构设计时，应该会比人类更强。你们认同这个观点吗？
陈志杰：我理解很多人说的 「架构」 其实指日常业务开发，比如写前端或后端代码，而领域术语中的 「架构设计」 门槛其实很高。
其实我觉得应该是反过来，我们可以类比自动驾驶，把 AI SWE 的能力分成几级。
-
L0：完全没有辅助，控制主体是人，所有工作都是人完成，这是传统的软件开发模式。
-
L1：控制主体还是人，但是 AI 可以进行一些补全，比如说 Tab 补全、脚手架代码或一个函数的生成等等。这是 Copilot 最开始的形态。
-
L2：局部任务的自动化。工程师负责描述需求、设计方案、交互决策，AI 可以完成多个任务，比如自动生成测试用例、接口设计、fix bug 等等。我觉得现在整个 AI SWE 或者 AI coding 大概属于 L2 这个阶段。
-
L3：整个模块级别的自动化。这个时候 AI 承担整个模块的开发和维护，相当于达到一个初级程序员的水平。人类的角色会变成一个软件的系统设计师。
-
L4：能够达到系统级别实施的水平，也就是高阶程序员的水平。它能够进行技术设计，比如说你的数据库应该怎么选？你的负载均衡、存储应该怎么设计等等。我觉得到 L4 这个阶段，才是能够做架构，但它仍然是不能替代创造性的工作。比如说，我前两天和一个 Infra 的朋友聊，他说，你让 AI 写一个 TensorFlow 的算子，它是可以写出来的，但是你说让它设计一套 TensorFlow 这种架构，我觉得是绝对不可能做出来的，现在这个阶段还差太远。
-
L5：SWE AGI 真正实现。Result-As-a-Service，人类提需求，AI 负责实现。
刘晓春：你看现在一些评测，比如 SWE-bench 上面，其实在涉及架构选型的任务里，AI 的准确率反而比写代码还高。这说明它在一些高层次的判断上，其实是有潜力的。
AI 今天之所以还难以真正做「架构」，一方面是它缺少我们人类架构师脑子里的那些「隐性经验」——不是那种写在教材里的通用知识，而是对具体业务、具体场景长期积累下来的判断力。如果哪天能把这些知识系统性地接入进去，我觉得 AI 未必不能比人做得更好。
陈志杰：如果只是泛泛给出基础建议，比如负载均衡方式，AI 没问题。
但真正的 L4 架构能力是指设计并实施整套 Infra：线上系统拓扑结构、前后端的实现、模块设计、接口定义、依赖关系、corner case 处理、部署运维方案，甚至多区域全球服务部署等。这需要针对具体业务定制化设计，而非输出通用文档。目前看，这条路还很长。我认为真正的架构师不是只能动嘴的，是能够动嘴并且能实施的。当然，L4 毕竟是远期目标，大家只是「开脑洞」探讨。
这里需要补充的是，这个类比只是为了形象说明，AI SWE 与无人驾驶有本质区别：无人驾驶领域 L2/L3 技术因为是涉及生命安全的，要是效果不好，可能造成严重后果，实际帮助有限；但 AI SWE 每个发展阶段都能交付成果，即便 AI 执行出错，重启或回滚就能解决。另外，技术路线差异 —— 无人驾驶 L2/L3 与 L4/L5 可能路线不同，但 AI SWE 的技术路线是连贯的，前期能力是后期发展的基础，每个阶段都能交付提效成果，让工程师聚焦创造性工作，脏活累活由机器承担。
李一豪：在一级一级升级到 L4 的过程中，现实社会中这个过程可能会怎么样发生？是不断有一些中低端的程序员慢慢被替代，更优秀的人可以做更有创造力的架构层面的思考？
陈志杰：我个人认为，在未来相当长的一段时间里，AI 其实都离不开人的结果验收、需求澄清和中间问题干预。随着技术发展，机器会逐步承担更多脏活累活，让工程师得以聚焦更具创造性的工作 —— 毕竟工程师群体本就善于通过工具创新解决问题，而 AI 本质上也在发挥类似的辅助作用。
AI 在企业中的落地也不是自上而下的强制推行，要是工程师不愿意用，就算是硬性部署也没用。因此核心在于提供优质的产品体验，让用户在实际使用中感受到效率提升，进而推动团队从下到上形成共识，最终通过采购实现全公司的效率优化。
长远来看，或许 10 年后 AGI 真的能实现，那个时候 AI Agent 可能包揽开发、部署、运维等全流程工作。到那时，工作模式可能演变为 「需求沟通者 + AI 执行者」 的组合 —— 专人负责梳理复杂的现实业务需求，agent 按需求输出最终成果，形成 「Result as a Service」 的形态，这种情况下对工程师的人力需求可能会大幅减少。
刘晓春：我补充一点，其实未来角色的分工可能会越来越清晰，人更多是负责设定目标和验收结果。
这里面之所以还是需要工程师来做这件事，而不是产品经理，是因为很多目标本身就带有很强的技术性。比如你要评估系统容量、并发用户数、带宽消耗等等，这些都不是拍脑袋能决定的，它们背后都需要有扎实的技术判断。所以哪怕是「设定目标」，也不是一句话那么简单，是需要理解整个系统边界的工程判断。
这其实挺像现代流水线的逻辑 —— 工人只需要在机器上设定要生产什么零件，机器就能自动把它做出来，人只要监控过程、最后验收产品就行。未来 AI 在软件工程里的角色，可能也会是类似的。
但这里还有个很现实的问题，就是「兜底」。现在很多 AI 已经可以把事情做到 90%、甚至 95%，但那最后 5% 通常才是最难搞的。如果这个尾巴太难，初级工程师可能兜不住，那就必须得是更资深的工程师来兜底。
这就产生了一个有趣的现象：看上去 AI 替代的是「人」，但真正被替代得最快的，可能是那些纯做底层实现、不参与技术决策的初级工程师。相反，AI 对高阶工程师来说，反而是一个「倍增器」，让他们效率更高、覆盖面更广。
陈志杰：对，中短期里面可以想象成一个工程师带 5 个或 10 个 Agent 去干活。对我们工程师来讲，我更愿意干有创造力的工作，我不喜欢修 bug，写文档，我喜欢去设计系统，喜欢做有挑战的事情。当你带 5 个、10 个 agent 干活的时候，可以把那些工作交给 agent，你更专注于让自己获得技术成长、做更有挑战性和创造力的工作。这对工程师个人和对整个公司都是非常有价值的。
刘晓春：以前有些工程师会觉得「我带了多少人」是一种成就感。将来可能不是这样了，真正厉害的工程师，不是带了多少人，而是能带 100 个 agent 去并行干活。
因为你能协调的 agent 越多、组织效率越高，你的生产力就越强。这才是未来工程师真正「牛 X」的方式。
陈志杰：衡量一个最优秀的工程师，永远不是说 ta 敲了多少代码，而是 ta 解决问题的能力，这个才是工程师的核心。
李一豪：我们观察到新一代的创始人，对技术的理解很深，使得产品解题思路跟过去的互联网很不一样。大家都在关注针对模型、模型之间的串联调度、有效的 context、reward 等等。你们在探索过程中有相似的感受吗？
陈志杰：我天然感觉，落地一个产品是个系统工程，不是靠一个单一模型或产品外壳所能支撑。比如说 Google，它是一个产品，但它后面其实有非常复杂的一套系统，包括众多模型和算法策略。广告或推荐系统看似只输出几条结果，实际上是上百个模型、策略与数据交织的产物。
所以我觉得我们做这件事情也是一样的，可能每个维度上都需要去做到极致。
-
产品上，我们需要去了解用户的真实需求痛点和 workflow，设计出很好的产品体验。
-
Infra 方面，为了让 agent 运行得好，要提供很多外围的基础设施，比如很好的沙盒隔离系统、服务发现机制、工具调用。
-
算法方面，用户行为数据的反馈是非常有帮助的。那么算法上，未来的一个发展方向应该也是更端到端的 agent learning，也就是说用户的反馈数据会进入到训练模型里面。当然，这里的模型可能不单纯只有一个大模型，还有很多外围的其他模型。
总而言之，它是一个系统工程。
05
开会少了，干活多了，
特别爽
Founder Park：两位都在大厂做了很多年，为什么决定出来创业呢？
陈志杰：我从学校开始做自然语言处理， 2010 年毕业后加入百度凤巢从事广告算法工作。2019 年之后出去到另一家公司待了一年半，然后去了字节，开始做推荐算法。
刘晓春：我 2011 年加入百度凤巢，和志杰是一路打拼过来的「老同事」。我自己差不多有 14 年的互联网经验，除了中间有两年出来创业，大多数时间都在百度工作。
创业原因挺简单的：
一方面是心里那股劲儿没消——看到很多凤巢的同事朋友都陆续出来创业了，自己也难免会想，不试试看，可能以后会后悔。
另一方面是从行业本身出发吧，我们长期都在 AI 领域工作，上一次移动互联网浪潮其实就有创业的想法，我自己也确实尝试过，但不算太成功。这一次 AI 的发展机会又摆在眼前，我们俩人想了想，如果现在都不行动，那还等什么时候呢？所以决定还是全身心投入，认真试一次。
Founder Park：我其实还挺好奇一点，去实现这样一个比较长期的愿景，到那一天，言创万物会是一个很庞大的组织吗？还是说，像你刚提到 Cursor，也就 30 多人就能做出很不错的成绩。
陈志杰：不会很庞大。我们现在团队也就 30 来人，我觉得今年不会超过 40 人。你看那些 foundation model 的团队，他们的核心团队其实人也都很少，也就几十人这样的规模。
刘晓春：多其实不是我们的目标。对我们来说，更重要的是把事情做成，而且是在成本可控、风险可控的前提下做成。组织庞大不一定代表效率或者成果，关键还是看能不能把复杂的事情做扎实、做漂亮。
Founder Park：你们接下来的产品节奏是怎样的？
陈志杰：我们正在优化第一版产品，可以期待下。大家老是调侃说做应用是「套壳」，但其实 AI SWE 真的是一个非常非常复杂的业务。举个例子，光我们开发那个 MVP 版本，现在前端后端代码就已经差不多 10 万多行了。
Founder Park：哪怕 MVP 都是一个非常复杂的产品。
陈志杰：是，你要考虑很多很多的边界条件和各种情况下的处理，挺复杂的。
Founder Park：创业半年来感受如何？
陈志杰：我感觉挺爽的。我比较喜欢自由。之前不了解的时候会觉得创业很焦虑，包括我创业之前也会对未来会很焦虑。但是，至少到目前为止的话挺爽的，我没怎么焦虑过。
Founder Park：现在的团队日常工作风格，跟之前你们在大厂会有什么区别？
陈志杰：我最大的感受就是会特别少，特别爽。之前的话可能一天至少一半的时间要开会。我是一个特别内向的人，照相都是往边上站那种。现在会少了很多，效率也高了很多。我们团队绝大部分人一天不会超过两个会议，效率自然而然就高非常多。
刘晓春：你觉得你得到你想要的自由了吗？
陈志杰：得到了，哈哈哈，我不想开会。
现在团队确实是一个特别精干的团队，绝大部分人也都是工程师。我们 30 人多人，除了两个产品经理、一个 UG 和两个职能的同学，剩下都是工程师。
刘晓春：我们现在这个团队，虽然规模不大，但整体的能力和配合度都挺让我安心的。每个人都很专注，也都愿意深挖问题、解决问题，这种氛围对一个创业团队来说其实挺难得的。
有些人可能觉得创业公司招人会比较困难，但我们确实还挺幸运的，团队里很多同事之前都有很扎实的实战经验，也愿意放下已有的稳定状态，来做这样一件挑战性比较高的事。我觉得这本身就已经非常宝贵了。
像志杰，能从原本资源很好的环境里走出来，一起来创业，我心里其实特别佩服。他不是为了所谓「更好」的 title，而是真的相信这个方向值得做。我们能走在一起，更多是因为对事情的判断一致。我也更相信，只要我们认真、一点点往前推进，它一定是能做出真正价值的。
陈志杰：这个就……我就是一个普通工程师，低调做人，我就是很喜欢技术。
（文：Founder Park）