Prompt 模板与团队推广

只读探索这个仓库。输出:
1. 技术栈
2. 入口文件
3. 主要数据流
4. 测试和构建命令
5. 高风险区域
不要修改文件。

解释 @src/scheduler/queue.ts 做什么,数据如何流入和流出。
按“入口、关键函数、副作用、错误处理、测试缺口”写成文档。

哪里实现了 {行为}? 先用 rg 定位,再读相关文件。
最后列出文件路径、函数名和调用链。

计划如何把 {模块} 改成 {目标}。
先列需要修改的文件、风险、兼容点和验证命令。
不要编辑任何文件。

我要做 {功能}。请先 interview 我:
- 用户和场景
- UI / API 行为
- 权限和安全
- 空状态和错误状态
- 迁移和兼容
问完后写 SPEC.md。

列出 {功能} 需要覆盖的 error states、empty states、loading states、权限不足和移动端边界。
不要写代码,只输出验收清单。

参考 {已有实现} 的模式,实现 {新功能}。
范围: {允许改的目录}。
要求:
- 不引入新依赖,除非现有模式已经使用
- 保持现有 API 兼容
- 完成后运行 {验证命令}

根据这张截图实现 UI。
完成后启动页面,截图对比原图,修掉布局、间距、颜色和文字溢出问题。
同时检查 320px、390px、1440px 和暗色主题。

为 {模块} 增加 {测试类型}。
先找现有测试风格,再补最小覆盖。
不要为了测试改生产行为。

这个测试失败了。先解释失败原因,再定位最小修复。
日志:
{粘贴关键错误}
完成后只运行相关测试,再说明是否需要全量回归。

复现并修复这个 bug。
顺序:
1. 找最小复现或相关测试
2. 定位根因
3. 小步修改
4. 跑验证
5. 总结风险

这段代码最近变慢了。先找性能热点和可能的重复渲染/重复请求。
不要先重构。给出证据后再改。

按 code review 姿态审查当前 git diff。
只列 bug、回归风险、安全问题和缺失测试。
每条都给文件/行号、严重级别和为什么会发生。
不要做风格建议。

生成 PR 描述:
- 背景
- 主要改动
- 验证命令和结果
- 风险
- 回滚方式
基于当前 git diff,不要编造没有运行过的测试。

做发布前检查:
- lint/typecheck/test/build
- 关键页面手动路径
- 移动端 390px
- 浅色/暗色
- 空状态/错误状态
输出通过项、失败项和下一步。

根据当前实现更新文档。
不要猜 API 行为,从源码、测试和官方文档核对。
保留权威来源链接。

把这次排错过程沉淀成 runbook:
- 症状
- 快速判断
- 常见原因
- 排查命令
- 修复步骤
- 回滚方式

从最近这次任务里提炼适合写入 CLAUDE.md 的稳定规则。
只保留以后每次都需要知道的内容,不要写一次性任务记录。

今天学到一个可复用技巧:
我让 Claude 只读 @src/components,找缺测试的组件。
Prompt:
"找出 @src/components 里没有测试或测试明显不足的组件,按风险排序。不要改文件。"
结果发现了两个我漏掉的组件。

Plan mode 是我敢让它碰重要代码的原因。
按 Shift+Tab 切到 plan,它会先列要改哪些文件,不直接动代码。
适合第一次在陌生模块试用。

如果你第一次用,不要拿最难的架构重构试。
找一个真实但边界清楚的任务:
- flaky test
- 补测试
- 解释陌生模块
- 修 lint
- 写 PR 描述

Claude Code 已开放给 {团队}。
它在终端/IDE 中读取当前代码库,可以解释代码、修 bug、写测试、跑验证和整理 PR。

两分钟开始:
1. 安装 Claude Code
2. 进入仓库运行 `claude`
3. 先跑 `/init`
4. 试一个真实小任务:
   "解释 @src/auth 的登录流程,列出风险,不要改文件。"

问题集中到 {支持渠道}。
数据使用、安全边界和 Provider 配置看内部说明: {链接}。

试点要求:
本周每人至少用一次 Claude Code 做真实任务。
请在 {频道} 留三点:
- 做了什么
- 哪一步最省时间
- 哪一步不可信或卡住
这些反馈决定下一轮 rollout 策略。