melech-idea-to-canvas

将 @ 转化为独立的 Cursor Canvas，帮助团队快速理解并就构建方案达成共识。

接受任何起点：粗略想法、灵光一现的念头、Slack 讨论串摘录、会议记录、决策日志、产品简介、PRD 片段、设计文档、RFC 或技术规范。输入越缺乏结构，这项技能就越需要承担梳理结构的工作。

这主要是一份知识传递材料，而不是审批流程、辩论空间，也不是把输入改写得更漂亮的副本。

核心目标： 让团队尽可能轻松地吸收作者掌握的信息，同时不遗漏重要含义、决策、约束或实现方向。

构建 Canvas 之前，先明确：

• 问题是什么，以及它为何重要
• 预期成果是什么
• 核心心智模型
• 提议的系统，以及各部分如何协同工作
• 关键流程、状态、边界和职责归属
• 重要决策及其依据
• 约束、风险、假设和明确的非目标
• 实现顺序，以及各团队或组件负责的内容
• 哪些细节是达成共识所必需的，哪些可以逐步呈现

如果输入粗略或缺乏结构，请合理推断以补足空白，明确标注推断或假设，并指出 Canvas 揭示的作者可能尚未考虑到的事项。

呈现原则：

• 少即是多。不要按原输入的章节逐一复述。
• 优先展示，而非解释。成品应像一组信息图，而不是配有图片的文档。
• 只有在视觉无法表达含义时，才使用简短、直接的文字。
• 将信息划分为可独立理解的视图。
• 建立清晰的层级：先呈现核心认知，再呈现实现细节。
• 让读者能在 5–10 分钟内掌握要点，同时支持深入探索。
• 让重要决策清晰可见。
• 将次要机制和详尽细节放入可展开部分或精简的技术附录。
• 不要隐瞒不确定性、重要权衡、依赖关系或尚未解决的风险。
• 不要让所有细节都占据同等的视觉权重。
• 不要添加装饰性图表、泛泛的卡片、虚构指标或毫无解释作用的视觉元素。
• 不要过分强调签字确认、审批状态、利益相关方辩论或治理流程。

视觉密度：

• 将拥挤或文字过多的区域视为缺陷。密度意味着此处缺少了应有的视觉表达。
• 每个密集文本块内部都有一种结构——序列、漏斗、分支、汇合、时序竞速或边界。找出这种结构，并将其空间化呈现，而不是用句子描述。
• 单元格里写满句子的表格，只是套着网格的散文，并非视觉表达。
• 文字与视觉必须相互依赖。如果周围的文字只是在重复视觉已经表达的内容，就删掉文字。
• 不要让现有的预置组件限制绘图方式。如果内置组件只能把文字塞进方框，就按照想法实际需要的方式组织版面。

绘图：

• 只要绘图能比散文更快、更清楚地传达要点，就使用绘图。
• 将绘图视为解释工具，而非装饰。
• 用绘图解释关系、流程、边界、状态、时序、职责归属和因果关系。
• 如果绘图已经表达了核心内容，配套文字应尽量精简。
• 每幅图都应回答一个具体问题，并且无需讲解也能看懂。
• 如果一句话或简短列表更清楚，就不要强行使用视觉表达。

只选择真正有助于澄清内容的视觉形式，例如：

• 系统或组件关系图
• 用户到系统的使用旅程
• 序列图或数据流图
• 生命周期或状态模型
• 职责与归属边界
• 分阶段实现路径
• 用于呈现重要权衡的聚焦对比 建议的叙事结构：

1. 我们在构建什么，以及为什么构建
2. 一分钟理解系统的思维模型
3. 系统如何端到端运作
4. 主要构件及其职责
5. 关键流程、状态和边缘情况
6. 影响实现方式的决策
7. 如何构建并逐步推出
8. 风险、假设和有意暂缓的细节
9. 为需要深入了解的读者准备的精简技术参考

准确性要求：

• 保留源内容的意图。
• 不要凭空添加超出合理推断范围的要求、决策或确定性。
• 明确区分已决定、假设、提议和未解决的事项。
• 保留源内容中的重要术语。
• 如果输入中存在矛盾或缺漏，请以准确、克制的方式指出，不要把画布变成审查报告。

画布要求：

• 使用 Cursor Canvas skill 创建一个实际的 .canvas.tsx 工件。
• 将其制作成可独立使用的工件，无需同时查看源输入。
• 采用鲜明的视觉层级和多样的版式，不要堆叠一排相同的卡片。
• 对次要细节采用渐进式呈现。
• 确保每个视图都有明确用途，且便于快速浏览。
• 不要包含占位内容或空白版块。
• 完成前，删除所有不能帮助理解或统一实现认知的内容。

最终检查： 针对每个版块，思考：

1. 读者在这里必须理解什么？
2. 是否能以比文字更清晰的方式呈现？
3. 删除什么不会损失含义？
4. 如果这个版块仍然以文字为主，我还没有找到哪种合适的呈现形式？