操作手册：如何通过编程打造成功的应用程序
这是我们用于构建最小可行产品（MVP）和内部工具的开发流程。
为了快速推进，我们结合了多种工具、人工智能代理和系统。这使我们能够将产品开发周期压缩到1-2天。
以下是高层次的流程：
想法 → 模板 → AI规划代理 → 核心功能（Claude / Codex / Gemini） → 部署
每个工具都包含可重复的功能，如电子邮件、支付和营销页面。为了避免每次都重建这些功能，我们创建了一个模块化的内部模板，可以在这里查看。这个模块化的方法使我们能够非常轻松地更改设计，并专注于产品的核心功能。一旦模板设置完成，我们就可以开始了。文档也可以在这里找到。模板功能如下所示：
模板功能：
- 营销页面：主页、关于、定价、博客、联系方式、服务、法律页面
- 身份验证：NextAuth & Google Auth
- 支付
- 电子邮件
- 通知
- 仪表板结构
- 功能门控
- SEO & GEO准备
- 数据库设置
AI规划代理
AI规划代理充当我们的内部敏捷团队。
在使用AI进行构建时，强有力的规划对于确保开发代理在明确的框架内运作至关重要。这些代理直接嵌入我们的代码库中，使我们能够为想要构建的功能提供完整的上下文。
简单的流程如下：
分析代理 → 创建产品简报（http://brief.md） → 产品经理代理 → 创建产品需求文档（http://prd.md） → 架构师代理 → 创建系统架构（http://architecture.md） → 产品经理代理 → 创建史诗和故事（http://epics.md, http://stories.md）
这些为什么如此重要？这个过程为我们和开发AI代理提供了明确的执行计划和强有力的框架。因此，代理不会产生幻觉，而是准确构建所需的内容，以所需的方式进行构建。
以下是一个故事的示例：
## 故事 2.9：在状态变更时向提交者发送电子邮件通知
作为一个*反馈提交者*，
我希望*在我的反馈状态发生变化时（例如，从进行中→测试→完成）收到电子邮件*，
以便*我知道团队正在处理我的建议，并能看到进展*。
### 验收标准
1. 当团队成员更改反馈项目状态（故事2.5 拖放）时，触发电子邮件通知
2. 仅当提交者在提交时提供了电子邮件地址时才发送电子邮件（FR17）
3. 电子邮件主题：“[项目名称] 更新：您的反馈现在是[状态]”
4. 电子邮件正文包括：原始反馈标题、新状态、团队评论（如有）、查看公共板的链接
5. 电子邮件异步发送（不阻塞状态更新）
6. 如果电子邮件发送失败，记录错误但允许状态更新成功（NFR12）
7. 如果状态快速多次变化，不发送重复电子邮件（去抖动或排队）
8. 包含退订链接（目前为占位符）
9. 在开发和生产中测试电子邮件发送
现在我们已经准备好了一切，模板中包含所有可重复的产品功能（登录、仪表板、支付、电子邮件等），规划阶段已完成，具有明确的焦点、框架、用户故事和架构，我们拥有了使用AI（Claude、Codex或Gemini）构建所需的所有上下文。
在这个阶段，开发按故事逐个进行。随着完整的规划上下文到位，AI代理准确实施所需的内容。根据功能的数量，我们可以在1-2天内部署并准备好一个可供真实用户验证的在线产品。
以下是我们能够实现的示例：
https://startupkit.today
https://founderspace.work
查看原文
This is the development process we use to build MVPs and internal tools.<p>To move fast, we combine multiple tools, AI agents, and systems. This lets us compress the product development lifecycle down to 1–2 days.<p>Here’s the high-level flow:
Idea → Boilerplate → AI Planning Agents → Core Features (Claude / Codex / Gemini) → Deployment<p>Every tool includes repeatable features such as emails, payments, and marketing pages. To avoid rebuilding these each time, we created a modular internal boilerplate which can be seen here. This modular approach allows us to change the design very easily and focus only on the core features of the product. Once the boilerplate is set up, we are ready to go. The documentation can also be found here. The boilerplate features are outlined below:<p>Boilerplate features:
Marketing pages: Home, About, Pricing, Blog, Contact, Services, Legal Pages
Authentification: NextAuth & Google Auth
Payment
Emails
Notifications
Dashboard Structure
Feature Gating
SEO & GEO ready
Database Setup<p>AI Planning Agents<p>AI Planning Agents act as our internal agile team.<p>When building with AI, strong planning is essential to ensure the development agent operates within clear guardrails. These agents live directly inside our codebase, making it easy to provide full context for the features we want to build.<p>A simple flow looks like this:<p>Analyst Agent → creates the Product Brief (http://brief.md) → PM Agent → creates the PRD (http://prd.md) → Architect Agent → creates the System Architecture (http://architecture.md)
→ PM Agent → creates the Epics & Stories (http://epics.md, http://stories.md)<p>Why are these so important? This process gives both us and the development AI agent a clear execution plan with strong guardrails. As a result, the agent does not hallucinate and builds exactly what is required, in the way it is required.<p>Here is an example of one story:<p>## Story 2.9: Send Email Notifications to Submitters on Status Changes
As a *feedback submitter*,
I want *to receive an email when my feedback status changes (e.g., Doing → Testing → Finished)*,
so that *I know the team is working on my suggestion and can see progress*.
### Acceptance Criteria
1. When team member changes feedback item status (Story 2.5 drag-and-drop), trigger email notification
2. Email sent only if submitter provided email address during submission (FR17)
3. Email subject: "[Project Name] Update: Your feedback is now [Status]"
4. Email body includes: original feedback title, new status, team comment (if any), link to view on public board
5. Email sent asynchronously (doesn't block status update)
6. If email sending fails, log error but allow status update to succeed (NFR12)
7. No duplicate emails if status changes multiple times quickly (debounce or queue)
8. Unsubscribe link included (placeholder for now)
9. Test email delivery in development and production<p>Now that we have everything in place the boilerplate with all repeatable product features (login, dashboard, payments, emails, etc.) and the planning stage completed with clear focus, guardrails, user stories, and architecture we have all the context needed to build with AI (Claude, Codex, or Gemini).<p>In this phase, development happens story by story. With the full planning context in place, the AI agent implements exactly what is required. Depending on the number of features, we can deploy and have a live product ready for real user validation in 1–2 days.<p>Here is an example of what we manage to achieve:<p>https://startupkit.today
https://founderspace.work