Prompt 不是靈感文字：把它當成可追蹤的產品資產
改了一句 prompt 就讓流程崩掉，問題通常不在註解，而在缺少 prompt 的版控、回放與回歸測試。把 prompt 當成產品資產管理，才撐得起 production。
我們最近一直在談「AI 讓產能提升」，但在實務上，很多團隊卡住的原因其實很單純：
你改了一句 prompt，整個流程或評測突然崩掉。
問題通常不在於你註解寫得不夠，而在於你把 prompt 當成「靈感文字」，而不是「可追蹤的產品資產」。
我很喜歡這篇 Threads 提到的概念：PIT（Prompt Integration Tooling）。
一句話理解：Git for prompts。
但它更關鍵的地方，不只是做文字 diff，而是把 prompt 的版本跟行為指標綁在一起，讓你能回答真正重要的問題：這次改動到底讓系統更好，還是更糟？
prompt 為什麼需要產品級管理？
當 prompt 進到 production，你面對的就不再是「好不好用」的主觀感覺，而是三個硬指標：
- 成功率：同樣的輸入，有多少比例能給出可用輸出？
- 延遲：回應速度能不能符合服務水準？
- 成本：每次呼叫的 token/費用是否可控？
如果這三個指標沒有被系統化追蹤，prompt 會退化成口耳相傳：哪個版本「好像比較穩」；誰的 Notion 上有最新版本；某天有人改了一句話，隔天全線炸掉。
PIT 的三個關鍵功能：把工程方法帶進 prompt
這篇文提到幾個很實用的能力，我覺得每個做 LLM 產品的團隊都會用到：
- bisect：用二分法找出是哪個版本把行為搞壞
當你有一串 prompt 變更歷史，最痛苦的是「到底哪次改動讓品質掉下來」。
bisect 的價值在於把定位問題從猜測變成流程：用最少的次數，快速縮小範圍。
- replay：同一筆 input 跑過多個版本，快速比較
這其實就是 prompt 的回歸測試。
你要能用同一組測試資料，把 v3、v4、v5 都跑一遍，立刻看出差異，而不是憑感覺說「我覺得這版比較順」。
- query：用條件搜尋版本
例如找出「成功率 > 0.9」且「成本 < 某門檻」的版本。
當 prompt 的版本變多，這會讓你從檔案管理升級成資產管理。
更重要的：它承認一件事
很多人把 prompt engineering 想成「文字工作」。
但在我看來，一旦你把 prompt 放進 production，它的性質就跟 code 一樣：需要版控、需要 review、需要安全掃描（注入、PII/Key）、需要 A/B test，還需要一套能回放與回歸的工程流程。
工具不是重點，重點是承認 prompt 的角色已經變了。
你們現在管理 prompt 的方式比較像哪一種？Git repo、Google Doc、Notion，還是靠記憶？
(原文連結)
