Skip to main content

开发工作流

在日常开发中，我会将 AI 深度融入工作流：首先通过配置项目 Rules 统一代码规范；日常需求使用 Agent 模式自动修改；复杂重构采用 Plan 模式渐进式推进；并在方案设计、CRUD 模板生成以及 Code Review 环节利用 AI 全方位提效。

1. 项目级上下文建设 (Rules 设定)​

AI 生成代码质量的第一决定因素是上下文。在进入具体开发前，我会先在项目根目录设定全局规则（如 .cursorrules、.windsurfrules 或 Trae 的项目设置）。

  • 内容包括：技术栈大版本（如 React 18 + TS + Tailwind）、目录结构规范、状态管理规范、命名约定，以及明确指出“绝对不能使用的过时库”。
  • 收益：给 AI 立下规矩，避免它每次都“自由发挥”，让生成的代码风格与现有项目保持高度一致，省去了事后反复纠正和沟通的时间。

2. 日常迭代与 Bug 修复 (Agent 模式 + Skills 联动)​

对于边界清晰的日常需求、或者有明确报错栈的 Bug，我会默认开启 Agent 模式。

  • 执行方式：将需求文档、设计图（利用多模态视觉解析能力）或 Terminal 里的报错日志扔给 AI。
  • 底层技能 (Skills) 联动：在这个过程中，Agent 不是在盲猜，而是自主调用了一系列 Skills：
    1. GetDiagnostics：自动读取 Linter 或 TS 报错。
    2. SearchCodebase (RAG)：拿着报错信息去整个代码库里做向量检索，找到出 Bug 的底层函数。
    3. RunCommand：修改完代码后，Agent 会自己跑 npm run test，看测试是否变绿。
  • 提效点：在这一步，我的角色从“代码编写者”转变成了“代码审查者 (Reviewer)”，只需判断 AI 给出的 Diff 是否合理，极大降低了心智负担。

3. 复杂需求与重构 (Plan 模式渐进式调整)​

当遇到牵一发而动全身的跨模块重构，或者从零开发大型复杂页面时，直接让 Agent 梭哈写代码极易翻车（AI 会陷入上下文混乱、破坏原有逻辑甚至陷入修改死循环）。此时必须切换到 Plan（规划）模式。

  • 工作流拆解：
    • 第一步：使用高阶 Prompt：“你现在是架构师，请不要写具体代码。请帮我把这个复杂需求拆解成 5 个可以独立测试的子任务，并生成 Markdown 格式的 Task List”。
    • 第二步：利用 AI IDE 的 TodoWrite 工具或本地任务管理插件，将这些步骤固化。
    • 第三步：让 AI 严格按照 Task List，一步（一轮对话）只完成一个功能。每完成一步，利用 RunCommand 跑一次构建，确保没有引入回归 Bug。

4. 架构设计与方案评估 (Brainstorming 与外挂知识库)​

在动手写哪怕一行代码之前，我会利用 AI 进行方案探讨，把它当成我的“资深架构师橡皮鸭”。

  • 数据库与数据流设计：给出业务场景，让 AI 帮我设计表结构或全局 Store 结构。这里可以结合 Function Calling，让 AI 调用本地的 ER 图渲染脚本，直接生成一张架构图图片给我。
  • 技术选型评估 (结合 WebSearch 联网检索技能)：比如提问“在当前 Next.js 项目中，我应该用 Zustand 还是 Redux？”。为了防止大模型知识库过期（幻觉），我会强制要求 AI 调用内置的 WebSearch 技能（即赋予 AI 实时访问搜索引擎的能力），先去抓取这两个库的最新 GitHub Release Notes 和 npm 下载量，再基于最新数据给我对比。
  • API 设计：让 AI 帮我规划 RESTful 或 GraphQL 接口，甚至直接生成对应的 TypeScript Interface 和 Mock 数据。

5. 繁琐工作自动化 (CRUD 与模板代码)​

AI 是处理规律性强、重复度高工作的最佳帮手。在高级工作流中，我们可以通过封装 Prompt 模板或开发专属的 Skills/MCP 工具，将这些繁琐工作彻底变成“一键执行”的自动化流水线。

  • CRUD 一条龙 (通过 Prompt 模板固化)：
    • 痛点：每次让 AI 生成后台管理页面，它的表格样式、接口调用格式、Zod 校验规则都不一样，需要反复纠正。
    • 高级解法：在团队内沉淀一份标准的 .prompt 模板。只需要给出数据库表结构，或者一段后端 API 响应的 JSON，配合模板指令：“请严格遵循项目中 @CrudTemplate.tsx 的规范，利用此 JSON 结构生成对应的 TypeScript 类型定义、Zod 校验层、前端 API 请求封装、以及带表单校验的 Ant Design 增删改查页面”。这能瞬间抹平重复劳动。
  • 正则与工具函数 (结合 AI 单元测试)：
    • 高级解法：彻底告别去 Google 搜正则的时代。直接用自然语言描述：“帮我写一个校验国内车牌号的正则”，并强制要求 AI “附带 5 个覆盖边界情况的 Jest 测试用例，且必须通过验证”。通过 TDD 的思路确保 AI 产出的工具函数绝对可靠。
  • 国际化 (i18n) (通过 MCP 工具自动化)：
    • 痛点：每次发版前都要手动把新加的中文词条复制给大模型，翻译完再手动贴回各个语言的 JSON 文件里，极易出错。
    • 高级解法：封装一个名为 AutoTranslateI18n 的 AI Skill (MCP 工具)。只需给 AI 下令：“同步国际化语言包”，AI 就会自动读取项目差异，发现新增的中文词条，调用大模型的翻译能力，然后自动将翻译结果按对应的键值路径写回所有多语言 JSON 文件中。这把原本需要半小时的手工活缩短到了 10 秒钟。

6. Code Review 与代码质量保障​

  • AI Code Review (结合自定义 Lint Prompt 与静态分析)：在提交 PR 之前，我会让 AI 帮我 Review 一遍刚写的代码。
    • 什么是自定义 Lint Prompt：AI 默认的 Review 会非常啰嗦，甚至去纠结缩进和换行。高级做法是配置一个专属的 Code Review Prompt：“请以资深前端安全专家的身份 Review 以下代码。假设该代码已通过 ESLint 和 Prettier 校验，请绝对忽略任何代码格式、缩进、未引用变量等语法问题。你只能且必须关注：内存泄漏（如未解绑的事件）、XSS 漏洞、React 无限重渲染陷阱、以及竞态条件。” 这能极大提高 Review 的信噪比。
    • 与 ESLint/Prettier 的完美结合 (职责分离)：
      1. 前置拦截：通过 Git Husky 配置 pre-commit 钩子，先跑本地的 Prettier 和 ESLint。AST 级别能解决的低级错误（极速、100% 准确），绝对不浪费大模型的 Token。
      2. AI 攻坚疑难 Lint：对于 ESLint 抛出的复杂报错（比如 react-hooks/exhaustive-deps 依赖遗漏，强行 autofix 可能会导致死循环），利用 IDE 的 Agent 模式，把报错日志直接喂给 AI，让它结合上下文去重构 useEffect 逻辑。
      3. 深层逻辑审查：静态分析工具全绿通过后，再触发 AI 的 Custom Lint Prompt，专注于业务语义和架构缺陷的审查。
  • 生成单测与覆盖率保底 (结合自研的 Coverage MCP Server)：
    • 痛点：以前让 AI 写单测，它往往只写一个“Happy Path（主流程）”就交差了。人类还要去手动跑 coverage 看哪里没覆盖到，再让 AI 补，非常割裂。
    • 什么是 Jest Coverage MCP：这是一个需要团队自己用 Node.js 编写的本地 MCP Server 工具（目前市面上尚无通用的、适配所有项目的第三方现成方案）。它的底层原理是封装一个脚本：在后台静默运行 jest --coverage --json，然后解析生成的 coverage-final.json，把未覆盖的代码行数（Uncovered Lines）提取出来转化为纯文本。
    • 闭环工作流：在 IDE 的 Agent 模式下，工作流变成了全自动：
      1. AI 写完基础单测。
      2. AI 主动调用名为 GetTestCoverage 的 MCP 工具。
      3. MCP 返回结果：“当前覆盖率 75%，第 45 行的 if (user.role === 'admin') 分支未覆盖”。
      4. AI 读取到这个反馈后，自动触发纠错机制，补写一个针对 Admin 角色的 Edge Case（边缘用例）。
      5. 再次调用 MCP 检查，直到覆盖率达标（如 >90%），AI 才会停止工作并向你汇报完成。

7. 上下文切换​

  • 如果一次对话上下文太长，会让 AI 生成 memory.md，然后开启下一个对话时先导入这一份 memory.md 文件恢复上下文再继续对话，以尽可能减少上下文丢失，防止处理结果差别太大

业界前沿的进阶工作流 (Advanced Workflows)​

除了在 IDE 中进行代码的修改，目前业界顶尖的 AI 工程化团队正在探索更深度的自动化工作流。如果你在面试中能抛出这些思路，能展现出极高的架构与工程化视野。

7.1 TDD 逆向驱动工作流 (AI-Driven TDD)​

  • 常规痛点：人类写测试用例很痛苦，而直接让 AI 写业务代码又容易出错。
  • 先进工作流：
    1. 开发者（或 AI）首先根据需求文档，用自然语言生成详尽的测试用例代码 (Jest/Vitest)，涵盖所有的正常流程和边界条件。
    2. 测试当然会全部挂掉 (Red)。
    3. 让 AI 编写具体的业务实现代码，直到所有测试用例跑通 (Green)。
    4. 让 AI 在保证测试通过的前提下，进行代码重构 (Refactor)。
  • 优势：把测试用例作为约束 AI 的“终极规则”，彻底解决 AI 生成代码的幻觉和质量不可控问题。

7.2 CLI 与自动化脚本串联 (Terminal-First Workflow)​

  • 应用场景：不要只把 AI 局限在编辑器里，要把它变成命令行的得力助手。
  • 具体实践：
    • Git 自动化：配置 AI 工具分析 git diff，自动生成符合规范（如 Angular Commit Convention）的 Commit Message。
    • Shell 助手：遇到不懂的服务器运维、Docker 配置或复杂的 FFmpeg 转码命令，直接使用 AI 终端工具（如 Warp、Cursor Terminal、GitHub Copilot CLI），让它理解你的需求并自动在终端生成并执行脚本。
    • CI/CD 融合：在 GitLab CI 或 GitHub Actions 中接入 AI，当构建失败或 E2E 测试报错时，由 AI 自动读取报错日志并直接给发起者推送修复建议的 PR。

7.3 Multi-Agent (多智能体协作工作流)​

这属于目前大型科技公司探索的深水区。面对极端复杂的工程需求，单个 Agent 容易在“需求理解、架构设计、代码编写、测试修复”中迷失。

  • 先进思路：将大任务拆分，引入多个专职 Agent 进行协作。
    • PM Agent：负责阅读飞书/Notion 文档，拆解出结构化的 User Story。
    • Architect Agent：基于 User Story 设计数据流、状态树和 API 契约。
    • Coder Agent：只负责根据 Architect 的设计输出具体代码。
    • Reviewer Agent：作为裁判，挑刺 Coder 的代码。如果不符合规范，打回重写。
  • 面试话术：“未来 AI 辅助编程的终极形态，不再是人类与单个 Copilot 对话，而是人类扮演 Team Leader，统筹和管理一个由多个细分领域 AI Agent 组成的虚拟研发团队。”