Docusign AI 營運模式推動工程團隊超越工具推行
Docusign 在發現單靠提供工具存取權限，未能持續推動採用率及早期生產力提升後，擴展了其工程 AI 計劃。Docusign AI 營運模式現時以同儕支援、可重用自動化及人為問責為核心。其重要之處在於重新組織工程工作方式，而交付成果仍須以獨立證據驗證。
公司描述了一項由個人編程輔助轉向共享工作流程的變革。這種轉變為一直將軟件授權與使用量儀表板視為轉型證據的工程領導者帶來壓力。購買存取權限未能解決培訓、維護、審核能力，以及自動化變更出錯時由誰負責等問題。
Spotify 提供了一個有用的比較，因為其工程團隊同樣描述了如何將編程代理整合至現有維護系統。兩者均未能證明存在適用於所有情況的 AI 生產力公式。不過，兩者共同顯示，當生成程式碼變得更容易後，組織工作會轉移到何處：界定任務、提供背景資料、檢查結果，以及支援各團隊採用。
Docusign AI 營運模式源於採用率停滯
Docusign 的工程說明指出，其全公司編程工具推行始於 2024 年 6 月。到下一階段，活躍採用率達到 49%，而據報錄得的 18% 生產力提升已停滯。公司指出，缺乏試驗時間、針對程式碼庫的指引及實務支援，是主要障礙。
其回應是設立一支六人的中央 Champions 團隊，並安排作為 Multipliers 的工程師嵌入開發團隊之中。Docusign 表示，採用率到 2025 年 10 月已達 65%，其後在引入 Multipliers 兩個月內升至 93%。這些數字來自公司自身的 AI 採用計劃，而非獨立評估。
這項組織變革針對的，是讓工具可供使用與讓工具在日常工程工作中真正有用之間的落差。
這一分別令該案例的意義超越 Docusign 本身。存取權限解決的是採購及分發問題。日常使用則取決於工程師能否將工具應用於眼前已在等待處理的工作。
面對陌生程式碼庫的開發者，需要的不只是提示詞入門。他們需要理解本地慣例、測試要求、相依關係，以及改動特定元件的後果。當這些細節互相影響時，一般示範無法解決每一個出現的問題。
同儕支援提供了穿越這種不確定性的方法，因為隊友面對相同限制。來自同一程式碼庫工作者的建議，能提供一般工作坊無法給予的資訊。組織價值來自於在任務進行期間提供這些知識。
中央協調仍然重要。缺乏協調時，有用的做法可能仍然孤立存在，而各團隊會重複研究相類問題。嵌入式網絡需要一個渠道上報反覆出現的困難，亦需要一個機制分發改進成果。
因此，Docusign AI 營運模式代表的不只是工具變更，也包括責任分配的轉變。支援採用成為持續的工程工作。必須有人收集問題、改善共享資源，並判斷某項做法能否成功在團隊之間移植。
所報告的採用曲線支持了有關參與度的說法，卻無法證明計劃中的哪一部分導致增長。工具改進、累積經驗及任務變化，同樣可隨時間影響使用情況。
這項限制並不影響核心觀察。Docusign 描述了對 AI 周邊社交及營運條件的投資，而非在部署後止步。當讀者將這些條件與公司的主要成果分開檢視時，該案例便更具參考價值。
它亦改變了「完成」的含義。一次推行有啟動日期及分發清單。營運模式則需要持續決定擁有權、質素，以及隨著周邊軟件變化，自動化應置於何處。
工程領導者須承擔授權無法涵蓋的工作
當 AI 成為日常生產工作的一部分，工程經理便面對更廣泛的責任：他們必須支援由建議到發布的整條路徑。
即時壓力落在同時負責交付承諾及團隊健康的領導者身上。他們必須決定學習時間從何而來、誰維護共享工作流程，以及審核者如何處理額外提出的變更。這些決定會與既有工作競爭資源。
採用目標提供清晰的管理訊號，卻未能回答最困難的資源分配問題。開發者可能經常使用 AI，卻花更多時間檢查其輸出。另一位開發者可選擇性使用，並消除一個持續存在的重複性工作來源。
將這些模式視為等同，會掩蓋真正的營運決策。有用的問題是哪些任務變得更容易、誰的時間被消耗，以及改變能否經受生產要求的考驗。單靠使用頻率無法回答這些問題。
嵌入式導師亦帶來機會成本。協助同事的工程師本身也有職責。一個成功計劃需要承認這些支援工作，否則便有可能依賴一旦期限收緊便會消失的投入。
這正是同儕主導 AI 採用為規劃帶來壓力之處。若指導對交付很重要，經理便需要在分派工作時將其納入考慮。否則，計劃可能看似成本低廉，因為其勞動仍隱藏在個人的日程之中。
平台團隊面對相關挑戰。共享自動化需要文件、測試、存取控制及維護。曾配合舊有程式碼庫結構運作的工作流程，在介面或建置要求改變後可能變得不可靠。
由此產生的工作，類似維護一項內部產品。使用者需要知道自動化支援甚麼、如何回報故障，以及誰會作出回應。一位熱心的創建者並不會自動提供可持續的支援安排。
安全及可靠性團隊承擔了決策的另一部分。他們需要掌握代理可存取甚麼，以及可作出甚麼變更。AI 代理，即選擇並執行步驟以達成目標的軟件，帶來的營運問題超越其生成的文字內容。
這項組織論點與 Google 的 AI 輔助開發研究一致。DORA 的 2025 年報告將 AI 描述為既有優勢與弱點的放大器，強調底層組織系統的重要性。
這項發現支持關注工具周邊環境，但並未獨立驗證 Docusign 的成果。即使程式碼生成有所改善，擁有權不清或審核緩慢的組織，仍需要處理這些狀況。
企業買家亦應認識到相同的責任分工。供應商提供能力，而買家決定這些能力如何進入實際工作。採購部門可評估可用功能，但工程領導層必須判斷周邊組織能否負責任地使用它們。
壓力亦延伸至領導者如何傳達進展。有關廣泛使用的說法，應保持為有關廣泛使用的說法。若要將其與交付連結，便需要有關已完成工作、質素及維持變革所需資源的證據。
可重用工作流程將效益延伸至個別提示詞以外
Docusign 的工程說明描述了將自動化延伸至編程、文件撰寫、審核及問題調查。其重點由零散協助轉向連接工程活動的工作流程。更廣泛的含義在於，一項有用的實驗能否成為另一個團隊可可靠採用的成果。
只要其假設與限制仍清晰可見，可重用工作流程便能讓本地經驗在整個組織中發揮作用。
儲存在聊天記錄中的提示詞，組織層面的影響有限。其作者可能記得哪些檔案很重要、模型誤解了甚麼，以及哪個結果需要修正。只收到提示詞的同事，卻無法承接這些周邊判斷。
封裝工作流程需要將這些假設明確化。支援的任務、所需背景資料、允許的操作及預期證據，均成為另一位工程師收到內容的一部分。這項工作決定重用是減少工作量，還是僅將疑難排解轉移他處。
試想一項影響多個相關檔案的設定變更。生成修改只處理了任務的一部分。工作流程亦需要能識別相關檔案、保留數值之間的關係、執行適當檢查，並解釋尚未解決的不確定性。
這些要求令任務邊界具有經濟重要性。界定狹窄的自動化可能更易檢查及維護，因為其預期行為較清晰。更廣泛的自主性，則增加其擁有者必須預見的情況範圍。
Spotify 的 背景編程代理提供了以軟件維護為基礎的比較。2025 年 11 月，其工程師描述了如何將名為 Honk 的代理整合至現有基礎設施，並表示已合併超過 1,500 個由 AI 生成的 pull request。
pull request 是提交作審核的建議程式碼變更。計算已合併的建議，比計算已生成的建議提供更具體的生產訊號。然而，這仍留下任務難度、審核工作量，以及沒有自動化時會發生甚麼的問題。
這個比較突顯基礎設施是實際優勢的來源。Spotify 描述了如何建基於現有維護系統。Docusign 則描述了如何在其工程環境周邊組織支援及內部工作流程。兩者均指向模型訂閱服務所無法提供的整合工作。
對工程領導者而言，這關乎哪些項目值得投資。可重用自動化需要可靠地接入程式碼庫、測試、審核流程及團隊知識。改善模型答案無法彌補周邊每一項缺失的連接。
背景資料亦帶來維護責任。程式碼改變時，指示可能過時。文件可能描述已不存在的行為。擷取內部資訊的工作流程，需要一種方法分辨現行指引與過時資料。
這令 可搜尋知識庫與此營運問題相關。工程師需要可取得的技術背景資料，然而單靠整理文件，並不能證明自動化變更正確無誤。
Docusign AI 營運模式最有趣之處正在這個組織邊界。一項有用成果若能讓其他人重現，而不依賴原作者的記憶，便會更具價值。要做到這點，必須封裝方法、保留證據並分配維護責任。
重用亦可能集中放大錯誤。若共享工作流程包含錯誤假設，更廣泛採用只會令該假設擴散。因此，分發與驗證必須同步發展，並設有清晰途徑以修正或撤回有問題的自動化流程。
更多 AI 活動仍未能確定提升生產力
採用情況和程式碼數量反映的是活動；交付表現則需要有關已完成工作及使其達到可接受標準所需投入的證據。
這項區分十分重要，因為工程產出有多重含義。已生成的程式碼、已審閱的程式碼、已部署的變更，以及客戶所獲益處，分別處於流程中的不同環節。較早環節的進展，可能與後續環節的延誤同時存在。
更多擬議變更可能增加審閱需求。若審閱者需要更長時間才能釐清意圖或驗證不熟悉的程式碼，生成速度便可能把工作轉移至組織中受資源限制的部分。局部改善因而未能反映整體結果。
程式碼數量亦會因應工作性質而異。刪除不必要的程式碼可改善系統，卻會減少所量度的產出。大規模重寫可增加活動量，卻未必帶來相稱的客戶效益。詮釋結果取決於該項工作原本要達成甚麼目標。
獨立研究說明了為何生產力主張需要審慎界定範圍。一項開發者生產力實驗研究了 16 名經驗豐富的開源開發者，使用 2025 年初的工具完成 246 項任務。在該情境下，允許使用 AI 令完成時間增加了 19%。
這項發現挑戰了參與者的預期，但其適用範圍相當具體。研究涉及的是熟悉相關專案、並使用研究期間可取得工具的資深貢獻者。它並不證明所有開發者、所有任務或後來的系統都會出現相同效果。
這項限定對 2026 年 11 月的評估十分重要。若重複引用較早的實驗結果而不註明日期，便會歪曲可用於理解不斷變化技術的證據。該研究支持人們對直覺保持懷疑，而非對 AI 協助作出永久定論。
METR 於 2026 年 2 月發表的量度更新帶來另一項複雜因素。研究人員表示，由於參與者選擇、任務選擇，以及量度同步進行的代理工作存在困難，後續數據提供的估算並不可靠。
研究人員相信，開發者獲得的效益很可能較早前研究為多。他們同時提醒，較新的證據未能可靠地確定該改善的幅度。兩項說法都應納入討論。
就 Docusign 而言，這些研究提供的是量度背景，而非直接比較。受支援的企業計劃，與涉及開源貢獻者的實驗有所不同。兩項結果均不能取代對公司實際工作流程和交付條件的評估。
可信的評估需要跟隨工作經過審閱和修正的過程。起草時節省的時間，必須連同理解、測試、修訂及支援結果所花的時間一併考慮。否則，量度只會捕捉最有利的一個階段。
任務選擇亦會影響詮釋。團隊最初可能會自動化重複性高、驗收準則明確的工作。在這些工作上的收益，並不表示在模糊的產品決策、架構變更或證據不完整的調查中亦有同等收益。
由同儕帶動的 AI 採用可提升信心和參與度，同時仍未能解答那些成效問題。這是應把各項主張分開處理的理由，而非否定該計劃。組織成功與生產力成功需要相關但不同的證據。
最有用的報告會說明哪些工作有所改變、如何界定完成，以及品質是否維持於可接受水平。單一的全公司生產力標籤，壓縮了過多不同活動，無法自行承載這些說明。
人工審閱成為生產系統的一部分
Docusign 表示，人類工程師在程式碼推出前仍會繼續審閱和批准。這道界線讓責任繼續由人承擔，即使自動化執行了更多準備工作。其成效取決於審閱者能否從收到的材料中確立所需事項。
當審閱者有足夠的背景、證據和時間去質疑擬議變更時，人為批准才提供有意義的控制。
一個人可以在未完全理解後果的情況下批准程式碼。因此，設有批准步驟反映的是流程要求，而非證明審閱已經足夠。支援證據的質素至關重要。
審閱者在評估實作前，需要先理解預期行為。技術上看似合理的變更，可能解決了錯誤問題，或改變了所要求範圍以外的行為。若測試編入了同一項錯誤假設，便無法解決這種不符。
這使任務描述成為控制系統的一部分。清晰的界線有助審閱者識別意料之外的變更，同時為自動化提供更狹窄的目標，並建立判斷工作何時仍未完成的基礎。
證據應說明已檢查甚麼，以及哪些部分仍存在不確定性。成功完成測試，可反映那些測試所涵蓋案例的資訊；但並不自動證明每種相關客戶情況均已覆蓋。
相同區分亦適用於安全性。存取限制約束代理可以執行甚麼操作，而審閱則評估其擬議操作是否可接受。組織需要兩類控制，因為兩者分別處理不同的失敗來源。
營運工作帶來更多問題。提出修正建議、開啟提案、合併程式碼，以及變更正在運作的服務，後果各不相同。隨着自動化涵蓋這個序列中更多環節，團隊需要明確說明由誰授權每次轉換。
這些界線應讓使用系統的工程師仍能理解。若批准模式變得不清晰，某人可能會以為其他人已經評估過風險。明確責任可減少這種模糊情況。
共享工作流程亦需要設有渠道，處理批准後出現的失敗情況。工程師可能發現，先前獲接受的自動化在另一個儲存庫中表現不佳。組織需要有方法遏止該行為，並通知其他使用者。
這也是為何維護責任歸屬十分重要。工作流程可能比創造它的專案或最初支援它的團隊架構更長壽。若沒有持續的責任歸屬，成功採用會形成不斷擴大的未獲支援依賴項集合。
另一項關注涉及學習。工程師需要有足夠理解，才能察覺生成的工作何時與系統設計相衝突。若自動化減少了日常接觸實作細節的機會，團隊便必須考慮這種理解會如何培養。
這項關注並不證明 AI 必然削弱工程技能。它指出了一個使用統計無法解決的組織問題。支援計劃的評估，應部分取決於工程師是否更能夠判斷自己所批准的工作。
因此，Docusign 的 AI 營運模式不僅取決於分發成功技術，亦必須保留質疑這些技術的能力。持久的採用包括知道共享工作流程何時合適、何時需要修訂，以及何時應由人員接手。
下一批證據應追蹤交付、可靠性和重用
在未來數月，最具參考價值的訊號應把更廣泛的自動化，連繫至獲接受的交付、正式環境品質，以及跨團隊的持續使用。
第一項訊號，是界定清晰工作類別的交付表現。後續報告應區分起草速度，與產出獲接受、已發布變更所需的時間。這將令營運主張更具體。
若任務範圍和品質期望維持可比性，較短交付時間將會強化相關論據。更快的起草若伴隨較長的審閱，則顯示效益較為有限。兩種結果均有助說明系統在哪些方面仍需改進。
相關比較亦須考慮團隊選擇自動化甚麼工作。已完成重複性任務的增加，能為維護能力提供有用資訊；但未必證明需要協商或不確定產品判斷的工作進展更快。
第二項訊號，是發布後的可靠性。有關修正、失敗變更和復原的證據，可釐清增加活動量是否帶來額外營運工作。在交付加快的同時維持穩定品質，將強化擴大該做法的論據。
品質惡化需要比宣稱 AI 成功或失敗更具體的診斷。問題可能涉及任務選擇、不完整檢查、背景不足，或審閱者負荷過重。每種解釋均意味不同的組織回應。
第三項訊號，是自動化建立團隊以外的持續重用。工作流程獲同事成功使用，代表知識已經流通的證據。在日常條件下反覆使用，比起由原作者支援的示範更有意義。
這些證據亦應包括維持重用正常運作所需的維護工作。若每個新團隊都需要大量自訂，效益仍然依賴專家支援。若團隊能在責任歸屬清晰的情況下採用並維護工作流程，營運模式便更具可信性。
這些是觀察準則，而非 Docusign 已宣布的報告承諾。現有說明並未確立公司何時會發表可比較的後續指標。讀者不應把期望中的評估視為承諾披露。
對開發者而言，實際問題是自動化是否改善他們必須完成的工作，包括審閱和支援。對企業買家而言，問題則是投資是否包括維持該改善所需的組織能力。
在借鑑 Docusign 的 AI 營運模式前，應檢視團隊擬擴展工作流程背後的證據。識別哪些工作能更早進入正式環境、審閱者仍須做甚麼，以及共享自動化在初步成功後由誰維護。詢問當另一個受不同限制的團隊使用它時，結果是否仍然成立。把交付時間、正式環境品質和持續重用一併追蹤，因為各自揭示成果的不同部分。清楚區分公司報告的參與情況與獨立量度的表現。下一個有用討論應由一項已完成的工作及其背後投入開始：對負責交付和維護它的人而言，究竟改變了甚麼？
