从工作负载、场地与运行条件进入算力项目，不以设备清单代替需求。
说明主要任务属于内容制作、数据处理、模型工作负载还是企业软件，并记录使用者、并发模式、使用窗口和输出目标。未确认的需求单独列出，不用假精确数字掩盖缺口。
分别记录已有场地、系统、网络、团队与伙伴能力。将“已具备”“需验证”“需新增”作为条件状态，而不是项目成果。
将电力、散热、网络、维护通道和实际部署环境纳入讨论。细节需要由适合的专业团队评估，网页中的概念设施不能替代工程资料。
每条路径使用同一组需求和假设，分别说明资源范围、服务关系、需要验证的问题与下一步工作。不能直接比较基于不同条件的数字。
明确需求方、顾问、技术供应者与项目伙伴各自提供什么。授权范围与正式披露保留原始来源，不由概念文案重新定义。
输出一页需求摘要、一份条件清单、一组候选路径和一个行动表。每个行动写清需要的信息与负责角色，让项目从讨论进入下一步。
Approach a compute project through workload, site and operating conditions instead of using an equipment list as a substitute for demand.
Describe whether the principal task is content production, data processing, model workloads or enterprise software. Record users, concurrency patterns, operating windows and output objectives. Keep unconfirmed demand separate instead of masking gaps with false precision.
Record existing sites, systems, networks, teams and partner capabilities separately. Treat available, to validate and to add as condition states rather than achieved project outcomes.
Include power, cooling, connectivity, service access and the deployment environment. Appropriate specialists need to assess the detail; a concept facility on a website does not replace engineering material.
Use the same demand and assumptions for each pathway. Describe resource scope, service relationships, questions to validate and next steps. Figures based on different conditions are not directly comparable.
Clarify what the customer, adviser, technology provider and project partner contribute. Mandates and formal disclosures retain their original sources and are not redefined by concept copy.
Produce a one-page demand summary, conditions register, possible pathways and action table. Each action identifies the required input and owner role so the project can move beyond discussion.