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

在提示词开头直接采用固定结构：

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

将角色、动作与约束要素通过箭头串联，形成完整指令链。千万别忽视这一环节——若遗漏技术栈版本，模型将默认采用Java 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”等具体操作，确保开发团队能直接参照执行。