给公司裁员省了将近150多万，结果干完活把我给裁。。

刚刷到个HR的吐槽贴，说自己辛苦干活帮公司裁员省了150万，结果活干完了反被裁了，配的标题是“狡兔死走狗烹”。

我作为程序员，看完真是唏嘘。干活拼命、优化流程、提升效率，结果到头来成了“优化对象”，这在我们这行也太常见了：写自动化脚本的最后被脚本干掉😅。网友里有的说“太实用了，理应留下”，但我觉得关键不在“干得多”，而在“你对谁有用”。价值感一旦递减，就随时可能被“释放”。

从我的角度看，职场从来不是讲情义的地方，它讲的是投入产出比。你值100万，公司只愿意出80万，那也得走人。所以说，别把自己当燃料，烧完了没人给你收骨灰。【备注:文末可领最新资料】

那天是在星巴克等人，外面下着小雨，我刚点了一杯美式，结果没等几口，就有人在群里问了个挺有意思的问题：“你们有写过那个连续递增交易的题没？就 LeetCode 那题。”我一看这个...哎哟，这题我可太熟了，当初在公司面试系统设计岗的时候，还真遇到过，虽然那时候写得不够优雅，但今天说出来，应该还是能帮上忙的。

先别急，我先给你们念一下题哈，就是——给你一个整数数组 prices，代表股票每天的价格，然后你只能选择买入或者卖出，目标就是找出最多的连续交易次数，但前提是这些交易必须是“连续递增”的，也就是你买了某一天，第二天必须涨你才能卖出，并且一次买入卖出算一笔交易。这个有点像我们平时炒股抓波段的逻辑，低买高卖，然后继续下一次循环。

那我那时候怎么写的呢...我印象挺深的，是在地铁上脑子一转就想到了，思路其实不难：

模拟交易过程就行了

你可以想象一下你每天早上打开股票App，看今天比昨天涨没涨，如果涨了，那就可以算作你“从昨天买了，今天卖出”，这样算一次交易嘛对吧。但题目要我们找“连续递增的交易段”，这就要求我们必须连续判断是不是一直涨，一直到不涨为止，然后才算一笔交易结束。

具体点讲，你得扫描这个 prices 数组，比如像 [1, 2, 3, 1, 2] 这样的数据，你从 1 涨到 3，可以交易一次，然后又从 1 涨到 2，再来一次。所以一共两次。

代码长这样：

defcount_increasing_trades(prices):
ifnot prices or len(prices) < 2:
return0

    count = 0
    start = 0

for i in range(1, len(prices)):
if prices[i] > prices[i - 1]:
continue
else:
if i - start > 1:
                count += 1
            start = i
# 检查最后一段
if len(prices) - start > 1:
        count += 1
return count

说实话，这个题...怎么说呢，不是为了考你啥骚操作的代码技巧，它其实更偏业务场景一点，有点像你写一个自动交易系统里一个“识别波段”模块。你得模拟人脑子的行为 —— 哎今天涨了，留着；哎不涨了，走人，落袋为安。

我当时其实还写了个变种，就是在某些版本中，交易的收益也要计算，不过这题不涉及收益，只是计数，那就老老实实“分段识别”就完事了。

顺便说一句，这种题你写得再漂亮，核心还是那句“边走边看”，你得明白那种“直到断掉才算一次”的定义，和一般的最大利润那题不太一样，那种可以重叠计算，而这个是非重叠的，交易是段落式的。

最后，当时我还优化了一点点，就是加个 debug 输出，把每一段打印出来，像：

# 输出每次交易的起止点
if i - start > 1:
    print(f"Trade from day {start} to day {i-1}")

这样你写完还可以验证下段落划分对不对，尤其调试的时候太香了。至于啥动态规划、栈乱七八糟的，这题根本用不上，你要是敢在这个场景下写个 O(n^2) 的做法，那就等着被挂吧。

说着说着...我那杯美式都凉了，人还没来。唉算了，不说了我再热一杯去，你们要谁要跑通这题，先把我这段代码自己跑几组样例看看，出了啥问题再来喊我。