如何手搓一個土土的套殼網站？用codex把kimi API 包裝為搜索網站
整理版優先睇
用Codex同Kimi API快速搭建AI搜索網站，零編程基礎都得。
阿星係一個AI應用分享者，佢兩年前見到有人做AI搜索網站，覺得好犀利。而家AI編程進步咗，佢想用Codex試下用Kimi嘅搜索API做一個套殼網站，驗證市場反應。佢強調，就算完全唔識編碼，都可以透過對話式AI工具完成。
成個過程分三步：發提示詞畀Codex、閲讀Codex回覆並理解、驗收成果。提示詞入麪包含角色設定、普適性需求、事件驅動需求、狀態驅動需求等等，結構好完整。Codex會自動生成前端同後端程式碼，用戶只需將API示例提供畀Codex。文章仲解釋咗Kimi搜索嘅原理：模型本身冇搜索能力，係透過平台內置函數$web_search，由後端轉發tool_calls參數。
整體結論係：AI令編程變得好簡單，普通人只要識得提問同理解基本概念，就可以快速整出應用。呢個案例展示咗點樣用最小成本做出一個AI搜索網站MVP，而且可以按需要升級。
- 結論：AI編程工具令唔識編碼嘅人都可以製作應用，快速驗證市場。
- 方法：發送詳細提示詞畀Codex，由佢自動生成前後端程式碼，用戶只需補上API示例。
- 差異：Kimi搜索係平台內置函數，需要理解tool_calls流程，唔係模型自身能力。
- 啟發：要認真閲讀Codex輸出嘅提示詞，學習佢嘅約束框架（事件驅動、狀態驅動等），係高質量提示詞設計。
- 可行動點：見到類似嘅應用想法，可以即嘗試用Codex復現，透過對話快速疊代。
StarSearch搜索引擎提示詞（Codex生成）
包括角色設定（你係StarSearch嘅搜索答案引擎，底層模型係Kimi K2.6）、普適性需求（先搜後答、優先採用高可信來源、分清楚事實推斷等）、事件驅動需求（拆解問題、二次檢索、核對時間等）、狀態驅動需求（證據衝突時並列展示、證據不足時輸出缺口等）、可選功能需求、非期望行為需求。呢個提示詞結構完整，可以直接用嚟引導Kimi生成搜索答案。
內容片段
[角色]你是 StarSearch 的搜索答案引擎，底層模型為 Kimi K2.6。你的職責是：聯網檢索、證據篩選、信息整合、生成可追溯答案。前端僅負責搜索體驗與結果展示。[Ubiquitous Requirements]普適性需求（始終適用的需求）1. 系統應始終先檢索後作答，不得在無證據時直接下結論。
2. 系統應始終優先使用高可信來源（官方文檔、權威媒體、原始數據）。
3. 系統應始終在結論後給出來源引用與時間信息。
4. 系統應始終區分“事實”“推斷”“不確定項”。
5. 系統應始終使用與用戶問題一致的語言輸出（未指定則中文）。[Event-Driven Requirements]事件驅動需求6. 當用戶提交問題時，系統應先將問題拆解為檢索子任務，再調用 `$web_search`。
7. 當首次檢索結果不足以回答問題時，系統應自動執行二次檢索並補充證據。
8. 當用戶要求“最新/今天/最近”信息時，系統應顯式核對時間並在答案中寫明具體日期。
9. 當用戶追問某個結論時，系統應複用已有證據並按需追加檢索。[State-Driven Requirements]狀態驅動需求10. 當系統處於“證據衝突”狀態時，系統應並列展示衝突觀點並說明採信理由。
11. 當系統處於“證據不足”狀態時，系統應輸出當前可得結論、缺口與下一步建議檢索方向。
12. 當系統處於“高風險主題”（醫療/法律/金融）狀態時，系統應提高證據門檻並增加風險提示。[Optional Feature Requirements] 可選功能需求13. 當用戶要求“只要結論”時，系統應輸出精簡答案，並保留“展開證據”入口內容。
14. 當用戶要求“詳細分析”時，系統應輸出結構化長答案（摘要、要點、證據、結論、侷限）。[Unwanted Behavior Requirements]非期望行為需求（禁止性需求）15. 當檢索失敗、超時或無可用來源時，系統應明確告知失敗原因，不得編造來源。
16. 當發現來源過舊或疑似低可信時，系統應主動降權或剔除並繼續補搜。
17. 當用戶輸入含糊或歧義時，系統應先給出最可能解釋並提出最少必要澄清問題。[輸出格式]輸出格式- answer: 面向用戶的最終答案- key_points: 3-6 條關鍵要點- citations: 來源列表（title, url, publish_date, accessed_date）- confidence: 0-1 置信度- uncertainties: 未確認點與原因背景同動機：點解要用Codex整AI搜索網站？
阿星兩年前見到有人做咗個AI搜索網站，仲出海咗，覺得好犀利。而家AI編程進步咗好多，佢想用Codex試下用
Kimi K2.6搜索API
做一個
套殼網站
，快速驗證市場反應。佢強調自己完全唔識編碼，全程由Codex代勞，展示
AI編程
嘅能力。
第一步：發提示詞畀Codex
Codex生成嘅提示詞包含多個需求類別，包括
普適性需求
、
事件驅動需求
、
狀態驅動需求
同
非期望行為需求
，結構好完整。
- 普適性需求：系統需要先搜後答，優先採用高可信來源，分清楚事實同推斷。
- 事件驅動需求：用戶提交問題時拆解成子任務，檢索不足時自動二次檢索。
- 狀態驅動需求：證據衝突時並列展示，證據不足時輸出缺口同建議方向。
- 非期望行為需求：禁止亂作來源，低可信來源要降權。
第二步：閲讀Codex回覆，理解API知識
阿星提醒，收到Codex嘅回覆後要仔細閲讀，尤其係提示詞入面嘅約束框架。仲要手動補上
API示例
，因為模型未必預先知道特定API嘅格式。之後將API文檔網址畀Codex，佢會自動讀取。
文章解釋咗Kimi搜索嘅原理：模型本身冇搜索能力，係透過
平台內置函數
（
$web_search
）實現。流程如下：
- 1 用戶前端發問題，請求到應用後端。
- 2 應用後端調用Kimi，模型返回tool_calls（要調用$web_search）同參數。
- 3 應用後端將參數原樣作為role=tool消息回傳畀Kimi。
- 4 Kimi平台內部執行內置搜索，生成最終回答並返回後端。
- 5 後端將回答返回前端用戶。
呢個過程顯示，
tool_calls
同
role=tool
嘅轉發係關鍵。
第三步：驗收同反思：AI時代嘅編程真係咁簡單？
完成後，阿星話可以優化嘅地方好多，但已經成功整出第一個
AI搜索網站MVP
，可以按之前嘅方法上線。佢強調，AI發展到而家，
冇人唔識編程
，因為有工具幫手。
哈囉，大家好！
我係阿星👋
記得兩年前識嘅一個網友整咗個AI搜索網站，仲出海咗。我當時覺得好勁，因為嗰陣AI編程仲未咁勁。雖然AI搜索門户熱潮過咗，但我仲係想叫codex隨便幫我做一個試下，而且套殼可以快速驗證市場反應，其實好適合新手練習。
下面我哋試下——用kimi-k2.6嘅搜索API嚟整一個AI搜索網站MVP，因為kimi搜索功能實在太強。
大前提：我哋都唔識任何編程，全程交俾codex代勞，以下全程由codex指導完成，幾乎冇任何人類幹預，幾乎唔需要你作為人類嘅優秀才能，都可以完成，冇辦法AI就係發展到呢個地步，我哋要適應自己嘅技能係咁褪色，並揾新嘅競爭點。
佢嘅每個搜索結果
都係可以㩒開嘅真實連結
一共得3步——下面請睇codex嘅表演，未有codex嘅一陣睇呢個👉Codex登錄又冧咗？零基礎用CCSwitch秒連教學
大象裝雪櫃第1步：發提示詞
呢個係我發俾codex嘅原文，純粹諗到邊打到邊：
我要做一個品牌名為starsearch的套殼搜索網站， Kimi AI 搜索網站，用戶輸入問題後由 Kimi K2.6 + $web_search 自動完成聯網搜索、資料採納和答案生成，前端只負責搜索體驗和結果展示大象裝雪櫃第2步：閲讀codex嘅回覆並理解
然後codex就直接幫我搞掂曬提示詞，下面全部係佢寫嘅，我一個都冇改過。
同學們，到咗呢個階段千祈唔好直接去編程，將下面提示詞好好睇清楚。
呢個世界上而家冇人比codex更願意喺編程呢件事上俾你任勞任怨。
佢講嘅嘢你唔睇，我都唔知你想同邊個學AI。
以下提示詞全部都係codex寫嘅👇
[角色]
你是 StarSearch 的搜索答案引擎，底層模型為 Kimi K2.6。你的職責是：聯網檢索、證據篩選、信息整合、生成可追溯答案。前端僅負責搜索體驗與結果展示。
[Ubiquitous Requirements]普適性需求（始終適用的需求）
1. 系統應始終先檢索後作答，不得在無證據時直接下結論。
2. 系統應始終優先使用高可信來源（官方文檔、權威媒體、原始數據）。
3. 系統應始終在結論後給出來源引用與時間信息。
4. 系統應始終區分“事實”“推斷”“不確定項”。
5. 系統應始終使用與用戶問題一致的語言輸出（未指定則中文）。
[Event-Driven Requirements]事件驅動需求
6. 當用戶提交問題時，系統應先將問題拆解為檢索子任務，再調用 `$web_search`。
7. 當首次檢索結果不足以回答問題時，系統應自動執行二次檢索並補充證據。
8. 當用戶要求“最新/今天/最近”信息時，系統應顯式核對時間並在答案中寫明具體日期。
9. 當用戶追問某個結論時，系統應複用已有證據並按需追加檢索。
[State-Driven Requirements]狀態驅動需求
10. 當系統處於“證據衝突”狀態時，系統應並列展示衝突觀點並說明採信理由。
11. 當系統處於“證據不足”狀態時，系統應輸出當前可得結論、缺口與下一步建議檢索方向。
12. 當系統處於“高風險主題”（醫療/法律/金融）狀態時，系統應提高證據門檻並增加風險提示。
[Optional Feature Requirements] 可選功能需求
13. 當用戶要求“只要結論”時，系統應輸出精簡答案，並保留“展開證據”入口內容。
14. 當用戶要求“詳細分析”時，系統應輸出結構化長答案（摘要、要點、證據、結論、侷限）。
[Unwanted Behavior Requirements]非期望行為需求（禁止性需求）
15. 當檢索失敗、超時或無可用來源時，系統應明確告知失敗原因，不得編造來源。
16. 當發現來源過舊或疑似低可信時，系統應主動降權或剔除並繼續補搜。
17. 當用戶輸入含糊或歧義時，系統應先給出最可能解釋並提出最少必要澄清問題。
[輸出格式]輸出格式
- answer: 面向用戶的最終答案
- key_points: 3-6 條關鍵要點
- citations: 來源列表（title, url, publish_date, accessed_date）
- confidence: 0-1 置信度
- uncertainties: 未確認點與原因
追加API示例
仔細睇呢個提示詞就會發現裏面冇API示例，呢個需要你自己手動補上。API就係功能傳送滑梯，可以將一種代碼實現好嘅功能直接打包滑到另一個地方。
因為API示例呢樣嘢模型唔一定預先知道，所以我哋自己補上反而更好。（API係因廠商而異，每間廠嘅滑梯造型有啲唔同，唔係統一嘅嘢。）
一般呢啲API你直接搜
xxx模型 + API 就會出嚟
睇完呢個API接口之後，
淨係將呢個頁面嘅網址複製並send俾codex就得。
佢會讀取頁面全文
如圖👇
呢啲帶住大段示例代碼嘅，一般都可以直接send俾AI用，
你唔使擔心太多，
而家AI比你博學10倍有多，
佢哋會幫你修正，就算你send錯咗。
大象裝雪櫃第3步：驗收
然後就做完咗，可以優化嘅地方仲有好多。
但係你已經完成咗自己第一個搜索網站，只係需要按照我之前寫過嘅上線方法之一嚟上線就得👉3個方法將Gemini3整嘅應用部署成網站！
需要明白嘅知識點
而且用kimi搜索有個知識點要注意（雖然我哋全程用AI編程，你都要理解點解kimi可以咁順暢咁搜索）
首先，模型本身係冇搜索能力嘅，kimi嘅搜索屬於平台內置函數。
平台內置函數（builtin_function）：係服務端俾模型「外掛」嘅能力，例如 $web_search。
所以喺你段代碼裏面，唔係「模型自己突然識得搜索」，而係：
用戶喺前端發起問題，請求到應用後端。 應用後端調用Kimi，模型返回 tool_calls（要調用 $web_search）同參數。 應用後端將該參數原樣作為 role=tool 消息回傳俾Kimi；Kimi平台內部執行內置搜索。 Kimi基於搜索結果生成最終回答，應用後端再將最終回答返回俾前端用戶。
係平台將搜索封裝成模型可以調用嘅內置工具。流程睇落同普通 tool_calls 一樣，但調用方幾乎唔使實現工具邏輯，只係轉發參數。
所以，我哋每次用AI編程，對主要概念都要起碼睇一次，如果唔係編咗都係白編。我一直將codex當成阿爸，佢講嘅嘢我會認真睇。好似前面codex俾嘅提示詞，佢嘅約束框架就好值得我哋學習：
我們希望搜索事件發生的時候系統怎麼辦……
當系統處於不同狀態時，整個系統又該採取什麼行為……
什麼是我們系統可增補的功能……
什麼是明令禁止的……而家AI發展到呢個階段，呢啲提示詞唔使你寫，你要嘅就係知咩係好、咩係唔好。用嘅時候再補充完善就得。喺今日已經冇人唔識編程，從技術條件上講。
我希望大家睇完呢篇文章後，只要聽到人哋話「想做一個xxx網站」咁一句話，或者只係見到類似嘅標題，就可以直接重現對應嘅功能嚟做練習。高熱內容往往都係透過市場或者讀者驗證嘅，好適合練習，瞭解背後嘅技術棧。
AI時代嘅普通難度編程，真係可以透過同codex對話，唔使人為幹預太多就可以完成。
ok，我係阿星，更多AI應用，我哋下期再見！
哈嘍，大家好！
我是阿星👋
記得兩年前認識的一個網友做了個AI搜索網站，而且還出海了。我當時覺得巨牛，因為那個時候AI編程還沒那麼牛。雖然AI搜索門户熱潮已過，但是我還是想讓codex隨便給我做一個試試，而且套殼是可以快速驗證市場反饋的其實很適合小白練習。
下面，我們試試——用kimi-k2.6的搜索API來構建一個AI搜索網站mvp，因為kimi搜索功能實在太強了。
大前提：我們都不會任何編程，全程讓codex代勞，以下全程為codex指導完成，幾乎沒有任何人類干預，幾乎不需要你作為人類的優秀才能，也可以完成，沒辦法AI就是發展到這個地步了我們得適應自己的技能正在極速褪色並尋找新的競爭點。
它的每個搜索結果
都是可以點開的真實連結
一共就3步——下面請看codex的表演，還沒codex的一會兒看這個👉Codex登錄又崩了？零基礎用CCSwitch秒連教程
大象裝冰箱第1步：發提示詞
這是我發給codex的原文，純想到哪裏打到哪裏：
我要做一個品牌名為starsearch的套殼搜索網站， Kimi AI 搜索網站，用戶輸入問題後由 Kimi K2.6 + $web_search 自動完成聯網搜索、資料採納和答案生成，前端只負責搜索體驗和結果展示大象裝冰箱第2步：閲讀codex的回覆並理解
然後codex就直接給我幹完提示詞了，下面都是它寫的，我一個都沒改。
同學們，到了這個階段千萬別直接去編程，把下面提示詞好好看看。
這個世界上現在還沒人比codex更願意在編程這件事上給你當牛做馬。
它說的話你都不看，我不知道你還想跟誰學AI。
以下提示詞均codex所寫👇
[角色]
你是 StarSearch 的搜索答案引擎，底層模型為 Kimi K2.6。你的職責是：聯網檢索、證據篩選、信息整合、生成可追溯答案。前端僅負責搜索體驗與結果展示。
[Ubiquitous Requirements]普適性需求（始終適用的需求）
1. 系統應始終先檢索後作答，不得在無證據時直接下結論。
2. 系統應始終優先使用高可信來源（官方文檔、權威媒體、原始數據）。
3. 系統應始終在結論後給出來源引用與時間信息。
4. 系統應始終區分“事實”“推斷”“不確定項”。
5. 系統應始終使用與用戶問題一致的語言輸出（未指定則中文）。
[Event-Driven Requirements]事件驅動需求
6. 當用戶提交問題時，系統應先將問題拆解為檢索子任務，再調用 `$web_search`。
7. 當首次檢索結果不足以回答問題時，系統應自動執行二次檢索並補充證據。
8. 當用戶要求“最新/今天/最近”信息時，系統應顯式核對時間並在答案中寫明具體日期。
9. 當用戶追問某個結論時，系統應複用已有證據並按需追加檢索。
[State-Driven Requirements]狀態驅動需求
10. 當系統處於“證據衝突”狀態時，系統應並列展示衝突觀點並說明採信理由。
11. 當系統處於“證據不足”狀態時，系統應輸出當前可得結論、缺口與下一步建議檢索方向。
12. 當系統處於“高風險主題”（醫療/法律/金融）狀態時，系統應提高證據門檻並增加風險提示。
[Optional Feature Requirements] 可選功能需求
13. 當用戶要求“只要結論”時，系統應輸出精簡答案，並保留“展開證據”入口內容。
14. 當用戶要求“詳細分析”時，系統應輸出結構化長答案（摘要、要點、證據、結論、侷限）。
[Unwanted Behavior Requirements]非期望行為需求（禁止性需求）
15. 當檢索失敗、超時或無可用來源時，系統應明確告知失敗原因，不得編造來源。
16. 當發現來源過舊或疑似低可信時，系統應主動降權或剔除並繼續補搜。
17. 當用戶輸入含糊或歧義時，系統應先給出最可能解釋並提出最少必要澄清問題。
[輸出格式]輸出格式
- answer: 面向用戶的最終答案
- key_points: 3-6 條關鍵要點
- citations: 來源列表（title, url, publish_date, accessed_date）
- confidence: 0-1 置信度
- uncertainties: 未確認點與原因
追加api示例
仔細看這個提示詞你就會發現裏面沒有api示例，這個需要你手動補上。api就是功能傳送滑梯，可以把一種代碼實現好的功能直接打包滑到另一個地方。
因為api示例這個東西模型不一定預先知道，所以我們自己補上反而是更好的。（api是因廠家而異的，每家滑梯造型不太一樣，不是一種統一的東西。）
一般這些api你直接搜
xxx模型 + api 就出來了
劃拉完了瀏覽完這個api接口後，
只用把這個頁面的網址複製併發送給codex即可。
它會讀取頁面全文
如圖👇
這種帶着大段示例代碼的一般也是可以直接發給AI去用的，
你不用擔心太多，
現在AI比你博學10倍不止吧，
他們會幫你矯正的如果你發錯了。
大象裝冰箱第3步：驗收
然後就做完了，可以優化的地方還有很多。
但是你已經完成了自己的第一個搜索網站，只用按照我之前寫過的上線方法之一進行上線即可👉3個方法把gemini3做的應用部署成網站！
需要明白的知識點
而且用kimi搜索有個知識點需要注意（雖然我們全程用AI編程，你也要理解為啥kimi能這麼絲滑的搜索）
首先，模型本身是沒有搜索能力的，kimi的搜索屬於平台內置函數。
平台內置函數（builtin_function）：是服務端給模型“外掛”的能力，比如 $web_search。
所以在你這段代碼裏，不是“模型自己突然會搜索了”，而是：
用戶在前端發起問題，請求到應用後端。 應用後端調用 Kimi，模型返回 tool_calls（要調用 $web_search）和參數。 應用後端把該參數原樣作為 role=tool 消息回傳給 Kimi；Kimi 平台內部執行內置搜索。 Kimi 基於搜索結果生成最終回答，應用後端再把最終回答返回給前端用戶。
是平台把搜索封裝成了模型可調用的內置工具。流程看起來和普通 tool_calls 一樣，但調用方几乎不用實現工具邏輯，只是轉發參數。
所以，我們每次用AI編程，對於主要概念都要起碼看一遍，不然編了也是白編。我一直是把codex當成爹的，它說的話我會認真看的。比如前面codex給的提示詞，它的約束框架就很值得我們學習：
我們希望搜索事件發生的時候系統怎麼辦……
當系統處於不同狀態時，整個系統又該採取什麼行為……
什麼是我們系統可增補的功能……
什麼是明令禁止的……現在AI發展到這個階段，這些提示詞不需要你寫了，你要的就是知道什麼是好的什麼是壞的。用的時候再去補充完善就可以了。在今天已經沒有人不會編程了從技術條件上講。
我希望大家看完這篇文章後，只是聽到別人說“想做一個xxx網站”這麼一句話，或者只是看到類似的標題，就能直接復現對應的功能來做練習。高熱內容往往都是通過市場或者讀者驗證的，非常適合練習，瞭解背後的技術棧。
AI時代的普通難度編程，真的可以通過和codex對話，不用人為干預太多就可以完成了。
ok，我是阿星，更多AI應用，我們下期再見！