跳至主要內容
AppFoyer
免費開始

透過程式設計代理讓應用程式符合商店要求

你的代理會讀取眼前的應用程式(SDK、權限、套件 ID),並根據找到的內容草擬每個合規頁面。你閱讀草稿並發布它們。代理做不到這一步。

開始之前

你需要 Claude Code 和一個 AppFoyer 帳戶。免費方案就夠了:建立一個帳戶。不需要建立金鑰:代理第一次連線時,會請你在瀏覽器中核准。

完全沒有程式設計代理?在瀏覽器中填寫六個欄位,不用外掛程式也能得到同樣的五個頁面。

沒有使用 Claude Code?外掛程式需要它,但隱私權政策和服務條款頁面不需要:儀表板中的這兩個編輯器各有一段已填入應用程式詳細資料的提示詞,你可以在任何 AI 助理中執行再貼回來。完整內容刊登在隱私權政策指南和服務條款指南中。

安裝

claude
/plugin marketplace add appfoyer/claude-plugin
/plugin install appfoyer@appfoyer

開始時不需要帳戶:代理會在你的電腦上讀取建置、顯示它找到的內容並提出問題,只有在有東西要儲存時才會請你連線。它第一次呼叫 AppFoyer 時,瀏覽器會開啟一個核准頁面:登入或建立免費帳戶,確認名稱以及瀏覽器會返回的位置,然後核准。Claude Code 會保存這個連線並自行續期;不需要複製任何東西,也不會在你的 shell 中儲存任何東西。如果瀏覽器沒有開啟,請執行 /mcp,選擇 appfoyer,再選擇 Authenticate。在 Claude Code 桌面應用程式中,請先從終端機用這個方式連線一次,再到桌面應用程式中開始新的工作階段:已經在執行中的工作階段看不到新的連線。在儀表板的 Agent 頁面中中斷連線後,下一次呼叫就會立即失敗。Claude Code 不會自行重新整理第三方市集:請在 /plugin → Marketplaces → appfoyer 中選擇 Enable auto-update,才能收到新版本。

那台電腦上沒有瀏覽器,例如遠端伺服器、容器或指令碼執行?請改用 API 金鑰:在 Agent → API key — for CI and headless use 下建立一把,照上面的方式安裝外掛程式以取得工作流程,然後再新增一次伺服器,並在標頭中放入金鑰:

export APPFOYER_API_KEY=cpk_…
claude mcp add --transport http appfoyer-key https://app.appfoyer.com/mcp --header "Authorization: Bearer $APPFOYER_API_KEY"

外掛程式只會從那個環境變數讀取金鑰:技能永遠看不到它,它只會放在 Claude Code 填入的 Authorization 標頭中傳送。

其他 MCP 用戶端(claude.ai、Claude Desktop、Cursor、VS Code)也可以用同樣的方式、同樣的核准頁面連線到 https://app.appfoyer.com/mcp。它們會取得這些工具;讀取你建置檔案的逐步工作流程,則隨 Claude Code 外掛程式提供。

要說什麼

請在你應用程式的存放庫中執行這些指令,而不是在空的目錄中:

要說的話會發生什麼事
Make this app store-ready 掃描建置檔案,確認它無法推導出的事實,草擬每個頁面,並傳回檢閱連結。
Is this app store-ready? 依照合規檢查清單進行唯讀稽核。不寫入任何內容。
Wire the store-ready links into the app 在你發布之後:以差異檔的形式提出應用程式內隱私權政策和支援連結的修改,讓你檢閱。
Add the AppFoyer drift check 提出一個 GitHub 工作流程,標出新增了頁面可能未涵蓋的 SDK 或權限的提取要求。運作方式。

範例

用你自己的話說就好;以下是這項技能能處理的情況。

一個應用程式,第一次執行

> Make this app store-ready
  • 列出它在建置檔案中找到的內容(SDK、權限、套件 ID),每一項都附上檔案和行號。
  • 只詢問它找不到的資訊:公司名稱、支援電子郵件、管轄地區、商店連結。最多兩輪。
  • 建立應用程式,從存放庫上傳圖示,並草擬全部五個頁面。
  • 最後提供檢閱連結。在你於該處發布之前,什麼都不會公開。

變更後再次執行

> Make this app store-ready
  • 依應用程式 ID 找到既有的應用程式,並比較新的事實和已儲存的事實。
  • 只重新草擬受變更影響的頁面,例如新增分析 SDK 後的隱私權政策。
  • 除非你要求,否則不會更動圖示和網址。

多個 flavor,在提示詞中指名

> Make com.acme.weather.free and com.acme.weather.pro store-ready
  • 建立兩個應用程式,不會就選擇範圍提出任何問題。
  • 讀取每個 flavor 自己的資料夾、名稱和相依項目。只有 free flavor 使用的廣告 SDK,不會寫進 pro flavor 的隱私權政策。
  • 傳回檢閱連結,以及每個 flavor 的控制台網址表格。

多個 flavor,未指名

> Make this app store-ready
  • 列出各個 flavor 及其應用程式 ID,預設全部選取,由你挑選哪些要有網站。
  • debug 和 staging 等建置類型會列為已排除,而不會提供選擇。

品牌 × 環境維度

> Make every brand store-ready
  • 列出組合(brandAProd、brandBProd),而不是單一 flavor。
  • 只提供正式環境。dev 和 qa 永遠不會發布到商店。
  • 當建置把應用程式名稱放在 Gradle(resValue、manifestPlaceholders)或移動過的 source set 中時,會從那裡讀取。
  • 如果無法判斷某個維度是環境還是品牌,它會詢問你。

自訂網址(Pro 和 Advanced)

> Make this app store-ready
  • 根據應用程式的英文名稱產生網址,例如 weather-now。
  • 如果該網址已被使用或與品牌名稱太相近,它會嘗試下一個(weather-now-app、acme-weather),最多五次,然後詢問你。
  • 在免費方案中,它會保留 app-… 網址,並說明自訂網址屬於 Pro。
  • app-… 網址會繼續提供同一個網站。

變更你已在使用的網址

> Change the address to weather-radar
  • 會先詢問。舊的自訂網址會立即釋出,仍寫著它的商店資訊頁就會失效。
  • 只有在你同意後才會變更。

更新圖示

> Update the app icon
  • 找出啟動器圖示:Play 512 圖示、最大的 mipmap 圖片,或 iOS AppIcon 行銷圖片,優先使用該 flavor 自己的圖示。
  • 如果超過 512 KB,它會在暫存資料夾中縮小一份副本。你的存放庫不會被更動。
  • 告訴你上傳了哪個檔案。在已發布的應用程式上,新圖示會立即上線。

有廣告的應用程式

> Make this app store-ready. AdMob publisher id pub-0000000000000000
  • 根據你提供的行撰寫 app-ads.txt。發布商 ID 不在你的程式碼中,所以它絕不會猜測。
  • 提醒你在商店資訊頁中把網站設為開發人員網站。
  • AdMob 已驗證我們網址上的 app-ads.txt 檔案;請給它最多 24 小時檢索。

讓頁面與建置保持同步

> Add the AppFoyer drift check
  • 每次執行「make this app store-ready」,都會在存放庫根目錄寫入 appfoyer.json:記錄頁面撰寫時依據的 SDK、資料類型和權限。它由檢查所使用的同一個掃描器寫入,絕不手動撰寫。
  • 這個提示詞會為免費的 appfoyer/check-action 顯示一個 GitHub 工作流程,你同意後就寫入 .github/workflows/appfoyer.yml。它絕不會覆寫你已有的檔案。
  • 從那之後,每個提取要求都會列出自頁面撰寫以來新增或移除的項目,並附上檔案和行號。再次執行外掛程式就會更新草稿和 appfoyer.json。
  • 不會替你提交任何東西。關於讓隱私權政策保持同步的指南,有詳細說明和其他 CI 系統的設定方式。

只檢查,不變更任何東西

> Is this app store-ready?
  • 為每個相符的應用程式執行檢查清單,並回報缺少什麼。不寫入任何內容。
  • 還沒有應用程式的 flavor 會回報為缺少。

把連結放進應用程式

> Wire the store-ready links into the app
  • 需要已發布的頁面。
  • 針對設定畫面或字串中的隱私權政策和支援連結提出差異檔。只有在你同意時才套用,而且絕不提交。

哪些資料會離開你的電腦

只有推導出的事實:

  • 應用程式的名稱、平台,以及套件或應用程式 ID;
  • 在你的建置檔案中找到的 SDK 和權限的名稱;
  • 你確認的答案:公司名稱、支援電子郵件、管轄地區、商店網址;
  • 代理草擬的頁面文字,會以草稿形式儲存在你的帳戶中;
  • 應用程式自己的圖示,透過單次使用的上傳連結傳送一次。

沒有其他檔案,絕不傳送原始碼,也絕不傳送在存放庫中找到的機密或金鑰。代理傳送的內容,本來就是隱私權政策必須寫明的事項。

有一個檔案會寫進你的存放庫並留在那裡:appfoyer.json,記錄頁面撰寫時的依據,由外掛程式內附的掃描器建立。它不會被傳送到任何地方。代理絕不會提交它或任何其他東西,提交由你來做。

代理不能做的事

不論透過瀏覽器還是 API 金鑰連線,外掛程式持有的都是代理憑證,所以它完全無法發布。這是在伺服器端強制執行的,而不是靠客氣地拜託代理:

  • 沒有發布工具。代理寫的是草稿;你的上線頁面不會改變。
  • 有兩樣東西沒有草稿:圖示和自訂網址。在已發布的應用程式上,它們會立即變更上線網站,而代理設定它們時會告訴你。未經你同意,它無法替換你已在使用的自訂網址。
  • 發布頁面的 REST 路由會直接拒絕代理憑證,只接受工作階段。
  • 每個頁面在發布時,仍會經過和手寫編輯相同的內容篩檢。
  • 每次代理呼叫都會記錄在帳戶的稽核記錄中,並註明發出呼叫的連線或金鑰。

所以連線或金鑰外洩時,最糟的情況是要捨棄一些草稿、錯誤的圖示或一個新網址,而不是有頁面以你的名義公開。

它取得的工具

外掛程式會連線到一個 MCP 端點,該端點只公開以下工具:

工具用途
list_apps 讀取 帳戶上的每個應用程式,包括 slug、公開網址,以及是否有任何內容已發布。
get_app 讀取 單一應用程式:設定、已儲存的資料收集事實,以及每個頁面的上線文字、發布狀態和待處理草稿。
create_app 寫入 以範本頁面建立應用程式。不會公開任何內容。
create_apps 寫入 一次呼叫最多建立十個應用程式,每個產品 flavor 一個。每個一開始都未發布。
update_app 寫入 變更設定、已儲存的資料收集事實或 SDK 清單。絕不編輯頁面文字。
set_page 寫入 為單一頁面寫入草稿。上線頁面不受影響。
set_ad_lines 寫入 取代 app-ads.txt。只有在有廣告 SDK 且你提供了發布商 ID 時才會使用。
get_checklist 讀取 伺服器計算出的商店就緒檢查清單,以及哪些頁面仍有未發布的草稿。
get_store_forms 讀取 根據事實和 SDK 清單,為 Google Play 的 Data safety 表單和 Apple 的 App Privacy 詳細資料草擬答案。由你自己在控制台中填入。
request_publish 寫入 表示草擬已完成,並傳回檢閱網址。不會發布任何東西。
set_icon 寫入 傳回應用程式圖示的一次性上傳網址。立即上線:圖示沒有草稿。
check_slug 讀取 依照和儀表板相同的規則,檢查自訂網址(Pro 和 Advanced)。
set_slug 寫入 取得自訂網址。立即上線。除非你已同意,否則拒絕替換你已有的網址。

出問題時

症狀原因
工具顯示「needs authentication」 連線從未獲得核准,或已被中斷。請執行 /mcp,選擇 appfoyer,再選擇 Authenticate。
核准頁面說這個要求無法使用 連結已過期,或被開啟了兩次。請從編輯器重新開始;沒有建立任何連線。
使用 API 金鑰時出現 unauthorized 金鑰已在儀表板中撤銷,或屬於另一個帳戶。請建立新的金鑰,再重新匯出。
發布時傳回配額錯誤 方案的已發布應用程式上限已用完。應用程式和它的草稿都會保留:取消發布另一個應用程式或升級方案,再從檢閱畫面發布。
草稿被拒絕或保留待審 內容篩檢比對到了某些內容。原因清單會列出比對到什麼以及如何修正;編輯後重新送出即可。公開內容沒有任何變更。

有一件事不會因此改變

草稿是根據你的程式碼補完的範本,並非法律建議。代理寫得快,不代表內容就正確:發布之前請讀過它寫的內容,尤其是你的應用程式收集哪些資料的清單。商店要追究責任的對象是你。

有問題請來信:support@appfoyer.com。