这件事一定要在提示词里提前说明白：Sleuth 的接入方式，以及链路请求头的透传规则。少了这一步，CodeBuddy 生成的代码通常不会自动带上 traceId。更稳妥的做法是按三步推进：先把上下文交代完整，再明确指定方法注入，最后检查一遍 Feign 拦截器是否真正生效。同时，还要避开三类最常见的链路中断问题：URL 硬编码、异步线程导致 MDC 丢失，以及 @Async 作用域配置不正确。

在CodeBuddy提示词中启用链路追踪上下文注入

当你希望 CodeBuddy 生成的代码自动携带 Sleuth/Zipkin 链路 ID，并支持微服务之间的跨服务透传时，必须在提示词中明确声明链路追踪上下文的存在方式与注入时机。否则，AI 往往会默认忽略 MDC 或 ThreadLocal 中的 traceId 字段，导致生成结果缺少链路追踪能力。

第一步：在提示词开头补充链路语境声明——明确写出“当前服务已集成 Spring Cloud Sleuth，所有 HTTP 请求头包含 X-B3-TraceId、X-B3-SpanId，Feign 调用需要透传这些请求头”。这一步不能省略，【若未声明，CodeBuddy会按无链路追踪环境生成代码，通常不会补充@RequestHeader或ClientHttpRequestInterceptor】。

第二步：指定关键方法必须注入 trace 上下文——例如：“在 getOrderDetail() 方法内部，需要通过 Tracer.currentSpan().context().traceId() 获取当前 traceId，并写入日志；如果调用外部服务，必须确保 Feign 客户端自动携带 X-B3-* 请求头。”

第三步：要求显式校验透传完整性——再追加一句：“生成代码后，请检查 Feign 接口是否配置了 RequestInterceptor，且拦截器中调用了 request.header('X-B3-TraceId', traceId)”。

提示词中规避链路断开的三类典型错误写法

方法一：尽量不要用硬编码字符串拼接 URL 再发起远程调用。比如 CodeBuddy 遇到“new RestTemplate().getForObject("http://xxx/order/" + id, String.class)”这类写法时，通常不会主动把 trace 上下文注入进去，原因也很明确：这里的 RestTemplate 实例并没有经过 Sleuth 自动包装，因此无法正常传递链路信息。

方法二：不要在异步线程中直接读取 MDC——例如“new Thread(() -> log.info("order processed")).start()”，这会导致子线程拿不到 traceId。更合适的写法应为“executor.submit(() -> { MDC.put("traceId", Tracer.currentSpan().context().traceId()); ... })”，从而保证日志链路信息不丢失。

方法三：不要遗漏“使用@Async注解的方法必须加上@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)”这一要求，否则 Sleuth 无法把父 span 正确传递给异步线程，【该注解缺失会导致链路在@Async处直接断开，而且CodeBuddy通常不会主动补全】。

用自然语言指令触发链路感知代码生成

可以直接对 CodeBuddy 说：“基于当前已接入 Sleuth 的 Spring Boot 服务，为订单查询接口增加链路 ID 日志打印，并确保调用库存服务时 traceId 可以透传过去。”

这句指令实际上包含了三个关键约束：项目已具备 Sleuth 依赖、当前服务是调用发起方、目标是保证跨服务链路持续连通。CodeBuddy 会据此更容易生成包含 MDC 日志、Feign 拦截器，以及 @Async 安全封装的完整代码。

如果你只说“帮我写个订单查询接口”，它通常不会加入任何链路追踪相关逻辑——因为缺少必要的上下文前提和提示词锚点。