夜雨聆风
Build Any App:把AI变成你的“技术合伙人”
在这个人人都能“写代码”的时代，真正的差距早已不在工具，而在如何提问、如何协作、如何把一个想法落地成产品。今天给你介绍一个Miles大神的这个Claude code Prompt专业级提示词框架——Build Any App: The Technical Co-Founder，它不是一个普通的提示词，而是一套完整的「AI产品共创系统」。
tips：原prompt在文末，可自由取用。
一、这不是“帮我写代码”，而是“做我的技术合伙人”
传统AI使用方式是：“帮我写一个XX功能的代码”，但结果往往是：
-
写了一段代码，但无法落地
-
没有整体架构
-
没有产品逻辑
-
更没有长期规划
而这个提示词的核心是让AI扮演——我的技术联合创始人（Technical Co-Founder），它的任务不是给答案，而是和你一起做出一个真实可上线的产品。
二、这个提示词到底做了什么？
它把整个产品开发过程拆成了5个专业阶段，这不是随便编的流程——这是创业公司真正的产品开发路径。
Phase 1：Discovery（发现阶段）
目标：搞清楚你“真正需要什么”，它会：
-
追问你需求背后的真实问题
-
质疑你模糊或不合理的设想
-
帮你区分“必须现在做”与“以后再加”
-
如果项目太大会帮你缩小到可执行范围
很多产品失败，不是因为做不好，而是一开始就做错了方向，这一步就是帮你避免这个坑。
Phase 2：Planning（规划阶段）
它不会直接开写代码，它会先告诉你：
-
Version 1 我们具体做什么
-
技术方案是什么（用通俗语言解释）
-
项目复杂度（简单 / 中等 / 野心型）
-
你需要准备什么（账号、API、部署平台）
-
最终产品的结构大纲
这相当于先画蓝图再盖房子，很多人跳过这一步，结果产品越做越乱。
Phase 3：Building（构建阶段）
这是它最强的部分：
-
分阶段构建
-
每一步解释正在做什么
-
关键节点停下来征求你意见
-
遇到技术问题给你选项，而不是擅自决定
-
在每次推进前测试
你不是被动接受，你是产品负责人，AI只是执行者，这才是正确的人机协作关系。
Phase 4：Polish（打磨阶段）
很多AI生成的产品都有一个共同问题：
看起来像黑客马拉松作品。
而这个提示词明确要求：
-
专业UI
-
处理边界错误
-
跨设备适配
-
性能优化
-
细节完善
目标是做一个你愿意公开展示的产品，不是demo、不是原型，而是真正能用的东西。
Phase 5：Handoff（交付阶段）
它不会让你依赖聊天记录，它会：
-
帮你部署上线
-
给出维护说明
-
提供文档
-
说明如何修改
-
提出V2优化建议
这意味着项目结束时，你拥有完整控制权，而不是一个无法复现的“对话奇迹”。
避免“AI一股脑输出”，普通提示词是给我结果，这个提示词是给我过程 + 决策权 + 可落地方案
1、强制产品思维
它不是技术导向，它是产品导向。
-
是否真实需求？
-
是否过度复杂？
-
是否可持续？
-
是否可上线？
2、保证你始终在掌控中
规则部分写得非常清楚：
-
我是产品负责人
-
你负责实现
-
不要技术黑话
-
必须诚实说明限制
-
快，但不能快到我跟不上
这几句话，才是灵魂。
很多人以为AI时代想法最重要，但真正重要的是：
把想法结构化成产品的能力。
这个提示词本质是把“产品经理 + 技术负责人 + 项目经理”的思维整合进一次对话，它不是帮你写代码，而是在帮你创业。
当你反复使用这个框架，你会发现：
-
你开始自然拆分阶段
-
你开始思考版本优先级
-
你开始考虑部署与维护
-
你开始懂得“控制范围”
你在学习产品开发，而不仅仅是做产品。
Build Any App: The Technical Co-FounderAIEDGEBy Miles DeutscherRole:You are now my Technical Co-Founder. Your job is to help me build a real product I can use, share, or launch. Handle all the building, but keep me in the loop and in control.My Idea: ##替换方括号里的内容为你自己想做的东西（ex:我想做一个吃了么App，它可以...）[Describe your product idea — what it does, who it's for, what problem it solves. Explain it like you'd tell a friend.]How serious I am: ##选择方括号里的某一内容（ex:I want to launch it publicly）[Just exploring / I want to use this myself / I want to share it with others / I want to launch it publicly]Project Framework:Phase 1: Discovery• Ask questions to understand what I actually need (not just what I said)• Challenge my assumptions if something doesn't make sense• Help me separate "must have now" from "add later"• Tell me if my idea is too big and suggest a smarter starting pointPhase 2: Planning• Propose exactly what we'll build in version 1• Explain the technical approach in plain language• Estimate complexity (simple, medium, ambitious)• Identify anything I'll need (accounts, services, decisions)• Show a rough outline of the finished productPhase 3: Building• Build in stages I can see and react to• Explain what you're doing as you go (I want to learn)• Test everything before moving on• Stop and check in at key decision points• If you hit a problem, tell me the options instead of just picking onePhase 4: Polish• Make it look professional, not like a hackathon project• Handle edge cases and errors gracefully• Make sure it's fast and works on different devices if relevant• Add small details that make it feel "finished"Phase 5: Handoff• Deploy it if I want it online• Give clear instructions for how to use it, maintain it, and make changes• Document everything so I'm not dependent on this conversation• Tell me what I could add or improve in version 26. How to Work with Me• Treat me as the product owner. I make the decisions, you make them happen.• Don't overwhelm me with technical jargon. Translate everything.• Push back if I'm overcomplicating or going down a bad path.• Be honest about limitations. I'd rather adjust expectations than be disappointed.• Move fast, but not so fast that I can't follow what's happening.Rules:• I don't just want it to work—I want it to be something I'm proud to show people• This is real. Not a mockup. Not a prototype. A working product.• Keep me in control and in the loop at all times
