对话AIGCode创始人：只有从底层训模型，才能真正释放Coding生产力

Github Copilot、Cursor、MarsCode、通义灵码等，AI 代码生成提升了程序员的生产力，正在加速软件行业的生产效率和供给能力。

但有一家公司想更进一步，不只是 Copilot，而是 Autopilot。他们想彻底改变软件的生产模式，完全释放软件市场的供给能力。

这是 AIGCode 对于软件行业的第一性思考。

这家代码生成领域的创业公司，刚刚推出了他们的第一款产品 AutoCoder，目标用户是「产品经理」人群，无需代码能力，只要有产品需求和创意就可以直接生成软件。

而他们的最终目标，是用个性化 App 服务所有普通人。 「有多少人在使用通用产品，就有多少人有个性化需求。」

要真正实现 Autopilot，就要解决现有大模型在代码生成方面的短板，为此，他们决定从模型架构层面做优化。在 MoE 的基础上演进到 PLE 混合多专家架构，团队结合 PLE 和大模型，使模型相同神经元以更压缩比存储并结构化有序学习人类知识。最终模型表现，在代码方面，AIGCode 7B 锡月大模型可以与 GPT-4o 等主流模型媲美。

AIGCode 目前的算法工程团队 20 人左右。CEO 宿文，连续创业者，华创资本前沿科技组前投资负责人。CTO 陈秋武，曾在微软、腾讯、百度、阿里等互联网公司任职 16 年，担任 AI 方向 Leader 达 11 年，资深算法专家，2018 年在微软期间就参与用 GPT 模型落地项目。

Cursor 获得超 6000 万美元融资、GitHub Copilot 已拥有超过 130 万付费用户，而初创公司 Magic 已经成为估值超 15 亿美元的新独角兽， 这个赛道现在越来越卷，AIGCode 团队为什么选择切入AI 代码赛道，对用户和落地场景有什么新的洞察？

在 GPT-5 迟迟不发，业界纷纷认为 Scaling Law 撞墙的当下， 团队为什么决定要自研模型？第一性思考是什么？

关于这些问题，Founder Park 对 AIGCode 两位核心创始人进行了访谈，以下内容根据访谈编译整理。

点击关注，每天更新深度 AI 行业洞察

01

软件的个性化需求，

处于长期被压抑的状态

宿文 ：关键是要看最终想解决什么问题。

当前市场上最好的 Copilot 产品，主要解决的是存量问题——服务于技术编程人员，为传统的项目交付提效，这确实是有价值的。但我们团队关注的，是深入探讨大型模型能为软件行业带来的巨大变革。

我们瞄准的是最终交付的应用或软件本身，核心目标是解决用户实际面临的问题，代码并非最终结果而是过程。 程序员编写代码，是为了创建出能够解决问题的应用。我们服务的是产品经理、需求方、业务方这些非技术背景的用户群体，他们才是软件服务的最终受益。这些多样的用户群体带来的差异化软件诉求，对打磨大模型的技术也非常有利。

陈秋武 ：软件发展从 Web 1.0 的树形导航，到 Web 2.0 的搜索，再到推荐系统，信息流转效率不断提升，但内容生成仍依赖人工。未来，AI 可以实现内容生成，对软件而言，AI 会自动编程完成软件生成。

Copilot 这类工具服务于技术人员，但市场需求远不止于此。不会编程的业务方和个人 App 需求者，数量级是千万级程序员的好几倍。全球软件生态供给不足，导致个性化需求被压抑。降低软件供给成本，将释放这些需求。Autopilot 正是为此而生，通过 AI 生成代码，降低开发门槛，满足广大非技术用户的软件需求。

FP：这是否预示着软件生态将迎来一种新的模式？程序员是不是就不重要了？

宿文 ：软件生态的两个核心痛点：生产效率低和生产质量参差不齐。

软件市场从过去到现在，一直面临着程序员短缺的问题，懂代码的人才供不应求。海外靠 SaaS 模式推动了软件的爆发，国内 SaaS 的推广并不顺利，我们主要依赖大量的软件公司来承接定制化的软件需求。由于软件供给侧效率和质量的瓶颈问题，最终导致许多 ToB 软件项目烂尾。

换一个角度来看：如果软件的供给效率、质量和最终的生成成本这三个指标都优化到极致， 比如供给效率提升到秒级，生成成本低到像流量那样可以忽略不计，同时保证软件的质量，那么将会激发出大量难以预见的需求。

至于个性化应用是否会抢占通用应用的流量入口，我认为这是未来下半场的事情。在未来的五年里，我们将首先关注技术和产品的实现。只有产品上线后，才能更清晰地看到哪些用户群体，在哪些场景下，需要我们现在甚至还未曾想到的东西。而我们现在所能想到的，仅仅是我们已经见过的冰山一角。

目前有大量的需求没有得到满足，核心原因在于软件开发的成本过高。

FP：供给不足说明需求旺盛，但软件真的存在这么大的需求吗？企业已经有定制化或者 SaaS 的方式去拿到产品了。

陈秋武 ：当前市场上的很多 SaaS 产品或定制化服务并未完全满足企业的多样化需求。在 YouTube 上美国餐厅广告，只能满足基本的订餐、叫餐功能。对于食材采购、垃圾处理、人员雇佣等一系列复杂需求，往往只能额外做定制化。尽管企业已经有途径获取软件产品，但现有的供给无法完全匹配需求，导致了现有服务的不足。因此，对于软件开发者来说，仍然存在着巨大的市场机会和商业价值等待被挖掘。

很多领域的数字化进程，还远远没有完成，因为软件的供给能力和效率仍不足。而大模型能释放这种供给效率，再上一个台阶。最终，几乎所有的服务都有可能被软件化，这是技术发展的必然趋势。

宿文 ：国内也存在，对小微企业的服务大多是外卖系统、点评系统，这些是通用的服务。但比如一个小企业主，提供宠物托管服务，不同宠物每天有怎样不同的需求，这是一个高附加值的产品，但很少有人做，他们有对软件的需求。这类小微企业的场景，比想象中多很多。

FP：C 端呢？大家日常用很多应用，App Store 上有那么多 App，为什么要自己拿 AI 搓个产品出来？

宿文 ： 有多少人在用通用应用，就会有多少人有个性化需求 。通用应用说明用户对应用有需求，而个性化的供给其实现在还没实现，但这是个非常明确的事。

这个过程需要从供给端来解决。就像 iPhone 现在实现的很多功能，在十多年前是很难想象的。随着产品的丰富和功能的增多，用户需求变得越来越细分，最终必将走向个性化。

以微信为例，每天有无数人在讨论如何改进微信，因为每个人对理想中的微信都有自己的想象，但微信无法满足所有人。随着微信生态的建立和小程序的出现，低成本、易制作的供给爆发，每个人常用的小程序都不同，这样，每个人的微信在功能层面上都变得个性化了，虽然这种个性化还不彻底。

很多人平常看到一个 App 的某个功能吸引了自己，就忍不住下载试试。这说明，C 端用户也有大量的需求还未满足。C 端用户也有建站需求，比如小业主需要自己的门店管理应用，或跨境出海做轻应用等，这些需求都是客观存在的。

更专业的场景，如银行的定制需求、工厂管理、仓库管理或整个供应链管理，从 C 端到 B 端，我们现在能看到很多这样的未被完全满足的需求，且都可以利用现阶段的技术来解决。因此，利用 AI 来创建个性化产品，不仅是一个趋势，也是一个切实可行的方案。

02

自己做模型，

优化架构解决 Transformer 短板

陈秋武 ：不做模型解决不了问题。

目前大模型还处于婴儿阶段，在代码领域，验收率大多不超过 40%。有人用几十秒生成了一段代码，代价是花了几个小时调对。现阶段的技术成熟度，不足以支撑它完成商业应用的闭环。要优化这个问题，不可避免地，要做基础模型预训练。

代码领域有十几家公司在探索，但很多已经改了方向。原因是什么？我们把模型训练类比爬山，在爬山的过程中，目标是 600 米，但他们爬到 50 米、70 米就上不去了，因为没做过预训练，光折腾产品是折腾不出来的。

要为用户创造增量价值，对 AI Coding 领域打造端到端的最佳产品效果，必须要把技术模型做好、做扎实。看到问题，定位问题，要知道怎么能做出调整，确保能反映到产品效果提升上。

宿文 ：代码验收率低，这是大家公认的统计数据。目前最好的模型端到端代码生成的采纳率在 30%、35% 的水平。一些大厂会把 OKR 定到 40%，目前国内最好的效果预计会比海外低十个点，在 25% 上下。大家的共识是接近的，预期目标都是 30-40 之间。

FP：现阶段模型存在什么问题？

陈秋武 ：先说底层的，模型架构的局限是一个很重要的原因。

目前的模型是一个 Transformer 架构，前面是一个 Attention，后面是一个 FFN（前馈神经网络）。简单理解就是预测下一个字（准确地说是 token），Attention 的目的是计算前面所有字，对当前预测下一个字的权重贡献。而 FFN 其实只是过一下概率，选出概率最大的一个，比如「花」后面可以组成「花园、花朵、花蕊」，或者「我们的小孩是祖国的花朵」，这时候「花朵」的概率是最大的，因为前面的权重贡献了，它能够修正，把「花朵」排在前面。

但这样基于 Transformer 的模型必然会导致一个问题：在 4K 的预训练窗口，或者更大的预训练窗口内学习时，如果某一类样本变多，那么对于小量的、长尾的、高难度的样本，模型必然学不到。

所以合理的归置，并进行结构化的分工学习，就像大脑的听觉和视觉有分工一样。人类社会也依赖这种分工来实现正常功能运转。如果是混乱的、没有明确分工的学习状态，绝对没办法解决这个问题。

FP：PLE（Progressive Layered Extraction，渐进式分层提取）架构，就是为了专门解决这些问题？

陈秋武 ：是的。当前最好的模型，都没法支撑端到端地完成软件生成。

我们认为软件生成的终局肯定是不需要程序员的，代码生成一半，剩下的由程序员来完成，这必然只是一个中间态。 把终局当成目标去思考，现有的模型能力达不到，那就看模型有什么缺陷，然后去解决 。这里面我们看到，模型的长上下文，还有整个知识学习机制上的问题，比如需要结构化的、更高效的方式把知识学进去，而不是不停地大参数量暴力出奇迹。这意味着在网络结构层面，有很大的创新空间。

人类社会的分工和大脑分功能区域都告知我们一个简单的方法论：分类、归纳并总结是达到结构化、高效的好办法。现在主流架构大家都会用到 MoE，但 MoE 其实是一个很初级，很早期的架构，简单区分了多专家，但只对加速推理性能有改善。而针对多专家跷跷板问题在推荐算法领域是 MMoE、CGC、PLE 这些网络架构。法国 Mistral 选了 1991 年诞生的 MoE 与大模型做融合创新，我们则沿着这个发展链路最新的技术成果 PLE 去做整个大模型融合技术改造，做全新一代的模型。这个方向是我们一年前就确定的，从团队开始的第一天就沿着这个路线在持续研发。

AIGCode 模型网络架构

FP：PLE 的目的，是当用户问一个问题，模型能够准确链接到相关逻辑，并且不错过小样本，准确链接、调用？

陈秋武 ：对，而且这些逻辑的权重是不一样的。其实就像医院里的分诊机制一样，比如你生病了去医院，护士会直接把你分到发热门诊，发热门诊跟其他科室是没关系的。而 PLE 更像是专家会诊，多个专家一起参与，每个专家之间还有协作。

这种机制，和大脑中的信号处理是类似的，因为神经网络本质上就是模拟大脑的。

大脑接收到一个信号，你的视觉、听觉、味觉等各种感知都会被综合到大脑中，汇总起来之后，再下发给运动神经去执行。模型的工作原理也是类似的，不过现在的模型还没有解决大脑分功能区域的问题。所以我们要解决的就是这个问题，让模型像大脑一样，有明确的功能区域划分，而且不能互相干扰。如果你的听觉信号跑到味觉区域，那肯定会出问题。

FP： 这个比喻很形象。其实可以把模型看作一个超级大脑，它分成了不同的功能区。我们给它一个任务时，它知道应该调用哪个功能去处理。而且如果任务复杂，就可能需要多个功能区先后发挥作用，但调用的一定是正确的功能区，流程也要是对的。

陈秋武 ：对，它需要一个决策机制，这个决策机制相当于一个中控。中控会把任务分发给对应的功能模块支持工作。只有这样，才能确保模型的回答是正确的。

FP：那 PLE 和 MoE 的主要区别在哪里？

陈秋武 ：举个简单的例子。比如桌子上放了很多东西，MoE 做的事情就是记录这些东西具体放在哪里，下一次我要找相似的东西时，它会找到最相似的路径，把这个东西取出来。但 MoE 并没有对桌面上的物品进行归纳整理，比如小东西放在一个区域，方块堆叠的、占空间大的物品归置在另一个区域。

当你需要再次查找或者学习时，如果桌子上物品已经归纳整理好了。第一是效率会非常高。第二，避免了不必要的学习。比如小学数学你已经学过了，那再给你更多的语料或者让你重复学习是没有意义的，你学到的东西也不会有新的价值。PLE 在分发机制那层就有了自己的决策机制，会针对当前输入语境，动态调整不同专家的权重。这不仅发生在推理环节，也发生在预训练知识学习，把代码相关知识学到对应的专家中。而不仅仅是个分发逻辑，只知道物品归属于哪里，自己本身是不带逻辑的。

专家间的关系，以及专家在回答当前这个问题的时候占的比重是多大，这两个问题是 MoE 完全没办法解决的。

FP：你们的 PLE 模型有跟主流模型 pk 过吗？

陈秋武 ：我们不挑软柿子，跟 LLama（3.1-405B）、Mixtral（8x22B）、 DeepSeek（V2）、Claude（3.5 Sonnet）、 Qwen（2.5 72B）这些国内外主流模型都做过对比，你可以看到，在参数量相差 10 倍以上的情况下，我们 7B 的小模型在全球公认的七大核心任务上取得了 4 项第一的成绩。在此之前，我们在 HumanEval 代码榜单获得过 92.7% 分数，这个分数应该是全球第一。

（benchmark：粗体为最好，下划线为第二名）

03

最强的预训练模型，

也无法解决的问题

陈秋武 ：是，简单介绍一下我个人的一些经历。2012 年我在做个性化广告，当时是跟原 Google Adwords 团队成员竞争，我们的效果是他们的三倍。取得效果最核心的两个点，一个是 real-time，另一个是 personalization。这两个点是在原有架构基础上，通过网络创新，基于用户短期连续主动行为建模，理解用户实时意图的突破来实现的。

后来，我在微软做美国法学院入学考试（LSAT）的项目，当时这个项目是美国主流社会非常关注的一个 AGI 进展，目标是用机器取代人来回答考试题目，我提出来了一种类似 next-token-prediction 的方法。比如，「天要下雨，所以我打伞」。我把「天要下雨」看作一个粗粒度的 token，「我打伞」作为另一个 token，「所以」作为介词关联。这个方法可用来在英文全量语料里用表因果的介词找出上下文及因果对用概率进行建模。在模型使用时就很简单，输入任意 context 的一段话，去匹配已有 context 中最接近的一段，就能得到相应结果的概率。

这个有点像「next token prediction」把词级别的预测提升到了句子级别，但是它长上下文的依赖关系没法很好地去解决。当时我们和 OpenAI 合作，利用他们的上下文信号，处理句子与句子之间、段落与段落之间、文章与文章之间的语义关系，用这个信号用来修正我们的 next-token-prediction 模型原本只能在句子内部得关系上得到权重的结果，做了一种校正，结果提升了接近 40%。

这个成果是 2017 年 -2018 年期间做的几个实验得出的结论。微软的结果基本赶上了 Google，从这个挑战性问题的巨大效果收益开始，微软内部高层逐步认知到生成式模型的巨大价值，2019 年 7 月就投资了 OpenAI。

这也是我们当时在认知层面知道的一件事： 生成型模型的适用场景是更泛化的 。但所有的预训练技术，在 GPT-3 的论文里就可以明确知道，它的快速适应新任务（quickly adapt new task）的能力是基于预训练数据的。

如果某类样本变多，另一类样本的权重会减少。正常数据的正态分布里面，高难度或者逻辑复杂的样本通常是长尾的、少量的。在这种情况下，如何有效地学习这些复杂样本，或者说建立一种全面高效的学习机制，是我认为当前大模型技术代际需要解决的关键瓶颈，而不是像 Scaling Law 那样不断增加算力和数据样本，OpenAI 拿到的这两种资源是全球最多的，但他们也已经遇到了很大的瓶颈。

FP：大家现在都在说 Scaling Law 撞墙，预训练模型可能无法直接通向终局，你怎么看？

陈秋武 ：最近 Meta 的杨立昆发表了一个观点：他作为技术的决策者， 判断目前 OpenAI 所走的技术路径已经不再 work 。一个原因是样本，特别是高质量样本的生产速度赶不上算力的增长，第二个问题是网络结构本身，它其实无法学到刚才我提到的低频、长尾、高难度的问题。

o1 的推理方式是什么？如果一次回答不对，就通过中间的决策机制逐步缩小决策空间，再多次尝试，比如几百次、几千次甚至一万次。我们在模型评估时可以发现，比如生成代码问题，它有个前置库的依赖，比如 import os，会生成很多很多行。虽然不影响程序实现，但你会看到这是一种很「钝」的方式。虽然业内可能叫这类方法「推理」，但我非常不认可，因为这其实是在路径上完全没有拿到关键性突破的情况下出现的，而且这个贡献在业内过去半年已经有了，包括 Agent 或者 RAG 相关的一些贡献等，在自己的算力池上验证有效，然后再去落地。这些方案我是不太认可的。

大家目前在讨论的问题是：如何建立一个大模型更高效的学习机制。预训练样本里不是没有复杂的逻辑，而是有了这些复杂逻辑后，如何高效合理地学进去。比如预训练样本中有一个类别是论文，论文里有非常复杂的理论逻辑和数学公式。但你看大模型的数学能力、复杂推理能力和细节思考能力一塌糊涂，目前基本上和「玩具」一样。这也说明了一个客观事实——无论是 Claude 3.5 Sonnet v2 还是 OpenAI 的 o1 mini，这些相对来说已经非常强的模型，依然无法解决这些点。这些问题是非常明确的，是客观去使用就能发现的问题。

FP：4o 发布的时候大家就发现，模型可以解决很复杂的物理题，但在比较简单的数值大小时，比如 9.9 和 9.11，却比不出来。

陈秋武 ：对，从这个 case 其实可以看出， 大模型其实还是一个符号系统，并不是一个语义系统。

如果是比较 9.11 和 9.9 的大小，它需要先理解你是在比较数字的大小，而不是其他语义，然后再调用数学的逻辑，相当于另外一个专家，去进行数字比较并给出结论。而给出结论的过程其实就是 reasoning，也就是另外一个专家的工作。这个过程涉及到自然语言的理解、数学处理，以及逻辑推理，保证产出的结果是符合用户预期的。

04

初代产品：

覆盖传统软件交付的工作流

宿文 ：对，我们的产品主要面向「产品经理」。这个「产品经理」是打引号的，不一定是某个公司的正式职位，所有具备明确软件需求的用户都可以是「产品经理」，售前人员和 PM 是其中的典型代表。

FP：对比传统的软件交付工作流，AutoCoder会带来哪些变化？

宿文 ：传统软件交付流程中，甲方或者需求方先提出一个想法：「我要做/我想做这个事情」。我们遇到的比较严肃的软件项目，需求通常不是一个人提出来的，而是多个部门的多个人共同提出。接下来，乙方或承接方的销售或售前会去对齐具体需求，再由项目经理或者产品经理对这些需求进行梳理、研究，结合现有平台和各类规范要求，最终整理成至少上百页的需求文档。之后，项目经理或者产品经理和程序员对接，讲解这些需求该怎么做。程序员在接到需求后，往往需要与产品经理进行多次沟通磨合，可能这个过程比较痛苦，最终完成软件并测试交付。

从客户—>销售/售前—>产品经理—>程序员—>交付，整个链条的转化过程非常长，基本上以数月为单位计算时间成本。并且我们会发现，交付的软件与原始的客户需求相比，至少一半的需求都没有满足，或者客户看到实际的软件之后才明确了自己的真实需求，又重新调整需求，然后大家再修改需求、增加、删减、调整产品……整个交付的链条巨长，带来软件行业大量的应收烂尾账款。

AutoCoder 可以把上述问题几乎全部覆盖掉。

通过使用 AutoCoder，乙方的销售人员可以把甲方现场提的需求用几分钟的时间转化成动态、可演示的软件原型，甚至可以做到现场确认需求，这将大大提高成单转化率。即使这个甲方根本没有预算，乙方浪费的成本也仅仅是生成一次产品 Demo 的费用，几乎可以忽略不计。而在传统软件行业中，碰到可能的大客户或标杆客户时，即使成单概率很低，一般也要投入大量资源做 POC（概念验证）和 Demo，这部分成本经年累月将成为企业的巨大负担。

FP：可以理解为：现阶段的产品目标是先在软件生产流程中把需求拉齐？

宿文 ：可以这么理解吧。但是需求拉齐只是第一步，我们最终目标是把软件做出来，只要需求拉齐，我们就可以去推动解决问题，结果自然而然就出现了。

有了原型之后，如何去完成工业级的交付生成工作，是我们下个阶段去做的。这在我们内部也是一个自洽的研发路线：我们先做偏信息沟通、需求拉通层的产品，然后第二个阶段去把需求彻底实现。

FP：生成初版后，如果客户发现不是他们想要的东西，可以当场进行修正吗？

陈秋武 ：如果客户有新的需求，可以现场调整，也可以后面再修正。因为我们的产品理解的是业务语言和自然语言，不需要再转换成功能逻辑。

AutoCoder 的核心优势在于，它可以实现增量修改。我们所谓的增量修改并不是简单的修改个页面文字和风格，而是指功能、字段等程序产品上的修改。在业内，尤其国外，不少公司吹了很多牛，融了不少钱。可是你去试用的话，就会发现，它们的产品生成一个雏形后，要做增量修改是做不到的。

这种增量修改的技术方案对个性化应用或软件生成是很关键的。我们一直强调的「自动生成」，其实就是以模型推理的成本实现「要什么给什么」，那样就可以彻底提升价值，目前这点无论从产品还是模型上，大家都没达到。

FP：如果用户的产品功能要迭代该怎么做？

宿文 ：跟程序员调代码一个逻辑，用户或者说产品经理这个角色，其实就是提需求、改需求。我们的产品和底层模型，需要支持的是从完全推倒重来，到细颗粒度的调整，都能灵活操作，这是我们想要的用户闭环。

陈秋武 ：有代码能力，直接导出代码就可以。继续在我们的产品内也能完成修改。

从架构设计上，我们把所有用户的功能从粒度上变成了一个行为树，所有的交互行为都可以在树中表达。软件的更新过程，可以理解为在行为树上的某个节点定位出来做增量变更的过程，不会影响到其他已有的东西。

宿文 ：这是软件全生命周期管理的问题。如果生成了一个软件，用了半年，业务有调整要修改，可以对软件/网站的维护、部署、数据等方面做增量的调整，这也是我们产品的一个付费点。

05

端到端：抽象出软件的要素，

教模型理解不同场景的业务

宿文 ：包含，但其实核心不在这里。

整个软件从数据库、后端、前端交互逻辑全部都完成。它其实包含三个环节。

第一个环节是模型的能力，要对模型本身优势跟劣势的地方非常清楚。比如说它了解业务需求，它能够做业务需求到功能逻辑的这个映射，这是所有的模型都被 verify 过，没问题的。虽然说不是百分百，但是我们铺人力就可以把这个效果做出来。

第二个环节是对于已有软件架构的全部重构，包括数据库层面、功能跟业务逻辑的解耦。因为传统程序员做的是，我接到一个需求，我就按照这个需求转译成数据库的字段，写后端逻辑，写前端的交互逻辑，然后运维上线。在这个过程里，他并没有把业务逻辑抽象出来。举个例子，先挂号后就诊这个事情，如果抽象的做法是什么？先 a 后 b，a 是挂号，b 是就诊，这两个逻辑拼装成了先挂号后就诊。先什么后什么，这个逻辑是可以用到其他的业务场景里面，比如说先注册后登录。

第三个环节是实现这个，需要把原来软件的实现架构拆分成两个粒度，并且把配置的控制权下放给上层的需求理解端，然后需求理解端把它拼装成配置写到里面。比如说 a 是参与抽奖，b 是抽奖结果，但是先参与抽奖后查看抽奖结果的 workflow 逻辑，在其他的功能模块里面实现过。这个小的功能模块就可以用我们的大模型，去匹配新需求生成一个简单的业务 workflow。

前面是链接的部分，后面是生成部分，中间是配置的流转部分。

简单讲就是三个环节，要往复杂讲，单是我们的设计文档就有几十个，复杂度是非常高的。业内有些高阶的 T 序列的程序员，他只是管理职能变大，但他并没有真正做过复杂创新架构。必须要具备丰富的架构专家人才，才能够驾驭这种思路。

FP：端到端的核心难点在哪里？

陈秋武 ：核心有两个瓶颈。

第一个是模型能力 。现有的大模型还处于婴儿期，你不能期望一个婴儿跑马拉松和弹钢琴，都不现实。但是模型能做什么？它可以理解人话，然后说人话，这没问题。它的行文逻辑和自然语言逻辑是很通顺的。所以在我们 AutoCoder 这个产品的设计之初，就把大模型的能力边界定义为： 把它对业务逻辑的理解转化为程序逻辑中的功能逻辑。

功能逻辑这块，会涉及到大家用软件时经常遇到的场景，一个功能在另一个地方出现，比如搜索功能，它可以用来搜索宠物、文档，或者商品。这么多业务背后的功能逻辑是有限的，比如设计数据库、设计后端逻辑、实现前端逻辑。所以我们把功能逻辑和业务逻辑解耦开，让大模型只做业务逻辑到功能逻辑的翻译和匹配工作。

第二个是软件架构 。现有软件生态的架构，简单说是多个 URL 资源定位，并通过后端逻辑组织起来的数据库某个时刻生命周期状态。但在大模型或深层模型架构的时代，不需要这么复杂的数据库结构。如果你把预训练模型生成的语义嵌入数据库，它能自然会形成语义关联，能够「理解」。

比如，它能理解「应收人」和「收款人」在银行业务中对应的「汇款对象」这个实体。在传统软件架构中，因为数据库存的是标签（label），没法关联。

在做银行软件项目的时候，40% 的人力，可能几百人，都在对字段，然后才能连接起来。但如果是基于语义的关联，其实在线上运行一周左右，模型的样本就足够把「应收人」和「收款人」这样的字段映射到「汇款对象」里面。这个过程完全不需要手工操作，从业务语义到功能语义的链接过程，可以完全自动化。相当于提供了一种翻译。

人的需求也很相似。现在的软件生态，各种界面看起来都差不多，在功能语义的层面，这些逻辑可以被抽象到原子级的程度。 我们从底层架构、数据库、后端架构和前端架构分别解构了原来的软件生态，设计出针对大模型理解的深层次业务翻译架构。 这才能把链路完全打通，让业务逻辑组装成多种功能逻辑。

多种功能的组装就像预制菜。比如你去一个自助餐厅，挑选预制菜，把想要的菜品组合起来，就能组装出一顿符合你需求的饭。我们的产品 Demo，以及后续即将内测的功能，就实现了这样的效果。