有效的项目提示词不靠堆砌角色设定，而是把 Agent 做什么、依据什么、不能改什么以及怎样算完成写清楚。复杂任务先用 Plan Mode 审计划。
开始前先准备什么
先把需求写成一句可观察结果，再补相关文件、现有行为和真实验证命令。
写提示词前先回答四个问题：谁会看到变化、现在发生什么、希望改成什么、用什么证据签收。如果其中任何一项未知，就把“先调查并报告”设为第一阶段，不要让 Agent 在缺少业务事实时直接编码。还要先查看 git status，把现有改动列为保护范围。
上下文以“足够做决定”为准。已知文件可以用 @文件 或 @目录 附加；终端输出可用 @Terminals，未提交变化可用 Git diff 上下文，页面问题可加入 Browser 上下文。官方提示文档说明，不知道相关文件时可以不强塞整个仓库，让 Agent 先搜索。
实际操作步骤
目标写成用户行为，例如“空搜索结果显示提示”，避免“优化体验”这类空话。
- 目标：写成可观察的用户行为，例如“空搜索结果显示提示并保留原筛选条件”，避免“优化体验”这类无法签收的空话。
- 依据：上下文用 @文件或 @目录加入已知相关范围；不确定时让 Agent 先搜索，不要一次附整个仓库。要求它引用找到的入口和现有模式。
- 范围：列出允许修改与禁止修改的内容，例如禁止新增依赖、禁止改接口、不可触碰生产配置，删除或迁移前必须询问。
- 验收：给出真实测试命令、手工步骤、输入与预期结果，不能只写“确保正常”。
- 先规划：跨文件或范围不清时切换 Plan Mode。它会调查代码、提出问题并生成可编辑计划；让 Plan Mode 输出文件清单、数据流、风险和回退方式后再批准构建。
一个可复制的四段式模板
目标：当搜索结果为空时，页面显示“没有符合条件的结果”，并保留当前筛选项。
上下文：请先读取 @src/search/ 和现有测试，指出路由入口、状态来源与可复用空状态组件。
范围：只改搜索页面及对应测试；不改 API、数据结构和公共组件；不新增依赖；发现需求冲突先停下询问。
验收：运行仓库现有的搜索页测试和构建；用查询词 zzz-test 复现空结果，提示可见，筛选项不重置；返回改动文件、命令与结果。
执行方式：先给计划、风险和预计文件，不要立即修改。这是演示模板，文件路径、命令和输入必须替换为仓库里的真实内容。一个合格计划应该解释状态从哪里来、为什么只改这些文件、测试怎样覆盖失败分支。如果 Agent 只把需求换句话复述，没有找到代码证据，计划还不能批准。
怎样验证结果
好提示词的验收结果是 Agent 能复述目标、列出有限改动范围，并用指定命令证明完成。
审查时逐项回看四段内容：目标行为是否出现，附加上下文是否真的被读取，禁止范围是否保持不变，验收命令是否真实执行。命令的名称、退出码和关键结果应可复核；“测试应该能过”不算结果。若执行偏离，优先回到计划补充遗漏条件，再决定重跑或局部修复。
常见错误
- 不要要求一次完成多个无关需求。
- 不要把真实密钥贴进上下文。
- 不要把“测试一下”当作验收命令。
适用边界
提示词不能替代项目权限、代码审查和测试；高影响操作仍需人工确认。
Plan Mode 适合多个可选方案、多文件改动和架构决定；已熟悉的单行安全改动可直接给小任务。提示词里也不要放密钥、真实客户数据或生产 Cookie。需要这些信息才能继续时，应改用项目规定的安全配置方式，并只给 Agent 必要的非敏感接口说明。
相关问答
提示词越长越好吗？
不是。保留能改变决策的信息，重复背景会占上下文并降低重点。
什么时候必须用 Plan Mode？
跨多个文件、有迁移或范围不清时先规划；单行安全修复可直接给小任务。
资料与适用范围
本文根据 2026 年 10 月 1 日核验的 官方资料 1、官方资料 2 整理。示例流程未在你的设备、账号或仓库中实测，界面、方案、权限和项目命令应以当前环境为准。
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/32604.html
