最近 AI 闹的沸沸扬扬，已经有很多公司开始裁员了。
作为软件从业人员，受影响不可谓不大。
但我们公司暂时还是安全的，因为 AI 并没有颠覆现有业务。
我相信有业务，才有软件开发需要。
正如有市场，所推出的产品才有价值，才能卖得出去。
有价值，开发者才有饭吃。
因此，AI 并不一定意味着降本，也可以用来增效。
裁员的公司，要么业务跟不上了，要么暂不需要效率那么高。
但是行业到底会如何发展，谁也说不准，
也不是我们普通程序员可以左右的，
本文只谈一下，我最近在一线开发过程中，使用 AI 编程的心得。
反正焦虑也没用，
不如考虑下，怎么用 AI 把实际工作做得更好吧。
AI 的概率性
在开发过程中，我发现 AI 具有「概率性」，就像抛硬币一样。
可能今天觉得还行，明天又不行了
这个问题行，下个问题没准又不行了
同一个需求，刚开做的时候行，做着做着不行了
而对于具有概率特征的问题而言，最好的回答是用统计学术语。
分布函数是怎样的，数学期望是多少。
而不是回答「到底」怎么样，根本就没有到底这回事。
所以，对于那些问「AI 到底有没有用」「AI 到底提效了多少」之类的问题，
我都拒绝回答。
因为我不知道，你说的是什么场景、哪一类需求、什么时间范围内的统计值？
AI 编程「有效场景」总结
但即使无法给出量化数据，我们仍然可以给出一些经验总结。
下文整理了我在一线开发过程中，高频使用的「AI 有效场景」。
1. 知识辅助类
知识辅助类，指的是有了 AI 之后，我不用再上网查资料了。
也不用一行行读代码了，类似这样的工作。
【查找】找到代码位置（当文件很多时，找到要从哪里开始改）
【理解】梳理现存代码中的业务逻辑、执行过程、数据传递、引用位置 等
【调库】查找二三方库的 API、用法、最佳实践、代码示例 等
理解代码库，知道从哪里开始改，改了以后会不会改错，
这是一线开发最关心的问题。
有些项目的的代码太多了，或者是可维护性太差了，人工甚至都不知道从哪下手。
有了 AI 辅助之后，我可以询问 AI，让它帮我梳理现有代码逻辑，
不用自己完整的阅读代码库了。甚至对于一个陌生的项目，也可以立即上手了。
除此之外，有了 AI 之后，我很少再去网上搜索相关问题的帖子了。
尤其是某些三方库的原理、API 用法、示例代码等。
我可以让 AI 帮我生成示例快速学会（不是直接改代码），抄作业更快了。
2. 打字辅助类
所谓打字辅助，指的是我知道怎么写，但是打字会很麻烦。
有了 AI 之后，我可以让 AI 帮我写，最后只需要验证结果是否「跟我想的」一样即可。
值得注意的是，这跟完全交给 AI 写，是两码事。
如果我自己都不知道怎么写，然后交给 AI，那就是「撞大运编程」。
【补全】tab 提示下一步要写的代码
【重构】用可控的方式重构代码（开发知道怎么改，只是比较费事）
【新建】新代码（新建一个组件、页面，并完成基本功能）
tab 补全是最常用的，省了很多打字工作。因为写代码的时候，经常会批量修改。
改了一处之后，按 tab tab tab 一路把其他地方都改了，就很省键盘。
但是仍然会有很多改错的地方，只需要停下来自己写就行了。
再就是重构了，有时候需要较大规模的移动代码，为了让代码结构适合最新的问题。
这时候自己手工移动，就很麻烦，也容易遗漏。
交给 AI 来处理，只需要 Code Review 就行了。
最后就是新建代码的场景，这也是各大新闻、广告吹的最多的场景。
什么一键生成一个「贪吃蛇」游戏之类的。
不幸的是，实际上很少有项目需要「贪吃蛇」功能，所以「提效不明显」。
我用到新建代码，通常是在需要一个新功能模块时，
我会让 AI 帮我生成「样板代码」，即使功能不全，只要勉强能跑就行。
接着，我会在样板代码上迭代开发。而不是期望 AI 把功能都实现完整。
3. 排查辅助类
排查辅助类的比较少，但也挺重要的。
遇到问题之后，有了一个可以实时沟通的伙伴，经常能少走很多弯路。
有时候 AI 甚至还能给出新思路。
- 【分析】问题定位（根据报错信息，分析原因。但能否自动修复，要看场景和具体问题）
有了 AI 之后，分析问题的手段和能力大大增加了。
而不是本来我都没办法解决，交给 AI 后就自动解决了，反正我没遇到过。
相反，是我跟 AI 一起，能把本质原因更快的找到了。
比如，之前在排查前端生产环境中的问题时，经常需要 sourcemap，
否则就无法通过编译后的代码，找到对应的源码在哪里。
现在，我都是直接把编译后的代码直接丢给 AI，让它帮我找。
再举个例子，在排查问题时，经常执行逻辑会下钻到所调用的二三方库中，
这时候人工阅读这些库的代码，是很麻烦的，
可以让 AI 帮我们分析执行过程，迅速找到症结所在。
与 AI 工具的「交互方式」总结
上文我列举了一些高频场景，
可以看到，始终让 AI 安全可控是非常重要的。
我也尝试过一些类似 openspec 之类的 SDD 实践（规范驱动开发），
也就是先把需求描述清楚后，让 AI 一把全输出。
诚然，这也不失为一种办法吧，但要看情况。
下面我来总结一下，与 AI 工具的交互方法，或者说是一些方法论。
1. 拆分问题
通过问题拆分，简化问题。
让 AI 只解决问题的一部分，而不是全部。
每解决一部分提交一次，不断丰富功能（不是一次搞定，而是迭代出来）
上下文工程，我认为最妙的地方不在于总是试图「补齐」上下文，
而在于你可以「构造」任意的上下文，来驱动 AI 实现特定目的。
所以遇到问题之后，我们是可以对问题进行拆分的，
比如，当你想要实现一个网页时，你可以分为好几个问题。
第一个问题，你可以先让 AI 实现一个空白页（最小可用版本）
第二个问题，你可以让 AI 在空白页基础上，逐步实现每个部分
第三个问题，你可以再让 AI 补齐某些交互逻辑
每一个问题对于 AI 来说都是新的，它所完成的工作，始终在你的掌控中。
虽然你可以一次性把所有需求都描述清楚，
但那样会打很多字，AI 也很难一次性都弄对（弄不对修起来更麻烦）。
2. 目的和手段
利用一切可以利用的手段，完成功能开发，而不是排斥它们，也不要迷信。
如果无效（哪怕是对当前问题无效），果断放弃
任何 AI 用法之类的广告，都是手段，也可能是虚假宣传。
我们要做的是，知道有，然后选择性的使用。
如果有效，那就尝试用起来。如果无效，那也别怀疑自己，果断放弃。
由于 AI 具有概率性，所以不见得你的问题，刚好适用。
也不见得你现在遇到的这个问题，正好适用。
思路就是，用好一切可用的手段，并牢记自己的目的。
3. 人工介入
几次无法解决问题（换了模型还是无法解决），那就果断人工介入
这就需要对 AI 生成的所有代码心中有数。即使不全了解，也要能堪比「历史遗留代码」那样，能看懂、可维护
不要全都交给 AI（否则成本立马就上来了，得不偿失）
时刻保持人工可介入的工作状态，不要都甩给 AI 去做。
因为实际项目跟广告里写的不一样。
广告里写的那些项目，跑完分就完事了，实际项目你还要继续加功能的。
所以，我不建议把方向盘交给 AI，除非那种以后完全不会动的功能。
比如有个动画效果，实现了就行了，以后根本不会改。
但如果有个复杂表单，以后很可能会再改，甚至一会就要累加功能了，那至少自己也要能看懂吧。
所以对于 AI 能否取代程序员，我是持保留态度的。
那要看解决什么问题，以及取代什么样的程序员。
结语
本文主要阐述了，作为一线开发，我正在高频使用的 AI 有效编程的场景，
以及，我个人与 AI 进行交互的思路和方法。
很惭愧的是，我还是无法做到网传的那种「上下文大师」的水准，
说什么，用人类语言就可以编程啊，只要描述清楚需求后 AI 就可以接管一切啊，
我都没有达成过。
关键是，我没有一个需要有「贪吃蛇」游戏的项目