摘要测试红了，是测试工作真正产生价值的时刻——但这个价值能不能兑现，取决于怎么处理失败。最危险的做法是把失败日志甩给AI，说”修到通过”。AI会以最快的方式让测试变绿，而最快的方式往往是改测试、加try/catch、重试掩盖，而不是修真正的bug。核心论点：先分类，再修复。一个失败可能是四种东西：产
摘要文本用例定了”测哪些场景”，这一篇解决”怎么用代码把它们测起来”。让AI把Given/When/Then翻译成可运行的测试代码，看似一句话的事，实际是自动化测试最容易翻车的环节——AI会新造一套fixture、断言无关紧要的实现细节、写出永远通过的空测试。核心论点：先定测试层级，再写代码。一条用
摘要从这一篇开始进入测试与验证线。测试的源头不是测试代码，而是文本测试用例——把Spec里的每条需求，系统地翻译成”在什么条件下、做什么操作、应该看到什么”的可执行描述。核心论点：“测什么”不能凭经验，必须从Spec推导。凭经验想测试用例，一定会漏；从REQ编号逐条推导，才能保证每条需求都被验证。这
摘要代码写完、测试变绿，不等于可以合入。在AINative开发里，代码评审（CodeReview）的对象变了：以前审的是”同事写的代码”，现在审的是”AI在一份Plan约束下产出的改动”。这带来两个新问题——改动量更大（AI一分钟能写人一小时的量），以及越界更隐蔽（AI会在”合法文件”里夹带计划外逻
摘要Plan评审通过，AI终于可以改代码了。但”可以动手”不等于”可以放开手脚”。Implement阶段是SDD里唯一真正改动生产代码的阶段，也是所有前期约束接受考验的阶段。核心论点：实现阶段的失控，几乎都源于”步子太大”和”边界太软”。AI一次拿到整个功能、没有明确的文件红线，就会自由发挥、顺手重
摘要SDD的四道闸门里，Gate1（Spec评审）和Gate2（Plan评审）是AI动手改代码之前仅有的两次人类拦截机会。这一篇专门讲人的动作：什么时候介入、重点审什么、怎么在十分钟内看出一份Spec/Plan靠不靠谱。核心论点：评审不是”再读一遍”，而是带着对抗性的检查。AI产出的文档天然倾向于”
摘要Spec回答”做什么”，Plan回答”怎么做”。这一篇讲Gate2的核心产物：为什么AI必须先研究代码库、产出一份受约束的执行计划并经人评审，才准碰代码。核心论点有三个：Plan是成本最低的纠错点。在Plan阶段发现”方案和现有架构冲突”，改几行字；在实现后发现，要回滚整条分支。Plan的价值不
这是“AINative开发”系列的第5篇。上一篇的Spec模板最后留了一栏“待确认问题”，并说：如果某个问题不是“需求没想清”，而是“技术上不知道可不可行”，它不该靠拍脑袋写进Spec。本篇就处理这类问题——在AI写代码速度极快的时代，把技术不确定性留到实现阶段，代价被放大了一个数量级。Spike就
这是“AINative开发”系列的第3篇。前两篇建立了SDD的四阶段与四道闸门，并用一次完整交付演示了错误如何被拦在闸门之外。但那次演示有一个隐含前提：AI开工前就理解了这个项目。本篇专门讨论这个前提——如果它不成立，再好的Spec也会被错误实现。摘要本篇回答一个问题：为什么同一个模型，在A项目里像
这是“AINative开发”系列的第2篇。前两篇分别讨论了AINative开发改变什么，以及AI为什么会把未决策的问题直接做成代码。本篇完整走一遍“删除草稿文章”的交付过程。**案例说明：**本文的删除接口、鉴权、Vitest/Playwright测试均为一个假想全栈项目的示意产物，不是本博客当前仓
这是“AINative开发”系列的第1篇。上一篇提出：可靠交付的最小单元不再只是代码。本篇通过一个订单取消案例，说明AICoding最难防的错误，往往不是语法错误，而是未经授权的产品决策。摘要本文分析AICoding中最难被发现的一类错误：AI在需求空白处替业务做出了未经授权的决策，并把它写成了结构
这是“AINative开发”系列的第0篇。本系列讨论一个具体问题：当AI成为软件生产过程中的重要执行者之后，我们如何用SDD开发和测试传统软件产品。摘要本文回答三个问题：AINative开发是什么、它和AI-enabled产品与AICoding有什么区别、以及为什么它必然要求引入SDD。核心论点：A
这是“智能体测评”系列的一篇番外。前面我们讲完了测评集方法论（第7篇），下一篇就要动手搭流水线了。但很多人照着流水线代码搭起来之后会发现一个尴尬的问题：任务能发出去，结果也能收回来，但中间的过程数据一律拿不到，想mock工具也无处下手——流水线跑成了黑盒。这篇番外补上缺失的一环：在测评之前，被测的智
这是“智能体测评”系列的第10篇，也是收官篇。第9篇讲了不同场景的测评方案差异，那些主要发生在发布之前。但Agent真正的考验从上线那一刻才开始——用户不会按你的测评集提问，环境会变化，模型会更新。这一篇我们讲四层框架的最后一层L4：Agent上线之后，怎么持续知道它好不好，以及怎么让生产环境反哺你
这是“智能体测评”系列的第9篇。第8篇给了一套通用的测评流水线骨架。但骨架不能直接套用——不同类型的Agent，“成功”的含义天差地别。这一篇我们挑三个最典型的场景，给出各自定制化的测评方案，包括任务设计、评分逻辑、轨迹指标和常见陷阱。为什么不能用一套尺子量所有Agent一个看似显然但经常被忽视的事
