豆包需求转开发任务提示词，输出优化更易发布
需求文档若要直接移交开发，需将豆包产出的模糊描述转化为精准的提示词。否则程序员收到后，必然反复追问边界细节。关键三步骤：清除模糊词汇、明确触发条件与设备终端、严格分离界面与逻辑。采用"主客体+操作指令+数据对象+约束条件"的结构化表达，覆盖异常分支，同时注明技术栈、复用模块、数据源及权限策略。
首先清理原始需求中的三类典型缺陷。逐句审查豆包生成的需求：遇“大概”“可能”“类似”等模糊词直接删除；发现“用户操作后显示结果”这类表述，需追问具体操作类型及触发页面；同时区分UI设计与功能逻辑——例如“页面要很美观”这类主观描述，对开发而言毫无价值。若出现“支持多端”，必须补充明确终端类型。仅写“多端”无法排期，需具体到iOS、Android、H5或小程序，并说明组合范围。
用“主客体+操作+数据+约束”重构每项任务
具体做法：将“用户能查订单”转化为“登录用户→点击‘我的订单’Tab→调用/order/list接口→预期返回status=200且data为数组→列表项包含order_id、status_text、pay_time字段”。这条执行链路为开发提供了清晰边界，每一步都刚性限定。
另一种思路是覆盖异常分支。例如“提交表单时若手机号格式不符合规则，前端需即时标红并阻断提交，不发起请求；若后端返回code=4001，则toast提示‘该号码已被注册’”。异常分支绝不能省略，否则测试阶段易遗漏关键场景，导致返工成本飙升。
补充开发所需的上下文信息
第一步：明确当前系统技术栈。在提示词起始行注明：“前端采用Vue3+TypeScript，后端为Spring Boot 3.2，数据库使用MySQL 8.0”。明确版本号可避免开发人员猜测。
第二步：标注现有可复用的能力模块。例如“用户登录态已通过AuthContext全局注入，无需重复鉴权；地址选择组件封装于@/components/AddressPicker，可直接import调用”。明确复用点可大幅节省开发时间，否则开发者可能重复造轮。
第三步：标注数据源与权限规则。例如“订单列表的商品图片URL来自CDN域名https://img.example.com，仅登录用户可访问；销量字段需增加缓存层，TTL设置为300秒”。若遗漏CDN域名或缓存策略，前端将调用错误地址，后端可能因流量冲击而崩溃，后果严重。