best-practices

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Best Practices — Prompt Transformer

最佳实践 — 提示词转换器

Transform prompts by adding what Claude needs to succeed.
通过添加Claude完成任务所需的要素来转换提示词。

Start Here

入门指南

Based on user's request:
User provides a prompt to transform: → Ask using AskUserQuestion:
  • Question: "How should I improve this prompt?"
  • Header: "Mode"
  • Options:
    1. Transform directly — "I'll apply best practices and output an improved version"
    2. Build context first — "I'll gather codebase context and intent analysis first"
User asks to learn/understand: → Show the 5 Transformation Principles section
User asks for examples: → Link to references/before-after-examples.md
User asks to evaluate a prompt: → Use the Success Criteria eval rubric at the end of this document

根据用户的请求:
用户提供需要转换的提示词: → 使用AskUserQuestion工具询问:
  • 问题: "我应该如何优化这个提示词?"
  • 标题: "模式选择"
  • 选项:
    1. 直接转换 — "我将应用最佳实践并输出优化后的版本"
    2. 先构建上下文 — "我将先收集代码库上下文并分析用户意图"
用户要求学习/了解相关内容: → 展示「5项转换原则」章节
用户要求查看示例: → 链接到references/before-after-examples.md
用户要求评估提示词质量: → 使用本文档末尾的「成功标准评估准则」

If "Transform directly"

若选择「直接转换」

Apply the 5 principles below and output the improved prompt immediately.
立即应用以下5项原则并输出优化后的提示词。

If "Build context first"

若选择「先构建上下文」

Launch 3 parallel agents to gather context:
Run these agents IN PARALLEL using the Task tool:

- Task task-intent-analyzer("[user's prompt]")
- Task best-practices-referencer("[user's prompt]")
- Task codebase-context-builder("[user's prompt]")
启动3个并行Agent来收集上下文:
使用Task工具并行运行这些Agent:

- Task task-intent-analyzer("[用户的提示词]")
- Task best-practices-referencer("[用户的提示词]")
- Task codebase-context-builder("[用户的提示词]")

What Each Agent Returns

各Agent的返回内容

AgentMissionReturns
task-intent-analyzerUnderstand what user is trying to doTask type, gaps, edge cases, transformation guidance
best-practices-referencerFind relevant patterns from references/Matching examples, anti-patterns to avoid, transformation rules
codebase-context-builderExplore THIS codebaseSpecific file paths, similar implementations, conventions
Agent任务目标返回结果
task-intent-analyzer理解用户的需求目标任务类型、存在的差距、边缘情况、转换指导建议
best-practices-referencer从references/目录中查找相关模式匹配的示例、需要避免的反模式、转换规则
codebase-context-builder探索当前代码库特定文件路径、类似实现、代码规范

After Agents Return

Agent返回结果处理流程

  1. Synthesize findings — Combine intent + best practices + codebase context
  2. Apply matching patterns — Use examples from best-practices-referencer as templates
  3. Ground in codebase — Add specific file paths from codebase-context-builder
  4. Transform the prompt — Apply the 5 principles with all gathered context
  5. Output — Show improved prompt with before/after comparison
  1. 综合分析结果 — 整合意图分析、最佳实践和代码库上下文
  2. 应用匹配模式 — 使用best-practices-referencer提供的示例作为模板
  3. 结合代码库信息 — 添加codebase-context-builder提供的特定文件路径
  4. 转换提示词 — 结合所有收集到的上下文应用5项转换原则
  5. 输出结果 — 展示优化后的提示词,并提供前后对比

Agent Definitions

Agent定义

The agents are defined in
agents/
:
  • agents/task-intent-analyzer.md
    — Analyzes intent, gaps, and edge cases
  • agents/best-practices-referencer.md
    — Finds relevant examples and patterns from references/
  • agents/codebase-context-builder.md
    — Explores codebase for files and conventions

这些Agent定义在
agents/
目录下:
  • agents/task-intent-analyzer.md
    — 分析意图、差距和边缘情况
  • agents/best-practices-referencer.md
    — 从references/目录中查找相关示例和模式
  • agents/codebase-context-builder.md
    — 探索代码库中的文件和规范

Transformation Workflow

转换工作流

When transforming (after mode selection):
  1. Identify what's missing — Check against the 5 principles below
  2. Add missing elements — Verification, context, constraints, phases, rich content
  3. Output the improved prompt — In a code block, ready to copy-paste
  4. Show what changed — Brief comparison of before/after

进行转换时(模式选择后):
  1. 识别缺失要素 — 对照以下5项原则检查
  2. 补充缺失内容 — 添加验证机制、上下文、约束条件、任务阶段、丰富内容
  3. 输出优化后的提示词 — 放在代码块中,方便复制粘贴
  4. 展示变更点 — 简要对比前后差异

The 5 Transformation Principles

5项转换原则

Apply these in order of priority:
按优先级顺序应用:

1. Add Verification (Highest Priority)

1. 添加验证机制(最高优先级)

The single highest-leverage improvement. Claude performs dramatically better when it can verify its own work.
MissingAdd
No success criteriaTest cases with expected inputs/outputs
UI changes"take screenshot and compare to design"
Bug fixes"write a failing test, then fix it"
Build issues"verify the build succeeds after fixing"
Refactoring"run the test suite after each change"
No root cause enforcement"address root cause, don't suppress error"
No verification report"summarize what you ran and what passed"
BEFORE: "implement email validation"
AFTER:  "write a validateEmail function. test cases: user@example.com → true,
         invalid → false, user@.com → false. run the tests after implementing"
BEFORE: "fix the API error"
AFTER:  "the /api/orders endpoint returns 500 for large orders. check
         OrderService.ts for the error. address the root cause, don't suppress
         the error. after fixing, run the test suite and summarize what passed
         and what you verified."
这是提升效果最显著的优化手段。 当Claude可以验证自己的工作成果时,表现会大幅提升。
缺失内容需要补充
无成功标准包含预期输入/输出的测试用例
UI变更"截取截图并与设计稿对比"
Bug修复"先编写一个失败的测试用例,再修复问题"
构建问题"修复后验证构建是否成功"
代码重构"每次变更后运行测试套件"
无根本原因要求"解决根本原因,不要掩盖错误"
无验证报告"总结你运行的测试和通过的内容"
优化前: "实现邮箱验证"
优化后: "编写一个validateEmail函数。测试用例:user@example.com → true,
         invalid → false, user@.com → false。实现后运行测试"
优化前: "修复API错误"
优化后: "/api/orders接口在处理大订单时返回500错误。检查
         OrderService.ts中的问题。解决根本原因,不要掩盖
         错误。修复后运行测试套件,总结通过的测试和验证内容。"

2. Provide Specific Context

2. 提供特定上下文

Replace vague references with precise locations and details.
VagueSpecific
"the code"
src/auth/login.ts
"the bug""users report X happens when Y"
"the API""the /api/users endpoint in routes.ts"
"that function"
processPayment()
on line 142
Four ways to add context:
StrategyExample
Scope the task"write a test for foo.py covering the edge case where user is logged out. avoid mocks."
Point to sources"look through ExecutionFactory's git history and summarize how its API evolved"
Reference patterns"look at HotDogWidget.php and follow that pattern for the calendar widget"
Describe symptoms"users report login fails after session timeout. check src/auth/, especially token refresh"
Respect Project CLAUDE.md:
If the project has a CLAUDE.md, the transformed prompt should:
  • Not contradict project conventions
  • Reference project-specific patterns when relevant
  • Note any project constraints that apply
BEFORE: "add a new API endpoint"
AFTER:  "add a GET /api/products endpoint. check CLAUDE.md for API conventions
         in this project. follow the pattern in routes/users.ts. run the API
         tests after implementing."
BEFORE: "fix the login bug"
AFTER:  "users report login fails after session timeout. check the auth flow
         in src/auth/, especially token refresh. write a failing test that
         reproduces the issue, then fix it"
用精确的位置和细节替换模糊的表述。
模糊表述具体表述
"代码"
src/auth/login.ts
"Bug""用户反馈当Y发生时会出现X问题"
"API""routes.ts中的/api/users接口"
"那个函数"第142行的
processPayment()
添加上下文的四种方式:
策略示例
限定任务范围"为foo.py编写测试,覆盖用户未登录的边缘情况。避免使用模拟。"
指向源代码"查看ExecutionFactory的Git历史,总结其API的演变过程"
参考现有模式"参考HotDogWidget.php的模式来实现日历组件"
描述症状"用户反馈会话超时后登录失败。检查src/auth/目录,特别是令牌刷新部分"
遵循项目CLAUDE.md:
如果项目包含CLAUDE.md,转换后的提示词应:
  • 不违反项目规范
  • 相关时参考项目特定模式
  • 注明适用的项目约束
优化前: "添加新的API接口"
优化后: "添加GET /api/products接口。查看CLAUDE.md了解本项目的API规范。
         遵循routes/users.ts中的模式。实现后运行API测试。"
优化前: "修复登录Bug"
优化后: "用户反馈会话超时后登录失败。检查src/auth/目录中的认证流程,
         特别是令牌刷新部分。编写一个能复现问题的失败测试用例,再修复问题"

3. Add Constraints

3. 添加约束条件

Tell Claude what NOT to do. Prevents over-engineering and unwanted changes.
Constraint TypeExamples
Dependencies"no new libraries", "only use existing deps"
Testing"avoid mocks", "use real database in tests"
Scope"don't refactor unrelated code", "only touch auth module"
Approach"address root cause, don't suppress error", "keep backward compat"
Patterns"follow existing codebase conventions", "match the style in utils.ts"
BEFORE: "add a calendar widget"
AFTER:  "implement a calendar widget with month selection and year pagination.
         follow the pattern in HotDogWidget.php. build from scratch without
         libraries other than the ones already used in the codebase"
告诉Claude不能做什么。防止过度设计和不必要的变更。
约束类型示例
依赖限制"不使用新库", "仅使用现有依赖"
测试要求"避免使用模拟", "测试中使用真实数据库"
范围限制"不要重构无关代码", "仅修改认证模块"
方法要求"解决根本原因,不要掩盖错误", "保持向后兼容性"
模式要求"遵循现有代码库规范", "匹配utils.ts中的风格"
优化前: "添加日历组件"
优化后: "实现一个包含月份选择和年份分页的日历组件。
         遵循HotDogWidget.php中的模式。基于现有代码库中的依赖从头实现,
         不使用外部库"

4. Structure Complex Tasks in Phases

4. 将复杂任务分阶段处理

For larger tasks, separate exploration from implementation.
The 4-Phase Pattern:
Phase 1: EXPLORE
"read src/auth/ and understand how we handle sessions and login.
 also look at how we manage environment variables for secrets."

Phase 2: PLAN
"I want to add Google OAuth. What files need to change?
 What's the session flow? Create a plan."

Phase 3: IMPLEMENT
"implement the OAuth flow from your plan. write tests for the
 callback handler, run the test suite and fix any failures."

Phase 4: COMMIT
"commit with a descriptive message and open a PR"
When to use phases:
  • Uncertain about the approach
  • Change modifies multiple files
  • Unfamiliar with the code being modified
Skip phases when:
  • Could describe the diff in one sentence
  • Fixing a typo, adding a log line, renaming a variable
BEFORE: "add OAuth"
AFTER:  "read src/auth/ and understand current session handling. create a plan
         for adding OAuth. then implement following the plan. write tests and
         verify they pass"
对于大型任务,将探索和实现分离。
四阶段模式:
阶段1:探索
"阅读src/auth/目录,了解我们如何处理会话和登录。
 同时查看我们如何管理环境变量中的密钥。"

阶段2:规划
"我想添加Google OAuth。需要修改哪些文件?
 会话流程是怎样的?制定一个计划。"

阶段3:实现
"按照你的计划实现OAuth流程。为回调处理程序编写测试,
 运行测试套件并修复任何失败的测试。"

阶段4:提交
"用描述性信息提交代码并创建PR"
何时使用分阶段:
  • 对实现方法不确定时
  • 变更涉及多个文件时
  • 对要修改的代码不熟悉时
何时跳过分阶段:
  • 可以用一句话描述变更内容时
  • 修复拼写错误、添加日志行、重命名变量时
优化前: "添加OAuth"
优化后: "阅读src/auth/目录,了解当前的会话处理方式。制定添加OAuth的计划。
         然后按照计划实现。编写测试并验证通过"

5. Include Rich Content

5. 包含丰富内容

Provide supporting materials that Claude can use directly.
Content TypeHow to Provide
FilesUse
@filename
to reference files
ImagesPaste screenshots directly
ErrorsPaste actual error messages, not descriptions
LogsPipe with
cat error.log | claude
URLsLink to relevant documentation
BEFORE: "make the dashboard look better"
AFTER:  "[paste screenshot] implement this design for the dashboard.
         take a screenshot of the result and compare it to the original.
         list any differences and fix them. ensure responsive behavior
         at 768px and 1024px breakpoints"
BEFORE: "the build is failing"
AFTER:  "the build fails with this error: [paste actual error]. fix it
         and verify the build succeeds. address the root cause, don't
         suppress the error"

提供Claude可以直接使用的支持材料。
内容类型提供方式
文件使用
@filename
引用文件
图片直接粘贴截图
错误信息粘贴实际错误消息,而非描述
日志使用
cat error.log | claude
命令传递
链接链接到相关文档
优化前: "让仪表板看起来更好"
优化后: "[粘贴截图] 按照这个设计实现仪表板。
         截取结果的截图并与原图对比。列出所有差异并修复。
         确保在768px和1024px断点处的响应式表现"
优化前: "构建失败了"
优化后: "构建失败,错误信息如下:[粘贴实际错误]。修复问题
         并验证构建成功。解决根本原因,不要掩盖错误"

Output Format

输出格式

When transforming a prompt, output:
markdown
**Original:** [their prompt]

**Improved:**
[transformed prompt in code block]

**Added:**
- [what was missing and added]
- [another improvement]
- [etc.]

转换提示词时,输出格式如下:
markdown
**原提示词:** [用户的提示词]

**优化后:**
[转换后的提示词,放在代码块中]

**新增内容:**
- [缺失的内容及补充项]
- [另一项优化点]
- [其他]

Quick Transformation Examples

快速转换示例

Bug Fix

Bug修复

BEFORE: "fix the login bug"

AFTER: "users report login fails after session timeout. check the auth flow
in src/auth/, especially token refresh. write a failing test that reproduces
the issue, then fix it. verify by running the auth test suite."

ADDED: symptom, location, verification (failing test), success criteria
优化前: "修复登录Bug"

优化后: "用户反馈会话超时后登录失败。检查src/auth/目录中的认证流程,
特别是令牌刷新部分。编写一个能复现问题的失败测试用例,再修复问题。
通过运行认证测试套件进行验证。"

新增内容: 症状描述、位置信息、验证机制(失败测试用例)、成功标准

Feature Implementation

功能实现

BEFORE: "add a search feature"

AFTER: "implement search for the products page. look at how filtering works
in ProductList.tsx for the pattern. search should filter by name and category.
add tests for: empty query returns all, partial match works, no results shows
message. no external search libraries."

ADDED: location, reference pattern, specific behavior, test cases, constraint
优化前: "添加搜索功能"

优化后: "为产品页面实现搜索功能。参考ProductList.tsx中的过滤模式。
搜索应支持按名称和类别过滤。添加测试用例:空查询返回所有结果、
部分匹配有效、无结果时显示提示信息。不使用外部搜索库。"

新增内容: 位置信息、参考模式、具体行为、测试用例、约束条件

Refactoring

代码重构

BEFORE: "make the code better"

AFTER: "refactor utils.js to use ES2024 features while maintaining the same
behavior. specifically: convert callbacks to async/await, use optional
chaining, add proper TypeScript types. run the existing test suite after
each change to ensure nothing breaks."

ADDED: specific changes, constraint (same behavior), verification after each step
优化前: "优化代码"

优化后: "重构utils.js以使用ES2024特性,同时保持原有行为。具体包括:
将回调转换为async/await、使用可选链、添加合适的TypeScript类型。
每次变更后运行现有测试套件以确保功能正常。"

新增内容: 具体变更要求、约束条件(保持原有行为)、分步验证

Testing

测试编写

BEFORE: "add tests for foo.py"

AFTER: "write tests for foo.py covering the edge case where the user is
logged out. avoid mocks. use the existing test patterns in tests/. test
cases: logged_out_user returns 401, expired_session redirects to login,
invalid_token raises AuthError."

ADDED: specific edge case, constraint (no mocks), pattern reference, test cases
优化前: "为foo.py添加测试"

优化后: "为foo.py编写测试,覆盖用户未登录的边缘情况。避免使用模拟。
使用tests/目录中的现有测试模式。测试用例:未登录用户返回401、
过期会话重定向到登录页、无效令牌抛出AuthError。"

新增内容: 特定边缘情况、约束条件(无模拟)、模式参考、测试用例

Debugging

性能调试

BEFORE: "the API is slow"

AFTER: "the /api/orders endpoint takes 3+ seconds. profile the database
queries in OrderService.ts. look for N+1 queries or missing indexes.
fix the performance issue and verify response time is under 500ms."

ADDED: specific endpoint, location, what to look for, measurable success criteria
优化前: "API速度慢"

优化后: "/api/orders接口响应时间超过3秒。分析OrderService.ts中的数据库查询。
查找N+1查询或缺失的索引。修复性能问题并验证响应时间低于500ms。"

新增内容: 具体接口、位置信息、排查方向、可衡量的成功标准

UI Changes

UI变更

BEFORE: "fix the button styling"

AFTER: "[paste screenshot of design] update the primary button to match this
design. check Button.tsx and the theme in tailwind.config.js. take a
screenshot after changes and compare to the design. list any differences."

ADDED: design reference, file locations, visual verification
优化前: "修复按钮样式"

优化后: "[粘贴设计截图] 更新主按钮以匹配此设计。检查Button.tsx和
         tailwind.config.js中的主题配置。变更后截取截图并与设计稿对比。
         列出所有差异。"

新增内容: 设计参考、文件位置、视觉验证

Exploration

代码探索

BEFORE: "how does auth work?"

AFTER: "read src/auth/ and explain how authentication works in this codebase.
cover: how sessions are created, how tokens are refreshed, where secrets
are stored. summarize in a markdown doc."

ADDED: specific files, specific questions to answer, output format
优化前: "认证是如何工作的?"

优化后: "阅读src/auth/目录,解释本代码库中的认证机制。包括:
会话如何创建、令牌如何刷新、密钥存储位置。用Markdown文档总结。"

新增内容: 具体文件、需要回答的具体问题、输出格式

Migration

版本迁移

BEFORE: "upgrade to React 18"

AFTER: "migrate from React 17 to React 18. first, read the migration guide
at [URL]. then identify all components using deprecated APIs. update one
component at a time, running tests after each. don't change unrelated code."

ADDED: phased approach, reference docs, incremental verification, scope constraint
优化前: "升级到React 18"

优化后: "从React 17迁移到React 18。首先,阅读[链接]中的迁移指南。
然后识别所有使用已废弃API的组件。逐个更新组件,每次更新后运行测试。
不要修改无关代码。"

新增内容: 分阶段方法、参考文档、增量验证、范围约束

With Verification Report

包含验证报告

BEFORE: "fix the API error"

AFTER: "the /api/orders endpoint returns 500 for large orders. check
OrderService.ts for the error. address the root cause, don't suppress
the error. after fixing, run the test suite and summarize what passed
and what you verified."

ADDED: symptom, location, root cause enforcement, verification report

优化前: "修复API错误"

优化后: "/api/orders接口在处理大订单时返回500错误。检查OrderService.ts中的问题。
解决根本原因,不要掩盖错误。修复后运行测试套件,总结通过的测试和验证内容。"

新增内容: 症状描述、位置信息、根本原因要求、验证报告

Transformation Checklist

转换检查清单

Before outputting, verify the improved prompt has:
  • Verification — How to know it worked (tests, screenshot, output)
  • Location — Specific files, functions, or areas
  • Constraints — What NOT to do
  • Single task — Not compound (split if needed)
  • Phases — If complex, structured as explore → plan → implement
  • Root cause — For bugs: "address root cause, don't suppress"
  • CLAUDE.md — Respect project conventions if they exist

输出前,验证优化后的提示词是否包含:
  • 验证机制 — 如何确认任务完成(测试、截图、输出结果)
  • 位置信息 — 具体文件、函数或区域
  • 约束条件 — 不能做什么
  • 单一任务 — 不是复合任务(必要时拆分)
  • 分阶段 — 若任务复杂,按探索→规划→实现的结构划分
  • 根本原因 — 针对Bug:"解决根本原因,不要掩盖"
  • CLAUDE.md — 若存在则遵循项目规范

Quick Prompt Quality Check

快速提示词质量检查

Rate the prompt against these dimensions:
Dimension0 (Missing)1 (Partial)2 (Complete)
VerificationNone"test it"Specific test cases + report
Location"the code""auth module"
src/auth/login.ts:42
ConstraintsNoneImplied"avoid X, no Y, root cause only"
ScopeVaguePartialSingle clear task
Quick assessment:
  • 0-3: Needs significant work
  • 4-5: Needs some improvements
  • 6-8: Good, minor tweaks

从以下维度评估提示词:
维度0(缺失)1(部分满足)2(完全满足)
验证机制"测试一下"具体测试用例 + 报告
位置信息"代码""认证模块"
src/auth/login.ts:42
约束条件隐含"避免X,不使用Y,仅解决根本原因"
范围模糊部分明确单一清晰的任务
快速评估:
  • 0-3分:需要大幅改进
  • 4-5分:需要一些改进
  • 6-8分:良好,只需微调

Fallback: If Still Too Vague

回退方案:若提示词仍过于模糊

If user chose "Transform directly" but the prompt lacks enough context, ask one natural question:
"What would Claude need to know to do this well?"
Don't interrogate — one question is enough. Transform with what you learn.

如果用户选择了「直接转换」但提示词缺乏足够上下文,询问一个自然的问题:
"Claude需要了解哪些信息才能更好地完成这项任务?"
不要过度询问 — 一个问题足够。根据得到的信息进行转换。

Common Anti-Patterns to Fix

需要修复的常见反模式

Anti-PatternProblemFix
"fix the bug"No symptom, no locationAdd what users report + where to look
"add tests"No scope, no casesSpecify edge cases + test patterns
"make it better"No criteria for "better"Define specific improvements
"implement X"No verificationAdd test cases or success criteria
"update the code"No constraintsAdd what to preserve, what to avoid

反模式问题修复方案
"修复Bug"无症状描述、无位置信息添加用户反馈的症状 + 查找位置
"添加测试"无范围、无测试用例指定边缘情况 + 测试模式
"优化代码"无"优化"的衡量标准定义具体的改进点
"实现X"无验证机制添加测试用例或成功标准
"更新代码"无约束条件添加需要保留和避免的内容

Success Criteria — Prompt Quality Eval

成功标准 — 提示词质量评估

A well-transformed prompt passes these checks:
转换良好的提示词需通过以下检查:

Principle 1: Verification ✅

原则1:验证机制 ✅

CheckPassFail
Has success criteria"run tests", "screenshot matches"Nothing
Measurable outcome"response < 500ms""make it faster"
Self-verifiableClaude can check its own workRequires human judgment
Root cause enforced"don't suppress error"Silent about approach
检查项通过不通过
包含成功标准"运行测试"、"截图匹配"
可衡量的结果"响应时间 < 500ms""加快速度"
可自我验证Claude可自行检查工作成果需要人工判断
要求解决根本原因"不要掩盖错误"未提及实现方式

Principle 2: Specificity ✅

原则2:具体性 ✅

CheckPassFail
File locations
src/auth/login.ts
"the auth code"
Function/class names
processPayment()
"that function"
Line numbers (if relevant)
:42
"somewhere in there"
CLAUDE.md respected"check project conventions"Ignores project rules
检查项通过不通过
文件位置
src/auth/login.ts
"认证代码"
函数/类名称
processPayment()
"那个函数"
行号(若相关)
:42
"在某个地方"
遵循CLAUDE.md"查看项目规范"忽略项目规则

Principle 3: Constraints ✅

原则3:约束条件 ✅

CheckPassFail
What NOT to do"avoid mocks", "no new deps"Open-ended
Scope boundaries"only touch auth module"Unlimited scope
Pattern to follow"match UserService.ts style"No reference
检查项通过不通过
明确禁止内容"避免使用模拟"、"不添加新依赖"开放式要求
范围边界"仅修改认证模块"无限制范围
参考模式"匹配UserService.ts的风格"无参考

Principle 4: Structure ✅

原则4:结构合理性 ✅

CheckPassFail
Single taskOne clear objectiveMultiple goals
Phased (if complex)"explore → plan → implement"Jump straight to code
Appropriate depthMatches task complexityOver/under-specified
检查项通过不通过
单一任务一个清晰的目标多个目标
复杂任务分阶段"探索→规划→实现"直接开始编码
合适的详细程度与任务复杂度匹配过度/不足指定

Principle 5: Rich Content ✅

原则5:内容丰富性 ✅

CheckPassFail
Actual errorsPasted error message"it's broken"
Screenshots (UI)Image attached"the button looks wrong"
File references
@filename
or path
"that file"
检查项通过不通过
实际错误信息粘贴错误消息"它坏了"
UI截图附图片"按钮看起来不对"
文件引用
@filename
或路径
"那个文件"

Overall Quality Score

整体质量评分

ScoreMeaningPrinciples Passed
⭐⭐⭐⭐⭐ExcellentAll 5
⭐⭐⭐⭐Good4 of 5
⭐⭐⭐Acceptable3 of 5
⭐⭐Needs work2 of 5
Poor1 or 0
Target: Every transformed prompt should score ⭐⭐⭐⭐ or ⭐⭐⭐⭐⭐

评分含义通过的原则数量
⭐⭐⭐⭐⭐优秀全部5项
⭐⭐⭐⭐良好4项
⭐⭐⭐可接受3项
⭐⭐需要改进2项
较差1项或0项
目标: 每个转换后的提示词应达到⭐⭐⭐⭐或⭐⭐⭐⭐⭐评分

Reference Files

参考文件

For more examples and patterns:
  • 50+ Examples: See references/before-after-examples.md
  • Prompt Templates: See references/prompt-patterns.md
  • Task Workflows: See references/common-workflows.md
  • What to Avoid: See references/anti-patterns.md
  • Official Guide: See references/best-practices-guide.md

更多示例和模式:
  • 50+示例:查看references/before-after-examples.md
  • 提示词模板:查看references/prompt-patterns.md
  • 任务工作流:查看references/common-workflows.md
  • 避免事项:查看references/anti-patterns.md
  • 官方指南:查看references/best-practices-guide.md

Sources

来源