软件项目接管与整改
适合：原开发者离开、外包项目失控，或者系统已经越来越难维护。
从现有代码和生产环境出发，重新建立可维护的开发、测试和部署流程，再分阶段解决技术债、稳定性和架构问题。
这些情况通常值得先做一次检查
本地运行正常，上线后频繁出错
用户注册或登录偶尔失败
支付流程不稳定
数据库没人敢改
没有 staging
不知道生产数据库有没有可靠备份
API Key 和密码散落在代码或聊天记录中
原开发者已经离开
AI 写了大量代码，但没人能判断风险
新功能越来越难加
检查范围
- 代码结构
- 数据库与数据一致性
- 认证与权限
- 环境变量与密钥管理
- 部署流程
- 生产配置
- 备份与恢复
- 第三方服务
- 测试覆盖
- 日志与错误处理
- 项目可维护性
最终会得到什么？
- 当前项目风险摘要
- P0 / P1 / P2 问题优先级
- 建议整改方案
- 哪些问题需要立即处理
- 哪些问题可以暂缓
- 哪些部分值得重构
- 哪些部分可以继续保留
适合哪些团队
- 已经做出 MVP，但准备进入正式上线阶段的创业团队
- 想确认 AI 辅助开发结果是否可靠的小型产品团队
- 准备接手旧项目、但还不知道风险范围的负责人
- 希望在继续投入开发前先了解真实技术状况的业务团队
合作通常怎么推进？
01 · 了解现状
先确认业务目标、当前系统状态、主要风险和现阶段最影响业务的问题。
02 · 明确范围
把需要马上处理的部分和可以后续安排的部分分开，避免目标失焦。
03 · 分阶段执行
优先完成最关键的检查、整改或开发工作，让每个阶段都能验证结果。
04 · 交付与下一步
整理当前结论、交付内容和建议的下一步，让项目继续推进而不是重新混乱。
关于软件健康检查
不会。输出重点是按优先级整理的问题和整改方向，帮助团队判断应该先修什么、哪些可以后面处理，而不是只给一份模糊结论。
可以。很多项目会先做健康检查，再根据结果进入阶段性整改、接管或持续支持，这样决策会更稳。
通常可以。只要能获得必要的代码、环境或部署信息，就可以先从现状出发识别主要风险。