1
月
在社区成长 1 月
LEVEL 1
1 XP
一、背景：为什么 AI 写得快，工程交付却未必更快
在 Cursor、VS Code + AI 插件、JetBrains AI Assistant 等编程环境中，生成一个函数、补齐一个类或解释一段代码已经非常方便。但在真实工程里，输入代码只占工作量的一部分，更多时间消耗在理解上下文、确认边界、复现问题、补充测试、调试失败以及审查变更上。
AI 编程最常见的低效模式是：让模型一次性修改大量文件，运行后发现报错，再把报错原样粘回对话框，经过多轮“猜测式修复”后，代码虽然暂时可运行，却引入了依赖膨胀、接口变化或测试覆盖不足等问题。
更稳妥的方法，是把 AI IDE 当作“受约束的结对编程工具”，建立如下闭环：
需求边界 → 提供最小上下文 → 先写验收测试 → 生成小范围补丁 → 本地执行 → 断点调试 → 审查差异 → 独立验证 → 提交。
本文以一个本地 Python 项目为例，演示如何让 AI 帮助实现日志解析功能，并通过测试与调试验证结果。示例只处理本地构造数据，不涉及任何未授权目标。
二、核心原理：AI IDE 真正需要的是约束与反馈
1. 上下文决定生成质量
AI 不会自动理解整个仓库。即使 IDE 支持代码索引，也可能遗漏运行时配置、隐式约定和外部依赖。因此，应主动提供：
- 目标文件及其直接调用者；
- 数据结构或接口定义；
- 现有测试与编码风格；
- 明确禁止修改的目录；
- 可执行的验收命令。
2. 测试比自然语言更适合作为验收标准
“完善日志解析”含义模糊，而“输入包含时间、级别和消息的单行文本，返回固定字段；非法行返回 None；不得抛出异常”是可验证的。把需求转化为测试后，AI 的任务就从开放式创作变成了满足约束。
3. 小补丁比大改造更容易审查
一次只修改一个行为，能快速判断失败来自实现、测试还是环境。建议单轮变更控制在一至三个文件内；如果 AI 建议顺便重构整个模块，应先拆分任务，而不是立即接受。
4. 调试信息应结构化反馈
不要只告诉 AI“还是不行”。更有效的信息包括：失败命令、异常类型、最短堆栈、实际值、期望值、Python 或运行时版本，以及是否能够稳定复现。
三、前置条件
本文示例需要：
- Python 3.10 或更高版本；
- 任意支持 AI 对话或补全的 IDE；
- Git；
- pytest；
- 一个独立的本地实验目录。
初始化项目：
mkdir ai-ide-lab
cd ai-ide-lab
python -m venv .venv
Linux/macOS 激活环境：
source .venv/bin/activate
Windows PowerShell 激活环境：
.venv\Scripts\Activate.ps1
安装测试工具并初始化仓库：
python -m pip install -U pip pytest
git init
mkdir src tests
创建 pyproject.toml：
[project]
name = 'ai-ide-lab'
version = '0.1.0'
requires-python = '>=3.10'
[tool.pytest.ini_options]
pythonpath = ['src']
testpaths = ['tests']
建议在开始使用 AI 修改前执行一次基线提交：
git add .
git commit -m 'chore: initialize local ai ide lab'
如果 Git 尚未配置身份，可以只执行 git diff 观察变化，不必为了实验强行提交。
四、分步骤实践
步骤 1：先定义接口，不让 AI 自由猜测
本例要解析如下格式的本地日志：
2025-03-08T10:20:30Z INFO service started
期望返回：时间戳、日志级别、消息。空行、缺少字段或未知级别返回 None。允许级别仅为 DEBUG、INFO、WARNING、ERROR。
创建 src/log_parser.py：
from dataclasses import dataclass
@dataclass(frozen=True)
class LogEntry:
timestamp: str
level: str
message: str
def parse_log_line(line: str) -> LogEntry | None:
raise NotImplementedError
这里先保留未实现状态。这样 AI 能看到稳定的接口，而不是自行决定函数名称、返回字典还是抛出异常。
步骤 2：要求 AI 先生成测试，而不是直接实现
在 AI IDE 中只选中 src/log_parser.py，并给出类似提示：
“请为 parse_log_line 设计 pytest 测试。约束：有效行返回 LogEntry；允许四种级别；消息可以包含空格；空行、字段不足、未知级别返回 None；当前阶段只新增 tests/test_log_parser.py，不修改生产代码。请覆盖正常、边界和非法输入。”
生成后不要立即接受全部内容，重点检查测试是否真正覆盖了需求。一个可用的测试文件可以是：
from log_parser import LogEntry, parse_log_line
def test_parse_valid_line():
result = parse_log_line('2025-03-08T10:20:30Z INFO service started')
assert result == LogEntry(
timestamp='2025-03-08T10:20:30Z',
level='INFO',
message='service started',
)
def test_message_may_contain_spaces():
result = parse_log_line('2025-03-08T10:20:30Z ERROR file open failed')
assert result is not None
assert result.message == 'file open failed'
def test_empty_line_returns_none():
assert parse_log_line('') is None
def test_missing_message_returns_none():
assert parse_log_line('2025-03-08T10:20:30Z INFO') is None
def test_unknown_level_returns_none():
assert parse_log_line('2025-03-08T10:20:30Z TRACE detail') is None
先运行：
pytest -q
此时测试失败是预期结果，因为实现仍抛出 NotImplementedError。这个“先红后绿”的过程能确认测试确实执行到了目标代码。
步骤 3：让 AI 在明确边界内实现最小补丁
第二轮提示应限制改动范围：
“根据 tests/test_log_parser.py 实现 parse_log_line。只修改 src/log_parser.py，不增加第三方依赖，不改变 LogEntry 定义，不修改测试。优先使用一次字符串切分，并说明对非法输入的处理路径。”
合理实现如下：
from dataclasses import dataclass
_ALLOWED_LEVELS = {'DEBUG', 'INFO', 'WARNING', 'ERROR'}
@dataclass(frozen=True)
class LogEntry:
timestamp: str
level: str
message: str
def parse_log_line(line: str) -> LogEntry | None:
parts = line.strip().split(maxsplit=2)
if len(parts) != 3:
return None
timestamp, level, message = parts
if level not in _ALLOWED_LEVELS or not message:
return None
return LogEntry(timestamp=timestamp, level=level, message=message)
再次运行：
pytest -q
通过后，不要马上结束。继续查看变更：
git diff -- src/log_parser.py tests/test_log_parser.py
审查时关注：AI 是否偷偷修改了测试来迁就实现；是否加入不必要的包；是否改变公开接口；是否用过宽的 except Exception 吞掉真实错误。
步骤 4：主动制造边界失败，验证 AI 没有只迎合样例
当前实现没有验证时间戳格式。如果需求明确要求 UTC ISO 形式，就应先增加失败测试：
def test_invalid_timestamp_returns_none():
assert parse_log_line('not-a-time INFO service started') is None
执行：
pytest -q tests/test_log_parser.py::test_invalid_timestamp_returns_none
确认测试失败后，再让 AI 只补充时间戳验证。提示中应说明是否允许标准库、是否接受带时区偏移的时间，以及是否必须以 Z 结尾。不要简单说“验证时间格式”，否则不同实现会产生不同语义。
例如，若规则是“必须为以 Z 结尾的 UTC 时间”，可使用标准库：
from datetime import datetime
def _is_utc_timestamp(value: str) -> bool:
if not value.endswith('Z'):
return False
try:
datetime.fromisoformat(value[:-1] + '+00:00')
except ValueError:
return False
return True
然后在构造 LogEntry 前调用该函数。此时再次运行全部测试，而不是只运行新用例：
pytest -q
步骤 5：在 IDE 中进行断点调试
当测试输出不足以说明问题时，可在 parse_log_line 第一行设置断点，并以调试方式运行单个测试。建议观察：
- line 的原始值是否含换行符；
- strip 后是否丢失了业务上需要保留的空白；
- split(maxsplit=2) 的结果长度；
- level 的大小写是否符合接口约定；
- 时间解析抛出的具体异常。
对于 VS Code，可创建 .vscode/launch.json：
{
'version': '0.2.0',
'configurations': [
{
'name': 'Debug current pytest file',
'type': 'debugpy',
'request': 'launch',
'module': 'pytest',
'args': ['${file}', '-q', '-s'],
'console': 'integratedTerminal'
}
]
}
注意：标准 JSON 实际要求双引号。如果手工创建 launch.json，应把示例中的单引号替换为双引号。这里使用单引号只是为了避免与文章载体的字符串转义混淆。
断点调试得到证据后，再将结论交给 AI。例如：
“失败输入末尾包含换行，line.strip() 后切分正确；实际问题是时间字符串带毫秒，当前校验误判。请只调整 _is_utc_timestamp，并增加毫秒时间测试，不改级别解析。”
这种反馈比直接粘贴整个终端更有效，也能减少模型修改无关代码。
步骤 6：建立提交前的固定检查链
可以在项目根目录创建简单脚本 scripts/check.sh：
#!/usr/bin/env sh
set -eu
python -m compileall -q src
pytest -q
git diff --check
赋予执行权限并运行：
chmod +x scripts/check.sh
./scripts/check.sh
Windows 用户可以用 PowerShell 编写等价脚本。关键不在脚本语言，而在于把验收流程固定下来。今后每次接受 AI 补丁，都先运行同一条命令，避免“这次忘了跑某项检查”。
步骤 7：用 Git 将 AI 改动限制在可回退范围
建议每个小任务采用独立分支：
git switch -c feature/log-parser
git status --short
git diff --stat
./scripts/check.sh
git add src/log_parser.py tests/test_log_parser.py scripts/check.sh
git diff --cached
git commit -m 'feat: add validated local log parser'
其中 git diff --cached 是非常重要的一步。AI IDE 的界面可能折叠部分修改，而暂存区差异能帮助发现意外文件、调试输出、硬编码路径和配置泄露。
五、提升补全质量的具体技巧
1. 补全前先写函数签名、类型标注和简短文档。相比空白文件，明确接口能显著减少无关生成。
2. 将“大功能”拆为可验证动作。例如不要一次要求“实现日志分析系统”，而应拆为解析单行、读取文件、聚合级别、输出报告四个任务。
3. 提示中加入不变量，例如“不得网络访问”“不得新增依赖”“不得修改测试”“非法输入不抛异常”。
4. 对 AI 给出的命令逐条阅读后再执行。尤其要警惕递归删除、覆盖配置、全局安装、修改权限以及来源不明的下载命令。
5. 对重复代码可使用行内补全，对跨文件设计则使用对话或代理模式。不要为了生成三行条件判断而开放整个仓库的写权限。
6. 每轮对话只解决一个失败。如果同时混入格式化、重构、性能优化和修复测试，出现回归时很难定位责任变更。
六、风险与注意事项
1. 隐私与代码外发
使用云端 AI 服务前，应确认项目授权、组织政策和插件的数据处理方式。密钥、客户数据、私有样本、崩溃转储和内部日志不应直接放入提示。可以先构造最小复现，用虚拟值替换敏感字段。
2. 提示注入与仓库内不可信文本
当 AI IDE自动读取 README、Issue、代码注释或外部依赖文档时，其中的文本可能包含误导性指令。仓库内容应被视为数据，而不是高优先级命令。不要允许代理在无人审查的情况下执行终端命令、上传文件或改写大量配置。
3. 生成代码的正确性与许可证
能运行不等于满足业务语义。必须由开发者审查算法、异常路径、兼容性和依赖来源。对来源不明确的大段生成代码，还应遵循所在组织的许可证审查流程。
4. 测试被“修绿”
当 AI 同时拥有生产代码和测试写权限时，它可能通过降低断言强度、删除边界用例或增加无条件跳过来让测试通过。因此，修复实现阶段应明确禁止修改测试，并通过 git diff 复核。
5. 调试数据泄露
堆栈、环境变量、请求头和内存内容可能包含令牌。复制到 AI 对话前要脱敏。安全分析或恶意样本研究应限定在本地隔离环境、授权靶场和防御用途，不要让 IDE 代理直接访问真实目标或生产凭据。
七、常见问题
问题 1：AI 总是修改无关文件怎么办？
先缩小上下文，只选中目标文件；在提示中列出允许修改的路径；应用补丁前查看文件列表。如果工具支持审批模式，应关闭自动接受或自动执行。
问题 2：测试都通过了，为什么上线仍然出错？
通常是测试数据与真实输入不一致，或遗漏编码、时区、并发、权限和依赖版本。应从真实问题中提取脱敏后的最小复现，并增加回归测试，而不是只扩写提示词。
问题 3：应该让 AI 先写代码还是先写测试？
新功能优先先定义接口和验收测试；已有缺陷优先写能稳定复现问题的失败测试；探索性原型可以先生成代码，但进入主分支前仍应补齐测试。
问题 4：AI 给出的实现很复杂，要不要接受？
先问它是否存在更小的标准库方案，并要求说明每个新增抽象解决什么问题。如果删除某层后测试仍能通过，通常应保留更简单的版本。
问题 5：如何判断一次 AI 修改是否适合提交？
至少满足五点：需求有明确边界；差异可以人工读完；测试覆盖新增行为；固定检查链通过；提交中不含密钥、临时日志、缓存文件和无关格式化。
八、总结
AI 编程 IDE 的价值并不只是每分钟生成更多代码，而是缩短“提出假设—实现补丁—获得反馈—验证结果”的周期。高质量工作流的关键是：用接口限制自由度，用测试表达验收条件，用断点获得事实，用 Git 控制变更范围，再用固定命令完成独立验证。
实际使用时，可以牢记一个简单原则：不要要求 AI 一次完成整个工程，而要让它每次交付一个能够被测试、审查和回退的小补丁。这样既能发挥代码补全和跨文件理解的效率优势，也能避免把不可解释、未经验证的生成结果直接带入正式项目。
在 Cursor、VS Code + AI 插件、JetBrains AI Assistant 等编程环境中，生成一个函数、补齐一个类或解释一段代码已经非常方便。但在真实工程里，输入代码只占工作量的一部分，更多时间消耗在理解上下文、确认边界、复现问题、补充测试、调试失败以及审查变更上。
AI 编程最常见的低效模式是：让模型一次性修改大量文件，运行后发现报错，再把报错原样粘回对话框，经过多轮“猜测式修复”后，代码虽然暂时可运行，却引入了依赖膨胀、接口变化或测试覆盖不足等问题。
更稳妥的方法，是把 AI IDE 当作“受约束的结对编程工具”，建立如下闭环：
需求边界 → 提供最小上下文 → 先写验收测试 → 生成小范围补丁 → 本地执行 → 断点调试 → 审查差异 → 独立验证 → 提交。
本文以一个本地 Python 项目为例，演示如何让 AI 帮助实现日志解析功能，并通过测试与调试验证结果。示例只处理本地构造数据，不涉及任何未授权目标。
二、核心原理：AI IDE 真正需要的是约束与反馈
1. 上下文决定生成质量
AI 不会自动理解整个仓库。即使 IDE 支持代码索引，也可能遗漏运行时配置、隐式约定和外部依赖。因此，应主动提供：
- 目标文件及其直接调用者；
- 数据结构或接口定义；
- 现有测试与编码风格；
- 明确禁止修改的目录；
- 可执行的验收命令。
2. 测试比自然语言更适合作为验收标准
“完善日志解析”含义模糊，而“输入包含时间、级别和消息的单行文本，返回固定字段；非法行返回 None；不得抛出异常”是可验证的。把需求转化为测试后，AI 的任务就从开放式创作变成了满足约束。
3. 小补丁比大改造更容易审查
一次只修改一个行为，能快速判断失败来自实现、测试还是环境。建议单轮变更控制在一至三个文件内；如果 AI 建议顺便重构整个模块，应先拆分任务，而不是立即接受。
4. 调试信息应结构化反馈
不要只告诉 AI“还是不行”。更有效的信息包括：失败命令、异常类型、最短堆栈、实际值、期望值、Python 或运行时版本，以及是否能够稳定复现。
三、前置条件
本文示例需要：
- Python 3.10 或更高版本；
- 任意支持 AI 对话或补全的 IDE；
- Git；
- pytest；
- 一个独立的本地实验目录。
初始化项目：
mkdir ai-ide-lab
cd ai-ide-lab
python -m venv .venv
Linux/macOS 激活环境：
source .venv/bin/activate
Windows PowerShell 激活环境：
.venv\Scripts\Activate.ps1
安装测试工具并初始化仓库：
python -m pip install -U pip pytest
git init
mkdir src tests
创建 pyproject.toml：
[project]
name = 'ai-ide-lab'
version = '0.1.0'
requires-python = '>=3.10'
[tool.pytest.ini_options]
pythonpath = ['src']
testpaths = ['tests']
建议在开始使用 AI 修改前执行一次基线提交：
git add .
git commit -m 'chore: initialize local ai ide lab'
如果 Git 尚未配置身份，可以只执行 git diff 观察变化，不必为了实验强行提交。
四、分步骤实践
步骤 1：先定义接口，不让 AI 自由猜测
本例要解析如下格式的本地日志：
2025-03-08T10:20:30Z INFO service started
期望返回：时间戳、日志级别、消息。空行、缺少字段或未知级别返回 None。允许级别仅为 DEBUG、INFO、WARNING、ERROR。
创建 src/log_parser.py：
from dataclasses import dataclass
@dataclass(frozen=True)
class LogEntry:
timestamp: str
level: str
message: str
def parse_log_line(line: str) -> LogEntry | None:
raise NotImplementedError
这里先保留未实现状态。这样 AI 能看到稳定的接口，而不是自行决定函数名称、返回字典还是抛出异常。
步骤 2：要求 AI 先生成测试，而不是直接实现
在 AI IDE 中只选中 src/log_parser.py，并给出类似提示：
“请为 parse_log_line 设计 pytest 测试。约束：有效行返回 LogEntry；允许四种级别；消息可以包含空格；空行、字段不足、未知级别返回 None；当前阶段只新增 tests/test_log_parser.py，不修改生产代码。请覆盖正常、边界和非法输入。”
生成后不要立即接受全部内容，重点检查测试是否真正覆盖了需求。一个可用的测试文件可以是：
from log_parser import LogEntry, parse_log_line
def test_parse_valid_line():
result = parse_log_line('2025-03-08T10:20:30Z INFO service started')
assert result == LogEntry(
timestamp='2025-03-08T10:20:30Z',
level='INFO',
message='service started',
)
def test_message_may_contain_spaces():
result = parse_log_line('2025-03-08T10:20:30Z ERROR file open failed')
assert result is not None
assert result.message == 'file open failed'
def test_empty_line_returns_none():
assert parse_log_line('') is None
def test_missing_message_returns_none():
assert parse_log_line('2025-03-08T10:20:30Z INFO') is None
def test_unknown_level_returns_none():
assert parse_log_line('2025-03-08T10:20:30Z TRACE detail') is None
先运行：
pytest -q
此时测试失败是预期结果，因为实现仍抛出 NotImplementedError。这个“先红后绿”的过程能确认测试确实执行到了目标代码。
步骤 3：让 AI 在明确边界内实现最小补丁
第二轮提示应限制改动范围：
“根据 tests/test_log_parser.py 实现 parse_log_line。只修改 src/log_parser.py，不增加第三方依赖，不改变 LogEntry 定义，不修改测试。优先使用一次字符串切分，并说明对非法输入的处理路径。”
合理实现如下：
from dataclasses import dataclass
_ALLOWED_LEVELS = {'DEBUG', 'INFO', 'WARNING', 'ERROR'}
@dataclass(frozen=True)
class LogEntry:
timestamp: str
level: str
message: str
def parse_log_line(line: str) -> LogEntry | None:
parts = line.strip().split(maxsplit=2)
if len(parts) != 3:
return None
timestamp, level, message = parts
if level not in _ALLOWED_LEVELS or not message:
return None
return LogEntry(timestamp=timestamp, level=level, message=message)
再次运行：
pytest -q
通过后，不要马上结束。继续查看变更：
git diff -- src/log_parser.py tests/test_log_parser.py
审查时关注：AI 是否偷偷修改了测试来迁就实现；是否加入不必要的包；是否改变公开接口；是否用过宽的 except Exception 吞掉真实错误。
步骤 4：主动制造边界失败，验证 AI 没有只迎合样例
当前实现没有验证时间戳格式。如果需求明确要求 UTC ISO 形式，就应先增加失败测试：
def test_invalid_timestamp_returns_none():
assert parse_log_line('not-a-time INFO service started') is None
执行：
pytest -q tests/test_log_parser.py::test_invalid_timestamp_returns_none
确认测试失败后，再让 AI 只补充时间戳验证。提示中应说明是否允许标准库、是否接受带时区偏移的时间，以及是否必须以 Z 结尾。不要简单说“验证时间格式”，否则不同实现会产生不同语义。
例如，若规则是“必须为以 Z 结尾的 UTC 时间”，可使用标准库：
from datetime import datetime
def _is_utc_timestamp(value: str) -> bool:
if not value.endswith('Z'):
return False
try:
datetime.fromisoformat(value[:-1] + '+00:00')
except ValueError:
return False
return True
然后在构造 LogEntry 前调用该函数。此时再次运行全部测试，而不是只运行新用例：
pytest -q
步骤 5：在 IDE 中进行断点调试
当测试输出不足以说明问题时，可在 parse_log_line 第一行设置断点，并以调试方式运行单个测试。建议观察：
- line 的原始值是否含换行符；
- strip 后是否丢失了业务上需要保留的空白；
- split(maxsplit=2) 的结果长度；
- level 的大小写是否符合接口约定；
- 时间解析抛出的具体异常。
对于 VS Code，可创建 .vscode/launch.json：
{
'version': '0.2.0',
'configurations': [
{
'name': 'Debug current pytest file',
'type': 'debugpy',
'request': 'launch',
'module': 'pytest',
'args': ['${file}', '-q', '-s'],
'console': 'integratedTerminal'
}
]
}
注意：标准 JSON 实际要求双引号。如果手工创建 launch.json，应把示例中的单引号替换为双引号。这里使用单引号只是为了避免与文章载体的字符串转义混淆。
断点调试得到证据后，再将结论交给 AI。例如：
“失败输入末尾包含换行，line.strip() 后切分正确；实际问题是时间字符串带毫秒，当前校验误判。请只调整 _is_utc_timestamp，并增加毫秒时间测试，不改级别解析。”
这种反馈比直接粘贴整个终端更有效，也能减少模型修改无关代码。
步骤 6：建立提交前的固定检查链
可以在项目根目录创建简单脚本 scripts/check.sh：
#!/usr/bin/env sh
set -eu
python -m compileall -q src
pytest -q
git diff --check
赋予执行权限并运行：
chmod +x scripts/check.sh
./scripts/check.sh
Windows 用户可以用 PowerShell 编写等价脚本。关键不在脚本语言，而在于把验收流程固定下来。今后每次接受 AI 补丁，都先运行同一条命令，避免“这次忘了跑某项检查”。
步骤 7：用 Git 将 AI 改动限制在可回退范围
建议每个小任务采用独立分支：
git switch -c feature/log-parser
git status --short
git diff --stat
./scripts/check.sh
git add src/log_parser.py tests/test_log_parser.py scripts/check.sh
git diff --cached
git commit -m 'feat: add validated local log parser'
其中 git diff --cached 是非常重要的一步。AI IDE 的界面可能折叠部分修改，而暂存区差异能帮助发现意外文件、调试输出、硬编码路径和配置泄露。
五、提升补全质量的具体技巧
1. 补全前先写函数签名、类型标注和简短文档。相比空白文件，明确接口能显著减少无关生成。
2. 将“大功能”拆为可验证动作。例如不要一次要求“实现日志分析系统”，而应拆为解析单行、读取文件、聚合级别、输出报告四个任务。
3. 提示中加入不变量，例如“不得网络访问”“不得新增依赖”“不得修改测试”“非法输入不抛异常”。
4. 对 AI 给出的命令逐条阅读后再执行。尤其要警惕递归删除、覆盖配置、全局安装、修改权限以及来源不明的下载命令。
5. 对重复代码可使用行内补全，对跨文件设计则使用对话或代理模式。不要为了生成三行条件判断而开放整个仓库的写权限。
6. 每轮对话只解决一个失败。如果同时混入格式化、重构、性能优化和修复测试，出现回归时很难定位责任变更。
六、风险与注意事项
1. 隐私与代码外发
使用云端 AI 服务前，应确认项目授权、组织政策和插件的数据处理方式。密钥、客户数据、私有样本、崩溃转储和内部日志不应直接放入提示。可以先构造最小复现，用虚拟值替换敏感字段。
2. 提示注入与仓库内不可信文本
当 AI IDE自动读取 README、Issue、代码注释或外部依赖文档时，其中的文本可能包含误导性指令。仓库内容应被视为数据，而不是高优先级命令。不要允许代理在无人审查的情况下执行终端命令、上传文件或改写大量配置。
3. 生成代码的正确性与许可证
能运行不等于满足业务语义。必须由开发者审查算法、异常路径、兼容性和依赖来源。对来源不明确的大段生成代码，还应遵循所在组织的许可证审查流程。
4. 测试被“修绿”
当 AI 同时拥有生产代码和测试写权限时，它可能通过降低断言强度、删除边界用例或增加无条件跳过来让测试通过。因此，修复实现阶段应明确禁止修改测试，并通过 git diff 复核。
5. 调试数据泄露
堆栈、环境变量、请求头和内存内容可能包含令牌。复制到 AI 对话前要脱敏。安全分析或恶意样本研究应限定在本地隔离环境、授权靶场和防御用途，不要让 IDE 代理直接访问真实目标或生产凭据。
七、常见问题
问题 1：AI 总是修改无关文件怎么办？
先缩小上下文，只选中目标文件；在提示中列出允许修改的路径；应用补丁前查看文件列表。如果工具支持审批模式，应关闭自动接受或自动执行。
问题 2：测试都通过了，为什么上线仍然出错？
通常是测试数据与真实输入不一致，或遗漏编码、时区、并发、权限和依赖版本。应从真实问题中提取脱敏后的最小复现，并增加回归测试，而不是只扩写提示词。
问题 3：应该让 AI 先写代码还是先写测试？
新功能优先先定义接口和验收测试；已有缺陷优先写能稳定复现问题的失败测试；探索性原型可以先生成代码，但进入主分支前仍应补齐测试。
问题 4：AI 给出的实现很复杂，要不要接受？
先问它是否存在更小的标准库方案，并要求说明每个新增抽象解决什么问题。如果删除某层后测试仍能通过，通常应保留更简单的版本。
问题 5：如何判断一次 AI 修改是否适合提交？
至少满足五点：需求有明确边界；差异可以人工读完；测试覆盖新增行为；固定检查链通过；提交中不含密钥、临时日志、缓存文件和无关格式化。
八、总结
AI 编程 IDE 的价值并不只是每分钟生成更多代码，而是缩短“提出假设—实现补丁—获得反馈—验证结果”的周期。高质量工作流的关键是：用接口限制自由度，用测试表达验收条件，用断点获得事实，用 Git 控制变更范围，再用固定命令完成独立验证。
实际使用时，可以牢记一个简单原则：不要要求 AI 一次完成整个工程，而要让它每次交付一个能够被测试、审查和回退的小补丁。这样既能发挥代码补全和跨文件理解的效率优势，也能避免把不可解释、未经验证的生成结果直接带入正式项目。
