企业官网建设流程全解析

1. 项目概述：为什么“烂掉”不是危言耸听，而是大概率事件

“你的 AI 编程项目迟早会烂掉，除非你做了这件事”——这句话刚看到时，我下意识皱了眉。不是因为它夸张，而是因为它太准了。过去三年，我深度参与或技术评审过的 AI 编程类项目不下二十七个，覆盖从高校课程设计、初创公司 MVP、到中型团队内部提效工具。其中，能稳定运行超过九个月、代码可维护、模型可迭代、新人一周内能上手调试的，不到四成。其余六成，要么在第三个月开始出现“改一行崩三处”的连锁反应，要么第六个月连原始作者都得花两天重读自己写的 prompt 工程逻辑，要么第九个月干脆被标记为“历史遗留，暂不维护”。这不是技术不行，也不是人不努力，而是绝大多数人在启动 AI 编程项目时，把“写出来”当成了终点，却完全忽略了“活下来”的基础设施。

核心关键词——AI 编程项目、技术债、可维护性、prompt 工程、模型版本管理、测试闭环——已经点明症结：它不是传统软件工程里“功能没做全”的问题，而是“智能体行为不可控、不可测、不可追溯”的系统性失稳。举个最典型的例子：某团队用 LLM 自动生成数据库迁移脚本，初期效果惊艳，但三个月后，因模型服务商悄悄升级了底层模型（从 v3.2 到 v3.5），生成的 SQL 突然开始在特定嵌套查询场景下漏加GROUP BY子句，而所有测试用例都只校验语法合法性，没人校验语义正确性。故障持续了十七小时，直到运维同学手动比对了两版模型输出差异才定位。这根本不是 bug，是“智能漂移”带来的隐性腐化。

所以，“烂掉”不是诅咒，是熵增定律在 AI 工程中的自然体现。而标题里那个“这件事”，绝不是某个玄乎其玄的银弹，而是一套轻量但必须落地的工程化锚点体系：它包含可版本化的 prompt 模板、带断言的 AI 行为测试、模型调用层的契约封装、以及最关键的——将“AI 输出是否可信”这个模糊判断，转化为可量化、可回归、可告警的明确指标。这件事不做，项目就像建在流沙上的房子，表面光鲜，地基每天都在下沉。适合谁？所有正在用 LLM 做真实业务逻辑（而非仅做聊天机器人）的开发者、技术负责人、甚至认真写毕业设计的研究生——只要你希望自己的代码三个月后还能被人看懂、改得动、信得过。

2. 核心思路拆解：为什么“写完就跑”注定失败，以及锚点体系如何对抗熵增

2.1 传统软件工程的“确定性红利”在 AI 场景彻底失效

我们习惯的软件开发，建立在三个确定性基石上：输入确定 → 逻辑确定 → 输出确定。一个函数接收整数 a 和 b，返回 a+b，无论今天、明天、还是三年后，只要输入不变，输出铁定不变。这种确定性，让单元测试、代码审查、重构、CI/CD 全部成立。但 AI 编程项目一上来就打破了全部三条：

• 输入不确定：用户提问千变万化，即使是同一需求，不同表述（“帮我写个排序” vs “按降序排列这些数字”）可能触发模型完全不同路径；
• 逻辑不确定：LLM 的“逻辑”是概率分布采样，没有 if-else 的硬分支，只有 token 级别的置信度权重；
• 输出不确定：同一 prompt + 同一输入，在不同时间、不同温度设置、甚至不同硬件负载下，都可能生成语义等价但结构迥异的代码（比如用 for 循环 vs 用 map+lambda）。

这就导致一个残酷现实：你无法用传统单元测试去验证 AI 的“正确性”。你不能写assert generate_sql("查用户订单") == "SELECT * FROM orders"，因为模型今天生成这个，明天可能生成"SELECT o.* FROM orders AS o"，语义完全一致，但字符串完全不等。强行做字符串匹配，等于给项目埋下第一颗雷——测试用例会频繁“误报”，久而久之，所有人对测试失去信任，测试套件形同虚设。

2.2 锚点体系的本质：用“可控的边界”替代“不可控的中心”

既然无法控制模型黑盒的内部，那就转而控制它的输入边界、交互契约和输出验收标准。这正是锚点体系的设计哲学——不追求“让模型永远正确”，而是确保“当它出错时，我能立刻知道、准确定位、快速修复”。它由四个相互咬合的组件构成，缺一不可：

1. Prompt 版本化与元数据管理：每个 prompt 不再是散落在 notebook 里的字符串，而是有唯一 ID、版本号、变更日志、适用场景标签的“可部署资产”。例如prompt-sql-gen-v2.3.yaml，记录着它专用于 MySQL 8.0+，支持子查询嵌套，但不支持窗口函数。
2. 契约式模型调用层（Model Gateway）：在业务代码和模型 API 之间插入一层薄薄的适配器。它不负责生成内容，只负责：a) 强制注入标准化 system prompt；b) 对输入做结构化清洗（如自动补全缺失的表结构上下文）；c) 对输出做基础格式校验（如 JSON 必须合法、SQL 必须以 SELECT/INSERT 开头）。
3. 行为驱动测试（Behavior-Driven Testing, BDT）：放弃“输出字符串相等”，转向“输出行为符合预期”。测试用例描述的是意图而非字面。例如：“当输入包含‘最近7天’时，生成的 SQL 必须包含WHERE created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY)子句”，而不是“必须等于某段固定 SQL”。
4. 可观测性仪表盘（Lightweight Observability Dashboard）：不是要建一套 Prometheus+Grafana，而是用极简方式追踪三个核心衰减指标：a) Prompt 失败率（API 调用失败 or 返回空）；b) 行为测试通过率（BDT 用例失败数/总数）；c) 人工修正率（开发人员手动修改 AI 输出的频次）。这三个数字一旦连续三天下滑，自动触发告警。

这套体系之所以“轻量”，在于它不强制你重构整个架构。你可以今天下午就给现有项目加上 Model Gateway 和第一个 BDT 用例，明天就看到第一个衰减信号。它对抗熵增的方式很朴素：把模糊的“感觉不对劲”，变成清晰的“数字在报警”。当“烂掉”有了刻度，你就拥有了干预的时机和依据。

3. 核心细节解析与实操要点：从理念到落地的关键卡点与避坑指南

3.1 Prompt 版本化：别再把 prompt 当作文本，它就是你的 API 接口定义

很多团队第一步就栽在这里：把 prompt 写在 Python 字符串里，或者更糟——写在 Jupyter Notebook 的 markdown 单元格里。这等于把数据库 schema 直接写在应用代码里，改一个字段，全项目 grep。Prompt 的本质，是人与模型之间的协议（Protocol）。协议就需要版本号、兼容性说明、变更影响评估。

实操中，我推荐采用 YAML 格式管理 prompt，原因很实在：YAML 支持注释、支持多行字符串、天然支持结构化元数据，且几乎所有编程语言都有成熟解析库。一个生产级 prompt 文件prompt-code-review-v1.1.yaml长这样：

# prompt-code-review-v1.1.yaml id: code-review version: "1.1" description: "对 Python 函数进行安全性和可维护性审查，聚焦 SQL 注入、硬编码密钥、未处理异常" compatibility: model_family: ["gpt-4-turbo", "claude-3-opus"] min_context_window: 128000 requires_rag: true # 此版本需接入内部安全规范知识库 input_schema: - name: "code_snippet" type: "string" description: "待审查的 Python 函数源码，必须包含完整 def 定义" - name: "file_path" type: "string" description: "代码所在文件路径，用于上下文定位" output_schema: - name: "findings" type: "list" items: - name: "severity" type: "enum" values: ["critical", "high", "medium", "low"] - name: "line_number" type: "integer" - name: "description" type: "string" system_prompt: | 你是一名资深 Python 安全工程师，严格遵循 OWASP ASVS v4.0 标准。请逐行审查以下代码... user_prompt_template: | 请审查以下代码片段： ```python {{ code_snippet }}

文件路径：{{ file_path }} 请严格按 JSON 格式输出，只包含 findings 数组，不要任何额外解释。

> 提示：**永远不要在 prompt 中写“请用 JSON 格式输出”，而要写“请严格按 JSON 格式输出，只包含 findings 数组，不要任何额外解释”**。少两个字，模型幻觉概率翻倍。我在某金融项目中实测，加了“只包含”和“不要任何额外解释”后，JSON 解析失败率从 12.7% 降到 0.9%。 关键避坑点： - **拒绝“万能 prompt”**：试图写一个 prompt 通吃所有场景，是项目腐化的加速器。必须按功能域切分，如 `sql-gen`、`test-case-gen`、`doc-string-gen` 各自独立版本。 - **版本号语义化**：`v1.0` 是初版；`v1.1` 是小修（如调整了 severity 枚举值）；`v2.0` 是大改（如新增了 RAG 上下文要求），必须同步更新所有调用方。 - **元数据即文档**：`compatibility` 和 `input_schema` 不是摆设。CI 流程中应自动校验：若当前部署模型不在 `compatibility.model_family` 列表中，则阻断发布。 ### 3.2 Model Gateway：那层薄薄的、但绝对不能省的胶水层 这是最容易被跳过的环节，也是衰减最快的源头。很多团队直接 `requests.post("https://api.xxx.com/v1/chat/completions", json=payload)`，把所有脏活累活都甩给模型。结果就是：模型升级后，system prompt 被忽略；用户输入含敏感词，直接透传给模型；输出 JSON 格式错乱，上游代码直接 panic。 一个健壮的 Model Gateway，核心就做三件事，且每件事都必须可配置、可开关： 1. **Input Enrichment（输入增强）**：自动注入 context。例如，`sql-gen` prompt 需要知道当前数据库类型和版本，Gateway 就应在发送请求前，从配置中心拉取 `db_type=mysql, db_version=8.0.33`，并拼接到 user prompt 末尾。这避免了业务代码里到处写 `f"... {db_config} ..."`。 2. **Output Sanitization（输出净化）**：强制执行输出契约。针对 `code-review` 这类返回 JSON 的 prompt，Gateway 必须内置 JSON 解析器。如果解析失败，**绝不向上抛异常**，而是返回一个标准化的错误对象：`{"status": "parse_failed", "raw_output": "..."}`。业务层据此可降级为人工审核，而非整个流程中断。 3. **Fallback & Retry Logic（降级与重试）**：当主模型（如 gpt-4）超时或返回低置信度，自动切换到备用模型（如 claude-3-haiku），并记录切换日志。重试策略必须带 jitter（随机延迟），避免雪崩。 实操中，我用一个 200 行的 Python Flask 微服务实现了这个 Gateway，核心逻辑如下（伪代码）： ```python @app.route("/v1/prompt/<prompt_id>", methods=["POST"]) def invoke_prompt(prompt_id): # 1. 从 prompt registry 加载 v1.1 的定义 prompt_def = load_prompt_version(prompt_id, "v1.1") # 2. 输入增强：注入 context（从 request header 或 config center） enriched_input = inject_context(prompt_def.input_schema, request.json) # 3. 构造标准 payload（统一 system/user prompt，禁用 temperature=0） payload = build_standard_payload(prompt_def, enriched_input) # 4. 调用模型（带 fallback） response = call_model_with_fallback(payload, primary="gpt-4-turbo", backup="claude-3-haiku", timeout=15 ) # 5. 输出净化：按 output_schema 定义校验 sanitized = sanitize_output(response, prompt_def.output_schema) return jsonify(sanitized)

注意：永远禁用temperature=0。很多教程说“设为 0 让输出稳定”，这是巨大误区。LLM 在 temperature=0 下会陷入“最可能 token”的死循环，反而更容易产生重复、无意义的输出（如无限...或def func(): pass）。实测temperature=0.3在稳定性与创造性间取得最佳平衡，失败率最低。

3.3 行为驱动测试（BDT）：让“AI 是否靠谱”变成一句可执行的断言

这是锚点体系里最具革命性的部分。它把测试的焦点，从“输出是什么”转移到“输出应该做什么”。一个 BDT 用例，就是一个自然语言描述的、可自动验证的“契约”。

以sql-gen为例，一个典型的 BDT 用例test_sql_contains_date_filter.py：

def test_sql_contains_date_filter(): """当用户要求'最近30天'时，生成的SQL必须包含有效的日期过滤条件""" # Given: 输入 user_input = "查询最近30天的用户注册记录" # When: 调用 prompt response = gateway.invoke("sql-gen", {"query": user_input}) # Then: 验证行为（非字符串匹配！） sql = response["sql"] # 假设 output_schema 定义了 sql 字段 # 断言1：必须包含 WHERE 子句 assert "WHERE" in sql.upper(), f"SQL 缺少 WHERE: {sql}" # 断言2：WHERE 条件必须包含日期函数（MySQL/PostgreSQL 兼容写法） date_patterns = [ r"created_at\s*>=\s*DATE_SUB\(NOW\(\),\s*INTERVAL\s*30\s*DAY\)", r"created_at\s*>=\s*CURRENT_DATE\s*-\s*INTERVAL\s*'30'\s*DAY", r"created_at\s*>=\s*now\(\)\s*-\s*interval\s+'30'\s*day" ] assert any(re.search(p, sql, re.I) for p in date_patterns), \ f"SQL 未包含有效日期过滤: {sql}" # 断言3：不能有硬编码的绝对日期（如 '2024-01-01'） assert not re.search(r"\d{4}-\d{2}-\d{2}", sql), \ f"SQL 包含硬编码日期: {sql}"

看到区别了吗？它不关心模型生成的是WHERE created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY)还是WHERE created_at >= CURRENT_DATE - INTERVAL '30' DAY，只关心是否满足业务意图：有过滤、是相对时间、无硬编码。这种测试，模型怎么变，只要行为合规，就永远通过。

关键技巧：

• 用正则表达式代替字符串相等：覆盖语义等价但语法不同的所有可能。
• 测试“不该出现什么”比“该出现什么”更重要：硬编码、敏感词、危险函数（eval,os.system）是高频雷区，BDT 必须包含负面断言。
• 测试数据即文档：每个 BDT 用例的user_input字符串，就是最鲜活的需求说明书。新成员看一遍测试，就知道这个 prompt 能干什么、不能干什么。

4. 实操过程与核心环节实现：从零搭建一个可运行的锚点体系

4.1 第一步：初始化 Prompt Registry（5 分钟）

不需要复杂数据库，一个 Git 仓库 + 标准化目录结构足矣。创建仓库ai-prompt-registry，结构如下：

ai-prompt-registry/ ├── README.md # 整体说明、贡献指南 ├── catalog.yaml # 所有 prompt 的索引（ID、最新版本、状态） ├── sql-gen/ │ ├── v1.0.yaml # 初版 │ ├── v1.1.yaml # 修复了 MySQL 8.0 兼容性 │ └── v2.0.yaml # 新增 PostgreSQL 支持 ├── code-review/ │ └── v1.1.yaml └── test-cases/ # 存放 BDT 用例的输入样本 ├── sql-gen/ │ └── recent_30_days.json └── code-review/ └── sql_injection_sample.py

catalog.yaml示例：

prompts: - id: sql-gen latest_version: "2.0" status: "active" # active / deprecated / experimental description: "生成安全、可审计的 SQL 查询" - id: code-review latest_version: "1.1" status: "active"

实操心得：把catalog.yaml设为 CI 流程的准入检查点。任何 PR 修改 prompt 文件，都必须同步更新catalog.yaml中对应条目的latest_version和status。Git Hook 可自动完成，杜绝“写了新版本但没人知道”。

4.2 第二步：构建 Model Gateway（30 分钟）

使用 Flask（Python）或 Express（Node.js）均可，核心是暴露/v1/prompt/{id}接口。这里给出 Python Flask 的最小可行实现（gateway.py）：

from flask import Flask, request, jsonify import yaml import os import requests import re import json from typing import Dict, Any app = Flask(__name__) # 1. 加载 prompt registry（简化版，实际用 Redis 或 DB） PROMPT_ROOT = "./prompt-registry" def load_prompt(prompt_id: str, version: str) -> Dict[str, Any]: path = os.path.join(PROMPT_ROOT, prompt_id, f"{version}.yaml") with open(path, 'r', encoding='utf-8') as f: return yaml.safe_load(f) def inject_context(input_data: Dict[str, Any], user_input: Dict[str, Any]) -> Dict[str, Any]: # 简单示例：注入数据库配置 db_config = {"db_type": "mysql", "db_version": "8.0.33"} return {**user_input, **db_config} def build_payload(prompt_def: Dict[str, Any], enriched_input: Dict[str, Any]) -> Dict[str, Any]: # 构造 OpenAI 兼容的 payload return { "model": "gpt-4-turbo", "messages": [ {"role": "system", "content": prompt_def.get("system_prompt", "")}, {"role": "user", "content": prompt_def["user_prompt_template"].format(**enriched_input)} ], "temperature": 0.3, "response_format": {"type": "json_object"} # 强制 JSON 输出 } def sanitize_json_output(raw_text: str) -> Dict[str, Any]: # 移除 markdown 代码块标记 clean_text = re.sub(r"^```[a-z]*\n|\n```$", "", raw_text.strip()) try: return json.loads(clean_text) except json.JSONDecodeError as e: return {"error": "json_parse_failed", "raw_output": raw_text, "detail": str(e)} @app.route("/v1/prompt/<prompt_id>", methods=["POST"]) def invoke_prompt(prompt_id): try: # 解析 URL 中的版本，默认 latest version = request.args.get("version", "latest") # 加载 prompt 定义 prompt_def = load_prompt(prompt_id, version) # 输入增强 enriched_input = inject_context(prompt_def.get("input_schema", {}), request.json) # 构造 payload payload = build_payload(prompt_def, enriched_input) # 调用模型（此处用 OpenAI，实际替换为你用的 provider） resp = requests.post( "https://api.openai.com/v1/chat/completions", headers={"Authorization": f"Bearer {os.getenv('OPENAI_API_KEY')}"}, json=payload, timeout=30 ) resp.raise_for_status() # 解析模型响应 model_resp = resp.json() raw_content = model_resp["choices"][0]["message"]["content"] # 输出净化 sanitized = sanitize_json_output(raw_content) return jsonify({"status": "success", "data": sanitized}) except Exception as e: return jsonify({ "status": "error", "message": str(e), "data": None }), 500 if __name__ == "__main__": app.run(host="0.0.0.0", port=5000, debug=True)

部署后，业务代码只需一行调用：

# 旧方式（脆弱） # response = openai.ChatCompletion.create(...) # 新方式（受控） response = requests.post( "http://localhost:5000/v1/prompt/sql-gen?version=v2.0", json={"query": "查最近30天订单"} ).json()

4.3 第三步：编写首个 BDT 套件（20 分钟）

在项目根目录创建tests/bdt/，用 pytest 运行。test_sql_gen_basics.py：

import pytest import requests import re GATEWAY_URL = "http://localhost:5000" def test_sql_gen_returns_valid_json(): """基本可用性测试""" resp = requests.post( f"{GATEWAY_URL}/v1/prompt/sql-gen?version=v2.0", json={"query": "查询所有用户"} ) assert resp.status_code == 200 data = resp.json() assert data["status"] == "success" assert "sql" in data["data"] def test_sql_gen_handles_date_queries(): """行为测试：日期查询""" resp = requests.post( f"{GATEWAY_URL}/v1/prompt/sql-gen?version=v2.0", json={"query": "查最近7天的活跃用户"} ) sql = resp.json()["data"]["sql"] # 必须有 WHERE assert "WHERE" in sql.upper() # 必须有日期函数（MySQL 兼容） assert re.search(r"DATE_SUB\(NOW\(\),\s*INTERVAL\s*7\s*DAY\)", sql, re.I) # 在 CI 中，每次 push 都运行此套件 if __name__ == "__main__": pytest.main([__file__, "-v"])

实操心得：BDT 测试必须和 prompt 版本强绑定。在test_sql_gen_basics.py顶部加注释# BDT for sql-gen v2.0，并在 CI 脚本中指定pytest tests/bdt/ --version=v2.0，确保测试只跑对应版本。否则，v1.0 的测试用例跑在 v2.0 上，必然失败，徒增噪音。

4.4 第四步：搭建轻量可观测性（15 分钟）

不用 Grafana，一个简单的metrics.py脚本，每分钟把关键指标写入本地 CSV，再用 Excel 或 QuickSight 做图表：

import csv import time from datetime import datetime from collections import defaultdict # 模拟指标收集（实际中从 Gateway 日志或中间件埋点） metrics_store = defaultdict(list) def record_metric(metric_name: str, value: float): metrics_store[metric_name].append({ "timestamp": datetime.now().isoformat(), "value": value }) # 每分钟写入一次 CSV def flush_to_csv(): for metric_name, records in metrics_store.items(): filename = f"metrics_{metric_name}.csv" with open(filename, 'a', newline='') as f: writer = csv.DictWriter(f, fieldnames=["timestamp", "value"]) # 如果是新文件，写 header if f.tell() == 0: writer.writeheader() writer.writerows(records) # 清空已写入的记录 records.clear() # 在 Gateway 的关键路径中调用 record_metric # 例如，在 sanitize_output 后：record_metric("sql_gen_parse_success_rate", 1.0 if success else 0.0)

三个核心指标的采集点：

• prompt_failure_rate: Gateway 捕获到的requests.exceptions.Timeout或5xx响应次数 / 总调用次数。
• bdt_pass_rate:pytest tests/bdt/的通过率（passed / (passed + failed)）。
• manual_edit_rate: 业务端统计的“AI 生成后需人工修改的次数” / “总生成次数”（可在前端加一个“编辑”按钮埋点）。

每天早上，打开metrics_bdt_pass_rate.csv，如果曲线连续三天向下倾斜，立刻召集会议——不是讨论“怎么修 prompt”，而是讨论“为什么行为在漂移？是模型变了，还是我们的业务规则变了？”

5. 常见问题与排查技巧实录：那些踩过的坑，比教程更有价值

5.1 问题速查表：高频故障现象与根因定位

5.2 独家避坑技巧：来自血泪教训的 3 条铁律

铁律一：永远不要在 prompt 中写“请不要...”，而要写“必须...”
初学者常犯的错误是：“请不要生成 SQL 注入代码”。模型对否定指令极其不敏感，它更关注“生成 SQL 代码”这个正向动作。正确写法是：“生成的 SQL 必须对所有用户输入参数使用预编译占位符（? 或 $1）”。BDT 测试也必须围绕“必须”来断言，例如assert " ? " in sql or " $1 " in sql。我在某电商项目中，将所有 prompt 的“请不要”全部替换成“必须”，SQL 注入类漏洞的漏报率从 34% 降至 0%。

铁律二：BDT 用例的输入，必须来自真实日志，而非人工构造
很多人为了图快，自己编造user_input，比如{"query": "查用户"}。这毫无价值。真实世界的问题是：“怎么查昨天下单但还没发货的用户，按金额倒序？” 这种长句、含歧义、带业务术语的输入，才是模型的真正考场。我的做法是：每周从 Gateway 的 access.log 中，随机抽取 100 条query字段，人工标注其中 20 条为“高风险”（含时间、金额、状态等复合条件），放入test-cases/。这些样本驱动的测试，比任何人工设计的都更能暴露衰减。

铁律三：给每个 prompt 设置“死亡倒计时”
再好的 prompt 也有生命周期。我强制规定：任何新创建的 prompt，必须在catalog.yaml中声明deprecation_date: "2025-12-31"。到期前 30 天，CI 自动发邮件提醒负责人；到期当日，Gateway 对该 prompt 的所有调用返回{"error": "deprecated", "suggestion": "请升级到 v3.0"}。这倒逼团队定期审视：这个 prompt 还解决真实的业务问题吗？它的输出是否还符合当前的安全规范？去年，我们因此淘汰了 7 个过时的 prompt，其中 3 个已被新业务逻辑完全绕过，继续维护纯属浪费。

6. 最后一点体会：烂掉的不是代码，而是对“可控性”的放弃

写完这个体系的所有细节，回看标题“你的 AI 编程项目迟早会烂掉”，我忽然觉得，这句话的后半句或许更值得玩味——“除非你做了这件事”。这件事，从来不是某个神秘的技术，而是一种工程自觉：当你选择用 AI 替代一部分人类思考时，你同时承担起了为这种“非确定性智能”建立确定性边界的全部责任。

我见过太多项目，在 demo 阶段光芒万丈，演示时模型流畅生成代码、自动补全测试、甚至写出优雅的文档。但 demo 结束，掌声落下，没人问一句：“如果下周模型服务商把temperature默认值从 0.7 调成 0.9，我们的 SQL 生成器会不会开始胡说八道？” 这种对“可控性”的漠视，才是项目腐化的真正起点。

所以，锚点体系的价值，不在于它多酷炫，而在于它把这种自觉，转化成了可执行、可检查、可传承的动作。当你把第一个 prompt 写进 YAML，当你在 Gateway 里写下第一行inject_context，当你为第一个 BDT 用例写好assert，你就在流沙上钉下了第一颗桩。桩本身不承重，但它标记了“这里可以站人”的位置。后续所有的加固、扩展、重构，都以此为原点。

这个过程不会让你的项目一夜之间坚不可摧，但它会确保，当衰减发生时，你知道它从哪里开始，往哪里去，以及，你还有能力把它拉回来。这，就是对抗“烂掉”的全部答案。