技术债怎么管理提示词：技术债盘点清单、影响评分与偿还排期（说服产品经理给排期）
团队技术债越积越多、却总排不上期，需要系统盘点并向管理者或产品经理争取时间时用：把零散的吐槽整理成一份有分类、有影响评估、有成本估算的技术债清单，按投入产出排序，并写成业务方看得懂的说明。
通用大模型 对话模型通用
你是一名技术负责人，擅长把工程问题翻译成业务语言。请帮我整理团队的技术债并制定偿还计划。 材料： - 系统简介：[系统用途与规模] - 团队成员提到的问题（吐槽、待办、代码里的待处理注释都可以，原样粘贴）： [粘贴问题列表] - 近期的事故或效率问题：[如上月两次因为同一模块出事故] - 每个迭代可以投入的时间：[如每两周 2 人天，或比例 20%] - 读者：[如产品负责人、技术总监] 请完成： 1. 归类整理：把材料中的问题合并去重，分类为：代码质量、架构设计、测试缺失、依赖与版本过旧、基础设施与部署、文档与知识缺失、安全隐患。 2. 逐条评估，输出清单表：编号 | 技术债 | 分类 | 现在造成的影响（尽量量化：事故次数、每次需求多花的时间、上线耗时）| 不处理的风险（会怎样恶化）| 偿还成本（人天，粗估）| 优先级。 3. 优先级规则：影响大且成本低的优先；有安全风险或依赖即将停止维护的单独标出，不受排序约束；「看着难受但影响很小」的放到最后，并明确可以暂不处理。 4. 偿还计划：根据每个迭代可投入的时间，排出接下来 3 个迭代的计划；说明哪些可以和业务需求一起做（「顺手修」），哪些需要单独排期。 5. 业务版说明：写一段给 [读者] 看的 300 字左右说明，不用技术术语，讲清楚「如果不处理，会对上线速度、稳定性、成本产生什么影响」，以及「投入多少时间，能换来什么」。 6. 防止新增：建议 2 到 3 条团队约定，减少新的技术债（例如新代码必须有测试、依赖每季度升级一次）。 材料中没有的数字不要编造，在影响一列写「待估」。
高亮处换成你自己的内容：[系统用途与规模]、[粘贴问题列表]、[如上月两次因为同一模块出事故]、[如每两周 2 人天，或比例 20%]、[如产品负责人、技术总监]、[读者]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[团队成员提到的问题] 不用整理，越原始越好。代码里的待处理注释可以用搜索批量导出。[近期的事故或效率问题] 是说服业务方的最好证据，有具体事件就写上。
常见坑：
- 清单里全是「代码写得丑」这种主观问题，业务方看不出为什么要花时间。要把每一条和可观察的影响挂钩：多花了多少时间、出过几次事故。
- 想一次性把技术债全还清，申请一整个月的「重构期」，几乎不会被批准。持续地每个迭代留出固定比例，更现实。
- 依赖库、框架、运行时的版本停止维护是有明确期限的风险，不能和普通技术债一起慢慢排。
追问技巧：追问「针对第一优先级的技术债，写一份一页的立项说明：问题、方案、成本、收益、风险」，可以直接拿去评审。
示例输出
示例，仅供参考（清单节选）
| 编号 | 技术债 | 分类 | 现在的影响 | 不处理的风险 | 成本 | 优先级 |
|---|---|---|---|---|---|---|
| TD-01 | 订单模块无自动化测试 | 测试缺失 | 近两个月 2 次事故源于此模块；每次发布手工回归半天 | 改动越来越不敢做 | 8 人天 | 高 |
| TD-02 | 运行时版本即将停止安全更新 | 依赖过旧 | 暂无 | 停止更新后的漏洞无法修补 | 5 人天 | 单独标出 |
| TD-03 | 工具类命名混乱 | 代码质量 | 待估，影响较小 | 低 | 2 人天 | 低（暂不处理） |
业务版说明（节选）：订单模块目前没有自动检查手段，每次上线都要人工花半天回归，近两个月仍有两次问题漏到了线上。如果接下来两个迭代各投入 4 人天补齐关键流程的自动化测试，预计每次发布可节省约半天，并降低同类事故再次发生的概率。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～