在 AI coding不断发展的现在，我们该怎么提升
1
问题的起因是我和 +1 关于 AI 使用的边界在哪里，有过几次讨论。我的想法是，我们就去用 AI，发挥 AI 的能力上限来用；+1 的观点是，我们限制 AI 来做一部分工作，写代码还是要人来参与其中。关于这个问题，我思考了很长时间，我觉得可能回到了之前的一个问题，「在 AI coding 不断发展的现在，我们该怎么提升自己」
其实最开始我也是有点迷茫的。AI 能力越来越强，在编码上已经能覆盖掉我们 90% 的工作，随着时间发展，将来可能真的能 100% 替代掉我，那这时候我该怎么办。
我最初的想法是去找寻这个问题的答案。我是不是要遵守某种方式，让自己亲自下场去写一些业务代码，防止时间长了代码都不会写了。或者说换种方式，在 AI 写完之后我自己去看一遍代码，给所有的代码都打上注释，保证自己能了解里面的具体逻辑。又或者在 AI 写完之后自己 review 一遍代码，不需要做到逐行看完，大概了解一下逻辑，比如数据的流动、页面的交互等等。
但是后来我发现这些东西好像还是不能回答最开始的问题。说实话我在这家公司已经呆了几年了，很多业务代码我们已经形成了固定的模式，比如前端页面就用 Template 组件，后端就是固定的写接口，写 services 就可以了。那这些东西对我来说其实已经很少需要脑力劳动了，大部分时间都是体力劳动。如果只是在写业务，好像很少有碰到需要去认真思考，去动脑子想该怎么做的时候。
在这种情况下，继续坚持手写代码的收益是什么，是让我能把 let const 写得更快吗？还是能让我不会忘了已经写了 4 年的 router 和 services？好像都没有什么意义吧。
2
然后我就去想我做什么事情的时候需要动脑子，还有做什么事情的时候我会感到开心和兴奋。
首先是把业务需求翻译成代码的过程。虽然我们的开发模式已经成熟了，但每个需求落地的时候仍然需要做很多决策：数据结构怎么设计、接口怎么拆分、和现有模块怎么衔接、状态放在哪一层管理。这些问题没有标准答案，需要结合当前项目的实际情况去判断。AI 可以帮你写实现，但这些设计决策是需要我们自己来做的。
另一个是业务之外的优化和探索。
我觉得可能是做业务之外的需求和优化的时候，在这一部分中我可能需要自己去挖掘问题，想出解决方案，然后去落地。因为业务上，不管是我们自己还是业务方，我们的协作模式已经固定了。业务方可能不会写代码，但是他们知道我们大概会写出什么样的东西来。比如后台就是固定的搜索、表单、弹窗、表格和分页，活动也就是那几种常见的玩法形式。不管是外部因素还是内部因素，我们都已经形成了一种标准路径，按照这个路径来我们就可以完成工作。
但是业务之外的优化里面，我们尝试过很多中不同的东西。比如项目优化，我们讨论出来的某个端项目的路由拆分、内部前端辅助机器人、CI/CD 发布机器人，还有正在做的某个项目的体积优化方案。在做这些东西的时候，我们好像没有什么路径依赖，就是靠思考，摆脱业务需求中的标准路径，我们自己去思考出来一套方案。
3
再往后我就去想，我觉得可以把最开始的问题拆分成两个问题。
- 如果现在你要去面试，在面对 AI coding ，你怎么去找到一份工作。
- 如果现在公司要裁员，只能留下一个人，你怎么保证自己是留下来的那一个。
我觉得这两个问题就可以回答我们最开始的问题。
现在我们已经不需要再为编码能力担忧了，我们在开发的过程中更多的是去思考业务和代码结合的部分，具体的编码上已经没有什么问题了。不会担心不知道页面怎么写，也不会担心不知道接口怎么写。
我们做的那些差异化的东西，比如内部前端辅助机器人，我觉得这个东西是一个很有代表性的东西，这是真正我们自己做出来的，从问题中生长出来的一个解决方案。这个东西不会出现在需求文档里面，业务方不会说我们想要一个 IM 机器人，帮我们做什么工作。但是这个东西确实是我们发现问题，根据问题思考怎么解决更方便，最终产出的。事实证明这个东西确实有用。
再比如 +1 做的监控系统，这个东西也不会出现在需求文档里，就算有需求可能也是用户反馈页面崩溃或者种种问题，从这些问题里，觉得需要一个监控系统来辅助定位问题。
前面的两个问题我觉得代表了两个方面。
在代码能力都差不多的时候，你怎么保证你比另一个候选人更强。
我的想法是这样的，我们现在工作经验都已经超过 3 年了。3 年其实就是一个分水岭，在这之后你再去面试的时候已经很少有公司会关心你会不会区分 var let const 了。再加上现在 AI 的发展，很多公司已经开始了 AI coding，那人的 coding 能力比重可能更少了。更多的时候可能是关心你的更深层次的东西，比如你面对一个困难的时候的解决方案，你有没有关注新知识，你是怎么获取新知识的。
个人的上下文有多少。这里指的是一些代码之外的业务能力，比如为什么历史代码要这么写、当初我们是怎么约定的、这个东西怎么用的。这些东西可能一个人掌握不了，但是至少你要知道应该问谁，应该去哪里查。
4
再回到 AI coding 上。
我觉得 AI 是一个工具，就像 vscode 一样。我最开始写代码是用 VC++ 6.0 写 C 语言的，那个工具里没有方法提示，没有注释，没有跳转，只有报错标红，然后编译之后会提示你编译不通过，只能自己一行一行看代码。现在我们用的编辑器，已经可以做到智能提示，你写两个字母就自动提示补充的方法。但是这个过程中我们好像并没有焦虑，我们不会焦虑说忘记了某个方法名是怎么写的，忘了某个方法的传参是什么，就算我们真的忘了上网一搜就有结果了。
AI coding 是大势所趋吗？说实话我也不知道，我不知道明天还能不能用上 AI，也不知道将来的 AI 会不会更好用，所以我并没有直接押宝 AI。如果我全部梭哈到 AI 上，那我现在就不会去思考这些问题，我的精力应该放到怎么调优 AI 使用上。
但是我觉得 AI 是一个工具，一个新工具，你怎么从 0 到 1 用好这个新工具的过程是重要的。其实就是你接触到一个新项目或者一个新包的时候的一个探索过程，这个东西是很个人的，而且我觉得会涉及到个人思想上的一些东西。
就比如说，我们都在用 AI，为什么你用这个 AI 产出的代码就是 80% 可用的，我用的 AI 产出的就是垃圾代码，基本不可用；或者为什么你用 AI 效率更高，我就得一句一句教 AI。
那么问题来了，同样都是在用 AI，为什么我们使用的结果就不一样呢？
5
我觉得现在我可以回答关于 AI 介入程度的问题了。
一个基准原则是，不管是不是 AI 写出来的代码，在自己负责的工作范围内，我们是不是能对这些东西负责。
有一个关于 AI 的笑话就是说，AI 取代不了会计，因为他不能替会计坐牢。我觉得这放到我们的工作里面也是合适的，虽然出了问题我们不至于要坐牢，但是问题确实是一个问题。
我不打算推荐具体的方式，我觉得这个东西因人而异。
但是团队协作确实需要一个基准线。这个基准线不是规定 AI 能做什么不能做什么，而是一个最低要求。就像我们引入一个新框架或新工具，最低要求是你要会正确使用它，至于它还有哪些额外的能力，就看个人的主观能动性了。比如 lodash，我们项目里有这个工具，它能做很多事情，但是不是每次写代码都会想到用它，这就因人而异了。AI 也是一样，怎么用、用多少，可以不统一，但底线要一致。
这个底线是什么？我觉得是：我们至少要知道自己做的需求是什么，如果出现问题要怎么排查，如果真的出现了线上紧急 bug，你是不是还能像没有 AI 一样快速地定位问题并解决问题。