提案长文 · 把一件共同任务推进到底
海角论坛阅读专题：从征集意见到可回访的阶段决定
异步讨论是指参与者在不同时间阅读、补充和回复，无需同时在线。它给人准备材料的空间，也容易让决定散落在多处。解决办法是让每轮讨论都有明确的输入、产出与下一步。以下虚构案例假设几位社区成员想共同编制图书交换目录，页面中的安排、方案和版本都用于示范，不表示活动已经举办，也不代表任何论坛的现行功能或规则。
01 · 启动：把共同愿望写成能完成的任务
“做个好用的目录”表达了愿望，却没有说明怎样才算做好。有人可能期待漂亮封面，有人关心是否能找到可交换的书，也有人想加入借阅记录。若这些目标混在一个主帖里，回复再多也未必指向同一结果。启动阶段先确定一个较小的交付物，再邀请别人补齐缺口；范围小，才能清楚说明这轮讨论何时可以结束。
任务卡：目标、交付物、完成标准与暂缓范围
示例任务卡可以这样写：“本轮整理一份可查找的图书交换目录，先记录书名、版本说明、交换状态及条目编号；重复书目保留不同版本，不合并成一条。首版暂不制作封面展示，也不处理实际交换安排。”目标描述使用需求，交付物描述留下什么，暂缓范围则保护讨论边界。不要只写“整理一下”，否则不同参与者可能各自整理出无法拼接的成果。
完成标准要能被另一个人核对。例如：每条记录都具备约定字段；空缺以“待确认”表示；同书不同版本可区分；维护说明能告诉接手者怎样更新状态。然后用一条虚构书目走一遍：能否知道它是否可交换？发现错字要改哪里？如果仍无法回答，就应调整标准。这里核对的是目录结构，提案中无需列出参与者的私人联系方式。
时间窗：让意见在合适的阶段进入
在同一任务卡下面写三段安排：征集阶段收集缺少的需求，澄清阶段回答影响方案的疑问，定稿阶段核对将采用的版本。时间应由实际参与者按生活节奏约定；本例不替他们指定真实日程。若有人只能较晚阅读，可预先说明如何补充意见。每次推进时都附上上一阶段的短摘要，避免后来者必须从头翻完所有回复才能参与。
期限到达并不等于所有人同意。可以记录“当前收到的意见已整理，尚未收到某项核对信息”，并说明下一步是延期、缩小试行范围还是等待确认。对截止后出现的意见，先判断它是否暴露了关键约束：若会导致目录不能使用，就进入本轮复核；若只是新增便利功能，可以放进下一轮。时间窗管理的是工作节奏，不替代参与者约定的决定方式。
02 · 澄清：先解开阻塞，再让不同工作接上
长帖里往往同时出现疑问、建议、报错和个人偏好。只按回复时间从头处理，会让重要缺口淹没在细节中。澄清阶段需要回答“没有哪条信息，就无法可靠地做下一步”。一个阻塞项必须指出受影响的动作；否则它只是一个笼统的担忧，无法判断何时解除。
阻塞清单：每一项都写解除条件
在图书目录例子中，“交换状态采用哪些词”是阻塞项，因为词义不统一，录入后就不能正确筛选。“卡片底色再柔和一点”通常属于润色项，不阻碍先整理条目。可以为阻塞项设一个短编号，例如 B-01，并记录问题、影响、所缺信息和解除条件。B-01 的解除条件可以是：已确认状态词的含义，并用一条记录验证各词不会互相混淆。
分配下一步时，用“待一位参与者确认接手字段核对”比擅自写某人负责更准确。自愿接手后，才记录约定的反馈时间；未有人接手就保留“待认领”。如果一项信息长期无法取得，可以讨论是否缩小首版范围，而不是用猜测补齐。清单还应记录已解除的项及其依据，否则后来者会把同一个问题重新提起。
依赖关系：让回复围绕可接续的工作
先确认字段规范，再分组录入，最后统一核对，这是事项间的依赖关系。若字段规范尚未确认，可以先收集候选书目，却不宜让所有人各自确定字段顺序。把这些关系写成“完成 A 后才能开始 B；C 可与 A 并行”即可，不需要复杂工具。一个主帖维护当前任务摘要，分支回复集中讨论单一缺口，方便读者看清哪些工作已经可继续。
有些回复谈的是前一版字段，却出现在后一版方案下面。回应前先注明对应版本和阻塞编号，再补充自己的判断，例如“针对 v0.1 的 B-01，建议把不可交换与尚未确认分开”。如果讨论已经分叉，应在主摘要里补一条指向关系，而不是把整段回复复制多遍。这里讲的是组织记录的方法；实际能否编辑、置顶或引用楼层，应以所用平台的功能为准。
03 · 比较：用相同约束形成一份有边界的决定
方案比较之前，先确认什么是共同底线。本例需要读者找到可交换的书、维护者能更新状态、条目不会因改版失去对应关系。底线由任务目标推导，不应随着个人偏好临时改变。下面对照两种虚构办法：按图书类别排列，以及按交换状态排列。表格展示比较思路，没有真实试用数据，也不声称一种办法普遍更好。
方案矩阵：把已知、未知与取舍分开
先为每种方案填同样的问题，再讨论差异。类别排列方便按兴趣浏览，但读者还需要看到交换状态；状态排列便于先找当前可交换条目，但状态变化可能引起位置调整。维护成本不能凭感觉写成“很低”，应追问由谁更新、每次改什么、原条目是否还能被找到。尚未实际验证的项目标为待确认，避免把推测当成已经发生的结果。
若两种办法都达到基本要求，可先选维护工作较容易承担的一种做有限试用，并约定检查点。若某项关键要求两种办法都达不到，就补充第三种方案或修改范围。用百分制打分只有在权重、评分依据与数据来源都明确时才有意义；本例没有这些条件，因此直接写取舍理由。读者应能从理由看出为什么此刻选它，以及哪些条件改变后选择可能不同。
| 比较维度 | 按类别排列 | 按状态排列 | 需要核对的条件 |
|---|---|---|---|
| 查找路径 | 先看类别，再看条目状态 | 先看可交换状态，再找书名 | 读者更常从哪种问题开始查找？ |
| 更新动作 | 主要修改条目内的状态字段 | 可能需要调整条目所在分组 | 更新者能否持续完成约定动作？ |
| 记录连续性 | 同一条目保留稳定编号 | 移动分组时也需保留编号 | 旧回复能否对应到变化后的条目？ |
决定记录：允许异议留下，同时说清下一步
一条示范记录可以写成：“本轮暂以类别排列为主，每条附交换状态；因为首版更需要稳定条目位置，状态变化通过字段更新处理。关于快速查找可交换书目的意见保留，先用少量虚构条目检查查找步骤。”这只是教学用选择，不是已经达成的真实共识。决定方式和有权确认的人应在征集前约定，不能在看到结果后临时换规则。
异议可分为已回应、待确认和暂缓三种处理状态，但不能把“已记录”写成“已解决”。对每条关键异议，写明它指出的影响以及何时重新评估。若异议涉及首版能否达到完成标准，就需要先澄清或缩小决定范围；若涉及未来扩展，则放进后续清单。结尾列出下一步动作、已确认接手的人或待认领状态，让阶段决定具备可执行的出口。
04 · 收尾：让版本、回访和交接连成一条线
定稿只是本轮讨论的阶段性结果。论坛里的旧回复不会因为主帖修改就自动更新含义，而图书状态也可能在目录开始使用后发生变化。收尾要保留两条线：一条说明方案怎样变化，另一条说明未来怎样发现它不再适用。这样既能减少重复讨论，也能在条件改变时有依据地重开问题。
版本记录：交代变化及其影响，不悄悄覆盖
在本例中，可以用 v0.1 表示征集草案，v0.2 表示字段已统一的草案；版本号只是示例，不代表软件版本。每次改动写一条记录：改了什么、为何修改、影响哪些旧条目、是否需要重新核对。若新增了“状态待确认”一项，就指出旧空值需补标，而不是笼统地写“已优化”。旧摘要保留对应版本说明，使引用旧文的回复仍能被理解。
对不影响含义的错字修正，可以简记；对改变范围、字段含义或完成标准的修改，则应重新通知需要确认的参与者，并留出反馈机会。若当前平台无法编辑主帖，可以发布一条清楚标注的新摘要，并注明它接替哪个版本。不要通过删掉全部旧意见制造从未出现分歧的表象；历史记录用于解释取舍，当前入口则应明确标出正在使用的版本。
回访与归档：区分完成、暂停和待确认
安排回访时，写检查问题比只写一个日期更有用。本例可检查：读者能否识别当前可交换状态；重复书名能否区分；条目修改是否留下对应关系；维护者是否仍能承担更新。实际回访时间由参与者约定。若只是个别字段漏填，可按既定维护方式修正；若状态长期无法确认或维护责任中断，就达到重开讨论的条件，重新审视目录范围。
归档摘要保留目标、当前版本、已完成项、未完成项及重新联系的工作入口。没有接手者时，应如实写“维护待认领”，不能写成已安排。暂停事项要写恢复所需条件；待确认事项要写缺少什么；已完成事项要写核对依据。读者下次回来时，只需先读摘要，再按编号追溯相关分支。一个好的结尾，能让协作在需要时自然续上，而不是让后来者重新猜一遍。