Vibe-Coding

项目开发

项目开发的提示词

重要工具清单

1) 任务管理

任务管理工具提供后台任务的全生命周期控制能力，覆盖从创建、查询、更新、监控到停止的完整链路。

工具名称 readOnly destructive concurrencySafe 简要说明
TaskCreateTool false false false 创建后台任务（条件启用：Todo V2）
TaskGetTool true false true 获取单个任务详情
TaskUpdateTool false false false 更新任务状态或内容
TaskListTool true false true 列出所有任务
TaskOutputTool 动态 false 动态 获取任务输出流；当 readOnly 时，concurrencySafe 为 true
TaskStopTool false false true 停止正在运行的任务

典型工作流

  1. 使用 TaskCreateTool 创建任务。
  2. 使用 TaskListTool 查看整体进度。
  3. 使用 TaskGetTool 检查单任务详情。
  4. 使用 TaskOutputTool 持续获取输出日志。
  5. 需要中断时，使用 TaskStopTool 停止任务。

2) 计划

计划模式工具用于“先规划、后执行”，在复杂变更前提供更安全的分析与决策路径。

工具名称 readOnly destructive concurrencySafe 简要说明
EnterPlanModeTool true false true 进入计划模式，仅允许使用只读工具集
ExitPlanModeV2Tool true false true 退出计划模式，恢复正常工具权限

使用场景

计划模式是一种安全策略：进入后，智能体只能使用只读工具（如 FileReadTool、GrepTool）进行信息收集与分析，不能执行任何修改操作。该模式适用于复杂需求前的方案设计、风险评估与影响分析。可结合第 14 章“结构化工作流”使用。

3) 用户澄清

当需求不完整、存在多种实现分支，或继续执行可能引发误操作时，应优先通过提问与用户确认。

工具名称 readOnly destructive concurrencySafe 简要说明
AskUserQuestionTool true false true 向用户发起澄清问题，获取关键决策后再继续执行

推荐触发时机

  1. 需求存在歧义（如目标、范围、优先级不明确）。
  2. 需要用户在多个方案中做选择（如性能优先 vs. 可维护性优先）。
  3. 涉及潜在破坏性操作前（如删除数据、批量覆盖、重构核心路径）。
  4. 发现上下文缺失（如缺少环境变量、账号权限、外部依赖信息）。

按计划开发连续工作提示词

用于“先计划、再连续执行”的场景，减少来回确认成本。

基础版（通用）

1
2

开始开发。请严格按既定计划连续执行，直到所有任务完成前不要主动中断；
若遇到阻塞、信息缺失或高风险操作，请暂停并向我提问确认。

增强版（含质量约束）

1
2
3
4
5
6
7

按照当前计划持续开发直到全部任务完成。
要求：
1) 小步提交，每步可验证；
2) 保持与现有代码风格一致；
3) 变更后运行相关测试/检查；
4) 出现失败先定位根因再修复；
5) 仅在以下情况暂停并提问：需求歧义、权限不足、外部依赖缺失、潜在破坏性操作。

配套执行规范

  • 每轮输出包含：当前步骤、完成情况、下一步。
  • 对未解决问题给出：影响范围、候选方案、推荐方案。
  • 涉及数据库/配置/权限变更时，必须先确认再执行。

从零到一项目开发

适用于新项目冷启动，目标是从“想法”快速推进到“可运行 MVP”。

推荐流程

  1. 需求澄清：目标用户、核心场景、验收标准。
  2. 技术选型：框架、数据存储、部署方式、成本约束。
  3. 架构设计：模块划分、接口边界、目录结构。
  4. 里程碑拆分：MVP → Beta → 正式版。
  5. 实现与验证：按优先级逐步交付并测试。

可复用提示词 

1
2
3
4
5
6
7
8

我们要从零开始做一个[项目名称]。
请先不要写代码，先完成以下任务：
1) 梳理需求与范围（做与不做）；
2) 给出技术选型建议及权衡；
3) 设计系统架构与目录结构；
4) 输出分阶段实施计划（MVP/Beta/GA）；
5) 列出风险与缓解策略。
确认后再进入编码阶段。

1
2
3
4
5

现在开始实现 MVP：
- 严格按计划执行；
- 每完成一项就更新 Todo 与进度；
- 先实现主链路，再补异常与边界；
- 完成后给出运行方式与验收结果。

新增功能需求开发

适用于已有项目中的增量需求，重点是“兼容存量、控制影响面”。

标准步骤

  1. 阅读相关模块，确认现有实现模式。
  2. 明确需求边界与非目标。
  3. 设计最小改动方案（接口、数据、UI/交互）。
  4. 先补测试或验收用例，再实现。
  5. 回归验证并输出变更说明。

可复用提示词 

1
2

请先分析[现有功能]在[文件/模块]中的实现方式，不要立即改代码。
然后给出新增[新功能]的改动方案

代码重构与优化

Bug 修复

修复策略强调“先复现、再定位、后修复、再验证”。

可复用提示词 

1

我在执行[命令/操作]时出现错误：[粘贴报错]。