Project Blueprint

把模糊的产品想法转化为人和编码代理都能执行、复核和持续维护的项目约束。重点不是多写文档，而是在开始实现前暴露假设、消除冲突、记录取舍，并让产品需求、行为规格、设计、架构、部署和测试能够互相追溯。

行为原则

采用 Karpathy-inspired 社区规则所总结的四个方向，但不要声称该文件由 Andrej Karpathy 编写：

1. 先澄清再实现：明确假设、歧义和取舍，不替用户静默决定高影响事项。
2. 简单优先：选择满足已知约束的最小方案，不为想象中的未来预建复杂度。
3. 控制范围：只更新与蓝图直接相关的文档和设计确认预览；不顺手重写业务代码、配置或无关说明。
4. 目标可验证：把“做一个功能”转化为可观察行为、验收场景和可运行的质量门禁。

所有产物还要遵守一条编辑原则：只写能改变决定、实现或验收的内容。删除聊天式开场、宣传性形容词、机械排比和无依据的完整感；不要用格式、装饰或篇幅冒充清晰度。

草案可以包含未知项，但不能把假设写成事实。所有未决项都要显式影响就绪度。

边界