用 AI 写代码最怕的不是它不会做复杂算法，而是它在工程日常里把简单事做坏：用字符串硬拼 YAML、改完代码不跑编译、看到版本号数字小就机械升级。这类问题不够“炫”，但足够伤人，因为它们会直接进入仓库、CI 和线上配置。
这篇文章不讨论模型排名，也不把一次体验放大成绝对结论。更有价值的问题是：当 AI 编程助手在一周实测里暴露出这些低级错误时，团队应该怎样约束它、验证它，并决定哪些任务能交给它。
翻车点不高级，但很工程
摘要里提到的几个问题有共同特征：它们不是“智力题”，而是工程习惯。
用字符串拼结构化数据，是典型例子。YAML、JSON、TOML 都有自己的转义、缩进、类型规则。AI 如果直接写：
config = "name: " + name + "\nimage: " + image + "\n"
看上去能跑，遇到冒号、换行、布尔值、空字符串、缩进层级时就可能出错。更糟的是，配置文件通常会被部署系统消费，错误不一定在生成时爆炸，可能在发布时才爆炸。
“改完不编译”则是另一个信号：模型完成的是文本编辑，不是工程闭环。一个人类工程师写完会至少跑一次单测、类型检查或构建；AI 如果只交 diff，不交验证结果，就等于把验证成本转嫁给使用者。
至于“看到版本号数字小就往上加”，问题在于它没有尊重兼容性语义。版本不是分数，1.10 不比 1.9 “小”，主版本升级也不等于更好。依赖升级要看 changelog、约束范围、锁文件和测试结果。
AI 适合写草稿，不适合裸奔进主干
这类翻车说明，AI 编程助手更像一个速度很快但缺少项目上下文的初级合作者。它可以帮你起草函数、补测试样例、解释错误栈、生成迁移脚本草案；但它不应该绕过项目已有的质量闸门。
比较稳妥的分工是：
- 让 AI 生成局部实现，而不是直接重排大面积架构。
- 让 AI 给出验证命令，而不是只给“已完成”。
- 让 AI 修改结构化文件时使用结构化库，而不是字符串拼接。
- 让 AI 升级依赖时说明原因、范围、风险和回滚方式。
这里的关键不是“信不信 AI”，而是把 AI 产物当成普通代码处理：能 lint、能 test、能 review、能回滚。
可以这样实践：给 AI 产物加一道本地验收脚本
下面是一个可以直接运行的最小示例：它演示如何用 Python 安全生成 YAML，并在生成后立刻解析校验。你可以把它改造成项目里的配置生成脚本，替换掉字符串拼接。
运行前需要安装 PyYAML：
python -m pip install pyyaml
保存为 generate_deployment.py 后运行：
from pathlib import Path
import yaml
config = {
"apiVersion": "apps/v1",
"kind": "Deployment",
"metadata": {
"name": "demo-api",
"labels": {"app": "demo-api"},
},
"spec": {
"replicas": 2,
"selector": {"matchLabels": {"app": "demo-api"}},
"template": {
"metadata": {"labels": {"app": "demo-api"}},
"spec": {
"containers": [
{
"name": "demo-api",
"image": "ghcr.io/example/demo-api:1.4.2",
"ports": [{"containerPort": 8080}],
}
]
},
},
},
}
output = Path("deployment.yaml")
output.write_text(yaml.safe_dump(config, sort_keys=False), encoding="utf-8")
loaded = yaml.safe_load(output.read_text(encoding="utf-8"))
assert loaded["kind"] == "Deployment"
assert loaded["spec"]["template"]["spec"]["containers"][0]["image"].endswith(":1.4.2")
print(f"wrote and validated {output}")
执行：
python generate_deployment.py
python - <<'PY'
import yaml
from pathlib import Path
print(yaml.safe_load(Path('deployment.yaml').read_text())['metadata']['name'])
PY
如果你的项目已经使用 Kubernetes，还可以继续加服务端校验或 dry-run：
kubectl apply --dry-run=client -f deployment.yaml
这段示例的重点不是 Kubernetes，而是工作方式：AI 可以帮你写 config 结构，但最终必须经过解析器和验证命令，而不是靠肉眼看缩进。
给 AI 的提示词也要带验收条件
很多人让 AI 写代码时，只说“帮我实现 X”。这会鼓励模型尽快吐出代码，而不是完成工程任务。可以把提示词改成下面这种形式：
请修改这个 Python 项目中的配置生成逻辑：
1. 不允许用字符串拼接生成 YAML，必须使用 PyYAML 或项目中已有的 YAML 库。
2. 修改后补一个最小测试，覆盖包含冒号、空字符串、数字版本号的字段。
3. 给出你建议我运行的验证命令，例如 pytest、ruff、mypy 或项目已有构建命令。
4. 如果需要升级依赖，先说明原因和兼容性风险，不要直接改版本号。
这不是保证 AI 不犯错的魔法，但它能把输出从“代码片段”拉回“可验证变更”。尤其是在 DeepSeek 或其他模型容易犯低级工程错误的场景里，提示词里的约束比泛泛地要求“写得健壮”有效得多。
落地建议：把 AI 当加速器，不当合并权限
一周实测暴露的问题提醒我们：AI 编程助手的价值和风险通常同时出现。它能快速生成代码，也能快速制造看似合理的坏代码。
团队可以用一个简单清单控制风险：
- 结构化数据必须用结构化库生成和解析。
- 每次 AI 修改后必须跑编译、测试、lint 中至少一项。
- 依赖升级必须说明版本语义、兼容性和回滚方案。
- 大改动拆小提交，避免一次性接受大段 diff。
- 对配置、部署、权限、数据迁移类变更提高 review 等级。
AI 写代码翻车并不稀奇，真正危险的是我们把它的输出当成已经完成的工程结果。让 AI 负责提速，让工具链负责验收，让工程师负责判断边界，这才是当前更现实的用法。