大家好，我是吴师兄。
昨天看到李沐的一条回复，挺有感触，有人问，Code Agent 普遍落地以后，程序员最重要的能力是什么？
沐神提了一个词：“tech leader 的能力”。
他的意思是，基础代码实现、review、运行这些环节正在被 AI 接过去，但 tech leader 的工作远不止这些。
关于这个话题，结合我掌握的情况，聊聊我的理解，这几年来，我基本每天都会和至少 5 个同学聊咨询。
最近和一些工作三年以上的程序员沟通，反复感受到一个问题：工具已经变了，他们衡量自己能力的方式，却还停在过去。
会几个框架，读过多少源码，能不能自己从头写一遍。学 AI，也习惯先列一大堆前置知识，全部搞懂了，才敢开始做项目。
这些当然有价值，但项目到底解决谁的问题，为什么这样设计，做到什么程度才算有用，往往被放到了后面。
我理解的 tech leader 能力，就是把问题定义清楚，做出取舍，再对交付质量和业务效果负责。
哪怕团队只有你和 AI，这些事情也得有人做。
所以我现在很想提醒准备转型的同学：别再把“跟着教程跑通一个 Demo”，当成项目学习的终点。
找一个开源项目改改、或者买点小项目，然后传几份 PDF，接一个模型，套个聊天页面，能问能答，换个框架再做一次，简历上又多了一个项目。
如果每次都停在这一步，对锻炼独立解决业务问题的能力，帮助就很有限。
Demo 能帮你入门，但你要靠项目证明自己能做事，就得继续往真实业务里走。
拿一个准备交付给商家使用的 AI 客服项目举例。
商家希望少花时间处理重复咨询，同时把售后问题处理好。做之前，你得先问：现有的人工、规则和系统已经能解决哪些问题，引入大模型，准备改善哪一段？
如果只是输入订单号、返回物流状态，现成接口就能完成，模型更值得尝试的地方，是接住用户五花八门的表达，结合上下文和业务资料，判断下一步该查什么、问什么、做什么。
比如用户说：“都五天了还没到，我周五要用，实在不行就不要了。”
里面既有催单，也有时间要求，还有一个带条件的退款意向，系统要先核实订单和物流，再判断需要补充什么信息，什么时候可以继续处理，什么时候该转人工。
当你把这些判断交给模型，开发工作就多了一层：决定模型能自主处理到哪一步，以及判断错了怎么发现、怎么收住。
这里就有架构选择。先让模型识别需求，再进入固定流程，够不够用？确实需要根据每一步查询结果动态决定动作的部分，再考虑交给 Agent。
这个选择，得拿业务里的问题去试。
只挑十条问得清清楚楚的问题，模型可能表现很好。但真实用户会漏信息、改口、表达情绪，还会提出超出规则的要求。你要让系统在这些情况下也能做出合适的处理，学习任务才真正展开。
模型需要售后规则，你就得研究如何检索到适用的条款；需要订单状态，就得设计工具，让它知道什么时候调用、传什么参数、怎样使用返回结果；信息不足，就要设计追问和停止条件。
接上接口，只完成了其中一部分，用户只是催单，Agent 却选了退款工具，哪怕接口执行成功，业务也已经做错了。
所以，工具设计还要考虑模型可能犯什么错，比如退款金额由后端按照订单和规则计算，接口直接不接收模型填写的金额；需要人工批准的操作，就在执行前强制检查批准结果，模型负责提出动作，系统负责检查动作能否执行。
tech leader 的判断，体现在如何分配模型、代码和人工各自的职责，让模型的灵活性产生价值，同时限制错误的后果。
职责划清了，也不能只靠一句“效果还不错”来验收。
假如客服把一条退款规则用错了，下一步该怎么办？直接换更贵的模型，还是先查它当时拿到了什么资料、调用了哪些工具、工具返回了什么？
适用条款没检索出来，要先查知识库和检索过程；资料已经给对，却仍选错动作，再检查上下文、工具说明和决策规则，评估是否需要调整模型。
把这些原因混在一起，反复改提示词，很难知道究竟改好了哪里。
这就需要保留执行轨迹，把有代表性的失败整理出来：脱敏，由人确认应该怎样处理，再变成评测案例，换模型或改方案时，固定其他测试条件，在隔离真实退款等操作的测试环境里比较新旧结果。
你要验证的，既包括回复有没有依据，也包括该追问时是否追问、该转人工时是否停下、有没有调用不该调用的工具，模型会有波动，关键场景还要重复测试，不能只拿一次成功当结论。
做到这里，商业化的约束又会推动你继续往下学。
更强的模型也许能处理更多复杂问题，但多轮调用会增加费用和等待时间，普通查单是否能用更便宜的方案，复杂售后再交给更强的模型？省下的 Token，会不会又变成人工纠错的成本？这些都得测。
最终要一起看问题解决情况、错误、人工接手、响应时间和总成本，确认这套系统给商家带来的改善值不值得投入。
你看，做到这一步，RAG、工具调用、上下文组织、评测、模型选择，就都有了具体的学习理由，也都能回到同一个业务目标上。
这就是我为什么建议，转大模型应用开发，一定要选一个以商业落地为目标的项目，作为学习主线。
跟着教程做 Demo，可以熟悉技术，继续往交付走，才会逼着你回答：AI 用在哪儿才有价值，什么错误不能接受，怎么证明改进有效，花多少钱才划算。
挑项目也要看这些内容，一个项目号称“企业级”，却只演示了正常情况下的聊天效果，没有失败分析、评测依据和成本取舍，仍然不足以支撑你学会交付。
当然，你开始时可以还没有客户，从自己工作里的一个问题、一家小店的重复咨询入手都可以，先找到实际使用者，弄清需求，做一个能试用的版本，再收集反馈。用模拟数据就如实标注，有实际效果以后再谈收益。
学原理、写代码、用 AI 辅助实现，都围绕这个项目推进，这样学到的知识，才会逐渐变成你判断方案、定位问题、交付结果的能力。
你可以暂时没有 tech leader 的职位，但从学习第一个项目开始，就该练习对 AI 的业务效果负责。