同一个模型，不同的工作环境
聊天应用、编辑器助手和能执行工具的智能体，都可能使用语言模型。真正影响工作方式的，是它能看到哪些信息、能调用哪些工具、执行前需要什么确认。
不要只从界面判断能力：聊天界面也可能有工具，终端界面也可能没有某项权限。开始前先确认能否读项目、修改文件、运行命令与查看结果。
你只把一段报错贴进聊天里，它就没有自动看到整个项目。让工具读取指定文件，或主动提供必要上下文，才有依据。
带走这一点 · 说明任务之前，先确定助手实际看得见和做得到什么。
选模型：看任务，而不是只看型号
不同模型在能力、速度、价格和输入限制上存在差异，同一模型在不同任务上也可能有不同表现。先用自己的典型任务做小样本验证，比根据名称猜效果可靠。
模型与工具的型号、价格和设置会更新。本课程保留判断方法，不把某个型号永久写成“最好”。简单转换与复杂项目修改，不必使用相同配置。
比较两个选项时，固定一份需求和验收标准，记录是否完成、耗时和实际成本。不要只比较答案长度。
带走这一点 · 用适合自己的任务评估模型，结果比宣传词更重要。
思考深度：给复杂问题更多处理空间
某些模型或工具提供推理预算等设置，允许在回答前投入更多计算。对于部分复杂任务可能有帮助，也可能增加等待和成本，且不能保证正确。
工具是否支持、如何控制，必须查看当前版本。重要任务仍应拆成有边界的步骤，给足证据，并设计独立验证。仅仅写一句“深入思考”不是质量保证。
跨多个文件的修改，需要先理解现有结构并评估影响。让 AI 先调查再修改，通常比不提供上下文只要求“认真点”更具体。
带走这一点 · 更多计算不能替代缺失信息和验收标准。
管理背景：把事实写成一份可更新的说明
把目标、已有实现、运行方法和长期约束写成项目说明，能帮助后续任务快速进入状态。具体工具怎样加载说明文件，应以它的功能和配置为准。
说明也会过时，需要跟随项目变化维护。把已确认事实、尚未确认的假设、已完成与待完成事项分开；不要用一长串历史聊天代替当前状态。
“当前数据存在浏览器；不需要登录；用这个命令启动；待验证刷新恢复”，是有用背景。“我们昨天讨论了十种方案”，通常还需要整理。
带走这一点 · 交接的目标是让接手者知道现状和下一步，而不是复述全部历史。
写清需求：目标、现状、约束和验收
好的描述包含服务对象与目标、已有条件、期望行为、范围约束和完成标准。遇到歧义时，可以要求 AI 先提出影响实现的关键问题，再继续。
排查故障同样需要准确：操作步骤、预期结果、实际结果、错误原文。把“我怀疑是数据库”标成假设，给检查留下空间。完整描述能减少来回猜测，但复杂任务仍然需要迭代。
“清单不好用”很难执行；“空白任务不能添加，提示原因，保留原有添加与删除，并验证刷新恢复”就有明确行为和验收。
带走这一点 · 专业性来自明确的信息和可检查的结果，不来自堆砌术语。
把模糊愿望拼成可执行的需求
依次补上目标、背景、约束和验收。观察同一个任务如何变得更明确。
帮我做个好用的东西。
0/4 类信息已明确。下方章末练习可以写你自己的版本。
这里检查的是信息结构，不是 AI 质量评分，也不保证真实模型一定正确执行。
哪段信息最有助于判断 AI 是否完成了“保存清单”？
先选一个答案，再看解释。
独立写一份清单改进需求，读者应能凭它判断什么叫完成。
先自己想，再按需打开提示。越往后，描述越完整，验收也越明确。
带着本章的背景去问 AI。拓展是选学，不影响继续阅读。
把我的模糊要求改成问题清单，先让我自己补充，不要直接替我作决定。
参考答案，可以改成你的版本
我正在从零学习计算机与 AI 编程。本章学过： 驾驭 AI：依据工具能力与权限决定交给它什么任务；管理项目背景，区分观察与猜测；组织一份完整需求，并用结果判断完成 把我的模糊要求改成问题清单，先让我自己补充，不要直接替我作决定。 请先确认我的理解，一次解释一个小问题，用具体例子并说明比喻的局限。讲完问一道情境题，根据我的回答继续。区分事实、推测和不确定内容；推荐可操作的验证方式。如果涉及具体工具，先确认版本，不要编造功能和资料。
完成这一章
标记各节已读，完成原理实验和情境题后，即可记录本章完成。随时可以直接阅读下一章。
继续查阅原始资料
正文是入门解释；下面的官方资料供你继续核对和深入。
Anthropic · Building effective agents