“動嘴”開發一個軟體後，我對AI時代的產研工作的認知

在AI技術飛速發展的今天，軟體開發的門檻正在被逐步降低。本文作者作為一名非計算機專業的產品經理，透過親身體驗，利用AI程式設計工具（如Deepseek和Trae）嘗試開發一款簡易的APS排程軟體，記錄了從需求提出到軟體完成的全過程。

———— / BEGIN / ————

作為一個非計算機專業的產品經理，雖然我沒有任何程式碼基礎，不懂程式設計，但是常年在產研團隊中工作，對程式設計和開發工作極度渴望，是程式設計師升職記、while true:learn等遊戲的忠實玩家，有時遇到自己感興趣的產品想法會有動手開發的衝動，但是礙於不會程式設計，不得不放棄。自從去年夏天cursor爆火之後，我開始跟著網上的大佬嘗試應用AI程式設計工具。

寫這篇文章記錄最近的一次AI程式設計嘗試，利用AI程式設計工具開發一款簡易的APS排程軟體，驗證一下目前的AI程式設計工具能否實現“動嘴”開發。同時在這次嘗試的過程中，對產研團隊的工作方式，產品經理的職業發展有了新的認知。

“動嘴”開發的過程

軟體的基本邏輯如下：

基本的資料包括產品、工藝、訂單，透過這些資料，可以得出生產所需要的各生產工序以及工作量（包括工序之間必要的約束關係）
規劃資源包括員工和裝置，員工具有不同的技能屬性，支援匹配的工序任務，裝置同理
規劃求解機制，程式能夠使用一定的演算法在符合所有約束條件的情況下，規劃工序任務、分配規劃資源，得出一個近似最優（時間、人力、裝置等等）的排產方案

這次開發的過程被分為了準備、編碼、測試、打包幾個階段，主要使用了線上的deepseek R1以及Trae，因為Trae最新的Claude-3.7-Sonnet模型每次請求都需要排很久的隊所以這次只使用了Claude-3.5-Sonnet和Deepseek-Reasoner（R1），預測使用Claude3.7模型開發效果會更好。

準備

因為在考慮開發這個軟體之前就已經對軟體的大致框架、功能邏輯有了基本的設計，所以這次嘗試跳過了設計階段直接開始準備開發。

準備階段我主要使用的是deepseek R1，在提供了基本的業務背景、業務目標、功能邏輯以及我當前的開發環境等資訊後，deepseek R1根據我的情況提供了技術選型方案、大致的開發步驟以及避坑指南。

這裡要非常感謝Deepseek的建議，因為在它的建議下使用了git，開發過程中程式碼可以回滾，避免了幾次重大問題。

核心語言我選擇了python、GUI框架選擇了Tkinter，檔案處理選擇了json。

接著，我在Trae的Builder模式下輸入大致的業務背景以及剛才生成技術選型的結果，提交之後，Builder開始幫我檢查本地是否正確安裝了開發所需的依賴環境，在運行了幾個指令之後，確認了當前我本地的開發環境，並幫我安裝了幾個必要的庫。

接下來，就可以開始編碼了（如果使用cursor的內容以及提前確定的設計、開發規範都可以透過rules提供給AI）。

編碼、測試、打包

目前一次性讓Claude-3.5-Sonnet完成整個相對複雜的程式開發是不現實的，並且在看不懂程式碼的情況下我需要即時驗證程式是否符合預期；所以，我把整個開發過程拆分成了介面搭建、資料維護功能搭建和規劃求解功能搭建三個步驟，增量式地完成軟體開發。

第一步，介面搭建

我們根據功能需要描述出軟體的介面框架和模組結構，很快它就完成了主介面、主選單、功能模組的搭建。

第二步，資料維護部分

需要描述每個模組資料的基本屬性和增、刪、改、查的規則，我們分不同的模組描述了基本的資料結構的大致規則，程式都按照要求編寫出了對應的資料維護功能，除錯執行，功能正常。

前幾個模組描述得足夠詳細，後面幾個模組在描述得時候就可以放飛了，簡單介紹下大致內容它就會根據類似的規則編寫出我們想要的標準功能。

到這裡，讓它統計一下，我們花了大約1個小時已經寫出了2850行程式碼，我們先在git上提交了這部分程式碼。

編碼最後一步，規劃求解，相比前面的步驟會稍複雜一些，首先嚐試了直接描述模組的功能和大致規則。

結果正如預測，程式執行失敗，出現了大量的報錯，我們試著將這些報錯發給builder讓它進行修復。

但是，經過幾輪修復後仍然沒有解決問題；於是，我們改變策略，回退程式碼，再次把內容拆分。

我們把排程的過程拆分為了：生成排程任務、任務分配、衝突檢查三個部分，分步實現每個功能，這次雖然部分情況下仍然出現報錯，但是基本讓它排查一次都能修復，經過十幾輪對話後，基本功能搭建好了。

但是此時生成的結果是表格形式的，所以，又花了幾輪對話，把排程結果改為了甘特圖的樣式，至此具有完整功能的第一版軟體開發好了。

再此版本之上，我還嘗試了讓Build更換演算法策略，改為使用之前Deepseek推薦的進化演算法，這種情況下需要強調更改過程只改演算法規則，保持頁面和互動不做改動，改動後的程式能順利執行。

在完成每個模組的功能開發後，我讓builder建立一個單元測試用例，並進行測試來驗證、確保基本功能的可用。

所有模組功能都驗證沒有問題，我們描述打包需求，讓builder幫我們選擇、安裝打包工具並執行打包命令，打包過程比較順利，至此，我們完成了軟體的開發過程。

小結一下

經過這次嘗試，可以得出結論：一般軟體開發過程中的技術選型、環境搭建、編碼、測試、打包工作，都可以使用AI完成。

作為沒有編碼技能的使用者可以透過AI工具實現自己的想法，想要開發商業級的軟體產品，操作者仍然需要具備工程師級別的程式設計經驗，AI編碼的效率提升也需要專業程式設計師來進一步評估。

但是具有豐富業務經驗的工程師能夠使用AI工具快速應用自己不熟悉的技術棧完成產品的編碼工作並不斷完善產品，同時一些高度重複機械性的編碼工作也可以讓AI代勞。如果AI程式設計技術繼續以現在的速度發展下去，未來我們也許真的會出現AI程式設計師同事。

在這次嘗試的過程中，對於產研工作尤其是產品經理的工作我產生了三個認知。

認知一，從“執行者”到“稽核人”

在這次嘗試的過程中，我和builder的主要互動模式如下：

我向它傳送需求指令
builder生成並編輯相應的程式碼檔案，在編輯器中展示每一步的修改內容並將所有的行為總結後報告給我
我進行稽核確認操作（儲存修改、拒絕修改、執行終端指令等）
編輯器執行相應操作並將終端反饋回傳給builder進行分析
builder分析需求完成情況，報告執行結果
我繼續傳送下一步需求指令

歸功於適用AI的通用通訊協議，AI能夠完成編碼工作中的主要操作，而Trae、cursor這類編輯器在集成了這種規則的同時開發了由使用者決定執行每一步操作的功能，從而形成了這種開發模式。

在這種模式下，以往程式設計師的編碼工作中很多通用的構思、大量機械的業務程式碼都能夠透過簡單的自然語言指令讓AI來實現，程式設計師從編碼的執行者變為了稽核人。

我們再延伸到產品經理：

對於產品經理的大部分工作同樣可以利用相同的技術產生類似的AI工具產品，創造AI產品助理，來和產品經理一起進行協同產品設計、文件撰寫；此時，產品經理的角色也將從執行者轉變為稽核人，此時會更多地要求產品經理具有比較強的商業敏感度、思辨能力和判斷力，在AI助理按照你的想法提供了產品方案後，你能夠根據你對產品、客戶以及業務的理解發現存在的問題，洞察到新的機會和可最佳化點做一個合格的稽核人。

認知二，產品研發流程變化

新的工具出現，讓程式設計的門檻降低，雖然我們無法直接參與到軟體程式的編寫工作中，但是工具為我們提供的程式設計能力，可以幫助我們把更多的產品想法落地到初步的demo上。

在研發資源不足以分配給團隊進行新的方向時，甚至產品經理可以自己開展“臭鼬工程”自己抽時間搗鼓出一個程式來進行前期的實驗，在得到積極的實驗反饋後，再申請相應的資源投入，這樣從想法到成功落地專案的可能性將會更高。

這樣一來，敏捷型的產品開發流程可能會演化為“非技術人員先脫離產品技術棧，構建新業務功能快速驗證成功後，再轉入開發專案衝刺”的超敏捷開發流程。

以前產品經理需要透過清晰的語言描述、產品原型圖來向相關方陳述產品方案。但是語言具有誘導性資訊傳遞過程會出現失真；高保真原型圖繪製費時費力，低保真原型圖又無法完整表達產品想法。

現在我們可以透過AI工具快速將想法轉變為基礎的產品案例，從而提升產品設計和方案驗證的效率。當然真正提升效率仍然依靠成熟可靠的AI工具和產品經理的專業性以及熟練應用工具的技能。

不過當前已經有產品經理開始使用AI程式設計工具來開發前端頁面，再將工程匯入figma來快速實現高保真產品原型的搭建工作，各大產品設計軟體也已經相繼推出AI設計的功能，這個設想應該很快就會成為普遍現實。

認知三，人性化設計的不可替代性

當AI抹平了執行的鴻溝，我們比任何時候都更需要知道：究竟要為什麼樣的價值去創造

當以上的兩個趨勢逐步成為現實後，可以預見的一個現象就是單純靠AI產出的內容會存在同質化嚴重的特點，這樣以來，產品經理角色真正的價值屬性就變成了脫離AI的洞察力。

我在這次嘗試的過程中就能夠感覺到在雖然在開發時我只需要提供相對模糊的表述，AI就可以在此基礎上進一步設計程式，補充很多可能忽略的細節，但是AI的設計始終無法脫離正規化。

目前AI的優勢在於它完成了我們普通人無法完成的知識儲備，像一個百科全書，並且已經開始具備了慢思考能力，能夠進行邏輯推理，但缺點是它始終會被禁錮在已有的知識中，根據所謂的“最佳實踐”產出內容，因而缺少創新性。並且我們都知道要想更加理解使用者，你需要的不是成為萬事通而是帶著使用者的思維去思考和體會，甚至成為使用者，這樣才能找到真正具有價值的產品機會。

我們需要能夠依靠我們對業務的理解、對使用者的敏銳洞察以及共情能力，發掘出產品價值，找到使用者的不滿、焦慮、恐懼、憤怒再借助AI工具來創造滿足使用者的產品。

所以從現在開始，在產品設計過程中，我們應該更多地去尋找我們相對於AI在人性理解中的優勢並且刻意地訓練，提高我們的敏感度，讓我們相比AI更加人性化。