氛围编程——从零开始一个项目

1. 梳理需求说明文档

早期只有一个模糊的想法，例如“开发一个系统，将用户警入的内容自动转换为小红书风格的卡片与配套文案”。将构想借助系统化的需求分析过程逐步细化，为后续的工程实践奠定扎实基础。

你是一个专业的软件需求分析专家，我准备开发一个Web系统，将用户输入内容转换为小红书卡片与文案，请围绕这一需求完善需求说明文档，文档中需要至少包含如下内容

- 简介：简要说明项目背景和目标，即“你要做什么”。
- 功能：列出系统将提供的功能和界面(站在用户角度描述外部可见的行为)。
- 约束：明确技术栈、性能要求、编码规范等限制条件。或特定要求。
- 其他细节(可选)：对于特别复杂或需要严格控制的算法/实现，可在需求说明文档中注明关键细节或特定要求。

2. 梳理技术设计文档

需求说明文档关注的是“做什么”，而技术设计文档的核心在于解答“怎么做”。

仔细阅读 @docs/requirements.md 文档，据此梳理出核心技术实现方案，内容应包含功能主流程、架构设计、更精细的技术栈选型等，将结果保存到 @docs/atech.md 文档

3. 梳理项目执行计划文档

大语言模型的上下文窗口(context window)存在长度上的严格限制。随着开发进度推进、代码量增加、对话内容不断扩展，A，A编程Agnt所维护的上下文状态会逐步逼近模型支持的最大长度，一旦超出限制将直接导致上下文截断，使模型遗忘早期关键信息，甚至引发任务崩溃。

为此，需要一种长期记忆机制，使得即使模型“失忆”或会话中断，也可快速“回忆”项目任务、定位当前进度、恢复开发状态。

仔细阅读 @docs/atech.md 与 @docs/requirements.md 文档，帮我规划一个项目执行计划文档，我期望先完成
后端接口体系开发，再逐步执行前端开发；另外，每个任务项需要用 `[]` 标记执行状态，在后续的对过程中，一旦完成某个任务项就标记为 `[x]`，将结果保存到 `docs/plan.md` 文档中

4. 开发后端服务程序

目前已有以下3份核心文档：

• requirements.md(需求说明文档):用于明确产品目标、功能边界、主要交互流程，以及关键的技术与非技术约束条件。
• tech.md(技术设计文档):明确技术栈选型、核心架构方案及实现过程中的技术约束。
• plan.md(项目执行计划文档):划分开发阶段，定义执行顺序，为 AI Agea 提供上下文线索，保障任务推进的连续性与可控性。

输入适当的提示词来驱动开发：

仔细阅读 @requirements.md 与 docs 目录下的技术文档，开始帮我按项目执行计划文档@plan.md一步步编写代码，请专注于业务编码，不需要编写单元测试代码;请将代码保存到packages目录下，并优先完成服务器端的开发。

5. 代码审查

在初步生成代码后，接下来需要先对代码做一次简单的代码审查。

• 审查日志是否完善

仔细阅读当前代码，在主流程的核心位置适当补充日志，充分暴露系统的运行状态。

• 审查实际生成的接口是否匹配 tech.md 中的规划。

优化 xxx 接口，请严格遵从 @tech.md 文档的规划，使用 xxx 路径暴露服务接口。

其它经验

推荐的一些文件和命名：

• prd.md: 产品需求文档，即功能、业务逻辑、界面等基本信息
• plan.md: 需求计划说明，应按照需求关系，优先实现 MVP 版本，并把细化需求拆分多个开发阶段
• architecture.md: 架构说明，使用文字和 mermaid 描述项目架构，描述项目的组件、模块、依赖关系
• frontend.md: 前端需求与计划说明
• backend.md: 后端需求与计划说明
• appflow.md：描述预期中用户如何使用该 APP，需要对其产品意图、数据流向、用户交互设定等内容