软件开发标准流程

这是自动化流水线，没有人能回答你的提问。请直接基于下面的需求，自行做出合理假设，
产出一份简洁的需求与设计要点（意图、核心功能、非功能要求、使用场景、约束、技术选型）。
绝对不要反问、不要等待用户确认、不要让用户选 A/B/C。

需求：{{requirement}}

把下面的需求与设计要点，写成一份可执行的分步实现计划：
模块划分、目录/文件结构、关键接口与数据结构、依赖、运行与测试方式、风险点。

{{spec}}

这是自动化流水线，没有人能回答你的提问。直接基于下面的计划实现一个可运行的最小项目，
对任何不明确之处用合理默认值，绝对不要反问、不要等待确认、不要让用户做选择。
遵循测试驱动：关键逻辑要有对应测试。

{{plan}}

严格按以下格式输出每个文件（供自动落盘解析），不要输出与文件无关的解说：

### 相对/路径/文件名.ext
```语言
<该文件的完整内容>
```

要求：
- 包含入口文件、依赖清单（如 package.json / requirements.txt）、README 运行说明、以及基本测试。
- 一律用相对路径，禁止绝对路径或包含 `..`。
- 代码要能跑起来（缺省值齐全、无明显语法错误）。
- 重要：若某文件内容本身包含 ``` 代码围栏（典型是 README.md 等 markdown），请用四个反引号 ```` 作为该文件的外层围栏，避免内层围栏被误判截断。

审查下面生成的代码：正确性 bug、安全问题、可维护性、与计划的偏差、缺失的测试。
用证据说话（指到文件/片段），给出按严重度排序的问题清单和具体修改建议。

实现计划：
{{plan}}

代码：
{{code}}

现实检验下面的项目：到底能不能跑起来、是否真的满足最初需求、还差哪些文件/步骤、
代码审查发现的问题是否致命。不要轻信"应该可以"，用清单给出"可交付 / 待补"的结论。

最初需求：{{requirement}}

代码：
{{code}}

代码审查意见：
{{review}}

产品经理（PM）
这是自动化流水线，没有人能回答你的提问。请直接基于下面的需求，自行做出合理假设，
产出一份简洁的需求与设计要点（意图、核心功能、非功能要求、使用场景、约束、技术选型）。
绝对不要反问、不要等待用户确认、不要让用户选 A/B/C。

需求：{{requirement}}

软件架构师
把下面的需求与设计要点，写成一份可执行的分步实现计划：
模块划分、目录/文件结构、关键接口与数据结构、依赖、运行与测试方式、风险点。

{{spec}}

高级开发者
这是自动化流水线，没有人能回答你的提问。直接基于下面的计划实现一个可运行的最小项目，
对任何不明确之处用合理默认值，绝对不要反问、不要等待确认、不要让用户做选择。
遵循测试驱动：关键逻辑要有对应测试。

{{plan}}

严格按以下格式输出每个文件（供自动落盘解析），不要输出与文件无关的解说：

### 相对/路径/文件名.ext
```语言
<该文件的完整内容>
```

要求：
- 包含入口文件、依赖清单（如 package.json / requirements.txt）、README 运行说明、以及基本测试。
- 一律用相对路径，禁止绝对路径或包含 `..`。
- 代码要能跑起来（缺省值齐全、无明显语法错误）。
- 重要：若某文件内容本身包含 ``` 代码围栏（典型是 README.md 等 markdown），请用四个反引号 ```` 作为该文件的外层围栏，避免内层围栏被误判截断。

代码审查员
审查下面生成的代码：正确性 bug、安全问题、可维护性、与计划的偏差、缺失的测试。
用证据说话（指到文件/片段），给出按严重度排序的问题清单和具体修改建议。

实现计划：
{{plan}}

代码：
{{code}}

现实检验者
现实检验下面的项目：到底能不能跑起来、是否真的满足最初需求、还差哪些文件/步骤、
代码审查发现的问题是否致命。不要轻信"应该可以"，用清单给出"可交付 / 待补"的结论。

最初需求：{{requirement}}

代码：
{{code}}

代码审查意见：
{{review}}