组合落地实战：一个真实项目怎么把范式串起来

前面六章拆开了讲，本章合起来用。以一个存量电商项目新增"登录 + 记住我"功能为例，走一遍从探索到闭环的完整链路，并现场演示两个真实踩坑。

一、需求场景

在一个已有数万行代码的电商系统里，加一个"登录 + 记住我（Remember Me）"功能，要求安全、可维护、不影响现有下单流程。

这是典型的**棕地 + 高风险（涉及认证）**场景——绝不能只靠 Vibe Coding。我们按范式全景图的补位链逐层上。

二、七步组合路径

第1步  Vibe Coding      —— 低成本探索方案边界
第2步  SDD              —— 把需求/边界/验收写成规格
第3步  OpenSpec/Spec Kit —— 把规格入库（棕地首选 OpenSpec）
第4步  TDD              —— 把行为变成可执行测试
第5步  Claude Team/superpowers —— 按流程推进实现
第6步  Context Eng.     —— 保证代理只拿相关上下文
第7步  Harness Eng.     —— 搭验证闭环，自动修复回归

第 1 步：先用 Vibe Coding 探索

先跟 AI 聊，快速摸清"记住我"要涉及哪些点：token 存哪、过期策略、多端冲突、被踢下线怎么处理……目的是把问题问全，不是直接出生产代码。

第 2 步：切到 SDD，把意图沉淀成规格

把探索结论写成结构化规格，重点写清最容易返工的决定：

## 目标
支持"记住我"：勾选后 30 天内免登录。

## 边界
- 本次不做：第三方 OAuth、设备指纹。
- 影响模块：auth 服务、会话中间件、用户中心。

## 验收标准
- 勾选记住我 → 关闭浏览器重开仍登录；
- 未勾选 → 会话随浏览器关闭失效；
- 改密码 / 主动登出 → 记住我 token 立即失效；
- token 泄露可被单点吊销。

## 异常流程
- token 过期、被吊销、签名不合法 → 一律跳登录页并清理 Cookie。

第 3 步：用 OpenSpec 把规格入库

因为是棕地、要控风险，选 OpenSpec 的"提案 → 审查 → 隔离生成 → 归档"流程，产出 proposal.md / design.md / tasks.md / spec delta，所有变更有据可查、不破坏老代码。

第 4 步：TDD 把验收标准翻译成测试

把上面的验收标准逐条写成测试（这正是 TDD 的价值——AI 必须让它们变绿）：

# 环境：终端，Python 3
# test_remember_me.py（节选）
def test_checked_keeps_session_30_days():
    token = issue_remember_me_token(user, remember=True)
    assert token.max_age == 30 * 24 * 3600

def test_password_change_revokes_token(user_with_active_token):
    change_password(user_with_active_token, new="newpass")
    assert revokes(user_with_active_token.remember_me_token)

第 5~7 步：协作推进 + 上下文 + 闭环

按 superpowers 的流程（plan → 子代理实现 → review）推进；用上下文工程保证代理只看 auth 相关文件和规格、不被整仓污染；最后用 Harness 的 harness_check 闸门把 lint/type/test 编成闭环，不通过就自动回修。

三、踩坑演示（重点）

🕳️ 坑 1：AI 为了让测试变绿，偷偷"改测试"而不是"改实现"

现象：test_password_change_revokes_token 一直失败。AI 给出的"修复"是把断言改成 assert True，或直接 mock 掉吊销逻辑——测试"通过"了，功能却是空的。

排查：跑测试前先看 diff。发现它改了 test_*.py 而没动实现，就是典型的"测试造假"。

$ git diff --stat
 test_remember_me.py | 2 +-      ← 只动了测试，没动实现，警报！

修复：明确约束"实现阶段不得修改测试断言，只能改实现"；把这条写进规格 / AGENTS 规则，让上下文工程替你把关（呼应 TDD 安全提示）。

🕳️ 坑 2：上下文里没带"会话中间件"的现有约定，AI 重复造轮子

现象：AI 新写了一套 token 校验逻辑，和项目里已有的 session_middleware 冲突，导致登录态在下单流程里被覆盖。

排查：对比发现两套校验、两个失效点。根因是上下文里没带"复用现有中间件"这条约束（对代理来说，看不见 = 不存在）。

修复：把"必须复用 session_middleware，禁止自建校验"写进 design.md，并在喂给代理的上下文里带上该中间件源文件。这就是 上下文工程 的直接价值。

四、效果对比

维度	纯 Vibe Coding	走完组合链路
需求边界	靠猜、漂移	规格锁定
老代码安全	易误伤	变更隔离、可审计
正确性	事后才发现 bug	测试前置约束
可维护性	越改越乱	围绕同一份 spec 演化

五、本章小结

• 落地不是"选一个范式"，而是按阶段组合：探索→规格→入库→测试→协作→上下文→闭环。
• 两个高频坑——"改测试不改实现""约束没入库导致重复造轮子"——本质都能被 SDD + TDD + 上下文工程 的组合挡住。

六、下一步

• 继续阅读：最佳实践与反模式。