- 编码前先描述方案并等待批准，需求不明时提出澄清问题
- 修改超3个文件的任务需先分解成更小单元
- 代码完成后列出潜在问题并提供测试用例
- 发现bug时先编写复现测试，修复至测试通过
- 每次被纠正后在CLAUDE.md添加新规则避免重复错误
277 个赞
感谢分享
6 个赞
感谢分享
4 个赞
这条我用了好久了 
当TA理解了以后 极高的概率一次过
6 个赞
这就塞进cc里
感谢分享 已经加到CC
感谢分享
感谢分享
1 个赞
可以的 这个思路很强啊
1 个赞
感谢分享
mark 编码提示词
这就用上看看效果
1 个赞
有条差不多
* 在开始设计方案或实现代码之前，你需要进行充分的调研。如果有任何不明确的要求，请在继续之前向我确认
2 个赞
感谢分享
有点意思 先 copy 一下
2 个赞
看起来挺有意思。先cp下
2 个赞
感谢分享
感谢佬友分享
这就去试试。
1 个赞
下面是经常用的深度访谈提示词，也可以参考
深度访谈Mcp版本
## 任务目标
请使用 MCP 工具对我进行**基于代码事实**的多轮深度访谈，澄清需求与技术方案，并在访谈结束后输出：
- 1 份「完整分析报告 + 多方案对比 + 推荐方案」
- 1 份「可执行技术规范文档」
最后通过 zhi 工具请求我逐条确认，确认后再进入具体实现。
## 工具说明（必须遵守）
- `sou___(project_root_path, query)`：在指定项目中做语义搜索，返回带文件路径与行号的相关代码片段。
- `zhi___(project_root_path, message, is_markdown=true, predefined_options=可选)`：与我交互展示内容（含问题、选项、总结、报告等）。
- **所有向我的提问与展示都必须通过 `zhi___`**（不要在普通对话里直接提问）。
## 全局原则（重要）
1. **先证据，后判断**：所有分析与建议必须能回溯到 `sou___` 返回的代码片段（路径+行号），不凭空推测。
2. **并行检索**：每进入一个主题前，先用 `sou___` 并行搜索 3-6 个关键 query，覆盖“定义、调用、配置、边界、异常、测试”等维度。
3. **访谈节奏**：每轮仅 2-3 个关键问题；每轮结束给出“已确认/待确认/风险提示”的小结，再进入下一轮。
4. **避免纯是/否**：问题要引导我给出目标、权衡与例子；必要时提供预定义选项 + 自由输入。
5. **关键决策必须确认**：范围、接口、数据、兼容、性能、安全、上线回滚、迁移等决策点，都要在最后用 zhi 逐条确认。
## 执行流程
### Phase 0：初始化
- 通过 `zhi___` 向我索要/确认 `project_root_path`（如果我已提供则直接使用）。
- 用 `zhi___` 让我用一句话描述：我要改什么/加什么/修什么，以及期望收益。
### Phase 1：代码事实盘点（每个主题都先搜再问）
对以下主题循环执行：「sou 并行检索 → zhi 深度提问（2-3题）→ zhi 小结」：
- 现状流程与关键入口（入口函数/路由/命令/任务）
- 相关模块边界与依赖（内部/外部服务）
- 数据与状态（模型、存储、缓存、幂等、一致性）
- 错误处理与可观测性（日志、指标、链路、告警）
- 配置与环境差异（feature flag、灰度、开关、权限）
- 测试与发布（现有测试、回归点、CI、迁移）
> `sou___` 查询建议（示例，需按项目替换）：
- “<需求关键词> 入口/handler/controller/router”
- “<需求关键词> service/usecase”
- “<关键实体> model/schema/table”
- “error/exception/try catch/返回码”
- “logger/metric/trace/telemetry”
- “config/env/feature flag”
- “test/<关键词>”
### Phase 2：方案生成与对比（基于代码事实）
- 至少提出 2 个可行方案（如：最小改动方案 / 架构演进方案）。
- 每个方案必须包含：
- 改动点清单（对应到文件路径/模块）
- 关键流程与异常路径
- 兼容性与迁移策略
- 风险与缓解措施
- 成本评估（复杂度、回归范围、可观测性/测试补齐）
### Phase 3：输出与最终确认（必须用 zhi）
通过 `zhi___` 输出以下结构化内容（is_markdown=true）：
1. 需求澄清摘要：目标/非目标/范围边界/成功指标
2. 代码证据索引：引用 sou 片段的路径+行号（按主题组织）
3. 决策日志：决策点、选项、权衡、推荐、待确认
4. 方案对比表：至少 2 方案（优缺点/风险/成本/适配条件）
5. 推荐方案：选择理由 + 触发回退条件
6. 可执行技术规范：
- 架构与模块划分
- 接口与数据结构（示例）
- 错误处理与可观测性
- 测试策略（新增/改动用例、回归清单）
- 发布计划（灰度、监控、回滚、迁移步骤）
7. 最终确认清单：用 `zhi___` 列出 8-15 条需要我逐条确认的关键点（可用 predefined_options 提供“同意/修改/补充/需要更多证据”）
## zhi 交互模板建议（让体验更顺）
- 每轮提问时：
- `predefined_options`: ["给我一个例子", "我需要更多代码证据", "偏向最小改动", "偏向长期演进", "有额外约束/风险", "先跳过稍后再定"]
- 每轮结束小结固定包含：
- ✅ 已确认
- ❓ 待确认
- ⚠️ 风险/依赖
- 🔎 下一轮将检索的代码点（列出将用的 sou query）
## 硬性约束
- 不得在普通对话中直接提问；所有问题与展示必须通过 `zhi___`
- 任何关键判断必须可回溯到 `sou___` 返回的代码证据
- 未获得最终确认前，不进入具体实现步骤
原始不带MCP版本
## 核心任务
你需要对我进行一场深度的技术与业务访谈，目的是输出一份详尽、无歧义且可执行的技术规范文档。请遵循以下流程与原则：
## 访谈执行流程
### Phase 1: 上下文理解与预判
在提问之前，请基于你已知的项目信息或代码片段（如有），先进行自我分析。不要问显而易见的问题，而是基于现有信息提出假设，通过提问来验证假设。
### Phase 2: 深度多轮访谈
1. **聚焦核心维度**：每轮对话仅聚焦 2-3 个关键决策点（如：数据一致性策略、异常处理模式、扩展性瓶颈）。
2. **苏格拉底式引导**：
- 避免封闭式（是/否）提问，改为启发式提问（例如：“在高并发场景下，您更倾向于牺牲即时性换取吞吐量，还是必须保证实时强一致？”）。
- 对模糊回答（如“越快越好”）进行追问，要求量化指标或具体场景。
- 挖掘隐性需求，主动指出用户未考虑到的边界情况（Edge Cases）。
3. **动态调整**：根据我的回答实时修正你的技术模型，确保没有逻辑冲突。
### Phase 3: 方案对比与收敛
在访谈充分后，请输出多套技术方案对比：
- **方案 A (保守/稳定)**
- **方案 B (激进/高性能)**
- **推荐方案**：并详细说明推荐理由。
### Phase 4: 最终规范输出
待我确认方案后，生成一份包含以下内容的技术规范：
- 系统架构图/流程图描述
- 核心接口定义
- 数据库设计变更
- 关键代码实现逻辑
## 交互原则
1. **专家姿态**：不要只是被动记录，要提供专业的建议和挑战（Challenge）我的想法。
2. **结构化输出**：回复时请使用清晰的 Markdown 格式（列表、表格、代码块）来组织信息，降低阅读负担。
3. **闭环确认**：在进入下一个话题前，简要总结当前达成的共识。
## 开始指令
请根据当前任务目标，开始第一轮访谈。请直接提出你认为最关键的 2-3 个引导性问题。
24 个赞
感谢分享 试下
2 个赞