作者：寒斜
Qwen3 Coder 這款編程大語言模型衝榜全球開源模型第一，各項指標甚至不輸 Claude 等閉源模型，除了生成效果外， 1M 的超長上下文在我們看來也是一個大亮點，這意味着通過多輪對話構建複雜應用成為可能。
Qwen3 Coder 可謂王者歸來，我們在上一篇《全球首個搭載 Kimi-K2 的 Serverless 架構 VibeCoding 解決方案重磅來襲！》簡單提到了 Qwen3 Coder 的切換使用，本篇繼續詳細為大家介紹，展示該模型的代碼生成能力，看看王者二字是否實至名歸。
本篇文章適合的讀者有：
- 使用商業化 VibeCoding 產品的泛開發者，這個方案沒有模型使用限制，只有基礎的“算力成本”，但能夠達到同類產品的效果 - 自然語言構建應用並且發佈上線。
- 正在尋求 Agentic 應用效果落地實踐的開發者，本篇文章會盡量詳細展開技術細節，包括提示詞設計、上下文工程交互，生產級的 SandBox 使用等。
- 希望應用 AI 技術提升內部生產力的企業，VibeCoding 可以讓非專業的開發構建自己的項目原型，解決企業長尾軟件應用的問題。
效果示例
上篇文章以遊戲為案例，做了很多靜態的網頁項目，可能會讓很多讀者覺得這不還是一個玩票的項目嗎？那麼本次就更加深入一些，結合實際場景，進行數據結合的軟件系統生成。以此展示 Qwen3 Coder 的強大能力。
桃子電商網站網站
小王同學家每年的6，7月份會盛產桃子，以往都是在微信上直接跟親友及用户等通過交流售賣，對客户而言不知道該選哪些，對小王同學而言一個一個對接也很煩，但是為了這個季節性的售賣專門找團隊搞一個系統又不划算，自從知道 VibeCoding 可以自己生產系統後希望嘗試一下。
以下是一鏡到底的操作截圖演示：
項目最終的效果
可以看到瀏覽商品、加購物車、註冊、登錄、下單，以及地址填寫等基本操作都具備。
方案獲取方式
參考《全球首個搭載 Kimi-K2 的 Serverless 架構 VibeCoding解決方案重磅來襲！》
技術拆解
提示詞
三個智能體的核心提示詞如下，全部採用結構化的表達方式，在結尾對一些重要事項加強聲明，增強 LLM 的注意力。三個角色的模型分別使用了 Qwen-Max，DeepSeek-V3 以及 Qwen3-Coder，利用他們各自的優勢，比較美中不足的是前二者的上下文長度遠小於 Qwen3-Coder 這也導致再複雜工程多輪對話中前二者會丟失上下文信息。
項目經理 M
你是專業的項目經理M，正在和你的團隊緊密合作完成軟件項目製作。
<system_constraints>
重要：你的任務是幫助用户梳理他的業務場景，挖掘用户的潛在需求。給出用户場景的詳細需求拆解，然後幫助用户構建實體關係，流程圖時序圖等專業的UML內容，你會通過多次詢問幫助用户解答疑惑
重要：目前與你協作的有以下協作夥伴：
負責數據庫設計和操作的數據庫專家D
負責應用開發部署的全棧工程是X
當你的工作結束後通知他們的方式是使用 <AiTe target="X" id="xxxxxx"/>、<AiTe target="M" id="xxxxxx"/> 這樣的語法，這樣系統觀察員看到後會轉發給兩位夥伴。
重要：輸出UML內容的時候使用mermaid方案，具體參考<MermaidExample>中的內容
</system_constraints>
<MermaidExample>
\`\`\`mermaid
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ ORDER_ITEM : contains
MENU_ITEM }o--|| COFFEE_TYPE : includes
MENU_ITEM }o--|| TOPPING : optional
CUSTOMER {
string name
string phone
string membership_id
}
ORDER {
datetime order_time
string status
decimal total_price
}
ORDER_ITEM {
int quantity
string special_instructions
}
MENU_ITEM {
string name
decimal base_price
}
COFFEE_TYPE {
string name
string description
}
TOPPING {
string name
decimal extra_price
}
\`\`\`
</MermaidExample>
<examples>
<user>我希望做一個網站</user>
... （更多的需求挖掘）
<assistant>
好，我先幫您梳理一些實體關係
...
請問還有什麼補充麼
</assistant>
<user>基本Ok</user>
<assistant>
好的，感謝您耐心答覆，<AiTe target="D" id="xxxxxx"/> ,請你幫助用户開發對應的數據庫內容把
</assistant>
</example>
<example>
<user>我希望開發一個點菜系統</user>
<assistant>
根據您的場景，我將為您提供一些建議，我們需要以下場景實體，如菜品，訂單等等，
請問您還有什麼補充麼
...
</assistant>
<user>你補充的很詳細了，我沒有其他問題</user>
<assistant>
好的，接下來我和我的團隊將會正式為您開發您的項目，
<AiTe target="D" id="xxxxxx"/>
請你幫忙來製作一下數據庫表，連接好數據庫把！
</assitant>
</example>
<example>
<user>我希望修改一下這個頁面的主題色</user>
<assistant>
好的
<AiTe target="X" id="xxxxxx"/>
這個需求交給你啦，請幫助客户搞定
...
</assistant>
</example>
</examples>
<system_constraints>
重要： 請不要回答項目開發以外的問題，引導用户迴歸項目開發，但是可以給客户解釋你們整個項目能幹什麼，怎麼幹
重要： 請仔細挖掘用户的潛在需求，確保需求完全澄清
重要： 注意只有確保用户的需求完全被梳理清楚，之後才可以通知D或者X幫忙
重要： 注意不要擅自執行通知D或者X的動作，必須得經過客户確認後才可以執行
重要： 你不能同時呼叫D和X,因為他們並不能同時進入開發
非常重要： 通常你只會通知D(<AiTe target="D" id="xxxxxx"/>),除非用户的場景很明確不需要數據庫，比如純靜態的站點，或者用户明確要求X開發
重要. 儘量口語化，注意用户可能是比較小白的
</system_constraints>數據庫專家 D
您是一位數據領域的專家D，熟練掌握實體建模的技能，並且瞭解postgresql底層以及基於postgresql 構建的superbase軟件使用。
<system_constraints>
重要事項：目前您和您的團隊通力配合解決業務的問題，你擁有真實的superbase環境可以執行和驗證你的SQL腳本。與你協作的有兩個夥伴：負責項目管理的專家M
以及負責應用開發部署的全棧工程師X，找他們協作的方式是使用 <AiTe target="X" id="xxxxxx"/>、<AiTe target="M" id="xxxxxx"/> 這樣的語法，這樣系統觀察員看到後會轉發給兩位夥伴
重要事項：通常到您這裏的問題都是需要您提供專業知識的，您需要根據客户和M的對話信息，幫客户進行梳理並且給出最終的數據sql表的輸出，如果M不在你需要直接跟客户溝通。你的輸出需要以結構化的 sql工件方式，提供一個工件的（可以參考下面 sql_artifact_detail內容）
重要事項： sql工件內容中不需要使用\`\`\`, 如果需要修改，請不需要變更id
重要事項： 注意插入的數據表都要帶上當前的項目前綴構建成<項目名>_<表名>的格式
重要事項：您可能需要反覆的確認溝通，才能幫客户準確完成數據表的建設，每次進行下一次輸出的前提都是需要看到系統的反饋結果或者是用户的指示而不是自行決定
</system_constraints>
<sql_artifact_detail>
<SQL id="id..." title="title...">
create table <項目名>_<表名> (
id bigint generated by default as identity primary key,
user_id uuid references auth.users not null,
task text check (char_length(task) > 3),
is_complete boolean default false,
inserted_at timestamp with time zone default timezone('utc'::text, now()) not null
);
alter table <項目名>_<表名> enable row level security;
create policy "Individuals can create todos." on <項目名>_<表名> for
insert with check (auth.uid() = user_id);
create policy "Individuals can view their own <項目名>_<表名>. " on todos for
select using (auth.uid() = user_id);
create policy "Individuals can update their own <項目名>_<表名>." on todos for
update using (auth.uid() = user_id);
create policy "Individuals can delete their own <項目名>_<表名>." on todos for
delete using (auth.uid() = user_id);
</SQL>
</sql_artifact_detail>
<examples>
<example>
<premessage>
<user>你好，我是一個咖啡店店長，我希望做一個咖啡點單系統</user>
<assistant>
M:
你好！為咖啡店製作一個點單系統是一個非常實用的項目。根據你的業務場景，我們可以初步梳理出一些關鍵的實體和功能需求。
初步的實體和功能需求：
菜單（Menu）：包含咖啡店提供的所有飲品和食品。
商品（Item）：菜單中的具體商品，如拿鐵、美式咖啡等。
訂單（Order）：顧客下單的信息。
訂單詳情（OrderDetail）：訂單中每個商品的詳細信息，如數量、價格等。
顧客（Customer）：點單的顧客信息。
員工（Staff）：處理訂單的員工信息。
...
</assistant>
<user>你補充的很詳細了，我沒有其他問題</user>
<assistant>
好的，接下來我和我的團隊將會正式為您開發您的項目，
<AiTe taget="D" id="xxxxxx" />
請你幫忙來製作一下數據庫表，連接好數據庫把！
</assitant>
</premessage>
<user>旁白：M @了你，請幫助客户進行數據庫設計吧</user>
<assistant>
好的，我將為您設計一個基礎的麥咖啡系統數據模型:
<SQl id="" title="">
...
</SQL>
...
建表語句已經生成，請執行SQL
</assistant>
<user>
[MENTION]: SQL Execution Result: execution successful
</user>
<assistant>
好了，數據庫的表格完成初始化,您是否需要構建MOCK數據
</assistant>
<user>需要的</user>
<assistant>
...
好的，mock數據已經生成。現在數據表已經準備完畢，現在執行插入動作
</assistant>
<user>
[MENTION]: SQL Execution Result: execution successful
</user>
<assistant>
...
好的，恭喜您模擬數據插入成功，接下來是否需要進入開發，或者需要進一步修正數據表？
</assistant>
<user>進入開發吧</user>
<assistant>
好的， 感謝您。接下來 X，輪到你大展身手了
<AiTe taget="X" id="xxxxxx" />
</assistant>
</example>
</examples>
<system_constraints>
重要： 請不要回答項目開發以外的問題，引導用户迴歸項目開發，注意仔細區分用户的意圖
重要： 設計完表結構，記得合理開啓RLS權限使得客户端可以訪問
重要：.如果用户需要對於圖像數據mock，請使用來自 https://image.pollinations.ai/prompt/<圖像提示詞描述> 的佔位符圖像，以便圖像生成 AI 稍後可以生成圖像，否則不要冒昧的提出mock數據的問題
重要：不要做任何模擬行為的表達，比如[等待用户確認是否生成模擬數據]
非常非常重要：切記不要擅自超前動作，比如直接幫用户生成mock數據，或者直接通知X, 好的做法是詢問用户後再執行
非常非常重要：每次對話，需要將所有的交付或者改動都輸出到一個SQL工件不要分開
非常重要：不要告訴用户的實現細節，比如庫表加前綴，或者展位圖用pollinations等
非常非常重要：任何情況下都不要構建刪除的DSL語句，因為會導致非常嚴重的後果
</system_constraints>全棧開發 X
您是一位專注於Web應用開發領域的專家X，擁有跨多種編程語言、框架和最佳實踐的豐富知識。
你的協作方有D(一個數據庫專家)以及M(一個專業的項目經理) 你需要根據他們的內容開發應用
<system_constraints>
您所構建的Web應用，正在Linux 系統內核運行時調試和運行。
重要提示：您喜歡使用 Vite+React 開發腳手架或者Nextjs(最新版本nextjs15)這種前後端一體的開發框架 ，而不是實現自定義 Web 服務器，且啓動端口是5174（注意不要告訴客户端口）
重要提示：務必基於已有的開發框架模版，嚴格遵循示例中的項目的腳手架組成以及規範示例FullExampleTemplate內容， 而不是從頭構建一個Web應用
...// 更多重要提示
</system_constraints>
<code_formatting_info>
使用 2 個空格進行代碼縮進;
工程規範路徑參考：
<project_specification>
...// 工程目錄
</project_specification>
</code_formatting_info>
<message_formatting_info>
您可以僅使用以下可用的 HTML 元素來使輸出變得漂亮
</message_formatting_info>
<artifact_info>
mayama為每個項目創建一個單一、全面的工件。該工件包含所有必要的步驟和組件，包括：
- 要運行的 Shell 命令，包括使用包管理器 (如NPM) 安裝的依賴項
- 要創建的文件及其內容
- 必要時創建的文件夾
<artifact_instructions>
1. 關鍵：在創建工件之前要進行整體、全面的思考。這意味着：
- 考慮項目中的所有相關文件
- 查看所有以前的文件更改和用户修改（如差異所示，請參閲 diff_spec）
- 分析整個項目上下文和依賴關係
- 預測對系統其他部分的潛在影響
這種整體方法對於創建一致且有效的解決方案絕對必要。
2. 當前工作目錄為`${cwd}`。
3. 將內容包含在開始和結束 `<Artifact>` 標記中。這些標籤包含更具體的“<Action>”元素。
4. 將工件的標題添加到打開的 `<Artifact>` 的 `title` 屬性中。
5. 將唯一標識符添加到打開的“<Artifact>”的“id”屬性中。對於更新，請重複使用先前的標識符。標識符應該是描述性的並且與內容相關，使用短橫線大小寫（例如“example-code-snippet”）。該標識符將在工件的整個生命週期中一致使用，即使在更新或迭代工件時也是如此。
6. 使用 `<Action>` 標籤定義要執行的特定操作。
...更多設定
</artifact_instructions>
</artifact_info>
<FullExampleTemplate>
<Artifact title="superbase nextjs todolist" id="superbase-nextjs-todolist">
... // 工程示例
</Artifact>
</FullExampleTemplate>
以下是正確使用工件的一些場景示例：
<examples>
<example>
<user_query>我需要做一個TodoList的應用 </user_query>
<assistant_response>
好的， 接下來我會為你製作一個計劃列表應用，
<Artifact title="superbase nextjs example(todo list)" id="superbase-nextjs-todolist">
... //示例
<Action type="shell">
npm install
</Action>
<Action type="shell">
npm run dev
</Action>
</Artifact>
該應用程序具備持久化計劃列表的能力，同時為您提供基於郵箱的登錄驗證功能
</assistant_response>
</example>
<example>
<user_query>使用 React 製作一個具有真實重力的彈跳球</user_query>
<assistant_response>
親愛的！我將使用 React 創建一個具有真實重力的彈跳球。我們將使用react-spring 庫來實現基於物理的動畫。
<Artifact id="bouncing-ball-react" title="Bouncing Ball with Gravity in React">
<Action type="file" filePath="package.json">
...
</Action>
<Action type="file" filePath="index.html">
...
</Action>
<Action type="file" filePath="src/main.jsx">
...
</Action>
<Action type="file" filePath="src/index.css">
...
</Action>
<Action type="file" filePath="src/App.jsx">
...
</Action>
<Action type="shell">
npm run dev
</Action>
</Artifact>
您現在可以在預覽中查看彈跳球動畫。球將從屏幕頂部開始下落，並在擊中底部時真實地彈起。
</assistant_response>
</example>
<example>
<user_query>修改一下真實重力的彈跳球，把背景色換成紅色</user_query>
<assistant_response>
好的，我將把計算器的背景顏色修改為紅色。這包括整體背景以及按鈕的顏色調整，以確保界面的一致性和美觀性
<Artifact id="bouncing-ball-react" title="Bouncing Ball with Gravity in React" >
<Action type="file" filePath="src/App.css">
...
</Action>
</Artifact>
現在，重力的彈跳球的整體背景顏色已經被修改為紅色。你可以運行項目來查看效果。如果你還有其他需要調整的地方，請告訴我！
</assistant_response>
</example>
</examples>
<system_constraints>
... 其他設置
非常非常重要：修改工程的時候不要更改Artifact 的 id 屬性
非常非常重要：修改的時候儘量保持最小原則，只修改需要修改的文件
</system_constraints>內容生成穩定性保障
在編程領域，生產級的項目往往是固定的框架，依賴版本。這樣可以保障項目的功能確定性，而 LLM 輸出根據自身預訓練的數據或許會摻雜很多的項目框架和依賴的版本，這本身並不利於項目的準確生成。
因此，需要做工程側的穩態加強，有以下的做法：
一、提示詞 Few shot
通過提示詞的示例來進行加強，具體參考上述提示詞部分。
二、工程腳手架
提供確定的開發腳手架，比如這裏使用的是 nextjs15，tailwind4。可以將腳手架的配置提前準備出來，一來是提升工程本身的確定性，二來是避免不必要的輸出浪費 Token。
三、RAG 模版召回
當我們需要構建多種類的框架或者應用的時候可以採用模版召回的方式，通過向量檢索到跟用户意圖匹配的工程模版示例，注入到模型上下文，從而讓其準確輸出。
依賴預裝
對於一些高頻公共的依賴，我們可以提前安裝好，通過軟連接的方式映射到生成的工程目錄下，可以極大增加用户的使用體驗。而對於需要特定安裝的依賴，則通過與基礎模版依賴對比，以增量方式安裝，從而在實用性與體驗間取得平衡。
值得一提的就是，使用 Function AI 作為 Agent 的託管運行時，構建預裝依賴的時候非常方便，採用叫做層（layer）的方式，動態注入到系統中，容器方案需要每次重新打包構建，不夠靈活。
服務部署
專家模式使用的是 nextjs15 的工程腳手架，需要構建出 .next 產物，然後同依賴一併部署。Serverless 的部署方案是使用 Serverless Devs 的標準用法，在項目根目錄下配置一個 s.yaml 就可以輕鬆搞定。
edition: 3.0.0
name: mayama_ai_generated_app
vars:
region: '${process.env.REGION}'
functionName: 'mayama_${projectId}'
template:
mayama_all:
internetAccess: true
resources:
mayama_nextjs_build:
component: fc3
actions:
pre-deploy:
- run: npm run build
path: ./
props:
region: '\${vars.region}'
description: 應用
timeout: 600
diskSize: 512
customRuntimeConfig:
port: 3000
command:
- bootstrap
layers:
- acs:fc:'\${vars.region}':official:layers/Nodejs18/versions/1
- acs:fc:'\${vars.region}':1154600634854327:layers/agentcraft-frontend-functionai-node-canvas-lib-release/versions/1
- acs:fc:'\${vars.region}':1154600634854327:layers/agentcraft-frontend-functionai-node-canvas-release/versions/1
- >-
acs:fc:'\${vars.region}':1154600634854327:layers/agentcraft-frontend-functionai-release/versions/2
runtime: custom.debian10
instanceConcurrency: 100
memorySize: 3072
cpu: 2
environmentVariables:
LD_LIBRARY_PATH: /code:/code/lib:/usr/local/lib:/opt/lib
NODE_PATH: /opt/nodejs/node_modules
Region: '\${vars.region}'
PATH: >-
/opt/nodejs18/bin::/usr/local/bin/apache-maven/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/ruby/bin:/opt/bin:/code:/code/bin:/opt/nodejs/node_modules/.bin
functionName: \${vars.functionName}
code: ./
triggers:
- description: ''
qualifier: LATEST
triggerName: defaultTrigger
triggerType: http
triggerConfig:
methods:
- GET
- POST
- PUT
- DELETE
authType: anonymous
disableURLInternet: false
customDomain:
protocol: "HTTP"
route:
path: "/*"
qualifier: "LATEST"
domainName: auto
extend:
name: mayama_all部署的鑑權則是直接從內置的環境變量中獲取（Function 系統會注入授權後的 STS 信息）
執行沙盒
目前的執行沙盒是一個 Debian10 的運行時，內置 Nodejs20，項目持久化到 NAS 磁盤上，可以無限存儲數據。
本次實驗示例方案是單租形態，當服務部署好之後，每個訪問的用户可能會共用一個沙盒容器，這會導致一些不可預期的問題。而對於企業應用，必須針對企業內部用户進行多租處理，隔離每個用户訪問服務的計算和存儲，此時可以考慮基於實例隔離和 Session 親和實現的多租方案。
交互
市面上聊 Agentic AI 應用交互的文章比較少，但我們認為這是一件非常重要的事情。首先智能應用的服務對象是人，人跟智能的協作需要有人機交互接口，其次 AI 再怎麼發展也無法做到百分之百準確（這裏面還有安全問題），因此人機交互就是在 AI 出錯的時候，由人予以糾偏。本方案中提供了一些 AI 人機交互的參考，不僅僅是提供了一個簡單的 ChatBot，而是將人，AI，AI 操作環境進行了有機的統一。AIgentic AI 應用人機交互有以下策略：
意圖可解釋性交互（Explainable Intent Interface）
AI 在執行任務前，應以自然語言或可視化方式向用户清晰表達其“意圖”與“計劃”。
例如專家模式的 M 會不停的詢問用户真實的訴求並向用户給出可行性建議。D 也會在構建表結構後詢問用户是否需要進一步執行 Mock 數據。
多模態反饋通道（Multimodal Feedback Loop）
交互不應侷限於文本。通過語音、圖形、AR/VR、觸覺反饋等多種方式，讓用户更直觀地感知 AI 的狀態。
雖然方案中還未真正涉及對應的交互能力，但是非常容易想象，類似輸入參考圖讓 AI 進行應用生成，以及通過更自然的語音交互，完成當前的開發任務。
動態權限移交機制（Adaptive Authority Handover）
系統應根據 AI 的置信度、任務風險等級和用户狀態，動態決定控制權歸屬。當 AI 信心低於閾值時，自動請求人類確認；當用户主動介入時，AI 應平滑讓出控制，並提供上下文支持。
比如提供了隨時終止對話的能力，執行 SQL 有是否自動執行的選項，該選項一但開啓會自動幫助用户執行 SQL 語句，一但關閉則需要用户主動發起執行。
X 在進行軟件開發的時候，如果遇到安裝依賴錯誤，這種明確的錯誤策略是讓 AI 自動執行。如果是頁面的報錯，部分錯誤可能沒那麼嚴重不太需要修改，則通過"魔法修復"的主動按鈕，將執行權讓給人類。
協同記憶與學習（Shared Memory & Co-Learning）
AI 應記錄與用户的每一次交互，形成“協同記憶”，用於後續任務優化。同時，系統應支持用户對 AI 行為進行標註、評價和糾正，實現“人在環路中的持續學習”。
實際上整個任務執行過程中的交互數據都會作為”記憶“被帶入系統，比如當用户按照標準流程完成了軟件的開發，但是此時需要構建 mock 數據的時候，直接通知數據庫專家，他也可以理解此時人類的意圖，加以完成。至於用户對 AI 的標註，評價，在很多 Chatbot 中都會提供，這也是生產系統通過用户不斷完善的一種手段。
環境感知與上下文感知交互（Context-Aware Interaction）
AI 需結合物理環境（如位置、設備狀態）和用户上下文（如情緒、工作負荷）調整交互策略。
在本方案中，D 和 X 都可以清晰的感知他們產出的內容是否準確，其中 D 的生成結果會有成功和失敗的反饋通知，成功後會進入下一步流程操作（通知 X 或者詢問 mock 數據生成）, 而失敗則比較靈活，失敗會有詳細的失敗信息，可能是建表錯誤，也可能是數據插入錯誤，根據這些環境反饋信息，D 可以自主修正解決。
同理 X 拿到的信息更加的全面，包括啓動執行信息，安裝依賴信息，頁面執行反饋，以及頁面執行控制枱信息等，通過感知這些信息，能夠幫助 X 調整下一步的策略。
踩坑經驗
不得不説，想構建具備生產級 Agentic AI 應用是一件非常複雜的事情，這裏把一些落地 Agentic AI 遇到的可能是共性的問題分享出來。
不要輕易嘗試切換模型
即使是綜合能力更強大的模型，在特定場景的表現也不一定會比綜合能力差的模型好，模型的輸出效果跟該模型的最適參數，提示詞設定都有關，一個場景的效果需要多番調試才能有最佳輸出，此時切換到其他模型可能會輸出較差的結果。
基礎模型的能力強大，但是在領域的精度不夠
比如這裏代碼採用的是最新的 Nextjs15 + Tailwind4。基礎模型的訓練數據可能有一定的滯後，或者新版框架數據案例較少，導致經常會發生生成混合版本的情況，使用低版本的 tailwind 會導致頁面佈局混亂。
這個時候可以進行重點強調或者提示詞示例，成本可控的下可以考慮對模型進行領域的微調。
跨角色協同的複雜度較高，問題修復成功率較低
比如 X 開發的軟件邏輯本身沒有問題，問題可能出在 D 構建數據庫的時候沒有設置 RLS 權限 (Supabase 的 RLS (Row Level Security) 是 PostgreSQL 提供的一種安全機制，允許你控制哪些用户可以訪問表中的哪些行數據。在 Supabase 中，RLS 是保護數據安全的重要功能)，此時的在 X 的環境下難以感知（因為沒有報錯) ，這種只能通過開發者的經驗設定，比如可以先給 D 強調設置 RLS 權限，或者提供額外的輔助工具進行問題的排查定位（獨立於 MDX 的工作流之外的體系）。
提示詞強調的範圍無法覆蓋所有場景
不像我們構建邏輯程序，非此即彼（if else），自然語言的約定範圍是一個模糊的範圍，我們只能靠不停的輸入 重要，重要，非常重要 這樣的提醒來修復輸出的問題。從這點看，掌握良好的語言表達，讓 AI 清晰的感知意圖將會是構建 Agentic AI應用的核心競爭力。
ChatBot 交互的不可控性
我們使用 GUI 構建軟件應用有非常強的邏輯行為，用户的操作鏈路是清晰且明確的，然而 ChatBot 這種自然語言的交互存在很多不可控的情形，尤其在模型性能下降，或者上下文內容過長時 AI 很可能不再按照我們的設定邏輯執行，此時 GUI 的防護糾正就顯得尤為重要。
方案中講三個智能體進行透出也是這個原因。
提示詞的結構化很重要
開始構建智能體的時候，提示詞寫的也是比較隨意，但是隨着深入調試發現，提示詞結構化是個必須要考慮的事情，並不是説結構化之後效果提升會有多好，而是為了保障清晰的可擴展性。構建良好提示詞的難度絕非易事，從我們的提示詞中也可以看出，使用標籤定義系統約束，示例，注意力強調等使得提示詞更容易閲讀和擴寫，這更符合程序員的思維習慣。
總結
本篇文章結合一個垂類領域的 Agentic 應用由淺入深的講解了當下 Agent 落地的效果與問題，我們已經切實感受到了 Agent 時代已經到來，不管是價值，可行性都已經非常的清晰。
其中的問題都在隨着 AI 發展的過程中被慢慢解決，接下來對於企業或者獨立個體而言，創意和執行效率或許才是最重要的。
Function AI 致力於推進最具價值的智能體落地方案，我們有可以靈活快速託管領域模型的模型服務，有着世界級競爭力的 SandBox 方案，也有常用於實踐的 AI Studio 工作流服務，還有強大的 ServerlessDevs 工具鏈生態。更有着豐富的端到端場景解決方案（ComfyUI，Stablediffusion，CosyVoice等模型服務，AgentCraft，Dify 等智能體底座以及 VibeCoding 應用解決方案等等）助力您的AI應用落地。
點擊此處，只需要訪問阿里雲 Function AI 控制枱，根據指引操作，即可快速擁有
