1. 從畫筆到代碼一個美術生的“甲方”初體驗“當甲方很快樂”這句話在項目群里通常是程序員們帶著復雜心情發出的調侃。但作為一個純正的美術生我從未想過有一天這句話會從我嘴里說出來而且是在一個涉及AI、AR和智能眼鏡的“硬核”技術項目里。這一切發生在短短五個小時內。我的專業是視覺傳達日常就是和PS、AIAdobe Illustrator此AI非彼AI、數位板打交道。代碼對我而言就像是另一種語言寫的天書。然而公司最近接了一個為大型倉儲物流中心做概念驗證的活兒核心是探索AI眼鏡在倉庫揀貨與盤點中的應用。團隊里懂算法的同事被另一個緊急項目抽走老板看著我桌上最新款的AR眼鏡原型機半開玩笑地說“你審美在線又最懂用戶體驗要不……你試試用現在那些‘低代碼’、‘AI開發’平臺把咱們之前討論的那個AR導航疊加AI識別的Demo搭出來就模擬一下從A區到B區路上識別貨箱并高亮顯示目標貨箱這個流程。”我當時的第一反應是老板你認真的嗎讓我一個畫畫的去搞AI開發但看著他那“我相信你可以”的眼神以及“反正就5小時搞不出來也沒關系就當熟悉下新技術”的免責聲明我硬著頭皮接下了這個“甲方”任務——畢竟這次的需求方是我自己。我的武器庫只有一臺電腦一些關于“低代碼”、“AI應用開發”、“AI Agent”的網絡搜索記錄以及一顆不想認輸的心。接下來的五小時是一場從茫然到興奮從絕望到狂喜的極限過山車。我發現當技術門檻被極大地降低當“開發”從寫代碼變成拖拽、配置和與AI對話一個創意者所能爆發出的能量超乎想象。這不是一個嚴謹的教程而是一個“外行”用最野路子在5小時內征服多個技術概念的奇遇記錄里面充滿了誤打誤撞的驚喜和哭笑不得的坑。2. 開局一頭霧水在“低代碼”與“AI開發平臺”的迷宮中定位坐在電腦前第一個問題就來了從哪開始我知道關鍵詞是“低代碼”和“AI開發平臺”。但搜索之后我陷入了更深的困惑。阿里云宜搭、騰訊云微搭、還有各種我聽都沒聽過的“斑斑低代碼”、“前幾年搞低代碼平臺的創業公司”……它們看起來都像是我需要的但又似乎完全不同。2.1 理解“低代碼”與“AI開發平臺”的本質區別我的第一個重大認知糾偏是弄明白了“低代碼”和“AI開發平臺”雖然常被一起提及但核心解決的是不同問題。這花了我將近半小時閱讀和對比。低代碼平臺它的核心是“快速構建應用”尤其是企業管理類應用OA、CRM、ERP等。它通過圖形化拖拽組件如表單、按鈕、表格和配置業務邏輯流來替代傳統的編寫大量基礎代碼。比如我想做一個倉庫入庫單審批流程用低代碼可能只需要拖一個表單設計器、連一個審批人節點、再配置一下數據庫字段就完成了。它關注的是業務流程的數字化和自動化。搜索時看到的“低代碼平臺中的視圖模型”、“柱狀圖自動彈出數能不能給關了”這些問題都非常“業務系統”離我的“AIAR”場景有點遠。AI開發平臺它的核心是“賦能AI能力”讓開發者甚至非開發者能夠更容易地使用、微調或部署人工智能模型。它提供的是像視覺識別、語音交互、自然語言處理、智能決策Agent這樣的能力。比如我想讓我的應用能識別貨箱上的文字就需要調用某個AI開發平臺提供的OCR文字識別API。它關注的是智能能力的集成與調用。我的項目呢既要“應用”一個能跑在AR眼鏡里的界面和邏輯又要“AI”識別貨箱。所以我需要的可能不是一個單純的平臺而是一個組合方案用某個相對靈活的應用開發工具可能是輕量級低代碼也可能是更偏向前端的框架搭建AR眼鏡的應用界面和基礎邏輯同時接入一個AI開發平臺提供的視覺識別服務。2.2 我的野路子選型邏輯時間緊迫容不得我系統學習。我的選型原則變得非常功利能否快速上手文檔是否清晰有沒有現成的模板或Demo社區是否活躍是否支持AR眼鏡我的目標設備是特定的AR眼鏡比如Rokid、RealWear或微軟HoloLens平臺或方案是否需要特殊的SDK或適配AI能力接入是否方便能否以最簡單的方式比如一個API調用接入我需要的圖像識別功能基于這三點我排除了那些需要復雜企業賬號申請、專注于內部流程管理的重型低代碼平臺。我也暫時擱置了需要從零學習Python或Java去訓練模型的“AI大模型開發”路線。我的目光投向了兩類產品面向AI應用的原型工具例如一些國內的AI應用開發平臺它們提供了將AI模型如對話、識別封裝成可交互應用界面的能力有時甚至支持簡單的邏輯編排。跨平臺前端框架云AI服務例如使用Unity對游戲引擎它其實對美術很友好或React Native這類工具開發一個簡單的AR應用界面然后通過HTTP請求調用像阿里云、百度云或騰訊云提供的、開箱即用的視覺識別API。最終我選擇了一條“縫合怪”路線用一個對設計者友好的交互原型工具類似Figma但能輸出真機可運行代碼的進階版快速搭建UI和頁面流同時在工具里用“自定義代碼”模塊調用一個提供免費試用額度的云AI服務API。這樣我就能在5小時內看到一個“有形且能動”的東西。3. 五小時極限沖刺拆解“AR導航AI識別”Demo目標明確了做一個在AR眼鏡屏幕上顯示虛擬箭頭指引同時攝像頭掃描到目標貨箱時能在其周圍顯示高亮框的Demo。3.1 第一步構建靜態場景與UI用時1.5小時作為美術生這是我的舒適區。我打開選定的原型工具假設它叫“CoDesign”。創建場景我導入了倉庫的簡單平面圖作為背景。繪制UI元素導航箭頭一個簡單的3D箭頭模型我設置它的初始狀態為隱藏。信息面板一個半透明的浮動面板用于顯示當前任務如“前往B-12區”和識別結果。高亮框一個紅色的矩形線框用于標記識別到的目標貨箱。設置頁面流我設計了兩個主要“狀態”。狀態一導航中。信息面板顯示“正在前往B-12區”導航箭頭根據預設路徑我簡單模擬了從A點到B點的直線動態更新位置和旋轉角度指向下一個拐點。這里我用到了工具的“動畫”和“智能動畫”功能通過關鍵幀來模擬移動而不是真寫代碼計算路徑。狀態二識別到目標。當觸發“識別”事件我暫時用一個手動按鈕模擬后信息面板內容切換為“已定位目標貨箱B-12-05”高亮框顯示在屏幕中央的某個位置模擬攝像頭捕捉到的位置。注意這里最大的“坑”是坐標系統。AR眼鏡的屏幕坐標2D和現實世界坐標3D的映射在真正的開發中需要SLAM同步定位與地圖構建技術。為了Demo我粗暴地假設攝像頭畫面就是屏幕目標貨箱出現在畫面固定位置。這是美術生思維的“取巧”也是原型與產品的巨大鴻溝。3.2 第二步接入AI識別能力用時2小時這是最讓我頭疼也最終帶來最大驚喜的部分。我需要讓應用能“看懂”攝像頭畫面里的貨箱。尋找合適的AI服務我搜索了“AI視覺識別 API 免費試用”找到了幾家大廠的服務。對比后選擇了一家因為它有清晰的“物體檢測”API文檔且每天提供一定次數的免費調用。理解API調用文檔里通常有一個curl命令示例。我看不懂但工具的模式讓我只需要關注幾個關鍵點Endpoint請求地址一個URL。Header請求頭里面要包含一個叫Authorization的東西值是Bearer你的API_Key。這個Key在注冊平臺后就能獲得。Body請求體我需要把圖片數據傳過去。文檔說可以傳圖片的URL或者直接傳圖片的base64編碼一種把圖片變成一長串文本的方法。在原型工具中“拼裝”我在“識別”按鈕的點擊事件上添加了一個“HTTP請求”動作。按照文檔填好URL。在Headers里添加Authorization: Bearer sk-my-test-key-123456示例。最麻煩的是圖片。我沒有真實的攝像頭流。于是我又“作弊”了我預先準備了幾張包含不同貨箱的倉庫照片上傳到圖床獲得URL直接把URL作為請求參數固定寫死。或者更“動態”一點我讓工具在點擊按鈕時自動將當前屏幕截圖模擬攝像頭畫面轉換成base64然后填到請求體里。這個“截圖轉base64”功能居然在工具的內置函數庫里找到了處理返回結果API的返回是一段JSON數據對于美術生來說這就像一段結構化的文字描述。它可能長這樣{ code: 0, msg: success, data: { objects: [ { label: cardboard_box, score: 0.95, bbox: [120, 80, 300, 400] // 代表框的左上角x,y和右下角x,y坐標 }, // ... 可能還有其他識別到的物體 ] } }我需要從這個JSON里取出label是cardboard_box紙箱且score置信度最高的那個對象的bbox坐標。讓高亮框動起來工具提供了“解析JSON”的功能。我設置了一個變量target_bbox來存儲解析到的坐標[120, 80, 300, 400]。然后將高亮框組件的位置和大小屬性綁定到這個變量。當API返回數據并解析后高亮框就自動跳到了對應的屏幕位置。當點擊按鈕看到高亮框真的根據“AI識別結果”移動到圖片中貨箱的位置時那種感覺難以言喻——我一個美術生沒有寫一行傳統意義上的代碼卻讓AI聽我指揮了。3.3 第三步串聯邏輯與模擬數據用時1小時現在我有了一堆散落的“積木”會動的箭頭、會跳的框、一個能調AI的按鈕。我需要把它們連成一個完整的故事。狀態管理我設置了兩個全局變量app_state值為navigating或identifying和target_position存儲高亮框坐標。邏輯串聯應用啟動app_state “navigating”導航箭頭開始動畫。我模擬了一個“到達目標區域”的事件比如一個倒計時結束或者手動點擊一個“已到達”按鈕。觸發后app_state “identifying”導航箭頭隱藏信息面板更新為“開始掃描貨箱...”。用戶演示者點擊“識別”按鈕觸發HTTP請求獲取AI結果更新target_position高亮框顯示。同時信息面板更新為“目標貨箱已高亮”。打磨與模擬為了演示更流暢我預設了幾組不同的target_position坐標和對應的貨箱圖片在點擊“識別”時隨機輪換模擬識別到不同貨箱的效果。我還給所有狀態切換加上了簡單的淡入淡出動畫。4. 踩坑實錄理想與現實的差距這5小時并非一帆風順幾乎每一步都有“坑”這些坑恰恰是傳統開發中習以為常但對新手來說宛如天塹的細節。4.1 網絡請求的異步之殤我最初以為點擊按鈕 - 調用API - 立刻更新界面是一條直線。實際上網絡請求是“異步”的。意思是點擊按鈕后程序說“我去發個請求”然后就繼續往下執行了不會傻等結果。這導致我的高亮框總是在AI結果回來之前就試圖用一個空的位置坐標去更新然后報錯。解決方案在工具的HTTP請求動作配置中我找到了“成功回調”和“失敗回調”。我需要把“更新高亮框位置”和“更新信息面板”這兩個操作從主流程里拖出來塞進“成功回調”函數里。這意味著只有API成功返回數據后這些界面更新才會發生。這是我學到的第一個重要的編程概念——異步回調。4.2 坐標系統的轉換陷阱我成功讓高亮框在屏幕上跳了起來但很快發現不對。AI API返回的bbox坐標[x1, y1, x2, y2]通常是基于輸入圖片的像素坐標系。而我的UI組件的位置可能是基于屏幕百分比、絕對像素值或者是另一套相對坐標。直接賦值會導致框的位置錯亂。解決方案我需要一個轉換函數。比如API返回的坐標是基于800x600的圖片而我的AR眼鏡屏幕分辨率是1920x1080。那么高亮框的左邊距應該是(x1 / 800) * 1920。我在工具的自定義代碼區域寫了一個簡單的JavaScript函數來做這個比例換算。這讓我意識到數據格式和坐標系的統一是集成不同模塊時最瑣碎也最關鍵的一步。4.3 AI模型的“偏見”與局限我用自己網上找的倉庫圖片測試識別率不錯。但當我興沖沖地想用手機拍一下辦公室的紙箱試試時識別結果要么是“椅子”要么置信度很低。這是因為云服務提供的通用“物體檢測”模型是在海量通用數據集COCO等上訓練的它對“在倉庫環境下的、特定擺放角度的、貼有復雜標簽的貨箱”特征學習不足。解決方案對于真正的項目這條路走不通。要么1使用該AI平臺提供的自定義模型訓練功能上傳幾百張自己倉庫的貨箱圖片進行微調要么2尋找行業垂直的、專門針對物流倉儲場景優化過的AI服務商。這遠遠超出了5小時Demo的范疇但它點明了AI應用落地的核心現成的通用模型往往不夠用領域定制化是關鍵。4.4 性能與真機部署的鴻溝我的Demo在原型工具的預覽窗口里跑得很流暢。但我知道這只是“預覽”。一旦要打包成真正的應用部署到AR眼鏡通常是Android系統上問題會接踵而至HTTP請求的延遲在移動網絡下是否可接受連續調用API的電量和流量消耗如何UI動畫在真機上是否依然流暢原型工具生成的代碼是否足夠優化這些我都沒有答案。這個Demo的價值在于快速驗證想法和交互邏輯在于讓業務方甚至是我自己在投入大量工程資源前看到一個“活”的、可交互的概念。它是一個溝通工具一個設計驗證工具而非一個產品原型。5. “甲方”的快樂與思考低代碼/AI開發平臺改變了什么五小時到點我向老板展示了一個可以點擊交互、有動畫、能“調用AI”識別圖片并高亮目標的AR應用原型。雖然它漏洞百出離真正可用差十萬八千里但所有人都震驚了。一個美術生在這么短的時間內竟然串起了一條從UI設計、邏輯編排到AI能力調用的完整鏈路。這種“甲方”的快樂源于以下幾點創意的快速具象化我不再需要先花幾周學習編程再和工程師反復溝通需求、等待排期。想法可以直接變成可交互的東西。這極大地壓縮了從“點子”到“原型”的路徑讓創意驗證變得極其高效。對核心邏輯的聚焦我不必糾纏于內存管理、線程同步、網絡框架等底層技術細節。我可以把幾乎全部精力都放在業務邏輯和用戶體驗上導航箭頭該怎么動更自然識別結果如何展示更清晰狀態切換的動畫怎么才不突兀這讓我這個“產品設計師”的角色得以真正貫穿始終。與技術的平等對話當我拿著這個Demo去和后來的工程師溝通時我不再說“我想要一個能識別貨箱的功能”而是說“你看我在這里調用了這個API它的返回格式是這樣的但我需要你把坐標轉換一下并且考慮一下網絡延遲時的加載狀態”。溝通效率提升了不止一個量級。當然狂喜之后是冷靜的思考。這5小時的奇遇并不能讓我轉型為AI開發工程師。它揭示的是一種新的生產范式而非職業的替代。對于中小企業或初創團隊正如熱搜詞里提到的“缺資金、缺人才、缺技術”這類低代碼/AI開發平臺極大地降低了創新試錯的門檻。你可以用極小的成本快速驗證一個涉及AI或復雜邏輯的產品創意拿到投資或內部支持后再投入專業力量進行工業化開發。對于專業開發者這不是威脅而是生產力的解放。平臺生成的代碼或搭建的應用往往可以作為高質量的“腳手架”或“前端原型”。開發者可以專注于更底層的算法優化、性能調優、系統架構和定制化深度開發把重復性的、標準化的界面和業務邏輯搭建工作交給工具或更廣泛的“公民開發者”。對于像“AI Agent”這樣的前沿概念這些平臺可能成為構建和測試Agent工作流的絕佳沙盒。你可以用圖形化的方式編排Agent的感知、決策、行動鏈條快速驗證其在不同場景下的有效性而無需先搭建復雜的技術環境。回到最初的問題AI開發用Java還是Python需要哪些技術棧對于想從事專業AI應用開發的人來說這依然是核心問題。Python在算法原型和數據處理上優勢明顯Java在大型企業級后端服務中地位穩固。你需要數據結構、算法、機器學習基礎、至少一門主力語言、框架知識等等。但我的5小時經歷說明了另一條路如果你是一個業務專家、產品經理、設計師或者是一個資源有限的創業者你的目標不是成為算法科學家或架構師而是快速將AI能力與具體業務場景結合創造價值。那么熟悉幾個主流的低代碼/AI開發平臺理解它們的能力邊界和集成方式學會“像甲方一樣思考并快速驗證需求”可能是一項比精通某種編程語言更立竿見影的技能。這五個小時我并沒有學會寫代碼但我學會了如何“駕駛”一套強大的工具去實現我的創意。當技術的大門以這種方式打開快樂確實屬于每一個能清晰表達需求的“甲方”。