資產盤點
先知道專案使用和產生了什麼客戶資料知識、開源元件、商業服務、通用框架、專案原始碼、配置、提示、評測與賬號清單
直接回答
AI專案智慧財產權與資產歸屬
合同附件應逐項區分客戶原有資產、專案專屬成果、供應商通用能力和第三方受許可資產，並分別約定所有權、使用範圍、修改權、再許可、保密、專案結束後的返還刪除及替代方案。具體法律結論需由專業法律人員結合實際合同和許可證審查，本頁用於幫助技術與採購補齊資產清單。
SCOPE & BUDGET LEVELS
先按專案階段明確投入邊界
以下分層用於建立預算和驗收基線，實際範圍仍需結合現狀、介面與時間要求評估。
合同分類約定
為不同資產確定權利與限制所有權、使用權、修改、部署環境、商業使用、保密、再許可、費用和期限
交付與退出驗證
確保權利能夠真正落實到執行能力倉庫賬號、檔案格式、金鑰替換、獨立構建部署、資料匯出刪除和第三方替代路徑
DECISION FACTORS
做決策時需要核對的關鍵因素
先確認約束和責任邊界，再比較技術路線與合作方式。
客戶資料與業務知識
明確企業提供的文件、訂單、對話、規則和反饋僅用於何種目的，是否允許訓練及何時返還或刪除。
基礎模型和API
多數第三方模型不隨專案轉讓所有權，應明確賬號、條款、使用地區、模型變化和替代路線。
提示、規則與工作流
專案專屬配置可能決定業務效果，需要約定交付格式、修改權、版本歷史和供應商通用模板邊界。
知識庫與評測集
切分標籤、索引配置、問題答案、錯誤標註和迴歸任務集應納入專案資產與保密範圍。
應用原始碼與部署
明確前後端、介面、Agent工具、資料庫指令碼、構建檔案、基礎設施配置及二次開發權。
開源和商業元件
列明許可證、版權宣告、分發限制、席位或呼叫費用，避免專案交付後才發現無法合法商業使用。
生成內容與業務責任
約定生成結果由誰稽核、是否允許公開或商業使用，以及侵權、錯誤和合規風險的處理機制。
退出與供應商切換
確認資料匯出、賬號移交、金鑰替換、通用元件繼續授權、過渡支援和刪除證明。
溝通或評估前建議準備
客戶原有資料知識和品牌資產專案專屬原始碼配置提示和評測集供應商通用框架與預存智慧財產權模型雲服務開源商業元件清單所有權使用權修改權和商業範圍資料保留訓練返還刪除和保密賬號倉庫部署檔案及獨立復現合同結束後的遷移過渡和刪除證明
建議實施路徑
在開發開始前建立資產臺賬，並隨版本和第三方依賴持續更新。驗收時不只簽署成果清單，還要由接管人員驗證倉庫許可權、依賴許可、資料匯出和獨立部署。涉及金額較大或商業分發的專案，應由智慧財產權與資料合規專業人員複核正式條款。
DECISION WORKSHEET
把AI專案智慧財產權與資產歸屬變成可執行決策
以下工作表幫助企業把模糊諮詢整理成供應商可估算、內部可審批、專案可驗收的輸入。
客戶資料與業務知識
明確企業提供的文件、訂單、對話、規則和反饋僅用於何種目的，是否允許訓練及何時返還或刪除。
評估時要求結論附帶資料來源、責任人和待驗證項。若該因素仍不確定，應安排診斷或小範圍驗證，不宜直接寫入不可變的固定總價範圍。
基礎模型和API
多數第三方模型不隨專案轉讓所有權，應明確賬號、條款、使用地區、模型變化和替代路線。
評估時要求結論附帶資料來源、責任人和待驗證項。若該因素仍不確定，應安排診斷或小範圍驗證，不宜直接寫入不可變的固定總價範圍。
提示、規則與工作流
專案專屬配置可能決定業務效果，需要約定交付格式、修改權、版本歷史和供應商通用模板邊界。
評估時要求結論附帶資料來源、責任人和待驗證項。若該因素仍不確定，應安排診斷或小範圍驗證，不宜直接寫入不可變的固定總價範圍。
一份可比較的評估摘要應包含什麼
至少整理客戶原有資料知識和品牌資產、專案專屬原始碼配置提示和評測集、供應商通用框架與預存智慧財產權、模型雲服務開源商業元件清單，同時說明當前業務量、平均處理時長、主要異常、已有系統、資料許可權、第三方依賴和上線視窗。向不同供應商提供相同版本的資料，並要求分別說明假設、排除項、客戶配合事項、交付物和驗收證據，才能避免只比較一個缺少邊界的總價。
舉例來說，企業預計專案可節省每月160小時人工，但這個數字應拆成任務數量、單次節省時間、採用率和人工複核比例。若首期只有40%的使用者使用，或新流程增加了複核工作，實際收益就會明顯低於表面估算。決策時建議同時建立保守、基準和理想三種情景，並把最關鍵的假設放進PoC驗證。
供應商溝通時建議追問的四類證據
第一類是範圍證據：需求版本、業務流程、原型、介面和排除項是否一致；第二類是工程證據：類似技術是否有可檢視的架構、程式碼管理、測試、部署與故障處理方法；第三類是人員證據：實際參與者、投入階段、職責和替換機制是否清楚；第四類是交付證據：原始碼、資料、賬號、文件、培訓、質保和運維如何移交。供應商無法在投標階段提供客戶機密是正常的，但應能解釋自己的方法和可在本專案形成的證據。
內部評審時不要只看總價和承諾週期。建議給範圍清晰度、關鍵依賴、團隊能力、驗收可執行性和長期接管分別評分，並記錄每個分數的依據。若某方案價格更低，卻把介面、遷移、測試或上線責任排除在外，應先換算成相同交付口徑再比較。
判斷原則
本頁提供的是決策框架，不構成固定報價或效果承諾。真正可靠的結論需要結合企業資料、真實樣本、系統約束和責任邊界，由業務與技術負責人共同確認。
FAQ
FAQs
把合作前最常見的問題提前說明清楚。
使用第三方大模型後客戶能擁有模型嗎？+
通常不能。客戶擁有的是自身資料、專案應用和合同約定的專屬成果；基礎模型的權利與使用限制由模型供應商條款決定。
提示詞是否一定屬於客戶？+
沒有自動統一答案，應區分客戶業務規則、專案專屬提示和供應商通用模板，並在合同中明確交付和使用範圍。
開源元件會影響商業化嗎？+
可能。不同許可證對修改、分發、SaaS和原始碼開放要求不同，且依賴鏈可能包含多種許可，需要形成清單並審查。
交付原始碼為什麼仍可能無法接管？+
如果缺少構建依賴、模型賬號、提示配置、知識流水線、資料庫、金鑰替換、部署檔案和許可證，原始碼本身不足以恢復完整系統。
DECISION FAQ
檢視全部265個問題 →與當前專案相關的常見問題
軟體專案啟動與方案選擇
簽訂保密協議後再提供需求資料可以嗎？
可以。涉及商業模式、客戶資料、原始碼、裝置引數或未公開產品時，可以先簽雙向保密協議，再分級提供資料。保密協議不應阻止基本供應商篩選，企業可以先提供脫敏背景和目標，確認團隊能力後再開放敏感內容。資料傳輸、訪問許可權和刪除方式同樣需要管理。
檢視完整回答 →軟體專案啟動與方案選擇低程式碼、開源系統和定製開發應該如何選擇？
低程式碼適合流程明確、變化頻繁且平臺能力覆蓋較高的內部應用；開源系統適合已有成熟領域產品、可透過配置和二次開發滿足需求的場景；定製開發適合差異化流程、複雜整合、效能或產品控制要求較高的專案。選擇時要比較三到五年的總成本和退出能力，而不只看首期價格。企業也可以採用組合路線，讓不同技術承擔最適合的業務邊界。
檢視完整回答 →合同、付款、變更與專案交付軟體專案驗收需要準備哪些資料？
驗收資料應覆蓋需求、設計、程式碼、測試、部署、資料、賬號、培訓和遺留問題。功能清單只是其中一部分，還要檢查介面、許可權、安全、效能、遷移、備份和回退。每項結論應關聯可執行樣本或測試證據。資料的目標是證明系統達到約定標準，並使客戶能夠繼續運營和接管。
檢視完整回答 →合同、付款、變更與專案交付軟體專案延期了，甲方應該怎麼處理？
先停止只追問完成百分比，要求團隊提供可執行成果、剩餘工作、風險和依賴清單。區分是範圍增加、客戶配合、技術問題還是供應商管理導致延期。基於事實重新制定可驗收的恢復計劃，並凍結非關鍵新增需求。若團隊無法恢復透明交付，應及時保全程式碼、資料和賬號並評估接管。
檢視完整回答 →