去年有個保險公司的技術負責人跟我吐槽，他們花了三個月上線的智能客服，上線第一周就被用戶罵"人工智障"。復盤發(fā)現(xiàn)，開發(fā)團隊把"專業(yè)友善"理解成了"用emoji賣萌"，而業(yè)務方想要的其實是"像資深理賠員那樣先共情再解決"。

這種錯位每天都在發(fā)生。LLM項目失敗，十有八九不是代碼寫錯了，是意圖從一開始就沒對齊。

微軟最近放出來一套叫ASP（Agentic Specification Protocol，智能體規(guī)約協(xié)議）的方法論，試圖從源頭解決這個問題。它的核心思路很產品經理：把模糊的"業(yè)務意圖"翻譯成機器能執(zhí)行的"合同"。

從用戶故事到"三位一體"

傳統(tǒng)軟件開發(fā)的路徑是清晰的：用戶故事→技術規(guī)格→代碼實現(xiàn)。但LLM系統(tǒng)里，這條鏈斷了。

業(yè)務方說"處理客戶投訴"，這個需求太肥了。對人類客服，這是句話；對AI智能體，它需要被拆解成原子級認知任務：識別情緒→確認保單信息→判斷責任歸屬→生成解決方案→執(zhí)行退款或轉人工。

ASP的做法是強制使用Trinity Framework（三位一體框架）：Task（任務）、Context（上下文）、Constraint（約束）。

Task解決"做什么"，但要拆到不能再拆。Context解決"在哪做"——這個agent調用什么工具、能訪問哪些數(shù)據(jù)、以什么身份說話。Constraint解決"什么不能做"，分為硬屏障（絕對不能碰的紅線）和軟指南（建議但可覆蓋的偏好）。

微軟架構師的原話是：「當BA或架構師提供的工單已經定義好這三根柱子，重活就干完了。開發(fā)者不用猜persona該是什么樣，邊界情況是什么——都寫在紙上了?！?/b>

80%的提示工程前置

ASP最狠的一招，是把Markdown模板嵌入需求流程。

任何涉及AI的功能請求，必須先填這個模板。等工單流到開發(fā)者手里，80%的提示工程已經完成。這個數(shù)字不是來自某篇論文，是架構師基于帕累托法則的經驗法則（Architect's Heuristic）。

具體怎么落地？BA用Trinity模板做需求訪談，產出"單一真相源"文檔。架構師把它轉成System Prompt Package。開發(fā)者把Context和Constraint硬編碼進系統(tǒng)消息，確保agent行為跨會話不變。需要查數(shù)據(jù)庫的子任務，再映射到具體函數(shù)調用。

多智能體系統(tǒng)更妙：一個Trinity Spec的Task，變成下一個的Context。像接力賽，每一棒都清楚自己從哪來、往哪去。

這套流程本質上是在回答一個老問題：業(yè)務和工程之間的翻譯損耗，能不能降到可接受范圍？

為什么約束是最被低估的部分

做過LLM產品的都知道，讓模型"做什么"相對容易，讓它"不做什么"才是噩夢。

ASP把Constraint單獨拎出來，分成兩類。硬屏障是絕對禁止：不能透露其他用戶數(shù)據(jù)、不能承諾超出權限的賠償、不能生成醫(yī)療建議。軟指南是風格偏好：優(yōu)先用電話而非郵件聯(lián)系、遇到不確定時先道歉再升級。

這個區(qū)分很關鍵。硬屏障需要代碼級保障，軟指南可以交給模型自行權衡?；煸谝黄?，要么過度約束導致機械僵硬，要么約束不足引發(fā)事故。

微軟的文檔里有個細節(jié)：開發(fā)者的剩余精力，應該花在工具集成、輸出驗證和異常處理上。這些才是IDE里該解決的問題，而不是在Jira工單和業(yè)務方來回扯皮"專業(yè)友善到底什么意思"。

誰該為意圖負責

ASP的潛臺詞很直白：提示工程不是開發(fā)者的專屬技能，是業(yè)務分析的新基本功。

這顛覆了現(xiàn)有的分工想象。很多公司把prompt engineering當成"寫代碼的人順便做的事"，結果業(yè)務方抱怨"技術不懂場景"，技術方反擊"需求模糊不清"。ASP把Trinity框架推到BA階段，相當于在組織架構里劃了一條新線——意圖澄清的責任，從工程側前移到了業(yè)務側。

代價是BA需要學習新語言。收益是開發(fā)者拿到的是可執(zhí)行的合同，不是待解的謎題。

那個保險客服項目的負責人后來告訴我，他們重構時用了類似思路，把"專業(yè)友善"拆解成12條可驗證的行為指標，比如"用戶提及損失時，3句話內必須出現(xiàn)共情表達"。上線后NPS從-15漲到+34。

指標不是重點。重點是終于有人承認：LLM項目的風險，不在技術棧選型，而在人怎么說話。

如果你的團隊正在踩類似的坑，第一個該問的問題或許是：你們的需求文檔里，有沒有一塊專門留給"約束"的陣地？