大家好，好久没有更新，今天我想聊一聊关于代码之外的事情。
在最近的忙碌中，我学习到了实际软件开发中的业务流程。
我就在想，在AI时代下，特别是现在各种Agent的能力日新月异，写代码这一件事，已经不再是程序员当下唯一要做的了。
在我看来，现在做软件开发，作为一名程序员，定方案，拆解需求，以及对于Agent整个流程的把控，对我们的要求是越来越高。
这里我不想制造焦虑。我就只是作为一名初入职场的实习生，分享下我自己真实的体会：在软件开发流程当中，AI在我的工作里参与度如何，我又是怎么和AI协作的。
一、企业标准研发流程 和 自己做项目的场景区别
对比公司里的研发流程，和自己做项目，差别是很大的。
1.1 需求链路和取舍逻辑不一样
在公司的时候，常常会有业务方把需求下发过来，产品团队按照他们的理解做成PRD，里面全部都是自然语言描述。轮到我们程序员开发，我们就要把这些自然语言，转成结构性语言，也就是机器可以识别的代码。
在这个转换过程当中，程序员要评估架构、方案，还有最终的代码质量。完整走一遍这套流程，你就会发现，每一步做取舍都得很谨慎。
但自己写项目就不是这样。我自己做小项目的时候，基本不会去调研这个功能有没有收益，市场到底需不需要。很多时候写代码就是练一下知识点，给项目多加点功能。如果实现起来复杂度很高，那我干脆就不做了，反正我只是用来学习。
但是真实业务开发里面，完全不能这么干。
1.2 项目体量带来的巨大差异
还有一个很大区别就是项目体量。 一个线上APP，要上线，还要兼顾海外版本、各种debug需求，杂七杂八的事情特别多。企业项目代码动不动就是千万级别，反观我自己写的项目，大多也就几万行，两边体量差得非常多。
这就带来一个很现实的问题。自己写小demo，AI几轮对话就能读完整个项目全部代码，上下文都掌握住，给出来的方案又快又完整。但是企业环境下行不通，千万行代码你不可能全部丢给AI，得靠我们开发者自己把逻辑梳理好，整理完上下文再交给它。
结合注意力机制来看：你给AI的上下文太少，依据不够，它就容易给出脱离项目实际的方案；可如果你塞的东西太多，它又会产生幻觉乱编。
怎么把控合适的上下文范围，挺考验开发者对需求、对现有代码的理解，还有你的抽象能力。
1.3 个人Demo的AI‑native，放到企业并不适用
所以企业场景用AI，跟自己写demo完全是两种模式。
自己几万行的小项目，你可以直接AI‑native开发。需求直接丢给AI，让它接管全部上下文，不用搞复杂知识库，也不用严格做质量检查。因为项目体量小，出不了什么严重问题。这种情况下，AI主导还是人主导，除了你自己学没学到东西，实际效果差距不会很大。
但放到企业研发就不一样。就算现在AI用得很普遍，企业也不会直接搞AI‑native，全部交给AI主导会出很多问题。
一方面，如果你自己对项目不熟，后面跟产品、QA还有别的团队跨部门沟通，这些事都是要人来做的，AI代替不了你沟通。
另一方面风险会直接失控。自己demo写错顶多功能不好用；生产环境一旦出bug，是要触碰质量红线，造成业务损失的。风险把控必须人来做，总不能让AI背锅。
二、实习踩坑实录：我的AI协作问题与真实感悟
2.1 我踩过的错误使用AI的例子
这里说下我自己真实遇到的情况。作为实习生，我过来是学习的，不能让AI代替我思考。前面也说了，代码质量、需求交付要以人为主，AI只是帮你提效，不能让AI去处理我自己都理解不了的东西。
我第一次接小需求的时候，觉得公司内部AI工具很厉害。我直接把技术方案链接丢给AI，让它输出方案，拿到之后又直接叫AI改代码。改完我就手动点点页面，简单做了黑盒测试。
这里会出现两种情况：
- 第一种，表面看着是符合预期的。但我只做了浅层黑盒测试，没有把内部代码逻辑完整过一遍。页面看着正常，数据也能跑，日志也没报错，但是你不知道改动影响了哪些地方，很可能悄悄埋下坑，把别的关联功能搞坏。
- 第二种就更糟。简单测试发现不对，我就把报错、bug一股脑丢回AI，让它反复改。但我自己测试不像QA那么全面，多轮改下来，受注意力窗口限制，AI会忘掉最开始的需求。加上我自己本来就没有吃透需求，提示词也没理清楚，结果就是越改越偏。
2.2 AI时代，能力要求发生的变化
经历这些之后，我就有一个感受：现在技术准入门槛好像变低了，但不是说代码基础就可以不要。 如果你看不懂AI给的方案，看不懂AI写的代码，那你根本就没法用AI，看得懂代码是最基本的底线。
相对的，现在对程序员架构、方案设计这块的权重，比以前高很多。写代码本身，就是把你脑子里想的东西翻译成机器能跑的逻辑，这部分语法层面的工作AI已经做得很好了。
但是质量把控还是得靠人。AI有时候会写一些没有意义的兜底，写很难看的不合理的硬编码，生成的代码和项目现有接口冲突，甚至给出来的方案跟需求本身就对不上。这些问题都要人去识别。
2.3 实习得到的两个主要误区
我实习的时候有两个挺大的误区。
第一，需要人工判断的地方，不能完全放手丢给AI。
当然，不懂的时候可以问AI，反复问，搞懂需求。但是AI在我眼里就像一本书，一个大知识库，集合了很多观点。你可以拿里面的东西用，但它说的适不适合你的场景、到底对不对，要你自己分辨，尽信书不如无书，思考这个过程不能省略。
第二，你自己要主动去澄清、理解需求，知道自己要达成什么目标。
其实人和Agent思考逻辑是差不多的，Agent harness里面有goal，也就是目标这个概念。如果你都不知道改代码、优化、修bug到底要达成什么goal，后面方案根本无从谈起。
很多时候梳理清楚这一堆上下文，才是心智成本最高的地方。把目标想明白这件事本身就很难；想清楚之后，剩下的就只是落地怎么做的问题。
所以我感觉，培养实习生，更多是练理解需求、拆需求的能力。包括招聘时，其实也越来越看重这些能力。
至于技术，很多架构思想都是相通的，MVC、MVVM、分布式这些概念都可以互相类比，纯技术不见得是最大门槛。
2.4 延伸想法：为什么服务端竞争会更激烈
那为什么软件开发里面服务端竞争是最激烈的？实习以后我的感受更深。
因为服务端离业务最近，很多业务问题本质就是数据、状态问题，离这些业务最近的就是服务端。
我认为软件开发的本质，还是理解业务、理解需求。把自然语言转化成结构性代码语言，这一步转换，其实更考验人。
AI时代，对古法编程的考察比重在下降。古法编程很大一部分就是考你熟不熟语法，能不能写出结构化代码。而自然语言转到结构性语言这部分的占比在上升。AI做古法编程，做语法转换已经做得很不错。真正要人去做的，还是沟通、理解业务，还有这一堆心智成本。
三、最后一点个人感悟
其实写到这里，也没有什么特别宏大的结论，都只是我实习这段时间实实在在的感受。
AI和Agent确实改变了写代码的方式，但很多核心工作还是绕不开人。写代码实现可以交给AI帮你提速，但是需求怎么判断、方案怎么选、风险在哪里，这些工具代替不了。
我作为实习生，也一直在调整自己用AI的习惯。哪些可以交给它，哪些东西我自己必须啃透；先把目标和需求想明白，再动手写代码。AI就是一本很好的参考书、协作工具，不能拿来直接代替你思考。
现在做开发，不完全比拼谁写代码更快。
看得懂业务、会拆解需求、把控整条流程的能力会越来越重要，这也是我后面需要继续学习的地方。
