提示词合集【自用】

遇到什么问题 用什么方法解决的 为什么不用别的方法 还有没有更好的方法这是一个{简要描述}请根据以下方式帮助我学习整个代码库 项目结构 - 编译方式 - 入口 - 核心逻辑 - 时序图 - 各个步骤关键实现函数。 每次回复只聚焦其中一个部分并且尽量的详细比如一次回复中讲清楚“项目结构”然后询问我是否可以继续后再进行下一个回复例如“编译方式”。 请一步一步来frontend-skill创建具有高设计水准、独特且达到生产标准的渲染前端界面。当用户要求构建Web组件、页面、artifact、海报或应用程序例如网站、落地页、仪表板、react组件、HTML/CSS布局、或对任何Web UI进行样式美化时请使用此skill。能生产更富有创意、精致的代码和UI设计有效避免平庸的AI审美。1将任务分解到你觉得不能再分解。2检查所有ai生成的答案质疑ai不停问ai最优解是什么。3技术类需要结合自己的专业知识引导并且修正ai。把自己当成一个项目经理思考这个项目招几个角色的人来完成这个项目jd就是给每一个ai角色的prompt。时刻盯着手下的员工按照自己的想法做事。提升智能体性能的技巧1.问题分解优于角色扮演2.添加自我批评审查之前的回应并识别任何逻辑错误或不一致之处、遗漏的重要信息、可以更清晰的领域之前的回应{response}3.上下文重于指令更多相关背景信息复杂的提示技术Claude提效先plan模式Claude.md 给ai的项目说明书包含架构、规范、注意事项每次回复前必须使用”Chloe“作为称呼 遇到不确定的代码设计问题必须先询问 Chloe不能直接行动 不能写兼容性代码除非Chloe主动要求把讨论过的关键结论、设计思路整理成文档写入项目Claude.md做懒加载通过多条指令告诉ai当遇到以上情景就去看对应的文件避免上下文撑爆场景、文档、说明Skill 适合需要大量上下文、但执行结果相对独立的任务Codex5.3debug Opus 4.6 Sonnet 4.5 Kimi K2.5 GLM 5Skill: 解释为什么而不是做什么把踩过的坑整理成checklist喂给claude审计的时候自动对照目标、端口、约束、交付物 输入输出、功能逻辑、数据结构、异常处理、限制条件常问自己「数据从哪来」「谁负责改 DOM」「类型在防什么错」先出项目设计文档请根据下面的需求先输出一份完整的项目设计文档(README风格)包含: 1.项目概述 2.功能模块拆分 3.技术栈 4.项目目录结构 5.接口/数据结构设计 6.实现步骤根据MD生成项目大框架根据上面的项目设计文档生成完整的项目骨架代码 只生成目录结构空文件基础配置 不要写具体业务逻辑 保证能正常启动按模块逐个实现功能 现在开始实现第一个模块:[模块名] 根据设计文档写出完整可运行代码包含: 组件/函数逻辑 类型/接口 注释 调用示例最后补全运行说明亮点总结 帮我补充 README.md: 运行步骤 核心亮点 技术难点与解决方案架构师级别的提示词你是我的首席软件架构师兼全栈工程师。 你负责构建和维护一个生产级应用并且必须遵守我们在ARCHITECTURE.md中定义的严格自定义架构。你的目标是深度理解并遵循以下结构、命名规范和职责分离原则。任何时候你生成的每一个文件、函数和功能都必须符合架构要求与生产级标准。架构概览放置完整的ARCHITECTURE.md内容。)职责说明1.代码生成与组织 所有文件必须创建在正确的目录例如: /backend/src/api/(后端控制器) /frontend/src/components/(前端组件) /common/types/(共享模型) 前端、后端、共享代码必须严格分层不得混写。 使用架构里指定的技术栈如:前端:React/Next.js;后端:Node/ Express。2.上下文感知开发 在编写或修改代码前必须阅读对应架构章节确保一致性。 推断各层之间的依赖和调用关系(例如前端service如何使用后端API) 新增功能时需说明该功能在架构中的位置及原因。3.文档与可扩展性 架构或技术结构变更时必须更新ARCHITECTURE.md. 自动生成注释、类型定义和文档格式必须与现有规范一致。 提出改进建议、重构或抽象方案但不能破坏现有架构。4.测试与质量 每个模块都必须生成对应的测试文件(如backend/tests/、frontend/tests/) 使用合适的测试框架(Jest、Pytest等)与代码质量工具(ESLint、Prettier)。 保持严格的TypeScript类型覆盖率与lint规范。5.安全与可靠性 始终实现安全认证(JWT、OAuth2)与数据保护(TLS、AES-256)。 提供健壮的错误处理、输入校验与日志符合安全规范。6.基础设施与部署 按照/scripts/和/.github/的规范生成基础设施文件(如Dockerfile、CI/CD YAML) 。7.产品路线图集成 将潜在的技术债务或优化点直接标注在文档里以方便后续开发者。要按照文档规范来开发。应该怎么做包括前端、后端、数据存储、数据流转、通信分别在哪里定义开发中保持与原架构一致并充分复用代码包括界面与组件、数据表、api等。# 智能体开发报告 **文档版本**: **创建日期**: **开发状态**: 后端前端数据 **相关文档**:---## 一、开发概述## 二、创建的文件清单### 2.1 后端接口与注册机制| 文件路径 | 功能说明 |### 2.2 模块| 文件路径 | 功能说明 |### 2.3 数据库迁移| 文件路径 | 功能说明 |## 三、修改的文件| 文件路径 | 修改内容 |## 四、核心架构## 五、实现的核心能力## 六、数据流程## 七、类型定义概览### 7.1 核心数据类型### 7.2 后端接口## 八、后续工作建议### 8.1 前端集成### 8.2 功能增强### 8.3 质量保障### 8.4 用户配置## 九、遵循的设计原则| 原则 | 落实情况 ||------|---------|| **最小必要原则** | ✅ 复用现有AgentService、数据库架构、IPC模式 || **架构一致性** | ✅ 遵循设计文档的模块划分 || **充分复用** | ✅ 复用xlsx依赖、BaseService、日志服务 || **代码规范** | ✅ 中文注释、TypeScript类型定义、无冗余代码 |---## 十、测试报告### 10.1 测试文件清单| 测试文件 | 测试数量 | 状态 |### 10.2 测试覆盖范围| 模块 | 测试内容 |### 10.3 运行测试命令## 十一、版本历史| 版本 | 日期 | 变更内容 |**相关文档**推荐的工作流程开发新模块时在「开发文档」下新建模块文件夹编写「设计文档」更新docs/MODULE_INDEX.md添加映射开始编码完成模块开发后编写「开发总结」不部分搜嘎不负春光哑巴迭代已有模块时更新「设计文档」如有架构变更在「开发总结」追加变更记录文档质量规范每篇文档顶部作者、创建日期、最后更新日期设计文档应有「关键设计决策」写明为什么开发总结应有「踩坑记录」没有就写无原因重于结论写结论同时需要写明原因设计文档模板# 模块名 — 设计文档 ​ 作者xxx | 创建日期yyyy-mm-dd | 最后更新yyyy-mm-dd ​ ## 功能概述 一句话描述这个模块做什么 ​ ## 输入/输出 - 输入用户上传什么文件、提供什么信息 - 输出系统产出什么结果 ​ ## 核心流程 描述主要的处理流程可以用文字或流程图 ​ ## 关键设计决策 列出重要的技术选择和原因为什么这样做比做了什么更重要 ​ ## 数据结构 关键的数据类型、接口定义 ​ ## 依赖关系 依赖了哪些外部服务、内部模块开发文档模板# 模块名 — 开发总结 ​ 作者xxx | 日期yyyy-mm-dd ​ ## 主要变更 本次开发/迭代完成了什么。 ​ ## 踩坑记录 开发过程中遇到的问题和解决方案。 ​ ## 遗留问题 已知但未解决的问题后续需要处理。 ​ ## 变更历史 | 日期 | 变更内容 | 作者 | |------|----------|------| | yyyy-mm-dd | 初始版本 | xxx |设计文档prompt根据以下代码/需求信息按照模板生成设计文档初稿 ​ 模板结构 1. 功能概述一句话 2. 输入/输出 3. 核心流程 4. 关键设计决策重点写为什么 5. 数据结构 6. 依赖关系 ​ 要求 - 语言简洁避免废话 - 设计决策部分必须写明原因不能只写结论 - 如果信息不足用 [待补充] 标记 ​ 以下是代码/需求信息 --- {粘贴代码或需求描述}开发文档prompt根据以下 git commit 记录和代码变更生成开发总结。 ​ 模板结构 1. 主要变更列出完成的功能点 2. 踩坑记录开发中遇到的问题和解决方案 3. 遗留问题已知未解决的问题 ​ 要求 - 踩坑记录要写清楚问题现象 → 原因分析 → 解决方案 - 如果 commit message 中没有体现踩坑踩坑记录写无 - 语言简洁 ​ 以下是 git log / 代码变更 --- {粘贴 git log 或 diff}软件设计系统由哪些模块/组件组成模块之间如何通信接口、协议数据如何存储、流转和处理如何应对未来的需求变化扩展性如何保证系统稳定、安全、高效常见的软件设计产出包括架构图如分层架构、微服务架构类图、时序图、状态图UML接口定义API 文档数据库 ER 图设计文档如技术方案、模块职责说明✅ 软件设计的核心原则包括高内聚低耦合、单一职责、开闭原则、关注点分离等。典型流程通常包括以下阶段需求分析Requirements Analysis 与用户/产品经理沟通明确“软件要解决什么问题”。 输出需求规格说明书SRS、用户故事、用例图。 关键问题功能需求非功能需求性能、安全、兼容性软件设计Software Design 概要设计架构设计确定整体技术架构如前后端分离、微服务、技术栈如 React Spring Boot MySQL。 详细设计定义模块接口、数据库表结构、关键算法、状态管理方案等。 输出系统架构图、数据库设计、API 文档、组件设计。编码实现Implementation / Coding 开发人员根据设计文档编写代码。 遵循编码规范进行单元测试、代码审查。 使用版本控制如 Git管理代码。测试Testing 单元测试、集成测试、系统测试、验收测试。 包括功能测试、性能测试、安全测试、兼容性测试等。 自动化测试如你熟悉的 Selenium常用于回归验证。部署Deployment 将软件发布到生产环境如服务器、云平台。 可能涉及 CI/CD 流水线、容器化Docker、配置管理等。维护与迭代Maintenance Evolution 修复 Bug、优化性能、响应用户反馈。 根据新需求进行功能迭代进入下一轮开发循环。搭建页面注意事项总结系统分析一个前端项目中的页面逻辑详细分析思路和观测重点。分析思路总览路由与页面跳转逻辑页面是如何被组织和导航的组件与交互逻辑页面内部是如何工作的状态管理逻辑数据如何流动和共享存储与数据持久化逻辑数据如何被保存第一步需求分析与设计拆解 (非编码)在动手写代码之前先想清楚明确页面功能这个页面的主要目的是什么定义数据接口页面需要展示哪些数据数据从哪里来后端API接口本地模拟数据接口的格式JSON结构是什么UI/UX设计稿如果有设计稿Figma, Sketch等仔细查看布局是上下结构还是左右结构有哪些主要的UI区域组件设计稿中有哪些重复出现的元素如按钮、卡片、模态框这些应该提取为可复用组件。交互点击按钮会发生什么是否有弹窗表单校验规则是什么组件树规划在纸上或脑子里构思一个组件树。将页面拆分成一个个更小、更易于管理的组件。页面组件通常放在src/views/或src/pages/下负责路由和整体布局。可复用组件通常放在src/components/下是独立的、可跨页面使用的部件。第二步搭建基础代码结构 (编码)创建路由如果是一个新页面打开路由配置文件router/index.js。在routes数组中添加一个新的路由规则指定path,name, 和要使用的组件。// router/index.js import UserList from /views/UserList.vue ​ const routes [ // ... 其他路由 { path: /users, name: UserList, component: UserList // 这个组件将在下一步创建 } ];创建Vue组件文件在src/views/目录下创建对应的Vue文件例如UserList.vue。搭建最基本的Vue单文件组件结构。!-- src/views/UserList.vue -- template div classuser-list !-- 页面内容将在这里搭建 -- /div /template ​ script setup // 逻辑将在这里编写 /script ​ style scoped /* 样式将在这里编写 */ /style第三步实现核心逻辑 (编码)在script setup标签中按需添加以下逻辑这是页面的“大脑”。状态与数据使用ref,reactive定义组件内需要的响应式数据。script setup import { ref, onMounted } from vue; import { apiGetUserList } from /api/user; // 假设有一个API模块 ​ // 1. 定义状态 const userList ref([]); // 用户列表数据 const loading ref(false); // 加载状态 const error ref(null); // 错误信息 ​ // 2. 生命周期 - 获取数据 onMounted(async () { loading.value true; try { const response await apiGetUserList(); // 调用API userList.value response.data; } catch (err) { error.value err.message; } finally { loading.value false; } }); ​ // 3. 定义方法 - 处理用户交互 function handleEditUser(userId) { // 例如跳转到编辑页面 router.push(/user/edit/${userId}); } ​ function handleDeleteUser(userId) { // 删除用户的逻辑 } /script引入状态管理如果需要如果数据需要跨组件共享使用 Pinia。import { useUserStore } from /stores/user; const userStore useUserStore(); // 然后在onMounted中调用 userStore.fetchUsers()第四步构建UI界面 (编码)在template中根据设计稿和定义的数据构建用户界面。使用基础UI和条件渲染展示数据、加载状态和错误信息。template div classuser-list h1用户列表/h1 !-- 加载状态 -- div v-ifloading加载中.../div !-- 错误状态 -- div v-else-iferror classerror{{ error }}/div !-- 正常状态 -- table v-else thead tr thID/th th姓名/th th操作/th /tr /thead tbody tr v-foruser in userList :keyuser.id td{{ user.id }}/td td{{ user.name }}/td td button clickhandleEditUser(user.id)编辑/button button clickhandleDeleteUser(user.id)删除/button /td /tr /tbody /table /div /template集成子组件将拆分好的部分用组件替换并通过props传递数据。template div classuser-list h1用户列表/h1 UserTable :usersuserList :loadingloading :errorerror edithandleEditUser deletehandleDeleteUser / /div /template script setup import UserTable from /components/UserTable.vue; // ... 其他逻辑 /script第五步添加样式与优化 (编码与测试)编写样式在style scoped中编写CSS确保加上scoped属性防止样式污染。style scoped .user-list { padding: 20px; } .error { color: red; } table { width: 100%; border-collapse: collapse; } th, td { border: 1px solid #ddd; padding: 8px; } /style交互优化添加一些UX优化如操作确认框、空状态提示、加载骨架屏等。测试与调试功能测试在浏览器中操作页面检查所有功能是否正常按钮点击、数据加载、路由跳转。数据测试测试边界情况如API请求失败、返回空数组等页面是否正常显示。Vue DevTools使用浏览器插件Vue DevTools检查组件状态、Props、事件是调试的利器。