当前时间： 2026-05-07 01:08:50
更新时间： 2026-05-07
分类：软件教程
评论(0)
你不是不会用AI,你只是不知道AI能干嘛
上周五下午，我正在改一个bug，隔壁工位的产品经理凑过来问我，下周评审的技术方
不是，哥们，你是不是觉得AI就是你对着它说一句话，它就能把所有事情给你干了？那我还要上班干嘛，我让AI来替我坐在这，工资打我卡上不就完了。
这个对话让我想明白了一件事。很多软件行业的从业者，不管是做开发的、做产品的、还是做项目的，他们对AI的理解还停留在一个非常浅的层面。
但那个用法，怎么说呢，就像你买了一台顶配的MacBook Pro，然后只用它来记事本。
刚接触AI的时候，我做的事情跟大多数人一模一样，对着ChatGPT问一句”什么是微服务”，它给我回一大段教科书式的定义，我看了一眼，觉得也就那样，还不如自己Google呢。
然后我就把ChatGPT关了，跟同事说，这玩意目前还不太行。
后来我才发现，问题不在AI，在我的用法。这就好比你刚装了个IntelliJ IDEA，打开一看发现界面跟VS Code不太一样，不习惯，就把电脑关了，然后跟别人说”这IDE不行”。
今天这篇文章，是这个系列的第一篇，我想先做一件事，就是帮你打开对AI的想象力。
不是教你具体怎么用，那后面会讲。而是先让你看到，AI在软件从业者的工作中，到底能做到什么程度。
这些场景全是我自己用出来的，不是我想象的，不是我从哪篇文章里看来的，是我真的去做了，然后发现，卧槽，原来还能这样。
你接手了一个新项目，前任开发已经离职了，留下一个几十万行代码的项目，没有文档，没有注释，git commit message全是”fix”和”update”。
以前我的做法是硬啃，从入口文件开始，一行一行往下看，碰到不认识的函数就ctrl+click跳过去，然后在脑子里慢慢拼出整个项目的调用链路。这个过程通常需要好几天，甚至好几周。
我把核心模块的代码扔给Claude，然后问它，帮我梳理一下这个项目的核心业务流程，主要的调用链路是什么，数据是怎么流转的。
几分钟之后，它给我一份清晰的梳理，关键入口、核心逻辑、数据流向、模块依赖，一目了然。
不是说这份梳理就是100%准确的，你还是要自己去验证。但它帮你跳过了从零开始摸索的过程，直接给你一个框架，你在这个框架上去验证和修正，效率提升不是一点半点。
我自己用下来的感受是，以前需要一周才能搞明白的项目，现在可能两天就能上手了。
这个我相信做开发的和做产品的都有共鸣。产品经理扔来一份需求文档，你读了半天，发现里面有些逻辑自相矛盾，有些边界情况没考虑到，有些技术上实现成本很高但产品经理完全没意识到。
以前你得花一整个下午去读那份文档，边读边记笔记，然后在评审会上一条一条提出来。
现在我会先让Claude帮我过一遍需求文档，它会帮我找出逻辑矛盾点、遗漏的边界条件、可能的技术风险，还会生成一份”需要跟产品经理确认的问题清单”。
我拿着这份清单去参加评审，效率高了不是一点半点。产品经理都觉得我最近review需求的能力突然变强了。
以前写技术方案是一件很痛苦的事。你得先调研各种技术选型，对比优劣，评估风险，然后写成文档。这个过程少说也得一两天。
现在我会先告诉Claude，我要做什么系统，核心需求是什么，约束条件有哪些，然后让它帮我做技术选型的分析。
它会给我列出几个候选方案，每个方案的优劣、适用场景、潜在风险，一清二楚。我在这个基础上做判断和取舍，然后让它帮我把方案写成文档。
而且写出来的文档质量，说实话，比我自己写的还要好。因为它不会有那种”我知道但懒得写”的遗漏，该说的都会说到。
你可能注意到了，我上面说的这些场景，有一个共同点。
没有用到什么prompt engineering的高级技巧，没有写什么复杂的提示词，就是用最朴素的方式把需求告诉AI，然后它就给你一个不错的结果。
AI在软件工作中的能力边界，远远超过大多数人以为的那个圈。
我自己把AI能帮软件从业者做的事情，大概分了一下层次。
写CRUD代码，改格式，写单元测试，改bug，这些事情每天都在发生，枯燥且耗时。AI可以帮你把这些事情的效率提升好几倍。你跟它说我要一个用户注册的接口，要支持手机号和邮箱，密码要用bcrypt加密，它几分钟就能给你一个可以直接用的代码框架。
不是说你完全不用改了，但至少80%的工作量它帮你扛了，你只需要专注在那20%需要动脑子的部分。
软件从业者每天都在处理大量的信息，需求文档、技术文档、代码、日志、会议记录、邮件。这些信息的获取和理解是有成本的，而且成本不低。
比如你想搞明白一个开源项目的架构，以前你得花好几天去读源码，现在把核心代码扔给AI，它几分钟就能给你一份架构分析。你在这个基础上再去读源码，效率完全不一样。
再比如你要快速了解一个你没接触过的技术领域，像你做后端的突然要做一些前端的事情，或者做业务开发的突然要搞一些大数据的东西。以前你得从头学，现在你把你具体要做的事情告诉AI，它可以给你一个非常有针对性的技术指引，不是泛泛的科普，而是结合你具体场景的建议。
打个比方，你review一段代码，你自己看可能觉得没什么问题。但让AI看一遍，它可能会告诉你这里有个潜在的并发问题，那里有个性能瓶颈，这个写法在极端情况下会有bug。
不是说AI比你强，而是它不会疲劳，不会因为赶工期就跳过细节，不会因为对这段代码太熟悉就产生盲区。它是你的第二双眼睛。
方案设计也是一样。你想到了A、B、C三个方案，让AI帮你做一轮分析，它可能会指出你没想到的风险，或者提出一个D方案。你可能最终不会用D方案，但这个思考过程本身就有价值，它让你的决策更完整。
以前一个三四线城市的初级开发，跟一个在大厂干了五年的高级工程师，之间的差距是巨大的。不只是技术能力的差距，更是信息和视野的差距。高级工程师见过更多的系统设计，踩过更多的坑，知道什么样的架构在什么样的场景下会出问题。
你没有分布式系统的经验，但你可以让AI帮你分析一个分布式系统的架构，告诉你每个组件的作用、可能会遇到的坑、业界的最佳实践。你虽然没有真实的经验，但你有了正确的认知框架，当你真正去做的时候，你的起点已经不一样了。
这不是说AI能替代经验，替代不了。但它能帮你缩小知识差距，让你在做决策的时候不至于两眼一抹黑。
为什么那么多软件从业者，明明每天都在用电脑，天天跟技术打交道，却用不好AI？
很多人试过一次AI，发现它给的答案不太行，就下了结论，觉得这东西不靠谱。这种心态我非常理解，因为我们做软件的人，对工具的要求是很高的，一个IDE如果代码补全不准，你可能直接就不用了。
AI不是一个开箱即用的工具，它更像一个能力很强但需要磨合的同事。你第一次跟一个新同事合作，配合肯定不默契，但你不会因此就拒绝跟他合作，对吧？你会慢慢了解他的工作方式，调整你们之间的协作模式。
就是我前面说的，把AI当搜索引擎用。问一个问题，拿一个答案，结束。这种方式当然也能用，但效率提升很有限。
真正让效率产生质变的用法，是把AI嵌入到你的工作流程里。不是偶尔想起来用一下，而是每个环节都想一想，这个环节能不能用AI来帮忙。需求分析、代码编写、代码review、测试、文档、方案设计，每一个环节都有AI能切入的点。
以前我跟AI说，帮我优化一下这段代码。它给我一个优化后的版本，但不是我想要的那种优化。
后来我换了个方式，我说这段代码的性能瓶颈在数据库查询，当前QPS是500，目标是2000，数据库是MySQL 8.0，数据量大概500万行，你帮我从索引优化和查询重构两个方向给建议。
跟AI协作的核心能力，就是你得把背景、上下文、约束条件都讲清楚。它不是你的领导，不会帮你定义问题，它是一个能力很强的执行者，你给它的信息越精准，它的输出就越有价值。
因为我们每天的工作就是跟抽象、跟逻辑、跟接口打交道。我们比任何人都更清楚，一个接口的输入决定了输出的质量。把跟AI的交互理解成一个接口调用，输入的质量决定输出的质量，这个道理我们秒懂。
我知道有些朋友可能会想，你说的这些我都懂，但工作太忙了，哪有时间去研究这些。
每天的需求排得满满当当，bug修不完，会议开不完，回到家已经精疲力尽了，谁还有精力去学什么AI。
AI这个东西，你投入的时间和回报之间的关系，不是线性的，是指数级的。你花两个小时学习怎么用AI来辅助你的工作，可能接下来每一天都能帮你省出一个小时。一个月下来，你省了30个小时，但你只投入了2个小时。
而且你不需要专门腾出时间来学。你就从明天的工作开始，碰到任何一个任务，先想一想，这个事情能不能用AI来帮忙。能，就试一下。不行，就正常做。就这么简单。
不需要什么仪式感，不需要专门的学习计划，就是把AI变成你工作中的一个默认选项。
当你知道了AI在你的工作中能做到什么程度，你自然就会去用它。就像你第一次发现IDE的代码补全功能之后，你再也不可能回去纯手敲了。
这个系列后面的文章，我会一个一个讲具体的用法，怎么写好提示词、怎么用AI写代码、怎么做需求分析、怎么搭建自己的AI工作流。但今天这第一篇，我想先帮你把那扇门推开。
后来我花了一个下午，用AI把方案写完了。第二天评审的时候，他看了我一眼说，你这效率可以啊。
我没说话，心里想的是，哥们，你要是知道我是怎么写的，你可能就不是这个表情了。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
夜雨聆风
