夜雨聆风AI 写代码最容易翻车的地方，不是模型不会写，而是你一上来就让它写。
一句“帮我做一个登录功能”，交给 Claude Code、Codex、Cursor、Trae，通常都能生成代码。但它不知道你的项目结构、权限边界、接口约定、测试方式，也不知道这次任务到底是原型、内部工具，还是要进生产环境。
软件开发里的提示词，不应该只是一句话需求，而是一条工作链：需求澄清 → 技术方案 → 项目上下文 → 分步实现 → 定向审查 → 调试复现 → 测试文档。
一、先选对工具
软件开发不要只盯“谁代码写得快”。不同阶段适合不同工具。
- 需求澄清和技术方案
：DeepSeek、ChatGPT、Claude 都可以。它们适合把模糊需求拆成页面、接口、数据模型、边界条件和风险清单。 - 代码库内改动
：Claude Code、Codex、Cursor、Trae 更合适。它们可以结合项目上下文读文件、改文件、跑命令或辅助执行多步任务。 - 项目规则沉淀
：Codex 可以读取项目里的 AGENTS.md 这类说明；Cursor 有 Rules 机制，会把规则内容放进模型上下文；Claude Code 也支持项目级命令和工作流配置。 - 中文需求和国内环境
：DeepSeek 适合做方案推演、代码解释和审查；Trae 的 Builder 模式适合从中文需求出发，读取项目文件、分解任务并逐步执行。 - API 侧长上下文任务
：DeepSeek API 的 Context Caching 默认开启，适合把固定提示词、工具定义、项目说明放在前面，减少重复上下文成本。
所以提示词也要跟着变。
不是“帮我写代码”，而是“先读项目规则和相关文件，确认实现方案，再只修改指定模块，最后跑测试并说明风险”。
二、需求阶段：先把一句话变成规格
最差的提问是：
帮我写一个登录功能。这句话缺的东西太多：前端还是后端？React 还是 Vue？要不要验证码？登录态存在 cookie 还是 token？失败提示怎么展示？有没有现成接口？要不要测试？
先让 AI 把需求拆开：
角色：你是资深全栈工程师，熟悉产品需求拆解和工程实现。任务：帮我把“登录功能”拆成可开发规格。项目背景：- 前端：React + TypeScript- 状态管理：Zustand- 后端：已有 /api/login 接口- 登录方式：邮箱 + 密码- 登录成功后跳转首页- 登录失败展示错误提示请输出：1. 页面交互流程2. 前端状态设计3. 接口请求和错误处理4. 需要确认的问题5. 不建议本轮实现的功能约束：- 先不要写代码- 不要自行增加验证码、短信登录、人脸识别- 不确定的地方列为“需要确认”这一步的目标不是让 AI 立刻动手，而是先把开发边界画清楚。
如果需求没拆清，后面生成的代码越多，返工越大。
三、上下文阶段：别让 AI 在仓库里乱猜
AI 进入一个陌生项目，最容易犯的错是“凭经验写”。它看到一个需求，就按常见项目结构生成一套新代码，结果和你现有目录、命名、接口风格都不一致。
先给它上下文。
如果你用 Claude Code、Codex、Cursor 或 Trae，可以这样开场：
请先阅读项目结构和相关文件，不要修改代码。重点查看：- package.json- src/routes 目录- src/api 目录- src/store 目录- 现有登录、鉴权或用户相关代码请输出：1. 这个项目的前端框架和路由方式2. API 请求封装在哪里3. 状态管理方式4. 登录功能最应该改哪些文件5. 暂时不要动哪些文件要求：- 只做分析，不写代码- 如果找不到相关文件，直接说明如果项目长期使用 AI 编程，最好把规则写进仓库。
例如 AGENTS.md、.cursor/rules、CLAUDE.md、项目 README，都可以放这些内容：
项目规则：- 所有新代码必须使用 TypeScript- 不允许使用 any- API 请求统一走 src/api/client.ts- UI 组件必须放在 src/components- 状态管理统一使用 Zustand- 提交前必须运行 npm test- 不要修改数据库迁移文件，除非任务明确要求临时提示词适合一次性任务，项目规则适合长期协作。
规则写得越清楚，AI 越不容易把项目改成另一套风格。
四、方案阶段：先计划，再写代码
复杂功能不要直接让 AI 改文件。
先让它给方案：
我需要实现多文件上传功能，支持进度显示、失败重试和取消上传。请先给技术方案，不要写代码。需要说明：1. 前端组件怎么拆分2. 上传队列怎么管理3. 每个文件的状态有哪些4. 失败重试怎么处理5. 取消上传怎么实现6. 哪些地方需要单元测试7. 这次最小可交付版本包含什么拿到方案之后，再让它收窄：
方案确认。请先只实现上传队列的状态管理，不要写 UI。要求：- 新增 useUploadQueue.ts- 支持 addFiles、startUpload、retry、cancel、remove- 每个文件状态包括 waiting、uploading、success、error、cancelled- 先写核心逻辑和测试- 不要接真实接口，用 mock uploader这和真实开发更接近。
先确认架构，再写局部代码；先跑通核心逻辑，再做界面和样式。
五、实现阶段：一次只让它改一个模块
AI 编程的危险，不是它写不出来，而是它一次改太多。
一个“帮我完成上传功能”，可能同时改组件、状态、接口、路由、样式、测试。最后出了问题，很难判断是哪一步引入的。
更好的方式是拆成几轮：
第一轮：只实现上传队列逻辑。修改范围：src/features/upload/useUploadQueue.ts不要修改 UI、路由和 API。完成后说明新增了哪些状态和方法。第二轮：只实现上传组件。修改范围：src/features/upload/UploadPanel.tsx复用上一轮的 useUploadQueue，不要重写队列逻辑。第三轮：只接入真实接口。修改范围：src/api/upload.ts 和 UploadPanel.tsx不要改状态管理文件，除非发现上一轮接口设计无法支持。每一轮都要写清楚三件事：
修改范围； 禁止修改什么； 完成后怎么验证。
AI 不是不能做大任务，而是大任务必须有边界。
六、调试阶段：给错误，也给复现路径
“代码报错了，帮我看看”几乎没用。
调试提示词至少要给四样东西：错误信息、相关代码、运行环境、复现步骤。
这段代码运行时报错，请帮我定位原因。错误信息：[粘贴完整报错，包括 stack trace]运行环境：- Node.js 版本：20.x- 包管理器：pnpm- 框架：Next.js- 触发命令：pnpm dev复现步骤：1. 打开 /login2. 输入邮箱和密码3. 点击登录4. 页面报错相关代码：[粘贴 login.tsx、api client、相关 hook]请输出：1. 最可能的错误原因2. 需要检查的文件3. 最小修复方案4. 修复后要跑哪些验证约束：- 不要顺手重构无关代码- 不要改 UI 样式如果错误是偶发问题，还要让 AI 先帮你补日志：
这个 bug 不是每次都出现。请先帮我设计最小日志方案，用来确认问题发生在哪一步。不要直接改业务逻辑。调试时最怕 AI 为了“修好”而大面积重写。
先定位，再修复。
七、代码审查：不要泛泛地问“有什么问题”
把一段代码丢给 AI，然后问“有什么问题”，它通常会给一堆散点建议：命名、性能、可读性、异常处理、测试覆盖率，什么都说一点。
代码审查要定向。
安全审查这样问：
请只审查这段登录代码的安全问题。重点检查：1. 是否有 SQL 注入或参数拼接风险2. 密码是否明文处理或记录日志3. token 是否安全存储4. 错误信息是否泄露内部细节5. 是否缺少限流或锁定策略不要关注命名、样式和普通性能优化。逻辑审查这样问：
请只审查这段订单状态流转的逻辑漏洞。重点检查：1. 状态是否可能跳过2. 重复提交会不会造成重复扣款3. 异步回调乱序时会不会写错状态4. 失败重试是否会破坏幂等性5. 哪些边界条件没有测试性能审查这样问：
请只审查这段列表渲染的性能问题。重点检查：1. 是否有不必要的重复渲染2. 是否需要 memo、虚拟列表或分页3. 是否存在大对象重复创建4. 是否有接口请求过多的问题要求：- 先按影响程度排序- 每条建议说明验证方式- 不要为了性能牺牲可读性，除非收益明显审查范围越窄，建议越能落地。
八、测试阶段：让 AI 补验证，不要只补代码
“帮我写单元测试”仍然太模糊。
更好的方式是先让 AI 列测试矩阵：
请为这个上传队列模块设计测试用例。模块能力：- 添加多个文件- 开始上传- 上传成功- 上传失败- 失败重试- 取消上传- 移除文件请输出测试矩阵：1. 正常路径2. 边界条件3. 异常路径4. 并发或乱序情况5. 不需要测试的内容先不要写测试代码。确认后再写测试：
按照上面的测试矩阵，使用 Vitest 写单元测试。要求：- mock uploader，不调用真实接口- 每个测试名称要说明业务场景- 测试代码能直接运行- 如果需要调整原模块以便测试，先说明再改测试不是“补几行断言”。
测试是在告诉 AI：这段代码必须用什么结果来证明自己写对了。
九、文档阶段：让 AI 写给下一个维护者
代码能跑，不等于别人能接手。
让 AI 写文档时，不要只说“加点注释”。先说明文档对象。
给维护者看的文档：
请为这个上传模块写一段维护文档。读者：接手这个模块的前端开发内容包括：1. 模块解决什么问题2. 核心文件和职责3. 状态流转说明4. 常见改动入口5. 已知限制6. 修改后必须跑哪些测试不要写营销式介绍。给初学者看的注释：
请给这段代码添加教学型注释。要求：- 解释为什么这么写，不只是解释语法- 复杂逻辑前加注释- 显而易见的变量声明不要注释- 不改变代码行为给团队看的变更说明：
请根据这次 diff 写一份 PR 描述。格式：1. 这次改了什么2. 为什么这么改3. 如何验证4. 风险和回滚方式要求：- 不要夸大收益- 不要写“优化了很多”这种空话文档的关键，不是把代码翻译成中文，而是让下一个人知道怎么维护。
十、软件开发提示词模板
1. 需求拆解模板
工具建议：DeepSeek / ChatGPT / Claude角色：资深软件工程师任务：把需求拆成可开发规格背景：[项目类型、技术栈、用户、已有接口]输出：交互流程、数据模型、接口需求、边界条件、需要确认的问题约束：先不写代码，不自行增加功能，不确定就标注2. 项目上下文模板
工具建议：Claude Code / Codex / Cursor / Trae任务：阅读项目上下文，不修改代码重点查看：[目录、配置、API 封装、状态管理、测试文件]输出：项目结构、相关文件、实现入口、风险文件、建议修改范围约束：只分析，不写代码，不运行破坏性命令3. 技术方案模板
工具建议：DeepSeek / Claude / ChatGPT / Claude Code / Codex任务：先给技术方案需求：[具体功能]输出：模块拆分、数据流、接口设计、异常处理、测试计划、最小可交付版本约束：不要写代码，先说明取舍和风险4. 分步实现模板
工具建议：Claude Code / Codex / Cursor / Trae任务：只实现当前一步修改范围：[文件或目录]禁止修改：[不相关模块、配置、数据库、样式]验收方式：[测试命令、页面路径、手动检查步骤]输出：改了哪些文件、如何验证、还有哪些风险5. 调试定位模板
工具建议：Claude Code / Codex / Cursor / Trae / DeepSeek任务：定位错误原因材料：错误信息、运行环境、复现步骤、相关代码输出：最可能原因、检查顺序、最小修复方案、验证方式约束：不要大面积重构，不要修改无关代码6. 定向代码审查模板
工具建议：DeepSeek / Claude / ChatGPT / Claude Code / Codex任务：按指定维度审查代码审查维度：[安全/逻辑/性能/可维护性/测试覆盖]输出：问题、风险等级、原因、修改建议、验证方式约束：只看指定维度，不泛泛点评7. 测试补全模板
工具建议：Claude Code / Codex / Cursor / Trae任务：为指定模块补测试测试范围：[函数、组件、接口、状态机]输出：测试矩阵、测试代码、运行命令、未覆盖风险约束：先列用例，再写代码；不调用真实外部服务软件开发提示词的核心，不是把需求说得更热闹，而是把任务边界说得更清楚。
需求阶段，用 DeepSeek、ChatGPT、Claude 把一句话需求拆成规格。
进入代码库后，用 Claude Code、Codex、Cursor、Trae 这类工具读取上下文、限定修改范围、分步执行、跑测试。
审查和调试阶段，再把问题收窄到安全、逻辑、性能、测试覆盖这些具体维度。
AI 可以写代码，但它更需要一条清晰的工作链。先把目标、上下文、边界和验收方式说清楚，AI 才像工程同事，而不是随机生成器。
#软件开发 #提示词工程 #AI编程 #ClaudeCode #Codex #Cursor #Trae
参考资料
OpenAI Codex 使用说明：https://help.openai.com/en/articles/11369540 OpenAI Codex CLI 入门：https://help.openai.com/en/articles/11096431 Claude Code Commands 文档：https://code.claude.com/docs/en/commands Claude Code Slash Commands：https://docs.claude.com/en/docs/claude-code/slash-commands Cursor Rules 文档：https://docs.cursor.com/en/context/rules Trae Builder 文档：https://traeide.com/zh/docs/what-is-trae-builder DeepSeek Context Caching 文档：https://api-docs.deepseek.com/guides/kv_cache DeepSeek Function Calling / JSON Output：https://api-docs.deepseek.com/zh-cn/news/news0725
合集文章链接： 一、提示词入门：别把 AI 当百度用 二、电商运营：从爆款标题到客服话术的提示词实战 三、会计财务：让 AI 做账、审单、写分析报告 四、工业设计：从概念草图到渲染图的提示词链 五、软件开发：代码生成、调试、文档一条提示词链搞定 六、应用APP：从产品需求到交互设计的提示词模板 七、AI算命风水：用提示词把玄学变成"个性化解读服务" 八、提示词进阶：Chain-of-Thought、Few-Shot 和多轮对话控制
