作者 |梵高先生

小編 | 不吃豬頭肉

引言：AI 的機遇與挑戰(zhàn)
自從 ChatGPT 橫空出世以來，人工智能似乎一夜之間變得無處不在。在日常使用中，我們常常在驚艷與失望之間徘徊：它有時能展現(xiàn)出令人驚嘆的能力，洞察深刻、對答如流，有時卻又犯下令人哭笑不得的錯誤。正如 ChatGPT 官方頁面的警示語所說：“ChatGPT 也可能會犯錯。請核查重要信息?！?這提醒我們，盡管 AI 技術(shù)突飛猛進，但要將其轉(zhuǎn)化為實際生產(chǎn)力，還需要深入的思考和探索。
在工程領(lǐng)域，特別是汽車電子測試這樣的專業(yè)領(lǐng)域，我們更需要理性地看待 AI 的能力。不同于日常的聊天問答，工程領(lǐng)域?qū)ぞ叩目煽啃?、穩(wěn)定性和可預(yù)測性有著極高的要求。那么，在這樣的專業(yè)領(lǐng)域中，什么樣的 AI 應(yīng)用才是真正有價值的？AI 又該如何與現(xiàn)有的工作流程深度融合，真正幫助工程師提升工作效率？這些都是我們需要認真思考的問題。
今年初，我們給小北同學(xué)已經(jīng)配上了AI智能助理PiHoo，看看他們配合得怎樣了？

汽車電子測試的復(fù)雜性與 AI 應(yīng)用機會
汽車電子測試是一個專業(yè)性強、流程復(fù)雜的領(lǐng)域。從測試項目啟動開始，工程師們就要經(jīng)歷一系列嚴謹而復(fù)雜的工作環(huán)節(jié)：首先需要深入分析需求文檔，制定相應(yīng)的測試策略；繼而設(shè)計測試用例并組織評審；之后要搭建和配置測試環(huán)境，開發(fā)測試腳本；最后是執(zhí)行測試，進行問題分析，生成測試報告，并對測試結(jié)果進行驗證確認。每一個環(huán)節(jié)都需要專業(yè)的知識和豐富的經(jīng)驗，任何一個環(huán)節(jié)的疏漏都可能影響最終的測試質(zhì)量。
在這些復(fù)雜的工作流程中，AI 可以作為工程師的得力助手，在多個關(guān)鍵環(huán)節(jié)發(fā)揮重要作用。
在測試需求分析階段，AI 可以輔助處理和解析復(fù)雜的需求文檔，幫助工程師提取關(guān)鍵的測試點，識別需求中潛在的風(fēng)險。當(dāng)進入測試用例設(shè)計階段，AI 能夠推薦合適的測試場景，輔助生成基礎(chǔ)的測試用例，并提供測試覆蓋度分析，幫助工程師確保測試的完整性。在測試腳本開發(fā)階段，AI 可以顯著提升效率：它能夠根據(jù)測試用例自動生成測試腳本框架，提供代碼補全和優(yōu)化建議，輔助識別潛在的代碼缺陷。在腳本調(diào)試過程中，AI 可以分析執(zhí)行日志，輔助定位問題，并給出修復(fù)建議。這可以加快開發(fā)速度。到了測試執(zhí)行階段，AI 的價值同樣顯著。它可以協(xié)助優(yōu)化測試執(zhí)行策略，生成部分測試數(shù)據(jù)，在發(fā)現(xiàn)異常時及時預(yù)警。測試完成后，AI 還能分析測試日志，對問題進行分類，并協(xié)助生成規(guī)范的測試報告，提升測試后期工作的效率。通過在這些特定環(huán)節(jié)中融入 AI 能力，可以顯著提升工程師的工作效率，減少重復(fù)性工作。
然而，要真正實現(xiàn)這些目標(biāo)，我們必須首先正視當(dāng)前 AI 技術(shù)面臨的幾個主要挑戰(zhàn)。

當(dāng)前 AI 在工程領(lǐng)域面臨的主要挑戰(zhàn)
1. 自然語言的固有局限
人們常說，被誤解是表達者的宿命。這源于自然語言與生俱來的模糊性和不確定性。正是因為這個原因，在工程領(lǐng)域，人們發(fā)明了各種專門的語言，如編程語言和建模語言等，以降低信息傳達過程中的不確定性。然而，當(dāng) AI 來處理這些自然語言時，同樣會面臨理解偏差的問題。為了確保 AI 能夠準確理解輸入文本中表達的意圖，我們必須建立完善的機制，比如增加評審和測試環(huán)節(jié)，以驗證 AI 的理解是否與人類的預(yù)期相符。這種驗證機制不僅是對 AI 輸出的把關(guān)，更是確保整個工作流程可靠性的重要保障。
2. 復(fù)雜圖表處理能力不足
在汽車電子測試領(lǐng)域的需求文檔中，各種專業(yè)術(shù)語和復(fù)雜圖表是不可或缺的表達方式。然而，當(dāng)前的大語言模型（LLM）最擅長處理的是純文本數(shù)據(jù)，即便具備了多模態(tài)處理能力，要完全理解工程領(lǐng)域中那些專業(yè)的、復(fù)雜的圖表依然是一個巨大的挑戰(zhàn)。為了解決這個問題，需要精心設(shè)計處理流程，將LLM 不擅長處理的信息轉(zhuǎn)換為它能夠理解的純文本格式，如 JSON 或 Markdown 等。但任何轉(zhuǎn)換過程都不可避免地會造成信息損失，因此在設(shè)計這樣的處理流程時，必須考慮如何控制信息損失，并建立有效的異常提示機制，確保在關(guān)鍵信息可能丟失時及時警示用戶。
3. 上下文長度限制
上下文長度的限制是當(dāng)前大語言模型面臨的一個顯著瓶頸。例如 32k token 的上下文長度，換算成英文文本大約是 50～100 頁左右，這其中還沒有考慮連續(xù)對話占用的空間。在實際工程應(yīng)用中，需求文檔動輒幾百上千頁，遠超模型的處理能力。需要對文檔進行分段處理，但這又帶來了新的挑戰(zhàn)：在一份完整的工程需求文檔中，不同段落之間存在著復(fù)雜的互相引用和依賴關(guān)系。簡單的分段處理可能導(dǎo)致 AI 無法完整理解某個需求片段的完整語境。因此，所需要的預(yù)處理機制，在保證每個片段長度適中的同時，還要能為 AI 提供充分的上下文信息，使其能夠準確理解每個需求片段在整體系統(tǒng)中的位置和意義。
4. 幻覺問題
大語言模型的"幻覺"問題，即模型生成看似合理但實際錯誤的內(nèi)容，這在工程應(yīng)用中是不能接受的。當(dāng)我們把 AI 視為一種工程工具時，如果這個工具本身無法檢測或預(yù)防可能出現(xiàn)的錯誤，使用它將會帶來難以預(yù)估的風(fēng)險。在汽車電子測試這樣對可靠性要求極高的領(lǐng)域，AI 的每一個輸出都可能影響到測試的質(zhì)量和結(jié)果的可靠性。因此就必須建立一套輸出驗證和監(jiān)控機制，根據(jù) AI 輸出結(jié)果的影響程度和范圍，設(shè)置相應(yīng)的驗證流程和質(zhì)量控制門檻，確保每一個 AI 的輸出都經(jīng)過充分的驗證和確認。
5. 專業(yè)知識體系的局限
當(dāng)前的大語言模型雖然經(jīng)過了海量數(shù)據(jù)的訓(xùn)練，但在特定專業(yè)領(lǐng)域的知識掌握仍然不夠深入和系統(tǒng)。在汽車電子測試領(lǐng)域，存在大量的專業(yè)標(biāo)準規(guī)范（如 ISO 26262、ASPICE 等）、測試方法論和最佳實踐，這些專業(yè)知識往往需要多年的實踐和積累才能真正掌握。AI 在處理這些專業(yè)問題時，可能會出現(xiàn)理解片面或者無法準確把握具體場景需求的情況。因此，在應(yīng)用 AI 工具時，我們需要建立專門的行業(yè)知識庫來增強 AI 在特定領(lǐng)域的專業(yè)能力。
6. 工具鏈集成的挑戰(zhàn)
汽車電子測試領(lǐng)域已經(jīng)形成了一套成熟的工具鏈生態(tài)，包括需求管理工具、測試用例管理系統(tǒng)、自動化測試平臺、缺陷跟蹤系統(tǒng)等。要讓 AI 真正發(fā)揮作用，就必須能夠與這些既有的工具鏈無縫集成。然而，不同工具之間的數(shù)據(jù)格式、接口協(xié)議可能存在差異，如何讓 AI 能夠準確理解和處理這些工具產(chǎn)生的數(shù)據(jù)，如何確保 AI 的輸出能夠被這些工具正確接收和使用，都是需要解決的技術(shù)難題。

結(jié)語
在汽車電子測試這樣的專業(yè)工程領(lǐng)域，我們需要的顯然不是一個簡單的聊天機器人。工程師們需要的是一個可靠的、值得信賴的問題解決工具。這個工具的輸出必須是穩(wěn)定、一致且可預(yù)期的 —— 我們不期待它帶來任何“驚喜”，更不能容忍“驚嚇”。即便它每次只能給出 60 分的結(jié)果，我們也希望它能保持這個水準，而不是時而 40 分，時而又達到 80 分。同時，這個工具必須具有清晰明確的能力邊界，能夠識別出什么是它可以勝任的，什么是超出其能力范圍的。更重要的是，它需要具備完善的錯誤檢測機制，在出現(xiàn)問題時能夠及時向用戶發(fā)出警示。只有同時滿足這些要求，AI 工具才能真正在工程實踐中發(fā)揮其價值，成為工程師可靠的助手。
作為深耕汽車電子測試領(lǐng)域十余年的專業(yè)咨詢公司，北匯信息對 AI 技術(shù)保持開放的態(tài)度。我們將充分發(fā)揮在汽車電子測試領(lǐng)域的專業(yè)優(yōu)勢和豐富經(jīng)驗，探索 AI 技術(shù)與傳統(tǒng)測試服務(wù)的融合。