让智能体成为一支工程团队
——AI 原生软件开发的一次完整实践

一、引言：这不是一篇「AI 写代码」的文章

我用 Claude Code 配合 mattpocock/skills 技能集，从零开发了一款 macOS 原生应用「长辈计算器」。项目本身并不复杂——四则运算、语音播报、计算历史，一个计算器而已。真正值得记录的，是它的开发过程：需求澄清、规格编写、任务拆分、TDD 实现、代码评审，五个环节全部由「人 + AI 智能体」协作完成，而 AI 在每个环节都承担了可独立交付的实质性工作。

这篇文章复盘这次实践，试图回答一个问题：当 AI 不再只是「帮你写代码」的工具，而是整条软件开发生命周期（SDLC）的参与者时，软件开发本身会发生什么变化？

我的核心结论是：AI 原生开发的关键不在「AI 能写多少代码」，而在于把软件开发中大量隐性的东西——需求理解、决策理由、测试接缝、验收标准——变成仓库里显式、可审查、可追踪的工件。这套流程的每个环节都在做同一件事：上下文工程（Context Engineering）。谁管理好了上下文，谁就管理好了 AI 开发的质量。

二、从「AI 辅助编程」到「AI 原生开发」

过去两年被称作「AI 编程」的实践，绝大多数是AI 辅助编程：人写代码，AI 补全片段、生成函数、修 bug。开发流程本身不变，AI 只是加快了打字速度。

AI 原生开发不同：它重新设计了软件开发生命周期本身。人不再逐行写代码，而是——

• 用访谈把模糊想法澄清成领域模型，而不是自己默默假设；
• 用规格文档把「系统该有什么行为」说清楚，而不是边写边想；
• 用任务系统把规格拆成可独立验证的切片，而不是一次性写一大坨；
• 用测试先行驱动实现，而不是写完再补测试；
• 用双轴评审把关质量，而不是自己 review 自己。

在这次实践中，这个分工具体化为一条有状态的流水线。

三、工作流全景：一条把隐性知识显式化的流水线

mattpocock-skills 把 AI 开发组织成一条流水线，五个环节首尾相接：

注意这条链路与传统流程的一个关键差异：文档不是过程的副产品，而是过程的主线。每个阶段结束时，产出物都不是「口头共识」，而是磁盘上可读、可 diff、可追溯的真实文件：CONTEXT.md、.scratch/elder-calculator/spec.md、issues/01…12.md，以及最终落进 git 的代码与测试。

四、四个阶段的实践拆解

4.1 需求：把「给老人做个计算器」变成领域模型

grill-with-docs 的工作方式是一场结构化的苏格拉底式访谈：AI 不直接开写，而是一轮一轮「拷问」，直到人和 AI 对产品共享同一个理解。这次项目经历了 4 轮访谈、约 25 个决策点，覆盖：目标用户画像（60–80 岁、老花眼、手部灵活性、听力状况）、功能边界（要不要记忆功能）、界面语言（全中文）、技术栈（SwiftUI vs AppKit）、分发方式、适老手段、语音播报粒度与读法、计算语义（实体计算器式 vs 表达式式）、清除键防误触机制、历史记录形态、首次启动体验……

有两个机制值得单独拎出来：

其一，决策即时落档。「一个术语被敲定，它落地到 CONTEXT.md 的时机就是它被敲定的那一刻，而不是最后批量补交。」材料中 CONTEXT.md 更新了 3 次，每次都在一轮访谈结束后立即写入，术语表从最初 7 个条目增长为覆盖计算语义、千分位、分级清除、设置项、错误边界的完整领域模型。

其二，推荐 + 确认的低摩擦决策模式。每一轮，AI 都会给出推荐及理由，用户只需「都按推荐」或针对性修改。例如砍掉记忆功能（M+/M−）这一重要取舍，AI 的理由是：「历史记录已经覆盖『之前算的数字想再用』的场景，记忆键的隐式状态（屏幕上多一个 M 指示灯）对老人是纯负担。」访谈的深度靠 AI 的结构化提问保证，决策速度靠推荐机制保证——这是「人做决策、AI 提供决策支持」的典型形态。

「四轮下来，设计树的分支已经全部走完，frontier 已清空……如有任何一条想改，现在说是最便宜的时机。」 —— 访谈结束时 AI 输出的共识总结，请用户做最终确认

这句话点出了这套流程的核心价值：把错误扼杀在需求阶段，因为这是纠偏成本最低的时机。

4.2 规格：先定接缝，再写故事

to-spec 阶段有两个亮点。

亮点一：测试接缝（seam）设计被前置到规格阶段。seam 是 Michael Feathers 的术语：一个「无需在那个位置编辑代码就能改变行为」的地点。在写任何代码之前，AI 先和人确认「在哪里测试」——最终确定两个接缝：

• 计算引擎：纯逻辑状态机，测试从「用户按键」这个最高点进，断言「屏幕显示什么、历史里多了什么」，完全不碰内部实现；
• 中文数字朗读转换：纯函数，数字（含小数、负数、万/亿量级）→ 播报文本，这是「规则最复杂、最容易出错的部分」。

理由很工程化：「接缝越少越好，这两个模块是真正独立的纯逻辑，其余都是它们的薄壳。」这个决策把「软件架构」从实现阶段提前到了规格阶段，并且用测试的视角来定义模块边界——先决定哪里可以被测试，再决定代码怎么组织。

亮点二：规格是行为契约，不是实现说明书。spec.md 包含：问题陈述（老年用户用系统计算器的具体痛点）、36 条用户故事（按「基本计算 / 看得清 / 听得见 / 错得起 / 回看核对 / 键盘与其他」六组组织）、实现决策（两个深模块 + 薄壳）、测试决策（只测外部行为，不测内部实现）、10 项明确的 Out of Scope。特别值得注意的是行为权威的单一来源：

「领域术语与全部交互共识的权威定义在根目录 CONTEXT.md……spec 与术语表冲突时以术语表为准并在实现前澄清。」

4.3 任务：曳光弹切片与依赖图

to-tickets 把 36 条用户故事拆成 12 张 ticket。关键原则是 ticket ≠ 用户故事：一张 ticket 会打包多条相关故事，每张是一个 tracer-bullet（曳光弹）垂直切片——贯穿引擎 → UI → 测试，独立可演示、可验证，尺寸控制在单个上下文窗口内。

ticket 03（四则运算与等号）就是一个例子：它一次性覆盖链式语义、运算符替换、出结果后开新笔、重复等号等十几条故事对应的引擎 + UI + 测试。

12 张票的依赖结构体现了明确的工程判断：

材料中有一段关于「为什么拆票」的论述，我认为是这套流程最深刻的设计思想：

• 每张票之间是一个天然的检查点：可以打开应用亲手点点看，不满意马上纠偏，而不是等 36 条故事全写完才发现方向错了。
• 每张票一个全新会话：智能体永远在最清醒的状态下写代码。「如果让 36 条故事在一个会话里连续做完，后半程的代码是上下文被塞满的智能体写的，质量衰减比『多敲几次命令』的代价大得多。」
• 因此，人的介入次数 ≈ ticket 数量（本次约 6–9 次「输入一行命令」），每次介入之间 /implement 是全自动的：读 spec、TDD 红绿循环、跑 code review、提交。

「这个『频繁介入』恰恰是这套流程的设计意图，不是缺点。」

这句话颠覆了很多人对 AI 开发的直觉。我们总希望 AI 一口气干完，但上下文是有穷的，质量随上下文长度衰减。用会话边界换取上下文清醒，用检查点换取纠偏机会，是这套流程对「上下文工程」最具体的落实。

4.4 实现与验证：TDD 红绿循环与双轴评审

/implement 会自动调用 /tdd 和 /code-review。以 ticket 03（四则运算与等号）为例，实现过程是教科书式的 TDD：

• 4 个红→绿切片：基本加法与算式 → 四则与链式 → 替换 / 新笔 / 重复等号 → 格式化；
• 每个切片先写测试（断言引擎外部行为），确认红灯，再实现转绿；
• 最终 23 个引擎行为测试全绿。

code-review 的「双轴」设计是另一个亮点：一个审查轴对 Spec（规格），一个审查轴对 Standards（编码标准），两个审查子智能体并行运行。这次评审的结果很有说服力：

• Spec 轴抓到了真实偏差：算式行中的数字未带千分位（违反 CONTEXT.md 的要求「屏幕上的数字带千分位」），已补测试修复——证明 review 不是走过场；
• Standards 轴给出判断性建议：落实了两项轻量重构（消除数据泥团、橙色按钮去重），同时明确拒绝了一项过度设计（算式字符串的 token 列表化重写），理由很克制：「现有实现已被 23 个测试钉住，留待 ticket 09 历史记录时再看是否需要。」

值得注意的是，review 的结果不只是意见，还区分了「必须修」和「暂不做」，并为「暂不做」给出了未来的触发条件——这是成熟的工程判断，不是机械执行。

五、五个关键洞察

把这次实践提炼为可迁移的方法论，我认为有五个洞察值得强调：

六、实践数据盘点

七、可以直接复用的方法清单

1. 新项目从访谈式需求澄清开始，不要直接让 AI 写代码；每个决策点给「推荐 + 理由」，用户只需确认或修改。
2. 术语和决策即时落档到 CONTEXT.md，不要等最后批量补交。
3. 写规格前先定测试接缝：问「在哪里测试」，用答案定义模块边界；接缝越少越好。
4. 用户故事按能力域分组，每组用术语表的词汇表述（基本计算 / 看得清 / 听得见 / 错得起 / 回看核对 / 键盘与其他）。
5. 明确写 Out of Scope，把「不做什么」和「做什么」一样写清楚。
6. 任务拆成 tracer-bullet 垂直切片，每张控制在单个上下文窗口内，标注 Blocked by，画出依赖图并管理 frontier。
7. 每张票一个全新会话，接受「频繁介入」并把它当作检查点。
8. TDD 红→绿切片推进，测试只断言外部行为、不碰内部实现。
9. code review 双轴：Spec 轴查「做没做对」，Standards 轴查「写得好不好」；区分「必须修」与「暂不做」。
10. 行为权威单一来源：CONTEXT.md > spec.md > ticket > 测试。

八、结语：下一个被重新设计的是工程师的角色

这次实践给我的最大感受是：AI 原生开发不是「让 AI 干活、人验收」的偷懒模式，而是一套更严格的工程纪律。它把传统开发中靠人脑记忆、靠会议口头对齐、靠隐式经验的东西——领域术语、决策理由、测试策略、验收标准——全部显式化、文件化、可追踪化。

当智能体承担了访谈、写作、拆解、编码、测试、评审这些执行性工作，人终于可以专注于它最擅长也最该做的事：判断什么是对的。

这也许就是「AI 原生」的真正含义：不是 AI 替代了工程师，而是工程师被重新定义——从「写代码的人」变成「定义问题、管理上下文、做决策的人」。下一次实践，真正值得设计的也许不是应用本身，而是这条流水线。