在微信推荐里刷到了CS146S，感觉可能会跟我们这个号讲过的内容比较重合，就去刷了一下，发现确实如此，并且更成体系。 以下为我们对课程各周内容的感想。因为没有课程视频，所以信息来源仅限于网站[1]上的slides/readings/assignments。 Week 1: Introduction to Coding LLMs and AI Development
主要讲提示词工程。作业里则一上来就要让大模型反转字符串或是计算ModPow。 我们觉得传统的程序员在这时可能会觉得沮丧：自己明明知道问题有很明确的解法，为什么还要依赖大模型这样低效且不确定的结果？ 但工具不好用也可能只是使用方式不对，好比拿着锤子拧螺丝。大模型擅长和不擅长的地方同样突出。因为模型存在不擅长的地方就排斥，跟因为模型存在擅长的地方就盲目崇拜一样，都是不可取的。我们之前也提到过： 尽管有着各种问题，但至少大模型在处理非结构化数据方面的能力是实打实的，尤其是最早被应用到的NLP领域。那么要想在现有的系统中利用这种提升的能力，程序员们就得接受系统中存在这样带有随机性的黑盒，并想办法得到更确定性的结果。
Week 2: The Anatomy of Coding Agents
也讲了很多MCP的好处。但我们觉得可能没有讲到点子上（MCP不过是另一种RPC ）。并且我们认为MCP并没有达到设计目标。比如原本是希望能够无缝接入更多工具的，但其实工具越多占用上下文就越多，调用失败的情况就会更多。 此外看了下课上工具的实现，发现编辑文件的工具接受的参数是(oldStr, newStr)。我们之前也在工具参数上走过弯路（手把手教你零成本抢前端同学的饭碗 ），对于这样的不统一也发表过看法： 从兼容层的角度来看，大模型的harness壳和前端项目使用的各种polyfill本质是一样的：随着模型能力的增强，harness提供的部分功能可能就没有必要存在了；同样随着web标准的普及和实现，polyfill中的功能也没有必要存在了。
模型厂商通常都会鼓吹“模型会吃掉一切”，但如果参考web标准实现的现状来看的话，结果会如何可能并不好说。
所以在我们看来至少在harness上面可能还有很多前端同学们熟悉的工作需要做。
Week 3: The AI IDE
提到一些现在应该是被归到harness的东西。比如告诉Agent要如何验证工作的正确性。我们提过好多次了： 可以验证结果的环境. 对于Agent来说是关键. 会犯错没关系, 毕竟人也经常会犯错, 顶多影响些效率. 但不知道自己犯了错才是致命的. 有可验证结果的环境的话就可以让Agent不断自主尝试直到做对.
还有讲压缩上下文，通过子代理减少上下文污染等，我们之前也写过： 子Agent返回时只需要返回最后一次的输出, 而不是全部的上下文. 因为通常最后一次输出的就是Agent完成工作后得到的最终结论. 在我们的例子里, Agent可能会调用工具读了很多源文件, 而这些源文件的内容就不需要被返回给父Agent造成上下文污染了.
不过提到的有一点我们一直抱有怀疑，就是把spec当作SSOT（Single Source of Truth），然后就开一堆Agent根据spec去并行生成代码，看上去是种刷Token消耗榜的好方法 于是版本管理的对象也变成了spec。代码被当成了一次性的东西，因为有些人觉得代码生成的成本会足够低。 然而我们觉得但凡有点码龄的应该都记得历史上的类似尝试。比如曾经也有些人觉得软件的整个生命周期都可以用UML来描述，其中代码可以由UML自动生成。 既然我们现在还在讨论同样的问题，那就说明历史上的类似尝试都是不成功的。就看是不是“这次不一样”吧 Week 4: Coding Agent Patterns
主要讲CC的使用。还提到CC会经常在会话里注入system reminder标签来防止对话跑偏。 我们的看法是谁爱用谁用，反正我们不用 Week 5: The Modern Terminal
演示Warp。感觉是个在国内没啥热度的工具。号称优势是零迁移成本，因为终端是开发者日常都会使用的。 对于终端的好处我们是认同的，但产品形态就有些尴尬了。比如现在各种TUI的壳，都会自带执行终端命令的功能。执行的命令和返回的结果最后都会留在会话里，形成完美的上下文，不需要从别的窗口里复制粘贴。 但现在模型厂商都自己下场做壳，就会搞得第三方工具一边使用厂商的模型，一边跟厂商自己的工具竞争。有的厂商还会封杀第三方工具 Week 6: AI Testing and Security
回过头来想想这可能也是个自然的结果。原本漏洞扫描工具做的就是模式匹配，而这正是大模型擅长的地方。并且挖洞是一件高杠杆的事，攻击者只需要成功突破一次，而防御者则需要全面防守。 此外还提到了大模型本身也成为了攻击面的一部分，比如提示词注入。我们之前也提到过： 更致命的问题在于大模型提供了新的攻击面. 提示词注入问题在本质上无法解决. 因为大模型无法区分提示和数据, 对于大模型来说都是上下文. 用软件来类比的话就好比是脚本语言中的eval函数, 接受的数据也是可以被执行的代码, 因为会带来各种安全问题而不被推荐使用.
说到这个份上其实已经可以想到很多缓解的方法了。有机会可以再水篇文。
Week 7: Modern Software Support
主要讲code review，以及AI如何辅助这项工作。提到code review的一个重要功能是mental alignment。 那我们觉得由此可以得到的推论应该是code review不能完全交给AI去做，否则就是AI自己跟自己去对齐了。 假如AI助理可以全权代表你操作设备了，那AI助理要是闯祸了开发商能背锅吗？如果AI能背锅的话那要是我闯祸了能甩锅给AI吗？这就类似目前自动驾驶面临的问题。车自己在开的时候要求人类随时准备接管，要是没有接管出了事情车企就不会担责。
如果哪天软件出了致命的bug，作为责任人的你看不懂AI写的代码，AI在那边不停烧token但还是改不好的时候又要怎么办呢？
所以我们觉得除非模型厂商能打保票说出了任何bug都可以兜底，否则就必须自己review AI生成的代码。就好比在车企能打保票说用了自动驾驶后发生任何事故都可以兜底之前，必须自己掌控方向盘一样。 但guest talk的slide里又是把全自动review当成目标的。所以对于商业公司的pitch不要太当回事了 此外，mental alignment还有一层含义是在review的过程中也可以学习。我们之前也提到过： 就拿编程语言学习来说，学习的并不是语法，而是惯用法。因此被投喂了全人类数据的AI应该是最清楚人类的惯用法是什么样的。
Week 8: Automated UI and App Building
老实说我们认识的前端同学平均能力都在后端之上，尤其是跟那些只会用Spring却不会写Java的所谓后端相比 但另一方面，能力更强应该也会越容易往别的方向迁移。前端同学们加油 Week 9: Agents Post-Deployment
只有真正经历过软件全周期的才会知道，coding只是周期中的一小部分。所以要是看到有人觉得因为AI能写代码了所以软件就要死了，笑笑就可以了 另外Agent需要先感知再采取行动，为了能感知系统的状态，系统的可观测性就一定要做好。这也是我们在公司引入AI之后一上来先重新搓了可观测设施的原因（从一个例子看AI编程提效这件事 ）。 Week 10: What's Next for AI Software Engineering
没有任何公开资料放出。所以我们也不知道讲了些啥。嘉宾是a16z的GP，内容好难猜阿 所以要说这课里有什么新东西么好像并没有。可能任何有经验的程序员花上一段时间体验下最新的AI大模型都可以得出类似的结论。但前提是不排斥AI，并且去亲自尝试。 我们觉得其中一个很有意思的点就是，课程上讲的都是AI通过干脏活累活来辅助人，但请来的商业公司的嘉宾大都在说怎么让AI全自动干活。观点越是这样割裂，个人就越需要保持清醒的判断，而不是被人牵着走吧。 [1] CS146S: The Modern Software Developer
https://themodernsoftware.dev/
夜雨聆风
可能跟前端更卷竞争更充分有关。都已经那么卷了还要被AI冲击，实在是太惨了
