AI 工作流

AI 辅助开发

Q: AI 辅助开发可以不跑测试吗？

不建议。至少应运行构建、lint、单元测试或人工验收中的一种。没有验证的代码 只能说明“看起来合理”，不能说明已经完成。

Q: 需求还不清楚时能直接让 AI 写吗？

可以先让 AI 帮你拆问题、列假设和生成任务单，但不要让它直接改生产代码。需 求不清楚时，先产出方案和问题清单，再进入实现。

Q: AI 写的代码可以直接合并吗？

不建议。即使验证命令通过，也要看 diff、检查边界条件、确认没有密钥或隐私 泄露，并由熟悉业务的人做最终判断。

Q: 怎么减少 AI 改到无关文件？

在 Goal 里写明允许修改的目录、禁止修改的文件和验证命令。结束后用 git diff 审查，发现无关改动就要求回到最小范围。

从需求拆解、代码生成、Bug 修复、测试验证到 Git 交付，说明如何把 AI 辅助开发变成可复核的工程工作流。

预计阅读: 6 分钟
最近更新: 2026/07/03
维护方式: 人工编辑

AI 辅助开发不是让模型替你“猜代码”，而是把一个工程任务拆成可理解、可修改、可验证的步骤。它适合写小功能、修 Bug、补测试、读代码、生成文档、排查构建错误和整理技术方案。

可靠的做法是：把目标写清楚，让 Codex 或其他代码代理先读项目结构，再限定修改范围，完成后运行测试、构建或人工验收。AI 可以加速实现，但需求判断、安全边界和最终合并仍要由人负责。

页面摘要

项目	说明
阅读时间	约 7 分钟
更新时间	2026-07-03
适合人群	开发者、技术负责人、产品经理、创业团队、正在学习编程或维护网站的人
核心收益	把“让 AI 写代码”变成目标清楚、范围可控、验证可运行、diff 可审查的工程流程
你会得到	适用场景、工作流程图、输入准备表、任务风险分级、可复制 Goal、常见案例、质量门禁和复核清单
不适合做什么	不适合让 AI 直接处理生产密钥、支付权限、数据迁移、核心架构重写或没有验收标准的大改动

适用场景

场景	AI 适合做什么	人需要把关什么
新增小功能	读现有组件、补交互、写最小实现	需求优先级、产品边界、用户体验
修 Bug	复现、定位、最小修复、补回归测试	生产影响、根因判断、回归范围
写测试	列用例、补单测、整理边界条件	测试是否覆盖关键业务路径
读代码	解释模块、画调用关系、找风险点	代码是否与真实业务一致
重构小模块	减少重复、拆函数、补类型	是否改变行为、是否值得改
生成文档	写 README、接口说明、变更摘要	文档是否准确、是否泄露内部信息
配环境	解释报错、补安装步骤、整理命令	命令安全、系统差异、权限控制

不适合直接交给 AI 的任务包括：未澄清的核心架构重写、生产数据迁移、支付权限改造、密钥处理、合规审计，以及没有验收标准的大范围改动。

工作流程

开始前准备

让 AI 写代码前，不一定要写长文档，但要给足会影响判断的信息。缺少这些信息，模型很容易把“能跑的示例”写成“不适合当前项目的代码”。

输入	示例	用途
目标	新增一个导出按钮，点击后下载当前筛选结果	让输出围绕具体行为
项目背景	Astro + MDX 文档站，使用 `npm run build` 验收	避免猜错框架和脚本
相关路径	`src/components/ExportButton.tsx`、`src/pages/report.astro`	缩小搜索范围
不应修改	不改数据库 schema，不动支付逻辑	控制风险和 diff 大小
验收命令	`npm run test`、`npm run build`、浏览器截图	证明改动可用
交付要求	汇报改动文件、验证结果、剩余风险	方便人工复核

如果你使用 Codex，最好让它先读取 package.json、项目目录和相关源码，再决定实现方式。不要只发一句“帮我做一个功能”。

任务风险怎么分级

不同编程任务适合交给 AI 的程度不一样。先给任务分级，可以决定要不要让 AI 直接改代码、要跑哪些验证、是否需要人工二次审查。

风险级别	适合交给 AI 的方式	示例任务	验收要求
低风险	可让 AI 直接修改，完成后人工看 diff	README、注释、文案、样式小修、示例代码	构建或预览通过，确认没有误删内容
中风险	让 AI 先给计划，再分步修改	新增组件、补测试、修普通 Bug、整理脚本	测试、lint、构建或浏览器验收至少覆盖关键路径
高风险	AI 只能辅助分析和起草方案	登录鉴权、支付、权限、数据库 schema、数据迁移	需要负责人审查、备份、回滚方案和真实环境演练
不建议直接交给 AI	只让 AI 生成问题清单和风险清单	生产密钥处理、合规审计、未脱敏客户数据、核心架构替换	先走人工评审和组织批准流程

高风险任务不是不能使用 AI，而是不能把 AI 输出当作可直接合并的结果。更稳的做法是让 AI 帮你读代码、列方案、找风险、写测试建议，再由熟悉系统的人决定是否进入实现。

可复制 Goal

Goal: 在当前项目中完成 [任务名称]，保持现有架构和代码风格。

背景：
- 项目类型：[例如 Astro 文档站 / Next.js 后台 / Python CLI]
- 相关路径：[填写文件、目录或让 Codex 自行查找]
- 用户目标：[用户完成什么动作，看到什么结果]

要求：
- 请先读取项目结构、package.json、相关源码和已有测试。
- 修改前给出简短计划，说明准备改哪些文件。
- 只做完成目标所需的最小改动，不做无关重构。
- 不要读取、打印、提交真实 API Key、Cookie 或用户隐私数据。
- 验证命令：[npm run build / npm test / pytest / 其他]

完成后请汇报：
1. 改动了哪些文件
2. 关键实现思路
3. 运行了哪些验证命令，结果如何
4. 仍需人工确认的风险

三个常见案例

案例	适合怎么交给 AI	验收方式
给网站增加专题页	提供目标关键词、站内风格、必须内链和构建命令	本地预览、移动端截图、`npm run build`
修复登录报错	提供复现步骤、脱敏日志、预期行为和失败命令	复现命令消失、补回归测试
给 API 调用补重试	提供当前请求代码、错误码、重试边界和超时要求	单元测试、模拟 429/500、检查日志不含密钥

示例：让 Codex 修复构建错误

Goal: 修复当前项目 `npm run build` 失败的问题。

要求：
- 先运行或读取失败日志，定位具体文件。
- 不要删除页面内容来绕过错误。
- 若是断链，优先改成正确链接或补缺失页面。
- 修复后运行 `npm run check:links` 和 `npm run build`。
- 完成后说明根因、改动文件和验证结果。

示例：让 AI 生成测试

请阅读当前函数和已有测试风格，为 [函数名] 补充边界测试。

重点覆盖：
- 正常输入
- 空值或缺失字段
- 权限不足
- 外部 API 超时
- 错误信息是否可读

不要改业务实现，除非测试暴露出明确 Bug。若需要改实现，请先说明原因。

工程质量门禁

OpenAI Codex 文档把 Codex 定位为可帮助写代码、理解代码、审查代码和调试的编码代理；官方 GitHub 集成也把代码审查、提示文件和 PR 反馈放在工作流里。放到真实项目中，AI 辅助开发至少要过下面这些门禁。

门禁	合格表现	常见失败信号
需求门禁	目标、输入、输出、验收命令写清楚	AI 做了“看起来相关”的功能，但不是用户要的结果
上下文门禁	读取项目结构、脚本、相关源码和已有测试	按通用框架模板写代码，和项目风格不一致
范围门禁	只改完成目标需要的文件	无关格式化、顺手重构、大面积移动文件
验证门禁	至少运行测试、lint、构建或浏览器验收之一	只描述“应该可以”，没有命令或截图证据
安全门禁	不读取、不打印、不提交真实密钥和隐私数据	日志、截图、示例代码里出现真实 Token 或 Cookie
交付门禁	汇报改动文件、验证结果和剩余风险	只说“已完成”，没有 diff 和风险说明

如果团队要把 Codex 放进 PR 审查、CI 或多人协作流程，建议把提示词、允许范围、验证命令和输出格式写成仓库内可版本化的文件。每次调整提示词后，用同一组 PR 或任务样例检查输出是否仍然能抓住安全、Bug、测试和维护性问题。

API 项目配置

当项目需要调用 OpenAI SDK、Codex CLI、GPT Image API 或 Claude 兼容接口时，可以把 OfApp.cn 作为统一入口。这样脚本、代理工具和内部系统可以共用一组环境变量，减少多处配置不一致的问题。

export OPENAI_BASE_URL="https://api.ofapp.cn/v1"
export OPENAI_API_KEY="sk-xxxx"
export OPENAI_MODEL="以控制台可用模型为准"

如果工具会自动拼接 /v1，则按照工具说明决定 Base URL 填 https://api.ofapp.cn 还是 https://api.ofapp.cn/v1。具体可用模型、能力、套餐和价格以 OfApp.cn 控制台或官方文档为准。

复核清单

检查项	复核问题
目标	改动是否真正解决了用户目标？
范围	是否出现无关文件、无关格式化或大规模重构？
验证	是否运行了测试、构建、lint 或手动验收？
错误状态	loading、empty、error、permission 等状态是否考虑？
安全	是否泄露 API Key、Cookie、用户数据或内部地址？
兼容	是否破坏旧入口、旧参数或旧数据？
依赖	是否新增了没有必要的依赖或版本风险？
文档	是否需要更新 README、示例、注释或变更说明？

资料来源

OfApp.cn 官网：网页入口、Codex 工作流、AI 写作、读文件、图片生成和统一入口说明。
OfApp.cn API 文档：Key、Base URL、Responses、Chat Completions、Images 和 Messages 兼容入口示例。
OfApp.cn 天才游乐场：网页体验入口、聊天参数、图片参数和本地 Key 使用方式。
OpenAI Codex Documentation：Codex 写代码、理解代码、审查代码、调试和 GitHub 工作流相关说明。

常见问题

AI 辅助开发可以不跑测试吗？

不建议。至少应运行构建、lint、单元测试或人工验收中的一种。没有验证的代码只能说明“看起来合理”，不能说明已经完成。

需求还不清楚时能直接让 AI 写吗？

可以先让 AI 帮你拆问题、列假设和生成任务单，但不要让它直接改生产代码。需求不清楚时，先产出方案和问题清单，再进入实现。

AI 写的代码可以直接合并吗？

不建议。即使验证命令通过，也要看 diff、检查边界条件、确认没有密钥或隐私泄露，并由熟悉业务的人做最终判断。

怎么减少 AI 改到无关文件？

在 Goal 里写明允许修改的目录、禁止修改的文件和验证命令。结束后用 git diff 审查，发现无关改动就要求回到最小范围。

什么时候需要 OfApp.cn？

当项目、脚本、Codex CLI、客户端或内部工具需要统一 AI API 入口时，可以把 Base URL 指向 OfApp.cn。具体模型、能力和价格请以 OfApp.cn 控制台或官方文档为准。

带走什么

AI 辅助开发的核心不是“让模型多写代码”，而是把需求变成可验证任务：目标清楚、上下文完整、范围可控、验证可运行、diff 可审查。OfApp.cn 可以作为统一 API 入口，帮助你把 AI 能力接进 Codex、脚本和项目；代码质量、测试、安全和最终交付仍要由人把关。