学习如何用 AI 编程，最稳妥的方式是给它一个有边界的任务、足以理解该任务的上下文，以及一个你能自己检查的验证目标。把模型当作一位能快速检查、解释并提出修改的结对编程伙伴，而不是有权决定代码何时正确的权威。

如果你刚开始接触结构化的 AI 工作，先阅读更宽泛的AI 实用入门工作流。本文把这个模式收窄到代码修改上：在这里，一个吸引人的答案远不如一个小的 diff、可重复的测试和清晰的停止点重要。

关键要点

从一个有可见输入、预期输出和明确排除项的任务开始。

只分享最小可用的上下文包，并在它离开你的电脑之前删除密钥。

在要求修改之前，先要求给出计划和文件清单。

运行任何东西之前，先审查 diff、依赖、权限和外部影响。

用你已经信任的工具验证正常、边界和失败情况下的行为。

如何用 AI 编程而不失去控制？

使用一个包含五道关卡的循环：界定、检查、提议、审查和验证。AI 可以在每道关卡内提供帮助，但由你决定工作何时推进。GitHub 的负责任使用指引指出，生成的代码可能不准确或不安全，审查和测试仍是用户的责任。［1］

这个流程适合小的缺陷修复、有针对性的测试、本地脚本或范围受控的重构。它不适合范围不明的重写、紧急的生产环境变更，或会暴露凭据和客户数据的请求。如果任务无法用一份简短的验收清单说清楚，就先缩小范围，再请求写代码。

先选择能“明显失败”的任务

一个好的首个任务应有可观察的约定。“让 parse_duration 拒绝负值，同时保留有效的秒和分钟”比“整理一下解析器”更好。前者说明了行为和兼容性边界；后者则会引来没有边界的重新设计。

写下四项内容：

**当前行为：**现在会发生什么，包括能演示它的命令或测试。
**预期行为：**修改之后应该发生什么。
**范围之外：**不得改变的文件、公共接口、依赖或格式。
**证明：**决定任务是否完成的测试或人工观察。

把这份清单保存在对话之外，作为你的依据。如果模型之后提出更大范围的改动，就拿它与清单比较，而不是凭记忆讨价还价。

步骤一：准备小而安全的上下文

默认情况下，不要粘贴整个代码库。从失败的测试、相关函数、它的调用方、必须保留的公共类型或模式，以及约束这次修改的仓库说明开始。只有当你能说明现有证据为何不够时，才添加另一个文件。

删除或替换：

API 密钥、密码、cookie、私钥和环境变量文件；
客户姓名、电子邮件地址、客服对话记录和生产环境数据；
内部主机名、命令输出中的令牌，以及带签名的下载链接；
所在组织尚未批准用于所选工具的专有代码。

如果真正的问题是访问和连接，请使用单独的 AI 编程工具访问检查清单。不要把账户或网络排障混进代码生成任务，因为这会让上下文更难审查，还可能诱使人分享不必要的凭据。

用合成 fixture 代替生产数据

用合成输入复现行为。一个六行的 CSV、一个临时的 SQLite 数据库或一棵很小的目录树，比生产环境导出的数据更容易检查。让 fixture 保持确定性，这样另一位开发者运行同一条命令就能看到同样的结果。

对于第一个编程任务，把允许使用的最小示例复制到一个隔离的分支、工作树、容器或一次性项目中。隔离并不能证明生成的代码是安全的，但在你还在了解工具可能做什么时，它能限制意外的写入。

步骤二：先让 AI 只读检查并给出计划

从只读请求开始。让模型找出相关文件、解释当前的控制流程、列出不确定之处，并提出最小的修改。告诉它暂时不要编辑文件或运行命令。

一条实用的提示词如下：

检查解析器及其测试。解释为什么负数时长会被接受。提出能拒绝负值、同时不改变公共返回类型也不增加依赖的最小修改。列出你会编辑的文件、会添加的测试，以及任何你无法核实的假设。暂时不要修改文件或运行命令。

回答应当是可以证伪的。文件清单可以与仓库对照；关于控制流程的说法可以通过追踪调用方来检查；不确定之处可以在第一次编辑之前解决。一段关于“改进校验”的泛泛之谈，则没有任何可以审核的内容。

关于某个厂商的终端智能体的操作演示，请参阅新手 Claude Code 指南。本文的流程与工具无关：重要的边界是所请求的动作，而不是界面的名称。

步骤三：只请求最小补丁

当计划与验收清单一致后，只授权相关的编辑。在请求中重申排除项：不升级依赖、不改变公共接口、不格式化未改动的行、不做无关的清理。要求模型在发现某项约束无法满足时停下来。

优先选择容易撤销的补丁。一处行为修改加一个回归测试，比一个“为将来的灵活性”引入的多文件抽象更容易推理。如果模型为了一个只需改一行的缺陷，想要重命名文件、重组模块并更新配置，就回到计划，问清楚哪项修改是严格必需的。

这是受控的本地示例，使用合成的解析器 fixture，不包含生产代码库、账户、客户数据或密钥，也不表示生成的补丁已经通过审查。

把命令与解释分开审查

不要让一段有用的解释掩盖一条有风险的命令。把每条建议的命令复制到审查清单中，并在执行前分类：

类别	示例	默认处理
只读	搜索文件、打印测试、查看 diff	在获批的工作区内通常是安全的
本地构建	编译、运行定向测试、创建缓存	先检查资源和脚本的副作用
修改状态	安装依赖、重写快照、执行迁移	需要明确理由并经过审查
外部动作	调用 API、上传代码、推送、部署、发送消息	在授权和目标明确之前停止
破坏性动作	删除数据、重置状态、覆盖发布版本	不作为探索性步骤运行

OpenAI 把沙箱和审批策略描述为互补的控制：沙箱设定技术边界，而审批决定某个动作何时可以越过它。［2］在提示词中要求模型“小心一点”，不能替代对文件系统、网络、身份和命令的限制。

步骤四：运行前审查完整 diff

按照计算机执行时经历的顺序阅读补丁。从配置和依赖开始，然后是公共接口、数据转换、外部影响和测试。当修改涉及身份验证、存储、子进程、网络调用或迁移时，使用详细的运行前 AI 代码审查清单。

问以下问题：

每个被修改的文件都属于已批准的任务吗？
补丁是否改动了锁文件、依赖来源、构建钩子或生成的产物？
不可信的输入能否到达 shell、查询、模板、路径、URL 或反序列化器？
权限、默认值、错误处理或重试行为是否发生了变化？
新测试证明的是需求，还是只是重复了实现？
当输入为空、格式错误、过大、重复或被中断时，会发生什么？

阅读最终的代码，而不只是模型的总结。总结可能漏掉某个被改动的默认值或额外的文件。如果你不理解某一行，就要求解释，并在执行前对照语言或框架文档核实。

步骤五：验证正常、边界和失败路径

运行能证明所改行为的最小可信命令。先运行新的回归测试，再运行最近的现有测试组。只有在定向测试给出有用的信号之后，才运行更大范围的 lint、类型检查、构建和集成关卡。

使用三类证据：

路径	时长解析器示例	能证明什么
正常	`15s` 和 `2m` 仍能解析	兼容的有效行为得以保留
边界	`0s`、可接受的最大值、空白字符	边界情况符合文档约定
失败	`-1s`、空输入、不支持的单位	无效输入按预期方式失败

不要让同一个模型宣布它自己的补丁正确。可以让它建议遗漏的情况，但要把仓库测试、编译器、lint 工具、静态分析和人工审查作为独立的证据。NIST 的安全软件开发框架把代码审查和分析放在更广泛的安全开发实践之中，而不是把某一个工具的结果当作发布的证明。［3］

如果测试失败，保留失败输出，转入以证据为基础的 AI 调试流程。不要立即授权另一次大范围的重写。

记录尚未验证的部分

本地测试通过，并不能证明生产环境配置、操作系统行为、外部服务状态或部署会成功。写一份简短的交接说明，包括：

修改的文件和预期的行为；
运行过的命令及其确切范围；
没有运行的测试及原因；
仍然依赖另一个环境的假设；
回滚或撤销的方法；
需要进行安全、数据或架构决策的审核人。

这份交接说明是结果的一部分。它能防止“AI 说它能用”成为这次工作唯一的记录。

什么时候应该停止 AI 编程流程？

当任务越过你未授权的边界、模型需要敏感数据、补丁无法保持小范围，或预期行为存在争议时，就停下来。当同一个失败在没有新证据的情况下反复出现时，也应停止。如果验收标准不清楚，更多的迭代也无济于事。

当任务涉及生产环境凭据、破坏性迁移、法律或许可证解读、高影响的授权、事件响应，或一个你无法安全测试的系统时，把任务交给人工负责人。更有成效的选择往往是交回一份聚焦的调查结果，而不是硬塞一个补丁。

如果必须与外部服务分享日志或代码，先应用 AI 隐私风险指南中的数据最小化做法。脱敏和最小权限应在上传之前落实，而不是在出现意外输出之后。

总结

界定一项可观察的行为和明确的排除项。
尽可能基于合成 fixture，只分享最小、已脱敏的上下文包。
在编辑之前，先要求检查和计划。
执行之前，审查完整的 diff 和每一条建议的命令。
用可信的仓库工具验证正常、边界和失败路径。
记录未经验证的环境；当风险或不确定性超出你的权限时，把任务交回。

常见问题

新手可以用 AI 写代码吗？

可以，前提是任务小到可以检查，且新手能够运行独立的检查。先从解释、测试和范围受控的修改开始，而不是整个应用程序。

应该把整个仓库粘贴给 AI 吗？

不应该。只分享能说明任务的最小获批文件集合，并删除密钥和个人数据。在使用外部服务之前，遵守所在组织的代码处理政策。

AI 生成的代码可以直接运行吗？

默认不可以。审查 diff、依赖、权限、外部影响和命令，然后在适当受限的环境中结合相关测试运行。

可以让 AI 自动安装依赖吗？

只有在你核实了为什么需要这个依赖、它来自哪里、锁文件会有什么变化，以及现有依赖能否解决问题之后才可以。安装依赖是一项会改变供应链的操作，而不是无害的解释步骤。

看不懂生成代码怎么办？

不要运行或合并它。要求逐行解释，把行为与官方文档对照，并请一位了解该语言和受影响系统的审核者参与。

第一个 AI 编程任务应该多大？

选择一项行为、代码库中的一个小区域和一项明确的证明。如果所需的修改需要新的架构、多次迁移或不明确的生产环境访问，就在使用 AI 之前先拆分它。

测试通过能证明补丁正确吗？

不能。测试只能证明它在该环境中所覆盖的场景。把测试与 diff 审查、静态检查、相关的集成证据，以及关于哪些内容尚未验证的明确说明结合起来。

免责声明：本文仅提供一般技术信息。分享代码或运行生成改动前，请遵守组织的安全、隐私、许可证与变更控制要求。

来源:

GitHub Docs — Responsible use of GitHub Copilot Chat in GitHub — https://docs.github.com/copilot/responsible-use/chat-in-github
OpenAI — Running Codex safely at OpenAI — https://openai.com/index/running-codex-safely/
NIST — Secure Software Development Framework — https://csrc.nist.gov/projects/ssdf

Sources checked 2026 年 8 月 24 日。

延伸阅读：

如何用 AI 编程：新手从限定任务到测试验证的安全工作流