4 篇文章带有标签 “tdd”

这是一份可以照着做的 AI 原生软件开发工作流指南。我用 Claude Code 加 mattpocock/skills 技能集，从零开发了一款 macOS 原生应用「长辈计算器」，并在交付后走完了完整的架构演进循环。本文拆解这条工作流的每一个环节——为什么这样设计（所以然）、具体怎么做（操作步骤）、实战中长什么样（真实证据）——让没有经验的开发者也能照着走完全程。完整对话实录见实践实录，速读版见上一篇实践总结。

一、为什么需要「AI 原生」工作流

大多数人的 AI 编码方式是：打开编辑器，描述一个需求，AI 吐出代码，人肉检查。这是 AI 辅助——AI 是打字快的初级程序员，工程过程还是人的那套。

AI 原生的含义不同：整个软件工程过程——需求澄清、规格化、任务拆解、实现、测试、评审、演进——都围绕 AI 的特性重新设计。

1.1 四个经典失败模式

mattpocock/skills 的作者 Matt Pocock 在仓库 README 里总结了他观察到的四个 AI 编码失败模式，这套技能集就是对着这四个失败模式设计的。理解它们，就理解了整条工作流的"所以然"：

失败模式 #1：智能体做的不是我要的（misalignment）

"No-one knows exactly what they want" —— 《程序员修炼之道》

实践记录：我用 Claude Code 加 mattpocock/skills 技能集，从零开发了一款 macOS 原生应用「长辈计算器」。本文以这次真实开发为主线，拆解这套"AI 原生"软件工程流水线的每个环节、它背后的设计哲学，以及实战中暴露的问题。原始对话实录见前一篇。

一、为什么是"AI 原生"而不是"AI 辅助"

大多数人的 AI 编码方式是：打开编辑器，描述一个需求，AI 吐出代码，人肉检查。这是 AI 辅助——AI 是打字快的初级程序员，工程过程还是人的那套。

AI 原生的含义不同：整个软件工程过程——需求澄清、规格化、任务拆解、实现、测试、评审——都围绕 AI 的特性重新设计。AI 的特性是什么？

AI 的特性	对工程过程的要求
上下文窗口有限，塞满后质量衰减	任务必须切成"单个上下文能装下"的批次
每次会话开始时最"清醒"	频繁开新会话，而不是一条会话干到底
不会主动追问，猜错了就错到底	需求阶段强制访谈，分歧在写代码前解决
产出无限、判断有限	人只做检查点决策，不做中间执行
记不住上一次的对话	共识必须落盘为文件，而不是留在脑子里

mattpocock/skills 就是围绕这张表设计的。

摘要

大语言模型驱动的代码生成技术正在重构传统软件工程的生产模式，软件开发重心逐步从手工代码编写迁移至需求定义、约束建模与质量验证环节。上海交通大学林云副教授提出 需求编译（Requirement Compilation） 理念，以 ARC（Agentic Requirement Compilation）智能体需求编译框架为核心，探索把大规模多模态业务需求文档直接转化为可运行软件系统的技术路径，同时开展面向智能体软件工程的课程教学改革，推动开发者从“代码工人”向“智能体架构师”转型。本文基于该前沿报告，梳理智能体软件工程范式变革背景、ARC框架技术原理、现存技术痛点、教学实践方案，同时分析产业落地瓶颈与未来研究方向，为Agent软件工程领域提供研究参考。

关键词：智能体软件工程；需求编译；ARC框架；大语言模型；测试驱动开发；DSL领域特定语言

一、引言

传统软件工程流程以人工编码为核心，需求、设计、编码、测试环节由人主导完成。生成式大模型出现后，单轮提示词生成小程序代码已经较为成熟，但面对包含数十至数百业务场景的大规模真实业务需求时，通用大模型普遍存在需求理解不全、逻辑幻觉、边界场景遗漏、架构混乱、需求‑代码不可追溯等问题，很难直接产出完整可维护的软件系统，形成AI编程的“复杂性高墙”。

现有Agent编程大多聚焦于代码补全、小脚本生成，缺少一套完整的、工程化的端到端链路：即从非结构化