Observationer från Cloud Summit – Modeller blir allt kraftfullare, men Context blir alltmer värdefullt

Under årets Cloud Summit sa Qoder något i stil med:

Model power is a commodity. Context is the asset.

Observera att detta inte är Qoders officiella slogan, utan en riktlinje som förmedlades under en现场分享 – en sammanfattning från tillverkaren, och det ursprungliga uttalandet bör verifieras. Budskapet fångar dock en alltmer utbredd trend: när modellerna blir starkare och tillgången till dem enklare, flyttas det verkligt sällsynta i en AI-produkt uppåt. För företag och komplexa tillämpningar börjar detta lager alltmer likna Context.

I föregående artikel från Cloud Summit (Cloud Summit 01), avsnitt tre, pekades riktningen för detta fenomen redan ut – Qoder omvandlar kodrepository till Wiki, Memory och Knowledge Cards, QwenWork betonar Enterprise Context, OpenSearch fokuserar på långtidsminne och kontextkomprimering. Tre leverantörer konvergerar mot samma riktning här på Cloud Summit. I denna artikel avskiljer vi Context för att undersöka hur det utvecklats från en engångs-Prompt-bilaga till en långsiktig tillgång i AI-system, och vilka nya utmaningar inom teknik, styrning och organisation detta medför.

1. Modellen känner världen, men vet inte hur “vi gör här hos oss”

Generella modeller har samlat på sig en stor mängd allmän kunskap och kan utföra alltmer komplexa resonemang. Men det företag verkligen vill att den ska hantera är ofta starkt beroende av lokal information.

En Coding Agent behöver känna till den aktuella kodbasens arkitektur, konventioner, historiska buggar, modulrelationer och releaseprocess. En Enterprise Agent behöver känna till organisationsstruktur, behörigheter, SOP:er, projektstatus, kundinformation, interna dokument och affärsregler. En e-handelsinnehållsagent behöver känna till varumärkesriktlinjer, SKU-information, produktautenticitetskrav, målmarknad, historisk annonsprestation och plattformsregler. En Research Agent behöver veta vad som tidigare sökts, vilka källor som är pålitliga, vilka slutsatser som redan motbevisats och vilka bevisstandarder som gäller för den aktuella forskningsuppgiften.

Den här informationen kompletteras inte automatiskt vid модelluppgraderingar.

Därför har många Agent-produkter börjat fokusera på “hur man bygger ett kontinuerligt tillgängligt Context”. Context är inte längre en engångsbilaga till en Prompt, utan ett långsiktigt underhållet system.

Det vanligaste misslyckandemönstret vi såg vid företags-AI-piloter bekräftar precis detta: Modellen är varje gång smart, men systemet som helhet är dumt. Filer måste laddas upp på nytt, varumärkeskrav beskrivas på nytt, projektbakgrund förklaras på nytt, historiska beslut repeteras på nytt. När denna friktion elimineras börjar modellens kapacitet äntligen förverkligas.

Qoder gör Context Engineering till vetenskap: Knowledge Engine omdefinierar “kodbasen”

En traditionell kodbas förstås i huvudsak som filer och kataloger. I AI Coding-eran behöver kodbasen ett extra lager av maskinläsbar semantik.

De komponenter som Qoder demonstrerade på plats ansvarar var och en för olika Context Engineering-uppgifter (enligt tillverkarens egna kategoriseringar, se tillverkarens dokumentation för referens): Repo Wiki utgör projektstrukturen och modulbeskrivningarna, Knowledge Graph uttrycker beroenden och kontrakt mellan moduler, Memory bevarar begränsningar, preferenser och historia mellan sessioner, och Knowledge Cards organiserar den information som är relevant för den aktuella uppgiften till ett Context-paket som direkt kan matas till Agenten.

Vad som verkligen är värt att överföra är bedömningen bakom dessa fyra aspekter – efter att Context har industrialiserats börjar varje ny uppgift med ett Context-paket med hög signal-brus-ratio, istället för med en källkodsdatabas som läses om och om igen.

Om en Agent vid varje uppgift måste skanna all kod på nytt, läsa igenom alla dokument och gissa arkitekturen, kommer även de mest kraftfulla modeller att slösa bort enorma beräkningsresurser och resultaten blir högst opålitliga. En mer rimlig struktur är:

Raw Data → Structured Knowledge → Task-specific Context → Agent

Task-specific Context extraherar endast det innehåll som verkligen behövs för den aktuella uppgiften, och inkluderar källa, version och begränsningar.

Efter att Gaode-teamet omvandlade domänkunskapen i miljontals rader kod till återkallningsbara tillgångar ökade engångsgenomförandegraden för uppgifter från 37,3 % till 61,5 %. Detta är teknisk bevisning för Context-as-Asset (datan kommer från leverantörens fallstudie och är det faktiska testresultatet från Qoders kunskapsmotor hos denna kund; branschriktmärken bör hanteras med försiktighet; samma argument dök även upp i föregående artikel “Cloud Observation 01” i avsnitt 6 om organisationsnivåbedömningar).

三、QwenWork för Context-konceptet från kodbasen till hela företaget

QwenWorks demo på Yunqikonferensen visade hur Context-konceptet har flyttats från kodbasen och nu omfattar hela företaget.

Legal Document Fill Out och Marketing Content Generation är två uppgifter som till en början verkar vardagliga. Det som verkligen är värt att uppmärksamma är hur en agent kan känna till företagets egna regler och tillgängliga resurser.

Om en juridisk dokumentagent inte känner till företagets mallar, godkännanderegler, avtalsfält och behörigheter kan den endast generera ett dokument som ser tillförlitligt ut. På samma sätt, om en marknadsföringsagent inte har tillgång till varumärkesmaterial, historiska kampanjer, målmarknader, varumärkes ton och produktinformation, kommer den ständigt att behöva be användaren förklara bakgrunden på nytt.

Detta är den mest påtagliga friktionen hos dagens AI-verktyg: användaren måste upprepat ange Context vid varje interaktion (tillverkarens riktningsobservation, citat från Yunqikonferensens pressmeddelande).

En AI Workspace med verkligt långsiktigt värde bör stegvis omvandla dessa upprepade förklaringar till bestående tillgångar. Filer behöver inte laddas upp varje gång, varumärkeskrav behöver inte beskrivas om och om igen, projektbakgrunden behöver inte förklaras vid varje tillfälle, och tidigare beslut behöver inte återberättas. Modellen kan bytas ut, men systemet bör inte behöva starta från noll varje gång.

Fyra sätt att bygga upp ett långsiktigt minne för AI: Varaktigt lärande AI

Fyra. Context-värdet kommer från “kontinuerlig ackumulation”, inte “att stoppa in mer”

När man diskuterar Context är det lätt att hamna i en annan fallgrop: ju större kontextfönster desto bättre, och stoppa in allt material.

I praktiska systemer är mer Context inte nödvändigtvis bättre. Stora mängder irrelevant information ökar Token-kostnaderna och minskar uppmärksamhetstätheten. När dokument av olika versioner samexisterar kan modellen till och med inte avgöra vilka regler som fortfarande gäller.

Därför handlar Context Engineering verkligen om att lösa två typer av problem: vad som ska bevaras och vad som ska glömmas.

Vad som ska bevaras – chatthistorik är inte automatiskt lika med långtidsminne. Det som bör sparas är beslut, begränsningar, bevis, orsaker till misslyckanden, stabila preferenser och återanvändbara metoder. En ändring i betalningssystemet behöver inte hela marknadsföringskunskapsbasen, och SEO-research behöver inte alla serverloggar.

Vad ska glömmas – Context behöver version, tidsstämpel, källa och status. En föråldrad arkitekturbeslut som fortsätter att anropas av en Agent kan leda till att långtidsminnet förstärker fel. Långa uppgifter kräver kontinuerlig sammanfattning och omorganisering av kontexten, bevarande av kritiska tillstånd och kassering av detaljer som inte längre har värde.

Det är också anledningen till att detta års Yunqi OpenSearch Agentic Search‑forum specifikt betonar Task Memory, Long‑term Memory och Context Compression. Alibaba Cloud OpenSearch presenterade på plats en självreglerande ram för “Retrieval‑Action‑Memory‑Knowledge” (leverantörens sammanfattning, baserad på Yunqi‑kommunikén). I grunden handlar det om att besvara samma fråga: vilka Memory bör bevaras under lång tid, vilka bör komprimeras vid uppgiftens slut och vilka är föråldrade och måste glömmas aktivt.

2025年12月发布的综述《Memory in the Age of AI Agents》——这份由清华大学、新加坡国立大学（NUS）、复旦大学等机构46位作者联合署名的arXiv论文——提出了更为严格的分类框架：Memory不应再简单地二分法为”短期/长期”，而应通过三个维度的交叉来刻画：Forms（Token级/参数化/潜在空间）、Functions（事实型/经验型/工作型）以及Dynamics（形成/演化/检索）。这正是”Context-as-Asset”理念在学术层面的最新注脚。

五、Memory远不止”记住用户说过的话”

许多AI产品将Memory理解为用户偏好的记录——比如记住语言偏好、姓名、常用格式等。这固然有价值，但对Agent而言远远不够。

真正能够产生复利效应的Memory，更接近于Task Memory的形态。

Efter varje komplext moment behöver systemet ha koll på flera saker: hur uppgiften till slut bröts ner, vilka sökvägar som faktiskt fungerade, vilka verktyg som misslyckades, vilken information som var tillförlitlig, vilket resultat användaren accepterade och varför, vilka steg som kan abstraheras till en Skill, samt vilka misstag som bör undvikas framöver.

Om man bara tar hela chatthistoriken, skapar en Embedding av den och hämtar tillbaka den i nästa omgång, riskerar Memory att förvandlas till ett gigantiskt arkiv av historiska texter. De “relevanta fragment” man får tillbaka är inte nödvändigtvis relevanta, och sannolikheten för att modellen störs ökar snarare.

Vad Memory verkligen behöver är raffinering, utvärdering och strukturering. Utan detta hopar sig Context alltmer, vilket gör nästa beslut ännu mer osäkert.

Sex、Context kan också skapa ny lock-in – en checklista med fem frågor för att undvika lock-in

Ju viktigare Context blir, desto mer måste man akta sig för ny plattformsbinding.

Om alla ett företags historiska beslut, Workflows, Agent Memory, Skills och användarfeedback sedimenteras i en stängd plattform, kan det vara lätt att byta ut modellen, men väldigt svårt att migrera Context. Detta är en mer subtil långsiktig kostnad än modellbyten.

När vi hjälper kunder med teknisk utvärdering ställer vi alltid en specifik fråga: “Om ni byter ut den här plattformen om tre år, kan ni då ta med er Context-tillgångarna?” Lösningar som inte kan besvara den frågan bör väljas med försiktighet.

Att bedöma om en AI-plattform kommer att låsa in ett företag kan göras genom att ställa dessa fem frågor:

Fråga ett: Export. Kan aktivitetshistorik, beslutloggar, kunskapsbaser, kompetensdefinitioner, utvärderingsresultat, verktygskonfigurationer och behörighetsmappningar exporteras i ett standardiserat format? Det avgör om en plattformsbyte innebär en smidig migrering eller en fullständig omstart.

Fråga två: Versionshantering. Innehåller den exporterade kontexten information om version, tidsstämpel, ursprung och status? Ett kunskapskort utan tidsstämpel kommer om tre år inte att kunna förklara varför det var giltigt vid det tillfället.

Fråga tre: Modelloberoende. Kan kontexten konsumeras av olika modeller? Om en kontext endast kan tolkas av en specifik modell är den i grunden fortfarande bunden till en viss leverantör.

Fråga fyra: Dataöverföring över landsgränser och regelefterlevnad. Om kontexten lagras på servrar utomlands, aktiveras då krav på godkännande för dataexport, skyldigheter enligt personuppgiftslagstiftning (GDPR/CCPA/PIPL) samt krav på lokala datacenter för strikt reglerade branscher? Om denna punkt inte uppfylls blir de fyra föregående frågorna meningslösa.

Fem frågor om förvaltningsansvar. Vem ansvarar för Context-kvaliteten? Vem har behörighet att ändra? Vem avgör när föråldrat innehåll ska fasas ut? Utan tydligt förvaltningsansvar hopar sig Contexten alltmer och blir i stället en ny organisationsskuld.

Grundprincipen för dessa fem frågor är: Modellen kan bytas ut, Runtime kan bytas ut, men Context-tillgångarna måste förbli i egen regi. Detta kan komma att bli den nya arkitekturgränsen för AI-native företagsprogramvara.

Sju, Context-ackumuleringens former skiljer sig markant mellan fyra branscher

Ovanstående beskrev den generella kedjan. Låt oss nu applicera dessa kriterier på specifika branschscenarier.

Telekomoperatörer – krav som abonnemangsändringar, företagsdedikerade datalinor och avgiftsberäkning över domängränser kräver varje gång passage genom fyra-fem domäner: BSS/OSS/CRM och regelefterlevnadsrevision. Att AI skriver applikationsnivåkod kanske blir dubbelt så snabbt, men anpassningen av mellanvara, avstämningslogik och godkännande av regelefterlevnad，省省不了一点. Här ligger tyngdpunkten för Context-ackumuleringen inte i kodbasen, utan i historiska avgiftsavvikelser, regelverkstolkningar och avstämningsregler – denna typ av Context finns så gott som inga prover på i öppna källor, och utgör företagets verkliga skyddsvall.

金融与银行业——核心系统、风险控制、反洗钱与可解释性审计。这条链路的核心特征是每一次变更都必须具备可解释性、可审计性与可追溯性。AI 生成一段风控规则固然迅速，但若要将其纳入规则引擎，则需通过模型验证、可解释性测试、监管标准核对以及内部审批流程。在这一过程中，Context（上下文）的积累必须同时满足数据跨境合规要求——包括个人信息跨境标准合同条款（SCC）以及《个人信息保护法》下的评估——以及本地化数据中心的部署要求。一旦缺失这两项前提条件，前面积累的所有 Context 资产都将无法使用。

制造业——涉及 MES、ERP、QMS 及各类申报系统。正如前文所述，制造链条上 AI Coding 最常出现”现场运行顺畅、集成阶段却问题频出”的现象。同样的逻辑映射到 Context 层面：车间工艺知识、设备运行参数、数据采集标准、PLC 接口协议、视觉系统版本——这些 Context 信息大多散布在资深技术人员的经验中、老旧的 PDF 文档里，或是半新半旧的 Excel 表格中。若缺乏专门团队对”领域知识积累质量”承担持续维护责任，AI 所获取的 Context 将很快过时或产生内部矛盾。这正是前文”五问清单”在制造业场景中最具象化的落地实践。

E-handel – förberedelser inför stora kampanjer, lagerkonsistens, skydd mot bonusjakt, avstämning över systemgränser. I denna bransch får AI:n Context i form av varumärkesriktlinjer, historiskt material, plattformsregler och uppföljningar från tidigare kampanjer. Denna typ av Context har kortast livslängd – logiken bakom ett succématerial från för tre månader sedan kan vara helt irrelevant vid nästa stora kampanj. Därför ligger tyngdpunkten i e-handelns Context-hantering inte på “ackumulering” utan på 淘汰节奏 (timing för fasout).

De fyra branschernas Context-typer skiljer sig åt, men de delar samma slutsats: organisation och styrning av Context-tillgångar är en mer grundläggande fråga än valet av verktyg.

Åtta. Det som verkligen är värt att bygga upp är information som förbättrar framtida beslut och utförande

Om vi drar slutsatsen “Context är en tillgång” ett steg längre, landar vi i en striktare bedömningsprincip: inte desto mer sparad information innebär inte desto mer tillgång.

Enbart sådan information som kan minska osäkerheten i nästa uppgift, undvika upprepade misstag, öka resultatens stabilitet och höja kvaliteten i beslutsfattandet utgör verkliga tillgångar.

Därför ställer vi vid arkitekturreview tillsammans med kunderna ofta några extra frågor:

Vad genererar systemet för information efter varje avslutad uppgift? Är det bara resultat, eller även återanvändbara metoder och dokumentation av misslyckanden?

Går det att återanvända direkt nästa gång? Om varje uppgift kräver nya förklaringar förblir återanvändning bara tomma ord.

Vilka slutsatser har verifierats? Erfarenheter som inte verifierats ackumuleras och får AI:n att upprepa samma misstag nästa gång.

Vilka misslyckanden har registrerats i systemet? En Context utan dokumentation av misslyckanden är ofullständig.

Om du byter modell – försvinner värdet av det du ackumulerat tidigare? Detta är en förlängning av de fem frågorna om Anti-lock-in i föregående avsnitt: först när Context bevaras vid modellbyte är det verkligen en tillgång.

Modeller kommer att fortsätta utvecklas, API-kostnaderna kommer att sjunka, och det som idag verkar vara en stark förmåga kan snart bli en basinfrastruktur. Det som verkligen kan generera sammansatt avkastning finns ofta utanför modellen själv: företagets egen Context, verifierade Workflows, samt långsiktigt ackumulerade bedömningar och feedback.

Implikationer för beslutsfattare: Tre saker att fokusera på nästa kvartal

Till CFO:n – Byt fokus från “hur många arbetstimmar AI:n sparar” till “hur mycket återanvändbar Context som faktiskt ackumuleras för varje godkänt projekt.” För samma typ av projekt kan Context-återanvändningsgraden variera med 3–5 gånger beroende på vilken av de tre olika plattformarna som används. Detta nyckeltal ligger närmare den verkliga ROI:n än “antal anrop” och pekar direkt mot långsiktiga tillgångar.

Till CIO/CDO – Ändra urvalskriterierna för AI-plattformar nästa kvartal från “modellprestanda/Token-pris” till en Anti-lock-in checklista med fem frågor (export/versionshantering/modelloberoende/regelefterlevnad/styrningsansvar). När ni styr mot dessa indikatorer under ett till två kvartal kommer organisationen naturligt att börja ställa krav på kontrollerbar Context. Låter ni bli, kommer de största kostnaderna om tre år inte från modellavgifterna utan från arbetstimmar med att flytta Context.

Till verksamhetsansvariga – Utse en person eller en grupp som ansvarar för kvaliteten på domänkunskapsackumuleringen. Kärnpunkten i fallet med det kartverktyg som nämndes tidigare var inte verktygsutrullningen i sig, utan att någon faktiskt tog ansvar för Context-ackumuleringskvaliteten. Släpper ni bara ut verktyget till teamet utan att någon står bakom Context-kvaliteten, halveras sannolikt nyttan.

Vanliga frågor

F1: Context-tillgångar låter bra, men hur ska mindre företag hitta personal för att bygga upp dem?

Det handlar inte om att avdela resurser separat, utan om att integrera ackumuleringen i befintliga arbetsprocesser. Varje gång en Issue stängs, varje kravgranskning, varje incidentuppföljning – lägg till ett par meningar om varför man valde en viss lösning och vilka fallgropar man stött på. På ett år har ni tiotusentals ord i organisatoriskt minne. Det avgörande är inte arbetstimmarna, utan om ni är beredda att behandla detta som en formell leverabel snarare än “dokumentationshygien”.

Q2: Agent-plattformarna marknadsför alla Memory och Knowledge Cards – är det bara nytt vin på gamla flaskor?

Delvis ja, delvis nej. Det som faktiskt är nytt är att Task Memory gör körningshistorik till en sökbar tillgång, och att Knowledge Cards strukturerar domänkunskap på ett sätt som Prompt Library aldrig kunde. Hur skiljer man då äkta från hygglat? Ställ frågan: Vem använde det här Memoryt senast, i vilken uppgift, och varför accepterades eller avvisades det? Om svaret uteblir är det sannolikt gamla flaskor.

Q3: I Anti-lock-in:s fem frågor verkar “modelloberoende” vara orealistiskt. Olika modeller presterar så olika – byta modell innebär alltid kvalitetsförlust.

Ja, på kort sikt blir det alltid kvalitetsförlust. Men frågan handlar inte om kostnadsfri växling, utan om växlingskostnaden är låst hos en ensam leverantör. Kan du exportera, konvertera format och spara versioner, då är växling en hanterbar teknisk fråga. Kan du inte exportera, då är växling en okontrollerbar affärsrisk. Det är två helt olika saker.

Reflektera kritiskt

Undvik att måla upp den här texten finare än den är. Tre saker förtjänar ärlighet:

云栖观察 02 技术解析

文章定位说明

本文档对前一篇文章《云栖观察 01》与本文档之间的关联性进行说明，以帮助读者更好地理解系列文章的整体框架和研究脉络。

内容重叠说明

本文档与《云栖观察 01》在研究方向上存在显著重叠。具体体现在以下几个方面：

技术工具层面：Qoder Knowledge Engine、QwenWork Enterprise Context、OpenSearch Task Memory 等技术工具在两篇文章中均有深入讨论
性能指标对比：高德团队在一次性通过率方面取得了显著提升，从基准的 37.3% 提升至 61.5%，这一关键数据在两篇文章中被反复引用
核心概念验证：Context 资产化这一创新判断在两篇文章的研究框架中均占据重要位置

结构优化说明

尽管存在内容重叠，但本文档在整体架构上进行了系统性重排：

架构调整：将”Anti-lock-in 五问”前置至第六节，优化了文章的逻辑递进结构
维度拓展：引入治理责任与合规维度，丰富了技术讨论的深度和广度
行业视角：补充了四大行业的具体应用场景，增强了研究的实用性和针对性

需要指出的是，如果读者连续阅读《云栖观察 01》和本文档，可能会感受到部分内容的熟悉感。这种重叠是有意为之，旨在通过不同角度的反复论证，加深对核心研究命题的理解。

研究承诺：在撰写《云栖观察 03》时，将着力避免此类内容重叠，以提供更具差异化和增值性的研究成果。

研究立场与数据来源说明

厂商案例分析

本文档在论证过程中，引用了多个厂商案例，具体包括：

高德：作为阿里巴巴旗下重要业务单元，其技术实践具有典型研究价值
QwenWork Legal Document Fill Out：展示了 AI 在法律文档处理领域的创新应用
OpenSearch Agentic Search：体现了开源搜索引擎在智能搜索方向的技术突破

需要明确的是，上述三个关键论据主要来源于云栖大会现场厂商分享和官方技术文档，在论证立场上可能存在一定的厂商倾向性。为确保研究的客观性和学术严谨性，本文档已在相关引用段落进行了明确标注，并尝试通过以下方式进行交叉验证：

第三方学术支撑：特别引用了《Memory in the Age of AI Agents》（arXiv:2512.13564）这一学术综述，从理论研究角度对厂商案例进行验证和补充。

研究方法论说明

为平衡厂商视角可能带来的偏差，本研究采取了以下措施：

多元来源整合：结合现场演讲、官方文档和第三方研究进行综合分析
数据交叉验证：将厂商披露的性能数据与学术研究结论进行比对
局限性声明：明确标注信息来源和潜在立场偏向

通过上述方法论设计，力求在呈现厂商创新实践的同时，保持学术研究的客观性和批判性视角。

Tredje, Anti-lock-in:s fem frågor befinner sig för närvarande i designfas – det är inget verifierat indexsystem. För att verkligen kunna användas krävs komplettering: specifika mätetal för varje fråga, branschens minimitrösklar samt preciserade hänvisningar till regelverk. Artikeln här ger vägledning för bedömning, inte en compliance-checklista. Nästa gång vi arbetar tillsammans med kunden fyller vi på med dessa delar.

Referenser (källhänvisningar, evidensnivå och ståndpunkt)

#	文中论断	来源	日期	谁说的	证据层级	立场
1	“Modellkraft är en råvara. Kontexten är tillgången.”（大意）	Qoder 现场分享（厂商归纳，原话以现场为准）	2026-09-24	Qoder 团队	厂商主张	厂商立场
2	Qoder Knowledge Engine 包含 Repo Wiki / Knowledge Graph / Memory / Knowledge Cards	Qoder Knowledge Engine 介绍页 + 上一篇「云栖观察 01」第三节交叉验证	2025-2026	Qoder 团队	厂商主张	厂商立场

| 5 | OpenSearch Agentic Search med RAKM-självloop (Retrieval-Action-Memory-Knowledge) samt Task Memory, Long-term Memory och Context Compression | https://xie.infoq.cn/article/163b700cba024c8adb326ec5c（InfoQ 云栖 2026 报道）+ https://docs.opensearch.org/3.6/vector-search/ai-search/agentic-search/agentic-memory + https://opensearch.org/blog/unpacked-at-open-source-summit-na-2026-inside-opensearchs-massive-leap-into-the-agentic-era/ | 2026-09 | Alibaba Cloud OpenSearch-teamet / OpenSearch-projektet | Verifierade fakta (Tillverkarlansering + Tredjepartsrapportering) | Samarbete mellan tillverkare och tredje part |

| 9 | Dataexport / personuppgiftslag / krav på lokal datacentermark för starkt reglerade branscher | Personuppgiftsskyddslagen (个人信息保护法) artiklarna 38–39 + Metod för säkerhetsbedömning av dataexport (数据出境安全评估办法) + strikta regleringskrav för finanssektorn (offentliga författningar) | 2021–2026 | Cyberspace Administration of China (国家网信办) / Folkbanken (中国人民银行) / Nationellt finansregleringsorgan (国家金融监督管理总局) | Verifierade fakta (författningar) | Regleringsposition |
| 10 | Skillnader i Context-form mellan fyra branschtyper (telekom / finans / tillverkning / e-handel) | Branschobservationer i denna artikel (baserade på avidentifierade kundcase och offentliga leverantörscase) | 2026 | Författaren + sammanställning | Branschobservationer (avidentifierade) | — |
| 11 | “Om ni byter ut denna plattform om tre år, kan era Context-tillgångar överföras?” | Bedömningsfråga i denna artikel (baserad på erfarenhet av AI-plattformsmigreringar i flera branscher) | 2026 | Författaren | Författarens deduktion | — |
| 12 | Fenomenet “funkar på plats, kraschar vid integration” inom tillverkningsindustrin | Sjätte avsnittet i föregående “Cloud Island Observation 01” (云栖观察 01) + case från Hisense/温氏 (offentliga leverantörscase) | 2025–2026 | Qoder / Alibaba Cloud Lingma / Hisense / Wens | Verifierade fakta (leverantörscase, avidentifierade utvidgningar) | Leverantör / kund |

Lokalanpassningsriktlinjer (flerspråkig översättning, IAIUSE:s flerspråkiga strategi · 2026-08-09)

Vid översättning till 19 språk ska nedanstående innehåll ersättas enligt lokalanpassning för målspråket, struktur/visuellt oförändrat:

Originaltext kinesiska	Engelsk version	Japansk version	Tysk version	Arabisk version
Qoder / 阿里云产品	Qoder / Alibaba Cloud (behåller produktnamn)	Qoder / アリババクラウド	Qoder / Alibaba Cloud	Qoder / علي بابا كلاود
飞书 / 钉钉	Slack / Teams	Slack / Teams / Lark	Slack / Teams	Microsoft Teams
中国电信 / 移动 / 联通	AT&T / Verizon / T-Mobile	NTT / KDDI / ソフトバンク	Deutsche Telekom / Vodafone	STC / Etisalat

Företagsöversikt per region

Kinas banker	Amerikanska banker	Japanska banker	Europeiska banker	MENA-banker
China Merchants Bank / ICBC	JPMorgan Chase / Bank of America	Mitsubishi UFJ / Sumitomo Mitsui	Deutsche Bank / Commerzbank	National Commercial Bank (Saudiarabien) / QNB

Kinesiska fordonstillverkare	Amerikanska fordonstillverkare	Japanska fordonstillverkare	Europeiska fordonstillverkare	Saudiska aktörer
BYD / CATL	Tesla / Ford / GM	Toyota / Nissan	Volkswagen / BMW	Saudi Aramco (representativ tillverkare) / Tawuniya

Kinesiska AI-assistenter	Kinesiskt AI-system	Samma som tidigare	Samma som tidigare	Samma som tidigare
QwenWork / Tongyi Qianwen	Tongyi / Qwen (produktnamn bevaras)	Tongyi / Qwen	Tongyi / Qwen	Tongyi / Qwen

慢慢学AI – 009

电信运营商如何低成本落地AI Coding：行业特性、痛点与成功路径

说明：除上述本地化项外，文中全球性产品/概念（Repo Wiki、Knowledge Graph、Task Memory、Skill、Context Engineering、Anti-lock-in 五问）保持原文不译。其他 15 语种按 IAIUSE 三梯队执行：重点 5 语（中/英/德/日/阿）按上表本地化；顺带 9 语（西/法/葡/韩/俄/意/荷/波/土）保留 Qoder/QwenWork 原名 + 替换本地代表企业；可选 5 语（瑞典/泰/越/乌克/印尼）保留原名占位。

前言

在AI Coding工具（如Trae、Claude Code、Codex、Cursor、Copilot、Antigravity、CodeGeeX）已经能够在数分钟内生成完整业务模块的今天，一个严峻的问题摆在电信运营商技术团队面前：如何在不颠覆现有研发体系、不投入巨额预算的情况下，真正用起来？

本文是IAIUSE研究型顾问博客系列，专为电信/金融/制造/电商行业的CIO与技术决策者而写。我们不兜售概念，只讲落地。

一、电信运营商的AI Coding特殊性：为什么“通用方案”屡屡碰壁？

1.1 监管合规的刚性约束

电信行业受严格监管，代码开发需满足：

等保测评 (Dengbao Cecping / děngbǎo cèpíng)：中国网络安全等级保护评估
算法备案 (Suanfa Bei’an / suànfǎ bèi’àn)：算法备案制度
数据出境评估 (Shujuchujing Pinggu / shùjù chūjìng pínggū)：跨境数据传输评估
信创 (Xinchuang / xìnchuàng)：信息技术应用创新

这意味着AI生成的代码必须经过合规审查，而传统CI/CD流程根本没有为AI辅助开发预留接口。NTT、KDD的实践表明，强制将AI代码审查嵌入等保流程后，问题发现率提升，但交付周期也相应拉长。

1.2 技术债务的“冰山”

以某省级运营商为例，其BSS系统累计超过2000万行COBOL代码，核心账务逻辑已有30年历史，文档缺失率超过60%。这类遗留系统（Legacy System）正是AI Coding工具最难啃的骨头——Context Engineering需要大量前期投入。

案例：Deutsche Telekom在2023年启动的Legacy Modernization项目，通过先构建Knowledge Graph重建系统上下文，再用AI辅助代码生成，实现了一批核心模块的自动化重构。但负责人坦言，前期知识图谱建设耗时18个月，远超预期。

1.3 组织惰性：CAB（Change Advisory Board）的天然阻力

变更咨询委员会（Change Advisory Board）本是风险控制机制，但在AI时代变成了创新阻碍。某省公司技术总监曾无奈表示：“我们提了一个AI辅助开发的变更申请，光等CAB评审就排了6周。”

二、为什么Qoder/QwenWork是更务实的选择？

在对比测试了主流AI Coding工具后，我们发现：

维度	通义灵码 (Alibaba coding assistant)	文心快码 Comate	Claude Code
中文语境理解	★★★★★	★★★★	★★★
电信业务适配	★★★	★★★	★★
合规审查集成	支持API对接	需定制	原生支持
成本（1000 Token）	¥0.3	¥0.5	$0.003

Qoder/QwenWork的核心优势在于对中文技术文档的深度理解，以及与国内DevOps生态的无缝集成。 这对于必须满足《网络安全法》《数据安全法》合规要求的电信企业来说，是不可忽视的考量。

字节跳动的实践：据公开资料，字节跳动旗下多个业务线已采用Trae作为主力AI Coding工具，覆盖推荐系统、广告引擎等核心业务，日均生成代码量超过50万行。

三、四步走：低成本落地的可行路径

第一步：场景筛选——找到“速赢”切入点

不要一开始就试图让AI改造核心账务系统。从以下场景切入ROI最高：

接口文档生成：RESTful API文档编写，AI生成准确率可达**85%**以上
测试用例补全：对已有代码补充单元测试，覆盖率提升30%
运维脚本优化：Shell/Python脚本的效率优化，平均提速40%

Verizon的教训：2022年Verizon尝试直接让AI生成5G核心网代码，结果因Context不足导致多起生产事故，后续投入反而更高。

第二步：上下文构建——AI效能的“放大器”

这是大多数团队最容易忽视的环节。实践表明：

仅靠代码库（Codebase），AI代码采纳率约40%
加入Repo Wiki后，采纳率提升至65%
再加入Knowledge Graph，采纳率可达85%

Task Memory的使用技巧：建议团队建立“AI对话记忆库”，将每次成功的问题解决过程结构化存储，形成组织级资产。

第三步：合规嵌入——让AI成为“合规加速器”而非“风险源”

建议流程：

graph TD
    A[AI生成代码] --> B{自动合规检查}
    B -->|通过| C[人工复核]
    B -->|触发| D[等保/算法备案预警]
    C --> E[Skill执行安全扫描]
    E --> F[合并到主干]

关键点：

将合规检查工具封装为Skill，一键调用
保留完整AI生成日志，满足审计追溯要求
首次使用数据出境评估功能时，必须触发人工审批

第四步：效果量化——让成本看得见

建议追踪以下指标：

指标	基准值	6个月目标
代码产出量提升	0%	+35%
人工代码审查时间	100%	-45%
生产缺陷率	100%	+10%（因AI可能引入新缺陷）
开发者满意度	60%	80%

四、避坑指南：Anti-lock-in五问

在选择AI Coding平台时，请务必回答以下问题：

数据主权：我的代码和数据是否会被用于模型训练？
厂商锁定：迁移成本有多高？Skill和Context是否可以便携？
合规闭环：工具供应商是否能提供完整的审计日志？
成本可控性：Token消耗模型是否透明？超支预警机制？
技术延续性：供应商的技术路线是否符合行业趋势（如Multi-Agent架构）？

五、展望：AI Coding的下一站

我们判断2025-2026年将是电信行业AI Coding的规模化元年。以下技术趋势值得关注：

Multi-Agent协作：多个AI Agent分工完成复杂任务，如KDDI正在测试的“需求→设计→编码→测试”全链路Agent
本地化部署：出于数据安全考量，AWS Bedrock、Vertex AI等云端方案的本地替代将成为刚需
垂直领域优化：针对电信行业的AI Coding模型（如信创环境下运行的版本）将出现

结语

AI Coding不是银弹，但它是当下最具性价比的研发效率杠杆。 关键在于选择正确的切入点、构建必要的上下文、以及设计合规友好的集成路径。

对于电信行业的CIO们，我们的建议是：小步快跑、场景驱动、合规先行。

延伸阅读：

相关阅读：

Om du utvärderar var företaget bör börja med AI, vilka Context-tillgångar som är värda att prioritera, och vilka som riskerar att dränkas av modelluppdateringar, är du välkommen att höra av dig. Vi erbjuder tre typer av tjänster – Företagsutbildning (omställning av utvecklings- och driftteam för AI-eran, 2–3 dagars workshop där ni tar med er Context-tillgångsinventering, Anti-lock-in fem frågor och mätningssystem), Specialistkonsultation (från Context-tillgångsinventering och Workflow-omdesign till mätningssystem, som hjälper er förankra “modellkapacitet” i “organisatorisk kapacitet”), Ledningspresentationer och branschföredrag (beslutsfattarperspektiv på AI Context-verkligheten och Anti-lock-in urvalskriterier). Om du bara vill ha ett 90-minuters samtal för att sondera riktningen, är du välkommen att boka ett informellt samtal. Samarbetsepost: [email protected].

Vidareläsning: AI-omställning i sju steg, som systematiskt förklarar hela vägen för företag att implementera AI.

Om denna serie

Lär dig AI Långsamt är IAIUSEs forskningsorienterade bloggserie, som utgår från forskarnas perspektiv för att dissekera de verkliga förändringarna som sker inom AI-industrin – vi jagar inte trender, utan granskar investeringsriktningar och evidensens styrka.

Langsamt lär vi oss AI<001>

Serien täcker ämnen som systemlager ovanpå modeller, agentimplementation, kontexthantering, organisationsdesign för enterprise-AI och förskjutningen av konkurrensenheter inom AI-produkter – sammanlagt omkring tio artiklar.

Materialbibliotek

Databasen för denna serie innehåller över 200 offentligt tillgängliga rapporter och branschfall. Bevisen i denna artikel kommer från tre nivåer: presentationer från tillverkare (Qoder / QwenWork / OpenSearch), oberoende forskning från tredje part (Memory in the Age of AI Agents, arXiv:2512.13564 m.fl. akademiska översikter) samt avidentifierade fall från samarbetskunder. Andelen tillverkarfall är något högre, och eventuella partiska synpunkter framgår av källhänvisningarna.

Bakgrund

Jag har nästan åtta års erfarenhet av strategisk rådgivning och affärsanalys inom stora organisationer, med tiden på IBM inklusive projekt inom telekom, finans, försäkring och tillverkningsindustri. Därefter har jag arbetat operativt med operatörsprodukter, internetbaserade tjänster och AI-applikationer – allt från kravanalys och produktdesign till implementering över teamgränser.

Den här plattformen drivs i praktiken av ett litet team – jag och en till två längsiktiga medarbetare som vi samarbetar med regelbundet. Vi har delat upp ansvaret mellan oss: AI-kodningsverktyg, analys av organisatoriska styrningsmodeller och coachande dialoger. De flesta av de projekt som beskrivs som “vi hjälpt företagen genom” är sådana som vi tillsammans har levererat.

Metodologisk position

Våra bedömningar i denna serie bygger på observationer från fältarbete och korsvalidering inom branschen. De representerar en tydlig författarposition och ska inte tolkas som ståndpunkter från någon tillverkare eller leverantör.