先交代背景：去年底开始，我把AICoding工具硬塞进了日常开发流程。不是偶尔玩一下，是每天打开IDE就顺手用那种。
这些场景估计你也在做：Copilot补补样板代码，Claude解释一下看不懂的报错，ChatGPT帮我写正则、生成单测草稿、重构一小段看着碍眼的逻辑。没什么新鲜的，大家都这么用。
但连续用了几个月之后，我发现真正变化的不是“码字速度”。代码写得快只是表象，真正被改变的是我拿到需求之后脑子里那个顺序。
以前接到一个需求，不管大小，我第一反应永远是：怎么拆模块？结构怎么搭？扩展性留多少？接口怎么设计才不丢人？现在变了，我现在的第一反应是：先让AI给我糊一个能跑的版本出来，看一眼再说。
换句话说，AI没替我做什么工程决策，它只是把我脑子里那个“想半天才动手”的环节给压缩了。以前憋半小时想方案，现在十分钟先跑起来再说。能不能跑，跑起来是什么鬼样子，一眼就能看到。信息来得太直接了。
第一个判断：先验证假设，再谈代码质量
说实话，以前写代码有个坏习惯——特别在意第一版的体面程度。命名要统一吧？抽象要不要提前做？目录结构是不是一步到位？要不然回头改起来麻烦。
但现在我把这事儿想明白了：如果需求本身还不确定，你花再多心思在结构上，方向一变全白干。
我现在更愿意让AI先吐一版粗糙但能跑的东西出来。变量名可能是tmp、data、result2这种，异常处理基本等于没有，测试？不存在的。但它能很快告诉我几个关键信息：需求有没有歧义，数据结构对不对得上，主流程能不能闭环，用户路径会不会走断。
说白了，这个阶段我要的不是代码，是信息。
等方向确认了，再老老实实补类型、补测试、处理边界条件、收敛依赖、整理结构。AI适合干从0到0.6的活儿，把一个想法变成一堆能跑的玩意儿。但从0.6到1.0，还得靠自己慢慢磨。我的判断标准很朴素：先确保核心路径的异常处理和关键单测补上，再收敛外部依赖、整理好接口边界，其他的视需求变化再动。我不会在需求还没完全定型的时候把结构焊死。
你让AI写一个能跑的demo，它真行。你让它写一个能上线扛三年的系统，它不行。中间差的那一截，叫工程判断。
第二个判断：写prompt就是写规格说明，别偷懒
不过这里要分两种情况说。
如果是在需求探索期，我的prompt确实很随意，甚至就一句话——因为我要的是“跑起来看看效果”，代码质量本身不是目的。但一旦方向确认了、进入落地阶段，prompt就得换一套写法。
刚开始用AI的时候，我特别粗暴：“帮我实现一个XX功能。”
得到的代码乍一看挺完整，一用就翻车。不是模型傻，是我给的上下文太少了。你让它猜，它就瞎猜，猜得还挺自信。
后来我学乖了。现在写prompt基本是这个套路：输入是什么，输出是什么，边界条件列清楚，不能引入哪些依赖，要兼容哪几个现有函数，异常怎么处理，代码风格跟哪一段保持一致。
你看，这哪是prompt，这分明就是一份小型技术规格说明书。
想明白这件事之后，我对“AI会不会取代程序员”这个问题的看法就变了。它不会取代谁，它只是把一部分工作量从“写”挪到了“定义”上。问题定义得越清楚，AI吐出来的东西越能用。问题本身稀里糊涂，AI只会把糊涂放大十倍还给你。
所以我现在花在写prompt上的时间比过去多了，但花在删代码和修bug上的时间少了。这笔账算得过来。
第三个判断：有些活被压缩了，有些能力被放大了
被压缩的活，特征很明显：重复、上下文独立、验收标准清楚。
样板代码、工具函数、普通CRUD、简单脚手架、初版文档、单测草稿。这些东西以前写起来不费脑子但费时间，现在直接扔给AI，它干得比我快，甚至干得比我好。我没有意见。
但有一些事情，AI碰都没碰到。
比如说，这个功能到底要不要做？产品说的需求背后到底解决什么问题？系统边界划在哪里？线上出了事故怎么快速兜底？这个技术方案半年后好不好维护？这些东西AI一概不懂，它连业务上下文都没有。
这些事情不一定写在代码里，但代码有没有价值，全看它们。
所以我现在对“AI替代程序员”这个说法不太买账。更真实的描述是：AI在压缩执行层的活儿，同时把问题定义和工程判断的重要性顶到了前面。
如果你日常就是在做“把PRD翻译成代码”这件事，那AI确实会让你压力很大。但如果你能把一个不清不楚的需求拆成可验证的小方案，再把AI吐出来的碎片代码整合进一个能长期维护的系统里——那AI就是你的杠杆，不是你的对手。
顺手说两句产业的事：为什么我开始看AI基建
上面这些判断，说起来挺顺，但有个前提：信息得跟上。
尤其是算力基建、光通信、PCB这些环节，看起来离写代码远，但其实决定了AI应用能不能更便宜、更稳定地跑起来。
我以前只看技术文档、GitHubTrending、各种releasenote。后来发现不够。模型调用价格降了，原来因为成本不敢做的功能突然就行了；开源模型能力涨了一截，私有化部署的方案就得重新算账；云厂商出了新的推理实例，延迟和成本的平衡点又变了。
这些事儿，你光看技术文档是看不到的。所以我现在会多看两眼产业层面的东西——不是追热点，是记录哪些变化可能会落到我手头的项目上。
结合最近看到的产业动态，我整理了四条比较确定的观察：
- 各大模型推理能力差距逐步缩小，行业竞争最终会落脚于上层产品设计与自有业务数据积累；
- AI开发工具更新迭代速度快，项目开发流程不能单一绑定某一款工具，保留方案可替换性；
3.多模态技术持续成熟，以往仅文本处理的业务场景，可尝试接入图像、语音、文档解析能力拓展功能；
4.推理成本持续下降，以前不敢做的实时调用、大规模后处理，现在可以重新算账了——这对开发者来说是最直接的变量。
这也是我更关注光通信和PCB的原因。AI应用越往下走，推理调用越多，对数据传输、服务器连接、算力集群稳定性的要求就越高。写代码的人看到的是接口和延迟，产业链上对应的，可能就是光模块、交换设备、PCB等基础环节，AI 不是停留在报告里的故事，而是已经流动在产线、设备和技术迭代里。
我自己对这件事的应对方式很简单：把AI基建方向放进长期观察清单里，用一个相对稳定的节奏持续跟踪。对我来说，这不是追短期热点，而是观察算力基础设施能不能持续受益于AI调用量提升——这比猜下一波风口要实在得多。
（图里的金额和周期只是我的个人设置，不构成投资建议，具体是否适合还要看自己的风险承受能力）
回到开头的问题：用了半年AI写代码，我的思路到底变了什么？
一句话总结：我不再把AI当成一个“帮我写代码的插件”，而是把它当成开发流程里的一个变量。
它改变了原型速度、试错成本、信息获取方式，也在重新分配程序员在团队里的价值权重。但它没有消除工程责任。AI吐出来的代码能不能上线，依赖合不合理，边界条件有没有漏，安全风险在哪——这些最后还得人拍板。
所以我的态度很简单：能扔给AI的执行活，让它先干。必须人来做判断的地方，别因为AI快就跳过去。半年下来最大的感受不是“代码不用写了”，而是开发这件事越来越像在管理一堆快速生成的方案。
生成变快了，判断就变得比以前更重了。
你呢？用了AI写代码之后，变化最明显的是哪一块？写得更快了，还是开始重新琢磨自己的开发流程了？评论区聊聊呗~
基金有风险，投资需谨慎。以上仅为个人经验分享，不构成投资建议。具体产品信息以基金合同、招募说明书及最新公告为准。
