這是我在Kiro 黑客馬拉松期間使用的工作流程，借助 AI 編程助手，不到一周的時間，我就將一個想法從 Spark 變成了 MVP。你可以把它想像成腦力激盪、系統級檢查和嚴格篩選的組合。
為什麼速度很重要
黑客馬拉松是不會寬容的。你沒有幾個月的時間來討論功能——你只有幾天的時間。大多數專案失敗的原因是：
-
直接進入程式碼，無需測試假設。
-
跳過系統阻止程序（權限、清單、API 配額）。
-
沒有明確的成功標準。
我的方法恰恰相反。我並沒有先寫程式碼，而是先與想法進行鬥爭，將其提煉成精簡的 PRD（產品需求文件），然後才讓 AI 根據清單進行建置。
5步驟工作流程
1）從一個想法+殺戮標準開始
寫一句話，例如：對於需要解決[問題]的[使用者]，我們的應用[解決方案或服務]。這能讓你明確它的目標使用者以及它的功能。
然後設定終止標準－如果48小時內無法證明可行性，就轉向。這可以避免沉沒成本陷阱。
還要記住，這是對類固醇的編碼，因此半生不熟的產品很容易被丟棄，因為沒有沉沒成本陷阱。
2）用人工智慧助理來檢視這個想法
不要只是頭腦風暴，讓人工智慧列出以下功能：
-
好的、壞的和醜的。
-
身份驗證需求（OAuth、API 金鑰、令牌刷新）。
-
第三方服務和配額。
-
可能的故障模式。
📌 專業提示：強迫AI扮演魔鬼代言人。缺陷越早暴露，就越容易修復。
3）細化為 PRD.md + 清單
與人工智慧助理討論後，指示它生成
a verbose instructional PRD that a developer or an LLM would use to create a full product. The PRD should be structured in a workflow step by step with a checklist.
4）從 PRD 建置，而不是從記憶建置
將 PRD 交給 AI 並要求：
-
帶有複選框的任務清單。
-
指示它在完成一個步驟後標記一個複選框。
這樣，人工智慧就會在明確的約束範圍內進行建置，而不是自由猜測。
5）除錯、記錄、重複
首先偵錯系統阻止程式：清單問題、設定、API 金鑰。
當您的應用程式完全建立後，現在就可以偵錯啟動問題，如果您按照上面概述的步驟操作，這些問題大多是小問題。
產生入職文件：
現在你需要指示AI生成應用的完整詳細文件。這樣做是為了節省新會話的配額，而不是再次將整個程式碼推入上下文長度。
最好提示
_" Generate a full documentation for the app that a developer or LLM could use to upgrade features, use the PRD and the source code."_
- 更具影響力的一步
將文件儲存在 repo 中。
在新的會話中，要求 AI 在編碼之前「閱讀文件」。
📌 更改程式碼時務必更新文件 — — 這可讓 AI 和未來的開發人員保持同步。
那是
當您進行功能變更時，請務必指示 AI 更新相關文件。
我遇到的陷阱（所以你不會遇到）
AI程式碼並非萬無一失。它可能會對API產生幻覺，或錯過權限。由於您擁有PRD和文件，因此您可以輕鬆清除會話並追蹤進度。
成本快速累積。儘早模擬 API 支出。
設計仍然需要人類。 AI 可以建立框架，但 UI/UX 的品味取決於你自己。
📌始終使用 git
為什麼 Kiro 非常適合
Kiro 簡化了這個循環：腦力激盪 → 審查 → 產品需求文件 → 建置 → 除錯 → 文件。由於工作流程是模組化的，我可以快速適應，追蹤變化，並避免大多數週末駭客專案陷入的混亂。
最後，我得到了一個可執行且有文件記錄的 MVP — — 而不僅僅是一堆程式碼。
結束語
有了結構化的工作流程和 AI 規則， 「一週內實現 MVP」並非空談，而是可以重複的。真正的訣竅在於儘早明確目標，並且絕不跳過清單。
**Feel free to leave a comment or a query!**
原文出處：https://dev.to/brian_mk/creating-a-market-viable-app-in-less-than-week-gc7
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
