今年我完整跟完一门编号为CS146S的课程，主题就是“AI时代的软件工程”。本来我以为这又是一门教你怎么用AI写代码的工具课，结果越听越发现，它真正在讨论的是另一个问题：当代码的生产方式从“人写”变成“人审、AI写”之后，软件工程那些老规矩还有哪些仍然成立。这门课给了我一个很明确的答案——绝大部分老规矩依然成立，只是执行顺序和关注重心变了。这门课适合谁？我觉得有三类人收获最大：正在用AI辅助开发但总觉得不可控的工程师，负责AI产品落地但说不清怎么保障质量的技术管理者，还有打算系统梳理AI开发流程、不想只停留在“会调API”层面的学习者。它不是教你某个具体模型怎么用，而是教你一套在AI语境下依然能打的工程方法论。1. 这门课到底在讨论什么：AI没有推翻软件工程，只是重排了优先级课程第一周就抛出一个很扎心的问题：如果一个AI能一天生成几千行代码，那还需要软件工程吗？听起来好像不需要，但我身边真实发生过的场景是：团队用AI快速拼出一个系统，结果没人说得清楚它为什么这么写、改哪条逻辑会炸、怎么证明它是对的。这恰恰是软件工程存在的理由。所以这门课的核心立场很鲜明：AI不会让软件工程消失，只会让软件工程的重心从“关注怎么写代码”转向“关注怎么证明代码是对的、怎么控制不确定性”。1.1 传统软件工程的核心问题，在AI时代原封不动很多人以为AI能把需求模糊、复杂度失控、质量保障这些老问题一并解决，事实恰好相反。需求不确定性反而更严重了。以前用户说“做一个订单列表”，你还能掰扯清楚字段和状态；现在用户说“做一个智能助手”，边界在哪里完全靠猜。AI的能力范围是个开放集，需求方很容易把期望抬高到“它什么都能干”，而工程方必须把它拉回“它只能在这些场景下可靠工作”。这是最花时间、也最容易被低估的一环。复杂度管理也一点没减少。AI生成的代码越多，系统里互相牵连的隐性依赖就越多。代码量不是衡量复杂度的标准，调用关系、数据流、外部依赖才是。模块划分、接口设计、分层隔离这些基本功，在AI写的代码堆里反而更重要，因为AI不会替你承担架构责任。质量保障更是如此。以前测试是在验证“实现是否符合规格”，现在测试还要多问一句“这个输出是否在可接受范围内”。传统测试的确定性断言依然需要，但远远不够。质量的定义变宽了，质量保障的手段必须跟着扩展。协作与沟通的老问题也在换皮重现。AI生成代码之后，代码评审不再是“看一个人写得对不对”，而是“看AI写的这段合不合业务预期、有没有埋雷”。文档、设计评审、变更管理这些流程不是被简化了，而是被重新发明了一遍。1.2 变的不是目标，是“确定性”这个前提为什么AI会让软件工程产生这么多连锁反应？根源在于一个前提变了：传统程序是确定性的，同样的输入必然得到同样的输出；而AI模型是概率性的，同样的输入可能给出不同的结果。这个变化看起来不大，影响却是全局性的。维度传统软件AI赋能的软件输出行为确定性，可精确断言概率性，只能约束范围调试方式断点定位、日志追踪提示词排查、数据排查、上下文排查测试重点功能逻辑与分支覆盖输出质量、边界治理、稳定性异常处理明确错误码与异常类型超时、重试、降级、兜底策略回归保障自动化测试用例评测集+自动化用例双轨这个表格基本就是整门课的地图。后面聊的测试、架构、评审，都是在围绕“概率性输出如何进入确定性系统”展开。1.3 我理解的全景图把课程主线压缩一下，其实就四条：AI辅助开发怎么用才靠谱、AI应用的测试与质量怎么保障、AI原生系统怎么设计架构、AI进入团队后协作流程怎么改。这四条也是我下面要展开的内容。2. AI辅助开发的正确打开方式：别把大模型当成编译器课程里有一句话我记了很久：把AI当成编译器，你会收获一个满嘴胡话的编译器；把AI当成一个能力很强但经常犯迷糊的新同事，你才知道怎么跟它配合。这句话太真实了。我用AI辅助编程有一段时间了，最大的感受是：它的产出质量和你的使用方式强相关。不是“问得越多越好”，而是“问得越结构化越好”。2.1 我在实践中常用到的三层用法第一层是局部代码生成。处理样板代码、格式化逻辑、简单工具函数这种低风险任务，AI基本稳得可怕。比如写一个日期范围拆分的函数、把一段混乱的配置整理成结构化的对象，这类需求边界清晰、验证成本低，直接交给AI生成能省不少时间。第二层是代码理解与重构。我经常拿一段自己不熟悉的代码问AI：“这段逻辑的入口在哪里？数据流是什么？有没有可以拆分的点？”这种用法下，AI更像一个可以随时对话的代码阅读助手。注意，它给出的理解结论不一定全对，但能帮我快速建立初步认知，再用调试工具验证一遍，效率比从头啃高很多。第三层是测试与文档生成。让AI根据函数签名和业务描述生成单元测试骨架、生成接口文档、生成变更说明，这些都是AI非常擅长的。但我不建议让AI在没有人review的情况下直接产出业务级测试断言，原因后面专门说。每层用法都有一个共同前提：你要有能力判断AI输出对不对。这不是劝退，而是提醒。如果你自己完全看不懂一段代码，AI生成的代码对你就是纯风险。2.2 提示工程在软件工程里不是聊天技巧，而是需求规格很多人把写提示词当成聊天技巧，其实在工程场景里，提示词就是一份需求规格说明书。你在提示词里写清楚了角色、上下文、输出格式，AI的行为才会收敛到你预期的范围内。我自己的标准模板是三段式：角色定义、任务上下文、输出约束。举个例子，我经常用AI做代码评审预览，提示词是这样写的：请以一名资深代码评审员的身份，审查下面的代码片段。 按【正确性】【安全性】【可维护性】【性能】四个维度输出问题清单。 每个问题必须包含：严重级别（高/中/低）、问题定位（文件+行号或函数名）、修复建议。 不要输出任何赞美性语言，只输出问题和建议。 没有问题时，直接输出“未发现明显问题”。 代码片段： <在这里粘贴代码>为什么这么写？角色定义让AI调用专业领域的知识框架；任务上下文让它知道审查范围；输出约束让结果可以直接进追踪系统。对比一下，如果你只是说“帮我看看这段代码”，它很可能给你一堆正确的废话，你还要自己再筛一遍。2.3 涉及大段代码时怎么管理上下文这是AI辅助开发里最容易被忽视的坑：上下文不是越长越好。模型对过长的上下文会产生注意力衰减，也就是“中间段信息被忽略”，尤其是当代码量大、逻辑复杂的时候。我的做法是分块提交。先把文件结构梳理清楚，再把有疑问的模块、函数单独摘出来提问。对需要全局信息的问题，先让AI分别处理几个局部，再让它做汇总推理。比如“分析这个服务的调用链”，我不会把整个仓库丢进去，而是先让它分别梳理入口、业务层、数据层的关键路径，最后再合并。还有一个小技巧：在提示词里明确引用依赖关系。只贴代码片段而不说明它依赖什么库、什么接口，AI生成的答案就可能基于错误假设。给它一行说明“这段代码依赖某个模块的某某函数，请结合这个约束分析”，准确率会明显提升。3. AI时代的测试策略：从人工断言到“用AI测试AI”课程里有一句贯穿始终的话：AI应用测试的难点不是覆盖代码行，而是覆盖“输出的合理程度”。传统测试用例是“跟预期结果比”，AI测试用例是“跟用户可接受的范围比”。这句话让我想通了很多以前模糊的问题。AI应用不是不需要测试，而是测试要做的事情更多、更难了。3.1 传统测试的基本盘不能丢先泼一盆冷水：AI写得再快，单元测试、集成测试、回归测试这些基本盘依然不能丢。理由很简单——AI生成代码只是改变代码的生产方式，没有改变代码要正确运行的底线。我见过很多团队，用AI生成了一堆代码，然后测试覆盖率接近零。原因是“AI生成的代码还要测什么”？结果一上线就出问题。AI生成的代码尤其需要测试，因为你不知道它是基于什么假设写出来的。单元测试是对AI输出的一种实时校验，也是后续重构的安全网。我的建议是：无论代码是不是AI写的，测试策略严格按照工程标准来。每个核心函数要有单元测试，模块间要有集成测试，主流程要有端到端测试。AI可以帮你生成测试骨架，但测试的标准必须由人来定。3.2 AI生成测试用例：能做什么，不能做什么AI生成测试用例的能力已经不错了，但边界要搞清楚。能做的事情包括：根据代码结构自动生成覆盖分支的用例、生成各种mock数据、构造边界输入（空值、超长字符串、负数字段）。这些是模式匹配任务，AI做得又快又好。不能做的事情更关键。AI不知道你的业务预期是什么，它判断不了“这个输入下正确结果应该是多少”。让它生成测试用例，经常会出现断言值是从代码实现里反向抄过来的情况，也就是“用实现验证实现”，这种测试等于没写。另外，数据隐私、合规边界这些业务规则，AI也无法替你把关。所以AI生成的测试用例必须经过人工review，重点就是要看断言是不是符合业务预期，而不是只看有没有跑通。3.3 面向LLM应用，测试要新增四个维度如果系统里接入了大模型，传统的测试维度是不够的。我在这门课里学到并验证过的四个新维度，值得直接抄进自己的测试计划。第一是输出结构校验。模型输出经常“有噪音”，该是JSON的时候给你夹带解释文字，该是枚举值的时候给你自由发挥。输出结构不校验，下游解析迟早翻车。这个维度在集成测试里就跑，不用等线上。第二是幻觉与事实性检测。特别是生成摘要、抽取信息的场景，要检查输出里是否出现了输入材料中完全没有的事实。简单做法是抽几个关键实体做比对，比如生成内容里提到的人名、机构名、时间点，去原文里找对应。第三是稳定性测试。同一个输入问三次，输出了三个不同答案，这在聊天场景也许还能忍，但放在金融、客服、审批场景就是事故。稳定性测试要设置可接受的波动范围，差的场景必须收敛。第四是成本与性能阈值。LLM应用的响应时间和token消耗是动态的，测试用例里应该包含“这个请求不能超过多少token、多少毫秒”的硬性指标。成本失控往往不是某一次调用贵，而是没有为单次调用设上限，数量一起来就爆了。3.4 一个简单的回归评测集思路换提示词、换模型、调参数，都可能让效果变好，同时让另一个场景变差。我习惯把关键输入输出沉淀成一个评测集，每次改动后跑一遍。EVAL_CASES = [ { "prompt": "请总结这段新闻：...", "must_contain": ["关键人名", "核心事件"], "forbidden": ["虚构机构", "编造时间"] }, { "prompt": "请用中文回答：...", "must_be_language": "zh", "max_tokens": 100 }, ] def run_eval(call_model, cases): failures = [] for case in cases: output = call_model(case["prompt"]) for keyword in case.get("must_contain", []): if keyword not in output: failures.append(f"缺少关键信息: {keyword}") for banned in case.get("forbidden", []): if banned in output: failures.append(f"出现不应有的内容: {banned}") if len(output) > case.get("max_tokens", 1000): failures.append("输出超长") return failures这个脚本很简陋，但理念是对的：把“输出质量”变成可以度量的任务。评测集不怕简单，关键是要持续积累。我每次处理用户反馈、线上问题，都会顺手把案例补进评测集，时间长了，这就是你团队真正的质量资产。4. AI原生系统的架构设计：把不确定性关进笼子里“AI原生”这个词现在有点被用滥了。在我看来，真正的AI原生不是“调用了大模型API就算数”，而是整个系统架构从设计第一天就接受了“模型会犯错、会超时、会换版本、会行为漂移”这个前提。这门课花了不少篇幅讲架构，核心就一句话：把不确定性关进笼子里，别让它顺着代码流得到处都是。4.1 调用层要做防腐设计很多团队在一开始图方便，让业务代码直接调用某个模型供应商的SDK。等哪天要换模型、换供应商，或者对方改了一个参数语义，你就得满项目去找调用点改代码。正确做法是加一层防腐层，把模型调用封装成一个内部接口。业务代码只认识这个接口，不关心背后用的是哪家模型。class AIModelClient: def __init__(self, provider, primary_model, fallback_model=None): self.provider = provider self.primary_model = primary_model self.fallback_model = fallback_model def generate(self, prompt, temperature=0.2, max_tokens=500): try: return self._call_primary(prompt, temperature, max_tokens) except TimeoutError: if self.fallback_model: return self._call_fallback(prompt, temperature, max_tokens) raise except RateLimitError: # 可以考虑加退避重试，或降级到缓存结果 return self._fallback_with_cache(prompt)这一段代码的核心作用有两个：一是隔离变化，换模型、加参数都不影响业务层；二是统一处理异常，把超时、限流、无结果都收敛到一个地方。没有这层壳，AI应用就像没装保险丝的电箱，小故障也能烧掉整片电路。4.2 上下文工程：Context才是AI应用的数据库课程里有个观点我特别认同：对AI应用来说，上下文就是数据库。模型的输出质量，很大程度上取决于你给它喂了什么样的上下文。但上下文不是越多越好。很多团队为了“让模型更懂业务”，把超长文档、全部历史对话一股脑塞进prompt，结果模型反而抓不住重点，成本还飙高。我对上下文工程的理解是三个动作：检索而不是全量塞入。需要知识库的时候，用检索拿到最相关的几段内容，而不是把整个知识库塞进去。这就像给人查资料，你不会扔给他一整座图书馆，而是给他翻到正确页码的几页纸。摘要而不是保留全文。长对话场景下，历史消息超过一定轮数后，把之前的对话总结成结构化摘要，保留关键信息，丢掉冗余。分层而不是平铺。上下文按“系统指令+用户意图+参考材料+工具结果”四块组织，让模型知道哪部分是必须遵守的规则，哪部分是可参考的资料，哪部分是当前要处理的任务。结构化上下文比一大段散文式的描述靠谱得多。4.3 可观测性与成本控制AI系统的排障思路和传统系统很不一样。传统系统可以依赖日志和断点复现问题，AI系统的问题往往是“同样的输入，结果时好时坏”，这时候没有记录就别想排查。我的做法是给每一次模型调用记录四件事：模型名称和参数、输入token和输出token、响应耗时、返回结果摘要。日志里有了这些，用户反馈一个问题时，你才能回答出“当时模型收到的是什么、输出的是什么、花了多少钱”。成本控制也有一个实用策略：路由分层。不是所有请求都需要用最强的大模型，简单的文本分类、关键词抽取、格式整理，用小模型处理又快又便宜；复杂的推理、长文总结、代码生成，再调大模型。再配合缓存层复用重复请求，总体成本能降下来不少。我遇到过一次线上事故，就是因为某次调整无意中把一大段历史信息加进了prompt，导致token消耗翻倍、响应延迟明显变高。没有日志记录，这个问题排查起来会非常费劲。这也是我坚持“一切调用皆可观测”的原因。5. 团队协作与代码评审：AI产物的“人机共同评审”AI进入团队之后，最容易翻车的环节是代码评审。因为AI生成代码有一种很强的说服力：格式干净、注释齐整、命名规范，看上去非常专业。但逻辑漏洞、隐藏依赖、安全风险，恰恰藏在漂亮的外壳下面。这周课上讨论的很多案例都指向同一个结论：AI时代，评审不是变轻松了，而是变重了。以前评审是人和代码之间的事，现在变成了人和AI之间的博弈。5.1 人审什么：四个不嫌多的检查点我给自己总结了一套固定的AI代码审查清单，不管AI生成什么代码，都按这四关过一遍。第一关是正确性。看边界条件是否处理了，空值、重复值、异常输入下会不会崩。AI经常在“看起来正常”的路径上表现良好，但在边界状况下露出破绽。第二关是安全性。权限校验写没写？敏感数据有没有泄漏到日志或模型输出？那些看起来无害的AI生成代码，可能恰好绕过了原本的安全控制。第三关是合规性。引用的开源代码许可证是否允许我们这么用？模型输出的内容是否涉及数据权限？AI不会主动告诉你“这部分代码可能来自某个你没有权的来源”，这个只能人来确认。第四关是可维护性。这段代码是不是重复造轮子？抽象得是否过度？有没有引入不必要的复杂依赖？AI容易生成表面统一、实际孤岛式的重复代码，时间长了就是技术债的温床。5.2 把AI接入现有研发流程的正确姿势AI不该替代流程，而是嵌入流程。我比较认可的几种姿势是：在代码评审前，用AI做一个变更摘要。特别是大范围的改动，AI可以自动生成“这个PR改了什么、影响哪些模块、可能的引入风险”，评审人先看摘要再深入，效率高很多。在CI流水线里，加一道AI静态检查。跑的维度就是刚才说的正确性、安全性、可维护性，但注意AI检查的结果是“建议”，不是“结论”。所有告警还是要有人确认后再处理。在提交环节，用AI生成变更说明和文档补充。这个收益是最直接的，Commit Message和接口文档能跟上代码变化，是小团队最容易欠的债。一定要记住：AI在任何流程里都只做“预审”和“建议”，最终拍板的必须是负责人。如果有人把AI检查通过当成“可以合并”的唯一标准，这个流程迟早出事。5.3 我踩过的三个坑挑三个我真实遇到过的问题分享一下，给各位当个参考。坑一：AI生成了一段看起来完全正确的匹配逻辑，根据某个字段做优先级排序。常规数据下跑得好好的，结果线上出现极端数据时，排序结果完全错乱。教训是：AI写的逻辑，边界条件一定得自己补测。坑二：AI自动生成了大量重复代码。效率确实高，但这个模块修了bug，另一个模块没修，排查的时候才发现有十几个几乎一样的实现。教训是：AI帮你可以，但架构规范不能放松，重复逻辑要持续收敛。坑三：AI生成代码时引用了一个未声明的依赖库，本地环境碰巧有，打包环境直接构建失败。教训是：AI生成的依赖声明一定要检查，别默认它写的都对。6. 常见问题与排查技巧实录最近半年我在不同项目里反复遇到的问题，基本集中在下面几类。整理成一张速查表，也把排查思路写清楚了。症状/场景可能原因推荐处理方式相同问题多次调用结果差异很大采样参数设置偏高把temperature调低，优先用0或0.1，对输出格式用结构化约束提示词一长效果就明显变差上下文超出模型有效注意力范围引入检索只保留相关片段，长对话做摘要压缩token成本快速增长大量重复请求未做缓存加缓存层，批量合并请求，小模型处理简单任务AI生成的代码评审时没问题，上线后才出错评审缺少业务上下文人工用业务用例走查，让AI额外列出它注意到的边界条件换了模型版本后输出风格突变没有沉淀评测集建立回归评测集，升级前全量跑，再决定是否上线模型频繁超时或限流单一调用链过重，没有降级方案增加超时控制、重试退避、备用模型降级排查这类问题有个通用逻辑：先看记录，再看上下文，最后动参数。没有记录就去改参数，等于闭着眼睛调琴弦，调到哪里算哪里。还有一个容易被忽视的地方：很多AI应用的“不稳定”，其实不是模型的问题，而是输入上下文变化造成的。你以为两次输入一样，但上下文里可能藏着上次对话留下的信息，或者知识库检索回来不同的片段。排查时先固定上下文，再对比结果，很多神秘问题当场就清楚了。最后聊一点个人体会。整个课程下来，我最认同的一句话是：AI时代的软件工程师，核心竞争力从“写得快”变成了“判断得准”。这件事听起来抽象，做起来很具体——多建评测集，多写测试，多维护日志，多人工走查边界。上完这门课之后，我给自己定了一个小习惯：每天把AI帮我写的代码和它没说清楚的地方记录一遍，慢慢就会很清楚哪些场景适合交出去，哪些场景必须人工兜底。这个习惯，比任何工具都管用。
今年我完整跟完一门编号为CS146S的课程，主题就是“AI时代的软件工程”。本来我以为这又是一门教你怎么用AI写代码的工具课，结果越听越发现，它真正在讨论的是另一个问题：当代码的生产方式从“人写”变成“人审、AI写”之后，软件工程那些老规矩还有哪些仍然成立。这门课给了我一个很明确的答案——绝大部分老规矩依然成立，只是执行顺序和关注重心变了。这门课适合谁？我觉得有三类人收获最大：正在用AI辅助开发但总觉得不可控的工程师，负责AI产品落地但说不清怎么保障质量的技术管理者，还有打算系统梳理AI开发流程、不想只停留在“会调API”层面的学习者。它不是教你某个具体模型怎么用，而是教你一套在AI语境下依然能打的工程方法论。1. 这门课到底在讨论什么：AI没有推翻软件工程，只是重排了优先级课程第一周就抛出一个很扎心的问题：如果一个AI能一天生成几千行代码，那还需要软件工程吗？听起来好像不需要，但我身边真实发生过的场景是：团队用AI快速拼出一个系统，结果没人说得清楚它为什么这么写、改哪条逻辑会炸、怎么证明它是对的。这恰恰是软件工程存在的理由。所以这门课的核心立场很鲜明：AI不会让软件工程消失，只会让软件工程的重心从“关注怎么写代码”转向“关注怎么证明代码是对的、怎么控制不确定性”。1.1 传统软件工程的核心问题，在AI时代原封不动很多人以为AI能把需求模糊、复杂度失控、质量保障这些老问题一并解决，事实恰好相反。需求不确定性反而更严重了。以前用户说“做一个订单列表”，你还能掰扯清楚字段和状态；现在用户说“做一个智能助手”，边界在哪里完全靠猜。AI的能力范围是个开放集，需求方很容易把期望抬高到“它什么都能干”，而工程方必须把它拉回“它只能在这些场景下可靠工作”。这是最花时间、也最容易被低估的一环。复杂度管理也一点没减少。AI生成的代码越多，系统里互相牵连的隐性依赖就越多。代码量不是衡量复杂度的标准，调用关系、数据流、外部依赖才是。模块划分、接口设计、分层隔离这些基本功，在AI写的代码堆里反而更重要，因为AI不会替你承担架构责任。质量保障更是如此。以前测试是在验证“实现是否符合规格”，现在测试还要多问一句“这个输出是否在可接受范围内”。传统测试的确定性断言依然需要，但远远不够。质量的定义变宽了，质量保障的手段必须跟着扩展。协作与沟通的老问题也在换皮重现。AI生成代码之后，代码评审不再是“看一个人写得对不对”，而是“看AI写的这段合不合业务预期、有没有埋雷”。文档、设计评审、变更管理这些流程不是被简化了，而是被重新发明了一遍。1.2 变的不是目标，是“确定性”这个前提为什么AI会让软件工程产生这么多连锁反应？根源在于一个前提变了：传统程序是确定性的，同样的输入必然得到同样的输出；而AI模型是概率性的，同样的输入可能给出不同的结果。这个变化看起来不大，影响却是全局性的。维度传统软件AI赋能的软件输出行为确定性，可精确断言概率性，只能约束范围调试方式断点定位、日志追踪提示词排查、数据排查、上下文排查测试重点功能逻辑与分支覆盖输出质量、边界治理、稳定性异常处理明确错误码与异常类型超时、重试、降级、兜底策略回归保障自动化测试用例评测集+自动化用例双轨这个表格基本就是整门课的地图。后面聊的测试、架构、评审，都是在围绕“概率性输出如何进入确定性系统”展开。1.3 我理解的全景图把课程主线压缩一下，其实就四条：AI辅助开发怎么用才靠谱、AI应用的测试与质量怎么保障、AI原生系统怎么设计架构、AI进入团队后协作流程怎么改。这四条也是我下面要展开的内容。2. AI辅助开发的正确打开方式：别把大模型当成编译器课程里有一句话我记了很久：把AI当成编译器，你会收获一个满嘴胡话的编译器；把AI当成一个能力很强但经常犯迷糊的新同事，你才知道怎么跟它配合。这句话太真实了。我用AI辅助编程有一段时间了，最大的感受是：它的产出质量和你的使用方式强相关。不是“问得越多越好”，而是“问得越结构化越好”。2.1 我在实践中常用到的三层用法第一层是局部代码生成。处理样板代码、格式化逻辑、简单工具函数这种低风险任务，AI基本稳得可怕。比如写一个日期范围拆分的函数、把一段混乱的配置整理成结构化的对象，这类需求边界清晰、验证成本低，直接交给AI生成能省不少时间。第二层是代码理解与重构。我经常拿一段自己不熟悉的代码问AI：“这段逻辑的入口在哪里？数据流是什么？有没有可以拆分的点？”这种用法下，AI更像一个可以随时对话的代码阅读助手。注意，它给出的理解结论不一定全对，但能帮我快速建立初步认知，再用调试工具验证一遍，效率比从头啃高很多。第三层是测试与文档生成。让AI根据函数签名和业务描述生成单元测试骨架、生成接口文档、生成变更说明，这些都是AI非常擅长的。但我不建议让AI在没有人review的情况下直接产出业务级测试断言，原因后面专门说。每层用法都有一个共同前提：你要有能力判断AI输出对不对。这不是劝退，而是提醒。如果你自己完全看不懂一段代码，AI生成的代码对你就是纯风险。2.2 提示工程在软件工程里不是聊天技巧，而是需求规格很多人把写提示词当成聊天技巧，其实在工程场景里，提示词就是一份需求规格说明书。你在提示词里写清楚了角色、上下文、输出格式，AI的行为才会收敛到你预期的范围内。我自己的标准模板是三段式：角色定义、任务上下文、输出约束。举个例子，我经常用AI做代码评审预览，提示词是这样写的：请以一名资深代码评审员的身份，审查下面的代码片段。 按【正确性】【安全性】【可维护性】【性能】四个维度输出问题清单。 每个问题必须包含：严重级别（高/中/低）、问题定位（文件+行号或函数名）、修复建议。 不要输出任何赞美性语言，只输出问题和建议。 没有问题时，直接输出“未发现明显问题”。 代码片段： <在这里粘贴代码>为什么这么写？角色定义让AI调用专业领域的知识框架；任务上下文让它知道审查范围；输出约束让结果可以直接进追踪系统。对比一下，如果你只是说“帮我看看这段代码”，它很可能给你一堆正确的废话，你还要自己再筛一遍。2.3 涉及大段代码时怎么管理上下文这是AI辅助开发里最容易被忽视的坑：上下文不是越长越好。模型对过长的上下文会产生注意力衰减，也就是“中间段信息被忽略”，尤其是当代码量大、逻辑复杂的时候。我的做法是分块提交。先把文件结构梳理清楚，再把有疑问的模块、函数单独摘出来提问。对需要全局信息的问题，先让AI分别处理几个局部，再让它做汇总推理。比如“分析这个服务的调用链”，我不会把整个仓库丢进去，而是先让它分别梳理入口、业务层、数据层的关键路径，最后再合并。还有一个小技巧：在提示词里明确引用依赖关系。只贴代码片段而不说明它依赖什么库、什么接口，AI生成的答案就可能基于错误假设。给它一行说明“这段代码依赖某个模块的某某函数，请结合这个约束分析”，准确率会明显提升。3. AI时代的测试策略：从人工断言到“用AI测试AI”课程里有一句贯穿始终的话：AI应用测试的难点不是覆盖代码行，而是覆盖“输出的合理程度”。传统测试用例是“跟预期结果比”，AI测试用例是“跟用户可接受的范围比”。这句话让我想通了很多以前模糊的问题。AI应用不是不需要测试，而是测试要做的事情更多、更难了。3.1 传统测试的基本盘不能丢先泼一盆冷水：AI写得再快，单元测试、集成测试、回归测试这些基本盘依然不能丢。理由很简单——AI生成代码只是改变代码的生产方式，没有改变代码要正确运行的底线。我见过很多团队，用AI生成了一堆代码，然后测试覆盖率接近零。原因是“AI生成的代码还要测什么”？结果一上线就出问题。AI生成的代码尤其需要测试，因为你不知道它是基于什么假设写出来的。单元测试是对AI输出的一种实时校验，也是后续重构的安全网。我的建议是：无论代码是不是AI写的，测试策略严格按照工程标准来。每个核心函数要有单元测试，模块间要有集成测试，主流程要有端到端测试。AI可以帮你生成测试骨架，但测试的标准必须由人来定。3.2 AI生成测试用例：能做什么，不能做什么AI生成测试用例的能力已经不错了，但边界要搞清楚。能做的事情包括：根据代码结构自动生成覆盖分支的用例、生成各种mock数据、构造边界输入（空值、超长字符串、负数字段）。这些是模式匹配任务，AI做得又快又好。不能做的事情更关键。AI不知道你的业务预期是什么，它判断不了“这个输入下正确结果应该是多少”。让它生成测试用例，经常会出现断言值是从代码实现里反向抄过来的情况，也就是“用实现验证实现”，这种测试等于没写。另外，数据隐私、合规边界这些业务规则，AI也无法替你把关。所以AI生成的测试用例必须经过人工review，重点就是要看断言是不是符合业务预期，而不是只看有没有跑通。3.3 面向LLM应用，测试要新增四个维度如果系统里接入了大模型，传统的测试维度是不够的。我在这门课里学到并验证过的四个新维度，值得直接抄进自己的测试计划。第一是输出结构校验。模型输出经常“有噪音”，该是JSON的时候给你夹带解释文字，该是枚举值的时候给你自由发挥。输出结构不校验，下游解析迟早翻车。这个维度在集成测试里就跑，不用等线上。第二是幻觉与事实性检测。特别是生成摘要、抽取信息的场景，要检查输出里是否出现了输入材料中完全没有的事实。简单做法是抽几个关键实体做比对，比如生成内容里提到的人名、机构名、时间点，去原文里找对应。第三是稳定性测试。同一个输入问三次，输出了三个不同答案，这在聊天场景也许还能忍，但放在金融、客服、审批场景就是事故。稳定性测试要设置可接受的波动范围，差的场景必须收敛。第四是成本与性能阈值。LLM应用的响应时间和token消耗是动态的，测试用例里应该包含“这个请求不能超过多少token、多少毫秒”的硬性指标。成本失控往往不是某一次调用贵，而是没有为单次调用设上限，数量一起来就爆了。3.4 一个简单的回归评测集思路换提示词、换模型、调参数，都可能让效果变好，同时让另一个场景变差。我习惯把关键输入输出沉淀成一个评测集，每次改动后跑一遍。EVAL_CASES = [ { "prompt": "请总结这段新闻：...", "must_contain": ["关键人名", "核心事件"], "forbidden": ["虚构机构", "编造时间"] }, { "prompt": "请用中文回答：...", "must_be_language": "zh", "max_tokens": 100 }, ] def run_eval(call_model, cases): failures = [] for case in cases: output = call_model(case["prompt"]) for keyword in case.get("must_contain", []): if keyword not in output: failures.append(f"缺少关键信息: {keyword}") for banned in case.get("forbidden", []): if banned in output: failures.append(f"出现不应有的内容: {banned}") if len(output) > case.get("max_tokens", 1000): failures.append("输出超长") return failures这个脚本很简陋，但理念是对的：把“输出质量”变成可以度量的任务。评测集不怕简单，关键是要持续积累。我每次处理用户反馈、线上问题，都会顺手把案例补进评测集，时间长了，这就是你团队真正的质量资产。4. AI原生系统的架构设计：把不确定性关进笼子里“AI原生”这个词现在有点被用滥了。在我看来，真正的AI原生不是“调用了大模型API就算数”，而是整个系统架构从设计第一天就接受了“模型会犯错、会超时、会换版本、会行为漂移”这个前提。这门课花了不少篇幅讲架构，核心就一句话：把不确定性关进笼子里，别让它顺着代码流得到处都是。4.1 调用层要做防腐设计很多团队在一开始图方便，让业务代码直接调用某个模型供应商的SDK。等哪天要换模型、换供应商，或者对方改了一个参数语义，你就得满项目去找调用点改代码。正确做法是加一层防腐层，把模型调用封装成一个内部接口。业务代码只认识这个接口，不关心背后用的是哪家模型。class AIModelClient: def __init__(self, provider, primary_model, fallback_model=None): self.provider = provider self.primary_model = primary_model self.fallback_model = fallback_model def generate(self, prompt, temperature=0.2, max_tokens=500): try: return self._call_primary(prompt, temperature, max_tokens) except TimeoutError: if self.fallback_model: return self._call_fallback(prompt, temperature, max_tokens) raise except RateLimitError: # 可以考虑加退避重试，或降级到缓存结果 return self._fallback_with_cache(prompt)这一段代码的核心作用有两个：一是隔离变化，换模型、加参数都不影响业务层；二是统一处理异常，把超时、限流、无结果都收敛到一个地方。没有这层壳，AI应用就像没装保险丝的电箱，小故障也能烧掉整片电路。4.2 上下文工程：Context才是AI应用的数据库课程里有个观点我特别认同：对AI应用来说，上下文就是数据库。模型的输出质量，很大程度上取决于你给它喂了什么样的上下文。但上下文不是越多越好。很多团队为了“让模型更懂业务”，把超长文档、全部历史对话一股脑塞进prompt，结果模型反而抓不住重点，成本还飙高。我对上下文工程的理解是三个动作：检索而不是全量塞入。需要知识库的时候，用检索拿到最相关的几段内容，而不是把整个知识库塞进去。这就像给人查资料，你不会扔给他一整座图书馆，而是给他翻到正确页码的几页纸。摘要而不是保留全文。长对话场景下，历史消息超过一定轮数后，把之前的对话总结成结构化摘要，保留关键信息，丢掉冗余。分层而不是平铺。上下文按“系统指令+用户意图+参考材料+工具结果”四块组织，让模型知道哪部分是必须遵守的规则，哪部分是可参考的资料，哪部分是当前要处理的任务。结构化上下文比一大段散文式的描述靠谱得多。4.3 可观测性与成本控制AI系统的排障思路和传统系统很不一样。传统系统可以依赖日志和断点复现问题，AI系统的问题往往是“同样的输入，结果时好时坏”，这时候没有记录就别想排查。我的做法是给每一次模型调用记录四件事：模型名称和参数、输入token和输出token、响应耗时、返回结果摘要。日志里有了这些，用户反馈一个问题时，你才能回答出“当时模型收到的是什么、输出的是什么、花了多少钱”。成本控制也有一个实用策略：路由分层。不是所有请求都需要用最强的大模型，简单的文本分类、关键词抽取、格式整理，用小模型处理又快又便宜；复杂的推理、长文总结、代码生成，再调大模型。再配合缓存层复用重复请求，总体成本能降下来不少。我遇到过一次线上事故，就是因为某次调整无意中把一大段历史信息加进了prompt，导致token消耗翻倍、响应延迟明显变高。没有日志记录，这个问题排查起来会非常费劲。这也是我坚持“一切调用皆可观测”的原因。5. 团队协作与代码评审：AI产物的“人机共同评审”AI进入团队之后，最容易翻车的环节是代码评审。因为AI生成代码有一种很强的说服力：格式干净、注释齐整、命名规范，看上去非常专业。但逻辑漏洞、隐藏依赖、安全风险，恰恰藏在漂亮的外壳下面。这周课上讨论的很多案例都指向同一个结论：AI时代，评审不是变轻松了，而是变重了。以前评审是人和代码之间的事，现在变成了人和AI之间的博弈。5.1 人审什么：四个不嫌多的检查点我给自己总结了一套固定的AI代码审查清单，不管AI生成什么代码，都按这四关过一遍。第一关是正确性。看边界条件是否处理了，空值、重复值、异常输入下会不会崩。AI经常在“看起来正常”的路径上表现良好，但在边界状况下露出破绽。第二关是安全性。权限校验写没写？敏感数据有没有泄漏到日志或模型输出？那些看起来无害的AI生成代码，可能恰好绕过了原本的安全控制。第三关是合规性。引用的开源代码许可证是否允许我们这么用？模型输出的内容是否涉及数据权限？AI不会主动告诉你“这部分代码可能来自某个你没有权的来源”，这个只能人来确认。第四关是可维护性。这段代码是不是重复造轮子？抽象得是否过度？有没有引入不必要的复杂依赖？AI容易生成表面统一、实际孤岛式的重复代码，时间长了就是技术债的温床。5.2 把AI接入现有研发流程的正确姿势AI不该替代流程，而是嵌入流程。我比较认可的几种姿势是：在代码评审前，用AI做一个变更摘要。特别是大范围的改动，AI可以自动生成“这个PR改了什么、影响哪些模块、可能的引入风险”，评审人先看摘要再深入，效率高很多。在CI流水线里，加一道AI静态检查。跑的维度就是刚才说的正确性、安全性、可维护性，但注意AI检查的结果是“建议”，不是“结论”。所有告警还是要有人确认后再处理。在提交环节，用AI生成变更说明和文档补充。这个收益是最直接的，Commit Message和接口文档能跟上代码变化，是小团队最容易欠的债。一定要记住：AI在任何流程里都只做“预审”和“建议”，最终拍板的必须是负责人。如果有人把AI检查通过当成“可以合并”的唯一标准，这个流程迟早出事。5.3 我踩过的三个坑挑三个我真实遇到过的问题分享一下，给各位当个参考。坑一：AI生成了一段看起来完全正确的匹配逻辑，根据某个字段做优先级排序。常规数据下跑得好好的，结果线上出现极端数据时，排序结果完全错乱。教训是：AI写的逻辑，边界条件一定得自己补测。坑二：AI自动生成了大量重复代码。效率确实高，但这个模块修了bug，另一个模块没修，排查的时候才发现有十几个几乎一样的实现。教训是：AI帮你可以，但架构规范不能放松，重复逻辑要持续收敛。坑三：AI生成代码时引用了一个未声明的依赖库，本地环境碰巧有，打包环境直接构建失败。教训是：AI生成的依赖声明一定要检查，别默认它写的都对。6. 常见问题与排查技巧实录最近半年我在不同项目里反复遇到的问题，基本集中在下面几类。整理成一张速查表，也把排查思路写清楚了。症状/场景可能原因推荐处理方式相同问题多次调用结果差异很大采样参数设置偏高把temperature调低，优先用0或0.1，对输出格式用结构化约束提示词一长效果就明显变差上下文超出模型有效注意力范围引入检索只保留相关片段，长对话做摘要压缩token成本快速增长大量重复请求未做缓存加缓存层，批量合并请求，小模型处理简单任务AI生成的代码评审时没问题，上线后才出错评审缺少业务上下文人工用业务用例走查，让AI额外列出它注意到的边界条件换了模型版本后输出风格突变没有沉淀评测集建立回归评测集，升级前全量跑，再决定是否上线模型频繁超时或限流单一调用链过重，没有降级方案增加超时控制、重试退避、备用模型降级排查这类问题有个通用逻辑：先看记录，再看上下文，最后动参数。没有记录就去改参数，等于闭着眼睛调琴弦，调到哪里算哪里。还有一个容易被忽视的地方：很多AI应用的“不稳定”，其实不是模型的问题，而是输入上下文变化造成的。你以为两次输入一样，但上下文里可能藏着上次对话留下的信息，或者知识库检索回来不同的片段。排查时先固定上下文，再对比结果，很多神秘问题当场就清楚了。最后聊一点个人体会。整个课程下来，我最认同的一句话是：AI时代的软件工程师，核心竞争力从“写得快”变成了“判断得准”。这件事听起来抽象，做起来很具体——多建评测集，多写测试，多维护日志，多人工走查边界。上完这门课之后，我给自己定了一个小习惯：每天把AI帮我写的代码和它没说清楚的地方记录一遍，慢慢就会很清楚哪些场景适合交出去，哪些场景必须人工兜底。这个习惯，比任何工具都管用。