正文
下半年，我们在 Aone Copilot 上半年推出了 Extensions 这种业务定制 Agent 的能力，希望能让垂直业务将各自的业务沉淀到 Aone Copilot 的插件里来，让更多的人复用，这些场景包括 RAG 搜索，还有一些业务版本升级的，还有一些是直接生成垂直业务代码的，这里面有一个团队与我们共建详情页的业务逻辑，比如体育和健康的，在详情页中的展现模式是不一样的，都需要业务去代码定制。这种定制长期以来只能依赖负责这个详情页的框架的同学来做，因为只有负责框架的同学知道每个位置应该如何定制，借助 Aone Copilot 的 Extensions 我们有希望把这种专家经验和业务知识等有机的结合起来定定制这些场景的实现逻辑。
但我们和业务团队都付出了几个月巨大的努力后发现，即使是这种非常垂直的场景也很难完全自动化的实现，用户几乎用不起来，通过 Extensions 生成的代码离用户想要的总是
差一点点距离，最多的价值是给用户产出了一个可用的 Demo，后续还需要用户去本地调整，
这里摘录了一些用户原声（含问题和反馈）：
-
诉求时想定制问大家组件内容，但是返回 PlaceHolder.empty() 和 null，代码里面没有展示具体组件内容怎么定制，可以反馈那种有真正定制问大家内容的 demo(如健康问大家的定制)。
-
有具体的实现定制，但是每个字段的作用不是很清楚，以及前台表达是怎样也不清楚。
-
最好先能个统一语言的输入，以及详情域的背景等知识信息，对比较不熟悉的同学可以更好入门。比如预置问题叫 sku 面板，业务输入可能是 sku 浮层、sku 弹层等等，会比较影响知识召回的准确率。
-
当不知道选择什么扩展点时，可能不知道怎么问起，比如每次都需要 @detail 选择对应的扩展点信息再进行询问，但是可能并不知道需要什么扩展点。并且如果初次开发详情，对于扩展点的描述也是不能理解的，希望能有更多的背景描述，或者提问的方式能帮助选择扩展点。
-
扩展点国际侧其实并没有定制过，作为开发可能也希望能希望 copilot 输出当前技术链路 (方案) 等信息，以及如果存在主站白名单、suagr 等控制，还是比较会依赖接口人。
反思下来，我们认为这里不全是模型能力问题，也不是全是工程实现问题。
-
业务上下文不足：企图让用户把需求讲清楚太难了：用户的输入要么过于简单，要么过于复杂，要么词不达意。但仔细思考这也很正常，即使是 PD 和开发之间对需求也需要反复对焦才能把需求讲清楚，即使是真人之间交流都有可能错误理解需求，何况是和程序呢，所以没有任何互动的过程是不可能把需求讲清楚的。
-
技术和领域上下文不匹配：功能逻辑虽然垂直和简单，但业务背景却比较复杂，还有很多暗语，例如“腰带”，“背书” 这种独属于这个场景的业务知识并不是提需求的人能理解的，用户不理解这种领域模型，提的业务需求和代码工程上下文关联不起来，准确率也就大打折扣了。
-
在详情页漫长的发展历程中，面对各种不同的情境，已经积累了丰富的实现、架构和设计经验。然而，无法详尽地记录下这些知识点，使得过往的经验与智慧难以被有效地传承和利用，导致用户的需求没有任何经验可借鉴，模型也没有任何知识可以参考。
对需求的理解和描述不足是阻碍大模型落地的重要的原因，
目前大模型落地比较好的反而是那种不需要描述需求的场景。
过早的拔高了用户期望而很多场景实际无法落地带来的负面影响
从 GPT3.5 问世以来，乐观派们认为随着 GPT4 甚至接下来 GPT5 的到来模型能力会解决绝大部分问题，低垂的果实被摘完后，开始去探索更复杂更有想象力的的场景，不少厂商开始搭建端到端的需求实现系统，不少团队开始刷榜 SWE-Bench，但这一年下来，大家对这种榜单或者类似的故事越来越失去兴趣，公测的产品依然在公测。
整个行业都在憧憬大模型所带来的宏伟愿景，同时又被由此引发的焦虑所困扰。这种心态导致本应专注于基础设施和数据建设的基础工作未能得到充分重视与落实。另一个严重的问题是，许多部门管理者或企业领导者因这些热门话题而对人工智能寄予过高期望，然而当他们发现各类辅助工具并未如预期般大幅提升工作效率时，便开始对这一技术的未来持怀疑态度，并逐渐失去了对那些可能实现效率提升的应用场景的兴趣，对失败的容忍度也变得越来越低，这给研发智能化发展也蒙上了一层阴影。
没有解决好工程上下文问题，也没有解决好业务上下文问题
大多数开发者工作的环境并不是随手画一个草图生成一个网页这么简单，
而是对老的系统进行维护
，
解决旧有系统的缺陷，基于旧有系统开发新需求
等。
如果把大模型当做一个拥有超高智商的新手，在一个从来没有接触过的项目里开发需求，那么他应该怎么开始？我想他应该会学习工程结构，理解项目目录，代码，配置等知道从哪儿着手；这个工程是如何在本地开发和调试的 ；这个项目是如何发布和线上测试灰度的 ；这个项目如何验收；这个项目是如何一步步演进至今的，避免踩坑等。除了这些工程上下文，有时候还需要理解业务上下文，这个项目是做什么的，有什么业务背景，这次的需求是什么，需求方的验收标准是什么，历史上有没有类似可以参考的逻辑等
没有这些经验，则再聪明的程序员都无法驾驭一个维护中的复杂系统，也不能在一个复杂系统中游刃有余。
而现如今大多数产品都无法做到满足这些条件。
