技术债
Technical Debt
中级通用技术债（Technical Debt）是为了尽快交付，或因既有实现不再适合当前需求，而留下的、会增加后续修改成本的技术问题。识别它能帮你和团队判断何时先上线、何时投入整理，例如把多处重复的计费逻辑收拢到一处。
你可能会说：「这个功能先上线没问题，但以后改起来可能很麻烦，能帮我找出这些隐患并排个处理顺序吗？」
读之前建议先了解
动手看看会员计费改规则时漏改了
1
为了赶上会员功能上线，团队把同一套折扣算法分别写进订单和续费。交付快了，但以后改规则得改两处。
要点技术债是怎么产生的，又该怎么处理？
- 1
先交付的选择可能留下代价
赶着上线时，我们可能把同一段计费规则复制到三个页面。眼下功能能用，但下次改价格就得逐处核对。省下的是这次的开发时间，增加的是以后修改和验证的工作。
- 2
需求变化也会让旧设计欠账
有些实现当初很合适，后来产品从单一套餐变成多种套餐，原来的数据结构才开始拖慢开发。所以技术债不等于当初写错了；关键是现有实现是否持续抬高后续成本。
- 3
按影响和时机决定何时偿还
你可以和 AI 一起列出受影响的功能、可能出错的地方，以及近期是否还会修改。常改又容易出错的部分，可以随下一次需求一起整理；暂时稳定的部分，先记录下来比贸然重写更合适。
容易混淆的地方
技术债和普通缺陷不一样：缺陷是当前行为不符合预期，技术债可能暂时不影响用户，却让以后改动更费力。它也不等于所有待办事项；一个尚未开发的新功能是产品待办，只有现有实现带来了后续成本，才适合从技术债的角度讨论。
什么时候用
适合用
- 准备给网站增加第二种会员套餐，发现套餐规则散落在多个页面，想先判断要不要整理再开发。
- 让 AI Agent 接手旧项目时，想识别哪些快捷实现会增加后续修改和测试的成本。
- 规划下个版本的开发时间时，需要在新功能和现有代码整理之间做取舍。
不适合用
- 用户反馈注册按钮点击后没有反应，这是当前缺陷；先定位并修复故障，比把它记成技术债更直接。
- 一个新功能还没决定要不要做，先做产品发现或排进产品待办，不需要把未开发本身叫作技术债。
- 一次性演示原型完成后就会丢弃，后续不会在这份实现上开发；重点是控制原型投入，而不是安排还债。
练一练选一个答案，看看解释
团队为了赶上线，把优惠计算逻辑分别写进网页和后台。现在要增加新的优惠规则，两处都得修改和测试。你会怎么判断下一步？
让 AI 帮你做复制给 AI Agent 直接用
请检查这次新增会员套餐涉及的现有代码，找出会增加后续修改成本的技术债。逐项说明它如何影响本次需求、继续沿用的风险、整理所需的改动范围；区分必须先处理和可以记录后处理的部分，先给方案，不要直接大规模重写。