AI Agent

用 AI Coding 写好 Python

一套契约优先的工作方法,用 coding agent 完成小而可测、能够安全交付的 Python 修改:任务契约、仓库检查、可复现环境与基于证据的交付。

学习结果

把 AI Coding 变成可以信任的开发方式:每次修改都有任务契约、可复现环境、聚焦测试、真实入口验证和基于证据的交付。

前置条件
  • 一个 coding agent,例如 Claude Code、Cursor 或 Copilot
  • 一个至少能运行一条测试的 Python 项目
  • 基本的 Git 使用经验

AI coding agent 可以快速生成语法和样板代码,但它不会自动理解项目边界、真实运行环境、用户风险或完成标准。高质量 AI Coding 的核心不是写出更多代码,而是把工作拆成可理解、可验证、可回退的小改动。

“使用 AI Coding”与”开发 AI Agent”是两件事:前者是开发方式,后者只是可能构建的一类产品。无论最终开发 API、自动化脚本、数据工具还是 Agent,都应使用同一套可靠工作循环。

先给任务建立契约

在让 coding agent 修改代码前,至少写清:

  • 目标:用户或系统最终能完成什么;
  • 当前行为:现在具体发生了什么;
  • 输入与输出:数据格式、边界和错误形式;
  • 约束:允许修改什么,明确不修改什么;
  • 验收:要运行哪些测试、命令或真实操作;
  • 权限:是否允许联网、安装依赖、提交、推送或部署。

可直接复用下面的任务模板:

目标:
当前行为:
期望行为:
允许修改:
禁止修改:
验收方式:
提交/推送/部署权限:

模糊的”优化一下”通常会得到范围过大的修改;明确契约才能让 AI 承担执行,而不是替你猜测产品决定。

要求 AI 先读取仓库

一个可靠的 Python 修改应先检查:

  1. AGENTS.mdREADME.md 和贡献规则;
  2. 当前 Git 分支、工作树和远程状态;
  3. pyproject.toml、Python 版本和依赖锁文件;
  4. 与目标最接近的实现和测试;
  5. 真实入口,例如 CLI、API route、任务脚本或浏览器流程。

不要让 AI 仅凭 README、TODO 或文件名推断实现已经存在。文档、代码、测试和真实运行结果需要相互印证。

固定 Python 环境

AI 生成的代码只有在可复现环境中才有意义:

  • 固定 Python 版本;
  • 使用隔离虚拟环境;
  • 声明直接依赖并锁定完整依赖树;
  • 不把本机全局包当成项目依赖;
  • 在干净环境中至少完成一次安装和测试。

现代项目可以参考 uv 官方文档;虚拟环境的底层行为见 Python venv 文档

每次只实现最小可验证改动

让 coding agent 遵循下面的粒度:

  1. 找到一个明确失败或缺失行为;
  2. 先确定测试或验收观察点;
  3. 修改最少的相关文件;
  4. 运行局部测试;
  5. 再运行受影响范围的完整测试;
  6. 检查 diff 中是否混入无关修改。

一个改动如果无法用一句话说明,通常还可以继续拆小。避免让 AI 同时重构架构、升级依赖、修改文案并发布生产环境。

用类型、验证和测试约束生成结果

Python 的动态特性适合快速开发,也容易让 AI 生成”看起来合理但边界不清”的代码。优先使用:

测试至少覆盖正常输入、空值与错误类型、超时与外部失败、权限不足,以及不应发生的文件、网络或数据库副作用。绿色测试只能证明被检查的行为通过,不能证明需求正确,也不能代替真实运行验收。

验证真实入口

完成代码后,运行用户真正会使用的入口:

  • CLI:执行真实命令并检查退出码、标准输出和错误输出;
  • API:检查请求、响应、状态码、超时和验证错误;
  • Web:使用真实浏览器检查 DOM、交互、网络请求和控制台;
  • 自动化:使用无害输入检查重复运行、失败恢复和幂等性;
  • Agent:检查工具参数、结构化输出、权限、轨迹和失败边界。

HTTP 客户端可参考 HTTPX,API 边界可参考 FastAPI,浏览器流程可参考 Playwright for Python

单独检查副作用和权限

AI 生成的 Python 经常会操作文件、Shell、浏览器、网络、数据库或模型工具。接受修改前逐项确认:

  • 文件目标是否精确,是否可能覆盖用户数据;
  • subprocess 是否避免不必要的 shell=True
  • 网络请求是否有超时、重试上限和目标限制;
  • 日志和错误信息是否暴露凭据或私人数据;
  • 数据库修改是否可审计、可回滚;
  • Agent 工具是否使用最小权限并要求必要确认。

相关标准库行为见 subprocess 文档pathlib 文档

交付时报告证据,而不是只说”完成”

一次完整交付至少说明:修改了什么、没有修改什么、实际运行了哪些测试和验收、哪些结果已验证、哪些仍未知,以及是否已提交、推送或部署及对应版本。

推荐完成标准:

[ ] 工作树只包含本次范围内的修改
[ ] 类型、格式和单元测试通过
[ ] 失败路径和边界输入已检查
[ ] 真实 CLI/API/浏览器入口已验证
[ ] 文件、网络、凭据和数据库副作用已检查
[ ] 文档与当前实现一致
[ ] 提交、远程和部署版本可以精确核对

下一步

在一个可运行示例上练习这个循环:复现失败的 starter,把任务契约交给 agent,再本地验证结果。

来源

本工作流引用的全部一手资料在正文中按使用位置链接:uv 与 venv 文档对应可复现环境;typing、Pydantic 与 pytest 文档对应生成代码约束;HTTPX、FastAPI 与 Playwright 对应入口验证;subprocess 与 pathlib 文档对应副作用审查。

验证记录

文档审校

依据 uv、pytest、typing、Pydantic、HTTPX、FastAPI、Playwright 与标准库文档对本工作流进行编辑审校。验证日期 2026-09-02。

关于作者

Organizational byline for FlyPython guides, verification records, and corrections. 编辑标准与联系方式 →