把 AI 当成实习生：提示词、上下文与任务拆解
第一天演示 To Do List 时，我先只输入一句：“帮我生成一个 To Do List 应用。”页面很快出来了，但技术栈、视觉风格和功能细节都由模型自行猜测。
第二轮，我补充了 HTML、CSS、JavaScript、现代简洁风、蓝色主题以及需要实现的功能。结果明显更接近预期。
这个实验不是为了证明提示词越长越好，而是让学生看到：你留给 AI 的猜测空间越大，结果的随机性就越高。
把提示词理解成任务委托
我最常用的心法是：把 AI 当作一个知识很多、执行很快，但不了解现场的实习生。
给实习生安排任务时，不会只说“你做一下”，而会交代五类信息：
- 背景：为什么做，当前项目和用户处于什么状态。
- 目标：这次希望改变什么结果。
- 任务：具体需要分析、编写或修改什么。
- 交付：最终要得到代码、文档、表格还是可运行页面。
- 约束：技术栈、范围、格式、风格和明确不能做的事。
这五项不是固定模板，而是一份最低限度的工作说明。简单任务可以很短，复杂任务则需要附上现有文件、截图和标准案例。
精准比冗长更重要
很多初学者理解提示词工程后，会走向另一个极端：每次都写几百字角色设定，却没有提供真正影响结果的信息。
有效上下文通常包括：
- 当前项目里的真实文件，而不是重新口述一遍。
- 目标页面截图或设计规范，而不是“做得高级一点”。
- 明确的输入输出示例，而不是抽象形容词。
- 现有错误日志和复现步骤，而不是“代码报错了”。
- 验收标准和范围边界，而不是“功能完整”。
无效上下文则包括重复寒暄、互相矛盾的旧要求、大段与当前任务无关的历史对话，以及没有说明用途的资料堆积。
一个窗口只解决一个主题
在训练营实操中，最常见的问题之一是所有工作都挤在同一个对话里：先聊立项，再生成 PRD，又做原型，接着搭后端，最后还让 AI 修部署问题。
对话越长，旧信息越容易和新任务混在一起。模型可能继续沿用已经废弃的技术选型，也可能把 C 端页面要求带到管理后台。
更稳妥的方式是按交付物建立边界：
- 立项与 ROI 一个主题。
- 三层需求与 PRD 一个主题。
- 原型设计一个主题。
- 技术方案与脚手架一个主题。
- 每个独立功能再开自己的开发任务。
需要继承的信息，用经过确认的文档传递，而不是依赖一条无限延长的聊天记录。
复杂任务一定要拆
任务拆分不是把一句话机械切成十个步骤，而是让每一步都具备独立结果和验证方法。
例如“完成水果商城”无法直接验收，可以拆成：
- 梳理用户下单业务流程。
- 输出 C 端页面清单和页面流转。
- 明确注册功能的正常与异常规则。
- 生成并评审 PRD。
- 生成多个风格 Demo，确认设计方向。
- 输出技术方案并搭建可运行脚手架。
- 逐个实现注册、登录、商品和订单功能。
- 每个功能完成后测试、提交和回归。
每一步都有明确产物，也允许人及时纠偏。即使后面失败，前面确认过的结果仍然可以复用。
文件、Rule、Skill 和工具怎样配合
如果要求只对当前任务有效，直接写进提示词或引用文件即可。
如果是项目长期遵守的编码、文档和验证规范，应该放进项目规则，让每次任务都能看到。
如果一项工作拥有稳定输入、固定流程和明确交付，可以封装成 Skill，让方法变成可复用 SOP。
外部工具则用于获取事实或执行动作，例如打开浏览器、查询数据库和操作 Git。不要因为工具多就全部启用；每一项工具说明都会占用注意力和上下文。
一份可直接复用的任务模板
讲师判断：好提示词的结果是减少来回解释
我判断一条提示词是否有效，不看它有多长，而看执行后还需要补充多少次关键信息。如果 AI 第一轮就能说清理解、列出风险并给出符合边界的交付，说明上下文质量较高；如果它不断追问项目位置、技术栈和验收方式，或者直接按自己的偏好扩展功能，说明任务委托仍然不完整。
还要警惕另一种极端：把所有背景一次性塞给 AI。信息越多不等于上下文越好。与当前任务无关的历史讨论、过期方案和大段日志会稀释重点。最稳妥的方式是围绕一个目标提供最小充分上下文，并明确哪些材料拥有最高优先级。
课后练习
把你最近使用过的一条模糊提示词改写成五要素版本。执行前先预测 AI 最可能误解的三个地方；执行后再对照结果，看哪些约束真正减少了偏差。