我按一套四阶段演进框架搭系统:能跑、跑得准、跑得稳、跑得快——典型的技术视角,先把它做对,再让它可信、持久、够快。四个阶段全部走完,验证信号全绿,系统却还谈不上完成。一个系统从出生到成熟,视角要经历一次切换:技术视角负责把它做对、做稳、做快,产品视角负责让用它的人觉得有用、好用。很多人卡在中间——测试用例完成就觉得做好了,用起来却很费劲。为什么必须切:技术不直接产生价值技术本身不产生价值,价值从使用开始产生。再厉害的发动机,没有轮胎、没有驾驶舱,顾客不会为它买单——他们为「解决出行问题」买单。技术实现是万里长征第一步,发动机要变成整车,整车要被开上路,问题被解决,价值才兑现。技术视角的「完成」恰恰不知道这件事。它的完成由内部指标定义:正确性、健壮性、性能——全部能在开发环境里被验证,天然给人「做完」的确定感。但这套指标自洽地排除了一个问题:用的人怎么想。不是疏忽,是边界:它隐含一个前提,使用者能直接接触底层。作者即用户时前提成立,交互不存在;使用者从「作者」变成「用户」,哪怕就是几个月后的自己,前提失效,技术视角的验证信号里没有它。什么时候切:主要矛盾转移看主要矛盾在哪:是「系统自身的问题」,还是「使用它的人遇到的问题」。前者是数字不对、跑挂了、太慢,由技术视角解决;后者是「不知道什么状态」「不知道怎么用」「看着不方便」。当交互成本大于系统成本,就该切了。切换不是技术做完才发生,而是技术问题不再是主要矛盾就发生。切了看什么:能用、好用、在用产品视角的验证信号,不再是「它有没有错」,而是「产品走到了哪一段」。产品的生命周期是一个门槛加两条轴:能用:门槛。用户用起来,验证确实解决了一些问题。问题不成立,到此为止。好用:成本轴。用户能高效解决问题。这一轴可以跳过——自己用、内部用,能用就够了;交互成本成为真实痛点时才值得投入。在用:价值轴。产品解决的是真实存在的、有价值的问题。能用问「问题解决了吗」,好用问「省不省力」,在用问「值不值得」。三段都只能靠真实使用来验证,开发环境测不出任何一段。切了做什么:把技术包装起来产品视角最根本的动作,是把技术实现包装起来。技术无感是目标。好的产品让用户感受不到技术——用户关心的是产品是否真实、高效地解决了问题,不关心它怎么解决;业务知识是使用产品的唯一门槛。产品视角的职责,就是用用户的语言和知识,让他们无感地使用技术能力,而不是为用产品去学一堆与业务无关的技术概念。技术无感是切换之后的目标,不是起点。探索期作者即用户,直接接触底层是迭代最快的方式,过早追求无感是另一种阶段前移。具体动作从痛点出发,而不是从功能出发——设计稿里的完整形态是上限不是下限;设计资产是地图不是规格,切换时激活、按痛点裁剪;建立反馈回路——系统进入真实使用,靠使用本身暴露障碍、优化体验、证明价值。一次真实的切换我按这套框架搭了一套个人量化系统。四个阶段走完,该验证的都验证了:结果正确、算法有效、能自动运行、出问题能恢复、速度远够用——技术视角的完成无可挑剔。然后我发现自己不知道系统当前在跑什么,不知道怎么加一个新的分析逻辑,看结果要翻文件。对照三阶段坐标:能用已达成,好用还没开始,在用还远。切产品视角时,我没有做当初规划的完整界面,先解决眼前的三件事,顺手把框架的边界写进文档——它管什么、不管什么、不管的部分什么时候轮到。切换完成的标志技术视角和产品视角是同一个系统的两个面。切换完成的标志,是验证信号换了:从「它有没有错」,换成「它走到没走到在用」。