学习笔记第9篇 | AI大模型应用开发实战
第17课了，AI Coding模块第三节。前面两节聊的是SpecDD+TDD和持续迭代重构，这节突然就跳到团队分工和个人发展上了——Agent越来越能写代码了，那人干嘛？前端后端还分不分得开？
传统分工那套东西正在松动
我自己做了五年前端，后来又搞了三年淘宝店，对"前端写页面、后端写接口、产品画原型"这套流程真的太熟了。但第17课上来就讲了一个事，我觉得说得挺到位的——这套分工模式，说白了就是在"专业化收益"和"交接成本"之间找个平衡点。
你想啊，前端专门搞表示层和交互，后端专门搞业务逻辑和数据，产品专门管用户路径和行为取舍。每个人把自己那块做深，效率确实最高。但问题是环节之间要交接啊。产品写完PRD丢给前端，前端画完页面等后端接口，后端写完逻辑再联调……这个交接成本是实打实的。
然后Agent来了，把这个平衡给搅了。
以前前端想自己搞个mock接口，还得现学Node.js弄数据库，门槛不低。现在呢？跟Agent说一下，一个能跑的接口就出来了。以前产品想验证个想法，得排期等开发，现在Agent直接就能出原型。
那原来那些岗位边界，肯定得重新想了。
岗位会消失吗？这个真不好说
课里有个观点我挺认同的：不能光看"Agent生成了多少代码"就觉得某个岗位快没了。
判断一个岗位还需不需要单独设，得看两个东西——一是Agent能做的部分去掉之后，剩下的事是不是还需要足够深的专业能力；二是这些事的工作量够不够撑起一个独立岗位，有没有人需要对结果负责。
Agent替代的是"实现成本"，不是判断力和责任感。它能帮你写个React组件没错，但这个组件该不该做？做了之后对用户体验啥影响？上线出问题谁来兜底？这些事它搞不定。
人要干嘛？四件事
这课最核心的部分就是这个了。Agent时代，人的重心从"写代码"变成了"围绕完整结果组织工作"。
怎么理解呢……人负责提供上下文、做取舍和判断，Agent负责可以委托出去的执行工作。
展开说的话，大概是四个方向。
第一个：想清楚为谁解决什么问题
这是最上游的事。你得先搞清楚——这个功能到底在帮谁解决什么问题？为啥值得投入资源？
需要的能力嘛，业务理解、跟用户沟通、拆解优先级这些。产物是啥呢，使用场景、方案理由、Spec规格说明、验收案例。
说白了就是——你得先想明白"做什么"和"为什么做"，再让Agent去做"怎么做"。
这块其实是最难被替代的。因为"定义问题"本身就需要对人的理解、对业务的判断。Agent可以帮你写100个功能，但它不知道这100个里哪5个才真正重要。（说到这个我想起之前开淘宝店的时候，选品选错了后面全白费，道理其实差不多……跑题了。）
第二个：怎么组织系统和执行
想清楚了做什么，下一步是"怎么组织"。模块怎么拆、接口怎么定义、数据怎么流转、哪些任务扔给Agent、哪些必须自己把控。
这块……我觉得是前端转全栈最大的坎。以前只管页面渲染和交互逻辑就完了，现在得理解整个系统怎么串起来的。不过好消息是，你理解了架构思路之后，具体实现可以委托给Agent。我目前还在学这块，说实话有点吃力，但大方向是能看懂的。
第三个：验证结果对不对
代码写完了，怎么知道它是对的？怎么知道它真解决了用户的问题？
这块第15课SpecDD+TDD其实已经详细聊过了，核心就是——验收标准要先于实现。先定好"什么算做完了"，再让Agent写代码跑测试。不然你真不知道它生成的东西对不对。
第四个：上线之后的事
功能上线不是终点，是起点——接入、发布、出问题怎么恢复、日常怎么维护、运行成本怎么控制。
第16课讲的持续迭代和重构就是这块的内容。代码不是一锤子买卖，得持续跑着、持续改。
"左脚踩右脚"——双Agent互查为啥不靠谱
接下来说这个课里最让我震惊的部分。
课里提到了一个内部测试的结果：端到端盲跑、开发Agent和检查Agent paired的双Agent模式，效果都翻过车。
双Agent模式是啥呢？就是一个Agent写代码，另一个Agent检查代码。听起来挺完美的对吧？一个干活一个质检。
但实际操作经常出问题。
问题出在一个特别形象的比喻上—— "左脚踩右脚" 。
两个Agent共享的是同一组上下文。如果开发Agent理解需求的时候就有偏差，搞出了一组不完整的假设，那检查Agent做检查的时候大概率也基于同样的假设去判断。
它俩用的是同一套"世界观"。
就像两个人看同一份有歧义的需求文档，都觉得自己的理解是对的。开发Agent按自己的理解写了代码，检查Agent用同样的理解去检查——代码确实"符合需求"，但这个"需求理解"本身就是错的。
它俩互相回复的时候也可能保留偏差。开发Agent说"我这么写是因为需求要求这样"，检查Agent一看好像说得通，就过了。但根本性的理解偏差，谁都没发现。
这就是"左脚踩右脚"——自己验证自己，永远查不出真正的问题。
那啥样的检查才算有效？课里给了三个条件——得有明确的可验证的验收标准，不能是"看起来差不多"那种；检查的人不能只看代码得真正跑起来看结果；得用真实数据和真实场景去验证，不能拿模拟数据自嗨。
人能补什么
既然Agent自己查自己有问题，那人能补啥？
课里列了几个——理解用户真正要啥（不只是字面意思）、在关键节点提出"是不是该换方向"、对Agent输出里"看起来对但细想有问题"的地方追问、基于经验直觉给出"这个方案我总觉得哪不对"的反馈。
然后形成一个循环：观察→判断→补充→核对→继续观察。
核心意思是——人不是替Agent干活，而是在Agent干活的过程中不断校准方向。就像开车，Agent是发动机，人是方向盘。发动机再猛方向错了也白搭。
还有个说法叫"读懂诊断"，具体是三个动作：追证据（Agent说有问题你得问证据在哪）、问机制（问题背后的原因是啥别只看表面）、比方案看结果（多个方案放一起比看哪个实际场景表现好）。
团队怎么组合
工程越复杂越需要组合不同专业深度，这个不会因为Agent来了就变了。
课里说了几种组织方式：
一种叫功能负责人，要理解从用户入口到数据运行的完整路径，不是啥都自己干，而是能把整条链路串起来。
一种是业务小组，持续负责一组用户结果，减少来回交接。这个跟敏捷里的"特性团队"思路差不多——一个小组从头到尾负责一个功能。
还有共享平台，维护共用的数据、权限、部署这些基础设施。
以及专业支持，处理一致性、复杂查询、可靠性安全这些特别深的问题。业务小组搞不定的，得专门的人来支持。
有意思的是课里还提了个趋势——业务人员能用Agent自己做原型验证想法之后，产研配合会分成三种情境：个人探索与原型、团队共享工具、跨团队或对外产品。越往后工程化程度越高，越需要专业技术团队介入。
做出功能不等于商业产品
这个观点我觉得值得单独说说。
很多人觉得功能做出来产品就有了。但课里讲得很清楚——做出功能≠商业产品。商业化需要同时满足三个条件：客户采用、持续交付、经营条件。
它用了一个嵌套关系来说明：原型是功能路径跑通（我能做出来）；产品是完整任务能持续完成（用户能持续用）；商业化是客户愿意买单且我们能持续提供服务。
原型是产品的子集，产品是商业化的子集。从原型期就应该开始验证客户价值，不是等做完了再想"有没有人要"。
这个其实跟我做淘宝店的体会很像。你商品上架了不等于能卖出去，得有人买、能持续发货、售后跟得上，这才叫做生意。（是不是扯远了……但确实是这么个道理。）
团队要积累啥
课里总结了五类需要持续积累的东西：领域和用户知识、系统和交付方案、质量和运行体系、可重复的方法流程、客户和经营经验。
但积累不是堆文件。维护这些知识有几个前提——来源和适用范围得写清楚，得有人负责维护，变了要及时更新，过时的要标明替代品。
不然攒下来的就是一堆过期文档，比没有还糟。这个我太有体会了，之前淘宝店的运营文档就是……算了不展开说了。
个人怎么积累能力
最后说说对我个人最有感触的部分。
课里给了三条建议。
第一条是多连接一段工作。别只盯自己负责那一小块，前端不要只看页面渲染，也去了解下后端数据逻辑、产品业务决策。连接的工作越多，判断力越强。
第二条是保留一项专业深度。虽然要做全栈要理解全局，但你得有一块是真懂的。不是啥都知道一点但啥都不精，而是在某个领域有足够深度。
第三条是执行前后记录预期和结果的对比。每次让Agent做事之前先写下你期望它产出啥，做完之后对比实际和预期。这样才能知道自己判断准不准、Agent能力边界在哪。
（说实话这三条看完我想了想，感觉自己开淘宝店那几年其实也在做类似的事——选品的时候调研市场是第一条，供应链管理是第二条，每次上架新品记录预期销量和实际销量的差距是第三条。换个场景道理其实是通的。）
这三条说到底就一个意思——Agent时代人的核心竞争力不是能写多少代码，是判断力。
判断力哪来的？从实践中来。从"我以为是这样结果发现不是"的反复校准中来。
收个尾
三节课下来最大的感受——AI Coding不只是用AI写代码那么简单。
第15课解决"怎么让AI写出正确的代码"，第16课解决"怎么让代码持续保持质量"，第17课解决"在AI能写代码的时代人应该干嘛"。
串起来就是一条线：先定义清楚做啥，再让Agent高质量做出来，做完持续维护改进——人要在每个环节提供判断力。
说句实在的，我之前一直焦虑前端会不会被AI替代。但这节课上完想了挺多——岗位消不消失其实不重要，重要的是你能不能提供Agent做不到的价值。
代码写得再快，方向错了也白搭。
嗯就这样。
