添加关键词 - 短横线副题：把操作过程写清楚，交付少返工
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /27ff64c0a7d6.html
📄
添加关键词 - 短横线副题：把操作过程写清楚，交付少返工
要把“添加关键词”的操作过程写清楚，核心不是罗列步骤，而是让接手的人能判断每一步是否做对：先写清准备条件，再按可执行的动作顺序实施，接着给出验证标准和异常判断，最后说明后续维护与交接方式。多人协作时，最关键的一步是给每个动作配上可观察的结果，而不是只写“添加关键词”四个字。
准备：先写明输入条件与责任人
操作说明开头应交代清楚前置条件，否则执行者只能猜。建议包含以下检查项：
- 操作对象：在哪个页面、哪个栏目或哪份表格中操作，用可识别的名称或路径描述。
- 输入材料：待添加的关键词清单由谁提供、放在哪个文件、格式是什么。
- 权限与角色：谁有编辑权限，谁负责审核，出现冲突时找谁确认。
- 完成定义：什么状态算“添加完成”，例如已保存并出现在列表、已通过审核。
准备部分不要写“根据实际情况处理”这类无法执行的话。如果条件不确定，就写成待确认项，并指定确认人。
实施：动作顺序与单步结果对应
实施部分是操作过程的主体。每一步应写成“动作 + 对象 + 预期结果”，例如：
- 打开指定编辑页面，确认页面标题与任务单一致。
- 在关键词输入区域逐条录入，每条之间用约定分隔符隔开。
- 保存后重新打开该页面，确认关键词数量与清单一致。
多人协作时，最容易返工的环节是录入格式不统一。可以在说明中固定一个短例子，标明分隔符、大小写和空格处理方式。若系统对重复词、特殊符号有处理规则，应写明“重复时保留哪一条”“符号是否会被过滤”，并注明这是需要实际测试确认的项，而不是凭经验断言。
如果操作涉及标签，例如在页面源码中定位某个区域，文字说明里提到标签时应写成 <h2> 这样的转义形式，避免被当成真实代码执行。
验证：用可核对的结果代替“检查一下”
验证步骤要能被第二个人独立复现。建议按以下顺序检查：
- 数量核对：添加后的条目数与来源清单是否一致。
- 内容核对：随机抽取若干条，逐字比对，重点看同音字、近形字和多余空格。
- 状态核对：保存、发布或提交审核后的状态是否符合完成定义。
- 异常记录：如果出现未保存、被过滤或顺序变化，记录现象、操作时间和页面位置，交给维护人判断。
这里要区分“可能原因”和“已定位原因”。例如条目未出现，可能是未保存、被规则过滤或权限不足，不能直接断言是某一种原因；只有复现并排除后，才能写成确定结论。
维护：交接说明与变更记录
操作完成后，补一段维护说明：谁在什么情况下需要更新关键词，更新后由谁复核，历史版本放在哪里。可以维护一张简单记录表，字段包括日期、操作人、变更内容、复核人。这样下一次协作时，接手人不必从头询问背景。
适用条件上，这套写法适合需要多人接力、交付物会被反复修改的场景；如果只是个人一次性操作，可以省略部分交接字段，但准备和验证两步仍建议保留。
下一步：挑一个最近因“添加关键词”返工过的任务，按上面的准备、实施、验证、维护四段重写一遍操作说明，并请未参与该任务的同事按说明独立执行一次，记录他卡住的位置，再据此补充判断条件。
