project-background-goallisted

# 项目背景与目标（Project Background And Goal） ## 目的与边界（Purpose And Boundary） 确立需求为什么存在、今天发生了什么、什么问题重要、涉及哪些人、预期达成什么结果，以及哪些约束或未知项会影响后续工作。 **不要**设计旅程、功能、页面、字段、API、架构或实现任务。业务方提供的产品方案是需要审视的证据，而不是理解业务需求的替代品。 ## 输入与输出（Inputs And Outputs） 输入：已登记的来源材料（会议纪要、邮件、BRD、PPT、图片）以及可识别的业务事实/目标负责人。输出：`background-goal.md`，使用 `src/templates/resolver.py background-goal.md` 解析出的模板。 分析前加载 `references/thinking-framework.md`（其中引用 `src/framework/thinking-core.md` §1 必用透镜）。起草前加载 `references/output-contract.md`。交接前加载 `references/audit-checklist.md` 与 `references/reviewer-checklist.md`。评审前运行 `scripts/validate_artifact.py <artifact> --json`。当来源材料稀疏时加载 `references/elicitation-techniques.md`（访谈/观察主动采集）。 ## 思考提示词（按阶段）（Thinking Prompts per stage） ### 1. Preflight - "我有哪些来源？谁拥有业务事实？信息密度如何？" - 为每个来源登记 SRC-ID。识别 business_fact_owner（业务事实负责人）与 goal_decision_owner（目标决策负责人）。 - **如果没有可用来源或事实负责人**，返回一张路由回执并 STOP——不要进入 Intake。 - 评估成熟度：L0（无来源）→ L1（单一稀疏来源）→ L2（已有业务方案）→ L3（定义良好）→ L4（上游已确认）。 ### 2. Intake - "每个来源实际说了什么——而不是我认为它是什么意思？" - 在解读之前先逐字提取来源陈述。按 `src/framework/contracts.md` 将每条分类为 `FACT`、`DECISION`、`ASSUMPTION`、`AI_INFERENCE`、`UNKNOWN` 或 `CONFLICT`。 - 保留来源 ID 与位置。不要把不同来源的主张合并成一条陈述。 ### 3. Think（应用 thinking-core.md §1 必用透镜） - **第一性原理（First Principles）**："我们想改变的可观察结果是什么？哪些假设伪装成了需求？" - **系统思维（Systems Thinking）**："哪些上游/下游系统、角色与数据会受影响？" - **角色视角（Role Perspective）**��"对每个识别出的角色——他们获得什么、失去什么、需要改变什么？" - **约束分析（Constraint Analysis）**："硬约束（法律、平台、品牌、时间）有哪些？" - **对抗性审视（Adversarial）**："任何主张的反面是否可能成立？什么证据能推翻它？" - **逆向验证（Reverse