写技术债改造方案时，最容易出现的问题就是“说大话”——什么“需统筹规划”“应分阶段推进”“要兼顾稳定性与迭代性”，听着一套一套的，落到代码仓库里一看，全是空话。更麻烦的是，ChatGPT这类模型默认就爱堆这种词，搞得最终方案像从模板里拼出来的，根本没法直接拿给团队执行。

所以，想要一份能落地的方案，得从根上改掉提示词的习惯。三个关键动作：让人物具象化、把虚词禁掉、把现实限制绑死。

用具体角色替代抽象主语

第一个动作很简单：别让模型当“万能专家”，得给它一个真实身份。在提示词开头就明确写清楚：“你是一位在支付系统干了7年的后端工程师，刚带队完成一次核心账务模块重构”。有了这个上下文，模型输出的每一句话都会被锁定在具体场景里。

下一步，要求所有建议必须绑定这个角色的真实经验。比如，不要让它说“建议引入监控”，而要改成“我们上次在订单履约链路加SLO告警时，发现Redis连接池超时被漏报，所以这次在改造前先补全连接池指标打点”。——没有具体上下文支撑的句子，模型根本编不出这种细节。这一步走完，90%的套话就能直接过滤掉。

禁用高频虚词清单

第二个动作：在提示词末尾加一句硬约束：“禁止出现以下任一词汇：夯实、抓手、赋能、闭环、纵深、耦合度（除非后接具体数值）、颗粒度（除非后接单位如‘接口级’‘字段级’）”。这不是为了凑字数，而是直接掐断模型偏好的虚词生成路径。

替代方法有两个：一是用动词短语替代名词化表达。比如把“提升系统的可维护性”改成“删掉3个重复的DTO转换工具类，统一用MapStruct注解生成”。——动手做什么、怎么做，一眼就能看清。

二是强制要求每项改造动作都带触发条件。比如“当单测覆盖率低于65%时，才启动Service层重构；否则先补单测”。没有触发条件的改造建议一律视为无效——这套规则背后，是让模型不再闭着眼睛写通用方案。

植入真实约束条件

第三个动作：在提示词里嵌入三条不可协商的现实限制——当前团队只有2名资深开发+1名测试，Q3要上线新营销活动，线上数据库版本是MySQL 5.7.28且无法升级。这三条一放进去，模型自然会放弃“理想状态下”的通用方案，转而计算真实资源下的取舍。

比如它不会再建议“全面迁移到DDD”，而可能写“先把优惠券核销服务里状态机逻辑抽成独立module，复用现有Spring StateMachine，不新增依赖”。——这才是能落实到排期和代码里的改造路径。

操作起来特别简单：把这三条限制直接复制进提示词第一段就行。后续所有输出都会自动带上这些硬约束，方案自然就不再是纸上谈兵。