先交代背景去年底开始我把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写代码之后变化最明显的是哪一块写得更快了还是开始重新琢磨自己的开发流程了评论区聊聊呗~基金有风险投资需谨慎。以上仅为个人经验分享不构成投资建议。具体产品信息以基金合同、招募说明书及最新公告为准。