建站任务记录：按情境整理需求、接口与故障信息

整理建站任务时，记录内容要随情境变化。先写清目标、涉及的页面或功能、当前状态和预期结果，避免只写“页面有问题”或“接入AI”这类无法复现的描述。以下内容用于团队协作或自有系统整理，不是厂商通用参数。 处理页面或内容需求时，记录目标页面、目标用户、要完成的操作、必需内容和验收条件。例如，说明用户需要找到什么信息、页面应提供什么入口，以及哪些内容仍需负责人确认

整理建站任务时，记录内容要随情境变化。先写清目标、涉及的页面或功能、当前状态和预期结果，避免只写“页面有问题”或“接入AI”这类无法复现的描述。以下内容用于团队协作或自有系统整理，不是厂商通用参数。

处理页面或内容需求时，记录目标页面、目标用户、要完成的操作、必需内容和验收条件。例如，说明用户需要找到什么信息、页面应提供什么入口，以及哪些内容仍需负责人确认。需求尚未确定时，标出待确认事项和负责人，不要把推测写成定案。

接入写作API或其他AI工具时，可记录调用目的、请求与响应的非敏感摘要、发生时间、任务编号、结果状态和必要的错误信息。记录范围以排查问题、识别重复任务为限。密钥只放在服务端或受保护的本机配置中，不要写进网页、正文或日志；保存请求内容前，也要检查其中是否含有个人信息或其他敏感资料。具体字段取决于所用工具和系统，不能假设接口参数都相同。

排查故障时，补充操作步骤、影响范围、发生时间、近期改动，以及问题能否重现。接口超时不能证明请求未处理或未计费。重试前，先查看已有响应、任务状态或自有系统的处理记录。任务编号和内容摘要可帮助自有系统避免重复入库，但不能代替结果核验。

记录中还应区分事实、判断和待确认事项。模型输出不等于事实核验，发布前仍需人工检查内容与页面表现。任务结束后，保留解决办法和未解决风险，并删除不再需要的敏感信息。这样，后续维护者能了解任务上下文，也不容易把一次故障当成普遍规律。