AI 门槛越来越低，普通开发者还能做什么？
从整理客户反馈这样的任务说起，区分 AI 能产出的东西与必须由人作出的决定，给出普通开发者可以练的判断力和能立刻开始的第一步。
先看一个很常见的任务：整理客户反馈。
把几百条文字交给模型，让它分类、归纳，几分钟后你就拿到一份条理清楚的总结：抱怨集中在哪几个方面，每一类占多大比例，典型原话出现在哪里。作为一次尝试，它超出了预期。
问题紧接着就来了：这份总结接下来怎么用？
负责人拿到它，接下来要决定的可能是：主要抱怨是什么？哪些问题应该优先处理？上次承诺的事情有没有进展？三个问题都成立，需要的东西却完全不一样。
门槛降低之后，人人都能做出一个工具。差别不在能不能做出来，而在于做出来的东西，能不能支撑别人接下来的决定。
这也是我认为普通开发者还能继续投入的地方。
对已经做了几年开发的人，这个问题更实在。过去花时间练出来的东西，还能不能继续换到价值？如果现在才开始学，会不会刚学会，它就变成人人都会的事？
1、门槛降低了，什么会贬值
先承认一个让人不太舒服的可能：有些会。
如果一项工作的要求已经很清楚，做法也相对固定，原来需要花时间编写，现在借助 AI 就能较快完成，那么，仅凭“这部分代码我会写”，确实更难体现差别。
这种变化不只影响新人。做了几年同类工作的人，如果积累主要是更熟练地重复相同做法，也需要重新看待这部分经验。熟练仍然有帮助，但当工具减少了对手工编写的依赖，它所能带来的优势也可能缩小。
不过，从这里直接推到“开发经验没用了”，又跳过了很大一段。
一次开发，包含理解要求、作出选择、写出实现、检查结果，以及处理使用以后出现的问题。AI 可以参与这些工作，但具体到某个任务，它改善了哪一部分、还剩下多少需要人做，必须分开判断。生成代码很快，不能直接证明整件事已经变容易。
这也解释了为什么同样使用 AI，有人只是更快地交出一个版本，有人却能借它多承担一部分工作。差别可能就在这里：后者知道要求还缺什么，能判断结果是否合适，也能在条件变化时继续处理。
值得重新整理的，是自己的经验里，哪些只是过去做过很多遍，哪些已经让自己更会判断一件事。
不必因此否定过去。那些返工、沟通和处理问题的经历，都可以重新拿出来看。但它们需要通过具体选择体现出来，才能帮助别人理解你现在能做什么。
2、一份漂亮的总结，为什么还不够
那么，判断力具体体现在什么地方？回到那批客户反馈，答案比较具体。
那份总结只是一个起点。负责人真正要回答的是三件事：主要抱怨是什么，哪些问题应该优先处理，上次承诺的事情有没有进展。
如果要了解主要抱怨，需要分类的口径说得清，而且每条结论都能回查到原文。否则没有办法判断，它说的是真问题，还是模型把三件不同的事归成了一件。
如果要决定处理顺序，出现次数多的意见就一定更重要吗？同一个用户重复提交同一件事，该怎么算？只有三个人提到、却会让整条流程走不下去的问题，又该放在哪里？这些都要知道处理一个问题要花多少代价、它卡住了谁，才谈得上排序。
如果要查看承诺进展，那就更不能只看这份总结了。得知道上次承诺过什么，分别由谁在跟进，这次反馈里有没有对应的消息。
三件事指向同一个地方：做出总结需要的材料，和作出决定需要的材料，不是同一批。 后者藏在团队的目标、历史承诺和实际代价里，不在那几百条文字里。
模型可以参与分析，但这些依据得有人弄清楚、提供进去，还要检查分析有没有偏离目标。所以，“理解业务”不必说得很玄。它可以具体到：你能看出来这份总结看起来完整，却还不足以支撑接下来的决定，并且知道应该继续问什么。
整理客户反馈时，AI 产出之后的工作落在人身上图里没画的部分同样重要：负责人还要把结论带回团队，再把处理结果告诉提出反馈的人。这段路 AI 参与得再深，也仍然要有人走完。
再往前一步，使用者还要付出自己的时间。把材料准备好，核对结果，纠正错误，再把结论带回原来的工作。生成过程省下的时间，可能被这些事情抵消。
对使用者来说，真正值得比较的是：从开始处理到事情完成，算上检查、修改和后续处理，用了这个工具以后，整体是否更合适。
这才是应用开发可以继续做的事情。你可以借助 AI 减少开发负担，再认真处理那些妨碍实际使用的问题。让对方不必每次从头交代，让结论便于核实，让不确定的事项得到确认。这些改进是否有用，要回到对方的工作里看。
当然，如果现成 AI 工具已经足够方便，对方就未必需要你再开发一个。承认这一点，有助于找到真正值得做的部分。我们要比较的对象，也包括对方现在的做法，以及他已经能直接使用的工具。
3、把任务分成三类，才知道该让 AI 走到哪一步
既然要比的是“整体是否更合适”，就得先分清手上的任务属于哪一种。三种情况如下。
分类的意义不在于好看，而在于它决定你接下来做什么。第一类不必自己开发，能用现成工具就用；第二类的工作重点是准备材料、验证结果；第三类里 AI 只能把材料准备到可以决策的程度，决定必须由有权限的人做。
也因为这样，“这个任务能不能用 Agent 做”从来不是一个是非题。同样是整理反馈，把重复意见归类是一类，判断哪些该先修是另一类。先分清是哪一类，再决定要不要动手。
4、你的经验还能留下什么
分清任务属于哪一类，靠的是对业务的了解。这正是经验能派上用场的地方。
先说清楚：经历过某个行业，能帮你起步，但“我做过这行”本身不够。
参与过相关系统的开发，可能让你接触过实际工作。但如果只知道有哪些功能、页面上显示什么，并不一定知道反馈为什么一直没有被处理，或者负责人究竟缺哪一块信息。
经验能不能发挥作用，要看能否把这些事情继续问清楚。
一份总结被说“没用”，原因可能有好几种：信息不准确，重要的问题被淹没了，或者内容其实没错，却没人知道接下来该由谁处理。原因不同，值得改的地方就不同。继续要求 AI 把文字写得更漂亮，未必能解决其中任何一种。
所以，值得重新整理的不是“我做过几年”，而是下面这些具体的东西。
- 当时为什么放弃了一个看起来更完整的办法？
- 哪个要求看起来可以省，最后却必须保留？
- 有哪次反馈改变了原本的理解？
这些问题比年限更能说清经验的内容，因为它们对应的是判断，而不是次数。
如果目前没有这样的经历，也不用把它理解成一道进不去的门槛。可以从观察实际工作开始：请使用者讲一次他现在的处理过程，看他卡在哪一步，再对照尝试前后的结果。起点小一些没有关系，重要的是自己的判断有东西可以核实。
同时，也要给原来的理解留出修改空间。你熟悉的流程可能本来就不合理，使用者口头上提出的办法，也未必最适合解决他的困难。经验的作用，是帮助你提出更有根据的问题，再通过实践修正答案。
5、为什么建议沿着 Agent 往前走
前面几节讲的是：哪一步需要人，凭什么判断，要问对什么问题。这些判断要有地方落脚，工具才接得住。Agent 讲的是多出来的那一段过程。
单独使用 AI，往往从一次提问开始：提出要求，拿到结果，这轮就结束了。学习 Agent 开发，则需要继续考虑：围绕一个目标，接下来还要做什么；怎样根据得到的信息调整；什么时候该停下来请人作决定。
对客户反馈来说，给出一份总结可以是一项帮助。但从发现问题，到核实情况，再到跟进处理，中间还有不少工作。如果其中一些环节适合让 AI 参与，Agent 应用就有了尝试的空间。
这里不需要先追求“全部自动完成”。先选一段边界清楚的：让使用者少做一次重复整理，或者更容易发现哪些事需要继续跟进。选哪一段，取决于它实际造成的负担，以及你有没有办法判断改善是否成立。
这样的练习，要求你同时理解使用者、AI 的表现和软件怎样配合。过去只负责其中一部分的开发者，可以借一个有边界的项目，把它们联系起来。
这就是我推荐这条路的理由。AI 帮你减轻部分实现负担，你便有机会把关注范围扩展到一项工作怎样完成。需要补的技术，也会因为眼前的问题而有明确用途。
但 Agent 不是越复杂越好。Anthropic 在《Building effective agents》中建议从能解决问题的简单方案开始，并指出 Agent 系统需要权衡额外的等待时间和成本。这项工程建议提醒我们，增加自动处理的步骤，必须有实际理由。
如果一项任务用普通程序或现成工具就能做好，选择简单办法，同样是在作开发判断。认真学习 Agent，也包括学会判断它什么时候值得使用。
6、没有资源、没有用户，第一步到底怎么走
读到这里，道理可能都懂了，可现实困难还在：手上没有合适的业务，也没有人等着试用。
先把目标放在自己能够接触和核实的事情上。
有工作经历，可以从参与过的一类任务中找问题，但不要仅凭印象认定它现在还存在。能接触使用者，就请他讲一遍现在怎样处理；无法接触，就如实把它当成自己的练习，别提前写成“已经解决了企业需求”。
刚开始学习，或者目前离开了原来的团队，也可以从自己反复需要完成的事情开始。选择时，留意两个条件：它确实给自己造成过负担；做好以后，自己能够判断差别。范围宁可小一些，也要能走到检查结果这一步。
接下来，把目标写得具体一点。如果选择整理自己的待办，可以写成：“把已有的待办整理成下一周的安排，保留截止日期，标出仍需确认的信息。”它不需要企业材料，也不需要先找到试用者，你自己就能回到原始记录检查。
如果能接触实际业务，前面那个客户反馈的例子可以写成：“让负责人少读重复内容，同时保留需要核实的重要问题。”这句话还不代表需求已经成立，但它指出了要观察什么，比“做一个智能分析平台”更容易开始讨论。
然后，先用现成工具试一遍。拿同一批材料，对照原来的做法，看看有没有遗漏，检查和修改花了多少精力，结果能不能直接帮助下一步工作。如果已经够用，就用好它；如果某种负担反复出现，再考虑通过自己的应用改善。
这样做还有一个实际好处：你能分清“需要补知识”和“需要多做功能”。结果不准确，可能要先查材料和判断标准；根本没有人需要这个结果，就应重新考虑目标。不同的问题需要不同的下一步，不能都靠继续开发来解决。
第一段实践有没有作用，可以先看三件事：你是否更清楚原来的困难，是否知道 AI 帮助了哪里、哪里没有，以及是否有结果支持继续投入。
这段经历不一定马上带来收入或工作机会。但它能让你在下一次选择方向、介绍项目或者比较工具时，多一些自己验证过的依据。
7、如果模型一更新，我做的事情又变简单了呢
这是一个合理的担心，也确实可能发生。
为弥补模型不足而写的某些功能，可能在新能力出现后不再需要。有些独立工具，也可能被通用产品覆盖。所以，只围绕“模型暂时做不好什么”投入，确实需要留意变化。
但学习的目标，可以包含怎样更好地使用这些变化。
如果你已经弄清楚一类工作的要求，保留了能检查结果的例子，也知道使用者在意哪些问题，新模型出现时，就可以拿原来的任务重新比较：做得更好了，原来的办法就能简化；仍然不合适，再判断差距在哪里。
这时，你既往的实践会帮助你作选择。某段实现不再需要，未必是坏事；你要完成的工作如果因此更容易，就可以把精力投入其他仍然存在的困难。
当然，任何经验都需要更新。这里没有一项本领能够保证以后始终被需要。普通开发者能够争取的，是让自己逐渐具备这样的能力：面对一个具体需要，能够借助已有工具提出办法、做出结果，并根据实际情况继续调整。
这也是对开头那个问题，我想给出的回答。
AI 门槛降低以后，值得做的是尽早用上它，并逐步承担一项工作中更多的部分。代码可以请它帮忙，陌生知识可以借它理解；而问题为什么值得解决、结果是否达到要求，要在实践中一起弄清楚。
下一份工作能否找到、个人产品能否有人使用，都不能仅凭“学了 Agent”来保证。但沿着这条路学习，你可以争取让别人更具体地了解自己：面对怎样的问题，能够承担什么，又有哪些实际结果可以说明。
普通开发者的机会，可以从这里开始：用 AI 扩展自己做事的范围，让每一次实践，都多留下一点自己能够理解、验证和继续使用的经验。
下一篇，我们进一步讨论《从回答问题到帮你做事，Agent 多做了什么？》，把这条学习方向与 Agent 实际参与工作的方式联系起来。