AI 可以迅速生成接口、测试和基础实现，让开发工作的前 80% 显得异常顺畅。真正危险的是剩下的 20%：隐含依赖、跨模块约束、历史决策和运行时边界往往要到集成阶段才暴露。此时，代码虽然增长很快，团队对系统的理解却没有同步增长。
解决方向不是单纯限制 AI 生成代码，而是把规格驱动开发（SDD）、测试驱动开发（TDD）和自动化架构适应度函数统一放进仓库，形成一个可版本化、可执行、可被人和 AI 共同读取的 Context Store。
Context Store 不是另一套文档系统
这里的 Context Store 可以理解为仓库内的“工程上下文控制面”。它至少包含三类信息：
- 规格锚点：功能目标、输入输出、非功能约束和验收条件。
- 行为证据：单元测试、集成测试、契约测试以及失败场景。
- 架构护栏：依赖方向、模块边界、安全规则和性能阈值。
这些内容必须和代码一起提交、审查和演进。若规格只存在于聊天记录，架构决策只存在于资深工程师的记忆中，AI agent 就只能根据局部代码猜测系统意图。即使生成结果能够编译，也可能悄悄破坏边界。
一个简单的仓库布局可以这样实践。以下结构是根据文章思想构造的示例，并非某个固定产品的 API：
project/
├── context/
│ ├── specs/
│ │ └── create-order.md
│ ├── decisions/
│ │ └── ADR-001-module-boundaries.md
│ └── architecture-rules.json
├── src/
│ ├── domain/
│ ├── application/
│ └── infrastructure/
├── tests/
│ └── test_create_order.py
└── tools/
└── check_architecture.py
这个目录不是为了增加文档数量，而是为了让关键上下文拥有稳定位置。开发者和 AI agent 在修改订单功能前，都应能找到对应规格、测试和架构规则。
把 SDD、TDD 和适应度函数连成闭环
三种机制解决的是不同问题。
SDD 说明“系统应该做什么”。例如，创建订单规格不应只写“新增下单接口”，还要明确幂等键、库存失败行为、金额精度和可接受延迟。规格越具体，AI 越不需要根据命名猜测业务规则。
TDD 把规格转换成可重复执行的行为证据。测试失败意味着实现尚未满足约定，而不是提示词写得不够长。对于 AI 生成的修改，测试还是最直接的反馈通道：agent 可以运行测试、读取失败信息，再缩小修改范围。
架构适应度函数检查的是单个测试通常覆盖不到的系统属性，例如：
- 领域层不得导入基础设施层。
- 新增公共 API 必须有对应规格。
- 数据库迁移必须保持向后兼容。
- 核心请求的延迟或包体积不得超过阈值。
三者组合后，变更流程形成闭环：规格定义意图，测试证明行为，适应度函数约束系统形状。代码生成速度可以提高，但合并条件不会因此放松。
一个可运行的最小架构检查器
可以先从最便宜、最确定的依赖规则开始。下面的 Python 脚本扫描 src/domain，阻止领域代码导入 infrastructure。它只使用 Python 标准库，可以直接运行。
将以下内容放入 tools/check_architecture.py：
from __future__ import annotations
import ast
import sys
from pathlib import Path
ROOT = Path(__file__).resolve().parents[1]
DOMAIN_DIR = ROOT / "src" / "domain"
FORBIDDEN_PREFIXES = ("src.infrastructure", "infrastructure")
def imported_modules(path: Path) -> list[tuple[int, str]]:
tree = ast.parse(path.read_text(encoding="utf-8"), filename=str(path))
imports: list[tuple[int, str]] = []
for node in ast.walk(tree):
if isinstance(node, ast.Import):
imports.extend((node.lineno, alias.name) for alias in node.names)
elif isinstance(node, ast.ImportFrom) and node.module:
imports.append((node.lineno, node.module))
return imports
def main() -> int:
violations: list[str] = []
if not DOMAIN_DIR.exists():
print(f"Domain directory not found: {DOMAIN_DIR}", file=sys.stderr)
return 2
for path in sorted(DOMAIN_DIR.rglob("*.py")):
for line, module in imported_modules(path):
if module.startswith(FORBIDDEN_PREFIXES):
relative_path = path.relative_to(ROOT)
violations.append(
f"{relative_path}:{line}: forbidden dependency on {module}"
)
if violations:
print("Architecture fitness check failed:")
print("\n".join(f"- {item}" for item in violations))
return 1
print("Architecture fitness check passed")
return 0
if __name__ == "__main__":
raise SystemExit(main())
创建最小目录并验证它：
mkdir -p src/domain src/infrastructure tools
printf 'from dataclasses import dataclass\n\n@dataclass\nclass Order:\n order_id: str\n' > src/domain/order.py
python tools/check_architecture.py
预期输出为：
Architecture fitness check passed
如果在 src/domain/order.py 中加入下面这行，检查器应以非零状态退出：
from src.infrastructure.database import save_order
这类检查并不理解完整架构，但它把一条重要规则从口头约定变成了可执行约束。后续可以逐步增加规则，而不是一开始建设庞大的治理平台。
让 CI 和 AI agent 使用同一份上下文
Context Store 的价值取决于它是否进入日常工作流。可以在 CI 中同时运行测试和架构检查：
name: context-store-checks
on:
pull_request:
push:
branches: [main]
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- name: Install test dependencies
run: python -m pip install pytest
- name: Run behavior tests
run: pytest -q
- name: Run architecture fitness functions
run: python tools/check_architecture.py
给 AI agent 的任务也应引用仓库内的锚点，而不是重复粘贴一大段临时背景。提示可以这样写：
实现 context/specs/create-order.md 中的验收条件。
修改前请读取：
- context/decisions/ADR-001-module-boundaries.md
- context/architecture-rules.json
- tests/test_create_order.py
约束：
1. 不得让 src/domain 依赖 src/infrastructure。
2. 先补充失败测试，再修改实现。
3. 运行 pytest -q 和 python tools/check_architecture.py。
4. 输出修改文件、测试结果和仍未覆盖的风险。
这种提示的关键不是措辞技巧，而是让 agent 使用与 CI、代码审查者相同的事实来源。上下文发生变化时，应修改仓库中的规格或决策记录，而不是依赖某次会话里的补充说明。
推行时要防止 Context Store 失真
Context Store 也会腐化。过期规格、永远通过的空洞测试，以及只检查文件名的伪架构规则，都会制造错误的安全感。因此，团队需要把上下文本身纳入评审：功能行为变化时更新规格，边界调整时记录决策，规则误报时修正规则和例外机制。
落地时可以按以下顺序推进：
- 选择一个频繁变更且边界清晰的模块作为试点。
- 为关键用例补齐规格、验收条件和现有行为测试。
- 把两到三条最重要的架构规则实现为快速检查器。
- 在拉取请求中强制运行测试和适应度函数。
- 要求 AI agent 在结果中列出读取的上下文、验证命令和未解决风险。
- 定期删除无价值规则，修复与真实系统脱节的规格。
AI 提高了代码生产速度，也压缩了团队发现错误方向的时间窗口。工程组织真正需要优化的指标不只是提交量，而是系统意图能否被快速、准确地恢复。把规格、测试和架构规则绑定到仓库，能够让这种理解具备版本、证据和自动反馈，也让演进式架构在 AI 加速的开发节奏下仍然可控。