有人回答了，就能说问题已经解决了吗？

收到回答，还不能说明问题已经解决

假设一个虚构问答版块收到这样的需求：有人回答就标成已解决，然后关闭问题。提问内容是导出的文件出现乱码，有人建议换一种编码打开。提问者还没有重新打开文件，此时标记解决，就把收到回答写成了问题解决。两件事发生的时间不同，确认的人也不能省掉。

先查现有问题、答案与评论分别有哪些状态，谁能确认解决，谁能锁定评论，以及是否保存修改记录。没有记录的部分写成未确认，不要编造回答率或解决率来证明这个需求正确。本例使用已有会员身份，一个问题只选择一个答案，不增加积分、奖励或匿名提问。

把需求改成让提问者确认哪个答案解决了问题，同时独立管理讨论限制。先确定这句话，按钮名称、权限和统计事件才有共同依据。设计画面之前，需要让提出需求的人看到自动关闭究竟省略了哪一步确认。

时间顺序从没有回答开始，然后收到第一条建议更换编码的答案。下方收到回答的展示对应这个只有一个答案的阶段。随后新增第二条建议在导入菜单选择UTF-8的答案。两个页面同时选择的检验，从这之后已有两个公开答案的状态开始。

自动处理方便，也不能省掉确认的人

可以比较三种方案：第一条回答就自动解决，一段时间没有回应就自动解决，提问者主动确认。前两种很容易减少待处理列表，可是提问者没空查看、或者答案没有帮助时，也会被系统当成成功。本例宁可保留未确认的问题，也要求提问者明确确认。这个代价要写进方案，而不是只描述好处。

GitHub公开讨论文档把标记或取消答案与锁定讨论作为不同操作介绍。这里参考的是两者分开控制的思路。只有提问者能确认、正文修改后解除确认，是本例独立选择的规则，不能写成GitHub已经采用相同实现。

管理员的边界也要写清楚。可以记录原因后解除错误确认，也可以锁定评论，但不能替提问者宣布问题已经解决。如果是客服人员负责结案的业务，确认主体就不同，不能直接复制这个权限表。先把谁有资格确认说清楚，再讨论如何减少操作。

要留下确认过什么，而不只是一个标记

只保存是否解决，所选答案改了以后就找不到原来确认的依据。要连接问题、所选答案、确认时两段正文的版本，以及解决状态的版本。版本属于实现字段，公开画面不用突然丢出内部编号，可以直接解释为内容已修改，需要重新确认。

本例规定，问题或所选答案的正文修改、隐藏或删除，都解除解决确认，错别字修改也包括在内。这样不需要另造一套自动判断修改是否重要的规则，但会增加提问者重复检查的次数。这个取舍必须留在策划书里。其他答案或评论变化不影响所选依据，因此保持原确认。

恢复正文或重新公开不代表恢复确认，提问者仍需阅读并重新选择。解除原因应通知提问者，但通知不能带出隐藏正文。记录对象关系、状态前后、操作人、时间、原因和通知结果；保存多久需要与原有政策对照，不能因为做了新功能就无限保留。

两个页面同时选择，也只能留下一个答案

服务器要在一次原子处理中检查当前操作者是否为提问者、答案是否属于该问题、正文是否公开、页面所见正文和状态版本是否仍然一致，以及当前是否未解决。原子处理就是把条件检查与结果保存连在一起，不能让另一个请求在中间改掉依据。只在按钮上禁用重复点击，覆盖不了两个标签页。

相同未解决状态下，两个页面同时选择不同答案，只允许一个成功。另一个请求展示当前选择，不能默默覆盖。要换答案，先解除旧确认，再读新答案并确认。撤回时同样检查当前选择与状态版本，避免旧页面把后来的新选择清掉。

成功响应丢失后重发，还要分开原操作结果与当前状态。原请求可能成功，但后来答案修改已经解除确认。画面应按当前未确认状态展示，不能因为找到了过去成功记录就恢复标记。历史和通知也不能重复生成，返回内容还要重新应用当前访问权限。

评论锁定但未解决，也应该正常显示

如果只写已关闭，读者不知道是问题解决了，还是运营限制了讨论。界面也要分开展示解决确认和评论锁定。内容仍公开时，即使评论被锁，提问者也可以确认答案或撤回确认。正文隐藏改变的是访问条件，不是另一种评论锁定。

点击之后先显示处理中，等服务器确认再改变解决标记。条件变化导致失败时，不要只写重试，要解释为什么需要重新阅读当前答案。下面是四个固定文案示例，切换它们不会在真实问答系统里保存确认。这些示例用于让团队核对词语和动作是否一致。

让AI先找会出错的条件，再整理流程

只说帮我写解决处理方案，AI可能顺手补上自动结案或管理员代确认。先给出谁确认、哪些修改解除确认、锁定限制什么，再让它在这些边界内寻找遗漏情形与状态前后。不是把所有判断交给AI，而是让它提供可逐条核对的候选条件。

如果建议中写重复请求直接返回首次成功结果，就继续检查响应丢失之后正文又被修改的情况。无法区分历史成功与当前未确认的答案不能原样采用。补好的条件还必须进入界面文案、服务器契约与QA，不能只留在聊天里。

下面是未执行的提问示例，不是真实对话或已获得的回答。实际使用时，按权限、版本、重试和锁定四项逐行核对。AI新提的政策要单独判断，不能因为文字写得顺，就混进已经确定的要求里。

提问示例：这是使用已有会员身份的公开问答版块。只有提问者可以选择一个答案确认解决。问题或所选答案正文修改、隐藏、删除都解除确认，评论锁定独立处理。没有自动解决，也没有管理员代确认。请检查两个页面同时选择、确认与正文修改竞争、成功响应丢失后修改正文再重试。分别写出起始状态、请求顺序、最终状态、界面文案及QA预期。需要增加新政策时请单独标明。

每份交接文件都要支持具体判断

策划书写为什么允许未确认问题留下，以及为什么错别字修改也要求重新检查。设计说明把各状态文案、操作、权限与并发修改后的结果连接起来。两份文件复制同一段解释，并不能让设计师或开发知道下一步如何实现。需求相同，文件承担的判断不同。

W3C状态消息说明支持这样的原则：不接收焦点的结果反馈，也应能被辅助技术识别。本例把处理中、确认成功、条件变化用文字区分，并提供适当状态通知。只改变黑色标记不够，每次都强行移动焦点也没有必要，实际实现需要把可见反馈与键盘操作一起验证。

运营需要查询解除原因，而不是一个替别人增加解决数量的按钮。通知发送失败不应撤销已提交的状态变化，只重试同一事件的通知。是否送达与提问者是否重新确认分开记录，才能定位失败发生在什么环节。

看最后留下什么状态，不只是按钮能不能点

验收必须写明起始状态，例如未解决且有两个公开答案，或者已经确认但评论锁定。预期结果包括所选答案、确认版本、历史和重复通知，而不只是画面上的字有没有变化。没有起点和顺序，同一条测试很容易被执行成不同场景。

确认与修改竞争要按两种顺序检查：确认先提交，后续修改必须解除；修改先提交，拿旧版本确认必须被拒绝。下表是实现后应执行的检验条件。点击本文固定展示，与真实问答系统通过联调是两个范围，需要分别记录，不能互相代替。

复用时先调整确认主体

这份交接说明以单个提问者确认作为前提。如果需要多个负责人共同认可，或者员工代替客户结案，就要重新确定操作人、必要同意和解除范围。只更换业务名称与按钮文字，不会自动变成适用于另一种服务的规则。

上线后，收到回答的问题数量与提问者确认的问题数量分开统计。解除原因和未确认状态也要保留，才能解释数字的含义。提问者确认不代表其他读者的相似问题同样解决。先统一究竟记录了什么事件，再讨论实际效果，不能把一个点击写成所有人的成果。

把无权限确认、跨问题选择、修改正文后残留旧确认、通过重试恢复旧状态列为阻止发布的缺陷。策划、设计、开发和QA拿下面说明与各自文件对照，再把修改后的条件按同一版本交接。真实验收结果要在实现后补充，不能提前写成已通过。

问答版块——解决确认的设计、开发与QA交接说明
例子：使用现有会员身份的虚构公开问答版块。每个问题只选一个答案，不含积分、奖励、匿名提问或管理员代替提问者确认。
目的：分开收到回答与提问者确认解决。第一条回答、长时间无回应或评论锁定都不能自动产生解决确认。
展示：暂无回答／已有回答、等待确认／提问者已确认解决。允许评论与锁定评论是独立维度。
操作人：只有提问者可以选择属于自己问题、当前公开的答案。服务器重新检查访问权限及问题与答案的关系。管理员可以记录理由并解除确认或锁定评论，不能代为确认解决。
确认条件：当前未解决，问题正文版本、所选答案正文版本、解决状态版本与页面所见一致。把这些条件与可见性、权限及归属放在一次原子处理中检查，再保存所选答案和确认的版本。
内容变化：问题或所选答案正文被修改、隐藏或删除，均解除确认，包括错别字修改。其他答案或评论变化不影响确认。恢复正文或重新公开不能自动恢复解决标记。
取消或替换：提问者撤回确认、管理员解除确认，都需检查当前选择与状态版本。保留答案及评论锁定。改选其他答案时，先解除原确认，再检查新答案。
锁定：只阻止新增评论。内容仍公开时，提问者可以确认或撤回。隐藏问题或答案与评论锁定不能合并为一个状态。
并发：从相同初始状态选择两个答案，只允许一个请求成功。失败请求显示最新结果，不能覆盖。确认与正文修改同时发生时，不能让旧确认附着在修改后的正文上。
重试：同一会员的同一次操作不能重复生成状态变化、历史或通知。原操作结果与当前状态分开返回。后续正文已经变化，即使原请求曾成功，也不能恢复解决标记。查询结果仍适用当前权限。
界面：服务器确认前不提前展示成功。区分成功、条件变化与无权访问。用文字和辅助技术可识别的反馈说明结果，不无故移动焦点。提供所选答案链接及撤回确认操作。
记录：问题与答案关系、确认的正文版本、状态前后、操作人、时间、解除理由、重复请求及通知结果。错误和通知不泄露隐藏正文，保留期限与现行政策核对。
交接：策划负责方案、权限及解除条件；设计负责状态与反馈；开发负责版本、原子处理及重试；QA负责起始状态与请求顺序；运营负责解除理由及通知失败。
检验：覆盖首次回答、无回应、错误身份、其他问题的答案、正常确认、修改隐藏删除恢复、无关评论变化、同时选择、修改竞争、响应丢失重试、撤回后保留锁定、锁定中确认。记录实际状态与历史。
复用前：多人确认或客服代为结案的服务要重新设计。本文是设计约定与固定界面示例，不代表真实问答系统已实现或联调通过。
例子顺序：无回答 → 第一条回答的展示 → 新增第二条后做同时选择检验。补充QA：改选后拒绝旧撤回或管理员解除；重试前隐藏内容或失去权限时不暴露正文；通知失败重试保持状态且不创建重复任务。与正文15项检验逐一核对。

来源与示例条件

这是参考GitHub答案选择与锁定区分、W3C状态反馈原则的虚构设计。权限、修改和重试政策为本例选择，并非真实服务成果。AI提问为未执行示例，英文与中文是同一韩文案例的本地化版本。

GitHub Docs — Moderating discussions

W3C — Understanding SC 4.1.3: Status Messages