文章摘要
- 誰做了什麼：攝影師杉山伸嗣、2011iPhone應用程式「COSPLAY SHOWCASE」在2018年App Store排名第二。、使用人工智慧作為網路應用程式復活。
- 綜上所述，：人工智慧並不是透過「丟掉一切」來運作的。但是，如果您擁有“構建並通過需求”的技術、過去的資產肯定與現在相關。
- 你從這篇文章得到什麼：透過實際的AI聯合開發揭示“AI失敗的模式”和“正確操作AI的5條規則”。
介紹：你也有「沉睡資產」嗎？
舊應用程式、已停止工作的 Web 服務、未轉換為數位資料的作品——。
「我當時所做的。、我相信很多人都想過，「我想用今天的技術再做一次」。。但現實中、在「技術壁壘」和「時間成本」面前、大多數項目被放棄。
我是2026年黃金週、我用人工智慧迎頭撞上了那堵牆。。
15一款名為“COSPLAY SHOWCASE”的iPhone應用程序，一年前在App Store上排名第二。、這是一個將其恢復為網路應用程式的專案。。不是一個完整的工程師、從「會編碼的攝影師」的角度來看。
「有了人工智慧，幾個小時就可以完成。」曾經有一段時間我也這麼想。。
現實有所不同。
挑戰的背景：分析 IPA/APK 的日期
起初，我所擁有的只是「二元」。
我能為這個專案做的準備是、當時只有以下幾種。
- iOS版本IPA文件（iPad/iPhone應用程式的「內容」已打包。、安裝包）
- 安卓版APK文件（這就是Android應用程式的「真實身份」。、一組用於安裝的檔案）
- 當時的 JPEG 影像和 UI 螢幕截圖
- 應用介紹頁面文字
- 我自己的“造物主記憶”
最大的問題是、沒有留下完整的原始碼。。
換句話說，該專案的出發點是、逆向工程從一開始就是前提。。
當你讓克勞德分析時會發生什麼事？
第一次嘗試很簡單。
「如果我讓 Claude 閱讀 IPA/APK，、是否可以在某種程度上自動轉換為React？ 」
當前世代AI是React世代、TypeScript生成、Tailwind CSS構築、UI元件生成、糾錯糾錯－－這方面很強。這就是為什麼「使用人工智慧將舊應用程式變成網頁版本」的想法、看起來很現實。
反應:（組合“部分”、（創建螢幕的機制）順風CSS:（只需排列預定的“單字”、設計工具）
但當你真正動手的時候、情況完全不同了。
內含IPA、資源結構、影像檔案、一些配置資訊、我能夠確認捆綁配置。。但、Objective-C 時代重要的編譯程式碼是、我無法按原樣閱讀它。克勞德分析 IPA 並認識到“類似結構的東西”。但UI遷移、gesture設計（對手指動作的「反應」設計）、狀態管理、動畫意圖這是、幾乎不可能恢復。
Android APK端是XML佈局和drawable（圖像、形狀等、（螢幕上顯示的「材料資料」的總稱）相對保持、讀起來有點容易。然而，這裡也出現了一個根本問題：人工智慧可以讀取“存在的東西”。但我不明白他們為什麼要這樣設計。。
為什麼影像會按這個順序排列？。為什麼這個時候切換呢？。為什麼滑動速度這麼快？。這些設計意圖是、不以二進位形式記錄。換句話說UI/UX 的哲學是、沒有被AI恢復。
這是、這是第一堵大牆。。
面臨絕望：3兩個“地獄”
隨著專案的進展、具體問題接二連三地出現。。
地獄1：UI構造崩壊
第一個提示是這樣的。
「從這個 IPA/APK 結構、反應 + 請使用 Tailwind CSS 重建等效的 UI。 」
結果是、已經很破了。
AI透過猜測開始組裝螢幕。但等級制度（階層）、國家結構（資料管理規則）、component分割（分成幾部分）與真實應用程式不同。產生“看起來像這樣，但又不同”。。即使在 Tailwind CSS 中、過度實用、響應崩潰、z-index事故、手機溢出頻傳。最常見的答案是“在 PC 上沒問題。”、這是一種「因智慧型手機而崩潰」的模式。
過度實用：（設計說明太多。、程式碼變成“咒語”）響應崩潰：（如果改變螢幕尺寸、（看起來很「亂」）z-index事故：（零件的重疊順序是亂序的。、（按鈕變成「埋藏」狀態，無法按下）移動溢出：（超出螢幕寬度）、左右搖晃）
地獄2：損壞的滑動行為
這件事特別嚴重。。
COSPLAY SHOWCASE的核心是“輕彈旋轉照片”。然而，AI使用慣性滾動、管理拖曳狀態、觸摸取消處理、我在實現移動手勢時犯了很多錯誤。。
觸摸取消；（觸摸的手指、（離螢幕或停用狀態）
因此、
- 被抓到
- 跳
- 向相反方向移動
- 只有手機壞了
經常發生。尤其是在行動裝置 Safari 中、觸摸動作、溢出、被動事件、在圖像渲染方面相當困難。
觸摸動作：（觸碰螢幕時「允許捲動」設定）溢出：（是否「隱藏或顯示」從框架突出的部分的規則）被動事件：（滾動「平滑移動」的初步訊號）影像渲染：（指定影像應該看起來清晰還是平滑）
觸覺是人工智慧最薄弱的領域。。 外觀可再現。然而，「手指分離」、「慣性重量」、「滑動速度」和「動畫時機」——這些不能僅由邏輯來決定。。最終，人類別無選擇，只能察覺到這種不適。。
地獄3：state循環地獄
這種情況在移植 React 時尤其頻繁發生。。
人工智慧即將到來useEffect（「自動連結」的自動處理）想寫。因此、無限重新渲染、state循環、圖片預載失控。
我試圖修復一個稱為收藏夾顯示的包裝佈局的錯誤。、我進入了“無限調試循環”，其中每次修改都會破壞不同的部分。。
- 垂直對齊 → 正確 → 標題順序顯示被打亂
- 修復→圖像大小變化→修復→水平滾動消失
- 嘗試將其重新組裝 → 另一部分損壞
人工智慧一次又一次無視同樣的禁令。忘記之前對話的上下文並倒退。
經過這個過程、我終於開始明白AI合拍的「本質結構」。。
由此衍生出的《AI協作五法則》
人工智慧不起作用，因為它是“折騰”。但是，如果你了解“如何操作AI”、過去的資產肯定與現在相關。以下是、以下是從這次經驗中提取的五條規則。。
規則1：將其作為“設計文件”而不是“請求”
對人工智慧來說最重要的指令是什麼？、模糊的要求結構化條件是將其轉換為。
❌ 失敗指令範例
“我希望它根據瀏覽器寬度自然換行。”
透過這條指令，AI為Tailwind生成了靈活的佈局。。但它破壞了COSPLAY SHOWCASE的橫向滾動UI。“自然折疊”對於人工智慧來說意味著“垂直堆疊”。
✅ 工作說明範例
- 垂直排列絕對不行。
- 始終保持水平滾動
- 保持圖像大小與標題順序相同
- 不要失去行數的平衡
差別不在於“你想讓我做什麼”、明確說明不該做什麼是。人工智慧受到的限制越多，、容易向正確的方向收斂。即使是修改滑動行為。、有一系列具體的禁止和條件，例如“不添加慣性”、“滑動速度恆定”、“移動 Safari 優先”、“加載圖像時禁止佈局移動”、這是最有效的指導。
規則2：設計時考慮到人工智慧的“遺忘”
人工智慧維護上下文的能力有限。在一次長時間的談話中、上半場決定的規格往往在下半場被忽略。。
其實在我的專案中、規則應該是“禁止水平滾動”、有很多情況下，AI會在幾十回合後崩潰，就像什麼都沒發生一樣。。修復狀態循環問題時也是如此、再次使用useEffect，這是先前對話中禁止的。、這又被重複了。
措施是“在每次會議開始時列出違禁物品清單。”就是這樣。。
【このセッションの絶対条件】
・横スクロールUIは変更しない
・画像サイズは既存の仕様を維持
・縦並びレイアウトは使用禁止
・useEffectの新規追加は禁止每次只需將其插入提示的開頭即可、人工智慧「落後」事故將大幅減少。不依賴過去的對話歷史、在每個提示處定義狀態這是人工智慧共同開發的基本禮儀。。
規則3：只要「理解程式碼的意思」就會為你帶來壓倒性的優勢。
您不必成為一名完整的工程師。但你也不能成為一個「完全的業餘愛好者」。。
當Claude說“這是由第687行的perRow計算引起的”、就看你能否理解其中的意思、下一指令的準確性會發生巨大變化。。就我而言、因為我至少能夠理解 React 狀態是如何循環的。、我能夠給出準確的更正指示，例如“請簡化狀態”和“請分離縮圖狀態”。
重要的不是寫程式的能力。、``試圖理解錯誤意義的態度。「是。即使你只是簡單地將錯誤訊息複製並貼上到人工智慧中並詢問“為什麼會發生這種情況？”、打開解決方案的道路。
程式設計的基本概念（變數、功能、環形、了解條件分支的人）、人工智慧時代「中產階級」最強陣地我在。來自編寫程式碼的人、能調整的人的價值、未來將會上升。
每行計算：（根據螢幕寬度自動調整「每行項目數」的計算）反應狀態：（應用程式此時記住的「記憶」）縮圖狀態：（正在選擇「縮小影像」的記憶體）
規則 4：要知道「製造者的記憶」是最寶貴的財富。
這個項目最重要的是、不是技術或人工智慧性能。、事實上我自己就是這個應用程式的設計師原來是。
如果沒有規範，人工智慧就無法發揮作用。。但、即使沒有規格，如果您有“製造商的記憶”、它可以被翻譯成語言並傳遞給人工智慧。。
- 點擊時的「速度」旋轉動畫
- 水平滾動的“慣性重量”
- 展示空間中的“產生深度”
即使這些沒有被數位記錄，、我用創造者的身體來記住它。將這些記憶轉化為文字的能力、成為向AI傳遞藍圖的力量。
相反，這次、當我向 Claude 拋出第一個簡單提示時：“請從此 IPA/APK 結構重建等效的 UI”、AI輸出的是“那樣的不同的東西”。152015 年以來應用程式的獨特行為和感覺、沒有原始碼的AI無法恢復。。
恢復過去的資產時、在考慮人工智慧性能之前，你應該問的問題是“你能用語言表達這項工作嗎？”。
規則5：留下“失敗記錄”、成為主要訊息
不要掩蓋人工智慧失敗的事實。。
無限調試循環、我一遍又一遍地犯同樣的錯誤、還有一些功能無法解決（這個Together功能還沒完成）。、把一切都記錄下來。
由於某種原因。
「我把一切都投入到人工智慧上，幾個小時內就完成了。」的故事。、讀書的感覺真好。但不可重現。試著做同樣的事情、因為結果不會一樣。
另一方面、記錄諸如“當我指示它這樣做時它壞了”、“當我按照這個順序修復它時，另一個部件壞了”或“這個功能不起作用”等記錄。、為了下一個人撞到同一堵牆、成為具體的地圖。
成功故事讀起來很有趣。。但失敗的故事、可作為訊息。
人類與人工智慧的合作越多、「我在哪裡絆倒」和「如何重建？」等主要資訊的價值增加了。。誰有它、只有真正做到這一點的人。
實用清單：使用人工智慧恢復過去資產之前需要檢查的事項
- 關於你想要復興的作品、我是作為設計師/製作人參與的嗎？
- 您有「記憶」來描述當時的規格嗎？
- 對人工智慧的指令可以寫成「條件清單」而不是「請求」嗎？
- 您願意至少閱讀錯誤訊息的含義嗎？
- 你準備好記錄你的失敗和嘗試和錯誤了嗎？
- 你能放下幾個小時內就能完成的期望嗎？
6如果全部檢查完、您的專案很可能由人工智慧提供支持。
概括：人工智慧是“搭建橋樑的工具”、是人類完成了這座橋。
2011「COSPLAY SHOWCASE」誕生於、20262018年黃金週後、再次開始作為網路應用程式工作。
確實是因為AI才完成的。。但、確實，單靠人工智慧永遠無法完成這項任務。。
分析 IPA 和 APK、第一次嘗試讓克勞德「自動恢復」失敗。state循環地獄、損壞的滑動行為、無限調試循環——AI生成很快，但是、設計很粗糙。但透過那次失敗、我學會了“如何使用人工智慧”。
AI時代需要的不是“生產力”。隔離問題、UI観察力、檢測不適、組織規範、修正說明——這些能力。。
透過人工智慧將過去的資產與現在連結起來的工作、這不是為了“玩得開心”。「以前不可能發生的事情、使其成為可能”就是這樣。。
只有懂得差異的人、AIを本当の意味で使いこなせる。
🎭COSPLAY SHOWCASE WEB版を体験する https://nsp-jp.com/cosplayshowcase/app/
📖プロジェクト全記録（元記事） https://nsp-jp.com/blog/cosplay-showcase-web-ai-revival/
