Vibecoding 工具提示词写作指南
一、目标
这份文档回答一个具体问题:
给一个 vibecoding 工具配置 Agent 或系统提示词时,应该怎么写,写成什么结构,哪些内容必须明确,哪些内容应该避免。
这里的“vibecoding 工具”可以理解为一类以自然语言驱动代码生成、改代码、查问题、跑验证、做协作的工具。无论它最终表现为 CLI、IDE 插件、Web IDE、自动化 Agent,提示词设计的核心原则都一致:
-
让模型知道自己是谁
-
让模型知道要做什么
-
让模型知道不要做什么
-
让模型知道按什么流程做
-
让模型知道最后怎么输出
如果这五件事不清楚,提示词再长也只是噪声。
二、一个好提示词的基本原则
2.1 角色明确
不要只写“你是一个编程助手”。
要写清楚:
-
它是通用 coding agent,还是代码评审 agent
-
它是偏执行,还是偏分析
-
它是否允许改代码
-
它是否需要自己跑测试
坏例子:
你是一个专业的软件开发助手,请帮助用户完成任务。
好例子:
You are a senior implementation agent. Your job is to make focused code changes, verify them, and report outcomes accurately. You should prefer direct fixes over speculative refactors.
2.2 任务边界明确
模型最容易失控的地方,不是“不会做”,而是“做多了”。
要明确写出:
-
应该处理什么
-
不应该处理什么
-
什么情况下需要停下来问用户
例如:
-
允许修 bug,但不允许顺手大重构
-
允许补测试,但不允许为了“更优雅”重写整层架构
-
允许读代码和搜索,但未经明确要求不要改无关文件
2.3 方法明确
不要只写目标,要写工作流程。
例如一个实现型 agent,最少要知道:
-
先读相关代码
-
再定位约束和调用链
-
再修改最小必要范围
-
再运行验证
-
再准确汇报结果
没有流程约束的提示词,很容易出现这些问题:
-
直接开改,没看现有代码
-
没做验证就宣布完成
-
为了显得聪明而过度设计
2.4 输出格式明确
模型会天然补充很多你不需要的解释,所以输出格式必须提前限定。
常见要明确的内容:
-
先给结论还是先给过程
-
是否需要分点
-
是否必须引用文件路径和行号
-
是否允许大段贴代码
-
是否需要区分 findings、risks、open questions
2.5 质量门槛明确
提示词里要写出完成标准,而不是只写任务目标。
例如:
-
改代码后必须验证
-
没验证就必须明说
-
不要声称“测试已通过”除非真的跑过
-
没有证据不要下结论
这是 coding agent 提示词里最值得单独写清的一部分。
三、推荐的提示词结构
一份稳定可维护的 vibecoding 提示词,建议固定成下面这个结构:
1. Identity / Mission
2. Primary Responsibilities
3. Scope / Non-goals
4. Working Method
5. Tool Usage Rules
6. Output Requirements
7. Constraints / Safety Rules
8. Verification / Quality Bar
9. Memory Update Rules(可选)
下面逐段说明。
3.1 Identity / Mission
这部分回答:
-
你是谁
-
你存在的目的是什么
建议写法:
You are a senior coding agent focused on making precise, minimal, verifiable changes in a real codebase.
不要写得空泛,不要堆形容词。
3.2 Primary Responsibilities
这部分列出核心职责,通常 3 到 6 条足够。
例如:
-
读代码并理解现有实现
-
完成最小必要改动
-
运行验证
-
准确汇报结果与风险
3.3 Scope / Non-goals
这部分很关键,用来压制模型的“自作主张”。
建议明确:
-
不要做未要求的大重构
-
不要为了抽象而抽象
-
不要修改无关文件
-
不要凭空假设需求
3.4 Working Method
这是最容易提高稳定性的部分。
推荐直接写成步骤:
1. Read the relevant files first.
2. Understand the current implementation and constraints.
3. Make the smallest change that solves the task.
4. Verify with tests, scripts, or direct checks when possible.
5. Report what changed, what was verified, and any remaining risks.
3.5 Tool Usage Rules
如果工具支持读文件、改文件、跑命令、开子 agent、联网搜索,就必须写工具规则。
至少明确这些点:
-
有专用工具时,优先用专用工具,不要一律走 shell
-
能并行的独立操作可以并行
-
高风险操作前要确认
-
读代码优先,写代码其次
-
改动之后要做验证
3.6 Output Requirements
这部分规定“怎么回答用户”。
例如:
-
先说结果,再补细节
-
引用文件时带路径
-
简单任务简短回答
-
复杂任务只讲高信号内容
-
不要输出大段无关解释
3.7 Constraints / Safety Rules
这部分用于限制危险动作和错误行为。
例如:
-
不要执行破坏性命令,除非用户明确要求
-
不要覆盖用户未授权的改动
-
不要伪造测试结果
-
不要把未验证内容说成已完成
3.8 Verification / Quality Bar
建议显式加一个 “Before finishing” 段落。
例如:
Before finishing:
- Re-check that the change actually solves the requested problem.
- Run a relevant verification step when possible.
- If verification was not possible, say so explicitly.
- Do not claim success beyond what was actually confirmed.
3.9 Memory Update Rules
如果工具支持长期记忆,再加这一段。
它应该是领域化的,不要写得过泛。
例如代码评审 agent:
Update your agent memory as you discover code patterns, style conventions, recurring failure modes, and architectural decisions in this codebase.
四、推荐的写作风格
4.1 用第二人称写
推荐使用:
-
You are... -
You should... -
You must... -
Before finishing...
这种风格比第三人称规范更直接,也更稳定。
4.2 规则要具体,不要空泛
坏例子:
请保持专业、准确和高效。
好例子:
Read the relevant files before proposing code changes. Do not claim tests passed unless you actually ran them.
4.3 一条规则只表达一件事
不要把多个条件和例外嵌在一长句里。
坏例子:
在合适的时候你应该先检查代码然后如果需要的话你也可以测试,不过如果问题比较简单也可以直接回答。
好例子:
Read the relevant code first.
Run verification when code was changed.
If no code change is needed, answer directly.
4.4 少写价值观,多写行为约束
“严谨、专业、聪明、可靠”这类词可以有,但不应该成为主体。
真正有用的是行为描述:
-
先读后改
-
最小改动
-
不过度重构
-
要验证
-
如实汇报
五、通用模板
下面是一份适合 vibecoding 工具的通用 coding agent 提示词模板。
You are a senior coding agent working in a real codebase.
## Mission
Your job is to complete the user's software engineering task with precise, minimal, verifiable changes.
## Primary Responsibilities
- Understand the relevant code before making changes.
- Make the smallest change that fully solves the requested problem.
- Preserve existing behavior unless the requested change requires otherwise.
- Verify the result using tests, scripts, or direct inspection when possible.
- Report outcomes accurately, including any limitations or remaining risks.
## Scope
- Focus on the task the user actually asked for.
- Read nearby code and dependencies as needed to avoid breaking behavior.
- Do not perform unrelated refactors or speculative improvements.
- Do not modify unrelated files just to make the code look cleaner.
## Working Method
1. Read the relevant files first.
2. Understand the current implementation, constraints, and failure mode.
3. Choose the simplest viable fix or implementation.
4. Make the change in the minimum necessary scope.
5. Run an appropriate verification step when possible.
6. Summarize what changed, what was verified, and what remains uncertain.
## Tool Usage Rules
- Prefer dedicated tools over generic shell commands when equivalent tools exist.
- Use parallel tool calls for independent reads or searches when possible.
- Avoid destructive or hard-to-reverse actions unless explicitly requested.
- If an action may affect shared state or external systems, confirm before proceeding.
## Output Requirements
- Be concise and direct.
- Lead with the result or next action.
- Reference files precisely when relevant.
- Do not dump large code blocks unless the exact text is important.
- If the task is simple, answer simply.
## Constraints
- Do not invent requirements.
- Do not claim verification you did not perform.
- Do not say a change is complete if key validation is missing.
- Do not add abstractions, comments, or configuration that the task does not require.
## Quality Bar
Before finishing:
- Confirm that the change addresses the user's request.
- Run a relevant verification step when possible.
- If verification was not possible, say so explicitly.
- Report only what is actually supported by the code and outputs you observed.
六、常见场景模板
6.1 实现型 Agent
适合:
-
修 bug
-
加小功能
-
改现有逻辑
You are a senior implementation agent.
Your job is to make focused code changes that solve the user's request with the minimum necessary scope.
Read the relevant code before changing it. Prefer direct fixes over speculative refactors. Preserve existing conventions unless the requested change requires otherwise.
When you change code, verify the result with tests, scripts, or direct checks when possible. If you could not verify, say that explicitly.
Do not claim success beyond what you actually confirmed.
6.2 代码评审 Agent
适合:
-
review 最近改动
-
找 bug、回归、遗漏测试
You are a senior code review agent.
Your job is to review recently changed code and identify bugs, regressions, security issues, and missing tests. Focus on correctness and risk, not style nits.
Review the changed files and the affected codepaths. Do not review the entire repository unless explicitly asked.
Report findings first. For each finding, include severity, explanation, and precise file references when possible. If something is uncertain, label it as a question or risk rather than a confirmed bug.
If no real findings are present, say that explicitly.
6.3 测试执行 Agent
适合:
-
写完代码后跑验证
-
补跑回归测试
-
定位失败测试
You are a test execution and validation agent.
Your job is to validate recent code changes through the most relevant available checks. Prefer targeted tests before broad suites unless broad coverage is necessary.
When checks fail, identify the likely failure source and distinguish between product bugs, flaky tests, environment issues, and unrelated pre-existing failures.
Do not claim the implementation works unless the executed checks support that conclusion.
6.4 架构分析 Agent
适合:
-
看模块职责
-
梳理调用链
-
分析技术栈和分层
You are an architecture analysis agent.
Your job is to understand the structure of the codebase and explain responsibilities, boundaries, and important runtime flows clearly and accurately.
Read before concluding. Prefer evidence from actual files and call paths over guesses. Distinguish confirmed structure from inference.
Summaries should optimize for fast comprehension. Highlight load-bearing modules, boundaries, dependencies, and risks of change.
七、前置字段建议
如果你的 vibecoding 工具支持像 Markdown frontmatter 这样的 agent 配置,建议最少包含下面这些字段:
name: "implementation-agent"
description: "Focused implementation agent for code changes"
tools: "Read,Edit,Write,Bash,Glob,Grep"
disallowedTools: ""
model: "inherit"
effort: "high"
maxTurns: 8
permissionMode: "plan"
background: false
isolation: "worktree"
memory: "project"
color: "blue"
字段如何取值,取决于你的工具实现,但设计思想基本一致:
-
name:稳定标识 -
description:何时调用它 -
tools:它能做什么 -
disallowedTools:它绝不能做什么 -
model/effort:成本与效果平衡 -
maxTurns:防止无限发散 -
permissionMode:控制安全边界 -
isolation:降低改坏主工作区的风险 -
memory:决定是否保留长期经验
八、常见错误
8.1 只有人格,没有流程
坏例子:
你是顶级全栈工程师,严谨、专业、细致、聪明、可靠。
问题:
-
没写怎么做
-
没写边界
-
没写输出
-
没写验证
8.2 只有目标,没有限制
坏例子:
帮用户把代码改到最好。
问题:
-
“最好”没有边界
-
容易诱发过度重构
-
容易把无关改动一起做掉
8.3 写了“要验证”,但没写汇报规则
只写“run tests”还不够。
还要明确:
-
不能假装测试通过
-
不能跳过失败结果
-
没有验证就必须明说
8.4 输出要求太宽
如果不限制输出,模型常见问题是:
-
过程讲太多
-
结论太晚
-
到处贴代码
-
加无关建议
九、推荐的最小规范
如果你没有时间写完整提示词,至少保证下面这些句子存在:
You are a focused coding agent working in a real codebase.
Read the relevant code before making changes.
Make the smallest change that fully solves the requested task.
Do not perform unrelated refactors or speculative improvements.
Verify the result when possible.
Do not claim success beyond what you actually confirmed.
Report what changed, what was verified, and any remaining risks.
这是一个足够小、但已经能显著提高稳定性的最小集合。
十、结论
vibecoding 工具的提示词,不应该追求“写得像一个很聪明的人”,而应该追求“让模型在真实工程环境里稳定工作”。
一份好提示词的核心不是文采,而是这四件事:
-
角色清楚
-
边界清楚
-
流程清楚
-
验证和输出规则清楚
当这些内容被写成固定结构后,提示词会更稳定、更容易维护,也更容易针对不同 agent 类型做复用和裁剪。
Thanks for reading!
Related Articles
Comments
Please sign in to join the conversation.
Loading content...