第一次看到“CS146S学习笔记AI时代的软件工程”这个题目是在某高校课程共享平台的热门榜单上。CS146S吸引我的点很简单——不是又一本教你怎么调API的教程而是真正把“软件工程”这门老学科放到大语言模型全面介入开发的背景下重新讲了一遍。学完整套内容回头看这门课解决的不是“怎么用工具”而是“当代码有一半不再由人手写时工程方法、团队协作、质量保障应该怎么重建”。这篇文章就把我整个学习过程整理出来涉及课程里的思考脉络、AI辅助编码的实操套路、测试与代码评审的新玩法、还有一路踩过的坑。适合正在用代码助手写业务代码、但又总觉得心里没底的开发者也适合准备把AI编码能力引入团队流程的技术负责人。读完之后最直接的好处是你能把“AI写代码”从个人体验升级成一套有章法的工程实践。1. AI时代软件工程的核心转向从写代码到做决策1.1 程序员角色的底层变化课程第一周讨论了一个很尖锐的问题如果大语言模型能完成大部分编码任务那软件工程师的价值还剩下什么答案不是“没人写代码了”而是“写代码”的权重在下降“判断、拆解、验证、权衡”的权重在上升。传统软件工程里需求分析、架构设计、编码、测试、部署是一条强顺序流水线。编码是体力密集环节也是大多数人最熟悉的环节。AI介入后流水线变成人类负责把模糊需求转化为清晰问题AI负责生成候选方案人类再负责审查和决策。CS146S里反复强调一个词——“human-in-the-loop”人在回路里不是摆设而是扮演验收者和把关者。举个具体的例子需求方说“做一个用户注册页”以前你要写表单、校验、接口对接、错误提示。现在你给代码助手一段上下文它能在一分钟内生成整页代码。看起来效率提升了十倍但问题变成了——“这段代码对不对”“它有没有漏掉接口鉴权”“错误提示文案是否合理”。这些判断能力恰恰不是简单“会写代码”就能掌握的而是需要对业务、系统边界、安全基线有整体理解。这门课第一个让我触动的观点就在这AI没有让软件工程师失业但确实让“初级重复编码”这个台阶变得很矮。过去靠熟练度建立的优势正在被模型能力抹平反而那些能定义清楚问题、能审查复杂代码逻辑、能设计可靠验证方案的人价值被放大了。1.2 课程整体脉络五个环节的重塑CS146S整门课把AI时代的软件工程拆成五条线需求、设计、编码、测试、运维。每条线在AI介入后都有明显变化我做一个简单的对照工程环节传统做法AI辅助下的新做法新的核心风险需求分析人工访谈、写PRD用对话式AI聚类用户反馈、生成需求草稿需求被AI错误“脑补”架构设计资深工程师主导AI生成多方案对比、影响面分析方案看似合理但脱离约束编码实现手写代码、静态检查结对编程、批量生成、自动补全代码质量问题隐蔽化测试验证人工设计用例、手写测试AI生成单测、模糊测试、变异分析测试“看起来过了”但无效运维监控人工看日志、定阈值AI日志分析、异常检测、故障摘要误报淹没真正的告警每个环节的变化不是孤立的。比如编码环节引入AI后测试环节必须跟上否则生成式代码的缺陷会以极低成本流入生产环境。课程里展示了一个案例一个AI生成的订单结算模块单看每一段代码都合理但组合起来存在重复扣款逻辑传统代码评审很难抓到因为它不是一个规则问题而是一个多文件状态流转的一致性问题。这个案例直接说明了为什么“AI生成代码人工随便看看”是最危险的组合。1.3 为什么现在必须重谈软件工程“软件工程”这个词诞生于上个世纪解决的是“软件开发失控”的问题。到了AI时代失控的形式变了。过去失控是“人写不完、进度爆炸”现在失控可能是“生成的代码太多了没有人能全部Review”。CS146S指出一个反直觉的观点AI最大的工程风险不是代码生成太少而是生成太多多到超出人的审查能力。所以这门课的管理学内核是“注意力预算”——人的审查注意力是稀缺资源AI应该被用来减少低认知负荷的工作比如写重复的样板代码、生成常规测试、格式化文档而不是用来批量制造需要人工逐行审阅的复杂逻辑。这个观点也直接影响了后面的实操选择哪些任务适合交给AI哪些任务一定留给人来做。2. 核心实操一提示词工程就是新型需求描述2.1 把提示词当成需求文档来写CS146S花了很大篇幅讲提示词工程但切入点不是“怎么写AI最喜欢的话术”而是“你怎么描述需求决定了你怎么验收结果”。这个思路很工程化提示词的本质是你对AI下达的一项需求说明。我实践下来一个合格的生产级提示词应该包含四部分角色或背景、任务目标、约束条件、输出格式。只写“帮我写个函数”这种等于你给实习生丢了一句“做个功能”就不管了结果一定不可控。我整理出一个简单模板这也是课程里最实用的部分背景我们有一个用户报名系统报名数据存储在MySQL的enroll表中字段包括id、user_email、course_id、status。 任务编写一个Python函数根据course_id查询该课程的所有有效报名者邮箱返回去重后的列表。 约束使用参数化查询防止SQL注入不使用ORM要求兼容Python 3.8如果查询异常返回空列表并记录日志。 输出只输出完整函数代码不输出解释用Markdown代码块包裹。这个提示词的效果比“帮我写个查询邮箱的函数”稳定得多。原因很简单背景消除了歧义约束限制了方案空间输出格式减少了返工。课程里把这个过程称之为“结构化需求描述”本质上跟写用户故事的逻辑是一致的。2.2 上下文管理的三个层次提示词写得再好上下文给不出来也是白搭。CS146S把AI助手的上下文分成三个层次理解这个分层对控制生成质量非常关键。第一层是会话内上下文也就是当前对话框里你说了什么。这个最简单但很多人不会用。我的习惯是先给项目整体说明再给具体任务。比如“这是一个基于FastAPI的仓库扫码系统数据库用PostgreSQL前端是Vue3”然后再提功能要求。为什么因为模型对任务的建模完全依赖它“看到”的内容你提供越接近“它需要知道的全部信息”生成结果越贴合实际。第二层是文件上下文代表你在IDE里打开或引用的具体代码文件。大多数现代编码助手能从打开的文件中自动提取符号和函数。这里有个实战技巧让AI修改某函数时一定要先手动打开该函数所在文件并把调用方文件也打开。因为你给了调用方代码AI才能判断修改是否会影响其他模块。只扔一个函数名让AI改等于盲改十次有八次要出问题。第三层是仓库级上下文就是AI能主动检索整个代码库。这个能力依赖工具链的索引和嵌入检索质量。课程数据给出一个参考开启仓库级检索后AI生成代码与现有代码风格的一致性提升非常明显但代价是响应时间变长、token消耗增加。所以我的建议是分层使用改单文件用小上下文跨模块加功能才开仓库检索不要全程开着否则又慢又费钱。2.3 代码审查的新姿势AI代写人要验收有了AI编码辅助之后代码审查模式也变了。以前是“人写人审”现在是“AI写、人审”审查的核心不再是读每一行语法而是关注逻辑正确性、一致性、边界条件。CS146S给了一个审查清单我复盘改动后觉得方向很对安全基线依赖是否引用了已知漏洞版本SQL是否拼接权限校验是否缺失业务逻辑生成的分支语句是否遗漏了状态组合与现有枚举、配置是否匹配资源管理文件句柄、网络连接、数据库会话是否有释放异常兜底异常分支是草草return还是打日志并走重试或补偿流程非功能约束性能、并发、可观测性是否符合团队已有规范。这套清单的价值在于把“人工审查”从逐行读代码重新定位为“抽查关键性质”。AI生成代码的大部分常规部分可以直接信任但关键性质必须由人来验证。我把这个原则叫“二八审查”80%的精力花在20%的关键路径上而不是对代码做地毯式扫描。2.4 一次完整的AI编码实操回放为了说明整套流程怎么落地我拿课程里的一个练习项目举例写一个带重试的HTTP下载函数。不用AI时我要自己考虑超时、重试间隔、临时文件清理。用AI时的标准动作是这样第一步明确需求边界。这个函数要支持多线程下载、断点续传吗不需要那就别写那么复杂。最终约束设定为单文件下载、支持超时、失败重试最多3次、下载完成后校验文件大小。第二步构造提示词。包含背景Python 3.10, 使用requests库、任务描述、约束条件重试间隔用指数退避、日志输出到logger、非2xx状态码视为失败、输出格式要求。第三步拿到AI输出后不经大脑直接验收。我特意盯了几个点重试循环是否在成功时break、超时异常是否被捕获、临时文件是否在finally中清理。结果AI生成的代码第一版在“非2xx状态码重试”这个分支处理得不够好它只对连接异常重试没考虑HTTP错误码。这是很典型的AI生成缺陷——技术栈正确但需求覆盖不完整。第四步把缺陷反馈给AI有针对性描述“如果resp.status_code 400应该视为失败并继续重试逻辑”第二轮生成的代码就正确了。这个案例说明了一个结论AI编码不是一次生成就完事而是一个“生成-审查-反馈-再生成”的闭环。课程把这种交互方式称为“迭代验收”它和传统“编码-测试-修复”的流程本质上一致只不过循环内每轮耗时从小时级降到分钟级。3. 核心实操二测试生成与质量保障的新路径3.1 AI补全单元测试的正确姿势AI生成测试代码是我认为在当前阶段价值被严重低估的场景。很多团队对“AI写业务代码”充满警惕但愿意接受“AI写测试”——因为测试代码出错的影响面相对小而且测试本身就是用来发现错误的哪怕生成质量一般亏损也有限。实操上AI补单测要给出三类关键信息被测函数签名、需要覆盖的分支行为、mock的外部依赖。比如我要为一个登录接口写测试AI需要知道这个函数接受username和password成功时返回token用户不存在返回404密码错误返回401数据库连接异常返回500。把这几个行为写进提示词AI生成的测试用例就能精准地覆盖代码路径而不是生成一堆无效的“烟囱测试”。课程里给了个很直白的比喻“AI生成测试就好像让新人照着需求文档写用例他写得又快又多但你需要审他覆盖了哪些场景而不是看他写了多少行。”3.2 覆盖率焦虑有效测试才是关键AI能快速拉高行覆盖率但行覆盖率从来都不等于测试有效性。CS146S引用了一个常见案例一个函数有if-elif-else三分支AI生成三个测试用例每个分支都打上一行覆盖率100%但每个用例只验证了“没有崩溃”没有验证返回值是否正确、状态变更是否符合预期。这种测试在覆盖率统计上很漂亮在缺陷捕捉能力上基本为零。课程引入了变异测试的思路作为应对办法通过引入缺陷变体比如把改成、把and改成or看现有测试能不能把它们杀死。如果一个变体没有被测试发现说明这块行为没有被有效验证。实操中我用过变异测试跑起来很慢但可以抽取核心模块来跑。AI在这个场景下同样可以做辅助——它可以帮我们分析“为什么这个变异体没被杀死”省去大量人工翻测试代码的时间。我自己的经验是与其追求AI生成全部测试不如让AI先做“用例设计”再人工确认再由AI把已确认的用例翻译成测试代码。这个流程把人的业务判断力和AI的速度结合得最好。3.3 在CI流水线里让AI发挥稳定作用把AI嵌进CI流水线是CS146S里比较有工程实践深度的一部分。传统CI跑静态检查、单元测试、构建、部署预览AI还能加进去什么课程给出三个可行性较高的切入点第一自动生成release notes。Git提交信息往往写得潦草让AI对比本次合并的commit与上一个tag之间的差异整理成面向产品人员的更新说明准确率很高能省下不少人工整理时间。第二自动化代码风格建议。不是替代ESLint那种强规则工具而是做“语义层”检查。比如发现重复代码块AI可以提示“这两个函数逻辑相似是否考虑提取公共方法”这种建议比单纯静态检查更接近代码评审。第三复杂变更的测试建议。当一次MR改了多个模块时AI可以根据变更文件推断影响范围建议需要重点回归的测试路径。这个能力虽然不能保证全覆盖但对大仓的冒烟测试选择很有帮助。接入方式上课程建议用异步任务而非阻塞任务。AI分析耗时不稳定直接卡在CI关键路径上会拖慢交付更好的方式是把AI分析结果作为MR的附加评论让开发者自行查看而不是让CI因为AI分析超时而失败。4. 工程化落地把AI编码能力接进真实项目4.1 工具链选型三类工具的定位差异课程第四周开始讲工程落地第一个问题是工具选型。现在市面上的AI编码工具看起来五花八门但抽象下来只有三类代码补全工具、对话式助手、自动化Agent。它们不是同一个东西混用概念最容易翻车。代码补全工具擅长的是“你写开头它续写”最适合内联实现样板代码、重复结构、常规CRUD决策成本低但藏在IDE角落缺少全局视角。对话式助手擅长的是“你描述问题它生成方案”适合重构、解释代码、生成测试、跨文件修改但需要开发者主动组织上下文。自动化Agent擅长的是“给定目标多步自动执行”可以自动跑测试、自动修改多文件、自动提交MR但现阶段稳定性不够非监督状态下很容易做出“看起来完成了、其实没完成”的事。我的选型建议是日常编码以补全工具为默认重活用对话式助手Agent只用于低风险的自动化场景批量格式调整、机械性重构、文档生成。三者选型对比我做了一张表方便直接对照参考类型典型能力优势风险适用阶段代码补全行内预测、短片段续写零打断、辅助流畅缺乏全局语义日常编码默认对话式助手多文件生成、重构、解释上下文可控、结果可审查依赖提示词质量设计、重构、测试自动化Agent自动执行多步骤任务省人力、批量处理不可控、易跑偏低风险自动化4.2 分阶段引入策略试点、建模、铺开、治理团队引入AI编码最忌讳一步到位全员强制。CS146S的路径建议是分四个阶段走。第一阶段试点选3到5个对新技术接受度高、且代码库模块边界清晰的开发者让他们在低风险模块中尝试AI辅助产出实际效果报告。重点是收集两个数据人均节省时间、生成代码被返工的比例。第二阶段建模根据试点数据建立使用规范。规范要回答几个问题什么场景允许AI生成什么不允许、AI生成代码的审查流程是什么、需要保留哪些人为检查点。我最重视的是“不允许场景”比如未经评审的依赖升级、涉及支付与权限的代码不允许直接AI生成后上线这类红线必须提前划好。第三阶段铺开把规范和工具推广到整个团队配套做培训。培训内容不仅仅是教工具按钮而是教“如何写合格提示词”“如何审查AI代码”“如何反馈修正”。门槛比想象中高不能默认大家看一遍文档就会。第四阶段治理建设反馈闭环。收集AI辅助代码的数据、缺陷率、处理时长周期性复盘看哪些环节AI确实产生了价值哪些环节反而拖慢了节奏。治理不是为了管人是为了让AI的使用方式随业务和技术演进持续迭代。4.3 安全与合规问题边界线在哪AI写代码的另一大工程挑战是安全和合规。CS146S提醒了三个容易被忽视的点。一是敏感信息泄露。开发者把数据库连接串、API密钥、内部域名贴进对话窗口等于把秘密交给了第三方。这个问题的预防不能靠自觉必须靠机制——本地部署私有化模型或接入公司统一网关的脱敏中间层。课程提供的建议是所有包含密钥、内网拓扑、客户数据的代码片段禁止直接粘贴进公网工具统一走内部代理。二是开源许可证污染。AI生成代码时可能“借鉴”了受限制许可证的代码段。实操中这个风险概率不高但因为不可追溯一旦发生很难处理。课程建议是在依赖引入和关键代码上线前用许可证扫描工具过一遍至少避免“听AI推荐引入某个包就直接装”的情况。三是供应链风险。AI推荐的依赖版本一旦被模型“幻觉”出来一个不存在的版本号就会对构建系统造成直接伤害。这个问题我在实践里真实遇到过后面会专门讲排查过程。核心对策是依赖锁定和可信源校验AI推荐的新包必须去官方源或公司私有源核实版本号后再引入。5. 常见翻车现场与排查经验实录5.1 问题速查表AI辅助开发用得越多翻车次数越多这是正常现象。CS146S没有回避这个问题反而用一整节课复盘高频故障。我结合自己的实操整理出一个速查表症状可能原因排查方向解决建议生成的代码调用不存在的API模型训练数据滞后用官方文档核对函数签名让AI读取当前SDK文档再重新生成修改一个文件却破坏另一个文件上下文缺失调用方代码检查影响面打开关联文件后再让AI修改AI反复生成同一个错误修复反馈信号不明确检查提示词是否包含错误现象和期望行为给出最小复现样例编造一个不存在的依赖版本模型幻觉去包管理源核实版本替换为真实存在的版本并锁定测试用例“看着过了”但缺陷率上升断言太弱检查测试是否验证返回值用变异测试评估断言有效性对话长了之后回答质量下降上下文窗口污染将原始需求重新声明开新会话并重贴关键约束AI生成的代码风格与项目不一致缺少项目规范说明检查是否提供了风格指南在提示词中粘贴代码风格片段这张表的核心逻辑是不要对着AI的输出做“玄学排查”所有问题都要先回到“输入是否完整、约束是否明确、上下文是否足够”这三个维度去找原因。我统计过自己的翻车案例八成以上出在上下文缺失不是AI能力问题而是我给的素材不够。5.2 实录一次AI修复失败里的完整排查栈我印象最深的一次翻车是让AI帮我修复一个并发写入bug。需求是“某个高频接口偶发数据覆盖需要加锁保护”。我用对话式助手提交了原代码片段让它加线程锁它给出的建议是在函数内部直接加一个普通的互斥锁生成的代码看起来也很完整。结果上线前做压力测试问题不但没解决反而出现了新的死锁。排查过程我复盘下来发现了三层问题。第一层原代码里已经有另外一把锁AI只看到了我粘过去的那段函数没看到全局锁的调用顺序于是新锁与旧锁形成交叉请求直接死锁。第二层AI在加锁时把锁的粒度扩大到了整个函数而函数内部有一次耗时很长的外部网络调用锁被长时间持有并发能力比不加锁还要差。第三层AI生成的finally里释放锁的部分被异常分支提前返回绕过了虽然没有彻底锁死但等锁线程全部卡住。这个案例让我彻底理解课程里强调的那句话“AI只能优化你给它的局部不能感知你省略的整体。”这次之后凡是涉及锁、事务、异步状态流转这类并发问题的修改我再也不直接让AI动手而是让AI列出可能的影响点由我人工设计修改方案AI只负责实现我明确指示的改动。5.3 我个人的避坑心得最后说几条个人体会都是踩出来的经验。第一永远不要用“AI说可以”替代“测试说可以”。AI的语言自信程度和代码正确性没有相关性。哪怕它用非常确定的语气说“这样修改没有问题”也必须走完整测试流程。我见过很多新手被AI的自信语气带偏省掉了本地验证步骤结果把问题直接带上线。第二给AI的反馈要对事不对风格。AI生成代码不符合预期时不要笼统说“不对”“重新来”而是指出具体偏差——“这里的错误处理方式与项目现有风格不一致应该沿用utils目录下error_handler的模式”。反馈越具体修正效果越好。把AI当作一个记忆力不错但缺乏常识的实习生来沟通准确率会提升一个台阶。第三工具再多核心还是人能不能定义出好的问题。CS146S整门课最打动我的点在于它没有把AI吹成万能钥匙而是反复提醒定义问题的能力、审查结果的能力、判断何时不需要AI的能力才是AI时代软件工程师真正的护城河。我个人在实操中还保留了一个小习惯每次让AI做有状态的改动前我会先在注释里写下“这段代码改变前和改变后的行为分别是什么”这个行为倒逼我理清了大量隐式约束也让AI生成方案的准确率高了很多。虽然CS146S结课了但这个习惯我一直留着——它比任何模型参数都管用。