程序员 AI 编程提示词手册一套提示词打通整个开发流程适用工具Claude Code、OpenAI Codex、Cursor Agent 等编程 Agent适用人群前端、后端、测试、全栈开发者使用方式每个环节给出的提示词均可直接复制粘贴把【】中的占位内容替换成你的真实需求即可目录零、先说清楚写好 Agent 提示词的 5 条军规一、需求分析环节二、技术设计与架构环节三、前端开发环节四、后端开发环节五、数据库环节六、测试环节七、代码审查环节八、部署与运维环节九、文档编写环节十、Bug 排查与调试环节十一、重构与性能优化环节十二、组合技把提示词串成一条流水线附录高频补丁话术速查表零、先说清楚写好 Agent 提示词的 5 条军规在抄提示词之前先理解为什么它们这么写。所有编程 Agent 的提示词本质都在做 5 件事给角色告诉它你是谁——资深前端架构师安全审计专家角色决定了它调用知识的角度。给上下文技术栈、项目现状、约束条件。Agent 最怕的不是需求难而是不知道你的项目长什么样。给边界明确不要做什么——不要引入新依赖、不要改动现有接口、不要动测试文件。边界越清晰返工越少。给验收标准什么样算做完“编译通过”“测试全绿”“Lighthouse 性能分 ≥ 90”可验证的标准胜过一百句形容词。给输出格式要代码块、要表格、要分步骤说明直接规定。记住一个万能骨架【角色】【项目上下文】【任务目标】【约束条件】【验收标准】【输出格式】下面每个环节的提示词都是这个骨架的具体填充。一、需求分析环节开发流程的第一步不是写代码而是把模糊的需求逼问成清晰的技术输入。这一步用对提示词能省掉后面 50% 的返工。1.1 需求拆解把一句话需求变成开发清单你是一位资深的产品技术负责人。我收到一个需求 【需求原文】把产品经理的原话粘贴在这里 【项目背景】现有系统是一个【Vue3 Spring Boot】的电商后台已有用户、商品、订单三个模块 请你完成 1. 把这个需求拆解成具体的功能点按优先级排序P0 必须有 / P1 应该有 / P2 可以有 2. 每个功能点标注涉及的前端页面、后端接口、数据表 3. 指出需求中模糊不清、需要和产品确认的地方列出问题清单 4. 预估每个功能点的开发工作量人天 输出格式先给功能拆解表格再给问题清单最后给工作量估算。1.2 需求评审让 AI 扮演挑刺的评审你现在是一名严格的技术评审委员负责评审下面这份需求文档。你的任务是挑毛病不是夸它。 【需求文档】粘贴需求文档内容 请从以下维度逐一审查 1. 边界情况有没有考虑空数据、并发、超时、重复提交、权限越界 2. 数据一致性哪些操作需要事务失败如何回滚 3. 兼容性是否影响现有功能老数据如何迁移 4. 安全有没有 SQL 注入、XSS、越权访问的风险点 5. 性能有没有 N1 查询、大表全表扫描、前端大数据量渲染的隐患 对每个发现的问题给出问题描述 严重程度高/中/低 建议解决方案。 只输出问题没有问题的地方不要硬编。1.3 技术可行性评估你是一位有 10 年经验的架构师。请评估以下方案的技术可行性 【方案描述】粘贴方案内容 【现有技术栈】前端 React 18 TypeScript后端 Java 17 Spring Boot 3数据库 MySQL 8.0 【团队情况】3 个前端、4 个后端、1 个测试项目周期 6 周 请回答 1. 这个方案能不能落地核心难点是什么 2. 有没有更简单的替代方案对比 2-3 个方案的优劣用表格 3. 需要哪些前期准备环境、权限、第三方接口、资质 4. 最大的风险点是什么如何兜底 结论先行第一段直接告诉我能/不能/有条件能然后再展开分析。二、技术设计与架构环节2.1 接口设计先行你是一位后端架构师。请为以下功能设计 RESTful API 接口文档 【功能描述】粘贴功能描述 【已有规范】统一返回格式 { code, message, data }code0 表示成功分页参数用 page/size鉴权用 JWT 要求 1. 列出所有接口Method Path 用途说明 2. 每个接口给出请求参数字段名、类型、是否必填、校验规则和响应示例 JSON 3. 标注错误码及其含义 4. 指出哪些接口需要鉴权、哪些需要限流 输出 Markdown 格式的接口文档可以直接贴进 wiki。2.2 数据库表设计你是一位数据库设计专家。请为以下业务设计数据库表 【业务描述】粘贴业务描述 【数据库】MySQL 8.0使用 InnoDB 引擎字符集 utf8mb4 要求 1. 给出完整的建表 DDL 语句 2. 每张表必须有主键、创建时间、更新时间、逻辑删除字段 3. 为高频查询场景设计合适的索引并解释为什么建这个索引 4. 标注字段之间的关联关系用简单的 ER 文字描述 5. 指出未来可能的性能瓶颈如数据量大的表是否需要分库分表预案2.3 架构方案选型你是一位技术决策者。我需要为以下场景做技术选型 【场景】粘贴场景描述例如给现有后台系统加一个实时消息推送功能 【约束】预算有限、团队没有运维、现有部署在单台云服务器上 请对比 2-3 个候选方案如 WebSocket / SSE / 轮询 / 第三方推送服务用表格对比 - 实现复杂度 - 性能与并发能力 - 运维成本 - 团队学习成本 - 长期扩展性 最后给出你的明确推荐和理由。不要骑墙必须选一个。三、前端开发环节3.1 从设计稿生成页面高还原度你是一位追求像素级还原的资深前端工程师。请根据我上传的设计稿图片实现这个页面。 【技术栈】React 18 TypeScript Tailwind CSS组件库用 shadcn/ui 【要求】 1. 先分析设计稿列出你识别到的布局结构、间距、字号、颜色值确认后再写代码 2. 组件拆分合理单一职责避免一个文件超过 200 行 3. 响应式适配桌面端 1440px 为主平板和手机需要自适应 4. 交互细节hover 态、点击态、加载态、空状态都要实现 5. 不要写死假数据数据通过 props 传入方便后续接接口 【验收标准】页面能在浏览器正常渲染无 console 报错布局与设计稿一致。3.2 前端组件开发可复用你是一位组件库作者。请开发一个通用组件 【组件名】SearchableSelect可搜索的下拉选择器 【功能要求】 1. 支持单选和多选两种模式通过 multiple 属性切换 2. 支持本地搜索过滤和远程搜索传入 onSearch 回调 3. 支持键盘操作上下键选择、回车确认、Esc 关闭 4. 支持禁用态、加载态、空数据提示 【技术要求】 - TypeScript 编写导出完整的 props 类型定义 - 样式用 Tailwind风格与 shadcn/ui 保持一致 - 附带 3 个使用示例基础单选、多选、远程搜索 - 不要引入额外的第三方依赖3.3 前端对接后端接口你是一位前端工程师。现在要把页面的假数据替换成真实接口。 【接口文档】粘贴接口文档 【现有代码】当前页面组件代码如下粘贴代码 要求 1. 封装一个 api 请求函数统一处理 loading、错误提示、token 注入 2. 用 React Query或 SWR管理服务端状态处理缓存和自动刷新 3. 处理所有边界状态加载中、接口报错、返回空列表、网络超时 4. 不要改动组件的 UI 结构只替换数据层 5. 错误提示要用户友好不要把 500 Internal Server Error 直接弹给用户3.4 前端性能优化你是一位前端性能优化专家。这个页面有性能问题请帮我诊断和修复。 【现象】粘贴现象例如列表页首次加载 6 秒滚动卡顿 【相关代码】粘贴相关组件代码 请按以下步骤工作 1. 先分析代码列出所有可能的性能问题点渲染、请求、资源体积 2. 按收益/成本比排序先改收益最大的 3. 逐项给出修改后的代码并解释优化原理 4. 给出验证方法改完后用什么指标确认优化生效了 约束不要为了优化引入重型依赖不要改变现有功能行为。3.5 前端 Bug 修复这个组件有一个 bug 【Bug 现象】粘贴现象例如快速切换 Tab 时偶发内容串台 【复现步骤】1. 打开页面 2. 快速点击 Tab A → Tab B → Tab A 3. 偶发出现 B 的内容显示在 A 下面 【相关代码】粘贴代码 请 1. 分析根因用一两句话说清楚为什么会发生不要上来就改 2. 给出最小化的修复方案只改必须改的代码 3. 说明修复后为什么不会再出现这个问题 4. 提醒还有哪些类似的隐患需要顺手检查四、后端开发环节4.1 接口开发完整链路你是一位资深后端工程师。请实现以下接口 【接口定义】粘贴接口定义Method、Path、入参、出参 【技术栈】Java 17 Spring Boot 3 MyBatis-Plus数据库 MySQL 8.0 【业务逻辑】粘贴业务逻辑描述 要求实现完整链路 1. Controller 层参数校验用 Valid返回统一响应体 2. Service 层核心业务逻辑涉及多表写操作的加事务 3. 数据访问层复杂查询手写 SQL 并加注释说明 4. 异常处理业务异常抛自定义异常由全局异常处理器统一处理 5. 日志关键步骤打日志包含请求 ID 便于链路追踪 【验收标准】代码能编译通过覆盖正常流程、参数非法、数据不存在、并发重复提交四种场景。4.2 复杂业务逻辑实现你是一位擅长复杂业务的后端专家。请实现以下业务逻辑 【业务描述】粘贴业务描述例如优惠券叠加计算满减券、折扣券、立减券可叠加但有互斥规则…… 【业务规则】逐条列出所有规则 要求 1. 先把业务规则整理成一张判定表格给我看确认理解无误后再写代码 2. 核心计算逻辑抽成独立方法每个方法单一职责加中文注释 3. 所有金额计算用 BigDecimal禁止用 double 4. 为每条业务规则至少写一个边界情况的注释 5. 逻辑分支超过 3 层嵌套的地方用策略模式或查表法重构4.3 并发与一致性处理你是一位高并发系统专家。以下场景存在并发问题请给出解决方案 【场景】粘贴场景例如秒杀下单库存 100 件QPS 峰值 5000 【现有实现】粘贴现有代码或描述 请回答 1. 当前实现有哪些并发风险超卖、重复下单、脏读……逐个分析 2. 给出分层解决方案数据库层乐观锁/悲观锁、缓存层Redis 预减库存、消息层MQ 削峰各自怎么配合 3. 写出关键代码库存扣减、幂等校验、失败补偿 4. 说明极端情况怎么处理Redis 挂了、MQ 消息丢了、用户重复点击4.4 后端接口性能优化这个接口响应太慢请帮我优化 【接口】粘贴接口信息 【现状】平均响应 3.2 秒P99 达到 8 秒数据量约【XX 万】条 【相关代码和 SQL】粘贴代码与 SQL 请按顺序排查 1. SQL 层分析执行计划我会提供 EXPLAIN 结果是否存在全表扫描、索引失效、N1 查询 2. 代码层是否有循环内查库、重复计算、不必要的对象创建 3. 架构层是否需要加缓存、异步化、分批处理 对每个问题给出具体修复代码并预估优化后的响应时间。 约束不能改变接口的入参出参结构前端不能改。五、数据库环节5.1 SQL 编写与优化你是一位 DBA。请帮我处理以下 SQL 需求 【需求】粘贴需求例如统计每个用户最近 30 天的下单金额排名取前 100 【表结构】粘贴相关表的 DDL 【数据量】订单表约 5000 万行用户表约 200 万行 要求 1. 写出 SQL并逐段解释逻辑 2. 分析这条 SQL 会走什么索引有没有性能隐患 3. 如果有更优写法窗口函数 / 临时表 / 预先汇总给出对比 4. 提醒生产环境执行这条 SQL 的注意事项锁表风险、执行时间5.2 慢 SQL 诊断这是一条慢查询请帮我诊断 【SQL】粘贴 SQL 【EXPLAIN 结果】粘贴执行计划 【表结构与索引】粘贴 DDL 【现状】执行耗时 12 秒业务要求 500ms 以内 请 1. 解读 EXPLAIN 结果指出全表扫描、filesort、临时表等危险信号 2. 给出索引优化建议建什么索引、联合索引的列顺序怎么排 3. 如果索引解决不了给出 SQL 重写方案 4. 说明每条建议的原理不要只给结论5.3 数据迁移脚本你是一位 DBA。我需要做一次数据迁移 【迁移内容】粘贴描述例如把 user 表的 phone 字段拆成 country_code phone 两个字段 【数据量】约 800 万行 【约束】业务不停机迁移期间新数据持续写入 请给出完整的迁移方案 1. 迁移脚本DDL 数据回填 SQL/程序逻辑 2. 灰度步骤先加字段 → 双写 → 校验 → 切流 → 删旧字段每一步的操作和回滚方案 3. 数据校验脚本如何确认迁移后数据无丢失、无错位 4. 风险点清单大事务、主从延迟、锁等待分别怎么规避六、测试环节6.1 单元测试生成你是一位测试工程师。请为以下代码编写单元测试 【待测代码】粘贴代码 【测试框架】JUnit 5 Mockito或 Vitest / Jest按实际技术栈替换 要求 1. 先列出测试用例清单正常流程、边界值、异常路径确认覆盖完整后再写代码 2. 外部依赖数据库、HTTP 调用、时间全部 mock测试必须可独立运行 3. 测试方法命名清晰should_期望结果_when_触发条件 4. 每个断言只验证一件事 5. 给出覆盖率目标行覆盖 ≥ 80%分支覆盖 ≥ 70%并说明哪些行刻意不覆盖及原因6.2 接口测试用例设计你是一位接口测试专家。请为以下接口设计测试用例 【接口文档】粘贴接口文档 请输出一张测试用例表格覆盖 1. 正常场景各字段合法值组合 2. 参数校验必填缺失、类型错误、超长、特殊字符、SQL 注入尝试 3. 权限场景无 token、token 过期、越权访问他人数据 4. 业务边界空数据、临界值、重复提交 5. 异常场景下游服务超时、数据库异常 每行包含用例名称、前置条件、请求参数、预期结果状态码 响应体关键字段。6.3 端到端E2E自动化测试你是一位自动化测试工程师。请为以下用户流程编写 E2E 测试 【用户流程】粘贴流程例如注册 → 登录 → 下单 → 支付 → 查看订单 【技术栈】Playwright TypeScript被测系统地址 http://localhost:3000 要求 1. 用 Page Object 模式组织代码页面元素和操作与测试逻辑分离 2. 选择器优先用>6.4 性能/压测方案你是一位性能测试工程师。请为以下接口设计压测方案 【接口】粘贴接口信息 【目标】支撑 QPS 2000P99 500ms 【环境】4 核 8G 应用服务器 × 2MySQL 单实例 8 核 16G 请给出 1. 压测场景设计基准测试、负载测试、压力测试分别怎么打 2. 用 k6或 JMeter写出可直接运行的压测脚本 3. 压测数据准备方案需要多少测试账号、多少商品数据如何构造 4. 监控指标清单压测期间盯哪些指标RT、TPS、错误率、CPU、内存、慢 SQL 5. 结果判定标准什么算通过瓶颈出现时按什么顺序排查七、代码审查环节7.1 提交前自查让 AI 当 Reviewer你是一位严格的 Code Reviewer。请审查以下代码改动模拟一次真实的 PR Review。 【改动内容】粘贴 diff 或代码 【背景】这个改动是为了【粘贴需求描述】 请从以下维度审查按严重程度排序输出 1. 正确性逻辑错误、边界遗漏、空指针风险 2. 安全注入、越权、敏感信息泄露密钥、token 硬编码 3. 性能N1、不必要的循环、大对象拷贝 4. 可读性命名、函数长度、重复代码 5. 可维护性是否违反现有项目规范是否需要补测试 输出格式每个问题给出【文件:行号】 问题描述 修改建议代码。 最后给出总体结论可以合并 / 需要修改后合并 / 需要重构。7.2 老代码理解接手祖传代码我刚接手一段老代码完全看不懂。请帮我解读 【代码】粘贴代码 【我知道的信息】这是一个【XX 模块】大概负责【XX 功能】 请 1. 用一段话概括这段代码的整体职责 2. 画一张文字版的调用流程图A 调用 BB 做什么…… 3. 标出代码里的坑魔法数字、隐式副作用、过时写法 4. 如果我要修改【XX 功能】告诉我应该从哪里入手、动哪里最安全7.3 安全专项审查你是一位安全工程师。请对以下代码做安全审计 【代码】粘贴代码 重点检查 OWASP Top 10 相关问题 1. 注入类SQL 注入、命令注入、XSS 2. 认证授权越权水平/垂直、token 校验缺失、敏感接口未鉴权 3. 数据安全敏感信息密码、身份证、手机号是否加密存储、日志是否脱敏 4. 配置安全硬编码密钥、调试接口暴露、错误信息泄露堆栈 对每个发现给出漏洞类型 风险等级 可利用场景 修复代码。八、部署与运维环节8.1 编写 Dockerfile 与部署配置你是一位 DevOps 工程师。请为以下项目编写容器化部署配置 【项目信息】前端 React 构建产物 后端 Spring Boot 3 应用 MySQL 8.0 Redis 【环境】云服务器 2 台4核8G没有 K8s用 docker-compose 要求 1. 前端 Dockerfile多阶段构建最终镜像用 nginx 托管静态文件镜像尽量小 2. 后端 DockerfileJRE 基础镜像分层打包加速构建 3. docker-compose.yml编排所有服务配置健康检查、重启策略、数据卷持久化 4. nginx.conf反向代理后端 API、开启 gzip、配置合理的缓存头 5. 给出常用运维命令清单查看日志、重启服务、进入容器排查 6. 标注安全注意事项不要把 .env 打进镜像数据库端口不要对外暴露8.2 CI/CD 流水线配置你是一位 DevOps 工程师。请为以下项目配置 CI/CD 流水线 【项目】GitHub 仓库前端 React 后端 Spring Boot 单仓管理 【部署目标】自有服务器通过 SSH 部署 【工具】GitHub Actions 要求 1. PR 阶段自动跑 lint、单元测试、构建验证失败禁止合并 2. 合并 main 后自动构建镜像/产物部署到测试环境 3. 打 tag 后部署到生产环境生产部署需要人工确认manual approval 4. 每一步失败要有明确的错误提示 5. 敏感信息服务器密钥、数据库密码全部用 secrets 管理 输出完整的 workflow YAML 文件关键步骤加注释。8.3 线上问题应急排查线上出故障了请帮我系统性排查 【故障现象】粘贴现象例如14:05 开始接口大量超时错误率 40% 【已知信息】粘贴监控数据、日志片段、最近的发布记录 请按以下思路引导我排查 1. 先定位影响面是所有接口还是特定接口所有用户还是部分用户 2. 缩小范围按发布变更 → 依赖服务 → 基础设施DB/Redis/网络→ 流量突增的顺序逐一排除 3. 每一步告诉我执行什么命令、看什么指标、根据结果怎么判断 4. 找到根因前先给出止血方案回滚、限流、扩容、降级 5. 事后给出复盘清单根因、时间线、改进措施8.4 日志与监控体系搭建你是一位可观测性专家。现在的系统基本没有监控出问题全靠用户反馈。请帮我搭建一套最小可用的监控体系 【现状】Spring Boot 应用 × 3MySQL Redis部署在 2 台云服务器 【约束】预算有限优先开源方案运维就我一个人兼职 请给出 1. 监控方案选型推荐一套轻量组合如 Prometheus Grafana Loki说明为什么不用更重的方案 2. 必须监控的指标清单应用层QPS、RT、错误率、JVM、中间件层、服务器层各列前 10 个最重要的 3. 告警规则哪些指标达到什么阈值必须告警告警发到哪里 4. 应用侧改造需要加什么依赖、暴露什么端点给出具体配置 5. 实施步骤按今天就能做 / 本周做 / 持续完善三个阶段排期九、文档编写环节9.1 README 生成你是一位技术文档专家。请为这个项目编写 README.md 【项目信息】粘贴项目描述、技术栈、目录结构 【目标读者】新入职的开发者需要 30 分钟内把项目跑起来 README 必须包含 1. 项目简介一段话讲清楚这个项目是干嘛的、解决什么问题 2. 技术栈与架构用简单的文字架构图说明模块关系 3. 快速开始环境要求、安装步骤、启动命令精确到复制粘贴就能跑 4. 项目结构说明每个目录的职责 5. 开发规范分支策略、提交规范、代码风格 6. 常见问题至少列 3 个新人最容易踩的坑及解决方法 语气简洁实用不要营销话术。9.2 接口文档同步你是一位技术文档工程师。以下代码最近做了改动请帮我同步更新接口文档 【旧文档】粘贴旧文档 【代码改动】粘贴 diff 请 1. 列出文档需要更新的所有地方新增接口、字段变更、废弃接口 2. 输出更新后的完整文档变更处用【变更】标记 3. 如果有破坏性变更删字段、改类型单独列出一个升级注意事项章节说明调用方需要怎么改9.3 技术方案文档你是一位架构师。请把以下技术方案整理成正式的设计文档 【方案内容】粘贴方案要点可以是零散的笔记、聊天记录、会议结论 【读者】团队技术评审会 文档结构要求 1. 背景与目标为什么要做这件事解决什么问题 2. 现状分析当前系统是怎么做的痛点在哪 3. 方案设计整体架构文字架构图、核心流程、关键设计决策 4. 方案对比考虑过哪些备选方案为什么没选 5. 影响范围涉及哪些系统改动、数据迁移、上下游协调 6. 风险与应对最大的 3 个风险及兜底方案 7. 排期计划里程碑拆分 写得让评审的人挑不出没考虑 XX这种毛病。十、Bug 排查与调试环节10.1 报错信息解读我遇到了这个报错请帮我分析 【完整报错堆栈】粘贴完整堆栈不要只截一行 【触发场景】粘贴操作步骤 【相关代码】粘贴相关代码 【环境】JDK 17、Spring Boot 3.2、本地能跑线上报错 请 1. 用一句话说清根因直接原因不是堆栈第一行 2. 解释错误发生的完整链路从哪个调用开始在哪一步炸的 3. 给出修复方案和修复后的代码 4. 说明为什么本地没复现线上复现——环境差异可能在哪 5. 给出防御性建议类似问题以后怎么提前发现10.2 偶现 Bug 攻坚有一个偶现 bug请帮我设计排查方案 【现象】粘贴现象例如每天凌晨 3 点左右偶发订单状态错乱白天正常 【已知线索】粘贴日志、监控、用户反馈 【已排除的原因】粘贴已经查过但排除的方向 请 1. 基于线索列出所有可能的假设按可能性排序 2. 为每个假设设计验证方法加什么日志、查什么数据、做什么实验 3. 给出可以立即落地的日志增强代码在关键路径补充上下文信息 4. 推荐一个守株待兔策略下次复现时怎么确保抓到完整现场10.3 内存泄漏/资源问题排查应用疑似内存泄漏请帮我排查 【现象】粘贴现象例如运行 3 天后内存涨到 90%重启后恢复 【环境】JVM 参数、堆大小、GC 日志关键信息 【已做尝试】粘贴已尝试的操作 请给出完整的排查手册 1. 第一步用什么命令确认是堆泄漏还是堆外泄漏jstat / jmap / Native Memory Tracking 2. 怎么 dump 内存、用什么工具分析MAT / VisualVM、重点看什么支配树、GC Roots 3. 列出本技术栈最常见的 5 个泄漏原因如 ThreadLocal 未清理、静态集合只增不减、连接未关闭、监听器未注销、缓存无上限并给出每个的排查特征 4. 给出止血方案重启策略、内存告警阈值、自动 dump 配置十一、重构与性能优化环节11.1 安全重构老代码你是一位重构专家。请重构以下代码 【代码】粘贴代码 【痛点】粘贴痛点例如这个 800 行的方法谁都不敢动 【约束】对外接口不能变现有行为不能变没有现成测试 请按安全重构的标准流程 1. 第一步先为现有代码补特征测试锁定当前行为给出测试代码 2. 第二步识别坏味道过长方法、重复代码、魔法数字、过深嵌套逐项列出 3. 第三步小步重构每一步给出重构手法名称Extract Method / Replace Conditional with Polymorphism 等和重构后代码 4. 说明每一步重构后如何验证行为没变 5. 最后给出重构前后的对比总结11.2 代码简化请简化以下代码要求一个新人 3 分钟能看懂 【代码】粘贴代码 简化原则 1. 早返回early return消灭嵌套 2. 有意义的命名替代注释 3. 重复逻辑抽函数但不过度抽象 4. 用数据结构Map/查表替代长串 if-else 5. 删除死代码和无用的防御性判断 输出简化后的完整代码并用要点列出每处简化及原因。不要改变外部行为。11.3 技术债盘点你是一位技术负责人。请帮我盘点这个模块的技术债 【模块代码】粘贴代码或目录结构 关键文件 【模块背景】粘贴背景例如这是 3 年前外包做的支付模块现在每周都有人踩坑 请输出一份技术债清单表格 - 债务项具体位置 - 类型代码质量 / 架构缺陷 / 文档缺失 / 测试缺失 / 依赖过时 - 风险等级哪天会炸 - 修复成本人天 - 建议优先级 最后给出还债策略哪些立刻修、哪些随需求顺带修、哪些可以暂时记账。十二、组合技把提示词串成一条流水线单个提示词解决点状问题组合起来才是完整的开发流。一个功能从 0 到上线推荐这样串第 1 步需求 → 设计同一个会话里完成先执行【1.1 需求拆解】→ 基于拆解结果执行【2.1 接口设计】【2.2 表设计】→ 最后让它输出一份开发任务清单按依赖关系排序第 2 步并行开发前后端各开一个会话前端会话【3.1 页面实现】→【3.3 接口对接】 后端会话【4.1 接口开发】→【6.1 单元测试】 两边用同一份接口文档作为唯一事实来源第 3 步质量门禁提交前执行【7.1 代码自查】→ 全部可以合并后再提交 涉及资金/权限的追加执行【7.3 安全审查】第 4 步上线与收尾【8.1 部署配置】→【9.2 文档同步】→ 上线后把【8.3 应急排查】提示词存好备用一个高阶技巧把规范固化成项目级记忆在 Claude Code 里把团队规范写进CLAUDE.md在 Codex 里写进AGENTS.md。内容包含技术栈版本、目录约定、命名规范、禁止事项如禁止直接操作生产数据库、常用命令。这样每轮对话都不用重复交代上下文提示词可以精简一半。附录高频补丁话术速查表这些短句可以追加在任何提示词后面解决最常见的问题场景追加这句话它给了一个巨大改动先给出最小可行改动不要顺手优化无关代码它自作主张引入新依赖不要使用任何新的第三方依赖只用项目已有的代码太长贴不下只输出改动过的函数用注释 // ...其余不变 省略未改动部分它理解偏了需求先不要写代码用你的话复述一遍需求等我确认担心它瞎编 API不确定的方法或参数明确标注待验证不要编造输出质量不稳定完成后自查一遍能否编译边界情况是否处理然后给出自查结论它改坏了其他功能解释这个改动的影响面哪些现有功能可能受影响如何验证需要它解释原理每个关键改动后用一句话解释为什么这么做我是面试官视角方案太复杂给我一个更简单的方案哪怕功能少 20%优先可维护性要对比多个方案用表格对比最后一行给出你的明确推荐不许骑墙写在最后这套提示词的核心心法只有一句话把 Agent 当成一个能力很强但完全不了解你项目的高级外包。它不知道你的项目规范 → 你给它上下文它不知道什么算完成 → 你给它验收标准它倾向于过度发挥 → 你给它边界约束它偶尔会一本正经地编 → 你要求它标注不确定项提示词不是咒语是工程化的沟通。用熟这套骨架之后你会发现自己写提示词的速度和 Agent 写代码的速度一样快。收藏这份手册下次开新需求时从第一章抄到最后一章就是一条完整的 AI 辅助开发流水线。