原创 Founder Park 2025-06-17 17:50 北京
写代码只占软件工程师工作的 30%。
超 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 负责实现。
- 产品上，我们需要去了解用户的真实需求痛点和 workflow，设计出很好的产品体验。Infra 方面，为了让 agent 运行得好，要提供很多外围的基础设施，比如很好的沙盒隔离系统、服务发现机制、工具调用。算法方面，用户行为数据的反馈是非常有帮助的。那么算法上，未来的一个发展方向应该也是更端到端的 agent learning，也就是说用户的反馈数据会进入到训练模型里面。当然，这里的模型可能不单纯只有一个大模型，还有很多外围的其他模型。
