很多人都有过这种体验：让ChatGPT写一份技术债改造方案，结果它翻来覆去就是“应优化架构”“需提升可维护性”之类的话，听起来全对，但落到实处根本不知道该怎么动手。问题出在哪里？不是模型笨，而是你给的提示词太“空”了——没有限定边界，模型就只能凭常识凑个教科书式的答案。

要解决这个痛点，关键不是让模型“写得更好”，而是让它“没法跑偏”。下面这几点，是在实际工作中反复试出来的有效方法。

明确限定改造范围

最简单却最容易被忽略的一步：在提示词开头就把物理边界写死。比如这句：「只处理 user-service 模块中 /v1/users/{id} 接口对应的 UserController.ja va 和 UserServiceImpl.ja va 两个文件。」不加上这一句，模型默认“整个系统都该改”，结果全是空话。

另一个常见误区是使用“建议”“可以”“应当”这类弱动词。你必须全部替换为强动词，比如“将删除”“将重命名”“将提取为独立方法”。举个例子，把“可以考虑将校验逻辑抽离”改成“将把 validateUserInput() 方法从 UserController.ja va 第42–58行剪切至 UserValidator.ja va 新建类中”。指示越明确，模型越没法打马虎眼。

强制绑定验证动作

每项改造必须配一句验证手段，这是让方案“可落地”的铁律。可以有两种做法：

一种是要求每步改造后写明验证方式。例如：“将 JWT token 解析逻辑从 filter 移至 AuthService → 修改后调用 curl -H 'Authorization: Bearer xxx' http://localhost:8080/v1/users/1 → 检查响应头 X-Auth-Source: service-layer 是否出现”。

另一种是指定失败兜底行为，这更关键。比如：“若迁移后 /v1/users/{id} 接口响应延迟超过 300ms，则立即回滚 UserServiceImpl.ja va 第77行的缓存装饰器代码，并保留原 Map 缓存实现”。

必须写明回滚触发条件和精确到行号的还原操作，否则模型会忽略不可逆风险。

注入真实上下文快照

模型没法知道你的代码库里具体长什么样，所以你需要在提示词里“塞”三段真实材料：

第一段，UserController.ja va 中 /v1/users/{id} 对应的完整方法体，连注释一起带上；第二段，SonarQube 扫描报告里该文件的 top3 技术债条目，比如 “Cyclomatic Complexity=17 > threshold=10” 这种；第三段，最近一次压测中该接口 P95 延迟为 420ms 的截图文字描述。

然后明确告诉模型：“仅基于以上三段原始信息生成改造步骤，禁止编造未提供的类名、配置项或监控指标”。这一步能严格锁死模型的想象空间，不让它凭空捏造不存在的依赖或组件。

最后还有个实用的小技巧：追加命名约束。比如指令中写明“所有新增方法必须以 withDebtFix_ 为前缀，例如 withDebtFix_validateEmailFormat()”。这样做的好处是，既能防止模型生成与现有代码风格冲突的命名，又方便后续审查和回滚时快速定位改动点。