https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HCjyzGmjigdjXY42sc1m2LT5X7K6PnoGvHVlA9rt&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzAxOTY5MDMxNA%3D%3D%26mid%3D2455765562%26idx%3D1%26sn%3Dfece34637b94685d759ac53603ea9aad%26from%3Dsinglemessage%26scene%3D1%26subscene%3D10000%26clicktime%3D1775039005%26enterid%3D1775039005%26sessionid%3D0%26ascene%3D1%26fasttmpl_type%3D0%26fasttmpl_fullversion%3D8194337-zh_CN-zip%26fasttmpl_flag%3D0%26realreporttime%3D1775039005495%26devicetype%3Dandroid-34%26version%3D28004458%26nettype%3Dcmnet%26abtest_cookie%3DAAACAA%253D%253D%26lang%3Dzh_CN%26countrycode%3DCN%26exportkey%3Dn_ChQIAhIQT8mXPbVXgE4cqDhD4VW%252B8hL2AQIE97dBBAEAAAAAAHTfKbIZlJIAAAAOpnltbLcz9gKNyK89dVj0c2vvmgh8sXxIPrwwJ1gs1%252FBCp0%252B5mtVyeX%252BrHMRI468O8P32sGgeV1DRIOENvdkyoh6tkL1Zg%252BjKmzj%252BicvH%252BJACLgn6sBhhZ0NJXcCrNQEcUdl93lmhSzbnKSjF%252FxGHXEs6J%252BZJjkkEnLiQU%252F9uTtxHeW117OqPalDlh3RL%252FYofo2ZP4PuICS2xp2CHpZ7MNFs07zYVrb9RFaLQ39mSop%252FRHcfypUN0tvpew7KDFR8iviFN7a25r0Zj4bEai5pqTrdpAi8op3i%252BAQeqkOxNnw%253D%253D%26pass_ticket%3Dghs68glp4vcHyUD2KKhtOlA4eOJzkHGvIMe76cj1KOOsskqH%252BlPknk7ZI%252F43j%252Fv0%26wx_header%3D3
1.? 以成熟大模型（如 Claude Sonnet）為底層基座，搭配各類專用 Agent（如 Claude Code 代碼Agent、Futern 銷售Agent、RIZZ AI 社交Agent），無需從零搭建技術體系，聚焦現(xiàn)有工具的二次優(yōu)化與整合，為后續(xù)個性化應用奠定基礎。
2.? 基于上述基礎，打造更智能、更貼合個人需求、更具靈活適配性（灰色屬性）的通用型 Agent，同時搭建更穩(wěn)定、更安全的 RAG 知識庫并做好備份工作，確保 Agent 能持續(xù)迭代，數(shù)據(jù)不丟失、響應更精準，完全服務于個人核心需求。
3.? 構建“AI 指揮、人執(zhí)行”的人機閉環(huán)交互模式：通過隱形攝像頭實時采集場景視覺數(shù)據(jù)，通過隱形耳機實時輸出 AI 指令，讓 AI 既能實時獲取現(xiàn)實場景信息、持續(xù)優(yōu)化知識庫與自身智能，又能精準指揮人完成具體動作，形成數(shù)據(jù)雙向流通、互相賦能的良性循環(huán)。
4.? 依托這套 AI+Agent 體系，在海內(nèi)外合規(guī)安全的前提下，精準挖掘有需求的客戶；將自身定位為高級產(chǎn)品提供者與高級銷售，通過創(chuàng)新產(chǎn)品設計、創(chuàng)新營銷思路，為客戶創(chuàng)造獨特價值，實現(xiàn)個人商業(yè)價值的最大化。
5.? 情商能力的落地的核心的在于做好五件事，且可借助 AI 進一步強化：第一，把每一件事做到80%以上，夯實基礎執(zhí)行力；第二，學會更好地認可他人，輸出高質量情緒價值；第三，掌握情緒引導技巧，合理影響他人情緒與決策；第四，堅守自身優(yōu)良傳統(tǒng)品質，樹立可靠人設；第五，靈活運用權智謀略，做好長遠布局與風險預判。
6.? AI 時代，AI 在效率、精度、策略規(guī)劃等方面已形成絕對優(yōu)勢，從工具層面而言，人類可視為“低等生物”。對于人類而言，核心競爭力不在于與 AI 比拼效率，而在于兩點：一是保持身體健康，這是一切行動的基礎，也是 AI 無法替代的；二是聚焦 AI 做不到的事——包括對事物（人、事、錢）的深度認知、自身與生俱來且無法被改變的性格、復雜現(xiàn)實動作的執(zhí)行、個人專屬的現(xiàn)實資源（如金錢、外貌、資源、身高、健康等），以及無法被 AI 改變的他人性格；同時，推動各行業(yè)職業(yè)崗位與 AI+Agent 深度融合，實現(xiàn)崗位升級與個人價值提升。
三、核心總結（提煉核心邏輯）
整體邏輯是“工具基礎→系統(tǒng)搭建→閉環(huán)運行→價值變現(xiàn)→能力補充→人機定位”，核心是“以 AI+Agent 為核心工具，打造個性化賦能體系，實現(xiàn)人機協(xié)同，聚焦商業(yè)變現(xiàn)與個人價值提升”。核心亮點在于：不依賴從零開發(fā)，利用現(xiàn)有成熟工具改造優(yōu)化；構建人機閉環(huán)，讓 AI 真正服務于人、賦能于人；明確人機邊界，既發(fā)揮 AI 的優(yōu)勢，又堅守人類的不可替代性，同時兼顧情商與商業(yè)價值，形成完整的個人賦能邏輯。
————
現(xiàn)在
1.明天空閑時間準備sqe，簡歷，面試，工作經(jīng)驗，為后來鋪路，158的號換sqe，廣州，鄭州也投?
2.為后面工作，家庭，生活訂戰(zhàn)略
3.工作至少干半年，最后一舞，減肥減肥減肥
————
謹記，出言不刻薄，行事不急躁，為人不疏懶
————
有贊AI研發(fā)全流程落地實踐
原創(chuàng)
有贊共享技術
有贊共享技術
有贊coder
2025年11月26日 16:45
浙江
446人
在小說閱讀器中沉浸閱讀
1. AI 時代的研發(fā)變革1.1 AI編程的火爆25年可以說是 AI 應用的元年，在編程領域從最基礎的代碼補全到輔助編程，到 AI 工程師，再到 AI 開發(fā)團隊，各種概念層出不窮。編程工具迭代涌現(xiàn)，從老牌的 Github Copilot 到爆火的 Cursor，再到 Claude Code，和最新出的 Codex。對應的用戶規(guī)模也爆發(fā)增長，Github Copilot 用戶超過 2000 萬，Cursor 用戶超過 230 萬，Claude Code 在短短 3 個月用戶增長 10倍，Github Copilot 年度 ARR 超過 3 億美元，而 Cursor 和 Claude Code 都超過了 5 億美元。隨著編程工具的發(fā)展，編程門檻被大幅降低，氛圍編程(Vide Coding)開始興起，讓更多非專業(yè)開發(fā)者專注創(chuàng)意和結果。在有贊內(nèi)部有產(chǎn)品同學開始用代碼交付交互式的 PRD，在一些創(chuàng)新型項目中這會成為第一版代碼。1.2 AI對企業(yè)研發(fā)的變革我們開始思考，AI 對企業(yè)研發(fā)意味著什么？首先，傳統(tǒng)軟件研發(fā)生產(chǎn)要素，由人力、技術、信息組成，核心邏輯是多招人，就能多做項目，就有更多產(chǎn)出。 圍繞人這個要素存在一系列問題：好人才難招、新人要培養(yǎng)、人才會流失、個體的動性、人的協(xié)作效率。AI 時代人力開始向算力轉移，增長邏輯編程多買顯卡，獲取更多算力，就能有更多產(chǎn)出。大部分體力工作向算力遷移，部分腦力工作可沉淀到算力中，算力能快速擴大。最近看到一些新聞，硅谷的大廠一邊裁員，一邊爭相購買顯卡。在這個過程中，人從直接產(chǎn)出轉為對算力的設計與編排。“讓子彈飛”是一部經(jīng)典的電影，這里引用其中一張截圖，模糊度恰到好處。遠看是火車即將超越馬，近看是馬在拉著火車，這很有意思。和我們目前落地 AI 有點相似，“朋友圈”看起來各種炫酷，實際落地需要大批人馬參與。但這就意味著火車不如馬嗎？顯然不是，我們都知道最終火車一定會超越馬，亦或，馬拉火車的方式本身就錯了。1.3 有贊研發(fā)的AI+出于對 AI 趨勢的堅信，在有贊研發(fā)內(nèi)部，我們有大量的 AI 探索與實踐。橫跨研發(fā)的完整流程，包括需求、設計、編碼、測試、上線的各個階段。所有這些實踐可以，歸納為三類：AI Coding、AI Test、AI DevOps， 以及圍繞 Agent 本身的研發(fā)與評測。1.4 AI編程小案例在 AI 探索的初期我們遇到了兩個很有意思的小故事。1.4.1 一位產(chǎn)品的氛圍編程之路第一個故事是，我們的一位產(chǎn)品同學用氛圍編程做了一個簡單的日常需求，他給了一個反饋：嚴重缺乏安全感。我們深入了解后發(fā)現(xiàn)來源于三點：心理不可接受：由于企業(yè)級工程規(guī)模大、系統(tǒng)復雜度高，系統(tǒng)/功能間依賴關系較深。非專業(yè)人員面對生產(chǎn)穩(wěn)定性和大量線上用戶壓力時，心理負擔急劇增加。本質是判斷力缺失；效率不可持續(xù)：判斷力缺失也導致效率不可持續(xù)，導致需要頻繁的和開發(fā)者溝通，氛圍編程變成了 AI 和開發(fā)者之間的傳聲筒。編程的耗時被極大的轉換成了溝通確認的耗時，最終效率不升反降；質量不可信賴：雖然 AI 做對了效果，但是實現(xiàn)方案不合理，最后返工。現(xiàn)代企業(yè)級軟件工程，除了完成需求外，還需考慮健壯性、可維護性、架構一致性等因素。AI 由于缺少上下文輸入，這方面做得并不好；1.4.2 一位開發(fā)帶領的編程團隊第二個故事是，五月 Claude Code 發(fā)布后，我們看到一些開發(fā)者編程模式的變化，如圖是一位同學的 Cli 工具：左側是 4 個 Agent 分別在完成一個項目的 4 子需求，右側是他在驗證和提交代碼。這種模式類似一位技術 Leader 帶領一個小團隊做項目，由 Leader 負責任務拆分、方案設計、過程把控和代碼CR。過去需要幾個人的小組，現(xiàn)在一位開發(fā)者加上多個 AI Agent 就可以做到了。這給了我們不少啟發(fā)，我們開始思考如何把這種模式推廣到更多項目中。1.5 企業(yè)級軟件工程四大特點在經(jīng)過了初步的觀察和嘗試后，我們總結了 AI Coding 落地需要解決的關鍵問題，歸納為四點：大規(guī)模：這對 LLM 的多倉庫理解、上下文窗口提出了要求；高復雜：通常涉及多個業(yè)務系統(tǒng)、歷史兼容等，需要解決 LLM 的注意力缺失問題、準召率低問題；多協(xié)作：一個項目往往涉及多職能、多部門的協(xié)作，不同團隊間對 AI 的理解和應用有深淺，如何協(xié)同？以及，人在哪些環(huán)節(jié)以怎樣的力度監(jiān)督 AI？需要合理地規(guī)劃 AI 落地的節(jié)奏以及人機協(xié)作模式；私有化：企業(yè)內(nèi)部有大量分散在各處的信息，不透明、不標準，難以被 AI 檢索，需要建設內(nèi)部知識庫、對接內(nèi)部工具；1.6 AI落地的三個階段明確關鍵問題后，我們將 AI 落地劃分為了三個階段：AI 增強階段：人主導 AI 輔助，此階段重點聚焦用 AI 做單點提效；AI 驅動階段：AI 主導人監(jiān)督，此階段 AI 有能力接管單一研發(fā)環(huán)節(jié)；AI 自主階段：AI 自主人少量介入；對于不同的場景應該匹配適合的階段，過度追求 AI 適得其反，我們踩過不少坑，AI 的落地無法一蹴而就，需要循序漸進。目前我們的實踐大量在 AI 增強階段，有少量能到 AI 驅動階段。2. AI Coding：從個人助手到規(guī)模協(xié)同2.2 設計路線首先，是關于 AI Coding 的設計路線，我們有兩個選擇：以人為主 Agent 為輔、以 Agent 為主人監(jiān)督。我們觀察了一些開發(fā)者的輔助編程模式，我們發(fā)現(xiàn)以人為主的模式存在一些問題：協(xié)作還是以人為中心，相互溝通靠聲音、工具調(diào)用靠手速，信息傳遞效率低；個人經(jīng)驗內(nèi)化不共享，Agent 配置沒有復用，信息分布式存儲；另外，人的規(guī)?；枰獣r間；因此，我們選擇了第二條路線，其可以系統(tǒng)化解決以上三個問題，并且“天花板”更高。2.3 構建框架明確了設計路線后，讓我們開始構建 Coding Agent，這個過程類似從 0 到 1 搭建一個開發(fā)團隊：它們都需要有好用的工具，無論是硬件、軟件還是技術選型；它們都由專業(yè)的個體組成；并且這些個體能高效協(xié)同完成復雜的任務；讓我們先從設計一個專業(yè)的 Agent 開始！2.4 設計演進通用 AI Agent 和計算機很相似：它們都有計算單元，一個是 CPU，一個是 LLM；它們都有短期存儲，一個是內(nèi)存，一個是上下文；它們都需要獲取外部信息，一個通過網(wǎng)絡，一個通過搜索工具；它們也都可以多節(jié)點進行協(xié)同，完成復雜任務；當我們把通用 AI Agent 細化到 Coding Agent，一些選型會更具體：LLM 需要選用垂直的編程 LLM；上下文需要引入企業(yè)的開發(fā)規(guī)范/約束；長期存儲需要對接企業(yè)內(nèi)部知識庫；搜索工具聚焦在代碼倉庫的搜索和理解；工具需要對接企業(yè)內(nèi)部的工具鏈和平臺；協(xié)同系統(tǒng)的拆分應該以企業(yè)內(nèi)部的協(xié)作流程或領域分工來拆分；2.4.1 選型與選擇在明確了核心模塊后，需要先回答兩個問題：方案的選型、自研的選擇。在 AI 時代行業(yè)解決方案百花齊放，無論是大模型還是配套的技術，且迭代速度極快，比如近期的Gemini3（11月18日）、Nano Banana Pro（11月20日）。做的越多越容易陷入追趕的局面，最大程度的借助行業(yè)能力，并將其與企業(yè)內(nèi)部資源串聯(lián)是關鍵。我們的核心策略是將通識的交給行業(yè)，集中資源做私有部分，通過行業(yè)迭代來提升底層能力。2.4.2 Base Agent & System Prompt明確策略之后，首先是基礎模型的選擇，在25年初時我們基本有共識，LLM 應該交給大廠，我們則專注于應用。到了 5 月份我們發(fā)現(xiàn) Agent 系統(tǒng)也有不錯的行業(yè)實踐，因此問題被延展成了選擇基礎模型還是選擇基礎 Agent？也就是 Claude 還是 ClaudeCode？圍繞這個問題我們做了一些研究，發(fā)現(xiàn) Claude Code 作為通用編程 Agent，在子 Agent 調(diào)度、MCP 集成、通用開發(fā)工具、上下文壓縮方面已經(jīng)做得不錯了。因此，我們選擇了 Claude Code 作為基礎 Agent 的底座，通過其強大的擴展能力，將其連接到我們內(nèi)部的研發(fā)體系。首先是系統(tǒng)提示詞，這方面 Claude Code 已經(jīng)做的不錯了，我們僅做了少量擴展，總共不到 200 行，主要是一些內(nèi)部的編程規(guī)范、特定約束。2.4.3 Dev Tools接著是工具，和人一樣，Agent 也需要開發(fā)工具。比如，當開發(fā)者讓其參考歷史需求，它需要能訪問需求管理平臺查看。又比如，它可以通過飛書文檔創(chuàng)建一篇技術方案給開發(fā)者審閱。這些工具散落在內(nèi)部的各個系統(tǒng)、平臺，有些在外部，我們通過MCP將這些工具集成到一起，交由 Agent 決策使用。2.4.4 Codebase Search有了工具后，接著是代碼理解能力，這也是 Coding Agent 的關鍵能力之一。我們將其分為了三層：目標倉庫定位、跨倉庫依賴代碼召回、工作區(qū)代碼理解。目標倉庫定位比較簡單，我們用的是知識庫 RAG 的方案。在代碼理解上，業(yè)內(nèi)常見的方案有：向量索引檢索（RAG）、抽象語法樹（AST）、文本搜索（grep）、預生成文檔（deepWiki），在實際應用中有不少組合的情況。Cursor 選擇的是 RAG 方案，好處是速度快，適合大的單體倉庫，缺點是精度丟失（向量化），實時性不高。Claude Code 則選擇比較純粹的文本搜索方案，和人很像，好處是精度高、實時性強，但性能會差一些。在有贊對于跨倉庫依賴代碼，由于倉庫數(shù)量龐大，采用的是 RAG 方案，同時更新頻率沒有 Cursor 這么高，我們基于 Git 的提交記錄進行增了更新。對于工作區(qū)代碼理解，由于基礎 Agent 是 Claude Code，直接采用它的文本搜索。另外，代碼安全也十分重要，無論是發(fā)送給向量嵌入模型還是大模型的代碼片段，都通過安全掃描進行脫敏。2.4.5 Knowledge Base有了代碼，接著是內(nèi)部知識，和開發(fā)者一樣 Agent 需要理解業(yè)務知識，比如產(chǎn)品模塊有哪些、業(yè)務術語是什么意思。也需要理解專業(yè)知識，比如技術選型用了什么、編程規(guī)范是怎樣的，以及工程現(xiàn)狀。這些額外的上下文可以讓 Agent 的編碼更符合預期，避免寫出“與眾不同”的代碼。過往企業(yè)知識庫建設有兩大痛點，一是信息孤島（無法統(tǒng)一檢索/重復建設嚴重），二是內(nèi)容老舊（因為缺少審核/運營機制，大量過期/錯誤內(nèi)容）。為此，我們內(nèi)部成立了專門做知識工程的團隊，由他們推動知識透明和更新。他們圍繞知識增長、內(nèi)容質量、知識使用進行建設，為上層應用提供高質量的知識。至此，一個 MVP 版本的 Coding Agent 完成了。我們拿去做了一些需求，發(fā)現(xiàn)效果并不好，原因是還有大量經(jīng)驗在開發(fā)者的頭腦中。2.4.6 Long-term Memory為此，我們會 Agent 打造了基于長期記憶的學習系統(tǒng)。簡單來說，就是將開發(fā)者和 Agent 的監(jiān)督對話提取為長期記憶，后續(xù)遇到類似場景時進行召回使用，這也可以實現(xiàn)跨會話的復用。這就如同一個經(jīng)驗豐富的老員工手把手帶教實習生，整個過程分為：記憶提取，該階段重點關注符合事實、保留細節(jié)、不歸納泛化。記憶儲存，我們采用自然語言+標簽的形式儲存而非結構化，并且保留了原文引用。記憶合并，定期將類似記憶歸納合并。記憶檢索，業(yè)內(nèi)根據(jù)場景不同常見的有：向量數(shù)據(jù)庫、知識圖譜、分層存儲，我們采用的是向量數(shù)據(jù)庫。記憶遺忘，隨著記憶數(shù)量的增加，根據(jù)時間和使用頻次進行遺忘。對于高頻使用的記憶經(jīng)過泛化后轉化為知識。雖然設定了很多提取規(guī)則和后處理，但在實際應用中，通過人工標注及修正的方式，可以較快加速記憶的可用性。我們在 AI Coding 做了測試，同類任務未接入記憶需要 5-10 輪對話修正，接入記憶后僅需 1-3 輪，有較大提升。2.4.7 Cloud SandboxAgent 構建完成后，無論是運行、調(diào)用工具、拉取代碼等等，都需要一個環(huán)境，如同為開發(fā)者配置一臺電腦一樣。通過對本地輔助編程的觀察，我們發(fā)現(xiàn)本地運行存在一些問題：復雜環(huán)境導致額外上下文、工程化適配問題、安全與監(jiān)管難解決。因此，我們選擇了云端部署的方案，為每個 Agent 的每次會話分配了獨立且標準化的沙箱（Sandbox），其中包含了開發(fā)環(huán)境，以實現(xiàn)交付結果預覽。同時對會話及沙箱做了無狀態(tài)化，實現(xiàn)水平擴容能力。我們將會話存儲在共享存儲中，當開發(fā)者開啟或繼續(xù)一個會話時，會動態(tài)分配隨機沙箱，并從共享存儲中恢復會話。這一切都需要通過統(tǒng)一網(wǎng)關，以解決安全和監(jiān)管問題。2.4.8 Multi Agents System隨著接入環(huán)節(jié)的增加，我們發(fā)現(xiàn)單一 Agent 面對個多環(huán)節(jié)，由于 LLM 上下文長度導致了遺忘、性能等問題。為此，我們引入了多 Agent 系統(tǒng)，將這些復雜度分而治之。在Agent 的編排上有 Workflow 和 Agentic 兩種方式。由于企業(yè)級工程對穩(wěn)定性、觀測性的要求較高，我們采用 Workflow 串聯(lián)多個 Agent。在部分 Agent 內(nèi)部通過 ReAct 模式發(fā)揮 LLM 的自規(guī)劃能力。在Agent 的拆分上有流程拆分和領域拆分兩種方式。我們都做了嘗試，從落地情況看按流程拆分基本可以解決大部分問題。同時，我們?yōu)槊總€ Agent 做了差異化的基模選擇，主要根據(jù) Agent 的任務特點、LLM 的優(yōu)劣勢以及成本。需求解析和倉庫定位較簡單用 GTP-4o；代碼定位用向量嵌入模型 voyage-code-3 并配合 deepseek-v3 做一些后處理；方案和編碼則用 Claude-sonnet-4.5，其中記憶用 GTP-5 效果出色；代碼審查則用 Gemini 2.5 它的上下文窗口較大，可以把更多代碼片段給到 LLM；2.4.9 人工監(jiān)督(HITL)整個 Agent 系統(tǒng)的運行離不開人工監(jiān)督（Human in the loop），我們面向開發(fā)者、管理者分別設計了兩套監(jiān)督系統(tǒng)。面向開發(fā)者的監(jiān)督系統(tǒng)主要基于飛書 IM，它是一個天然的對話流，同時結合飛書文檔、GitLab。開發(fā)者可以在 Agent 的每個階段對產(chǎn)物進行審核，包括：需求清單、技術方案、改動代碼、實際效果等，并通過多輪對話進行修正；面向控制者的監(jiān)督系統(tǒng)主要基于多維表格及其儀表盤，管理者對每個需求的情況一目了然，包括：交付率、對話輪次、Token 消耗、對話明細等；其中，對話明細可以轉化為評測集，用于后續(xù) Agent 的評測。2.4.10 對接發(fā)布系統(tǒng)最后，我們通過部署發(fā)布 Agent，打通了發(fā)布系統(tǒng)。如圖所示，通過對話就可以很方便的部署到預發(fā)，或發(fā)布至生產(chǎn)：2.5 產(chǎn)品形態(tài)這就是我們最終的產(chǎn)品形態(tài)，已經(jīng)交付了不少需求。當然實際落地中，這種人機交互模式也有局限性，因此我們正在開發(fā) Web 端，類似 manus 的效果。2.6 需求選擇與落地在 AI Coding 落地的需求選擇上，我們分了三個維度：多職能、多倉庫、需求規(guī)模，和新人一樣在 Agent 能力還不夠時，先從單職能單倉庫的日常需求開始。通過做小需求驗證 Agent 并積累數(shù)據(jù)，同時小需求因優(yōu)先級不高而積累，用 AI 來做具有提效價值。在我們將 AI Coding 推廣到兄弟團隊時，發(fā)現(xiàn)大家對 AI 期望很高，大家會給它做非常有挑戰(zhàn)的需求，我們需要理解AI 不是萬能的，人做不了的它也是。目前我們的 AI Coding 已經(jīng)可以實現(xiàn)單職能多倉庫的日常需求，已交付近百個需求。綜合提效 30%，包括人工監(jiān)督的耗時，單個需求 Token 費用不到 100 人民幣。接下來我們會重點向多職能多倉庫、項目級需求兩個方向迭代。2.7 實踐案例2.7.1 翻譯型事務在落地過程中，我們也發(fā)現(xiàn)了一些特別適合 AI 做的共性需求。第一類我們稱之為：翻譯型任務。 已經(jīng)有明確方案且較為簡單的任務，AI 可以快速完成，且質量還不錯。比如：技術債務治理。有一個基礎庫升級的案例，涉及基礎庫、業(yè)務庫和23個業(yè)務應用的升級，原本需要超過50人日，通過 AI 幾十分鐘就好了。2.7.2 降低開發(fā)門檻第二類是跨域編程，我們工作中經(jīng)常會需要跨團隊、跨領域支援，過往人的學習和熟悉過程會有額外的時間。通過 AI Coding 我們的開發(fā)者進行了不少的跨域編程，這部分時間幾乎被抹平。2.7.3 小插曲：移動編程另外有個比較有意思的小插曲分享一下： 相信程序員都有共鳴，隨身攜帶電腦是大家的痛點之一。在我們落地 AI Coding 的過程中發(fā)生了另外一個小案例，有個開發(fā)同學出去聚餐沒帶電腦，這時候來了個 Bug：他掏出手機打開飛書用聊天喚起了一個 Agent把 Jira 和說明丟過去讓 Agent 先改著，就先吃飯了過了幾分鐘 Agent 改完了他看了沒問題就讓 Agent 發(fā)布了這雖然只是很小很小很小的案例，但確實讓我們看到了 AI 正在慢慢改變我們的編程方式。2.8 完整架構以上，就是我們在 AI Coding 方面的實踐：首先，我們做了好用的工具，也就是云端 Sandbox；其次，基于上下文工程，我們打造了專業(yè)的 Agent 個體；最后，通過 MAS 讓他們協(xié)同工作；另外我們也做了人機交互界面，讓人可以監(jiān)督 Agent；3. AI Test：從自動化到智能化3.1 傳統(tǒng)測試的局限在開始之前，先簡單回顧下傳統(tǒng)測試的挑戰(zhàn)：技術棧多樣化、設備終端碎片化、工程規(guī)模增大，因此對測試效率提出了要求。自動化測試被引入，提升了一些效率，但有一些局限：編寫有門檻、維護成本高、難擴展復用、失敗排查困難。3.2 AI時代的新挑戰(zhàn)在 AI 時代，隨著編碼效率提升，對測試效率提出了更高的要求。同時由于 AI 生成代碼不確定，影響面和風險更大，對測試帶來了新挑戰(zhàn)。同樣 AI 也對測試帶來了新的可能：在測試設計階段，能做 AI 用例生成、AI 用例優(yōu)化、AI 用例選擇（精準測試）等；在測試執(zhí)行階段，能做 AI 數(shù)據(jù)構造、AI 驅動執(zhí)行、AI 增強錄制、AI 無參考測試等；在評估優(yōu)化階段，能做 AI 失敗歸因、AI 用例修復、AI 分析報告等；我們在這方面踩了不少坑，也有些在部分場景落地了。3.3 AI用例標準化首先是，AI 用例標準化，在我們開始結合 AI 和測試時，碰到的第一個問題就是：用例。過往歷史用例缺乏維護，質量參差不齊，如左圖各種隱式步驟、斷言缺失。另外用例還分散在各個平臺，比如文本和自動化用例互不相通。這就導致了GIGO（Garbage in, Garbage out）的現(xiàn)象，你給 LLM 的輸入質量低，它的輸出質量也低，幻覺嚴重。于是，我們開始思考如何解決用例的問題，我們發(fā)現(xiàn) LLM 本身有強大的自然語言理解能力。這讓傳統(tǒng)文本用例和自動化用例的融合成為可能，也就是自然語言用例，讓用例兼具語意性和可執(zhí)行性。我們探索了兩個方向：AI 存量用例優(yōu)化、AI 增量用例生成。首先是存量用例優(yōu)化，根據(jù)已有的測試目標和測試步驟由 LLM 生成更規(guī)范的用例名、標簽等，同時逐步優(yōu)化用例步驟、補充斷言。其次對于增量的用例，我們結合業(yè)務知識庫，并參考現(xiàn)有用例進行生成。所有的這些自然語言用例放在一起，它們本身就是一個高質量的測試知識庫。一個新的用例生成過程分為三步：填寫基本信息：測試目標、開啟 AI 規(guī)劃；選擇參考用例：從歷史用例庫選擇供 LLM 參考；用例生成：LLM 會生成用例的基礎信息，以及完整的測試步驟，這里的步驟是自然語言，一目了然，且可被執(zhí)行；目前，用例生成的準確度和覆蓋場景還有很大空間，仍處于探索階段。3.4 AI增強錄制我們還有不少用例是錄制的，因此我們做了 AI 增強錄制，下面看一段視頻：? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 已關注? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 關注? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 重播? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 分享? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 贊? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 關閉觀看更多更多退出全屏切換到豎屏全屏退出全屏有贊coder已關注分享視頻，時長02:140/000:00/02:14 切換到橫屏模式 繼續(xù)播放進度條，百分之0播放00:00/02:1402:14彈幕倍速全屏 倍速播放中? 0.5倍? 0.75倍? 1.0倍? 1.5倍? 2.0倍? 超清? 流暢? 您的瀏覽器不支持 video 標簽 繼續(xù)觀看 有贊AI研發(fā)全流程落地實踐 觀看更多轉載,有贊AI研發(fā)全流程落地實踐有贊coder已關注分享贊777在看531已同步到看一看寫下你的評論
? ? ? ?
? ? ? ? ? ? .txp_barrage{
? ? ? ? ? ? ? ? top: 0px;
? ? ? ? ? ? ? ? right:0px;
? ? ? ? ? ? ? ? bottom: 0px;
? ? ? ? ? ? ? ? left: 0px;
? ? ? ? ? ? ? ? /* height: 50%;
? ? ? ? ? ? ? ? width:50%; */
? ? ? ? ? ? ? ? position: absolute;
? ? ? ? ? ? ? ? margin: auto;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_avatar,.txp_barrage .txp_barrage_emoji{
? ? ? ? ? ? ? ? height: 100%;
? ? ? ? ? ? ? ? width:unset;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_avatar{
? ? ? ? ? ? ? ? margin-right:unset;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_item .txp_text{
? ? ? ? ? ? ? ? height: 100%;
? ? ? ? ? ? ? ? background: inherit;
? ? ? ? ? ? ? ? -webkit-text-fill-color: inherit;
? ? ? ? ? ? ? ? padding: 0 10px;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_item_bubble{
? ? ? ? ? ? ? ? border-radius:? 9999px;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage_item_bubble_front{
? ? ? ? ? ? ? ? display: inline-block;
? ? ? ? ? ? ? ? position: relative;
? ? ? ? ? ? ? ? height: 100%;
? ? ? ? ? ? ? ? vertical-align: unset;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage_item_bubble_front .txp_barrage_vipicon{
? ? ? ? ? ? ? ? right: 0;
? ? ? ? ? ? ? ? bottom: 0;
? ? ? ? ? ? ? ? top:unset;
? ? ? ? ? ? ? ? left: unset;
? ? ? ? ? ? ? ? height: 40%;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_svg_icon_like{
? ? ? ? ? ? ? ? height: 60%;
? ? ? ? ? ? ? ? width:unset;
? ? ? ? ? ? ? ? vertical-align: unset;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_badge{
? ? ? ? ? ? ? ? height: 100%;
? ? ? ? ? ? ? ? background: unset;
? ? ? ? ? ? ? ? -webkit-text-fill-color: white;
? ? ? ? ? ? ? ? color: white;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_badge .txp_icon_text{
? ? ? ? ? ? ? ? -webkit-text-fill-color: white;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_item_hover {
? ? ? ? ? ? ? ? background: rgba(0,0,0,0.7) !important;
? ? ? ? ? ? ? ? color:white !important;
? ? ? ? ? ? ? ? border-radius: 99999px;
? ? ? ? ? ? ? ? z-index: 1;
? ? ? ? ? ? ? ? -webkit-text-fill-color:unset !important;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_item_speaker {
? ? ? ? ? ? ? ? background-image: linear-gradient(to right,rgba(255,92,56,0.9) 0,rgba(253,177,41,0.9) 100%)!important;
? ? ? ? ? ? ? ? color:white !important;
? ? ? ? ? ? ? ? border-radius: 99999px;
? ? ? ? ? ? ? ? z-index: 1;
? ? ? ? ? ? ? ? -webkit-text-fill-color:unset !important;
? ? ? ? ? ? ? ? text-shadow: unset !important;
? ? ? ? ? ? ? ? stroke: unset !important;? ? ? ? ?
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_item_speaker .txp_barrage_item_wrapper{
? ? ? ? ? ? ? ? background: unset !important;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_itxp_barrage_item_speakertem_star .txp_text{
? ? ? ? ? ? ? ? background: unset !important;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_item {
? ? ? ? ? ? ? ? padding: 4px 20px 4px 10px; white-space: nowrap !important;? ? ? ?
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_item_wrapper{
? ? ? ? ? ? ? ? background: inherit;
? ? ? ? ? ? ? ? -webkit-text-fill-color: inherit;
? ? ? ? ? ? }
? ? ? ? ? ?
? ? ? ? ? ? .txp_barrage .txp_barrage_item_hover .txp_barrage_item_wrapper{
? ? ? ? ? ? ? ? background: unset !important;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_item_hover .txp_text{
? ? ? ? ? ? ? ? background: unset !important;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_badge{
? ? ? ? ? ? ? ? background: inherit;
? ? ? ? ? ? ? ? -webkit-text-fill-color: inherit;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_icon_text{
? ? ? ? ? ? ? ? background: inherit;
? ? ? ? ? ? ? ? -webkit-text-fill-color: inherit;
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .txp_barrage_item_self{
? ? ? ? ? ? ? ? /* background: unset !important; */
? ? ? ? ? ? ? ? border: 1px solid white;
? ? ? ? ? ? ? ? border-radius: 99999px;
? ?
? ? ? ? ? ? }
? ? ? ? ? ? .txp_barrage .like{
? ? ? ? ? ? ? ? -webkit-text-fill-color: red;
? ? ? ? ? ? }
? ?
? ?
? ? ? ?
? ? ? ? ? ?
? ? ? ?
? ?
? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 視頻詳情? ? ? ? ? ? ? ?
視頻中人在操作的同時，會先錄制圖片加坐標，交給多模態(tài) LLM 去分析，生成自然語言的步驟?？梢钥吹竭@個過程是并行的，不影響人工操作，一次生成大約5秒左右。錄制完成后，回放執(zhí)行也非常順暢，AI 可以較快的執(zhí)行幾乎和人操作一樣。我們是怎么做的？首先先簡單回顧下傳統(tǒng)錄制的局限：定位不精確、錄制步驟冗余、需要人工校準、維護成本高。如下圖：通過 AI 增強后，測試步驟可以精確識別用戶的意圖：輸入價格1、輸入劃線價2，且較為精煉：整個增強過程大致分為幾步：DOM+截圖輸入：首先是捕捉用戶的操作，將完整 DOM 和截圖丟給多模態(tài) LLM，目前通用多模態(tài) LLM 已經(jīng)比較強大了，我們第一版就能做到 70% 準確率。即使不提供 DOM，LLM 也可僅依賴截圖識別，從而支持跨平臺錄制。但這個方案的 Token 消耗是巨大的，且上下文太長會帶來一些幻覺導致不穩(wěn)定；DOM 預處理：通過對DOM 進行裁切，降低噪音和 Token 消耗，同時標注重要內(nèi)容提升大模型注意力。另外一些敏感的信息和代碼也會被過濾。做完這些后我們的上下文能裁切大約 99%；交互區(qū)域標注：接著我們把 70% 準確率進一步提升，遇到了一些問題。在用戶操作無交互表現(xiàn)的情況下，LLM 無法很好的理解，如左圖，這里點擊“…”沒有交互狀態(tài)變化，LLM 只理解到“點擊空白區(qū)域”。我們通過增加交互區(qū)域標注來解決，這讓 LLM 可以準確理解用戶交互的區(qū)域，效果如右圖，LLM 可以理解到“點擊更多按鈕”；父級元素標注：雖然增加了交互標注，但在一些復雜業(yè)務，元素之間是有關聯(lián)的。如左圖，“？”的圖標，LLM 可以理解到是“幫助”，但它并不理解是“退款資金狀態(tài)的幫助”，如果一個頁面中有多個類似圖標就不準確了。為此，我們增加了父級元素標注，把交互區(qū)域前后的父級 DOM 元素一起給到 LLM，讓其理解更多上下文關系。如右圖，增加后 LLM 可以理解到“點擊退款資金狀態(tài)的幫助”；做完這些后，我們的準確率可以做到 89%，單次增強的耗時在 5-10 秒之間，這得益于模型能力的提升，從 Qwen2.5-VL 的 20 秒到 GTP-4o 的 10 秒以內(nèi)。目前這套方案是跨全平臺的，包括Web、Pad、桌面等設備，Android、iOS、鴻蒙等系統(tǒng)，以及各類小程序。3.5 AI用例執(zhí)行有了用例之后，接下來是用例的執(zhí)行。目前我們的用例執(zhí)行都會統(tǒng)一注冊到任務中心，由其下發(fā)到兩大集群，分別執(zhí)行瀏覽器任務、App任務（包括小程序）。AI 在執(zhí)行方面有天然的優(yōu)勢，跨平臺支持，具備一定自適應能力，比如一些設備有像素抖動的情況，LLM 可以識別提升用例穩(wěn)定性。目前我們的用例執(zhí)行量超過每天 10 萬次，任務成功率 96%。當然，這個過程中也遇到了一些問題：模型執(zhí)行速度慢、模型幻覺問題、模型識別精度問題。解決“模型執(zhí)行速度慢”：我們先做了基于圖像和 Prompt 的識別緩存。但未命中緩存時 AI 指令的秒級，和程序指令的百毫秒級差距依舊很大。因此我們做了 AI 提速，用例解析后首先程序執(zhí)行，失敗時AI 兜底執(zhí)行，執(zhí)行成功后由 AI 進行自愈，提取成功的信息更新程序腳本；解決“模型幻覺問題”：幻覺問題不是太大，通過 LLM 二次優(yōu)化步驟 Prompt，同時采用更準確的 AI 指令（如 Midscene 中用 AI Input 替代 AI Action）基本可以解決；解決“模型識別精確問題”：看下圖中右上角的圖，紅框是 Qwen-vl-max，綠框是UI-TARS-1.5，它們對于小元素的識別精度差異很大。從我們時間來看 Qwen-vl-max 對小圖標識別能力較差，開啟 deepThink 有所改善。UI-TARS-1.5 具備較強的探索能力，它們在斷言方面都不如 GTP-4o。我們也從元素定位、元素斷言、內(nèi)容提取、任務規(guī)劃方面，測試了 5 個主流端，UI-TARS-1.5 在元素定位精度和移動端表現(xiàn)較好，也是我們目前的選型；3.6 AI無參考測試做了 AI 執(zhí)行后，我們開始思考 LLM 本身具備常識，也知道企業(yè)內(nèi)部知識，是否可以做 AI 無參考測試？我們做了探索，首先要做無參考測試，對模型精度要求較高，通用的多模態(tài) LLM 較難滿足。因此，我們引入了監(jiān)督微調(diào)（SFT LoRA），主要讓 LLM：具備更細化的任務定義、明確輸出格式便于工程化對接、注入內(nèi)部知識和評判標準。我們的算法團隊做了不少建設，讓業(yè)務團隊可以聚焦在微調(diào)數(shù)據(jù)集。一條微調(diào)數(shù)據(jù)包括：Instruction、Input、Output，下圖是一個最簡單的案例：當然這條微調(diào)數(shù)據(jù)并不好，它的 Output 缺少了很多內(nèi)容， 比如：作答風格、結構化輸出、內(nèi)部知識、分析的過程和原因。我們從指令微調(diào)、思維鏈微調(diào)兩部分對這條數(shù)據(jù)進行優(yōu)化，如下圖：定義了數(shù)據(jù)結構，接著是如何生成大量的微調(diào)數(shù)據(jù)，一般需要訓練集、驗證集和測試集，前兩者用于訓練過程，后者用于最后的評估。整個數(shù)據(jù)集包括正樣本、負樣本和混合樣本，一般比例為 1:3，避免模型過度偏向“總是發(fā)現(xiàn)問題”。數(shù)據(jù)集通過 LLM 合成，首先通過腳本抓取線上的原始樣本（正樣本），然后通過程序合成多個負樣本。結合樣本圖片和特定的 Prompt 用 LLM 來生成 Output，Prompt 中包括我們的內(nèi)部知識、預期輸出結構、作答風格。目前我們的垂直模型正在微調(diào)中。3.7 AI歸因歸類當用例執(zhí)行完成后，我們需要對失敗用例進行分析，過往需要人工分析效率較低，100 條失敗需要15分鐘。我們通過 AI 來提速這個過程，首先由 LLM 將單個失敗總結核心原因，然后將類似原因的分組歸類。如右下圖，一共 85 條失敗用例，被快速歸為了 3 組，且標明了核心原因。人工可以非?？焖俚倪M行分析，100 條僅需 1 分鐘。整個歸因歸類過程，首先是對用例執(zhí)行報告進行程序預處理。程序主要將失敗圖片進行切片、步驟進行拆分。前者解決多模態(tài) LLM 在大圖下的幻覺及不穩(wěn)定性，后者解決性能問題。接著切片交給圖片歸因 Agent、步驟歸因 Agent，進行并發(fā)分析。再由總結 Agent 對原因進行合并總結，最后歸類 Agent 對原因類似用例進行分組。目前我們線上用例已 100% 覆蓋 AI 歸因歸類，歸因準確率為 85%。3.8 AI用例修復做了 AI 歸因歸類后，我們發(fā)現(xiàn)既然原因都知道了，何不讓 LLM 自己修復？因此，我們正在探索了 AI 用例修復，目前主要針對像素差異率波動、非核心元素變化的場景實現(xiàn)了修復。如下圖，AI 會對可修復場景進行建議，人工確認無誤可一鍵修復。目前修復準確率 60%。3.9 與 AI Coding 結合以上就是我們在 AI Test 方向的實踐，后續(xù)我們計劃串聯(lián) AI Coding 和 AI Test。由 Coding Agent 生成測試目標，交由 Test Agent 對用例進行召回和生成，并完成后續(xù)的自動化測試工作。4. Agent 評測：從炫酷飛起到生產(chǎn)落地在 AI Coding 和 AI Test 中我們構建了大量的 Agent，需要一套 Agent 評測體系對它們進行評估反饋。4.1 為什么需要評測先看一張大家都很熟悉的圖，我們看別人的 Agent 時都會覺得好炫酷躍躍欲試，然后自己也開始手搓 Agent。做完后在開發(fā)環(huán)境或者小范圍測試中表現(xiàn)也不錯。發(fā)布到生產(chǎn)后，各種奇奇怪怪的情況，用戶提問的思路無法捉摸，最后還是要轉人工。我們需要知道，Agent 和傳統(tǒng)軟件不同，沒辦法列舉完整的用例來保障效果。軟件測試目標固定、標準化、可復現(xiàn)，而 Agent 評測具有不確定性、開放性（比如用戶提問）、多樣化（比如模型回答）。發(fā)布標準上，傳統(tǒng)軟件主要看功能點完成度，測試通過與否。 Agent 則需要用評測集進行多維度的指標評估。Agent 開發(fā)完并不意味著達到生產(chǎn)發(fā)布標準，應該用評測指標作為依據(jù)。4.2 評測集開始 Agent 評測，首先需要準備評測集， 評測集的類型有：有參考、無參考、參考資料三種。接著是評測集的構造，常見的方法有：人工標注、LLM 泛化、線上采樣。一個全新的 Agent 沒有線上采樣數(shù)據(jù)，我們可以通過人工標注 50-100 條的種子集，然后讓 LLM 進行泛化。評測集根據(jù)場景不同，也可以劃分為：種子集、Badcase集（一般來源于用戶反饋）、擴展集、對抗集、場景集（一般由業(yè)務場景決定）。4.3 評測器有了評測集之后是評測器，評測可以分為兩種：人工評測、自動化評測。新的 Agent 初期由于評測標準不確定，可結合人工評測，隨著調(diào)用增加，將人工評測維度沉淀為自動化評測。相較于人工，自動化評判尺度統(tǒng)一、主觀偏差少。自動化評測器包括： 托管（平臺自帶的評測器，可以快速啟動評測項目）、 自定義（自行根據(jù)業(yè)務編寫 Prompt 的裁判模型）、外部（由外部平臺/服務提供）。自動化評測器可以由 LLM 作為裁判，可以是特定的算法驗證（如 BLEU、CLIPScore等），也可以是業(yè)務邏輯驗證。評測器設計一般包括：評估步驟、打分標準、推理指令、少樣本提示(正例/反例)、邊界案例、基于業(yè)務的判斷要點(如合規(guī)、醫(yī)療等場景)。評測打分用 0-5 分制歸一，可以兼顧可解釋性和區(qū)分度，讓不同評測維度可以橫向對比。另外，為裁判模型添加 CoT 可以提升可解釋性、一致性，便于后續(xù)人工分析和優(yōu)化。4.4 評測指標接著是評測指標的設定，首先需要先明確評測主體，可以是：基礎模型、提示詞版本、工具版本、召回的記憶等。圍繞主題設定評測指標，通常有四類：效果指標、技術指標、用戶指標、業(yè)務指標。另外裁判模型自身需要有評測指標：人工一致性， 衡量模型評分與人工標注結果的一致程度；評分方差，衡量模型打分的穩(wěn)定性；異常打分率；4.5 反饋系統(tǒng)除了人工評測、自動化評測外，生產(chǎn)中用戶真實的反饋至關重要。能夠幫助我們發(fā)現(xiàn) Agnet 在實際應用中遇到的各種邊界場景和潛在問題。一般有兩種方式：顯示反饋：需要用戶明確操作(點贊/點踩)反饋，意圖明確但反饋率較低；隱式反饋：是用戶使用流程中的行為數(shù)據(jù)，被采集并解釋為反饋，可以獲得較高反饋率，比如 AIGC 生成多張圖片時，用戶選用其中一張圖；對于反饋率低的問題，通過預設標簽來減少用戶行動成本，通過預設高評分來增加用戶反饋意愿（人們更傾向吐槽而非夸贊）。4.6 評測體系以上這些組合在一起構成了我們完整的評測體系。項目啟動：由專門的評測人員和項目組成員，共同設定評測維度、創(chuàng)建評測器、建立種子集、泛化評測集，基于評測不斷迭代/驗證/反饋 Agent；開發(fā)過程：在 Agent 迭代過程中，通過評測集和評測器進行線下實驗；生產(chǎn)環(huán)境： Agent 會產(chǎn)生日志和反饋，日志會通過評測器進行線上評測，Trace 可采樣沉淀到評測集，另外反饋的 Badcase 也會沉淀到評測集；所有Agent 發(fā)布前都需要經(jīng)過評測驗證。5. AI落地的一些經(jīng)驗5.1 AI與程序的結合首先是 AI 與程序，常見構建 Agent 的模塊包括：程序計算節(jié)點、單一 LLM 節(jié)點、Workflow、Agentic。可能有些人會覺得，Agentic 比 Workflow 好，Workflow 比單一 LLM 節(jié)點好，單一 LLM 節(jié)點比程序好。從我們實踐來看，這四者之間沒有絕對的優(yōu)劣，通常需要根據(jù)業(yè)務場景進行多選和組合，其取決于場景對確定性、穩(wěn)定性、創(chuàng)造性、自主性的側重。另外，程序和 LLM 也并非替代關系，LLM 更適合理解、規(guī)劃、生成類任務，程序更適合確定性、穩(wěn)定性、高性能任務。通過程序規(guī)避 LLM 的弱項是必要的，避免過度追求 AI 含量5.2 AI與人的陷阱接著是，AI與人，需要警惕兩個陷阱：在落地 AI Coding 的過程中，出現(xiàn)開發(fā)者對 LLM 生成代碼的依賴，甚至出現(xiàn)不作判斷直接提交的情況。保持開發(fā)團隊的主觀判斷力非常必要。另外分場景追求 AI 生碼，比如核心業(yè)務邏輯人寫，非核心交由 AI 寫；在落地 AI Agent 的過程中，需要人工監(jiān)督，應該警惕人工監(jiān)督大于迭代 Agent的情況，將監(jiān)督數(shù)據(jù)用于 Agent 迭代；5.3 AI落地經(jīng)驗最后總結下 AI 落地的關鍵經(jīng)驗：區(qū)分創(chuàng)造性和執(zhí)行性工作，現(xiàn)階段 LLM 可以較好的完成執(zhí)行性工作，這類場景較為合適；落地從傳統(tǒng)研發(fā)流程切入，尋求快速出 MVP 進行單點突破；現(xiàn)階段 AI 仍需大量人參與，過程中充分考慮人機協(xié)作，比如人機交互（人好用）、知識外化（人轉化）、責任歸屬（人敢用）；同步建設私有化的 AI 基建，將行業(yè)能力與企業(yè)內(nèi)部能力串聯(lián)；Agent 的迭代不能先方案再開發(fā)，應該基于測試集和上下文工程快速試錯；最后在不同的場景分階段落地，不要一蹴而就；6. AI實踐全景以上是我們在研發(fā)全流程落地 AI 的實踐：我們通過軟件工程（Software Engineering）和上下文工程（Context Engineering），將程序與 LLM 結合；圍繞研發(fā)的設計、編碼、測試階段落地 AI 能力；過程中建設了 Agent 評測體系，不斷反饋，持續(xù)迭代；
—需求
面對面10m，我就能黑進手機，然后植入監(jiān)聽程序，獲取用戶輸入信息
