把问题说清楚，是使用 AI 的第一步。目标、背景、约束和输出格式，可以组成一份容易检查的任务说明。 与其只说帮我写点内容，不如明确读者、用途和期望结果。例如，请为初学者整理一份学习提纲，并用五个要点说明每一步要做什么。具体目标也方便判断回答有没有完成任务。 给出与问题有关的资料，说明哪些内容可以使用、哪些事实不能猜测，以及篇幅或格式要求。资料中不需要的个人信息可以先删除，不要为了让任务显得完整而加入无关敏感内容。 检查第一次回答后，指出需要修改的具体位置和原因。把有效的任务结构保存下来，下一次替换背景和目标即可使用；提示词仍需要随着任务改变，而不是追求一个通用万能句式。

理解 Token 和上下文，可以帮助整理长资料，也能让提问、引用和结果检查更有条理。 模型通常会把输入转换成 Token 再处理。文本的分词方式与模型有关，中文、英文和代码的对应关系也可能不同，因此不宜直接把字符数当成准确的 Token 数。 处理资料时，还要考虑任务说明、对话记录和输出内容。具体模型的窗口和输出限制应查看官方文档；不要仅凭一个宣传数字判断整份资料能否被完整处理。 可以按章节整理资料，保留标题和来源，再针对每一部分提出问题。得到摘要后回到原文核对关键事实，并检查不同章节之间有没有遗漏或矛盾。

流畅的回答不等于可靠的结论。把事实、引用和推断分开检查，可以让 AI 辅助工作更稳妥。 日期、数据、产品功能和法规条款都应单独核对。让 AI 列出依据可以辅助整理，但依据是否存在、是否真的支持结论，仍要由使用者检查。 优先查阅官方文档、原始报告和论文，注意资料的发布日期和适用范围。网页标题相似不代表内容一致，引用链接也不能代替对原文的阅读。 资料不足时可以明确写出尚未确认的部分，而不是把推测补成事实。对结果进行人工复核，并保存重要结论的来源，后续更新时更容易找到依据。

模型运行在哪里，只是选择的一部分。任务要求、设备资源、数据流向和维护成本，都需要一起考虑。 本地运行需要核对设备资源、模型格式和工具兼容性；云端使用则需要了解服务接口、网络条件和限制。先用一个小任务测试完整流程，再判断是否适合日常工作。 本地工具也可能连接外部服务，云端平台也各有数据处理规则。检查输入资料会经过哪些环节，以及日志、插件和同步功能如何工作，不要只根据名称判断数据是否离开设备。 模型更新、依赖安装、质量检查和故障处理都需要时间。适合自己的方案，应当能持续完成任务，并有明确的维护和数据管理方式。

AI 可以参与解释代码和整理草稿。把需求说明、代码审查和测试串起来，才能判断结果是否可用。 提交编程任务前，描述运行环境、输入示例、预期输出和异常情况。涉及现有项目时，补充必要的接口约定，避免让生成的代码与项目实际结构脱节。 检查错误处理、权限判断和边界条件，特别留意新增依赖和外部调用。对于看不懂的代码，可以先请求解释，再回到文档核对，不能以解释流畅作为正确性的证明。 运行适合任务的检查和测试，覆盖正常输入以及容易出错的情况。保留可回退的改动记录，在理解实现和验证结果之后，再把代码用于正式流程。

先建立目录、保留来源，再提出具体问题。清晰的文档结构能让摘要和核对更有方向。 准备资料时，尽量保留章节标题、页码和表格说明。扫描文档还需要检查文字识别结果，特别注意数字、单位和跨页内容是否被错误合并。 先列出需要回答的问题，再决定读取哪些章节。可以要求输出对应章节和引用位置，便于回到原文核对，但仍需要检查这些引用是否准确。 分段处理后，应重新查看不同章节之间的关联。摘要可能省略条件和例外，因此涉及行动决定时，需要结合原文的完整上下文来理解。

把经常重复的 AI 任务整理成模板，可以减少遗漏。保留稳定的任务结构，再用变量填写对象、资料和交付要求，比反复复制整段旧对话更容易维护。 先写清任务目标、必要背景和输出格式，再把每次会变化的内容留成填写项。变量可以包括读者、材料、篇幅和语气，避免把某次任务的专属信息误带到下一次。 为模板提供一份经过人工检查的输出示例，说明哪些特征是需要保留的。示例应足够简短，并明确它用于解释格式，不能替代当前任务的事实与资料。 检查回答是否遗漏约束、是否出现无依据的结论，以及格式是否方便后续使用。把反复出现的问题加入检查清单，并记录模板的适用场景与修改日期。

整理会议材料时，可以让 AI 分别提取讨论结论、待办事项和仍未确认的问题。输出后再逐项对照原始记录，避免把建议误写成已经通过的决定。 提供完整的会议材料，并说明会议主题、参与者及记录的起止范围。遇到人名或时间不清楚的地方，要求保留疑问标记，不要让工具自行补全没有出现的信息。 将已经确认的决定与需要继续讨论的问题分别列出。待办事项应包含具体动作、负责人及时间要求；原始材料没有提及时，明确标记为待确认，方便会后核对。 检查摘要中的每项结论是否能在记录中找到依据，并确认没有遗漏重要限制。把修改意见写回整理规则，保存一份经过核对的版本，再作为后续协作的参考。

在开始生成代码之前，可以先让 AI 将需求拆成用户动作、输入输出和验收条件。先检查问题是否被准确理解，再决定如何实现，通常比直接要求生成整个功能更容易检查。 用具体场景描述谁在什么情况下操作，以及希望得到什么结果。对页面、接口或文件的要求分别说明，避免把多个没有关系的目标混在同一段任务描述中。 为功能补充空输入、重复操作、加载失败等情况，并说明预期反馈。让 AI 把不确定的要求列成问题，先确定必要条件，再进入实现步骤，减少后续来回修改。 将每项要求对应到可以观察的结果，例如按钮状态、提示文字或数据变化。实现之后逐项核对，保存发现的问题及修复方式，不把生成的代码本身当作验收完成的依据。

比较不同 AI 工具的回答时，先固定问题、资料与输出要求，再记录准确性、完整性和表达方式。单次结果只能作为观察，不能直接代表所有任务中的表现。 准备一组与你实际用途相关的问题，为每个问题提供相同背景与限制。记录使用的工具、日期及可见版本信息，避免在资料条件不同的情况下直接比较最终答案。 分别观察回答是否符合要求、是否有可核对的依据，以及是否主动说明不确定之处。把格式好看与事实可靠分开记录，遇到重要结论仍应回到可信资料进行检查。 对容易受随机输出影响的问题可以重复测试，记录差异出现的位置。把结论限定在这组问题和测试条件内，再根据实际工作任务判断哪种工具更适合继续使用。