一、信号一：代码和结构还能不能被新人看懂
一个项目能不能继续修，首先看代码是否还能被接手。
这里说的不是代码写得漂不漂亮，而是几个基本问题：项目能不能正常启动，依赖是否清楚，数据库结构是否能对应业务页面，接口是否有基本命名规则，关键流程有没有明显断层。
如果新开发人员花几天时间以后，能大致看懂登录、订单、支付、后台、权限这些核心模块在哪里，那项目还有抢救空间。
但如果项目连启动环境都搭不起来，代码散在多个压缩包里，数据库表名和页面完全对不上，关键逻辑靠猜，原开发人员也联系不上，那继续修的风险就会很高。
很多老板不愿意重做，是因为觉得“代码都写了这么多，扔掉太可惜”。但如果这些代码没有可维护性，它们不是资产，而是负担。
二、信号二：数据还能不能保住
烂尾项目里最值得保护的，往往不是代码，而是数据。
如果系统已经上线过，里面可能有客户、订单、会员、课程、库存、售后、财务记录。这些数据如果真实有效，就应该优先评估能否导出、清洗和迁移。
有时候代码可以重做，但数据不能丢。
老板要问几个问题：
- 数据库还在不在？
- 关键表能不能解释清楚？
- 订单、客户、支付、售后这些核心数据是否完整？
- 数据里有没有重复、脏数据或缺字段？
- 如果重做系统，数据是否能迁移到新结构里？
如果数据清楚、结构还能理解，即使系统本身很烂，也有重构价值。反过来，如果数据本来就是乱的，继续在旧系统上修，可能只是把混乱固化得更深。
三、信号三：业务流程有没有真正跑通过
有些项目看起来烂尾，其实只是最后一段没有打磨好。比如页面粗糙、权限不细、统计报表没做完、消息提醒不稳定，但核心流程已经能跑：客户能下单，后台能处理，员工能履约，老板能看结果。
这种项目可以优先考虑修。
但如果核心业务流程从来没有跑通过，就要谨慎。比如用户端能提交订单，但后台没有接单；后台能看到订单，但支付和订单状态对不上；员工能处理服务，但售后和退款没有流程；数据统计只是摆设，老板无法判断业务结果。
软件项目的核心不是页面数量，而是流程闭环。
如果闭环已经存在，修补比较有意义。如果闭环不存在，继续在旧基础上加功能，往往越做越乱。
四、什么情况下适合继续修
适合继续修的项目，通常有几个特征。
项目能启动，核心代码结构还能看懂；数据库有价值，核心数据能保住；业务流程已经部分跑通；老板现在最急的是修复 bug、补齐权限、优化体验、整理部署，而不是重新改变业务方向。
这种情况下，可以先做一个“抢救清单”：
第一阶段，只修能影响上线和使用的核心问题；第二阶段，补权限、日志、异常处理和数据统计；第三阶段，再考虑体验优化和功能扩展。
不要一接手就大改。烂尾项目最怕新的团队还没看清楚，就开始重构全部代码。这样很容易变成第二次烂尾。
五、什么情况下应该考虑重做
如果出现下面情况，重做反而更省钱。
项目无法稳定启动，核心模块没人能解释；代码里充满临时写法，改一个地方坏三个地方；数据库结构和业务严重不匹配；核心流程从来没有跑通；原来的技术选型已经明显不适合后续维护；安全、支付、权限等关键部分风险很高。
这种时候继续修，不一定是在省钱，可能是在给旧坑继续投钱。
重做也不等于从零浪费。可以保留旧系统里的有效资料：需求记录、页面截图、数据表、业务流程、用户反馈、踩过的坑。这些都能帮助新项目少走弯路。
真正要扔掉的，是不可维护的代码和错误的流程假设。
六、老板最该避免的是边修边加新需求
很多烂尾项目二次接手失败，原因不是没人能修，而是老板一边修一边加新需求。
“既然都接手了，顺便把会员也加上。”“既然要改后台，顺便做个数据大屏。”“既然要上线，顺便接 AI 客服。”
这些想法都能理解，但在项目抢救阶段非常危险。
烂尾项目第一目标不是变得更强，而是先恢复可控。先让系统能启动、能运行、能备份、能定位问题、能完成核心流程。等基础稳定以后，再谈扩展。
深度补充：老板真正需要的不是观点，而是一套可执行判断框架
上面的内容解决的是方向问题，但真实项目里，老板还需要一套能拿去开会、询价、筛供应商和验收的框架。否则文章读完觉得有道理，回到项目现场还是会被报价、功能表和各种承诺带着走。
这一部分不讲空泛概念，只讲可以直接落地的判断方法。你可以把它当成项目启动前的内部评审表，也可以当成和开发方沟通前的准备清单。
一、先把问题放回真实经营场景
场景 1：旧项目能打开，但没人敢改
这个场景最容易被误判的地方，是老板把它当成一个“要不要开发”的技术问题，其实它首先是一个经营问题。能打开不代表可维护，很多旧系统没有文档、没有日志、没有清晰结构。 如果这个问题没有被讲清楚，开发团队只能按表面功能报价，最后做出来的系统看起来完整，却不一定能改善业务。
更稳的做法，是先把场景拆成“触发点、当前处理方式、损失来源、系统应该接住的动作”四部分。触发点说明问题什么时候发生，当前处理方式说明现在靠谁在补，损失来源说明为什么值得投入，系统动作说明第一版到底要解决哪一步。先做只读审计，判断启动、代码、数据库和核心流程。 这样拆完以后，老板和开发方讨论的就不再是空泛功能，而是一个可以评估投入产出的闭环。
场景 2：系统已经有真实数据
这个场景最容易被误判的地方，是老板把它当成一个“要不要开发”的技术问题，其实它首先是一个经营问题。一味推倒重做可能丢掉客户、订单、交易和运营记录。 如果这个问题没有被讲清楚，开发团队只能按表面功能报价，最后做出来的系统看起来完整，却不一定能改善业务。
更稳的做法，是先把场景拆成“触发点、当前处理方式、损失来源、系统应该接住的动作”四部分。触发点说明问题什么时候发生，当前处理方式说明现在靠谁在补，损失来源说明为什么值得投入，系统动作说明第一版到底要解决哪一步。先评估数据价值和迁移可能，再决定代码是否保留。 这样拆完以后，老板和开发方讨论的就不再是空泛功能，而是一个可以评估投入产出的闭环。
场景 3：老板已经失去耐心
这个场景最容易被误判的地方，是老板把它当成一个“要不要开发”的技术问题，其实它首先是一个经营问题。情绪上想马上换人继续开发，但新团队如果不审计，只会接着踩坑。 如果这个问题没有被讲清楚，开发团队只能按表面功能报价，最后做出来的系统看起来完整，却不一定能改善业务。
更稳的做法，是先把场景拆成“触发点、当前处理方式、损失来源、系统应该接住的动作”四部分。触发点说明问题什么时候发生，当前处理方式说明现在靠谁在补，损失来源说明为什么值得投入，系统动作说明第一版到底要解决哪一步。先用一周内的审计报告定修复、重构或重做路径。 这样拆完以后，老板和开发方讨论的就不再是空泛功能，而是一个可以评估投入产出的闭环。
场景 4：新需求不断加进烂尾项目
这个场景最容易被误判的地方，是老板把它当成一个“要不要开发”的技术问题，其实它首先是一个经营问题。旧问题没解决就加新功能，会形成第二次烂尾。 如果这个问题没有被讲清楚，开发团队只能按表面功能报价，最后做出来的系统看起来完整，却不一定能改善业务。
更稳的做法，是先把场景拆成“触发点、当前处理方式、损失来源、系统应该接住的动作”四部分。触发点说明问题什么时候发生，当前处理方式说明现在靠谁在补，损失来源说明为什么值得投入，系统动作说明第一版到底要解决哪一步。抢救阶段只处理启动、核心闭环、数据、安全和上线问题。 这样拆完以后，老板和开发方讨论的就不再是空泛功能，而是一个可以评估投入产出的闭环。
二、用这几条标准先筛一遍，别急着进入报价
1. 代码是否能启动。
要问的问题是：新环境能否按文档启动前后端和数据库？ 观察重点不是“能不能做”，而是“做完以后能不能被验证”。不合格信号通常是：依赖缺失、配置混乱、没人知道怎么跑。合格信号应该是：能复现本地或测试环境，并定位主要模块。如果这个信号成立，项目就可以进入下一轮范围评估；如果不成立，先补业务信息，比急着开发更重要。
2. 数据是否有价值。
要问的问题是：客户、订单、支付、售后等数据是否完整？ 观察重点不是“能不能做”，而是“做完以后能不能被验证”。不合格信号通常是：数据结构混乱且无法解释。合格信号应该是：核心数据可导出、可清洗、可迁移。如果这个信号成立，项目就可以进入下一轮范围评估；如果不成立，先补业务信息，比急着开发更重要。
3. 流程是否跑通过。
要问的问题是：用户端到后台到结果是否有闭环？ 观察重点不是“能不能做”，而是“做完以后能不能被验证”。不合格信号通常是：每一步都靠人工补。合格信号应该是：至少一条主流程可用，只是体验或稳定性差。如果这个信号成立，项目就可以进入下一轮范围评估；如果不成立，先补业务信息，比急着开发更重要。
4. 风险是否可控。
要问的问题是：支付、权限、安全和数据一致性有没有明显隐患？ 观察重点不是“能不能做”，而是“做完以后能不能被验证”。不合格信号通常是：关键风险无人敢碰。合格信号应该是：能列出风险等级和修复优先级。如果这个信号成立，项目就可以进入下一轮范围评估；如果不成立，先补业务信息，比急着开发更重要。
5. 重做是否能保留资产。
要问的问题是：旧项目有哪些内容可复用？ 观察重点不是“能不能做”，而是“做完以后能不能被验证”。不合格信号通常是：只有坏代码，没有有效数据和流程资料。合格信号应该是：数据、截图、需求和历史反馈能转化为新项目输入。如果这个信号成立，项目就可以进入下一轮范围评估；如果不成立，先补业务信息，比急着开发更重要。
三、和开发方沟通时，要把这些问题问到可执行
问题 1：现在最大的阻塞是不能启动、不能上线，还是不能维护？
这个问题要追到可执行层面。只回答“需要”“可以”“差不多”都不够，最好能落到页面、角色、数据、状态或验收证据上。老板可以继续追问：三种问题对应完全不同的处理方式。 只有追到这个程度，报价、周期和风险才不会停留在猜测。
问题 2：旧系统里哪些数据绝对不能丢？
这个问题要追到可执行层面。只回答“需要”“可以”“差不多”都不够，最好能落到页面、角色、数据、状态或验收证据上。老板可以继续追问：请列客户、订单、支付、售后、文件和操作记录。 只有追到这个程度，报价、周期和风险才不会停留在猜测。
问题 3：原开发方交付了哪些材料？
这个问题要追到可执行层面。只回答“需要”“可以”“差不多”都不够，最好能落到页面、角色、数据、状态或验收证据上。老板可以继续追问：源码、数据库、部署文档、服务器账号、第三方接口账号是否齐全？ 只有追到这个程度，报价、周期和风险才不会停留在猜测。
问题 4：老板最急着恢复哪条业务流程？
这个问题要追到可执行层面。只回答“需要”“可以”“差不多”都不够，最好能落到页面、角色、数据、状态或验收证据上。老板可以继续追问：先恢复收款、接单、查询，还是后台管理？ 只有追到这个程度，报价、周期和风险才不会停留在猜测。
问题 5：如果重做，旧系统要并行多久？
这个问题要追到可执行层面。只回答“需要”“可以”“差不多”都不够，最好能落到页面、角色、数据、状态或验收证据上。老板可以继续追问：迁移窗口和停机风险必须提前规划。 只有追到这个程度，报价、周期和风险才不会停留在猜测。
四、预算和周期不要一口吃完，按阶段拆才稳
第 1 阶段：只读审计。
这一阶段的目标不是做得越多越好，而是把 不改代码先看清现状 做扎实。建议交付物包括：启动报告、代码结构、数据库说明、风险清单。如果这一阶段没有明确结果，就不要急着进入下一阶段，否则后面的开发只是在不确定基础上继续加码。
第 2 阶段：抢救决策。
这一阶段的目标不是做得越多越好，而是把 确定修、局部重构还是重做 做扎实。建议交付物包括：三种方案对比、预算区间、风险和周期。如果这一阶段没有明确结果，就不要急着进入下一阶段，否则后面的开发只是在不确定基础上继续加码。
第 3 阶段：最小修复。
这一阶段的目标不是做得越多越好，而是把 恢复核心流程和数据安全 做扎实。建议交付物包括：启动修复、关键 bug、备份、权限和日志补齐。如果这一阶段没有明确结果，就不要急着进入下一阶段，否则后面的开发只是在不确定基础上继续加码。
第 4 阶段：迁移或重构。
这一阶段的目标不是做得越多越好，而是把 把旧项目从不可控变成可维护 做扎实。建议交付物包括：新结构、数据迁移、灰度切换、回滚方案。如果这一阶段没有明确结果，就不要急着进入下一阶段，否则后面的开发只是在不确定基础上继续加码。
五、这些坑最容易让项目后期失控
风险 1：直接接着写。
常见表现是：新团队不审计就开始改功能。它真正危险的地方在于，前期看起来只是小问题，后期会影响 越修越乱。更稳的替代做法是：先审计，再定修复边界。
风险 2：舍不得旧代码。
常见表现是：把沉没成本当资产。它真正危险的地方在于，前期看起来只是小问题，后期会影响 继续投入不可维护系统。更稳的替代做法是：用可启动、可理解、可测试判断代码价值。
风险 3：忽略数据迁移。
常见表现是：只讨论新系统功能，不讨论旧数据。它真正危险的地方在于，前期看起来只是小问题，后期会影响 上线切换失败。更稳的替代做法是：先做数据盘点和迁移脚本验证。
风险 4：抢救时加新功能。
常见表现是：边修边加会员、AI、报表。它真正危险的地方在于，前期看起来只是小问题，后期会影响 第二次烂尾。更稳的替代做法是：抢救阶段只做恢复和风险控制。
六、验收时不要只看页面，要看证据
**1. 审计证据：**有启动结果、模块清单、数据库说明和风险等级。
**2. 修复证据：**核心流程能跑通，且问题可定位。
**3. 数据证据：**关键数据已备份、可导出、可迁移。
**4. 决策证据：**修、重构、重做各自成本和风险被列清。
七、老板可以直接复制这份内部评审清单
- 源码是否完整？
- 项目能否启动？
- 数据库是否可解释？
- 核心流程是否跑通过？
- 关键数据能否迁移？
- 支付和权限是否有风险？
- 是否需要并行切换？
- 抢救阶段禁止新增哪些功能？
这份清单的意义，不是让老板变成产品经理或技术经理，而是让项目一开始就有共同语言。老板负责讲清业务目标和约束，开发方负责把目标拆成方案、系统和交付节奏。两边都把边界说清楚，项目才有机会稳。
进一步落地：从内部评审到项目推进，建议准备这 5 份材料
如果这篇文章只停留在观点层面，对老板帮助仍然有限。真正进入项目时，最好把 烂尾项目抢救 拆成 5 份材料。它们不需要写得像大公司文档那么厚，但必须足够清楚，能让老板、业务负责人、开发方和后期维护人员对同一件事有相同理解。
1. 内部立项判断表
这张表主要给老板和核心负责人看，目标是确认项目到底为什么做。表里至少要有四列：当前问题、造成的成本、第一版目标、暂不解决的内容。
以 烂尾项目抢救 为例，当前问题不能只写“效率低”“体验差”“想升级”，而要写成可观察现象：谁每天在补，哪一步最容易错，哪类客户最容易流失，哪类数据最难统计。造成的成本也不要只写“大概很麻烦”，要尽量落到时间、人数、返工、投诉、漏单、重复沟通或管理盲区。
第一版目标要和 修复、重构或重做决策 对齐。它不是愿望清单，而是一个可验证结果。比如第一版只验证一个流程是否能跑通，只验证一类用户是否愿意使用，只验证一个岗位是否能减少重复工作。暂不解决的内容同样重要，因为它能防止项目一开始就被过多想法拖散。
如果这张表写不出来，说明项目还没有准备好进入开发报价。此时继续问价格，只会得到一个不可靠的估算。
2. 业务流程和责任人表
软件项目不是只有页面和按钮，它背后一定有业务责任。流程表要写清楚：谁发起、谁处理、谁确认、谁复盘、谁维护。
这里最容易被忽略的是“责任人”和“异常处理人”。很多项目设计正常流程时看起来很顺，一遇到取消、退回、补资料、支付失败、客户投诉、人员调整、数据不一致，就立刻回到微信和口头沟通。系统一旦接不住异常，数据就会断，老板后面看到的统计也不可信。
围绕 源码、数据、流程和上线风险，流程表至少要回答这些问题：入口在哪里，第一步由谁触发，系统自动做什么，人工确认什么，状态怎么变化，异常进入哪里，最后结果如何被记录。每一个状态最好都有负责人，而不是写成“相关人员处理”。
这张表越清楚，开发方越容易判断工作量；这张表越模糊，报价差异就越大，后期返工也越多。
3. 供应商沟通问题表
老板找开发方沟通时，不要只问“多少钱”和“多久能做完”。这两个问题当然要问，但应该放在范围和风险之后。
建议至少准备一组固定问题：你怎么理解我们的业务目标？第一版你建议先做哪些？哪些功能你建议后置？这个项目最大的风险是什么？报价里包含哪些看不见的工作？上线后谁负责维护？如果需求变化，费用和周期怎么调整？
好的开发方不会只顺着客户说“都能做”。他应该能指出 未审计就继续投入 这类风险，并解释为什么某些功能应该晚一点做，为什么某些基础工作不能省，为什么某些承诺必须由人工确认或合同写清。
如果一个供应商只愿意给功能清单和总价，不愿意讨论风险、阶段、验收和维护，那它也许适合做很简单的小活，但不适合承担有业务结果要求的项目。
4. 第一版里程碑表
里程碑不是排期表的装饰，而是控制项目风险的工具。每个里程碑都应该对应一个可以检查的成果。
比较稳的拆法是：需求确认、原型确认、核心流程开发、测试环境验收、正式上线、试运行复盘。每个阶段都要写清输入、输出和验收方式。比如原型确认阶段，不只是看页面好不好看，而是看用户路径、后台处理、权限和数据是否合理。测试环境验收阶段，不只是点一遍主流程，还要看异常、权限、日志、导出和提醒。
围绕 烂尾项目抢救，第一版最怕“功能都做了一点，但没有一个闭环跑通”。所以里程碑要以闭环为中心，而不是以页面数量为中心。宁可少做几个模块，也要让一个核心流程从入口、处理、结果到复盘完整跑起来。
5. 上线后运营复盘表
很多老板以为项目验收就是终点，其实上线后的前 30 天才是真正的验证期。
运营复盘表要记录 可启动性、可维护性、数据可迁移性和核心流程可用性。这些指标不一定一开始就很漂亮，但它们能告诉你项目是否在产生真实价值。比如用户有没有从入口进入，员工有没有按流程处理，异常有没有在线上解决，客户反馈有没有被记录，哪些功能没人用，哪些流程仍然需要人工补救。
复盘表不要只给开发方看，也要给内部负责人看。因为很多问题不是代码问题，而是业务规则、岗位责任、培训方式和运营习惯的问题。开发方可以修系统，但不能替公司长期运营系统。
一个更实际的推进顺序
第一周，不急着定最终报价，先把问题、流程和第一版范围写清楚。
第二周，让开发方基于一页需求和流程表做澄清，输出风险清单和阶段建议。
第三周，确认原型和报价，把必须做、后置做、不做写进范围。
开发阶段，按里程碑验收，不要等到全部做完才第一次认真看。
上线后，至少保留两到四周试运行，记录真实使用问题，再决定第二阶段投入。
这个顺序看起来慢一点，但它能避免项目在一开始就走偏。对老板来说，真正节省成本的不是压低报价，而是减少错误方向、减少返工、减少上线后没人负责的概率。
现场追问：老板开项目会时，可以直接这样问
很多软件项目不是缺观点，而是缺追问。老板只要多问几句，很多隐藏风险就会提前暴露。下面这些问题适合在立项会、报价会、原型确认会和上线复盘会上反复使用。
追问 1：旧代码到底值不值得保留？
这个问题不要只听一句结论，最好要求团队拿出依据。依据可以是用户路径、当前数据、员工访谈、订单样本、历史投诉、财务记录、后台截图或竞品拆解。老板真正要判断的不是回答听起来是否顺耳，而是这个回答能不能指导下一步动作。
如果回答停留在“应该可以”“大概没问题”“后面再说”，就说明风险还没有被消化。更稳的回答应该能讲清：为什么现在要这样做，做完看什么结果，失败以后怎么回退，哪些内容暂时不碰，谁对结果负责。
追问 2：数据迁移是不是比重做更重要？
这个问题不要只听一句结论，最好要求团队拿出依据。依据可以是用户路径、当前数据、员工访谈、订单样本、历史投诉、财务记录、后台截图或竞品拆解。老板真正要判断的不是回答听起来是否顺耳，而是这个回答能不能指导下一步动作。
如果回答停留在“应该可以”“大概没问题”“后面再说”，就说明风险还没有被消化。更稳的回答应该能讲清：为什么现在要这样做，做完看什么结果，失败以后怎么回退，哪些内容暂时不碰，谁对结果负责。
追问 3：抢救阶段能不能加新功能？
这个问题不要只听一句结论，最好要求团队拿出依据。依据可以是用户路径、当前数据、员工访谈、订单样本、历史投诉、财务记录、后台截图或竞品拆解。老板真正要判断的不是回答听起来是否顺耳，而是这个回答能不能指导下一步动作。
如果回答停留在“应该可以”“大概没问题”“后面再说”，就说明风险还没有被消化。更稳的回答应该能讲清：为什么现在要这样做，做完看什么结果，失败以后怎么回退，哪些内容暂时不碰，谁对结果负责。
追问 4：换团队前要拿到哪些资料？
这个问题不要只听一句结论，最好要求团队拿出依据。依据可以是用户路径、当前数据、员工访谈、订单样本、历史投诉、财务记录、后台截图或竞品拆解。老板真正要判断的不是回答听起来是否顺耳，而是这个回答能不能指导下一步动作。
如果回答停留在“应该可以”“大概没问题”“后面再说”，就说明风险还没有被消化。更稳的回答应该能讲清：为什么现在要这样做，做完看什么结果，失败以后怎么回退，哪些内容暂时不碰，谁对结果负责。
追问 5：只读审计应该产出什么？
这个问题不要只听一句结论，最好要求团队拿出依据。依据可以是用户路径、当前数据、员工访谈、订单样本、历史投诉、财务记录、后台截图或竞品拆解。老板真正要判断的不是回答听起来是否顺耳，而是这个回答能不能指导下一步动作。
如果回答停留在“应该可以”“大概没问题”“后面再说”，就说明风险还没有被消化。更稳的回答应该能讲清：为什么现在要这样做，做完看什么结果，失败以后怎么回退，哪些内容暂时不碰，谁对结果负责。
追问 6：什么时候必须推倒重做？
这个问题不要只听一句结论，最好要求团队拿出依据。依据可以是用户路径、当前数据、员工访谈、订单样本、历史投诉、财务记录、后台截图或竞品拆解。老板真正要判断的不是回答听起来是否顺耳，而是这个回答能不能指导下一步动作。
如果回答停留在“应该可以”“大概没问题”“后面再说”，就说明风险还没有被消化。更稳的回答应该能讲清：为什么现在要这样做，做完看什么结果，失败以后怎么回退，哪些内容暂时不碰，谁对结果负责。
会议纪要模板：每次沟通后都要留下这 6 类记录
第一，今天确认了什么。不要只写“沟通需求”，要写清楚确认了哪些功能、哪些范围、哪些角色、哪些状态。
第二，今天没有确认什么。未确认事项比已确认事项更容易造成后期争议，必须单独列出来，比如第三方接口、数据迁移、支付规则、售后范围、上线方式。
第三，今天新增了什么风险。每次沟通都可能暴露新风险，风险不一定马上解决，但必须有人负责跟进。
第四，哪些内容进入第一版，哪些后置。只要这个边界不持续更新，第一版就会越来越大。
第五，下一步谁负责。每个待办后面都应该有责任人和截止时间，不能只写“双方继续确认”。
第六，这次沟通是否影响报价和周期。只要影响，就要及时确认，不要等项目快结束时再一起算账。
这份纪要不需要复杂，但它能保护项目。软件开发里的很多问题，不是因为没人沟通，而是沟通完没有留下可以执行、可以追踪、可以复盘的记录。
决策边界：什么时候该继续，什么时候该先停一下
做 烂尾项目抢救，老板最需要的是边界感。边界感不是保守，而是知道项目什么时候应该继续推进，什么时候应该停下来补基础。很多项目后期变贵、变慢、变乱，不是因为一开始不努力，而是因为一开始没有设置止损条件。
应该先停下来的信号
如果出现 代码不可启动、数据不可解释、核心流程从未跑通、关键账号资料缺失，就不建议立刻进入完整开发。这个时候继续推进，往往只是把不确定性包装成项目计划。看起来有报价、有周期、有功能表，实际上每一项都可能在开发过程中被推翻。
停下来不等于项目失败。恰恰相反，能在早期停下来补信息，是老板控制风险的能力。可以先做一轮小调研、流程梳理、资料整理、原型验证或只读审计。等关键问题变清楚，再进入开发，整体成本通常更低。
可以继续推进的信号
如果已经具备 数据有价值、流程有基础、风险能分级，且抢救范围能被严格限制，就可以进入下一步评估。这里的“继续”也不是直接把所有功能做完，而是进入更明确的方案阶段：写清第一版范围，确认里程碑，拆出交付物，定好验收方式，再安排开发。
特别要注意，继续推进的依据必须是证据，而不是信心。证据可以是用户访谈、订单样本、员工操作记录、后台数据、现有系统截图、历史投诉、财务损耗或试运行结果。没有证据的信心，很容易变成后期返工。
老板最终要守住的原则
先判断旧资产价值，再决定修还是重做。只要这个原则不偏，项目就算过程中调整，也不会偏离业务目标。
如果讨论越来越集中在“功能再加一个、页面再做一个、AI 再接一个、端再多一个”，就要回到最初的问题：这件事到底在改善哪一个业务结果？谁会每天使用？做完怎么验收？上线后谁维护？
能回答这些问题，项目才值得继续。回答不了，先停下来把问题补清楚，反而是更成熟的决策。
