DeepSeek写技术债优先级提示词怎么输出检查清单

第一步：用三元组锁定角色、动作与约束

直接在提示词开头写死这样的结构：

“你作为微服务架构治理工程师→生成一份可落地的技术债优先级检查清单→基于SOLID原则+OpenAPI 3.1+Go 1.22+K8s 1.28环境，禁用任何主观评价词如‘较重’‘有待加强’。”

把角色、动作和约束用箭头串起来，一步到位。千万别小看这一步——如果漏掉技术栈版本，模型会默认用Ja va Spring Boot或Python Flask，生成的东西根本对接不上你现在的服务定义和CLI工具链，检查项也就失去了实际意义。

第二步：强制注入三类校验锚点

维度锚点

在提示词里明确要求：检查清单必须覆盖7类隐蔽设计债，包括单一职责失效、接口隔离缺失、依赖倒置缺失、里氏替换失效、开闭原则违反、聚合根越界、领域事件污染，每类至少一条可验证的检查项。这样能确保模型不会漏掉关键领域，输出结果更全面。

上下文锚点

插入不可替换的变量：SERVICE_NAME=order-service、ENV=prod-k8s-2024、MAIN_API=/v2/checkout。模型输出的所有检查项必须至少调用其中两个变量，比如“验证order-service在prod-k8s-2024环境下对/v2/checkout的超时策略是否硬编码”。这样生成的检查项才有针对性，而不是通用的套话。

反例锚点

嵌入真实故障片段，比如“支付回调重复触发→该问题本应在检查清单第5项‘领域事件幂等性校验’暴露；订单状态机跳变异常→该问题本应在检查清单第2项‘状态转换契约一致性检查’暴露”。模型必须在输出中显式引用这两条反例对应的编号，确保它不会忽略这些典型问题，从而避免相似故障再次发生。

第三步：分层输出结构化表格

要求模型按Markdown表格输出，表头固定为：检查项ID、所属设计债类型、风险等级、验证方式、失败示例、修复路径。风险等级只允许填高、中、低三档，而且高级项必须满足特定条件：影响至少2个下游服务、变更需跨3个Git仓库、或导致P0故障历史≥1次。每条验证方式必须包含可执行命令或断言，比如“执行ds-solid-check --spec openapi.yaml --rule interface-segregation | grep ‘/v2/checkout’”，而不是含糊的“检查接口是否符合I原则”。失败示例要具体到代码行或配置片段，比如“openapi.yaml第87行：responses.200.schema.properties.paymentId.type = string → 该字段属payment-service领域，不应出现在order-service响应体中”。修复路径禁止使用“优化”“调整”这类模糊动词，必须用“将paymentId字段移至payment-sdk/v1.3.0 DTO”或“在domain/event.go中新增OrderPaidV2Event结构体并弃用OrderPaidEvent”这样的具体操作，才能保证开发团队能直接照着执行。