How to Build Apps with AI: From Idea to API (Or X)

如何利用 AI 构建应用：从创意到 API（或 X）

Can AI help you build useful apps without settling for slop? This guide shows a human-led workflow for taking a product idea through requirements, feature-level implementation, API design, and verification. I use Orbit, a Slack-style team chat demo, as a case study. You can apply the process to your own product, whether you write code or are still shaping the idea. AI 能否帮助你构建实用的应用，而不至于产出“垃圾（slop）”？本指南展示了一种以人为核心的工作流程，涵盖了从产品创意到需求分析、功能实现、API 设计及验证的全过程。我以 Orbit（一个 Slack 风格的团队聊天演示程序）为例进行说明。无论你是开发者还是正处于构思阶段，都可以将此流程应用到你自己的产品中。

My first prompt was simple: “I want to build a Slack clone.” That sentence named a product category. It did not say who the product was for, what the first version had to do, what “done” meant, or which parts could be simulated. On social media, I often see two absolute claims: AI only builds “slop,” and AI cannot help create applications that reach production. Both claims miss the role of the people building the product. 我的第一个提示词很简单：“我想构建一个 Slack 克隆版。”这句话定义了一个产品类别，但并没有说明产品受众是谁、第一个版本需要实现什么功能、什么是“完成”状态，或者哪些部分可以进行模拟。在社交媒体上，我经常看到两种绝对的论调：AI 只会产出“垃圾”，以及 AI 无法帮助创建可投入生产的应用。这两种观点都忽略了产品构建者（人类）的作用。

AI can help create useful software when people set the scope, review the changes, test the behavior, and own the release decision. AI-generated code cannot certify itself as production-ready. Orbit is a demo, not a production application. It has no sign-in, uses one shared public demo owner, and loses stored data when its process restarts. I will show what the AI-assisted workflow produced and what still needs verification before a production release. 当人类负责设定范围、审查变更、测试行为并掌握发布决策权时，AI 确实能帮助创建实用的软件。AI 生成的代码无法自行证明其已达到生产就绪状态。Orbit 是一个演示程序，而非生产级应用。它没有登录功能，使用一个共享的公共演示账号，且在进程重启时会丢失存储的数据。我将展示 AI 辅助工作流程的产出，以及在正式发布前仍需验证的内容。

Why AI output can be useful

为什么 AI 的产出是有用的

“Slop” is a fair description of output that looks complete but does not meet the user’s needs. A vague request gives an AI room to guess. If no one checks those guesses against real requirements, the result can look polished while behaving like the wrong product. The process for Orbit added checks at each handoff. ChatGPT helped expose missing decisions. Claude organized the decisions in a PRD and feature specs. Grok Build implemented bounded changes. “垃圾”是对那些看起来完整却无法满足用户需求的产品输出的恰当描述。模糊的请求会给 AI 留下猜测的空间。如果没人根据真实需求去核对这些猜测，结果可能看起来很精致，但行为逻辑却完全偏离了产品初衷。Orbit 的流程在每次交付时都增加了检查环节：ChatGPT 帮助暴露了缺失的决策；Claude 将这些决策整理成产品需求文档（PRD）和功能规范；Grok Build 则实现了受限的功能变更。

I reviewed the UI, revised the requirements, and asked for an API audit only after the UI behavior was accepted. Feature acceptance criteria and tests made some results observable. That work is evidence that AI can contribute to product planning, interface work, API design, and implementation. It does not prove that Orbit is production-ready. The current demo has no sign-in, shared demo data, and process-scoped persistence. 我审查了 UI，修订了需求，并且只有在 UI 行为被认可后才要求进行 API 审计。功能验收标准和测试使部分结果变得可观测。这些工作证明了 AI 可以在产品规划、界面设计、API 设计和实现方面做出贡献。但这并不证明 Orbit 已达到生产就绪状态。目前的演示程序没有登录功能，使用共享数据，且持久化仅限于进程生命周期内。

Orbit, the running example

Orbit：运行中的示例

The screenshots follow a new visitor from the welcome screen to a channel, a thread, and a direct message. The welcome screen tells visitors that they share demo data. There is no sign-in. Do not enter private messages. Calls are simulated; they do not carry live audio or video. The welcome screen explains the shared demo before a visitor enters. 截图展示了一位新访客从欢迎界面进入频道、主题（thread）和私信的过程。欢迎界面告知访客他们共享的是演示数据。这里没有登录功能，请勿输入私人信息。通话功能是模拟的，不传输实时音频或视频。欢迎界面在访客进入前就解释了这是一个共享演示环境。

Turn the idea into requirements before asking for code

在要求写代码之前，先将创意转化为需求

“Build a Slack clone” leaves many decisions open. Does the first version need accounts, real-time messages, calls, file uploads, mobile navigation, or search across every message? If a model answers those questions by guessing, it can build a polished interface for the wrong product. I used ChatGPT to make the missing decisions visible before I asked Claude to write the PRD. “构建一个 Slack 克隆版”留下了许多未决事项。第一个版本需要账号系统、实时消息、通话、文件上传、移动端导航，还是全消息搜索？如果模型通过猜测来回答这些问题，它可能会为一个错误的产品构建一个精致的界面。我利用 ChatGPT 在要求 Claude 编写 PRD 之前，先将缺失的决策显性化。

Prompt 1: clarify the idea 提示词 1：澄清创意

I want to build a Slack-style team chat app. Help me clarify the idea before you write a build prompt. Ask questions about:

• who will use the app and what they need to do;
• the smallest useful first version;
• workspaces, channels, direct messages, threads, and search;
• accounts, data ownership, persistence, and real-time behavior;
• files, calls, mobile use, and accessibility;
• security, edge cases, and features that are out of scope. Separate confirmed facts, assumptions, recommendations, and open questions. Do not turn an unanswered question into a requirement. Do not write code. When the important questions are answered, write a structured brief I can give to another assistant to draft a PRD. 我想构建一个 Slack 风格的团队聊天应用。在编写构建提示词之前，请帮我澄清这个创意。请询问以下方面的问题：
• 谁将使用该应用，他们需要做什么；
• 最小可行性版本（MVP）包含什么；
• 工作区、频道、私信、主题和搜索功能；
• 账号、数据所有权、持久化和实时行为；
• 文件、通话、移动端使用和无障碍访问；
• 安全性、边缘情况以及不在范围内的功能。 请将确认的事实、假设、建议和未决问题分开。不要将未回答的问题转化为需求。不要写代码。当重要问题得到解答后，请编写一份结构化的简报，以便我提供给另一个助手来起草 PRD。

The key instruction is to separate what I decided from what the model suggested. If the answer says “accounts are required” but I never chose an account system, that is an assumption to review, not a requirement to pass along. For a non-technical builder, describe the user and the problem in everyday language. For a technical builder, add the stack, integrations, data boundaries, and deployment constraints. Either way, ask the model to list unanswered questions instead of filling them in. 关键指令在于将“我的决定”与“模型的建议”区分开来。如果回答中提到“需要账号系统”，但我从未选择过账号系统，那么这只是一个需要审查的假设，而不是一个需要传递的需求。对于非技术构建者，请用日常语言描述用户和问题；对于技术构建者，请添加技术栈、集成、数据边界和部署约束。无论哪种情况，都要要求模型列出未回答的问题，而不是替你填补它们。

What BRD, PRD, and SRS mean

BRD、PRD 和 SRS 的含义

The document names vary between companies. Teams also combine them. These are common meanings: 文档名称在不同公司之间有所不同，团队有时也会将它们合并。以下是常见的含义：

• A BRD, or Business Requirements Document, describes the business problem, stakeholders, expected outcomes, constraints, and success measures. BRD（业务需求文档）：描述业务问题、利益相关者、预期成果、约束条件和成功衡量标准。
• A PRD, or Product Requirements Document, describes users, product outcomes, workflows, feature priorities, and acceptance criteria. PRD（产品需求文档）：描述用户、产品成果、工作流、功能优先级和验收标准。
• An SRS, or Software Requirements Specification, describes… SRS（软件需求规格说明书）：描述……