🔍 把评价从印象变成论证

写一段评价的时候，试着走完五个动作。比如你观察到方案 A 用了五种高饱和色同时标记不同类别的指标，想说配色有问题——那「配色不太好」只是一个印象，还不构成论证。要变成 HD 水平的段落，得这样走：

1. 标准：Week 4 的注意力引导原则
2. 观察：方案 A 五类指标全用高饱和色
3. 影响：焦点分散，用户没法快速找到异常值
4. 证据：课程知识加方案截图里可指认的色块分布
5. 相对结论：方案 B 只用一个对比色突出异常，聚焦效果更好，但对分类区分的支持较弱

少了任何一层，那段文字就从论证退回了印象。其中相对结论特别容易漏——写完「方案 B 在这一点上更好」就停下来了。相对结论要的是条件化的判断：在当前维度上方案 B 聚焦更好，同时也要写清楚它在分类区分上不如方案 C。把这个结构用在每个关键维度上，三份 proposal 的横向比较就自然出来了。

🎯 评价里的 weakness 直接变成 scope

选定一份 proposal 之后接着写 Selected Project。这部分的 scope 直接从评价阶段写过的 weakness 里来，每个 weakness 只有四种处理方式：保留原样、修改、删除或延期，每种都需要理由和验收条件。

放到草稿里可以写成这样一条链：评价阶段写了「方案 B 的配色方案同时标记五类指标，高饱和色调削弱了焦点层级」→ scope 修改变成「将调色板限制为单一对比色突出异常值」→ 验收条件是「修改后做一次 task walkthrough，确认用户能快速定位异常数据点」。从评价到修改到验收，读者能追溯每个 scope 决策的证据来源。

🔗 如果 Selected Project 里出现一条修改，但 Critical Evaluations 里找不到对应的那条弱点，那这条修改就没有证据支撑。Rubric 要求评价→选择→计划之间形成可追溯的链条。

📅 从 scope 拆出 timeline 和分工

scope 决策确定之后，每一条拆成带 deadline 的具体任务进 timeline。HD Rubric 要求 deliverables 拆成 manageable tasks，每项有日期。

这里还有一条容易忽略的规则：每名成员对每项 deliverable 都要有实质贡献。一个人包办开发、另一个人只管写报告，这种分法满足不了 HD 对 workload fairly divided 的要求。比如配色修改这项任务，可以这样安排：

• 一人实施配色调整
• 一人准备测试数据跑 task walkthrough
• 一人对照评价标准复核修改结果

三个人在同一项 deliverable 上各有可识别的动作。安排分工的时候，同一个 deliverable 里除了主负责人，其他成员在开发、数据核验、测试或复核中也要有具体位置。

另外 Contribution Summary 记的是已经完成的工作，用过去时；Work Allocation 规划的是后续 dashboard 项目里将要承担的任务，用将来时。两部分时间方向不同，写法也不同，直接复制粘贴会很明显。

📋 评价维度一旦建好，三个模块就是同一条链：横向比较推出选择理由，weakness 拆成 scope 决策，scope 拆出带 deadline 的 timeline。