商汤科技Copilot技术负责人张涛：大模型不能解决一切，AI产品需要领域知识
“程序员的饭碗被AI惦记”，早已不是新鲜事。李彦宏说未来不需要程序员，黄仁勋说未来不要再让孩子学编程！
Coding这个行业会消失？要回答这个问题，AI编程工具的研发者最有发言权。
近日，商汤科技小浣熊出圈，我们在AIGC实战派中邀请到小浣熊背后的主导开发者，商汤科技Copilot应用技术负责人张涛。
“那些仍需要人精心地去跟机器沟通的部分，以前叫Coding、现在叫Coding，以后还是叫Coding！”
从模糊语义的人类语言到精确运行的机器指令，这个Gap会一直需要Coding来弥合。
在张涛看来，我们不妨换另一种角度去思考AI编程的意义。AI让我们不再局限于传统的代码编写，而是致力于让人类能够通过更自然、更直观的方式与机器交流。张涛认为，消灭Coding并非目标，人们真正的愿景是提升编程的效率和直观性，让更多人能够参与到创造未来的行列中来。
“现在的AI，是一种新的交互形式，它能与很多垂域的产品结合起来。”
之前的产品开发，往往会从场景需求出发，然后去收集各种各样的一些软件组件，或者是一些技术实现方案来实现自己原来想定义的产品。
而一旦想要往已经成熟的产品加入AI，或者在产品初期引入AI时，那么即使它不是个AI Native的产品，也需要提前把AI的局限性纳入到考虑里面来。
值得注意的是，引入AI并没有那么简单，或许引入AI的方式并不起眼，它可能是一个一个小小的按钮，或者是融入到一个不可见的整体流程，但这背后都是各种各样的场景和需求。
“你要去照顾大模型来做产品，因为你的核心feature是由大模型提供的。这是AI Native产品带来的一个明显的思路改变。”
然而，让软件编程者去主导一个大模型应用的产品，并不是一个水到渠成的事情。
正如张涛在提到自身角色转变时所说的，只懂大模型远远不够，还有很多，比如产品思维，但最重要的，还是需要具备相应的领域知识和行业认知。
“我们不能过分自信地认为，懂大模型就可以把一切都做了。”
以下为访谈要点：
- AI产品不会消灭程序员，反而会促进程序员这个行业良性的发展。
- 实际上大家现在做这两件事：第一，克服现在大模型的若干个缺点，第二，激发大模型更多的思考能力。
- AI提效工具类的产品，更多是让它能够处理人类慢思考能够解决的事情。
- 爽点就在于，一个事情如果没有什么成就感，但又一定要做，机器可以直接帮我完成。
- 不能过分自信地认为，懂大模型就可以把一切都做了。否则，可能全世界只需要Open AI的那700多人，其他的人都不需要来做软件了。
- 对于正确性有高要求的场景而言，SFT的成本比较高，而且可操作性也是受限的，不如直接外挂一些知识库的方法。
采访内容如下：
一、Coding会一直存在，刷题怪可能会消失
51CTO《AIGC实战派》：最近李彦宏、周鸿祎、黄仁勋都就程序员这个职业是否会消失发表了观点，你对这个问题怎么看？
张涛：程序员还会存在，只是工作方式不一样了。程序员群体是对技术抱有好奇心的，肯定尝试过各种各样的AI辅助编程产品。从体感上看，目前已有的AI编程工具，大都是以Copilot的形式存在，去替代开发者去完成简单枯燥的程式化的工作，加速开发效率。最重要的一点是，它可以让你的Coding思路更加流畅丝滑。
如果说哪部分人会被取代，“背答案”或“刷题怪”可能危险了。从另一个角度看，AI产品不会消灭程序员，反而会促进程序员这个行业良性的发展。
一方面，大家不必再去投入太大精力去考察已有的经典算法或古怪的代码中的奇技淫巧。更多地还是回到编程思想，沟通协作、解决问题的能力上来。另一方面，这也会让开发者更积极的能投入到关键技术的探索里面，同时也能参与进产品的开发体验和设计之中。比如我之前就是个程序员，现在其实有一半的精力在做产品相关事情。所以说，AI时代，会让一个代码实现的劳动者转变成一个思考者的角色。
51CTO《AIGC实战派》：Coding本身这件事会被消灭吗？
张涛：我认为还是消灭不了的。消灭Coding的意义就在于，大家希望通过“人和人”交流的方式去和机器打交道，也就是用自然语言来做编程，但是这两者之间是天然有一个鸿沟。
之所以称之为自然语言，是因为它还是有一些模糊语义和需要澄清的部分。它和严格的形式化语言，比如说像数学公式、代码等，天然有一个gap，即：没有哪一个数学家，他会纯用自然语言去阐述自己的数学发现。
至于说Coding中可以被AI取代的部分，是那些成组织的、有既定任务的部分，那些仍需要人和机器去精心沟通的部分，以前叫Coding，现在叫Coding，以后还是叫Coding。
51CTO《AIGC实战派》：Coding效率变高，是不是企业需要的程序员会变少？
张涛：确实存在这个问题。一部分既定任务或者CRUD，其实这些是AI可以通过人的简单指令，就能做到，甚至可能做的比人更好，而且不知疲惫。程序员这个职业自身的技术或者能力成分可能会发生一些变化。
之前，程序员的傍身之技，更多在于编程，比如对某一个编程语言特别的熟悉，理解一些编程的思想，此外还有一些落地实践经验。后续可能就会转变到留出更多的时间来发掘新算法，更多地思考新的产品特性，比如，思考AI时代之后会给编程领域带来怎样的新的交互方式、产品形态，我就是个例子。
二、让大模型坦承自己做不到
51CTO《AIGC实战派》：AI编程类产品是否已经成熟，有哪些待改进之处？
张涛：如果不考虑现在模型能力的限制，可以说趋于成熟了。现在，比较关键的大模型限制主要有两个。一个是context length（上下文长度），还有一个就是幻觉问题。现在大家都是采用一些工程手段来解决这两类问题。虽然这样不是说彻底解决，但是可以把它解决到一个使用的状态，比如RAG，它本质上精排了一些优质数据和信息去增大里面的信息的密度，去解决这个问题。
另外还有prompt engineering、SFT的方式，让大模型自身来抑制幻觉，让其遇到一些未知的知识的时候，就坦诚的表示“不知道”。这些都是在大语言模型在落地的过程中非常重要的一个配套工程。
但目前还没有达成一个既定的行业标准的成熟状态，大家现在还是在摸索。可能路径上是清晰的，但是实际的技术栈上，还没有形成真正的共识，比如上面提到的这些事情，langchain能不能做，也能做，但是可能用AutoGen更快，更容易。针对不同的场景，大家会采用一些不同的方式。总结来说，实际上大家现在做这两件事：第一，克服现在大模型的若干个缺点，第二，激发大模型更多的思考能力。
三、聊一聊AI编程产品思路
51CTO《AIGC实战派》：在激发大模型能力方面，小浣熊家族有着怎样的产品路径？
张涛：小浣熊家族目前已经完成了两款产品，分别是编程和办公场景。这两个产品从底层逻辑上，其实它是一个继承的关系。AI提效工具类的产品，更多是让它能够处理人类慢思考能够解决的事情。
而慢思考、逻辑推理，这些工作可能不是直接靠这个大模型“next token prediction”就可以做到的。那怎么办？
第一，先给产品一个特定的、最适用于大模型的能力。代码能力是大模型一个非常强大的内在能力，因为大模型本身就跑在计算机里。我们可以将其内化，强化大模型的编程能力。
第二，验证可行后，凭借代码能力可以做更多，去解决之前纯靠大模型解决不了的事情：比如一些数据分析、数据可视化等任务。这就对应为办公小浣熊这个场景。其中，除了强化代码能力之外，还需要结合沙盒的执行反馈，来强化大模型的多轮反思能力。后续该系列产品还计划通过、websearch、知识库、多Agent等方式来激活大模型更多的能力。
AI编程产品形态方面，目前以代码能力为出发点，自然会想到以插件形式集成到开发者经常使用的IDE内，这是一个最自然的形态。剩下的一些编程相关的工作，比如前端，对着一张高保真的图像来实现复刻代码，其实也可以给大模型直接做，这是多模态大模型所擅长的。
51CTO《AIGC实战派》：从用户角度看，AI产品的痛点和爽点在哪里？
张涛：从国内外类Copilot产品的数据来看，开发人员的接受度很高。爽点就在于，一个事情如果没有什么成就感，但又一定要做，机器可以直接帮我完成。
举个例子，开发者在写代码的过程中，有很多任务，思路很简单，且有很多既定方法，但又没有API，却需要花时间去敲。这类工作交给AI，代码写到那里一停，小浣熊就可以直接给出后面十来行的函数。这对于程序员来讲就是一个很大的爽点。
针对开发者平时搜索技术文档方面，Devin是个值得借鉴的方法，可信度不能仅依靠大模型自身的反省能力。更好地一个方式是采用RAG或Web搜索而来的强参考信息，这些信息是有来源标注的，大家可以review。
除了帮你写代码，还有和你对话聊天，解决编程过程中遇到的一些问题，你可以直接针对代码某些技术点进行提问。
四、角色转变：懂大模型远远不够
51CTO《AIGC实战派》：从开发者到AI产品的打造者，有着怎样的变化？
张涛：之前自己主要是程序员的角色，现在主要在做代码产品，所以在产品思维上会有更多的要求。但并不是完全转向了产品角色。
之所以选择代码产品，是因为垂类AI产品是需要具备这个领域的知识和行业认知。
我在这里的角色并不是一个大模型专家，反而更多是一名产品所在行业的从业者——一名程序员。我们不能过分自信地认为，懂大模型就可以把一切都做了。否则，可能全世界只需要Open AI的那700个人，其他的人都不需要来做软件了。
51CTO《AIGC实战派》：跟开发之前非大模型产品相比，流程上有哪些变化？
张涛：之前的产品更多从场景出发，然后来收集一些软件组件，或者是一些技术实现方案来实现自己预先定义的产品。而一旦想要往已经成熟的产品加入AI，或者在产品初期引入AI时，那么即使它不是个AI Native的产品，也需要提前把AI的限制局限性纳入到考虑里面来。
之前大家可能从需求设计来出发，而现在大家可能有一定的考虑，需要去照顾大模型来做，因为如果产品的一些核心feature是大模型提供的，思路就需要转变。
比如代码产品中，我们先有代码场景，然后在大模型放进来的第一时间就要考虑到大模型是如何起作用，如何扬长避短，在准备阶段和一次次打磨过程中，让大模型更好地为编程场景工作。
五、AI产品打磨，需要工程和模型双侧配合
51CTO《AIGC实战派》：打造一款AI产品，有哪些棘手的挑战？
张涛：目前，AI产品的棘手问题挺多。比如，如何让大模型更实用，刚才我们提到的RAG方案其实就需要做很多工作，怎样保证性能效果有提升。虽然说它是“精选数据加入到提示”的方法，但是这里的精选数据也是一个模糊定义，所以他真正对模型的理解到底是加buff还是损失或者噪音，这里都需要大量研究工作。再比如，对于正确性有高要求的场景而言，SFT的成本比较高，而且可操作性也是受限的，不如直接外挂一些知识库的方法。此外，工程和模型的配合的视角上面也要做很多大量实验的工作，流程上目前也不能做到很精确的定义。以上这些都需要工程侧和模型侧一起解决。
