08 - AI 编程智能体与 Agentic Engineering 实践

章节定位：面试官对您“AI 时代工程效能与前沿工具链”的专项考察。截至 2026 年，AI 编程工具已从“代码补全”进化到“自主智能体”时代。本章涵盖主流 AI Coding Agent 生态、从 Vibe Coding 到 Agentic Engineering 的研发范式演进、动态工作流与对抗性验证质量防线、利用 AI Agent 像素级还原 UI/UX 设计稿合集的工程化闭环、日常开发心智模型与避坑法则，以及对个人技术路线的深刻影响。

Q1：2026 年的 AI 编程工具生态是什么样的？你日常在用哪些？

追问场景：一面或二面开场，面试官想快速了解您对当前 AI 编程工具市场的认知深度。

答：

2026 年 8 月的 AI 编程工具市场，已经和 2025 年完全不同了。形态上分化成了三条清晰的路线：IDE 插件、独立 AI 原生 IDE、终端 CLI Agent。我逐个说明：

第一条路线：IDE 插件派——在 VS Code、JetBrains 等现有编辑器里装插件，补全、对话、重构都在熟悉的界面里完成。代表有 GitHub Copilot（月费 $10，与 GitHub Issues/Actions 深度集成，从 Issue 到 PR 的流程最顺畅）、Kimi Code 的 VS Code 插件（国内直连，¥49/月起）。好处是不用换工具，坏处是受限于宿主编辑器的 API 边界。

第二条路线：独立 AI 原生 IDE——fork 了编辑器源码深度改造，AI 能力渗透到每个角落。代表有 Cursor（行业事实标准，Pro $20/月，2026 年新增了云 Agent、移动端和 CLI）、Devin Desktop（原名 Windsurf，被 Cognition 收购后更名为 Devin Desktop，免费版每月 25 个提示额度）、TRAE Work（字节跳动出品，基础功能免费）。2026 年 8 月，Cursor 还推出了代码托管功能“Origin”的 Beta 版，开始在 IDE 内直接托管源码。

第三条路线：终端 CLI Agent——这是 2025 到 2026 年崛起最快的形态。不给你图形界面，直接在终端里用自然语言对话，Agent 自己读文件、改代码、跑命令、看报错、迭代修复。本质上是把模型当成一个有文件系统权限的开发者，你派活，它执行，你 review。代表有 Claude Code（终端 Agent 的开创者，包含在 Claude Pro 订阅中 $20/月起）、Kimi Code CLI（月之暗面出品，国内直连，支持 /goal 目标驱动模式）、Aider（开源，42K+ GitHub Stars，BYOK 模式）、OpenCode（开源，172K+ GitHub Stars，MIT 协议）。

我日常的主力组合是“Codex + Gemini 双轨驱动”：
- Gemini（前端全栈与多模态架构大脑）：极其适合前端 UI/UX 与多模态视觉交互。我主要利用 Gemini 进行 Figma 高保真设计稿的视觉解析与图生代码（Image-to-Code）、React/Vue 响应式组件组装、Tailwind CSS 样式审美还原，以及利用其百万级 Token 超长上下文通读全仓架构、逆向解析系统时序图/拓扑图并执行 Playwright 视觉走查比对（Visual Diff）。
- Codex（终端 Coding Agent / 后端与执行中枢）：极其擅长核心业务逻辑、终端沙箱执行与测试驱动开发（TDD）。Codex 具备完整的文件系统与命令执行权限，在处理跨模块复杂业务编码、沙箱内运行自动化测试与错误自愈时具备极高的确定性。二者形成了 “Gemini 主攻前端、多模态与宏观架构，Codex 主攻后端逻辑与沙箱自愈落地” 的高效全栈协同体系。

Q2：Vibe Coding 这个概念还在用吗？现在业界怎么定义这个方向？

追问场景：考察您对行业趋势的跟踪深度。面试官想知道您是否还停留在 2025 年的认知水平。

答：

Vibe Coding 这个概念是 Andrej Karpathy 在 2025 年提出的，指开发者通过自然语言向 AI 描述意图，由 AI 自动生成、调试并迭代软件的全新开发范式。

但到了 2026 年 8 月，这个概念已经演进和分化了。 Karpathy 本人在 2026 年进一步阐述：Vibe Coding 没有“死”，而是演化出了一个新的分支——Agentic Engineering。他把专业开发从原始的 Vibe Coding 中单独拎出来，暂称为 Agentic Engineering。

具体来说，Vibe Coding 正在从“目的地品类”向“功能层”演进——它不再是一个“你要专门去用的工具”，而是嵌入到更多工作流中的基础能力。AI 编程工具已成为整个消费级 AI 应用领域中增速最快的品类之一。中科院等研究机构在 arXiv 发表的综述论文将 Vibe Coding 归纳为五种协作模型：从“无约束自动化”到“迭代对话式”到“规划驱动”到“测试驱动”，直到最成熟的“上下文增强协作”——这恰好勾勒出从 Vibe Coding 到 Agentic Engineering 的进化阶梯。

我的理解是：Vibe Coding 是“用自然语言编程”这个宏大概念的统称，而 Agentic Engineering 是它面向专业软件开发者的“严肃版本”——强调规划、验证、测试、代码审查等工程实践，而不是“随便说一句话就让 AI 生成一堆代码然后直接上线”。2026 年的专业开发者，做的已经不是原始的 Vibe Coding，而是 Agentic Engineering。

Q3：2026 年的 AI Coding Agent 有什么新能力是 2025 年没有的？你能举例说明吗？

追问场景：考察您对行业前沿的敏感度，面试官想确认您不只是“知道有这些工具”，而是“真的在用这些新能力”。

答：

2026 年最大的变化是 AI Coding Agent 从“辅助”走向了“自主”。我列几个我实际在用、且明显感受到质变的能力：

能力一：动态工作流（Dynamic Workflows）——Claude Code 2026 年 5 月发布

Claude Code 现在可以动态编写编排脚本，在一个会话中运行数十到数百个并行子智能体，在工作交到你手上之前自行检查结果。这意味着：以前需要你手动拆解成十几个小任务、逐个让 AI 完成的事情，现在 Claude 自己拆、自己分配、自己验证。

实际案例：Jarred Sumner 用 Claude Code 的动态工作流将 Bun 从 Zig 移植到 Rust——75 万行 Rust 代码，从第一次提交到合并仅用了 11 天，99.8% 的现有测试套件通过。一个工作流负责映射每个结构体的 Rust 生命周期，下一个工作流负责编写数百个 .rs 文件（数百个智能体并行工作，每个文件配两个 Reviewer），然后修复循环驱动构建和测试套件直到全部通过。

我在政务小灵通中的实践：虽然没有 Bun 那种规模，但我用 Claude Code 的类似能力做过一次“代码库级别的安全审计扫描”——让 Agent 遍历所有 API 路由，检查是否有缺少权限校验的接口。以前这种事需要 grep 加人工翻阅几十个文件，现在 Agent 十几分钟给我一份带代码位置和修复建议的报告。

能力二：云端智能体与事件驱动（Cloud Agents）——Cursor 2026 年 8 月发布

Cursor 的云端智能体现在可以响应事件自动接手工作：监控你的 PR、关注 Slack 讨论串、运行定时任务。云端智能体会自动订阅自己创建的 PR，并持续推进直至完成——修复 CI 问题、处理 bot 评论。子智能体还可以在各自的虚拟机上运行，每个获得一份隔离的项目副本和干净的上下文。

实际场景：你可以对 Cursor 说“帮我盯着这个 PR，CI 绿了自动合并，有冲突自动解决”——然后去干别的事，Agent 在云端自己跑。

能力三：子智能体并发 + 工作树隔离——Cursor 3.2（2026 年 5 月）

Cursor 3.2 引入了“编码彻底并发”——子智能体 A 改配置中心，B 写路由逻辑，C 埋监控点，最后自动检查兼容性。每个子智能体在自己的“工作树”（Work Tree）中操作，互不干扰。GitHub Copilot 的桌面应用也支持了类似能力——每个会话在自己的 Git 工作树、分支和任务状态中运行。

Q4：AI 生成代码的质量把控，在 2026 年有什么新方法？

追问场景：岗位 JD 明确要求“能够识别 AI 代码缺陷”，此题为必考题。

答：

2026 年的质量把控方法和 2025 年最大的区别是：不再完全依赖“人工 Review”，而是引入了“Agent 审阅 Agent”的自动化验证层。

方法一：动态工作流中的“对抗性验证”（Adversarial Verification）

Claude Code 的动态工作流中，当任务成本很高时，工作流会让 “对抗性智能体”在结果交付给你之前尝试破坏它——独立尝试找出漏洞、边界条件失败、逻辑错误。相当于“让一个 Agent 写代码，让另一个 Agent 专门找茬”，然后再修复，再找茬，循环直到通过。这在 2025 年是做不到的——那时候只有“一个 Agent 生成，你来 Review”。

方法二：Agent Merge + CI 自动化验收（GitHub Copilot 2026）

GitHub Copilot 的桌面应用引入了 Agent Merge——Agent 监视 CI 流水线、下载失败日志、解决合并冲突、自动推送修复，在所有预设的组织条件满足后才自动合并。质量验收不再依赖“人盯着 CI 看”，而是 Agent 自己看、自己修、自己合。

方法三：测试驱动 Agent 工作流（Test-Driven Agent）

中科院的综述论文将“测试驱动”列为 Vibe Coding 的五种协作模型之一。我在实践中也验证了这一点：让 Agent 先写测试，再写实现，最后跑测试验证——这不仅提升了代码质量，还让 Agent 的产出有了“验收标准”。我在政务小灵通中要求 AI 生成代码时必须同步生成 pytest 单元测试，且覆盖率不低于 80%。

我的三层质量防线（2026 版）：

第一层：Agent 自检——利用动态工作流的“对抗性验证”，让 Agent 自己先找一轮 Bug。

第二层：CI 自动化验收——Agent Merge 或类似机制，让 Agent 自己盯着 CI 跑通。

第三层：人类 Review（聚焦高价值判断）——人工 Review 不再检查“语法错误”或“格式问题”（这些 Agent 已经自检过了），而是聚焦“架构合理性”、“业务逻辑正确性”、“安全边界”这些 Agent 难以判断的层次。

Q5：面对 UI/UX 同事交付的一整套高保真设计图合集，如何利用 AI Agent（如 Claude Code / Codex / Cursor 等）实现高保真还原与高质量工程化落地？

追问场景：考察全栈端侧交付、多模态 AI 智能体应用以及现代前端工程化实战能力。面试官想看求职者究竟是停留在“把截图扔给大模型让它写一段杂乱 HTML”的初级玩具级使用，还是具备“利用 Agent 闭环完成设计系统解构、组件工程化拆解、多模态视觉比对校验与交互集成”的专业级 Agentic Engineering 架构思维。

答：

很多开发者在尝试用 AI 还原设计稿时，最容易犯的错误就是 “截图一扔，让 AI 直接生成一整页代码”。这种原始的玩具级做法在真实工程中 100% 会翻车：
- 视觉漂移与魔数横飞（Magic Numbers）：间距（Padding/Margin）忽大忽小、色值随意硬编码、字体字阶不统一，缺乏设计系统支撑；
- 组件孤岛与面条代码：生成一千多行单文件 JSX/Vue，毫无组件分层，缺少 TypeScript 类型契约，完全不可维护；
- 静态假象与极端状态缺失：设计稿是静态的，而真实工程必须防御长文本截断（Truncate/Tooltip）、骨架屏（Skeleton）、错误重试、空状态（Empty State）及响应式断点；
- 画板合集的上下文爆炸：UI/UX 交付的通常是一整套画板合集（主列表、抽屉详情、筛选弹窗、空态等 10+ 画板），一股脑塞给 Agent 会迅速耗尽上下文并导致各画板设计语言前后分裂。

在我的全栈工程实践中，我总结了一套 「5 步 Agentic UI 像素级工程化落地闭环」（DESIGN.md 语义契约与 Tokens 沉淀 → 拓扑拆解与 TS 契约先行 → 子智能体并行构建 → Playwright 视觉对抗 Diff 自愈修正 → 生产级健壮性加固），将设计稿还原度从传统手工的 85% 提升到 98% 以上：

┌─────────────────────────────────────────────────────────────────────────┐
│        Step 1: 设计系统解构与语义 Tokens 契约沉淀 (DESIGN.md / Tokens) │
│  五维矩阵提取: 色彩角色 / 文本阶梯 / 8px 栅格 / 圆角 / 投影海拔 → 注入 Tailwind │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ 统一设计真理源与基座组件库
┌────────────────────────────────────▼────────────────────────────────────┐
│              Step 2: 页面合集拓扑拆解与接口契约声明                      │
│  画板合集梳理 → 三层组件树 (Layout/业务/原子) + TypeScript Props/Mock   │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ 强类型约束与职责边界隔离
┌────────────────────────────────────▼────────────────────────────────────┐
│              Step 3: 子智能体（Subagents）并行构建与组装                │
│  Agent A: 原子与业务组件  │  Agent B: 响应式视图布局  │  Agent C: 状态机交互 │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ 本地 Vite Dev Server 真实渲染
┌────────────────────────────────────▼────────────────────────────────────┐
│       Step 4: Playwright 多视口截图 + 多模态对抗式 Visual Diff 闭环      │
│  无头浏览器真实截图 ◄───► 原始设计稿对比 → 发现 4px 偏差/色差 → 自动迭代修复 │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ 视觉精度 98%+ 收敛达标
┌────────────────────────────────────▼────────────────────────────────────┐
│              Step 5: 生产级健壮性补全与数据解耦 (Production Hardening)  │
│  骨架屏/空状态/溢出 Tooltip/深色模式适配 → 解耦 MSW Mock，无缝对接 API   │
└─────────────────────────────────────────────────────────────────────────┘

第一步：设计系统解构与 Tokens 契约沉淀（DESIGN.md + Design Tokens 双层架构）

建立单一真理源（Single Source of Truth）：
在让 Agent 写具体页面前，先通过 Figma MCP / 多模态视觉分析提取全局 Design Tokens 五维矩阵，沉淀为 .stitch/DESIGN.md（包含头部 YAML Tokens 与正文设计意图说明）并同步至 tailwind.config.js / CSS 变量：
1. 色彩体系（Semantic Colors）：明确功能角色（primary, surface, on-surface, error 等），严禁任意 hex 硬编码；
2. 文本阶梯（Typography Scale）：定义 xs(12px) 到 2xl(24px) 的字号、行高（Line-height）与字重映射，禁止随意写 13px/15px；
3. 8px 栅格间距（Spacing Scale）：所有内外边距与间隙（Gap）严格遵循 4px / 8px / 16px / 24px / 32px 步进，确保不同 DPI 屏幕下无次像素模糊；
4. 圆角与几何（Border Radius）：确立通用基准（如 rounded-md (8px)）并遵循内层半径 $\le$ 外层半径减 Padding 的同心圆角法则；
5. 投影与海拔（Elevation & Shadows）：定义从 shadow-none（贴地）到 shadow-2xl（模态弹窗）的 Z 轴空间深度。

对齐成熟组件库底座：
明确约束 Agent 必须基于项目现有的组件库底座（如 shadcn/ui + Radix UI 或 Ant Design）进行组装，严禁 Agent 重复造轮子手写原生基础控件。

第二步：页面合集拓扑拆解与接口契约声明（Contract-First Component Tree）

面对设计同事交付的几十个画板合集（列表、详情抽屉、过滤弹窗等），坚决禁止让 Agent 直接写 UI，必须先产出架构拓扑与目录结构。

组件树三层拆解：
1. 容器层（Layout Views）：页面网格骨架、导航与面包屑容器、响应式侧边栏；
2. 业务复合层（Feature Components）：表格数据展示、复合筛选器栏、状态卡片组；
3. 基础原子层（Atomic UI）：业务专有徽标（StatusBadge）、指标卡（MetricCard）。

声明 TypeScript 契约：要求 Agent 先编写各组件的 Props Interface 和完整的 Mock 数据结构（Fixtures）。这样后续不同层级的生成都有强类型约束。

第三步：子智能体并行构建与工作树隔离（Subagents Concurrent Generation）

利用 Claude Code 的动态工作流 或 Cursor 3.2 的子智能体并发，将拆解后的模块分发给不同的 Subagent 并行执行：

Subagent A：负责根据设计稿切图构建专有原子组件与 Mock 数据；

Subagent B：基于 TypeScript 契约拼装主视图并实现响应式 Flex/Grid 布局；

Subagent C：负责弹窗/抽屉开关、标签页切换等局部 UI 状态机。

契约防漂移：因为所有 Subagent 都严格遵循第一步的 Design Tokens 和第二步的 TypeScript 类型契约，组装时几乎零冲突。

第四步：Playwright 截图驱动的「多模态对抗式 Visual Diff」闭环调优（核心工程护城河）

这是保证 98%+ 像素级还原度的关键杀手锏，也是区分“玩具级”与“工程级”的核心分水岭：
1. 真实无头渲染：Agent 本地启动 Vite 开发服务器，通过 Playwright / 无头 Chromium 在不同视口（1920px、1440px、768px）下截取真实的页面渲染图。
2. 多模态对抗审查（Adversarial Visual Diff）：将「设计稿原图」与「Playwright 真实截图」成对传入多模态模型，Prompt 要求其作为“严苛的 UI 走查专家”，从像素对齐、行高、字重、内外边距、阴影扩散等方面挑刺：
- “检测到表头高度为 48px，设计稿要求 40px，padding-top 需缩减 4px”；
- “操作按钮字体字重为 regular，设计稿标注为 semibold (600)”；
- “卡片阴影缺失，缺少 shadow-sm 级别投影”。
3. 自主迭代修正（Self-Correction Loop）：Agent 接收到 Diff 报告后，自主修改 CSS 类名，重新执行 Playwright 截屏比对，直到视觉差异收敛在误差阈值内。

第五步：生产级健壮性补全与工程收尾（Production Hardening）

最后，让 Agent 专项针对极端场景进行代码加固，补齐静态设计稿往往没有体现的动态边界：
- 文本溢出与长字段防御：所有可能出现超长文本的单元格加上 truncate 并在悬浮时触发 Tooltip；
- 状态完整性覆盖：自动生成骨架屏（Skeleton）、数据为空时的空状态（Empty State）、接口报错时的错误回退卡片；
- 前后端数据解耦：所有 Mock 数据统一提取至独立 Mock 模块（如 MSW 或 local fixtures），预留好清晰的 RESTful/SSE 数据接入点，为后端接口对接做好准备。

工程价值总结：通过这套流程，原本前端还原一整套复杂后台设计稿需要 3-5 天的手工调试，现在通过 Agent 可以在 半天内完成高质量、带类型保护、高保真且符合设计系统的工程化交付。

Q6：AI 编程工具的 token 消耗和成本怎么控制？这是很多团队关心的问题。

追问场景：面试官会关注“成本意识”——能落地 AI 提效和“不计成本地用 AI”是两码事。

答：

这个问题非常务实。Gartner 2026 年 6 月的报告指出，按当前 token 消耗增速，企业 AI 编程成本预计在 2028 年超过开发者平均薪资，约 2,000 美元/月。成本控制不是锦上添花，是必须面对的工程问题。

我的成本控制策略（三层）：

第一层：工具选型层面的成本优化

Cursor Pro（$20/月）包含每月 500 次高速请求配额，重度使用容易耗尽。我的做法是：日常编码用 Cursor，大规模任务切到终端 Agent（按 API 用量计费，用多少付多少）。

Kimi Code 的 API 缓存命中率超过 90%，缓存命中时输入仅 2 元/百万 Token——这意味着重复或相似的任务几乎不花钱。

Aider/OpenCode 等开源方案：BYOK 模式，你可以接入便宜的模型（如 Gemini 3.7 Flash）来执行低优先级任务。

第二层：工作流层面的“分级使用”

高价值任务（架构设计、核心逻辑） → 用最强模型（Claude Code / Kimi K3），不省 token。

中价值任务（代码生成、单元测试） → 用中等模型，或利用缓存。

低价值任务（格式化、简单重构） → 用 Cursor 的 Tab 补全（几乎不消耗额外 token）或开源方案。

第三层：技术层面的“防跑飞”机制

Claude Code 的动态工作流虽然强大，但官方也提醒“会消耗显著更多的 token”。我的做法是：先在小型范围（如单个模块）上测试，估算 token 消耗量，再扩大到全代码库。

设置 Token 预算上限——在 Agent 会话中设置“如果消耗超过 X token 仍未完成，暂停并向我报告进度”，避免“Agent 跑飞了你还不知道”。

Q7：你是如何用 Codex 进行日常开发的？有何独到经验与避坑心得？

追问场景：考察候选人是否真正将 AI 原生 Coding Agent（如 Codex / 终端智能体）内化为日常开发的肌肉记忆，评估研发心智模型（Mental Model）、工程质量防线、任务切片与防翻车经验。

答：

在我的 AI 原生全栈研发实践中，我彻底摒弃了那种“截图一扔或一句话盲猜”的玩具级 Vibe Coding。我的核心认知是：把 Codex 定位为执行力极高但在长上下文中易漂移的 Junior 工程师，而我扮演架构指挥官（Tech Lead）；绝不依赖虚浮的提示词技巧，而是把经典软件工程的「DDD（领域建模）」、「SDD（契约先行）」与「TDD（沙箱测试自愈）」深度融入 AI 研发流程，构建确定性的工程三角闭环。

我将这套自主沉淀的日常开发体系总结为 「三大方法论工程支柱」 与 「标准化 5 步主轴工作流」：

一、三大方法论工程支柱（DDD + SDD + TDD）

                    ┌───────────────────────────────────────────┐
                    │       1. DDD (Domain-Driven Design)       │
                    │   沉淀 CONTEXT.md / LANGUAGE.md 统一语言   │
                    │   解决：“Agent 听得懂业务、不废话不膨胀”  │
                    └─────────────────────┬─────────────────────┘
                                          │ 统一领域模型与术语输入
                    ┌─────────────────────▼─────────────────────┐
                    │        2. SDD (Spec-Driven Development)   │
                    │   逆向架构拷问产出 PRD 与 ADR 架构决策    │
                    │   解决：“Agent 拿得到清晰契约、目标不跑偏”│
                    └─────────────────────┬─────────────────────┘
                                          │ 拆解为垂直示踪切片 (Tracer Bullets)
                    ┌─────────────────────▼─────────────────────┐
                    │        3. TDD (Test-Driven Development)   │
                    │   驱动沙箱终端红绿自愈循环 (Red-Green)    │
                    │   解决：“Agent 代码有测试护栏、能自主排错”│
                    └───────────────────────────────────────────┘

1. 支柱一：DDD（领域驱动设计）—— 攻克“废话连篇与上下文退化（Context Rot）”

痛点：Agent 空降到具体项目中如果不理解领域专有黑话（Jargon），经常会用 20 个口水词来猜测描述 1 个概念，导致 Token 快速膨胀，破坏 100k 以内的黄金上下文区间（Smart Zone）。
我的工程解法：
在项目根目录维护 CONTEXT.md / LANGUAGE.md，沉淀一套「统一语言字典（Ubiquitous Language）」；
实战对比：
- ❌ 繁琐模糊口语：“当课程某节内容被实际写入物理文件系统生成具体位置时出现级联问题”；
- ✅ 统一领域术语：“物化级联（Materialization Cascade）出现异常”。
统一语言让 Codex 能在极短 Token 内精准理解复杂业务，杜绝语义歧义。

2. 支柱二：SDD（契约驱动开发）—— 攻克“交付物货不对板（Misalignment）”

痛点：人类与 AI 之间存在天然的沟通鸿沟，一句话丢需求（如“帮我写个用户权限模块” ❌）必然导致 AI 盲目猜测与设计漂移。
我的工程解法：
逆向架构拷问会话（Pre-Code Grilling Session）：在写代码前，严禁让 Codex 直接动手，而是命令它先作为严苛的架构师对开发者进行连环质询，穷尽所有边界条件、极端并发、鉴权规则与错误回退；
沉淀单一真理源：拷问结束后自动生成 ADR（架构决策记录） 与不可篡改的 终局目标规范（Destination Document / PRD）；
垂直示踪切片（Tracer Bullet Slicing）：依据 SPEC 将大任务拆解为贯穿端到端的垂直微切片，单个切片严格限制在单次会话可闭环的范围内。

3. 支柱三：TDD（测试驱动开发）—— 攻克“代码暗坑与缺乏自愈护栏”

痛点：AI 生成的代码表面语法完全正确，但暗藏边界 Panic、并发竞态或破坏既有历史功能。
我的工程解法：
严格在沙箱终端中跑通 Red-Green-Refactor 循环：
1. Red（红灯）：Codex 必须先编写能精确复现 Bug 或覆盖新需求的失败测试用例；
2. Green（绿灯）：Codex 编写具体业务逻辑，在终端自主反复执行测试并自愈修复，直到测试全部点绿；
3. Refactor（重构与走查）：在绿灯保护下优化重构，并触发安全与性能专项对抗审查。

二、日常标准化 5 步主轴工作流（The Main Spine Workflow）

在日常开发中，我跑通的标准化全生命周期工程闭环如下：

┌─────────────────────────────────────────────────────────────────────────┐
│ Step 1: 逆向需求拷问与 ADR 沉淀 (Pre-Code Grilling Session)             │
│ Codex 连环深度质询 → 澄清业务边界、极端用例，生成 ADR 架构决策与 PRD   │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ 沉淀 DDD 统一语言 (Ubiquitous Language)
┌────────────────────────────────────▼────────────────────────────────────┐
│ Step 2: 垂直示踪切片分发 (Tracer Bullet Slicing)                        │
│ 将 PRD 拆解为贯穿端到端、单次会话可闭环的垂直切片 (Vertical Slices)     │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ 隔离会话，单票独立执行
┌────────────────────────────────────▼────────────────────────────────────┐
│ Step 3: 沙箱 TDD 自动实现 (Red-Green TDD Loop)                          │
│ 编写红灯测试用例 (Red) → 编写业务实现 → 在沙箱终端执行自愈变绿 (Green) │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ 输出干净的 Git Staging Diff
┌────────────────────────────────────▼────────────────────────────────────┐
│ Step 4: 对抗性代码审查 (Adversarial Code Review) & 架构防腐            │
│ Codex 对照 SPEC/ADR 自审安全与竞态漏洞 → 架构师人工 Sign-Off 确认交付   │
└─────────────────────────────────────────────────────────────────────────┘

Q8：你对 AI 编程工具的未来判断是什么？这对你自己的技术路线有什么影响？

追问场景：考察前瞻性思维，面试官想看您是否有“跟着趋势走”的战略眼光。

答：

我对未来 3 年的判断是三个关键词：“自主化”、“工业化”、“民主化”。

判断一：从“辅助”到“自主”的加速

2026 年已经是 AI Coding Agent 从“辅助”到“自主”的关键转折年。到 2027-2028 年，我判断 “给一个目标，Agent 自己跑完整个 PR” 会成为标准工作流，而不是今天的“高级功能”。Cursor 的云 Agent 已经能监控 PR、响应 Slack 消息，Claude Code 的动态工作流已经能并行调度数百个子智能体——这些能力在 2026 年还是前沿，到 2028 年会是标配。

判断二：从“工具”到“平台”的工业化

a16z 的报告指出，Vibe Coding 正在从“目的地品类”向“功能层”演进。AI 编程能力会像“数据库”或“消息队列”一样，成为开发平台的基础设施层，而不是一个独立的产品。Cursor 推出代码托管功能“Origin”、GitHub Copilot 推出独立桌面应用——工具厂商正在从“AI 编辑器”走向“AI 原生开发平台”。

判断三：开发者的“杠杆率”指数级提升

Cursor 的《开发者习惯报告》显示，到 2026 年 5 月，开发者每周人均编码量翻了一倍以上，单次 PR 新增代码量同比暴涨 2.5 倍。这意味着一个工程师借助 AI Agent，可以完成以前 3-5 人团队的工作量。这对个人来说是巨大的杠杆，对团队来说意味着“小团队能干大事情”。

对我自己的影响：

我的技术路线是 “AI 应用落地（RAG/Agent）+ 高并发后端（Go/Python）+ Agentic Engineering 工作流” 三者的融合。具体来说：
- 不把自己定位成“纯 AI 算法工程师”（我不写模型，我用模型）——这和我在 RAG 项目中的定位一致。
- 也不把自己定位成“传统后端工程师”（CRUD 已经可以被 Agent 大量替代）。
- 我的核心价值是“知道什么任务该交给 Agent、什么任务该自己写、以及如何让 Agent 和人类协作产出高质量代码”——这恰好是 Agentic Engineering 的核心能力。