AI 辅助研发：把 Codex 接入真实工程流程

我在上海锋趣的项目中持续使用 Codex 约 1 年，覆盖客户端嵌入页、官方管理后台和作者后台。我的定位不是“让 AI 替我写代码”，而是把它放进一个可检查、可验证、可回退的研发闭环，加速信息检索和机械工作，把时间留给业务判断、架构边界和风险控制。

在锋趣项目中的实践

我把 AI 定位为工程加速器，而不是替代开发判断的“自动写代码工具”。在锋趣的客户端嵌入页和多个管理后台中，我逐步形成了可重复的协作流程：先让 Codex 基于真实代码定位入口、依赖与影响面，再由我确认约束和方案；实现后检查 diff、边界与异常路径，并通过项目构建和针对性回归确认结果。

这套实践提高了我处理陌生模块、跨文件改动、重复样板、重构排障和技术文档的效率，也让我更重视上下文质量、任务拆分、验收标准与安全边界。我不会向模型提供账号、密钥或用户数据，也不会未经人工 Review 直接合并或发布生成代码。

AI 能力不等于提示词技巧

真正影响结果的通常不是一句“高级 Prompt”，而是四件事：上下文是否准确、任务边界是否清楚、验收标准是否可执行、生成结果是否经过验证。我的职责始终包括：

• 判断需求是否合理，并把业务规则翻译成技术约束。
• 决定组件、Store、Router、服务层和配置层的职责边界。
• 审查 AI 生成的 diff，处理兼容性、异常路径和项目约定。
• 运行构建和针对性回归，对最终代码和上线结果负责。

我在项目中的使用场景

1. 理解存量代码

面对一个不熟悉的功能，我会先让 Codex 沿着“页面入口 → 路由 → Store → API → 公共组件”梳理调用链，再通过代码检索逐项核对。它适合快速建立地图，但模块职责、真实数据含义和历史兼容逻辑仍需要我结合业务确认。

2. 分析改动影响

在跨文件需求中，我会先明确期望行为、不应改变的行为和验收条件，再让 Codex 找出调用方、共享状态、接口依赖和可能受影响的构建配置。这样能更早发现“只改当前页面却破坏其他专区”的风险。

3. 加速实现与重构

对于结构明确、重复度高的表单、接口适配、数据转换和类型补充，可以让 Codex生成初版；对于状态归属、权限边界、缓存一致性等设计问题，我先给出约束和候选方案，再让它协助实现。代码进入项目之前必须符合现有风格，而不是为了使用新写法制造额外迁移成本。

4. 排障与验证

我会提供错误现象、复现路径、关键日志和相关代码，让 Codex提出待验证假设，然后按成本从低到高逐个排除。修复后检查 diff，并至少完成语法/类型检查、生产构建和受影响路径回归；高风险改动还要覆盖权限切换、空数据、接口失败和重复操作。

5. 沉淀文档

对于动态菜单、配置化活动、SVGA 资源加载等跨模块逻辑，AI 可以帮助把实现整理成流程、边界和排查清单。我会删除未经证实的推断，补充真实约束，让文档既能帮助维护，也能支撑交接和复盘。

一套可重复的协作闭环

明确问题与验收标准
  → 提供最小且相关的代码上下文
  → 让 Codex 探索调用链与影响面
  → 我确认方案、边界和风险
  → 小步实现并审查 diff
  → 构建、测试与针对性回归
  → 记录结论，必要时回退

我倾向把大任务拆成可独立验证的小步。例如先完成数据模型和纯函数，再接入 Store，最后修改页面；每一步都能单独检查，出现问题时也更容易定位，而不是一次生成大量文件后再整体猜错在哪里。

用 AI 搭建前端项目框架

我不会用一句“帮我搭一个 Vue 项目”让 AI 一次生成完整工程。框架决定了后续所有人的开发边界，应该按从约束到验证的顺序落地：

1. 先定义约束：运行环境、Vue 版本、浏览器范围、部署路径、包管理器、是否需要 SSR、权限和多环境要求。
2. 设计目录与依赖方向：页面可以依赖业务模块，业务模块可以依赖基础设施，反向依赖需要被禁止；公共层不因“以后可能复用”而提前膨胀。
3. 先做最小骨架：只建立入口、Router、状态层、请求层、环境配置、错误边界和基础样式，不先生成大量业务页面。
4. 打通一条纵向链路：用一个真实页面验证路由、接口、状态、异常处理、权限、测试和构建，确认约定可行后再扩展。

AI 可以生成候选目录、配置和样板，我负责解释每一个依赖为什么存在、替换或删除不合适的抽象，并确保空项目能够构建、真实链路能够运行。面试中如果说“项目是我搭的”，就必须能说明入口、依赖方向、环境配置、路由状态、错误处理和发布链路。

“训练 AI”在工程里具体指什么

日常研发中所谓“越用越懂项目”，主要来自三个层次：

• 任务上下文：为当前问题提供目标、相关文件、已有行为、限制条件和验收标准。
• 项目级规则：把目录约定、命名方式、禁用做法、测试命令和交付检查写进仓库规则或开发文档，让不同任务复用同一套约束。
• 反馈校准：把 Review 中反复出现的问题整理成反例、提示模板和检查清单；下一次先提供这些约束，再观察错误是否减少。

这属于上下文工程和工作流校准，不是对基础模型做参数训练。如果未来使用知识库、检索增强、微调或评测集，我会分别说明数据来源、更新机制和评估方式，不混用概念。

如何写出更精准的任务说明

我常用的任务结构不是堆角色设定，而是提供可执行信息：

目标：要改变哪一种用户行为
现状：入口、调用链和当前问题
范围：允许修改与禁止修改的文件/模块
约束：版本、兼容性、接口、代码风格与安全要求
验收：正常、异常、权限、空数据和构建检查
输出：先分析方案，确认后小步修改，并说明风险与验证结果

例如，不说“优化首页”，而是说明首屏指标、现有资源、不可改变的交互、目标设备、需要保留的埋点以及验证方法。提示越接近一份可执行的工程任务，AI 越不容易用看似合理但不适配项目的通用答案填空。

如何减少 AI 出错

• 要求先引用真实文件和调用关系，再提出修改方案；找不到证据时明确说不知道。
• 一次只处理一个可验证目标，控制改动文件数和 diff 规模。
• 提供版本信息和现有项目命令，避免生成其他版本的 API 或配置。
• 对接口字段、权限码和业务规则以源码/接口文档为准，不让 AI 猜测。
• 让 AI 同时列出风险、反例和未验证假设，而不只给成功路径。
• 通过编译器、类型系统、lint、测试和生产构建获得独立反馈，不能让 AI 自己证明自己正确。

如何保证 AI 代码的质量与可维护性

我用与人工代码相同、甚至更严格的标准验收生成代码：命名表达业务意图，状态有明确归属，组件和函数保持单一职责，错误能够被感知和恢复，重复抽象建立在真实变化点上。还要检查是否引入了不必要依赖、是否绕开现有公共能力、是否扩大了全局状态、是否制造隐式副作用，以及后续开发者能否在不阅读提示词的情况下维护它。

测试重点放在业务边界和状态转移，而不是追求生成大量浅层用例。AI 生成的测试和实现可能共享同一个错误假设，因此测试通过只能作为证据之一，还需要需求核对、差异审查和真实运行验证。

AI 生成代码量很大时如何做 Code Review

大 diff 本身就是风险信号。我的第一选择是停止继续生成，把改动按“纯机械变化、公共能力、业务逻辑、配置与依赖”拆成独立批次或提交。Review 时按以下顺序进行：

1. 先看范围：文件清单、增删行数、依赖和配置变化是否符合任务边界。
2. 再看高风险点：鉴权、路由、共享状态、缓存、接口写操作、异常处理和发布配置优先于样式与样板代码。
3. 检查语义而非只看语法：数据从哪里来、由谁修改、失败后能否恢复、旧行为是否仍成立。
4. 机械改动可抽样，规则必须全量验证：批量重命名可以抽样并用检索确认残留；业务分支、权限和数据转换不能只抽样。
5. 让验证与提交对齐：每个批次有对应的检查命令和回归路径，确保出现问题时可以定位和回退。

如果一个 AI 生成的改动无法被人在合理时间内解释和 Review，它就不具备可交付性。正确做法是缩小批次或重新实现，而不是因为“已经生成完了”就降低审查标准。

质量与安全边界

• 不向模型提供账号、密钥、生产配置、用户数据或未脱敏日志。
• 不把“AI 说可以”当作验证证据，以真实源码、构建结果和运行行为为准。
• 不未经 Review 直接合并或发布生成代码；最终责任仍在开发者。
• 不要求 AI 凭空补齐业务规则；信息不足时先确认需求或保留显式假设。
• 不为追求生成速度牺牲现有兼容性、代码风格和可维护性。

我如何衡量它是否真的有价值

我不会用“生成了多少行代码”衡量 AI 能力。更有意义的观察是：进入陌生模块是否更快、影响面遗漏是否减少、重复劳动是否下降、修复是否形成验证闭环、文档是否能被后来者使用。若 AI 带来的审查和返工成本高于节省的时间，就应该缩小任务或改用传统方式完成。

能力边界

这段经历证明的是我能把 Codex 稳定接入前端研发流程，并对生成结果进行工程化治理；它不等同于大模型训练、微调或推理平台开发经验。下一步我正在补充 Agent 应用中的工具调用、上下文管理、评测和可观测性，把已有的软件工程经验延伸到 AI 应用开发。

继续阅读：配置化活动平台