技术债务往往藏在代码库的细节里，可能是一次临时绕过的判断逻辑，也可能是长期未升级的依赖包。文心快码具备较强的代码理解能力，但如果你只输入一句“帮我优化代码”，它很难给出系统级的债务治理建议。要让AI真正参与技术债务管理，提示词需要从模糊请求升级为结构化审计指令，把识别、量化、偿还和沉淀串联成闭环。
下面从四个层面展开，说明如何用提示词把技术债务从一种感觉变成可执行的数据和流程。
一、把技术债务拆成可识别的信号
很多团队对技术债务的理解停留在重复代码和糟糕命名上，这会导致大量隐性债务被忽略，比如依赖版本漂移、异常处理不一致、缓存过期策略缺失、API误用等。文心快码可以阅读代码上下文，但前提是你给它明确的扫描维度。一个有效的债务审计提示词至少包含角色设定、扫描范围、债务类型、输出格式和排除项五个部分。
下面是一个可以直接在文心快码中使用的审计提示词模板：
你是一名资深技术债务审计专家。请阅读当前仓库 src/order 目录下的代码，围绕以下维度逐项扫描： 1. 重复代码：是否存在复制粘贴超过 20 行的逻辑块 2. 圈复杂度：超过 10 的函数或方法 3. 依赖风险：package.json 或 go.mod 中过期超过两个大版本的依赖 4. 异常处理：是否存在吞掉异常或空 catch 分支 5. 测试缺口：核心业务分支缺少单元测试的模块 输出要求：每项给出文件路径、行号范围、问题简述、建议优先级。 不要修改任何代码，只做审计。
这个提示词的价值在于把“找问题”变成了可复现的扫描动作。你可以根据项目语言调整目录范围和债务类型。例如Java项目可以增加空指针风险、线程安全问题，前端项目可以增加无效渲染和状态管理混乱。扫描范围不应过大，建议按模块执行，否则结果会淹没在噪音中。
另外，文心快码生成的结果可能包含大量文件路径和行号，建议在提示词中明确“忽略自动生成代码、vendor 目录和第三方库”，只关注业务代码。这样能减少误报，让后续处理更聚焦。
二、用评分卡把技术债务从感觉变成数据
识别出几十个债务项后，团队容易陷入先修哪个的争论。此时可以让文心快码为每项债务输出评分卡，用统一标准计算优先级。评分维度可以包括影响范围、修复成本、复发概率和业务敏感度，每项1到5分，最终生成加权优先级分数。
更关键的是要求模型输出结构化JSON，而不是自然语言描述，这样结果可以直接进入脚本或表格做趋势分析。以下是债务评分输出示例：
{
"debt_id": "TD-023",
"location": "src/order/refund.go:87-142",
"type": "圈复杂度超标",
"scores": {
"impact": 4,
"fix_cost": 3,
"recurrence": 4,
"business_sensitivity": 5
},
"priority_score": 4.2,
"suggested_action": "拆分退款状态机，将条件分支迁移到策略模式",
"estimated_hours": 6
}
要获得稳定的JSON输出，提示词可以加入约束：“只返回JSON数组，不要添加代码块围栏，不要输出解释文字”。文心快码在多轮对话中会保持格式，但单次调用仍可能出现偏差，因此建议在CI或本地脚本中做一层JSON格式校验，解析失败时重试一次。
评分卡不仅用于排序，也能帮助团队和技术负责人沟通。当产品经理质疑为什么要花时间做重构时，一份带影响范围和业务敏感度的债务台账比“代码很乱”更有说服力。你可以每月导出一次评分结果，观察高风险债务是否减少、新引入债务是否被控制。
三、分批偿还技术债务的小步工作流
技术债务治理失败的最常见原因不是缺少工具，而是试图一次性推倒重来。大范围重构会带来回归风险，最终因测试失败或时间压力被叫停。更务实的做法是让文心快码按单个债项生成小步修复方案，每一步保持可测试、可回滚。
下面是一个针对具体函数做低风险重构的提示词示例：
请针对 src/order/refund.go 中的 refund 函数做低风险重构。约束如下： 1. 保持函数签名和返回值不变 2. 只提取条件分支为独立小函数，不改变业务逻辑 3. 每次修改后给出对应的单元测试用例 4. 不允许调整数据库访问和日志输出格式 5. 输出修改前后 diff 摘要和测试运行命令
文心快码可以根据这些约束给出重构后的代码。例如原始函数中多个条件判断集中在一起，它可以提取为状态判断函数，提升可读性但不改变行为：
func getRefundStatus(order Order) string {
if order.IsCancelled() {
return "cancelled"
}
if order.IsReturned() {
return "returned"
}
return "pending"
}
重构后可以拆成更小的函数，但一定要配合测试。每次只处理一个债务项，人工审查差异后再提交，这样即使出现问题也容易定位。文心快码不是代替你做决策，而是把重复的模式识别和代码生成工作承担下来，降低每一次偿还动作的成本。
四、把提示词沉淀为团队资产并持续度量
一次高质量的提示词如果只留在聊天窗口里，下次遇到同样问题还要重新组织语言，团队其他人也无法复用。建议把债务管理相关的提示词保存到版本库中，按用途拆分：审计、评分、重构、报告。文心快码支持将常用提示词保存为指令或团队知识库，调用时只需要指定指令名。
docs/
prompts/
debt/
audit.md
scoring.md
refactor.md
report.md
除了沉淀模板，还要持续度量治理效果。可以每个月运行一次审计提示词，把输出的JSON保存为快照，再让文心快码对比本月与上月的结果，标记新引入债务、已偿还项和长期未处理项。这样技术债务不再是一个模糊的概念，而是一组可以跟踪的数据。
提示词本身也需要版本管理。债务分类标准、评分权重、排除规则发生变化时，要像修改代码一样提交变更并说明原因。否则团队会基于不同标准做决策，数据失去可比性。文心快码提示词进阶的核心，并不是写更长的提示词，而是建立一套可执行、可验证、可持续的债务管理机制，让AI真正进入工程治理闭环。