建站任务记录哪些信息：适用条件与例外如何区分

整理建站任务时，除了写清“要做什么”，还应说明要求适用于哪些页面、流程或环境，以及哪些情况需要另行处理。范围不清，执行者可能把局部规则当成全站要求；例外若没有记录判断依据，也难以确认是否需要重复操作。 先写任务对象和目标：涉及哪个站点、页面或功能，完成后预期出现什么可检查的变化。再记录当前状态、相关环境和前置条件，例如任务是否只针对某类页面，是否依赖已有内

整理建站任务时，除了写清“要做什么”，还应说明要求适用于哪些页面、流程或环境，以及哪些情况需要另行处理。范围不清，执行者可能把局部规则当成全站要求；例外若没有记录判断依据，也难以确认是否需要重复操作。

先写任务对象和目标：涉及哪个站点、页面或功能，完成后预期出现什么可检查的变化。再记录当前状态、相关环境和前置条件，例如任务是否只针对某类页面，是否依赖已有内容或配置。尚未确认的信息应标为待核实，不要用猜测补齐。

区分适用范围与例外，可以按“默认条件—不适用条件—处理方式”记录。比如，改动只适用于指定页面，就写明页面范围；若有暂不调整的页面，也要列出识别依据和后续处理办法。例外应对应明确条件，不能只写“特殊情况另议”。各网站的结构和工作流程不同，一处任务的范围不能直接套用到所有站点。

涉及AI工具或写作API时，可记录请求目的、输入内容的简要说明、执行时间、任务编号和已知结果。模型输出不等于事实核验；API超时也不能单独证明请求未处理或未计费。应先核对已有结果，再决定是否重试。自有系统可以结合任务编号和内容摘要识别重复入库，但这不代表服务端一定支持相同机制。

不要在任务记录中写入密钥、访问令牌等敏感信息。密钥只应保存在服务端或受保护的本机配置中，也不要放进网页正文或日志。任务完成后，补记实际变更、未完成项和判断依据，方便复核；范围有变化时，应更新记录，而不是悄悄扩大原任务。