在AI编程日益普及的今天，提升AI生成代码质量的关键在于“规格驱动开发”（Spec Coding）。然而，许多开发者因其复杂的文档维护负担而望而却步，仍停留在将大量原始代码直接抛给AI的低效模式中，导致代码幻觉和逻辑错误频发。
本文将打破“Spec Coding等于重型工程”的迷思，介绍一种无需额外工具链、不依赖复杂提示词的极简落地方案——“零文档契约”（Zero-Doc Spec Coding）。其核心是回归开发者本能：编写结构化的测试断言。
一、 困境与破局：从“文档驱动”到“极简意图”
1.1 上下文窗口的“信噪比”危机
理解Spec Coding的必要性，需先认清大语言模型（LLM）的局限。LLM本质是一个“无状态”函数，其输出质量完全取决于输入质量。
将整个项目源码塞入AI上下文，无异于制造一场“信息灾难”。生产级代码库充斥着数据库配置、错误处理等实现细节，这些对AI理解核心业务意图而言，大多是干扰噪声。当噪声淹没信号，AI的注意力被严重分散，沟通效率低下，出错率激增。
1.2 极简解法：Zero-Doc（零文档）
传统Spec Coding难以推广，在于其误区：要求开发者在代码外维护另一套复杂文档或模型。这类方案虽解决了意图对齐问题，却难逃“文档腐化”的命运——文档维护负担重且极易过时。
Zero-Doc Spec Coding的革新之处在于：我们不维护任何静态文档，只维护“活的”测试断言。文档是死的，但单元测试可随系统迭代而更新。
我们的极简着陆点是将产品需求文档（PRD）直接转化为结构化的测试断言：
- 输入：PRD（业务意图）
- 锚点：结构化测试代码（经人类严格审查的领域）
- 产物：实现代码（可随时重构或重写的衍生品）
二、 核心方法论：构建“海平面”的高保真契约
传统Spec Coding常需“频繁压缩”信息以生成AI说明书。Zero-Doc理念则将这种“压缩”直接具象化为测试用例的编写，并借鉴“海平面用例”概念来锚定意图。
2.1 锚定海平面
将软件开发视为一片海洋：
- 云端：高层战略目标（如“提升用户留存”），对AI编码过于抽象。
- 海底：底层函数实现（如“数据库连接池配置”），对AI理解意图而言过于琐碎且充满噪声。
- 海平面：用户目标层级（如“用户成功重置密码”），是描述系统行为的理想抽象层。
Spec Coding强调将意图锚定在“海平面”。在此层级，我们既不谈论虚无愿景，也不纠缠代码细节，而是清晰描述用户通过系统达成的具体、可观测目标。
2.2 结构化降噪：目录即地图，用例即契约
为消除自然语言的模糊性，让AI精准理解海平面用例，我们采用多层结构化降噪方案：
- 宏观结构化（目录层）：利用测试文件的物理目录和动名词命名，构建系统能力地图。
- 微观结构化（代码层）：在具体测试文件中，将断言划分为
@MSS（主成功场景）和@Extensions（扩展流程），将非结构化需求转化为格式严整的测试契约。
2.2.1 宏观降噪：构建系统能力地图
在一个真实的生产级项目（如电商或内容平台）中，整个specs测试目录应严格按“用户目标（用例）”组织，而非按技术组件划分。
打开项目的specs目录，你看到的应是清晰的业务动作：
apps/system/specs/
├── ClaimTask.spec.ts # 认领任务
├── ConfigurePaymentTable.spec.tsx # 配置支付表格
├── CreateOrder.spec.tsx # 创建订单
├── DeleteUserAccount.spec.tsx # 注销账户
├── ManageUserData.spec.ts # 管理用户数据
├── ManageSettlements.spec.tsx # 管理结算列表
├── PerformPaymentAction.spec.tsx # 执行支付操作
├── ReviewContentMachine.spec.ts # 内容机器审核
├── SearchTasks.spec.ts # 搜索任务
└── ViewIncomeSummary.spec.tsx # 查看收益概览
... (共数十个独立业务用例)基于这种平铺的用例文件，可利用AI生成一份高信噪比的系统能力地图索引（如README_SPECS.md）。这份索引管理业务的模块与层级，极大降低用例管理成本。无论上层业务如何调整，底层用例文件结构无需大改，只需更新索引。
当新人或AI需要了解系统功能时，无需翻阅过时文档，查看此地图即可：
## 核心业务用例 (System Capabilities)
### 用户入驻与认证 (User Onboarding)
* **[管理用户资料数据 (ManageUserData)](./specs/ManageUserData.spec.ts)**：管理用户资料拉取、回填及多步表单验证。
* **[内容机器审核 (ReviewContentMachine)](./specs/ReviewContentMachine.spec.ts)**：用户提交材料的机器审核流程，支持自动识别与信息比对。
### 财务与结算系统 (Settlement System)
* **[管理结算单列表 (ManageSettlements)](./specs/ManageSettlements.spec.tsx)**：结算列表主页面，整合搜索、批量操作和创建入口。
* **[执行支付操作 (PerformPaymentAction)](./specs/PerformPaymentAction.spec.tsx)**：处理结算单的审批、绑定、付款、删除等业务动作。这份地图与底层目录共同构成了一份永不过时的、活的PRD。所有命名遵循动名词组，业务意图一目了然。
2.2.2 微观降噪：结构化测试契约
从宏观地图进入具体用例文件（如“用户注册”），即抵达微观契约层。
传统方式下，开发者可能将一个数百行的React组件丢给AI，其中混杂UI样式、副作用管理等细节，AI极易迷失。而在Zero-Doc方式下，我们将业务契约直接写入测试断言，获得极高信噪比：
// specs/RegisteringUser.spec.ts
describe('@UseCase RegisteringUser: 用户使用邮箱和密码注册新账户', () => {
// @MSS: Main Success Scenario (主成功流程)
it('@MSS-1: 提交有效信息应成功创建账户并返回成功消息', async () => {
const result = await register('test@example.com', 'StrongPass123!');
expect(result.status).toBe('success');
});
// @Extensions: 异常与分支流程
it('@Ext-2a: 邮箱格式无效应拒绝并报错', async () => {
const result = await register('invalid-email', 'StrongPass123!');
expect(result.error).toBe('InvalidEmail');
});
});三、 辨析：Zero-Doc 契约 vs 普通单元测试
这种结构化做法常引发质疑：“这不就是多写单元测试并集中存放吗？与普通单测有何区别？”
这是关键问题。表面看都使用测试框架，但Zero-Doc契约本质是披着测试外衣的“可执行文档”。
核心差异体现在三方面：
首先是视角本质不同。 普通单测是自下而上的“海底视角”，关注实现细节（如test_validate_email_regex），验证“代码写得对不对”。Zero-Doc契约是自上而下的“海平面视角”，屏蔽技术细节，只关注业务意图（如RegisteringUser），验证“系统做的事情对不对”。
其次是信息架构不同。 普通单测往往平铺零散，缺乏业务关联。Zero-Doc契约通过宏观目录索引和微观@MSS标签，将非结构化需求翻译成高信噪比蓝图，是用测试框架外壳承载领域驱动设计（DDD）内核。
最后是生命周期不同。 普通单测是代码附庸，底层重构时常随之报废。在Zero-Doc理念下，契约是AI生成代码的输入源（Prompt的具象化）。只要业务需求不变，无论底层代码被AI如何重写，这份契约都坚如磐石。业务代码是可随时被AI重写的衍生品，而测试契约是系统唯一、永不过时的核心资产。契约确立后，AI便能据此生成具体实现。
四、 全场景落地：统一的工作流闭环
此方式最强之处在于，它不仅是文档，更是可执行测试，从而形成自动化反馈循环。
4.1 闭环引擎：AI 的自我修正
- Spec -> 测试：AI读取PRD，自动生成含
@UseCase、@MSS和@Extensions标签的测试用例。 - 测试 -> 实现：AI编写实现代码以通过上述测试。
- 自我修正：若实现代码有误，测试失败（红灯）。AI收到报错后，在“测试围栏”内自动调整逻辑，直至测试通过（绿灯）。
4.2 遗留系统治理 (Reverse Engineering)
面对无文档的“遗留”代码，采用增量逆向策略：
- 逆向：让AI扫描老模块源码，反向生成测试断言。
- 固化：将断言保存为测试文件，形成“行为快照”。
- 重构：有了测试安全网，可大胆进行代码重构。
4.3 新需求开发 (New Feature)
面对冗长PRD文档：
- 转化：将PRD喂给AI，让其自动提取并生成结构化单测断言。
- 审查：开发者作为“人在环中”（human in the loop），审查测试用例是否覆盖所有
@MSS和@Extensions。 - 生成：AI自动生成实现代码。
4.4 需求变更 (Legacy Change)
当业务规则变化（如密码长度从8位改为12位）：
- 定位：找到对应测试文件。
- 修改：仅修改测试断言中的期望值。
- 修复：运行测试，AI发现不匹配，自动定位并修复实现代码。这是一次精准的外科手术式变更。
这本质是一种用例驱动的Zero-Doc Spec Coding模式。我们用宏观目录划定系统边界，用@UseCase圈定业务场景，用@MSS和@Extensions穷尽业务分支。此闭环彻底取代了传统的文档维护。
回顾过去，为对抗软件熵增，开发者常需小心翼翼设计复杂系统架构（如洋葱架构、六边形架构），试图用层层抽象保护核心逻辑。但在AI编程时代，这种沉重的“防御性设计”可能不再是首选。当AI拥有强大实现能力，我们无需过度设计复杂代码架构，只需设计好清晰的目录结构和契约蓝图。只要契约在，系统随时可以推倒重来。
五、 终极图景：迎接“代码虚无主义”
若未来AI模型进化，上下文窗口无限大，推理能力极强，能瞬间理解十万行代码，我们还需要写Spec吗？
若真到那一天，程序员或许都不再需要。但在那天到来前，我们必须为系统建立坚固“护栏”。
这并非一场伪装成“AI最佳实践”的TDD复兴运动，而是确立一种全新的人机协作范式。当你准备好让断言完全接管业务逻辑描述，也就准备好接受这种“代码虚无主义”——实现代码变得不再重要，重要的是你定义的测试契约。
告别僵死文档，拥抱鲜活断言。Zero-Doc Spec Coding以@MSS与@Extensions为契约，确立了AI协作的唯一事实来源。这不仅是开发门槛的降低，更是生产关系的重塑：人类定义意图，AI交付实现。
